From owner-v6ops@ops.ietf.org Thu Jan 2 08:01: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 IAA03942 for ; Thu, 2 Jan 2003 08:01:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18U4xX-000O8c-00 for v6ops-data@psg.com; Thu, 02 Jan 2003 05:00:27 -0800 Received: from e32.co.us.ibm.com ([32.97.110.130]) by psg.com with esmtp (Exim 3.36 #2) id 18U4xU-000O82-00 for v6ops@ops.ietf.org; Thu, 02 Jan 2003 05:00:24 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02D0An0027136; Thu, 2 Jan 2003 08:00:10 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-231-6.mts.ibm.com [9.65.231.6]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02D08tT058950; Thu, 2 Jan 2003 06:00:09 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h02CwYD03813; Thu, 2 Jan 2003 07:58:34 -0500 Message-Id: <200301021258.h02CwYD03813@cichlid.adsl.duke.edu> To: Jonne.Soininen@nokia.com cc: pekkas@netcore.fi, v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt In-Reply-To: Message from of "Mon, 30 Dec 2002 20:46:02 PST." <4D7B558499107545BB45044C63822DDE0175DA99@mvebe001.americas.nokia.com> Date: Thu, 02 Jan 2003 07:58:34 -0500 From: Thomas Narten X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > yep, I only did editorial nits, and tried to make it conformant with > the ID nits. However, I did not split the references to normative > and informative. The document is going to be Informational, and so I > would guess that all references are informative by definition. (This > would be my understanding.) Whether a reference is normative or not has little to do with whether a document is on standards track or not. It has to do with how critical the reference is to understanding and/or implementing the document at issue. I.e, if a document says, one SHOULD/MUST do foo, as defined in RFC XXX, that is a normative reference, as one can't really implement foo without having the referenced document at hand. It does not matter whether the documents are or are not on the standards track. Thus, it is useful to split references into info/normative in almost all cases. This helps the *reader* better understand whether the reference is just informational or more important. See draft-rfc-editor-rfc2223bis-03.txt. Thomas From owner-v6ops@ops.ietf.org Fri Jan 3 23:32:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25333 for ; Fri, 3 Jan 2003 23:32:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UfzR-0000NE-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 20:32:53 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18UfzF-0000M9-01 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 20:32:41 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12125 for ; Fri, 3 Jan 2003 17:41:02 -0700 (MST) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8500B6QZ8DPR@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 17:41:02 -0700 (MST) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H85006GQZ8C8P@mail.sun.net> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 17:41:01 -0700 (MST) Date: Fri, 03 Jan 2003 16:41:00 -0800 From: Alain Durand Subject: Re: Request to Publish ISATAP To: Fred Templin Cc: itojun@iijlab.net, Christian Huitema , Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush Message-id: <3E162D9C.7020404@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: <20030104002536.55296.qmail@web13003.mail.yahoo.com> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Fred Templin wrote: >Alain, > >Sorry for moving so quickly on this, but I submitted a -10.txt >draft before seeing your message. It can be viewed at: > > http://www.geocities.com/osprey67/isatap-10.txt > > This is somehow better, but there are still problems. I hope you can fix them in -11. 2. There are no mandatory rules for the selection of a FQDN, but administrators are encouraged to use the convention "isatap.domainname" (e.g., isatap.example.com.) The -10 draft says nothing on how this name is communicated from the site Isatap administrator to the isatap nodes. I guess the draft should say this is done by an out-of band method,e.g. manual configuration. If this is the case, then I would strongly recommend you add some text to say that in the absence of configuration data, implementations MUST NOT assume that isatap.domainame will work, and in particular MUST provide a way for the user to configure that parameter. - Alain. From owner-v6ops@ops.ietf.org Fri Jan 3 23:32:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25347 for ; Fri, 3 Jan 2003 23:32:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UfzH-0000MP-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 20:32:43 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18UfzF-0000M9-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 20:32:41 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05182 for ; Fri, 3 Jan 2003 18:51:37 -0700 (MST) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8600HF32I0JK@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 18:51:37 -0700 (MST) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H86006RD2I099@mail.sun.net> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 18:51:36 -0700 (MST) Date: Fri, 03 Jan 2003 17:51:36 -0800 From: Alain Durand Subject: Re: on NAT-PT To: itojun@iijlab.net Cc: v6ops@ops.ietf.org Message-id: <3E163E28.8090406@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: <20030104011808.2E0634B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT itojun@iijlab.net wrote: >>>you have been ignoring my comment (i made this comment months ago) >>>to use "AD is secure" for the response from DNS-ALG. >>> >>> >>> >>Let met get back to this now. >> >>The fundamental issue is that nodes do not know >>about the potential presence of a DNS ALG, >>so they can not decide if it is OK to do recursive >>queries themselves or if they have to use "AD is secure" >>and send DNS queries to a trusted recursive resolver. >> >> > > i guess you are talking about something different. > > if the site administration policy is to use a recursive resolver > and "AD is secure", this does not matter whether the recursive > resolver is DNS-ALG or not. the whole point of "AD is secure" is to > offload the implementation complexity of DNSSEC from the end clients > and put it into recursive resolver. > >itojun > > I think yes, were are talking about something different. Yes, using 'AD is secure' works and solve the particular problem I'm describing. What I'm saying is that imposing to use 'AD is secure' to operate DNSsec in IPv6 networks is a big step that I'm not sure I'm ready to make. - Alain. From owner-v6ops@ops.ietf.org Fri Jan 3 23:38:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25526 for ; Fri, 3 Jan 2003 23:38:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ug7e-0000lz-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 20:41:22 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Ug7U-0000lL-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 20:41:12 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 2E0634B22; Sat, 4 Jan 2003 10:18:08 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Fri, 03 Jan 2003 13:32:52 PST. <3E160184.2060808@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Sat, 04 Jan 2003 10:18:08 +0900 Message-Id: <20030104011808.2E0634B22@coconut.itojun.org> X-Spam-Status: No, hits=1.6 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>you have been ignoring my comment (i made this comment months ago) >>to use "AD is secure" for the response from DNS-ALG. >> >Let met get back to this now. > >The fundamental issue is that nodes do not know >about the potential presence of a DNS ALG, >so they can not decide if it is OK to do recursive >queries themselves or if they have to use "AD is secure" >and send DNS queries to a trusted recursive resolver. i guess you are talking about something different. if the site administration policy is to use a recursive resolver and "AD is secure", this does not matter whether the recursive resolver is DNS-ALG or not. the whole point of "AD is secure" is to offload the implementation complexity of DNSSEC from the end clients and put it into recursive resolver. itojun From owner-v6ops@ops.ietf.org Fri Jan 3 23:39: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 XAA25541 for ; Fri, 3 Jan 2003 23:39:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ug7V-0000ld-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 20:41:13 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Ug7U-0000lK-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 20:41:12 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C711A4B24; Sat, 4 Jan 2003 10:18:36 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Fri, 03 Jan 2003 10:21:20 PST. <3E15D4A0.7070302@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Sat, 04 Jan 2003 10:18:36 +0900 Message-Id: <20030104011836.C711A4B24@coconut.itojun.org> X-Spam-Status: No, hits=1.6 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> so you don't apologize for attacking me on "product advertisement"? >> how nice. >My words were too strong, but yours are sometime strong too. >I guess this is because none of us are native english speaker. so you don't know how to apologize in English? itojun From owner-v6ops@ops.ietf.org Fri Jan 3 23:55: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 XAA25737 for ; Fri, 3 Jan 2003 23:55:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UgNc-0001q3-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 20:57:52 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18UgNb-0001pe-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 20:57:51 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 9D18F4B25; Sat, 4 Jan 2003 13:33:06 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Fri, 03 Jan 2003 20:28:46 PST. <03E6FD6D-1F9D-11D7-9565-00039376A6AA@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Sat, 04 Jan 2003 13:33:06 +0900 Message-Id: <20030104043306.9D18F4B25@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>> What I'm saying is that imposing to use 'AD is secure' >>> to operate DNSsec in IPv6 networks is a big step >>> that I'm not sure I'm ready to make. >> you are generalizing it too much by saying "in IPv6 networks" - what >> i'm suggesting is to use "AD is secure" for NAT-PT, that's all. >> it doesn't have to be imposed for all IPv6 networks. >So you're back to my previous question. The context is now clearer, >thanks. >How does the end node knows it is behind a NAT-PT box? end nodes do not need to know if it is behind a NAT-PT box or not. their connections will be invited to NAT-PT translation device by a matter of site administration policy (use specific recursive resolver), that's all. the use of "AD is secure" is not directly dependent to DNS-ALG, you could use it even when you are using normal recursive resolver. i suggested the use of "AD is secure" because you asked how you can use DNSSEC with NAT-PT. itojun From owner-v6ops@ops.ietf.org Sat Jan 4 00:15: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 AAA25990 for ; Sat, 4 Jan 2003 00:15:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ugh8-0002jg-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 21:18:02 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18Ugh5-0002j9-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 21:17:59 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29280 for ; Fri, 3 Jan 2003 15:50:19 -0700 (MST) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8500BNSRIMPR@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 14:54:23 -0700 (MST) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H8500L0BRILHD@mail.sun.net> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 14:54:22 -0700 (MST) Date: Fri, 03 Jan 2003 13:54:21 -0800 From: Alain Durand Subject: Re: Request to Publish ISATAP To: Fred Templin Cc: itojun@iijlab.net, Christian Huitema , Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush Message-id: <3E16068D.1080802@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: <20021231230949.32247.qmail@web13005.mail.yahoo.com> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Fred Templin wrote: >Itojun, > >I will not go into the specifics of your message dated 12/24/02, >but would ask that you review and comment on the latest version >of the draft found at: > > http://www.geocities.com/osprey67/isatap-09.txt > I still have a problem with the DNS solution in draft-09: When DNS fully-qualified domain names are used, IPv4 addresses for the PRL and SASL are discovered through a static host file or by querying an IPv4-based DNS server to resolve the domain names into address records (e.g., DNS 'A' resource records) containing IPv4 addresses. Unspecified alternative methods for domain name resolution may also be used. The following notes apply when DNS fully-qualified domain names are used: 1. Site administrators maintain domain names and IPv4 addresses for the PRL and SASL for the site's ISATAP service, e.g., as address records in the site's name service. Administrators may also advertise the domain names in a DHCPv4 option for ISATAP. ==> You are making the assumption that "site's name service" and "site's ISATAP service" have the same topology. This asumption is now always valid,for example at SUN we have some domain names like eng.sun.com which span across different geographies. I support Itojun's suggestion to drop all reference to DNS in this section. - Alain. From owner-v6ops@ops.ietf.org Sat Jan 4 00:28: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 AAA26179 for ; Sat, 4 Jan 2003 00:28:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ugtv-0003Pg-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 21:31:15 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18Ugtt-0003PK-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 21:31:14 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id BFA3F4B23; Sat, 4 Jan 2003 11:00:46 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Fri, 03 Jan 2003 17:51:36 PST. <3E163E28.8090406@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Sat, 04 Jan 2003 11:00:46 +0900 Message-Id: <20030104020047.BFA3F4B23@coconut.itojun.org> X-Spam-Status: No, hits=1.6 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I think yes, were are talking about something different. >Yes, using 'AD is secure' works and solve the particular >problem I'm describing. as far as i understand the use of recursive resolver (DNS-ALG) is part of the deal in NAT-PT. so the point you made previously (nodes that make recursive query by themselves) are not covered/supported by NAT-PT. >What I'm saying is that imposing to use 'AD is secure' >to operate DNSsec in IPv6 networks is a big step >that I'm not sure I'm ready to make. you are generalizing it too much by saying "in IPv6 networks" - what i'm suggesting is to use "AD is secure" for NAT-PT, that's all. it doesn't have to be imposed for all IPv6 networks. itojun From owner-v6ops@ops.ietf.org Sat Jan 4 00:34: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 AAA26283 for ; Sat, 4 Jan 2003 00:34:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Ugzh-0003bC-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 21:37:13 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18Ugzf-0003ak-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 21:37:11 -0800 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23448 for ; Fri, 3 Jan 2003 11:21:22 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8500H7IHNLJK@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 11:21:22 -0700 (MST) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H8500L0KHNKI8@mail.sun.net> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 11:21:21 -0700 (MST) Date: Fri, 03 Jan 2003 10:21:20 -0800 From: Alain Durand Subject: Re: on NAT-PT To: itojun@iijlab.net Cc: v6ops@ops.ietf.org Message-id: <3E15D4A0.7070302@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: <20021224022552.D39C64B27@coconut.itojun.org> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT itojun@iijlab.net wrote: > so you don't apologize for attacking me on "product advertisement"? > how nice. > My words were too strong, but yours are sometime strong too. I guess this is because none of us are native english speaker. Anyway, happy new year! - Alain. From owner-v6ops@ops.ietf.org Sat Jan 4 00:49: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 AAA26502 for ; Sat, 4 Jan 2003 00:49:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18UhEI-00044u-00 for v6ops-data@psg.com; Fri, 03 Jan 2003 21:52:18 -0800 Received: from web13003.mail.yahoo.com ([216.136.174.13]) by psg.com with smtp (Exim 3.36 #2) id 18UhEG-00044i-00 for v6ops@ops.ietf.org; Fri, 03 Jan 2003 21:52:16 -0800 Message-ID: <20030104002536.55296.qmail@web13003.mail.yahoo.com> Received: from [205.226.2.67] by web13003.mail.yahoo.com via HTTP; Fri, 03 Jan 2003 16:25:36 PST Date: Fri, 3 Jan 2003 16:25:36 -0800 (PST) From: Fred Templin Subject: Re: Request to Publish ISATAP To: Alain Durand Cc: itojun@iijlab.net, Christian Huitema , Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush In-Reply-To: <3E16068D.1080802@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.6 required=5.0 tests=DATE_IN_PAST_03_06,FROM_ENDS_IN_NUMS,IN_REP_TO, MAILTO_TO_SPAM_ADDR,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, Sorry for moving so quickly on this, but I submitted a -10.txt draft before seeing your message. It can be viewed at: http://www.geocities.com/osprey67/isatap-10.txt while awaiting submission to the I-D repository. I think you will find that this version addresses your concerns somewhat, but perhaps not completely. My expectation (and sincere hope) is that we can finalize all remaining issues in a soon-to-be-released -11.txt draft. In the meantime, please formalize any additional comments with reference to -10. Regards, Fred Templin osprey67@yahoo.com --- Alain Durand wrote: > I support Itojun's suggestion to drop all reference to DNS in this section. > > - Alain. __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-v6ops@ops.ietf.org Sun Jan 5 17:59: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 RAA11822 for ; Sun, 5 Jan 2003 17:59:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VJhF-000E3A-00 for v6ops-data@psg.com; Sun, 05 Jan 2003 14:56:45 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18VJhC-000E2x-00 for v6ops@ops.ietf.org; Sun, 05 Jan 2003 14:56:43 -0800 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10191 for ; Fri, 3 Jan 2003 15:31:11 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H850053EQISCW@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 14:32:53 -0700 (MST) Received: from sun.com ([129.146.18.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H8500LHIQISI8@mail.sun.net> for v6ops@ops.ietf.org; Fri, 03 Jan 2003 14:32:52 -0700 (MST) Date: Fri, 03 Jan 2003 13:32:52 -0800 From: Alain Durand Subject: Re: on NAT-PT To: itojun@iijlab.net Cc: v6ops@ops.ietf.org Message-id: <3E160184.2060808@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: <20021224022552.D39C64B27@coconut.itojun.org> X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT itojun@iijlab.net wrote: >you have been ignoring my comment (i made this comment months ago) >to use "AD is secure" for the response from DNS-ALG. > Let met get back to this now. The fundamental issue is that nodes do not know about the potential presence of a DNS ALG, so they can not decide if it is OK to do recursive queries themselves or if they have to use "AD is secure" and send DNS queries to a trusted recursive resolver. - Alain. From owner-v6ops@ops.ietf.org Mon Jan 6 08:37: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 IAA03312 for ; Mon, 6 Jan 2003 08:37:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VXSx-000G0x-00 for v6ops-data@psg.com; Mon, 06 Jan 2003 05:38:55 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18VXSw-000G0j-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 05:38:54 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18VXSw-000BXb-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 05:38:54 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: v6ops@ops.ietf.org Subject: co-chair Message-Id: Date: Mon, 06 Jan 2003 05:38:54 -0800 X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit bob fink has graciously accepted my, and others', repeated begging to co-chair v6ops with itojun and margaret. many thanks, bob. randy From owner-v6ops@ops.ietf.org Mon Jan 6 16:52: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 QAA16191 for ; Mon, 6 Jan 2003 16:52:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Vf9l-0004QS-00 for v6ops-data@psg.com; Mon, 06 Jan 2003 13:51:37 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Vf9F-0004Ou-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 13:51:05 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h06Lp2i19288 for ; Mon, 6 Jan 2003 23:51:02 +0200 Date: Mon, 6 Jan 2003 23:51:02 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: new 6to4 security draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Based on the discussion a month ago, I've updated my 6to4 security draft. Hopefully I didn't lose any significant points along the way. It has been submitted to the I-D repository, but it's available in the meantime from: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-6to4-security-02.txt Updates include (probably forgot something): - add a table and some extra text in summary of threat analysis to make comparisons easier - add a threat to relays (a copy of "relay spoofing" 5.2.2) which is possible if IPv6 source address spoofing is possible (perhaps I was a bit too naive about ipv6 ingress-filtering.. :-) - add a few short sections on proposed threat mitigation methods - remove discussion of using 192.88.99.1 as source - minor text addition on strong crypto mechanisms - editorial updates In conclusion, it seems like we're heading towards a situation where we either have to decide that these are not significant problems or specify and implement some iTrace-like mechanism *) in certain spots of the infrastructure (e.g. 6to4 router's decapsulation path could ok). Or do some bigger changes like the "More specific 6to4 routes" thing, also described in the draft. Comments, text, etc. welcome. *) it seems to me that iTrace has been in a stall for the last 1-1.5 years or so, so if a mechanism is needed one should either figure out why there has been no progress (e.g. an architectural doubt about sending traces all over the internet) or whether a simplified mechanism should be developed independently. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Jan 6 19:36: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 TAA20160 for ; Mon, 6 Jan 2003 19:36:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VhjQ-0008g5-00 for v6ops-data@psg.com; Mon, 06 Jan 2003 16:36:36 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Vhiv-0008fB-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 16:36:05 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Vhiv-000Du8-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 16:36:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: From: "MicklesCK" To: "Pekka Savola" , Subject: RE: isp-cases-02 comments Date: Mon, 6 Jan 2003 17:40:56 -0500 X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ 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. ] See my comments "in line" below. A new draft was submitted with those changes and a few others. > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Pekka Savola > Sent: Sunday, November 17, 2002 6:08 PM > To: v6ops@ops.ietf.org > Subject: isp-cases-02 comments > > > Hello, > > First, it seems that some/many of my earlier comments: > > Date: Wed, 18 Sep 2002 18:25:58 +0300 (EEST) > From: Pekka Savola > To: Cleve Mickles > Cc: v6ops@ops.ietf.org > Subject: ISP scenarios comments > > haven't been integrated or commented on. Frustrating. > > As for the other issues that struct me while reading.. > > Substantial: > > 3.1.3.4.....Multicast > Multicast is not widely deployed in CORE networks. To > implement multicast, > providers have deployed parallel infrastructure using Unix > hosts running > mboned or dvmrp on separate routers. > > ==> I don't know which providers (today) do that, but all I know either > don't do multicast at all, or do it using PIM. Added a reference to reflect the recommended solution for Multicast is PIM-SM. > > 3.1.4. Traffic Engineering > > ==> advertisements between and inside ISP's today are also TE (some of > them are multihoming, of course). There may be a problem with this if > certain policies disallow more specifics. > I'm not sure how to change the verbiage here. I can remove the reference but some ISPs do fiddle( not recommended ) with advertisements to perform TE. > 3.1.5.2.....Ingress Filtering > > ==> note that ingress filtering can also be implemented as static access > lists, not just as uRPF. > Added the note about static filtering. > Cable modems use a combination of policy settings and IGMPv2[RFC2236] > to control multicast forwarding (see Section 3.3.1 [DOCSIS-1.1]). > Forwarding of IPv6 multicast datagrams may not occur properly as CMs > are required to forward multicast datagrams only when CPE equipment > has joined that group. This is potentially a show-stopper if native > IPv6 Neighbor Discovery[RFC2461] is being used through a CM. > > ==> this may or may not be related to the multicast problems presented at > draft-savola-v6ops-multicast-issues-01. If not, I'd like to hear > comments from people more familiar with the inner workings cable modems. > > 3.2.4. HFC IPv6 Deployment Options > > ==> some of these might be (to some degree of detail) better off in the > yet-to-come solutions document. Agreed. Section was removed from the scenario document. > > 3.2.8 Network Management > > DOCSIS cable modems use an out of band, privately addressed IPv4 > network for configuration and network management functions. > > ==> I don't really know DOCSIS, but is it _really_ out-of-band? > How is it separated from the rest of the traffic? > > 3.4.6. Network Management > [dialup] > > ==> especially in dial-up, the ISP usually collects some info > like userid, > IP address, time connected, etc. for accounting purposes. These > accounting tools may need to support v6 addresses too. > Added the note. > 3.6.1.1 Physical architecture of public wireless LAN > > Public wireless LAN (WLAN) enables subscribers within home, office or the > outdo > > Figure 3.6.1 describes the physical architecture of wireless LAN model. > > +-------+ > | AAA | > | Radius| > | TACACS| > '---' +-------+ > ( ) | > +-----+ (Wireless) +----+ /------------\ +-------+ > |Hosts+--( LAN )---| AP |----| Underlying \--- | ISP |==> Core > +-----+ ( ) +----+ \ technology | | Edge | > ( ) \-----------/ | Router| > '---' +-------+ > > ==> isn't this a simplification? Where's the access router here? Are > these routed/bridged connections? (1 AP/subnet or possibly many > APs/subnet) > > ==> in bridged case, may have v6-specific considerations. > > Like ethernet, IEEE 802.11 standard dose not define authentication and > security mechanisms. Moreover, WLAN is basically a broadcast network > and each host can l two authentication mechanisms: (1) IEEE 802.1x > and (2) non-standard MAC address based authentication. > > ==> I believe there are many other ways to build WLAN's that using these > two authentication techniques (e.g. some web hijacking + auth). > > 3.6.4.1 IEEE 802.1x based authentication > > IEEE 802.1x enables edge devices such as bridge or AP to perform > authentication mechanism, and determines whether to allow or block data > transmitted by hosts. It uses extended authentication protocol (EAP) as a > standard protocol to transmit subscriber's authentication data. > Authentication is based of userID and/or password, and packets transmitted > by un-authenticated hosts are filtered and dropped by AP Figure 3.6.3 > describes logical architecture of 802.1x based authentication > > ==> I can't see how eavesdropping couldn't be used to cause MITM or steal > credentials, but I'm not sure if more detailed discussion of 802.1x > belongs here. > > 3.6.4.4 Intrusion Detection, Ingress Filtering, and Prevention > > ==> one particular point about WLAN's is that as they're usually more > widely available (think of "war-driving"), attempts for malicious > activies > are more probably higher too -- there may have to be more monitoring > activities than other access methods usually. > > > > Editorial: > > ==> the lines are way too long, the limit is 72 chars. Fixed. > > ==> different scenarios under section 3 should really be their own > higher-level sections -- that would reduce the nesting a bit; listing all > the levels of requirements (IGP, EGP, ...) may not be usable in ToC, it > just makes it longer. Adjusted the numbering and removed the nested levels from the TOC. > > 3.1.6.2.....Configuration Tools > Many ISPs have monitoring tools that query the network gear to > gather data. > These scripts are written in perl or expect and will access > the device via the CLI over the in-band ipv4 connection. > > ==> not so definite, please (at least s/are written/may be written/) changed. > > > A CMTS MAY also be an IPv6 router and thus support IPv6 natively. > > ==> should this special-uppercase keywording be a bit more restricted, to > cases it's really useful for -- the document is not meant to be > normative, I think -- s/MAY/may/ ? corrected. > > Some small ISPs do not even provide global addresses to their > customers. These ISPs then operates NATs on their backbones. > > ==> s/operates/operate/ corrected. > > Once a subscriber is considered as valid, information > exchanged between AP > > ==> s/as// ? ...not sure what the previous comment means? Thanks, Cleve... > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > From owner-v6ops@ops.ietf.org Mon Jan 6 19:35: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 TAA20150 for ; Mon, 6 Jan 2003 19:35:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Vhjw-0008hI-00 for v6ops-data@psg.com; Mon, 06 Jan 2003 16:37:08 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18VhjB-0008fM-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 16:36:21 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18VhjB-000DuE-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 16:36:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: <20021128031015.9B0E44B22@coconut.itojun.org> From: "MicklesCK" To: Cc: "V6ops" Subject: RE: ISP Cases Draft: Which sections have too much information? Date: Mon, 6 Jan 2003 17:44:58 -0500 X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ 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. ] I've removed more of the figures from the DSL section of the draft. We can continue to pair it down as necessary but I wanted folks to see the draft with the changes so far. The draft should be posted shortly. Cleve... > -----Original Message----- > From: itojun@itojun.org [mailto:itojun@itojun.org]On Behalf Of > itojun@iijlab.net > Sent: Wednesday, November 27, 2002 10:10 PM > To: micklesc@aol.net > Cc: V6ops > Subject: Re: ISP Cases Draft: Which sections have too much information? > > > >From the WG meeting today there was consensus that there > >was too much information in the draft. Can we get specific > >feedback on which sections should be paired back? > >http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-02.txt > > i understand your motive to document the operational details, but > i don't think the detail all down to the copper level will help > readers - readers will need a proper level of abstraction. > > for instance: > > page 20, figure 3.3.2 > page 22, figure 3.3.3 > page 23, figure 3.3.4 > do you really need to go into ATM/AAL5? i don't think it make any > difference even if we remove all ATM/AAL5 details (there's no real > reference to ATM/AAL5 in the text). there's no reference to PPPoE, > or PPPoA - there's no difference in the description. the most > important points are > (1) there are 3 IP devices - customer hosts, customer router, and > ISP edge router > (2) customer router and ISP edge router will establish a > point-to-point > connectivity, either by ATM PVC, PPPoE, or PPPoA. > (3) in some cases, ISP edge router uses L2TP to aggregate > connections > (4) customer router may implement NAT (sigh) > > if you abstract it to proper level, subsections in 3.3.2 will become > a single diagram. > > <--customer------> <--ISP----------> > > +-----+ +-------+ +----+------+ > |Hosts|--+Router +----------------+ ISP | C > +-----+ +-------+ | Edge +=>O > | Router | R > +-----------+ E > > same goes to section 3.6 (public access wireless LAN). i > don't think > there's any difference between 802.11b-based solution and > 802.11x-based > solution, with respect to IPv6 transition. > > itojun > From owner-v6ops@ops.ietf.org Tue Jan 7 01:58:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25296 for ; Tue, 7 Jan 2003 01:58:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18VniI-000JY0-00 for v6ops-data@psg.com; Mon, 06 Jan 2003 22:59:50 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Vnhn-000JWG-00 for v6ops@ops.ietf.org; Mon, 06 Jan 2003 22:59:19 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h076xD022590; Tue, 7 Jan 2003 08:59:13 +0200 Date: Tue, 7 Jan 2003 08:59:12 +0200 (EET) From: Pekka Savola To: MicklesCK cc: v6ops@ops.ietf.org Subject: RE: isp-cases-02 comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,TO_LOCALPART_EQ_REAL,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks. Responding only to two unclear comments. On Mon, 6 Jan 2003, MicklesCK wrote: > > 3.1.4. Traffic Engineering > > > > ==> advertisements between and inside ISP's today are also TE (some of > > them are multihoming, of course). There may be a problem with this if > > certain policies disallow more specifics. > > > > I'm not sure how to change the verbiage here. I can remove the > reference but some ISPs do fiddle( not recommended ) with > advertisements to perform TE. I'll check the next revision. > > Once a subscriber is considered as valid, information > > exchanged between AP > > > > ==> s/as// ? > > ...not sure what the previous comment means? Just that I think it should be "considered valid" not "considered as valid", but I'm not 100% sure. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Jan 9 11:03: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 LAA15887 for ; Thu, 9 Jan 2003 11:03:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18WfAw-000KaO-00 for v6ops-data@psg.com; Thu, 09 Jan 2003 08:04:58 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 18WfAm-000KZG-00 for v6ops@ops.ietf.org; Thu, 09 Jan 2003 08:04:48 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h09G4Ehk049716 for ; Thu, 9 Jan 2003 17:04:15 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h09G4ETL029082 for ; Thu, 9 Jan 2003 17:04:15 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA07460 from ; Thu, 9 Jan 2003 17:04:13 +0100 Message-Id: <3E1D9D57.9D93BC24@hursley.ibm.com> Date: Thu, 09 Jan 2003 17:03:35 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt References: <3E00FE9D.5050206@sun.com> <3E0106A9.9050003@iprg.nokia.com> <3E010A7D.40102@sun.com> <3E010DE7.5060805@iprg.nokia.com> <3E010E01.7010906@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (catching up on old mail) It's probably worth saying yet again that without ingress filtering in place, we are exposed to an infinity of spoofing attacks, and 6to4 spoofing is a drop in the ocean. So two basic assumptions, that should probably be stated clearly in the draft, are that ISPs run ingress filtering, and that 6to4 routers and relays are correctly implemented. Without these conditions, there is no hope anyway. Brian Alain Durand wrote: > > Fred L. Templin wrote: > > > > > Maybe I'm behind the times here, but when I last looked at DDoS > > attacks randomly varying the IPv4 source address was an element > > that made the attacks particularly difficult to trace. At that > > time, it was not necessarily true that all sites in the global > > IPv4 Internet properly configured IPv4 ingress filtering. Are > > you saying this is no longer the case? > > Some ISPs do ingress filtering, some don't. > The issue here is to make sure 6to4 will not be used > as a way to bypass ingress filtering when/if in place. > > - Alain. From owner-v6ops@ops.ietf.org Thu Jan 9 15:02: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 PAA24955 for ; Thu, 9 Jan 2003 15:02:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Wiv2-0000UP-00 for v6ops-data@psg.com; Thu, 09 Jan 2003 12:04:48 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Wiuz-0000U7-00 for v6ops@ops.ietf.org; Thu, 09 Jan 2003 12:04:45 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h09K4ci12912; Thu, 9 Jan 2003 22:04:38 +0200 Date: Thu, 9 Jan 2003 22:04:38 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt In-Reply-To: <3E1D9D57.9D93BC24@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 9 Jan 2003, Brian E Carpenter wrote: > It's probably worth saying yet again that without ingress filtering > in place, we are exposed to an infinity of spoofing attacks, and > 6to4 spoofing is a drop in the ocean. So two basic assumptions, that > should probably be stated clearly in the draft, are that ISPs run > ingress filtering, and that 6to4 routers and relays are correctly > implemented. Without these conditions, there is no hope anyway. Well, yes -- it should be made more clear. But also, no -- 6to4 and similar mechanisms could also be nice tools to distract spoofed attacks, even if there wasn't ingress filtering used at all. That is, because tracing spoofed DoS attacks currently involves basically tracing back packets hop-by-hop. At some point, it usually gets impossible to do. If you are nextdoor neighbors topology-wise, 6to4 or similar mechanisms could be used to launder this traffic so it would appear to come from somewhere else. Obviously, the second point would be moot if iTrace - like mechanisms would be generally deployed. And perhaps, the second kind of attacks are a bit on the theoretical side anyway -- unless the first kind is proven unsuccessful enough, most attackers don't really want to bother figuring out how they could use 6to4 etc. as an extra indirection layer. I don't think it's realistic to assume the world, either v4 or v6 will run ingress filtering to a significant enough level -- so that we wouldn't have to worry about spoofing. Instead, using tracing mechanisms we could 1) make internet a much better place, and 2) find those folks who don't obviously do ingress filtering and start bugging them _directly_ (think of the lists of known "directed-broadcast reflectors" some years ago) to install them. > Alain Durand wrote: > > > > Fred L. Templin wrote: > > > > > > > > Maybe I'm behind the times here, but when I last looked at DDoS > > > attacks randomly varying the IPv4 source address was an element > > > that made the attacks particularly difficult to trace. At that > > > time, it was not necessarily true that all sites in the global > > > IPv4 Internet properly configured IPv4 ingress filtering. Are > > > you saying this is no longer the case? > > > > Some ISPs do ingress filtering, some don't. > > The issue here is to make sure 6to4 will not be used > > as a way to bypass ingress filtering when/if in place. > > > > - Alain. > -- 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 Jan 14 10:17: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 KAA26963 for ; Tue, 14 Jan 2003 10:17:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YSoL-000I7v-00 for v6ops-data@psg.com; Tue, 14 Jan 2003 07:17:05 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18YSoH-000I7T-00 for v6ops@ops.ietf.org; Tue, 14 Jan 2003 07:17:02 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26588; Tue, 14 Jan 2003 10:13:39 -0500 (EST) Message-Id: <200301141513.KAA26588@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-ipv4survey-00.txt Date: Tue, 14 Jan 2003 10:13:39 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : Survey of IPv4 Addresses in Currently Deployed IETF Standards Author(s) : P. Nesser Filename : draft-ietf-v6ops-ipv4survey-00.txt Pages : 0 Date : 2003-1-13 This document seeks to document all usage of IPv4 addresses in currently deployed IETF documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-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-ipv4survey-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-ipv4survey-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-1-13142104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13142104.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jan 14 10:17: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 KAA26983 for ; Tue, 14 Jan 2003 10:17:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YSoQ-000I8Y-00 for v6ops-data@psg.com; Tue, 14 Jan 2003 07:17:10 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18YSoN-000I83-00 for v6ops@ops.ietf.org; Tue, 14 Jan 2003 07:17:07 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26613; Tue, 14 Jan 2003 10:13:45 -0500 (EST) Message-Id: <200301141513.KAA26613@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-cases-02.txt Date: Tue, 14 Jan 2003 10:13:45 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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 : Transition Scenarios for 3GPP Networks Author(s) : J. Soininen Filename : draft-ietf-v6ops-3gpp-cases-02.txt Pages : 10 Date : 2003-1-13 This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope of this document. The purpose of the document is to list the scenarios for further discussion and study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-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-3gpp-cases-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-3gpp-cases-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-1-13142114.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-cases-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13142114.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jan 14 16:37: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 QAA12530 for ; Tue, 14 Jan 2003 16:37:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YYlP-0006Up-00 for v6ops-data@psg.com; Tue, 14 Jan 2003 13:38:27 -0800 Received: from imo-r08.mx.aol.com ([152.163.225.104]) by psg.com with esmtp (Exim 3.36 #2) id 18YYlM-0006T2-00 for v6ops@ops.ietf.org; Tue, 14 Jan 2003 13:38:25 -0800 Received: from MicklesCK@aol.com by imo-r08.mx.aol.com (mail_out_v34.13.) id i.54.746ec3c (5709) for ; Tue, 14 Jan 2003 16:37:46 -0500 (EST) Received: from pcsn630877 (micklesck2-2p05.office.aol.com [10.0.31.6]) by air-id04.mx.aol.com (v89.12) with ESMTP id MAILINID42-0114163746; Tue, 14 Jan 2003 16:37:46 -0500 Reply-To: From: "MicklesCK" To: Subject: RE: I-D ACTION:draft-mickles-v6ops-isp-cases-03.txt Date: Tue, 14 Jan 2003 16:37:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.6 required=5.0 tests=SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02,USER_AGENT_OUTLOOK version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In case folks did not see the announcement, this is an updated version of the ISP draft and I wanted to make sure folks take a look. All the sections in the draft are complete at this time and comments to the list are appreciated. Thanks, Cleve... ============================================================================ ======== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transition Scenarios for ISP Networks Author(s) : C. Mickles Filename : draft-mickles-v6ops-isp-cases-03.txt Pages : 33 Date : 2003-1-10 This document describes the different types of Internet Service Provider (ISP) networks in existence today. It will provide design and operational considerations in delivering network services to customers for five specific areas in an effort to better identify specific issues which may arise during a transition to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-03.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-mickles-v6ops-isp-cases-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mickles-v6ops-isp-cases-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Wed Jan 15 03:24: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 DAA19812 for ; Wed, 15 Jan 2003 03:24:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YiqH-000GJm-00 for v6ops-data@psg.com; Wed, 15 Jan 2003 00:24:09 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18YiqE-000GJY-00 for v6ops@ops.ietf.org; Wed, 15 Jan 2003 00:24:06 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0F8N7012571 for ; Wed, 15 Jan 2003 10:23:07 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Jan 2003 10:24:03 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 15 Jan 2003 10:24:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: (Editorial) comments on draft-mickles-v6ops-isp-cases-03.txt Date: Wed, 15 Jan 2003 10:24:03 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC369A@esebe005.ntc.nokia.com> Thread-Topic: I-D ACTION:draft-mickles-v6ops-isp-cases-03.txt Thread-Index: AcK8FfWBJchnrz8+RPKdVL0sS/flYwAVDSAg From: To: Cc: X-OriginalArrivalTime: 15 Jan 2003 08:24:03.0851 (UTC) FILETIME=[76B12DB0:01C2BC6F] X-Spam-Status: No, hits=3.9 required=5.0 tests=NO_REAL_NAME,SEARCH_ENGINE_PROMO,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA19812 Hi, Cleve! I quickly browsed your draft through. Please find below some (more or less editorial) comments: - Footer: I think expiration month should be July - First page: It might be good to put (Editor) or (Ed.) after your name? - TOC: "Networks" is missing after 5. Broadband HFC/Coax - TOC, 6.3 and 6.4: with a capital. (those subtitles also written with a capital in the actual document) - Page 2, Copyright statement should be 2003? - 3.: existance - Section 4.: Why CORE, why not just Core or core? - 4.1, second last row in page 4: "...long haul circuits.." - A general comment valid for many sections: It would be good to have one empty row after each (sub)title (e.g. 4.2) and each (sub)section / paragraph - Many subtitles: Unnecessary dots, e.g. "4.3.1.....IGP" - Section 4 and also elsewhere: it would be useful to explain each abbreviation first time it is mentioned. E.g. IGP, EGP, PIM-SM, etc. in section 4. What does IBGP mean on the first row on page 5? - 4.6.2., third row: "ipv4" - 4.7. Should radius / tacacs be written with a capital? - 5.3.2., 11th row: "...a Layer-2" - 5.8, 5th row: esp -> especially, also some edits needed in 6th row: "transition functionality.. which? where?) - 6.: todays -> today's - 6.1.: Just commenting that also abbreviations ADSL, SDSL, etc. should be explained - References: Is there a special reason for splitting the references for separate sections? - It would be useful to divide the references to Informative and Normative. I will also do this for "3GPP analysis" next revision. :-) - The reference format is not the same for e.g. Wireless section and HFC Cable section. - Terms and acronyms, page 32. This kind of format could make this section more readable: aaa Explanation for aaa bbb Explanation for bbb ccc Explanation for ccc - Terms and acronyms: not all acronyms used in the document (there are so many of them) are explained here? Cheers, -Juha W.- -----Original Message----- From: ext MicklesCK [mailto:MicklesCK@aol.com] Sent: 14 January, 2003 23:38 To: v6ops@ops.ietf.org Subject: RE: I-D ACTION:draft-mickles-v6ops-isp-cases-03.txt In case folks did not see the announcement, this is an updated version of the ISP draft and I wanted to make sure folks take a look. All the sections in the draft are complete at this time and comments to the list are appreciated. Thanks, Cleve... ============================================================================ ======== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transition Scenarios for ISP Networks Author(s) : C. Mickles Filename : draft-mickles-v6ops-isp-cases-03.txt Pages : 33 Date : 2003-1-10 This document describes the different types of Internet Service Provider (ISP) networks in existence today. It will provide design and operational considerations in delivering network services to customers for five specific areas in an effort to better identify specific issues which may arise during a transition to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-03.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-mickles-v6ops-isp-cases-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mickles-v6ops-isp-cases-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Wed Jan 15 13:41:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06289 for ; Wed, 15 Jan 2003 13:41:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YsVE-000845-00 for v6ops-data@psg.com; Wed, 15 Jan 2003 10:43:04 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18YsVD-00083s-00 for v6ops@ops.ietf.org; Wed, 15 Jan 2003 10:43:03 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18YsVC-0000jR-00 for v6ops@ops.ietf.org; Wed, 15 Jan 2003 10:43:03 -0800 Message-Id: <5.2.0.9.0.20030115103527.02cbdd80@mail.addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 15 Jan 2003 10:37:10 -0800 To: v6ops@ops.ietf.org From: Bob Fink Subject: important dates for 56th IETF X-Spam-Status: No, hits=0.3 required=5.0 tests=RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ 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. ] 56th IETF - San Francisco, California, USA Important Meeting Dates January 7, Tuesday - Working Group and BOF scheduling begins January 13, Monday - Registration begins February 24, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 25, Tuesday - Working Group and BOF scheduling closes at 17:00 ET March 3, Monday - Internet Draft final submission cut-off at 09:00 ET March 7, Friday - Registration and Pre-payment cut-off at 12:00 noon ET March 12, Wednesday - Registration cancellation cut-off at 17:00 ET March 13, Thursday - Working Group agendas due date at 12:00 ET March 16-21 - 56th IETF Meeting in San Francisco, CA April 14, Monday - Proceedings submission cutoff date by 17:00 ET * All times are in US Eastern Time From owner-v6ops@ops.ietf.org Thu Jan 16 08:10: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 IAA09241 for ; Thu, 16 Jan 2003 08:10:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Z9n1-000F2C-00 for v6ops-data@psg.com; Thu, 16 Jan 2003 05:10:35 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18Z9mz-000F20-00 for v6ops@ops.ietf.org; Thu, 16 Jan 2003 05:10:33 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08948; Thu, 16 Jan 2003 08:07:08 -0500 (EST) Message-Id: <200301161307.IAA08948@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-00.txt Date: Thu, 16 Jan 2003 08:07:08 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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, R. van der Pol Filename : draft-ietf-v6ops-unman-scenarios-00.txt Pages : 16 Date : 2003-1-15 In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the 'unmanaged networks', which typically correspond to home networks or small office networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-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-ietf-v6ops-unman-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-ietf-v6ops-unman-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. --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-1-15125727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unman-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-15125727.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jan 16 20:51: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 UAA29173 for ; Thu, 16 Jan 2003 20:51:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZLgF-000BwJ-00 for v6ops-data@psg.com; Thu, 16 Jan 2003 17:52:23 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18ZLgC-000Bw6-00 for v6ops@ops.ietf.org; Thu, 16 Jan 2003 17:52:20 -0800 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14534 for ; Thu, 16 Jan 2003 18:52:19 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8U0050357614@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 16 Jan 2003 18:52:19 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H8U0091N575QH@mail.sun.net> for v6ops@ops.ietf.org; Thu, 16 Jan 2003 18:52:18 -0700 (MST) Date: Thu, 16 Jan 2003 17:53:12 -0800 From: Alain Durand Subject: comment on: draft-ietf-v6ops-unman-scenarios-00.txt In-reply-to: <200301161307.IAA08948@ietf.org> To: v6ops@ops.ietf.org Cc: Christian Huitema Message-id: <6FD36B5E-29BE-11D7-8691-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I have several comments on draft-ietf-v6ops-unman-scenarios-00.txt. Some minor ones and a major one, let me start by the later: Security. In IPv4+NAT, incoming connections are blocked unless someone configured port forwarding. It means that a highly insecure host in the unmanaged network has some degree of protection from the outside. Not perfect, but at least it raises the bar a little. For example, I can have an unconfigured network printer that is fully open, or not worry too much about an potential security hole in the file server. If IPv6 is turned on, in any of the described scenario A-D, all the sudden all port from all addresses become reachable from the outside. This is actually the benefit of IPv6, but it comes with a price: My unsecure hosts become more vulnerable, as they are now directly exposed, and in my example, anybody can print on my network printer. Security through obscurity helps a little here, as the IPv6 address of my printer will be hard to guess. However, in the peer-to-peer example described in the draft, the IPv6 address of the host gets published so your peers can reach you. But what if there are services running on the same hosts that are, let's say, not as robust as they should? Maybe the peer-to-peer application is 'safe' but the 'backdoor' in the file server has not been properly fixed... This problem has different repercussions depending on which scenario you're in: In scenario A, tunneling IPv6 over UDP to bypass the NAT/Firewall creates a security breach. I understand this is the unmanaged case, but if those techniques are applied in the enterprise (managed or unmanaged), this can have serious consequences. In scenario B, C & D, the CPE MUST implement an IPv6 firewall, and make this one easy to administer in this unmanaged scenario ;-) - Alain. From owner-v6ops@ops.ietf.org Fri Jan 17 12:10:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28952 for ; Fri, 17 Jan 2003 12:10:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Za24-0007yI-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 09:11:52 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18Za21-0007y3-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 09:11:49 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02374; Fri, 17 Jan 2003 10:11:47 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0HHBbP06123; Fri, 17 Jan 2003 18:11:37 +0100 (MET) Date: Thu, 16 Jan 2003 20:16:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 6to4 security questions To: Jason Goldschmidt Cc: Tim Chown , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3DDBFF8E.2010401@eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.6 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A long time ago Jason said: > At Sun we are using 6to4, as an early transition mechanism, for our > deployment. For the past few years we have had a few (read 3) > engineering sites connected by configured tunnels. We found deployment > scalability problems with this approach, so we decided to go with 6to4. What Jason forgot to mention was that this deployment (inside Sun's firewalls) uses exclusively 6to4 addresses. Thus there are no 6to4 relays. Erik From owner-v6ops@ops.ietf.org Fri Jan 17 12:10: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 MAA28967 for ; Fri, 17 Jan 2003 12:10:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Za1z-0007y1-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 09:11:47 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18Za1w-0007xm-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 09:11:44 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05634; Fri, 17 Jan 2003 10:11:32 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0HHBPP06102; Fri, 17 Jan 2003 18:11:25 +0100 (MET) Date: Thu, 16 Jan 2003 19:55:15 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Request to Publish ISATAP To: Fred Templin Cc: itojun@iijlab.net, Christian Huitema , Margaret Wasserman , v6ops@ops.ietf.org, Bob Fink , Randy Bush In-Reply-To: "Your message with ID" <20021224135119.34800.qmail@web13005.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.6 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Some additional information to take into account... > > in 5.1, the document proposes a different handling of link-layer > > address option in ND from the normal ND. > > This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph > on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the > normative text that allows what ISATAP is doing is plain for all to see. Correct. > > also in 5.2, the document > > proposes special handling of router discovery. ND and router discovery > > have to be link-layer independent, and if we wish to make any changes > > to ND/autoconf, we must update RFC2461/2462, in link-layer independent > > manner. > > Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1, > we have the following text: > > However, because ND uses link-layer multicast for some of its > services, it is possible that on some link types (e.g., NBMA links) > alternative protocols or mechanisms to implement those services will > be specified (in the appropriate document covering the operation of > IP over a particular link type). > > Clearly, no updates to RFC2461 are necessary since ISATAP is exactly > such "the appropriate document..." as described above. After RFC 2461 was written RFC 2491 "IPv6 over Non-Broadcast Multiple Access (NBMA) networks". It makes sense for schemes that do IPv6 over NBMA to use that as the basis and not provide additional and different changes to how ND works. Erik From owner-v6ops@ops.ietf.org Fri Jan 17 12:10: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 MAA28989 for ; Fri, 17 Jan 2003 12:10:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Za2Z-0007yx-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 09:12:23 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 18Za2W-0007yE-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 09:12:21 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24282; Fri, 17 Jan 2003 09:11:48 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0HHBhP06142; Fri, 17 Jan 2003 18:11:44 +0100 (MET) Date: Thu, 16 Jan 2003 20:32:28 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: An alternative to 6to4 and teredo To: Joshua Graessley Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=DATE_IN_PAST_12_24,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A long time ago Joshua wrote: > This is a chicken and egg problem. That is why transition tools are > important. Apple could develop and ship a system that implemented 6to4 > and shipworm/teredo to fall back on when IPv6 wasn't immediately > available. Apple could also ship an application that made use of IPv6. > Microsoft is in a similar position. Once that's done, third party > developers can take advantage of that, assuming all of the transition > mechanisms work. Shooting down 6to4 eliminates one transition > mechanism. Not even acknowledging Teredo is another shot at transition. I argue that using tunnel broker and extending it to support UDP tunneling across NATs is much better than 6to4 and Teredo when considering the space of temporary solutions until the ISPs provide native IPv6. I think tunnel brokered tunnels provide better incentives for deployment than 6to4 relays because they are visible to the user - the provider can throw in some content and adds as part of the web page you visit, and the can claim "we have x,000 users". A 6to4 relay provider can not do this. The "connect to IPv6" icon on the desktop also helps drive IPv6 awareness - folks will see that enabling that allows them to run their IPv6 peer to peer games even across an IPv4 NAT box, thus they are more likely to ask their ISP for native IPv6 than if this is completely automatic as is envisioned for Teredo. The only downside of the tunnel broker schemes is potentially less efficient routing. But if the services are popular this might be a self-correcting problem. And if they are not popular it is either because there is sufficient native IPv6 access or that IPv6 is not being widely used. The upsides for tunnel broker (with UDP tunneling across NATs, or even PPP over TCP over NATs for those so inclined) in addition to the incentives above is that it avoids the security issues around 6to4 and Teredo, and is operationally much much simpler to trouble-shoot. And there isn't any risk of creating separate IPv6 native and 6to4 universes since it is all IPv6 native addresses with regular IPv6 routing. Erik From owner-v6ops@ops.ietf.org Fri Jan 17 12:24:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29243 for ; Fri, 17 Jan 2003 12:24:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZaGm-0008JB-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 09:27:04 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18ZaGi-0008Iv-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 09:27:01 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0HHQlS20454; Fri, 17 Jan 2003 19:26:47 +0200 Date: Fri, 17 Jan 2003 19:26:47 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Joshua Graessley , Subject: Re: An alternative to 6to4 and teredo In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 16 Jan 2003, Erik Nordmark wrote: > > This is a chicken and egg problem. That is why transition tools are > > important. Apple could develop and ship a system that implemented 6to4 > > and shipworm/teredo to fall back on when IPv6 wasn't immediately > > available. Apple could also ship an application that made use of IPv6. > > Microsoft is in a similar position. Once that's done, third party > > developers can take advantage of that, assuming all of the transition > > mechanisms work. Shooting down 6to4 eliminates one transition > > mechanism. Not even acknowledging Teredo is another shot at transition. > > I argue that using tunnel broker and extending it to support UDP tunneling > across NATs is much better than 6to4 and Teredo when considering the space > of temporary solutions until the ISPs provide native IPv6. I agree, to some extent. Definitely so for Teredo (complexity). > I think tunnel brokered tunnels provide better incentives for deployment > than 6to4 relays because they are visible to the user - the provider > can throw in some content and adds as part of the web page you visit, > and the can claim "we have x,000 users". A 6to4 relay provider can not > do this. The "connect to IPv6" icon on the desktop also helps drive > IPv6 awareness - folks will see that enabling that allows them to run > their IPv6 peer to peer games even across an IPv4 NAT box, thus they > are more likely to ask their ISP for native IPv6 than if this is > completely automatic as is envisioned for Teredo. > > The only downside of the tunnel broker schemes is potentially less efficient > routing. But if the services are popular this might be a self-correcting > problem. And if they are not popular it is either because there is sufficient > native IPv6 access or that IPv6 is not being widely used. That's not all. 6to4/Teredo offer an automatic configuration using anycast addresses. Much easier than trying to figure out the closest tunnel broker, configuring to use that etc. > The upsides for tunnel broker (with UDP tunneling across NATs, or even PPP > over TCP over NATs for those so inclined) in addition to the incentives above > is that it avoids the security issues around 6to4 and Teredo, and is > operationally much much simpler to trouble-shoot. I agree, but there is a cost to a tunnel broker model, that is, not so simple configuration.. -- 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 Jan 17 14:45:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02789 for ; Fri, 17 Jan 2003 14:45:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZcRu-000Bf4-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 11:46:42 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #2) id 18ZcRr-000BeQ-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 11:46:39 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0HJk1Fn059766; Fri, 17 Jan 2003 20:46:02 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0HJjxRW196226; Fri, 17 Jan 2003 20:45:59 +0100 Received: from lig32-229-36-80.us.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21538 from ; Fri, 17 Jan 2003 20:45:44 +0100 Message-Id: <3E285D34.A6067A4A@hursley.ibm.com> Date: Fri, 17 Jan 2003 20:44:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Erik Nordmark Cc: Joshua Graessley , v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've never argued against tunnel brokers for isolated hosts. Please remember that 6to4 was actually designed for whole sites with no IPv6 ISP, not for isolated hosts. The fact that a well-known operating system ships 6to4 for isolated hosts doesn't change the original design point. Brian Erik Nordmark wrote: > > A long time ago Joshua wrote: > > > This is a chicken and egg problem. That is why transition tools are > > important. Apple could develop and ship a system that implemented 6to4 > > and shipworm/teredo to fall back on when IPv6 wasn't immediately > > available. Apple could also ship an application that made use of IPv6. > > Microsoft is in a similar position. Once that's done, third party > > developers can take advantage of that, assuming all of the transition > > mechanisms work. Shooting down 6to4 eliminates one transition > > mechanism. Not even acknowledging Teredo is another shot at transition. > > I argue that using tunnel broker and extending it to support UDP tunneling > across NATs is much better than 6to4 and Teredo when considering the space > of temporary solutions until the ISPs provide native IPv6. > > I think tunnel brokered tunnels provide better incentives for deployment > than 6to4 relays because they are visible to the user - the provider > can throw in some content and adds as part of the web page you visit, > and the can claim "we have x,000 users". A 6to4 relay provider can not > do this. The "connect to IPv6" icon on the desktop also helps drive > IPv6 awareness - folks will see that enabling that allows them to run > their IPv6 peer to peer games even across an IPv4 NAT box, thus they > are more likely to ask their ISP for native IPv6 than if this is > completely automatic as is envisioned for Teredo. > > The only downside of the tunnel broker schemes is potentially less efficient > routing. But if the services are popular this might be a self-correcting > problem. And if they are not popular it is either because there is sufficient > native IPv6 access or that IPv6 is not being widely used. > > The upsides for tunnel broker (with UDP tunneling across NATs, or even PPP > over TCP over NATs for those so inclined) in addition to the incentives above > is that it avoids the security issues around 6to4 and Teredo, and is > operationally much much simpler to trouble-shoot. > And there isn't any risk of creating separate IPv6 native and 6to4 > universes since it is all IPv6 native addresses with regular IPv6 routing. > > Erik From owner-v6ops@ops.ietf.org Fri Jan 17 15:01:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03213 for ; Fri, 17 Jan 2003 15:01:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zcj2-000CKi-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 12:04:24 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18Zciy-000CKL-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 12:04:20 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5411D87AF; Fri, 17 Jan 2003 21:04:15 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 9172278C8; Fri, 17 Jan 2003 21:04:09 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Erik Nordmark'" Cc: "'Joshua Graessley'" , Subject: RE: An alternative to 6to4 and teredo Date: Fri, 17 Jan 2003 21:04:08 +0100 Organization: Unfix Message-ID: <003b01c2be63$98eddb80$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA03213 Pekka Savola wrote: > On Thu, 16 Jan 2003, Erik Nordmark wrote: > That's not all. 6to4/Teredo offer an automatic configuration using > anycast addresses. Much easier than trying to figure out the closest > tunnel broker, configuring to use that etc. > > > The upsides for tunnel broker (with UDP tunneling across > NATs, or even PPP > > over TCP over NATs for those so inclined) in addition to > the incentives above > > is that it avoids the security issues around 6to4 and Teredo, and is > > operationally much much simpler to trouble-shoot. > > I agree, but there is a cost to a tunnel broker model, that > is, not so simple configuration.. There is at least Tunnel Setup Protocol (TSP*) which does automatic configuration and it'salso quite extendable. On debian for instance it's "apt-get install freenet6" and you are going. The only 'problem' is that the Freenet6 broker system is located in the US thus european hosts have some (80ms+) additional latency. A "POP" per ISP would be better which is something we are pursuing for SixXS. The TSP protocol can handle this fortunatly. A POP per ISP would at least mean that clients can get near-native IPv6. TSP: http://www.freenet6.net/draft-tsp.shtml It is marked "Expires: November 30, 2001" though, what happened that it didn't get pushed through? Good example is xs4all who first had a IPng.nl based tunnelbroker and modified it for their needs with which they are now providing IPv6 to their clients who can't get it natively. The IPv6-in-IPv4 thus only is carried in their network untill their tunnelbox, for xdsl clients this is thus max 3 hops and a latency of about only <~3ms added when they would have native connectivity. See the "Deployment at XS4all" presentation to be found at: http://www.ams-ix.net/aiad/presentations.html for more info. My point is that ISP's should be pushed to have something like that or that at least they should deploy a 'close' relay, may this be 6to4 or a tunnelbased system. As long as their clients can connect as 'locally' as possible. I've partially developped an alternative to this scheme with some big differences to what Freenet6 does with their TSP protocol. Some other things are in line first though. But it will be a system I want to have deployed at least before march for the SixXS system which we fortunatly abstracted with an API so that things like these can be implemented quite easily. Small example is port 42006 on our noc.sixxs.net box which basically replaces the website and can be easily accessed by any program capable of sending data over a tcp/ip socket. As I also probably wrote before, people do also sign up for things like MSN and hotmail etc, so an IPv6 tunnel via a webinterface shouldn't be that hard either. The only thing is making them think that having it is useful! (Which is one part I have on the 'other things to do first' :) Greets, Jeroen From owner-v6ops@ops.ietf.org Fri Jan 17 17:33: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 RAA06442 for ; Fri, 17 Jan 2003 17:33:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zf4B-000G4T-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 14:34:23 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Zf47-000G4F-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 14:34:19 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0HMY8N22131; Sat, 18 Jan 2003 00:34:08 +0200 Date: Sat, 18 Jan 2003 00:34:07 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'Erik Nordmark'" , "'Joshua Graessley'" , Subject: RE: An alternative to 6to4 and teredo In-Reply-To: <003b01c2be63$98eddb80$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 17 Jan 2003, Jeroen Massar wrote: > There is at least Tunnel Setup Protocol (TSP*) which does automatic > configuration and it'salso quite extendable. On debian for instance > it's "apt-get install freenet6" and you are going. The only 'problem' > is that the Freenet6 broker system is located in the US thus european > hosts have some (80ms+) additional latency. A "POP" per ISP would be > better which is something we are pursuing for SixXS. The TSP protocol > can handle this fortunatly. A POP per ISP would at least mean that > clients can get near-native IPv6. > > TSP: http://www.freenet6.net/draft-tsp.shtml > It is marked "Expires: November 30, 2001" though, what happened > that it didn't get pushed through? Folks probably lost hope. > Good example is xs4all who first had a IPng.nl based tunnelbroker > and modified it for their needs with which they are now providing > IPv6 to their clients who can't get it natively. The IPv6-in-IPv4 > thus only is carried in their network untill their tunnelbox, > for xdsl clients this is thus max 3 hops and a latency of about > only <~3ms added when they would have native connectivity. > See the "Deployment at XS4all" presentation to be found at: > http://www.ams-ix.net/aiad/presentations.html for more info. > [...] > I've partially developped an alternative to this scheme with some > big differences to what Freenet6 does with their TSP protocol. > Some other things are in line first though. But it will be a > system I want to have deployed at least before march for the > SixXS system which we fortunatly abstracted with an API so that > things like these can be implemented quite easily. > Small example is port 42006 on our noc.sixxs.net box which > basically replaces the website and can be easily accessed by > any program capable of sending data over a tcp/ip socket. Above you show one of the main points here: there are dozens of tunnelbrokers, and each have their own interface (pretty much). It's just too much work that way. (btw, I think tunnel brokering would get off a bit if a client+server code using some agreed protocol would happen to be publicized under a liberal license like BSD.) > As I also probably wrote before, people do also sign up for > things like MSN and hotmail etc, so an IPv6 tunnel via a > webinterface shouldn't be that hard either. > The only thing is making them think that having it is useful! > (Which is one part I have on the 'other things to do first' :) Hotmail etc. have been around for ages. Tunnel brokers come and go. The configuration may require some installation in your computer. Sure, many folks still do it, but there's a big difference. But of course, some kind of "tunnel broker discovery" or catalogues could be coined up too... [moved this from above] > My point is that ISP's should be pushed to have something like > that or that at least they should deploy a 'close' relay, may > this be 6to4 or a tunnelbased system. As long as their clients > can connect as 'locally' as possible. This is not all. We provide 6to4 relay service to everybody in the world. There is no way we would offer any tunnel brokering (_using our addresses_) outside our customers. 6to4 is much more provider-neutral on this aspect, which could also be considered as a good thing! -- 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 Jan 17 19:02:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07902 for ; Fri, 17 Jan 2003 19:02:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZgTd-000ISJ-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 16:04:45 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18ZgTZ-000IS7-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 16:04:41 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C9E894B22; Sat, 18 Jan 2003 09:04:38 +0900 (JST) To: Erik Nordmark Cc: Jason Goldschmidt , Tim Chown , v6ops@ops.ietf.org In-reply-to: Erik.Nordmark's message of Thu, 16 Jan 2003 20:16:52 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: 6to4 security questions From: itojun@iijlab.net Date: Sat, 18 Jan 2003 09:04:38 +0900 Message-Id: <20030118000438.C9E894B22@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >A long time ago Jason said: > >> At Sun we are using 6to4, as an early transition mechanism, for our >> deployment. For the past few years we have had a few (read 3) >> engineering sites connected by configured tunnels. We found deployment >> scalability problems with this approach, so we decided to go with 6to4. > >What Jason forgot to mention was that this deployment (inside Sun's firewalls) >uses exclusively 6to4 addresses. you mean that there's no external connectivity to the 6bone? if sun's firewall is acting as a 6to4 border router, the box is subject to various attacks (as it will accept 6to4-encapsulated packet from anybody). >Thus there are no 6to4 relays. having 6to4 relay router is totally different question from running a 6to4 site. itojun From owner-v6ops@ops.ietf.org Fri Jan 17 21:04: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 VAA08982 for ; Fri, 17 Jan 2003 21:04:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZiMN-000M08-00 for v6ops-data@psg.com; Fri, 17 Jan 2003 18:05:23 -0800 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by psg.com with esmtp (Exim 3.36 #2) id 18ZiMH-000Lzl-00 for v6ops@ops.ietf.org; Fri, 17 Jan 2003 18:05:17 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZiMC-0001uh-00; Fri, 17 Jan 2003 18:05:12 -0800 Date: Fri, 17 Jan 2003 21:01:47 -0500 From: Keith Moore To: Brian E Carpenter Cc: moore@cs.utk.edu, Erik.Nordmark@sun.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-Id: <20030117210147.7cfc01d5.moore@cs.utk.edu> In-Reply-To: <3E285D34.A6067A4A@hursley.ibm.com> References: <3E285D34.A6067A4A@hursley.ibm.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 17 Jan 2003 20:44:52 +0100 Brian E Carpenter wrote: > I've never argued against tunnel brokers for isolated hosts. Please > remember that 6to4 was actually designed for whole sites with no > IPv6 ISP, not for isolated hosts. The fact that a well-known operating > system ships 6to4 for isolated hosts doesn't change the original design > point. for that matter, 6to4 works great for isolated hosts that need to talk to other hosts running 6to4. tunnel broker is *much* less efficient. OTOH, I think tunnel broker is a good way to provide default route for a 6to4 site. Keith From owner-v6ops@ops.ietf.org Sat Jan 18 07:41: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 HAA26254 for ; Sat, 18 Jan 2003 07:41:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZsJU-000Fou-00 for v6ops-data@psg.com; Sat, 18 Jan 2003 04:43:04 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18ZsJR-000Foi-00 for v6ops@ops.ietf.org; Sat, 18 Jan 2003 04:43:01 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 9FCCE882E; Sat, 18 Jan 2003 13:42:56 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 532EA7B84; Sat, 18 Jan 2003 13:42:50 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" Cc: "'Erik Nordmark'" , "'Joshua Graessley'" , , Subject: RE: An alternative to 6to4 and teredo Date: Sat, 18 Jan 2003 13:42:41 +0100 Organization: Unfix Message-ID: <001901c2beef$181389b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA26254 Pekka Savola [mailto:pekkas@netcore.fi] wrote: > On Fri, 17 Jan 2003, Jeroen Massar wrote: > > There is at least Tunnel Setup Protocol (TSP*) which does automatic > > configuration and it'salso quite extendable. On debian for instance > > it's "apt-get install freenet6" and you are going. The only > 'problem' > > is that the Freenet6 broker system is located in the US > thus european > > hosts have some (80ms+) additional latency. A "POP" per ISP would be > > better which is something we are pursuing for SixXS. The > TSP protocol > > can handle this fortunatly. A POP per ISP would at least mean that > > clients can get near-native IPv6. > > > > TSP: http://www.freenet6.net/draft-tsp.shtml > > It is marked "Expires: November 30, 2001" though, what happened > > that it didn't get pushed through? > > Folks probably lost hope. I rather think it never got completely finished seeing that Appendix A mentions "A DTD should be placed here for the protocol." etc... I added Marc to the CC list he can probably best comment on what happened and/or what is going on. > > As I also probably wrote before, people do also sign up for > > things like MSN and hotmail etc, so an IPv6 tunnel via a > > webinterface shouldn't be that hard either. > > The only thing is making them think that having it is useful! > > (Which is one part I have on the 'other things to do first' :) > > Hotmail etc. have been around for ages. Tunnel brokers come > and go. The configuration may require some installation in your computer. > Sure, many folks still do it, but there's a big difference. > > But of course, some kind of "tunnel broker discovery" or > catalogues could be coined up too... I had quite a big list of tunnelbrokers in the dmoz.org directory but apparently some of the big mofo's there found that the IPv6 index wasn't good enough and changed it around. Fortunatly google mirrors it to their directory.google.com* and thus it still exists, it isn't on dmoz any more so it's unmaintained unfortunatly. * = http://directory.google.com/Top/Computers/Internet/Protocols/IP/IPng/IPv 6_Access_Providers/?il=1 Checking the top 10 I see some very stable TB's. And I think that the google ranking also is quite a good indication of the use of the TB's. HE + Freenet6 are quite large, though I never heared of any numbers from them. For SixXS/IPng (IPng is using the SixXS code) the listing is at http://www.sixxs.net/misc/statistics/ , this is Pim and my project so I won't go bragging around with it I do have to say that all the tunnels noted there (500+) are actively used. We then also got quite a strict policy for who gets a tunnel and who gets to keep it for at least the public POP's. Each one of them can have their own policies as they are mostly ISP bound and thus those users are (paying) customers of that ISP if they do something that ISP will deal with it. Having a central server serve a list of available tunnelbrokers is actually the idea I am taking up for the SixXS project and mind you is also the thing that Freenet6 is doing already succesfully for quite some time now. > [moved this from above] > > My point is that ISP's should be pushed to have something like > > that or that at least they should deploy a 'close' relay, may > > this be 6to4 or a tunnelbased system. As long as their clients > > can connect as 'locally' as possible. > > This is not all. > > We provide 6to4 relay service to everybody in the world. > There is no way we would offer any tunnel brokering (_using our addresses_) > outside our customers. 6to4 is much more provider-neutral on this > aspect, which could also be considered as a good thing! Ah indeed the neutral political problem. This is indeed something to look at unfortunatly. In SixXS we solved this with the fact that a POP has a list of policies and based upon those a user can choose that POP or not or force him to use only that POP. Eg. the HeaNet POP simply only allows tunnels to prefixes which are directly peered with HeaNet, thus most of Ireland. I know also that many ISP's let non-customers use 6bone space and keep the RIR space for their paying customers. In their respect RIR space is 'better' IPv6 space then 6bone space and they can justify this to their paying clients as "they are testing if it's going to work for you". As said we hope to finish up the automatic configuration programs asap. The programs, code and protocol will become public at release. The reason why we are not using TSP is because it misses quite a couple of things which we require for the operation of our style of system. For example automatic dynamic tunnels are not supported easily without traffic being sent to an unsuspecting dailup user with ZoneAlarm running You really don't want to know what kind of odd abuse messages alongside of the threats you get then ;) Greets, Jeroen From owner-v6ops@ops.ietf.org Sat Jan 18 11:02: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 LAA28216 for ; Sat, 18 Jan 2003 11:02:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZvSg-000Ky9-00 for v6ops-data@psg.com; Sat, 18 Jan 2003 08:04:46 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #2) id 18ZvSd-000KwO-00 for v6ops@ops.ietf.org; Sat, 18 Jan 2003 08:04:43 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0IG45vU014786; Sat, 18 Jan 2003 17:04:05 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0IG42Ba063830; Sat, 18 Jan 2003 17:04:02 +0100 Received: from lig32-229-52-159.us.lig-dial.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19684 from ; Sat, 18 Jan 2003 17:03:58 +0100 Message-Id: <3E296F2B.8D02B33B@hursley.ibm.com> Date: Sat, 18 Jan 2003 16:13:47 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Alain Durand Cc: v6ops@ops.ietf.org, Christian Huitema Subject: Re: comment on: draft-ietf-v6ops-unman-scenarios-00.txt References: <6FD36B5E-29BE-11D7-8691-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is there any reason why we can't recommend strongly that the router for an unman network should incorporate a firewall with most ports closed by default, and opened manually on demand, as with most personal firewall products? There are some user interface design issues for such a solution, but personal firewalls are a proof of concept. Brian Alain Durand wrote: > > I have several comments on draft-ietf-v6ops-unman-scenarios-00.txt. > Some minor ones and a major one, let me start by the later: > > Security. > > In IPv4+NAT, incoming connections are blocked unless > someone configured port forwarding. It means that a highly insecure > host in the unmanaged network has some degree of protection from the > outside. > Not perfect, but at least it raises the bar a little. For example, I > can have > an unconfigured network printer that is fully open, or not worry > too much about an potential security hole in the file server. > > If IPv6 is turned on, in any of the described scenario A-D, all the > sudden > all port from all addresses become reachable from the outside. > This is actually the benefit of IPv6, but it comes with a price: > My unsecure hosts become more vulnerable, as they are now directly > exposed, > and in my example, anybody can print on my network printer. > Security through obscurity helps a little here, as the IPv6 address of > my > printer will be hard to guess. However, in the peer-to-peer example > described in the draft, the IPv6 address of the host gets published > so your peers can reach you. But what if there are services running > on the same hosts that are, let's say, not as robust as they should? > Maybe the peer-to-peer application is 'safe' but the 'backdoor' in the > file server has not been properly fixed... > > This problem has different repercussions depending on which scenario > you're in: > > In scenario A, tunneling IPv6 over UDP to bypass the NAT/Firewall > creates a security breach. I understand this is the unmanaged case, > but if those techniques are applied in the enterprise (managed or > unmanaged), > this can have serious consequences. > > In scenario B, C & D, the CPE MUST implement an IPv6 firewall, > and make this one easy to administer in this unmanaged scenario ;-) > > - Alain. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Sat Jan 18 11:16: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 LAA28337 for ; Sat, 18 Jan 2003 11:16:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zvh2-000LQ8-00 for v6ops-data@psg.com; Sat, 18 Jan 2003 08:19:36 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18Zvgz-000LPk-00 for v6ops@ops.ietf.org; Sat, 18 Jan 2003 08:19:33 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0IGJPU26980; Sat, 18 Jan 2003 18:19:25 +0200 Date: Sat, 18 Jan 2003 18:19:25 +0200 (EET) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org, Christian Huitema Subject: Re: comment on: draft-ietf-v6ops-unman-scenarios-00.txt In-Reply-To: <6FD36B5E-29BE-11D7-8691-00039376A6AA@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 16 Jan 2003, Alain Durand wrote: > In IPv4+NAT, incoming connections are blocked unless someone configured > port forwarding. It means that a highly insecure host in the unmanaged > network has some degree of protection from the outside. Not perfect, but > at least it raises the bar a little. For example, I can have an > unconfigured network printer that is fully open, or not worry too much > about an potential security hole in the file server. > > If IPv6 is turned on, in any of the described scenario A-D, all the > sudden all port from all addresses become reachable from the outside. [...] I haven't read the latest draft yet, but there is a distict solution for this. That is, *intentionally* do not provide any IPv6-Internet <-> IPv4-Unmanaged translation. The security benefits or lack thereof are the same. Only provide IPv6<->IPv4 translation _internally_ (if really required). Then, make a requirement that devices which implement IPv6 and enable it by default [in unmanaged networks scope at least] must have some security mechanisms in place, like "personal firewalls". Of course, we could try to strenghten the protections at the IPv6 router, but that's probably a fight we could never win, only lose. The best would of course be educating the folks about security of lack thereof provided by NAT and global addressing. (Joe M. Arketeer could of course push IPv6 site-local addresses to solve this particular problem, needless to say what I think of that..) -- 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 Sat Jan 18 13:41:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29631 for ; Sat, 18 Jan 2003 13:41:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zxw6-0000BE-00 for v6ops-data@psg.com; Sat, 18 Jan 2003 10:43:18 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50] helo=smtp.cs.utk.edu) by psg.com with esmtp (Exim 3.36 #2) id 18Zxw4-0000B2-00 for v6ops@ops.ietf.org; Sat, 18 Jan 2003 10:43:16 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 2187714086; Sat, 18 Jan 2003 13:43:15 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 16912-01; Sat, 18 Jan 2003 13:43:14 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 80AE514085; Sat, 18 Jan 2003 13:43:14 -0500 (EST) Date: Sat, 18 Jan 2003 13:43:14 -0500 From: Keith Moore To: Brian E Carpenter Cc: moore@cs.utk.edu, Alain.Durand@Sun.COM, v6ops@ops.ietf.org, huitema@windows.microsoft.com Subject: Re: comment on: draft-ietf-v6ops-unman-scenarios-00.txt Message-Id: <20030118134314.366001f8.moore@cs.utk.edu> In-Reply-To: <3E296F2B.8D02B33B@hursley.ibm.com> References: <6FD36B5E-29BE-11D7-8691-00039376A6AA@sun.com> <3E296F2B.8D02B33B@hursley.ibm.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: eec6400b17e2847232f3b083ac7c7f456b722eac X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 18 Jan 2003 16:13:47 +0100 Brian E Carpenter wrote: > Is there any reason why we can't recommend strongly that the router > for an unman network should incorporate a firewall with most ports > closed by default, and opened manually on demand, as with most > personal firewall products? this is similar to what I've been thinking. -- I tried enlightenment but it kept crashing. From owner-v6ops@ops.ietf.org Sun Jan 19 10:41:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21415 for ; Sun, 19 Jan 2003 10:41:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aHYa-0003ar-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 07:40:20 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18aHYU-0003ae-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 07:40:15 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h0JFe8h11148; Sun, 19 Jan 2003 16:40:08 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h0JFdnof095814; Sun, 19 Jan 2003 16:39:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200301191539.h0JFdnof095814@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Joshua Graessley , v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo In-reply-to: Your message of Thu, 16 Jan 2003 20:32:28 +0100. Date: Sun, 19 Jan 2003 16:39:49 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: I argue that using tunnel broker and extending it to support UDP tunneling across NATs is much better than 6to4 and Teredo when considering the space of temporary solutions until the ISPs provide native IPv6. => congratulations on a such courageous public opinion... BTW teredo comes from an old discussion about what to standardize for UDP tunneling across NATs (tunnel server ports for instance). And there isn't any risk of creating separate IPv6 native and 6to4 universes since it is all IPv6 native addresses with regular IPv6 routing. => this is my main concern about 6to4. Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sun Jan 19 10:41: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 KAA21433 for ; Sun, 19 Jan 2003 10:41:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aHcQ-0003lk-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 07:44:18 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18aHcO-0003lY-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 07:44:16 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h0JFiCh11179; Sun, 19 Jan 2003 16:44:12 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h0JFhrof095828; Sun, 19 Jan 2003 16:43:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200301191543.h0JFhrof095828@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Jeroen Massar , "'Erik Nordmark'" , "'Joshua Graessley'" , v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo In-reply-to: Your message of Sat, 18 Jan 2003 00:34:07 +0200. Date: Sun, 19 Jan 2003 16:43:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: We provide 6to4 relay service to everybody in the world. There is no way we would offer any tunnel brokering (_using our addresses_) outside our customers. 6to4 is much more provider-neutral on this aspect, which could also be considered as a good thing! => many ISPs are very reluctant to run a 6to4 relay so I am not convinced of the provider-neutral aspect of 6to4... I have no objection to be a TB-provider customer BTW. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sun Jan 19 10:45: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 KAA21482 for ; Sun, 19 Jan 2003 10:45:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aHg1-0003xn-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 07:48:01 -0800 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by psg.com with esmtp (Exim 3.36 #2) id 18aHfy-0003xa-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 07:47:58 -0800 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id h0JFlmh11216; Sun, 19 Jan 2003 16:47:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h0JFlSof095858; Sun, 19 Jan 2003 16:47:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200301191547.h0JFlSof095858@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Erik Nordmark , Jason Goldschmidt , Tim Chown , v6ops@ops.ietf.org Subject: Re: 6to4 security questions In-reply-to: Your message of Sat, 18 Jan 2003 09:04:38 +0900. <20030118000438.C9E894B22@coconut.itojun.org> Date: Sun, 19 Jan 2003 16:47:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: >A long time ago Jason said: > >> At Sun we are using 6to4, as an early transition mechanism, for our >> deployment. For the past few years we have had a few (read 3) >> engineering sites connected by configured tunnels. We found deployment >> scalability problems with this approach, so we decided to go with 6to4. > >What Jason forgot to mention was that this deployment (inside Sun's firewalls) >uses exclusively 6to4 addresses. you mean that there's no external connectivity to the 6bone? => yes, this is what Jason and other Sun people described at the last IETF. This is a good usage case for 6to4, with no external security issue at all. if sun's firewall is acting as a 6to4 border router, the box is subject to various attacks (as it will accept 6to4-encapsulated packet from anybody). >Thus there are no 6to4 relays. having 6to4 relay router is totally different question from running a 6to4 site. => and this is a cause of security and non technical burdens... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sun Jan 19 12:56: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 MAA23071 for ; Sun, 19 Jan 2003 12:56:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aJiM-000AZp-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 09:58:34 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18aJi1-000AWl-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 09:58:13 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12718; Sun, 19 Jan 2003 09:57:40 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0JHvZP24524; Sun, 19 Jan 2003 18:57:35 +0100 (MET) Date: Sun, 19 Jan 2003 18:54:06 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: An alternative to 6to4 and teredo To: Pekka Savola Cc: Erik Nordmark , Joshua Graessley , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > That's not all. 6to4/Teredo offer an automatic configuration using > anycast addresses. Much easier than trying to figure out the closest > tunnel broker, configuring to use that etc. If somebody wants to provide a good tunnel broker service they can automate this without any changes in the clients. Just have multiple tunnel servers at different places in the topology and have the tunnel broker meaure or estimate the location of the client before handing it off to a tunnel server. Thus if example.net wants to capture IPv6 "customers" that they don't have as IPv4 customers they could do this relatively easily. > I agree, but there is a cost to a tunnel broker model, that is, not so > simple configuration.. Yes, but see above. A single icon on the desktop might be sufficient. And it has the advantage of lower operational complexity resulting in a higher probability that it actually works. And should it not work the icon allows you turn turn it off. Erik From owner-v6ops@ops.ietf.org Sun Jan 19 13:17: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 NAA23330 for ; Sun, 19 Jan 2003 13:17:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aK3R-000Bmq-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 10:20:21 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18aK35-000Bm7-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 10:19:59 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0JIJkO09331; Sun, 19 Jan 2003 20:19:46 +0200 Date: Sun, 19 Jan 2003 20:19:46 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Joshua Graessley , Subject: Re: An alternative to 6to4 and teredo In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 19 Jan 2003, Erik Nordmark wrote: > > That's not all. 6to4/Teredo offer an automatic configuration using > > anycast addresses. Much easier than trying to figure out the closest > > tunnel broker, configuring to use that etc. > > If somebody wants to provide a good tunnel broker service they can > automate this without any changes in the clients. .. assuming that the protocol TB uses is specified and implemented widely enough. Being able to ship it by default in OS's helps. > Just have multiple tunnel > servers at different places in the topology and have the tunnel broker > meaure or estimate the location of the client before handing it > off to a tunnel server. .. possibly even requiring specification or at least publication of this measument mechanism. Note: I believe you also need a way to get the list of "tunnel brokers close to me" -- manually adding them doesn't seem like an option. > Thus if example.net wants to capture IPv6 "customers" that they don't > have as IPv4 customers they could do this relatively easily. Assuming above. > > I agree, but there is a cost to a tunnel broker model, that is, not so > > simple configuration.. > > Yes, but see above. A single icon on the desktop might be sufficient. > And it has the advantage of lower operational complexity resulting in > a higher probability that it actually works. And should it not work the icon > allows you turn turn it off. Well.. I don't think you can get it much easier than 'echo IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0' or the like; that's all you need to enable 6to4 using the anycast address on certain operating systems. No software needed, no nothing: IPv6 in 5 seconds. Of course "actually works" is relative. Perhaps, to focus, we should ask ourselves: do we want to provide a mechanism that provides easy use for the case where: 1) Joe User wants to use his closest Tunnel Broker that allows him to use the service (not knowing where this closest TB even is!), or 2) Joe User digs out the tunnel broker address/hostname of his ISP or someone close by and starts to use the service From my observation point, 6to4 is ultimately superior at 1), at least in locations where you have some deployment of 6to4 relays (here in Finland, there are at least two advertising 192.88.99.0/24 and 2002::/16). Note that to be practical, 1) seems to require that there is some mechanism of autodiscovering tunnel broker services. Surfing the web is a no-go. -- 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 Sun Jan 19 13:24: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 NAA23455 for ; Sun, 19 Jan 2003 13:24:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aKAM-000CAW-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 10:27:30 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18aKA0-000C7H-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 10:27:08 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 9E0078AE9; Sun, 19 Jan 2003 19:27:00 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E49807EEC; Sun, 19 Jan 2003 19:26:54 +0100 (CET) From: "Jeroen Massar" To: "'Erik Nordmark'" , "'Pekka Savola'" Cc: "'Joshua Graessley'" , Subject: RE: An alternative to 6to4 and teredo Date: Sun, 19 Jan 2003 19:26:57 +0100 Organization: Unfix Message-ID: <005701c2bfe8$5a10e610$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA23455 Erik Nordmark wrote: > > That's not all. 6to4/Teredo offer an automatic configuration using > > anycast addresses. Much easier than trying to figure out > the closest > > tunnel broker, configuring to use that etc. > > If somebody wants to provide a good tunnel broker service they can > automate this without any changes in the clients. Just have > multiple tunnel > servers at different places in the topology and have the tunnel broker > meaure or estimate the location of the client before handing it > off to a tunnel server. > > Thus if example.net wants to capture IPv6 "customers" that they don't > have as IPv4 customers they could do this relatively easily. Which is exactly what we (SixXS) do, we actually let the user pick a 'preferred' POP, then measure their latency from the POPs to the selected IP and then we select onto which POP they go. This, the signup process, will be done completely automatically soon(tm). Mind you that TSP servers can already do it, wether they really do so I don't know though. Multiple TB's are implemented in their system though. > > I agree, but there is a cost to a tunnel broker model, that > is, not so > > simple configuration.. > > Yes, but see above. A single icon on the desktop might be sufficient. > And it has the advantage of lower operational complexity resulting in > a higher probability that it actually works. And should it > not work the icon allows you turn turn it off. If all is well the client should get a notification of the server controlling this system that: - it could not connect to the server. - it is not allowed to serv. - packets can't apparently reach the endpoint. (If you can't ping6 the remote endpoint the 6in4 path is broken) etc.. so this could also all be done automatically. Greets, Jeroen From owner-v6ops@ops.ietf.org Sun Jan 19 14:45: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 OAA24684 for ; Sun, 19 Jan 2003 14:45:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aLPJ-000GvL-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 11:47:01 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18aLOx-000Gtm-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 11:46:39 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id C218B8AED; Sun, 19 Jan 2003 20:46:35 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 00B8E78C8; Sun, 19 Jan 2003 20:46:29 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" , "'Erik Nordmark'" Cc: "'Joshua Graessley'" , Subject: RE: An alternative to 6to4 and teredo Date: Sun, 19 Jan 2003 20:46:32 +0100 Organization: Unfix Message-ID: <005f01c2bff3$787be9a0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA24684 Pekka Savola wrote: > Well.. I don't think you can get it much easier than 'echo > IPV6TO4INIT=yes >> /etc/sysconfig/network-scripts/ifcfg-eth0' or the like; > that's all you need to enable 6to4 using the anycast address on certain operating > systems. No software needed, no nothing: IPv6 in 5 seconds. > > Of course "actually works" is relative. Pinging the endpoint of the tunnel and/or the relay should show that it's up enough. if the tb/relay isn't setup correctly there isn't much one can do about it anyways. > Perhaps, to focus, we should ask ourselves: do we want to provide a > mechanism that provides easy use for the case where: > 1) Joe User wants to use his closest Tunnel Broker that > allows him to use > the service (not knowing where this closest TB even is!), or > 2) Joe User digs out the tunnel broker address/hostname of > his ISP or > someone close by and starts to use the service > > From my observation point, 6to4 is ultimately superior at 1), > at least in locations where you have some deployment of 6to4 relays (here > in Finland, there are at least two advertising 192.88.99.0/24 and 2002::/16). Well one should not limit "Tunnel Brokers" to systems using 6in4 (IPv6 in IPv4) IMHO there should/can/could be a mechanism that works somewhat like: C: Connect to central service S: I've X tunnelbrokers for you S: The best is number 10 C: Request 10 S: type = 6to4 S: ipv4_pop = 10.1.1.1 or: S: type = 6in4 S: ipv4_pop = 10.1.1.1 S: ipv6_pop = fec0::1 S: ipv6_client = fec0::1 S: prefixlen = 64 S: subnet = fec0:1000:1::/48 Or something similar. Note that one can take a good look at TSP for this. > Note that to be practical, 1) seems to require that there is some > mechanism of autodiscovering tunnel broker services. Surfing > the web is a no-go. Depends on the fact if there is a central face for the thing. Indeed googling around for such a setup is a no-go. Btw: on debian: apt-get install freenet6 and you are off. Apparently there are also Win32, *BSD and other clients. Maybe we should purssue a similiar or derived protocol like TSP? Note that there is 1 problem here: Central Point-Of-Failure if the central server providing the TB lists goes down/overloaded etc. In that case 6to4 is quite good, if one can reach the anycast address then one can have 6to4 too in most cases. As for the 'highlatency' one should restrict their 6to4 relay too peers so that people in austrialia simply don't see any 6to4 relay at all at the moment. IMHO none is better as the switch.ch relay with massive overhead. In any case if we want to see global low-latency tunnelbroker setups there have to be deployments of those TB's/relays close to the user. Greets, Jeroen From owner-v6ops@ops.ietf.org Sun Jan 19 16:13: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 QAA25521 for ; Sun, 19 Jan 2003 16:13:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aMnB-000MF4-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 13:15:45 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #2) id 18aMmq-000MAN-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 13:15:24 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 19 Jan 2003 13:14:52 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 19 Jan 2003 13:14:52 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 19 Jan 2003 13:14:52 -0800 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.3710.0); Sun, 19 Jan 2003 13:14:51 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 19 Jan 2003 13:14:51 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Sun, 19 Jan 2003 13:14:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: An alternative to 6to4 and teredo Date: Sun, 19 Jan 2003 13:14:51 -0800 Message-ID: Thread-Topic: An alternative to 6to4 and teredo Thread-Index: AcK/5ew0Pcq7K6V4S8enVbY7duT4KQAFpVtI From: "Christian Huitema" To: "Erik Nordmark" , "Pekka Savola" Cc: "Erik Nordmark" , "Joshua Graessley" , X-OriginalArrivalTime: 19 Jan 2003 21:14:51.0498 (UTC) FILETIME=[CE1714A0:01C2BFFF] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA25521 >> That's not all. 6to4/Teredo offer an automatic configuration using >> anycast addresses. Much easier than trying to figure out the closest >> tunnel broker, configuring to use that etc. > > If somebody wants to provide a good tunnel broker service they can > automate this without any changes in the clients. Just have multiple tunnel > servers at different places in the topology and have the tunnel broker > meaure or estimate the location of the client before handing it > off to a tunnel server. Even if you solved the set up issue, there would still be the matter of cost. Tunnel brokers are only "cost neutral" if they are provided by the user's ISP. On the other hand, if the tunnel broker has to be accessed over the Internet, then there is a direct bandwidth cost: the tunnel broker essentially becomes a secondary ISP. The cost may not be quite as large as the primary ISP, as there is less equipment involved, but it is of the same order of magnitude -- maybe 1/4th of the price of a regular subscription. You are unlikely to finance that kind of of cost with advertisements alone. Rather than opposing tunnel brokers and automatic solutions, we should consider them complementary. Something like, use autoconfiguration by default, switch to a provisioned tunnel if one is available. In the case of 6to4, this essentially boils down to replacing the default "anycast" route by the specific address of a configured (or brokered) relay. In the case of Teredo, this requires provisioning a "configured" mode. I actually debated this "configured Teredo" option with Keith Moore last year. You have to solve a basic security issue: a configured option requires some way to assert and prove the client's identity, so the client can retain a stable IPv6 address even if the NAT mappings happen to change. At the time, we could not agree on a simple security procedure, but since draft 08, Teredo's initialization process actually includes a sign on procedure. It would be fairly easy to program clients to go to a Teredo server and receive either a Teredo prefix of a stable prefix; in the latter case, the client would simply switch to tunnel mode. This would allow both the "free server" model of the current design, and a "configured server" model when the local ISP is willing to support it. -- Christian Huitema From owner-v6ops@ops.ietf.org Sun Jan 19 16:34:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25769 for ; Sun, 19 Jan 2003 16:34:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aN7e-000NaD-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 13:36:54 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #2) id 18aN7I-000NZR-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 13:36:32 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 19 Jan 2003 13:36:01 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 19 Jan 2003 13:36:01 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 19 Jan 2003 13:36:01 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sun, 19 Jan 2003 13:36:00 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 19 Jan 2003 13:36:00 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Sun, 19 Jan 2003 13:36:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comment on: draft-ietf-v6ops-unman-scenarios-00.txt Date: Sun, 19 Jan 2003 13:35:59 -0800 Message-ID: Thread-Topic: comment on: draft-ietf-v6ops-unman-scenarios-00.txt Thread-Index: AcK/IXfeKI+QbzVuSE2tXpGZZN6QQAA3nNsN From: "Christian Huitema" To: "Keith Moore" , "Brian E Carpenter" Cc: , , X-OriginalArrivalTime: 19 Jan 2003 21:36:00.0210 (UTC) FILETIME=[C24D2B20:01C2C002] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA25769 Brian asked: >> Is there any reason why we can't recommend strongly that the router >> for an unman network should incorporate a firewall with most ports >> closed by default, and opened manually on demand, as with most >> personal firewall products? Yes, there is a reason. On a PFW, you get an API for opening a port. On a home gateway, you may get midcom eventually, but you most probably have some kind a gateway specific manual configuration interface. And Keith added: > this is similar to what I've been thinking. A lot of this discussion is based on the assumption that if a host is provided with IPv6 connectivity, all the host services suddenly become accessible over IPv6. Well, this is not necessarily the case. (It is definitely not the case with Windows XP.) For example, some applications may not be accessible over IPv6, or may be programmed to only accept local connections, either from a scoped address or from a local prefix. So, in practice, the danger is not quite as large as you may think. My main issue with a "firewall all the ports" recommendation is that it perpetuates the firewall based security model, and that it also assumes that by default an unmanaged host should only behave as a client. This negates one of the main advantages of IPv6, i.e. the provision of global addresses and the ability for all hosts to behave as "servers" or "peers". There are other security models than port filtering at a server. One of them is precisely the "personal firewall" that Brian mentions. If the host is equipped with a personal firewall, then adding a firewall in the gateway is redondant, and in fact becomes a source of problems -- the user opens a port in the personal firewall, but the application still fails. The other security model is end-to-end IPSEC, which is arguably more powerful than port filtering. The bottom line is, one has to be very cautious with blanket recommendations, and we should not necessarily recommend a "client only" configuration. -- Christian Huitema From owner-v6ops@ops.ietf.org Sun Jan 19 17:38:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26526 for ; Sun, 19 Jan 2003 17:38:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aO7P-0001zT-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 14:40:43 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18aO7N-0001yG-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 14:40:41 -0800 Received: from esunmail ([129.147.58.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12477 for ; Sun, 19 Jan 2003 15:40:40 -0700 (MST) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H8Z00MZCGBR0E@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sun, 19 Jan 2003 15:40:40 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H8Z0038XGBO8G@mail.sun.net> for v6ops@ops.ietf.org; Sun, 19 Jan 2003 15:40:38 -0700 (MST) Date: Sun, 19 Jan 2003 14:41:33 -0800 From: Alain Durand Subject: Re: comment on: draft-ietf-v6ops-unman-scenarios-00.txt In-reply-to: To: Christian Huitema Cc: Keith Moore , Brian E Carpenter , v6ops@ops.ietf.org Message-id: <2943CDB5-2BFF-11D7-9AAD-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Sunday, January 19, 2003, at 01:35 PM, Christian Huitema wrote: > A lot of this discussion is based on the assumption that if a host is > provided with IPv6 connectivity, all the host services suddenly become > accessible over IPv6. Well, this is not necessarily the case. (It is > definitely not the case with Windows XP.) For example, some > applications may not be accessible over IPv6, or may be programmed to > only accept local connections, either from a scoped address or from a > local prefix. So, in practice, the danger is not quite as large as you > may think. A lot of this discussion is based on the observation that hosts are often ill-configured (or their default configuration is not secure) and the application running on them are often not as secure as they should be. Now, that said,some systems are better than others, and I'm willing to accept that system and application designer can do the right thing. However, IMHO, the issue should be documented in draft-ietf-v6ops-unman-scenarios. - Alain. From owner-v6ops@ops.ietf.org Sun Jan 19 20:20: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 UAA28112 for ; Sun, 19 Jan 2003 20:20:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQeU-000DC8-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:23:02 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18aQeT-000D7d-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:23:01 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25942; Sun, 19 Jan 2003 17:22:29 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1MOP20623; Mon, 20 Jan 2003 02:22:24 +0100 (MET) Date: Sun, 19 Jan 2003 22:42:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: An alternative to 6to4 and teredo To: Brian E Carpenter Cc: Erik Nordmark , Joshua Graessley , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3E285D34.A6067A4A@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.5 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I've never argued against tunnel brokers for isolated hosts. Please > remember that 6to4 was actually designed for whole sites with no > IPv6 ISP, not for isolated hosts. The fact that a well-known operating > system ships 6to4 for isolated hosts doesn't change the original design > point. My point is that tunnel brokers (plus prefix delegation?) might make sense beyond isolated hosts as well. For instance, it might make sense for a home router. The configuration isn't the elusive "zero", but it can be simple enough to be used. I wonder if there is any data on the fraction of the existing tunnel broker clients serve more than one host. (It does at the office in France.) Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:20: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 UAA28127 for ; Sun, 19 Jan 2003 20:20:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQfU-000DHt-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:24:04 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 18aQfS-000DCy-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:24:02 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07076; Sun, 19 Jan 2003 17:23:30 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1NNP20830; Mon, 20 Jan 2003 02:23:24 +0100 (MET) Date: Mon, 20 Jan 2003 00:59:43 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: on NAT-PT To: "Karim El-Malki (EAB)" Cc: "'Margaret Wasserman'" , juha.wiljakka@nokia.com, Alain.Durand@sun.com, brian@hursley.ibm.com, itojun@iijlab.net, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > You would be mistaken when we consider IMS. If I have an IMS IPv6 pdp > context, and want to communicate using IMS services with non-3g IPv4 hosts > that are using IPv4 SIP based services, then I can't use another v4 pdp > context. That's because IMS is only ipv6. So a translator + sip alg would be > useful. Karim, I thought 3GPP IMS and the IETF SIP specification are designed not to interoperate. Thus you'd need some SIP level proxy in any case. As long as you place the proxy on a dual-stack node you don't need any NAT-PT functionality. It seems like the only claimed strong case for NAT-PT in this email tread is 3GPP IMS, thus I think we need to understand this case a lot better. Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:20: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 UAA28142 for ; Sun, 19 Jan 2003 20:20:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQec-000DCP-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:23:10 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18aQea-000D7r-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:23:08 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26000; Sun, 19 Jan 2003 17:22:36 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1MVP20629; Mon, 20 Jan 2003 02:22:31 +0100 (MET) Date: Sun, 19 Jan 2003 22:52:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: An alternative to 6to4 and teredo To: Keith Moore Cc: Brian E Carpenter , Erik.Nordmark@sun.com, jgraessley@apple.com, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20030117210147.7cfc01d5.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=0.3 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > OTOH, I think tunnel broker is a good way to provide default route for a 6to4 > site. That would make the site be multi-addressed with a 6to4 prefix plus a prefix that was assigned by the tunnel broker. That raises questions of what source address filtering might be appropriate at the tunnel server - should they accept any source address? That would seem counter to the arguments about 6to4 relays introducing new ways to spoof source addresses - the tunnel server would in essence to the same. Unless there was a way to register an alternate source address prefix with the tunnel broker as part of configuring the tunnel broker ... Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:20:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28159 for ; Sun, 19 Jan 2003 20:20:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQfa-000DIY-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:24:10 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18aQfX-000DD5-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:24:07 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26308; Sun, 19 Jan 2003 17:23:36 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1NWP20899; Mon, 20 Jan 2003 02:23:32 +0100 (MET) Date: Mon, 20 Jan 2003 01:09:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: application proxy To: "Thakur, Anand" Cc: "V6ops (E-mail)" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > could someone please give me an example of 'application proxies' (for > ipv6/ipv4 transition) that people have been talking about in their drafts. > is BIA or BIS an example of this? if yes,are there any more examples? I didn't see anybody else respond so here I go. It is not BIA or BIS. Instead it is a regular application layer proxy such as a http proxy, a mail relay, or a SIP proxy, where the software is IPv6 capable. When you run such a piece of software on a dual-stack node in many cases it will just work - it will receive an email on one IP address and send it out on some other IP address - whether they are the same IP version or different IP versions. I know people can do this with sendmail for mail. I don't know which proxy(ies) folks have been using for this. I'm unsure if there are IPv6 SIP proxies which already support this. Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:20: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 UAA28173 for ; Sun, 19 Jan 2003 20:20:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQev-000DCv-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:23:29 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 18aQet-000DBw-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:23:27 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06886; Sun, 19 Jan 2003 17:22:55 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1MoP20683; Mon, 20 Jan 2003 02:22:51 +0100 (MET) Date: Mon, 20 Jan 2003 00:59:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: on NAT-PT To: itojun@iijlab.net Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20021128044637.BC9C24B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > there are some concerns raised in the working group meeting > with respect to NAT-PT. it seems to me that the concerns does not > have enough technical ground (or there are some confusions in > understanding how NAT-PT works). i don't see the need for revising > NAT-PT at all. some clarifications on the document might be nice, > but no major re-work is needed, IMHO. Sorry for the delay in responding. As a WG contrinutor I disagree. I think both NAT-PT and SIIT should be moved to historic or at least to a status where their deployment is not recommended. (And I think I understand Rob's comments that NAT-PT might be useful when the network is mostly IPv6 with some IPv4 islands needing NAT-PT functionality, but that isn't what NAT-PT is being proposed for today. Resurrecting it when we need that functionality would be fine.) The primary reason for this is unnecessary complexity. I assert that 90-99% of the cases where they are used one can instead use dual-stack hosts (and routers) with private IPv4 addresses and a good old IPv4 NAT. This has makes IPv6 add less complexity than having network operators not only have to understand and deal with the bad behaviors of their IPv4 NATs, also have to deal with the, likely slightly different, bad behaviors of NAT-PT boxes. Also, I expect NAT functionality to evolve over time because folks are using it and feeling the pain. But such improvement, whether done in the NAT boxes or by specifying and implementing protocols which work across the NAT, will be done first for IPv4 NATs with the NAT-PT functionality lagging. Two examples is STUN and IPsec. STUN can be used to cross IPv4 NAT boxes, but it is explicitly designed to not work with NAT-PT boxes since the protocol can not carry IPv6 addresses. There are non-standard IPsec implementations which work across IPv4 NATs, but I don't know of any that work across NAT-PT. And the IPsec WG might one day standardize this, but I expect any NAT-PT variant will be deferred in standardization or productization. So I think the preferred scheme for this type of interoperability should be what we already have - IPv4 private addresses and IPv4 NATs. With IPv6 end-to-end communication when communicating with IPv6 peers. Of course, there is 1-10% of cases when this is unattractive e.g. due to the need to route IPv4 inside the domain and it would make sense for the WG to try to understand that space better. In some of those cases I think the dual routing will be simpler than having a new type of NAT device to deal with. In other cases it might be sufficient to have proxy functionality at the v4/v6 boundary and no NAT (e.g. SIP, HTTP, SMTP) Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:21:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28187 for ; Sun, 19 Jan 2003 20:21:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQfK-000DHA-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:23:54 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18aQfJ-000DCa-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:23:53 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26231; Sun, 19 Jan 2003 17:23:21 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1NDP20748; Mon, 20 Jan 2003 02:23:13 +0100 (MET) Date: Mon, 20 Jan 2003 00:59:40 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: on NAT-PT To: itojun@iijlab.net Cc: Alain Durand , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20030104020047.BFA3F4B23@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > you are generalizing it too much by saying "in IPv6 networks" - what > i'm suggesting is to use "AD is secure" for NAT-PT, that's all. > it doesn't have to be imposed for all IPv6 networks. Suppose I have a host that doesn't want to trust "AD is secure". This might be because I'm only wanting to trust it when talking to my trusted "home" resolver. Suppose I visit a place which provides nice IPv6 functionality using NAT-PT. Can my box validate the DNSSEC signatures itself? As far as I understand it can't, since it doesn't know which AAAA records have been made up by the DNS ALG in the NAT-PT box. Reading draft-ietf-dnsext-dns-threats-02.txt makes me believe this would be unacceptable. Oh - and I think DNSSEC will be deployed in our lifetime, just like I think IPv6 will be deployed in our lifetime. But are likely to happen over the next 5-10 years. Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:21: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 UAA28201 for ; Sun, 19 Jan 2003 20:21:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQfq-000DJk-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:24:26 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18aQfo-000DJM-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:24:24 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06487; Sun, 19 Jan 2003 18:24:21 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1OGP20937; Mon, 20 Jan 2003 02:24:17 +0100 (MET) Date: Mon, 20 Jan 2003 01:49:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-01.txt To: Christian Huitema Cc: "Fred L. Templin" , Alain Durand , Pekka Savola , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > With a defense like the one I propose, it becomes about as hard to spoof > a v6 address using 6to4 as it is to spoof a v4 address (or a v6 address) > in the first place, which implies that 6to4 would have a neutral effect > on Internet security. Not quite. You are proposing an ITRACE-like detection mechanism whereas ingress filtering is a prevention mechanism. Thus once somebody is attacked they could scramble around looking for the detector that has hopefully logged your ITRACE-like packets (assuming those packets weren't filtered out by an over-zealous firewall). One note on the proposed ITRACE-like mechanism. What you specify is known as reverse-itrace. It also makes sense to do forward itrace where the reports are sent to the IPv6 DST (telling it the relationship between S4 and S6). That way in case the attack doesn't use reflection but is just e.g. a good old SYN attack, the victim sees the reports. I wonder if the packet formats in draft-ietf-itrace-03.txt can carry IPv6 addresses and be extended to carry S4. Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:21: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 UAA28217 for ; Sun, 19 Jan 2003 20:21:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQfu-000DKG-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:24:30 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18aQft-000DK3-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:24:29 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06520; Sun, 19 Jan 2003 18:24:27 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1OOP20954; Mon, 20 Jan 2003 02:24:24 +0100 (MET) Date: Mon, 20 Jan 2003 01:55:07 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: new 6to4 security draft To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > *) it seems to me that iTrace has been in a stall for the last 1-1.5 years > or so, so if a mechanism is needed one should either figure out why there > has been no progress (e.g. an architectural doubt about sending traces all > over the internet) or whether a simplified mechanism should be developed > independently. I think that is due to the firefighting approach. There are no widespread source address spoofing attacks, hence folks are looking at different fires. But there has been some slow progress on itrace since you sent the above mail. Making sure that the itrace packet formats can handle IPv6 addresses but the extra IPv4 address from a 6to4 relay would be a good idea just to keep our options open. Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:21:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28232 for ; Sun, 19 Jan 2003 20:21:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aQeK-000DBt-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:22:52 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #2) id 18aQeJ-000DBh-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:22:51 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07410; Sun, 19 Jan 2003 18:22:48 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1MgP20669; Mon, 20 Jan 2003 02:22:43 +0100 (MET) Date: Sun, 19 Jan 2003 23:06:30 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 6to4 security questions To: itojun@iijlab.net Cc: Erik Nordmark , Jason Goldschmidt , Tim Chown , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20030118000438.C9E894B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.2 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > you mean that there's no external connectivity to the 6bone? if sun's > firewall is acting as a 6to4 border router, the box is subject to > various attacks (as it will accept 6to4-encapsulated packet from > anybody). Yep. The Sun boxes you see in the 6bone are external to the firewall. Those boxes do not use 6to4. > having 6to4 relay router is totally different question from running > a 6to4 site. Not if all of it is sitting in an isolated network (inside a proxy-based firewall). The point is that if you have both native IPv6 address and 6to4 addresses in a routing realm, then you need relays. The deployment inside the Sun firewall avoids this by only using 6to4 addresses. Hence it doesn't test the relay aspects of 6to4. Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:46:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28581 for ; Sun, 19 Jan 2003 20:46:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aR3y-000FNm-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:49:22 -0800 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #2) id 18aR3v-000FNL-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:49:19 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04313; Sun, 19 Jan 2003 17:48:47 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0K1mdP22323; Mon, 20 Jan 2003 02:48:40 +0100 (MET) Date: Mon, 20 Jan 2003 02:45:10 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: An alternative to 6to4 and teredo To: Christian Huitema Cc: Erik Nordmark , Pekka Savola , Joshua Graessley , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Even if you solved the set up issue, there would still be the matter of > cost. Tunnel brokers are only "cost neutral" if they are provided by the > user's ISP. On the other hand, if the tunnel broker has to be accessed over > the Internet, then there is a direct bandwidth cost: the tunnel broker > essentially becomes a secondary ISP. The cost may not be quite as large as > the primary ISP, as there is less equipment involved, but it is of the same > order of magnitude -- maybe 1/4th of the price of a regular subscription. > You are unlikely to finance that kind of of cost with advertisements alone. I don't know the cost distribution for an access ISP, but I'm imagining a lot of it is related to the access equipment and network (modems, DLS stuff, cable plant and modems) whether they own or lease that. Some part of the cost is related to the aggregate bandwidth they support, but I have no idea how big part. Thus I think this is a business opportunity to explore. With a vendor hat on I'm sufficiently concerned about the operational complexity of 6to4 and teredo that I'm willing to put tunnel broker clients into our product. > Rather than opposing tunnel brokers and automatic solutions, we should > consider them complementary. Something like, use autoconfiguration by > default, switch to a provisioned tunnel if one is available. In the case of > 6to4, this essentially boils down to replacing the default "anycast" route > by the specific address of a configured (or brokered) relay. In the case of > Teredo, this requires provisioning a "configured" mode. So by default the box would use teredo/6to4? And then the user has to expicitly (or implicitly by configuring a tunnel) disable that? This means that if the teredo/6to4 is operationally unstable both the box as well as the new-fangled IPv6 thing will be perceived to be broken. Contrast this with a "click her to enable p2p games using the new IPv6 technology" ability you have if you make the users have to actively take one step to enable things. If it doesn't work well then they can at least turn it off. > I actually debated this "configured Teredo" option with Keith Moore last > year. You have to solve a basic security issue: a configured option requires > some way to assert and prove the client's identity, so the client can retain > a stable IPv6 address even if the NAT mappings happen to change. At the > time, we could not agree on a simple security procedure, but since draft 08, > Teredo's initialization process actually includes a sign on procedure. It > would be fairly easy to program clients to go to a Teredo server and receive > either a Teredo prefix of a stable prefix; in the latter case, the client > would simply switch to tunnel mode. This would allow both the "free server" > model of the current design, and a "configured server" model when the local > ISP is willing to support it. In the "tunnel mode" case do you still attempt to establish direct paths between NATs? We have zero operational experience with such approaches and I have no idea how to debug such a setup should I be exposed to it (since there is a NAT between me and the NET I can't view the real net for sure, which makes debugging a real pain for these types of improvements). Erik From owner-v6ops@ops.ietf.org Sun Jan 19 20:47: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 UAA28613 for ; Sun, 19 Jan 2003 20:47:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aR5h-000FYR-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 17:51:09 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18aR5f-000FYA-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 17:51:08 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 073E1797E; Mon, 20 Jan 2003 02:51:02 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 0C16D77AA; Mon, 20 Jan 2003 02:50:56 +0100 (CET) From: "Jeroen Massar" To: "'Erik Nordmark'" , "'Brian E Carpenter'" Cc: "'Joshua Graessley'" , Subject: RE: An alternative to 6to4 and teredo Date: Mon, 20 Jan 2003 02:50:59 +0100 Organization: Unfix Message-ID: <009901c2c026$61fb8900$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA28613 Erik Nordmark wrote: > I wonder if there is any data on the fraction of the existing tunnel > broker clients serve more than one host. (It does at the > office in France.) I can answer that very positively as seen from the SixXS perspective. Most of the users get a tunnel and are quite sharp at getting their subnet delegation the week later when they get enough credits for doing so. After that one will usually see 5+ different hosts coming from the delegated prefix. With 'hosts' I mean IP addresses who are surfing websites. The 'biggest' use for subnets unfortunatly is to have a cool/vanity hostnames on IRC though. We also tend to block out most of those users. And as we are known for doing that most of those users stay away from our tunnelbroker setup leaving over the more serious users and those where exactly who we want to serve. Personally I am quite glad with my subnet, as know all my 'internal' hosts can simply be reached from the public internet. Usually the places I visit and where I need IPv6 connectivity I try and convince the local admin in getting IPv6 and usually this ends up into setting them up with a IPv6 tunnel. Which is probably one of the advantages of having your 'own' tunnelbroker. Then again 1/3th of my home<->internet consist of IPv6 which IMHO is quite a lot. It would be a lot more if somebody convinced services like google to do IPv6 though. Most people I know/hear talking about it have the same feeling like me on the ground that it's quite handy to have all your hosts globally reachable. If you want real stats I could once setup a ntop like tool which counts traffic per destination/source port on the IPv6 level. Then one could really see for what IPv6 is being used. Unfortunatly I don't know of any IPv6 aware traffic analyzers which are capable of doing this. Greets, Jeroen From owner-v6ops@ops.ietf.org Sun Jan 19 20:59: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 UAA28718 for ; Sun, 19 Jan 2003 20:59:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aRGS-000GQU-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 18:02:16 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18aRGI-000GPz-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 18:02:06 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 76E68797E; Mon, 20 Jan 2003 03:02:02 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 31A7D78B1; Mon, 20 Jan 2003 03:01:57 +0100 (CET) From: "Jeroen Massar" To: "'Erik Nordmark'" , "'Keith Moore'" Cc: "'Brian E Carpenter'" , , Subject: RE: An alternative to 6to4 and teredo Date: Mon, 20 Jan 2003 03:02:00 +0100 Organization: Unfix Message-ID: <00a101c2c027$eb74c0b0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA28718 Erik Nordmark wrote: > > OTOH, I think tunnel broker is a good way to provide default route for a 6to4 > > site. > > That would make the site be multi-addressed with a 6to4 prefix > plus a prefix that was assigned by the tunnel broker. > > That raises questions of what source address filtering might > be appropriate > at the tunnel server - should they accept any source address? > That would seem counter to the arguments about 6to4 relays introducing > new ways to spoof source addresses - the tunnel server would > in essence to the same. > > Unless there was a way to register an alternate source address prefix > with the tunnel broker as part of configuring the tunnel broker ... I tend to simply block out anything not assigned to that tunnel. If a packet has a return path, the packet should use that as an outgoing path too. This has to do with source spoofing and with the fact that one otherwise would be giving a transit service to that tunnel user. As most tunnelbroker services are free, those ISP certainly aren't doing free transit for somebody else ;) Also debugging problems becomes quite a mess. Greets, Jeroen From owner-v6ops@ops.ietf.org Sun Jan 19 22:06: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 WAA29805 for ; Sun, 19 Jan 2003 22:06:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSJ0-000Lm7-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:08:58 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSIx-000Llu-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:08:55 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K37tu21935; Sun, 19 Jan 2003 22:07:55 -0500 (EST) Date: Sun, 19 Jan 2003 22:07:49 -0500 From: Marc Blanchet To: Erik Nordmark , Joshua Graessley cc: v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-ID: <2773430000.1043032069@Router> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29805 -- jeudi, janvier 16, 2003 20:32:28 +0100 Erik Nordmark wrote/a écrit: > > A long time ago Joshua wrote: > >> This is a chicken and egg problem. That is why transition tools are >> important. Apple could develop and ship a system that implemented 6to4 >> and shipworm/teredo to fall back on when IPv6 wasn't immediately >> available. Apple could also ship an application that made use of IPv6. >> Microsoft is in a similar position. Once that's done, third party >> developers can take advantage of that, assuming all of the transition >> mechanisms work. Shooting down 6to4 eliminates one transition >> mechanism. Not even acknowledging Teredo is another shot at transition. > > I argue that using tunnel broker and extending it to support UDP tunneling > across NATs see draft-parent-blanchet-ngtrans-tsp-teredo-00.txt applicability: draft-blanchet-ngtrans-tsp-applicability-00.txt >is much better than 6to4 and Teredo when considering the space > of temporary solutions until the ISPs provide native IPv6. > > I think tunnel brokered tunnels provide better incentives for deployment > than 6to4 relays because they are visible to the user - the provider > can throw in some content and adds as part of the web page you visit, > and the can claim "we have x,000 users". A 6to4 relay provider can not > do this. The "connect to IPv6" icon on the desktop also helps drive > IPv6 awareness - folks will see that enabling that allows them to run > their IPv6 peer to peer games even across an IPv4 NAT box, thus they > are more likely to ask their ISP for native IPv6 than if this is > completely automatic as is envisioned for Teredo. tunnel brokers with TSP enables the user to receive: - a ipv6 address of its tunnel endpoint. + by policy, the broker could give it permanently, even if the ipv4 address change. + which means that you keep your ipv6 address permanent if you care. - an ipv6 prefix, which enables a network behind the device: the network could be a mobile small network or a fixed network. + the ipv6 prefix can be permanent (decided by policy of broker) after being allocated by the broker. - register inverse dns delegation. - set up routing peering if necessary > > The only downside of the tunnel broker schemes is potentially less > efficient routing. - depends on where you put it. - there is provision in TSP to make a redirect to another broker. redirect could be related to topology. not perfect but could improve. > But if the services are popular this might be a > self-correcting problem. And if they are not popular it is either because > there is sufficient native IPv6 access or that IPv6 is not being widely > used. > > The upsides for tunnel broker (with UDP tunneling across NATs, or even PPP > over TCP over NATs for those so inclined) in addition to the incentives > above is that it avoids the security issues around 6to4 and Teredo, and is > operationally much much simpler to trouble-shoot. yes. tunnel brokers are just configuring "configured tunnels". tsp is a way to automate the establishment of the tunnel, with authentication. > And there isn't any risk of creating separate IPv6 native and 6to4 > universes since it is all IPv6 native addresses with regular IPv6 routing. > > Erik > Marc. From owner-v6ops@ops.ietf.org Sun Jan 19 22:11:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29833 for ; Sun, 19 Jan 2003 22:11:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSOR-000M8Z-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:14:35 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSOO-000M8N-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:14:32 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3DBu21975; Sun, 19 Jan 2003 22:13:12 -0500 (EST) Date: Sun, 19 Jan 2003 22:13:05 -0500 From: Marc Blanchet To: Jeroen Massar , "'Pekka Savola'" , "'Erik Nordmark'" cc: "'Joshua Graessley'" , v6ops@ops.ietf.org Subject: RE: An alternative to 6to4 and teredo Message-ID: <2781640000.1043032385@Router> In-Reply-To: <003b01c2be63$98eddb80$210d640a@unfix.org> References: <003b01c2be63$98eddb80$210d640a@unfix.org> X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29833 -- vendredi, janvier 17, 2003 21:04:08 +0100 Jeroen Massar wrote/a écrit: > Pekka Savola wrote: > >> On Thu, 16 Jan 2003, Erik Nordmark wrote: > > > >> That's not all. 6to4/Teredo offer an automatic configuration using >> anycast addresses. Much easier than trying to figure out the closest >> tunnel broker, configuring to use that etc. >> >> > The upsides for tunnel broker (with UDP tunneling across >> NATs, or even PPP >> > over TCP over NATs for those so inclined) in addition to >> the incentives above >> > is that it avoids the security issues around 6to4 and Teredo, and is >> > operationally much much simpler to trouble-shoot. >> >> I agree, but there is a cost to a tunnel broker model, that >> is, not so simple configuration.. > > There is at least Tunnel Setup Protocol (TSP*) which does automatic > configuration and it'salso quite extendable. On debian for instance > it's "apt-get install freenet6" and you are going. The only 'problem' > is that the Freenet6 broker system is located in the US thus european > hosts have some (80ms+) additional latency. A "POP" per ISP would be > better which is something we are pursuing for SixXS. The TSP protocol > can handle this fortunatly. A POP per ISP would at least mean that > clients can get near-native IPv6. > > TSP: http://www.freenet6.net/draft-tsp.shtml > It is marked "Expires: November 30, 2001" though, what happened > that it didn't get pushed through? we have made updates on the draft (but forgot to update the freenet6 website). please refer to: draft-blanchet-ngtrans-tsp-* Marc. From owner-v6ops@ops.ietf.org Sun Jan 19 22:14:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29865 for ; Sun, 19 Jan 2003 22:14:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSRT-000MNJ-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:17:43 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSRQ-000MLy-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:17:40 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3GRu22019; Sun, 19 Jan 2003 22:16:27 -0500 (EST) Date: Sun, 19 Jan 2003 22:16:19 -0500 From: Marc Blanchet To: Pekka Savola , Jeroen Massar cc: "'Erik Nordmark'" , "'Joshua Graessley'" , v6ops@ops.ietf.org Subject: RE: An alternative to 6to4 and teredo Message-ID: <2786140000.1043032579@Router> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29865 -- samedi, janvier 18, 2003 00:34:07 +0200 Pekka Savola wrote/a écrit: > [...] >> I've partially developped an alternative to this scheme with some >> big differences to what Freenet6 does with their TSP protocol. >> Some other things are in line first though. But it will be a >> system I want to have deployed at least before march for the >> SixXS system which we fortunatly abstracted with an API so that >> things like these can be implemented quite easily. >> Small example is port 42006 on our noc.sixxs.net box which >> basically replaces the website and can be easily accessed by >> any program capable of sending data over a tcp/ip socket. > > Above you show one of the main points here: there are dozens of > tunnelbrokers, and each have their own interface (pretty much). It's just > too much work that way. > > (btw, I think tunnel brokering would get off a bit if a client+server code > using some agreed protocol TSP? > would happen to be publicized under a liberal > license like BSD.) freenet6 code, which implements tsp, has a Mozilla license. > >> As I also probably wrote before, people do also sign up for >> things like MSN and hotmail etc, so an IPv6 tunnel via a >> webinterface shouldn't be that hard either. >> The only thing is making them think that having it is useful! >> (Which is one part I have on the 'other things to do first' :) > > Hotmail etc. have been around for ages. Tunnel brokers come and go. The > configuration may require some installation in your computer. Sure, many > folks still do it, but there's a big difference. > > But of course, some kind of "tunnel broker discovery" or catalogues could > be coined up too... we have a proposal on this already, that I can send if people are interested in it. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > Marc. From owner-v6ops@ops.ietf.org Sun Jan 19 22:17:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29881 for ; Sun, 19 Jan 2003 22:17:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSU1-000Mov-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:20:21 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSTz-000Mob-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:20:19 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3J6u22059; Sun, 19 Jan 2003 22:19:06 -0500 (EST) Date: Sun, 19 Jan 2003 22:19:00 -0500 From: Marc Blanchet To: Jeroen Massar , "'Pekka Savola'" cc: "'Erik Nordmark'" , "'Joshua Graessley'" , v6ops@ops.ietf.org Subject: RE: An alternative to 6to4 and teredo Message-ID: <2790940000.1043032740@Router> In-Reply-To: <001901c2beef$181389b0$210d640a@unfix.org> References: <001901c2beef$181389b0$210d640a@unfix.org> X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29881 -- samedi, janvier 18, 2003 13:42:41 +0100 Jeroen Massar wrote/a écrit: > Pekka Savola [mailto:pekkas@netcore.fi] wrote: > >> On Fri, 17 Jan 2003, Jeroen Massar wrote: >> > There is at least Tunnel Setup Protocol (TSP*) which does automatic >> > configuration and it'salso quite extendable. On debian for instance >> > it's "apt-get install freenet6" and you are going. The only >> 'problem' >> > is that the Freenet6 broker system is located in the US >> thus european >> > hosts have some (80ms+) additional latency. A "POP" per ISP would be >> > better which is something we are pursuing for SixXS. The >> TSP protocol >> > can handle this fortunatly. A POP per ISP would at least mean that >> > clients can get near-native IPv6. >> > >> > TSP: http://www.freenet6.net/draft-tsp.shtml >> > It is marked "Expires: November 30, 2001" though, what happened >> > that it didn't get pushed through? >> >> Folks probably lost hope. > > I rather think it never got completely finished seeing that > Appendix A mentions "A DTD should be placed here for the protocol." > etc... it is finished and code is working. again draft on the web site was not updated, but the ietf directory has new versions of the draft draft-blanchet-ngtrans-tsp* > I added Marc to the CC list he can probably best comment on > what happened and/or what is going on. > Marc. From owner-v6ops@ops.ietf.org Sun Jan 19 22:19: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 WAA29915 for ; Sun, 19 Jan 2003 22:19:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSWK-000N3H-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:22:44 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSWA-000N1z-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:22:34 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3Lbu22090; Sun, 19 Jan 2003 22:21:37 -0500 (EST) Date: Sun, 19 Jan 2003 22:21:31 -0500 From: Marc Blanchet To: Erik Nordmark , Pekka Savola cc: Joshua Graessley , v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-ID: <2794300000.1043032891@Router> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29915 -- dimanche, janvier 19, 2003 18:54:06 +0100 Erik Nordmark wrote/a écrit: >> That's not all. 6to4/Teredo offer an automatic configuration using >> anycast addresses. Much easier than trying to figure out the closest >> tunnel broker, configuring to use that etc. > > If somebody wants to provide a good tunnel broker service they can > automate this without any changes in the clients. Just have multiple > tunnel servers at different places in the topology and have the tunnel > broker meaure or estimate the location of the client before handing it > off to a tunnel server. yes. moreover, the tsp protocol enables the broker (again at the broker level) to refer the client to another broker which would better fits its needs (for whatever reason: > > Thus if example.net wants to capture IPv6 "customers" that they don't > have as IPv4 customers they could do this relatively easily. > >> I agree, but there is a cost to a tunnel broker model, that is, not so >> simple configuration.. > > Yes, but see above. A single icon on the desktop might be sufficient. > And it has the advantage of lower operational complexity resulting in > a higher probability that it actually works. And should it not work the > icon allows you turn turn it off. > > Erik > From owner-v6ops@ops.ietf.org Sun Jan 19 22:21:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29943 for ; Sun, 19 Jan 2003 22:21:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSXv-000NEO-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:24:23 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSXs-000NE9-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:24:21 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3NNu22112; Sun, 19 Jan 2003 22:23:23 -0500 (EST) Date: Sun, 19 Jan 2003 22:23:17 -0500 From: Marc Blanchet To: Pekka Savola , Erik Nordmark cc: Joshua Graessley , v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-ID: <2797810000.1043032997@Router> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29943 -- dimanche, janvier 19, 2003 20:19:46 +0200 Pekka Savola wrote/a écrit: > On Sun, 19 Jan 2003, Erik Nordmark wrote: >> > That's not all. 6to4/Teredo offer an automatic configuration using >> > anycast addresses. Much easier than trying to figure out the closest >> > tunnel broker, configuring to use that etc. >> >> If somebody wants to provide a good tunnel broker service they can >> automate this without any changes in the clients. > > .. assuming that the protocol TB uses is specified and implemented widely > enough. Being able to ship it by default in OS's helps. freenet6 client (which implements tsp) is in the ports of freebsd and some linux distributions. Marc. From owner-v6ops@ops.ietf.org Sun Jan 19 22:24:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00014 for ; Sun, 19 Jan 2003 22:24:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSb7-000NPM-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:27:41 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSaz-000NOw-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:27:33 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3QMu22166; Sun, 19 Jan 2003 22:26:22 -0500 (EST) Date: Sun, 19 Jan 2003 22:26:15 -0500 From: Marc Blanchet To: Christian Huitema , Erik Nordmark , Pekka Savola cc: Joshua Graessley , v6ops@ops.ietf.org Subject: RE: An alternative to 6to4 and teredo Message-ID: <2801970000.1043033175@Router> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA00014 -- dimanche, janvier 19, 2003 13:14:51 -0800 Christian Huitema wrote/a écrit: >>> That's not all. 6to4/Teredo offer an automatic configuration using >>> anycast addresses. Much easier than trying to figure out the closest >>> tunnel broker, configuring to use that etc. >> >> If somebody wants to provide a good tunnel broker service they can >> automate this without any changes in the clients. Just have multiple >> tunnel servers at different places in the topology and have the tunnel >> broker meaure or estimate the location of the client before handing it >> off to a tunnel server. > > Even if you solved the set up issue, there would still be the matter of > cost. Tunnel brokers are only "cost neutral" if they are provided by the > user's ISP. On the other hand, if the tunnel broker has to be accessed > over the Internet, then there is a direct bandwidth cost: the tunnel > broker essentially becomes a secondary ISP. The cost may not be quite as > large as the primary ISP, as there is less equipment involved, but it is > of the same order of magnitude -- maybe 1/4th of the price of a regular > subscription. You are unlikely to finance that kind of of cost with > advertisements alone. > Rather than opposing tunnel brokers and automatic solutions, we should > consider them complementary. Something like, use autoconfiguration by > default, switch to a provisioned tunnel if one is available. In the case > of 6to4, this essentially boils down to replacing the default "anycast" > route by the specific address of a configured (or brokered) relay. >In the > case of Teredo, this requires provisioning a "configured" mode. > I actually debated this "configured Teredo" option with Keith Moore last > year. You have to solve a basic security issue: a configured option > requires some way to assert and prove the client's identity, so the > client can retain a stable IPv6 address even if the NAT mappings happen tsp with NAT traversal (udp encap similar to teredo) have an authentication framework for users, so proving the identity of the user is already there. Marc. > to change. At the time, we could not agree on a simple security > procedure, but since draft 08, Teredo's initialization process actually > includes a sign on procedure. It would be fairly easy to program clients > to go to a Teredo server and receive either a Teredo prefix of a stable > prefix; in the latter case, the client would simply switch to tunnel > mode. This would allow both the "free server" model of the current > design, and a "configured server" model when the local ISP is willing to > support it. > -- Christian Huitema > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Sun Jan 19 22:25: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 WAA00033 for ; Sun, 19 Jan 2003 22:25:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSca-000NiE-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:29:12 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aScY-000Nhs-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:29:10 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3S6u22201; Sun, 19 Jan 2003 22:28:06 -0500 (EST) Date: Sun, 19 Jan 2003 22:28:00 -0500 From: Marc Blanchet To: Erik Nordmark , Brian E Carpenter cc: Joshua Graessley , v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-ID: <2804210000.1043033280@Router> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MIME_LONG_LINE_QP,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA00033 -- dimanche, janvier 19, 2003 22:42:20 +0100 Erik Nordmark wrote/a écrit: >> I've never argued against tunnel brokers for isolated hosts. Please >> remember that 6to4 was actually designed for whole sites with no >> IPv6 ISP, not for isolated hosts. The fact that a well-known operating >> system ships 6to4 for isolated hosts doesn't change the original design >> point. > > My point is that tunnel brokers (plus prefix delegation?) prefix delegation is what freenet6 (with tsp) is doing for years now, with user authentication (using SASL framework). > might make > sense beyond isolated hosts as well. For instance, it might make sense for > a home router. > > The configuration isn't the elusive "zero", but it can be simple enough to > be used. > > I wonder if there is any data on the fraction of the existing tunnel > broker clients serve more than one host. (It does at the office in > France.) It is in order of many many thousands on just freenet6. Marc. From owner-v6ops@ops.ietf.org Sun Jan 19 22:28: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 WAA00059 for ; Sun, 19 Jan 2003 22:28:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aSeu-000Nv8-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 19:31:36 -0800 Received: from jazz.viagenie.qc.ca ([206.123.31.2]) by psg.com with esmtp (Exim 3.36 #2) id 18aSer-000Nuq-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 19:31:33 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h0K3UKu22246; Sun, 19 Jan 2003 22:30:21 -0500 (EST) Date: Sun, 19 Jan 2003 22:30:14 -0500 From: Marc Blanchet To: Erik Nordmark , Keith Moore cc: Brian E Carpenter , jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-ID: <2807110000.1043033414@Router> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b10 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA00059 -- dimanche, janvier 19, 2003 22:52:20 +0100 Erik Nordmark wrote/a écrit: >> OTOH, I think tunnel broker is a good way to provide default route for a >> 6to4 site. > > That would make the site be multi-addressed with a 6to4 prefix > plus a prefix that was assigned by the tunnel broker. > > That raises questions of what source address filtering might be > appropriate at the tunnel server - should they accept any source address? tunnel server is implementing "configured tunnels", so strictly speaking, only configured tunnels are "accepted". > That would seem counter to the arguments about 6to4 relays introducing > new ways to spoof source addresses - the tunnel server would > in essence to the same. > > Unless there was a way to register an alternate source address prefix > with the tunnel broker as part of configuring the tunnel broker ... could be done, since the 6to4 prefix is derived from the ipv4 address of the source, which is also the source address of the tsp request and the tunnel endpoint. Marc. > > Erik > From owner-v6ops@ops.ietf.org Sun Jan 19 23:18: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 XAA01004 for ; Sun, 19 Jan 2003 23:18:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aTQs-0002Ls-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 20:21:10 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18aTQn-0002Ld-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 20:21:06 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0K4Ks912650; Mon, 20 Jan 2003 06:20:54 +0200 Date: Mon, 20 Jan 2003 06:20:54 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: itojun@iijlab.net, Subject: Re: on NAT-PT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I totally agree with Erik. NAT-PT/SIIT seem like mechanisms which could be useful if you want to artificially remove IPv4 even when the hosts do want to use IPv4. I many transition mechanism solutions I keep asking why should it be this complex. We should be able to advocate e.g. dual-stack capabilities. On Mon, 20 Jan 2003, Erik Nordmark wrote: > > there are some concerns raised in the working group meeting > > with respect to NAT-PT. it seems to me that the concerns does not > > have enough technical ground (or there are some confusions in > > understanding how NAT-PT works). i don't see the need for revising > > NAT-PT at all. some clarifications on the document might be nice, > > but no major re-work is needed, IMHO. > > Sorry for the delay in responding. > > As a WG contrinutor I disagree. > I think both NAT-PT and SIIT should be moved to historic or at least > to a status where their deployment is not recommended. > (And I think I understand Rob's comments that NAT-PT might be useful > when the network is mostly IPv6 with some IPv4 islands needing > NAT-PT functionality, but that isn't what NAT-PT is being proposed for today. > Resurrecting it when we need that functionality would be fine.) > > The primary reason for this is unnecessary complexity. > > I assert that 90-99% of the cases where they are used one can instead > use dual-stack hosts (and routers) with private IPv4 addresses and > a good old IPv4 NAT. > > This has makes IPv6 add less complexity than having network operators > not only have to understand and deal with the bad behaviors of > their IPv4 NATs, also have to deal with the, likely slightly different, > bad behaviors of NAT-PT boxes. > > Also, I expect NAT functionality to evolve over time because folks are > using it and feeling the pain. But such improvement, whether done in the NAT > boxes or by specifying and implementing protocols which work across > the NAT, will be done first for IPv4 NATs with the NAT-PT functionality > lagging. > > Two examples is STUN and IPsec. STUN can be used to cross IPv4 NAT boxes, > but it is explicitly designed to not work with NAT-PT boxes since the > protocol can not carry IPv6 addresses. > There are non-standard IPsec implementations which work across IPv4 NATs, > but I don't know of any that work across NAT-PT. And the IPsec WG > might one day standardize this, but I expect any NAT-PT variant will > be deferred in standardization or productization. > > So I think the preferred scheme for this type of interoperability should > be what we already have - IPv4 private addresses and IPv4 NATs. > With IPv6 end-to-end communication when communicating with IPv6 peers. > > Of course, there is 1-10% of cases when this is unattractive e.g. due > to the need to route IPv4 inside the domain and it would make sense for the > WG to try to understand that space better. In some of those cases > I think the dual routing will be simpler than having a new type of NAT device > to deal with. In other cases it might be sufficient to have proxy functionality > at the v4/v6 boundary and no NAT (e.g. SIP, HTTP, SMTP) > > Erik > > -- 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 Sun Jan 19 23:21:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01060 for ; Sun, 19 Jan 2003 23:21:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aTU9-0002fW-00 for v6ops-data@psg.com; Sun, 19 Jan 2003 20:24:33 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18aTU6-0002eN-00 for v6ops@ops.ietf.org; Sun, 19 Jan 2003 20:24:31 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0K4OJK12667; Mon, 20 Jan 2003 06:24:20 +0200 Date: Mon, 20 Jan 2003 06:24:19 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Keith Moore , Brian E Carpenter , , Subject: Re: An alternative to 6to4 and teredo In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, 19 Jan 2003, Erik Nordmark wrote: > > OTOH, I think tunnel broker is a good way to provide default route for a 6to4 > > site. > > That would make the site be multi-addressed with a 6to4 prefix > plus a prefix that was assigned by the tunnel broker. > > That raises questions of what source address filtering might be appropriate > at the tunnel server - should they accept any source address? > That would seem counter to the arguments about 6to4 relays introducing > new ways to spoof source addresses - the tunnel server would > in essence to the same. > > Unless there was a way to register an alternate source address prefix > with the tunnel broker as part of configuring the tunnel broker ... There are no need for any changes provided that everybody implements the new default address selection. That way communication between 6to4<->6to4 never uses the upstream tunnel broker, 6to4->native uses native source addresses and native->6to4 picks native destination addresses. Or so I've thought. This is very briefly noted in the new 6to4 security draft. -- 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 Jan 20 03:09: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 DAA13566 for ; Mon, 20 Jan 2003 03:09:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aX1f-000N0v-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 00:11:23 -0800 Received: from coconut.itojun.org ([219.101.47.130]) by psg.com with esmtp (Exim 3.36 #2) id 18aX1c-000N0d-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 00:11:20 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1A5C74B22; Mon, 20 Jan 2003 17:11:17 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Mon, 20 Jan 2003 06:20:54 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: on NAT-PT From: itojun@iijlab.net Date: Mon, 20 Jan 2003 17:11:17 +0900 Message-Id: <20030120081117.1A5C74B22@coconut.itojun.org> X-Spam-Status: No, hits=1.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I totally agree with Erik. NAT-PT/SIIT seem like mechanisms which could >be useful if you want to artificially remove IPv4 even when the hosts do >want to use IPv4. > >I many transition mechanism solutions I keep asking why should it be this >complex. We should be able to advocate e.g. dual-stack capabilities. i do not really advocating NAT-PT itself, so i personally am okay to see it go away. but there are scenarios such as 3GPP/cellular ones that tries to deploy IPv6-only clients. do you recommend them to do dual stack instead, or? itojun From owner-v6ops@ops.ietf.org Mon Jan 20 06:29: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 GAA16431 for ; Mon, 20 Jan 2003 06:29:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aa9x-00040i-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 03:32:09 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 18aa9u-00040W-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 03:32:06 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0KBYKt11799 for ; Mon, 20 Jan 2003 13:34:20 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Jan 2003 13:32:03 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 13:32:03 +0200 Received: from maebe001.NOE.Nokia.com ([10.209.0.44]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 13:32:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: An alternative to 6to4 and teredo Date: Mon, 20 Jan 2003 12:32:00 +0100 Message-ID: <05C8D36DA4EF684D8BD4E309B1CD5AF14C4C8A@maebe001.europe.nokia.com> Thread-Topic: An alternative to 6to4 and teredo Thread-Index: AcK+eb3qmto0DqXJTMuC9Rvjx2E3UwB/NW6A From: To: , Cc: , , X-OriginalArrivalTime: 20 Jan 2003 11:32:01.0797 (UTC) FILETIME=[8CEFEB50:01C2C077] X-Spam-Status: No, hits=1.3 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16431 -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 17 January, 2003 23:34 To: Jeroen Massar Cc: 'Erik Nordmark'; 'Joshua Graessley'; v6ops@ops.ietf.org Subject: RE: An alternative to 6to4 and teredo On Fri, 17 Jan 2003, Jeroen Massar wrote: >> TSP: http://www.freenet6.net/draft-tsp.shtml >> It is marked "Expires: November 30, 2001" though, what happened >> that it didn't get pushed through? >Folks probably lost hope. However, there is a newer version (although it expired last month): http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-01.txt Br, Ivan Laloux From owner-v6ops@ops.ietf.org Mon Jan 20 06:36:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16899 for ; Mon, 20 Jan 2003 06:36:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aaHQ-0004LW-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 03:39:52 -0800 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by psg.com with esmtp (Exim 3.36 #2) id 18aaHN-0004KM-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 03:39:49 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aaHG-0005IB-00; Mon, 20 Jan 2003 03:39:42 -0800 Date: Mon, 20 Jan 2003 06:35:52 -0500 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, brian@hursley.ibm.com, Alain.Durand@Sun.COM, v6ops@ops.ietf.org Subject: Re: comment on: draft-ietf-v6ops-unman-scenarios-00.txt Message-Id: <20030120063552.3d7f2edb.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >> Is there any reason why we can't recommend strongly that the router > >> for an unman network should incorporate a firewall with most ports > >> closed by default, and opened manually on demand, as with most > >> personal firewall products? > > Yes, there is a reason. On a PFW, you get an API for opening a port. On a > home gateway, you may get midcom eventually, but you most probably have some > kind a gateway specific manual configuration interface. mumble. both the API and midcom seem equally unsatisfactory. if you trust apps to be secure, what's the purpose of the firewall? and if you don't trust the apps to be secure, how is giving them an API going to make them more secure? manual configuration is a pain, but at least it puts the trust decision elsewhere. > And Keith added: > > this is similar to what I've been thinking. > > A lot of this discussion is based on the assumption that if a host is > provided with IPv6 connectivity, all the host services suddenly become > accessible over IPv6. Well, this is not necessarily the case. (It is > definitely not the case with Windows XP.) For example, some applications may > not be accessible over IPv6, or may be programmed to only accept local > connections, either from a scoped address or from a local prefix. So, in > practice, the danger is not quite as large as you may think. well, by the time this stuff gets deployed nobody is going to be using XP anyway :) again, if we can't trust the apps to be secure just because they invoke some API to open up a firewall, I don't think we can trust them to be secure just because they listen on a v6 socket. > My main issue with a "firewall all the ports" recommendation is that it > perpetuates the firewall based security model, and that it also assumes that > by default an unmanaged host should only behave as a client. This negates > one of the main advantages of IPv6, i.e. the provision of global addresses > and the ability for all hosts to behave as "servers" or "peers". I share this concern. And yet the problem of insecure applications is very real and widespread, and it's not going to go away just because we wish IPv6 to be more flexible. > The bottom line is, one has to be very cautious with blanket > recommendations, and we should not necessarily recommend a "client only" > configuration. I think there's a difference between recommending that hardware have a certain capability and recommending that it be used. Keith From owner-v6ops@ops.ietf.org Mon Jan 20 06:37: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 GAA16927 for ; Mon, 20 Jan 2003 06:37:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aaIK-0004Ns-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 03:40:48 -0800 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by psg.com with esmtp (Exim 3.36 #2) id 18aaIH-0004NG-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 03:40:45 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aaI7-00058X-00; Mon, 20 Jan 2003 03:40:35 -0800 Date: Mon, 20 Jan 2003 06:37:02 -0500 From: Keith Moore To: Pekka Savola Cc: moore@cs.utk.edu, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-Id: <20030120063702.269e6317.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 20 Jan 2003 06:24:19 +0200 (EET) Pekka Savola wrote: > On Sun, 19 Jan 2003, Erik Nordmark wrote: > > > OTOH, I think tunnel broker is a good way to provide default route for a 6to4 > > > site. > > > > That would make the site be multi-addressed with a 6to4 prefix > > plus a prefix that was assigned by the tunnel broker. > > > > That raises questions of what source address filtering might be appropriate > > at the tunnel server - should they accept any source address? > > That would seem counter to the arguments about 6to4 relays introducing > > new ways to spoof source addresses - the tunnel server would > > in essence to the same. > > > > Unless there was a way to register an alternate source address prefix > > with the tunnel broker as part of configuring the tunnel broker ... > > There are no need for any changes provided that everybody implements the > new default address selection. > > That way communication between 6to4<->6to4 never uses the upstream tunnel > broker, 6to4->native uses native source addresses and native->6to4 picks > native destination addresses. > > Or so I've thought. This is very briefly noted in the new 6to4 security > draft. address selection is fundamentally broken. it only works with two-party apps. Keith From owner-v6ops@ops.ietf.org Mon Jan 20 07:31: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 HAA17619 for ; Mon, 20 Jan 2003 07:31:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ab7Y-0006nX-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 04:33:44 -0800 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 18ab7V-0006nL-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 04:33:41 -0800 Received: (qmail 13630 invoked by uid 1007); 20 Jan 2003 12:33:39 -0000 Date: Mon, 20 Jan 2003 13:33:39 +0100 From: Gert Doering To: Keith Moore Cc: Pekka Savola , Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-ID: <20030120133339.F15927@Space.Net> References: <20030120063702.269e6317.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030120063702.269e6317.moore@cs.utk.edu>; from moore@cs.utk.edu on Mon, Jan 20, 2003 at 06:37:02AM -0500 X-NCC-RegID: de.space X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, Jan 20, 2003 at 06:37:02AM -0500, Keith Moore wrote: > address selection is fundamentally broken. it only works with two-party apps. Could you elaborate this a bit more? Everything that uses TCP or UDP is a "two-party connection" - otherwise, you use multicast, which has a completely different set of "address selection" issues. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) 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 Mon Jan 20 07:43:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17840 for ; Mon, 20 Jan 2003 07:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18abJs-0007Rd-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 04:46:28 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18abJp-0007RR-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 04:46:26 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0KCkAF15310; Mon, 20 Jan 2003 14:46:19 +0200 Date: Mon, 20 Jan 2003 14:46:09 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: on NAT-PT In-Reply-To: <20030120081117.1A5C74B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 20 Jan 2003 itojun@iijlab.net wrote: > >I totally agree with Erik. NAT-PT/SIIT seem like mechanisms which could > >be useful if you want to artificially remove IPv4 even when the hosts do > >want to use IPv4. > > > >I many transition mechanism solutions I keep asking why should it be this > >complex. We should be able to advocate e.g. dual-stack capabilities. > > i do not really advocating NAT-PT itself, so i personally am okay to > see it go away. but there are scenarios such as 3GPP/cellular ones > that tries to deploy IPv6-only clients. do you recommend them to > do dual stack instead, or? There are those 1-10% of cases where 3GPP might fit. But if we don't want that, providing ALG's to 3GPP and requiring they will have to use v6 for the rest could be acceptable too. But really, 3GPP (as long as you don't connect your laptops to your phones :-) is a rather restricted scenario in which NAT-PT could be acceptable. -- 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 Jan 20 07:49: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 HAA18268 for ; Mon, 20 Jan 2003 07:49:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18abPk-0007jD-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 04:52:32 -0800 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by psg.com with esmtp (Exim 3.36 #2) id 18abPd-0007il-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 04:52:26 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18abPH-0006XR-00; Mon, 20 Jan 2003 04:52:03 -0800 Date: Mon, 20 Jan 2003 07:48:30 -0500 From: Keith Moore To: Gert Doering Cc: moore@cs.utk.edu, pekkas@netcore.fi, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-Id: <20030120074830.386a7506.moore@cs.utk.edu> In-Reply-To: <20030120133339.F15927@Space.Net> References: <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 20 Jan 2003 13:33:39 +0100 Gert Doering wrote: > Hi, > > On Mon, Jan 20, 2003 at 06:37:02AM -0500, Keith Moore wrote: > > address selection is fundamentally broken. it only works with two-party > > apps. > > Could you elaborate this a bit more? Everything that uses TCP or UDP > is a "two-party connection" - otherwise, you use multicast, which has > a completely different set of "address selection" issues. many applications involve more than two parties, even if the interconnections between components of those applications are two-party connections. a >2 component app often needs to be able to provide referrals from one component to another - e.g. to say "if you need to access this component, contact it at address A port P". if the network requires address selection in order to allow one component to reach another, then it hinders operation of this kind of application. and for a variety of reasons, DNS is often too ambiguous, too slow, or too unreliable for DNS names to be used as general-purpose names for hosts. actually DNS is a good example of an application that uses referrals, both for its own use and for use by other applications. but DNS is not the only app that does this. From owner-v6ops@ops.ietf.org Mon Jan 20 07:53: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 HAA18307 for ; Mon, 20 Jan 2003 07:53:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18abTd-0007xq-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 04:56:33 -0800 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 18abTa-0007xE-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 04:56:30 -0800 Received: (qmail 16240 invoked by uid 1007); 20 Jan 2003 12:56:28 -0000 Date: Mon, 20 Jan 2003 13:56:01 +0100 From: Gert Doering To: Keith Moore Subject: Re: An alternative to 6to4 and teredo Message-ID: <20030120135601.J15927@Space.Net> References: <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <20030120074830.386a7506.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030120074830.386a7506.moore@cs.utk.edu>; from moore@cs.utk.edu on Mon, Jan 20, 2003 at 07:48:30AM -0500 X-NCC-RegID: de.space X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, Jan 20, 2003 at 07:48:30AM -0500, Keith Moore wrote: > > > address selection is fundamentally broken. it only works with two-party > > > apps. > > > > Could you elaborate this a bit more? Everything that uses TCP or UDP > > is a "two-party connection" - otherwise, you use multicast, which has > > a completely different set of "address selection" issues. > > many applications involve more than two parties, even if the interconnections > between components of those applications are two-party connections. a >2 > component app often needs to be able to provide referrals from one component > to another - e.g. to say "if you need to access this component, contact it at > address A port P". In that case, a reasonable way would be to pass on the full set of addresses for A. Especially for new protocols this should be taken into account, or when adapting old protocols to IPv6. (Deleting the already-written rant about broken protocols like FTP) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) 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 Mon Jan 20 08:49:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20172 for ; Mon, 20 Jan 2003 08:49:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18acKJ-000AXX-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 05:50:59 -0800 Received: from [194.196.100.237] (helo=d12lmsgate-4.de.ibm.com) by psg.com with esmtp (Exim 3.36 #2) id 18acKB-000ARe-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 05:50:51 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0KDnTUZ014168; Mon, 20 Jan 2003 14:49:30 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0KDnTU8283966; Mon, 20 Jan 2003 14:49:29 +0100 Received: from dhcp222-14.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42564 from ; Mon, 20 Jan 2003 14:49:10 +0100 Message-Id: <3E2BFE2D.F5B087BB@hursley.ibm.com> Date: Mon, 20 Jan 2003 14:48:29 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Christian Huitema Cc: Keith Moore , Alain.Durand@Sun.COM, v6ops@ops.ietf.org Subject: Re: comment on: draft-ietf-v6ops-unman-scenarios-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, SUPERLONG_LINE,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Philosophically, I agree with Christian. But in the real world (where we see a fair amount of FUD and paranoia), I think I agree with myself and Keith. Indeed, such a router would have to come with a distributed GUI so that to the user, it looks exactly like today's personal firewalls. I agree we should be cautious about recommendations, but at the minimum we must describe at least one solution that is safer than NAT. Brian Christian Huitema wrote: > > Brian asked: > >> Is there any reason why we can't recommend strongly that the router > >> for an unman network should incorporate a firewall with most ports > >> closed by default, and opened manually on demand, as with most > >> personal firewall products? > > Yes, there is a reason. On a PFW, you get an API for opening a port. On a home gateway, you may get midcom eventually, but you most probably have some kind a gateway specific manual configuration interface. > > And Keith added: > > this is similar to what I've been thinking. > > A lot of this discussion is based on the assumption that if a host is provided with IPv6 connectivity, all the host services suddenly become accessible over IPv6. Well, this is not necessarily the case. (It is definitely not the case with Windows XP.) For example, some applications may not be accessible over IPv6, or may be programmed to only accept local connections, either from a scoped address or from a local prefix. So, in practice, the danger is not quite as large as you may think. > > My main issue with a "firewall all the ports" recommendation is that it perpetuates the firewall based security model, and that it also assumes that by default an unmanaged host should only behave as a client. This negates one of the main advantages of IPv6, i.e. the provision of global addresses and the ability for all hosts to behave as "servers" or "peers". > > There are other security models than port filtering at a server. One of them is precisely the "personal firewall" that Brian mentions. If the host is equipped with a personal firewall, then adding a firewall in the gateway is redondant, and in fact becomes a source of problems -- the user opens a port in the personal firewall, but the application still fails. The other security model is end-to-end IPSEC, which is arguably more powerful than port filtering. > > The bottom line is, one has to be very cautious with blanket recommendations, and we should not necessarily recommend a "client only" configuration. > > -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Jan 20 10:21: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 KAA21716 for ; Mon, 20 Jan 2003 10:21:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18adls-000F7f-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 07:23:32 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18adln-000F5R-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 07:23:27 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.72.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA20228; Mon, 20 Jan 2003 07:21:52 -0800 (PST) Message-Id: <5.1.0.14.2.20030120100030.025f8030@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 Jan 2003 10:21:25 -0500 To: Erik Nordmark From: Margaret Wasserman Subject: Re: on NAT-PT Cc: itojun@iijlab.net, v6ops@ops.ietf.org In-Reply-To: References: <"Your message with ID" <20021128044637.BC9C24B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >As a WG contributor I disagree. >I think both NAT-PT and SIIT should be moved to historic or at least >to a status where their deployment is not recommended. Also as an individual contributor... I agree with Erik. I haven't seen a case yet where NAT-PT cannot be replaced with a less damaging and simpler mechanism (or combination of mechanisms), such as dual-stack hosts and tunneling. >I assert that 90-99% of the cases where they are used one can instead >use dual-stack hosts (and routers) with private IPv4 addresses and >a good old IPv4 NAT. >[...] >So I think the preferred scheme for this type of interoperability should >be what we already have - IPv4 private addresses and IPv4 NATs. >With IPv6 end-to-end communication when communicating with IPv6 peers. Exactly. Any node that needs to make a connection to an IPv4-only node or service must include an IPv4 stack. Any node that needs to connect to an IPv6-only node or service must include an IPv6 stack. Nodes that need to do both must be dual-stack. It just make sense. NAT-PT also has some problems that would be a serious limitation for almost any deployment, such as the inability for two nodes on the IPv6-only side of a NAT-PT box to establish an IPv4 connection to each other. >Of course, there is 1-10% of cases when this is unattractive e.g. due >to the need to route IPv4 inside the domain and it would make sense for the >WG to try to understand that space better. In some of those cases >I think the dual routing will be simpler than having a new type of NAT device >to deal with. In other cases it might be sufficient to have proxy >functionality >at the v4/v6 boundary and no NAT (e.g. SIP, HTTP, SMTP) There are also other alternatives that would not require IPv4 routing within the domain. For example, a dual stack host running in an IPv6-only infrastructure could set-up an IPv4 in IPv6 tunnel to the a dual-stack router on the edge of the IPv6-only network. The IPv4 address for the dual-stack host could be dynamically allocated/leased, allowing a large number of nodes that occasionally use IPv4 to share a smaller number of IPv4 addresses. DSTM offers one example of this type of mechanism. The proxy alternative may make sense for the 3GPP IMS case, as this is a special case where only certain services are required to be IPv6-only. IMS-capable handsets may still be capable of opening IPv4 PDP contexts for communication with non-IMS IPv4 nodes and services. I don't think that we've explored these alternatives enough to know which would make the most sense for the 3GPP IMS situation, and I don't think that we should settle on NAT-PT as the solution for that scenario until we have actively looked for alternatives that avoid the problems of NAT-PT. Margaret From owner-v6ops@ops.ietf.org Mon Jan 20 10:36: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 KAA22040 for ; Mon, 20 Jan 2003 10:36:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ae16-000G1Q-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 07:39:16 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18ae13-000FyM-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 07:39:13 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.72.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA01043; Mon, 20 Jan 2003 07:37:18 -0800 (PST) Message-Id: <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 Jan 2003 10:36:30 -0500 To: Keith Moore From: Margaret Wasserman Subject: Re: An alternative to 6to4 and teredo Cc: Gert Doering , moore@cs.utk.edu, pekkas@netcore.fi, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org In-Reply-To: <20030120074830.386a7506.moore@cs.utk.edu> References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >many applications involve more than two parties, even if the interconnections >between components of those applications are two-party connections. a >2 >component app often needs to be able to provide referrals from one component >to another - e.g. to say "if you need to access this component, contact it at >address A port P". I've been thinking about this a lot lately, and I wonder... Why do these referrals need to be by IP address? It would make more sense to refer another party to a DNS name and port number. Then the other party can do its own DNS look-up, and make its own address selection decision. >if the network requires address selection in order to allow one component to >reach another, then it hinders operation of this kind of application. >and for a variety of reasons, DNS is often too ambiguous, too slow, or too >unreliable for DNS names to be used as general-purpose names for hosts. If DNS is too ambiguous, slow or unreliable for this purpose, shouldn't we fix DNS? Margaret From owner-v6ops@ops.ietf.org Mon Jan 20 10:49: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 KAA22249 for ; Mon, 20 Jan 2003 10:49:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeDN-000Go9-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 07:51:57 -0800 Received: from p-mail1.rd.francetelecom.com ([193.49.124.31]) by psg.com with smtp (Exim 3.36 #2) id 18aeDK-000Gl9-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 07:51:54 -0800 Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail1 with InterScan Messaging Security Suite; Mon, 20 Jan 2003 16:51:36 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 16:51:21 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: on NAT-PT Date: Mon, 20 Jan 2003 16:51:20 +0100 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcLAmL+5iIt3xgZNT/ahVe578QIfIQAAlYrQ From: "BELOEIL Luc FTRD/DMI/CAE" To: "Margaret Wasserman" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 20 Jan 2003 15:51:21.0445 (UTC) FILETIME=[C735C950:01C2C09B] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA22249 Hi all, > > The proxy alternative may make sense for the 3GPP IMS case, as this > is a special case where only certain services are required to be > IPv6-only. IMS-capable handsets may still be capable of opening > IPv4 PDP contexts for communication with non-IMS IPv4 nodes and > services. > I've proposed that solution for months but it seems that current 3GPP specifications do not allow such a solution. > I don't think that we've explored these alternatives enough to know > which would make the most sense for the 3GPP IMS situation, and I > don't think that we should settle on NAT-PT as the solution for that > scenario until we have actively looked for alternatives that avoid the > problems of NAT-PT. > > Margaret > From an operator point of view, we do prefer IMS-capable dual-stack nodes and to avoid NAT-PT. Luc From owner-v6ops@ops.ietf.org Mon Jan 20 10:49:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22263 for ; Mon, 20 Jan 2003 10:49:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeCD-000Ghq-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 07:50:45 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #2) id 18aeC9-000Ghc-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 07:50:42 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id E6DE77E1D; Mon, 20 Jan 2003 16:50:37 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 265A97885; Mon, 20 Jan 2003 16:50:30 +0100 (CET) From: "Jeroen Massar" To: "'Margaret Wasserman'" Cc: Subject: RE: An alternative to 6to4 and teredo Date: Mon, 20 Jan 2003 16:50:35 +0100 Organization: Unfix Message-ID: <002601c2c09b$abf1a740$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > >many applications involve more than two parties, even if the > interconnections > >between components of those applications are two-party > connections. a >2 > >component app often needs to be able to provide referrals > from one component > >to another - e.g. to say "if you need to access this > component, contact it at > >address A port P". > > I've been thinking about this a lot lately, and I wonder... > Why do these > referrals need to be by IP address? It would make more sense to > refer another party to a DNS name and port number. Then the > other party > can do its own DNS look-up, and make its own address > selection decision. Not every IP has a correct forward/reverse pair. Especially with the /64 subnets and then multiple ones on the same net, not everybody will be putting up reverse and forwards. Thus one needs to remain at IP <-> IP level :( Also some protocols expect that the remote is the same as the other connection comes from for security reasons etc. Greets, Jeroen From owner-v6ops@ops.ietf.org Mon Jan 20 10:51: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 KAA22295 for ; Mon, 20 Jan 2003 10:51:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeG1-000Gw8-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 07:54:41 -0800 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 18aeFy-000Gvv-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 07:54:38 -0800 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0KFrLup000295; Mon, 20 Jan 2003 10:53:21 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 20 Jan 2003 10:52:51 -0500 Message-ID: <3E2C1C18.9060209@nc.rr.com> Date: Mon, 20 Jan 2003 10:56:08 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Keith Moore , Gert Doering , pekkas@netcore.fi, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, RCVD_IN_MULTIHOP_DSBL,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret Wasserman wrote: > > >> many applications involve more than two parties, even if the >> interconnections >> between components of those applications are two-party connections. a >2 >> component app often needs to be able to provide referrals from one >> component >> to another - e.g. to say "if you need to access this component, >> contact it at >> address A port P". > > > I've been thinking about this a lot lately, and I wonder... Why do these > referrals need to be by IP address? It would make more sense to > refer another party to a DNS name and port number. Then the other party > can do its own DNS look-up, and make its own address selection decision. Keith's argument is that DNS is too slow and not available. > >> if the network requires address selection in order to allow one >> component to >> reach another, then it hinders operation of this kind of application. >> and for a variety of reasons, DNS is often too ambiguous, too slow, or >> too >> unreliable for DNS names to be used as general-purpose names for hosts. > > > If DNS is too ambiguous, slow or unreliable for this purpose, shouldn't we > fix DNS? Yes! If the referral model can be made to work with DNS, then many of the issues with referrals and limited-scoped addresses would go away (IMHO). Regards, Brian From owner-v6ops@ops.ietf.org Mon Jan 20 10:52: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 KAA22331 for ; Mon, 20 Jan 2003 10:52:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeGj-000H1Q-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 07:55:25 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50] helo=smtp.cs.utk.edu) by psg.com with esmtp (Exim 3.36 #2) id 18aeGg-000H1B-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 07:55:22 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id C2EF01419F; Mon, 20 Jan 2003 10:55:18 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03767-09; Mon, 20 Jan 2003 10:55:18 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 0E2AA1419E; Mon, 20 Jan 2003 10:55:18 -0500 (EST) Date: Mon, 20 Jan 2003 10:55:17 -0500 From: Keith Moore To: Margaret Wasserman Cc: moore@cs.utk.edu, gert@space.net, pekkas@netcore.fi, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-Id: <20030120105517.4d5504a2.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: a57c64ad8ff481d411322bf7f1e70a1416b2d457 X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 20 Jan 2003 10:36:30 -0500 Margaret Wasserman wrote: > > > >many applications involve more than two parties, even if the > >interconnections between components of those applications are > >two-party connections. a >2 component app often needs to be able to > >provide referrals from one component to another - e.g. to say "if you > >need to access this component, contact it at address A port P". > > I've been thinking about this a lot lately, and I wonder... Why do > these referrals need to be by IP address? It would make more sense to > refer another party to a DNS name and port number. No it doesn't. First, because DNS is too slow and unreliable for some purposes; Second, because a host can have multiple DNS names associated with it at any given time, but the binding between the DNS name and the host is subject to change at any time and the host/app typically doesn't know which DNS names are bound to which things; Third, because even if an app does use DNS lookup to get all of the addresses of its peers it still doesn't mean that it's better to expect the host/app to be responsible for routing than to expect the network to do so. > Then the other party can do its own DNS look-up, and make its own > address selection decision. It's the idea that it's reasonable to expect a host or app to make a decision about which address to use that I'm questioning. Just because it's hard for the network to do routing on a large scale doesn't mean that apps and hosts are in a better position to do so. > >if the network requires address selection in order to allow one > >component to reach another, then it hinders operation of this kind of > >application. and for a variety of reasons, DNS is often too > >ambiguous, too slow, or too unreliable for DNS names to be used as > >general-purpose names for hosts. > > If DNS is too ambiguous, slow or unreliable for this purpose, > shouldn't we fix DNS? You can't fix DNS, at least not beyond a point. Part of the problem is that DNS names have long since ceased to be host names, and there's no going back. DNS names are now better thought of service names, with "host" just being another kind of service. Another part of the problem is that DNS is by intent and design heavily federated and distributed, which means that DNS servers typically aren't co-located with, and don't share fate with, the endpoints that use them. It may be possible to improve DNS, e.g. by building better tools to keep servers in sync and to discourage configuration errors, by using anycast addresses for DNS servers and using routing advertisements to direct queries to nearby servers that happen to be up, by building large distributed DNS server farms and getting sites to outsource their DNS servers to such farms (at least for their public DNS service), etc. But I don't see this happening soon, and in any event I don't see how DNS can be made as reliable as IP. DNS is a very useful service, but DNS names are not suitable as a universal replacement for IP addresses as endpoint identifiers. -- I tried enlightenment but it kept crashing. From owner-v6ops@ops.ietf.org Mon Jan 20 10:53: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 KAA22375 for ; Mon, 20 Jan 2003 10:53:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeIV-000H9N-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 07:57:15 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50] helo=smtp.cs.utk.edu) by psg.com with esmtp (Exim 3.36 #2) id 18aeIS-000H93-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 07:57:12 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 853891419E; Mon, 20 Jan 2003 10:57:11 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03767-10; Mon, 20 Jan 2003 10:57:11 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id E7B4013FC6; Mon, 20 Jan 2003 10:57:10 -0500 (EST) Date: Mon, 20 Jan 2003 10:57:10 -0500 From: Keith Moore To: Brian Haberman Cc: moore@cs.utk.edu, mrw@windriver.com, gert@space.net, pekkas@netcore.fi, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-Id: <20030120105710.71c9ea0c.moore@cs.utk.edu> In-Reply-To: <3E2C1C18.9060209@nc.rr.com> References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> <3E2C1C18.9060209@nc.rr.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: b9fc8f6abef2f70596a524e1c1f0be53e9535dbc X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > > If DNS is too ambiguous, slow or unreliable for this purpose, > > shouldn't we fix DNS? > > Yes! > > If the referral model can be made to work with DNS, then many of > the issues with referrals and limited-scoped addresses would go > away (IMHO). so if it's too hard to make IP routing work well, we'll just declare it somebody else's problem? even though that somebody else is in an even worse position to solve that problem? -- I tried enlightenment but it kept crashing. From owner-v6ops@ops.ietf.org Mon Jan 20 11:02:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22594 for ; Mon, 20 Jan 2003 11:02:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeQF-000HgN-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 08:05:15 -0800 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #2) id 18aeQ4-000Hfn-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 08:05:04 -0800 Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0KG42up015111; Mon, 20 Jan 2003 11:04:02 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 20 Jan 2003 11:06:01 -0500 Message-ID: <3E2C1E9A.3040208@nc.rr.com> Date: Mon, 20 Jan 2003 11:06:50 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore CC: v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> <3E2C1C18.9060209@nc.rr.com> <20030120105710.71c9ea0c.moore@cs.utk.edu> In-Reply-To: <20030120105710.71c9ea0c.moore@cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,NOSPAM_INC,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: >>>If DNS is too ambiguous, slow or unreliable for this purpose, >>>shouldn't we fix DNS? >> >>Yes! >> >>If the referral model can be made to work with DNS, then many of >>the issues with referrals and limited-scoped addresses would go >>away (IMHO). > > > so if it's too hard to make IP routing work well, we'll just declare it somebody else's problem? even though that somebody else is in an even worse position to solve that problem? > That is not what I am saying. Some of the arguments you have used are based on the DNS behavior. My point is that if we fix those, I would expect some of your concerns with referrals could be fixed by using names rather than addresses. Regards, Brian From owner-v6ops@ops.ietf.org Mon Jan 20 11:02: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 LAA22608 for ; Mon, 20 Jan 2003 11:02:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeQP-000Hh8-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 08:05:25 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18aeQM-000Hcj-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 08:05:22 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.72.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA15371; Mon, 20 Jan 2003 08:03:47 -0800 (PST) Message-Id: <5.1.0.14.2.20030120105426.033ffd70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 Jan 2003 11:00:29 -0500 To: "BELOEIL Luc FTRD/DMI/CAE" From: Margaret Wasserman Subject: RE: on NAT-PT Cc: "Erik Nordmark" , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 04:51 PM 1/20/2003 +0100, BELOEIL Luc FTRD/DMI/CAE wrote: >Hi all, > > > > > The proxy alternative may make sense for the 3GPP IMS case, as this > > is a special case where only certain services are required to be > > IPv6-only. IMS-capable handsets may still be capable of opening > > IPv4 PDP contexts for communication with non-IMS IPv4 nodes and > > services. > > >I've proposed that solution for months but it seems that current 3GPP >specifications do not allow such a solution. My understanding is that the IMS subsystem is specified to be IPv6-only, which will require that some services are only available on IPv6 (i.e. the 3GPP version of SIP). This may also result in some parts of the 3GPP infrastructure (routers and equivalent) being IPv6-only. While a handset can be IMS-capable, I don't think that an IMS-capable handset is required to be IPv6-only. An IMS handset could still be capable of establishing IPv4 PDP contexts, and using IPv4 to access the Internet and/or non-IMS 3GPP networks and services... Could someone correct me if I'm wrong, and please cite relevant parts of the 3GPP standards? Margaret From owner-v6ops@ops.ietf.org Mon Jan 20 11:08: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 LAA22712 for ; Mon, 20 Jan 2003 11:08:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aeWE-000I2N-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 08:11:26 -0800 Received: from moebius2.space.net ([195.30.1.100] ident=qmailr) by psg.com with smtp (Exim 3.36 #2) id 18aeWB-000I29-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 08:11:24 -0800 Received: (qmail 36963 invoked by uid 1007); 20 Jan 2003 16:11:21 -0000 Date: Mon, 20 Jan 2003 17:11:21 +0100 From: Gert Doering To: Keith Moore Cc: Brian Haberman , mrw@windriver.com, gert@space.net, pekkas@netcore.fi, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-ID: <20030120171121.Y15927@Space.Net> References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> <3E2C1C18.9060209@nc.rr.com> <20030120105710.71c9ea0c.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030120105710.71c9ea0c.moore@cs.utk.edu>; from moore@cs.utk.edu on Mon, Jan 20, 2003 at 10:57:10AM -0500 X-NCC-RegID: de.space X-Spam-Status: No, hits=-5.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, Jan 20, 2003 at 10:57:10AM -0500, Keith Moore wrote: > so if it's too hard to make IP routing work well, we'll just declare > it somebody else's problem? even though that somebody else is in an > even worse position to solve that problem? It's part of the "make IP routing work" solution to put part of the burden onto someone else. I think we all agree that "giving everybody and his dog" portable address space so he can do multihoming to his heart's content is not going to work. So some other approaches are needed, and "multiple IPv6 prefixes on the same infrastructure" combined with something like SCTP has potential to be part of the solution, at least for a certain class of "globally-visible address-space multihoming candidates". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55857 (55593) 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 Mon Jan 20 12:15:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24460 for ; Mon, 20 Jan 2003 12:15:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18afYK-000LcD-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 09:17:40 -0800 Received: from p-mail2.rd.francetelecom.com ([193.49.124.32] helo=p-mail2) by psg.com with smtp (Exim 3.36 #2) id 18afYF-000Lb7-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 09:17:36 -0800 Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by 192.144.74.32 with InterScan Messaging Security Suite; Mon, 20 Jan 2003 18:21:23 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 20 Jan 2003 18:17:03 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: on NAT-PT Date: Mon, 20 Jan 2003 18:17:02 +0100 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcLAnah/jrZSrCBfQ6WK5kSKv1nM7QABeyZA From: "BELOEIL Luc FTRD/DMI/CAE" To: "Margaret Wasserman" Cc: "Erik Nordmark" , , X-OriginalArrivalTime: 20 Jan 2003 17:17:03.0242 (UTC) FILETIME=[BFF5BEA0:01C2C0A7] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24460 > -----Message d'origine----- > De : Margaret Wasserman [mailto:mrw@windriver.com] > > At 04:51 PM 1/20/2003 +0100, BELOEIL Luc FTRD/DMI/CAE wrote: > >Hi all, > > > > > > > > The proxy alternative may make sense for the 3GPP IMS > case, as this > > > is a special case where only certain services are required to be > > > IPv6-only. IMS-capable handsets may still be capable of opening > > > IPv4 PDP contexts for communication with non-IMS IPv4 nodes and > > > services. oh ! I've read too quickly. You are right. Sorry. Luc From owner-v6ops@ops.ietf.org Mon Jan 20 14:06:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27659 for ; Mon, 20 Jan 2003 14:06:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ahHP-0000bA-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 11:08:19 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18ahHL-0000Z6-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 11:08:15 -0800 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 LAA17328; Mon, 20 Jan 2003 11:07:42 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0KJ7fW27881; Mon, 20 Jan 2003 11:07:41 -0800 X-mProtect: <200301201907> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1kAhZd; Mon, 20 Jan 2003 11:07:40 PST Message-ID: <3E2C4AA9.1070207@iprg.nokia.com> Date: Mon, 20 Jan 2003 11:14:49 -0800 From: "Fred L. 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: Erik Nordmark , Pekka Savola , Joshua Graessley , v6ops@ops.ietf.org, Marc Blanchet Subject: Re: An alternative to 6to4 and teredo References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > Even if you solved the set up issue, there would still be the matter of cost. Tunnel brokers are only "cost > neutral" if they are provided by the user's ISP. On the other hand, if the tunnel broker has to be accessed > over the Internet, then there is a direct bandwidth cost: the tunnel broker essentially becomes a secondary > ISP. The cost may not be quite as large as the primary ISP, as there is less equipment involved, but it is of > the same order of magnitude -- maybe 1/4th of the price of a regular subscription. You are unlikely to finance > that kind of of cost with advertisements alone. There is also the cost issue of the number of messages required to set up the tunnel. There needs to be a reasonably persistent flow of messages from a source to a particular destination (or, from a source *through* a particular tunnel broker) before the cost for tunnel setup can be amortized. Thus, I agree with Christian that tunnel brokers provided by the ISP are one example in which the cost is justified. In other cases, e.g., when the source sends only a few messages to a particular destination) automatic tunnelling mechanisms are more cost-efficient. > Rather than opposing tunnel brokers and automatic solutions, we should consider them complementary. Something > like, use autoconfiguration by default, switch to a provisioned tunnel if one is available. In the case of > 6to4, this essentially boils down to replacing the default "anycast" route by the specific address of a > configured (or brokered) relay. In the case of Teredo, this requires provisioning a "configured" mode. I agree with the complementary observation. Automatic tunneling can provide the default behavior and configured tunnels (or, "semi-automatic" tunnels) can be established when/if needed. (Longest-prefix-match will steer packets to the appropriate interface.) Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Mon Jan 20 14:15: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 OAA27991 for ; Mon, 20 Jan 2003 14:15:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ahRN-00012a-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 11:18:37 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #2) id 18ahRK-00011b-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 11:18:34 -0800 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 LAA18395; Mon, 20 Jan 2003 11:17:59 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h0KJHxT10557; Mon, 20 Jan 2003 11:17:59 -0800 X-mProtect: <200301201917> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkFkGWb; Mon, 20 Jan 2003 11:17:57 PST Message-ID: <3E2C4D13.8020608@iprg.nokia.com> Date: Mon, 20 Jan 2003 11:25:07 -0800 From: "Fred L. 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: Marc Blanchet CC: Pekka Savola , Jeroen Massar , "'Erik Nordmark'" , "'Joshua Graessley'" , v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo References: <2786140000.1043032579@Router> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Marc Blanchet wrote: > -- samedi, janvier 18, 2003 00:34:07 +0200 Pekka Savola > wrote/a icrit: >>(btw, I think tunnel brokering would get off a bit if a client+server code >>using some agreed protocol > > > TSP? I have previously stated that I see merits in the TSP approach, but in a complimentary (not competitive) sense wrt automatic tunneling. I believe automatic tunneling can provide a ubiquitous, connectionless mechanism with configured (and/or "semi-automatic") tunnels providing a connection-oriented mechanism for special use-cases (e.g., when stronger security, bi-directonal links, etc. are needed). See: 'draft-templin-interact-00.txt' for text describing how an automatic tunneling mechanism (in this case, ISATAP) can coexist with TSP. Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Mon Jan 20 14: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 OAA28630 for ; Mon, 20 Jan 2003 14:38:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ahn9-0002HB-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 11:41:07 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50] helo=smtp.cs.utk.edu) by psg.com with esmtp (Exim 3.36 #2) id 18ahn6-0002Gs-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 11:41:04 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7392113FCC; Mon, 20 Jan 2003 14:41:03 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 00501-03; Mon, 20 Jan 2003 14:41:02 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id D327C13FC9; Mon, 20 Jan 2003 14:41:02 -0500 (EST) Date: Mon, 20 Jan 2003 14:41:02 -0500 From: Keith Moore To: Brian Haberman Cc: moore@cs.utk.edu, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-Id: <20030120144102.1cc11e18.moore@cs.utk.edu> In-Reply-To: <3E2C1E9A.3040208@nc.rr.com> References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> <3E2C1C18.9060209@nc.rr.com> <20030120105710.71c9ea0c.moore@cs.utk.edu> <3E2C1E9A.3040208@nc.rr.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: da70ff8981ec164b58270eac5c8021c7f73e6cac X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > so if it's too hard to make IP routing work well, we'll just declare > > it somebody else's problem? even though that somebody else is in > > an even worse position to solve that problem? > > > > That is not what I am saying. Some of the arguments you have > used are based on the DNS behavior. My point is that if we > fix those, I would expect some of your concerns with referrals > could be fixed by using names rather than addresses. as I said in a separate thread, while DNS can be improved, I don't think it can be fixed to be fast or reliable enough for DNS names to serve as general-purpose endpoint identifiers. -- I tried enlightenment but it kept crashing. From owner-v6ops@ops.ietf.org Mon Jan 20 14:39:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28673 for ; Mon, 20 Jan 2003 14:39:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ahoT-0002L5-00 for v6ops-data@psg.com; Mon, 20 Jan 2003 11:42:29 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50] helo=smtp.cs.utk.edu) by psg.com with esmtp (Exim 3.36 #2) id 18ahoQ-0002Kt-00 for v6ops@ops.ietf.org; Mon, 20 Jan 2003 11:42:27 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0E30D13FCC; Mon, 20 Jan 2003 14:42:26 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 00387-06; Mon, 20 Jan 2003 14:42:25 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 6CCC913FC9; Mon, 20 Jan 2003 14:42:25 -0500 (EST) Date: Mon, 20 Jan 2003 14:42:25 -0500 From: Keith Moore To: Gert Doering Cc: moore@cs.utk.edu, bkhabs@nc.rr.com, mrw@windriver.com, gert@space.net, pekkas@netcore.fi, Erik.Nordmark@sun.com, brian@hursley.ibm.com, jgraessley@apple.com, v6ops@ops.ietf.org Subject: Re: An alternative to 6to4 and teredo Message-Id: <20030120144225.60f50116.moore@cs.utk.edu> In-Reply-To: <20030120171121.Y15927@Space.Net> References: <20030120133339.F15927@Space.Net> <20030120063702.269e6317.moore@cs.utk.edu> <20030120133339.F15927@Space.Net> <5.1.0.14.2.20030120103322.033f96f8@mail.windriver.com> <3E2C1C18.9060209@nc.rr.com> <20030120105710.71c9ea0c.moore@cs.utk.edu> <20030120171121.Y15927@Space.Net> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 3684ac769ceb1623fae0432e6ba2e6415db0cb8c X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 20 Jan 2003 17:11:21 +0100 Gert Doering wrote: > Hi, > > On Mon, Jan 20, 2003 at 10:57:10AM -0500, Keith Moore wrote: > > so if it's too hard to make IP routing work well, we'll just declare > > > > it somebody else's problem? even though that somebody else is in > > an even worse position to solve that problem? > > It's part of the "make IP routing work" solution to put part of the > burden onto someone else. not when that "someone else" is even less capable of solving the problem. -- I tried enlightenment but it kept crashing. From owner-v6ops@ops.ietf.org Tue Jan 21 03:20: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 DAA23483 for ; Tue, 21 Jan 2003 03:20:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18atf6-000HRr-00 for v6ops-data@psg.com; Tue, 21 Jan 2003 00:21:36 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18atf3-000HRZ-00 for v6ops@ops.ietf.org; Tue, 21 Jan 2003 00:21:33 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0L8KV027250 for ; Tue, 21 Jan 2003 10:20:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Jan 2003 10:21:29 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 10:21:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Tue, 21 Jan 2003 10:21:24 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC36B1@esebe005.ntc.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcLAnkqBsdKmVNPkQKuZP+4F5yqxYQAg+cUA From: To: , Cc: , , , X-OriginalArrivalTime: 21 Jan 2003 08:21:25.0255 (UTC) FILETIME=[16A3D970:01C2C126] X-Spam-Status: No, hits=1.3 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA23483 Hi, Margaret & others! Just refering to 3GPP 23.221 specification that states about the supported IP version in the IMS: 3GPP TS 23.221 V5.7.0 (2002-12), subsection 5.1.: "- IM CN subsystem elements (UE to CSCF and the other elements e.g. MRF): - The architecture shall make optimum use of IPv6. - The IM CN subsystem shall exclusively support IPv6. - The UE shall exclusively support IPv6 for the connection to services provided by the IM CN subsystem." This tells us that IMS is IPv6-only (also UE is considered to be a part of the IMS when using IMS services). Some further comments: - IMS is an extensive concept; when saying that IMS is "exclusively IPv6", it is a valid statement for all elements that are connected to the IMS / considered to be a part of the IMS. Both signalling and user data traffic belong to the IMS. E.g. the connections between two IMS UEs belong to the IMS. Connections can only be IPv6, not IPv4 and not IPv4 & IPv6 simultaneously. - The user has to activate an IPv6 PDP context to access IMS and registrate to the P-CSCF (i.e. registrate to the IMS SIP server) using an IPv6 address. - E.g. tunneling traffic (IPv4 in IPv6) through the IMS and IPv4 connection from the IMS UE to the IPv4 correspondent node is not a feasible solution for IMS scenario 1. However, the (3GPP Release 5) UE can use IPv4 (type of PDP contexts) to access other services than IMS, e.g. web browsing, MMS, e-mail... The latest version of the 23.221 specification can be found here: ftp://ftp.3gpp.org/specs/latest/Rel-5/23_series/23221-570.zip Best Regards, -Juha W.- -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@windriver.com] Sent: 20 January, 2003 18:00 To: BELOEIL Luc FTRD/DMI/CAE Cc: Erik Nordmark; itojun@iijlab.net; v6ops@ops.ietf.org Subject: RE: on NAT-PT At 04:51 PM 1/20/2003 +0100, BELOEIL Luc FTRD/DMI/CAE wrote: >Hi all, > > > > > The proxy alternative may make sense for the 3GPP IMS case, as this > > is a special case where only certain services are required to be > > IPv6-only. IMS-capable handsets may still be capable of opening > > IPv4 PDP contexts for communication with non-IMS IPv4 nodes and > > services. > > >I've proposed that solution for months but it seems that current 3GPP >specifications do not allow such a solution. My understanding is that the IMS subsystem is specified to be IPv6-only, which will require that some services are only available on IPv6 (i.e. the 3GPP version of SIP). This may also result in some parts of the 3GPP infrastructure (routers and equivalent) being IPv6-only. While a handset can be IMS-capable, I don't think that an IMS-capable handset is required to be IPv6-only. An IMS handset could still be capable of establishing IPv4 PDP contexts, and using IPv4 to access the Internet and/or non-IMS 3GPP networks and services... Could someone correct me if I'm wrong, and please cite relevant parts of the 3GPP standards? Margaret From owner-v6ops@ops.ietf.org Tue Jan 21 08:37: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 IAA29543 for ; Tue, 21 Jan 2003 08:37:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aydT-000PQJ-00 for v6ops-data@psg.com; Tue, 21 Jan 2003 05:40:15 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18aydQ-000PPF-00 for v6ops@ops.ietf.org; Tue, 21 Jan 2003 05:40:12 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA18973; Tue, 21 Jan 2003 05:38:32 -0800 (PST) Message-Id: <5.1.0.14.2.20030121082144.035e4998@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 Jan 2003 08:38:07 -0500 To: From: Margaret Wasserman Subject: RE: on NAT-PT Cc: , , , , In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC36B1@esebe005.ntc.nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Juha, Thanks for the references. >- IMS is an extensive concept; when saying that IMS is "exclusively IPv6", >it is a valid statement for all elements that are connected to the IMS / >considered to be a part of the IMS. Both signalling and user data traffic >belong to the IMS. E.g. the connections between two IMS UEs belong to the >IMS. Connections can only be IPv6, not IPv4 and not IPv4 & IPv6 >simultaneously. I don't understand why the IMS being "exclusively IPv6" would prevent two IMS-capable UEs from opening IPv4 PDP contexts and connecting to each other for non-IMS services. I'm not even sure how you could prevent this, as an IMS-capable UE has no real way of knowing whether the remote service that it is trying to access is/isn't hosted on another IMS-capable UE. It seems very likely that, regardless of the capabilities of the handset, some folks will want to use IPv4-only devices behind the handset (IPv4-only palm pilots, laptops, etc.) for some time. Even after IPv6 is available on most laptops, palm pilots, etc. they may still need/want to run IPv4-only applications. I can't understand how it would be in the best interests of 3GPP, IPv6 or anyone else to prevent two people who buy very high-end IMS-capable phones from making an IPv4 connection between their two phones to run an IPv4-only application... >- The user has to activate an IPv6 PDP context to access IMS and >registrate to the P-CSCF (i.e. registrate to the IMS SIP server) using an >IPv6 address. Right, this is clear. The IMS-capable UE will have to use IPv6 to access SIP and other IMS services. IMS connections to regular Internet SIP services (which may be IPv4-only) will be done through a proxy. So, the IPv6 <-> IPv4 conversion can also be handled by that proxy. Are there other services that are part of IMS that need to be proxied? >- E.g. tunneling traffic (IPv4 in IPv6) through the IMS and IPv4 >connection from the IMS UE to the IPv4 correspondent node is not a >feasible solution for IMS scenario 1. > >However, the (3GPP Release 5) UE can use IPv4 (type of PDP contexts) to >access other services than IMS, e.g. web browsing, MMS, e-mail... When you say that tunneling (IPv4 in IPv6) is not feasible, is that just a dogmatic position (based on the dogma that IMS is IPv6-only), or is there a technical reason why you couldn't tunnel IPv4 over the IPv6-only parts of the IMS infrastructure? As far as handsets go, I think it is fine that they have to use IPv6 to access IMS services, as those services are IPv6-only. As long as they can use IPv4 to access non-IMS services, I don't see where the need for NAT-PT comes in. I've just printed out the latest 3GPP scenario/analysis documents, and I'll read them again... But, I'm still not convinced that NAT-PT is really needed in this situation, and I'd like to see a clearer technical analysis of why less damaging alternatives (dual-stack, possibly combined with IPv4 in IPv6 tunnels) would not work. Margaret > > >The latest version of the 23.221 specification can be found here: >ftp://ftp.3gpp.org/specs/latest/Rel-5/23_series/23221-570.zip > >Best Regards, > -Juha W.- > >-----Original Message----- >From: ext Margaret Wasserman [mailto:mrw@windriver.com] >Sent: 20 January, 2003 18:00 >To: BELOEIL Luc FTRD/DMI/CAE >Cc: Erik Nordmark; itojun@iijlab.net; v6ops@ops.ietf.org >Subject: RE: on NAT-PT > > >At 04:51 PM 1/20/2003 +0100, BELOEIL Luc FTRD/DMI/CAE wrote: > >Hi all, > > > > > > > > The proxy alternative may make sense for the 3GPP IMS case, as this > > > is a special case where only certain services are required to be > > > IPv6-only. IMS-capable handsets may still be capable of opening > > > IPv4 PDP contexts for communication with non-IMS IPv4 nodes and > > > services. > > > > >I've proposed that solution for months but it seems that current 3GPP > >specifications do not allow such a solution. > >My understanding is that the IMS subsystem is specified to be IPv6-only, >which will require that some services are only available on IPv6 (i.e. >the 3GPP version of SIP). This may also result in some parts of the >3GPP infrastructure (routers and equivalent) being IPv6-only. > >While a handset can be IMS-capable, I don't think that an IMS-capable >handset is required to be IPv6-only. An IMS handset could still be >capable of establishing IPv4 PDP contexts, and using IPv4 to access >the Internet and/or non-IMS 3GPP networks and services... > >Could someone correct me if I'm wrong, and please cite relevant parts >of the 3GPP standards? > >Margaret From owner-v6ops@ops.ietf.org Tue Jan 21 14:40:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10014 for ; Tue, 21 Jan 2003 14:40:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18b4Gq-000ETD-00 for v6ops-data@psg.com; Tue, 21 Jan 2003 11:41:16 -0800 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18b4Gm-000ET0-00 for v6ops@ops.ietf.org; Tue, 21 Jan 2003 11:41:13 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0LJf6Av021267; Tue, 21 Jan 2003 20:41:06 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 21 Jan 2003 20:41:06 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28852@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Margaret Wasserman'" , juha.wiljakka@nokia.com Cc: luc.beloeil@rd.francetelecom.com, Erik.Nordmark@sun.com, itojun@iijlab.net, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com Subject: RE: on NAT-PT Date: Tue, 21 Jan 2003 20:36:55 +0100 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=-0.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Margaret > I don't understand why the IMS being "exclusively IPv6" > would prevent two > IMS-capable UEs from opening IPv4 PDP contexts and > connecting to each other > for non-IMS services. I'm not even sure how you could > prevent this, as > an IMS-capable UE has no real way of knowing whether the > remote service > that it is trying to access is/isn't hosted on another > IMS-capable UE. > > It seems very likely that, regardless of the capabilities of > the handset, > some folks will want to use IPv4-only devices behind the > handset (IPv4-only > palm pilots, laptops, etc.) for some time. Even after IPv6 > is available on > most laptops, palm pilots, etc. they may still need/want to > run IPv4-only > applications. I can't understand how it would be in the > best interests of > 3GPP, IPv6 or anyone else to prevent two people who buy very high-end > IMS-capable phones from making an IPv4 connection between > their two phones > to run an IPv4-only application... You are correct, none of that is prevented. > >- The user has to activate an IPv6 PDP context to access IMS and > >registrate to the P-CSCF (i.e. registrate to the IMS SIP > server) using an > >IPv6 address. > > Right, this is clear. The IMS-capable UE will have to use > IPv6 to access > SIP and other IMS services. Correct. Of course your "other IMS services" could be anything. It could include web browsing for example (towards v4 or v6 sites). That's because you want to allow someone using IMS to also be able to run normal services on the same PDP Context. Opening another PDP Context for this is not a solution which can be mandated (more explaination below). > IMS connections to regular > Internet SIP services > (which may be IPv4-only) will be done through a proxy. So, > the IPv6 <-> IPv4 > conversion can also be handled by that proxy. The SIP proxy can handle SIP translation. However there also needs to be a translator to handle traffic (e.g. video streaming on UDP) translation. > Are there > other services that > are part of IMS that need to be proxied? There are other services that can be run over an IMS PDP Context which would require translation. If you open up an IPv6 PDP Context (IMS) you can only talk IPv6. I think that's now clear to all. However you may want to run other (non-SIP) v6 app.s on that same PDP Context without establishing another PDP Context. You're allowed to do that. It's better to use the same PDP Context because it takes longer to establish a 2nd PDP Context and it uses up more network resources than necessary. Say that the user opens app.x which is not widely used so that it doesn't make sense for the operator to deploy an app. proxy. This won't be the mainstream case which is a good thing, but it is still to be covered. In this case you have an IPv6 IMS PDP Context on which you run IMS IPv6 SIP app.s and "other v6" app.s. For the "other v6" app.s which are mainstream (e.g. http) you can use an app. proxy to talk to v4. However for the remaining v6 app.s you would need a NAT-PT to talk to v4. It's only for a limited amount of traffic, so it's not like the plan is to have millions of users sending all their data through the NAT-PT. The bottom line is that IMS is IPv6-only but it does not exclude other v6 applications. An IMS IPv6 PDP Context can carry IPv6 SIP and IPv6 non-SIP traffic but no IPv4 traffic. Since you cannot send IPv4 traffic, some of the IPv6 non-SIP traffic needs to go through a NAT-PT to talk to v4. Hope it makes more sense although it's not easy to explain. > As far as handsets go, I think it is fine that they have to > use IPv6 to > access IMS services, as those services are IPv6-only. As > long as they can > use IPv4 to access non-IMS services, I don't see where the > need for NAT-PT > comes in. If I'm running e.g. web browsing over an IPv6 IMS PDP Context (which has a good reason as mentioned above) my understanding is that you shouldn't use IPv4. The reason is the good old "IMS is IPv6-only" story. So there would be a need for some form of translation/app. proxying (dual-stack http proxy in this case). Other services which are not mainstream like http would require a translator such as a NAT-PT. You can also use a separate IPv4 PDP Context to access non-IMS services such as web browsing, but if the user already has an active IMS IPv6 PDP Context we can't and shouldn't prevent this other scenario which has its advantages as mentioned above. Rgds /Karim From owner-v6ops@ops.ietf.org Tue Jan 21 17:05:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13425 for ; Tue, 21 Jan 2003 17:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18b6Yz-000MA6-00 for v6ops-data@psg.com; Tue, 21 Jan 2003 14:08:09 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18b6Yv-000M7I-00 for v6ops@ops.ietf.org; Tue, 21 Jan 2003 14:08:05 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA25768; Tue, 21 Jan 2003 14:06:20 -0800 (PST) Message-Id: <5.1.0.14.2.20030121170052.029a8a68@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 Jan 2003 17:05:52 -0500 To: "Karim El-Malki (EAB)" From: Margaret Wasserman Subject: RE: on NAT-PT Cc: juha.wiljakka@nokia.com, luc.beloeil@rd.francetelecom.com, Erik.Nordmark@sun.com, itojun@iijlab.net, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28852@ESEALNT442.al.sw.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Karim, >There are other services that can be run over an IMS PDP Context which would >require translation. If you open up an IPv6 PDP Context (IMS) you can only >talk IPv6. I think that's now clear to all. However you may want to run >other (non-SIP) v6 app.s on that same PDP Context without establishing another >PDP Context. You're allowed to do that. It's better to use the same PDP >Context >because it takes longer to establish a 2nd PDP Context and it uses up more >network resources than necessary. Say that the user opens app.x which is not >widely used so that it doesn't make sense for the operator to deploy an >app. proxy. >This won't be the mainstream case which is a good thing, but it is still to >be covered. In this case you have an IPv6 IMS PDP Context on which you run >IMS IPv6 SIP app.s and "other v6" app.s. For the "other v6" app.s which are >mainstream (e.g. http) you can use an app. proxy to talk to v4. However >for the >remaining v6 app.s you would need a NAT-PT to talk to v4. Why would you run IPv6 apps to talk to IPv4? It would make much more sense to open an IPv4 PDP context to talk to a remote IPv4 host than to communicate over IPv6 with either proxies or translation. >It's only for a limited >amount of traffic, so it's not like the plan is to have millions of users >sending >all their data through the NAT-PT. The bottom line is that IMS is >IPv6-only but it >does not exclude other v6 applications. An IMS IPv6 PDP Context can carry >IPv6 SIP >and IPv6 non-SIP traffic but no IPv4 traffic. Since you cannot send IPv4 >traffic, >some of the IPv6 non-SIP traffic needs to go through a NAT-PT to talk to v4. >Hope it makes more sense although it's not easy to explain. No IPv6 PDP context can carry IPv4 traffic -- IMS PDP contexts are not special in this regard. To send IPv4 traffic, you need to open an IPv4 PDP context. >If I'm running e.g. web browsing over an IPv6 IMS PDP Context >(which has a good reason as mentioned above) my understanding is that you >shouldn't >use IPv4. The reason is the good old "IMS is IPv6-only" story. So there >would be >a need for some form of translation/app. proxying (dual-stack http proxy >in this case). >Other services which are not mainstream like http would require a translator >such as a NAT-PT. You can also use a separate IPv4 PDP Context to access >non-IMS >services such as web browsing, but if the user already has an active IMS IPv6 >PDP Context we can't and shouldn't prevent this other scenario which has its >advantages as mentioned above. I don't see any advantages that would outweigh the serious disadvantages of using NAT-PT... Why do you consider it such a problem to open an IPv4 PDP context to communicate to IPv4-only nodes and services? Margaret From owner-v6ops@ops.ietf.org Wed Jan 22 02:03: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 CAA27864 for ; Wed, 22 Jan 2003 02:03:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bEws-00035t-00 for v6ops-data@psg.com; Tue, 21 Jan 2003 23:05:22 -0800 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by psg.com with esmtp (Exim 3.36 #2) id 18bEwP-00031B-00 for v6ops@ops.ietf.org; Tue, 21 Jan 2003 23:05:19 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0M74VB25013 for ; Wed, 22 Jan 2003 01:04:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Jan 2003 01:04:23 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 23:03:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Tue, 21 Jan 2003 23:03:01 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEEBDBE7@mvebe001.americas.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcLBmYaNXgTvTu+LSMaVcJQ+cz9dJwARIiTw From: To: , Cc: , , , , X-OriginalArrivalTime: 22 Jan 2003 07:03:02.0852 (UTC) FILETIME=[4E33D840:01C2C1E4] X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA27864 Hi Margaret, > Why would you run IPv6 apps to talk to IPv4? It would make much more > sense to open an IPv4 PDP context to talk to a remote IPv4 > host than to > communicate over IPv6 with either proxies or translation. I believe I have explained this very thing on this very mailing list already a couple of times. However, repeating never hurts... ;) As said before (by Juha, and Karim, and myself) IMS is v6 only. This means that the only version of IP that can be used is the version 6. IMS consists of both the SIP signaling (SIP messages to the SIP proxies, and SIP servers), and the "media stream" either between two mobiles, or between a mobile and an IMS service. This media stream (according SIP specifications) can be virtually anything. Theoretically, you can signal with SIP a session of FTP between two nodes. In this case, the media stream would be the FTP session. The media stream is end-to-end - not hopping through proxies and servers like the SIP signaling. These two things combined it means that the IMS mobile has to be IPv6 only when it is using the IMS to set up a session (with another mobile, a fixed node, or a server). This means that no IPv4 is permitted in any form or another. (No, not even on top of v6 as then it is still v4, right?) > > >It's only for a limited > >amount of traffic, so it's not like the plan is to have > millions of users > >sending > >all their data through the NAT-PT. The bottom line is that IMS is > >IPv6-only but it > >does not exclude other v6 applications. An IMS IPv6 PDP > Context can carry > >IPv6 SIP > >and IPv6 non-SIP traffic but no IPv4 traffic. Since you > cannot send IPv4 > >traffic, > >some of the IPv6 non-SIP traffic needs to go through a > NAT-PT to talk to v4. > >Hope it makes more sense although it's not easy to explain. > > No IPv6 PDP context can carry IPv4 traffic -- IMS PDP > contexts are not special > in this regard. To send IPv4 traffic, you need to open an > IPv4 PDP context. > > >If I'm running e.g. web browsing over an IPv6 IMS PDP Context > >(which has a good reason as mentioned above) my > understanding is that you > >shouldn't > >use IPv4. The reason is the good old "IMS is IPv6-only" > story. So there > >would be > >a need for some form of translation/app. proxying > (dual-stack http proxy > >in this case). > >Other services which are not mainstream like http would > require a translator > >such as a NAT-PT. You can also use a separate IPv4 PDP > Context to access > >non-IMS > >services such as web browsing, but if the user already has > an active IMS IPv6 > >PDP Context we can't and shouldn't prevent this other > scenario which has its > >advantages as mentioned above. > > I don't see any advantages that would outweigh the serious > disadvantages > of using NAT-PT... Why do you consider it such a problem to > open an IPv4 > PDP context to communicate to IPv4-only nodes and services? > Let's assume for a second that what you say is true, and we start to use v4 with IMS as well. So, how would that work: If an IPv4 node is on the other side of the communication, the IMS mobile would get the non-IMS phone's IPv4 address in the SIP signaling. You say that the IMS mobile would then get an IPv4 address and submit that to the non-IMS phone via SIP. First, where is the IPv6 here? Secondly, what does this mean technically for the IMS phone? It means that there has to be an IPv4 stack on the phone in case this phone calls at some point of its life to somebody that has an IPv4 phone. Thus, as long as there is a single potential node in an IPv4 network that could be contacted, all the IMS phones in the world (new or old) have to have support for IPv4! Thirdly, there may or actually most probably will be NAT in the media path. This NAT can be either on the IMS phone's operator's network, or in the non-IMS phone's network. Most probably there will be NAT in both. The problem in v4 nat is that you don't know where it is! This means that this does not work in reality at all! OK, the next question is how does the IMS (or better the interworking unit on the border of IMS and IPv4 world) know there is need for NAT-PT in a session. It knows as all the IMS phones are IPv6, and if there comes an invite from the IPv4 side with an IPv4 address in the SDP. It then can understand that there is a need for IPv4/IPv6 translation. How this is done, you can check from the analysis document in detail. (I guess this mail is long enough anyways). After this I really have to conclude that NAT-PT (or actually a translator that is not NAT-PT but a subset of it) is lesser evil in dual-stack! It may be that for some applications, and for old software dual-stack may be a cleaner solution, though - but not in this case. Sorry about the long answer... Jonne. > Margaret > > > > From owner-v6ops@ops.ietf.org Wed Jan 22 04:40:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20420 for ; Wed, 22 Jan 2003 04:40:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bHP0-00095N-00 for v6ops-data@psg.com; Wed, 22 Jan 2003 01:42:34 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18bHOr-000958-00 for v6ops@ops.ietf.org; Wed, 22 Jan 2003 01:42:26 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0M9fdl31164; Wed, 22 Jan 2003 11:41:39 +0200 Date: Wed, 22 Jan 2003 11:41:38 +0200 (EET) From: Pekka Savola To: Jonne.Soininen@nokia.com cc: mrw@windriver.com, , , , , , Subject: RE: on NAT-PT In-Reply-To: <4D7B558499107545BB45044C63822DDEEBDBE7@mvebe001.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,SUPERLONG_LINE, USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, I think there is confusion here; let me try to clarify. IMS is IPv6-only. That's not up for debate. IMS will require some translation services (sounds like a case for ALG to me!) to access IPv4 services like VoIP (as these can't be ruled out, as I have suggested), using IMS-specific primitives. However, the issue I believe Margaret (and others) are trying to get to is, is translation (=NAT-PT) really required for _other_ services than the IPv6-only IMS. That is, say, web browsing on a 3GPP device. Or running IMAP to check mails. Connecting your laptop to the 3GPP device. Or whatever. For these, I believe, the answer is "no, you could get an IPv4 PDP context for them without problem and avoid translation". Right? On Tue, 21 Jan 2003 Jonne.Soininen@nokia.com wrote: > Hi Margaret, > > > Why would you run IPv6 apps to talk to IPv4? It would make much more > > sense to open an IPv4 PDP context to talk to a remote IPv4 > > host than to > > communicate over IPv6 with either proxies or translation. > > I believe I have explained this very thing on this very mailing list already a couple of times. However, repeating never hurts... ;) > As said before (by Juha, and Karim, and myself) IMS is v6 only. This means that the only version of IP that can be used is the version 6. IMS consists of both the SIP signaling (SIP messages to the SIP proxies, and SIP servers), and the "media stream" either between two mobiles, or between a mobile and an IMS service. This media stream (according SIP specifications) can be virtually anything. Theoretically, you can signal with SIP a session of FTP between two nodes. In this case, the media stream would be the FTP session. The media stream is end-to-end - not hopping through proxies and servers like the SIP signaling. > > These two things combined it means that the IMS mobile has to be IPv6 only when it is using the IMS to set up a session (with another mobile, a fixed node, or a server). This means that no IPv4 is permitted in any form or another. (No, not even on top of v6 as then it is still v4, right?) > > > > > >It's only for a limited > > >amount of traffic, so it's not like the plan is to have > > millions of users > > >sending > > >all their data through the NAT-PT. The bottom line is that IMS is > > >IPv6-only but it > > >does not exclude other v6 applications. An IMS IPv6 PDP > > Context can carry > > >IPv6 SIP > > >and IPv6 non-SIP traffic but no IPv4 traffic. Since you > > cannot send IPv4 > > >traffic, > > >some of the IPv6 non-SIP traffic needs to go through a > > NAT-PT to talk to v4. > > >Hope it makes more sense although it's not easy to explain. > > > > No IPv6 PDP context can carry IPv4 traffic -- IMS PDP > > contexts are not special > > in this regard. To send IPv4 traffic, you need to open an > > IPv4 PDP context. > > > > >If I'm running e.g. web browsing over an IPv6 IMS PDP Context > > >(which has a good reason as mentioned above) my > > understanding is that you > > >shouldn't > > >use IPv4. The reason is the good old "IMS is IPv6-only" > > story. So there > > >would be > > >a need for some form of translation/app. proxying > > (dual-stack http proxy > > >in this case). > > >Other services which are not mainstream like http would > > require a translator > > >such as a NAT-PT. You can also use a separate IPv4 PDP > > Context to access > > >non-IMS > > >services such as web browsing, but if the user already has > > an active IMS IPv6 > > >PDP Context we can't and shouldn't prevent this other > > scenario which has its > > >advantages as mentioned above. > > > > I don't see any advantages that would outweigh the serious > > disadvantages > > of using NAT-PT... Why do you consider it such a problem to > > open an IPv4 > > PDP context to communicate to IPv4-only nodes and services? > > > > Let's assume for a second that what you say is true, and we start to use v4 with IMS as well. So, how would that work: > > If an IPv4 node is on the other side of the communication, the IMS mobile would get the non-IMS phone's IPv4 address in the SIP signaling. You say that the IMS mobile would then get an IPv4 address and submit that to the non-IMS phone via SIP. First, where is the IPv6 here? > Secondly, what does this mean technically for the IMS phone? It means that there has to be an IPv4 stack on the phone in case this phone calls at some point of its life to somebody that has an IPv4 phone. Thus, as long as there is a single potential node in an IPv4 network that could be contacted, all the IMS phones in the world (new or old) have to have support for IPv4! > Thirdly, there may or actually most probably will be NAT in the media path. This NAT can be either on the IMS phone's operator's network, or in the non-IMS phone's network. Most probably there will be NAT in both. The problem in v4 nat is that you don't know where it is! This means that this does not work in reality at all! > > OK, the next question is how does the IMS (or better the interworking unit on the border of IMS and IPv4 world) know there is need for NAT-PT in a session. It knows as all the IMS phones are IPv6, and if there comes an invite from the IPv4 side with an IPv4 address in the SDP. It then can understand that there is a need for IPv4/IPv6 translation. How this is done, you can check from the analysis document in detail. (I guess this mail is long enough anyways). > > After this I really have to conclude that NAT-PT (or actually a translator that is not NAT-PT but a subset of it) is lesser evil in dual-stack! > > It may be that for some applications, and for old software dual-stack may be a cleaner solution, though - but not in this case. > > Sorry about the long answer... > > Jonne. > > > Margaret > > > > > > > > > -- 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 Jan 22 04: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 EAA20552 for ; Wed, 22 Jan 2003 04:48:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bHXh-0009JK-00 for v6ops-data@psg.com; Wed, 22 Jan 2003 01:51:33 -0800 Received: from p-mail1.rd.francetelecom.com ([193.49.124.31]) by psg.com with smtp (Exim 3.36 #2) id 18bHXd-0009IH-00 for v6ops@ops.ietf.org; Wed, 22 Jan 2003 01:51:29 -0800 Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Wed, 22 Jan 2003 10:51:07 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 10:50:44 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: on NAT-PT Date: Wed, 22 Jan 2003 10:50:43 +0100 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcLBmYaNXgTvTu+LSMaVcJQ+cz9dJwARIiTwAAWgzXA= From: "BELOEIL Luc FTRD/DMI/CAE" To: , , Cc: , , , X-OriginalArrivalTime: 22 Jan 2003 09:50:44.0135 (UTC) FILETIME=[BB31CB70:01C2C1FB] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA20552 Hi Jonne and all, > > Hi Margaret, > > > These two things combined it means that the IMS mobile has to > be IPv6 only when it is using the IMS to set up a session > (with another mobile, a fixed node, or a server). This means > that no IPv4 is permitted in any form or another. (No, not > even on top of v6 as then it is still v4, right?) > ... > > > > > > I don't see any advantages that would outweigh the serious > > disadvantages > > of using NAT-PT... Why do you consider it such a problem to > > open an IPv4 > > PDP context to communicate to IPv4-only nodes and services? > > > > Let's assume for a second that what you say is true, and we > start to use v4 with IMS as well. So, how would that work: > > If an IPv4 node is on the other side of the communication, > the IMS mobile would get the non-IMS phone's IPv4 address in > the SIP signaling. You say that the IMS mobile would then get > an IPv4 address and submit that to the non-IMS phone via SIP. > First, where is the IPv6 here? > Secondly, what does this mean technically for the IMS phone? > It means that there has to be an IPv4 stack on the phone in > case this phone calls at some point of its life to somebody > that has an IPv4 phone. Thus, as long as there is a single > potential node in an IPv4 network that could be contacted, > all the IMS phones in the world (new or old) have to have > support for IPv4! I do not share your point. The question to use IPv6-only or dual-stack phone does not concern technical issues but business issues. I have the feeling its an operator issue, and to use NAT-PT may be worse (see below). > Thirdly, there may or actually most probably will be NAT in > the media path. This NAT can be either on the IMS phone's > operator's network, or in the non-IMS phone's network. Most > probably there will be NAT in both. The problem in v4 nat is > that you don't know where it is! This means that this does > not work in reality at all! > It depends on the service architecture. If I follow your point I could say that with NAT-PT, we are likely to have NAT-PT (or "SIP proxy+ media translator") on the IMS phone's operator's network, NAT on network of mobile operator's ISP, and NAT in the other non-IMS terminal's network. ;+( > OK, the next question is how does the IMS (or better the > interworking unit on the border of IMS and IPv4 world) know > there is need for NAT-PT in a session. It knows as all the > IMS phones are IPv6, and if there comes an invite from the > IPv4 side with an IPv4 address in the SDP. It then can > understand that there is a need for IPv4/IPv6 translation. > How this is done, you can check from the analysis document in > detail. (I guess this mail is long enough anyways). > > After this I really have to conclude that NAT-PT (or actually > a translator that is not NAT-PT but a subset of it) is lesser > evil in dual-stack! > NAT-PT does not solve interconnections issues with IPv4 non-IMS networks. From an IPv4-only external network, a NAT/PAT+STUN or a NAT-PT or a "SIP-proxy + media translator" behave in the same way (address advertised are not those handled by terminals). > It may be that for some applications, and for old software > dual-stack may be a cleaner solution, though - but not in this case. > > Sorry about the long answer... > > Jonne. > > > Margaret > > From owner-v6ops@ops.ietf.org Wed Jan 22 09:26:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25535 for ; Wed, 22 Jan 2003 09:26:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bLrO-000H90-00 for v6ops-data@psg.com; Wed, 22 Jan 2003 06:28:10 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #2) id 18bLrM-000H8l-00 for v6ops@ops.ietf.org; Wed, 22 Jan 2003 06:28:08 -0800 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0MER6009131 for ; Wed, 22 Jan 2003 16:27:06 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Jan 2003 16:28:05 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 16:28:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Wed, 22 Jan 2003 16:28:03 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC36C1@esebe005.ntc.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcLB+npVIRTbQtDJQAKOqerXGKhBPgAJYXcg From: To: , Cc: , , , , , X-OriginalArrivalTime: 22 Jan 2003 14:28:04.0765 (UTC) FILETIME=[79C86CD0:01C2C222] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_02_03,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA25535 Hi, Pekka! (firstly, thanks Karim & Jonne for your detailed comments; I read them through and I don't have anything special to add to them at the moment.) What comes to non-IMS traffic / traffic not going through the IMS (i.e. like described in the GPRS scenario 1), IPv4 type of PDP contexts can be used. However, as I have previously commented, getting a public IPv4 address to the UE can be difficult. Using private IPv4 addresses means use of NATs when contacting a peer node in the public Internet. Cheers, -Juha W.- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 22 January, 2003 11:42 However, the issue I believe Margaret (and others) are trying to get to is, is translation (=NAT-PT) really required for _other_ services than the IPv6-only IMS. That is, say, web browsing on a 3GPP device. Or running IMAP to check mails. Connecting your laptop to the 3GPP device. Or whatever. For these, I believe, the answer is "no, you could get an IPv4 PDP context for them without problem and avoid translation". Right? From owner-v6ops@ops.ietf.org Wed Jan 22 09:32: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 JAA25693 for ; Wed, 22 Jan 2003 09:32:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bLz3-000HN8-00 for v6ops-data@psg.com; Wed, 22 Jan 2003 06:36:05 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18bLyy-000HMr-00 for v6ops@ops.ietf.org; Wed, 22 Jan 2003 06:36:00 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0MEZYw00463; Wed, 22 Jan 2003 16:35:34 +0200 Date: Wed, 22 Jan 2003 16:35:33 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: Jonne.Soininen@nokia.com, , , , , , Subject: RE: on NAT-PT In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC36C1@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 22 Jan 2003 juha.wiljakka@nokia.com wrote: > What comes to non-IMS traffic / traffic not going through the IMS (i.e. > like described in the GPRS scenario 1), IPv4 type of PDP contexts can be > used. However, as I have previously commented, getting a public IPv4 > address to the UE can be difficult. Using private IPv4 addresses means > use of NATs when contacting a peer node in the public Internet. Of course, but the situation is no worse than it currently is; if we want to make it better, the right solution is pushing for upgrading the end nodes you're connecting to and use IPv6. (I have argued this could be done for the IMS case too, but apparently the deployment base of IPv4 VoIP phones etc. which can't be upgraded is larger than I expected.) Pekka > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 22 January, 2003 11:42 > > However, the issue I believe Margaret (and others) are trying to get to > is, is translation (=NAT-PT) really required for _other_ services than the > IPv6-only IMS. > > That is, say, web browsing on a 3GPP device. Or running IMAP to check > mails. Connecting your laptop to the 3GPP device. Or whatever. > > For these, I believe, the answer is "no, you could get an IPv4 PDP context > for them without problem and avoid translation". Right? > -- 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 Jan 22 10:45: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 KAA28444 for ; Wed, 22 Jan 2003 10:45:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bN6m-000JgM-00 for v6ops-data@psg.com; Wed, 22 Jan 2003 07:48:08 -0800 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by psg.com with esmtp (Exim 3.36 #2) id 18bN67-000JfO-00 for v6ops@ops.ietf.org; Wed, 22 Jan 2003 07:47:58 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0MFlBB02113 for ; Wed, 22 Jan 2003 09:47:22 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Jan 2003 09:47:03 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Jan 2003 07:46:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Wed, 22 Jan 2003 07:46:12 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0175DBE5@mvebe001.americas.nokia.com> Thread-Topic: on NAT-PT Thread-Index: AcLCI4g7fYhrRjMXRxCi8wia80LdtAACTOYw From: To: , Cc: , , , , , X-OriginalArrivalTime: 22 Jan 2003 15:46:14.0106 (UTC) FILETIME=[64D913A0:01C2C22D] X-Spam-Status: No, hits=1.3 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28444 Hi Pekka, > Of course, but the situation is no worse than it currently > is; if we want > to make it better, the right solution is pushing for upgrading the end > nodes you're connecting to and use IPv6. > I certainly do think you are right! I think the IMS + translator case can be just a transition case to a limited number of IPv4 legacy nodes. > (I have argued this could be done for the IMS case too, but > apparently the > deployment base of IPv4 VoIP phones etc. which can't be > upgraded is larger > than I expected.) The priority number one is to get the end nodes upgraded to IPv6, and the interworking case would be used _only_ when really necessary. Cheers, Jonne. > Pekka > > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 22 January, 2003 11:42 > > > > However, the issue I believe Margaret (and others) are > trying to get to > > is, is translation (=NAT-PT) really required for _other_ > services than the > > IPv6-only IMS. > > > > That is, say, web browsing on a 3GPP device. Or running > IMAP to check > > mails. Connecting your laptop to the 3GPP device. Or whatever. > > > > For these, I believe, the answer is "no, you could get an > IPv4 PDP context > > for them without problem and avoid translation". Right? > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From owner-v6ops@ops.ietf.org Thu Jan 23 03:14: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 DAA29699 for ; Thu, 23 Jan 2003 03:14:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bcVg-000AMt-00 for v6ops-data@psg.com; Thu, 23 Jan 2003 00:14:52 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #2) id 18bcVe-000AMf-00 for v6ops@ops.ietf.org; Thu, 23 Jan 2003 00:14:51 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0N8H7t00471 for ; Thu, 23 Jan 2003 10:17:07 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Jan 2003 10:14:48 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 10:14:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 3GPP IPv6 transition analysis, revision -01 Date: Thu, 23 Jan 2003 10:14:46 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC36C6@esebe005.ntc.nokia.com> Thread-Topic: 3GPP IPv6 transition analysis, revision -01 Thread-Index: AcLCtBTvuYRxRBxUTlCk375Lh12NXQAAvGYQ From: To: X-OriginalArrivalTime: 23 Jan 2003 08:14:47.0046 (UTC) FILETIME=[7E1D7A60:01C2C2B7] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA29699 Hi all! A new revision of the 3GPP IPv6 transition analysis document has been published. It can be found here: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-01.txt The draft should now resolve questions / issues presented on the mailing list so far. Cheers, -Juha W.- From owner-v6ops@ops.ietf.org Thu Jan 23 03:59:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00677 for ; Thu, 23 Jan 2003 03:59:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bdFX-000Bh5-00 for v6ops-data@psg.com; Thu, 23 Jan 2003 01:02:15 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18bdFV-000Bgm-00 for v6ops@ops.ietf.org; Thu, 23 Jan 2003 01:02:13 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15634; Thu, 23 Jan 2003 02:02:07 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0N91lP10361; Thu, 23 Jan 2003 10:01:48 +0100 (MET) Date: Thu, 23 Jan 2003 09:58:17 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: on NAT-PT To: Margaret Wasserman Cc: Erik Nordmark , itojun@iijlab.net, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.0.14.2.20030120100030.025f8030@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > There are also other alternatives that would not require IPv4 > routing within the domain. For example, a dual stack host running > in an IPv6-only infrastructure could set-up an IPv4 in IPv6 tunnel to the > a dual-stack router on the edge of the IPv6-only network. The IPv4 address > for the dual-stack host could be dynamically allocated/leased, allowing a > large number of nodes that occasionally use IPv4 to share a smaller > number of IPv4 addresses. DSTM offers one example of this type of > mechanism. Yes, I think the ability to use DHCPv* to setup tunnels (that terminate within the same admin domain) is a useful tool, the same way that tunnel broker/TSP is a useful tool to setup tunnels that cross admin boundaries (where some authentication/sign-in is needed). I think that is the key essence of DSTM. But I'm not certain one can get much IPv4 address reuse by using short leases. It depends on the traffic pattern and type of applications folks use and since that is quite unpredictable the conservative thing would be to design for the worse case which I think means one IPv4 address per IPv6 address. Still, this could be combined with a v4NAT for sharing IPv4 addresses. I think this is lower complexity than NAT-PT/SIIT since it just piles boxes (or functions if folks want to implement them in the same box) after eachother with no interaction between them. Thus you'd have a box terminating the IPv4 in IPv6 tunnel, and after that a v4NAT. Thus you avoid running IPv4 except between the tunnel box and the v4NAT (and externally). Erik From owner-v6ops@ops.ietf.org Thu Jan 23 04:08:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00934 for ; Thu, 23 Jan 2003 04:08:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bdOc-000Bs2-00 for v6ops-data@psg.com; Thu, 23 Jan 2003 01:11:38 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #2) id 18bdOa-000Brp-00 for v6ops@ops.ietf.org; Thu, 23 Jan 2003 01:11:36 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21303; Thu, 23 Jan 2003 02:11:31 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0N9BNP11529; Thu, 23 Jan 2003 10:11:24 +0100 (MET) Date: Thu, 23 Jan 2003 10:07:54 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: on NAT-PT To: "Karim El-Malki (EAB)" Cc: "'Margaret Wasserman'" , juha.wiljakka@nokia.com, luc.beloeil@rd.francetelecom.com, Erik.Nordmark@sun.com, itojun@iijlab.net, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com In-Reply-To: "Your message with ID" <76E5F712842F5F49A35738622BAA0F4FA28852@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The SIP proxy can handle SIP translation. However there also needs to > be a translator to handle traffic (e.g. video streaming on UDP) translation. But as far as I understand this space (not very far at all) the box that handle the media streams need to be instructed by the SIP proxy for what mappings to create - it can't just be a plain old NAT-PT box. Thus it starts looking more like an UDP proxy for the purposes of carrying RTP which is controlled by the SIP proxy - not a NAT-PT which creates state based on the packets that fly by. Erik From owner-v6ops@ops.ietf.org Thu Jan 23 05:11: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 FAA02073 for ; Thu, 23 Jan 2003 05:11:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18beN7-000CzE-00 for v6ops-data@psg.com; Thu, 23 Jan 2003 02:14:10 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18beN5-000Cyp-00 for v6ops@ops.ietf.org; Thu, 23 Jan 2003 02:14:07 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA23284; Thu, 23 Jan 2003 02:12:09 -0800 (PST) Message-Id: <5.1.0.14.2.20030123044753.0325d6a8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 Jan 2003 05:11:44 -0500 To: Jonne.Soininen@nokia.com From: Margaret Wasserman Subject: RE: on NAT-PT Cc: , , , , , In-Reply-To: <4D7B558499107545BB45044C63822DDEEBDBE7@mvebe001.americas.n okia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jonne, Thanks for the response, but maybe I'm still not getting it... >I believe I have explained this very thing on this very mailing list >already a couple of times. However, repeating never hurts... ;) >As said before (by Juha, and Karim, and myself) IMS is v6 only. This means >that the only version of IP that can be used is the version 6. Alright, I am with you so far. IMS is IPv6 only. >IMS consists of both the SIP signaling (SIP messages to the SIP proxies, >and SIP servers), and the "media stream" either between two mobiles, or >between a mobile and an IMS service. This media stream (according SIP >specifications) can be virtually anything. Theoretically, you can signal >with SIP a session of FTP between two nodes. Okay, this is where we start to diverge. I understand that you can theoretically use SIP to signal anything. And, there may be reasons why someone would want to use IMS/SIP to signal an FTP session between two IMS-capable nodes (I can't think of one, but I'll take your word for it). But why would you ever want to use IMS/SIP to signal an FTP (or other) session between an IMS-capable node and a non-IMS-capable IPv4-only node? What makes you think that this would work? I don't think that most non-IMS nodes will be capable of having their FTP sessions signalled through SIP. >In this case, the media stream would be the FTP session. The media stream >is end-to-end - not hopping through proxies and servers like the SIP signaling. Right, but it is also possible to establish an IPv4 end-to-end session without IMS/SIP signalling, right? So, can you explain why anyone would want to use IMS/SIP signaling to establish an arbitrary application connection with an IPv4-only node? >These two things combined it means that the IMS mobile has to be IPv6 only >when it is using the IMS to set up a session (with another mobile, a fixed >node, or a server). This means that no IPv4 is permitted in any form or >another. (No, not even on top of v6 as then it is still v4, right?) This smacks of religion to me... Is there some technical reason why it wouldn't work to tunnel IPv4 in IPv6 over the IMS parts of the infrastructure? Or is this just dogma -- "No IPv4 Allowed!"? > > > > I don't see any advantages that would outweigh the serious > > disadvantages > > of using NAT-PT... Why do you consider it such a problem to > > open an IPv4 > > PDP context to communicate to IPv4-only nodes and services? > > > >Let's assume for a second that what you say is true, and we start to use >v4 with IMS as well. So, how would that work: I don't _think_ that I'm suggesting this. I'm suggesting that, when you need to set-up a session with a non-IMS, IPv4-only node or service, that you shouldn't use IMS. >If an IPv4 node is on the other side of the communication, the IMS mobile >would get the non-IMS phone's IPv4 address in the SIP signaling. You say >that the IMS mobile would then get an IPv4 address and submit that to the >non-IMS phone via SIP. First, where is the IPv6 here? Why do we need IPv6 here? For a dual-stack node to communicate with an IPv4-only node, no IPv6 is needed. >Secondly, what does this mean technically for the IMS phone? It means that >there has to be an IPv4 stack on the phone in case this phone calls at >some point of its life to somebody that has an IPv4 phone. Thus, as long >as there is a single potential node in an IPv4 network that could be >contacted, all the IMS phones in the world (new or old) have to have >support for IPv4! Well, yes. I am actually proposing that, for now at least, all phones should be dual-stack. Eventually, when the huge majority of nodes and services are available via IPv6, it might make sense to use NAT-PT (in the other direction) to allow IPv6 access to legacy IPv4 servers. But, in the meantime, I think that any node that wants to connect to both IPv4 and IPv6 nodes and services should be dual-stack. >Thirdly, there may or actually most probably will be NAT in the media >path. This NAT can be either on the IMS phone's operator's network, or in >the non-IMS phone's network. Most probably there will be NAT in both. The >problem in v4 nat is that you don't know where it is! This means that this >does not work in reality at all! In _reality_ IPv4 NAT works just fine for most purposes... I'm writing to you from behind one right now. That argument aside, however... I agree that an IPv4 network is quite likely to include NAT. This is one of several reasons why IPv6 is needed. However, declaring the IMS system IPv6-only will not change the fact that 3GPP providers will need to provide some sort of IPv4 services (perhaps native or perhaps via IPv4 over IPv6 tunnels), and that IPv4 network is likely to include NAT. In fact, in your example, you have replaced the IMS network NAT with NAT-PT (not necessarily an improvement) and haven't done anything that will remove the NAT from the non-IMS phone's network. So, there will still be two NATs in the path, and there will still be no way to know where they are. Why is it better that one of the NATs is NAT-PT? >After this I really have to conclude that NAT-PT (or actually a translator >that is not NAT-PT but a subset of it) is lesser evil in dual-stack! Maybe I'm missing something, but I still don't understand. How can it be better to end-up with an IPv6 <-> IPv4 translated session than to end-up with a native IPv4 session? >It may be that for some applications, and for old software dual-stack may >be a cleaner solution, though - but not in this case. Perhaps this is one of the places we are disconnecting. I tend to think of the 3G "phone" as a clever little modem that will allow my PC and PDA to connect to the Internet. And, my PC and PDA do run old software, for which dual-stack would be a cleaner solution... Margaret From owner-v6ops@ops.ietf.org Thu Jan 23 07:48:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04907 for ; Thu, 23 Jan 2003 07:48:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bgoA-000GGM-00 for v6ops-data@psg.com; Thu, 23 Jan 2003 04:50:14 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 18bgo8-000GGA-00 for v6ops@ops.ietf.org; Thu, 23 Jan 2003 04:50:12 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04768; Thu, 23 Jan 2003 07:46:43 -0500 (EST) Message-Id: <200301231246.HAA04768@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-01.txt Date: Thu, 23 Jan 2003 07:46:43 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** 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-01.txt Pages : 19 Date : 2003-1-22 This document analyzes making 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-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-3gpp-analysis-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-3gpp-analysis-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-1-22111455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-22111455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jan 23 09:01: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 JAA07887 for ; Thu, 23 Jan 2003 09:01:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bhwZ-000IW3-00 for v6ops-data@psg.com; Thu, 23 Jan 2003 06:02:59 -0800 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #2) id 18bhwU-000IVk-00 for v6ops@ops.ietf.org; Thu, 23 Jan 2003 06:02:55 -0800 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id h0NE2fKV015736; Thu, 23 Jan 2003 15:02:41 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 23 Jan 2003 15:02:38 +0100 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28857@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Erik Nordmark'" Cc: "'Margaret Wasserman'" , juha.wiljakka@nokia.com, luc.beloeil@rd.francetelecom.com, itojun@iijlab.net, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com Subject: RE: on NAT-PT Date: Thu, 23 Jan 2003 14:58:28 +0100 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=0.7 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > The SIP proxy can handle SIP translation. However there > also needs to > > be a translator to handle traffic (e.g. video streaming on > UDP) translation. > > But as far as I understand this space (not very far at all) > the box that handle the media streams need to be instructed > by the SIP proxy > for what mappings to create - it can't just be a plain old > NAT-PT box. > Thus it starts looking more like an UDP proxy for the > purposes of carrying > RTP which is controlled by the SIP proxy - not a NAT-PT which creates > state based on the packets that fly by. It could also involve transport protocols other than RTP/UDP. Wouldn't it be just a NAT-PT having the translator part and ALG part separated? The ALG would be in the SIP proxy and would return addresses to the ipv6 host of the form PREFIX::v4_addr where the PREFIX belongs to the chosen translator box. So you could load share over multiple translator boxes. The translator would still keep state. /Karim From owner-v6ops@ops.ietf.org Sat Jan 25 02:06:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20390 for ; Sat, 25 Jan 2003 02:06:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18cJkx-0000Rk-00 for v6ops-data@psg.com; Fri, 24 Jan 2003 22:25:31 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #2) id 18cJkj-0000RA-00 for v6ops@ops.ietf.org; Fri, 24 Jan 2003 22:25:17 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00934; Fri, 24 Jan 2003 23:24:23 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0P6OGP18461; Sat, 25 Jan 2003 07:24:16 +0100 (MET) Date: Sat, 25 Jan 2003 05:23:29 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: on NAT-PT To: "Karim El-Malki (EAB)" Cc: "'Erik Nordmark'" , "'Margaret Wasserman'" , juha.wiljakka@nokia.com, luc.beloeil@rd.francetelecom.com, itojun@iijlab.net, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com In-Reply-To: "Your message with ID" <76E5F712842F5F49A35738622BAA0F4FA28857@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > It could also involve transport protocols other than RTP/UDP. > Wouldn't it be just a NAT-PT having the translator part and ALG part > separated? The ALG would be in the SIP proxy and would return > addresses to the ipv6 host of the form PREFIX::v4_addr where the > PREFIX belongs to the chosen translator box. So you could load share > over multiple translator boxes. The translator would still keep state. I don't think (but again I'm not sure) that this is sufficient for SIP signalled media. The SIP proxy gets a request which contains some IP addresses and port numbers for the media. It needs to pass that along - perhaps replacing the IP addresses and port numbers in the process. This happens long before the media stream starts. This the SIP proxy needs to know what the IP address and port number mapping will be in the "NAT" before the SIP handshake completes. Thus this is not a NAT that creates state with IP/port mappings based on observing data packets - it is a box which creates this state based on interaction with the SIP proxy. In essence it becomes a slave of the SIP proxy. Does anybody on the list know enough about SIP to say whether the above makes or does not make sense? Of course, folks could build a single box with this functionality - NAT(-PT) - SIP proxy - SIP proxy controlled IP/port mapper but you can't just have an independent SIP proxy and NAT(-PT) box do this; significant interfaces would be needed between the SIP and NAT functionality. Hence NAT-PT by itself isn't useful here. Erik From owner-v6ops@ops.ietf.org Sat Jan 25 12:40: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 MAA26233 for ; Sat, 25 Jan 2003 12:40:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18cUIf-0003Ql-00 for v6ops-data@psg.com; Sat, 25 Jan 2003 09:41:01 -0800 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #2) id 18cUId-0003Po-00 for v6ops@ops.ietf.org; Sat, 25 Jan 2003 09:40:59 -0800 Received: from ssenthil-u5.cisco.com (ssenthil-u5.cisco.com [128.107.162.100]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0PHdnSR018506; Sat, 25 Jan 2003 09:39:49 -0800 (PST) Date: Sat, 25 Jan 2003 09:39:49 -0800 (PST) From: Senthil Sivakumar To: Erik Nordmark cc: "Karim El-Malki (EAB)" , "'Margaret Wasserman'" , , , , , Subject: RE: on NAT-PT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05, USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > The SIP proxy gets a request which contains some IP addresses and port numbers > for the media. It needs to pass that along - perhaps replacing the IP addresses > and port numbers in the process. This happens long before the media stream > starts. This the SIP proxy needs to know what the IP address and port number > mapping will be in the "NAT" before the SIP handshake completes. > > Thus this is not a NAT that creates state with IP/port mappings > based on observing data packets - it is a box which creates this state based > on interaction with the SIP proxy. In essence it becomes a slave of > the SIP proxy. My understanding is that if you have to seperate the SIP ALG functionality from the translator, the seperated box with the ALG will translate the SIP control messages as well the header. All the control messages will be directed to the translator which has the SIP ALG intelligence and all the media will go through the stateless translator, because the SIP ALG would have translated the media address in the payload with a different prefix which is the prefix of the translator. Senthil > > Does anybody on the list know enough about SIP to say whether the above > makes or does not make sense? > > Of course, folks could build a single box with this functionality > - NAT(-PT) > - SIP proxy > - SIP proxy controlled IP/port mapper > but you can't just have an independent SIP proxy and NAT(-PT) box do this; > significant interfaces would be needed between the SIP and NAT functionality. > > Hence NAT-PT by itself isn't useful here. > > Erik > > > From owner-v6ops@ops.ietf.org Mon Jan 27 02:33:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08883 for ; Mon, 27 Jan 2003 02:33:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18d3kd-0006XY-00 for v6ops-data@psg.com; Sun, 26 Jan 2003 23:32:15 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 18d3kZ-0006WS-00 for v6ops@ops.ietf.org; Sun, 26 Jan 2003 23:32:11 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 26 Jan 2003 23:32:09 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 26 Jan 2003 23:32:09 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 26 Jan 2003 23:32:10 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 26 Jan 2003 23:32:09 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Sun, 26 Jan 2003 23:32:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: on NAT-PT Date: Sun, 26 Jan 2003 23:32:07 -0800 Message-ID: Thread-Topic: on NAT-PT Thread-Index: AcLEqz/2qGyVlW+xQYGHN85AgPUxGwBKhwoU From: "Christian Huitema" To: "Senthil Sivakumar" , "Erik Nordmark" Cc: "Karim El-Malki \(EAB\)" , "Margaret Wasserman" , , , , , X-OriginalArrivalTime: 27 Jan 2003 07:32:08.0869 (UTC) FILETIME=[32F9A550:01C2C5D6] X-Spam-Status: No, hits=0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA08883 > Of course, folks could build a single box with this functionality > - NAT(-PT) > - SIP proxy > - SIP proxy controlled IP/port mapper > but you can't just have an independent SIP proxy and NAT(-PT) box do this; > significant interfaces would be needed between the SIP and NAT functionality. You could build such a box, but there are some well known limitations. Normally, SIP does not constraint the media flow to follow the same path as the signalling; forcing this single path can result in spectacularly poor performances in some scenarios, e.g. when calls are redirected, or when the proxy is "remote" -- as is the case today with most large instant messaging systems. Also, the rewriting that you describe imposes to rewrite the SDP payload of the SIP messages; if the SIP UA secure the payload with MIME security , this rewriting is impossible. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Jan 27 08:03: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 IAA14953 for ; Mon, 27 Jan 2003 08:03:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18d8vg-000GJC-00 for v6ops-data@psg.com; Mon, 27 Jan 2003 05:04:00 -0800 Received: from a80-126-101-63.adsl.xs4all.nl ([80.126.101.63] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18d8ve-000GIl-00 for v6ops@ops.ietf.org; Mon, 27 Jan 2003 05:03:59 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h0RD2fO17032 for v6ops@ops.ietf.org; Mon, 27 Jan 2003 14:02:41 +0100 (CET) Date: Mon, 27 Jan 2003 14:02:41 +0100 From: Ronald van der Pol To: v6ops@ops.ietf.org Subject: v6ops at San Francisco Message-ID: <20030127130241.GA16786@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.9 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Do we have an agenda for IETF 56 already? Is one time slot enough? In Atlanta many discussions were cut off. rvdp From owner-v6ops@ops.ietf.org Mon Jan 27 12:49:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20650 for ; Mon, 27 Jan 2003 12:49:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dDOf-0000rz-00 for v6ops-data@psg.com; Mon, 27 Jan 2003 09:50:13 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18dDOb-0000rm-00 for v6ops@ops.ietf.org; Mon, 27 Jan 2003 09:50:09 -0800 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09444 for ; Mon, 27 Jan 2003 10:50:08 -0700 (MST) Received: from xpa-fe2 (esunmail-ge1 [129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H9D003MNW7K75@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 27 Jan 2003 10:50:08 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H9D000XIW7J7C@mail.sun.net> for v6ops@ops.ietf.org; Mon, 27 Jan 2003 10:50:08 -0700 (MST) Date: Mon, 27 Jan 2003 09:50:06 -0800 From: Alain Durand Subject: Re: on NAT-PT To: Erik Nordmark Cc: "Karim El-Malki (EAB)" , "'Margaret Wasserman'" , juha.wiljakka@nokia.com, luc.beloeil@rd.francetelecom.com, itojun@iijlab.net, v6ops@ops.ietf.org, Jonne.Soininen@nokia.com Message-id: <3E35714E.8040908@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=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Erik Nordmark wrote: >>Thus this is not a NAT that creates state with IP/port mappings >>based on observing data packets - it is a box which creates this state based >>on interaction with the SIP proxy. In essence it becomes a slave of >>the SIP proxy. >> Yes. >> >>Does anybody on the list know enough about SIP to say whether the above >>makes or does not make sense? >> >>Of course, folks could build a single box with this functionality >> - NAT(-PT) >> - SIP proxy >> - SIP proxy controlled IP/port mapper >>but you can't just have an independent SIP proxy and NAT(-PT) box do this; >>significant interfaces would be needed between the SIP and NAT functionality. >> You can do that, but as Christian pointed out, this has severe limitations. >> >>Hence NAT-PT by itself isn't useful here. >> I would say that differently. NAT-PT by itself is not sufficient. If we want to go that route, we need a protocol to enable dialog between the SIP proxy and the NAT-PT boxes. Is there something in the MIDCOM space that could be used? - Alain. From owner-v6ops@ops.ietf.org Mon Jan 27 17:14:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28874 for ; Mon, 27 Jan 2003 17:14:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dHY0-000Bea-00 for v6ops-data@psg.com; Mon, 27 Jan 2003 14:16:08 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18dHXw-000BdA-00 for v6ops@ops.ietf.org; Mon, 27 Jan 2003 14:16:04 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA27921 for ; Mon, 27 Jan 2003 22:16:02 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h0RMFvAU019714 for ; Mon, 27 Jan 2003 22:15:58 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h0RMFv427158 for v6ops@ops.ietf.org; Mon, 27 Jan 2003 22:15:57 GMT Date: Mon, 27 Jan 2003 22:15:57 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: v6ops at San Francisco Message-ID: <20030127221557.GF27090@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20030127130241.GA16786@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030127130241.GA16786@rvdp.org> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At this formative time two sessions would seem appropriate. Tim On Mon, Jan 27, 2003 at 02:02:41PM +0100, Ronald van der Pol wrote: > Do we have an agenda for IETF 56 already? Is one time slot enough? > In Atlanta many discussions were cut off. > > rvdp From owner-v6ops@ops.ietf.org Tue Jan 28 16:10: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 QAA07646 for ; Tue, 28 Jan 2003 16:10:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dcyp-000BwC-00 for v6ops-data@psg.com; Tue, 28 Jan 2003 13:09:15 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18dcyk-000Bvs-00 for v6ops@ops.ietf.org; Tue, 28 Jan 2003 13:09:11 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18dcyj-0001jk-00 for v6ops@ops.ietf.org; Tue, 28 Jan 2003 13:09:09 -0800 Message-Id: <5.2.0.9.0.20030128083643.0202d588@mail.addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 28 Jan 2003 08:50:10 -0800 To: v6ops@ops.ietf.org From: Bob Fink Subject: agenda items for v6ops in San Francisco Cc: Margaret Wasserman , Jun-ichiro itojun Hagino , Bob Fink , Randy Bush X-Spam-Status: No, hits=0.6 required=5.0 tests=RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ 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. ] v6ops Folk, Here is a first cut of an agenda for the v6ops meeting in San Francisco. For now we are only scheduling one 2 1/2 hour session, but can request an additional one if warranted. 3G Analysis draft - Wiljakka, 10-20 mins UNMAN analysis draft - Huitema, 10-20 mins ISP Scenarios - Mickles, Enterprise Scenarios - 20-30 mins Enterprise Scenarios - Pouffary, 20-30 mins IPv4 Survey draft restructuring - Nesser or chairs, 10-20 mins Mech draft - Nordmark, 5-10 mins Please send suggestions for additional agenda items to the chairs and/or the list. Also, let me know if another presenter that listed will do the presenting. Thanks, Bob From owner-v6ops@ops.ietf.org Tue Jan 28 16:40: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 QAA08825 for ; Tue, 28 Jan 2003 16:40:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ddVW-000DTm-00 for v6ops-data@psg.com; Tue, 28 Jan 2003 13:43:02 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18ddVT-000DTY-00 for v6ops@ops.ietf.org; Tue, 28 Jan 2003 13:43:00 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h0SLgpb00635; Tue, 28 Jan 2003 23:42:51 +0200 Date: Tue, 28 Jan 2003 23:42:51 +0200 (EET) From: Pekka Savola To: Bob Fink cc: v6ops@ops.ietf.org, Margaret Wasserman , Jun-ichiro itojun Hagino , Randy Bush Subject: Re: agenda items for v6ops in San Francisco In-Reply-To: <5.2.0.9.0.20030128083643.0202d588@mail.addr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 28 Jan 2003, Bob Fink wrote: > v6ops Folk, > > Here is a first cut of an agenda for the v6ops meeting in San Francisco. > > For now we are only scheduling one 2 1/2 hour session, but can request an > additional one if warranted. > > > 3G Analysis draft - Wiljakka, 10-20 mins > > UNMAN analysis draft - Huitema, 10-20 mins > > ISP Scenarios - Mickles, Enterprise Scenarios - 20-30 mins > > Enterprise Scenarios - Pouffary, 20-30 mins > > IPv4 Survey draft restructuring - Nesser or chairs, 10-20 mins > > Mech draft - Nordmark, 5-10 mins > > > Please send suggestions for additional agenda items to the chairs and/or > the list. Also, let me know if another presenter that listed will do the > presenting. As a general note, I think we should try to discuss "transition architecture" in a more aggregated fashion: now it has spread all over the analysis documents (consider e.g. NAT/PT vs dual-stack etc.). One way trying to get some coherence here might be to try to have some discussion (like 10-20 mins) on some specific topics before (or after) the scenarios. -- 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 Jan 28 16:43: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 QAA08882 for ; Tue, 28 Jan 2003 16:43:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ddYl-000Dh5-00 for v6ops-data@psg.com; Tue, 28 Jan 2003 13:46:23 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18ddYi-000Dgs-00; Tue, 28 Jan 2003 13:46:21 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18ddYg-0001nQ-00; Tue, 28 Jan 2003 13:46:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: agenda items for v6ops in San Francisco References: <5.2.0.9.0.20030128083643.0202d588@mail.addr.com> Message-Id: Date: Tue, 28 Jan 2003 13:46:19 -0800 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > As a general note, I think we should try to discuss "transition > architecture" in a more aggregated fashion: now it has spread all over the > analysis documents (consider e.g. NAT/PT vs dual-stack etc.). > > One way trying to get some coherence here might be to try to have some > discussion (like 10-20 mins) on some specific topics before (or after) the > scenarios. this has some appeal. also, i think a generic discussion of they types of security issues raised by transition mechanisms might be worthwhile. i suspect that we would benefit from a common and consistent story for both of these. randy From owner-v6ops@ops.ietf.org Wed Jan 29 05:20: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 FAA14895 for ; Wed, 29 Jan 2003 05:20:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dpKr-000LjN-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 02:20:49 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18dpKo-000Lj8-00 for v6ops@ops.ietf.org; Wed, 29 Jan 2003 02:20:46 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0TAJvgG017062; Wed, 29 Jan 2003 11:19:59 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0TAJrPC134330; Wed, 29 Jan 2003 11:19:54 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51690 from ; Wed, 29 Jan 2003 11:19:50 +0100 Message-Id: <3E37AA9A.20B199B1@hursley.ibm.com> Date: Wed, 29 Jan 2003 11:19:06 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Randy Bush Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: agenda items for v6ops in San Francisco References: <5.2.0.9.0.20030128083643.0202d588@mail.addr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > > > As a general note, I think we should try to discuss "transition > > architecture" in a more aggregated fashion: now it has spread all over the > > analysis documents (consider e.g. NAT/PT vs dual-stack etc.). > > > > One way trying to get some coherence here might be to try to have some > > discussion (like 10-20 mins) on some specific topics before (or after) the > > scenarios. > > this has some appeal. also, i think a generic discussion of they types of > security issues raised by transition mechanisms might be worthwhile. i > suspect that we would benefit from a common and consistent story for both of > these. I'd say this argues for a second session. I don't see it fitting into anything like 20 minutes. Brian From owner-v6ops@ops.ietf.org Wed Jan 29 07:30:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17705 for ; Wed, 29 Jan 2003 07:29:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18drNo-000Ouv-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 04:32:00 -0800 Received: from a80-126-101-63.adsl.xs4all.nl ([80.126.101.63] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18drNm-000Oui-00 for v6ops@ops.ietf.org; Wed, 29 Jan 2003 04:31:58 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h0TCTFp04855; Wed, 29 Jan 2003 13:29:15 +0100 (CET) Date: Wed, 29 Jan 2003 13:29:15 +0100 From: Ronald van der Pol To: Pekka Savola Cc: Bob Fink , v6ops@ops.ietf.org, Margaret Wasserman , Jun-ichiro itojun Hagino , Randy Bush Subject: translation issues [was Re: agenda items for v6ops in San Francisco] Message-ID: <20030129122915.GC4735@rvdp.org> References: <5.2.0.9.0.20030128083643.0202d588@mail.addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jan 28, 2003 at 23:42:51 +0200, Pekka Savola wrote: > As a general note, I think we should try to discuss "transition > architecture" in a more aggregated fashion: now it has spread all over the > analysis documents (consider e.g. NAT/PT vs dual-stack etc.). We have tried to write down the issues involved in translating between IPv4 and IPv6, see: http://www.ietf.org/internet-drafts/\ draft-vanderpol-v6ops-translation-issues-00.txt Comments are welcome. rvdp From owner-v6ops@ops.ietf.org Wed Jan 29 12:40: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 MAA24322 for ; Wed, 29 Jan 2003 12:40:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dwCL-0008We-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 09:40:29 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18dwCI-0008WO-00 for v6ops@ops.ietf.org; Wed, 29 Jan 2003 09:40:26 -0800 Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03685 for ; Wed, 29 Jan 2003 10:40:25 -0700 (MST) Received: from xpa-fe2 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H9H00DOLL3B0Z@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 29 Jan 2003 10:40:25 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H9H00IVJL39FN@mail.sun.net> for v6ops@ops.ietf.org; Wed, 29 Jan 2003 10:40:23 -0700 (MST) Date: Wed, 29 Jan 2003 09:41:23 -0800 From: Alain Durand Subject: Re: translation issues [was Re: agenda items for v6ops in San Francisco] In-reply-to: <20030129122915.GC4735@rvdp.org> To: Ronald van der Pol Cc: Pekka Savola , Bob Fink , v6ops@ops.ietf.org, Margaret Wasserman , Jun-ichiro itojun Hagino , Randy Bush Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Most of the issues you mention are not exactly properties of NAT (or a NAT IPv6->IPv4), but properties of the DNS-ALG: - breaking DNSsec - getting unwanted translated address I've long argued that if you remove the DNS-ALG piece of the picture, things become simpler. I'm planing to write a document before the cut-off date to summarize the discussion Itojun & I had a little while back to compare a DNS-ALG solution to a well know prefix one. - Alain. On Wednesday, January 29, 2003, at 04:29 AM, Ronald van der Pol wrote: > On Tue, Jan 28, 2003 at 23:42:51 +0200, Pekka Savola wrote: > >> As a general note, I think we should try to discuss "transition >> architecture" in a more aggregated fashion: now it has spread all >> over the >> analysis documents (consider e.g. NAT/PT vs dual-stack etc.). > > We have tried to write down the issues involved in translating > between IPv4 and IPv6, see: > http://www.ietf.org/internet-drafts/\ > draft-vanderpol-v6ops-translation-issues-00.txt > > Comments are welcome. > > rvdp > From owner-v6ops@ops.ietf.org Wed Jan 29 15:06:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28160 for ; Wed, 29 Jan 2003 15:06:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dyVU-000Ej3-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 12:08:24 -0800 Received: from a80-126-101-63.adsl.xs4all.nl ([80.126.101.63] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18dyVR-000Eiq-00 for v6ops@ops.ietf.org; Wed, 29 Jan 2003 12:08:21 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h0TK82G00323; Wed, 29 Jan 2003 21:08:02 +0100 (CET) Date: Wed, 29 Jan 2003 21:08:02 +0100 From: Ronald van der Pol To: Alain Durand Cc: Ronald van der Pol , Pekka Savola , Bob Fink , v6ops@ops.ietf.org, Margaret Wasserman , Jun-ichiro itojun Hagino , Randy Bush Subject: Re: translation issues Message-ID: <20030129200802.GA253@rvdp.org> References: <20030129122915.GC4735@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jan 29, 2003 at 09:41:23 -0800, Alain Durand wrote: > Most of the issues you mention are not exactly properties of NAT > (or a NAT IPv6->IPv4), but properties of the DNS-ALG: > - breaking DNSsec > - getting unwanted translated address We tried to write down _all_ the issues involved with translation, including NAT, NAT-PT, NAPT-PT, DNS-ALG, etc. > I've long argued that if you remove the DNS-ALG piece of the picture, > things become simpler. > > I'm planing to write a document before the cut-off date to summarize the > discussion Itojun & I had a little while back to compare a DNS-ALG > solution to a well know prefix one. We intentionally refrained from suggesting solutions. We only wanted to write down the issues in an objective manner. Other drafts, like yours, should describe if we want/can solve all the issues. rvdp From owner-v6ops@ops.ietf.org Wed Jan 29 22:06:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06615 for ; Wed, 29 Jan 2003 22:06:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18e518-000A0B-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 19:05:30 -0800 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #1) id 18e515-0009zz-00 for v6ops@ops.ietf.org; Wed, 29 Jan 2003 19:05:28 -0800 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0U35a203598 for ; Wed, 29 Jan 2003 21:05:36 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Jan 2003 21:05:24 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 29 Jan 2003 19:04:58 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: agenda items for v6ops in San Francisco X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 29 Jan 2003 19:04:57 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEEBDBEE@mvebe001.americas.nokia.com> Thread-Topic: agenda items for v6ops in San Francisco Thread-Index: AcLHhE5Y8Tr4IHIgRri5JTK1XsNDkQAh1ecA From: To: , Cc: , X-OriginalArrivalTime: 30 Jan 2003 03:04:58.0677 (UTC) FILETIME=[5F79B650:01C2C80C] X-Spam-Status: No, hits=1.3 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA06615 > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Randy Bush wrote: > > > > > As a general note, I think we should try to discuss "transition > > > architecture" in a more aggregated fashion: now it has > spread all over the > > > analysis documents (consider e.g. NAT/PT vs dual-stack etc.). > > > > > > One way trying to get some coherence here might be to try > to have some > > > discussion (like 10-20 mins) on some specific topics > before (or after) the > > > scenarios. > > > > this has some appeal. also, i think a generic discussion > of they types of > > security issues raised by transition mechanisms might be > worthwhile. i > > suspect that we would benefit from a common and consistent > story for both of > > these. > > I'd say this argues for a second session. I don't see it fitting into > anything like 20 minutes. > > Brian I tend to agree with Brian. Could this be done somehow separately maybe some evening/morning/Sunday? Cheers, Jonne. From owner-v6ops@ops.ietf.org Wed Jan 29 22:38:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07429 for ; Wed, 29 Jan 2003 22:38:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18e5Zc-000BoS-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 19:41:08 -0800 Received: from roam.psg.com ([193.0.9.124]) by psg.com with esmtp (Exim 3.36 #1) id 18e5Za-000BoF-00; Wed, 29 Jan 2003 19:41:06 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18e5ZU-0002xQ-00; Wed, 29 Jan 2003 19:41:00 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jonne.Soininen@nokia.com Cc: v6ops@ops.ietf.org Subject: RE: agenda items for v6ops in San Francisco References: <4D7B558499107545BB45044C63822DDEEBDBEE@mvebe001.americas.nokia.com> Message-Id: Date: Wed, 29 Jan 2003 19:41:00 -0800 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> this has some appeal. also, i think a generic discussion of they types of >>> security issues raised by transition mechanisms might be worthwhile. i >>> suspect that we would benefit from a common and consistent story for both of >>> these. >> I'd say this argues for a second session. I don't see it fitting into >> anything like 20 minutes. > I tend to agree with Brian. Could this be done somehow separately maybe > some evening/morning/Sunday? given recent deep discussions of the widely disliked results of dealing with architectural and security issues late in the design and document process as opposed to early, i find a suggestion to 'bury' discussions of such considerations and keep right on hacking rather droll, to say the least. randy From owner-v6ops@ops.ietf.org Wed Jan 29 22:55: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 WAA07617 for ; Wed, 29 Jan 2003 22:55:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18e5qX-000ChZ-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 19:58:37 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18e5qT-000ChL-00 for v6ops@ops.ietf.org; Wed, 29 Jan 2003 19:58:33 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA25204; Wed, 29 Jan 2003 19:57:15 -0800 (PST) Message-Id: <5.1.0.14.2.20030129224646.02a98a78@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 Jan 2003 22:55:12 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: agenda items for v6ops in San Francisco Cc: Bob Fink , v6ops@ops.ietf.org, Jun-ichiro itojun Hagino , Randy Bush In-Reply-To: References: <5.2.0.9.0.20030128083643.0202d588@mail.addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, >As a general note, I think we should try to discuss "transition >architecture" in a more aggregated fashion: now it has spread all over the >analysis documents (consider e.g. NAT/PT vs dual-stack etc.). I agree. Now that we are starting to get somewhat stable analysis documents, I think it is time to start pulling this together and looking for commonality. Ultimately, the transitions mechanisms should reflect a consistent architecture -- we shouldn't end up with a custom toolkit for each environment... But, I think that using the "divide and conquer" approach has helped us understand the problems that our architecture needs to address, and that it will continue to do so. >One way trying to get some coherence here might be to try to have some >discussion (like 10-20 mins) on some specific topics before (or after) the >scenarios. This sounds really good... Did you have one or more specific topics in mind? I'd like to see some discussion of transition security, including your 6to4 security work. I also think that we might consider two general discussions: (1) Translation-related mechanisms, perhaps based on Ron's transition issues draft? (2) Tunneling-related mechanisms -- are there common issues in this space? Or, do folks think that there is a better way to organize this discussion. Bob, Itojun and I will discuss the time allotments for the agenda in more detail and decide whether to request a second slot ASAP. Margaret From owner-v6ops@ops.ietf.org Thu Jan 30 00:32: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 AAA09127 for ; Thu, 30 Jan 2003 00:32:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18e7L8-000HiR-00 for v6ops-data@psg.com; Wed, 29 Jan 2003 21:34:18 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18e7L6-000Hi7-00 for v6ops@ops.ietf.org; Wed, 29 Jan 2003 21:34:16 -0800 Received: from consulintel02 ([216.54.161.237]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Thu, 30 Jan 2003 06:35:13 +0100 Message-ID: <016e01c2c821$4f33b560$2300a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: "Margaret Wasserman" , "Jun-ichiro itojun Hagino" Cc: Subject: agenda items for SF ? ISPs document Date: Thu, 30 Jan 2003 00:34:47 -0500 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 216.54.161.237 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_03_05,USER_AGENT_OE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Margaret, Itojun, I'm not sure if we can work setting up the agenda of the next v6ops meeting in SF, while some of the design teams aren't progressing, and the editor is just putting together some of the comments received (after several months some times !), and not having any kind of discussion ... I really think we need some quick action on this. I'm not even sure this will be in time for the next IETF, but we can (should) try ... Now, trying to be constructive, I will propose that this document is split into several documents, with more focus, and the design team is re-designed in some way. For example, why not doing something like: - Core networks - Access networks - IXs - Management (it could be included in each of the documents) May be we want to be even more focused, considering different types of access networks in different documents. Obviously separating this means that probably we are going to repeat some text from one document to others, but it makes also the life easier for those ISPs that only deploy one technology, as they only need to read one document that only considers its own scenario. In any case, I really hope that you can take soon a decision about how to make this work progressing, and solving the issue of the actual editor ignoring how IETF works (in my point of view). I'm sorry to be so direct, but if we continue this trend we can have another "multi6" situation ;-) Hope it helps ! Regards, Jordi ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Thu Jan 30 10:43:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01851 for ; Thu, 30 Jan 2003 10:43:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eGrD-000AQx-00 for v6ops-data@psg.com; Thu, 30 Jan 2003 07:44:03 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18eGrA-000AQY-00 for v6ops@ops.ietf.org; Thu, 30 Jan 2003 07:44:01 -0800 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0UFkTs24333 for ; Thu, 30 Jan 2003 17:46:29 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Jan 2003 17:43:58 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 30 Jan 2003 17:43:58 +0200 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 30 Jan 2003 07:43:56 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: agenda items for v6ops in San Francisco X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 30 Jan 2003 07:43:55 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEEBDBF0@mvebe001.americas.nokia.com> Thread-Topic: agenda items for v6ops in San Francisco Thread-Index: AcLIEXNs9bgl6VolT0SobRAjuS9pkgAYlchg From: To: Cc: X-OriginalArrivalTime: 30 Jan 2003 15:43:56.0062 (UTC) FILETIME=[65DF3BE0:01C2C876] X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA01851 Hi Randy, I guess my last mail gave a wrong impression: I did not wish to have a closed meeting or anything. I just thought that a meeting that would be concentrated on this topic may be useful. I thought that it would be implicitly clear that the meeting would be open for everybody, and it would be published on the v6ops mailing list well ahead of time that everybody who is interested could participate. I guess, that it wasn't clear. Anyways, it was just a proposal... Cheers, Jonne. > -----Original Message----- > From: ext Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, January 29, 2003 7:41 PM > To: Soininen Jonne (NET/MtView) > Cc: v6ops@ops.ietf.org > Subject: RE: agenda items for v6ops in San Francisco > > > >>> this has some appeal. also, i think a generic discussion > of they types of > >>> security issues raised by transition mechanisms might be > worthwhile. i > >>> suspect that we would benefit from a common and > consistent story for both of > >>> these. > >> I'd say this argues for a second session. I don't see it > fitting into > >> anything like 20 minutes. > > I tend to agree with Brian. Could this be done somehow > separately maybe > > some evening/morning/Sunday? > > given recent deep discussions of the widely disliked results > of dealing with > architectural and security issues late in the design and > document process as > opposed to early, i find a suggestion to 'bury' discussions of such > considerations and keep right on hacking rather droll, to say > the least. > > randy > > From owner-v6ops@ops.ietf.org Fri Jan 31 13:16:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14360 for ; Fri, 31 Jan 2003 13:16:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18efir-000MIf-00 for v6ops-data@psg.com; Fri, 31 Jan 2003 10:17:05 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18efin-000MHy-00 for v6ops@ops.ietf.org; Fri, 31 Jan 2003 10:17:01 -0800 Received: from consulintel02 ([216.54.161.237]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Fri, 31 Jan 2003 19:18:04 +0100 Message-ID: <0a9a01c2c955$09b25340$2300a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , "Jun-ichiro itojun Hagino" , "Margaret Wasserman" Cc: References: Subject: Re: agenda items for SF ? ISPs document Date: Fri, 31 Jan 2003 13:17:31 -0500 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 216.54.161.237 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.2 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, In my opinion this is not the main problem we have with this document. The main problem is that you don't heard the people, you don't reply emails. It's not just me, I talked with more people with the same problem ! Not having discussion will not bring us a good document accepted by the majority of the WG. This is the main problem. Again, if the WG still believe that you continue with this work, that I'm not in favor because it proven not to be progressing in a good shape, I will accept it. I still believe we should sub-divide the document, may be not in the way I suggested, but in some way, and make more focus. In any case, whatever is the decision, I volunteer (again), to work on this, but FIRST we need a decision ! Regards, Jordi ----- Original Message ----- From: "MicklesCK" To: "Jun-ichiro itojun Hagino" ; "Margaret Wasserman" ; "JORDI PALET MARTINEZ" Cc: Sent: Friday, January 31, 2003 11:48 AM Subject: RE: agenda items for SF ? ISPs document > > Thanks for the comments. > > I think we saw early on that the scenario document was becoming rather > lengthy. We have to strike a balance with it being useful to ISPs > without making it difficult to use because there is too much > information. > > The purpose of this "scenario" draft is to lay out the "problem > set" which we are trying to solve in terms of the transition to > IPv6. If we think less information is needed to define the problem > we can continue to remove details. The goal is really to get to the > "analysis" document which will make recommendations of how ISPs can > transition their networks to IPv6. > > All the sections were added by the working group and we sought > authors to add content to the document. As of the interim > V6OPS meeting three additional sections were added by the > WG but only two authors came forward to author two of the > sections. We do not have an author for the datacenter > section. I propose we drop the additional datacenter > section since, as I pointed out at the interim meeting, there > would be overlap with the Enterprise draft. In any event, the > WG thought that overlap was OK and wanted to have the > additional section added to the ISP draft as well. > > If the WG wants to further subdivide the ISP draft then that > is our prerogative, but hopefully some willing volunteers will > step forward as well. > > Cleve... > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > > Behalf Of JORDI PALET MARTINEZ > > Sent: Thursday, January 30, 2003 12:35 AM > > To: Margaret Wasserman; Jun-ichiro itojun Hagino > > Cc: v6ops@ops.ietf.org > > Subject: agenda items for SF ? ISPs document > > > > > > Hi Margaret, Itojun, > > > > I'm not sure if we can work setting up the agenda of the next > > v6ops meeting in SF, while some of the design teams aren't > > progressing, and the editor is just putting together some of the > > comments received (after several months some times !), and not > > having any kind of discussion ... > > > > I really think we need some quick action on this. I'm not even > > sure this will be in time for the next IETF, but we can (should) try > > ... > > > > Now, trying to be constructive, I will propose that this document > > is split into several documents, with more focus, and the design > > team is re-designed in some way. > > > > For example, why not doing something like: > > - Core networks > > - Access networks > > - IXs > > - Management (it could be included in each of the documents) > > > > May be we want to be even more focused, considering different > > types of access networks in different documents. Obviously separating > > this means that probably we are going to repeat some text from > > one document to others, but it makes also the life easier for those > > ISPs that only deploy one technology, as they only need to read > > one document that only considers its own scenario. > > > > In any case, I really hope that you can take soon a decision > > about how to make this work progressing, and solving the issue of the > > actual editor ignoring how IETF works (in my point of view). I'm > > sorry to be so direct, but if we continue this trend we can have > > another "multi6" situation ;-) > > > > Hope it helps ! > > > > Regards, > > Jordi > > > > ********************************* > > Madrid 2003 Global IPv6 Summit > > 12-14 May 2003 - Pre-register at: > > http://www.ipv6-es.com > > Interested in participating or sponsoring ? > > Contact us at ipv6@consulintel.es > > > > > > > > > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Fri Jan 31 16:03:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18856 for ; Fri, 31 Jan 2003 16:03:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eiMS-0004t8-00 for v6ops-data@psg.com; Fri, 31 Jan 2003 13:06:08 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18eiMP-0004sr-00 for v6ops@ops.ietf.org; Fri, 31 Jan 2003 13:06:06 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18eiMO-0001Bg-00 for v6ops@ops.ietf.org; Fri, 31 Jan 2003 22:06:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit In-Reply-To: <016e01c2c821$4f33b560$2300a8c0@consulintel.es> From: "MicklesCK" To: "Jun-ichiro itojun Hagino" , "Margaret Wasserman" , "JORDI PALET MARTINEZ" Cc: Subject: RE: agenda items for SF ? ISPs document Date: Fri, 31 Jan 2003 11:48:12 -0500 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ 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. ] Thanks for the comments. I think we saw early on that the scenario document was becoming rather lengthy. We have to strike a balance with it being useful to ISPs without making it difficult to use because there is too much information. The purpose of this "scenario" draft is to lay out the "problem set" which we are trying to solve in terms of the transition to IPv6. If we think less information is needed to define the problem we can continue to remove details. The goal is really to get to the "analysis" document which will make recommendations of how ISPs can transition their networks to IPv6. All the sections were added by the working group and we sought authors to add content to the document. As of the interim V6OPS meeting three additional sections were added by the WG but only two authors came forward to author two of the sections. We do not have an author for the datacenter section. I propose we drop the additional datacenter section since, as I pointed out at the interim meeting, there would be overlap with the Enterprise draft. In any event, the WG thought that overlap was OK and wanted to have the additional section added to the ISP draft as well. If the WG wants to further subdivide the ISP draft then that is our prerogative, but hopefully some willing volunteers will step forward as well. Cleve... > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of JORDI PALET MARTINEZ > Sent: Thursday, January 30, 2003 12:35 AM > To: Margaret Wasserman; Jun-ichiro itojun Hagino > Cc: v6ops@ops.ietf.org > Subject: agenda items for SF ? ISPs document > > > Hi Margaret, Itojun, > > I'm not sure if we can work setting up the agenda of the next > v6ops meeting in SF, while some of the design teams aren't > progressing, and the editor is just putting together some of the > comments received (after several months some times !), and not > having any kind of discussion ... > > I really think we need some quick action on this. I'm not even > sure this will be in time for the next IETF, but we can (should) try > ... > > Now, trying to be constructive, I will propose that this document > is split into several documents, with more focus, and the design > team is re-designed in some way. > > For example, why not doing something like: > - Core networks > - Access networks > - IXs > - Management (it could be included in each of the documents) > > May be we want to be even more focused, considering different > types of access networks in different documents. Obviously separating > this means that probably we are going to repeat some text from > one document to others, but it makes also the life easier for those > ISPs that only deploy one technology, as they only need to read > one document that only considers its own scenario. > > In any case, I really hope that you can take soon a decision > about how to make this work progressing, and solving the issue of the > actual editor ignoring how IETF works (in my point of view). I'm > sorry to be so direct, but if we continue this trend we can have > another "multi6" situation ;-) > > Hope it helps ! > > Regards, > Jordi > > ********************************* > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Pre-register at: > http://www.ipv6-es.com > Interested in participating or sponsoring ? > Contact us at ipv6@consulintel.es > > > >