From owner-v6ops@ops.ietf.org Tue Jul 1 16:05: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 QAA14811 for ; Tue, 1 Jul 2003 16:05:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XRDc-000Apf-FD for v6ops-data@psg.com; Tue, 01 Jul 2003 19:55:12 +0000 Received: from [192.77.173.5] (helo=secundus.nysernet.org) by psg.com with esmtp (Exim 4.14) id 19XRDX-000ApG-1K for v6ops@ops.ietf.org; Tue, 01 Jul 2003 19:55:07 +0000 Received: from [199.109.32.35] (cookiemonster.nysernet.org [199.109.32.35]) by secundus.nysernet.org (Postfix) with ESMTP id 43B3E50343 for ; Tue, 1 Jul 2003 15:54:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: owens@secundus.nysernet.org Message-Id: Date: Tue, 1 Jul 2003 15:55:04 -0400 To: v6ops@ops.ietf.org From: Bill Owens Subject: Relative performance of IPv6 and IPv4 for current users Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk There's a small debate going on within the Apple IPv6 mailing list over whether it is wise to have an application prefer v6 connectivity, when it is available, over v4. The argument against preferring to use v6 runs along the lines of "most people have only v4 connectivity, and for those few that have v6, the performance of v4 is usually better". Although it is hardly a scientific way to conduct a survey, I'm curious what the members of this group think of that assertion. Personally, I find that my v6 connectivity is either just about as good as v4, or very much worse, and the difference is whether the other end is connected natively or through some variety of tunnel. But I don't have a good feel for what percentage of v6-accessible sites fall into each category. There is also a sub-argument about 6to4, and whether it is sensible to enable 6to4 with anycast relay support given the dearth of relay routers. There seems to be some agreement that in the abscence of a local v6 router, allowing the machine to configure itself as a 6to4 router without a relay is a reasonable compromise. I think that I can agree with that, if those v6 connection attempts which fail without the default route, do so rapidly enough to avoid delaying the eventual v4 connection. Would anyone with more 6to4 experience care to comment on that idea? Bill. From owner-v6ops@ops.ietf.org Tue Jul 1 18:01: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 SAA17798 for ; Tue, 1 Jul 2003 18:01:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XTAM-000HDP-5M for v6ops-data@psg.com; Tue, 01 Jul 2003 21:59:58 +0000 Received: from [203.146.155.28] (helo=fuchsia.home) by psg.com with esmtp (Exim 4.14) id 19XTAH-000HD3-6h for v6ops@ops.ietf.org; Tue, 01 Jul 2003 21:59:54 +0000 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h61Lvqlw013376; Wed, 2 Jul 2003 04:57:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h61Lsgs23934; Wed, 2 Jul 2003 04:54:47 +0700 (ICT) From: Robert Elz To: Bill Owens cc: v6ops@ops.ietf.org Subject: Re: Relative performance of IPv6 and IPv4 for current users In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 2003 04:54:42 +0700 Message-ID: <16841.1057096482@munnari.OZ.AU> X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Tue, 1 Jul 2003 15:55:04 -0400 From: Bill Owens Message-ID: | Personally, I find that my v6 connectivity is either just about as | good as v4, or very much worse, and the difference is whether the | other end is connected natively or through some variety of tunnel. I don't see that distinction, perhaps because tunnels count for almost all of the IPv6 I do. It depends which performance is counted - I find that IPv6 connectivity tends to work more reliably than IPv4 most of the time (but that may just be that most people advertising IPv6 make sure it works most of the time, whereas IPv4 is just everybody, some conscientious, others not. On straight bandwidth type of performance (byte per second) it varies day to day - my IPv6 and IPv4 travel over different paths, sometimes one is more congested, other times the other is. But, the real issue, for most people, is that IPv6 by-passes NAT, and IPv4 doesn't. That's the one that matters, and for that reason alone I'd always take IPv6 in preference to IPv4 any day, regardless of how much slower it seemed. kre From owner-v6ops@ops.ietf.org Tue Jul 1 19:40: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 TAA20731 for ; Tue, 1 Jul 2003 19:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XUi0-000M4j-F4 for v6ops-data@psg.com; Tue, 01 Jul 2003 23:38:48 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19XUhp-000M4M-9l for v6ops@ops.ietf.org; Tue, 01 Jul 2003 23:38:37 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19XUho-0006W1-TN for v6ops@ops.ietf.org; Tue, 01 Jul 2003 16:38:37 -0700 Message-ID: <20030701210428.GA48752@salmon.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Date: Tue, 1 Jul 2003 22:04:28 +0100 From: David Malone To: Bill Owens Cc: v6ops@ops.ietf.org Subject: Re: Relative performance of IPv6 and IPv4 for current users X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ 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. ] On Tue, Jul 01, 2003 at 03:55:04PM -0400, Bill Owens wrote: > Although it is hardly a scientific way to conduct a survey, I'm > curious what the members of this group think of that assertion. If you're interested in another random data point, my IPv6 connectivity is about the same as IPv4 at home and at work, as the ISPs provide either native connectivity or connectivity via tunnels, and both ISPs peer at the local IXP. During the SQL-slammer my IPv6 connectivity was significantly better than IPv4 ;-) > There is also a sub-argument about 6to4, and whether it is sensible > to enable 6to4 with anycast relay support given the dearth of relay > routers. I really wonder if there is a dearth of 6to4 relay routers. My work and home ISPs both have relay routers. When I use 6to4 with other Irish ISPs I see the traffic going to several different relays (I think I've seen two distinct ones on Germany and Switch in Switzerland). David. From owner-v6ops@ops.ietf.org Tue Jul 1 21:30: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 VAA23999 for ; Tue, 1 Jul 2003 21:30:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XWQr-0001J2-5q for v6ops-data@psg.com; Wed, 02 Jul 2003 01:29:13 +0000 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by psg.com with esmtp (Exim 4.14) id 19XWQo-0001Gy-KC for v6ops@ops.ietf.org; Wed, 02 Jul 2003 01:29:10 +0000 Received: from pec.etri.re.kr (mkshin.etri.re.kr [129.254.112.163]) by pec.etri.re.kr (8.11.3/8.11.3) with ESMTP id h621fs916421 for ; Wed, 2 Jul 2003 10:41:54 +0900 (KST) Message-ID: <3F02378A.EA89871B@pec.etri.re.kr> Date: Wed, 02 Jul 2003 10:38:18 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: draft-shin-v6ops-application-transition-01.txt Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_20,RCVD_IN_RFCI version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, v6ops folks, We've updated the draft on Application Aspects of IPv6 Transition. http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-01.txt I think there is a lot of support for proceeding with the IP version-independent application development guidelines in the draft. In order to acheive this, section "Application porting considerations" and "Developing IP version-independent applications" are newly added. As well, Eva was joined in author team. We wait for your comments. Thanks, Myung-Ki. From owner-v6ops@ops.ietf.org Wed Jul 2 03:58: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 DAA27700 for ; Wed, 2 Jul 2003 03:58:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XcTU-000Gsf-Ar for v6ops-data@psg.com; Wed, 02 Jul 2003 07:56:20 +0000 Received: from [209.228.32.139] (helo=c001.snv.cp.net) by psg.com with smtp (Exim 4.14) id 19XcTR-000GsS-L5 for v6ops@ops.ietf.org; Wed, 02 Jul 2003 07:56:17 +0000 Received: (cpmta 4701 invoked from network); 2 Jul 2003 00:56:16 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 2 Jul 2003 00:56:16 -0700 X-Sent: 2 Jul 2003 07:56:16 GMT Message-ID: <004001c3406f$67c9ece0$03051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: Relative performance of IPv6 and IPv4 for current users Date: Wed, 2 Jul 2003 10:56:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_20,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just out of curiosity, have the fixed that little problem in the MAC OS where opening the printer selection window results in a ping every 30 seconds to all possible printers out there? It was a problem in the old Mac OS, and if it is still there then you could be sending out trillions of IMP pings every 30 seconds, this is almost as good as Quake for killing a network. ----- Original Message ----- From: "Bill Owens" To: Sent: Tuesday, July 01, 2003 10:55 PM Subject: Relative performance of IPv6 and IPv4 for current users > There's a small debate going on within the Apple IPv6 mailing list > over whether it is wise to have an application prefer v6 > connectivity, when it is available, over v4. The argument against > preferring to use v6 runs along the lines of "most people have only > v4 connectivity, and for those few that have v6, the performance of > v4 is usually better". > > Although it is hardly a scientific way to conduct a survey, I'm > curious what the members of this group think of that assertion. > Personally, I find that my v6 connectivity is either just about as > good as v4, or very much worse, and the difference is whether the > other end is connected natively or through some variety of tunnel. > But I don't have a good feel for what percentage of v6-accessible > sites fall into each category. > > There is also a sub-argument about 6to4, and whether it is sensible > to enable 6to4 with anycast relay support given the dearth of relay > routers. There seems to be some agreement that in the abscence of a > local v6 router, allowing the machine to configure itself as a 6to4 > router without a relay is a reasonable compromise. I think that I can > agree with that, if those v6 connection attempts which fail without > the default route, do so rapidly enough to avoid delaying the > eventual v4 connection. Would anyone with more 6to4 experience care > to comment on that idea? > > Bill. > From owner-v6ops@ops.ietf.org Wed Jul 2 04:48: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 EAA28726 for ; Wed, 2 Jul 2003 04:48:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XdHL-000It2-2X for v6ops-data@psg.com; Wed, 02 Jul 2003 08:47:51 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.14) id 19XdHI-000IsI-1X for v6ops@ops.ietf.org; Wed, 02 Jul 2003 08:47:48 +0000 Received: (qmail 97672 invoked by uid 2502); 2 Jul 2003 08:47:16 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.156417 secs); 02/07/2003 09:47:15 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Jul 2003 08:47:15 -0000 Date: Wed, 2 Jul 2003 09:47:15 +0100 (WEST) From: Carlos Friacas To: David Malone cc: Bill Owens , Subject: Re: Relative performance of IPv6 and IPv4 for current users In-Reply-To: <20030701210428.GA48752@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 1 Jul 2003, David Malone wrote: > > There is also a sub-argument about 6to4, and whether it is sensible > > to enable 6to4 with anycast relay support given the dearth of relay > > routers. > > I really wonder if there is a dearth of 6to4 relay routers. My work > and home ISPs both have relay routers. When I use 6to4 with other > Irish ISPs I see the traffic going to several different relays (I > think I've seen two distinct ones on Germany and Switch in Switzerland). Try: whois -h whois.ripe.net 192.88.99.0 | grep origin :-) > David. Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!" From owner-v6ops@ops.ietf.org Wed Jul 2 05:24: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 FAA29506 for ; Wed, 2 Jul 2003 05:24:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xdpl-000KO5-9I for v6ops-data@psg.com; Wed, 02 Jul 2003 09:23:25 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19Xdpi-000KNh-HZ for v6ops@ops.ietf.org; Wed, 02 Jul 2003 09:23:22 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA12930 for ; Wed, 2 Jul 2003 10:23:21 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id KAA20124 for ; Wed, 2 Jul 2003 10:23:20 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h629NKQ11523 for v6ops@ops.ietf.org; Wed, 2 Jul 2003 10:23:20 +0100 Date: Wed, 2 Jul 2003 10:23:20 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Relative performance of IPv6 and IPv4 for current users Message-ID: <20030702092320.GC10922@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20030701210428.GA48752@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030701210428.GA48752@salmon.maths.tcd.ie> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 01, 2003 at 10:04:28PM +0100, David Malone wrote: > > > There is also a sub-argument about 6to4, and whether it is sensible > > to enable 6to4 with anycast relay support given the dearth of relay > > routers. > > I really wonder if there is a dearth of 6to4 relay routers. My work > and home ISPs both have relay routers. When I use 6to4 with other > Irish ISPs I see the traffic going to several different relays (I > think I've seen two distinct ones on Germany and Switch in Switzerland). Many networks have 6to4 relays that they do not advertise outside their own network... so "dearth" is a visibility issue also... Tim From owner-v6ops@ops.ietf.org Wed Jul 2 10:40: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 KAA24991 for ; Wed, 2 Jul 2003 10:40:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xik1-0008fB-1b for v6ops-data@psg.com; Wed, 02 Jul 2003 14:37:49 +0000 Received: from [171.68.223.137] (helo=sj-core-3.cisco.com) by psg.com with esmtp (Exim 4.14) id 19Xijx-0008eS-6m for v6ops@ops.ietf.org; Wed, 02 Jul 2003 14:37:45 +0000 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h62Eb5ve024966; Wed, 2 Jul 2003 07:37:08 -0700 (PDT) Date: Wed, 2 Jul 2003 09:37:04 -0500 (Central Daylight Time) From: "Craig A. Huegen" To: Bill Owens cc: v6ops@ops.ietf.org Subject: Re: Relative performance of IPv6 and IPv4 for current users In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 1 Jul 2003, Bill Owens wrote: > There's a small debate going on within the Apple IPv6 mailing list > over whether it is wise to have an application prefer v6 > connectivity, when it is available, over v4. The argument against Anecdotal case: about a year ago I was downloading BIND 9 from ftp.isc.org. I typed "ftp ftp.isc.org"; it wasn't obvious, but my machine used the IPv6 address. I couldn't understand why the transfer was only getting roughly 1 KB/sec. I used "ping" and "traceroute" and things looked just fine. It wasn't until I scrolled up and saw "entering extended passive mode" that I finally realized the performance problem -- I was using IPv6. A resulting traceroute6 showed my routing from my home to Cisco to Japan back to ISC. Being the enterprise network control freak that I am, I would really like a standardized ability to prefer IPv4 over IPv6 until we feel comfortable that IPv6 reachability and performance of the topology is up to par with the IPv4 network. I'm sure we'll do fine, but I imagine we'll have a number of cases where we're asked to figure out performance problems and will end up realizing it's because IPv6 was used over IPv4. /cah -- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-v6ops@ops.ietf.org Wed Jul 2 12:43: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 MAA00726 for ; Wed, 2 Jul 2003 12:43:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xkg9-000F1b-R2 for v6ops-data@psg.com; Wed, 02 Jul 2003 16:41:57 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19Xkg6-000F0U-Gc for v6ops@ops.ietf.org; Wed, 02 Jul 2003 16:41:54 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19Xkg6-0005Xm-4J for v6ops@ops.ietf.org; Wed, 02 Jul 2003 09:41:54 -0700 Message-ID: <20030702163911.GA29807@walton.maths.tcd.ie> References: <20030701210428.GA48752@salmon.maths.tcd.ie> <20030702092320.GC10922@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030702092320.GC10922@login.ecs.soton.ac.uk> Date: Wed, 2 Jul 2003 17:39:11 +0100 From: David Malone To: v6ops@ops.ietf.org Cc: davew@heanet.ie Subject: Re: Relative performance of IPv6 and IPv4 for current users X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ 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. ] On Wed, Jul 02, 2003 at 10:23:20AM +0100, Tim Chown wrote: > > I really wonder if there is a dearth of 6to4 relay routers. My work > > and home ISPs both have relay routers. When I use 6to4 with other > > Irish ISPs I see the traffic going to several different relays (I > > think I've seen two distinct ones on Germany and Switch in Switzerland). > > Many networks have 6to4 relays that they do not advertise outside their > own network... so "dearth" is a visibility issue also... If anyone is interested, I had a go at counting 6to4 relay routers from the IPv6 side. I did this by tracerout6ing with a 6to4 source address and then using tcpdump to catch the IPv4 addresses of relay-routers that was used to encapsulate the replies. To decide where to traceroute to, I used the ::1 addresses of each prefix in the IPv6 BGP table (as seen from HEAnet this morning). After doing this, I got replies encapsulated 26 different source IPv4 addresses. One was the anycast address and I had a go at guessing the countries of the remainder (AU:1 CZ:1 DE:1 FI:1 IE:1 JP:1 KR:3 LT:2 NL:3 NO:1 PT:1 SE:2 TH:1 TW:1 UK:2 US:3). About 1/4 of the response packets came from the 6to4 anycast address, so it seems to be worth trying to figure out how many relays it represents. Looking at the histogram of TTLs in the IPv4 header, it looks like there are at least 3 or 4. To try to get a better idea, I tracerout6ed to a 6to4 address using a routing header to get the packet to first go to nodes that had had replies encapsulated with the anycast address. The second last hop of these traceroutes should help identify the 6to4 relay. This produced 27 IPv6 addresses, but sevral of them looked like they were assigned to the same machine. Looking at the /32s that these IPv6 addresses are in suggests that there are actually about 12 distinct relays in this group. Looking them up in whois shows that two of the /32s are in switch, so we're probably looking at 11 (CH:1 DE:3 EE:1 FI:1 IE:1 JP:1 NL:1 UK:1 US:1). In total, that's about 33, if you take into account a possible overlap of 2 or 3. [Naturally, I may have missed lots of relays that aren't visable from the route to the ::1 address within a prefix...] David. From owner-v6ops@ops.ietf.org Wed Jul 2 13:06: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 NAA01982 for ; Wed, 2 Jul 2003 13:06:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Xl3P-000Giv-Ro for v6ops-data@psg.com; Wed, 02 Jul 2003 17:05:59 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19Xl3N-000GfE-CN for v6ops@ops.ietf.org; Wed, 02 Jul 2003 17:05:57 +0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h62H5DfU002249; Wed, 2 Jul 2003 10:05:14 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h62H5D27026678; Wed, 2 Jul 2003 13:05:13 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h62H5DH2006301; Wed, 2 Jul 2003 13:05:13 -0400 (EDT) Message-Id: <200307021705.h62H5DH2006301@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: "Craig A. Huegen" cc: Bill Owens , v6ops@ops.ietf.org From: Sebastien Roy Subject: Re: Relative performance of IPv6 and IPv4 for current users In-Reply-To: Message from "Craig A. Huegen" of "Wed, 02 Jul 2003 09:37:04 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 2003 13:05:12 -0400 X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk chuegen@cisco.com said: > Being the enterprise network control freak that I am, I would really > like a standardized ability to prefer IPv4 over IPv6 until we feel > comfortable that IPv6 reachability and performance of the topology > is up to par with the IPv4 network. There is a way to do this if the OS implements rfc3484's policy table. You can change the precedence of IPv4 addresses in this table to accomplish this. It's is described in section 10.3 of rfc3484. > I'm sure we'll do fine, but I > imagine we'll have a number of cases where we're asked to figure out > performance problems and will end up realizing it's because IPv6 was > used over IPv4. Interestingly, my colleagues and I published a draft on "Dual Stack IPv6 on by Default" (draft-roy-v6ops-v6onbydefault-00.txt) that touches upon this briefly. Version 01 of this draft was submitted last weekend, so it should show up in the directory any day now. -Seb From owner-v6ops@ops.ietf.org Wed Jul 2 18:14: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 SAA24762 for ; Wed, 2 Jul 2003 18:14:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19XppS-0009bN-MP for v6ops-data@psg.com; Wed, 02 Jul 2003 22:11:54 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Xpoh-0009Yw-0Q for v6ops@ops.ietf.org; Wed, 02 Jul 2003 22:11:07 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23924; Wed, 2 Jul 2003 18:11:02 -0400 (EDT) Message-Id: <200307022211.SAA23924@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-apps-01.txt Date: Wed, 02 Jul 2003 18:11:02 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-apps-01.txt Pages : 69 Date : 2003-7-2 The transition from an all IPv4 network to an all IPv6 network requires several interim steps, being one of them the evolution of current IPv4 dependent protocols to protocols that are independent of the type of IP addresses used. Hence, it is hoped that protocols will be redesigned and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards - Full, Draft, and Proposed - and Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-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-ipv4survey-apps-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-ipv4survey-apps-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-7-2181855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-apps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2181855.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 3 11: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 LAA17053 for ; Thu, 3 Jul 2003 11:33:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y63e-0006ut-43 for v6ops-data@psg.com; Thu, 03 Jul 2003 15:31:38 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Y63K-0006u2-DT for v6ops@ops.ietf.org; Thu, 03 Jul 2003 15:31:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16424; Thu, 3 Jul 2003 11:31:13 -0400 (EDT) Message-Id: <200307031531.LAA16424@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-trans-01.txt Date: Thu, 03 Jul 2003 11:31:13 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-trans-01.txt Pages : 0 Date : 2003-7-3 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area 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-trans-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-ipv4survey-trans-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-ipv4survey-trans-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-7-3112059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-trans-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112059.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 3 11:33: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 LAA17095 for ; Thu, 3 Jul 2003 11:33:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y63J-0006u7-DW for v6ops-data@psg.com; Thu, 03 Jul 2003 15:31:17 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Y63D-0006sx-St for v6ops@ops.ietf.org; Thu, 03 Jul 2003 15:31:12 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16390; Thu, 3 Jul 2003 11:31:08 -0400 (EDT) Message-Id: <200307031531.LAA16390@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-subip-01.txt Date: Thu, 03 Jul 2003 11:31:08 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-subip-01.txt Pages : 0 Date : 2003-7-3 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area 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-subip-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-ipv4survey-subip-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-ipv4survey-subip-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-7-3112050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-subip-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112050.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 3 11:33:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17132 for ; Thu, 3 Jul 2003 11:33:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y62w-0006qv-8l for v6ops-data@psg.com; Thu, 03 Jul 2003 15:30:54 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Y62p-0006qM-Vl for v6ops@ops.ietf.org; Thu, 03 Jul 2003 15:30:48 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16217; Thu, 3 Jul 2003 11:30:45 -0400 (EDT) Message-Id: <200307031530.LAA16217@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-int-01.txt Date: Thu, 03 Jul 2003 11:30:44 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Internet Area: Survey of IPv4 Addresses Currently Deployed Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-int-01.txt Pages : 53 Date : 2003-7-3 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area 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-int-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-ipv4survey-int-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-ipv4survey-int-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-7-3112002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-int-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-int-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112002.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 3 11:33: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 LAA17300 for ; Thu, 3 Jul 2003 11:33:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y638-0006rf-71 for v6ops-data@psg.com; Thu, 03 Jul 2003 15:31:06 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Y630-0006r4-13 for v6ops@ops.ietf.org; Thu, 03 Jul 2003 15:30:58 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16268; Thu, 3 Jul 2003 11:30:55 -0400 (EDT) Message-Id: <200307031530.LAA16268@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-ops-01.txt Date: Thu, 03 Jul 2003 11:30:54 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-ops-01.txt Pages : 0 Date : 2003-7-3 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Operations & Management Area 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-ops-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-ipv4survey-ops-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-ipv4survey-ops-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-7-3112021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-ops-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112021.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 3 11:33:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17318 for ; Thu, 3 Jul 2003 11:33:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y63G-0006tn-Ry for v6ops-data@psg.com; Thu, 03 Jul 2003 15:31:14 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Y62y-0006qy-UU for v6ops@ops.ietf.org; Thu, 03 Jul 2003 15:30:57 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16252; Thu, 3 Jul 2003 11:30:50 -0400 (EDT) Message-Id: <200307031530.LAA16252@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-intro-01.txt Date: Thu, 03 Jul 2003 11:30:50 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-intro-01.txt Pages : 0 Date : 2003-7-3 This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in currently deployed IETF documented standards. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which type of RFCs that has been documented, and a concatenated summary of results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-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-ipv4survey-intro-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-ipv4survey-intro-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-7-3112012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112012.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 3 11:34: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 LAA17365 for ; Thu, 3 Jul 2003 11:34:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y63l-0006vK-J3 for v6ops-data@psg.com; Thu, 03 Jul 2003 15:31:45 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Y639-0006ry-Ru for v6ops@ops.ietf.org; Thu, 03 Jul 2003 15:31:10 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16363; Thu, 3 Jul 2003 11:31:04 -0400 (EDT) Message-Id: <200307031531.LAA16363@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-sec-01.txt Date: Thu, 03 Jul 2003 11:31:04 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-sec-01.txt Pages : 0 Date : 2003-7-3 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area 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 Sandards (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-sec-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-ipv4survey-sec-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-ipv4survey-sec-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-7-3112041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-sec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112041.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Jul 3 11:34: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 LAA17386 for ; Thu, 3 Jul 2003 11:34:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Y63B-0006s7-1A for v6ops-data@psg.com; Thu, 03 Jul 2003 15:31:09 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.14) id 19Y634-0006rM-U8 for v6ops@ops.ietf.org; Thu, 03 Jul 2003 15:31:03 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16317; Thu, 3 Jul 2003 11:30:59 -0400 (EDT) Message-Id: <200307031530.LAA16317@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-routing-01.txt Date: Thu, 03 Jul 2003 11:30:59 -0400 X-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_10,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-routing-01.txt Pages : 21 Date : 2003-7-3 This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area 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-routing-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-ipv4survey-routing-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-ipv4survey-routing-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-7-3112031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-routing-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3112031.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Jul 4 04:32: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 EAA20409 for ; Fri, 4 Jul 2003 04:32:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YLwL-0005jf-Qk for v6ops-data@psg.com; Fri, 04 Jul 2003 08:29:09 +0000 Received: from [195.101.245.16] (helo=p-mail2) by psg.com with esmtp (Exim 4.14) id 19YLwI-0005jG-TH for v6ops@ops.ietf.org; Fri, 04 Jul 2003 08:29:07 +0000 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Jul 2003 10:28:28 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: drafty IPv6 security overview draft submitted Date: Fri, 4 Jul 2003 10:28:22 +0200 Message-ID: Thread-Topic: drafty IPv6 security overview draft submitted Thread-Index: AcM3BwxEMtgtsR4tShaHKFhU1dkNeACkWUugAhqfsvA= From: "BELOEIL Luc FTRD/DMI/CAE" To: "Pekka Savola" Cc: , "BAUDOT Alain FTRD/DMI/CAE" X-OriginalArrivalTime: 04 Jul 2003 08:28:28.0031 (UTC) FILETIME=[3E6158F0:01C34206] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all,=20 I took a look at your paper a few weeks ago, but did not take time to answer. I do think that such a paper is really usefull! I have no comment on the structure only on the ideas... - Section 2 Increased end-to-end Transparency: I do think that is really important, most of entreprise network managers I meet are really concerned about that point ! - Section 5 : IPv6 Service Piloting Done Insecurely I did not understand your point about personal firewall and entreprise firewall when you write that those firewalls "are often expected to also become IPv6-capable (even tough this is not really necessary)". Could you explain ? - Section 9 : Operational Factors Your point concerning "IPv6 processing may not happen at (near) line speed ..." does not concern security but availability ? Or do you have in mind DoS attack ? my 0,02 % Luc -----Message d'origine----- De : BAUDOT Alain FTRD/DMI/CAE=20 Envoye : lundi 23 juin 2003 17:29 A : Pekka Savola; v6ops@ops.ietf.org Objet : RE: drafty IPv6 security overview draft submitted Hi Pekka, I think it is very valuable to point out such concrete and operational issues, one may face thinking about how to deploy IPv6 securely and safely (without disrupting existing services), as well. =20 It seems actually that there 3 types of issues : issues due to the protocol itself, issues due to transition/co-existence tools, and issues due to the deployement that may be adopted. And I guess each type of issue should have specic kind of answer. Regards, Alain. > -----Message d'origine----- > De : Pekka Savola [mailto:pekkas@netcore.fi] > Envoye : vendredi 20 juin 2003 10:33 > A : v6ops@ops.ietf.org > Objet : drafty IPv6 security overview draft submitted >=20 >=20 > Hello all, >=20 > I just submitted a draft on IPv6 security overview. It's quite raw=20 > and badly structured, but I ran out of time (and I'm off for a few=20 > days, back on Wednesday or so). >=20 > I've tried to describe at least briefly all the aspects=20 > relating to IPv6=20 > and IPv6 transition/co-existence I could quickly think of. =20 > This could be=20 > one basis for the security discussion in Vienna. >=20 > Please have a look at it at some point and send feedback. >=20 > Prior to it being formally posted, it can be read from: >=20 > http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security- overview-00.txt Abstract The transition/co-existance from IPv4 to IPv4/IPv6 causes one to consider the security considerations of such a process. In this memo, I try to give an overview of different aspects relating to IPv6: the notion of increased end-to-end transparency, implications of tunneling, the use of IPv4-mapped addresses, the considerations of IPv6 service piloting without firewalls, IPv6 protocol-specific issues, IPv6 transition/co-existence mechanism -specific issues, consequences of enabling IPv6 by default, and operational security issues when enabling IPv6 in the network infrastructure. It's only about 8 pages or so :-) --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 4 08:04: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 IAA24431 for ; Fri, 4 Jul 2003 08:04:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YPHR-000GKp-0M for v6ops-data@psg.com; Fri, 04 Jul 2003 12:03:09 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19YPHN-000GKA-L1 for v6ops@ops.ietf.org; Fri, 04 Jul 2003 12:03:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h64C32i12938; Fri, 4 Jul 2003 15:03:02 +0300 Date: Fri, 4 Jul 2003 15:03:01 +0300 (EEST) From: Pekka Savola To: BELOEIL Luc FTRD/DMI/CAE cc: v6ops@ops.ietf.org, BAUDOT Alain FTRD/DMI/CAE Subject: RE: drafty IPv6 security overview draft submitted In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for your comments. On Fri, 4 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > - Section 5 : IPv6 Service Piloting Done Insecurely > > I did not understand your point about personal firewall and entreprise > firewall when you write that those firewalls "are often expected to also > become IPv6-capable (even tough this is not really necessary)". Could > you explain ? Sorry, I left out too much text apparently. The point is that IPv4 access can go through one firewall, and IPv6 access through some other firewall. They don't need to be one and the same, and neither does their software need to be the same. > - Section 9 : Operational Factors > > Your point concerning "IPv6 processing may not happen at (near) line > speed ..." does not concern security but availability ? Or do you have > in mind DoS attack ? Yes, this is more of an availability issue (which is part of security). It can also be used as a DoS attack. The bottom line is, if people don't feel confident enough in the IPv6 support, they really can't enable it (especially in the dual-stack networks, where IPv4 is "production"). -- 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 Jul 4 08:05: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 IAA24447 for ; Fri, 4 Jul 2003 08:05:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YPJd-000GVI-9b for v6ops-data@psg.com; Fri, 04 Jul 2003 12:05:25 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19YPJa-000GU6-Q1 for v6ops@ops.ietf.org; Fri, 04 Jul 2003 12:05:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h64C5KU12953; Fri, 4 Jul 2003 15:05:20 +0300 Date: Fri, 4 Jul 2003 15:05:19 +0300 (EEST) From: Pekka Savola To: BAUDOT Alain FTRD/DMI/CAE cc: v6ops@ops.ietf.org Subject: RE: drafty IPv6 security overview draft submitted In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (sorry for delay..) On Mon, 23 Jun 2003, BAUDOT Alain FTRD/DMI/CAE wrote: > I think it is very valuable to point out such concrete and operational > issues, one may face thinking about how to deploy IPv6 securely and > safely (without disrupting existing services), as well. > > It seems actually that there 3 types of issues : issues due to the > protocol itself, issues due to transition/co-existence tools, and issues > due to the deployement that may be adopted. And I guess each type of > issue should have specic kind of answer. I agree that this characterization seems reasonable. It's sometimes difficult to draw the line, especially between the first two, though. > > -----Message d'origine----- > > De : Pekka Savola [mailto:pekkas@netcore.fi] > > Envoye : vendredi 20 juin 2003 10:33 > > A : v6ops@ops.ietf.org > > Objet : drafty IPv6 security overview draft submitted > > > > > > Hello all, > > > > I just submitted a draft on IPv6 security overview. It's quite raw > > and badly structured, but I ran out of time (and I'm off for a few > > days, back on Wednesday or so). > > > > I've tried to describe at least briefly all the aspects > > relating to IPv6 > > and IPv6 transition/co-existence I could quickly think of. > > This could be > > one basis for the security discussion in Vienna. > > > > Please have a look at it at some point and send feedback. > > > > Prior to it being formally posted, it can be read from: > > > > http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security- > overview-00.txt > > Abstract > > The transition/co-existance from IPv4 to IPv4/IPv6 causes one to > consider the security considerations of such a process. In this > memo, I try to give an overview of different aspects relating to > IPv6: the notion of increased end-to-end transparency, implications > of tunneling, the use of IPv4-mapped addresses, the considerations of > IPv6 service piloting without firewalls, IPv6 protocol-specific > issues, IPv6 transition/co-existence mechanism -specific issues, > consequences of enabling IPv6 by default, and operational security > issues when enabling IPv6 in the network infrastructure. > > > It's only about 8 pages or so :-) > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Jul 4 08:16: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 IAA24554 for ; Fri, 4 Jul 2003 08:16:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19YPTx-000HGC-2Y for v6ops-data@psg.com; Fri, 04 Jul 2003 12:16:05 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19YPTs-000HFb-RU for v6ops@ops.ietf.org; Fri, 04 Jul 2003 12:16:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h64CFpG13021; Fri, 4 Jul 2003 15:15:52 +0300 Date: Fri, 4 Jul 2003 15:15:51 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: drafty IPv6 security overview draft submitted In-Reply-To: <3EF3973A.7080208@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for comments. Sorry for not being to answer right away.. On Fri, 20 Jun 2003, Alain Durand wrote: > A couple points: > 1- You do not talk about the tunneling/open relay issues, > like the abuse of 6to4. those were discussed elsewhere, > but I think it would be worth it mentionning them here. The reason why I left them out (mostly: I only said that transition mechanism security has to be considered, in general) is that I don't want to try to tackle the same issue many more times. In this particular case (6to4), I think it has been rather well documented. Did you have some others in mind? Of course, it might be a good idea to try to add some kind of summary of the discussion here, or some brief words at least. Only, I'm not sure if there is an agreement on how to summarize it (at least yet). > 2- I came across an interesinting issue when playing with VPN: > I use an IPv4 VPN to connect to my office network. > My DNS resolution is done over IPv4. > When I'm looking for my server, the DNS (over IPv4 over VPN) > returns both A and AAAA records. When my laptop is on an IPv6 > enable link, it will use IPv6 to try to connec to my server. > However, the VPN does not know about IPv6, and it let the packets > go on the local network. Anybody on the > local link can intercept those packets by pretending to have the IPv6 > address of my server (thanks to neighbor discovery, it does not even > have to compromise any router...). > This may be a bug in my VPN, bit I wonder how many VPNs share > the same behavior... I think this stems from even a bigger issue about Neighbor Discovery. Consider an IPv6-enabled node in any network at all, where IPv6 routers don't exist, and a transition mechanism isn't available (there are a *plenty* of those). The same attack is still possible. This stems from the ND principle of assuming all destinations are on-link unless you know otherwise. This has caused problems in the past too. I personally don't think this is a big issue as such, as in IPv6 protocol suite there is an assumption that your link is relatively secure. But it might make sense to bring it up explicitly so folks don't forget about it. It might make sense to kickstart some effort (this and potential issues unearthed in the v6-on-by-default come to kind) to record the issues encountered in Neighbor Discovery specs (as those are bound to be revised soonish). Thanks. > Pekka Savola wrote: > > >Hello all, > > > >I just submitted a draft on IPv6 security overview. It's quite raw > >and badly structured, but I ran out of time (and I'm off for a few > >days, back on Wednesday or so). > > > >I've tried to describe at least briefly all the aspects relating to IPv6 > >and IPv6 transition/co-existence I could quickly think of. This could be > >one basis for the security discussion in Vienna. > > > >Please have a look at it at some point and send feedback. > > > >Prior to it being formally posted, it can be read from: > > > >http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-security-overview-00.txt > > > >Abstract > > > > The transition/co-existance from IPv4 to IPv4/IPv6 causes one to > > consider the security considerations of such a process. In this > > memo, I try to give an overview of different aspects relating to > > IPv6: the notion of increased end-to-end transparency, implications > > of tunneling, the use of IPv4-mapped addresses, the considerations of > > IPv6 service piloting without firewalls, IPv6 protocol-specific > > issues, IPv6 transition/co-existence mechanism -specific issues, > > consequences of enabling IPv6 by default, and operational security > > issues when enabling IPv6 in the network infrastructure. > > > > > >It's only about 8 pages or so :-) > > > > > > > > > -- 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 Jul 7 19:57: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 TAA22050 for ; Mon, 7 Jul 2003 19:57:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19Zfkj-0002KX-3r for v6ops-data@psg.com; Mon, 07 Jul 2003 23:50:37 +0000 Received: from [63.99.114.4] (helo=TNEXVS01.tahoenetworks.com) by psg.com with esmtp (Exim 4.14) id 19Zfkg-0002KL-7x for v6ops@ops.ietf.org; Mon, 07 Jul 2003 23:50:34 +0000 Received: from TNEXVS02.tahoenetworks.com ([10.10.1.132]) by TNEXVS01.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 16:50:33 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C344E2.8E1E2B1C" Subject: Use of 6to4 anycast address. Date: Mon, 7 Jul 2003 16:50:33 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A490@TNEXVS02.tahoenetworks.com> Thread-Topic: Use of 6to4 anycast address. Thread-Index: AcNE4o2FNZyC6BjnQ1yZrLM8lV4pEg== From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 07 Jul 2003 23:50:33.0617 (UTC) FILETIME=[8E3D1010:01C344E2] X-Spam-Status: No, hits=1.6 required=5.0 tests=HTML_20_30 version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C344E2.8E1E2B1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I am curious on what the implementations on the relay routers do, when = encapsulating packets using 6to4 anycast address (192.88.99.1) ? At least there is the issue = of fragmentation at the IPv4 level where when multiple relay router is sending packets to the = same 6to4 router, the 6to4 router may not be able to properly reassemble as the same fragment id = could be used by both relay routers. I saw some discussion in = draft-savola-v6ops-6to4-security-01.txt which recommends that relay routers should use 192.88.99.1. Not sure what implementations = do. Does the 6to4=20 router implementations verify to make sure that the source address used = is 192.88.99.1 in this case ? -mohan ------_=_NextPart_001_01C344E2.8E1E2B1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Use of 6to4 anycast address.

Hi,

I am curious on what the = implementations on the relay routers do, when encapsulating = packets
using 6to4 anycast address = (192.88.99.1) ? At least there is the issue of fragmentation at = the
IPv4 level where when multiple relay = router is sending packets to the same 6to4 router, the 6to4
router may not be able to properly = reassemble as the same fragment id could be used by both
relay routers. I saw some discussion = in draft-savola-v6ops-6to4-security-01.txt which recommends
that relay routers should use = 192.88.99.1. Not sure what implementations do. Does the 6to4
router implementations verify to make = sure that the source address used is 192.88.99.1 in this case ?

-mohan


------_=_NextPart_001_01C344E2.8E1E2B1C-- From owner-v6ops@ops.ietf.org Tue Jul 8 02:13: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 CAA10469 for ; Tue, 8 Jul 2003 02:13:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZlfS-000ICD-OB for v6ops-data@psg.com; Tue, 08 Jul 2003 06:09:34 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19ZlfP-000IC0-Bv for v6ops@ops.ietf.org; Tue, 08 Jul 2003 06:09:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h68690m22336; Tue, 8 Jul 2003 09:09:00 +0300 Date: Tue, 8 Jul 2003 09:09:00 +0300 (EEST) From: Pekka Savola To: Mohan Parthasarathy cc: v6ops@ops.ietf.org Subject: Re: Use of 6to4 anycast address. In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A490@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.2 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 7 Jul 2003, Mohan Parthasarathy wrote: > I am curious on what the implementations on the relay routers do, when > encapsulating packets using 6to4 anycast address (192.88.99.1) ? At > least there is the issue of fragmentation at the IPv4 level where when > multiple relay router is sending packets to the same 6to4 router, the > 6to4 router may not be able to properly reassemble as the same fragment > id could be used by both relay routers. I saw some discussion in > draft-savola-v6ops-6to4-security-01.txt which recommends that relay > routers should use 192.88.99.1. Not sure what implementations do. Does > the 6to4 router implementations verify to make sure that the source > address used is 192.88.99.1 in this case ? To be clear, one of the previous versions of draft-savola-v6ops-6to4-security stated that all relays using 192.88.99.1 might be beneficial. I don't think this is the common practice, though. It seems to me that the crux of this issue is whether the relay uses 192.88.99.1 as the source address (when 192.88.99.1 is otherwise used), or one of its other addresses. I've seen relays act both ways. From the above, I'm not sure if the problem you're describing is a serious one or not. AFAICS, it would require that the fragmentation ID's would collide while defragmenting. Typically, packets causing defragmentation arrive only some milliseconds apart, and the probability of collision in that window seems rather small (but possible, of course). This could be considered just one source of L2 errors from IPv6 protocol perspective. Has anyone collected statistics or analyzed this in detail to see whether this is a big issue or not? -- 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 Jul 8 12:45: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 MAA00074 for ; Tue, 8 Jul 2003 12:45:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ZvYi-000Cel-Ry for v6ops-data@psg.com; Tue, 08 Jul 2003 16:43:16 +0000 Received: from [209.249.147.28] (helo=proxy1.addr.com) by psg.com with esmtp (Exim 4.14) id 19ZvYg-000CdX-5B for v6ops@ops.ietf.org; Tue, 08 Jul 2003 16:43:14 +0000 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h68GggEZ024049 for ; Tue, 8 Jul 2003 09:42:43 -0700 (PDT) Message-Id: <5.2.0.9.0.20030708094208.026a72f0@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 08 Jul 2003 09:42:41 -0700 To: v6ops@ops.ietf.org From: Bob Fink Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_10,MSG_ID_ADDED_BY_MTA_3 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk IPv6 Operations WG (v6ops) IETF-57, Vienna Tuesday, July 15 at 1545-1800 Wednesday, July 16 at 1530-1730 ================================ CHAIRS: Bob Fink Pekka Savola Margaret Wasserman First Session: Tuesday, July 15, 2003 at 1545-1800 =================================================== Introduction and agenda bashing - 5 mins, Margaret Wasserman === current status - 5 mins, Margaret/Pekka === UNMAN Analysis discussion - 25 mins, Christian Huitema === Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet === IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim El-Malki === ISP Scenarios - 40 mins, Mikael Lind === ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound Second Session: Wednesday, July 16, 2003 at 1530-1730 ====================================================== v6-on-by-default - 25 mins, Alain Durand 5-10 mins presentation, remainder discussion === threedegrees - 10 mins, Christian Huitema === Security - discussion of what we should be doing - 45 mins, Chairs === NAT-PT Applicability Statement team report - 15 mins, Suresh Satapati or team member === Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola === Status report of IPv4 Survey drafts - 10 mins, Chairs -end From owner-v6ops@ops.ietf.org Wed Jul 9 09:19: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 JAA00074 for ; Wed, 9 Jul 2003 09:19:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aEnI-000Inh-Me for v6ops-data@psg.com; Wed, 09 Jul 2003 13:15:36 +0000 Received: from [147.11.1.11] (helo=mail.wrs.com) by psg.com with esmtp (Exim 4.14) id 19aEmm-000Ika-Ed for v6ops@ops.ietf.org; Wed, 09 Jul 2003 13:15:04 +0000 Received: from Kevin.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA07059; Wed, 9 Jul 2003 06:14:24 -0700 (PDT) Message-Id: <5.1.0.14.2.20030709091015.0385f1e8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Jul 2003 09:14:30 -0400 To: Bob Fink From: Margaret Wasserman Subject: Re: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna Cc: v6ops@ops.ietf.org In-Reply-To: <5.2.0.9.0.20030708094208.026a72f0@mail.addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, Please note that we made an error in the agenda. The following draft is not the most recent version of the Enterprise scenarios document: >ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound > The most recent version can be found at: http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-03.txt This version has been substantially modified from the previous version, so it is important to read the right draft. I apologize for any inconvenience, as this problem was caused by the fact that I erroneously accepted the earlier version as a WG draft. We will update the agenda as soon as possible. Sorry, Margaret From owner-v6ops@ops.ietf.org Wed Jul 9 10:33: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 KAA03012 for ; Wed, 9 Jul 2003 10:33:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aFyi-000LdH-6n for v6ops-data@psg.com; Wed, 09 Jul 2003 14:31:28 +0000 Received: from [209.249.147.28] (helo=proxy1.addr.com) by psg.com with esmtp (Exim 4.14) id 19aFyC-000LbD-BK for v6ops@ops.ietf.org; Wed, 09 Jul 2003 14:30:56 +0000 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h69EUJAu024723 for ; Wed, 9 Jul 2003 07:30:21 -0700 (PDT) Message-Id: <5.2.0.9.0.20030708193710.026992b8@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 07:23:27 -0700 To: v6ops@ops.ietf.org From: Bob Fink Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_10,MSG_ID_ADDED_BY_MTA_3 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk IPv6 Operations WG (v6ops) IETF-57, Vienna Tuesday, July 15 at 1545-1800 Wednesday, July 16 at 1530-1730 ================================ CHAIRS: Bob Fink Pekka Savola Margaret Wasserman First Session: Tuesday, July 15, 2003 at 1545-1800 =================================================== Introduction and agenda bashing - 5 mins, Margaret Wasserman === current status - 5 mins, Margaret/Pekka === UNMAN Analysis discussion - 25 mins, Christian Huitema === Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet === IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim El-Malki === ISP Scenarios - 40 mins, Mikael Lind === ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound Second Session: Wednesday, July 16, 2003 at 1530-1730 ====================================================== v6-on-by-default - 25 mins, Alain Durand 5-10 mins presentation, remainder discussion === threedegrees - 10 mins, Christian Huitema === Security - discussion of what we should be doing - 45 mins, Chairs === NAT-PT Applicability Statement team report - 15 mins, Peter Barany === Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola === Status report of IPv4 Survey drafts - 10 mins, Chairs -end From owner-v6ops@ops.ietf.org Wed Jul 9 11:46: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 LAA06743 for ; Wed, 9 Jul 2003 11:46:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aH7q-000OrH-Cn for v6ops-data@psg.com; Wed, 09 Jul 2003 15:44:58 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19aH7K-000OqP-Iq for v6ops@ops.ietf.org; Wed, 09 Jul 2003 15:44:26 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0ED66B80A; Wed, 9 Jul 2003 11:44:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 9 Jul 2003 11:44:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Date: Wed, 9 Jul 2003 11:44:22 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284F2A@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Thread-Index: AcNGJzGD37CoRGTCTBmlqm1YSymwvgACRzGg From: "Bound, Jim" To: "Bob Fink" , X-OriginalArrivalTime: 09 Jul 2003 15:44:23.0144 (UTC) FILETIME=[F81B9E80:01C34630] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Chairs, For the enterprise session. The time is to much. It should be 20 minutes. If persons have read the draft what should happen is input to the general direction the draft has taken. If you have not read the draft you should shut up in the meeting :--). Much input to this work should come on the mailing list before a meeting where all participants of this working group exist not just at meeting and definitely not adhoc at the last minute in a meeting for bashing. We have had ZERO input on this draft and not one comment on this mailing list. Do you want to do this or what? The team restructured from our last meeting. We do not want more than 20 minutes please fix the agenda to reflect that. We probably should have an interim Enterprise Scenario meeting before Minneapolis but the real question for this meeting is should this become a working group item or not. Getting that determined in Vienna would be success. thanks /jim =20 > -----Original Message----- > From: Bob Fink [mailto:bob@thefinks.com]=20 > Sent: Wednesday, July 09, 2003 10:23 AM > To: v6ops@ops.ietf.org > Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna=20 > - 2nd version >=20 >=20 > IPv6 Operations WG (v6ops) > IETF-57, Vienna >=20 > Tuesday, July 15 at 1545-1800 > Wednesday, July 16 at 1530-1730 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > CHAIRS: Bob Fink > Pekka Savola > Margaret Wasserman >=20 >=20 > First Session: Tuesday, July 15, 2003 at 1545-1800=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Introduction and agenda bashing - 5 mins, Margaret Wasserman >=20 > =3D=3D=3D > current status - 5 mins, Margaret/Pekka=20 > >=20 > =3D=3D=3D > UNMAN Analysis discussion - 25 mins, Christian Huitema=20 > l-00.txt> >=20 > =3D=3D=3D > Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet=20 > -nat-00.txt> >=20 > =3D=3D=3D > IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim=20 > El-Malki=20 > translator-00.txt> >=20 > =3D=3D=3D > ISP Scenarios - 40 mins, Mikael Lind=20 > arios-00.txt> >=20 > =3D=3D=3D > ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound=20 Second Session: Wednesday, July 16, 2003 at 1530-1730 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D v6-on-by-default - 25 mins, Alain Durand 5-10 mins presentation, remainder discussion =3D=3D=3D threedegrees - 10 mins, Christian Huitema =3D=3D=3D Security - discussion of what we should be doing - 45 mins, Chairs =3D=3D=3D NAT-PT Applicability Statement team report - 15 mins, Peter Barany =3D=3D=3D Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola =3D=3D=3D Status report of IPv4 Survey drafts - 10 mins, Chairs -end From owner-v6ops@ops.ietf.org Thu Jul 10 01:18: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 BAA05855 for ; Thu, 10 Jul 2003 01:18:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19aTmr-0004v5-U9 for v6ops-data@psg.com; Thu, 10 Jul 2003 05:16:09 +0000 Received: from [209.249.147.28] (helo=proxy1.addr.com) by psg.com with esmtp (Exim 4.14) id 19aTmp-0004tI-3Z for v6ops@ops.ietf.org; Thu, 10 Jul 2003 05:16:07 +0000 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h6A5FWAu096996; Wed, 9 Jul 2003 22:15:32 -0700 (PDT) Message-Id: <5.2.0.9.0.20030709221323.02673e98@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jul 2003 22:15:31 -0700 To: "Bound, Jim" , From: Bob Fink Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B04284F2A@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-11.3 required=5.0 tests=BAYES_10,IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jim, As Margaret responded to Yanick earlier today: >Hi Yanick, > >If we don't use all of the time for this section, that is okay. We'll just >end early... > >But, I wanted to make sure that there is plenty of time to work through any >issues in the document, in the hopes that we can get this document accepted >by the WG and in good shape to be published by ~Minneapolis. > >Margaret Hope this is ok. Thanks, Bob === At 11:44 AM 7/9/2003 -0400, Bound, Jim wrote: >Chairs, > >For the enterprise session. The time is to much. It should be 20 >minutes. If persons have read the draft what should happen is input to >the general direction the draft has taken. If you have not read the >draft you should shut up in the meeting :--). Much input to this work >should come on the mailing list before a meeting where all participants >of this working group exist not just at meeting and definitely not adhoc >at the last minute in a meeting for bashing. > >We have had ZERO input on this draft and not one comment on this mailing >list. > >Do you want to do this or what? The team restructured from our last >meeting. > >We do not want more than 20 minutes please fix the agenda to reflect >that. > >We probably should have an interim Enterprise Scenario meeting before >Minneapolis but the real question for this meeting is should this become >a working group item or not. Getting that determined in Vienna would be >success. > >thanks >/jim > > > > > -----Original Message----- > > From: Bob Fink [mailto:bob@thefinks.com] > > Sent: Wednesday, July 09, 2003 10:23 AM > > To: v6ops@ops.ietf.org > > Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna > > - 2nd version > > > > > > IPv6 Operations WG (v6ops) > > IETF-57, Vienna > > > > Tuesday, July 15 at 1545-1800 > > Wednesday, July 16 at 1530-1730 > > > > ================================ > > > > CHAIRS: Bob Fink > > Pekka Savola > > Margaret Wasserman > > > > > > First Session: Tuesday, July 15, 2003 at 1545-1800 > > =================================================== > > Introduction and agenda bashing - 5 mins, Margaret Wasserman > > > > === > > current status - 5 mins, Margaret/Pekka > > > > > > === > > UNMAN Analysis discussion - 25 mins, Christian Huitema > > l-00.txt> > > > > === > > Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet > > > -nat-00.txt> > > > > === > > IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim > > El-Malki > > > translator-00.txt> > > > > === > > ISP Scenarios - 40 mins, Mikael Lind > > > arios-00.txt> > > > > === > > ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound >xt> > > > >Second Session: Wednesday, July 16, 2003 at 1530-1730 >====================================================== >v6-on-by-default - 25 mins, Alain Durand >5-10 mins presentation, remainder discussion >t> > >=== >threedegrees - 10 mins, Christian Huitema > >=== >Security - discussion of what we should be doing - 45 mins, Chairs >w-00.txt> > >=== >NAT-PT Applicability Statement team report - 15 mins, Peter Barany draft yet> > >=== >Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola >tion-01.txt> > >=== >Status report of IPv4 Survey drafts - 10 mins, Chairs >1.txt> >.txt> >txt> >txt> >-01.txt> >txt> >1.txt> >1.txt> > >-end From owner-v6ops@ops.ietf.org Thu Jul 10 09:54:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02224 for ; Thu, 10 Jul 2003 09:54:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19abo2-000Oc0-TT for v6ops-data@psg.com; Thu, 10 Jul 2003 13:49:54 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19abnW-000ObL-6V for v6ops@ops.ietf.org; Thu, 10 Jul 2003 13:49:22 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 990D1742; Thu, 10 Jul 2003 09:49:21 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 10 Jul 2003 09:49:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Date: Thu, 10 Jul 2003 09:49:14 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241413@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Thread-Index: AcNGok51aVwc4p26Sni/u6xGCRi4HwAReJ1Q From: "Bound, Jim" To: "Bob Fink" , X-OriginalArrivalTime: 10 Jul 2003 13:49:15.0093 (UTC) FILETIME=[0D007050:01C346EA] X-Spam-Status: No, hits=-9.6 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Bob, This works. When Yanick does the update of what we did this group asked for we are done. Then Margaret should ask if this work is to be working group item. That will motivate the team to haul ass and go to next step and we should have an interim meeting to move quickly. Yanick and I have talked and this is not going to take 40 minutes. We have a real issue with no mail input on this list. We also don't want people using the meeting to work their agendas. That is unacceptable. I also feel if you get 15 hands that read the spec and then 100 hands on voting the vote is irrelevant, unless the subject has had wide discussion on the mail list (like the private address debate). This work has had zero discussion.=20 Is this clear above regarding the point of order? Thanks. We have developed three use scenarios for this version. The idea is to be able to use them to map many scenarios into so we can do the next step which is the analysis document. We have altered this document from any input (within reason of course) but for our team to feel this work is worth working on we need to know if we are a working group item or not. After the ngtrans fiasco and hassle many in this community trusts nothing you all do as chairs for awhile as far as "administration". You burned some of us pretty bad and for me it was personal too as it caused me a lot of work. Also did you see the DoD IPv6 annoucment that Oct 2003 it is required to provide dual capable IPv4/IPv6 systems. The strategy is an aggressive move towards IPv6 as fast as possible. That means dominant IPv6 backbones quick. See updated DSTM spec after Vienna which will define what 'dominant Ipv6 backbone' means later and why I mention it even in this thread. DoD is the largest Internet Enterprise in the U.S. I am talking with them directly on this too. So we will have that input to for this Enterprise work. Thanks for the follow up, /jim > -----Original Message----- > From: Bob Fink [mailto:bob@thefinks.com]=20 > Sent: Thursday, July 10, 2003 1:16 AM > To: Bound, Jim; v6ops@ops.ietf.org > Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57=20 > Vienna - 2nd version >=20 >=20 > Jim, >=20 > As Margaret responded to Yanick earlier today: >=20 > >Hi Yanick, > > > >If we don't use all of the time for this section, that is=20 > okay. We'll=20 > >just end early... > > > >But, I wanted to make sure that there is plenty of time to=20 > work through=20 > >any issues in the document, in the hopes that we can get=20 > this document=20 > >accepted by the WG and in good shape to be published by ~Minneapolis. > > > >Margaret >=20 >=20 > Hope this is ok. >=20 >=20 > Thanks, >=20 > Bob >=20 >=20 >=20 > =3D=3D=3D > At 11:44 AM 7/9/2003 -0400, Bound, Jim wrote: > >Chairs, > > > >For the enterprise session. The time is to much. It should be 20=20 > >minutes. If persons have read the draft what should happen=20 > is input to=20 > >the general direction the draft has taken. If you have not read the=20 > >draft you should shut up in the meeting :--). Much input to=20 > this work=20 > >should come on the mailing list before a meeting where all=20 > participants=20 > >of this working group exist not just at meeting and definitely not=20 > >adhoc at the last minute in a meeting for bashing. > > > >We have had ZERO input on this draft and not one comment on this=20 > >mailing list. > > > >Do you want to do this or what? The team restructured from our last=20 > >meeting. > > > >We do not want more than 20 minutes please fix the agenda to reflect=20 > >that. > > > >We probably should have an interim Enterprise Scenario=20 > meeting before=20 > >Minneapolis but the real question for this meeting is should this=20 > >become a working group item or not. Getting that determined=20 > in Vienna=20 > >would be success. > > > >thanks > >/jim > > > > > > > > > -----Original Message----- > > > From: Bob Fink [mailto:bob@thefinks.com] > > > Sent: Wednesday, July 09, 2003 10:23 AM > > > To: v6ops@ops.ietf.org > > > Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna > > > - 2nd version > > > > > > > > > IPv6 Operations WG (v6ops) > > > IETF-57, Vienna > > > > > > Tuesday, July 15 at 1545-1800 > > > Wednesday, July 16 at 1530-1730 > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > CHAIRS: Bob Fink > > > Pekka Savola > > > Margaret Wasserman > > > > > > > > > First Session: Tuesday, July 15, 2003 at 1545-1800=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > Introduction and agenda bashing - 5 mins, Margaret Wasserman > > > > > > =3D=3D=3D > > > current status - 5 mins, Margaret/Pekka=20 > > > > > > > > > =3D=3D=3D > > > UNMAN Analysis discussion - 25 mins, Christian Huitema=20 > > > =20 > > > l-00.txt> > > > > > > =3D=3D=3D > > > Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet=20 > > > > > -nat-00.txt> > > > > > > =3D=3D=3D > > > IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim El-Malki > > > =20 > > translator-00.txt> > > > > > > =3D=3D=3D > > > ISP Scenarios - 40 mins, Mikael Lind > > > =20 > > arios-00.txt> > > > > > > =3D=3D=3D > > > ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound > > -v6net-03.t > >xt> > > > > > > > >Second Session: Wednesday, July 16, 2003 at 1530-1730 > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > >v6-on-by-default - 25 mins, Alain Durand > >5-10 mins presentation, remainder discussion > >t> > >=3D=3D=3D >threedegrees - 10 mins, Christian Huitema > >=3D=3D=3D >Security - discussion of what we should be doing - 45 mins, Chairs >w-00.txt> > >=3D=3D=3D >NAT-PT Applicability Statement team report - 15 mins, Peter Barany draft yet> > >=3D=3D=3D >Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola >tion-01.txt> > >=3D=3D=3D >Status report of IPv4 Survey drafts - 10 mins, Chairs >1.txt> >.txt> >txt> >txt> >-01.txt> >txt> >1.txt> >1.txt> > >-end From owner-v6ops@ops.ietf.org Thu Jul 10 10:46:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05538 for ; Thu, 10 Jul 2003 10:46:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19acg4-00016a-Nm for v6ops-data@psg.com; Thu, 10 Jul 2003 14:45:44 +0000 Received: from [209.249.147.28] (helo=proxy1.addr.com) by psg.com with esmtp (Exim 4.14) id 19acfW-00010k-Re for v6ops@ops.ietf.org; Thu, 10 Jul 2003 14:45:10 +0000 Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h6AEiWNx085911; Thu, 10 Jul 2003 07:44:34 -0700 (PDT) Message-Id: <5.2.0.9.0.20030710073939.028845b0@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 10 Jul 2003 07:44:28 -0700 To: "Bound, Jim" , From: Bob Fink Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241413@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-12.1 required=5.0 tests=BAYES_01,IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jim, I don't disagree with what you say, and am certainly concerned in general with how little discussion we get on lists about important topics such as this. I do still think it will be useful to have some discussion on the draft (even if its only 5 minutes). However, I suggest that you and Yanick get in touch with Margaret and Pekka before the meeting and talk about the process. I won't be at this IETF. Thanks, Bob === At 09:49 AM 7/10/2003 -0400, Bound, Jim wrote: >Bob, > >This works. When Yanick does the update of what we did this group asked >for we are done. Then Margaret should ask if this work is to be working >group item. That will motivate the team to haul ass and go to next step >and we should have an interim meeting to move quickly. Yanick and I >have talked and this is not going to take 40 minutes. We have a real >issue with no mail input on this list. We also don't want people using >the meeting to work their agendas. That is unacceptable. I also feel >if you get 15 hands that read the spec and then 100 hands on voting the >vote is irrelevant, unless the subject has had wide discussion on the >mail list (like the private address debate). This work has had zero >discussion. > >Is this clear above regarding the point of order? Thanks. > >We have developed three use scenarios for this version. The idea is to >be able to use them to map many scenarios into so we can do the next >step which is the analysis document. > >We have altered this document from any input (within reason of course) >but for our team to feel this work is worth working on we need to know >if we are a working group item or not. After the ngtrans fiasco and >hassle many in this community trusts nothing you all do as chairs for >awhile as far as "administration". You burned some of us pretty bad and >for me it was personal too as it caused me a lot of work. > >Also did you see the DoD IPv6 annoucment that Oct 2003 it is required to >provide dual capable IPv4/IPv6 systems. The strategy is an aggressive >move towards IPv6 as fast as possible. That means dominant IPv6 >backbones quick. See updated DSTM spec after Vienna which will define >what 'dominant Ipv6 backbone' means later and why I mention it even in >this thread. DoD is the largest Internet Enterprise in the U.S. I am >talking with them directly on this too. So we will have that input to >for this Enterprise work. > >Thanks for the follow up, >/jim > > > -----Original Message----- > > From: Bob Fink [mailto:bob@thefinks.com] > > Sent: Thursday, July 10, 2003 1:16 AM > > To: Bound, Jim; v6ops@ops.ietf.org > > Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57 > > Vienna - 2nd version > > > > > > Jim, > > > > As Margaret responded to Yanick earlier today: > > > > >Hi Yanick, > > > > > >If we don't use all of the time for this section, that is > > okay. We'll > > >just end early... > > > > > >But, I wanted to make sure that there is plenty of time to > > work through > > >any issues in the document, in the hopes that we can get > > this document > > >accepted by the WG and in good shape to be published by ~Minneapolis. > > > > > >Margaret > > > > > > Hope this is ok. > > > > > > Thanks, > > > > Bob > > > > > > > > === > > At 11:44 AM 7/9/2003 -0400, Bound, Jim wrote: > > >Chairs, > > > > > >For the enterprise session. The time is to much. It should be 20 > > >minutes. If persons have read the draft what should happen > > is input to > > >the general direction the draft has taken. If you have not read the > > >draft you should shut up in the meeting :--). Much input to > > this work > > >should come on the mailing list before a meeting where all > > participants > > >of this working group exist not just at meeting and definitely not > > >adhoc at the last minute in a meeting for bashing. > > > > > >We have had ZERO input on this draft and not one comment on this > > >mailing list. > > > > > >Do you want to do this or what? The team restructured from our last > > >meeting. > > > > > >We do not want more than 20 minutes please fix the agenda to reflect > > >that. > > > > > >We probably should have an interim Enterprise Scenario > > meeting before > > >Minneapolis but the real question for this meeting is should this > > >become a working group item or not. Getting that determined > > in Vienna > > >would be success. > > > > > >thanks > > >/jim > > > > > > > > > > > > > -----Original Message----- > > > > From: Bob Fink [mailto:bob@thefinks.com] > > > > Sent: Wednesday, July 09, 2003 10:23 AM > > > > To: v6ops@ops.ietf.org > > > > Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna > > > > - 2nd version > > > > > > > > > > > > IPv6 Operations WG (v6ops) > > > > IETF-57, Vienna > > > > > > > > Tuesday, July 15 at 1545-1800 > > > > Wednesday, July 16 at 1530-1730 > > > > > > > > ================================ > > > > > > > > CHAIRS: Bob Fink > > > > Pekka Savola > > > > Margaret Wasserman > > > > > > > > > > > > First Session: Tuesday, July 15, 2003 at 1545-1800 > > > > =================================================== > > > > Introduction and agenda bashing - 5 mins, Margaret Wasserman > > > > > > > > === > > > > current status - 5 mins, Margaret/Pekka > > > > > > > > > > > > === > > > > UNMAN Analysis discussion - 25 mins, Christian Huitema > > > > > > > > l-00.txt> > > > > > > > > === > > > > Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet > > > > > > > -nat-00.txt> > > > > > > > > === > > > > IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim El-Malki > > > > > > > translator-00.txt> > > > > > > > > === > > > > ISP Scenarios - 40 mins, Mikael Lind > > > > > > > arios-00.txt> > > > > > > > > === > > > > ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound > > > -v6net-03.t > > >xt> > > > > > > > > > > > >Second Session: Wednesday, July 16, 2003 at 1530-1730 > > >====================================================== > > >v6-on-by-default - 25 mins, Alain Durand > > >5-10 mins presentation, remainder discussion > > >fault-01.tx>t> > > > >=== > >threedegrees - 10 mins, Christian Huitema > > > >=== > >Security - discussion of what we should be doing - 45 mins, Chairs > >e>w-00.txt> > > > >=== > >NAT-PT Applicability Statement team report - 15 mins, Peter Barany >draft yet> > > > >=== > >Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka >Savola > >i>tion-01.txt> > > > >=== > >Status report of IPv4 Survey drafts - 10 mins, Chairs > >0>1.txt> > >1>.txt> > >.>txt> > >.>txt> > >g>-01.txt> > >.>txt> > >0>1.txt> > >0>1.txt> > > > >-end From owner-v6ops@ops.ietf.org Thu Jul 10 11:11: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 LAA06420 for ; Thu, 10 Jul 2003 11:11:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ad2i-0002Sl-5C for v6ops-data@psg.com; Thu, 10 Jul 2003 15:09:08 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19ad2A-0002Rt-Um for v6ops@ops.ietf.org; Thu, 10 Jul 2003 15:08:35 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 59208B96D; Thu, 10 Jul 2003 11:08:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 10 Jul 2003 11:08:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Date: Thu, 10 Jul 2003 11:08:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04284F7D@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Thread-Index: AcNG8czwkinzp7TsTVyDjZzCbDPWWgAAvwNg From: "Bound, Jim" To: "Bob Fink" , X-OriginalArrivalTime: 10 Jul 2003 15:08:34.0125 (UTC) FILETIME=[219B17D0:01C346F5] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Bob, OK we will send note to Margaret and Pekka today. Discussion is good. Brainstorming on specs with no mail input is political. Also we wanted to just do brainstorming on multi6 and the ruling was we don't do brainstorming in IETF meetings. We have a minimal draft to get started and discussion on that direction is fine brainstorming scenarios etc is different and I for one want 'consistency' in the IETF rule sets. I don't want them made up adhoc as community member. Thanks /jim > -----Original Message----- > From: Bob Fink [mailto:bob@thefinks.com]=20 > Sent: Thursday, July 10, 2003 10:44 AM > To: Bound, Jim; v6ops@ops.ietf.org > Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57=20 > Vienna - 2nd version >=20 >=20 > Jim, >=20 > I don't disagree with what you say, and am certainly=20 > concerned in general=20 > with how little discussion we get on lists about important=20 > topics such as=20 > this. I do still think it will be useful to have some=20 > discussion on the=20 > draft (even if its only 5 minutes). >=20 > However, I suggest that you and Yanick get in touch with=20 > Margaret and Pekka=20 > before the meeting and talk about the process. I won't be at=20 > this IETF. >=20 >=20 > Thanks, >=20 > Bob >=20 > =3D=3D=3D > At 09:49 AM 7/10/2003 -0400, Bound, Jim wrote: > >Bob, > > > >This works. When Yanick does the update of what we did this group=20 > >asked for we are done. Then Margaret should ask if this work=20 > is to be=20 > >working group item. That will motivate the team to haul ass=20 > and go to=20 > >next step and we should have an interim meeting to move quickly. =20 > >Yanick and I have talked and this is not going to take 40=20 > minutes. We=20 > >have a real issue with no mail input on this list. We also=20 > don't want=20 > >people using the meeting to work their agendas. That is=20 > unacceptable. =20 > >I also feel if you get 15 hands that read the spec and then=20 > 100 hands=20 > >on voting the vote is irrelevant, unless the subject has had wide=20 > >discussion on the mail list (like the private address debate). This=20 > >work has had zero discussion. > > > >Is this clear above regarding the point of order? Thanks. > > > >We have developed three use scenarios for this version. The=20 > idea is to=20 > >be able to use them to map many scenarios into so we can do the next=20 > >step which is the analysis document. > > > >We have altered this document from any input (within reason=20 > of course)=20 > >but for our team to feel this work is worth working on we=20 > need to know=20 > >if we are a working group item or not. After the ngtrans fiasco and=20 > >hassle many in this community trusts nothing you all do as=20 > chairs for=20 > >awhile as far as "administration". You burned some of us pretty bad=20 > >and for me it was personal too as it caused me a lot of work. > > > >Also did you see the DoD IPv6 annoucment that Oct 2003 it is=20 > required=20 > >to provide dual capable IPv4/IPv6 systems. The strategy is an=20 > >aggressive move towards IPv6 as fast as possible. That=20 > means dominant=20 > >IPv6 backbones quick. See updated DSTM spec after Vienna which will=20 > >define what 'dominant Ipv6 backbone' means later and why I=20 > mention it=20 > >even in this thread. DoD is the largest Internet Enterprise=20 > in the U.S. =20 > >I am talking with them directly on this too. So we will have that=20 > >input to for this Enterprise work. > > > >Thanks for the follow up, > >/jim > > > > > -----Original Message----- > > > From: Bob Fink [mailto:bob@thefinks.com] > > > Sent: Thursday, July 10, 2003 1:16 AM > > > To: Bound, Jim; v6ops@ops.ietf.org > > > Subject: RE: IPv6 Operations WG (v6ops) agenda for=20 > IETF-57 Vienna -=20 > > > 2nd version > > > > > > > > > Jim, > > > > > > As Margaret responded to Yanick earlier today: > > > > > > >Hi Yanick, > > > > > > > >If we don't use all of the time for this section, that is > > > okay. We'll > > > >just end early... > > > > > > > >But, I wanted to make sure that there is plenty of time to > > > work through > > > >any issues in the document, in the hopes that we can get > > > this document > > > >accepted by the WG and in good shape to be published by=20 > > > >~Minneapolis. > > > > > > > >Margaret > > > > > > > > > Hope this is ok. > > > > > > > > > Thanks, > > > > > > Bob > > > > > > > > > > > > =3D=3D=3D > > > At 11:44 AM 7/9/2003 -0400, Bound, Jim wrote: > > > >Chairs, > > > > > > > >For the enterprise session. The time is to much. It=20 > should be 20=20 > > > >minutes. If persons have read the draft what should happen > > > is input to > > > >the general direction the draft has taken. If you have not read=20 > > > >the draft you should shut up in the meeting :--). Much input to > > > this work > > > >should come on the mailing list before a meeting where all > > > participants > > > >of this working group exist not just at meeting and=20 > definitely not=20 > > > >adhoc at the last minute in a meeting for bashing. > > > > > > > >We have had ZERO input on this draft and not one comment on this=20 > > > >mailing list. > > > > > > > >Do you want to do this or what? The team restructured from our=20 > > > >last meeting. > > > > > > > >We do not want more than 20 minutes please fix the agenda to=20 > > > >reflect that. > > > > > > > >We probably should have an interim Enterprise Scenario > > > meeting before > > > >Minneapolis but the real question for this meeting is=20 > should this=20 > > > >become a working group item or not. Getting that determined > > > in Vienna > > > >would be success. > > > > > > > >thanks > > > >/jim > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bob Fink [mailto:bob@thefinks.com] > > > > > Sent: Wednesday, July 09, 2003 10:23 AM > > > > > To: v6ops@ops.ietf.org > > > > > Subject: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna > > > > > - 2nd version > > > > > > > > > > > > > > > IPv6 Operations WG (v6ops) > > > > > IETF-57, Vienna > > > > > > > > > > Tuesday, July 15 at 1545-1800 > > > > > Wednesday, July 16 at 1530-1730 > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > CHAIRS: Bob Fink > > > > > Pekka Savola > > > > > Margaret Wasserman > > > > > > > > > > > > > > > First Session: Tuesday, July 15, 2003 at 1545-1800=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > Introduction and agenda bashing - 5 mins, Margaret Wasserman > > > > > > > > > > =3D=3D=3D > > > > > current status - 5 mins, Margaret/Pekka=20 > > > > > > > > > > > > > > > =3D=3D=3D > > > > > UNMAN Analysis discussion - 25 mins, Christian Huitema=20 > > > > >=20 > > > > > > l-00.txt> > > > > > > > > > > =3D=3D=3D > > > > > Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet=20 > > > > >=20 > > > > > -nat-00.txt> > > > > > > > > > > =3D=3D=3D > > > > > IPv6-IPv4 Translators in 3GPP Networks - 10 mins,=20 > Karim El-Malki=20 > > > > >=20 > > > > > translator-00.txt> > > > > > > > > > > =3D=3D=3D > > > > > ISP Scenarios - 40 mins, Mikael Lind=20 > > > > >=20 > > > > > arios-00.txt> > > > > > > > > > > =3D=3D=3D > > > > > ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound > > > >=20 > > > >-v6net-03.t > > > >xt> > > > > > > > > > > > > > > > >Second Session: Wednesday, July 16, 2003 at 1530-1730=20 > > > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > >v6-on-by-default - 25 mins, Alain Durand > > > >5-10 mins presentation, remainder discussion=20 > > > > >fault-01.tx>t> > > > > > >=3D=3D=3D > > >threedegrees - 10 mins, Christian Huitema=20 > > > > > > >=3D=3D=3D > > >Security - discussion of what we should be doing - 45 mins, Chairs=20 > >=20 > > savola-v6ops-security-over > > >vi > >e>w-00.txt> > > > > > >=3D=3D=3D > > >NAT-PT Applicability Statement team report - 15 mins, Peter Barany=20 > > > > > > > > >=3D=3D=3D > > >Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka > >Savola > >=20 > > shin-v6ops-application-tra > > >ns > >i>tion-01.txt> > > > > > >=3D=3D=3D > > >Status report of IPv4 Survey drafts - 10 mins, Chairs > >=20 > > ietf-v6ops-ipv4survey-intr > > >o- > >0>1.txt> > >=20 > > ietf-v6ops-ipv4survey-apps > > >-0 > >1>.txt> > >=20 > > ietf-v6ops-ipv4survey-ops- > > >01 > >.>txt> > >=20 > > ietf-v6ops-ipv4survey-int- > > >01 > >.>txt> > >=20 > > ietf-v6ops-ipv4survey-rout > > >in > >g>-01.txt> > >=20 > > ietf-v6ops-ipv4survey-sec- > > >01 > >.>txt> > >=20 > > ietf-v6ops-ipv4survey-subi > > >p- > >0>1.txt> > >=20 > > ietf-v6ops-ipv4survey-tran > > >s- > >0>1.txt> > > > > > >-end >=20 >=20 From owner-v6ops@ops.ietf.org Thu Jul 10 14:23: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 OAA15394 for ; Thu, 10 Jul 2003 14:23:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ag2w-000Bvx-5O for v6ops-data@psg.com; Thu, 10 Jul 2003 18:21:34 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19ag1u-000Br5-Ai; Thu, 10 Jul 2003 18:20:30 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ag1t-0003tj-6X; Thu, 10 Jul 2003 20:20:29 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 10 Jul 2003 20:20:28 +0200 To: Bob Fink Cc: "Bound, Jim" , Subject: RE: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version References: <9C422444DE99BC46B3AD3C6EAFC9711B03241413@tayexc13.americas .cpqcorp.net> <5.2.0.9.0.20030710073939.028845b0@mail.addr.com> Message-Id: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't disagree with what you say, and am certainly concerned in general > with how little discussion we get on lists about important topics such as > this. lack of solid draft review is a major problem, and not just in this wg. randy From owner-v6ops@ops.ietf.org Fri Jul 11 13:03: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 NAA06065 for ; Fri, 11 Jul 2003 13:03:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b1F9-000L2v-0j for v6ops-data@psg.com; Fri, 11 Jul 2003 16:59:35 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.14) id 19b1F6-000L2h-D9 for v6ops@ops.ietf.org; Fri, 11 Jul 2003 16:59:32 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6BGxWGo022370 for ; Fri, 11 Jul 2003 10:59:32 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHV00CGBDV73A@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 10:59:32 -0600 (MDT) Received: from sun.com ([212.158.47.2]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHV003CEDV4T3@mail.sun.net> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 10:59:31 -0600 (MDT) Date: Fri, 11 Jul 2003 09:59:47 -0700 From: Alain Durand Subject: comments on draft-pouffary-v6ops-ent-v6net-03.txt In-reply-to: <5.2.0.9.0.20030708193710.026992b8@mail.addr.com> To: v6ops@ops.ietf.org Message-id: <13CA0206-B3C1-11D7-94DB-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I would like to say that this -03 is in a much better shape than any of the previous version, I think we are now on a much better track, and I would recommend to adopt it as a working group item. Detailed comments: Section 3.1, network scenario: what is scenario 2? is it a typo or is scenario 2 missing? Section 4 does not tell us anything new, and is actually part of the solution space, not the scenario space. Section 5 is actually redundant with section 3.2, network scenario characteristics. If one of the scenario 1, (2?) and 3 say you need to map 1 to 1 the characteristics, then section 6 is useless. If the scenario says some characteristics do not necessarily need an equivalent in v6, section 6 may gets in the way. In fact, I believe I would be happy with this document as it is with only section 1, 2, 3, 6 and up, deleting section 4 & 5. - Alain. From owner-v6ops@ops.ietf.org Fri Jul 11 13:24: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 NAA06973 for ; Fri, 11 Jul 2003 13:24:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b1cC-000MGr-ML for v6ops-data@psg.com; Fri, 11 Jul 2003 17:23:24 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19b1c9-000MGe-Vu for v6ops@ops.ietf.org; Fri, 11 Jul 2003 17:23:22 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6BHNLm7022237 for ; Fri, 11 Jul 2003 11:23:21 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHV00BN7EYWMY@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 11:23:21 -0600 (MDT) Received: from sun.com ([212.158.47.2]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHV007FREYU90@mail.sun.net> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 11:23:20 -0600 (MDT) Date: Fri, 11 Jul 2003 10:23:37 -0700 From: Alain Durand Subject: comments on draft-lind-v6ops-isp-scenarios-00.txt In-reply-to: <5.2.0.9.0.20030708193710.026992b8@mail.addr.com> To: v6ops@ops.ietf.org Message-id: <68321A1A-B3C4-11D7-94DB-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I'm a little confused by the direction this effort is taking... Basically this document is telling us that ISP can start deploying IPv6 at their core or at their edges or both at the same time. I guess we all knew that for a long time... Are future revision of this document going to address the pros and cons of both approaches? Are we expecting a companion document that will explain how to implement both approaches? - Alain. From owner-v6ops@ops.ietf.org Fri Jul 11 13:39: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 NAA07603 for ; Fri, 11 Jul 2003 13:39:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b1r6-000NEo-5x for v6ops-data@psg.com; Fri, 11 Jul 2003 17:38:48 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19b1r3-000NEV-Pr for v6ops@ops.ietf.org; Fri, 11 Jul 2003 17:38:45 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6BHcjtD000106 for ; Fri, 11 Jul 2003 11:38:45 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHV00B4XFOKMY@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 11:38:45 -0600 (MDT) Received: from sun.com ([212.158.47.2]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHV003E6FOIT3@mail.sun.net> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 11:38:44 -0600 (MDT) Date: Fri, 11 Jul 2003 10:39:01 -0700 From: Alain Durand Subject: comments on draft-palet-v6ops-proto41-nat-00.txt In-reply-to: <5.2.0.9.0.20030708193710.026992b8@mail.addr.com> To: v6ops@ops.ietf.org Message-id: <8EF960C7-B3C6-11D7-94DB-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Proto 41 redirection as explain in this document cannot be demultiplex and only works for the same number of tunnels as the number of external IPv4 addresses. So, if there is only one external IPv4 address, only one tunnel can be set up. Also, this obviously does not work very well in case of doubled-nated network. (I just happen to sit on one right now) - Alain. From owner-v6ops@ops.ietf.org Fri Jul 11 14:04: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 OAA08452 for ; Fri, 11 Jul 2003 14:04:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19b2F4-000OlJ-7Q for v6ops-data@psg.com; Fri, 11 Jul 2003 18:03:34 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19b2F1-000Ol7-Mp for v6ops@ops.ietf.org; Fri, 11 Jul 2003 18:03:31 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6BI3VtD014190 for ; Fri, 11 Jul 2003 12:03:31 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHV00CAYGTU3A@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 12:03:31 -0600 (MDT) Received: from sun.com ([212.158.47.2]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHV00BKSGTSFW@mail.sun.net> for v6ops@ops.ietf.org; Fri, 11 Jul 2003 12:03:30 -0600 (MDT) Date: Fri, 11 Jul 2003 11:03:47 -0700 From: Alain Durand Subject: Comments on draft-ietf-v6ops-unmaneval-00.txt In-reply-to: <5.2.0.9.0.20030708193710.026992b8@mail.addr.com> To: v6ops@ops.ietf.org Message-id: <04B77B82-B3CA-11D7-94DB-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_20,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT In case A, the extra cost in bandwidth in the tunnel broker solution versus Teredo is due to the triangular routing induced by the tunnel server. If the tunnel server is located within the ISP network, this overhead is almost zero. So, I think the section 2.1.4 should recommend the deployment of tunnel server within ISP as a first step for those ISP who'd like to offer IPv6 service with minimal investment. Also, I think that the comparison in terms of complexity is a little unfair. The bubble mechanism is complex, and the tunnel broker solution does not have to be made fully automatic. The real difference is then that communications initiated by the outside prior to the tunnel establishment will not work. - Alain. From owner-v6ops@ops.ietf.org Sat Jul 12 08:08: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 IAA12882 for ; Sat, 12 Jul 2003 08:08:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bJ8R-000Jee-5m for v6ops-data@psg.com; Sat, 12 Jul 2003 12:05:51 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19bJ7f-000Jau-Um for v6ops@ops.ietf.org; Sat, 12 Jul 2003 12:05:04 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19bJ7f-00058C-0q for v6ops@ops.ietf.org; Sat, 12 Jul 2003 14:05:03 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 12 Jul 2003 14:05:02 +0200 To: v6ops@ops.ietf.org Subject: first widely published relay as a dos issue Message-Id: X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: Alexander Gall To: 6bone@ISI.EDU Subject: [6bone] DoS attacks through 6to4 anycast relay Date: Thu, 10 Jul 2003 11:43:42 +0200 We (SWITCH) are running one of the (still few) 6to4 anycast relays. Normally, traffic rates are very low (last month's average input was a little over 200kbps) but there were some spikes of several Mbps in the past week. On Tuesday and Wednesday, the traffic was enough to severely disrupt our 7206VXR that serves as relay and terminates some 6bone tunnels as well. We are currently testing an IOS image with IPv6 netflow support on that router, so I was able to see what was going on yesterday evening (17:00 - 18:30 UTC+2). The number of active flows climbed to almost 3000 (from a normal 100-300). This was due to short UDP flows with random source and destination ports from 2002:3ED3:10C:: to 3FFE:8171:61::11 like these SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0x203D 0x8032 150 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0x043D 0x9432 180 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xAA89 0x8A8E 60 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xCE89 0xDE8E 160 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xF289 0x328E 160 Netflow made this easy to spot but the large number of flows is probably also the main reason why the router performed very badly during the event :-( Traffic peaked at 18Mbps before I blocked packets from 62.211.1.12 to 192.88.99.1 at the upstream router. The source points to inetnum: 62.211.1.0 - 62.211.1.255 netname: TIN descr: Telecom Italia S.p.A descr: E@sy.ip ADSL service OSPF Area 1 descr: Wholesale service for ISP country: IT admin-c: BS104-RIPE tech-c: BS104-RIPE status: ASSIGNED PA remarks: Please send abuse notification to abuse@telecomitalia.it notify: ripe-staff@telecomitalia.it mnt-by: TIWS-MNT changed: net_ti@telecomitalia.it 20020801 source: RIPE but that may well be spoofed. The destination resloves to an interesting name (with only a AAAA RR): rootk.it :-) I take this as a good sign that IPv6 is finally catching on ;-) -- Alex SWITCH-NOC From owner-v6ops@ops.ietf.org Sat Jul 12 08:37: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 IAA14020 for ; Sat, 12 Jul 2003 08:37:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bJc5-000Ksx-AX for v6ops-data@psg.com; Sat, 12 Jul 2003 12:36:29 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19bJbZ-000KqV-KD for v6ops@ops.ietf.org; Sat, 12 Jul 2003 12:35:57 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 12 Jul 2003 05:35:27 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 12 Jul 2003 05:35:26 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 12 Jul 2003 05:35:26 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 12 Jul 2003 05:35:26 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 12 Jul 2003 05:35:25 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 12 Jul 2003 05:35:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: first widely published relay as a dos issue Date: Sat, 12 Jul 2003 05:30:26 -0700 Message-ID: Thread-Topic: first widely published relay as a dos issue Thread-Index: AcNIb0IfIvCyErExRlWaO4N9+9WSpwAAhz+O From: "Christian Huitema" To: "Randy Bush" , X-OriginalArrivalTime: 12 Jul 2003 12:35:25.0276 (UTC) FILETIME=[117381C0:01C34872] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable How is that a "publshed relay DoS issue"? It seems that all these = packets had the same source and destination addresses, and that the = address could be traced. A plausible explanation is a bug in some brand = new software, without malicious intent; it is not necessarily a DoS = attack. It is also not specifically a relay attack. If those two = addresses were both native addresses, then we would have the same attack = against every IPv6 router on the path, it would just not use the relay. ________________________________ From: owner-v6ops@ops.ietf.org on behalf of Randy Bush Sent: Sat 7/12/2003 5:05 AM To: v6ops@ops.ietf.org Subject: first widely published relay as a dos issue From: Alexander Gall To: 6bone@ISI.EDU Subject: [6bone] DoS attacks through 6to4 anycast relay Date: Thu, 10 Jul 2003 11:43:42 +0200 We (SWITCH) are running one of the (still few) 6to4 anycast relays. Normally, traffic rates are very low (last month's average input was a little over 200kbps) but there were some spikes of several Mbps in the past week. On Tuesday and Wednesday, the traffic was enough to severely disrupt our 7206VXR that serves as relay and terminates some 6bone tunnels as well. We are currently testing an IOS image with IPv6 netflow support on that router, so I was able to see what was going on yesterday evening (17:00 - 18:30 UTC+2). The number of active flows climbed to almost 3000 (from a normal 100-300). This was due to short UDP flows with random source and destination ports from 2002:3ED3:10C:: to 3FFE:8171:61::11 like these SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt = Packets 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0x203D 0x8032 = 150 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0x043D 0x9432 = 180 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xAA89 0x8A8E = 60 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xCE89 0xDE8E = 160 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xF289 0x328E = 160 Netflow made this easy to spot but the large number of flows is probably also the main reason why the router performed very badly during the event :-( Traffic peaked at 18Mbps before I blocked packets from 62.211.1.12 to 192.88.99.1 at the upstream router. The source points to inetnum: 62.211.1.0 - 62.211.1.255 netname: TIN descr: Telecom Italia S.p.A descr: E@sy.ip ADSL service OSPF Area 1 descr: Wholesale service for ISP country: IT admin-c: BS104-RIPE tech-c: BS104-RIPE status: ASSIGNED PA remarks: Please send abuse notification to abuse@telecomitalia.it notify: ripe-staff@telecomitalia.it mnt-by: TIWS-MNT changed: net_ti@telecomitalia.it 20020801 source: RIPE but that may well be spoofed. The destination resloves to an interesting name (with only a AAAA RR): rootk.it :-) I take this as a good sign that IPv6 is finally catching on ;-) -- Alex SWITCH-NOC From owner-v6ops@ops.ietf.org Sat Jul 12 08:41:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14189 for ; Sat, 12 Jul 2003 08:41:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bJgd-000L7n-My for v6ops-data@psg.com; Sat, 12 Jul 2003 12:41:11 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19bJg8-000L6z-4G; Sat, 12 Jul 2003 12:40:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19bJg7-00059q-B9; Sat, 12 Jul 2003 14:40:39 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 12 Jul 2003 14:40:38 +0200 To: "Christian Huitema" Cc: Subject: RE: first widely published relay as a dos issue References: Message-Id: X-Spam-Status: No, hits=-8.1 required=5.0 tests=BAYES_30,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How is that a "publshed relay DoS issue"? It seems that all these packets > had the same source and destination addresses, and that the address could > be traced. that's why i said dos, not ddos From owner-v6ops@ops.ietf.org Sat Jul 12 08:48: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 IAA14464 for ; Sat, 12 Jul 2003 08:48:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bJnH-000La2-B9 for v6ops-data@psg.com; Sat, 12 Jul 2003 12:48:03 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19bJnD-000LZe-Tr; Sat, 12 Jul 2003 12:48:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6CClun05951; Sat, 12 Jul 2003 15:47:56 +0300 Date: Sat, 12 Jul 2003 15:47:55 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: Randy Bush , Subject: RE: first widely published relay as a dos issue In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-26.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 12 Jul 2003, Christian Huitema wrote: > How is that a "publshed relay DoS issue"? It seems that all these > packets had the same source and destination addresses, and that the > address could be traced. A plausible explanation is a bug in some brand > new software, without malicious intent; it is not necessarily a DoS > attack. It is also not specifically a relay attack. If those two > addresses were both native addresses, then we would have the same attack > against every IPv6 router on the path, it would just not use the relay. A plausible assumption seems to be that the attack was not targeted at the relay in particular, it just happened to be on the harm's way. If it had been, it would probably have been nastier. But still, I think there's something to learn from this case. For example: - even relatively low traffic counts can harm at least some of the deployed base - (not mentioned here, but an issue in some other scenarios) IPv6 traffic may be free (for some), but IPv4 is not. So, some operators may be hesitant to deploy or at least advertise a 6to4 relay -- this could mean they'd get in the harm's way because 6to4 relay would be doing encapsulation (esp. if it would be a full fledged relay) - the fewer 6to4 relays there are, the more probable it is *your* relay gets in the way of a DoS attack.. :-/ - others ? > From: owner-v6ops@ops.ietf.org on behalf of Randy Bush > Sent: Sat 7/12/2003 5:05 AM > To: v6ops@ops.ietf.org > Subject: first widely published relay as a dos issue > > > > From: Alexander Gall > To: 6bone@ISI.EDU > Subject: [6bone] DoS attacks through 6to4 anycast relay > Date: Thu, 10 Jul 2003 11:43:42 +0200 > > We (SWITCH) are running one of the (still few) 6to4 anycast relays. > Normally, traffic rates are very low (last month's average input was a > little over 200kbps) but there were some spikes of several Mbps in the > past week. On Tuesday and Wednesday, the traffic was enough to > severely disrupt our 7206VXR that serves as relay and terminates some > 6bone tunnels as well. > > We are currently testing an IOS image with IPv6 netflow support on > that router, so I was able to see what was going on yesterday evening > (17:00 - 18:30 UTC+2). The number of active flows climbed to almost > 3000 (from a normal 100-300). This was due to short UDP flows with > random source and destination ports from 2002:3ED3:10C:: to > 3FFE:8171:61::11 like these > > SrcAddress InpIf DstAddress OutIf Prot SrcPrt DstPrt Packets > 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0x203D 0x8032 150 > 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0x043D 0x9432 180 > 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xAA89 0x8A8E 60 > 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xCE89 0xDE8E 160 > 2002:3ED3:10C:: Tu2 3FFE:8171:61::11 Gi4/0 0x11 0xF289 0x328E 160 > > Netflow made this easy to spot but the large number of flows is > probably also the main reason why the router performed very badly > during the event :-( > > Traffic peaked at 18Mbps before I blocked packets from 62.211.1.12 to > 192.88.99.1 at the upstream router. > > The source points to > > inetnum: 62.211.1.0 - 62.211.1.255 > netname: TIN > descr: Telecom Italia S.p.A > descr: E@sy.ip ADSL service OSPF Area 1 > descr: Wholesale service for ISP > country: IT > admin-c: BS104-RIPE > tech-c: BS104-RIPE > status: ASSIGNED PA > remarks: Please send abuse notification to abuse@telecomitalia.it > notify: ripe-staff@telecomitalia.it > mnt-by: TIWS-MNT > changed: net_ti@telecomitalia.it 20020801 > source: RIPE > > but that may well be spoofed. > > The destination resloves to an interesting name (with only a AAAA RR): > rootk.it :-) > > I take this as a good sign that IPv6 is finally catching on ;-) > > -- > Alex > SWITCH-NOC > > > > > -- 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 Jul 12 11:53: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 LAA24632 for ; Sat, 12 Jul 2003 11:53:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bMds-00037v-Sj for v6ops-data@psg.com; Sat, 12 Jul 2003 15:50:32 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19bMd6-00033w-M9 for v6ops@ops.ietf.org; Sat, 12 Jul 2003 15:49:44 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 12 Jul 2003 08:49:14 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 12 Jul 2003 08:49:14 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 12 Jul 2003 08:49:14 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 12 Jul 2003 08:49:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 12 Jul 2003 08:49:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: first widely published relay as a dos issue Date: Sat, 12 Jul 2003 08:49:12 -0700 Message-ID: Thread-Topic: first widely published relay as a dos issue Thread-Index: AcNIc+eO5gxP1tutTXuv68zXnjpyxgAF8ESV From: "Christian Huitema" To: "Pekka Savola" Cc: "Randy Bush" , X-OriginalArrivalTime: 12 Jul 2003 15:49:13.0073 (UTC) FILETIME=[24288610:01C3488D] X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > But still, I think there's something to learn from this case. For > example: Absolutely! > - even relatively low traffic counts can harm at least some of the > deployed base =20 Yes, that looks like a real problem. It may be due to the relative = newness of some of the implementations. Maybe we need to have published = benchmarks...=20 > - (not mentioned here, but an issue in some other scenarios) IPv6 = traffic > may be free (for some), but IPv4 is not. So, some operators may be > hesitant to deploy or at least advertise a 6to4 relay -- this could = mean > they'd get in the harm's way because 6to4 relay would be doing > encapsulation (esp. if it would be a full fledged relay) =20 Using the anycast address makes your relay harder to target -- the = attacker does not know with certainty which relay will be hit! However, = it seems that we operators only have a limited control on who can use = their relay. Basically, the only real control is whether or not to = advertise a route in BGP. Once a relay is advertised to some neighbor = AS, there is no real mechanism to prevent re-advertisement. We may want = to study some solution. > - the fewer 6to4 relays there are, the more probable it is *your* = relay > gets in the way of a DoS attack.. :-/ We certainly need to deploy many more relays!=20 -- Christian Huitema From owner-v6ops@ops.ietf.org Sat Jul 12 12:44: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 MAA26909 for ; Sat, 12 Jul 2003 12:44:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bNT3-0005Dt-Q5 for v6ops-data@psg.com; Sat, 12 Jul 2003 16:43:25 +0000 Received: from [130.59.4.1] (helo=central.switch.ch) by psg.com with esmtp (Exim 4.14) id 19bNSY-0005DF-1W; Sat, 12 Jul 2003 16:42:54 +0000 Received: from enigma ([130.59.4.86] helo=enigma.switch.ch) by central.switch.ch with esmtp (Exim 3.20 #1) id 19bNSW-0006l5-00; Sat, 12 Jul 2003 18:42:52 +0200 To: "Christian Huitema" Cc: "Randy Bush" , Subject: Re: first widely published relay as a dos issue References: From: Alexander Gall Date: 12 Jul 2003 18:42:51 +0200 In-Reply-To: Message-ID: <9pfzlbae7o.fsf@switch.ch> Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.95 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 12 Jul 2003 05:30:26 -0700, "Christian Huitema" said: > How is that a "publshed relay DoS issue"? It seems that all these > packets had the same source and destination addresses, and that the > address could be traced. A plausible explanation is a bug in some > brand new software, without malicious intent; it is not necessarily > a DoS attack. I can't rule that out but it doesn't seem plausible to me. It looked like a typical UDP flood with random source and destination addresses. BTW, there were two other such incidents on Tuesday and Thursday with traffic rates up to 70-80Mbps (most of it was dropped by our relay). Apparently, most traffic came from the same IPv4 address, but there were also a few large flows from other sources, so it might have even been a DDoS (in which case some of the other anycast relays could have been hit as well). Unfortunately we don't know what the destinations were in those cases (we only have information on the IPv4 flows towards 192.88.99.1), so we can't make any statement about that. > It is also not specifically a relay attack. If those > two addresses were both native addresses, then we would have the > same attack against every IPv6 router on the path, it would just not > use the relay. I'm fairly sure that the relay was not the intended victim. The black hats might not have realized yet that there are still lots of bottlenecks in the 6bone. -- Alex SWITCH-NOC From owner-v6ops@ops.ietf.org Sat Jul 12 17:07: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 RAA11231 for ; Sat, 12 Jul 2003 17:07:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bRWf-000GwB-Jq for v6ops-data@psg.com; Sat, 12 Jul 2003 21:03:25 +0000 Received: from [62.189.30.6] (helo=tortoise.webcentre.net) by psg.com with esmtp (Exim 4.14) id 19bRW9-000Gum-QN for v6ops@ops.ietf.org; Sat, 12 Jul 2003 21:02:53 +0000 Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by tortoise.webcentre.net (8.9.3p2/8.9.3) with ESMTP id VAA14287 for ; Sat, 12 Jul 2003 21:38:23 +0100 (BST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA05619 for ; Sat, 12 Jul 2003 21:38:22 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id VAA25647 for ; Sat, 12 Jul 2003 21:38:21 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6CKcLL03406 for v6ops@ops.ietf.org; Sat, 12 Jul 2003 21:38:21 +0100 Date: Sat, 12 Jul 2003 21:38:21 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: comments on draft-palet-v6ops-proto41-nat-00.txt Message-ID: <20030712203821.GE2631@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <5.2.0.9.0.20030708193710.026992b8@mail.addr.com> <8EF960C7-B3C6-11D7-94DB-00039358A080@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EF960C7-B3C6-11D7-94DB-00039358A080@sun.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-33.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk But it's ideal for a home network. Our students in residential DSL homes use it for example. Tim On Fri, Jul 11, 2003 at 10:39:01AM -0700, Alain Durand wrote: > Proto 41 redirection as explain in this document cannot be demultiplex > and only works for the same number of tunnels as the number of external > IPv4 addresses. > So, if there is only one external IPv4 address, only one tunnel can be > set up. > Also, this obviously does not work very well in case of doubled-nated > network. > (I just happen to sit on one right now) > > - Alain. > From owner-v6ops@ops.ietf.org Sat Jul 12 18:10: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 SAA14707 for ; Sat, 12 Jul 2003 18:10:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bSXz-000Jp8-GY for v6ops-data@psg.com; Sat, 12 Jul 2003 22:08:51 +0000 Received: from [195.64.92.136] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 4.14) id 19bSXU-000JnS-45 for v6ops@ops.ietf.org; Sat, 12 Jul 2003 22:08:20 +0000 Received: from limbo (limbo.unfix.org [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 DC56D8024; Sat, 12 Jul 2003 23:13:49 +0200 (CEST) From: "Jeroen Massar" To: "'Tim Chown'" , Subject: RE: comments on draft-palet-v6ops-proto41-nat-00.txt Date: Sat, 12 Jul 2003 23:13:40 +0200 Organization: Unfix Message-ID: <008d01c348ba$86072d00$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.4510 In-Reply-To: <20030712203821.GE2631@login.ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Status: No, hits=-22.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > But it's ideal for a home network. Our students in > residential DSL homes use it for example. I think the majority of 6bone connectivity is proto41 tunnels. > On Fri, Jul 11, 2003 at 10:39:01AM -0700, Alain Durand wrote: > > Proto 41 redirection as explain in this document cannot be demultiplex > > and only works for the same number of tunnels as the number > > of external IPv4 addresses. > > So, if there is only one external IPv4 address, only one > > tunnel can be set up. > > Also, this obviously does not work very well in case of > > doubled-nated network. > > (I just happen to sit on one right now) Then you might want to redirect it twice ;) The other solution is digging vpn tunnels... Greets, Jeroen From owner-v6ops@ops.ietf.org Sun Jul 13 04:33: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 EAA03258 for ; Sun, 13 Jul 2003 04:33:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bcGI-000N3e-U3 for v6ops-data@psg.com; Sun, 13 Jul 2003 08:31:14 +0000 Received: from [81.160.207.94] (helo=dhcp1.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.14) id 19bcGE-000N3N-M3 for v6ops@ops.ietf.org; Sun, 13 Jul 2003 08:31:10 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h6D8V7KL009764; Sun, 13 Jul 2003 10:31:08 +0200 (CEST) Date: Sun, 13 Jul 2003 10:30:59 +0200 Subject: Re: IPv6 Operations WG (v6ops) agenda for IETF-57 Vienna - 2nd version Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Bob Fink" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B04284F7D@tayexc13.americas.cpqcorp.net> Message-Id: <54D9257E-B50C-11D7-A22A-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-18.3 required=5.0 tests=BAYES_20,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim, > Also we wanted > to just do brainstorming on multi6 and the ruling was we don't do > brainstorming in IETF meetings. if you are referring to my mail I think what I said was that doing this in a full group will be hard to manage and get useful output from. We will have an open mike session on Wednesday, which is close to what you suggested. I also said that there is pleaty of bars and hallways to continue the brainstorming in... Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPxEYx6arNKXTPFCVEQLWqQCglAdjRNIGy41Brw+hJaGq3Eyfuk4An1jk tY8an9O1pIxNAgSBXL1JfJOv =S/UL -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Sun Jul 13 08:57: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 IAA18326 for ; Sun, 13 Jul 2003 08:57:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bgNU-0007sC-0z for v6ops-data@psg.com; Sun, 13 Jul 2003 12:54:56 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19bgNP-0007rw-NC for v6ops@ops.ietf.org; Sun, 13 Jul 2003 12:54:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6DCsn422291 for ; Sun, 13 Jul 2003 15:54:49 +0300 Date: Sun, 13 Jul 2003 15:54:48 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: comments on roy-v6ops-v6onbydefault-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-7.3 required=5.0 tests=BAYES_30,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi authors, the rest of the WG, Thanks for putting together this document, and revising it extensively. I believe it's of excellent quality and very important for the WG. Hopefully we'll have good discussion on this (and other operational aspects) in the second v6ops session in Vienna. I've some comments on the draft. Four generic notes first: - Sections 2.1 and 2.2 cover two rather interrelated problems. There seems to be some overlapping text, and I keep thinking of ways to handle/organize these two that would seem a bit more fluent (even though it's rather good as is). - Section 2.2 (and the last paragraph of 2.2.1) bashes the "all destinations are on link by default" Neighbor Discovery rule pretty extensively, and I agree with it. However, I imagine there are legitimate reasons why people thought it was a good idea. We should get some idea of the tradeoffs (even though they would not belong to this particular document -- see below). - In Section 2 in particular, you bring out one example of default address selection failing. It would be very useful to try to analyze whether this might happen in some other cases as well, and if not, state so explicitly. That way we can get the issues in the right proportions. It might also be interesting to know if there are any issues with destination address selection in systems that don't (yet) impletement it as specified in RFC3484 (it's more difficult than doing src address selection..). We're an operations WG after all ;-) - There are some suggested modifications e.g. to ND, but there are no firm conclusions section at least -- which would bring these points together, and discuss pros and cons of these proposals. Of course, one could argue that these are out of scope of this document, and we should write (or urge ipv6 wg to do that) a short separate I-D on the pros and cons of such modifications. (I.e. it would be nice if it would be very explicit what we'd like to do with to fix these issues -- if we know that yet) substantial ----------- The Default Address Selection for IPv6 [ADDRSEL] destination address selection mechanism could save the application a few useless connection attempts by placing the IPv4 addresses in front of the IPv6 addresses. This would be desired since all IPv6 destinations in this scenario are unreachable (there's no route to them), and the system's only IPv6 source address is inadequate to communicate with off-link destinations even if it did have an off-link route. ==> the comment (there's no route to them) is incorrect: there _is_ a route to them -- the mandated default IPv6 route pointing to the Ethernet interface! Now, after thinking a bit this seems like a tricky issue, and we have to be sure the terminology and the context is clear. At least some implementations add a default route of a very low metric (overridden by everything else) to point to Interfaces like this. Maybe some other implementations do this differently? The destinations are still unreachable, though -- but the reason is that the Neighbor Discovery will fail to those addresses (note: this is much worse than having no (effective) route at all, because it incurs a longer timeout). Fixing the destination address selection mechanism by adding such a rule is only a mitigating factor if applications use standard name resolution API's that implement this mechanism, and these applications try addresses in the order returned. This may not be an acceptable assumption in some cases, as there are applications that use hard coded addresses and address search orders (DNS resolver is one example), and/or literal addresses passed in from the user. ==> I'm having trouble with about "address search orders (DNS resolver is one example)". Isn't destination address selection implemented in the getaddrinfo which acts as an intermediary to the entries returned by the DNS resolver? AFAICS, if applications use standard name resolution API's, there is no problem. If they implement their own hacks (including the address ordering), there are likely to be problems. Or am I just misunderstanding the point here? 2.3 Transport Protocol Robustness ==> this section discusses transport protocols in general for one paragraph, and dedicates the rest to TCP. Should UDP discussed explicitly (it may be that there are fewer issues with UDP, though)? 3.2.1 Dealing with Poor IPv6 Network Performance There are few options from the end node's perspective. One is to configure each node to prefer IPv4 destinations over IPv6. If hosts implement the Default Address Selection for IPv6 [ADDRSEL] policy table, IPv4 mapped addresses could be assigned higher precedence, resulting in applications trying IPv4 for communication first. This has the negative side-effect that these nodes will almost never use IPv6 unless the only address published in the DNS for a given name is IPv6, presumably because of this phenomenon. Disabling IPv6 on the end nodes is another solution. The idea would be that enabling IPv6 on dual stack nodes is a manual process that would be done when the administrator knows that IPv6 connectivity is adequate. ==> another solution could be inserting such preference for IPv4, but giving even higher preference to _some_ IPv6, e.g. the site's own /48 prefix, the ISP's prefix, or whatever seems to be topologically reasonable. (Actually, one could possibly implement this by the more specific routes and preferences thing, if it would be possible to disable the default route configuration phase based on some toggle. But I'm not sure if this is the right approach.) The problem here is that currently this seems to be a on/off thing; either *all* (or at least a significant number of them) destinations that are used should be good enough, or no support at all can be enabled. We need to fix this, make it easier to adjust the preferences to a bit more fine-grained than a binary toggle. 3.3.1 Mitigating Security Risks ==> please add a sentence or two on how you think the VPN software should react in this case. Deny unknown protocols by defaul unless there is a configuration option to let them be? 5. Security Considerations This document raises security concerns in Section 3.3. ==> still, could you try to summarize the issues in section 3.3 in one or two short paragraphs? I think that would be a good practice. editorial --------- It begins in Section 2 by examining problems within IPv6 ==> s/It/This memo/ succeeds. Since the system has no off-link IPv6 routes, the optimal scenario would be if the IPv4 addresses returned were ordered before the IPv6 addresses. The following sections describe where things can ==> s/has no off-link IPv6 routes/has only on-link IPv6 connectivity/ address. Since [ADDRSEL] considers private addresses (as defined in [PRIVADDR]) of site-local scope, ==> s/considers/considers to be/ ? It is therefore important that the system quickly determine that the IPv6 destination is unreachable so that the application can try the IPv4 destination. ==> s/try/fall back and try/ (it's already rather clear, but just to drive the point home, as there are also issues with that fallback in the applications side..) on-link until at least address resolution has failed, which is no less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), plus ==> that's four seconds (first try, wait a second, plus 3 retransmissions, after each 1 second delay [nowhere it is defined how long you have to wait after the last retransmission, but I assume RETRANS_TIMER is a safe value]). (same for 45 -> 60 seconds) If hosts need to communicate with on-link destinations, then then they need to be explicitly configured to have on-link routes for those destinations. ==> reword this slightly and/or combine with the earlier paragraph so that it is clear that this paragraph would be applicable in the scenario if the onlink rule would be removed from the Neighbor Discovery. One problem is that default routes are not special. The on-link assumption as stated in [ND] would have a host assume that all destinations are on-link when its default router list is empty. Clearly it shouldn't make this assumption if it has an off-link route that covers the destination and that route isn't a default route. The absence of a default route does not mean that destinations are not reachable through more specific routes. ==> one might clarify even a bit further that this may be the case e.g. when a host is explicitly configured to have routes to only a specific set of addresses (e.g. the /48 prefix of the site). We certainly have done so as (one) security mechanism in IPv4 for e.g. backup and NFS servers. traffic), IPv6 packets could go through the network untouched if tunneled over a transport layer. This could open the host to direct ==> s/layer/protocol, such as UDP/ A similar problem could exist for VPN software. A VPN could protect all IPv4 packets but drop all others onto the local subnet unprotected. ==> reword "drop all others .." slightly, e.g. "but not understand anything about other protocols, and leave them send them on to the local subnet unprotected." Enabling IPv6 on a dual stack node is only useful if applications that support IPv6 on that node properly cycle through addresses returned from name lookups and fall back to IPv4 when IPv6 ==> s/cycle/loop/ (cycle is fine too, but loop is what I've heard the most often and it's better to try to use the same terminology) -- 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 Jul 13 10:32: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 KAA25412 for ; Sun, 13 Jul 2003 10:32:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19bhsY-000CHB-0Z for v6ops-data@psg.com; Sun, 13 Jul 2003 14:31:06 +0000 Received: from [131.115.230.132] (helo=tms001bb.han.telia.se) by psg.com with esmtp (Exim 4.14) id 19bhsV-000CGv-Pb for v6ops@ops.ietf.org; Sun, 13 Jul 2003 14:31:03 +0000 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Sun, 13 Jul 2003 16:31:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on draft-lind-v6ops-isp-scenarios-00.txt Date: Sun, 13 Jul 2003 16:31:01 +0200 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE837CF33@TMS031MB.tcad.telia.se> Thread-Topic: comments on draft-lind-v6ops-isp-scenarios-00.txt Thread-Index: AcNH0WYLF6hp84SaRVGdtRGm7ffdawBeViBU From: To: , X-OriginalArrivalTime: 13 Jul 2003 14:31:01.0905 (UTC) FILETIME=[626AD810:01C3494B] X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >Are future revision of this document going to address the pros and cons >of both approaches?=20 No, it will be done in the solutions document that will follow the = scenarios document. =20 >Are we expecting a companion document that >will explain how to implement both approaches? Yes, it will be done in the solutions document. /Mikael From owner-v6ops@ops.ietf.org Mon Jul 14 07:59: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 HAA13404 for ; Mon, 14 Jul 2003 07:59:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19c1vN-000Le7-AD for v6ops-data@psg.com; Mon, 14 Jul 2003 11:55:21 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19c1vJ-000Ldu-2I for v6ops@ops.ietf.org; Mon, 14 Jul 2003 11:55:17 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6EBtGJg015688 for ; Mon, 14 Jul 2003 05:55:16 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI0009INJS3BC@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 14 Jul 2003 05:55:16 -0600 (MDT) Received: from sun.com ([81.160.135.242]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI0000UBJS1WC@mail.sun.net> for v6ops@ops.ietf.org; Mon, 14 Jul 2003 05:55:15 -0600 (MDT) Date: Mon, 14 Jul 2003 04:55:14 -0700 From: Alain Durand Subject: Re: comments on roy-v6ops-v6onbydefault-01 In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <079B87E1-B5F2-11D7-8724-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-28.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Sunday, July 13, 2003, at 05:54 AM, Pekka Savola wrote: > Hi authors, the rest of the WG, > > Thanks for putting together this document, and revising it extensively Thank you for reading it carefully. > . I > believe it's of excellent quality and very important for the WG. > Hopefully we'll have good discussion on this (and other operational > aspects) in the second v6ops session in Vienna. > > I've some comments on the draft. Four generic notes first: > > - Sections 2.1 and 2.2 cover two rather interrelated problems. There > seems > to be some overlapping text, and I keep thinking of ways to > handle/organize > these two that would seem a bit more fluent (even though it's rather > good as is). We have been trying to find a better way without much success. Suggestions welcome. > > - Section 2.2 (and the last paragraph of 2.2.1) bashes the "all > destinations > are on link by default" Neighbor Discovery rule pretty extensively, > and I > agree with it. However, I imagine there are legitimate reasons why > people > thought it was a good idea. We should get some idea of the tradeoffs > (even > though they would not belong to this particular document -- see below). Yes. I talked about this with Erik Nordmark, we have to build a case that present both the useful side and the harmful sides of this on-link assumption. For now, it seems the the useful side is pretty narrow. We will do that in the next revision of the draft (or in a separate draft) > > - In Section 2 in particular, you bring out one example of default > address > selection failing. It would be very useful to try to analyze whether > this > might happen in some other cases as well, and if not, state so > explicitly. > That way we can get the issues in the right proportions. The default address selection rules are so complex that is is difficult to do a full analysis. We stumbled on this one while doing real deployment. > It might also be interesting to know if there are any issues with > destination address selection in systems that don't (yet) implement it > as specified in RFC3484 (it's more difficult than doing src address > selection..). We're an operations WG after all ;-) Well, we first discovered the issue on a system that was not (yet) implementing the default address selection. But as this is (was) not standardized anywhere, I'm not sure if there is any value in analyzing this any further... > - There are some suggested modifications e.g. to ND, but there are no > firm > conclusions section at least -- which would bring these points > together, and > discuss pros and cons of these proposals. Of course, one could argue > that > these are out of scope of this document, and we should write (or urge > ipv6 > wg to do that) a short separate I-D on the pros and cons of such > modifications. This is by design. We first would like to report to the ops community that there are serious problems. One we will agree on that, it will be time to make recommendations. > (I.e. it would be nice if it would be very explicit what we'd like to > do with to fix these issues -- if we know that yet) I'll suggest to ways to go forward during the meeting. > > substantial > ----------- > > The Default Address Selection for IPv6 [ADDRSEL] destination address > selection mechanism could save the application a few useless > connection attempts by placing the IPv4 addresses in front of the > IPv6 addresses. This would be desired since all IPv6 destinations > in > this scenario are unreachable (there's no route to them), and the > system's only IPv6 source address is inadequate to communicate with > off-link destinations even if it did have an off-link route. > > ==> the comment (there's no route to them) is incorrect: > there _is_ a route to them -- the mandated > default IPv6 route pointing to the Ethernet interface! > > Now, after thinking a bit this seems like a tricky issue, and we have > to > be sure the terminology and the context is clear. At least some > implementations add a default route of a very low metric (overridden by > everything else) to point to Interfaces like this. Maybe some other > implementations do this differently? > > The destinations are still unreachable, though -- but the reason is > that > the Neighbor Discovery will fail to those addresses (note: this is much > worse than having no (effective) route at all, because it incurs a > longer > timeout). > > Fixing the destination address selection mechanism by adding such a > rule is only a mitigating factor if applications use standard name > resolution API's that implement this mechanism, and these > applications try addresses in the order returned. This may not be > an > acceptable assumption in some cases, as there are applications that > use hard coded addresses and address search orders (DNS resolver is > one example), and/or literal addresses passed in from the user. > > ==> I'm having trouble with about "address search orders (DNS resolver > is > one example)". Isn't destination address selection implemented in the > getaddrinfo which acts as an intermediary to the entries returned by > the DNS > resolver? AFAICS, if applications use standard name resolution API's, > there > is no problem. If they implement their own hacks (including the > address > ordering), there are likely to be problems. > > Or am I just misunderstanding the point here? You're right. Text need to be clarified a bit. > > 2.3 Transport Protocol Robustness > > ==> this section discusses transport protocols in general for one > paragraph, > and dedicates the rest to TCP. Should UDP discussed explicitly (it may > be that there are fewer issues with UDP, though)? Good point. We made some measurement with UDP, it is not as severe as TCP but it is far from acceptable. > > 3.2.1 Dealing with Poor IPv6 Network Performance > > There are few options from the end node's perspective. One is to > configure each node to prefer IPv4 destinations over IPv6. If hosts > implement the Default Address Selection for IPv6 [ADDRSEL] policy > table, IPv4 mapped addresses could be assigned higher precedence, > resulting in applications trying IPv4 for communication first. This > has the negative side-effect that these nodes will almost never use > IPv6 unless the only address published in the DNS for a given name > is > IPv6, presumably because of this phenomenon. > > Disabling IPv6 on the end nodes is another solution. The idea would > be that enabling IPv6 on dual stack nodes is a manual process that > would be done when the administrator knows that IPv6 connectivity is > adequate. > > ==> another solution could be inserting such preference for IPv4, but > giving even higher preference to _some_ IPv6, e.g. the site's own /48 > prefix, the ISP's prefix, or whatever seems to be topologically > reasonable. If and only if there is a simple way to express the list of "reachable" prefixes... Then you have the issue to distribute that list to all the internal nodes... tricky. For example, in our deployment, we use a number (10-20) /48 6to4 derived prefixes and the list keep expanding. > (Actually, one could possibly implement this by the more specific > routes > and preferences thing, if it would be possible to disable the default > route configuration phase based on some toggle. But I'm not sure if > this > is the right approach.) > > The problem here is that currently this seems to be a on/off thing; > either *all* > (or at least a significant number of them) destinations that are used > should be good enough, or no support at all can be enabled. We need > to fix > this, make it easier to adjust the preferences to a bit more > fine-grained > than a binary toggle. I'm not sure how to achieve this.... See previous comment. > > 3.3.1 Mitigating Security Risks > > ==> please add a sentence or two on how you think the VPN software > should > react in this case. Deny unknown protocols by defaul unless there is a > configuration option to let them be? It is not clear at all to me what should be done. One could sent all unknown packets either to the bit bucket or to the other side of the VPN... Not sure which is best. > > 5. Security Considerations > > This document raises security concerns in Section 3.3. > > ==> still, could you try to summarize the issues in section 3.3 in one > or > two short paragraphs? I think that would be a good practice. > ok for next revision. Thanks again for the detailed review. - Alain. > editorial > --------- > > It begins in Section 2 by examining problems within IPv6 > > ==> s/It/This memo/ > > succeeds. Since the system has no off-link IPv6 routes, the optimal > scenario would be if the IPv4 addresses returned were ordered before > the IPv6 addresses. The following sections describe where things > can > > ==> s/has no off-link IPv6 routes/has only on-link IPv6 connectivity/ > > address. Since [ADDRSEL] considers private addresses (as defined in > [PRIVADDR]) of site-local scope, > > ==> s/considers/considers to be/ ? > > It is therefore important that the system quickly > determine that the IPv6 destination is unreachable so that the > application can try the IPv4 destination. > > ==> s/try/fall back and try/ (it's already rather clear, but just to > drive > the point home, as there are also issues with that fallback in the > applications side..) > > on-link until at least address resolution has failed, which is no > less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), > plus > > ==> that's four seconds (first try, wait a second, plus 3 > retransmissions, > after each 1 second delay [nowhere it is defined how long you have to > wait > after the last retransmission, but I assume RETRANS_TIMER is a safe > value]). > (same for 45 -> 60 seconds) > > If hosts need to communicate with on-link destinations, then then > they need to be explicitly configured to have on-link routes for > those destinations. > > ==> reword this slightly and/or combine with the earlier paragraph so > that > it is clear that this paragraph would be applicable in the scenario if > the > onlink rule would be removed from the Neighbor Discovery. > > One problem is that default routes are not special. The on-link > assumption as stated in [ND] would have a host assume that all > destinations are on-link when its default router list is empty. > Clearly it shouldn't make this assumption if it has an off-link > route > that covers the destination and that route isn't a default route. > The absence of a default route does not mean that destinations are > not reachable through more specific routes. > > ==> one might clarify even a bit further that this may be the case e.g. > when a host is explicitly configured to have routes to only a specific > set of addresses (e.g. the /48 prefix of the site). We certainly have > done > so as (one) security mechanism in IPv4 for e.g. backup and NFS servers. > > traffic), IPv6 packets could go through the network untouched if > tunneled over a transport layer. This could open the host to direct > > ==> s/layer/protocol, such as UDP/ > > A similar problem could exist for VPN software. A VPN could protect > all IPv4 packets but drop all others onto the local subnet > unprotected. > > ==> reword "drop all others .." slightly, e.g. "but not understand > anything > about other protocols, and leave them send them on to the local subnet > unprotected." > > Enabling IPv6 on a dual stack node is only useful if applications > that support IPv6 on that node properly cycle through addresses > returned from name lookups and fall back to IPv4 when IPv6 > > ==> s/cycle/loop/ (cycle is fine too, but loop is what I've heard the > most > often and it's better to try to use the same terminology) > > -- > 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 Jul 15 01:47:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07915 for ; Tue, 15 Jul 2003 01:47:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cIch-000DyR-Ga for v6ops-data@psg.com; Tue, 15 Jul 2003 05:45:11 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cIcc-000Dxf-2h for v6ops@ops.ietf.org; Tue, 15 Jul 2003 05:45:06 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 6A33CCADB for ; Mon, 14 Jul 2003 17:07:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 14 Jul 2003 17:07:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: draft-roy-v6ops-v6onbydefault-01.txt Date: Mon, 14 Jul 2003 17:07:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047C9E08@tayexc13.americas.cpqcorp.net> Thread-Topic: draft-roy-v6ops-v6onbydefault-01.txt Thread-Index: AcNKRm4kN4jHRfEHQf+z1dnfEJZNaQAACPWA From: "Bound, Jim" To: X-OriginalArrivalTime: 14 Jul 2003 21:07:24.0103 (UTC) FILETIME=[EC200570:01C34A4B] X-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Roy, Alain, and Jim, Do you perceive this work as BCP? Or Info RFC? If accepted and worked on? This work is asking very good deployment and implementation questions. Comments in line. > Abstract >=20 > This document discusses problems that can occur when dual=20 > stack nodes > that have IPv6 enabled by default are deployed in IPv4 or=20 > mixed IPv4 > and IPv6 environments. The problems include application connection > delays, poor connectivity, and network security. Its purpose is to > raise awareness of these problems so that they can be=20 > fixed or worked > around. Do you mean dual stack or dual IP layer. Most implementations I am aware of are dual IP layer. There is a huge difference. This is important for clarity for the rest of the document. =20 >=20 > > 1. Introduction >=20 > This document specifically addresses operating system=20 > implementations > that implement the dual stack IPv6 model, and would ship with IPv6 We and others have implemented a dual IP layer not a dual stack. So this does not apply to us and others (yes wearing my HP hat on this comment)??? We don't have tcp4 and tcp6 is the bottom line. =20 I am just trying to make a point we have this error throughout the IETF and other forums dealing with standards and deployment. Not many did a pure dual stack at all. > enabled by default. It addresses the case where such a system is > installed and placed in an IPv4 only or mixed IPv4 and IPv6 > environment, and documents potential problems that users on such > systems could experience if the IPv6 connectivity is=20 > non-existent or > sub-optimal. So this work does not apply to a network where IPv6 is robust and dominant? =20 Or even equivalent with IPv4? Meaning it only applies when a few subnets are doing IPv6 in a large IPv4 cloud or network? > 2. No IPv6 Router >=20 > Consider a scenario in which a dual stack system has IPv6=20 > enabled and > placed on a link with no IPv6 routers. The system is using IPv6 > Stateless Address Autoconfiguration [AUTOCONF], so it only has a > link-local IPv6 address configured. It also has a single IPv4 > address that happens to be a private address as defined in > [PRIVADDR]. >=20 > An application on this system is trying to communicate with a > destination whose name resolves to public and global IPv4 and IPv6 > addresses. The application uses an address resolution API that > implements the destination address selection mechanism described in > Default Address Selection for IPv6 [ADDRSEL]. The application will > attempt to connect to each address returned in order until one > succeeds. Since the system has no off-link IPv6 routes,=20 > the optimal > scenario would be if the IPv4 addresses returned were=20 > ordered before > the IPv6 addresses. The following sections describe where=20 > things can > go wrong with this scenario. I agree that the optimization above for this case would be useful or order IPv4 is wise. This points to tools we need for transiton I think as a note and a failing in ADDRSEL. >=20 > 2.1 Problems with Default Address Selection for IPv6 >=20 > The Default Address Selection for IPv6 [ADDRSEL]=20 > destination address > selection mechanism could save the application a few useless > connection attempts by placing the IPv4 addresses in front of the > IPv6 addresses. This would be desired since all IPv6=20 > destinations in > this scenario are unreachable (there's no route to them), and the > system's only IPv6 source address is inadequate to communicate with > off-link destinations even if it did have an off-link route. Anyone who implements ADDRSEL should permit it to be configurable. This could be an additional configuration correct? Thus problem solved right ? But the default rules are up for debate again I think? . >=20 > 2.2 Neighbor Discovery's On-Link Assumption Considered Harmful >=20 > Let's assume that the application described in Section 2 is > attempting a connection to an IPv6 address first, either=20 > because the > destination address selection mechanism described in Section 2.1 > returned the addresses in that order, or because the application > isn't trying the addresses in the order returned. Regardless, the > user expects that the application will quickly connect to the > destination. It is therefore important that the system quickly > determine that the IPv6 destination is unreachable so that the > application can try the IPv4 destination. >=20 > Neighbor Discovery's [ND] conceptual sending algorithm=20 > dictates that > when sending a packet to a destination, if a host's default router > list is empty, then the host assumes that the destination=20 > is on-link. Note this is a conceptual algorithm not a standards requirement. This is important to note to all. I don't assume this at all fyi. >=20 > For an IPv6 enabled host deployed on a network that has no IPv6 > routers as is the case in this scenario, the result is that > link-layer address resolution must be performed on all=20 > IPv6 addresses > to which the host sends packets. The Application will not receive > acknowledgment of the unreachability of destinations that are not > on-link until at least address resolution has failed, which is no > less than three seconds (MAX_MULTICAST_SOLICIT *=20 > RETRANS_TIMER), plus > any transport layer connection timeouts which could be=20 > minutes in the > case of TCP. The delay with respect to TCP is discussed later in > Section 2.3. But what is your point here or just setting up assumptions? If there is not router on the link and one sends to send to global an implementation should catch that and simply not send the packet. Of course I advocate smart hosts for v4 or v6 and don't agree with dumb hosts. The code to do this is trivial even on sensor device with low real estate for the stack. >=20 > On a network that has no IPv6 routing and no IPv6 neighbors, making > the assumption that every IPv6 destination is on-link will be a > costly and incorrect assumption. If an application has a list of > addresses associated with a destination and the first 15 are IPv6 > addresses, then the application won't be able to=20 > successfully send a > packet to the destination until the attempts to resolve each IPv6 > address have failed (45 seconds), which could be compounded by any > transport timeouts associated with each connection attempt. Same comment as above. But it is good to document this and I don't agree. I guess to me this is common sense networking 101 or IPv6 for dummies. Maybe an IPv6 for Dummies book would be good to write to cover many of these cases. And vendors who don't protect users from this will die anyway and may not even pass the IPv6 Logo requirements via the IPv6 Forum............... >=20 > If IPv6 hosts don't assume that destinations are on-link=20 > as described > above, then communication with destinations that are not=20 > on-link and > unreachable will immediately fail. The IPv6=20 > implementation should be > able to immediately notify applications that it has no=20 > route to such > IPv6 destinations, and applications won't waste time waiting for > address resolution to fail. >=20 > If hosts need to communicate with on-link destinations, then then > they need to be explicitly configured to have on-link routes for > those destinations. This is something I agree with but that will not fly in the IETF is my input to you. Any smart implementation does this now. To not do it is stupid. The prevailing view in the IETF is that hosts are stupid and that is the first thing to fix and that is the IETF prevailing view that hosts are stupid. Nice theory but will not work in practice. Must have been router vendors that pushed this view :--) (thats a joke). >=20 > 2.2.1 Other Problems with the On-Link Assumption >=20 > The on-link assumption is problematic in ways not directly=20 > related to > the scenario described, but they should still be briefly mentioned > here. >=20 > One problem is that default routes are not special. The on-link > assumption as stated in [ND] would have a host assume that all > destinations are on-link when its default router list is empty. > Clearly it shouldn't make this assumption if it has an=20 > off-link route > that covers the destination and that route isn't a default route. > The absence of a default route does not mean that destinations are > not reachable through more specific routes. I do not make that assumption if the onlink prefix is set is the only time I assume that as code developer reading the spec. That is bad read of the specification and I don't see this assumption at all. But I see your point. >=20 > Another problem is that the on-link assumption behavior is=20 > undefined > on multi-homed hosts. When such a host has no default=20 > routers and it > is trying to reach a destination to which it has no route,=20 > should it > try NUD on all interfaces at once? Should it simply=20 > realize that the > destination is unreachable? The latter is the simplest solution. > Determining that a destination is unreachable when there=20 > is no route > to that destination is the simple solution for all cases, not just > the multi-homed case. Same comment as above. >=20 > 2.3 Transport Protocol Robustness >=20 > Making the same set of assumptions as Section 2.2,=20 > regardless of how > long the network layer takes to determine that the IPv6 destination > is unreachable, the delay associated with a connection=20 > attempt to an > unreachable destination can be compounded by the transport=20 > layer. In > order for our application to quickly fail from an=20 > unreachable address > to a potentially reachable one, the transport layer should=20 > notify the > application by failing a connection attempt, or passing=20 > ICMPv6 errors > up to the application, etc... Nothing should go over IP layer in v4 or v6 that don't have a route if not on link and mulltiple ways to test if node is onlink anyway in any stack implementation. > 3.1 IPv6 Network of Smaller Scope >=20 > A network that has a smaller scope of connectivity for IPv6 as it > does for IPv4 could be a problem in some cases. If=20 > applications have > access to name to address mapping information that is of greater > scope than the connectivity to those addresses, there is obvious > potential for suboptimal network performance. Hosts will=20 > attempt to > communicate with IPv6 destinations that are outside the=20 > scope of the > IPv6 routing, and depending on how the scope boundaries=20 > are enforced, > applications may not be notified that packets are being dropped at > the scope boundary. Clearly a low end IPv6 network in IPv4 cloud has to be configured wisely. Would it not be better to have INFO or BCP on configuring IPv6 in the particular cases you reference in this specification? > 3.1.1 Alleviating the Scope Problem >=20 > To allow applications to correctly fall back to IPv4 when IPv6 > packets are destined beyond their allowed scope, the devices > enforcing the scope boundary should send ICMPv6 Destination > Unreachable messages back to senders of such packets. The sender's > transport layer should act on these errors as described in Section > 2.3. This should be an entire draft and subject by itself IMO. The scope is to large to even be in a spec as just a paragraph and some minor text. Needs its own draft.=20 >=20 > 3.2 Poor IPv6 Network Performance >=20 > By default in dual stack nodes, applications will try IPv6 > destinations first. If the IPv6 connectivity to those destinations > is poor while the IPv4 connectivity is better (i.e., the=20 > IPv6 traffic > experiences higher latency, lower throughput, or more lost packets > than IPv4 traffic), applications will still communicate=20 > over IPv6 at > the expense of network performance. There is no information > available to applications in this case to advise them to=20 > try another > destination address. But any good IPv6 implementation will give the user the option of configuring these mechanisms over time with deployment. > 3.2.1 Dealing with Poor IPv6 Network Performance >=20 > There are few options from the end node's perspective. One is to > configure each node to prefer IPv4 destinations over IPv6.=20 > If hosts > implement the Default Address Selection for IPv6 [ADDRSEL] policy > table, IPv4 mapped addresses could be assigned higher precedence, > resulting in applications trying IPv4 for communication first. This > has the negative side-effect that these nodes will almost never use > IPv6 unless the only address published in the DNS for a=20 > given name is > IPv6, presumably because of this phenomenon. This is my entire issue with ADDRSEL and why I do not advocate implementing it at this time in pre-production or production IPv6 networks (fine for research test beds). It is not baked yet and did not consider all the issues this draft points to clearly. I applaud this draft bringing this out and we need to think about the effect of ADDRSEL as a default too. =20 I think this work can spawn at least 3 drafts (and more) that we need to work on. 1. Configuring IPv6 nodes in variant IPv4 and IPv6 networks. 2. Things to watch out for when deploying IPv6. 3. Smart things IPv6 implementations should do when no IPv6 router exists. Good brainstorming on deployment issues too. Thanks /jim From owner-v6ops@ops.ietf.org Tue Jul 15 03:58: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 DAA01571 for ; Tue, 15 Jul 2003 03:58:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cKgQ-000Mej-Da for v6ops-data@psg.com; Tue, 15 Jul 2003 07:57:10 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.14) id 19cKgM-000MdZ-Bz for v6ops@ops.ietf.org; Tue, 15 Jul 2003 07:57:06 +0000 Received: (qmail 29789 invoked by uid 2502); 14 Jul 2003 10:09:54 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.135857 secs); 14/07/2003 11:09:54 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Jul 2003 10:09:53 -0000 Date: Mon, 14 Jul 2003 11:09:53 +0100 (WEST) From: Carlos Friacas To: v6ops@ops.ietf.org Subject: More comments on draft-palet-v6ops-proto41-nat-00.txt In-Reply-To: <008d01c348ba$86072d00$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-10.5 required=5.0 tests=BAYES_30,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello All, I have some questions: [1, Introduction] + "routers or tunnel servers" ~= "tunnel brokers" ? "(...) with a manual configuration at the IPv6 router tunnel-end." It isnt feasible for a service you intend to sell. using manual configurations on routers simply isnt scalable. + reference to [3] I still dont understand why a project focused on Internet Exchanges (IXPs/NAPs/...) may have anything to do with NAT boxes and tunnels. End-users shouldnt be a topic. People managing networks, BGP and AS numbers should. + "big opportunity to rapidly deploy a huge number of nodes and networks" You mean, nodes of tunnel brokers? networks? ...using a router as a NAT client? it may seem as a good "hack idea" to use a laptop for this. a theoretical question -- does the community want rapid deployment? with high RTTs and high chance of self-denial-of-service ? ...or is it a way to kill IPv6 faster? + last paragraph You are listing the need to: - change tunnel brokers - change something in some operating systems (which ones?) Wouldnt be easier to v6-ize the NAT boxes? (dont know if it would be a good idea, as we dont need NAT boxes in the native IPv6 world...) [4, Applicability] + "The most usual scope of application of this technology seems to be SOHO and home environments, but is not limited to these." Do you mind to specify more environments? I think it would be important to specify, if they exist. [5, NAT design considerations] + "New firmware/software versions of the NAT implementations should ensure the support of protocol-41 forwarding." I would add: ", and the means for its administrator to turn it on and off". As an example, we wouldnt want anyone using a connection to a tunnel broker if native IPv6 is available on the wire/air. Mandatory support for protocol-41 forwarding seems unnappropriate, as tunnels usage will fade away (as a method of getting IPv6 connectivity). [7, Security] + (more) The mechanism of forwarding protocol 41 might be considered a serious security issue in some organizations. Those wanting to restrict access to some applications/networks for instance. They can/do provide IPv4 and native IPv6, but with a well-defined set of filtering rules. Using (standardizing) a mecanism that permits clients to override the set of rules seems dangerous. If vendors start(or continue) to permit forwarding of protocol 41 in their factory defaults (expressely or somewhat hidden) ops people can have a new plague to toy around, when native (and filtered) IPv6 is in place. Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!" From owner-v6ops@ops.ietf.org Tue Jul 15 05:37: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 FAA10545 for ; Tue, 15 Jul 2003 05:37:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cMDq-0002Ly-Qv for v6ops-data@psg.com; Tue, 15 Jul 2003 09:35:46 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19cMDo-0002Lj-Bn for v6ops@ops.ietf.org; Tue, 15 Jul 2003 09:35:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6F9Zg709699 for ; Tue, 15 Jul 2003 12:35:42 +0300 Date: Tue, 15 Jul 2003 12:35:41 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: v6 security: covert channel through DstOptions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, FYI, FWIW, I came across this: http://net.suug.ch/articles/2003/07/06/ip6msg.html .. where someone has hacked a system to pass data between the endpoints embedded in unrecognized IPv6 destination options. Nothing new there, but now it has gone operational. However the attacks could be much more nastier too. Similar issues have already been discussed in: http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-01.txt -- 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 Jul 15 06:20: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 GAA12504 for ; Tue, 15 Jul 2003 06:20:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cMtT-0004sZ-FA for v6ops-data@psg.com; Tue, 15 Jul 2003 10:18:47 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.14) id 19cMtR-0004sL-BB for v6ops@ops.ietf.org; Tue, 15 Jul 2003 10:18:45 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 9C61413; Tue, 15 Jul 2003 19:18:37 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Tue, 15 Jul 2003 12:35:41 +0300. 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: v6 security: covert channel through DstOptions From: itojun@iijlab.net Date: Tue, 15 Jul 2003 19:18:37 +0900 Message-Id: <20030715101837.9C61413@coconut.itojun.org> X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >FYI, FWIW, I came across this: > >http://net.suug.ch/articles/2003/07/06/ip6msg.html > >.. where someone has hacked a system to pass data between the endpoints >embedded in unrecognized IPv6 destination options. Nothing new there, but >now it has gone operational. > >However the attacks could be much more nastier too. another URL (i don't have one with me now) noted that it is a covered channel. i'm not sure if we can really *attack* other system with this. itojun From owner-v6ops@ops.ietf.org Tue Jul 15 06:23: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 GAA12629 for ; Tue, 15 Jul 2003 06:23:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cMxh-000578-UX for v6ops-data@psg.com; Tue, 15 Jul 2003 10:23:09 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19cMxf-00056k-JX for v6ops@ops.ietf.org; Tue, 15 Jul 2003 10:23:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6FAN1I10137; Tue, 15 Jul 2003 13:23:01 +0300 Date: Tue, 15 Jul 2003 13:23:01 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: v6 security: covert channel through DstOptions In-Reply-To: <20030715101837.9C61413@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 15 Jul 2003 itojun@iijlab.net wrote: > >FYI, FWIW, I came across this: > > > >http://net.suug.ch/articles/2003/07/06/ip6msg.html > > > >.. where someone has hacked a system to pass data between the endpoints > >embedded in unrecognized IPv6 destination options. Nothing new there, but > >now it has gone operational. > > > >However the attacks could be much more nastier too. > > another URL (i don't have one with me now) noted that it is a > covered channel. i'm not sure if we can really *attack* other system > with this. Yes, indeed -- this is a method of covert channel creation only. (Perhaps I should not have used the word "hacked [up]" to refer to coding a mechanism from the RFC2460 specification.) -- 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 Jul 15 10:56: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 KAA22884 for ; Tue, 15 Jul 2003 10:56:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRAv-000KC4-Rz for v6ops-data@psg.com; Tue, 15 Jul 2003 14:53:05 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19cRAt-000KBq-Mm for v6ops@ops.ietf.org; Tue, 15 Jul 2003 14:53:03 +0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6FEr3iR005791 for ; Tue, 15 Jul 2003 08:53:03 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FEr227015952 for ; Tue, 15 Jul 2003 10:53:02 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FEr28Q001408 for ; Tue, 15 Jul 2003 10:53:02 -0400 (EDT) Message-Id: <200307151453.h6FEr28Q001408@thunk.east.sun.com> From: Bill Sommerfeld To: v6ops@ops.ietf.org Subject: security considerations comments on draft-ietf-v6ops-unmaneval-00.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jul 2003 10:53:02 -0400 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk 1) section 4.3: tunnel-related security considerations really apply to all four scenarios; while it is less likely that tunnels will be used in the other scenarios, it's not impossible. suggested edit: pull the meat of section 4.3 into the main security considerations section and make it clearly applicable to any situation where tunnels are in use. 2) section 2.2: On dual-stack nodes, similar security policy should be applied to ipv4 and ipv6 communications; if strict policy is applied only to v6 traffic, this will provide no additional security (as the node will likely still be vulnerable through the v4 side). As a non-security matter, migration to v6 will be discouraged if common apps work over v4 but fail over v6. suggested edit: replace last sentance of 2.2 with: Security policy which prevents use of v6 while allowing v4 will discourage migration to v6 without significantly improving security. Developers and administrators should make sure that global Internet connectivity through either IPv4 or IPv6 is restricted to only those applications that are expressly designed for global Internet connectivity. - Bill From owner-v6ops@ops.ietf.org Tue Jul 15 11:02: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 LAA23115 for ; Tue, 15 Jul 2003 11:02:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRJO-000Kpa-5I for v6ops-data@psg.com; Tue, 15 Jul 2003 15:01:50 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.14) id 19cRJK-000KpM-Pk for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:01:46 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6FF1kAh021963 for ; Tue, 15 Jul 2003 09:01:46 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI200M3YN2XZK@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 15 Jul 2003 09:01:46 -0600 (MDT) Received: from sun.com ([81.160.137.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI2009O9N2V9K@mail.sun.net> for v6ops@ops.ietf.org; Tue, 15 Jul 2003 09:01:45 -0600 (MDT) Date: Tue, 15 Jul 2003 08:01:45 -0700 From: Alain Durand Subject: 6to4 vs forwarding IP proto41 in NAT To: v6ops@ops.ietf.org Message-id: <4057C01D-B6D5-11D7-83E1-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-9.7 required=5.0 tests=BAYES_01,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT A NAT box could do the following when receiving an IPv6 packet encapsulated in IPv4 with proto 41: If IPv6 dst does not belong to the local 6to4 /48 prefix, forward internally, else decapsulate. Why will will not work? - Alain. From owner-v6ops@ops.ietf.org Tue Jul 15 11:02: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 LAA23176 for ; Tue, 15 Jul 2003 11:02:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRKM-000Kw7-UY for v6ops-data@psg.com; Tue, 15 Jul 2003 15:02:50 +0000 Received: from [160.36.58.43] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 4.14) id 19cRKI-000KuH-2Z for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:02:46 +0000 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6FF1RN21186; Tue, 15 Jul 2003 11:01:29 -0400 (EDT) Date: Tue, 15 Jul 2003 11:01:27 -0400 From: Keith Moore To: v6ops@ops.ietf.org Cc: moore@cs.utk.edu Subject: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Message-Id: <20030715110127.5e400515.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.2 (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=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with what Margaret said in the meeting - if we're going to recommend behavior to NAT vendors we should recommend that the NATs implement a v6 router. Of course if they do that it's pretty simple and obvious to have that router support a 6to4 interface. I also agree that this document isn't the right place to put a detailed recommendation about how to implement v6 in a SOHO v4NAT/v6router box. So maybe it could be said that nailing up protocol 41 in a v4NAT box is a temporary measure until the NATs can be upgraded to support v6 routing in the box? From owner-v6ops@ops.ietf.org Tue Jul 15 11:09: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 LAA23413 for ; Tue, 15 Jul 2003 11:09:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRQG-000LUl-2u for v6ops-data@psg.com; Tue, 15 Jul 2003 15:08:56 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19cRQC-000LUP-Jb for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:08:52 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA26483 for ; Tue, 15 Jul 2003 16:08:51 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id QAA21567 for ; Tue, 15 Jul 2003 16:08:50 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6FF8oa27003 for v6ops@ops.ietf.org; Tue, 15 Jul 2003 16:08:50 +0100 Date: Tue, 15 Jul 2003 16:08:50 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT Message-ID: <20030715150850.GG26381@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <4057C01D-B6D5-11D7-83E1-00039358A080@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4057C01D-B6D5-11D7-83E1-00039358A080@sun.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk The advantage for plain proto41 forwarding is that you don't have to decapsulate for it to work - just pass it on :) The NAT web config screen can just have a checkbox to forward proto41 and a field to specify the RFC1918 address to forward it to. But agreed if the vendor is implementing 6to4, there is no reason why they couldn't choose to do this. I wouldn't like to lose the ability to run a tunnel broker client inside my network (for a host or network broker client) because of 6to4 support on the router (which I applaud - and I'd be interested to know which vendors are implementing it... Christian?) Of course ideally we want IPv6 natively, but... Tim On Tue, Jul 15, 2003 at 08:01:45AM -0700, Alain Durand wrote: > A NAT box could do the following when receiving an IPv6 packet > encapsulated in IPv4 with proto 41: > > If IPv6 dst does not belong to the local 6to4 /48 prefix, forward > internally, > else decapsulate. > > Why will will not work? > > - Alain. > From owner-v6ops@ops.ietf.org Tue Jul 15 11:11: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 LAA23513 for ; Tue, 15 Jul 2003 11:11:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRS3-000Lgr-Al for v6ops-data@psg.com; Tue, 15 Jul 2003 15:10:47 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19cRRz-000LgC-Q0 for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:10:43 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA26529 for ; Tue, 15 Jul 2003 16:10:42 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id QAA21600 for ; Tue, 15 Jul 2003 16:10:42 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6FFAgT27062 for v6ops@ops.ietf.org; Tue, 15 Jul 2003 16:10:42 +0100 Date: Tue, 15 Jul 2003 16:10:42 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Message-ID: <20030715151042.GH26381@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20030715110127.5e400515.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030715110127.5e400515.moore@cs.utk.edu> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 15, 2003 at 11:01:27AM -0400, Keith Moore wrote: > > So maybe it could be said that nailing up protocol 41 in a v4NAT box is > a temporary measure until the NATs can be upgraded to support v6 > routing in the box? Absolutely. We're talking about (SOHO) deployment now. Tim From owner-v6ops@ops.ietf.org Tue Jul 15 11:21: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 LAA23885 for ; Tue, 15 Jul 2003 11:21:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRbh-000Mih-Bi for v6ops-data@psg.com; Tue, 15 Jul 2003 15:20:45 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19cRbd-000Meb-DV for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:20:41 +0000 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 08:20:10 -0700 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 08:20:10 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:20:10 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:20:10 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:19:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 6to4 vs forwarding IP proto41 in NAT Date: Tue, 15 Jul 2003 08:17:33 -0700 Message-ID: Thread-Topic: 6to4 vs forwarding IP proto41 in NAT Thread-Index: AcNK4xCUFodDFjd3TNe4vV6N25O0hAAASZSq From: "Christian Huitema" To: "Alain Durand" , X-OriginalArrivalTime: 15 Jul 2003 15:19:53.0181 (UTC) FILETIME=[8A6B90D0:01C34AE4] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable No, it will not work. The NAT that implements 6to4 will decapsulate all = packets that it receives as if they were meant for the local 6to4 = router. If the packets have a "wrong" destination address, it should = implement the behavior recommended in the 6to4 security recommendations, = i.e. drop the packet.=20 ________________________________ From: owner-v6ops@ops.ietf.org on behalf of Alain Durand Sent: Tue 7/15/2003 8:01 AM To: v6ops@ops.ietf.org Subject: 6to4 vs forwarding IP proto41 in NAT A NAT box could do the following when receiving an IPv6 packet encapsulated in IPv4 with proto 41: If IPv6 dst does not belong to the local 6to4 /48 prefix, forward internally, else decapsulate. Why will will not work? - Alain. From owner-v6ops@ops.ietf.org Tue Jul 15 11:22: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 LAA23917 for ; Tue, 15 Jul 2003 11:22:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRcn-000MpW-GB for v6ops-data@psg.com; Tue, 15 Jul 2003 15:21:53 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19cRcl-000Mm5-DV for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:21:51 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 08:21:21 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 08:21:20 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 08:21:20 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:21:21 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:21:19 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:21:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Date: Tue, 15 Jul 2003 08:20:25 -0700 Message-ID: Thread-Topic: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Thread-Index: AcNK4wln2+w/JLvRQPWTt2yvkRyiPAAAZR9p From: "Christian Huitema" To: "Keith Moore" , Cc: X-OriginalArrivalTime: 15 Jul 2003 15:21:02.0676 (UTC) FILETIME=[B3D7A940:01C34AE4] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The consensus in the room was that Jordi's draft should simply document = the current practice, with all its considerations, and should refrain = from making any recommendation to NAT vendors. ________________________________ From: owner-v6ops@ops.ietf.org on behalf of Keith Moore Sent: Tue 7/15/2003 8:01 AM To: v6ops@ops.ietf.org Cc: moore@cs.utk.edu Subject: comment on draft-palet-v6ops-proto41-nat-00.txt discussion I agree with what Margaret said in the meeting - if we're going to recommend behavior to NAT vendors we should recommend that the NATs implement a v6 router. Of course if they do that it's pretty simple and obvious to have that router support a 6to4 interface. I also agree that this document isn't the right place to put a detailed recommendation about how to implement v6 in a SOHO v4NAT/v6router box. So maybe it could be said that nailing up protocol 41 in a v4NAT box is a temporary measure until the NATs can be upgraded to support v6 routing in the box? From owner-v6ops@ops.ietf.org Tue Jul 15 11:26: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 LAA24167 for ; Tue, 15 Jul 2003 11:26:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRgp-000NG9-Qw for v6ops-data@psg.com; Tue, 15 Jul 2003 15:26:03 +0000 Received: from [160.36.58.43] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 4.14) id 19cRgn-000NFq-Gb for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:26:01 +0000 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6FFOgN21633; Tue, 15 Jul 2003 11:24:43 -0400 (EDT) Date: Tue, 15 Jul 2003 11:24:42 -0400 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, v6ops@ops.ietf.org Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Message-Id: <20030715112442.7b41f6f3.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.2 (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=-26.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The consensus in the room was that Jordi's draft should simply > document the current practice, with all its considerations, and should > refrain from making any recommendation to NAT vendors. I must have missed that consensus call. I'd like to see a one- or two-sentence recommendation, or some statement that this is an interim measure. More than that, I think, would be too much. Keith > I agree with what Margaret said in the meeting - if we're going to > recommend behavior to NAT vendors we should recommend that the NATs > implement a v6 router. Of course if they do that it's pretty simple > and obvious to have that router support a 6to4 interface. > > I also agree that this document isn't the right place to put a > detailed recommendation about how to implement v6 in a SOHO > v4NAT/v6router box. > > So maybe it could be said that nailing up protocol 41 in a v4NAT box > is a temporary measure until the NATs can be upgraded to support v6 > routing in the box? From owner-v6ops@ops.ietf.org Tue Jul 15 11:26: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 LAA24188 for ; Tue, 15 Jul 2003 11:26:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRgn-000NFr-I8 for v6ops-data@psg.com; Tue, 15 Jul 2003 15:26:01 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19cRgl-000NDG-3Y for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:25:59 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 08:25:28 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 08:25:28 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:25:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:25:27 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:25:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 6to4 vs forwarding IP proto41 in NAT Date: Tue, 15 Jul 2003 08:22:50 -0700 Message-ID: Thread-Topic: 6to4 vs forwarding IP proto41 in NAT Thread-Index: AcNK499u2umZLhf3Q3STpdCqrdB0cQAARRlW From: "Christian Huitema" To: "Tim Chown" , X-OriginalArrivalTime: 15 Jul 2003 15:25:10.0034 (UTC) FILETIME=[47477F20:01C34AE5] X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Windows XP, with IPv6 enabled, if you ask to "share a link", the PC = will behave as an IPv4 NAT (using ICS) and as a 6to4 router. So I guess = there is at least one example of "NAT that is also a 6to4 router." ________________________________ From: owner-v6ops@ops.ietf.org on behalf of Tim Chown Sent: Tue 7/15/2003 8:08 AM To: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT The advantage for plain proto41 forwarding is that you don't have to decapsulate for it to work - just pass it on :) The NAT web config screen can just have a checkbox to forward proto41 and a field to specify the RFC1918 address to forward it to. But agreed if the vendor is implementing 6to4, there is no reason why = they couldn't choose to do this. I wouldn't like to lose the ability to run a tunnel broker client inside = my network (for a host or network broker client) because of 6to4 support on the router (which I applaud - and I'd be interested to know which = vendors are implementing it... Christian?) Of course ideally we want IPv6 natively, but... Tim On Tue, Jul 15, 2003 at 08:01:45AM -0700, Alain Durand wrote: > A NAT box could do the following when receiving an IPv6 packet > encapsulated in IPv4 with proto 41: > > If IPv6 dst does not belong to the local 6to4 /48 prefix, forward > internally, > else decapsulate. > > Why will will not work? > > - Alain. > From owner-v6ops@ops.ietf.org Tue Jul 15 11:29: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 LAA24264 for ; Tue, 15 Jul 2003 11:29:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRjj-000NZA-1P for v6ops-data@psg.com; Tue, 15 Jul 2003 15:29:03 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.14) id 19cRjY-000NXi-82 for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:28:52 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3B6CB93; Wed, 16 Jul 2003 00:28:50 +0900 (JST) To: Keith Moore Cc: "Christian Huitema" , v6ops@ops.ietf.org In-reply-to: moore's message of Tue, 15 Jul 2003 11:24:42 -0400. <20030715112442.7b41f6f3.moore@cs.utk.edu> 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: comment on draft-palet-v6ops-proto41-nat-00.txt discussion From: itojun@iijlab.net Date: Wed, 16 Jul 2003 00:28:50 +0900 Message-Id: <20030715152850.3B6CB93@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> The consensus in the room was that Jordi's draft should simply >> document the current practice, with all its considerations, and should >> refrain from making any recommendation to NAT vendors. > >I must have missed that consensus call. i (and some others) commented like above, but there was no consensus call. christian's statement is a little bit misleading i guess. itojun From owner-v6ops@ops.ietf.org Tue Jul 15 11:32: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 LAA24432 for ; Tue, 15 Jul 2003 11:32:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRmb-000NxC-E7 for v6ops-data@psg.com; Tue, 15 Jul 2003 15:32:01 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19cRmY-000NtH-UY for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:31:58 +0000 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jul 2003 08:31:28 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 15 Jul 2003 08:31:28 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:31:28 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:31:27 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 15 Jul 2003 08:31:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Date: Tue, 15 Jul 2003 08:30:44 -0700 Message-ID: Thread-Topic: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Thread-Index: AcNK5dJMA0XhmR1pTsKVtw5lobkGngAADx2r From: "Christian Huitema" To: , "Keith Moore" Cc: X-OriginalArrivalTime: 15 Jul 2003 15:31:08.0523 (UTC) FILETIME=[1CF493B0:01C34AE6] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I should have said that this was the dominant opinion. There was = effectively no formal consensus call. Sorry for the confusion. ________________________________ From: itojun@itojun.org on behalf of itojun@iijlab.net Sent: Tue 7/15/2003 8:28 AM To: Keith Moore Cc: Christian Huitema; v6ops@ops.ietf.org Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt discussion=20 >> The consensus in the room was that Jordi's draft should simply >> document the current practice, with all its considerations, and = should >> refrain from making any recommendation to NAT vendors. > >I must have missed that consensus call. i (and some others) commented like above, but there was no = consensus call. christian's statement is a little bit misleading i guess. itojun From owner-v6ops@ops.ietf.org Tue Jul 15 11:32: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 LAA24448 for ; Tue, 15 Jul 2003 11:32:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRmp-000NyC-2o for v6ops-data@psg.com; Tue, 15 Jul 2003 15:32:15 +0000 Received: from [130.92.9.53] (helo=mailhub02.unibe.ch) by psg.com with esmtp (Exim 4.14) id 19cRmm-000Nvg-BL for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:32:12 +0000 Received: from localhost (localhost [127.0.0.1]) by mailhub02.unibe.ch (Postfix) with ESMTP id E09917641E for ; Tue, 15 Jul 2003 17:31:40 +0200 (MEST) Received: from mailhub02.unibe.ch ([127.0.0.1]) by localhost (mailhub02 [127.0.0.1:10024]) (amavisd-new) with LMTP id 05667-01-44 for ; Tue, 15 Jul 2003 17:31:40 +0200 (MEST) Received: from ubecx01 (ubecx01.unibe.ch [130.92.6.40]) by mailhub02.unibe.ch (Postfix) with ESMTP id 0AAC07642E for ; Tue, 15 Jul 2003 17:31:40 +0200 (MEST) Received: from vaiooo (dhcp-99-122.vpn.unibe.ch [130.92.99.122]) by ubecx01.unibe.ch (PMDF V5.2-32 #42481) with ESMTP id <0HI200CIEOGQLG@ubecx01.unibe.ch> for v6ops@ops.ietf.org; Tue, 15 Jul 2003 17:31:39 +0200 (MEST) Date: Tue, 15 Jul 2003 17:30:53 +0200 From: Marcin Michalak Subject: Discussion regarding IP proto41 in NAT In-reply-to: <4057C01D-B6D5-11D7-83E1-00039358A080@sun.com> To: v6ops@ops.ietf.org Message-id: <3F143A4D.1309.159D8CE6@localhost> Organization: Telscom MIME-version: 1.0 X-Mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-description: Mail message body Content-transfer-encoding: 7BIT X-Virus-checked: by University of Berne X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hello, Forgive me if this is already done: It seems to me that we need to have clear recommendations with priorities what solutions are to be used. Something like Margaret was saying: native IPv6, then ... What also I see that many things are becoming obvious for us, but may not be so obvious for the others. So in my opinion it should be clearly stated in all transition documents that native IPv6 is the best and recommended solution. Have a good time in Vienna (or somewhere else :-)), Marcin ---------------------------------------------------------- Marcin Michalak Research Engineer Mobile: +41 79 330 83 51 Telscom AG From owner-v6ops@ops.ietf.org Tue Jul 15 11:44: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 LAA24742 for ; Tue, 15 Jul 2003 11:44:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRxh-000P7g-2E for v6ops-data@psg.com; Tue, 15 Jul 2003 15:43:29 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19cRxc-000P6F-Ni for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:43:25 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 52-md50000000024.tmp for ; Tue, 15 Jul 2003 17:44:21 +0200 Message-ID: <011601c34ae7$ef5fce40$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20030715152850.3B6CB93@coconut.itojun.org> Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Date: Tue, 15 Jul 2003 17:44:04 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Tue, 15 Jul 2003 17:44:21 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I agree with Itojun, my feeling is that the WG chairs requested me to update the document, and I will do so with the comments from the WG and any emails that I receive in the next two weeks, more or less. So please, all, provide your inputs ! Regards, Jordi ----- Original Message ----- From: To: "Keith Moore" Cc: "Christian Huitema" ; Sent: Tuesday, July 15, 2003 5:28 PM Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt discussion > >> The consensus in the room was that Jordi's draft should simply > >> document the current practice, with all its considerations, and should > >> refrain from making any recommendation to NAT vendors. > > > >I must have missed that consensus call. > > i (and some others) commented like above, but there was no consensus > call. christian's statement is a little bit misleading i guess. > > itojun > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Tue Jul 15 11:46: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 LAA24795 for ; Tue, 15 Jul 2003 11:46:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cRzr-000PJy-SF for v6ops-data@psg.com; Tue, 15 Jul 2003 15:45:43 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.14) id 19cRzo-000PHj-I3 for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:45:40 +0000 Received: (qmail 64130 invoked by uid 2502); 15 Jul 2003 15:45:08 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.137948 secs); 15/07/2003 16:45:08 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jul 2003 15:45:08 -0000 Date: Tue, 15 Jul 2003 16:45:08 +0100 (WEST) From: Carlos Friacas To: Marcin Michalak cc: v6ops@ops.ietf.org Subject: Re: Discussion regarding IP proto41 in NAT In-Reply-To: <3F143A4D.1309.159D8CE6@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 15 Jul 2003, Marcin Michalak wrote: > Hello, > Forgive me if this is already done: It seems to me that we need to > have clear recommendations with priorities what solutions are to be > used. Something like Margaret was saying: native IPv6, then ... > > What also I see that many things are becoming obvious for us, but > may not be so obvious for the others. So in my opinion it should be > clearly stated in all transition documents that native IPv6 is the > best and recommended solution. > Have a good time in Vienna (or somewhere else :-)), > Marcin > > ---------------------------------------------------------- > Marcin Michalak Research Engineer > Mobile: +41 79 330 83 51 Telscom AG I also strongly second this view. This discussion is about easying SOHO and HOME deployment, but it seems to me that the quality involved with using this mechanism might turn users against IPv6 usage. The focus should be to: a) ISPs requesting addresses b) getting the BGP sessions up and running c) ISPs going dual-stack on their backbone d) ISPs extending native IPv6 to their customers "door" (SOHO *and* HOME) Again -- you All -- have a good time in Vienna. Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!" From owner-v6ops@ops.ietf.org Tue Jul 15 11: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 LAA24886 for ; Tue, 15 Jul 2003 11:47:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cS1e-000PUR-Db for v6ops-data@psg.com; Tue, 15 Jul 2003 15:47:34 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19cS1b-000PTi-JL for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:47:31 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA28061 for ; Tue, 15 Jul 2003 16:47:30 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id QAA23676 for ; Tue, 15 Jul 2003 16:47:30 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6FFlTJ28095 for v6ops@ops.ietf.org; Tue, 15 Jul 2003 16:47:29 +0100 Date: Tue, 15 Jul 2003 16:47:29 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Discussion regarding IP proto41 in NAT Message-ID: <20030715154729.GO26381@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <3F143A4D.1309.159D8CE6@localhost> 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=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk That's the ISP scenarios document, not unmanaged :) Tim On Tue, Jul 15, 2003 at 04:45:08PM +0100, Carlos Friacas wrote: > On Tue, 15 Jul 2003, Marcin Michalak wrote: > > > Hello, > > Forgive me if this is already done: It seems to me that we need to > > have clear recommendations with priorities what solutions are to be > > used. Something like Margaret was saying: native IPv6, then ... > > > > What also I see that many things are becoming obvious for us, but > > may not be so obvious for the others. So in my opinion it should be > > clearly stated in all transition documents that native IPv6 is the > > best and recommended solution. > > Have a good time in Vienna (or somewhere else :-)), > > Marcin > > > > ---------------------------------------------------------- > > Marcin Michalak Research Engineer > > Mobile: +41 79 330 83 51 Telscom AG > > > I also strongly second this view. > This discussion is about easying SOHO and HOME deployment, but it seems to > me that the quality involved with using this mechanism might turn users > against IPv6 usage. > The focus should be to: > a) ISPs requesting addresses > b) getting the BGP sessions up and running > c) ISPs going dual-stack on their backbone > d) ISPs extending native IPv6 to their customers "door" (SOHO *and* HOME) > > > Again -- you All -- have a good time in Vienna. > > > Regards, > > ./Carlos "Networking is fun!" > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 > [ See me @ h323:videoconf05.fccn.pt] > "Internet is just routes (125953/461), naming (millions) and... people!" > From owner-v6ops@ops.ietf.org Tue Jul 15 11:48: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 LAA24912 for ; Tue, 15 Jul 2003 11:48:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cS23-000PXV-Na for v6ops-data@psg.com; Tue, 15 Jul 2003 15:47:59 +0000 Received: from [160.36.58.43] (helo=astro.cs.utk.edu) by psg.com with esmtp (Exim 4.14) id 19cS20-000PWs-G5 for v6ops@ops.ietf.org; Tue, 15 Jul 2003 15:47:56 +0000 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h6FFkeN22003; Tue, 15 Jul 2003 11:46:40 -0400 (EDT) Date: Tue, 15 Jul 2003 11:46:39 -0400 From: Keith Moore To: v6ops@ops.ietf.org Cc: moore@cs.utk.edu Subject: comment on draft-lind-v6ops-isp-scenarios-00.txt Message-Id: <20030715114639.368ecdf7.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.2 (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=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit relative to the suggestion made at the meeting: I think there are two purposes of this document: 1. to provide feedback to the protocol developers in IETF - are our existing transition mechanisms adequate? do we need new ones, or to tweak existing ones? 2. to provide input to networks considering v6 deployment. if NANOG/RIPE/APNIC/APRICOT/whomever could be recruited to contribute v6 experiences to this document, that would IMHO be great - even if a lot of the work were done outside of IETF. but we would like to see the drafts published as Internet-Drafts (even if available in another form) and the result published as an RFC (even if published elsewhere) so that IETF people will see the output. in general I'd like to see more paths for feedback to IETF from the operators' organizations. Keith From owner-v6ops@ops.ietf.org Wed Jul 16 01:22: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 BAA18116 for ; Wed, 16 Jul 2003 01:22:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ceh7-000IWx-Gx for v6ops-data@psg.com; Wed, 16 Jul 2003 05:19:13 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19ceh5-000IWj-RE for v6ops@ops.ietf.org; Wed, 16 Jul 2003 05:19:12 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ceh4-00078K-UN for v6ops@ops.ietf.org; Wed, 16 Jul 2003 07:19:11 +0200 Message-Id: <5.1.1.6.0.20030715080310.00b0fc78@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 15 Jul 2003 08:03:56 -0700 To: v6ops@ops.ietf.org From: "Gregory M. Lebovitz" Subject: link to ietf57 jabber info? X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ 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. ] anyone have a link to info on using Jabber here in vienna? From owner-v6ops@ops.ietf.org Wed Jul 16 02:09: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 CAA28648 for ; Wed, 16 Jul 2003 02:09:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cfSe-000LJA-Dn for v6ops-data@psg.com; Wed, 16 Jul 2003 06:08:20 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19cfSU-000LGi-1E for v6ops@ops.ietf.org; Wed, 16 Jul 2003 06:08:10 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 6-md50000000033.tmp for ; Wed, 16 Jul 2003 08:09:04 +0200 Message-ID: <027f01c34b60$be47dc70$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <4057C01D-B6D5-11D7-83E1-00039358A080@sun.com> Subject: Re: 6to4 vs forwarding IP proto41 in NAT Date: Tue, 15 Jul 2003 23:58:59 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 08:09:04 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_30,DATE_IN_PAST_06_12,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Agree, it should work. Regards, Jordi ----- Original Message ----- From: "Alain Durand" To: Sent: Tuesday, July 15, 2003 5:01 PM Subject: 6to4 vs forwarding IP proto41 in NAT > A NAT box could do the following when receiving an IPv6 packet > encapsulated in IPv4 with proto 41: > > If IPv6 dst does not belong to the local 6to4 /48 prefix, forward > internally, > else decapsulate. > > Why will will not work? > > - Alain. > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 02:09: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 CAA28807 for ; Wed, 16 Jul 2003 02:09:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cfSY-000LIx-49 for v6ops-data@psg.com; Wed, 16 Jul 2003 06:08:14 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19cfSU-000LGh-1D for v6ops@ops.ietf.org; Wed, 16 Jul 2003 06:08:10 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 5-md50000000033.tmp for ; Wed, 16 Jul 2003 08:09:03 +0200 Message-ID: <027e01c34b60$bdd54480$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: More comments on draft-palet-v6ops-proto41-nat-00.txt Date: Tue, 15 Jul 2003 23:49:35 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 08:09:03 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-10.2 required=5.0 tests=DATE_IN_PAST_06_12,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Carlos, My comments in-line. Regards, Jordi ----- Original Message ----- From: "Carlos Friacas" To: Sent: Monday, July 14, 2003 12:09 PM Subject: More comments on draft-palet-v6ops-proto41-nat-00.txt > > Hello All, > > I have some questions: > > > [1, Introduction] > > + "routers or tunnel servers" ~= "tunnel brokers" ? > > "(...) with a manual configuration at the IPv6 router tunnel-end." > It isnt feasible for a service you intend to sell. using manual > configurations on routers simply isnt scalable. I'm not implementing a service just describing an option to do it. Is a decision of the implementor how it should be. > > + reference to [3] > > I still dont understand why a project focused on > Internet Exchanges (IXPs/NAPs/...) may have anything to do with NAT > boxes and tunnels. End-users shouldnt be a topic. People managing > networks, BGP and AS numbers should. Well, I guess you shouldn't try to tell the "inventor" and technical responsible of a project what's the project scope. I can tell you that Euro6IX scope is not ONLY the IXs, but also how they become useful to users, and whatever is needed to foster the deployment of IPv6. This information is explained in the project documents, publicly available. > > + "big opportunity to rapidly deploy a huge number of nodes and networks" > > You mean, nodes of tunnel brokers? > networks? ...using a router as a NAT client? it may seem as a good "hack > idea" to use a laptop for this. > a theoretical question -- does the community want rapid deployment? with > high RTTs and high chance of self-denial-of-service ? > ...or is it a way to kill IPv6 faster? > I think the text is clear on this point, and again I don't need to consider how to implement the service, just offer a solution to deploy it. > + last paragraph > > You are listing the need to: > - change tunnel brokers > - change something in some operating systems (which ones?) > Wouldnt be easier to v6-ize the NAT boxes? (dont know if it would be a > good idea, as we dont need NAT boxes in the native IPv6 world...) > I'm not specifying the tunnel brokers, and thus no need to indicate what scripts for what OS should be changed. This will be another document. No, not all the vendors are going to make the effort and investment in provide native IPv6, and not all the existing hardware supports it. > > [4, Applicability] > > + "The most usual scope of application of this technology seems to be > SOHO and home environments, but is not limited to these." > Do you mind to specify more environments? I think it would be important > to specify, if they exist. Whatever where there is a NAT box ;-) > > > [5, NAT design considerations] > > + "New firmware/software versions of the NAT implementations should > ensure the support of protocol-41 forwarding." > > I would add: ", and the means for its administrator to turn it on and > off". > As an example, we wouldnt want anyone using a connection to a tunnel > broker if native IPv6 is available on the wire/air. > Mandatory support for protocol-41 forwarding seems unnappropriate, as > tunnels usage will fade away (as a method of getting IPv6 connectivity). > The only one that have access to the NAT boxes is the administrator (in most of the scenarios the owner/user = SOHO). > > [7, Security] > > + (more) > > The mechanism of forwarding protocol 41 might be considered a serious > security issue in some organizations. Those wanting to restrict access > to some applications/networks for instance. They can/do provide IPv4 > and native IPv6, but with a well-defined set of filtering rules. Using > (standardizing) a mecanism that permits clients to override the set of > rules seems dangerous. If vendors start(or continue) to permit > forwarding of protocol 41 in their factory defaults (expressely or > somewhat hidden) ops people can have a new plague to toy around, when > native (and filtered) IPv6 is in place. > Exactly the same security issues as you already have with any kind of tunnels. So, the mechanism to override the rules are already here: Any kind of tunnel of VPN. The question of what kind of filters or firewalls or whatever is deployed in IPv6 networks, isn't the scope of this document. > > > Regards, > > ./Carlos "Networking is fun!" > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 > [ See me @ h323:videoconf05.fccn.pt] > "Internet is just routes (125953/461), naming (millions) and... people!" > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 02:09: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 CAA28918 for ; Wed, 16 Jul 2003 02:09:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cfSm-000LJY-Cw for v6ops-data@psg.com; Wed, 16 Jul 2003 06:08:28 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19cfSU-000LGj-1q for v6ops@ops.ietf.org; Wed, 16 Jul 2003 06:08:10 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 7-md50000000033.tmp for ; Wed, 16 Jul 2003 08:09:04 +0200 Message-ID: <028001c34b60$bec23c90$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20030715110127.5e400515.moore@cs.utk.edu> Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Date: Wed, 16 Jul 2003 00:06:26 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 08:09:04 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-15.4 required=5.0 tests=BAYES_10,DATE_IN_PAST_06_12,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, this is a very good point. I included this in the new document. Regards, Jordi ----- Original Message ----- From: "Keith Moore" To: Cc: Sent: Tuesday, July 15, 2003 5:01 PM Subject: comment on draft-palet-v6ops-proto41-nat-00.txt discussion > I agree with what Margaret said in the meeting - if we're going to > recommend behavior to NAT vendors we should recommend that the NATs > implement a v6 router. Of course if they do that it's pretty simple and > obvious to have that router support a 6to4 interface. > > I also agree that this document isn't the right place to put a detailed > recommendation about how to implement v6 in a SOHO v4NAT/v6router box. > > So maybe it could be said that nailing up protocol 41 in a v4NAT box is > a temporary measure until the NATs can be upgraded to support v6 > routing in the box? > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 02:19: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 CAA05732 for ; Wed, 16 Jul 2003 02:19:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cfdH-000M6s-U1 for v6ops-data@psg.com; Wed, 16 Jul 2003 06:19:19 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19cfdE-000M6a-SE for v6ops@ops.ietf.org; Wed, 16 Jul 2003 06:19:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6G6JE520304 for ; Wed, 16 Jul 2003 09:19:14 +0300 Date: Wed, 16 Jul 2003 09:19:14 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: food for thought on NAT traversal techniques Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.7 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Find below a bit food for thought on designing NAT traversal mechanisms. I think it would be useful to consider a bit more on what we NEED. - Should we send a clear signal to NAT vendors what kind of deployment model we think is best, and what are the goals they should try to work towards? - Should we try to leverage existing IPv4 NAT traversal mechanisms if possible (there seem to be a plenty of them, like STUN, TURN, etc.), and even avoid all IPv6 work we can? Would that be of value in itself ("A particular kind of NAT breaks this IPv_4_ solution we'd like to use to traverse NATs")? - What is the expected lifetime of our NAT traversal mechanism (e.g. a few years, until most NAT vendors have started deploying 6to4 or native) ? - What features are critical for the NAT traversal mechanism? For example: * simplicity (spec and the protocol) * ease of use (easy to turn on/configure) * interop with NATs (works with all NAT boxes or close enough) * robustness (is otherwise failure-proof with few things that could go wrong) * route optimization (traffic between different IPv6 nodes behind NAT's as direct as possible) * security (doesn't make unexpected holes, minimizes DoS attacks etc.) - What are the properties of the solution(s) we would like to use/develop considering these issues? How much work we should we should use on mechanisms which are likely to: * be quite low in our "preferred solutions list", * have a limited lifetime, and hopefully soon replaced by a better-working mechanism, * are something other WG's have had to specify as well, and * be something we may not even be able to specify implement correctly, simply and reliably? -- 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 Jul 16 03:16: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 DAA18122 for ; Wed, 16 Jul 2003 03:16:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cgUy-000PWA-EM for v6ops-data@psg.com; Wed, 16 Jul 2003 07:14:48 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19cgUt-000PVd-8H for v6ops@ops.ietf.org; Wed, 16 Jul 2003 07:14:43 +0000 Received: from blue.seas.upenn.edu (BLUE.SEAS.UPENN.EDU [158.130.64.177]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6G7EeM1015257 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 03:14:41 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6G7EeOM011871; Wed, 16 Jul 2003 03:14:40 -0400 (EDT) Received: from localhost (rsofia@localhost) by blue.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6G7EeO9011868; Wed, 16 Jul 2003 03:14:40 -0400 (EDT) Date: Wed, 16 Jul 2003 03:14:40 -0400 (EDT) From: HELENA RUTE SOFIA To: Keith Moore cc: v6ops@ops.ietf.org Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt In-Reply-To: <20030715114639.368ecdf7.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-15.2 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Keith, comments below... > relative to the suggestion made at the meeting: > > I think there are two purposes of this document: > > 1. to provide feedback to the protocol developers in IETF - are our > existing transition mechanisms adequate? do we need new ones, or to > tweak existing ones? > > 2. to provide input to networks considering v6 deployment. It seems to me that 1. and 2. could simply start by an analysis of current deployed solutions; trying to exhaustively cover the possible situations that could be a representative subset of real scenarios, to provide some "howto" is an endless task, and would take so long, that it would probably not make much sense in the end...also, different ISPs not only have different sizes, use different technologies, but also have different purposes in terms of offered services; and, we also have commercial services and research services... So, as was also mentioned yesterday at the v6ops meeting, why not simply change the document to provide an analysis of current scenarios? I'm pretty sure that it doesn't cost much to some ISPs of different sizes to provide some input on a draft that somebody could put together... Ch., rute From owner-v6ops@ops.ietf.org Wed Jul 16 03:20: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 DAA18226 for ; Wed, 16 Jul 2003 03:20:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cgZo-000Ptu-JZ for v6ops-data@psg.com; Wed, 16 Jul 2003 07:19:48 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19cgZl-000PtZ-MP for v6ops@ops.ietf.org; Wed, 16 Jul 2003 07:19:45 +0000 Received: from blue.seas.upenn.edu (BLUE.SEAS.UPENN.EDU [158.130.64.177]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6G7JfM1015936 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 03:19:42 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6G7JfOM012366; Wed, 16 Jul 2003 03:19:41 -0400 (EDT) Received: from localhost (rsofia@localhost) by blue.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6G7JeN8012361; Wed, 16 Jul 2003 03:19:41 -0400 (EDT) Date: Wed, 16 Jul 2003 03:19:40 -0400 (EDT) From: HELENA RUTE SOFIA To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT In-Reply-To: <027f01c34b60$be47dc70$eb88a051@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.2 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk One thing that is really puzzling me about this draft is: do we really need this?? There are currently two options that have "more" priority in terms of implementation, i.e., v6 and 6to4...so why try to create a document on something that is currently assumed to work, and that is only used as a "hack", when one of the other two is not working?? Why do we need a document on this? Rute On Tue, 15 Jul 2003, JORDI PALET MARTINEZ wrote: > Agree, it should work. > > Regards, > Jordi > > ----- Original Message ----- > From: "Alain Durand" > To: > Sent: Tuesday, July 15, 2003 5:01 PM > Subject: 6to4 vs forwarding IP proto41 in NAT > > > > A NAT box could do the following when receiving an IPv6 packet > > encapsulated in IPv4 with proto 41: > > > > If IPv6 dst does not belong to the local 6to4 /48 prefix, forward > > internally, > > else decapsulate. > > > > Why will will not work? > > > > - Alain. > > > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com > > > From owner-v6ops@ops.ietf.org Wed Jul 16 03:40: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 DAA19099 for ; Wed, 16 Jul 2003 03:40:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cgtD-00019N-21 for v6ops-data@psg.com; Wed, 16 Jul 2003 07:39:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19cgt9-00017E-O6 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 07:39:48 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 22-md50000000035.tmp for ; Wed, 16 Jul 2003 09:40:44 +0200 Message-ID: <04e601c34b6d$8cbb4ef0$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: 6to4 vs forwarding IP proto41 in NAT Date: Wed, 16 Jul 2003 09:40:33 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 09:40:44 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is exactly what I already reflected in the new version of the draft. I will wait for more inputs before publish it. Regards, Jordi ----- Original Message ----- From: "HELENA RUTE SOFIA" To: "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, July 16, 2003 9:19 AM Subject: Re: 6to4 vs forwarding IP proto41 in NAT > > One thing that is really puzzling me about this draft is: do we really > need this?? There are currently two options that have "more" priority in > terms of implementation, i.e., v6 and 6to4...so why try to create a > document on something that is currently assumed to work, and that is only > used as a "hack", when one of the other two is not working?? Why do we > need a document on this? > > Rute > > > On Tue, 15 Jul 2003, JORDI PALET MARTINEZ wrote: > > > Agree, it should work. > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "Alain Durand" > > To: > > Sent: Tuesday, July 15, 2003 5:01 PM > > Subject: 6to4 vs forwarding IP proto41 in NAT > > > > > > > A NAT box could do the following when receiving an IPv6 packet > > > encapsulated in IPv4 with proto 41: > > > > > > If IPv6 dst does not belong to the local 6to4 /48 prefix, forward > > > internally, > > > else decapsulate. > > > > > > Why will will not work? > > > > > > - Alain. > > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on-line at: > > http://www.ipv6-es.com > > > > > > > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 04:17: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 EAA20442 for ; Wed, 16 Jul 2003 04:17:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19chSD-0003Ge-1w for v6ops-data@psg.com; Wed, 16 Jul 2003 08:16:01 +0000 Received: from [2002:d9d0:b6d6::1] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.14) id 19chS5-0003GD-QS for v6ops@ops.ietf.org; Wed, 16 Jul 2003 08:15:54 +0000 Received: from [81.160.147.201] ([81.160.147.201]) by lord.fakat.com (8.12.9/8.12.8) with ESMTP id h6G8IG8F087716; Wed, 16 Jul 2003 10:18:17 +0200 (CEST) (envelope-from jasko@fakat.com) Date: Wed, 16 Jul 2003 10:15:52 +0200 (CEST) From: Jasminko Mulahusic To: HELENA RUTE SOFIA cc: v6ops@ops.ietf.org Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt In-Reply-To: Message-ID: <20030716100816.X270@vagabond.imslab.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Jul 2003, HELENA RUTE SOFIA wrote: > It seems to me that 1. and 2. could simply start by an analysis of current > deployed solutions; trying to exhaustively cover the possible situations > that could be a representative subset of real scenarios, to provide some > "howto" is an endless task, and would take so long, that it would probably > not make much sense in the end...also, different ISPs not only have > different sizes, use different technologies, but also have different > purposes in terms of offered services; and, we also have commercial > services and research services... > true. the thing is that we are not sure if there are any isps that have deployed fully commercial v6 networks, operated in the same way as their v4 networks. and even if we could find them it is not sure they would be able to share the results with us. jasminko > So, as was also mentioned yesterday at the v6ops meeting, why not simply > change the document to provide an analysis of current scenarios? I'm > pretty sure that it doesn't cost much to some ISPs of different sizes to > provide some input on a draft that somebody could put together... > > Ch., > rute > > > From owner-v6ops@ops.ietf.org Wed Jul 16 04:24: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 EAA20634 for ; Wed, 16 Jul 2003 04:24:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19chZc-0003hz-IY for v6ops-data@psg.com; Wed, 16 Jul 2003 08:23:40 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19chZa-0003hh-43 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 08:23:38 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA17597 for ; Wed, 16 Jul 2003 09:23:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id JAA07248 for ; Wed, 16 Jul 2003 09:23:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6G8Nai27768 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 09:23:36 +0100 Date: Wed, 16 Jul 2003 09:23:36 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt Message-ID: <20030716082336.GJ26779@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20030716100816.X270@vagabond.imslab.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030716100816.X270@vagabond.imslab.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jul 16, 2003 at 10:15:52AM +0200, Jasminko Mulahusic wrote: > > true. the thing is that we are not sure if there are any isps that have > deployed fully commercial v6 networks, operated in the same way as their > v4 networks. and even if we could find them it is not sure they would be > able to share the results with us. The main production deployments now are in the research networks, which have to be commercial quality, but may not offer all the types of services that commercial ISPs do. But v6 is running dual stack in Abilene, GEANT, many European NRENs and the transatlantic link(s) dual-stack without v6 breaking v4. But there are many gaps. Projects such as 6NET are trying to document and where possible work on these (www.6net.org/publications). Tim From owner-v6ops@ops.ietf.org Wed Jul 16 04:25: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 EAA20672 for ; Wed, 16 Jul 2003 04:25:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19chaF-0003l3-8I for v6ops-data@psg.com; Wed, 16 Jul 2003 08:24:19 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19chaC-0003kf-62 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 08:24:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6G8OE321466 for ; Wed, 16 Jul 2003 11:24:14 +0300 Date: Wed, 16 Jul 2003 11:24:13 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Accept Enterprise Scenarios Document as WG Draft? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_20,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, In the first session in Vienna, we had unanimous consensus that the scenario document produced by the Enterprise Team would serve as a good starting place for our work, and that we should accept it as a WG draft. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-03.txt Unless there are any objections from the mailing list, We'll ask the Enterprise Team to publish the next version as a WG I-D. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Wed Jul 16 04:40: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 EAA21185 for ; Wed, 16 Jul 2003 04:40:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19chpH-0004qV-Hl for v6ops-data@psg.com; Wed, 16 Jul 2003 08:39:51 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19chpF-0004pD-3S for v6ops@ops.ietf.org; Wed, 16 Jul 2003 08:39:49 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 29-md50000000037.tmp for ; Wed, 16 Jul 2003 10:40:44 +0200 Message-ID: <05c901c34b75$ee749360$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20030716100816.X270@vagabond.imslab.net> <20030716082336.GJ26779@login.ecs.soton.ac.uk> Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt Date: Wed, 16 Jul 2003 10:40:15 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 10:40:44 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit And Euro6IX (www.euro6ix.org) is working in the commercial side ;-) Also, there is a lot of commercial deployment in Japan. Regards, Jordi ----- Original Message ----- From: "Tim Chown" To: Sent: Wednesday, July 16, 2003 10:23 AM Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt > On Wed, Jul 16, 2003 at 10:15:52AM +0200, Jasminko Mulahusic wrote: > > > > true. the thing is that we are not sure if there are any isps that have > > deployed fully commercial v6 networks, operated in the same way as their > > v4 networks. and even if we could find them it is not sure they would be > > able to share the results with us. > > The main production deployments now are in the research networks, which have > to be commercial quality, but may not offer all the types of services that > commercial ISPs do. > > But v6 is running dual stack in Abilene, GEANT, many European NRENs and > the transatlantic link(s) dual-stack without v6 breaking v4. > > But there are many gaps. Projects such as 6NET are trying to document and > where possible work on these (www.6net.org/publications). > > Tim > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 04:52: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 EAA21606 for ; Wed, 16 Jul 2003 04:52:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ci0J-0005Zg-Ly for v6ops-data@psg.com; Wed, 16 Jul 2003 08:51:15 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19ci0H-0005ZS-DC for v6ops@ops.ietf.org; Wed, 16 Jul 2003 08:51:13 +0000 Received: from blue.seas.upenn.edu (BLUE.SEAS.UPENN.EDU [158.130.64.177]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6G8p9M1029780 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 04:51:10 -0400 Received: from blue.seas.upenn.edu (localhost [127.0.0.1]) by blue.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6G8p9OM018697; Wed, 16 Jul 2003 04:51:09 -0400 (EDT) Received: from localhost (rsofia@localhost) by blue.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6G8p8hk018694; Wed, 16 Jul 2003 04:51:08 -0400 (EDT) Date: Wed, 16 Jul 2003 04:51:08 -0400 (EDT) From: HELENA RUTE SOFIA To: Jasminko Mulahusic cc: v6ops@ops.ietf.org Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt In-Reply-To: <20030716100816.X270@vagabond.imslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-15.8 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > different sizes, use different technologies, but also have different > > purposes in terms of offered services; and, we also have commercial > > services and research services... > > > > true. the thing is that we are not sure if there are any isps that have > deployed fully commercial v6 networks, operated in the same way as their > v4 networks. and even if we could find them it is not sure they would be > able to share the results with us. > Actually, there is such input. it's just a question of asking :-) (NTT/Verio in the USA, for instance; I believe NTT in europe also). I cannot help in terms of commercial services, given that FCCN only provides non-commercial services. But, even ISPs such as FCCN can gladly provide input. Please notice that part of this effor has already been done earlier, either in the now extinct 6bone, or in some other projects related to v6. It's just a matter of asking. An analysis is certainly more feasible than a document trying to cover howtos for different ISPs... Rute From owner-v6ops@ops.ietf.org Wed Jul 16 05:09: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 FAA22163 for ; Wed, 16 Jul 2003 05:09:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ciH6-0006sV-5M for v6ops-data@psg.com; Wed, 16 Jul 2003 09:08:36 +0000 Received: from [2002:d9d0:b6d6::1] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.14) id 19ciH3-0006s4-Eb for v6ops@ops.ietf.org; Wed, 16 Jul 2003 09:08:33 +0000 Received: from [81.160.147.201] ([81.160.147.201]) by lord.fakat.com (8.12.9/8.12.8) with ESMTP id h6G9At8F087878; Wed, 16 Jul 2003 11:10:56 +0200 (CEST) (envelope-from jasko@fakat.com) Date: Wed, 16 Jul 2003 11:08:31 +0200 (CEST) From: Jasminko Mulahusic To: HELENA RUTE SOFIA cc: v6ops@ops.ietf.org Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt In-Reply-To: Message-ID: <20030716105838.B270@vagabond.imslab.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Jul 2003, HELENA RUTE SOFIA wrote: > Actually, there is such input. it's just a question of asking :-) > (NTT/Verio in the USA, for instance; I believe NTT > in europe also). i guess this is something for the isp design team to figure out where and which questions to ask. it was asked yesterday in the v6ops meeting and ti looks like, of the isps present yesterday, ntt/verio are the only one that have done it on the scale that is interesting for this exercise. though, it was not clear how much they will be able to share with us. other isps that have done it are welcomed to step forward. jasminko > I cannot help in terms of commercial services, given that FCCN only > provides non-commercial services. But, even ISPs such as FCCN can gladly > provide input. > > Please notice that part of this effor has already been done earlier, > either in the now extinct 6bone, or in some other projects related to v6. > It's just a matter of asking. An analysis is certainly more feasible than > a document trying to cover howtos for different ISPs... > > Rute > > From owner-v6ops@ops.ietf.org Wed Jul 16 05:23: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 FAA22670 for ; Wed, 16 Jul 2003 05:23:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ciUZ-0007hJ-Ek for v6ops-data@psg.com; Wed, 16 Jul 2003 09:22:31 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19ciUV-0007h6-Hl for v6ops@ops.ietf.org; Wed, 16 Jul 2003 09:22:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6G9MKB22047; Wed, 16 Jul 2003 12:22:20 +0300 Date: Wed, 16 Jul 2003 12:22:20 +0300 (EEST) From: Pekka Savola To: Jasminko Mulahusic cc: HELENA RUTE SOFIA , Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt In-Reply-To: <20030716105838.B270@vagabond.imslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-28.2 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Jul 2003, Jasminko Mulahusic wrote: > On Wed, 16 Jul 2003, HELENA RUTE SOFIA wrote: > > > Actually, there is such input. it's just a question of asking :-) > > (NTT/Verio in the USA, for instance; I believe NTT > > in europe also). > > i guess this is something for the isp design team to figure out where and > which questions to ask. > > it was asked yesterday in the v6ops meeting and ti looks like, of the isps > present yesterday, ntt/verio are the only one that have done it on the > scale that is interesting for this exercise. though, it was not clear how > much they will be able to share with us. > > other isps that have done it are welcomed to step forward. What I'd like to see is that people forget this "academic networks are not ISPs" model. Academic networks might not have certain drawbacks ISPs have, but there are enough similarities in the core network, network management, support infrastructure, etc. and to some degree, customer access interface to see that looking at the both are useful, and should not be excluded. However, there are at least several aspects to ISPs, however, which are typically not present in academic networks: *typically*, these become prevalent in the ISPs with DSL/cable/modem etc. access directly to the large number of customers (not big networks such as universities themselves). I think the *easiest* thing is to *first* work on issues which apply to both academic networks and ISPs, i.e. the ISP backbones, network management etc. Of course, other efforts are also welcome if there is enough energy and interest for them. -- 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 Jul 16 05:36: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 FAA23252 for ; Wed, 16 Jul 2003 05:36:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cihl-0008d8-Rx for v6ops-data@psg.com; Wed, 16 Jul 2003 09:36:09 +0000 Received: from [2001:218:1f01:10::2] (helo=guri.nttv6.jp) by psg.com with esmtp (Exim 4.14) id 19cihb-0008ah-N6 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 09:35:59 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id 132ABB162D; Wed, 16 Jul 2003 18:35:29 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id 996071265A4; Wed, 16 Jul 2003 18:35:28 +0900 (JST) Date: Wed, 16 Jul 2003 18:35:28 +0900 (JST) Message-Id: <20030716.183528.78753235.miyakawa@nttv6.jp> To: jasko@fakat.com Cc: rsofia@seas.upenn.edu, v6ops@ops.ietf.org, miyakawa@nttv6.jp Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt From: Shin Miyakawa In-Reply-To: <20030716105838.B270@vagabond.imslab.net> References: <20030716105838.B270@vagabond.imslab.net> Organizaton: NTT Communications X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think that I should make some comments on it ... ;-) > it was asked yesterday in the v6ops meeting and ti looks like, of the isps > present yesterday, ntt/verio are the only one that have done it on the > scale that is interesting for this exercise. though, it was not clear how > much they will be able to share with us. First of all, we do not think that we are the only one ;-) but anyway... yes, as I said yesterday, we are glad to make comments on the documents and finishing PD requirement draft ;-), I am ready to contribute to the document. I think that we can not disclose entire our experiences, design policy and implementation because we think that should be company secrets, but at the same time, we think that some part of information and technology should be shared by all of the world. # For example, we have already published our ADSL service spec as # http://www.ietf.org/internet-drafts/draft-shirasaki-dualstack-service-01.txt Best regards, Shin Miyakawa, Ph.D NTT Communications / WIDE Project E-mail:miyakawa@nttv6.jp / miyakawa@wide.ad.jp From owner-v6ops@ops.ietf.org Wed Jul 16 05:46: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 FAA23448 for ; Wed, 16 Jul 2003 05:46:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cir4-0009Fv-Bq for v6ops-data@psg.com; Wed, 16 Jul 2003 09:45:46 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.14) id 19cir0-0009Cy-FU for v6ops@ops.ietf.org; Wed, 16 Jul 2003 09:45:42 +0000 Received: (qmail 65886 invoked by uid 2502); 16 Jul 2003 09:45:10 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.135158 secs); 16/07/2003 10:45:10 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Jul 2003 09:45:10 -0000 Date: Wed, 16 Jul 2003 10:45:10 +0100 (WEST) From: Carlos Friacas To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: More comments on draft-palet-v6ops-proto41-nat-00.txt In-Reply-To: <027e01c34b60$bdd54480$eb88a051@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello. Again, inline. > > I have some questions: > > > > > > [1, Introduction] > > > > + "routers or tunnel servers" ~= "tunnel brokers" ? > > > > "(...) with a manual configuration at the IPv6 router tunnel-end." > > It isnt feasible for a service you intend to sell. using manual > > configurations on routers simply isnt scalable. > > I'm not implementing a service just describing an option to do it. > Is a decision of the implementor how it should be. Perhaps you should make a reference in your document, that this approach will lead to manual configurations. It would be nice to have this explicit -- you are documenting "testbed procedures". > > + reference to [3] > > > > I still dont understand why a project focused on > > Internet Exchanges (IXPs/NAPs/...) may have anything to do with NAT > > boxes and tunnels. End-users shouldnt be a topic. People managing > > networks, BGP and AS numbers should. > > Well, I guess you shouldn't try to tell the "inventor" and technical > responsible of a project what's the project scope. I've read the documents publicly available at the project's site. That was the reason i did the comment in the first place. > I can tell you that Euro6IX scope is not ONLY the IXs, but also how they > become useful to users, IXs are interconnection points. They have a central role in avoiding traffic from ISP A to ISP B in city X, from going to city Y. IXs' issues are lower latency, redundancy, etc... in the end, they will benefit users, but final users *DONT* connect to IXs. Your projects' credibility would be significant if AMS-IX, LINX, DECIX and others (real IXs) were a part of the project... > and whatever is needed to foster the > deployment of IPv6. I can concurr with that. IPv6 deployment (and widespread) depends also on the capability of ISPs connecting natively to their local IX (and transit providers connecting to several IXs). > This information is explained in the project > documents, publicly available. Yes, i've seen those. > > + "big opportunity to rapidly deploy a huge number of nodes and networks" > > > > You mean, nodes of tunnel brokers? > > networks? ...using a router as a NAT client? it may seem as a good "hack > > idea" to use a laptop for this. > > a theoretical question -- does the community want rapid deployment? with > > high RTTs and high chance of self-denial-of-service ? > > ...or is it a way to kill IPv6 faster? > > > > I think the text is clear on this point, and again I don't need to consider > how to implement the service, just offer a solution to deploy it. What i was trying to query, is your opinion on this being a *bad* solution or not (considering the roundtrip, complexity, etc...). In any case, huge number of nodes/networks connected to tunnel brokers (in reality they are only a few...) should be documented as a poor solution. > > + last paragraph > > > > You are listing the need to: > > - change tunnel brokers > > - change something in some operating systems (which ones?) > > Wouldnt be easier to v6-ize the NAT boxes? (dont know if it would be a > > good idea, as we dont need NAT boxes in the native IPv6 world...) > > > > I'm not specifying the tunnel brokers, and thus no need to indicate what scripts for what OS should be changed. This will be another > document. Its some sort of???: "I think IP will run better with 512 bits addresses -- hey everyone: change all your applications to meet my view!" I would wish to know more about what is needed on the tunnel brokers end... > No, not all the vendors are going to make the effort and investment in > provide native IPv6, and not all the existing hardware > supports it. If they dont provide, customers will simply prefer other vendors... > > [4, Applicability] > > > > + "The most usual scope of application of this technology seems to be > > SOHO and home environments, but is not limited to these." > > Do you mind to specify more environments? I think it would be important > > to specify, if they exist. > > Whatever where there is a NAT box ;-) So: "SOHO and Home". Where can we think about using a NAT box with an environment that you can name differently??? anyone? > > [5, NAT design considerations] > > > > + "New firmware/software versions of the NAT implementations should > > ensure the support of protocol-41 forwarding." > > > > I would add: ", and the means for its administrator to turn it on and > > off". > > As an example, we wouldnt want anyone using a connection to a tunnel > > broker if native IPv6 is available on the wire/air. > > Mandatory support for protocol-41 forwarding seems unnappropriate, as > > tunnels usage will fade away (as a method of getting IPv6 connectivity). > > > > The only one that have access to the NAT boxes is the administrator > (in most of the scenarios the owner/user = SOHO). changing this draft to "informational" was good. Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!" From owner-v6ops@ops.ietf.org Wed Jul 16 06:03: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 GAA23750 for ; Wed, 16 Jul 2003 06:02:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cj7G-000AIw-Kn for v6ops-data@psg.com; Wed, 16 Jul 2003 10:02:30 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.14) id 19cj7D-000AGk-VB for v6ops@ops.ietf.org; Wed, 16 Jul 2003 10:02:28 +0000 Received: (qmail 79685 invoked by uid 2502); 16 Jul 2003 10:01:56 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.117213 secs); 16/07/2003 11:01:56 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Jul 2003 10:01:56 -0000 Date: Wed, 16 Jul 2003 11:01:56 +0100 (WEST) From: Carlos Friacas To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt In-Reply-To: <05c901c34b75$ee749360$eb88a051@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Jul 2003, JORDI PALET MARTINEZ wrote: > And Euro6IX (www.euro6ix.org) is working in the commercial side ;-) Can you please point me out where i can read that *exactly* on the site? I cannot find that "commercial side" on the objectives or on the work plan. Thanks in advance. > Also, there is a lot of commercial deployment in Japan. > > Regards, > Jordi > > ----- Original Message ----- > From: "Tim Chown" > To: > Sent: Wednesday, July 16, 2003 10:23 AM > Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt > > > > On Wed, Jul 16, 2003 at 10:15:52AM +0200, Jasminko Mulahusic wrote: > > > > > > true. the thing is that we are not sure if there are any isps that have > > > deployed fully commercial v6 networks, operated in the same way as their > > > v4 networks. and even if we could find them it is not sure they would be > > > able to share the results with us. > > > > The main production deployments now are in the research networks, which have > > to be commercial quality, but may not offer all the types of services that > > commercial ISPs do. > > > > But v6 is running dual stack in Abilene, GEANT, many European NRENs and > > the transatlantic link(s) dual-stack without v6 breaking v4. > > > > But there are many gaps. Projects such as 6NET are trying to document and > > where possible work on these (www.6net.org/publications). > > > > Tim > > > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com > > > ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!" From owner-v6ops@ops.ietf.org Wed Jul 16 06:13:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23926 for ; Wed, 16 Jul 2003 06:13:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cjHC-000Atm-Vi for v6ops-data@psg.com; Wed, 16 Jul 2003 10:12:46 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19cjHA-000AsR-5u for v6ops@ops.ietf.org; Wed, 16 Jul 2003 10:12:44 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 38-md50000000041.tmp for ; Wed, 16 Jul 2003 12:13:41 +0200 Message-ID: <07e801c34b82$e87d66f0$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt Date: Wed, 16 Jul 2003 12:12:43 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 12:13:41 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Well ... look who are the partners. Anyway, you've the info in the home page, and in the objectives section pointed out by that page ... Regards, Jordi ----- Original Message ----- From: "Carlos Friacas" To: "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, July 16, 2003 12:01 PM Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt > On Wed, 16 Jul 2003, JORDI PALET MARTINEZ wrote: > > > And Euro6IX (www.euro6ix.org) is working in the commercial side ;-) > > Can you please point me out where i can read that *exactly* on the site? > > I cannot find that "commercial side" on the objectives or on the work > plan. > > Thanks in advance. > > > > Also, there is a lot of commercial deployment in Japan. > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "Tim Chown" > > To: > > Sent: Wednesday, July 16, 2003 10:23 AM > > Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt > > > > > > > On Wed, Jul 16, 2003 at 10:15:52AM +0200, Jasminko Mulahusic wrote: > > > > > > > > true. the thing is that we are not sure if there are any isps that have > > > > deployed fully commercial v6 networks, operated in the same way as their > > > > v4 networks. and even if we could find them it is not sure they would be > > > > able to share the results with us. > > > > > > The main production deployments now are in the research networks, which have > > > to be commercial quality, but may not offer all the types of services that > > > commercial ISPs do. > > > > > > But v6 is running dual stack in Abilene, GEANT, many European NRENs and > > > the transatlantic link(s) dual-stack without v6 breaking v4. > > > > > > But there are many gaps. Projects such as 6NET are trying to document and > > > where possible work on these (www.6net.org/publications). > > > > > > Tim > > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on-line at: > > http://www.ipv6-es.com > > > > > > > > > ./Carlos "Networking is fun!" > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 > [ See me @ h323:videoconf05.fccn.pt] > "Internet is just routes (125953/461), naming (millions) and... people!" > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 06:19: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 GAA24145 for ; Wed, 16 Jul 2003 06:19:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cjNg-000BHD-0P for v6ops-data@psg.com; Wed, 16 Jul 2003 10:19:28 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net ident=qmailr) by psg.com with smtp (Exim 4.14) id 19cjNd-000BH1-LF for v6ops@ops.ietf.org; Wed, 16 Jul 2003 10:19:25 +0000 Received: (qmail 86703 invoked by uid 1007); 16 Jul 2003 10:19:24 -0000 Date: Wed, 16 Jul 2003 12:19:24 +0200 From: Gert Doering To: JORDI PALET MARTINEZ Cc: v6ops@ops.ietf.org Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt Message-ID: <20030716121924.R67740@Space.Net> References: <20030716100816.X270@vagabond.imslab.net> <20030716082336.GJ26779@login.ecs.soton.ac.uk> <05c901c34b75$ee749360$eb88a051@consulintel.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <05c901c34b75$ee749360$eb88a051@consulintel.es>; from jordi.palet@consulintel.es on Wed, Jul 16, 2003 at 10:40:15AM +0200 X-NCC-RegID: de.space X-Spam-Status: No, hits=-35.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, Jul 16, 2003 at 10:40:15AM +0200, JORDI PALET MARTINEZ wrote: > And Euro6IX (www.euro6ix.org) is working in the commercial side ;-) Isn't Euro6IX the EU-research-money fundet project that doesn't permit connection of any commercial network? Anyway - besides the research projects, there are already a number of commercial ISPs in Europe that struggle with implementing a commercial- grade IPv6 service. The problems encountered are what you'd expect - hardware vendor support, upstream ISPs that do not support IPv6, NOC people training, etc. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Wed Jul 16 06:30: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 GAA24459 for ; Wed, 16 Jul 2003 06:30:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cjWo-000Bp3-U9 for v6ops-data@psg.com; Wed, 16 Jul 2003 10:28:54 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19cjWl-000Bmg-Kt for v6ops@ops.ietf.org; Wed, 16 Jul 2003 10:28:51 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 25-md50000000042.tmp for ; Wed, 16 Jul 2003 12:29:47 +0200 Message-ID: <085b01c34b85$2536d570$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20030716100816.X270@vagabond.imslab.net> <20030716082336.GJ26779@login.ecs.soton.ac.uk> <05c901c34b75$ee749360$eb88a051@consulintel.es> <20030716121924.R67740@Space.Net> Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt Date: Wed, 16 Jul 2003 12:28:38 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 12:29:47 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A R&D funded project can never be involved in commercial transit, that's clear. But we have several ISPs working with the project, and connected to it, that "use" the project to build their networks before going into commercial, and they can also have trial users (if they aren't charge for the service). Regards, Jordi ----- Original Message ----- From: "Gert Doering" To: "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, July 16, 2003 12:19 PM Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt > Hi, > > On Wed, Jul 16, 2003 at 10:40:15AM +0200, JORDI PALET MARTINEZ wrote: > > And Euro6IX (www.euro6ix.org) is working in the commercial side ;-) > > Isn't Euro6IX the EU-research-money fundet project that doesn't permit > connection of any commercial network? > > Anyway - besides the research projects, there are already a number of > commercial ISPs in Europe that struggle with implementing a commercial- > grade IPv6 service. > > The problems encountered are what you'd expect - hardware vendor support, > upstream ISPs that do not support IPv6, NOC people training, etc. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 55442 (55636) > > SpaceNet AG Mail: netmaster@Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 07:27: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 HAA25857 for ; Wed, 16 Jul 2003 07:27:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ckQG-000EpS-Ev for v6ops-data@psg.com; Wed, 16 Jul 2003 11:26:12 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19ckQC-000Ep1-KZ for v6ops@ops.ietf.org; Wed, 16 Jul 2003 11:26:08 +0000 Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6GBQ0M1017268 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 07:26:00 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6GBPxWQ011887; Wed, 16 Jul 2003 07:26:00 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6GBPxVl011884; Wed, 16 Jul 2003 07:25:59 -0400 (EDT) Date: Wed, 16 Jul 2003 07:25:59 -0400 (EDT) From: "Rute C. Sofia" To: Pekka Savola cc: Jasminko Mulahusic , Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-15.2 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, > What I'd like to see is that people forget this "academic networks are not > ISPs" model. > > Academic networks might not have certain drawbacks ISPs have, but there > are enough similarities in the core network, network management, support > infrastructure, etc. and to some degree, customer access interface to see > that looking at the both are useful, and should not be excluded. excelent point... my 2-cents on this: instead of asking people (read ISPs here...) to come forward and speak about what they've done, why not simply try to summarise the aspects that would be interesting to analyse and then, simply send that list to the mailing-list. This would work as a form, which then might give rise to an analysis, or to a set of scenarios that could be covered (again, simply in terms of analysis of what peoplare are currently doing, and not as a howto). Possibly, an initial list wouldn't address issues such as policies that can't be disclosed (thinking in commercial terms), or other issues that might be a bit controverse. And, this would also possibly add some interest in something that is still too vague... rute From owner-v6ops@ops.ietf.org Wed Jul 16 07:43: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 HAA26465 for ; Wed, 16 Jul 2003 07:43:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ckfN-000FoP-4P for v6ops-data@psg.com; Wed, 16 Jul 2003 11:41:49 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19ckfK-000FnL-9G for v6ops@ops.ietf.org; Wed, 16 Jul 2003 11:41:46 +0000 Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6GBfgM1019410 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 07:41:42 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6GBfgWQ012528; Wed, 16 Jul 2003 07:41:42 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6GBff2G012525; Wed, 16 Jul 2003 07:41:41 -0400 (EDT) Date: Wed, 16 Jul 2003 07:41:41 -0400 (EDT) From: "Rute C. Sofia" To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT In-Reply-To: <04e601c34b6d$8cbb4ef0$eb88a051@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-14.7 required=5.0 tests=BAYES_10,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jordi, > This is exactly what I already reflected in the new version of the draft. > > I will wait for more inputs before publish it. I understand the point of your document, but really do not see a place for it... It's not so much a question of the "mechanism" (it is here; it is used sometimes), but really, a question of the purpose of the document. There has to be a clear purpose (and maybe I'm missing it), otherwise, we just end up adding more entropy...Can you please answer clearly the following questions: 1) does the document introduce a *significant* contribution to current deployment status? 2) if something should be forced to vendors, that should be either ipv6 or 6to4 ;-). Why impose a third option, given that only a subset of scenarios will *possibly* gain with it ?? And, a bit out of scope in technical terms...out of curiosity, if you already have an "updated" version of the draft (updated in which sense??), why didn't you present it yesterday? thanks, rute From owner-v6ops@ops.ietf.org Wed Jul 16 07:54: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 HAA26694 for ; Wed, 16 Jul 2003 07:54:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ckqk-000Gfd-T2 for v6ops-data@psg.com; Wed, 16 Jul 2003 11:53:34 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.14) id 19ckqi-000GfP-1P for v6ops@ops.ietf.org; Wed, 16 Jul 2003 11:53:32 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA22877 for ; Wed, 16 Jul 2003 12:53:30 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id MAA16720 for ; Wed, 16 Jul 2003 12:53:30 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6GBrUQ31567 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 12:53:30 +0100 Date: Wed, 16 Jul 2003 12:53:29 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT Message-ID: <20030716115329.GA31469@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <04e601c34b6d$8cbb4ef0$eb88a051@consulintel.es> 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=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk There are two uses for the document: 1. To alert people to the (to some obvious) protocol41 "trick" to carry an IPv6 tunnel into a NAT network. This is very handy for early adoptors (the IPv6 geeks). It is not a long-term solution. 2. To alert NAT vendors to the fact that if they make what should be a simple mod to their formware - *if* they are not already supporting IPv6 in some other way e.g. 6to4 or better - they can enable their geek customers to use IPv6 at home. I think it's a useful informational document, so long as the "trick" is just seen as an early adoptor/last resort mechanism. It is a mechanism we use a lot btw. tim On Wed, Jul 16, 2003 at 07:41:41AM -0400, Rute C. Sofia wrote: > Jordi, > > > > This is exactly what I already reflected in the new version of the draft. > > > > I will wait for more inputs before publish it. > > > I understand the point of your document, but really do not see a place for > it... It's not so much a question of the "mechanism" (it is here; it is > used > sometimes), but really, a question of the purpose of the document. > There has to be a clear purpose (and maybe I'm missing it), otherwise, > we just end up adding more entropy...Can you please answer clearly the > following questions: > > 1) does the document introduce a *significant* contribution to current > deployment status? > 2) if something should be forced to vendors, that should be either ipv6 or > 6to4 ;-). Why impose a third option, given that only a subset of scenarios > will *possibly* gain with it ?? > > And, a bit out of scope in technical terms...out of curiosity, if you > already have an "updated" version of the draft (updated in which sense??), > why didn't you present it yesterday? > > thanks, > rute > From owner-v6ops@ops.ietf.org Wed Jul 16 08:02: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 IAA26905 for ; Wed, 16 Jul 2003 08:02:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ckyp-000HML-4n for v6ops-data@psg.com; Wed, 16 Jul 2003 12:01:55 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19ckyl-000HJu-QE for v6ops@ops.ietf.org; Wed, 16 Jul 2003 12:01:52 +0000 Received: from consulintel02 ([81.160.136.235]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 18-md50000000046.tmp for ; Wed, 16 Jul 2003 14:02:46 +0200 Message-ID: <096d01c34b92$25dc7860$eb88a051@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: 6to4 vs forwarding IP proto41 in NAT Date: Wed, 16 Jul 2003 14:02:27 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Wed, 16 Jul 2003 14:02:46 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 81.160.136.235 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rute, 1) I don't think the purpose of the IETF documents/work is only for *significant* contributions to current deployment status, and I explained this in the yesterday session. The work describes the situation that isn't documented (but used). 2) If the vendors don't want to use native or 6to4, and we don't have a backup option, we miss the chance to help the people to connect to IPv6 in a way that we know is possible. My survey show that the subset of "scenarios" is big enough to be very relevant. The update has been done yesterday night, with the inputs received during the meeting, and I will wait some more days for additional inputs before an "official" publication. Regards, Jordi ----- Original Message ----- From: "Rute C. Sofia" To: "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, July 16, 2003 1:41 PM Subject: Re: 6to4 vs forwarding IP proto41 in NAT > Jordi, > > > > This is exactly what I already reflected in the new version of the draft. > > > > I will wait for more inputs before publish it. > > > I understand the point of your document, but really do not see a place for > it... It's not so much a question of the "mechanism" (it is here; it is > used > sometimes), but really, a question of the purpose of the document. > There has to be a clear purpose (and maybe I'm missing it), otherwise, > we just end up adding more entropy...Can you please answer clearly the > following questions: > > 1) does the document introduce a *significant* contribution to current > deployment status? > 2) if something should be forced to vendors, that should be either ipv6 or > 6to4 ;-). Why impose a third option, given that only a subset of scenarios > will *possibly* gain with it ?? > > And, a bit out of scope in technical terms...out of curiosity, if you > already have an "updated" version of the draft (updated in which sense??), > why didn't you present it yesterday? > > thanks, > rute > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Wed Jul 16 08:36:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27835 for ; Wed, 16 Jul 2003 08:36:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19clVs-000J6k-8l for v6ops-data@psg.com; Wed, 16 Jul 2003 12:36:04 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.14) id 19clVo-000J4T-BW for v6ops@ops.ietf.org; Wed, 16 Jul 2003 12:36:00 +0000 Received: (qmail 12768 invoked by uid 2502); 16 Jul 2003 12:35:28 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.118864 secs); 16/07/2003 13:35:28 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Jul 2003 12:35:28 -0000 Date: Wed, 16 Jul 2003 13:35:28 +0100 (WEST) From: Carlos Friacas To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT In-Reply-To: <20030716115329.GA31469@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Jul 2003, Tim Chown wrote: > > There are two uses for the document: > > 1. To alert people to the (to some obvious) protocol41 "trick" to carry an > IPv6 tunnel into a NAT network. This is very handy for early adoptors > (the IPv6 geeks). It is not a long-term solution. If it is documented (approved), it might be considered a long-term solution by some people... because it would classify as an "hack" documented by the ietf! And moreover, some ipv6 projects/sites already document this. Euro6ix is an example. > 2. To alert NAT vendors to the fact that if they make what should be a > simple mod to their formware - *if* they are not already supporting IPv6 > in some other way e.g. 6to4 or better - they can enable their geek > customers to use IPv6 at home. Again, focusing on "geek customers" will not take IPv6 usage anywhere. IPv6 deployment (and usage) will only rely on *everybody* using it (sometimes), without having to know IPv6 is there. Vendors work based on demand: if you have 5 or 50 geeks sending emails, they do nothing, if some big enterprise requests it, they will try to comply promptly. > I think it's a useful informational document, so long as the "trick" is > just seen as an early adoptor/last resort mechanism. > > It is a mechanism we use a lot btw. ...but certainly wish not having to do it... ;-))) > tim Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167 [ See me @ h323:videoconf05.fccn.pt] "Internet is just routes (125953/461), naming (millions) and... people!" From owner-v6ops@ops.ietf.org Wed Jul 16 08:46: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 IAA28033 for ; Wed, 16 Jul 2003 08:46:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cleZ-000JgN-5k for v6ops-data@psg.com; Wed, 16 Jul 2003 12:45:03 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19cleU-000JfP-Lu for v6ops@ops.ietf.org; Wed, 16 Jul 2003 12:44:58 +0000 Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6GCiuM1029040 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 08:44:56 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6GCitWQ016029; Wed, 16 Jul 2003 08:44:55 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6GCitp2016025; Wed, 16 Jul 2003 08:44:55 -0400 (EDT) Date: Wed, 16 Jul 2003 08:44:55 -0400 (EDT) From: "Rute C. Sofia" To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT In-Reply-To: <20030716115329.GA31469@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Tim, > > 1. To alert people to the (to some obvious) protocol41 "trick" to carry an > IPv6 tunnel into a NAT network. This is very handy for early adoptors > (the IPv6 geeks). It is not a long-term solution. > > 2. To alert NAT vendors to the fact that if they make what should be a > simple mod to their formware - *if* they are not already supporting IPv6 > in some other way e.g. 6to4 or better - they can enable their geek > customers to use IPv6 at home. > > I think it's a useful informational document, so long as the "trick" is > just seen as an early adoptor/last resort mechanism. > > It is a mechanism we use a lot btw. I completely agree with the sentence above, and that was stated in my previous mail. But, Point 2. above says it all: "*if* they are not already supporting IPv6 in some other way e.g. 6to4 or better..."... Given that the solution that it's trying to be "imposed" is a temporary solution, not compatible with the other possible ones, I do not see a point in creating a document about it. I do understand that it's in use ;-P, but an individual draft about this does not seem really useful, in my viewpoint. Much less a WG document on this... Maybe I'm completely wrong here, but again, what I'm transmitting is that I don't see the need to document a temporary solution, simply arguing with the purpose that vendors should give this third option...which is already in use...there is so much work to be done regarding v6ops, that my fear is that this document just ends up in simply adding entropy... Rute From owner-v6ops@ops.ietf.org Wed Jul 16 08:48: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 IAA28107 for ; Wed, 16 Jul 2003 08:48:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19clhE-000JrT-Px for v6ops-data@psg.com; Wed, 16 Jul 2003 12:47:48 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19clh9-000JqB-Dl for v6ops@ops.ietf.org; Wed, 16 Jul 2003 12:47:43 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GClhiR023135 for ; Wed, 16 Jul 2003 06:47:43 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI400ECZBJIRF@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 16 Jul 2003 06:47:42 -0600 (MDT) Received: from sun.com ([81.160.173.145]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI400BB5BJGUM@mail.sun.net> for v6ops@ops.ietf.org; Wed, 16 Jul 2003 06:47:42 -0600 (MDT) Date: Wed, 16 Jul 2003 05:47:42 -0700 From: Alain Durand Subject: IPv6 on by default slides To: v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_20,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Here is a link to my slides for today's presentation for those of you who'd rather like to see them on their laptop. http://playground.sun.com/ipv6/IPv6ONbyDefault.pdf - Alain. From owner-v6ops@ops.ietf.org Wed Jul 16 08:53: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 IAA28266 for ; Wed, 16 Jul 2003 08:53:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19clmW-000KKf-Qu for v6ops-data@psg.com; Wed, 16 Jul 2003 12:53:16 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19clmU-000KK2-1C for v6ops@ops.ietf.org; Wed, 16 Jul 2003 12:53:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6GCrB724054 for ; Wed, 16 Jul 2003 15:53:11 +0300 Date: Wed, 16 Jul 2003 15:53:11 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Please stop thread: 6to4 vs forwarding IP proto41 in NAT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I think the thread: 6to4 vs forwarding IP proto41 in NAT has degenerated a bit, and I fail to see whether anything constructive can come of it. Please consider twice before continuinig posting about the subject. I think it should be clear that revising the documentation of the proto41 forwarding feature is potentially useful -- at least I didn't know such feature existed. Whether such should/could be recommended is another issue, but we'll get back to that later when/if that seems appropriate. -- 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 Jul 16 08:54: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 IAA28307 for ; Wed, 16 Jul 2003 08:54:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cln9-000KNj-2L for v6ops-data@psg.com; Wed, 16 Jul 2003 12:53:55 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19cln6-000KN8-0O for v6ops@ops.ietf.org; Wed, 16 Jul 2003 12:53:52 +0000 Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6GCrlM1030747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 08:53:48 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6GCrlWQ016523; Wed, 16 Jul 2003 08:53:47 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6GCrl1w016520; Wed, 16 Jul 2003 08:53:47 -0400 (EDT) Date: Wed, 16 Jul 2003 08:53:47 -0400 (EDT) From: "Rute C. Sofia" To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: 6to4 vs forwarding IP proto41 in NAT In-Reply-To: <096d01c34b92$25dc7860$eb88a051@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jordi, > 1) I don't think the purpose of the IETF documents/work is only for *significant* contributions to current deployment status, and I > explained this in the yesterday session. The work describes the situation that isn't documented (but used). > 2) If the vendors don't want to use native or 6to4, and we don't have a backup option, we miss the chance to help the people to > connect to IPv6 in a way that we know is possible. My survey show that the subset of "scenarios" is big enough to be very relevant. please notice that I am not against the solution you are describing. I see a draft (if within the goals of a WG) as a document that will help all of "us" somehow. It might open path for future exploration on some issues, present an analysis, or describe some experimental situation that could help a significant bunch of people . This is what I mean by a significant contribution :-). it can be a minor thing, but significant somehow ;-) Your draft presents a hack/trick (whatever you'd like to name it, but I'm avoiding the word mechanism) that is a temporary solution; there are two other possible ways that vendors should follow *before* simply deciding on following the draft. But, let's look at the hypothetical scenario, where the trick was imposed, given that by default it was there (what you're saying above). the only people benefiting from it would be a small subset of people! So it is here that I really don't see the purpose in creating another draft ... Rute > > The update has been done yesterday night, with the inputs received during the meeting, and I will wait some more days for additional > inputs before an "official" publication. > > Regards, > Jordi > > ----- Original Message ----- > From: "Rute C. Sofia" > To: "JORDI PALET MARTINEZ" > Cc: > Sent: Wednesday, July 16, 2003 1:41 PM > Subject: Re: 6to4 vs forwarding IP proto41 in NAT > > > > Jordi, > > > > > > > This is exactly what I already reflected in the new version of the draft. > > > > > > I will wait for more inputs before publish it. > > > > > > I understand the point of your document, but really do not see a place for > > it... It's not so much a question of the "mechanism" (it is here; it is > > used > > sometimes), but really, a question of the purpose of the document. > > There has to be a clear purpose (and maybe I'm missing it), otherwise, > > we just end up adding more entropy...Can you please answer clearly the > > following questions: > > > > 1) does the document introduce a *significant* contribution to current > > deployment status? > > 2) if something should be forced to vendors, that should be either ipv6 or > > 6to4 ;-). Why impose a third option, given that only a subset of scenarios > > will *possibly* gain with it ?? > > > > And, a bit out of scope in technical terms...out of curiosity, if you > > already have an "updated" version of the draft (updated in which sense??), > > why didn't you present it yesterday? > > > > thanks, > > rute > > > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com > > > From owner-v6ops@ops.ietf.org Wed Jul 16 09:15: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 JAA28826 for ; Wed, 16 Jul 2003 09:15:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cm7H-000Lw2-HS for v6ops-data@psg.com; Wed, 16 Jul 2003 13:14:43 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cm7D-000Lvp-0P for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:14:39 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B02A2773E; Wed, 16 Jul 2003 09:14:37 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:14:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 6to4 vs forwarding IP proto41 in NAT Date: Wed, 16 Jul 2003 09:14:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04285128@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 vs forwarding IP proto41 in NAT Thread-Index: AcNK499u2umZLhf3Q3STpdCqrdB0cQAARRlWAC3IfeA= From: "Bound, Jim" To: "Christian Huitema" , "Tim Chown" , X-OriginalArrivalTime: 16 Jul 2003 13:14:37.0554 (UTC) FILETIME=[352BA520:01C34B9C] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable thats one solution. the other is what Jordi proposes to get NAT vendors to support this outside of the PC and plethora of devices in the home. /jim > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 > Sent: Tuesday, July 15, 2003 11:23 AM > To: Tim Chown; v6ops@ops.ietf.org > Subject: RE: 6to4 vs forwarding IP proto41 in NAT >=20 >=20 > On Windows XP, with IPv6 enabled, if you ask to "share a=20 > link", the PC will behave as an IPv4 NAT (using ICS) and as a=20 > 6to4 router. So I guess there is at least one example of "NAT=20 > that is also a 6to4 router." >=20 > ________________________________ >=20 > From: owner-v6ops@ops.ietf.org on behalf of Tim Chown > Sent: Tue 7/15/2003 8:08 AM > To: v6ops@ops.ietf.org > Subject: Re: 6to4 vs forwarding IP proto41 in NAT >=20 >=20 >=20 > The advantage for plain proto41 forwarding is that you don't=20 > have to decapsulate for it to work - just pass it on :) The=20 > NAT web config screen can just have a checkbox to forward=20 > proto41 and a field to specify the RFC1918 address to forward it to. >=20 > But agreed if the vendor is implementing 6to4, there is no=20 > reason why they couldn't choose to do this. >=20 > I wouldn't like to lose the ability to run a tunnel broker=20 > client inside my network (for a host or network broker=20 > client) because of 6to4 support on the router (which I=20 > applaud - and I'd be interested to know which vendors are=20 > implementing it... Christian?) >=20 > Of course ideally we want IPv6 natively, but... >=20 > Tim >=20 > On Tue, Jul 15, 2003 at 08:01:45AM -0700, Alain Durand wrote: > > A NAT box could do the following when receiving an IPv6 packet=20 > > encapsulated in IPv4 with proto 41: > > > > If IPv6 dst does not belong to the local 6to4 /48 prefix, forward=20 > > internally, else decapsulate. > > > > Why will will not work? > > > > - Alain. > > >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:16: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 JAA28854 for ; Wed, 16 Jul 2003 09:16:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cm91-000M35-33 for v6ops-data@psg.com; Wed, 16 Jul 2003 13:16:31 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cm8x-000M2a-No for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:16:27 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2928F7CFD; Wed, 16 Jul 2003 09:16:27 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:16:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Date: Wed, 16 Jul 2003 09:16:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04285129@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on draft-palet-v6ops-proto41-nat-00.txt discussion Thread-Index: AcNK6AiZYxJ+JxvzRyqn2TUOd4TrPgAtEvGg From: "Bound, Jim" To: "JORDI PALET MARTINEZ" , X-OriginalArrivalTime: 16 Jul 2003 13:16:24.0104 (UTC) FILETIME=[74ADE280:01C34B9C] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable good. I could not be there and the mail is confusing me what happened. this is important work for v6ops and I still think we need to influence the nat box vendors and isps to use that as one alternative to other missions in the market. /jim > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es]=20 > Sent: Tuesday, July 15, 2003 11:44 AM > To: v6ops@ops.ietf.org > Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt=20 > discussion >=20 >=20 > Hi, >=20 > I agree with Itojun, my feeling is that the WG chairs=20 > requested me to update the document, and I will do so with=20 > the comments from the WG and any emails that I receive in the=20 > next two weeks, more or less. >=20 > So please, all, provide your inputs ! >=20 > Regards, > Jordi >=20 > ----- Original Message -----=20 > From: > To: "Keith Moore" > Cc: "Christian Huitema" ;=20 > > Sent: Tuesday, July 15, 2003 5:28 PM > Subject: Re: comment on draft-palet-v6ops-proto41-nat-00.txt=20 > discussion >=20 >=20 > > >> The consensus in the room was that Jordi's draft should simply=20 > > >> document the current practice, with all its considerations, and=20 > > >> should refrain from making any recommendation to NAT vendors. > > > > > >I must have missed that consensus call. > > > > i (and some others) commented like above, but there was no=20 > consensus=20 > > call. christian's statement is a little bit misleading i guess. > > > > itojun > > >=20 > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:20: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 JAA28950 for ; Wed, 16 Jul 2003 09:20:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmBx-000MFS-4L for v6ops-data@psg.com; Wed, 16 Jul 2003 13:19:33 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cmBt-000MF3-K5 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:19:29 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 15046BD50; Wed, 16 Jul 2003 09:19:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:19:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Discussion regarding IP proto41 in NAT Date: Wed, 16 Jul 2003 09:19:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428512A@tayexc13.americas.cpqcorp.net> Thread-Topic: Discussion regarding IP proto41 in NAT Thread-Index: AcNK6E3W999f+Y7KTIKzPX9ocWPu4AAtDvsQ From: "Bound, Jim" To: "Carlos Friacas" , "Marcin Michalak" Cc: X-OriginalArrivalTime: 16 Jul 2003 13:19:28.0911 (UTC) FILETIME=[E2D531F0:01C34B9C] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable funny. I think the exact opposite of this input. but thats fine. I think the below is exactly what should be done. I turn on my device in my house. it configures Ipv6. knows to use proto 41 with tunnels and it works through my router/dsl box and with my ISP. all below must happen. this way I can Microsoft, Linux, Freebsd, other UNIX, Symbian, et al on all my devices with basic IPv6 and I avoid any particular lock-in to any vendor and creates an open market. I prefer this and most users I know do too. /jim > -----Original Message----- > From: Carlos Friacas [mailto:cfriacas@fccn.pt]=20 > Sent: Tuesday, July 15, 2003 11:45 AM > To: Marcin Michalak > Cc: v6ops@ops.ietf.org > Subject: Re: Discussion regarding IP proto41 in NAT >=20 >=20 > On Tue, 15 Jul 2003, Marcin Michalak wrote: >=20 > > Hello, > > Forgive me if this is already done: It seems to me that we need to=20 > > have clear recommendations with priorities what solutions are to be=20 > > used. Something like Margaret was saying: native IPv6, then ... > > > > What also I see that many things are becoming obvious for=20 > us, but may=20 > > not be so obvious for the others. So in my opinion it should be=20 > > clearly stated in all transition documents that native IPv6 is the=20 > > best and recommended solution. Have a good time in Vienna (or=20 > > somewhere else :-)), > > Marcin > > > > ---------------------------------------------------------- > > Marcin Michalak Research Engineer > > Mobile: +41 79 330 83 51 Telscom AG >=20 >=20 > I also strongly second this view. > This discussion is about easying SOHO and HOME deployment,=20 > but it seems to me that the quality involved with using this=20 > mechanism might turn users against IPv6 usage. The focus should be to: > a) ISPs requesting addresses > b) getting the BGP sessions up and running > c) ISPs going dual-stack on their backbone > d) ISPs extending native IPv6 to their customers "door" (SOHO=20 > *and* HOME) >=20 >=20 > Again -- you All -- have a good time in Vienna. >=20 >=20 > Regards, >=20 > ./Carlos =20 > "Networking is fun!" > -------------- [http://www.ip6.fccn.pt] =20 > http://www.fccn.pt > , CMF8-RIPE, CF596-ARIN,=20 > Wide Area Network Workgroup F.C.C.N. - Fundacao para a=20 > Computacao Cientifica Nacional fax:+351 218472167 > [ See me @ h323:videoconf05.fccn.pt] > "Internet is just routes (125953/461), naming (millions)=20 > and... people!" >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:25: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 JAA29196 for ; Wed, 16 Jul 2003 09:25:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmGv-000Mhx-OS for v6ops-data@psg.com; Wed, 16 Jul 2003 13:24:41 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cmGs-000Mhb-Vu for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:24:39 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3BCB376D4; Wed, 16 Jul 2003 09:24:38 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:24:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 6to4 vs forwarding IP proto41 in NAT Date: Wed, 16 Jul 2003 09:24:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428512C@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 vs forwarding IP proto41 in NAT Thread-Index: AcNLavGMBMP97p0bSgKerja+ovof2AAMkf6w From: "Bound, Jim" To: "HELENA RUTE SOFIA" , "JORDI PALET MARTINEZ" Cc: X-OriginalArrivalTime: 16 Jul 2003 13:24:38.0023 (UTC) FILETIME=[9B13F170:01C34B9D] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable because if the nat vendors have guidance to pass through proto 41 and ISPs will decap IPv6 can be used as tunnel to the outside word for two IPv6 nodes to communicate using IPv6 all be it with IPv4. It gives reason to nat and isps to do init ipv6. also permits other options and that is the work of this draft to flush out. if we don't flush it out then I agree. but this also would permit tunnel brokers which I think are a good idea for home use. we will learn and expand from pekkas list he sent from this exercise and why jordis work is important for us as engineers working on transition to analyze. /jim > -----Original Message----- > From: HELENA RUTE SOFIA [mailto:rsofia@seas.upenn.edu]=20 > Sent: Wednesday, July 16, 2003 3:20 AM > To: JORDI PALET MARTINEZ > Cc: v6ops@ops.ietf.org > Subject: Re: 6to4 vs forwarding IP proto41 in NAT >=20 >=20 >=20 > One thing that is really puzzling me about this draft is: do=20 > we really need this?? There are currently two options that=20 > have "more" priority in terms of implementation, i.e., v6 and=20 > 6to4...so why try to create a document on something that is=20 > currently assumed to work, and that is only used as a "hack",=20 > when one of the other two is not working?? Why do we need a=20 > document on this? >=20 > Rute >=20 >=20 > On Tue, 15 Jul 2003, JORDI PALET MARTINEZ wrote: >=20 > > Agree, it should work. > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "Alain Durand" > > To: > > Sent: Tuesday, July 15, 2003 5:01 PM > > Subject: 6to4 vs forwarding IP proto41 in NAT > > > > > > > A NAT box could do the following when receiving an IPv6 packet=20 > > > encapsulated in IPv4 with proto 41: > > > > > > If IPv6 dst does not belong to the local 6to4 /48 prefix, forward=20 > > > internally, else decapsulate. > > > > > > Why will will not work? > > > > > > - Alain. > > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on-line at: > > http://www.ipv6-es.com > > > > > > >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:26: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 JAA29249 for ; Wed, 16 Jul 2003 09:26:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmI2-000Mqp-Ai for v6ops-data@psg.com; Wed, 16 Jul 2003 13:25:50 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cmHz-000MqC-CK for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:25:47 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CB9E9CB02; Wed, 16 Jul 2003 09:25:46 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:25:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on draft-lind-v6ops-isp-scenarios-00.txt Date: Wed, 16 Jul 2003 09:25:46 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428512D@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on draft-lind-v6ops-isp-scenarios-00.txt Thread-Index: AcNLcsFtvsiDtyQ1SJuLSDWn9I8spQAKu+dQ From: "Bound, Jim" To: "Jasminko Mulahusic" , "HELENA RUTE SOFIA" Cc: X-OriginalArrivalTime: 16 Jul 2003 13:25:46.0674 (UTC) FILETIME=[C3FF4120:01C34B9D] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable ntt verio has and in the u.s. other ISPs have some support now like Sprint. its happening and why we need to think and assume they will deploy. /jim > -----Original Message----- > From: Jasminko Mulahusic [mailto:jasko@fakat.com]=20 > Sent: Wednesday, July 16, 2003 4:16 AM > To: HELENA RUTE SOFIA > Cc: v6ops@ops.ietf.org > Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt >=20 >=20 >=20 >=20 > On Wed, 16 Jul 2003, HELENA RUTE SOFIA wrote: >=20 > > It seems to me that 1. and 2. could simply start by an analysis of=20 > > current deployed solutions; trying to exhaustively cover=20 > the possible=20 > > situations that could be a representative subset of real=20 > scenarios, to=20 > > provide some "howto" is an endless task, and would take so=20 > long, that=20 > > it would probably not make much sense in the end...also, different=20 > > ISPs not only have different sizes, use different technologies, but=20 > > also have different purposes in terms of offered services; and, we=20 > > also have commercial services and research services... > > >=20 > true. the thing is that we are not sure if there are any isps=20 > that have deployed fully commercial v6 networks, operated in=20 > the same way as their v4 networks. and even if we could find=20 > them it is not sure they would be able to share the results with us. >=20 > jasminko >=20 > > So, as was also mentioned yesterday at the v6ops meeting, why not=20 > > simply change the document to provide an analysis of current=20 > > scenarios? I'm pretty sure that it doesn't cost much to=20 > some ISPs of=20 > > different sizes to provide some input on a draft that=20 > somebody could=20 > > put together... > > > > Ch., > > rute > > > > > > >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:26: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 JAA29265 for ; Wed, 16 Jul 2003 09:26:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmIj-000MuZ-Et for v6ops-data@psg.com; Wed, 16 Jul 2003 13:26:33 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cmIh-000MuJ-CB for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:26:31 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id CD4CCBC70; Wed, 16 Jul 2003 09:26:30 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:26:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on draft-lind-v6ops-isp-scenarios-00.txt Date: Wed, 16 Jul 2003 09:26:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0428512E@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on draft-lind-v6ops-isp-scenarios-00.txt Thread-Index: AcNLc7kOcSOT7/MAQrSfQowPKQ3g9AAKhi4g From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 16 Jul 2003 13:26:30.0643 (UTC) FILETIME=[DE346430:01C34B9D] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable not to mention the DoD annoucment and moonv6 in U.S. will spawn new ISPs on board too. /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk]=20 > Sent: Wednesday, July 16, 2003 4:24 AM > To: v6ops@ops.ietf.org > Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt >=20 >=20 > On Wed, Jul 16, 2003 at 10:15:52AM +0200, Jasminko Mulahusic wrote: > >=20 > > true. the thing is that we are not sure if there are any isps that=20 > > have deployed fully commercial v6 networks, operated in the=20 > same way=20 > > as their v4 networks. and even if we could find them it is not sure=20 > > they would be able to share the results with us. >=20 > The main production deployments now are in the research=20 > networks, which have to be commercial quality, but may not=20 > offer all the types of services that commercial ISPs do. >=20 > But v6 is running dual stack in Abilene, GEANT, many European=20 > NRENs and the transatlantic link(s) dual-stack without v6 breaking v4. >=20 > But there are many gaps. Projects such as 6NET are trying to=20 > document and where possible work on these (www.6net.org/publications). >=20 > Tim >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:36:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29558 for ; Wed, 16 Jul 2003 09:36:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmRv-000Nmn-Pp for v6ops-data@psg.com; Wed, 16 Jul 2003 13:36:03 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cmRs-000NmX-2Y for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:36:00 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 83AB67AE; Wed, 16 Jul 2003 09:35:59 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:35:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comment on draft-lind-v6ops-isp-scenarios-00.txt Date: Wed, 16 Jul 2003 09:35:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047C9E25@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on draft-lind-v6ops-isp-scenarios-00.txt Thread-Index: AcNLdgMOZx2XLu67RmSst12+m+DTdgAJ/2AQ From: "Bound, Jim" To: "JORDI PALET MARTINEZ" , X-OriginalArrivalTime: 16 Jul 2003 13:35:59.0284 (UTC) FILETIME=[31241F40:01C34B9F] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable also moonv6 will do native ipv6 across the U.S. west to east coasts Oct 2003. http://www.iol.unh.edu/consortiums/ipv6/grouptest/IDCI/ cannot divulge now ISPs on board to early and not fair. Moonv6 slides. http://www.nav6tf.org/summit_slides/Moonv6_final.pdf If you want to know triva of where moonv6 came from send me private mail :--) /jim > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es]=20 > Sent: Wednesday, July 16, 2003 4:40 AM > To: v6ops@ops.ietf.org > Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt >=20 >=20 > And Euro6IX (www.euro6ix.org) is working in the commercial side ;-) >=20 > Also, there is a lot of commercial deployment in Japan. >=20 > Regards, > Jordi >=20 > ----- Original Message -----=20 > From: "Tim Chown" > To: > Sent: Wednesday, July 16, 2003 10:23 AM > Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt >=20 >=20 > > On Wed, Jul 16, 2003 at 10:15:52AM +0200, Jasminko Mulahusic wrote: > > >=20 > > > true. the thing is that we are not sure if there are any=20 > isps that=20 > > > have deployed fully commercial v6 networks, operated in=20 > the same way=20 > > > as their v4 networks. and even if we could find them it=20 > is not sure=20 > > > they would be able to share the results with us. > >=20 > > The main production deployments now are in the research networks,=20 > > which have to be commercial quality, but may not offer all=20 > the types=20 > > of services that commercial ISPs do. > >=20 > > But v6 is running dual stack in Abilene, GEANT, many European NRENs=20 > > and the transatlantic link(s) dual-stack without v6 breaking v4. > >=20 > > But there are many gaps. Projects such as 6NET are trying=20 > to document=20 > > and where possible work on these (www.6net.org/publications). > >=20 > > Tim > >=20 >=20 > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:39: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 JAA29682 for ; Wed, 16 Jul 2003 09:39:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmVE-000NxW-6c for v6ops-data@psg.com; Wed, 16 Jul 2003 13:39:28 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cmVB-000NxD-Cx for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:39:25 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C889FBCF3; Wed, 16 Jul 2003 09:39:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:39:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 6to4 vs forwarding IP proto41 in NAT Date: Wed, 16 Jul 2003 09:39:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04285131@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 vs forwarding IP proto41 in NAT Thread-Index: AcNLj3jKFSJa57BiTlOETHIzye5aSgAD/Mzw From: "Bound, Jim" To: "Rute C. Sofia" , "JORDI PALET MARTINEZ" Cc: X-OriginalArrivalTime: 16 Jul 2003 13:39:24.0654 (UTC) FILETIME=[AB8D18E0:01C34B9F] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I understand the point of your document, but really do not=20 > see a place for it... It's not so much a question of the=20 > "mechanism" (it is here; it is used sometimes), but really, a=20 > question of the purpose of the document. There has to be a=20 > clear purpose (and maybe I'm missing it), otherwise, we just=20 > end up adding more entropy...Can you please answer clearly=20 > the following questions: >=20 > 1) does the document introduce a *significant* contribution=20 > to current deployment status? Yes. We want many options for transition this is investigation and we do investigation. We are not done yet. > 2) if something should be forced to vendors, that should be=20 > either ipv6 or 6to4 ;-). Why impose a third option, given=20 > that only a subset of scenarios will *possibly* gain with it ?? Nothing forces vendors other than the market. And all users I know do not only want the two you list. So we disagree on that base assumption of the market and users. /jim >=20 > And, a bit out of scope in technical terms...out of=20 > curiosity, if you already have an "updated" version of the=20 > draft (updated in which sense??), why didn't you present it yesterday? >=20 > thanks, > rute >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:41: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 JAA29789 for ; Wed, 16 Jul 2003 09:41:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmXD-000O8w-IL for v6ops-data@psg.com; Wed, 16 Jul 2003 13:41:31 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19cmXB-000O8g-23 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 13:41:29 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7E63CB7DE; Wed, 16 Jul 2003 09:41:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 16 Jul 2003 09:41:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 6to4 vs forwarding IP proto41 in NAT Date: Wed, 16 Jul 2003 09:41:27 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04285132@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 vs forwarding IP proto41 in NAT Thread-Index: AcNLmFGCEoRisthwTOuTh8gPxeMLswAB4ceQ From: "Bound, Jim" To: "Rute C. Sofia" , "Tim Chown" Cc: X-OriginalArrivalTime: 16 Jul 2003 13:41:28.0247 (UTC) FILETIME=[F537E470:01C34B9F] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable we either discuss it here or we go make it standard out of the ietf. I think its in the v6ops and ietf interest to keep discussing and see where this goes. do you have any technical comment on the spec? /jim > -----Original Message----- > From: Rute C. Sofia [mailto:rsofia@seas.upenn.edu]=20 > Sent: Wednesday, July 16, 2003 8:45 AM > To: Tim Chown > Cc: v6ops@ops.ietf.org > Subject: Re: 6to4 vs forwarding IP proto41 in NAT >=20 >=20 > Tim, >=20 > > > > 1. To alert people to the (to some obvious) protocol41=20 > "trick" to carry an > > IPv6 tunnel into a NAT network. This is very handy=20 > for early adoptors > > (the IPv6 geeks). It is not a long-term solution. > > > > 2. To alert NAT vendors to the fact that if they make what=20 > should be a > > simple mod to their formware - *if* they are not=20 > already supporting IPv6 > > in some other way e.g. 6to4 or better - they can enable=20 > their geek > > customers to use IPv6 at home. > > > > I think it's a useful informational document, so long as=20 > the "trick"=20 > > is just seen as an early adoptor/last resort mechanism. > > > > It is a mechanism we use a lot btw. >=20 > I completely agree with the sentence above, and that was=20 > stated in my previous mail. >=20 > But, Point 2. above says it all: "*if* they are not already=20 > supporting IPv6 in some other way e.g. 6to4 or better..."... >=20 > Given that the solution that it's trying to be "imposed" is a=20 > temporary solution, not compatible with the other possible=20 > ones, I do not see a point in creating a document about it. I=20 > do understand that it's in use ;-P, but an individual draft=20 > about this does not seem really useful, in my viewpoint. Much=20 > less a WG document on this... Maybe I'm completely wrong=20 > here, but again, what I'm transmitting is that I don't see=20 > the need to document a temporary solution, simply arguing=20 > with the purpose that vendors should give this third=20 > option...which is already in use...there is so much work to=20 > be done regarding v6ops, that my fear is that this document=20 > just ends up in simply adding entropy... >=20 > Rute >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jul 16 09:58: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 JAA00496 for ; Wed, 16 Jul 2003 09:58:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmmI-000PR6-CH for v6ops-data@psg.com; Wed, 16 Jul 2003 13:57:06 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19cmmF-000PQp-Cr; Wed, 16 Jul 2003 13:57:03 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19cmmD-0000NW-MB; Wed, 16 Jul 2003 15:57:01 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Jul 2003 15:57:01 +0200 To: "JORDI PALET MARTINEZ" Cc: Subject: Re: comment on draft-lind-v6ops-isp-scenarios-00.txt References: <20030716100816.X270@vagabond.imslab.net> <20030716082336.GJ26779@login.ecs.soton.ac.uk> <05c901c34b75$ee749360$eb88a051@consulintel.es> <20030716121924.R67740@Space.Net> <085b01c34b85$2536d570$eb88a051@consulintel.es> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > A R&D funded project can never be involved in commercial transit, that's > clear. uh, this is patently not the case in some stateside r&e funded networks randy From owner-v6ops@ops.ietf.org Wed Jul 16 10:06: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 KAA01342 for ; Wed, 16 Jul 2003 10:06:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cmvC-0000A9-As for v6ops-data@psg.com; Wed, 16 Jul 2003 14:06:18 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.14) id 19cmv9-00009h-0f for v6ops@ops.ietf.org; Wed, 16 Jul 2003 14:06:15 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7627613 for ; Wed, 16 Jul 2003 23:06:13 +0900 (JST) To: v6ops@ops.ietf.org 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: "IPv6 on by default" comment From: itojun@iijlab.net Date: Wed, 16 Jul 2003 23:06:13 +0900 Message-Id: <20030716140613.7627613@coconut.itojun.org> X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk due to my (lack of) English speaking skill i may not have delivered my comment to everyone, so i post it here again. with "there's no RA -> consider everything as onlink" portion of ND spec, there's ambiguity. ND spec does not help us decide which interface we should use to send packet out. i agree that ND spec needs clarification on this part (drop "everything as onlink" statement, clarify which outgoing interface should be used, etc). KAME implementation, by default, does not honor "consider everything as onlink" rule because of this ambiguity (therefore we won't experience the delay). if "default outgoing interface" gets configred to KAME kernel with ndp(8) command, the rule will be honored (and will experience the delay) itojun From owner-v6ops@ops.ietf.org Wed Jul 16 10:56: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 KAA04886 for ; Wed, 16 Jul 2003 10:56:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cngR-0003Bv-31 for v6ops-data@psg.com; Wed, 16 Jul 2003 14:55:07 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19cngM-00037h-Qm for v6ops@ops.ietf.org; Wed, 16 Jul 2003 14:55:02 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GEsNpi013390; Wed, 16 Jul 2003 07:54:24 -0700 (PDT) Received: from lillen (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 h6GEsLQ04359; Wed, 16 Jul 2003 16:54:21 +0200 (MEST) Date: Wed, 16 Jul 2003 16:52:43 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Residual threats in draft-savola-v6ops-6to4-security-02.txt? To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Maybe it's just me but I can't clearly find the threats that remain once all the clarified and extended rules in section 5 and 6 have been applied. Is this what the "fix" column in the table in 5.5.1 is trying to tell me? It would be useful to flesh that out a bit. Erik From owner-v6ops@ops.ietf.org Wed Jul 16 11:16: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 LAA05522 for ; Wed, 16 Jul 2003 11:16:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cnzj-0004Wn-4p for v6ops-data@psg.com; Wed, 16 Jul 2003 15:15:03 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.14) id 19cnzd-0004WG-Ci for v6ops@ops.ietf.org; Wed, 16 Jul 2003 15:14:57 +0000 Received: from red.seas.upenn.edu (RED.SEAS.UPENN.EDU [158.130.64.176]) by lion.seas.upenn.edu (8.12.9/8.12.8) with ESMTP id h6GFEqM1029879 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 16 Jul 2003 11:14:53 -0400 Received: from red.seas.upenn.edu (localhost [127.0.0.1]) by red.seas.upenn.edu (8.12.9/8.12.9) with ESMTP id h6GFEpWQ000314; Wed, 16 Jul 2003 11:14:51 -0400 (EDT) Received: from localhost (rsofia@localhost) by red.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h6GFEpZ2000311; Wed, 16 Jul 2003 11:14:51 -0400 (EDT) Date: Wed, 16 Jul 2003 11:14:51 -0400 (EDT) From: "Rute C. Sofia" To: "Bound, Jim" cc: Tim Chown , Subject: RE: 6to4 vs forwarding IP proto41 in NAT In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B04285132@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jim, On Wed, 16 Jul 2003, Bound, Jim wrote: > we either discuss it here or we go make it standard out of the ietf. I > think its in the v6ops and ietf interest to keep discussing and see > where this goes. > > do you have any technical comment on the spec? > as the spec stands, I cannot comment, simply because for me it does not make sense... I am waiting for the version that Jordi says is almost ready and yes, I will comment that one. Rute > /jim > > > -----Original Message----- > > From: Rute C. Sofia [mailto:rsofia@seas.upenn.edu] > > Sent: Wednesday, July 16, 2003 8:45 AM > > To: Tim Chown > > Cc: v6ops@ops.ietf.org > > Subject: Re: 6to4 vs forwarding IP proto41 in NAT > > > > > > Tim, > > > > > > > > 1. To alert people to the (to some obvious) protocol41 > > "trick" to carry an > > > IPv6 tunnel into a NAT network. This is very handy > > for early adoptors > > > (the IPv6 geeks). It is not a long-term solution. > > > > > > 2. To alert NAT vendors to the fact that if they make what > > should be a > > > simple mod to their formware - *if* they are not > > already supporting IPv6 > > > in some other way e.g. 6to4 or better - they can enable > > their geek > > > customers to use IPv6 at home. > > > > > > I think it's a useful informational document, so long as > > the "trick" > > > is just seen as an early adoptor/last resort mechanism. > > > > > > It is a mechanism we use a lot btw. > > > > I completely agree with the sentence above, and that was > > stated in my previous mail. > > > > But, Point 2. above says it all: "*if* they are not already > > supporting IPv6 in some other way e.g. 6to4 or better..."... > > > > Given that the solution that it's trying to be "imposed" is a > > temporary solution, not compatible with the other possible > > ones, I do not see a point in creating a document about it. I > > do understand that it's in use ;-P, but an individual draft > > about this does not seem really useful, in my viewpoint. Much > > less a WG document on this... Maybe I'm completely wrong > > here, but again, what I'm transmitting is that I don't see > > the need to document a temporary solution, simply arguing > > with the purpose that vendors should give this third > > option...which is already in use...there is so much work to > > be done regarding v6ops, that my fear is that this document > > just ends up in simply adding entropy... > > > > Rute > > > > > > > From owner-v6ops@ops.ietf.org Wed Jul 16 11:23: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 LAA05892 for ; Wed, 16 Jul 2003 11:23:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19co7P-00057r-1I for v6ops-data@psg.com; Wed, 16 Jul 2003 15:22:59 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19co7L-00055e-Su for v6ops@ops.ietf.org; Wed, 16 Jul 2003 15:22:55 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jul 2003 08:22:24 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jul 2003 08:22:24 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Jul 2003 08:22:24 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Jul 2003 08:22:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jul 2003 08:22:23 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 16 Jul 2003 08:23:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Residual threats in draft-savola-v6ops-6to4-security-02.txt? Date: Wed, 16 Jul 2003 08:22:20 -0700 Message-ID: Thread-Topic: Residual threats in draft-savola-v6ops-6to4-security-02.txt? Thread-Index: AcNLq0aNRxmbpBGETTSw4k6MbmJhlwAAWfon From: "Christian Huitema" To: "Erik Nordmark" , Cc: X-OriginalArrivalTime: 16 Jul 2003 15:23:39.0895 (UTC) FILETIME=[3BF72070:01C34BAE] X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In fact, the document could get some editing. We should adopt a = structure "by threat", in which for each thread we describe the attack, = note the existing mitigation, discuss whether other additional = mitigations should be implemented, and conclude by the qualification of = the residual threat. =20 We also need to agree on some qualification level. We discussed that on = the list, but basically it is a matter of comparing the situation with = 6to4 to the situation without. If the mitigations are sufficient to make = the situation no worse with 6to4 than with the existing IPv4 Internet, = then the threat should not considered critical. This forces us to decide = a question, what is the level we compare to. For example, a lot is said = about address spoofing, but addresses can in practice be spoofed = today... =20 ________________________________ From: owner-v6ops@ops.ietf.org on behalf of Erik Nordmark Sent: Wed 7/16/2003 7:52 AM To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: Residual threats in draft-savola-v6ops-6to4-security-02.txt? Maybe it's just me but I can't clearly find the threats that remain once all the clarified and extended rules in section 5 and 6 have been applied. Is this what the "fix" column in the table in 5.5.1 is trying to tell = me? It would be useful to flesh that out a bit. Erik From owner-v6ops@ops.ietf.org Wed Jul 16 12:53: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 MAA08387 for ; Wed, 16 Jul 2003 12:53:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cpVy-000AxQ-9E for v6ops-data@psg.com; Wed, 16 Jul 2003 16:52:26 +0000 Received: from [3ffe:501:100f::35] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.14) id 19cpVv-000AxE-8W for v6ops@ops.ietf.org; Wed, 16 Jul 2003 16:52:23 +0000 Received: from ocean.jinmei.org (unknown [2001:7f9:8400:1:fd04:8708:ebdc:eaf6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A1D1515248 for ; Thu, 17 Jul 2003 01:52:20 +0900 (JST) Date: Thu, 17 Jul 2003 01:52:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: v6ops@ops.ietf.org Subject: Re: "IPv6 on by default" comment In-Reply-To: <20030716140613.7627613@coconut.itojun.org> References: <20030716140613.7627613@coconut.itojun.org> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-22.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >>>>> On Wed, 16 Jul 2003 23:06:13 +0900,=20 >>>>> itojun@iijlab.net said: > KAME implementation, by default, does not honor "consider everything as > onlink" rule because of this ambiguity (therefore we won't experience > the delay). > if "default outgoing interface" gets configred to KAME kernel with > ndp(8) command, the rule will be honored (and will experience the delay) Actually, the reason why we (KAME) disabled the "everything as onlink" rule by default is the exact concern that the v6-on-by-default draft points out; delay to fallback to IPv4. (I'm not saying the ambiguity on the interface is not an issue, but this is not the reason why we do not honor the rule.) In any event, I agree that the rule in RFC2461 should be more clarified or even revised. =46rom KAME implementation note: IPv6 on-link determination rule (RFC2461) is quite different from assumptions in BSD IPv4 network code. To implement the behavior in RFC2461 section 6.3.6 (3), the kernel needs to know the default outgoing interface. To configure the default outgoing interface, use commands like "ndp -I de0" as root. Then the kernel will have a "default" route to the interface with the cloning "C" bit being on. This default route will cause to make a neighbor cache entry for every destination that does not match an explicit route entry. Note that we intentionally disable configuring the default interface by default. This is because we found it sometimes caused inconvenient situation while it was rarely useful in practical usage. For example, consider a destination that has both IPv4 and IPv6 addresses but is only reachable via IPv4. Since our getaddrinfo(3) prefers IPv6 by default, an (TCP) application using the library with PF_UNSPEC first tries to connect to the IPv6 address. If we turn on RFC 2461 6.3.6 (3), we have to wait for quite a long period before the first attempt to make a connection fails. If we turn it off, the first attempt will immediately fail with EHOSTUNREACH, and then the application can try the next, reachable address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Wed Jul 16 13:17:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09016 for ; Wed, 16 Jul 2003 13:17:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cptV-000CXi-FS for v6ops-data@psg.com; Wed, 16 Jul 2003 17:16:45 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19cptS-000CXV-7J for v6ops@ops.ietf.org; Wed, 16 Jul 2003 17:16:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6GHGbU26791; Wed, 16 Jul 2003 20:16:38 +0300 Date: Wed, 16 Jul 2003 20:16:37 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: Residual threats in draft-savola-v6ops-6to4-security-02.txt? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 16 Jul 2003, Erik Nordmark wrote: > Maybe it's just me but I can't clearly find the threats that remain > once all the clarified and extended rules in section 5 and 6 have > been applied. > > Is this what the "fix" column in the table in 5.5.1 is trying to tell me? > It would be useful to flesh that out a bit. Thanks for the comment. Fix refers only to the workarounds presented in section 5. It is assumed that all the implementations already do about all the suggested checks described in section 6 (in sect 5 there are basically only more generic suggestions like applyting iTrace), which is a bit of a stretch. This should be stated somewhere, but I'll re-organize the document slightly to make it easier to understand. -- 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 Jul 16 13:42: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 NAA09874 for ; Wed, 16 Jul 2003 13:42:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cqHS-000E0X-Rc for v6ops-data@psg.com; Wed, 16 Jul 2003 17:41:30 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19cqHO-000Dzv-Ps for v6ops@ops.ietf.org; Wed, 16 Jul 2003 17:41:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6GHfOo26999 for ; Wed, 16 Jul 2003 20:41:24 +0300 Date: Wed, 16 Jul 2003 20:41:24 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Accept IPv6-on-by-Default Document as WG Draft? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, In the second session in Vienna, we had unanimous consensus that an operational document describing IPv6-on-by-Default scenarios would serve as a good starting place for our work, and that we should accept it as a WG draft. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-01.txt Unless there are any objections from the mailing list, We'll ask the authors to publish the next version as a WG I-D. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Wed Jul 16 13:43: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 NAA09919 for ; Wed, 16 Jul 2003 13:43:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cqJW-000E9P-0H for v6ops-data@psg.com; Wed, 16 Jul 2003 17:43:38 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19cqJT-000E8z-Rd for v6ops@ops.ietf.org; Wed, 16 Jul 2003 17:43:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6GHhXl27031 for ; Wed, 16 Jul 2003 20:43:33 +0300 Date: Wed, 16 Jul 2003 20:43:33 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Accept 6to4 Security Analysis document as WG Draft? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, In the second session in Vienna, we had unanimous consensus that a document analyzing 6to4 security issues would serve as a good starting place for our work, and that we should accept it as a WG draft. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-02.txt Unless there are any objections from the mailing list, We'll ask the author to publish the next version as a WG I-D. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Wed Jul 16 13:54: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 NAA10400 for ; Wed, 16 Jul 2003 13:54:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19cqSq-000F1E-BU for v6ops-data@psg.com; Wed, 16 Jul 2003 17:53:16 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19cqSm-000F0l-R8 for v6ops@ops.ietf.org; Wed, 16 Jul 2003 17:53:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6GHrAb27149; Wed, 16 Jul 2003 20:53:10 +0300 Date: Wed, 16 Jul 2003 20:53:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com Subject: v6ops Vienna presentations -> Bob Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, All of those who made presentations at v6ops sessions, please send (at least) the PDF versions to Bob, so they can be put on the web page. Thanks. -- 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 Jul 17 02:41: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 CAA18051 for ; Thu, 17 Jul 2003 02:41:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d2Pa-00086k-GZ for v6ops-data@psg.com; Thu, 17 Jul 2003 06:38:42 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.14) id 19d2PV-000866-TC for v6ops@ops.ietf.org; Thu, 17 Jul 2003 06:38:38 +0000 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 08:38:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34C2D.FA1B74CA" Subject: comment on enterprise draft-pouffary-v6ops-ent-v6net-03.txt Date: Thu, 17 Jul 2003 08:38:04 +0200 Message-ID: Thread-Topic: comment on enterprise draft-pouffary-v6ops-ent-v6net-03.txt Thread-Index: AcNMLe5Bzwx1avGXSEW0UotLT8BpfQ== From: "BAUDOT Alain FTRD/DMI/CAE" To: X-OriginalArrivalTime: 17 Jul 2003 06:38:05.0868 (UTC) FILETIME=[FAA236C0:01C34C2D] X-Spam-Status: No, hits=-1.7 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_20,HTML_40_50,HTML_FONT_COLOR_BLUE, HTML_FONT_COLOR_RED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C34C2D.FA1B74CA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have one more comment on the enterprise draft, related to the base = scenario section: I have in mind the concrete case where IPv6 is a solution to reduce the = complexity one may face when merging a number a network based on the use = of the same range of private addresses. This correspond to the case of = large enterprise, for example an insurance company, incorporating number = of small agencies. I just wonder if this case, network complexity fix, should be explicitly = identify as part as a base scenario (typically scenario 2 or even 3). Alain. ______________________________________________ Alain BAUDOT=20 France Telecom R&D DMI/SIR e-mail : alain.baudot@rd.francetelecom.com=20 42 rue des coutures=20 BP 6243 Phone : +33 2 31 75 94 27=20 14066 CAEN CEDEX Fax : +33 2 31 73 56 26 FRANCE ------_=_NextPart_001_01C34C2D.FA1B74CA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable comment on enterprise = draft-pouffary-v6ops-ent-v6net-03.txt

I have one more comment on the = enterprise draft, related to the base scenario section:
I have in mind the concrete case = where IPv6 is a solution to reduce the complexity one may face when = merging a number a network based on the use of the same range of private = addresses. This correspond to the case of large enterprise, for example = an insurance company, incorporating number of small agencies.

I just wonder if this case, = network complexity fix, should be explicitly identify as part as a base = scenario (typically scenario 2 or even 3).

Alain.
______________________________________________
Alain BAUDOT
France = Telecom R&D DMI/SIR
e-mail = :        alain.baudot@rd.francetelecom.com
42 rue des = coutures
BP 6243 =         =         Phone : +33 2 31 75 94 = 27
14066 CAEN CEDEX =        Fax : +33 2 31 73 56 26
FRANCE

------_=_NextPart_001_01C34C2D.FA1B74CA-- From owner-v6ops@ops.ietf.org Thu Jul 17 08:11: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 IAA02568 for ; Thu, 17 Jul 2003 08:11:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19d7Wp-0000Uv-Ug for v6ops-data@psg.com; Thu, 17 Jul 2003 12:06:31 +0000 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19d7Wm-0000UW-BR for v6ops@ops.ietf.org; Thu, 17 Jul 2003 12:06:29 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19d7Wl-000H4F-Er for v6ops@ops.ietf.org; Thu, 17 Jul 2003 14:06:27 +0200 Message-ID: <20030717074310.T29649-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Thu, 17 Jul 2003 08:03:41 -0400 (EDT) From: "Alan E. Beard" To: v6ops@ops.ietf.org Subject: Concerning draft-pouffary-v6ops-ent-v6net-04 X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ 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. ] Folks: Concerning draft-pouffary-v6ops-ent-v6net-04.txt: First, some general comments: The draft in its present form is characterized by a strong, if somewhat skeletal, basic structure, and there exists the bare minimum of connective tissue required to hold the structure together. However, there is precious little muscle on the structure, a complete absence of fat, and not even a hint of skin, much less proper clothing for a public presentation. This draft in its present form does not march, and any attempt to force movement is likely to give rise to a prodigious clattering of bones and scraping of joints. The above, and much of what follows herein, proceeds from a presumption that the IPv6 Enterprise Network Scenarios document, upon completion, will bet intended to provide guidance to enterprise network teams (as stated in paragraph 2 of section 1), and to serve as a basis for the companion analysis and solutions document. If the above presumption is even remotely accurate, we will need to provide information beyond the existing text for the use of the enterprise network team, which team is likely to be comprised of administrative managers and, in the case of financial services organizations, auditors in addition to network engineers. To be a bit less imprecise, it would be useful to provide text which might indicate to a reasonable administrative manager (assuming that at least one instance of this mythical beast actually exists): what we are talking about (couched in a minimum of jargon); why the manager should care; and why the IETF is presuming to give an enterprise advice which may very well be perceived as gratuitous. Notwithstanding the above, much, in fact almost all, of the existing text is very good indeed. In particular, the Base Network Scenarios definitions are complete and sound, as are the example network descriptions. In general, section 3.2, Network Scenarios Characteristics, is well crafted, although there are few nits involving questions framed "A or B" which can legitimately be answered "Yes" or "Both". Now, on to specifics. Concerning base scenarios: I can foresee a sequence of events wherein a single hetwork traverses all three scenarios enumerated in the draft, with the final state being that represented by scenario 3. The most probable sequence would be 2;1;3. In fact, one of my clients discussed (and subsequently abandoned) just this sequence, and several others have muttered darkly about similar sequences. Concerning example networks: most of my clients operate networks which exhibit many of the characteristics of all three enumerated examples. We should perhaps not assume that most enterprise networks can be neatly categorized - the range of services supported in commercial enterprise networks (particularly in financial services networks, where lies most of my client base) is more extensive than any one of the enumerated example networks subsumes. For financial services networks, only single-offering service providers (for example, ATM operations providers) have the luxury of a single-application network. That notwithstanding, the three example networks, if considered in toto, do cover most of the requirements seen in networks operated by many of my clients. Perhaps we should add some sort of statement indicating that real-world networks are likely to exhibit characteristics which overlap more than one of the enumerated examples. Concerning network infrastructure requirements, the audience may find it useful to have additional information concerning which subsets of the enterprise network team may find specific sections of especial interest, to wit: For most of my clients, DNS, routing and autoconfiguration issues are left to the engineering wallahs: there is a default assumption that these matters will be resolved by the techies well before any transition is attempted. Security considerations are likewise left to the techies, subject to approval of the auditors; in practice, this leaves to the network engineering team the task of educating the auditors concerning what security mechanisms carry forward from the IPv4 implementation - a non-trivial task, as the auditors are by nature and by instruction paranoid. Considerable guidance (preferably from an authoritative source) will be required before the auditors will be pacified. Applications issues, for the most part, fall to network engineering; applications developers don't know, and emphatically don't care, about v6 support. In practice, applications which support only v4 will force dual-stack support until all such applications reach the end of their service life and are retired or replaced with entirely new code. Recommendations concering applications will be most useful if made specific to new application development; in almost all cases, existing applications in commercial environments are unlikely to see re-coding for support of IPv6. Even new applications are unlikely to support v6 absent an administrative (as distinguished from engineering) requirement for such support. Guidance in this area will be most effective if directed to administrative managment, rather than engineering, staff. For most networks I see on a regular basis, network management issues are left for resolution by vendors or by the network operations coding team. In most cases, dual-stack implementations of NM applications will be required, but a set of solutions which provides for direct management (preferably on the native transport protocol) of both v4 and v6 nodes will be required until all nodes in the network become v6 only. Guidance from a source authoritative on these matters will be useful to engineering and administrative managers of the end-user networks. Address planning is probably the task which affects vital interests of every subset of the network team, particularly in view of the current scheme for allocation of IPv6 address space. Administrative management will be involved in an attempt to ensure continuous (non-interruptible) network operations; auditors will be involved in an attempt to ensure utter and complete independence from any external entity (including, but not limited to, any one ISP); and network engineering will be involved because they have to actually make the bloody thing _work_! I'm not entirely sure how we draw the distinctions between the several subsets of the enterprise network team, but I think we need to do at least some explicit targeting of the text (and tell the audience just _who_ are the targets) for each section, lest the engineering wallahs be faced with something like this: admin: "An RFC? That's engineering stuff - you handle it." engr: "yes, but there is information in here you need..." admin: "Where does it say THAT?" engr: "Um, well, there's no explicit specfication beyond 'enterprise network team'..." admin: "Well, you read it, and give us a summary." [engineer slouches away, muttering darkly.] Now, the comments herein are admittedly very far from comprehensive or complete. However, even this rather sketchy set of notes might stimulate some discussion. I'll be traveling for the next three weeks or so, including 12 days incommunicado in the North Atlantic, but I'll try to follow this note with some additional mutterings when I get back to the office about mid-August. That's my $.02 worth ;-) Regards, Alan E. Beard -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 From owner-v6ops@ops.ietf.org Fri Jul 18 12:54: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 MAA05446 for ; Fri, 18 Jul 2003 12:54:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dYT7-0001mx-5I for v6ops-data@psg.com; Fri, 18 Jul 2003 16:52:29 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19dYT4-0001mj-VZ for v6ops@ops.ietf.org; Fri, 18 Jul 2003 16:52:27 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 266DBB4B1 for ; Fri, 18 Jul 2003 12:52:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 18 Jul 2003 12:52:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: proto41 clarification on my comments to wg Date: Fri, 18 Jul 2003 12:52:25 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04285215@tayexc13.americas.cpqcorp.net> Thread-Topic: proto41 clarification on my comments to wg Thread-Index: AcNNTPcRMkNoJQQST9G14SSP/f4stQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 18 Jul 2003 16:52:25.0661 (UTC) FILETIME=[F73206D0:01C34D4C] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Please do not respond to this mail. Offline I was asked to make this clarification. In my mail on proto41 I was speaking of nat boxes. I should have said I was specifically speaking of home use cable and adsl routers that do nat not any other user type or operations. thanks /jim From owner-v6ops@ops.ietf.org Fri Jul 18 12:54:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05462 for ; Fri, 18 Jul 2003 12:54:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19dYQu-0001dA-Pq for v6ops-data@psg.com; Fri, 18 Jul 2003 16:50:12 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19dYQp-0001ci-4F for v6ops@ops.ietf.org; Fri, 18 Jul 2003 16:50:07 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 89BEC4BB; Fri, 18 Jul 2003 12:50:06 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 18 Jul 2003 12:50:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Concerning draft-pouffary-v6ops-ent-v6net-04 Date: Fri, 18 Jul 2003 12:50:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04285214@tayexc13.americas.cpqcorp.net> Thread-Topic: Concerning draft-pouffary-v6ops-ent-v6net-04 Thread-Index: AcNMXKNxD/YAnoCCQLm/OuN5Cks2FAA71e4A From: "Bound, Jim" To: "Alan E. Beard" , X-OriginalArrivalTime: 18 Jul 2003 16:50:06.0287 (UTC) FILETIME=[A41F3DF0:01C34D4C] X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Alan, Thanks for this input. We will take it to heart for next release. Thanks so much. The team will now add meat to the bones that our colleagues in this WG made it WG item.=20 Two quesitons to you and the working group.=20 First one. We have gone back and forth on this work and other scenario works if we should put in an IETF doc why a user of this should care. I am amoral on this and will go either way. So I ask should we explain why this is important to users in this spec and other specs? Second question is should we target the audience to be the manager, admin, and engineer or just one of them. My view is mostly the admin but enough that the engineer knows to go look at the solutions/analysis follow on document to the Enterprise scenarios. =20 thanks /jim > -----Original Message----- > From: Alan E. Beard [mailto:aeb1@aebeard.com]=20 > Sent: Thursday, July 17, 2003 8:04 AM > To: v6ops@ops.ietf.org > Subject: Concerning draft-pouffary-v6ops-ent-v6net-04 >=20 >=20 > [ post by non-subscriber. with the massive amount of spam,=20 > it is easy to miss > and therefore delete posts by non-subscribers. if you wish=20 > to regularly > post from an address that is not subscribed to this mailing=20 > list, send a > message to -owner@ops.ietf.org and ask to have=20 > the alternate > address added to the list of addresses from which submissions are > automatically accepted. ] >=20 > Folks: >=20 > Concerning draft-pouffary-v6ops-ent-v6net-04.txt: >=20 > First, some general comments: >=20 > The draft in its present form is characterized by a strong,=20 > if somewhat skeletal, basic structure, and there exists the=20 > bare minimum of connective tissue required to hold the=20 > structure together. However, there is precious little muscle=20 > on the structure, a complete absence of fat, and not even a=20 > hint of skin, much less proper clothing for a public=20 > presentation. This draft in its present form does not march,=20 > and any attempt to force movement is likely to give rise to a=20 > prodigious clattering of bones and scraping of joints. >=20 > The above, and much of what follows herein, proceeds from a=20 > presumption that the IPv6 Enterprise Network Scenarios=20 > document, upon completion, will bet intended to provide=20 > guidance to enterprise network teams (as stated in paragraph=20 > 2 of section 1), and to serve as a basis for the companion=20 > analysis and solutions document. >=20 > If the above presumption is even remotely accurate, we will=20 > need to provide information beyond the existing text for the=20 > use of the enterprise network team, which team is likely to=20 > be comprised of administrative managers and, in the case of=20 > financial services organizations, auditors in addition to=20 > network engineers. To be a bit less imprecise, it would be=20 > useful to provide text which might indicate to a reasonable=20 > administrative manager (assuming that at least one instance=20 > of this mythical beast actually exists): what we are talking=20 > about (couched in a minimum of jargon); why the manager=20 > should care; and why the IETF is presuming to give an=20 > enterprise advice which may very well be perceived as gratuitous. >=20 > Notwithstanding the above, much, in fact almost all, of the=20 > existing text is very good indeed. In particular, the Base=20 > Network Scenarios definitions are complete and sound, as are=20 > the example network descriptions. In general, section 3.2,=20 > Network Scenarios Characteristics, is well crafted, although=20 > there are few nits involving questions framed "A or B" which=20 > can legitimately be answered "Yes" or "Both". >=20 >=20 > Now, on to specifics. >=20 > Concerning base scenarios: I can foresee a sequence of=20 > events wherein a > single hetwork traverses all three scenarios enumerated in=20 > the draft, with the final state being that represented by=20 > scenario 3. The most probable sequence would be 2;1;3. In=20 > fact, one of my clients discussed (and subsequently=20 > abandoned) just this sequence, and several others have=20 > muttered darkly about similar sequences. >=20 > Concerning example networks: most of my clients operate=20 > networks which exhibit many of the characteristics of all=20 > three enumerated examples. We should perhaps not assume that=20 > most enterprise networks can be neatly categorized - the=20 > range of services supported in commercial enterprise networks=20 > (particularly in financial services networks, where lies most=20 > of my client base) is more extensive than any one of the=20 > enumerated example networks subsumes. For financial services=20 > networks, only single-offering service providers (for=20 > example, ATM operations providers) have the luxury of a=20 > single-application network. That notwithstanding, the three=20 > example networks, if considered in toto, do cover most of the=20 > requirements seen in networks operated by many of my clients.=20 > Perhaps we should add some sort of statement indicating that=20 > real-world networks are likely to exhibit characteristics=20 > which overlap more than one of the enumerated examples. >=20 > Concerning network infrastructure requirements, the audience=20 > may find it useful to have additional information concerning=20 > which subsets of the enterprise network team may find=20 > specific sections of especial interest, to wit: >=20 > For most of my clients, DNS, routing and autoconfiguration=20 > issues are left to the engineering wallahs: there is a=20 > default assumption that these matters will be resolved by the=20 > techies well before any transition is attempted. Security=20 > considerations are likewise left to the techies, subject to=20 > approval of the auditors; in practice, this leaves to the=20 > network engineering team the task of educating the auditors=20 > concerning what security mechanisms carry forward from the=20 > IPv4 implementation - a non-trivial task, as the auditors are=20 > by nature and by instruction paranoid. Considerable guidance=20 > (preferably from an authoritative source) will be required=20 > before the auditors will be pacified. >=20 > Applications issues, for the most part, fall to network=20 > engineering; applications developers don't know, and=20 > emphatically don't care, about v6 support. In practice,=20 > applications which support only v4 will force dual-stack=20 > support until all such applications reach the end of their=20 > service life and are retired or replaced with entirely new=20 > code. Recommendations concering applications will be most=20 > useful if made specific to new application development; in=20 > almost all cases, existing applications in commercial=20 > environments are unlikely to see re-coding for support of=20 > IPv6. Even new applications are unlikely to support v6 absent=20 > an administrative (as distinguished from engineering)=20 > requirement for such support. Guidance in this area will be=20 > most effective if directed to administrative managment,=20 > rather than engineering, staff. >=20 > For most networks I see on a regular basis, network=20 > management issues are left for resolution by vendors or by=20 > the network operations coding team. In most cases, dual-stack=20 > implementations of NM applications will be required, but a=20 > set of solutions which provides for direct management=20 > (preferably on the native transport protocol) of both v4 and=20 > v6 nodes will be required until all nodes in the network=20 > become v6 only. Guidance from a source authoritative on=20 > these matters will be useful to engineering and=20 > administrative managers of the end-user networks. >=20 > Address planning is probably the task which affects vital=20 > interests of every subset of the network team, particularly=20 > in view of the current scheme for allocation of IPv6 address=20 > space. Administrative management will be involved in an=20 > attempt to ensure continuous (non-interruptible) network=20 > operations; auditors will be involved in an attempt to ensure=20 > utter and complete independence from any external entity=20 > (including, but not limited to, any one ISP); and network=20 > engineering will be involved because they have to actually=20 > make the bloody thing _work_! >=20 > I'm not entirely sure how we draw the distinctions between=20 > the several subsets of the enterprise network team, but I=20 > think we need to do at least some explicit targeting of the=20 > text (and tell the audience just _who_ are the targets) for=20 > each section, lest the engineering wallahs be faced with=20 > something like this: >=20 > admin: "An RFC? That's engineering stuff - you handle it." >=20 > engr: "yes, but there is information in here you need..." >=20 > admin: "Where does it say THAT?" >=20 > engr: "Um, well, there's no explicit specfication beyond=20 > 'enterprise network team'..." >=20 > admin: "Well, you read it, and give us a summary." >=20 > [engineer slouches away, muttering darkly.] >=20 > Now, the comments herein are admittedly very far from=20 > comprehensive or complete. However, even this rather sketchy=20 > set of notes might stimulate some discussion. I'll be=20 > traveling for the next three weeks or so, including 12 days=20 > incommunicado in the North Atlantic, but I'll try to follow=20 > this note with some additional mutterings when I get back to=20 > the office about mid-August. >=20 > That's my $.02 worth ;-) >=20 > Regards, >=20 > Alan E. Beard >=20 > --=20 > Alan E. Beard > AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 >=20 >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Jul 21 05:48: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 FAA22251 for ; Mon, 21 Jul 2003 05:48:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eXE1-0001Uy-8h for v6ops-data@psg.com; Mon, 21 Jul 2003 09:44:57 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.14) id 19eXDx-0001UO-Bn for v6ops@ops.ietf.org; Mon, 21 Jul 2003 09:44:53 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6L9iDOu015992; Mon, 21 Jul 2003 02:44:14 -0700 (PDT) Received: from lillen (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 h6L9i9Q19859; Mon, 21 Jul 2003 11:44:10 +0200 (MEST) Date: Mon, 21 Jul 2003 10:52:58 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: food for thought on NAT traversal techniques 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=-8.0 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Hi, > > Find below a bit food for thought on designing NAT traversal mechanisms. > I think it would be useful to consider a bit more on what we NEED. > > - Should we send a clear signal to NAT vendors what kind of deployment > model we think is best, and what are the goals they should try to work > towards? I think it would be useful for the IETF to try write up something which shows the path to IPv6 for small and home networks. Without this we have this collection of mechanisms and the danger that some are told "implement 6to4" and others are told "implement proto 41" when in fact what we really want is native IPv6 where the NAT becomes a leaf IPv6 router with prefix delegation etc. Currently there is a danger that the various short term approxes overshadow the final goal which would be bad. > - Should we try to leverage existing IPv4 NAT traversal mechanisms if > possible (there seem to be a plenty of them, like STUN, TURN, etc.), and > even avoid all IPv6 work we can? Would that be of value in itself ("A > particular kind of NAT breaks this IPv_4_ solution we'd like to use to > traverse NATs")? My opinion is that when the endpoint is IPv4 the best general approach is to use the IPv4 NAT (by having the IPv6 nodes really being dual-stacked with a private IPv4 address). That way the above techniques can be used, with all their benefits and downsides, without writing one extra line of code. Thus the key thing v6ops needs to worry about in this space is the case when the endpoint is IPv6 but there exists some IPv6-unaware IPv4 NAT box in the path. Being able to construct some form of IPv6 tunnel over that NAT box would allow e2e IPv6 communication. > - What is the expected lifetime of our NAT traversal mechanism > (e.g. a few years, until most NAT vendors have started deploying 6to4 or > native) ? The v6overNAT would naturally go away once the NAT box is v6 aware, whether using native or 6to4. > - What features are critical for the NAT traversal mechanism? > For example: > * simplicity (spec and the protocol) > * ease of use (easy to turn on/configure) > * interop with NATs (works with all NAT boxes or close enough) > * robustness (is otherwise failure-proof with few things that could go > wrong) > * route optimization (traffic between different IPv6 nodes behind > NAT's as direct as possible) > * security (doesn't make unexpected holes, minimizes DoS attacks etc.) My list includes simplicity, robustness and security. I understand the desire to optimize things, but I'm concerned about sending the signal that v6overNAT is the new Internet when in fact we want the new Internet to be IPv6. Thus wanting the v6overNAT solution to be good enough to be confused with native IPv6 would make sense if we don't want the users to know the difference but this implies that the users will never know to ask for native IPv6 from the ISP. The alterantive would be to send the message that v6overNAT is a temporary measure to provide global addressability, but that ISP support of native IPv6 is needed to get better performance. I'm not surprised that different participants make different tradeoffs on this point. Perhaps we should try to discuss this tradeoff explicitly instead of discussing it implicitly when talking about some proposed mechanism. Erik > - What are the properties of the solution(s) we would like to use/develop > considering these issues? How much work we should we should use on > mechanisms which are likely to: > * be quite low in our "preferred solutions list", > * have a limited lifetime, and hopefully soon replaced by a > better-working mechanism, > * are something other WG's have had to specify as well, and > * be something we may not even be able to specify implement correctly, > simply and reliably? > > -- > 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 Jul 21 08:57: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 IAA26187 for ; Mon, 21 Jul 2003 08:57:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eaBq-000EHJ-La for v6ops-data@psg.com; Mon, 21 Jul 2003 12:54:54 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19eaBl-000EH1-Ng for v6ops@ops.ietf.org; Mon, 21 Jul 2003 12:54:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6LCslq22342 for ; Mon, 21 Jul 2003 15:54:47 +0300 Date: Mon, 21 Jul 2003 15:54:46 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: Editorial issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.7 required=5.0 tests=USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I've looked a bit into 3GPP Analysis document, and I'll be sending out issues I found out separated in different messages, a day or so apart. Whether they should be filed in an issue tracker (like Roundup), a web page, etc. is up to the 3GPP design team, and especially the editor. editorial --------- This document analyzes the transition scenarios in 3GPP packet data networks that might come up in the deployment phase of IPv6. The transition scenarios are documented in [3GPP-SCEN] and this document will further analyze them. The scenarios are divided into two categories: GPRS scenarios and IMS scenarios. ==> first use of "IMS", so spell it out. 1.1 Scope of this Document The scope of this informational document is to analyze and solve the possible transition scenarios in the 3GPP defined GPRS network ==> note that the category will be BCP, so perhaps it's better to substitute s/informational/Best Current Practices/, or even "informational Best Current Practices/, as you prefer considering the audience (i.e. whether they're aware of what BCP really means) where a UE connects to, or is contacted from the Internet, or ==> s/from/from,/, s/Internet,/Internet/ ? of the SIP based IP Multimedia Core Network Subsystem (IMS). This document is not focused on radio interface issues; both 3GPP Second ==> s/is not focused/does not focus/ ? 1.2 Abbreviations ==> I note that SGSN, HLR and DNS (at least) are not listed. At least the first two should be added. 1.3 Terminology Dual Stack UE Dual Stack UE is a 3GPP mobile handset having dual stack implemented. It is capable of activating both IPv4 and IPv6 PDP contexts. Dual stack UE may be capable of tunneling. ==> there is a slight circular definition here, "DS UE is something with dual stack". Maybe some rewording would be needed? Not a major issue. This chapter briefly introduces some transition mechanisms specified by the IETF. Applicability of different transition mechanisms to 3GPP networks is discussed in chapters 3 and 4. ==> s/Applicability/The applicability/ ? The following scenarios described by [3GPP-SCEN] are analyzed here. In all of the scenarios, the UE is part of a network where there is at least one router of the same IP version, i.e. GGSN, and it is connecting to a node in a different network. ==> s/it is/the UE is/ In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes. It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an ==> spell out PDP. However, the UE may attach to a 3GPP network, in which the SGSN (Serving GPRS Support Node), the GGSN and the HLR (Home Location Register) support IPv4 PDP contexts by default, ==> change the order of term and abbreviation: Serving GPRPS Support Node (SGSN), Home Location Register (HLR) One deployment scenario example is using laptop computer and a UMTS UE as a modem. ==> s/laptop/a laptop/ ==> I don't think UE is a modulator/demodulator and calling it a modem may be a bit confusing ? When analyzing a dual stack UE behavior, an application running on a UE can identify whether the endpoint required is an IPv4 or IPv6 capable node by examining the address to discover what address family category it falls into. ==> reword "application": typically, this function is performed at a lower layer (operating system, IP stack), and the use of applciation gives IMHO the wrong picture that the applications themselves would have to somehow distinguish the end-point address family. ==> s/category// Since the UE is capable of native communication with both protocols, one of the main concerns of an operator is correct address space and routing management. ==> s/correct/the correct/ ? Keeping the Internet name space unfragmented is another important issue for both IPv4 and IPv6. It means that any record in the public Internet should be available unmodified to any nodes, IPv4 or IPv6, regardless of the transport being used. ==> s/any record/any DNS record/ (maybe even spell out DNS) served by at least an IPv4 reachable DNS server. This ==> s/an/one/ be used. In a 3GPP network, one IPv6 island could contain the GGSN while another island contains the operator's IPv6 application servers. However, manually configured tunnels can be an ==> s/contains/could contain/ "6to4" nodes use special IPv6 addresses with a "6to4" prefix containing the IPv4 address of the corresponding "IPv6 in IPv4" tunnel endpoint ("6to4" router) which performs encapsulation / decapsulation. When connecting two nodes with "6to4" addresses, the ==> s/"6to4"/6to4/ (could explain it the first time 6to4 is stated if necessary) 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network 3GPP networks are expected to support both IPv4 and IPv6 for a long time, on the UE-GGSN link and between the GGSN and external networks. For this scenario it is useful to split the end-to-end IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 link (PDP context) to connect to the GGSN without the need to communicate over an IPv6 network. Regarding the GGSN-to-v4NODE communication, typically the transport network between the GGSN and external networks will support only IPv4 in the early stages and migrate to dual stack, since these networks are already deployed. Therefore it is not envisaged that tunneling of IPv4 in IPv6 will be required from the GGSN to external IPv4 networks either. In the longer run, 3GPP operators may need to phase out IPv4 UEs and the IPv4 transport network. This would leave only IPv6 UEs. Therefore, overall, the transition scenario involving an IPv4 UE communicating with an IPv4 peer through an IPv6 network is not considered very likely in 3GPP networks. ==> the paragraph is too long and should be reorganized slightly so that it can be split to two or more paragraphs. However, since it is difficult to anticipate all possible applications, there is a need for translators that can translate ==> s/all/all the/ 2. Additional forwarding delays due to further processing, when compared to normal IP forwarding. 3. Problems with source address selection due to the inclusion of a DNS ALG on the same node [NATPT-DNS]. ==> start these with "There are ..." Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface, would raise concerns on the overall network reliability. ==> s/interface,/interface/ The legacy IPv4 nodes are mostly nodes that support the applications that are popular today in the IPv4 Internet: mostly e- mail, and web-browsing. ==> s/mail,/mail/ applications. As these application are designed for IPv6, and to use the advantages of newer platforms, ==> s/application/applications/ Taking the above into account, the traffic to and from the legacy IPv4 UE is restricted to a few applications. These applications already today mostly rely on proxies or local servers to communicate between private address space networks and the Internet. ==> remove "today" from "already today mostly rely" (too complex otherwise :-) 4. IMS Transition Scenarios As the IMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically. In the following, the possible transition scenarios are listed. ==> reword: (or something to the effect). As the IMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically and are listed below. The recommended approach (as documented in [DNStrans]) currently is that every recursive DNS server should be either IPv4-only or dual ==> s/currently is/is currently/ ? stack and every single DNS zone should be served by at least an IPv4 reachable DNS server. The recommendation rules out IPv6-only ==> s/an/one/ There will probably be few legacy IPv4 nodes in the Internet that will communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed. ==> did you really mean "few" (like, "hardly any"), or "a few" ? Figure 1 shows a possible configuration scenario where the SIP ALG is separate to the CSCFs. ==> s/separate to/separated from/ (or something else, I'm not sure what the text is intended to mean) ? The authors notify that work is being done on analyzing 3GPP IPv4/IPv6 translators related to IMS scenario 1, and a personal draft is expected shortly. ==> note that the IMS scenario 1 is really *this* scenario, should this be reworded? 7. Copyright ==> please also add the IPR section 8. References 8.1 Normative [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description Protocol, RFC 2327, April 1998. [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 in Session Description Protocol (SDP), June 2002. ==> are these meant as normative references? No harm in having them, I guess, but I guess they're more like informational in nature.. [ISP-scen] Mickles, C. (Editor): "Transition Scenarios for ISP Networks", March 2003, draft-mickles-v6ops-isp-cases-05.txt, work in progress. ==> replace by Mikael Lind's document (I think) [ISP-analysis] Mickles, C. (Editor): "Transition Analysis for ISP Networks", February 2003, draft-mickles-v6ops-isp-analysis-00.txt, work in progress. ==> this should be removed for now (I think) -- 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 Jul 21 17:23:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11292 for ; Mon, 21 Jul 2003 17:23:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ei4G-000IIP-6S for v6ops-data@psg.com; Mon, 21 Jul 2003 21:19:36 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.14) id 19ei4B-000IHw-CA for v6ops@ops.ietf.org; Mon, 21 Jul 2003 21:19:31 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6LLJTB23932 for ; Tue, 22 Jul 2003 00:19:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jul 2003 00:19:29 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 00:19:28 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Jul 2003 00:19:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-04: Editorial issues Date: Tue, 22 Jul 2003 00:19:27 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A1B@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: Editorial issues Thread-Index: AcNPh8ZnjE1Xg7f1SVqgqb6tdPDfAQAPU7AA From: To: , X-OriginalArrivalTime: 21 Jul 2003 21:19:27.0668 (UTC) FILETIME=[C44B8740:01C34FCD] X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_10,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Pekka!=20 Many thanks for your comments, some comments below marked with JW. -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 21 July, 2003 15:55 I've looked a bit into 3GPP Analysis document, and I'll be sending out=20 issues I found out separated in different messages, a day or so apart. =20 Whether they should be filed in an issue tracker (like Roundup), a web page, etc. is up to the 3GPP design team, and especially = the editor. JW: Using the tracker is a good idea, I consider that after my holidays. editorial --------- This document analyzes the transition scenarios in 3GPP packet data networks that might come up in the deployment phase of IPv6. The transition scenarios are documented in [3GPP-SCEN] and this document will further analyze them. The scenarios are divided into two categories: GPRS scenarios and IMS scenarios. =3D=3D> first use of "IMS", so spell it out. JW: Yep. 1.1 Scope of this Document = =20 The scope of this informational document is to analyze and solve the possible transition scenarios in the 3GPP defined GPRS network =20 =3D=3D> note that the category will be BCP, so perhaps it's better to=20 substitute s/informational/Best Current Practices/, or even = "informational=20 Best Current Practices/, as you prefer considering the audience (i.e.=20 whether they're aware of what BCP really means) JW: That's correct, I will use BCP. where a UE connects to, or is contacted from the Internet, or =3D=3D> s/from/from,/, s/Internet,/Internet/ ? JW: Hmm, good question is, whether any commas are needed in that=20 sentence at all - can any native speaker confirm? of the SIP based IP Multimedia Core Network Subsystem (IMS). This document is not focused on radio interface issues; both 3GPP Second =20 =3D=3D> s/is not focused/does not focus/ ? JW: ok 1.2 Abbreviations = =20 =3D=3D> I note that SGSN, HLR and DNS (at least) are not listed. At = least the=20 first two should be added. JW: Yes, the abbreviations HLR and SGSN (mentioned only once) are = missing, and so is DNS also. I will add all three, and check the doc through for any other missing abbreviations. 1.3 Terminology = =20 Dual Stack UE Dual Stack UE is a 3GPP mobile handset having dual stack implemented. It is capable of activating both IPv4 and IPv6 PDP contexts. Dual stack UE may be capable of tunneling. =20 =3D=3D> there is a slight circular definition here, "DS UE is something = with=20 dual stack". Maybe some rewording would be needed? Not a major issue. JW: Yep, dual stack has dual stack... I'll make some rewording, such as the UE has both IPv4 and IPv6 stacks. This chapter briefly introduces some transition mechanisms specified by the IETF. Applicability of different transition mechanisms to 3GPP networks is discussed in chapters 3 and 4. = =20 =3D=3D> s/Applicability/The applicability/ ? JW: That can be correct... The following scenarios described by [3GPP-SCEN] are analyzed here. In all of the scenarios, the UE is part of a network where there is at least one router of the same IP version, i.e. GGSN, and it is connecting to a node in a different network. =3D=3D> s/it is/the UE is/ JW: got it. In this scenario, the dual stack UE is capable of communicating with both IPv4 and IPv6 nodes. It is recommended to activate an IPv6 PDP context when communicating with an IPv6 peer node and an =20 =3D=3D> spell out PDP. JW: PDP context needs to be spelled out. I will do it already in section = 2.1 or even in 1.3. However, the UE may attach to a 3GPP network, in which the SGSN (Serving GPRS Support Node), the GGSN and the HLR (Home Location Register) support IPv4 PDP contexts by default, =3D=3D> change the order of term and abbreviation: Serving GPRPS Support Node (SGSN), Home Location Register (HLR)=20 JW: You mean alphabetical order? Anyway, I would like to list the network elements in a more logical order, according to their = functionalities. One deployment scenario example is using laptop computer and a UMTS UE as a modem. =3D=3D> s/laptop/a laptop/ =3D=3D> I don't think UE is a modulator/demodulator and calling it a = modem=20 may be a bit confusing ? JW: 1. ok, 2. That is the common language used, e.g. GPRS phones are = shown as modems and AT commands are used for contorl. Another term we could=20 use is dial-up (emulation). When analyzing a dual stack UE behavior, an application running on a UE can identify whether the endpoint required is an IPv4 or IPv6 capable node by examining the address to discover what address family category it falls into.=20 =3D=3D> reword "application": typically, this function is performed at a = lower=20 layer (operating system, IP stack), and the use of applciation gives = IMHO=20 the wrong picture that the applications themselves would have to somehow = distinguish the end-point address family. JW: Hmm, some applications can participate in that decision making?=20 But what kind of rewording would you suggest? =3D=3D> s/category// JW: got it. Since the UE is capable of native communication with both protocols, one of the main concerns of an operator is correct address space and routing management. =3D=3D> s/correct/the correct/ ? JW: ok Keeping the Internet name space unfragmented is another important issue for both IPv4 and IPv6. It means that any record in the public Internet should be available unmodified to any nodes, IPv4 or IPv6, regardless of the transport being used. =3D=3D> s/any record/any DNS record/ (maybe even spell out DNS) JW: DNS record sounds good. served by at least an IPv4 reachable DNS server. This =20 =3D=3D> s/an/one/ JW: yup. be used. In a 3GPP network, one IPv6 island could contain the GGSN while another island contains the operator's IPv6 application servers. However, manually configured tunnels can be an =20 =3D=3D> s/contains/could contain/ JW: I would put "can contain" to both. "6to4" nodes use special IPv6 addresses with a "6to4" prefix containing the IPv4 address of the corresponding "IPv6 in IPv4" tunnel endpoint ("6to4" router) which performs encapsulation / decapsulation. When connecting two nodes with "6to4" addresses, the =20 =3D=3D> s/"6to4"/6to4/ (could explain it the first time 6to4 is stated = if=20 necessary) JW: Yep, actually those quotation marks are not needed, I will spell out = 6to4 when it pops up for the first time. 3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network = =20 3GPP networks are expected to support both IPv4 and IPv6 for a long time, on the UE-GGSN link and between the GGSN and external networks. For this scenario it is useful to split the end-to-end IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to- v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4 link (PDP context) to connect to the GGSN without the need to communicate over an IPv6 network. Regarding the GGSN-to-v4NODE communication, typically the transport network between the GGSN and external networks will support only IPv4 in the early stages and migrate to dual stack, since these networks are already deployed. Therefore it is not envisaged that tunneling of IPv4 in IPv6 will be required from the GGSN to external IPv4 networks either. In the longer run, 3GPP operators may need to phase out IPv4 UEs and the IPv4 transport network. This would leave only IPv6 UEs. Therefore, overall, the transition scenario involving an IPv4 UE communicating with an IPv4 peer through an IPv6 network is not considered very likely in 3GPP networks. =3D=3D> the paragraph is too long and should be reorganized slightly so = that=20 it can be split to two or more paragraphs. JW: The paragraph is not that long, but because it is the whole section, I'll do it. However, since it is difficult to anticipate all possible applications, there is a need for translators that can translate =20 =3D=3D> s/all/all the/ JW: ok 2. Additional forwarding delays due to further processing, when compared to normal IP forwarding. = =20 3. Problems with source address selection due to the inclusion of a DNS ALG on the same node [NATPT-DNS]. =3D=3D> start these with "There are ..." JW: fine for me. However, parts of that text may be removed once we can refer to NAT-PT appl- statement doc. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface, would raise concerns on the overall network reliability. =3D=3D> s/interface,/interface/ JW: ok The legacy IPv4 nodes are mostly nodes that support the applications that are popular today in the IPv4 Internet: mostly e- mail, and web-browsing. =3D=3D> s/mail,/mail/ JW: ok applications. As these application are designed for IPv6, and to use the advantages of newer platforms, =3D=3D> s/application/applications/ JW: good point. Taking the above into account, the traffic to and from the legacy IPv4 UE is restricted to a few applications. These applications already today mostly rely on proxies or local servers to communicate between private address space networks and the Internet. =3D=3D> remove "today" from "already today mostly rely" (too complex = otherwise=20 :-) JW: OK, this is not an EU directive document, will do something to it. 4. IMS Transition Scenarios = =20 As the IMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically. In the following, the possible transition scenarios are listed. =3D=3D> reword: (or something to the effect). JW: I try to do something. As the IMS is exclusively IPv6, the number of possible transition scenarios is reduced dramatically and are listed below. =20 The recommended approach (as documented in [DNStrans]) currently is that every recursive DNS server should be either IPv4-only or dual =3D=3D> s/currently is/is currently/ ? JW: I'd keep the order as it is. stack and every single DNS zone should be served by at least an IPv4 reachable DNS server. The recommendation rules out IPv6-only =20 =3D=3D> s/an/one/ JW: got it There will probably be few legacy IPv4 nodes in the Internet that will communicate with the IMS UEs. It is assumed that the solution described here is used for limited cases, in which communications with a small number of legacy IPv4 SIP equipment are needed. =3D=3D> did you really mean "few" (like, "hardly any"), or "a few" ? JW: Our intention was to say, that the number of legacy IPv4 SIP nodes that need to communicate with IMS UEs probably is (really) small, = so few is correct. Figure 1 shows a possible configuration scenario where the SIP ALG is separate to the CSCFs. =3D=3D> s/separate to/separated from/ (or something else, I'm not sure = what=20 the text is intended to mean) ? JW: At least "separated from" sounds good. I don't actually know whether = "separate to" is incorrect..? The authors notify that work is being done on analyzing 3GPP IPv4/IPv6 translators related to IMS scenario 1, and a personal draft is expected shortly. =3D=3D> note that the IMS scenario 1 is really *this* scenario, should = this be=20 reworded? JW: I will reword that anyway and tell about Karim's draft. 7. Copyright = =20 =3D=3D> please also add the IPR section JW: Yep, can add that, even though we don't have any IPRs on this doc. Is it a needed section in every draft / RFC? 8. References 8.1 Normative [RFC2327] Handley, M., Jacobson, V.: SDP: Session Description Protocol, RFC 2327, April 1998. = =20 [RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6 in Session Description Protocol (SDP), June 2002. =3D=3D> are these meant as normative references? No harm in having = them, I=20 guess, but I guess they're more like informational in nature.. JW: It was easy putting them as normative references, because they are RFCs. As you commented. those RFCs contain relevant background = information for IMS scen 1 / SIP functionality related to that. But anyway, we are not = considering SIP parts that deeply. [ISP-scen] Mickles, C. (Editor): "Transition Scenarios for ISP Networks", March 2003, draft-mickles-v6ops-isp-cases-05.txt, work in progress. =3D=3D> replace by Mikael Lind's document (I think) JW: Yep, needs to have the latest doc. = =20 [ISP-analysis] Mickles, C. (Editor): "Transition Analysis for ISP Networks", February 2003, draft-mickles-v6ops-isp-analysis-00.txt, work in progress. =3D=3D> this should be removed for now (I think) = = =20 JW: Yes, at least until Lind's team manages to puglish their -00 = analysis. I will start my 3,5 week holiday on Tuesday afternoon and will be back = on week 34. I will produce a new version of our document that week. Hopefully = other members in the design team can reply to the comments sent on the mailing list. Cheers, -Juha- From owner-v6ops@ops.ietf.org Tue Jul 22 03:33: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 DAA04414 for ; Tue, 22 Jul 2003 03:33:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19erbv-000Mtq-8h for v6ops-data@psg.com; Tue, 22 Jul 2003 07:30:59 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19erbr-000MtY-7h for v6ops@ops.ietf.org; Tue, 22 Jul 2003 07:30:55 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M7Url00952 for ; Tue, 22 Jul 2003 10:30:53 +0300 Date: Tue, 22 Jul 2003 10:30:52 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_20,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is my second issue in the 3GPP analysis document. ---- Section 3.4 (see the text below), "IPv6 UE Connecting to an IPv4 Node", describes the common case of IPv6-only UE connecting to an IPv4 node. The technique specified is NAT-PT, and the text includes some words of NAT-PT applicability as well as a reference to NAT64. I believe this approach is not a good one, as here NAT-PT (or something like that) is used as a general purpose translation device for all kinds of traffic. I think we need to figure out whether this is really necessary or acceptable. My personal belief is that we consider the model: - Use IPv4 where appropriate, - Not deploy IPv6-only UE's if they have a need to reach IPv4 services, and - Use application proxies (such as HTTP gateways, maybe even TCP/UDP relays specific to an application) where appropriate to make it easier to go for IPv6-only UE's at some point if it's the way to go. Other thoughts? ---- cut ----- 3.4 IPv6 UE Connecting to an IPv4 Node IPv6 nodes can communicate with IPv4 hosts by making use of a translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local network. For some applications, application proxies can be appropriate (e.g. HTTP, email relays, etc.). Such applications will not be transparent to the UE. Hence, a flexible mechanism with minimal manual intervention should be used to configure these proxies on IPv6 UEs. Within the 3GPP architecture, application proxies can be placed on the GGSN external interface (Gi), or inside the service network. However, since it is difficult to anticipate all possible applications, there is a need for translators that can translate headers independent of the type of application being used. Due to the significant lack of IPv4 addresses in some domains, port multiplexing is likely to be a necessary feature for translators (i.e. NAPT-PT). When NA(P)T-PT is used, it needs to be placed on the GGSN external (Gi) interface, typically separate from the GGSN. NA(P)T-PT can be installed, for example, on the edge of the operator's network and the public Internet. NA(P)T-PT will intercept DNS requests and other applications that include IP addresses in their payloads, translate the IP header (and payload for some applications if necessary) and forward packets through its IPv4 interface. NA(P)T-PT introduces limitations that are expected to be magnified within the 3GPP architecture. Some of these limitations are listed below (notice that some of them are also relevant for IPv4 NAT). We note here that [v4v6trans] analyzes the issues when translating between IPv4 and IPv6. However, the NAT-PT issues should be clearly documented in an RFC in the v6ops Working Group and a decision should be made, whether revisiting the NAT-PT RFC is necessary / what kind of update is needed. 1. NA(P)T-PT is a single point of failure for all ongoing connections. 2. Additional forwarding delays due to further processing, when compared to normal IP forwarding. 3. Problems with source address selection due to the inclusion of a DNS ALG on the same node [NATPT-DNS]. 4. NA(P)T-PT does not work (without application level gateways) for applications that embed IP addresses in their payload. 5. NA(P)T-PT breaks DNSSEC. 6. NA(P)T-PT does not scale very well in large networks. 3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface, would raise concerns on the overall network reliability. In addition, IPv6 users are expected to use delay-sensitive applications provided by IMS. Hence, there is a need to minimize forwarding delays within the IP backbone. Furthermore, due to the unprecedented number of connections handled by the default routers (GGSN) in 3GPP networks, a network design that forces traffic to go through a single node at the edge of the network (typical NA(P)T-PT configuration) is not likely to scale. Translation mechanisms should allow for multiple translators, for load sharing and redundancy purposes. To minimize the problems associated with NA(P)T-PT, the following actions can be recommended: 1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6 to IPv4" case). 2. Ensure (if possible) that NA(P)T-PT does not become a single point of failure. 3. Allow for load sharing between different translators. That is, it should be possible for different connections to go through different translators. Note that load sharing alone does not prevent NA(P)T-PT from becoming a single point of failure. There are some ways to fix the problems with NA(P)T-PT, one suggestion is [NAT64]. When thinking the DNS issues, the IPv6 UE needs to find the IPv4 address in the DNS [DNStrans]. Note that DNSSEC is broken if NA(P)T-PT is used. -- 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 Jul 22 03:35: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 DAA04475 for ; Tue, 22 Jul 2003 03:35:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ergB-000N7Z-3S for v6ops-data@psg.com; Tue, 22 Jul 2003 07:35:23 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19erfw-000N5i-Tx for v6ops@ops.ietf.org; Tue, 22 Jul 2003 07:35:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M7Z6A00976 for ; Tue, 22 Jul 2003 10:35:07 +0300 Date: Tue, 22 Jul 2003 10:35:06 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: necessity for protocol translators in sect 2.3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is the second issue for today; because it's heavily interconnected with the first bullet, I'm posting it at the same time. ------ If the approach "use of NAT-PT in IPv6 UE -> IPv4 node" is accepted (and maybe even if not), I'd also modify section 2.3 slightly: 1) the "Translators are typically needed" sounds too strong, and 2) "two communicating nodes" does not address the peer-to-peer or other non-client-server applications, so generalize the text to say just "communicating nodes" ------ 2.3 Protocol Translators A translator can be defined as an intermediate component between a native IPv4 node and a native IPv6 node to enable direct communication between them without requiring any modifications to the end nodes. Header conversion is a translation mechanism. In header conversion, IPv6 packet headers are converted to IPv4 packet headers, or vice versa, and checksums are adjusted or recalculated if necessary. NAT-PT (Network Address Translator / Protocol Translator) [RFC2766] using SIIT [RFC2765] is an example of such a mechanism. Translators are typically needed when the two communicating nodes do not share the same IP version. Translation can actually happen at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP proxy) or Layer 7 (using application relays). modify the last paragraph to (for example): Translators may be needed in some cases when the communicating nodes do not share the same IP version. Translation can actually happen at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP proxy) or Layer 7 (using application relays). -- 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 Jul 22 04:04: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 EAA05074 for ; Tue, 22 Jul 2003 04:04:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19es7k-000OXi-95 for v6ops-data@psg.com; Tue, 22 Jul 2003 08:03:52 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.14) id 19es7h-000OVS-Id for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:03:49 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 04:03:19 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BC3@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node Date: Tue, 22 Jul 2003 04:03:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Section 3.4 (see the text below), "IPv6 UE Connecting to an > IPv4 Node", > describes the common case of IPv6-only UE connecting to an > IPv4 node. > The technique specified is NAT-PT, and the text includes > some words of > NAT-PT applicability as well as a reference to NAT64. => Perhaps we should remove the reference to NAT64. > > I believe this approach is not a good one, as here NAT-PT > (or something > like that) is used as a general purpose translation device > for all kinds > of traffic. => Your interpretation is correct but I'm not sure about the benefit part. > > I think we need to figure out whether this is really necessary or > acceptable. > > My personal belief is that we consider the model: > - Use IPv4 where appropriate, => This is already assumed. > - Not deploy IPv6-only UE's if they have a need to reach > IPv4 services, and => This is also already assumed, more on this below. > - Use application proxies (such as HTTP gateways, maybe > even TCP/UDP > relays specific to an application) where appropriate to make > it easier to > go for IPv6-only UE's at some point if it's the way to go. => Again this is already assumed. In draft-elmalki-v6ops ... which was presented in Vienna, we explained the case for NAT-PT. Basically, unlike ethernet, a "3GPP link" cannot be dual stacked. A UE can certainly be dual stacked, but a "link" (PDP context) can only run either V4 or V6 but _not_ both. So, despite having a dual stack UE, you might only have one PDP context that supports v6 for example. To avoid the cost of setting up another PDP context, a UE may continue to use v6. For more details on the cost of setting up a PDP context see draft-elmalki. The other reason is IMS which mandates IPv6 for signalling and media. Hesham From owner-v6ops@ops.ietf.org Tue Jul 22 04:09: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 EAA05226 for ; Tue, 22 Jul 2003 04:09:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esDF-000Onn-9Z for v6ops-data@psg.com; Tue, 22 Jul 2003 08:09:33 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.14) id 19esDD-000OmP-9G for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:09:31 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 04:09:01 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BC4@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: necessity for protocol translators in sect 2.3 Date: Tue, 22 Jul 2003 04:08:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > If the approach "use of NAT-PT in IPv6 UE -> IPv4 node" is > accepted (and > maybe even if not), I'd also modify section 2.3 slightly: > > 1) the "Translators are typically needed" sounds too strong, => The rest of the sentence is needed though "when two communicating nodes have different IP stacks". Note that this does not imply that they don't implement both stacks, it just means that in the context of a certain communication scenario, they appear to be single-stacked. See my other response to your first issue (re PDP context). > modify the last paragraph to (for example): > > > Translators may be needed in some cases when the > communicating nodes > do not share the same IP version. => I don't have a strong opinion on this but a reader might ask "what do you do in the other cases?" Because you use "some" above after assuming two nodes with different IP stacks. Actually, I think maybe we should not associate translation with ALGs, after all, they don't actually translate. Hesham From owner-v6ops@ops.ietf.org Tue Jul 22 04:12: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 EAA05301 for ; Tue, 22 Jul 2003 04:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esFp-000OvT-KE for v6ops-data@psg.com; Tue, 22 Jul 2003 08:12:13 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19esFm-000Ouv-Hl for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:12:10 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M8C6C01334; Tue, 22 Jul 2003 11:12:06 +0300 Date: Tue, 22 Jul 2003 11:12:06 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BC3@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 22 Jul 2003, Soliman Hesham wrote: > > - Use application proxies (such as HTTP gateways, maybe > > even TCP/UDP > > relays specific to an application) where appropriate to make > > it easier to > > go for IPv6-only UE's at some point if it's the way to go. > > => Again this is already assumed. > > In draft-elmalki-v6ops ... which was presented in Vienna, > we explained the case for NAT-PT. Basically, unlike ethernet, > a "3GPP link" cannot be dual stacked. A UE can certainly be > dual stacked, but a "link" (PDP context) can only run either > V4 or V6 but _not_ both. Use another PDP context for IPv4. (Which is what I tried to advocate..) > For more details on the cost of setting up > a PDP context see draft-elmalki. I fail to see anything convincing there; - PDP contexts require state in the 3GPP network, and - PDP context require radio signalling or a channel Lots of things require state in the network, including any kind of protocol translator. Protocol translators mitigate the need for radio channels, and this is likely to be a problem only in the short term, when the number of radio signalling/channels is not a problem (a small number of customers). > The other reason is IMS which mandates IPv6 for signalling > and media. I thought draft-elmalki was primarily focused on solving the IMS signalling problem -- which seems strictly separate from this "NAT-PT for general consumption" approach, and needs to be settled when we figure out which way to go in the IMS Scenario 1. -- 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 Jul 22 04:20: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 EAA05444 for ; Tue, 22 Jul 2003 04:20:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esN6-000PJf-Jf for v6ops-data@psg.com; Tue, 22 Jul 2003 08:19:44 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.14) id 19esN4-000PHQ-9w for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:19:42 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 04:19:12 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BC5@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node Date: Tue, 22 Jul 2003 04:19:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > In draft-elmalki-v6ops ... which was presented in Vienna, > > we explained the case for NAT-PT. Basically, unlike ethernet, > > a "3GPP link" cannot be dual stacked. A UE can certainly be > > dual stacked, but a "link" (PDP context) can only run either > > V4 or V6 but _not_ both. > > Use another PDP context for IPv4. (Which is what I tried to > advocate..) > > > For more details on the cost of setting up > > a PDP context see draft-elmalki. > > I fail to see anything convincing there; > - PDP contexts require state in the 3GPP network, and > - PDP context require radio signalling or a channel => There is also the time it takes to setup a PDP context, which is significant. > > Lots of things require state in the network, including any kind of > protocol translator. Protocol translators mitigate the need > for radio > channels, => This is not related to radio channels, it's related to the time and the resources consumed in the network. and this is likely to be a problem only in the > short term, when > the number of radio signalling/channels is not a problem (a > small number > of customers). => I don't understand the above statement. There is no relationship between the resources/time consumed to setup a context and the number of customers. > > > The other reason is IMS which mandates IPv6 for signalling > > and media. > > I thought draft-elmalki was primarily focused on solving the IMS > signalling problem -- which seems strictly separate from > this "NAT-PT for > general consumption" approach, and needs to be settled when > we figure out > which way to go in the IMS Scenario 1. => They are tightly coupled. The draft first makes the case for NAT-PT and then goes into how IMS would use it. If IMS requires translation anyway, NAT-PT will be used. Everything is running in the same network. Hesham From owner-v6ops@ops.ietf.org Tue Jul 22 04:21: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 EAA05487 for ; Tue, 22 Jul 2003 04:21:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esP5-000PTw-Tu for v6ops-data@psg.com; Tue, 22 Jul 2003 08:21:47 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19esP3-000PTd-3r for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:21:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M8Lfv01421; Tue, 22 Jul 2003 11:21:41 +0300 Date: Tue, 22 Jul 2003 11:21:41 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: necessity for protocol translators in sect 2.3 In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BC4@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 22 Jul 2003, Soliman Hesham wrote: > > modify the last paragraph to (for example): > > > > > > Translators may be needed in some cases when the > > communicating nodes > > do not share the same IP version. > > => I don't have a strong opinion on this but > a reader might ask "what do you do in the other cases?" > Because you use "some" above after assuming two > nodes with different IP stacks. If this is a worry, we could expand it a bit, maybe like: Translators may be needed in some cases when the communicating nodes do not share the same IP version; in others, it may be possible to avoid such communication altogether. Translation can actually happen at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP proxy) or Layer 7 (using application relays). (or just remove "in some cases", it's not really a problem for me.) > Actually, I think maybe we should not associate > translation with ALGs, after all, they don't actually > translate. If we'd do this, the above would hold without modifications. I'm not sure whether having proxies and such under translators is too big a stretch or not (when you consider it from the end-to-end point of view, they certainly do something..). Removing it from here would certainly require some new text and shift balances around quite a bit. -- 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 Jul 22 04:27: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 EAA05606 for ; Tue, 22 Jul 2003 04:27:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esTw-000Pr5-UW for v6ops-data@psg.com; Tue, 22 Jul 2003 08:26:48 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.14) id 19esTu-000Pp1-AK for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:26:46 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 04:26:16 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BC6@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: necessity for protocol translators in sect 2.3 Date: Tue, 22 Jul 2003 04:26:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This text is fine with me. Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, July 22, 2003 4:22 AM > To: Soliman Hesham > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-04: necessity for protocol translators in > sect 2.3 > > > On Tue, 22 Jul 2003, Soliman Hesham wrote: > > > modify the last paragraph to (for example): > > > > > > > > > Translators may be needed in some cases when the > > > communicating nodes > > > do not share the same IP version. > > > > => I don't have a strong opinion on this but > > a reader might ask "what do you do in the other cases?" > > Because you use "some" above after assuming two > > nodes with different IP stacks. > > If this is a worry, we could expand it a bit, maybe like: > > Translators may be needed in some cases when the > communicating nodes > do not share the same IP version; in others, it may be > possible to > avoid such communication altogether. Translation can > actually happen > at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP > proxy) or Layer 7 (using application relays). > > (or just remove "in some cases", it's not really a problem for me.) > > > Actually, I think maybe we should not associate > > translation with ALGs, after all, they don't actually > > translate. > > If we'd do this, the above would hold without modifications. > I'm not sure > whether having proxies and such under translators is too big > a stretch or > not (when you consider it from the end-to-end point of view, they > certainly do something..). Removing it from here would > certainly require > some new text and shift balances around quite a bit. > > -- > 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 Jul 22 04:39: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 EAA05788 for ; Tue, 22 Jul 2003 04:39:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19esdL-0000ft-1D for v6ops-data@psg.com; Tue, 22 Jul 2003 08:36:31 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19esdH-0000fM-2R for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:36:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M8aNx01563; Tue, 22 Jul 2003 11:36:23 +0300 Date: Tue, 22 Jul 2003 11:36:22 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BC5@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 22 Jul 2003, Soliman Hesham wrote: > > > In draft-elmalki-v6ops ... which was presented in Vienna, > > > we explained the case for NAT-PT. Basically, unlike ethernet, > > > a "3GPP link" cannot be dual stacked. A UE can certainly be > > > dual stacked, but a "link" (PDP context) can only run either > > > V4 or V6 but _not_ both. > > > > Use another PDP context for IPv4. (Which is what I tried to > > advocate..) > > > > > For more details on the cost of setting up > > > a PDP context see draft-elmalki. > > > > I fail to see anything convincing there; > > - PDP contexts require state in the 3GPP network, and > > - PDP context require radio signalling or a channel > > => There is also the time it takes to setup a PDP > context, which is significant. These need to be spelled out properly so we can make reasonable decisions. > > Lots of things require state in the network, including any kind of > > protocol translator. Protocol translators mitigate the need > > for radio > > channels, > > => This is not related to radio channels, it's related > to the time and the resources consumed in the network. This is very much related. If you, using e.g. IPv6 proxies, make it so that you basically never need IPv4, the time and resources consumed for IPv4 in the network is much smaller. > and this is likely to be a problem only in the > > short term, when > > the number of radio signalling/channels is not a problem (a > > small number > > of customers). > > => I don't understand the above statement. There is no > relationship between the resources/time consumed to setup > a context and the number of customers. There is. draft-elmalki-* seems to give an impression that the absolute number of state (for all users combined) is too much -- and my immediate reaction to that is that by reducing the amount of concurrent state the problem could be handled. This also helps to a lesser extent wrt. time consumed to setup contexts (if there are free resources == few customers in the network, you can set up contexts pre-emptively). > > > The other reason is IMS which mandates IPv6 for signalling > > > and media. > > > > I thought draft-elmalki was primarily focused on solving the IMS > > signalling problem -- which seems strictly separate from > > this "NAT-PT for > > general consumption" approach, and needs to be settled when > > we figure out > > which way to go in the IMS Scenario 1. > > => They are tightly coupled. The draft first makes > the case for NAT-PT and then goes into how IMS would > use it. If IMS requires translation anyway, NAT-PT > will be used. Everything is running in the same > network. Disagree. If IMS requires translation, we may end up designing a translation which suits IMS. The previous sections don't indicate which translation will be used for IMS, or that if IMS uses translation, the translation would also be used in *any* other kind scenario. -- 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 Jul 22 05:00: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 FAA06411 for ; Tue, 22 Jul 2003 05:00:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19eszT-00020m-Hq for v6ops-data@psg.com; Tue, 22 Jul 2003 08:59:23 +0000 Received: from [128.176.188.114] (helo=batch16.uni-muenster.de) by psg.com with esmtp (Exim 4.14) id 19eszR-00020a-4l for v6ops@ops.ietf.org; Tue, 22 Jul 2003 08:59:21 +0000 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch16.uni-muenster.de (Postfix) with ESMTP id BA5DF14BF; Tue, 22 Jul 2003 10:59:04 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id D7907312FE; Tue, 22 Jul 2003 10:59:03 +0200 (CEST) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 71C62312D3; Tue, 22 Jul 2003 10:59:02 +0200 (CEST) Subject: Re: 3gpp-analysis-04: necessity for protocol translators in sect 2.3 From: "Christian Strauf (JOIN)" To: Pekka Savola Cc: v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1058864358.24752.13.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 22 Jul 2003 10:59:18 +0200 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Status: No, hits=-19.1 required=5.0 tests=BAYES_20,IN_REP_TO,REFERENCES,USER_AGENT_XIMIAN autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi, > 2.3 Protocol Translators I hope that this wasn't already addressed: wouldn't it be good to mention Transport Relay Translators (TRT) (RFC 3142) here and in "3.4 IPv6 UE Connecting to an IPv4 Node"? Though I'm really not a fan of NA(P)T-PT and similar, I really think that TRT is much more well-behaved in terms of connection failures than NA(P)T-PT because of its way of handling ICMP. So I personally think that it would fit into this context quite nicely. Of course it still has many problems in common with NA(P)T-PT when it comes to translating certain protocols. Cheers, Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westfälische Wilhelms-Universität Münster http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung Team: join@uni-muenster.de Röntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 Münster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653 From owner-v6ops@ops.ietf.org Tue Jul 22 05: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 FAA06498 for ; Tue, 22 Jul 2003 05:03:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19et3Y-0002LY-Ks for v6ops-data@psg.com; Tue, 22 Jul 2003 09:03:36 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.14) id 19et3W-0002IM-Cr for v6ops@ops.ietf.org; Tue, 22 Jul 2003 09:03:34 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 05:03:04 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BC8@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node Date: Tue, 22 Jul 2003 05:03:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, > > => There is also the time it takes to setup a PDP > > context, which is significant. > > These need to be spelled out properly so we can make > reasonable decisions. > > > > Lots of things require state in the network, including > any kind of > > > protocol translator. Protocol translators mitigate the need > > > for radio > > > channels, > > > > => This is not related to radio channels, it's related > > to the time and the resources consumed in the network. > > This is very much related. If you, using e.g. IPv6 proxies, > make it so > that you basically never need IPv4, the time and resources > consumed for > IPv4 in the network is much smaller. => But what's the relevance of this to radio channels? There is one physical network that supports an aggregate (X) amount of traffic, whether it's v4 or v6. My comment was related to the time it takes to setup the context and the resources consumed in the SGSN and GGSN. > > => I don't understand the above statement. There is no > > relationship between the resources/time consumed to setup > > a context and the number of customers. > > There is. draft-elmalki-* seems to give an impression that > the absolute > number of state (for all users combined) is too much => I read your comment to mean that the number of radio channels is not important when there is a small number of users. That's what I couldn't parse. Certainly the no of PDP contexts does matter and is part of a GGSN spec (how many it can handle). -- and > my immediate > reaction to that is that by reducing the amount of > concurrent state the > problem could be handled. > > This also helps to a lesser extent wrt. time consumed to > setup contexts > (if there are free resources == few customers in the > network, you can set > up contexts pre-emptively). => I've lost you here, how do you make the decision that there are few customers in the network? How does the UE know that? > > => They are tightly coupled. The draft first makes > > the case for NAT-PT and then goes into how IMS would > > use it. If IMS requires translation anyway, NAT-PT > > will be used. Everything is running in the same > > network. > > Disagree. > > If IMS requires translation, we may end up designing a > translation which > suits IMS. The previous sections don't indicate which > translation will be > used for IMS, => What types of translation are there? We need IP address and port translation, hence NAPT-PT. The draft discusses how to install the translation state in the translator (i.e. installing it before traffic goes through the translator). or that if IMS uses translation, the > translation would also > be used in *any* other kind scenario. => It doesn't, but how can you restrict that in an IETF spec? If a UE doesn't get an IPv4 context, it will go through the translator. Hesham From owner-v6ops@ops.ietf.org Tue Jul 22 05:44: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 FAA07308 for ; Tue, 22 Jul 2003 05:44:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19etee-0003rh-Fy for v6ops-data@psg.com; Tue, 22 Jul 2003 09:41:56 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19eteb-0003rM-DX for v6ops@ops.ietf.org; Tue, 22 Jul 2003 09:41:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M9fmH02112; Tue, 22 Jul 2003 12:41:48 +0300 Date: Tue, 22 Jul 2003 12:41:48 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com, , Subject: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-14.7 required=5.0 tests=BAYES_10,IN_REP_TO,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, This is a WG Last Call for comments on sending the following first three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents to the IESG for consideration as Informational RFCs: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.txt Please review these documents carefully, and send your feedback to the list (editorial modifications may also be sent to the editor, Andreas). Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. Please note that the first document ("introduction") includes the summary of all the results, which are subject to change; please ignore the details of section 3 when reviewing it. The last call will end in 3 weeks, on 12th August. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Tue Jul 22 05:54:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07539 for ; Tue, 22 Jul 2003 05:54:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19etqL-0004RT-BI for v6ops-data@psg.com; Tue, 22 Jul 2003 09:54:01 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19etqH-0004R3-OL for v6ops@ops.ietf.org; Tue, 22 Jul 2003 09:53:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6M9rr302226; Tue, 22 Jul 2003 12:53:53 +0300 Date: Tue, 22 Jul 2003 12:53:52 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BC8@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 22 Jul 2003, Soliman Hesham wrote: > > > > Lots of things require state in the network, including > > any kind of > > > > protocol translator. Protocol translators mitigate the need > > > > for radio > > > > channels, > > > > > > => This is not related to radio channels, it's related > > > to the time and the resources consumed in the network. > > > > This is very much related. If you, using e.g. IPv6 proxies, > > make it so > > that you basically never need IPv4, the time and resources > > consumed for > > IPv4 in the network is much smaller. > > => But what's the relevance of this to radio channels? > There is one physical network that supports an aggregate > (X) amount of traffic, whether it's v4 or v6. > > My comment was related to the time it takes to setup the context > and the resources consumed in the SGSN and GGSN. The text in elmalki draft seems to suggest that there a UE with only v6 PDP context requires one radio channel, while a UE with v4/v6 PDP contexts require two radio channels (regardless of the fact that the aggregate bandwidth usage is the same). I don't know the radio technology well enough to to say whether this perception is true or not. > > my immediate > > reaction to that is that by reducing the amount of > > concurrent state the > > problem could be handled. > > > > This also helps to a lesser extent wrt. time consumed to > > setup contexts > > (if there are free resources == few customers in the > > network, you can set > > up contexts pre-emptively). > > => I've lost you here, how do you make the decision > that there are few customers in the network? How > does the UE know that? I don't know what (if any) signalling there is between the UE and the network where some hints about network utilization could be piggybacked. Probably a lot. But even if there wasn't any, the first UE's could be programmed to open both PDP contexts when they start, and possibly discard the other one if it is not used in X minutes (or even keep it, no matter). > > If IMS requires translation, we may end up designing a > > translation which > > suits IMS. The previous sections don't indicate which > > translation will be > > used for IMS, > > => What types of translation are there? We need IP > address and port translation, hence NAPT-PT. No. > The > draft discusses how to install the translation > state in the translator (i.e. installing it before > traffic goes through the translator). Yes, but for a very specific purpose only. > or that if IMS uses translation, the > > translation would also > > be used in *any* other kind scenario. > > => It doesn't, but how can you restrict > that in an IETF spec? If a UE doesn't get an IPv4 context, > it will go through the translator. Please, we're discussing the 3GPP solutions document. We as the WG can do it any way we see fit. Hopefully the solutions are reasonable though. If operators or vendors want to do something else, that's their problem and fine too. We should not write the document based on what people think might happen, but what we think *should* happen (but necessarily won't especially in all cases). -- 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 Jul 22 05:54: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 FAA07564 for ; Tue, 22 Jul 2003 05:54:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19etoU-0004LK-NP for v6ops-data@psg.com; Tue, 22 Jul 2003 09:52:06 +0000 Received: from [131.115.230.133] (helo=tms002bb.han.telia.se) by psg.com with esmtp (Exim 4.14) id 19etoS-0004Kv-2N for v6ops@ops.ietf.org; Tue, 22 Jul 2003 09:52:04 +0000 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Jul 2003 11:52:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: ISP team volunteers Date: Tue, 22 Jul 2003 11:52:02 +0200 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE837CF3E@TMS031MB.tcad.telia.se> Thread-Topic: ISP team volunteers Thread-Index: AcNQNuaIqrnJHX3zQgmYVP6sQLdAFw== From: To: X-OriginalArrivalTime: 22 Jul 2003 09:52:02.0742 (UTC) FILETIME=[E6D10560:01C35036] X-Spam-Status: No, hits=1.0 required=5.0 tests=NO_REAL_NAME version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, In Vienna I got a lot of new volunteers who wanted to help out in the = ISP team. All who talked to me should be in the list that follows. If = you are not on the list or if you want to help but didn't volunteer in = Vienna please contact me.=20 List of volunteers: Rute Sofia Stephan Millet=20 Bernard Tuy=20 David Meyer Iljisch Van Beijnum Marc Blanchet Shin Miyakawa Kurt Jaeger Simon Leinen =20 Thanks, Mikael From owner-v6ops@ops.ietf.org Tue Jul 22 06:40: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 GAA08721 for ; Tue, 22 Jul 2003 06:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19euWz-0006ee-4b for v6ops-data@psg.com; Tue, 22 Jul 2003 10:38:05 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.14) id 19euWt-0006dU-Jv for v6ops@ops.ietf.org; Tue, 22 Jul 2003 10:37:59 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 22 Jul 2003 06:37:29 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BC9@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node Date: Tue, 22 Jul 2003 06:37:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > The text in elmalki draft seems to suggest that there a UE > with only v6 > PDP context requires one radio channel, while a UE with > v4/v6 PDP contexts > require two radio channels (regardless of the fact that the > aggregate > bandwidth usage is the same). > > I don't know the radio technology well enough to to say whether this > perception is true or not. => Ok, we can add some text to clarify this. > > => I've lost you here, how do you make the decision > > that there are few customers in the network? How > > does the UE know that? > > I don't know what (if any) signalling there is between the UE and the > network where some hints about network utilization could be > piggybacked. > Probably a lot. => None exists today. > > But even if there wasn't any, the first UE's could be > programmed to open > both PDP contexts when they start, and possibly discard the > other one if > it is not used in X minutes (or even keep it, no matter). => You're making assumptions about product rollouts and deployment that are not necessarily correct. To be precise, you're assuming that UE's will come in phases: "First UE's", seconds ...etc and that they are synched with different scales of deployment. This is not the case. Second, you assume that early networks will be underutilised. This is also not necessarily a general rule and depends on each operator. > > => What types of translation are there? We need IP > > address and port translation, hence NAPT-PT. > > No. => No what? > > > The > > draft discusses how to install the translation > > state in the translator (i.e. installing it before > > traffic goes through the translator). > > Yes, but for a very specific purpose only. => The draft discusses a specific case, it doesn't _design_ a new translator for it. It discussed the use of the existing translator. > > => It doesn't, but how can you restrict > > that in an IETF spec? If a UE doesn't get an IPv4 context, > > it will go through the translator. > > Please, we're discussing the 3GPP solutions document. We as > the WG can do > it any way we see fit. Hopefully the solutions are > reasonable though. > If operators or vendors want to do something else, that's > their problem > and fine too. > > We should not write the document based on what people think > might happen, > but what we think *should* happen => What _should_ happen IMHO is that we explain how the technology would apply to 3GPP, specify pros and cons to our knowledge and stop right there. It is futile to try to restrict something without having a protocol fail if you attempt to do that restricted action. At least this is the aim of the existing keywords in RFC 2119. Hesham From owner-v6ops@ops.ietf.org Tue Jul 22 06:41: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 GAA08778 for ; Tue, 22 Jul 2003 06:41:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19euZn-0006nC-Or for v6ops-data@psg.com; Tue, 22 Jul 2003 10:40:59 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.14) id 19euZf-0006mj-0e for v6ops@ops.ietf.org; Tue, 22 Jul 2003 10:40:51 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6CF4999; Tue, 22 Jul 2003 19:40:48 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org, bob@thefinks.com, mrw@windriver.com, andreas.bergstrom@hiof.no In-reply-to: pekkas's message of Tue, 22 Jul 2003 12:41:48 +0300. 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: comment: draft-ietf-v6ops-ipv4survey-intro-01.txt From: itojun@iijlab.net Date: Tue, 22 Jul 2003 19:40:48 +0900 Message-Id: <20030722104048.6CF4999@coconut.itojun.org> X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk i made a quick one-path on the draft. i dunno how the references between sections are managed, i hope it is automated somehow... itojun overall "this problem has been fixed..." to state that there's IPv6 variant available for the document looks strange to me. line 250 wrong: STD 44/RFC 891 in Section 3.44 right: STD 44/RFC 891 in Section 3.1.17 line 274 (3.1.1) why this document suggests updates to RFC1812 to include IPv6 routing requirement, while suggesting separate IPv6 variant for RFC1122? not sure which is the right way to go. line 280 (3.1.3) these "has been updated" statement look strange to me. how about: RFC791 defines IPv4. RFC2460 defines IPv6. Similarly to RFC922 which defines IPv4 addressing architecture, RFC2373 defines IPv6 addressing architecture. RFC792 defines ICMP for IPv4. RFC2463 defines ICMPv6, which is ICMP for IPv6. RFC1122 defines IGMP, Internet Group Management Protocol for IPv4. RFC2710 defines MLD, Multicast Listener Discovery, which is basically IGMP for IPv6. line 303 (3.1.6) which document deprecates the use of literal IP address? RFC2822 still has domain-literal syntax, i.e. itojun@[10.1.1.1]. line 335 (3.1.13) how about: RFC2467 defines a method for the transmission IPv6 over FDDI networks. line 339 (3.1.14) how about: RFC2464 defines a method for the transmission IPv6 over ethernet networks. line 358 (3.1.19) how about: RFC2497 defines a method for the transmission IPv6 over ARCnet networks. line 383 (3.1.23) how about: RFC2740 defines OSPF for IPv6. line 388 (3.1.24) how about: RFC2080 defines RIPng, RIP for IPv6. line 397 (3.2.1) i don't think there's enough specification for DHCPv6 options to replace bootp as a whole. line 410 (3.2.3) how about: RFC1981 defines path MTU discovery for IPv6. line 560 (3.3.8) I don't think there's applicability statement for OSPFv3 in RFC2740. line 756 (3.3.43) I don't think RFC2492 defines IPv6 *broadcast* over ATM. how about: IPv6 does not utilize link-layer broadcast. From owner-v6ops@ops.ietf.org Tue Jul 22 08:09: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 IAA10678 for ; Tue, 22 Jul 2003 08:09:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19evuL-000BKl-CC for v6ops-data@psg.com; Tue, 22 Jul 2003 12:06:17 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19evu8-000BJL-1s for v6ops@ops.ietf.org; Tue, 22 Jul 2003 12:06:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6MC5tK03600; Tue, 22 Jul 2003 15:05:56 +0300 Date: Tue, 22 Jul 2003 15:05:55 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org, , , Subject: Re: comment: draft-ietf-v6ops-ipv4survey-intro-01.txt In-Reply-To: <20030722104048.6CF4999@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 22 Jul 2003 itojun@iijlab.net wrote: > overall > "this problem has been fixed..." to state that there's IPv6 variant > available for the document looks strange to me. Well, it's good (IMHO) for one purpose, explicitly stating that the problem no longer exists. That is, if you just say "RFC X defines Foo2, which is Foo for IPv6", it is not clear whether RFC X and Foo2 provide all the features the original Foo did. Saying it fixes the problem is a bit awkward but OK. However, I'm not sure if Phil actually analyzed whether the same functions are being provided.. That said, I think something like "RFC2080 defines RIPng, RIP for IPv6." is slightly better, editorial-wise. I could go either way, but I'd like to try to avoid a lot of (editorial) extra work for our editors if it doesn't have an acceptable cost/benefit ratio. Other thoughts? ... Responding to a few comments only which might possibly warrant more discussion. > line 274 (3.1.1) > why this document suggests updates to RFC1812 to include IPv6 routing > requirement, while suggesting separate IPv6 variant for RFC1122? > not sure which is the right way to go. Yes, I agree with that. I think it should say that router reqs for v6 should be defined. > line 303 (3.1.6) > which document deprecates the use of literal IP address? RFC2822 still > has domain-literal syntax, i.e. itojun@[10.1.1.1]. Very good point. I also thought it was done in 2822 but it seems it only removed certain older versions. Something to bring up to the apps folks, but I think there's already a person looking into these. > line 397 (3.2.1) > i don't think there's enough specification for DHCPv6 options to > replace bootp as a whole. I don't know bootp in particular, but I'd bet DHCPv6 provides enough of options to provide for bootp functionality. Do you have some particular options in mind? DHCPv4 certainly has quite a bit more of them than DHCPv6, though. > line 560 (3.3.8) > I don't think there's applicability statement for OSPFv3 in RFC2740. True. -- 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 Jul 22 08:25: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 IAA11019 for ; Tue, 22 Jul 2003 08:25:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ewCK-000C6e-1r for v6ops-data@psg.com; Tue, 22 Jul 2003 12:24:52 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.14) id 19ewCC-000C5Y-0B for v6ops@ops.ietf.org; Tue, 22 Jul 2003 12:24:44 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id ACB8413; Tue, 22 Jul 2003 21:24:41 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org, bob@thefinks.com, mrw@windriver.com, andreas.bergstrom@hiof.no In-reply-to: pekkas's message of Tue, 22 Jul 2003 15:05:55 +0300. 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: comment: draft-ietf-v6ops-ipv4survey-intro-01.txt From: itojun@iijlab.net Date: Tue, 22 Jul 2003 21:24:41 +0900 Message-Id: <20030722122441.ACB8413@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> line 397 (3.2.1) >> i don't think there's enough specification for DHCPv6 options to >> replace bootp as a whole. > >I don't know bootp in particular, but I'd bet DHCPv6 provides enough of >options to provide for bootp functionality. Do you have some particular >options in mind? DHCPv4 certainly has quite a bit more of them than >DHCPv6, though. most importantly, boot file name ("file" in RFC951 page 4). itojun From owner-v6ops@ops.ietf.org Wed Jul 23 05:40: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 FAA06898 for ; Wed, 23 Jul 2003 05:40:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fG3T-000AwM-Nt for v6ops-data@psg.com; Wed, 23 Jul 2003 09:37:03 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fG3Q-000Aw5-3v for v6ops@ops.ietf.org; Wed, 23 Jul 2003 09:37:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6N9avu16961 for ; Wed, 23 Jul 2003 12:36:58 +0300 Date: Wed, 23 Jul 2003 12:36:57 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: The use of 6to4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk The first issue of today. --8<-- In the document, the use of 6to4 is mentioned several times. However, this method needs some scoping: IMHO, it is clear that 6to4 is not a useful approach for ISP-like networks, so it is not useful to recommend that 3GPP networks use it for example for Internet connectivity. It is just so much easier to get a configured tunnel or native IPv6 from the upstream providers. You just can't build a service like 3GPP networks intend to using 6to4; for some internal piloting, etc. it may be possible, yes, but that's mostly outside of the scope of the document (but could be mentioned for completeness if enough folks feel like it). The text in the document is already healthily skeptical of 6to4's usefulness in this context, but I fail to see: - clear need for the existance of 6to4 here at all, and - sufficiently clear disclaimers why 6to4 is *NOT* the right solution for 3GPP networks. Note: this issue does not specifically address the document's suggestion to use 6to4 in the UE's, independent of the 3GPP operator. That'll be dealt with in the next issues. The text snippets below are the important ones: ----- 3.2.1 Tunneling inside the 3GPP Operator's Network [...] "6to4" nodes use special IPv6 addresses with a "6to4" prefix containing the IPv4 address of the corresponding "IPv6 in IPv4" tunnel endpoint ("6to4" router) which performs encapsulation / decapsulation. When connecting two nodes with "6to4" addresses, the corresponding "6to4" routers use the IPv4 addresses specified in the "6to4" prefixes to tunnel IPv6 packets through the IPv4 network. But if only one of them has a "6to4" address, a "6to4" relay must be present to perform the missing "6to4" router functionality for the native-IPv6 node. [note: could split to two paragraphs around here, the paragraph is both the 6to4 introduction and 3GPP application] If we consider the "6to4" tunneling mechanism and the 3GPP addressing model (a unique /64 prefix allocated for each primary PDP context), a /48 "6to4" prefix would only be enough for approximately 65000 UEs. Thus, a few public IPv4 addresses would be needed depending on the size of the operator. 3.2.2 Tunneling outside the 3GPP Operator's Network [...] On the other hand, usage of dynamic tunneling, such as "6to4", can also be considered, but scalability problems arise when thinking about the great number of UEs in the 3GPP networks. The specific limitation when applying "6to4" in 3GPP networks should also be taken into account, as commented in 3.2.1. Other issues to keep in mind with respect to the "6to4" mechanism are that reverse DNS is not yet completely solved and there are some security considerations associated with the use of "6to4" relay routers (see [6to4SEC]). Moreover, in a later phase of the transition period, there will be a need for assigning new, native IPv6 addresses to all "6to4" nodes in order to enable native IPv6 connectivity. ----- At least, add a new paragraph at the end of 3.2.2: In consequence, the use of 6to4 to enable IPv6 connectivity to a part or parts of the 3GPP network is strongly discouraged; configured tunneling or preferably native IPv6 connectivity is preferred. The end of the paragraph of 3.2.1 is also confusing things: tunneling inside the operator's network ("replacement for BGP tunneling"; as described in section 2.4.3 of draft-savola-v6ops-6to4-security-02.txt but IMHO a bit bad practice) -- and addressing the needs of the 3GPP UE's (pun intended). If you want to only use 6to4 internally, you can't deploy 6to4 addresses on the UE's. If you wan to use it externally, the considerations in the next section step out. So, I think at least the end of the last paragraph of section 3.2.1 should be removed/reworded. I also fail to see a strict need for the 6to4 introduction (the first part of the paragraph in 3.2.1) here, at least at this point. -- 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 Jul 23 05:40:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06914 for ; Wed, 23 Jul 2003 05:40:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fG4v-000B1S-Fi for v6ops-data@psg.com; Wed, 23 Jul 2003 09:38:33 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.14) id 19fG4r-000Ayx-6k for v6ops@ops.ietf.org; Wed, 23 Jul 2003 09:38:29 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6N9btuD021361; Wed, 23 Jul 2003 02:37:56 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-95.cisco.com [10.21.96.95]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX13803; Wed, 23 Jul 2003 05:37:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20030722093210.03dec948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jul 2003 05:37:47 -0400 To: itojun@iijlab.net From: Ralph Droms Subject: Re: comment: draft-ietf-v6ops-ipv4survey-intro-01.txt Cc: Pekka Savola , v6ops@ops.ietf.org, bob@thefinks.com, mrw@windriver.com, andreas.bergstrom@hiof.no In-Reply-To: <20030722122441.ACB8413@coconut.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk The dhc WG considered two ways to go about defining options in DHCPv6: - carry forward all of the existing DHCPv4 options - define DHCPv6 options "on demand" as specific requirements are recognized The WG decided to adopt the second strategy, so the base DHCPv6 specification includes all of the options needed for the basic DHCPv6 machinery, and some additional options have been defined in several other drafts. If there are specific options for which we can identify requirements, we can start the process to define those options... - Ralph At 09:24 PM 7/22/2003 +0900, itojun@iijlab.net wrote: > >> line 397 (3.2.1) > >> i don't think there's enough specification for DHCPv6 options to > >> replace bootp as a whole. > > > >I don't know bootp in particular, but I'd bet DHCPv6 provides enough of > >options to provide for bootp functionality. Do you have some particular > >options in mind? DHCPv4 certainly has quite a bit more of them than > >DHCPv6, though. > > most importantly, boot file name ("file" in RFC951 page 4). > >itojun From owner-v6ops@ops.ietf.org Wed Jul 23 06:24: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 GAA07674 for ; Wed, 23 Jul 2003 06:24:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fGlN-000Dc7-3z for v6ops-data@psg.com; Wed, 23 Jul 2003 10:22:25 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fGlI-000Dbr-6R for v6ops@ops.ietf.org; Wed, 23 Jul 2003 10:22:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6NAMCD17577 for ; Wed, 23 Jul 2003 13:22:13 +0300 Date: Wed, 23 Jul 2003 13:22:12 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: DNS guidelines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is the second issue of today. (I'm using an accelerated cycle because I'm leaving for vacation on Friday and want to send all of them out before that.) ---- Actually, there are five related issues here regarding DNS guidelines in the document. * The statement about IPv6-only DNS servers, "every recursive DNS server should be either IPv4-only or dual stack", it not entirely accurate. It is perfectly OK to have a IPv6-only DNS server which recursively queries from _other_ recursive DNS servers. As long as there are dual-stack recursive DNS servers in the "recursion chain", the rule is fulfilled. It may be useful to try to reword the text slightly to cover for this case too. * The analysis only refers to [DNStrans]; it should also refer to (where appropriate) draft-ietf-dnsop-ipv6-transport-guidelines-00.txt which is soon ready for DNSOP last call. * " When thinking the DNS issues, [...]" sounds bad and should be reworded (sorry, forgot to add this to the editorial section.) * The description in section 3.5 is very terse. The problems here appear to be two-fold: 1) either 3GPP operator's DNS servers should be dual-stack (to reach those bogus IPv6-only servers serving the AAAA records), or 2) at least one IPv4 DNS server is needed for AAAA records so that the 3GPP operator's DNS servers are able to get the record. The first is not noted, and the for the second, it is not stated that this is not the *3GPP operator's* problem, but guy's who is serving AAAA records. If we wants to break the operational practices for robust DNS, there is no way we can stop him.. * the description of DNS issues is spread throughout the document. Perhaps we should reword the section "2. Transition mechanisms" to "2. Transition mechanisms and considerations" and add a subsection on DNS, where we could move e.g. text in section 3.1 and the first paragraph of 4.1, and only give pointers and discussion specific to GPRS/IMS scenarios under those scenarios. ----- 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes [...] Keeping the Internet name space unfragmented is another important issue for both IPv4 and IPv6. It means that any record in the public Internet should be available unmodified to any nodes, IPv4 or IPv6, regardless of the transport being used. The recommended approach is the following: every recursive DNS server should be either IPv4-only or dual stack and every single DNS zone should be served by at least an IPv4 reachable DNS server. This recommendation rules out IPv6-only recursive DNS servers and DNS zones served by IPv6-only DNS servers, and this approach could be revisited if translation techniques between IPv4 and IPv6 were to be widely deployed [DNStrans]. 3.4 IPv6 UE Connecting to an IPv4 Node [...] When thinking the DNS issues, the IPv6 UE needs to find the IPv4 address in the DNS [DNStrans]. Note that DNSSEC is broken if NA(P)T-PT is used. 3.5 IPv4 UE Connecting to an IPv6 Node [...] When thinking the DNS issues, the DNS zones containing AAAA records for the IPv6 nodes need to be served by at least one IPv4 accessible DNS server [DNStrans]. 4.1 DNS Interworking in IMS The recommended approach (as documented in [DNStrans]) currently is that every recursive DNS server should be either IPv4-only or dual stack and every single DNS zone should be served by at least an IPv4 reachable DNS server. The recommendation rules out IPv6-only recursive DNS servers and DNS zones served by IPv6-only DNS servers. To perform DNS resolution in the IMS, the UE can be configured as a stub resolver pointing to a recursive DNS resolver. This communication can happen over IPv6. However, in the process to find the IPv6 address of a SIP server, the recursive DNS resolver may need to access data that is available only on some IPv4 DNS servers, see [DNStrans]. One way to achieve this is to make the DNS resolver be dual stack. As DNS traffic is not directly related to the IMS functionality, this is not in contradiction with the IPv6- only nature of the IMS. 8. References 8.2 Informative [DNStrans] Durand, A. and Ihren, J.: "IPv6 DNS transition issues", February 2003, draft-ietf-dnsop-ipv6-dns-issues-02.txt, work in progress. ----- -- 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 Jul 23 11:26: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 LAA16785 for ; Wed, 23 Jul 2003 11:26:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fLSI-0003xF-3b for v6ops-data@psg.com; Wed, 23 Jul 2003 15:23:02 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.14) id 19fLRl-0003vc-W8 for v6ops@ops.ietf.org; Wed, 23 Jul 2003 15:22:30 +0000 Received: (qmail 22246 invoked by uid 2502); 23 Jul 2003 15:21:58 -0000 Received: from rsofia@seas.upenn.edu by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.146736 secs); 23/07/2003 16:21:58 Received: from dhcp01.fccn.pt (HELO seas.upenn.edu) (193.136.7.131) by atlas.fccn.pt with SMTP; 23 Jul 2003 15:21:58 -0000 Message-ID: <3F1EA711.8060007@seas.upenn.edu> Date: Wed, 23 Jul 2003 16:17:37 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 To: Pekka Savola , v6ops@ops.ietf.org Subject: Re: Thoughts on the extent of changes to IPv4 survey documents? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-34.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, regarding the ipv4 survey documents, from a global viewpoint and given that the survey's purpose is simply to document identified IPv4 dependencies, the documents are just fine. Rute Pekka Savola wrote: >Hi editors (& co-chairs), > >As you may have seen, we've started a WG last-call on a couple of the >first IPv4 survey documents. As feedback, itojun sent a couple of wording >change suggestions. > >There are a lot of other possibilities to improve the documents as well, >but I'm not sure if it's worth the trouble. > >I'd like to solicit your thoughts as editors on what you feel is the >appropriate extent/scope of changes in the IPv4 survey documents? > >Please respond (if you have any opinions) here or in the v6ops thread. > >Thanks > > > From owner-v6ops@ops.ietf.org Wed Jul 23 12:25:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18862 for ; Wed, 23 Jul 2003 12:25:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fMNs-0007vL-Ss for v6ops-data@psg.com; Wed, 23 Jul 2003 16:22:32 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.14) id 19fMNo-0007uU-UV for v6ops@ops.ietf.org; Wed, 23 Jul 2003 16:22:28 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NGMS9k004059 for ; Wed, 23 Jul 2003 10:22:28 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIH003E6K5F5Y@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 23 Jul 2003 10:22:28 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIH00HQBK5B54@mail.sun.net> for v6ops@ops.ietf.org; Wed, 23 Jul 2003 10:22:27 -0600 (MDT) Date: Wed, 23 Jul 2003 09:24:30 -0700 From: Alain Durand Subject: Re: 3gpp-analysis-04: DNS guidelines In-reply-to: To: Pekka Savola Cc: v6ops@ops.ietf.org Message-id: <22DDF45D-BD2A-11D7-8681-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-29.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Wednesday, July 23, 2003, at 03:22 AM, Pekka Savola wrote: > Hi, > > This is the second issue of today. (I'm using an accelerated cycle > because > I'm leaving for vacation on Friday and want to send all of them out > before > that.) > ---- > > Actually, there are five related issues here regarding DNS guidelines > in > the document. > > * The statement about IPv6-only DNS servers, "every recursive DNS > server > should be either IPv4-only or dual stack", it not entirely accurate. > It > is perfectly OK to have a IPv6-only DNS server which recursively > queries > from _other_ recursive DNS servers. As long as there are dual-stack > recursive DNS servers in the "recursion chain", the rule is fulfilled. > It may be useful to try to reword the text slightly to cover for this > case > too. I think it is mainly a terminology issue. In my vocabulary, what you describe is a forwarder DNS server, not a recursive DNS server... Although, I agree, there is a lot of confusion in the terminology in that area. This will be cleared up in the upcoming revision of draft-ietf-dnsop-ipv6-transport-guidelines-00.txt > > * The analysis only refers to [DNStrans]; it should also refer to > (where > appropriate) draft-ietf-dnsop-ipv6-transport-guidelines-00.txt which is > soon ready for DNSOP last call. The other documents have or will expired, so the only one to refer to now is draft-ietf-dnsop-ipv6-transport-guidelines-00.txt > > * " When thinking the DNS issues, [...]" sounds bad and should be > reworded > (sorry, forgot to add this to the editorial section.) > > * The description in section 3.5 is very terse. The problems here > appear > to be two-fold: > > 1) either 3GPP operator's DNS servers should be dual-stack (to reach > those bogus IPv6-only servers serving the AAAA records), or > > 2) at least one IPv4 DNS server is needed for AAAA records so that the > 3GPP operator's DNS servers are able to get the record. > > The first is not noted, and the for the second, it is not stated that > this > is not the *3GPP operator's* problem, but guy's who is serving AAAA > records. If we wants to break the operational practices for robust > DNS, > there is no way we can stop him.. > > * the description of DNS issues is spread throughout the document. > Perhaps we should reword the section "2. Transition mechanisms" to "2. > Transition mechanisms and considerations" and add a subsection on DNS, > where we could move e.g. text in section 3.1 and the first paragraph of > 4.1, and only give pointers and discussion specific to GPRS/IMS > scenarios > under those scenarios. > > ----- > 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes > [...] > Keeping the Internet name space unfragmented is another important > issue for both IPv4 and IPv6. It means that any record in the > public Internet should be available unmodified to any nodes, IPv4 > or IPv6, regardless of the transport being used. The recommended > approach is the following: every recursive DNS server should be > either IPv4-only or dual stack and every single DNS zone should be > served by at least an IPv4 reachable DNS server. This > recommendation rules out IPv6-only recursive DNS servers and DNS > zones served by IPv6-only DNS servers, and this approach could be > revisited if translation techniques between IPv4 and IPv6 were to > be widely deployed [DNStrans]. ==> this is where draft-ietf-dnsop-ipv6-transport-guidelines-00.txt should be mentioned and the entire text should be deleted in this section. > > 3.4 IPv6 UE Connecting to an IPv4 Node > [...] > When thinking the DNS issues, the IPv6 UE needs to find the IPv4 > address in the DNS [DNStrans]. Note that DNSSEC is broken if > NA(P)T-PT is used. > > 3.5 IPv4 UE Connecting to an IPv6 Node > [...] > When thinking the DNS issues, the DNS zones containing AAAA records > for the IPv6 nodes need to be served by at least one IPv4 > accessible DNS server [DNStrans]. > > 4.1 DNS Interworking in IMS > > The recommended approach (as documented in [DNStrans]) currently is > that every recursive DNS server should be either IPv4-only or dual > stack and every single DNS zone should be served by at least an > IPv4 reachable DNS server. The recommendation rules out IPv6-only > recursive DNS servers and DNS zones served by IPv6-only DNS > servers. Same comment here. > > To perform DNS resolution in the IMS, the UE can be configured as a > stub resolver pointing to a recursive DNS resolver. This > communication can happen over IPv6. However, in the process to find > the IPv6 address of a SIP server, the recursive DNS resolver may > need to access data that is available only on some IPv4 DNS > servers, see [DNStrans]. One way to achieve this is to make the DNS > resolver be dual stack. As DNS traffic is not directly related to > the IMS functionality, this is not in contradiction with the IPv6- > only nature of the IMS. same here. The only thing to say is that 3GPP DNS recursive server MUST be dual stack according to draft-ietf-dnsop-ipv6-transport-guidelines-00.txt. - Alain. From owner-v6ops@ops.ietf.org Thu Jul 24 03:21:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27166 for ; Thu, 24 Jul 2003 03:21:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19faNl-000564-A7 for v6ops-data@psg.com; Thu, 24 Jul 2003 07:19:21 +0000 Received: from [194.196.100.235] (helo=d12lmsgate-2.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19faNg-00054p-NG for v6ops@ops.ietf.org; Thu, 24 Jul 2003 07:19:16 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6O7IX9d132608; Thu, 24 Jul 2003 09:18:35 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6O7ITcH256386; Thu, 24 Jul 2003 09:18:30 +0200 Received: from hursley.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA54572; Thu, 24 Jul 2003 09:18:29 +0200 Message-ID: <3F1F8849.F81C410@hursley.ibm.com> Date: Thu, 24 Jul 2003 09:18:33 +0200 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: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-04: The use of 6to4 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 6to4 was designed as a technique to ride over the networks of ISPs who don't support IPv6 natively, so I have to agree with Pekka *except* perhaps in the case of a 3G operator who decides not support IPv6 (such operators are rumoured to exist). In that case, host-based 6to4 might just have some applicability, but the scenario would need to be described very precisely. Brian -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NOTE: My email will soon change to brc@zurich.ibm.com Try that if you get failure messages. Pekka Savola wrote: > > The first issue of today. > > --8<-- > > In the document, the use of 6to4 is mentioned several times. However, > this method needs some scoping: IMHO, it is clear that 6to4 is not a > useful approach for ISP-like networks, so it is not useful to recommend > that 3GPP networks use it for example for Internet connectivity. It is > just so much easier to get a configured tunnel or native IPv6 from the > upstream providers. You just can't build a service like 3GPP networks > intend to using 6to4; for some internal piloting, etc. it may be possible, > yes, but that's mostly outside of the scope of the document (but could be > mentioned for completeness if enough folks feel like it). > > The text in the document is already healthily skeptical of 6to4's > usefulness in this context, but I fail to see: > > - clear need for the existance of 6to4 here at all, and > - sufficiently clear disclaimers why 6to4 is *NOT* the right solution for > 3GPP networks. > > Note: this issue does not specifically address the document's suggestion > to use 6to4 in the UE's, independent of the 3GPP operator. That'll be > dealt with in the next issues. > > The text snippets below are the important ones: > ----- > 3.2.1 Tunneling inside the 3GPP Operator's Network > [...] > "6to4" nodes use special IPv6 addresses with a "6to4" prefix > containing the IPv4 address of the corresponding "IPv6 in IPv4" > tunnel endpoint ("6to4" router) which performs encapsulation / > decapsulation. When connecting two nodes with "6to4" addresses, the > corresponding "6to4" routers use the IPv4 addresses specified in > the "6to4" prefixes to tunnel IPv6 packets through the IPv4 > network. But if only one of them has a "6to4" address, a "6to4" > relay must be present to perform the missing "6to4" router > functionality for the native-IPv6 node. > > [note: could split to two paragraphs around here, the paragraph is both > the 6to4 introduction and 3GPP application] > > If we consider the "6to4" > tunneling mechanism and the 3GPP addressing model (a unique /64 > prefix allocated for each primary PDP context), a /48 "6to4" prefix > would only be enough for approximately 65000 UEs. Thus, a few > public IPv4 addresses would be needed depending on the size of the > operator. > > 3.2.2 Tunneling outside the 3GPP Operator's Network > [...] > On the other hand, usage of dynamic tunneling, such as "6to4", can > also be considered, but scalability problems arise when thinking > about the great number of UEs in the 3GPP networks. The specific > limitation when applying "6to4" in 3GPP networks should also be > taken into account, as commented in 3.2.1. Other issues to keep in > mind with respect to the "6to4" mechanism are that reverse DNS is > not yet completely solved and there are some security > considerations associated with the use of "6to4" relay routers (see > [6to4SEC]). Moreover, in a later phase of the transition period, > there will be a need for assigning new, native IPv6 addresses to > all "6to4" nodes in order to enable native IPv6 connectivity. > ----- > > At least, add a new paragraph at the end of 3.2.2: > > In consequence, the use of 6to4 to enable IPv6 connectivity to a part > or parts of the 3GPP network is strongly discouraged; configured > tunneling or preferably native IPv6 connectivity is preferred. > > The end of the paragraph of 3.2.1 is also confusing things: tunneling > inside the operator's network ("replacement for BGP tunneling"; as > described in section 2.4.3 of draft-savola-v6ops-6to4-security-02.txt but > IMHO a bit bad practice) -- and addressing the needs of the 3GPP UE's > (pun intended). If you want to only use 6to4 internally, you can't deploy > 6to4 addresses on the UE's. If you wan to use it externally, the > considerations in the next section step out. > > So, I think at least the end of the last paragraph of section 3.2.1 should > be removed/reworded. > > I also fail to see a strict need for the 6to4 introduction (the first part > of the paragraph in 3.2.1) here, at least at this point. > > -- > 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 Jul 24 04:02: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 EAA28073 for ; Thu, 24 Jul 2003 04:02:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fb2l-0007Pv-Sl for v6ops-data@psg.com; Thu, 24 Jul 2003 08:01:43 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fb2i-0007Pa-Cq for v6ops@ops.ietf.org; Thu, 24 Jul 2003 08:01:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6O81cd31530 for ; Thu, 24 Jul 2003 11:01:38 +0300 Date: Thu, 24 Jul 2003 11:01:37 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is a slightly related point to "The use of 6to4" issue raised yesterday. Section 3.1 goes and analyzes the case where the 3GPP network does not provide IPv6 support at great length. I strongly believe that: 1) we *MUST NOT* require or recommend the implementation of any automatic tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We SHOULD NOT require or recommend the implement configured tunneling on UE's (but I can be convinced otherwise). 2) The use of ISATAP is misguided in this space: it's only useful if the 3GPP operator supports IPv6 (i.e. provides the ISATAP routers and other infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, etc. This seems in direct conflict with 3GPP goals. 3) we should be able to assume that unless the 3GPP operator where the user buys his service doesn't support IPv6, the user cannot use IPv6 on his gadget. On the other hand, if the particular GGSN the user is connected using IPv4 supports only IPv4, there is nothing stopping the user from using some other GGSN for IPv6 support. That is, as long as the 3GPP operator has basically one IPv6-aware GGSN, SGSN and HLR, IPv6 users are happy. The reasons for these points are mainly: - The number of UE's is expected to be very high, - The implementation footprint of UE's is expected to be very small, so any extra code is difficult to justify, - The upgradeability of UE's is poor, and we may not be able to retire such mechanisms, - We're concerned about 3GPP *deployment* not early trials or piloting - There is a significant pressure for 3GPP operators to do IPv6 properly, and we should rather work on getting on with *real* IPv6 deployment than fiddling around with transition mechanisms in this space. Of course, if the UE implements something like 6to4, there's nothing to stop them. Just we shouldn't advocate that.. This, I'd suggest major reworking of the parts of the section 3.1. ===8<==== 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes [...] However, the UE may attach to a 3GPP network, in which the SGSN (Serving GPRS Support Node), the GGSN and the HLR (Home Location Register) support IPv4 PDP contexts by default, but may not support IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP contexts, and an application on the UE needs to communicate with an IPv6(-only) node, the UE may activate an IPv4 PDP context and encapsulate IPv6 packets in IPv4 packets using a tunneling mechanism. This might happen in very early phases of IPv6 deployment, or in IPv6 demonstrations and trials. The UE may be assigned a private or public IPv4 address when the IPv4 PDP context has been activated, although it is more likely that it will receive a private address (due to the lack of public IPv4 addresses). The use of private IPv4 addresses in the UE depends on the support of these addresses by the tunneling mechanism and the deployment scenario. In some cases, public IPv4 addresses are required (one example is 6to4 [RFC3056]), but if the tunnel endpoints are in the same private domain or the tunneling mechanism works through IPv4 NAT (Network Address Translator), private IPv4 addresses can be used (examples are [ISATAP] and [TEREDO]). In general, if tunneling from the host is needed, ISATAP and 6to4 are preferred and TEREDO is a mechanism of last resort when neither of these are applicable. One deployment scenario example is using laptop computer and a UMTS UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the laptop computer and an IPv4 PDP context is activated. Although "IPv6 in IPv4" tunneling can be either automatic or configured (by the user), the first alternative is favored, because it is expected that most UE users just want to use an application in their UE; they might not even care, whether the network connection is IPv4 or IPv6. [...] 3.2.2 Tunneling outside the 3GPP Operator's Network [...] On the other hand, usage of dynamic tunneling, such as "6to4", can also be considered, but scalability problems arise when thinking about the great number of UEs in the 3GPP networks. The specific limitation when applying "6to4" in 3GPP networks should also be taken into account, as commented in 3.2.1. Other issues to keep in mind with respect to the "6to4" mechanism are that reverse DNS is not yet completely solved and there are some security considerations associated with the use of "6to4" relay routers (see [6to4SEC]). Moreover, in a later phase of the transition period, there will be a need for assigning new, native IPv6 addresses to all "6to4" nodes in order to enable native IPv6 connectivity. -- 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 Jul 24 04:23: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 EAA28568 for ; Thu, 24 Jul 2003 04:23:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fbMd-0008Sk-6f for v6ops-data@psg.com; Thu, 24 Jul 2003 08:22:15 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fbMZ-0008SW-Rh for v6ops@ops.ietf.org; Thu, 24 Jul 2003 08:22:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6O8MAn31706 for ; Thu, 24 Jul 2003 11:22:10 +0300 Date: Thu, 24 Jul 2003 11:22:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: tunnels out of 3GPP operator's network Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, In section 3.2.2, "Tunneling outside the 3GPP Operator's Network", describes the case where the 3GPP operator has to obtain Internet connectivity through a tunnel. My concern comes from the second-to-last paragraph: Usage of manually configured "IPv6 in IPv4" tunneling is sensible if the number of the tunnels can be kept limited. It is assumed that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the 3GPP network towards the ISP / Internet should be sufficient. This seems to be mixing issues with tunneling inside the 3GPP operator's network. Why on earth would 3GPP operator have more than 10-15 configured tunnels *out* of its network? This and the last paragraph would seem to indicate some confusion or misunderstanding. I also see little need for the text in the previous paragraph: Defining the tunnel endpoint depends on the deployment scenario. The authors want to avoid duplicating work and note here that the ISP transition scenarios are analyzed in [ISP- scen] and [ISP-analysis]. (How many ways can you define a tunnel end-point??) I'd remove the last paragraph completely (as was already mentioned in some other issue), and reword the two last ones to like: If the ISP only provides IPv4 connectivity, then the IPv6 traffic initiated from the 3GPP network should be transported tunneled in IPv4 to the ISP. Usage of manually configured "IPv6 in IPv4" tunneling is the best approach, as the number of the tunnels outside of the 3GPP network is very limited; no more than a couple of tunnels should be needed. ISP transition scenarios are described in [ISP-scen] and [ISP-analysis]. (or leave the last one out completely; it should already be addresses in at the start of section 3.2) ==== 3.2.2 Tunneling outside the 3GPP Operator's Network This subsection includes the case when the peer node is outside the operator's network. In that case the "IPv6 in IPv4" tunnel starting point can be in the operator's network - encapsulating node can be e.g. the GGSN or the edge router. The case is pretty straightforward if the upstream ISP provides native IPv6 connectivity to the Internet. If there is no native IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4" tunnel should be configured from e.g. the GGSN to the dual stack border gateway in order to access the upstream ISP. If the ISP only provides IPv4 connectivity, then the IPv6 traffic initiated from the 3GPP network should be transported tunneled in IPv4 to the ISP. Defining the tunnel endpoint depends on the deployment scenario. The authors want to avoid duplicating work and note here that the ISP transition scenarios are analyzed in [ISP- scen] and [ISP-analysis]. Usage of manually configured "IPv6 in IPv4" tunneling is sensible if the number of the tunnels can be kept limited. It is assumed that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the 3GPP network towards the ISP / Internet should be sufficient. On the other hand, usage of dynamic tunneling, such as "6to4", can also be considered, but scalability problems arise when thinking about the great number of UEs in the 3GPP networks. The specific limitation when applying "6to4" in 3GPP networks should also be taken into account, as commented in 3.2.1. Other issues to keep in mind with respect to the "6to4" mechanism are that reverse DNS is not yet completely solved and there are some security considerations associated with the use of "6to4" relay routers (see [6to4SEC]). Moreover, in a later phase of the transition period, there will be a need for assigning new, native IPv6 addresses to all "6to4" nodes in order to enable native IPv6 connectivity. -- 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 Jul 24 05:12: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 FAA00021 for ; Thu, 24 Jul 2003 05:12:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fc99-000BEx-Vq for v6ops-data@psg.com; Thu, 24 Jul 2003 09:12:23 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fc95-000BEe-CW for v6ops@ops.ietf.org; Thu, 24 Jul 2003 09:12:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6O9CEg32201 for ; Thu, 24 Jul 2003 12:12:14 +0300 Date: Thu, 24 Jul 2003 12:12:14 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: Need for UE<->3GPP Configuration? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Looking at the document, it is not clear to me how the UE's will be configured. For example, how will they be provisioned with: - the DNS server addresses (search path is a definite non-goal) - addresses of web proxies, and possibly other ALG's - the NTP servers, if needed - other stuff. As far as I know, this part of the 3GPP analysis has been forgotten (however, there is a mention on the requirement for the easy configurability of proxies in the document.). -- 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 Jul 24 08:16: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 IAA03544 for ; Thu, 24 Jul 2003 08:16:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fey0-000KzU-1X for v6ops-data@psg.com; Thu, 24 Jul 2003 12:13:04 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fexw-000Kz5-Qn for v6ops@ops.ietf.org; Thu, 24 Jul 2003 12:13:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6OCCwn01458 for ; Thu, 24 Jul 2003 15:12:58 +0300 Date: Thu, 24 Jul 2003 15:12:58 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Karim's original message was off-list, so this was my response. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Thu, 24 Jul 2003 15:03:57 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > 2) The use of ISATAP is misguided in this space: it's only > > useful if the > > 3GPP operator supports IPv6 (i.e. provides the ISATAP > > routers and other > > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, etc. This > > seems in direct conflict with 3GPP goals. > > It is not in conflict with any 3GPP goals. Note that the 3GPP operator > requires IPv6 for SIP-based IMS but this doc also covers generic access > (which is where we talk about tunnelling). On the contrary it helps > operators to start rolling out IPv6 without having to upgrade everything > all at once. This is an important issue which we have addressed. Also, > when a user roams to a network that does not support IPv6, I take it that by the latter you mean a network under that same 3GPP operator which does not support IPv6? > > 3) we should be able to assume that unless the 3GPP > > operator where the > > user buys his service doesn't support IPv6, the user cannot > > use IPv6 on > > his gadget. On the other hand, if the particular GGSN the user is > > connected using IPv4 supports only IPv4, there is nothing > > stopping the > > user from using some other GGSN for IPv6 support. > > That can't be done. The user doesn't choose GGSNs. > > > That is, > > as long as the > > 3GPP operator has basically one IPv6-aware GGSN, SGSN and > > HLR, IPv6 users > > are happy. > > That is not correct. If you happen to go to the wrong SGSN/GGSN > you just don't get IPv6 service, independently from the fact > that there may be another SGSN/GGSN somewhere else in the > network supporting IPv6. On these two issues, I keep getting mixed signals from different people involved with 3GPP work. Some say it can be done, some say it can't. I think a separate and very clear analysis with refs should be done on that subject. > You have left out the issue that when we're introducing a new > technology nowadays we don't do it all at once but gradually. Dubious 3GPP specs (see above) are a real hindrance to deployment, it seems.. > That means we will have to deal with IPv6 capable mobiles > trying to use IPv6 app.s even in areas where IPv6 native > connectivity is not possible. If we don't consider this case > then we won't be providing a full set of answers to 3GPP. Or 3GPP is making expectations it shouldn't. It may just be that we could say, "if you want to use IPv6, require IPv6". -- 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 Jul 24 08:38: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 IAA04069 for ; Thu, 24 Jul 2003 08:38:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ffLg-000MKo-3v for v6ops-data@psg.com; Thu, 24 Jul 2003 12:37:32 +0000 Received: from [194.196.100.235] (helo=d12lmsgate-2.de.ibm.com) by psg.com with esmtp (Exim 4.14) id 19ffLb-000MKP-Vt for v6ops@ops.ietf.org; Thu, 24 Jul 2003 12:37:28 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6OCac9d229084; Thu, 24 Jul 2003 14:36:47 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6OCZBO9161968; Thu, 24 Jul 2003 14:35:12 +0200 Received: from hursley.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA48346; Thu, 24 Jul 2003 14:35:10 +0200 Message-ID: <3F1FD283.A4BE3DB0@hursley.ibm.com> Date: Thu, 24 Jul 2003 14:35:15 +0200 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: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If UE that normally uses IPv6 roams to a provider that only supports IPv4, some kind of tunnel solution seems inevitable. ISATAP is certainly irrelevant, because the IPv4 provider won't provide ISATAP machinery by definition. So either the home provider will have to offer a tunnel broker or a 6to4 relay for use by its subscribers when they roam on IPv4. I don't think the IETF should worry about whether the UE has enough real estate for this option; that's a vendor choice. I suspect the UE will have less overhead to support 6to4 than to support a tunnel broker protocol. Brian-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NOTE: My email will soon change to brc@zurich.ibm.com Try that if you get failure messages. Pekka Savola wrote: > > Hi, > > This is a slightly related point to "The use of 6to4" issue raised > yesterday. > > Section 3.1 goes and analyzes the case where the 3GPP network does not > provide IPv6 support at great length. > > I strongly believe that: > > 1) we *MUST NOT* require or recommend the implementation of any automatic > tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We SHOULD NOT > require or recommend the implement configured tunneling on UE's (but I can > be convinced otherwise). > > 2) The use of ISATAP is misguided in this space: it's only useful if the > 3GPP operator supports IPv6 (i.e. provides the ISATAP routers and other > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, etc. This > seems in direct conflict with 3GPP goals. > > 3) we should be able to assume that unless the 3GPP operator where the > user buys his service doesn't support IPv6, the user cannot use IPv6 on > his gadget. On the other hand, if the particular GGSN the user is > connected using IPv4 supports only IPv4, there is nothing stopping the > user from using some other GGSN for IPv6 support. That is, as long as the > 3GPP operator has basically one IPv6-aware GGSN, SGSN and HLR, IPv6 users > are happy. > > The reasons for these points are mainly: > > - The number of UE's is expected to be very high, > - The implementation footprint of UE's is expected to be very small, so > any extra code is difficult to justify, > - The upgradeability of UE's is poor, and we may not be able to retire > such mechanisms, > - We're concerned about 3GPP *deployment* not early trials or piloting > - There is a significant pressure for 3GPP operators to do IPv6 properly, > and we should rather work on getting on with *real* IPv6 deployment than > fiddling around with transition mechanisms in this space. > > Of course, if the UE implements something like 6to4, there's nothing to > stop them. Just we shouldn't advocate that.. > > This, I'd suggest major reworking of the parts of the section 3.1. > > ===8<==== > 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes > [...] > However, the UE may attach to a 3GPP network, in which the SGSN > (Serving GPRS Support Node), the GGSN and the HLR (Home Location > Register) support IPv4 PDP contexts by default, but may not support > IPv6 PDP contexts. If the 3GPP network does not support IPv6 PDP > contexts, and an application on the UE needs to communicate with an > IPv6(-only) node, the UE may activate an IPv4 PDP context and > encapsulate IPv6 packets in IPv4 packets using a tunneling > mechanism. This might happen in very early phases of IPv6 > deployment, or in IPv6 demonstrations and trials. > > The UE may be assigned a private or public IPv4 address when the > IPv4 PDP context has been activated, although it is more likely > that it will receive a private address (due to the lack of public > IPv4 addresses). The use of private IPv4 addresses in the UE > depends on the support of these addresses by the tunneling > mechanism and the deployment scenario. In some cases, public IPv4 > addresses are required (one example is 6to4 [RFC3056]), but if the > tunnel endpoints are in the same private domain or the tunneling > mechanism works through IPv4 NAT (Network Address Translator), > private IPv4 addresses can be used (examples are [ISATAP] and > [TEREDO]). In general, if tunneling from the host is needed, ISATAP > and 6to4 are preferred and TEREDO is a mechanism of last resort > when neither of these are applicable. > > One deployment scenario example is using laptop computer and a UMTS > UE as a modem. IPv6 packets are encapsulated in IPv4 packets in the > laptop computer and an IPv4 PDP context is activated. Although > "IPv6 in IPv4" tunneling can be either automatic or configured (by > the user), the first alternative is favored, because it is expected > that most UE users just want to use an application in their UE; > they might not even care, whether the network connection is IPv4 or > IPv6. > [...] > > 3.2.2 Tunneling outside the 3GPP Operator's Network > [...] > On the other hand, usage of dynamic tunneling, such as "6to4", can > also be considered, but scalability problems arise when thinking > about the great number of UEs in the 3GPP networks. The specific > limitation when applying "6to4" in 3GPP networks should also be > taken into account, as commented in 3.2.1. Other issues to keep in > mind with respect to the "6to4" mechanism are that reverse DNS is > not yet completely solved and there are some security > considerations associated with the use of "6to4" relay routers (see > [6to4SEC]). Moreover, in a later phase of the transition period, > there will be a need for assigning new, native IPv6 addresses to > all "6to4" nodes in order to enable native IPv6 connectivity. > > -- > 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 Jul 24 09:20: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 JAA05267 for ; Thu, 24 Jul 2003 09:20:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fg01-000OwX-QJ for v6ops-data@psg.com; Thu, 24 Jul 2003 13:19:13 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19ffzx-000Ow7-AN for v6ops@ops.ietf.org; Thu, 24 Jul 2003 13:19:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6ODJ5w02183; Thu, 24 Jul 2003 16:19:05 +0300 Date: Thu, 24 Jul 2003 16:19:04 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: "'Brian E Carpenter'" , Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28BDC@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > You're assuming that roaming is done at L3. Roaming is normally > done at L2 so for example ISATAP is a relevant option. (I think you should elaborate on "normally") OK. If roaming is done at L2, then IP addresses etc. should stay the same when you roam, right? Then IPv6 addresses will stay too, right? So, why do you need ISATAP there then? > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: den 24 juli 2003 14:35 > > To: Pekka Savola > > Cc: v6ops@ops.ietf.org > > Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs; > > 3GPP IPv6 > > deployment > > > > > > If UE that normally uses IPv6 roams to a provider that only supports > > IPv4, some kind of tunnel solution seems inevitable. ISATAP is > > certainly irrelevant, because the IPv4 provider won't provide > > ISATAP machinery by definition. So either the home provider will > > have to offer a tunnel broker or a 6to4 relay for use by its > > subscribers when they roam on IPv4. I don't think the IETF > > should worry about whether the UE has enough real estate for > > this option; that's a vendor choice. > > > > I suspect the UE will have less overhead to support 6to4 than > > to support a tunnel broker protocol. > > > > Brian-- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > > > > NOTE: My email will soon change to brc@zurich.ibm.com > > Try that if you get failure messages. > > > > Pekka Savola wrote: > > > > > > Hi, > > > > > > This is a slightly related point to "The use of 6to4" issue raised > > > yesterday. > > > > > > Section 3.1 goes and analyzes the case where the 3GPP > > network does not > > > provide IPv6 support at great length. > > > > > > I strongly believe that: > > > > > > 1) we *MUST NOT* require or recommend the implementation > > of any automatic > > > tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We > > SHOULD NOT > > > require or recommend the implement configured tunneling on > > UE's (but I can > > > be convinced otherwise). > > > > > > 2) The use of ISATAP is misguided in this space: it's > > only useful if the > > > 3GPP operator supports IPv6 (i.e. provides the ISATAP > > routers and other > > > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, > > etc. This > > > seems in direct conflict with 3GPP goals. > > > > > > 3) we should be able to assume that unless the 3GPP > > operator where the > > > user buys his service doesn't support IPv6, the user > > cannot use IPv6 on > > > his gadget. On the other hand, if the particular GGSN the user is > > > connected using IPv4 supports only IPv4, there is nothing > > stopping the > > > user from using some other GGSN for IPv6 support. That > > is, as long as the > > > 3GPP operator has basically one IPv6-aware GGSN, SGSN and > > HLR, IPv6 users > > > are happy. > > > > > > The reasons for these points are mainly: > > > > > > - The number of UE's is expected to be very high, > > > - The implementation footprint of UE's is expected to be > > very small, so > > > any extra code is difficult to justify, > > > - The upgradeability of UE's is poor, and we may not be > > able to retire > > > such mechanisms, > > > - We're concerned about 3GPP *deployment* not early > > trials or piloting > > > - There is a significant pressure for 3GPP operators to > > do IPv6 properly, > > > and we should rather work on getting on with *real* IPv6 > > deployment than > > > fiddling around with transition mechanisms in this space. > > > > > > Of course, if the UE implements something like 6to4, > > there's nothing to > > > stop them. Just we shouldn't advocate that.. > > > > > > This, I'd suggest major reworking of the parts of the section 3.1. > > > > > > ===8<==== > > > 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes > > > [...] > > > However, the UE may attach to a 3GPP network, in which the SGSN > > > (Serving GPRS Support Node), the GGSN and the HLR > > (Home Location > > > Register) support IPv4 PDP contexts by default, but > > may not support > > > IPv6 PDP contexts. If the 3GPP network does not > > support IPv6 PDP > > > contexts, and an application on the UE needs to > > communicate with an > > > IPv6(-only) node, the UE may activate an IPv4 PDP context and > > > encapsulate IPv6 packets in IPv4 packets using a tunneling > > > mechanism. This might happen in very early phases of IPv6 > > > deployment, or in IPv6 demonstrations and trials. > > > > > > The UE may be assigned a private or public IPv4 > > address when the > > > IPv4 PDP context has been activated, although it is more likely > > > that it will receive a private address (due to the > > lack of public > > > IPv4 addresses). The use of private IPv4 addresses in the UE > > > depends on the support of these addresses by the tunneling > > > mechanism and the deployment scenario. In some cases, > > public IPv4 > > > addresses are required (one example is 6to4 > > [RFC3056]), but if the > > > tunnel endpoints are in the same private domain or the > > tunneling > > > mechanism works through IPv4 NAT (Network Address Translator), > > > private IPv4 addresses can be used (examples are [ISATAP] and > > > [TEREDO]). In general, if tunneling from the host is > > needed, ISATAP > > > and 6to4 are preferred and TEREDO is a mechanism of last resort > > > when neither of these are applicable. > > > > > > One deployment scenario example is using laptop > > computer and a UMTS > > > UE as a modem. IPv6 packets are encapsulated in IPv4 > > packets in the > > > laptop computer and an IPv4 PDP context is activated. Although > > > "IPv6 in IPv4" tunneling can be either automatic or > > configured (by > > > the user), the first alternative is favored, because > > it is expected > > > that most UE users just want to use an application in their UE; > > > they might not even care, whether the network > > connection is IPv4 or > > > IPv6. > > > [...] > > > > > > 3.2.2 Tunneling outside the 3GPP Operator's Network > > > [...] > > > On the other hand, usage of dynamic tunneling, such as > > "6to4", can > > > also be considered, but scalability problems arise > > when thinking > > > about the great number of UEs in the 3GPP networks. > > The specific > > > limitation when applying "6to4" in 3GPP networks should also be > > > taken into account, as commented in 3.2.1. Other > > issues to keep in > > > mind with respect to the "6to4" mechanism are that > > reverse DNS is > > > not yet completely solved and there are some security > > > considerations associated with the use of "6to4" relay > > routers (see > > > [6to4SEC]). Moreover, in a later phase of the > > transition period, > > > there will be a need for assigning new, native IPv6 > > addresses to > > > all "6to4" nodes in order to enable native IPv6 connectivity. > > > > > > -- > > > Pekka Savola "You each name yourselves > > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A > > Clash of Kings > > > -- 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 Jul 24 09:41: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 JAA05953 for ; Thu, 24 Jul 2003 09:41:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fgLN-0000ID-K2 for v6ops-data@psg.com; Thu, 24 Jul 2003 13:41:17 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fgLJ-0000Hs-96 for v6ops@ops.ietf.org; Thu, 24 Jul 2003 13:41:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6ODfA902498; Thu, 24 Jul 2003 16:41:10 +0300 Date: Thu, 24 Jul 2003 16:41:09 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment (fwd) In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28BDD@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > > 2) The use of ISATAP is misguided in this space: it's only > > > > useful if the > > > > 3GPP operator supports IPv6 (i.e. provides the ISATAP > > > > routers and other > > > > infrastructure) but doesn't just have IPv6 SGSN's, > > GGSN's, etc. This > > > > seems in direct conflict with 3GPP goals. > > > > > > It is not in conflict with any 3GPP goals. Note that the > > 3GPP operator > > > requires IPv6 for SIP-based IMS but this doc also covers > > generic access > > > (which is where we talk about tunnelling). On the contrary it helps > > > operators to start rolling out IPv6 without having to > > upgrade everything > > > all at once. This is an important issue which we have > > addressed. Also, > > > when a user roams to a network that does not support IPv6, > > > > I take it that by the latter you mean a network under that same 3GPP > > operator which does not support IPv6? > > Both a separate operator and a portion of the network (e.g. SGSN). Ok, see the other thread with Brian C. > > > > 3) we should be able to assume that unless the 3GPP > > > > operator where the > > > > user buys his service doesn't support IPv6, the user cannot > > > > use IPv6 on > > > > his gadget. On the other hand, if the particular GGSN > > the user is > > > > connected using IPv4 supports only IPv4, there is nothing > > > > stopping the > > > > user from using some other GGSN for IPv6 support. > > > > > > That can't be done. The user doesn't choose GGSNs. > > > > > > > That is, > > > > as long as the > > > > 3GPP operator has basically one IPv6-aware GGSN, SGSN and > > > > HLR, IPv6 users > > > > are happy. > > > > > > That is not correct. If you happen to go to the wrong SGSN/GGSN > > > you just don't get IPv6 service, independently from the fact > > > that there may be another SGSN/GGSN somewhere else in the > > > network supporting IPv6. > > > > On these two issues, I keep getting mixed signals from > > different people > > involved with 3GPP work. Some say it can be done, some say it can't. > > I can't remember seeing emails on this list saying the opposite, > but if anyone has corrections to make please feel free. I've talked with a few people in Nokia and they seem to have said so. Of course, I know close to nothing of 3GPP, so they might have misunderstood my questions or I might have misunderstood their answers. > > > You have left out the issue that when we're introducing a new > > > technology nowadays we don't do it all at once but gradually. > > > > Dubious 3GPP specs (see above) are a real hindrance to > > deployment, it > > seems.. > > I'd say "interpretations" are a hindrance as with all non-IETF specs > which get discussed in IETF. I agree. And where do those interpretations stem from? Lack the IETF understanding non-IETF specs and the lack of non-IETF people understanding IETF specs. Let's look at the former. I don't know whether it is the responsibility of the IETF reader to educate himself with non-IETF specs, or the responsibility of the people discussing non-IETF specs in the IETF context to educate IETF folks. There are probably different opinions on this, but as 3GPP comes to the IETF, my personal feeling is that it is the latter. (I.e. to provide enough context of 3GPP so that IETF folks can make reasonable decisions.) > I think the design team has the right competence to address these issues > and we didn't have major disagreement. You misunderstand the role of the design team. The design team is to address issues, yes, but all its decisions are brought to the working group, and the most importantly, all those decisions must be justified -- and the working group has to feel good with them. There may be good reasons for decisions made in the process, but at least all of them do not appear to be apparent. Design team is a brain-storming activity to cook up proposals for the WG. WG then decides what to do with those proposals based on how it feels about them. From RFC2418: 6.5. Design teams It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole. > > > That means we will have to deal with IPv6 capable mobiles > > > trying to use IPv6 app.s even in areas where IPv6 native > > > connectivity is not possible. If we don't consider this case > > > then we won't be providing a full set of answers to 3GPP. > > > > Or 3GPP is making expectations it shouldn't. It may just be > > that we could > > say, "if you want to use IPv6, require IPv6". > > We could apply the same reasoning to fixed ISPs but I'm not sure > this method (overnight upgrade of full live network) works for > everyone. There is a reason why we have "3GPP scenarios", "ISP scenarios" and "Unmanaged scenarios" are separate (I'm assuming here that 3GPP doesn't overlap with Enterprise :-): it is assumed that 3GPP is *different* in some respect, and has some unique characteristics. Of course, different people's assumptions on _what_ those unique characteristics are may be different (which may be causing misunderstandings). My assumptions include for example: - large number of UE's (at least after the kickoff) - very plain & simple UE's (IPv6 implementation-wise) - strong network support for IPv6 ("IMS is exclusively IPv6" etc.) - others -- 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 Jul 24 09:59:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06573 for ; Thu, 24 Jul 2003 09:59:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fgcK-0001Th-1D for v6ops-data@psg.com; Thu, 24 Jul 2003 13:58:48 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19fgcG-0001TL-T9 for v6ops@ops.ietf.org; Thu, 24 Jul 2003 13:58:45 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19fgcG-000KKZ-6L for v6ops@ops.ietf.org; Thu, 24 Jul 2003 06:58:44 -0700 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28BD8@ESEALNT442.al.sw.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment Date: Thu, 24 Jul 2003 13:24:38 +0200 X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi Some comments on the tunnelling issues below. > This is a slightly related point to "The use of 6to4" issue raised > yesterday. > > Section 3.1 goes and analyzes the case where the 3GPP > network does not > provide IPv6 support at great length. > > I strongly believe that: > > 1) we *MUST NOT* require or recommend the implementation of > any automatic > tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We > SHOULD NOT > require or recommend the implement configured tunneling on > UE's (but I can > be convinced otherwise). We are not mandating tunnelling for generic cases. However we analysed each scenario and where it made sense we recommended certain mechanisms such as tunnelling. Tunnelling is not a generic solution for all our problems and we are not claiming that. > 2) The use of ISATAP is misguided in this space: it's only > useful if the > 3GPP operator supports IPv6 (i.e. provides the ISATAP > routers and other > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, etc. This > seems in direct conflict with 3GPP goals. It is not in conflict with any 3GPP goals. Note that the 3GPP operator requires IPv6 for SIP-based IMS but this doc also covers generic access (which is where we talk about tunnelling). On the contrary it helps operators to start rolling out IPv6 without having to upgrade everything all at once. This is an important issue which we have addressed. Also, when a user roams to a network that does not support IPv6, the use of ISATAP can allow access to IPv6 app.s. It is obvious that in the long run native IPv6 access is the way to go. If that helps we can make this more explicit. > > 3) we should be able to assume that unless the 3GPP > operator where the > user buys his service doesn't support IPv6, the user cannot > use IPv6 on > his gadget. On the other hand, if the particular GGSN the user is > connected using IPv4 supports only IPv4, there is nothing > stopping the > user from using some other GGSN for IPv6 support. That can't be done. The user doesn't choose GGSNs. > That is, > as long as the > 3GPP operator has basically one IPv6-aware GGSN, SGSN and > HLR, IPv6 users > are happy. That is not correct. If you happen to go to the wrong SGSN/GGSN you just don't get IPv6 service, independently from the fact that there may be another SGSN/GGSN somewhere else in the network supporting IPv6. > > The reasons for these points are mainly: > > - The number of UE's is expected to be very high, > - The implementation footprint of UE's is expected to be > very small, so > any extra code is difficult to justify, > - The upgradeability of UE's is poor, and we may not be > able to retire > such mechanisms, > - We're concerned about 3GPP *deployment* not early trials > or piloting > - There is a significant pressure for 3GPP operators to do > IPv6 properly, > and we should rather work on getting on with *real* IPv6 > deployment than > fiddling around with transition mechanisms in this space. > > Of course, if the UE implements something like 6to4, there's > nothing to > stop them. Just we shouldn't advocate that.. You have left out the issue that when we're introducing a new technology nowadays we don't do it all at once but gradually. That means we will have to deal with IPv6 capable mobiles trying to use IPv6 app.s even in areas where IPv6 native connectivity is not possible. If we don't consider this case then we won't be providing a full set of answers to 3GPP. /Karim From owner-v6ops@ops.ietf.org Thu Jul 24 10:01: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 KAA06692 for ; Thu, 24 Jul 2003 10:01:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fgeY-0001hX-Fs for v6ops-data@psg.com; Thu, 24 Jul 2003 14:01:06 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.14) id 19fgeV-0001hH-4i for v6ops@ops.ietf.org; Thu, 24 Jul 2003 14:01:03 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19fgeU-000KOb-OF for v6ops@ops.ietf.org; Thu, 24 Jul 2003 07:01:02 -0700 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28BDC@ESEALNT442.al.sw.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: "Karim El-Malki (HF/EAB)" To: "'Brian E Carpenter'" , Pekka Savola Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment Date: Thu, 24 Jul 2003 14:46:23 +0200 X-Spam-Status: No, hits=-6.4 required=5.0 tests=BAYES_00 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ 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. ] You're assuming that roaming is done at L3. Roaming is normally done at L2 so for example ISATAP is a relevant option. /Karim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: den 24 juli 2003 14:35 > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs; > 3GPP IPv6 > deployment > > > If UE that normally uses IPv6 roams to a provider that only supports > IPv4, some kind of tunnel solution seems inevitable. ISATAP is > certainly irrelevant, because the IPv4 provider won't provide > ISATAP machinery by definition. So either the home provider will > have to offer a tunnel broker or a 6to4 relay for use by its > subscribers when they roam on IPv4. I don't think the IETF > should worry about whether the UE has enough real estate for > this option; that's a vendor choice. > > I suspect the UE will have less overhead to support 6to4 than > to support a tunnel broker protocol. > > Brian-- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > NOTE: My email will soon change to brc@zurich.ibm.com > Try that if you get failure messages. > > Pekka Savola wrote: > > > > Hi, > > > > This is a slightly related point to "The use of 6to4" issue raised > > yesterday. > > > > Section 3.1 goes and analyzes the case where the 3GPP > network does not > > provide IPv6 support at great length. > > > > I strongly believe that: > > > > 1) we *MUST NOT* require or recommend the implementation > of any automatic > > tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We > SHOULD NOT > > require or recommend the implement configured tunneling on > UE's (but I can > > be convinced otherwise). > > > > 2) The use of ISATAP is misguided in this space: it's > only useful if the > > 3GPP operator supports IPv6 (i.e. provides the ISATAP > routers and other > > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, > etc. This > > seems in direct conflict with 3GPP goals. > > > > 3) we should be able to assume that unless the 3GPP > operator where the > > user buys his service doesn't support IPv6, the user > cannot use IPv6 on > > his gadget. On the other hand, if the particular GGSN the user is > > connected using IPv4 supports only IPv4, there is nothing > stopping the > > user from using some other GGSN for IPv6 support. That > is, as long as the > > 3GPP operator has basically one IPv6-aware GGSN, SGSN and > HLR, IPv6 users > > are happy. > > > > The reasons for these points are mainly: > > > > - The number of UE's is expected to be very high, > > - The implementation footprint of UE's is expected to be > very small, so > > any extra code is difficult to justify, > > - The upgradeability of UE's is poor, and we may not be > able to retire > > such mechanisms, > > - We're concerned about 3GPP *deployment* not early > trials or piloting > > - There is a significant pressure for 3GPP operators to > do IPv6 properly, > > and we should rather work on getting on with *real* IPv6 > deployment than > > fiddling around with transition mechanisms in this space. > > > > Of course, if the UE implements something like 6to4, > there's nothing to > > stop them. Just we shouldn't advocate that.. > > > > This, I'd suggest major reworking of the parts of the section 3.1. > > > > ===8<==== > > 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes > > [...] > > However, the UE may attach to a 3GPP network, in which the SGSN > > (Serving GPRS Support Node), the GGSN and the HLR > (Home Location > > Register) support IPv4 PDP contexts by default, but > may not support > > IPv6 PDP contexts. If the 3GPP network does not > support IPv6 PDP > > contexts, and an application on the UE needs to > communicate with an > > IPv6(-only) node, the UE may activate an IPv4 PDP context and > > encapsulate IPv6 packets in IPv4 packets using a tunneling > > mechanism. This might happen in very early phases of IPv6 > > deployment, or in IPv6 demonstrations and trials. > > > > The UE may be assigned a private or public IPv4 > address when the > > IPv4 PDP context has been activated, although it is more likely > > that it will receive a private address (due to the > lack of public > > IPv4 addresses). The use of private IPv4 addresses in the UE > > depends on the support of these addresses by the tunneling > > mechanism and the deployment scenario. In some cases, > public IPv4 > > addresses are required (one example is 6to4 > [RFC3056]), but if the > > tunnel endpoints are in the same private domain or the > tunneling > > mechanism works through IPv4 NAT (Network Address Translator), > > private IPv4 addresses can be used (examples are [ISATAP] and > > [TEREDO]). In general, if tunneling from the host is > needed, ISATAP > > and 6to4 are preferred and TEREDO is a mechanism of last resort > > when neither of these are applicable. > > > > One deployment scenario example is using laptop > computer and a UMTS > > UE as a modem. IPv6 packets are encapsulated in IPv4 > packets in the > > laptop computer and an IPv4 PDP context is activated. Although > > "IPv6 in IPv4" tunneling can be either automatic or > configured (by > > the user), the first alternative is favored, because > it is expected > > that most UE users just want to use an application in their UE; > > they might not even care, whether the network > connection is IPv4 or > > IPv6. > > [...] > > > > 3.2.2 Tunneling outside the 3GPP Operator's Network > > [...] > > On the other hand, usage of dynamic tunneling, such as > "6to4", can > > also be considered, but scalability problems arise > when thinking > > about the great number of UEs in the 3GPP networks. > The specific > > limitation when applying "6to4" in 3GPP networks should also be > > taken into account, as commented in 3.2.1. Other > issues to keep in > > mind with respect to the "6to4" mechanism are that > reverse DNS is > > not yet completely solved and there are some security > > considerations associated with the use of "6to4" relay > routers (see > > [6to4SEC]). Moreover, in a later phase of the > transition period, > > there will be a need for assigning new, native IPv6 > addresses to > > all "6to4" nodes in order to enable native IPv6 connectivity. > > > > -- > > 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 Jul 24 10:28: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 KAA08892 for ; Thu, 24 Jul 2003 10:28:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fh3Z-0003JI-SL for v6ops-data@psg.com; Thu, 24 Jul 2003 14:26:57 +0000 Received: from [193.180.251.49] (helo=albatross.tn.sw.ericsson.se) by psg.com with esmtp (Exim 4.14) id 19fh3X-0003J5-7Q for v6ops@ops.ietf.org; Thu, 24 Jul 2003 14:26:55 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6OEQYG6014892; Thu, 24 Jul 2003 16:26:34 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Jul 2003 16:26:34 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28BE1@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: "'Brian E Carpenter'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment Date: Thu, 24 Jul 2003 16:26:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_01,MSG_ID_ADDED_BY_MTA_3 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > You're assuming that roaming is done at L3. Roaming is normally > > done at L2 so for example ISATAP is a relevant option. > > (I think you should elaborate on "normally") According to the 3gpp standard. > > OK. If roaming is done at L2, then IP addresses etc. should > stay the same > when you roam, right? Then IPv6 addresses will stay too, > right? So, why > do you need ISATAP there then? Imagine a situation in which you're roaming to another operator's network. The roaming user requests v6 connectivity (PDP Context) in the new network. If the new network doesn't support it, the roaming user won't get v6 connectivity. The PDP Context is a special L2 as described in RFC 3314. /Karim From owner-v6ops@ops.ietf.org Thu Jul 24 11:23: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 LAA10896 for ; Thu, 24 Jul 2003 11:23:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fhvq-0006P5-MZ for v6ops-data@psg.com; Thu, 24 Jul 2003 15:23:02 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19fhvn-0006NB-Vk for v6ops@ops.ietf.org; Thu, 24 Jul 2003 15:22:59 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 08:22:29 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jul 2003 08:22:29 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 08:22:39 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 08:22:23 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 08:22:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment Date: Thu, 24 Jul 2003 08:19:55 -0700 Message-ID: Thread-Topic: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment Thread-Index: AcNR4fEtUYbq7uYET3+6hiZ2wh5uQgAFCJUQ From: "Christian Huitema" To: "Brian E Carpenter" , "Pekka Savola" Cc: X-OriginalArrivalTime: 24 Jul 2003 15:22:22.0534 (UTC) FILETIME=[6128C660:01C351F7] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > If UE that normally uses IPv6 roams to a provider that only supports > IPv4, some kind of tunnel solution seems inevitable. ISATAP is > certainly irrelevant, because the IPv4 provider won't provide > ISATAP machinery by definition. So either the home provider will > have to offer a tunnel broker or a 6to4 relay for use by its > subscribers when they roam on IPv4. I don't think the IETF > should worry about whether the UE has enough real estate for > this option; that's a vendor choice. An UE can only use 6to4 if the ISP provides it with a global IPv4 address. I suspect that the same 3G ISP that are looking at not providing IPv6 support are also looking at not providing global IPv4 addresses. There are certainly many GPRS service today that by default provide you with net 10 addresses; you have to pay extra to get the "professional" option and a global address. If the ISP does not provide a global address to the UE, then IPv6 connectivity can only be obtained via a tunneling protocol that goes through the ISP's NAT -- either some form of VPN or tunnel, or a Teredo, or a variation of these. --Christian Huitema From owner-v6ops@ops.ietf.org Thu Jul 24 11:40: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 LAA11281 for ; Thu, 24 Jul 2003 11:40:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fiBC-0007T8-Eu for v6ops-data@psg.com; Thu, 24 Jul 2003 15:38:54 +0000 Received: from [193.180.251.47] (helo=penguin.al.sw.ericsson.se) by psg.com with esmtp (Exim 4.14) id 19fiB8-0007Rj-Md for v6ops@ops.ietf.org; Thu, 24 Jul 2003 15:38:50 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6OFcjjG019441; Thu, 24 Jul 2003 17:38:45 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Jul 2003 17:38:45 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28BE2@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment (fwd) Date: Thu, 24 Jul 2003 17:38:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_01,MSG_ID_ADDED_BY_MTA_3 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk More comments below. > > I can't remember seeing emails on this list saying the opposite, > > but if anyone has corrections to make please feel free. > > I've talked with a few people in Nokia and they seem to have > said so. Of > course, I know close to nothing of 3GPP, so they might have > misunderstood > my questions or I might have misunderstood their answers. > > > > > You have left out the issue that when we're introducing a new > > > > technology nowadays we don't do it all at once but gradually. > > > > > > Dubious 3GPP specs (see above) are a real hindrance to > > > deployment, it > > > seems.. > > > > I'd say "interpretations" are a hindrance as with all > non-IETF specs > > which get discussed in IETF. > > I agree. > > And where do those interpretations stem from? Lack the IETF > understanding > non-IETF specs and the lack of non-IETF people understanding > IETF specs. > Let's look at the former. Interpretations can stem from misunderstanding of the questions or answers as you wrote above. That's often the case since that is an important means by which knowledge is shared. > > I don't know whether it is the responsibility of the IETF reader to > educate himself with non-IETF specs, or the responsibility > of the people > discussing non-IETF specs in the IETF context to educate > IETF folks. > > There are probably different opinions on this, but as 3GPP > comes to the > IETF, my personal feeling is that it is the latter. (I.e. to provide > enough context of 3GPP so that IETF folks can make > reasonable decisions.) I agree and that's been an important part of RFC 3314 and the scenarios draft. I think they do a good job. > > > I think the design team has the right competence to > address these issues > > and we didn't have major disagreement. > > You misunderstand the role of the design team. The design > team is to > address issues, yes, but all its decisions are brought to > the working > group, and the most importantly, all those decisions must be > justified -- > and the working group has to feel good with them. There may be good > reasons for decisions made in the process, but at least all > of them do not > appear to be apparent. > > Design team is a brain-storming activity to cook up > proposals for the WG. > WG then decides what to do with those proposals based on how > it feels > about them. You're jumping to conclusions here. I never said that design teams are above the WG. The point is that you are the person raising these objections and I was trying to find out what they are based on. If the WG thinks that RFC 3314, analysis and scenario drafts don't provide enough background info to support the need for tunnelling we can put in something to explain it better. However what you were saying previously was that you talked to some people who told you the opposite of what is written in the draft. So it looks like the meaning and recommendation is your issue rather than the clarity. If people disagree with what I have written on 3gpp in these emails or what is in the draft then they should bring it up now so it can be addressed. Otherwise we can just work on the clarity and move on. /Karim From owner-v6ops@ops.ietf.org Thu Jul 24 12:01: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 MAA11825 for ; Thu, 24 Jul 2003 12:01:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fiWK-0008zG-8S for v6ops-data@psg.com; Thu, 24 Jul 2003 16:00:44 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fiWH-0008z3-9E for v6ops@ops.ietf.org; Thu, 24 Jul 2003 16:00:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6OFsqY04180; Thu, 24 Jul 2003 18:54:52 +0300 Date: Thu, 24 Jul 2003 18:54:51 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: "'Brian E Carpenter'" , Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28BE1@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > You're assuming that roaming is done at L3. Roaming is normally > > > done at L2 so for example ISATAP is a relevant option. > > > > (I think you should elaborate on "normally") > > According to the 3gpp standard. Are there known (or planned) deviations from this standard? > > OK. If roaming is done at L2, then IP addresses etc. should > > stay the same > > when you roam, right? Then IPv6 addresses will stay too, > > right? So, why > > do you need ISATAP there then? > > Imagine a situation in which you're roaming to another > operator's network. The roaming user requests v6 connectivity > (PDP Context) in the new network. If the new network doesn't > support it, the roaming user won't get v6 connectivity. Ok; this is not necessarily a huge problem in itself. But let me try to rephrase this: Imagine a situation in which you're moving under another GGSN in your operator's network. The user requests v6 connectivity (PDP Context) in the network. If the network doesn't support it, the user won't get v6 connectivity. I.e., to be able to use v6 everywhere under your own operator's network, is it required that all GGSN's in that operator's network support IPv6 PDP contexts? Or let me phrase this differently: Would roaming with 3GPP UE work if the roaming agreements would include an indication whether the foreign network supports the same PDP context types as the original network. I.e. the user can prefer those roaming partners which provide the services they want. That should be enough of an economic incentive. Or, i.e. we define that "roaming" is not "true roaming" unless you provide the support for the same PDP context types; that is, there is "partial roaming" as of today and "real roaming" of tomorrow. IMHO, it seems ill-advised to call something "roaming" when they fail to provide critical infrastructure capabilities the users need. > The PDP Context is a special L2 as described in RFC 3314. Ok, let me try to clarify several ambiguous points: (there are probably more but from the top of my head) Does the IP address of the UE change when it roams to another network? Does the GGSN always change to a GGSN of the another network? If not, how is IP address kept the same? If yes, is mobility (in the meaning of "connection survivability") between roaming networks a non-goal as it can't work at PDP context layer? When the user moves inside the same operator's network does the IP address change? (I don't think so) - Does the GGSN change? (I don't think so) If yes, how does mobility work then? What determines which GGSN you end up using in the operator's network? - How does this work in a network where some GGSN's are v6-capable and some not? Figure 3 (typo: should be fig 4) in page 11 seems to indicate that UE can have multiple PDP contexts, to multiple ISPs. As long as UE opens the PDP context to his own ISP which supports v6, you're fine. But can the UE do 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 Thu Jul 24 12:20: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 MAA12427 for ; Thu, 24 Jul 2003 12:20:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fip2-000APJ-4E for v6ops-data@psg.com; Thu, 24 Jul 2003 16:20:04 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19fioz-000ALZ-7O for v6ops@ops.ietf.org; Thu, 24 Jul 2003 16:20:01 +0000 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 24 Jul 2003 09:19:30 -0700 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jul 2003 09:19:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 09:19:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 09:19:30 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 24 Jul 2003 09:19:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Automatic tunnels Date: Thu, 24 Jul 2003 09:17:02 -0700 Message-ID: Thread-Topic: Automatic tunnels Thread-Index: AcNR6mapPFc/pSmkRbGGYk9QjyNMJQAETYLA From: "Christian Huitema" To: X-OriginalArrivalTime: 24 Jul 2003 16:19:29.0134 (UTC) FILETIME=[5B9270E0:01C351FF] X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable During the Vienna meeting, I sensed that there was a split in the WG constituency between those who like automatic tunneling techniques such as 6to4 and Teredo because they enable automatic deployment of IPv6, and those who have an instinctive dislike for these technologies and would much prefer controlled mechanisms and the orderly deployment of tunnels. I would like to understand how we can resolve this tension. My personal analysis is that configured tunnels have a lot of drawbacks, unless they are "very short", in practice if they are provided by the very same ISP that provides IPv4 connectivity. This opinion is based on our collective experience with long tunnels: they require collaboration of a remote entity, and thus explicit configuration; they don't follow the natural Internet topology and thus often result in rather poor transmission times; and they are costly to provide, as someone has to pay for the transmission to and from the tunnel endpoint. Automatic tunnels like 6to4 and Teredo have the advantage of being potentially "very short": the transmission between two transition hosts follows the IPv4 topology, and is thus as short as it gets; the transmission between transition and native includes a dog-leg, but that leg can be as short as the distance to the nearest relay, i.e. the nearest dual stack router. The typical issues with automatic tunnels are the stability of the IPv6 address (as stable as the underlying IPv4), the provision of reverse mappings in the DNS, and the possibility of attacks on or through the relays, most of which can probably be mitigated. Another often quoted issue is that people might just be satisfied with the transition technology and never go native, but I don't believe that this creates much of a difference between configured and automatic tunnels. An obvious compromise would be to use no tunnel at all if the ISP provides IPv6 connectivity, configured tunnels when provided by the local ISP, automatic tunneling otherwise. However, this begs one question. Why would an ISP invest in providing local tunnels, instead of providing native connectivity faster? If the ISP wants to facilitate the transition, why would it not just provide a local 6to4 relay for the exclusive use of its customers? -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Jul 24 12:47:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13806 for ; Thu, 24 Jul 2003 12:47:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fjEz-000CRH-5o for v6ops-data@psg.com; Thu, 24 Jul 2003 16:46:53 +0000 Received: from [193.180.251.47] (helo=penguin.al.sw.ericsson.se) by psg.com with esmtp (Exim 4.14) id 19fjEv-000CQY-4y for v6ops@ops.ietf.org; Thu, 24 Jul 2003 16:46:49 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6OGk7jG026945; Thu, 24 Jul 2003 18:46:07 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 24 Jul 2003 18:46:07 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28BE4@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola'" Cc: "'Brian E Carpenter'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment Date: Thu, 24 Jul 2003 18:45:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-5.7 required=5.0 tests=BAYES_01,MSG_ID_ADDED_BY_MTA_3 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > > > You're assuming that roaming is done at L3. Roaming > is normally > > > > done at L2 so for example ISATAP is a relevant option. > > > > > > (I think you should elaborate on "normally") > > > > According to the 3gpp standard. > > Are there known (or planned) deviations from this standard? Not that I know of. > > > OK. If roaming is done at L2, then IP addresses etc. should > > > stay the same > > > when you roam, right? Then IPv6 addresses will stay too, > > > right? So, why > > > do you need ISATAP there then? > > > > Imagine a situation in which you're roaming to another > > operator's network. The roaming user requests v6 connectivity > > (PDP Context) in the new network. If the new network doesn't > > support it, the roaming user won't get v6 connectivity. > > Ok; this is not necessarily a huge problem in itself. > > But let me try to rephrase this: > > Imagine a situation in which you're moving under another > GGSN in your > operator's network. The user requests v6 connectivity > (PDP Context) in the network. If the network doesn't > support it, the user won't get v6 connectivity. > > I.e., to be able to use v6 everywhere under your own > operator's network, > is it required that all GGSN's in that operator's network > support IPv6 PDP > contexts? You can make it work with just one GGSN if you really want to. > > Or let me phrase this differently: > > Would roaming with 3GPP UE work if the roaming agreements > would include > an indication whether the foreign network supports the same > PDP context > types as the original network. > > I.e. the user can prefer those roaming partners which > provide the services > they want. That should be enough of an economic incentive. Basically the UE won't know until it tries to activate a v6 connection and it gets refused. > > Or, i.e. we define that "roaming" is not "true roaming" > unless you provide > the support for the same PDP context types; that is, there > is "partial > roaming" as of today and "real roaming" of tomorrow. > > IMHO, it seems ill-advised to call something "roaming" when > they fail to > provide critical infrastructure capabilities the users need. Some people would see voice, IPv4 or MMS as critical so I don't think it makes sense to get into a discussion here on what the word "roaming" should mean. > > > The PDP Context is a special L2 as described in RFC 3314. > > Ok, let me try to clarify several ambiguous points: (there > are probably > more but from the top of my head) > > Does the IP address of the UE change when it roams to > another network? The active PDP Context's address doesn't change as long as this type of "connection survivability" roaming is allowed. However note that roaming is also when I get off the plane in another country and turn my mobile on. So the address is likely to change. > Does the GGSN always change to a GGSN of the another network? No. > If not, how is IP address kept the same? L2 tunnelling back to the home network. > > When the user moves inside the same operator's network does > the IP address > change? (I don't think so) No. > - Does the GGSN change? (I don't think so) No. > > What determines which GGSN you end up using in the > operator's network? The type of service "APN" you request (more in RFC 3314) > - How does this work in a network where some GGSN's are > v6-capable and > some not? You create a v6 "APN" mapped to the IPv6 GGSN, but I don't think this is important in practice. I think you are concentrating too much on the GGSN issue. Although the GGSN is your default router, in order to activate the PDP Context you need support also in the SGSN for example. Whether you're roaming or not this holds true. As a user you sit under two nodes: SGSN and GGSN. The SGSN has geographical coverage. If I am under a SGSN that refuses the v6 pdp context or a network where there is no IPv6 GGSN then I can use tunnelling. That's all we're saying. > > Figure 3 (typo: should be fig 4) in page 11 seems to > indicate that UE can > have multiple PDP contexts, to multiple ISPs. As long as UE > opens the PDP > context to his own ISP which supports v6, you're fine. But > can the UE do > that? It can activate mutliple PDP Contexts. However the addressing and forwarding is through the GGSN. So, the ISP may support IPv6 but the SGSN/GGSN don't. It's just like any access router. If your ISP supports IPv6 and your current access router is IPv4-only you'll still need to tunnel to get to your v6 ISP. /Karim From owner-v6ops@ops.ietf.org Thu Jul 24 13:24: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 NAA16878 for ; Thu, 24 Jul 2003 13:24:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fjnw-000Fax-5X for v6ops-data@psg.com; Thu, 24 Jul 2003 17:23:00 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19fjnr-000FYV-Ak for v6ops@ops.ietf.org; Thu, 24 Jul 2003 17:22:55 +0000 Received: from consulintel02 ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 9-md50000000113.tmp for ; Thu, 24 Jul 2003 19:23:57 +0200 Message-ID: <01f501c35208$5ad99210$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Automatic tunnels Date: Thu, 24 Jul 2003 19:23:48 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Thu, 24 Jul 2003 19:23:57 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-9.6 required=5.0 tests=BAYES_20,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Christian, all, I'm in principle in favor of both, because my belief is that only the market will drive one or the other. Of course, I will much prefer native services, but they only will happen when the ISPs can start making money because the native service itself, or because is an added value for their "regular" IPv4 service. The problem is that I don't think most of the ISPs will invest in offering tunnel services, because they will cost almost the same as providing native service, with the only difference of the customer CPE and the BAS in case of xDSL or similar services. May be some will start with tunnels until they upgrade their BAS, and then will ask their customers to pay an additional fee for moving to a native service. Is a possible business model, but as said, who knows. But what I'm convinced is that we will have both type of tunnels, and we must provide good technical support for them: 1) Automatic tunnels provided mainly by non-local ISPs (as is the case for the actual tunnel brokers, over all the world) 2) Configured tunnels provided by local ISPs. I think this is opposed to your belief ... but I think the local ISPs will only provide tunnels if they can be managed. So what I believe is that we need more support for the "local-ISPs". Automatic tunnels don't like them, because, at least actually, they have non easy way to control the users. If we have a Teredo-like mechanism that provides authentication (with or w/o billing, that's another history), that will be interesting for local ISPs, but then is not so-automatic. I think it can be a simple registration site, something like what you have for a TB. I don't think that providing transition paths will difficult the global adoption of IPv6, more at the contrary, transition is always "bad" in terms of performance, and the people will like to take advantage of native IPv6, specially when they tried a good transition path. My 20 cents ;-) Regards, Jordi ----- Original Message ----- From: "Christian Huitema" To: Sent: Thursday, July 24, 2003 6:17 PM Subject: Automatic tunnels During the Vienna meeting, I sensed that there was a split in the WG constituency between those who like automatic tunneling techniques such as 6to4 and Teredo because they enable automatic deployment of IPv6, and those who have an instinctive dislike for these technologies and would much prefer controlled mechanisms and the orderly deployment of tunnels. I would like to understand how we can resolve this tension. My personal analysis is that configured tunnels have a lot of drawbacks, unless they are "very short", in practice if they are provided by the very same ISP that provides IPv4 connectivity. This opinion is based on our collective experience with long tunnels: they require collaboration of a remote entity, and thus explicit configuration; they don't follow the natural Internet topology and thus often result in rather poor transmission times; and they are costly to provide, as someone has to pay for the transmission to and from the tunnel endpoint. Automatic tunnels like 6to4 and Teredo have the advantage of being potentially "very short": the transmission between two transition hosts follows the IPv4 topology, and is thus as short as it gets; the transmission between transition and native includes a dog-leg, but that leg can be as short as the distance to the nearest relay, i.e. the nearest dual stack router. The typical issues with automatic tunnels are the stability of the IPv6 address (as stable as the underlying IPv4), the provision of reverse mappings in the DNS, and the possibility of attacks on or through the relays, most of which can probably be mitigated. Another often quoted issue is that people might just be satisfied with the transition technology and never go native, but I don't believe that this creates much of a difference between configured and automatic tunnels. An obvious compromise would be to use no tunnel at all if the ISP provides IPv6 connectivity, configured tunnels when provided by the local ISP, automatic tunneling otherwise. However, this begs one question. Why would an ISP invest in providing local tunnels, instead of providing native connectivity faster? If the ISP wants to facilitate the transition, why would it not just provide a local 6to4 relay for the exclusive use of its customers? -- Christian Huitema ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Thu Jul 24 15:44: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 PAA26904 for ; Thu, 24 Jul 2003 15:44:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19flyV-000Paj-En for v6ops-data@psg.com; Thu, 24 Jul 2003 19:42:03 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19flyR-000PaU-K3 for v6ops@ops.ietf.org; Thu, 24 Jul 2003 19:41:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6OJfui07709; Thu, 24 Jul 2003 22:41:56 +0300 Date: Thu, 24 Jul 2003 22:41:56 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28BE4@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > > Or let me phrase this differently: > > > > Would roaming with 3GPP UE work if the roaming agreements > > would include > > an indication whether the foreign network supports the same > > PDP context > > types as the original network. > > > > I.e. the user can prefer those roaming partners which > > provide the services > > they want. That should be enough of an economic incentive. > > Basically the UE won't know until it tries to activate > a v6 connection and it gets refused. This seems like a potentially fatal design flaw. If UE's were to run PPP PDP Contexts, could the lack of IPv6 support in remote SGSN's/GGSN's be avoided ? > > Or, i.e. we define that "roaming" is not "true roaming" > > unless you provide > > the support for the same PDP context types; that is, there > > is "partial > > roaming" as of today and "real roaming" of tomorrow. > > > > IMHO, it seems ill-advised to call something "roaming" when > > they fail to > > provide critical infrastructure capabilities the users need. > > Some people would see voice, IPv4 or MMS as critical so I don't > think it makes sense to get into a discussion here on what the word > "roaming" should mean. Is there a significant number of roaming partners where voice, IPv4 or MMS are not supported (in regions where some other potential roaming partners would provide support for them)? Otherwise your analogy does not seem fitting. > > > The PDP Context is a special L2 as described in RFC 3314. > > > > Ok, let me try to clarify several ambiguous points: (there > > are probably > > more but from the top of my head) > > > > Does the IP address of the UE change when it roams to > > another network? > > The active PDP Context's address doesn't change as long > as this type of "connection survivability" roaming is allowed. > However note that roaming is also when I get off the plane > in another country and turn my mobile on. So the address is > likely to change. Ok. > > Does the GGSN always change to a GGSN of the another network? > No. > > > If not, how is IP address kept the same? > > L2 tunnelling back to the home network. So, as the GGSN does not always change, there should be a way to keep alive the association with the local GGSN? If you use IPv6 PDP context to a local GGSN, move over to another country and 3GPP operator but don't switch off your UE -- retaining your old GGSN -- does the IPv6 still work through the IPv6 PDP context through L2 tunneling? If not, why not? > > - How does this work in a network where some GGSN's are > > v6-capable and > > some not? > > You create a v6 "APN" mapped to the IPv6 GGSN, but I don't think > this is important in practice. I think you are concentrating too > much on the GGSN issue. Maybe so, but the IP concepts are those I'm familiar with :-) > Although the GGSN is your default router, > in order to activate the PDP Context you need support also in the > SGSN for example. Whether you're roaming or not this holds true. > As a user you sit under two nodes: SGSN and GGSN. The SGSN has > geographical coverage. If I am under a SGSN that refuses the > v6 pdp context or a network where there is no IPv6 GGSN then I > can use tunnelling. That's all we're saying. If SGSN doesn't support IPv6 PDP contexts but GGSN does, you're out of luck? (without tunneling by the UE) > > Figure 3 (typo: should be fig 4) in page 11 seems to > > indicate that UE can > > have multiple PDP contexts, to multiple ISPs. As long as UE > > opens the PDP > > context to his own ISP which supports v6, you're fine. But > > can the UE do > > that? > > It can activate mutliple PDP Contexts. However the addressing > and forwarding is through the GGSN. So, the ISP may support IPv6 > but the SGSN/GGSN don't. It's just like any access router. If your > ISP supports IPv6 and your current access router is IPv4-only you'll > still need to tunnel to get to your v6 ISP. I'm not sure if my question got across, because I don't understand the answer in that context. So, let's try again: How exactly can UE's open multiple PDP _primary_ contexts to different operators? Is there anything in the capabilities of the network(s) which may hinder your possibilities to open PDP contexts to different ISPs? When you're roaming, couldn't you just try opening IPv6 PDP context, and if it fails, try some other roaming partner (if available) and try to open an IPv6 PDP context there too? Or even try opening PDP contexts simultaneously (would be more costly, I suppose -- depending on whether the billing starts after or before the PDP context activation is successful; in this scenario, it's the latter)? -- 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 Jul 24 16:25: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 QAA28687 for ; Thu, 24 Jul 2003 16:25:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fmdW-0002mI-AL for v6ops-data@psg.com; Thu, 24 Jul 2003 20:24:26 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19fmdR-0002m5-7U for v6ops@ops.ietf.org; Thu, 24 Jul 2003 20:24:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6OKOHk08439; Thu, 24 Jul 2003 23:24:17 +0300 Date: Thu, 24 Jul 2003 23:24:17 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (HF/EAB)" cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28BDC@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > You're assuming that roaming is done at L3. Roaming is normally > done at L2 so for example ISATAP is a relevant option. Later, I thought of another issue here. When you roam, your IP address typically changes to one given by the remote 3GPP operator. Who provides Internet connectivity to this address, the remote operator or your "home" operator (e.g. via L2 tunneling)? If the former, ISATAP would not really be applicable, as the operators would not be in the same administrative domains, and moreover, the addresses would likely be private. > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: den 24 juli 2003 14:35 > > To: Pekka Savola > > Cc: v6ops@ops.ietf.org > > Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs; > > 3GPP IPv6 > > deployment > > > > > > If UE that normally uses IPv6 roams to a provider that only supports > > IPv4, some kind of tunnel solution seems inevitable. ISATAP is > > certainly irrelevant, because the IPv4 provider won't provide > > ISATAP machinery by definition. So either the home provider will > > have to offer a tunnel broker or a 6to4 relay for use by its > > subscribers when they roam on IPv4. I don't think the IETF > > should worry about whether the UE has enough real estate for > > this option; that's a vendor choice. > > > > I suspect the UE will have less overhead to support 6to4 than > > to support a tunnel broker protocol. > > > > Brian-- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > > > > NOTE: My email will soon change to brc@zurich.ibm.com > > Try that if you get failure messages. > > > > Pekka Savola wrote: > > > > > > Hi, > > > > > > This is a slightly related point to "The use of 6to4" issue raised > > > yesterday. > > > > > > Section 3.1 goes and analyzes the case where the 3GPP > > network does not > > > provide IPv6 support at great length. > > > > > > I strongly believe that: > > > > > > 1) we *MUST NOT* require or recommend the implementation > > of any automatic > > > tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We > > SHOULD NOT > > > require or recommend the implement configured tunneling on > > UE's (but I can > > > be convinced otherwise). > > > > > > 2) The use of ISATAP is misguided in this space: it's > > only useful if the > > > 3GPP operator supports IPv6 (i.e. provides the ISATAP > > routers and other > > > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, > > etc. This > > > seems in direct conflict with 3GPP goals. > > > > > > 3) we should be able to assume that unless the 3GPP > > operator where the > > > user buys his service doesn't support IPv6, the user > > cannot use IPv6 on > > > his gadget. On the other hand, if the particular GGSN the user is > > > connected using IPv4 supports only IPv4, there is nothing > > stopping the > > > user from using some other GGSN for IPv6 support. That > > is, as long as the > > > 3GPP operator has basically one IPv6-aware GGSN, SGSN and > > HLR, IPv6 users > > > are happy. > > > > > > The reasons for these points are mainly: > > > > > > - The number of UE's is expected to be very high, > > > - The implementation footprint of UE's is expected to be > > very small, so > > > any extra code is difficult to justify, > > > - The upgradeability of UE's is poor, and we may not be > > able to retire > > > such mechanisms, > > > - We're concerned about 3GPP *deployment* not early > > trials or piloting > > > - There is a significant pressure for 3GPP operators to > > do IPv6 properly, > > > and we should rather work on getting on with *real* IPv6 > > deployment than > > > fiddling around with transition mechanisms in this space. > > > > > > Of course, if the UE implements something like 6to4, > > there's nothing to > > > stop them. Just we shouldn't advocate that.. > > > > > > This, I'd suggest major reworking of the parts of the section 3.1. > > > > > > ===8<==== > > > 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes > > > [...] > > > However, the UE may attach to a 3GPP network, in which the SGSN > > > (Serving GPRS Support Node), the GGSN and the HLR > > (Home Location > > > Register) support IPv4 PDP contexts by default, but > > may not support > > > IPv6 PDP contexts. If the 3GPP network does not > > support IPv6 PDP > > > contexts, and an application on the UE needs to > > communicate with an > > > IPv6(-only) node, the UE may activate an IPv4 PDP context and > > > encapsulate IPv6 packets in IPv4 packets using a tunneling > > > mechanism. This might happen in very early phases of IPv6 > > > deployment, or in IPv6 demonstrations and trials. > > > > > > The UE may be assigned a private or public IPv4 > > address when the > > > IPv4 PDP context has been activated, although it is more likely > > > that it will receive a private address (due to the > > lack of public > > > IPv4 addresses). The use of private IPv4 addresses in the UE > > > depends on the support of these addresses by the tunneling > > > mechanism and the deployment scenario. In some cases, > > public IPv4 > > > addresses are required (one example is 6to4 > > [RFC3056]), but if the > > > tunnel endpoints are in the same private domain or the > > tunneling > > > mechanism works through IPv4 NAT (Network Address Translator), > > > private IPv4 addresses can be used (examples are [ISATAP] and > > > [TEREDO]). In general, if tunneling from the host is > > needed, ISATAP > > > and 6to4 are preferred and TEREDO is a mechanism of last resort > > > when neither of these are applicable. > > > > > > One deployment scenario example is using laptop > > computer and a UMTS > > > UE as a modem. IPv6 packets are encapsulated in IPv4 > > packets in the > > > laptop computer and an IPv4 PDP context is activated. Although > > > "IPv6 in IPv4" tunneling can be either automatic or > > configured (by > > > the user), the first alternative is favored, because > > it is expected > > > that most UE users just want to use an application in their UE; > > > they might not even care, whether the network > > connection is IPv4 or > > > IPv6. > > > [...] > > > > > > 3.2.2 Tunneling outside the 3GPP Operator's Network > > > [...] > > > On the other hand, usage of dynamic tunneling, such as > > "6to4", can > > > also be considered, but scalability problems arise > > when thinking > > > about the great number of UEs in the 3GPP networks. > > The specific > > > limitation when applying "6to4" in 3GPP networks should also be > > > taken into account, as commented in 3.2.1. Other > > issues to keep in > > > mind with respect to the "6to4" mechanism are that > > reverse DNS is > > > not yet completely solved and there are some security > > > considerations associated with the use of "6to4" relay > > routers (see > > > [6to4SEC]). Moreover, in a later phase of the > > transition period, > > > there will be a need for assigning new, native IPv6 > > addresses to > > > all "6to4" nodes in order to enable native IPv6 connectivity. > > > > > > -- > > > Pekka Savola "You each name yourselves > > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A > > Clash of Kings > > > -- 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 Jul 24 23:23: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 XAA09903 for ; Thu, 24 Jul 2003 23:23:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ft8A-0004H3-Jw for v6ops-data@psg.com; Fri, 25 Jul 2003 03:20:30 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19ft84-0004GZ-GC for v6ops@ops.ietf.org; Fri, 25 Jul 2003 03:20:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6P3KMe12284 for ; Fri, 25 Jul 2003 06:20:22 +0300 Date: Fri, 25 Jul 2003 06:20:22 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: Automatic tunneling inside 3GPP operator's network Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, This is my last issue in the document. This has already been discussed before, at least in the thread starting May 14, 2003, with subject "3gpp-analysis document and automatic tunneling", but without concrete resolution. Perhaps rereading that discussion would be in order prior to starting the same debate again. The text basically includes healthy disclaimers (based on my insistence I guess) why running automatic tunneling mechanisms in 3GPP operators' backbones is not a good idea, and dual-stack should be done instead, coupled with a couple of tunnels. (Most of this is really ISP scenarios anyway.) However, the text still, IMHO, uses too strong words in favor of automatic tunneling mechanisms, in particular in three paragraphs I've marked with a "*" in the text below. I've also marked a section which might use some more description with "@": "if the number of IPv6 islands grow, the administrative burden of maintaining tunnels also grows". Correct: but isn't this a CLEAR signal that instead of building more tunnels you should be deploying dual stack between those islands? We want an (IPv4/)IPv6 continent, not dozens of small islands connected with bridges! What I want is to: - remove all references to the use of 6to4 (for the use of automatic tunneling in the 3GPP operator's core network) or IGP/BGP tunneling mechanisms from this document, and - discuss connection redundancy requirements (if any) and how they could be met with regular, already specified, simple methods (like running IPv6 routing protocols, using configured tunnneling and deploying dual-stack infrastructure). ===== 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network [...] "IPv6 in IPv4" tunnels between IPv6 islands can be either static or dynamic. The selection of the type of tunneling mechanism is up to the operator / ISP deployment scenario and only generic recommendations can be given in this document. The following subsections are focused on the usage of different tunneling mechanisms when the peer node is in the operator's network or outside the operator's network. The authors note that where the actual 3GPP network ends and which parts of the network belong to the ISP(s) also depends on the deployment scenario. The authors are not commenting how many ISP functions the 3GPP operator should perform. However, many 3GPP operators are ISPs of some sort themselves. ISP transition scenarios are documented and analyzed in [ISP-scen], [ISP-analysis] and their future updates. 3.2.1 Tunneling inside the 3GPP Operator's Network Many GPRS operators already have IPv4 backbone networks deployed and they are gradually migrating them while introducing IPv6 islands. IPv6 backbones can be considered quite rare in the first phases of the transition. If the 3GPP operator already has IPv6 widely deployed in its network, this subsection is not so relevant. In initial, smaller scale IPv6 deployment, where a small number of IPv6 in IPv4 tunnels are required to connect the IPv6 islands over the 3GPP operator's IPv4 network, manually configured tunnels can be used. In a 3GPP network, one IPv6 island could contain the GGSN while another island contains the operator's IPv6 application servers. However, manually configured tunnels can be an @ administrative burden when the number of islands and therefore tunnels rises. In that case, upgrading parts of the backbone to dual stack may be the simplest choice. The administrative burden could also be mitigated by using automated management tools which are typically necessary to manage large networks anyway. * Even a dynamic tunneling mechanism, such as "6to4" [RFC3056] or an IGP/EGP routing protocol based tunneling mechanism [BGP][IGP], could be used if other methods are not suitable. Routing protocol based mechanisms such as [BGP] consist of running BGP between the neighboring router tunnel endpoints and using multi-protocol BGP extensions to exchange reachability information of IPv6 prefixes. * The routers use this information to create IPv6 in IPv4 tunnel interfaces and route IPv6 packets over the IPv4 network. It is possible to combine this with different types of tunnels. * Connection redundancy should also be noted as an important requirement in 3GPP networks. Static tunnels on their own don't provide a routing recovery solution for all scenarios where an IPv6 route goes down. However, they may provide an adequate solution depending on the design of the network and in presence of other router redundancy mechanisms. On the other hand, IGP/EGP based mechanisms can provide redundancy. "6to4" nodes use special IPv6 addresses with a "6to4" prefix containing the IPv4 address of the corresponding "IPv6 in IPv4" tunnel endpoint ("6to4" router) which performs encapsulation / decapsulation. When connecting two nodes with "6to4" addresses, the corresponding "6to4" routers use the IPv4 addresses specified in the "6to4" prefixes to tunnel IPv6 packets through the IPv4 network. But if only one of them has a "6to4" address, a "6to4" relay must be present to perform the missing "6to4" router functionality for the native-IPv6 node. If we consider the "6to4" tunneling mechanism and the 3GPP addressing model (a unique /64 prefix allocated for each primary PDP context), a /48 "6to4" prefix would only be enough for approximately 65000 UEs. Thus, a few public IPv4 addresses would be needed depending on the size of the operator. -- 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 Jul 24 23:23: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 XAA09919 for ; Thu, 24 Jul 2003 23:23:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ft7V-0004Bk-D0 for v6ops-data@psg.com; Fri, 25 Jul 2003 03:19:49 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19ft7S-0004BY-KL for v6ops@ops.ietf.org; Fri, 25 Jul 2003 03:19:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6P3JiW12247 for ; Fri, 25 Jul 2003 06:19:44 +0300 Date: Fri, 25 Jul 2003 06:19:43 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: SIP/SDP transition Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The text in section 4.2 on IMS scenarios describes SIP/SDP transition scenarios. At least based on Karim El-Malki et al.'s work, it is not apparent that ALG should/has to change the SIP messages and SDP payload. I thought the "architectural" approach would have been been different, i.e., in principle, make the IPv6-only IMS aware of the payload translation, a la RSIP. In any case, the SIP/SDP transition scenarios need to be fleshed out a bit more. ===== SIP and SDP transition has to be made in an SIP/SDP Application Level Gateway. The ALG has to change the IP addresses transported in the SIP messages and the SDP payload of those messages to the appropriate version. In addition, there has to be interoperability for DNS queries; see section 4.1 for details. -- 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 Jul 24 23:23: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 XAA09961 for ; Thu, 24 Jul 2003 23:23:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ft9J-0004L5-IO for v6ops-data@psg.com; Fri, 25 Jul 2003 03:21:41 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19ft9G-0004Ks-VL for v6ops@ops.ietf.org; Fri, 25 Jul 2003 03:21:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6P3Lb312291 for ; Fri, 25 Jul 2003 06:21:37 +0300 Date: Fri, 25 Jul 2003 06:21:37 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: On vacation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, I will be on vacation with no access to email (or intermittent and shoddy at best) for about 1.5 weeks. Contact other co-chairs for v6ops related activities in the meantime. I'll continue the message threads I was participating when I return. -- 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 Jul 24 23:23: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 XAA09978 for ; Thu, 24 Jul 2003 23:23:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ft7c-0004Bz-Kh for v6ops-data@psg.com; Fri, 25 Jul 2003 03:19:56 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 4.14) id 19ft7a-0004Bn-7a for v6ops@ops.ietf.org; Fri, 25 Jul 2003 03:19:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6P3Jqh12252 for ; Fri, 25 Jul 2003 06:19:52 +0300 Date: Fri, 25 Jul 2003 06:19:52 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: Security considerations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The security consideration section of the 3GPP analysis document is still very weak; in principle, they only cover three points related to NAT-PT and/or DNSSEC. A more thorough analysis is required. In addition to NAT-PT/DNSSEC issues (I'm not sure if the three points are a conclusive list, though), the security properties of different transition scenarios and mechanisms should be briefly described. The exact contents depends a lot on which mechanisms we seem to get rough consensus on. ===== 5. Security Considerations 1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and [v4v6trans]. 2. The 3GPP specifications do not currently define the usage of DNS Security. They neither disallow the usage of DNSSEC, nor do they mandate it. 3. NAT-PT breaks DNSSEC. -- 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 Jul 24 23:48: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 XAA10588 for ; Thu, 24 Jul 2003 23:48:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19ftXj-0006Y8-JF for v6ops-data@psg.com; Fri, 25 Jul 2003 03:46:55 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.14) id 19ftXh-0006Vw-9e for v6ops@ops.ietf.org; Fri, 25 Jul 2003 03:46:53 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 24 Jul 2003 23:46:21 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922BFC@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Security considerations Date: Thu, 24 Jul 2003 23:46:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, Do you want to send text? Perhaps when you get back. This comment is a bit too open. Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, July 24, 2003 11:20 PM > To: v6ops@ops.ietf.org > Subject: 3gpp-analysis-04: Security considerations > > > Hi, > > The security consideration section of the 3GPP analysis > document is still > very weak; in principle, they only cover three points > related to NAT-PT > and/or DNSSEC. A more thorough analysis is required. > > In addition to NAT-PT/DNSSEC issues (I'm not sure if the > three points are > a conclusive list, though), the security properties of different > transition scenarios and mechanisms should be briefly described. > > The exact contents depends a lot on which mechanisms we seem to get > rough consensus on. > > ===== > 5. Security Considerations > > > 1. NAT-PT DNS ALG problems are described in [NATPT-DNS] and > [v4v6trans]. > > > 2. The 3GPP specifications do not currently define the usage > of DNS Security. They neither disallow the usage > of DNSSEC, > nor do they mandate it. > > > 3. NAT-PT breaks DNSSEC. > -- > 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 Jul 25 00:46: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 AAA11644 for ; Fri, 25 Jul 2003 00:46:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fuQq-000AYU-1Y for v6ops-data@psg.com; Fri, 25 Jul 2003 04:43:52 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.14) id 19fuQj-000AY0-Na for v6ops@ops.ietf.org; Fri, 25 Jul 2003 04:43:45 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 022DB13; Fri, 25 Jul 2003 13:43:43 +0900 (JST) To: "JORDI PALET MARTINEZ" Cc: v6ops@ops.ietf.org In-reply-to: jordi.palet's message of Thu, 24 Jul 2003 19:23:48 +0200. <01f501c35208$5ad99210$870a0a0a@consulintel.es> 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: Automatic tunnels From: itojun@iijlab.net Date: Fri, 25 Jul 2003 13:43:43 +0900 Message-Id: <20030725044344.022DB13@coconut.itojun.org> X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >The problem is that I don't think most of the ISPs will invest in >offering tunnel services, because they will cost almost the same >as providing native service, with the only difference of the customer >CPE and the BAS in case of xDSL or similar services. May be some >will start with tunnels until they upgrade their BAS, and then will >ask their customers to pay an additional fee for moving to a native >service. Is a possible business model, but as said, who knows. we at IIJ use PC with BSD operating system for terminating our tunnelling service customers. required investment is minimal, and 1 PC can terminate > 10000 tunnels if you want to (we don't do 10000, but freenet6 does it). it is an added value to our IPv4 service (it will look more tasty). other japanese ISPs are doing similar things. so i guess i disagree with you on "most of the ISPs won't invest on tunnel service". itojun From owner-v6ops@ops.ietf.org Fri Jul 25 02:39: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 CAA25886 for ; Fri, 25 Jul 2003 02:39:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fwCF-000JnI-Ab for v6ops-data@psg.com; Fri, 25 Jul 2003 06:36:55 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.14) id 19fwCB-000Jlx-V1 for v6ops@ops.ietf.org; Fri, 25 Jul 2003 06:36:52 +0000 Received: from consulintel02 ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.4.R) with ESMTP id 58-md50000000119.tmp for ; Fri, 25 Jul 2003 08:37:53 +0200 Message-ID: <072901c35277$02c3fb50$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <20030725044344.022DB13@coconut.itojun.org> Subject: Re: Automatic tunnels Date: Fri, 25 Jul 2003 08:33:55 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Fri, 25 Jul 2003 08:37:53 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't think most of the ISPs will do it with just a PC. Most of them still don't believe in IPv6, so is just a good excuse for them (they will tell you that is still not well supported by the router vendors). Most of the cost anyway is training the people and maintaining the service (including the customers hot line). Its clear, how many TBs exist around the world versus ISPs ? But may be there are other reasons that I didn't cached ? Regards, Jordi ----- Original Message ----- From: To: "JORDI PALET MARTINEZ" Cc: Sent: Friday, July 25, 2003 6:43 AM Subject: Re: Automatic tunnels > >The problem is that I don't think most of the ISPs will invest in > >offering tunnel services, because they will cost almost the same > >as providing native service, with the only difference of the customer > >CPE and the BAS in case of xDSL or similar services. May be some > >will start with tunnels until they upgrade their BAS, and then will > >ask their customers to pay an additional fee for moving to a native > >service. Is a possible business model, but as said, who knows. > > we at IIJ use PC with BSD operating system for terminating our > tunnelling service customers. required investment is minimal, and 1 > PC can terminate > 10000 tunnels if you want to (we don't do 10000, > but freenet6 does it). it is an added value to our IPv4 service (it > will look more tasty). other japanese ISPs are doing similar things. > so i guess i disagree with you on "most of the ISPs won't invest on > tunnel service". > > itojun > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Fri Jul 25 03:46: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 DAA27675 for ; Fri, 25 Jul 2003 03:46:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fxFk-000P1a-D6 for v6ops-data@psg.com; Fri, 25 Jul 2003 07:44:36 +0000 Received: from [213.134.128.238] (helo=email.cdp.pl) by psg.com with esmtp (Exim 4.14) id 19fxFg-000Ow5-Uu for v6ops@ops.ietf.org; Fri, 25 Jul 2003 07:44:33 +0000 Received: (qmail 18579 invoked from network); 25 Jul 2003 07:43:33 -0000 Received: from office-gw1.waw.cdp.pl (HELO crowley.pl) ([213.134.140.130]) (envelope-sender ) by 0 (qmail-1.03) with SMTP for ; 25 Jul 2003 07:43:33 -0000 Message-ID: <01ed01c3527f$f07b6a10$8ddca8c0@zurawputer> From: "Piotr Zurawski" To: References: <20030725044344.022DB13@coconut.itojun.org> <072901c35277$02c3fb50$870a0a0a@consulintel.es> Subject: Re: Automatic tunnels Date: Fri, 25 Jul 2003 09:39:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In my company, not supporting the IPv6 was the first reason to make problems with the deployment. But I see it as a deeper thing: IPv4 services are managable through network management systems. For the ATM network you can tune up many parameters to optimize IP traffic and/or other services. If you add a new protocol, which cannot be managed via the same interface, this messes up the things:there are not many people with knowledge how to solve the problems with tunneled IPv6 and even how to find them. Another point is that nobody will guarantee, that the service will be working properly. For IPv4 our hardware vendor gives us the support. For IPv6 we're on our own. Most of us here are technical persons (as far as I see it). It's not a problem for techies to solve the things - we're just in it. This looks completely different from managements' point of view: IPv6 comes as a new service, without any guarantees (we offer SLA for all type of services being offered, you'd have to cross IPv6 from your SLA portfolio then - it won't look good). To deploy IPv6 you'll need to train people and any human resource rotation will cause more problems (more things to be learnt). Still, since nearly noone *REQUIRES* IPv6 connectivity to be done, it does not come as a priority to be deployed. For management, more important is to improve the services already existing. The reason, that would vitally speed up the global deployment would be the deadline. This is not based on what US DoD done (but it's a good example how to speed it up). From my experience, if management does not see the deadline, the current affairs (having deadline and precise effects) will be considered to be done. I didn't wanted to feed up the troll. That's just how it looks in few ISPs in Poland I know. Best Regards, Piotr ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Friday, July 25, 2003 8:33 AM Subject: Re: Automatic tunnels > I don't think most of the ISPs will do it with just a PC. Most of them still don't believe in IPv6, so is just a good excuse for > them (they will tell you that is still not well supported by the router vendors). Most of the cost anyway is training the people and > maintaining the service (including the customers hot line). > > Its clear, how many TBs exist around the world versus ISPs ? > > But may be there are other reasons that I didn't cached ? > > Regards, > Jordi > > ----- Original Message ----- > From: > To: "JORDI PALET MARTINEZ" > Cc: > Sent: Friday, July 25, 2003 6:43 AM > Subject: Re: Automatic tunnels > > > > >The problem is that I don't think most of the ISPs will invest in > > >offering tunnel services, because they will cost almost the same > > >as providing native service, with the only difference of the customer > > >CPE and the BAS in case of xDSL or similar services. May be some > > >will start with tunnels until they upgrade their BAS, and then will > > >ask their customers to pay an additional fee for moving to a native > > >service. Is a possible business model, but as said, who knows. > > > > we at IIJ use PC with BSD operating system for terminating our > > tunnelling service customers. required investment is minimal, and 1 > > PC can terminate > 10000 tunnels if you want to (we don't do 10000, > > but freenet6 does it). it is an added value to our IPv4 service (it > > will look more tasty). other japanese ISPs are doing similar things. > > so i guess i disagree with you on "most of the ISPs won't invest on > > tunnel service". > > > > itojun > > > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com > > > > From owner-v6ops@ops.ietf.org Fri Jul 25 04:13: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 EAA28266 for ; Fri, 25 Jul 2003 04:13:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fxha-0001R0-HZ for v6ops-data@psg.com; Fri, 25 Jul 2003 08:13:22 +0000 Received: from [195.207.101.240] (helo=relay1.alcatel.be) by psg.com with esmtp (Exim 4.14) id 19fxhX-0001Nc-Ql for v6ops@ops.ietf.org; Fri, 25 Jul 2003 08:13:19 +0000 Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by relay1.alcatel.be (8.12.9/8.12.4) with ESMTP id h6P8ClrH013297; Fri, 25 Jul 2003 10:12:47 +0200 (MEST) From: Robert.Peschi@alcatel.be Subject: Re: Automatic tunnels To: "Christian Huitema" Cc: Date: Fri, 25 Jul 2003 10:12:46 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 07/25/2003 10:12:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_10,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Christian, you wrote: > (...) [configured tunnels] don't follow the natural > Internet topology and thus often result in rather poor > transmission times and a bit further: > Automatic tunnels like 6to4 (...) have the advantage of being > potentially "very short": the transmission between two transition > hosts follows the IPv4 topology, What do you mean by "following or not the IPv4 topology" ? From the IPv4 forwarding point of view, I can't figure out such a difference between configured or 6to4 tunnels. I guess I must be missing you point here ? Thanks, Robert From owner-v6ops@ops.ietf.org Fri Jul 25 05:45: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 FAA00296 for ; Fri, 25 Jul 2003 05:45:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19fz7C-0008nI-Jm for v6ops-data@psg.com; Fri, 25 Jul 2003 09:43:54 +0000 Received: from [193.180.251.49] (helo=albatross.tn.sw.ericsson.se) by psg.com with esmtp (Exim 4.14) id 19fz78-0008n4-H4 for v6ops@ops.ietf.org; Fri, 25 Jul 2003 09:43:50 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h6P9hmG6021528; Fri, 25 Jul 2003 11:43:48 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 25 Jul 2003 11:43:48 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28BEB@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola '" Cc: "'v6ops@ops.ietf.org '" Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment Date: Fri, 25 Jul 2003 11:43:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,MSG_ID_ADDED_BY_MTA_3, ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Answered this already in your list of questions. It is the latter (L2 tunnelling) thus e.g. ISATAP is applicable. /Karim -----Original Message----- From: Pekka Savola To: Karim El-Malki (HF/EAB) Cc: v6ops@ops.ietf.org Sent: 2003-07-24 22:24 Subject: RE: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 dep loyment On Thu, 24 Jul 2003, Karim El-Malki (HF/EAB) wrote: > You're assuming that roaming is done at L3. Roaming is normally > done at L2 so for example ISATAP is a relevant option. Later, I thought of another issue here. When you roam, your IP address typically changappes to one given by the remote 3GPP operator. Who provides Internet connectivity to this address, the remote operator or your "home" operator (e.g. via L2 tunneling)? If the former, ISATAP would not really be applicable, as the operators would not be in the same administrative domains, and moreover, the addresses would likely be private. > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: den 24 juli 2003 14:35 > > To: Pekka Savola > > Cc: v6ops@ops.ietf.org > > Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs; > > 3GPP IPv6 > > deployment > > > > > > If UE that normally uses IPv6 roams to a provider that only supports > > IPv4, some kind of tunnel solution seems inevitable. ISATAP is > > certainly irrelevant, because the IPv4 provider won't provide > > ISATAP machinery by definition. So either the home provider will > > have to offer a tunnel broker or a 6to4 relay for use by its > > subscribers when they roam on IPv4. I don't think the IETF > > should worry about whether the UE has enough real estate for > > this option; that's a vendor choice. > > > > I suspect the UE will have less overhead to support 6to4 than > > to support a tunnel broker protocol. > > > > Brian-- > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Brian E Carpenter > > Distinguished Engineer, Internet Standards & Technology, IBM > > > > NOTE: My email will soon change to brc@zurich.ibm.com > > Try that if you get failure messages. > > > > Pekka Savola wrote: > > > > > > Hi, > > > > > > This is a slightly related point to "The use of 6to4" issue raised > > > yesterday. > > > > > > Section 3.1 goes and analyzes the case where the 3GPP > > network does not > > > provide IPv6 support at great length. > > > > > > I strongly believe that: > > > > > > 1) we *MUST NOT* require or recommend the implementation > > of any automatic > > > tunneling methods such as 6to4 or ISATAP on 3GPP UE's. We > > SHOULD NOT > > > require or recommend the implement configured tunneling on > > UE's (but I can > > > be convinced otherwise). > > > > > > 2) The use of ISATAP is misguided in this space: it's > > only useful if the > > > 3GPP operator supports IPv6 (i.e. provides the ISATAP > > routers and other > > > infrastructure) but doesn't just have IPv6 SGSN's, GGSN's, > > etc. This > > > seems in direct conflict with 3GPP goals. > > > > > > 3) we should be able to assume that unless the 3GPP > > operator where the > > > user buys his service doesn't support IPv6, the user > > cannot use IPv6 on > > > his gadget. On the other hand, if the particular GGSN the user is > > > connected using IPv4 supports only IPv4, there is nothing > > stopping the > > > user from using some other GGSN for IPv6 support. That > > is, as long as the > > > 3GPP operator has basically one IPv6-aware GGSN, SGSN and > > HLR, IPv6 users > > > are happy. > > > > > > The reasons for these points are mainly: > > > > > > - The number of UE's is expected to be very high, > > > - The implementation footprint of UE's is expected to be > > very small, so > > > any extra code is difficult to justify, > > > - The upgradeability of UE's is poor, and we may not be > > able to retire > > > such mechanisms, > > > - We're concerned about 3GPP *deployment* not early > > trials or piloting > > > - There is a significant pressure for 3GPP operators to > > do IPv6 properly, > > > and we should rather work on getting on with *real* IPv6 > > deployment than > > > fiddling around with transition mechanisms in this space. > > > > > > Of course, if the UE implements something like 6to4, > > there's nothing to > > > stop them. Just we shouldn't advocate that.. > > > > > > This, I'd suggest major reworking of the parts of the section 3.1. > > > > > > ===8<==== > > > 3.1 Dual Stack UE Connecting to IPv4 and IPv6 Nodes > > > [...] > > > However, the UE may attach to a 3GPP network, in which the SGSN > > > (Serving GPRS Support Node), the GGSN and the HLR > > (Home Location > > > Register) support IPv4 PDP contexts by default, but > > may not support > > > IPv6 PDP contexts. If the 3GPP network does not > > support IPv6 PDP > > > contexts, and an application on the UE needs to > > communicate with an > > > IPv6(-only) node, the UE may activate an IPv4 PDP context and > > > encapsulate IPv6 packets in IPv4 packets using a tunneling > > > mechanism. This might happen in very early phases of IPv6 > > > deployment, or in IPv6 demonstrations and trials. > > > > > > The UE may be assigned a private or public IPv4 > > address when the > > > IPv4 PDP context has been activated, although it is more likely > > > that it will receive a private address (due to the > > lack of public > > > IPv4 addresses). The use of private IPv4 addresses in the UE > > > depends on the support of these addresses by the tunneling > > > mechanism and the deployment scenario. In some cases, > > public IPv4 > > > addresses are required (one example is 6to4 > > [RFC3056]), but if the > > > tunnel endpoints are in the same private domain or the > > tunneling > > > mechanism works through IPv4 NAT (Network Address Translator), > > > private IPv4 addresses can be used (examples are [ISATAP] and > > > [TEREDO]). In general, if tunneling from the host is > > needed, ISATAP > > > and 6to4 are preferred and TEREDO is a mechanism of last resort > > > when neither of these are applicable. > > > > > > One deployment scenario example is using laptop > > computer and a UMTS > > > UE as a modem. IPv6 packets are encapsulated in IPv4 > > packets in the > > > laptop computer and an IPv4 PDP context is activated. Although > > > "IPv6 in IPv4" tunneling can be either automatic or > > configured (by > > > the user), the first alternative is favored, because > > it is expected > > > that most UE users just want to use an application in their UE; > > > they might not even care, whether the network > > connection is IPv4 or > > > IPv6. > > > [...] > > > > > > 3.2.2 Tunneling outside the 3GPP Operator's Network > > > [...] > > > On the other hand, usage of dynamic tunneling, such as > > "6to4", can > > > also be considered, but scalability problems arise > > when thinking > > > about the great number of UEs in the 3GPP networks. > > The specific > > > limitation when applying "6to4" in 3GPP networks should also be > > > taken into account, as commented in 3.2.1. Other > > issues to keep in > > > mind with respect to the "6to4" mechanism are that > > reverse DNS is > > > not yet completely solved and there are some security > > > considerations associated with the use of "6to4" relay > > routers (see > > > [6to4SEC]). Moreover, in a later phase of the > > transition period, > > > there will be a need for assigning new, native IPv6 > > addresses to > > > all "6to4" nodes in order to enable native IPv6 connectivity. > > > > > > -- > > > Pekka Savola "You each name yourselves > > king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A > > Clash of Kings > > > -- 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 Jul 25 12:05:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10458 for ; Fri, 25 Jul 2003 12:05:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g50t-0007oM-ES for v6ops-data@psg.com; Fri, 25 Jul 2003 16:01:47 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19g50q-0007nL-Ql for v6ops@ops.ietf.org; Fri, 25 Jul 2003 16:01:44 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jul 2003 09:01:14 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:01:08 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Jul 2003 09:01:08 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:01:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:00:56 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:01:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Automatic tunnels Date: Fri, 25 Jul 2003 08:58:27 -0700 Message-ID: Thread-Topic: Automatic tunnels Thread-Index: AcNShJsHuPJ2erO1RXuRFTRKTU8EqAAQFFnw From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 25 Jul 2003 16:01:02.0830 (UTC) FILETIME=[F29398E0:01C352C5] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > (...) [configured tunnels] don't follow the natural > > Internet topology and thus often result in rather poor > > transmission times >=20 > and a bit further: >=20 > > Automatic tunnels like 6to4 (...) have the advantage of being > > potentially "very short": the transmission between two transition > > hosts follows the IPv4 topology, >=20 > What do you mean by "following or not the IPv4 topology" ? >=20 > From the IPv4 forwarding point of view, I can't figure out such > a difference between configured or 6to4 tunnels. Traffic between two 6to4 routers will follow exactly the same path as IPv4 traffic between these two routers. If the network topology changes, the path will automatically follow the new routing state. This is a big difference to traffic over overlay networks like the 6Bone, in which packets hop from tunnel to tunnel; the tunnel layout is typically meant to reflect the nominal network topology, but it will not change if events affect the routing. A practical consequence is that a ping between two 6to4 addresses often shows a much shorter delay than a ping between two tunneled hosts. -- Christian Huitema From owner-v6ops@ops.ietf.org Fri Jul 25 12:07: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 MAA10611 for ; Fri, 25 Jul 2003 12:06:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g55R-0008Gz-LR for v6ops-data@psg.com; Fri, 25 Jul 2003 16:06:29 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19g55M-0008Gg-AD for v6ops@ops.ietf.org; Fri, 25 Jul 2003 16:06:24 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6PG6Np4011542 for ; Fri, 25 Jul 2003 10:06:23 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIL00EY38QN7C@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 25 Jul 2003 10:06:23 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIL005V38QLG9@mail.sun.net> for v6ops@ops.ietf.org; Fri, 25 Jul 2003 10:06:23 -0600 (MDT) Date: Fri, 25 Jul 2003 09:08:29 -0700 From: Alain Durand Subject: Re: Automatic tunnels In-reply-to: To: Christian Huitema Cc: v6ops@ops.ietf.org Message-id: <3B2AE8C6-BEBA-11D7-A988-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, July 24, 2003, at 09:17 AM, Christian Huitema wrote: > An obvious compromise would be to use no tunnel at all if the ISP > provides IPv6 connectivity, configured tunnels when provided by the > local ISP, automatic tunneling otherwise. However, this begs one > question. Why would an ISP invest in providing local tunnels, instead > of > providing native connectivity faster? If the ISP wants to facilitate > the > transition, why would it not just provide a local 6to4 relay for the > exclusive use of its customers? > > -- Christian Huitema > Christian, First of, let me clarify that is discussion is more relevant to the home ISP than to the enterprise ISP. I will agree with your analysis that customers configured tunnels needs to be terminated within the home ISP core or access network to be efficient. This does not rule out configured tunnels, however it requires ISP cooperation to work. I would also like to point that automatic tunnels have their share of problems. Security is a big concern on my list. We have studied at length 6to4 security issues, we would need to do the same with teredo/isatap. The rest of the message analyses 6to4 vs tunnel broker from the ISP perspective (as opposite to the user perspective) One issue is to understand the scaling properties of configured/automatic tunnel solutions. 6to4 to native v6 kinda works (if you accept that the packets you send to your neighbor can go a couple times around the planet) today because there is very little traffic.Tunnel brokers done outside of traditional IPv4 ISPs induce sub-optimal traffic. It's fine as a bootstrapping mechanism for early adopter, but this cannot sustain production traffic. For this, as said earlier, tunnel server would have to be as close to the source as possible. We also need to understand if and how a home ISP can deploy gradually IPv6 for its customer. Does providing a 6to4 relay helps? Does providing a tunnel broker in in core/access networks help? Does this makes it easier to go gradually to native? The issue with with an ISP deploying an internal 6to4-to-native relay is that it will help its customers who are using 6to4 to send packets to native IPv6 destination, but won't do much to make sure that the same packets will return any quicker. As 6to4 to native and back is fundamentally asymmetric routing, somebody, preferably close to the native IPv6 node has to have a route for 2002::/16. As one can not realistically expect to have every single IPv6 network maintaining a local native-to-6to4 gateway, we would have to rely on public, open native-to-6to4 relays to exist and advertise 2002::/16 in the DFZ. So far, I have identified only a few of those public native-to-6to4 relays. My understanding is that, expect from the willingness to promote the technology, there is actually little incentive to operate such a relay, as it will just attract transit traffic that has nothing to do with the ISP customers. But if/once an ISP had deployed local 6to4-to-native relay, what is the next step? It seems to me that there is a more natural evolution path if the ISP starts with a tunnel broker/server. Internal links can be upgraded to native, then PE-CPE links can be upgraded to native in places where the demand justifies it. In other words, it seems to me that it is easier to go selectively from a sparse deployment mode to a dense deployment mode. - Alain. From owner-v6ops@ops.ietf.org Fri Jul 25 13:01: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 NAA12389 for ; Fri, 25 Jul 2003 13:01:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19g5v8-000BYs-UH for v6ops-data@psg.com; Fri, 25 Jul 2003 16:59:54 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.14) id 19g5v5-000BYW-SN for v6ops@ops.ietf.org; Fri, 25 Jul 2003 16:59:51 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jul 2003 09:59:48 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:59:47 -0700 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Jul 2003 09:59:48 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:59:43 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:59:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 25 Jul 2003 09:59:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Automatic tunnels Date: Fri, 25 Jul 2003 09:57:19 -0700 Message-ID: Thread-Topic: Automatic tunnels Thread-Index: AcNSxqYOOShOZ42yQY6uEaDpZxG7NAABP0cA From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 25 Jul 2003 16:59:46.0022 (UTC) FILETIME=[26900860:01C352CE] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > We also need to understand if and how a home ISP can deploy gradually > IPv6 > for its customer. Does providing a 6to4 relay helps? Does providing a > tunnel broker > in in core/access networks help? Does this makes it easier to go > gradually to native? I guess we agree that the main priority for ISP ought to be, "provide native IPv6 services". The question then is what should an ISP do when it wishes to provide IPv6 but is not quite ready. I would expect the ISP design team to tell us more about the constraints and the practicalities, but there are clearly three possibilities: do nothing, provide support for automatic tunneling, or provide configured tunnels. The support for automatic tunneling is simple: just provide a 6to4-to-native service and advertise a route to 192.88.99.1; to avoid abuse, make sure that 192.88.99.1 is only reachable by subscribers of this ISP. The support for configured tunnels is somewhat more complex: if the ISP really want to provide additional benefits compare to automatic tunnels, it needs to do some form of customer management to ensure that customers get stable prefixes, that they use the tunnel end point closest to home, etc. Frankly, I don't know whether the additional complexity is worth the cost. > The issue with with an ISP deploying an internal 6to4-to-native relay > is that > it will help its customers who are using 6to4 to send packets to native > IPv6 > destination, but won't do much to make sure that the same packets will > return any quicker. As 6to4 to native and back is fundamentally > asymmetric routing, > somebody, preferably close to the native IPv6 node has to have a route > for 2002::/16. Deploying a "native to 6to4" relay is actually very easy -- its is a matter of turning on 6to4 relaying on a dual-stack router, or even on a dual-stack host. I would expect that these relays will be plentiful. > As one can not realistically expect to have every single IPv6 network > maintaining > a local native-to-6to4 gateway, we would have to rely on public, > open native-to-6to4 relays to exist and advertise 2002::/16 in the DFZ. We should precisely aim for having at least one native to 6to4 router in every dual stack ISP. These routers are very easy to control: just don't propagate 2002::/16 in BGP. They provide an immediate added value to the local IPv6 users. > So far, I have identified only a few of those public native-to-6to4 > relays. > My understanding is that, expect from the willingness to promote the > technology, > there is actually little incentive to operate such a relay, as it will > just attract transit traffic > that has nothing to do with the ISP customers. I believe it is a whole lot easier to provide "private" relays, for local use only, rather than public relays, for the whole Internet. However, backbone ISP have a built-in incentive to provide these relays: the relays create traffic, and that traffic ends up being billed to the second tier ISP who send packets to the backbone. -- Christian Huitema From owner-v6ops@ops.ietf.org Fri Jul 25 19:33: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 TAA01809 for ; Fri, 25 Jul 2003 19:33:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19gC2D-0009Ic-Id for v6ops-data@psg.com; Fri, 25 Jul 2003 23:31:37 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.14) id 19gC2A-0009IQ-VX for v6ops@ops.ietf.org; Fri, 25 Jul 2003 23:31:35 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6PNVYp4020237 for ; Fri, 25 Jul 2003 17:31:34 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIL009G2TCL67@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 25 Jul 2003 17:31:34 -0600 (MDT) Received: from sun.com ([129.146.17.35]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIL008BQTCLYF@mail.sun.net> for v6ops@ops.ietf.org; Fri, 25 Jul 2003 17:31:33 -0600 (MDT) Date: Fri, 25 Jul 2003 16:31:32 -0700 From: Alain Durand Subject: Re: Automatic tunnels To: Christian Huitema Cc: v6ops@ops.ietf.org Message-id: <3F21BDD4.7000106@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=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Christian Huitema wrote: >>IPv6 >>destination, but won't do much to make sure that the same packets will >>return any quicker. As 6to4 to native and back is fundamentally >>asymmetric routing, >>somebody, preferably close to the native IPv6 node has to have a route >>for 2002::/16. >> >> > >Deploying a "native to 6to4" relay is actually very easy -- its is a >matter of turning on 6to4 relaying on a dual-stack router, or even on a >dual-stack host. I would expect that these relays will be plentiful. > > Do you have any data that shows that this is happening? >>As one can not realistically expect to have every single IPv6 network >>maintaining >>a local native-to-6to4 gateway, we would have to rely on public, >>open native-to-6to4 relays to exist and advertise 2002::/16 in the >> >> >DFZ. > >We should precisely aim for having at least one native to 6to4 router in >every dual stack ISP. These routers are very easy to control: just don't >propagate 2002::/16 in BGP. They provide an immediate added value to the >local IPv6 users. > So, if I understand you correctly, what you're aiming at is that everytime a 6to4 user A with a IPv4 ISPa wants to communicate with an native IPv6 user B with an IPv6 ISPb: - IPv4 ISPa has deployed a 6to4-to-native relay - IPv6 ISPb has deployed a native-to-6to4 relay or has a peering agreement with someone who offer native-to-6to4 relay service. This is an operational issue, are IPv6 ISPs doing this today? If not, why? - Alain. From owner-v6ops@ops.ietf.org Sat Jul 26 05: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 FAA00997 for ; Sat, 26 Jul 2003 05:09:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19gKyI-0001bZ-6k for v6ops-data@psg.com; Sat, 26 Jul 2003 09:04:10 +0000 Received: from [2001:770:10:300::86e2:510b] (helo=salmon.maths.tcd.ie ident=mmdf) by psg.com with smtp (Exim 4.14) id 19gKyD-0001Xs-Ms for v6ops@ops.ietf.org; Sat, 26 Jul 2003 09:04:05 +0000 Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Jul 2003 10:03:58 +0100 (BST) Date: Sat, 26 Jul 2003 10:03:58 +0100 From: David Malone To: Alain Durand Cc: Christian Huitema , v6ops@ops.ietf.org Subject: Re: Automatic tunnels Message-ID: <20030726090358.GA36066@hamilton.maths.tcd.ie> References: <3F21BDD4.7000106@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F21BDD4.7000106@sun.com> User-Agent: Mutt/1.5.3i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Jul 25, 2003 at 04:31:32PM -0700, Alain Durand wrote: > >Deploying a "native to 6to4" relay is actually very easy -- its is a > >matter of turning on 6to4 relaying on a dual-stack router, or even on a > >dual-stack host. I would expect that these relays will be plentiful. > Do you have any data that shows that this is happening? I did some measurements of the number of 6to4 relays, including private ones. I've included relevant part of my message to v6ops below. The count was done on 2 July. (If anyone would like this written up in more detail, let me know...) David. If anyone is interested, I had a go at counting 6to4 relay routers from the IPv6 side. I did this by tracerout6ing with a 6to4 source address and then using tcpdump to catch the IPv4 addresses of relay-routers that was used to encapsulate the replies. To decide where to traceroute to, I used the ::1 addresses of each prefix in the IPv6 BGP table (as seen from HEAnet this morning). After doing this, I got replies encapsulated 26 different source IPv4 addresses. One was the anycast address and I had a go at guessing the countries of the remainder (AU:1 CZ:1 DE:1 FI:1 IE:1 JP:1 KR:3 LT:2 NL:3 NO:1 PT:1 SE:2 TH:1 TW:1 UK:2 US:3). About 1/4 of the response packets came from the 6to4 anycast address, so it seems to be worth trying to figure out how many relays it represents. Looking at the histogram of TTLs in the IPv4 header, it looks like there are at least 3 or 4. To try to get a better idea, I tracerout6ed to a 6to4 address using a routing header to get the packet to first go to nodes that had had replies encapsulated with the anycast address. The second last hop of these traceroutes should help identify the 6to4 relay. This produced 27 IPv6 addresses, but sevral of them looked like they were assigned to the same machine. Looking at the /32s that these IPv6 addresses are in suggests that there are actually about 12 distinct relays in this group. Looking them up in whois shows that two of the /32s are in switch, so we're probably looking at 11 (CH:1 DE:3 EE:1 FI:1 IE:1 JP:1 NL:1 UK:1 US:1). In total, that's about 33, if you take into account a possible overlap of 2 or 3. [Naturally, I may have missed lots of relays that aren't visable from the route to the ::1 address within a prefix...] From owner-v6ops@ops.ietf.org Sat Jul 26 08:35: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 IAA05388 for ; Sat, 26 Jul 2003 08:35:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.14) id 19gOCc-000Ei8-01 for v6ops-data@psg.com; Sat, 26 Jul 2003 12:31:10 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.14) id 19gOCJ-000Eg2-6p for v6ops@ops.ietf.org; Sat, 26 Jul 2003 12:30:51 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 94994BD15; Sat, 26 Jul 2003 08:30:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 26 Jul 2003 08:30:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents Date: Sat, 26 Jul 2003 08:30:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047C9E94@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents Thread-Index: AcNQNeenV7BwnN/xS5uglk9YYCmLwQDOPtJQ From: "Bound, Jim" To: "Pekka Savola" , Cc: , , X-OriginalArrivalTime: 26 Jul 2003 12:30:50.0445 (UTC) FILETIME=[BF6C1FD0:01C35371] X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > This is a WG Last Call for comments on sending the following=20 > first three=20 > "Survey of IPv4 Addresses in Currently Deployed IETF=20 > Standards" documents=20 > to the IESG for consideration as Informational RFCs: >=20 > Introduction to the Survey of IPv4 Addresses in Currently=20 > Deployed IETF Standards > =20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-01 .txt I don't see the point of section 1.2 it is commentary and it is imperative that this document just report the facts. I do not agree or disagree with the statements I just don't see its value, and worst case it could affect the objectivity view of the readers impression of the document. 3.1.1 This entire series of documents should not make judgement calls as is done with 1122 and 1123 (should be written wordage). It should just say has IPv6 dependency which was done well in the next set of documents we have been asked to review. Please remove all recommendations or perceived recommendations in this document series. 3.1.2 Same comment as 3.1.1 3.1.9 A6 records are dead. 3.1.11 Same comment as 3.1.1 3.1.22 Same comment as 3.1.1 3.2.1 DHCPv6 will be RFC 3315 very soon as a note. Its in RFC editor queue. 3.3.25 Same comment as 3.1.1 3.3.71 Same comment as 3.1.1. and this one has capitalized MUST (not good) References to Mobile IPv6 need to use draft-24 or say RFC PS is eminant and also could be used for DHCPv6 references too. If the wording is fixed as I state an issue in 3.1.1. then this is ready to go. It is a very good piece of work too. >Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards =20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-01 .txt This document is fine and the wording is good. e.g. IPv4 address dependency is used not statements of what to do. I am fine with this moving to INFO. >Survey of IPv4 Addresses in Currently Deployed IETF Operations &=20 >Management Area Standards =20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.t xt This is good piece of work too. The detail of what needs to be done is very good but it should be left as that an explanation. There are many instances again of my comment in INTRO 3.1.1 above. Just go through the doc and just report what is missing. Make no recommendations with SHOULD, MAY, or MUST and this is fine. I think the INTRO should be fixed before the others can move to INFO. thanks /jim From owner-v6ops@ops.ietf.org Mon Jul 28 17:35: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 RAA21466 for ; Mon, 28 Jul 2003 17:35:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hFaS-0002aC-Vs for v6ops-data@psg.com; Mon, 28 Jul 2003 21:31:20 +0000 Received: from [205.226.5.12] (helo=mailhost.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19hFaQ-0002a0-ME for v6ops@ops.ietf.org; Mon, 28 Jul 2003 21:31:18 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA06366; Mon, 28 Jul 2003 14:31:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6SLVCj07939; Mon, 28 Jul 2003 14:31:12 -0700 X-mProtect: <200307282131> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9NTC8b; Mon, 28 Jul 2003 14:31:10 PDT Message-ID: <3F259788.8090108@iprg.nokia.com> Date: Mon, 28 Jul 2003 14:37:12 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Brian E Carpenter , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-04: Transition mechanisms at UEs; 3GPP IPv6 deployment References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: >>If UE that normally uses IPv6 roams to a provider that only supports >>IPv4, some kind of tunnel solution seems inevitable. ISATAP is >>certainly irrelevant, because the IPv4 provider won't provide >>ISATAP machinery by definition. So either the home provider will >>have to offer a tunnel broker or a 6to4 relay for use by its >>subscribers when they roam on IPv4. I don't think the IETF >>should worry about whether the UE has enough real estate for >>this option; that's a vendor choice. >> >> > >An UE can only use 6to4 if the ISP provides it with a global IPv4 >address. I suspect that the same 3G ISP that are looking at not >providing IPv6 support are also looking at not providing global IPv4 >addresses. There are certainly many GPRS service today that by default >provide you with net 10 addresses; you have to pay extra to get the >"professional" option and a global address. > >If the ISP does not provide a global address to the UE, then IPv6 >connectivity can only be obtained via a tunneling protocol that goes >through the ISP's NAT -- either some form of VPN or tunnel, or a Teredo, >or a variation of these. > Not necessarily; the tunnel could also terminate at the ISP's NAT. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Jul 29 05:19: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 FAA16467 for ; Tue, 29 Jul 2003 05:19:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hQbR-000LsJ-33 for v6ops-data@psg.com; Tue, 29 Jul 2003 09:17:05 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hQbN-000Ls3-6p for v6ops@ops.ietf.org; Tue, 29 Jul 2003 09:17:01 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6T9H3FJ006055; Tue, 29 Jul 2003 11:17:04 +0200 (CEST) Date: Tue, 29 Jul 2003 11:16:58 +0200 Subject: Re: Automatic tunnels Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "JORDI PALET MARTINEZ" From: Kurt Erik Lindqvist In-Reply-To: <01f501c35208$5ad99210$870a0a0a@consulintel.es> Message-Id: <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-31.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To be honest, I think both forms of tunnels offers the ISPs a good starting point. Given the current levels of bandwidth consumed by IPv6 traffic (a large carrier told me they had magnitudes more OSI traffic for ADM management than IPv6 traffic) I think that we have to realize that carriers will not start rolling out native links of the same bandwidth as they do for IPv4 - especially with current revenue levels from IPv6 services. The alternative is dual-stack, but if I would be a carrier I would be very reluctant to roll-out dual-stack software (or at least to activate it) on my routers. Tunneling gives the ISPs the advantage that they can activate IPv6 at the edge and start in small scale and bind it all together across the core. Christian is right in saying that this potentially (not to say in real life) gives less performance and higher RTT. However, I think is something that market demand will have to take care of. - - kurtis - On torsdag, jul 24, 2003, at 19:23 Europe/Stockholm, JORDI PALET MARTINEZ wrote: > Hi Christian, all, > > I'm in principle in favor of both, because my belief is that only the > market will drive one or the other. > > Of course, I will much prefer native services, but they only will > happen when the ISPs can start making money because the native > service itself, or because is an added value for their "regular" IPv4 > service. > > The problem is that I don't think most of the ISPs will invest in > offering tunnel services, because they will cost almost the same > as providing native service, with the only difference of the customer > CPE and the BAS in case of xDSL or similar services. May be > some will start with tunnels until they upgrade their BAS, and then > will ask their customers to pay an additional fee for moving to > a native service. Is a possible business model, but as said, who knows. > > But what I'm convinced is that we will have both type of tunnels, and > we must provide good technical support for them: > 1) Automatic tunnels provided mainly by non-local ISPs (as is the case > for the actual tunnel brokers, over all the world) > 2) Configured tunnels provided by local ISPs. > > I think this is opposed to your belief ... but I think the local ISPs > will only provide tunnels if they can be managed. > > So what I believe is that we need more support for the "local-ISPs". > Automatic tunnels don't like them, because, at least actually, > they have non easy way to control the users. > > If we have a Teredo-like mechanism that provides authentication (with > or w/o billing, that's another history), that will be > interesting for local ISPs, but then is not so-automatic. I think it > can be a simple registration site, something like what you have > for a TB. > > I don't think that providing transition paths will difficult the > global adoption of IPv6, more at the contrary, transition is always > "bad" in terms of performance, and the people will like to take > advantage of native IPv6, specially when they tried a good > transition path. > > My 20 cents ;-) > > Regards, > Jordi > > ----- Original Message ----- > From: "Christian Huitema" > To: > Sent: Thursday, July 24, 2003 6:17 PM > Subject: Automatic tunnels > > > During the Vienna meeting, I sensed that there was a split in the WG > constituency between those who like automatic tunneling techniques such > as 6to4 and Teredo because they enable automatic deployment of IPv6, > and > those who have an instinctive dislike for these technologies and would > much prefer controlled mechanisms and the orderly deployment of > tunnels. > I would like to understand how we can resolve this tension. > > My personal analysis is that configured tunnels have a lot of > drawbacks, > unless they are "very short", in practice if they are provided by the > very same ISP that provides IPv4 connectivity. This opinion is based on > our collective experience with long tunnels: they require collaboration > of a remote entity, and thus explicit configuration; they don't follow > the natural Internet topology and thus often result in rather poor > transmission times; and they are costly to provide, as someone has to > pay for the transmission to and from the tunnel endpoint. > > Automatic tunnels like 6to4 and Teredo have the advantage of being > potentially "very short": the transmission between two transition hosts > follows the IPv4 topology, and is thus as short as it gets; the > transmission between transition and native includes a dog-leg, but that > leg can be as short as the distance to the nearest relay, i.e. the > nearest dual stack router. The typical issues with automatic tunnels > are > the stability of the IPv6 address (as stable as the underlying IPv4), > the provision of reverse mappings in the DNS, and the possibility of > attacks on or through the relays, most of which can probably be > mitigated. Another often quoted issue is that people might just be > satisfied with the transition technology and never go native, but I > don't believe that this creates much of a difference between configured > and automatic tunnels. > > An obvious compromise would be to use no tunnel at all if the ISP > provides IPv6 connectivity, configured tunnels when provided by the > local ISP, automatic tunneling otherwise. However, this begs one > question. Why would an ISP invest in providing local tunnels, instead > of > providing native connectivity faster? If the ISP wants to facilitate > the > transition, why would it not just provide a local 6to4 relay for the > exclusive use of its customers? > > -- Christian Huitema > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com > > > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyY7jKarNKXTPFCVEQJUJACdFKV0mVXF9MGuNUnTf3xIAKHaDxoAoOXP FabX32ktYDgsgQyiV6hIO7dg =mcrb -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Jul 29 05:25:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16605 for ; Tue, 29 Jul 2003 05:25:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hQj4-000MRF-Md for v6ops-data@psg.com; Tue, 29 Jul 2003 09:24:58 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.20) id 19hQhM-000MIE-HP for v6ops@ops.ietf.org; Tue, 29 Jul 2003 09:23:12 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA01557 for ; Tue, 29 Jul 2003 10:23:11 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id KAA20564 for ; Tue, 29 Jul 2003 10:23:10 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6T9NAn22355 for v6ops@ops.ietf.org; Tue, 29 Jul 2003 10:23:10 +0100 Date: Tue, 29 Jul 2003 10:23:10 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Automatic tunnels Message-ID: <20030729092310.GM21531@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 29, 2003 at 11:16:58AM +0200, Kurt Erik Lindqvist wrote: > > The alternative is dual-stack, but if I would be a carrier I would be > very reluctant to roll-out dual-stack software (or at least to activate > it) on my routers. I'm curious, what do you see as the main reasons for this? Tim From owner-v6ops@ops.ietf.org Tue Jul 29 05:41: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 FAA16852 for ; Tue, 29 Jul 2003 05:41:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hQyQ-000Ncn-2N for v6ops-data@psg.com; Tue, 29 Jul 2003 09:40:50 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hQyN-000NcX-PT for v6ops@ops.ietf.org; Tue, 29 Jul 2003 09:40:48 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6T9epFJ006072; Tue, 29 Jul 2003 11:40:51 +0200 (CEST) Date: Tue, 29 Jul 2003 11:40:43 +0200 Subject: Re: Automatic tunnels Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: v6ops@ops.ietf.org To: Tim Chown From: Kurt Erik Lindqvist In-Reply-To: <20030729092310.GM21531@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> The alternative is dual-stack, but if I would be a carrier I would be >> very reluctant to roll-out dual-stack software (or at least to >> activate >> it) on my routers. > > I'm curious, what do you see as the main reasons for this? > Experience? :-) The two vendors have enough of a problem to get v4 packets from interface A to interface B, and that is with customers that are paying for SLAs... I know it's being done and on pretty large networks as well. But I also hear people that are having problems in doing so. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZBIKarNKXTPFCVEQI1HwCgm+pypVvFW5x9nbAP4NratusukHEAn0dC ttZk9pXKc87JMSM0IDIO9WU1 =wxGW -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Jul 29 05:51: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 FAA17145 for ; Tue, 29 Jul 2003 05:51:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hR8X-000OSz-F6 for v6ops-data@psg.com; Tue, 29 Jul 2003 09:51:17 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.20) id 19hR8M-000OSH-DM for v6ops@ops.ietf.org; Tue, 29 Jul 2003 09:51:06 +0000 Received: (qmail 20754 invoked by uid 2502); 29 Jul 2003 09:51:04 -0000 Received: from rsofia@seas.upenn.edu by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.174392 secs); 29/07/2003 10:51:04 Received: from dhcp01.fccn.pt (HELO seas.upenn.edu) (193.136.7.131) by atlas.fccn.pt with SMTP; 29 Jul 2003 09:51:04 -0000 Message-ID: <3F264277.40702@seas.upenn.edu> Date: Tue, 29 Jul 2003 10:46:31 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Tim Chown , v6ops@ops.ietf.org Subject: Re: Automatic tunnels References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.4 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTE_TWICE_1,REFERENCES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > >>>very reluctant to roll-out dual-stack software (or at least to >>>activate >>>it) on my routers. >>> >>> >>I'm curious, what do you see as the main reasons for this? >> >> >> > >Experience?:-) The two vendors have enough of a problem to get v4 >packets from interface A to interface B, and that is with customers >that are paying for SLAs... > >I know it's being done and on pretty large networks as well. But I also >hear people that are having problems in doing so. > > > Not sure if I understood the point above correctly, but there are several reasons that ISPs use not to deploy dual-stack...the biggest is simply fear of the unknown ;-) Actually, in the past we (FCCN, the portuguese NREN) had several problems with Cisco routers, due to unstable "stable" IOS versions. But, after a bit of tackling, dual-stack is running indeed. Juniper routers were a great help to deploy dual-stack in an operacional environment. There were no problems at all. Rute From owner-v6ops@ops.ietf.org Tue Jul 29 06:12: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 GAA17478 for ; Tue, 29 Jul 2003 06:12:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hRSh-00006D-PS for v6ops-data@psg.com; Tue, 29 Jul 2003 10:12:07 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hRSf-000057-0T for v6ops@ops.ietf.org; Tue, 29 Jul 2003 10:12:05 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TAC8FJ006091; Tue, 29 Jul 2003 12:12:08 +0200 (CEST) Date: Tue, 29 Jul 2003 12:12:02 +0200 Subject: Re: Automatic tunnels Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Tim Chown , v6ops@ops.ietf.org To: Rute Sofia From: Kurt Erik Lindqvist In-Reply-To: <3F264277.40702@seas.upenn.edu> Message-Id: <18E828BC-C1AD-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.0 required=5.0 tests=BAYES_10,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> very reluctant to roll-out dual-stack software (or at least to >>>> activate >>>> it) on my routers. >>>> >>> I'm curious, what do you see as the main reasons for this? >>> >>> >> >> Experience?:-) The two vendors have enough of a problem to get v4 >> packets from interface A to interface B, and that is with customers >> that are paying for SLAs... >> >> I know it's being done and on pretty large networks as well. But I >> also hear people that are having problems in doing so. >> >> > Not sure if I understood the point above correctly, but there are > several reasons that ISPs use not to deploy dual-stack...the biggest > is simply fear of the unknown ;-) Absolutely. It's probably the largest reason. But even then tunnels are a great help for ISPs to see and learn. > Actually, in the past we (FCCN, the portuguese NREN) had several > problems with Cisco routers, due to unstable "stable" IOS versions. > But, after a bit of tackling, dual-stack is running indeed. Juniper > routers were a great help to deploy dual-stack in an operacional > environment. There were no problems at all. Glad to hear. I have heard opposite experiences but this will probably vary with your network topology, size, equipment in use etc. Just as for v4. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZIdKarNKXTPFCVEQJCJQCgo9ujz8ZjQz7t3bgzUHsEGHDVFAwAmwcX Y1pUDU93+nPkS7gtRoLs5uL+ =kHMK -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Jul 29 06:25: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 GAA17703 for ; Tue, 29 Jul 2003 06:25:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hReh-0000wZ-Jj for v6ops-data@psg.com; Tue, 29 Jul 2003 10:24:31 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.20) id 19hRed-0000wG-SB for v6ops@ops.ietf.org; Tue, 29 Jul 2003 10:24:28 +0000 Received: (qmail 6996 invoked by uid 1007); 29 Jul 2003 10:24:26 -0000 Date: Tue, 29 Jul 2003 12:24:26 +0200 From: Gert Doering To: v6ops@ops.ietf.org Subject: Re: Automatic tunnels Message-ID: <20030729122426.G67740@Space.Net> References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030729092310.GM21531@login.ecs.soton.ac.uk>; from tjc@ecs.soton.ac.uk on Tue, Jul 29, 2003 at 10:23:10AM +0100 X-NCC-RegID: de.space X-Spam-Status: No, hits=-38.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Tue, Jul 29, 2003 at 10:23:10AM +0100, Tim Chown wrote: > > The alternative is dual-stack, but if I would be a carrier I would be > > very reluctant to roll-out dual-stack software (or at least to activate > > it) on my routers. > I'm curious, what do you see as the main reasons for this? Operational errors (like "wrong IP address configured on interface" or "routing protocol configuration things" or "correct v4 address in DNS but v6 address wrong" or so) hit in quite surprising ways - you test, you run traceroute and ping, all looks fine, and then you realize that you traceroute'd only v4 while v6 is broken, or vice versa. Of course all this is solveable, but it means "more room for errors", and usually these do happen. (We're in the process of converting the v4-only network to dual-stack, and it's quite a challenge) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55442 (55636) 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 Tue Jul 29 06:38: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 GAA17898 for ; Tue, 29 Jul 2003 06:38:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hRry-00022M-H4 for v6ops-data@psg.com; Tue, 29 Jul 2003 10:38:14 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.20) id 19hRrw-000224-7i for v6ops@ops.ietf.org; Tue, 29 Jul 2003 10:38:12 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA03719 for ; Tue, 29 Jul 2003 11:38:10 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id LAA24165 for ; Tue, 29 Jul 2003 11:38:10 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6TAcAw23253 for v6ops@ops.ietf.org; Tue, 29 Jul 2003 11:38:10 +0100 Date: Tue, 29 Jul 2003 11:38:10 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Automatic tunnels Message-ID: <20030729103810.GV21531@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> <20030729122426.G67740@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030729122426.G67740@Space.Net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 29, 2003 at 12:24:26PM +0200, Gert Doering wrote: > > Operational errors (like "wrong IP address configured on interface" or > "routing protocol configuration things" or "correct v4 address in DNS but > v6 address wrong" or so) hit in quite surprising ways - you test, you > run traceroute and ping, all looks fine, and then you realize that you > traceroute'd only v4 while v6 is broken, or vice versa. > > Of course all this is solveable, but it means "more room for errors", > and usually these do happen. > > (We're in the process of converting the v4-only network to dual-stack, > and it's quite a challenge) There are many networks that have gone dual stack, so what you're saying is we need more operational experience feedback of the problems, rather than just the success stories. The early adoptors are the US and European research networks and backbones. I think they've been instrumental in helping Cisco, Juniper et al iron out many of the problems to make deployment less problematic (but by no means straightforward) for ISPs. Tim From owner-v6ops@ops.ietf.org Tue Jul 29 06:40: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 GAA17942 for ; Tue, 29 Jul 2003 06:40:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hRuN-0002IT-Bx for v6ops-data@psg.com; Tue, 29 Jul 2003 10:40:43 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.20) id 19hRuK-0002HY-DF for v6ops@ops.ietf.org; Tue, 29 Jul 2003 10:40:40 +0000 Received: (qmail 57251 invoked by uid 2502); 29 Jul 2003 10:40:39 -0000 Received: from rsofia@seas.upenn.edu by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.120629 secs); 29/07/2003 11:40:38 Received: from dhcp01.fccn.pt (HELO seas.upenn.edu) (193.136.7.131) by atlas.fccn.pt with SMTP; 29 Jul 2003 10:40:38 -0000 Message-ID: <3F264E16.5020803@seas.upenn.edu> Date: Tue, 29 Jul 2003 11:36:06 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 To: Gert Doering CC: v6ops@ops.ietf.org Subject: Re: Automatic tunnels References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> <20030729122426.G67740@Space.Net> In-Reply-To: <20030729122426.G67740@Space.Net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Gert, >Operational errors (like "wrong IP address configured on interface" or >"routing protocol configuration things" or "correct v4 address in DNS but >v6 address wrong" or so) hit in quite surprising ways - you test, you >run traceroute and ping, all looks fine, and then you realize that you >traceroute'd only v4 while v6 is broken, or vice versa. > > Most operational errors are because ISPs do not have guidelines on how to deploy IPv6. It is quite a big task, given that everything has to be changed and somehow, the connectivity should be kept at any cost. Added to that, there's the addressing space allocation... Also, this is still a field where in operational terms there is still room to do a lot. It took us almost 5 years ;-) to complete the transition to dual-stack, mostly because the equipment did not fully behave as it should. So, in fact we had to acquire different equipment, and not only upgrade software. But, we're a non-commercial ISP. It is obviously harder for a commercial ISP to justify a full upgrade to the bakbone. But, given that we are speaking of dual-stack and not of IPv6-only ;-), it should not be such a big fuss, given that in the worst-case, it can still run as IPv4 ;-) Rute From owner-v6ops@ops.ietf.org Tue Jul 29 06:45: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 GAA17996 for ; Tue, 29 Jul 2003 06:45:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hRyh-0002s2-Ta for v6ops-data@psg.com; Tue, 29 Jul 2003 10:45:11 +0000 Received: from [193.6.222.240] (helo=mignon.ki.iif.hu) by psg.com with esmtp (Exim 4.20) id 19hRyf-0002rh-KB for v6ops@ops.ietf.org; Tue, 29 Jul 2003 10:45:09 +0000 Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id ACEE75D67; Tue, 29 Jul 2003 12:45:08 +0200 (CEST) Received: from mignon.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68487-04; Tue, 29 Jul 2003 12:45:06 +0200 (CEST) Received: by mignon.ki.iif.hu (Postfix, from userid 1003) id D97895610; Tue, 29 Jul 2003 12:45:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mignon.ki.iif.hu (Postfix) with ESMTP id D46A554C8; Tue, 29 Jul 2003 12:45:06 +0200 (CEST) Date: Tue, 29 Jul 2003 12:45:06 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Kurt Erik Lindqvist Cc: Tim Chown , v6ops@ops.ietf.org Subject: Re: Automatic tunnels In-Reply-To: Message-ID: <20030729121511.Y64439@mignon.ki.iif.hu> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 29 Jul 2003, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> The alternative is dual-stack, but if I would be a carrier I would be > >> very reluctant to roll-out dual-stack software (or at least to > >> activate > >> it) on my routers. > > > > I'm curious, what do you see as the main reasons for this? > > > > Experience? :-) The two vendors have enough of a problem to get v4 > packets from interface A to interface B, and that is with customers > that are paying for SLAs... > > I know it's being done and on pretty large networks as well. But I also > hear people that are having problems in doing so. You can look at several examples in Europe. GEANT, SURFNET or RENATER already dual stacked. They have rather large network. I am sure, that they had slight problems running dual-stack in the beginning, but they run successfully now. On the other hand for example at HUNGARNET we also have rather large IPv6 network, but currently we cannot run dual stack since there is no IPv6 support at all for large number of our routers (Cisco 7600). It seems, that we have to find alternative solution... Regards, Janos Mohacsi From owner-v6ops@ops.ietf.org Tue Jul 29 06:49: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 GAA18098 for ; Tue, 29 Jul 2003 06:49:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hS2F-0003G2-Vk for v6ops-data@psg.com; Tue, 29 Jul 2003 10:48:51 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.20) id 19hS2D-0003Fn-JB for v6ops@ops.ietf.org; Tue, 29 Jul 2003 10:48:50 +0000 Received: (qmail 63360 invoked by uid 2502); 29 Jul 2003 10:48:48 -0000 Received: from rsofia@seas.upenn.edu by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.114455 secs); 29/07/2003 11:48:48 Received: from dhcp01.fccn.pt (HELO seas.upenn.edu) (193.136.7.131) by atlas.fccn.pt with SMTP; 29 Jul 2003 10:48:47 -0000 Message-ID: <3F264FFF.4090600@seas.upenn.edu> Date: Tue, 29 Jul 2003 11:44:15 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 To: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: Automatic tunnels References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> <20030729122426.G67740@Space.Net> <20030729103810.GV21531@login.ecs.soton.ac.uk> In-Reply-To: <20030729103810.GV21531@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-23.2 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTE_TWICE_1,REFERENCES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > >There are many networks that have gone dual stack, so what you're saying >is we need more operational experience feedback of the problems, rather >than just the success stories. The early adoptors are the US and European >research networks and backbones. I think they've been instrumental in >helping Cisco, Juniper et al iron out many of the problems to make >deployment less problematic (but by no means straightforward) for ISPs. > > > Completely agree. NRENs are in the group of ISPs with more IPv6 experience. And, it is a fact that this helped vendors to tackle problems. Also, given that NRENs are quite different in topology and equipment, their experience will for sure be benefitial as an example on how to deploy IPv6 for other ISPs... Rute From owner-v6ops@ops.ietf.org Tue Jul 29 07:08: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 HAA18402 for ; Tue, 29 Jul 2003 07:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSL5-0005QH-EO for v6ops-data@psg.com; Tue, 29 Jul 2003 11:08:19 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hSL3-0005Q4-3Y for v6ops@ops.ietf.org; Tue, 29 Jul 2003 11:08:17 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6TB8JFJ006116; Tue, 29 Jul 2003 13:08:20 +0200 (CEST) Date: Tue, 29 Jul 2003 13:08:13 +0200 Subject: Re: Automatic tunnels Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Tim Chown , v6ops@ops.ietf.org To: Rute Sofia From: Kurt Erik Lindqvist In-Reply-To: <3F264FFF.4090600@seas.upenn.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> There are many networks that have gone dual stack, so what you're >> saying >> is we need more operational experience feedback of the problems, >> rather >> than just the success stories. The early adoptors are the US and >> European >> research networks and backbones. I think they've been instrumental >> in >> helping Cisco, Juniper et al iron out many of the problems to make >> deployment less problematic (but by no means straightforward) for >> ISPs. >> >> > Completely agree. NRENs are in the group of ISPs with more IPv6 > experience. And, it is a fact that this helped vendors to tackle > problems. Also, given that NRENs are quite different in topology and > equipment, their experience will for sure be benefitial as an example > on how to deploy IPv6 for other ISPs... There is also the fact that NRENs does not have to generate ROI for their deployment, while many ISPs are struggling to do ROI on IPv4. Which again is a driver for a step-by-step approach. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyZVoKarNKXTPFCVEQINrQCg7hFykx+OCVbweS132TfdUBkWJmMAoLwC goAvhR1IFUnbCSEVmTwxPWXa =25Hu -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Tue Jul 29 07:16: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 HAA18619 for ; Tue, 29 Jul 2003 07:16:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hSSq-0006BV-6P for v6ops-data@psg.com; Tue, 29 Jul 2003 11:16:20 +0000 Received: from [193.136.7.1] (helo=atlas.fccn.pt) by psg.com with smtp (Exim 4.20) id 19hSSm-0006B2-EZ for v6ops@ops.ietf.org; Tue, 29 Jul 2003 11:16:16 +0000 Received: (qmail 84355 invoked by uid 2502); 29 Jul 2003 11:16:15 -0000 Received: from rsofia@seas.upenn.edu by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.124746 secs); 29/07/2003 12:16:14 Received: from dhcp01.fccn.pt (HELO seas.upenn.edu) (193.136.7.131) by atlas.fccn.pt with SMTP; 29 Jul 2003 11:16:14 -0000 Message-ID: <3F26566D.9020302@seas.upenn.edu> Date: Tue, 29 Jul 2003 12:11:41 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Tim Chown , v6ops@ops.ietf.org Subject: Re: Automatic tunnels References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurtis, >>uipment, their experience will for sure be benefitial as an example >>on how to deploy IPv6 for other ISPs... >> >> > >There is also the fact that NRENs does not have to generate ROI for >their deployment, while many ISPs are struggling to do ROI on IPv4. >Which again is a driver for a step-by-step approach. > > > It is a fact that NRENs are non-profit organizations, but they do have to justify where the money goes ;-), whether we speak of v4, v6, services and so on. So, there is always a need for a ROI, independently of the technology... Anyway, this is possibly off-topic ;-). AS for the online topic I believe we all agree that: 1) the transition takes a long time, requires some investment, and the profit is still not clear (in commercial terms, of course...) 2) there are still lots of issues with the equipment and software used; 3) a step-by-step approach is necessary 4) feedback from ISPs (whether they are commercial or not) is required, so others can more easily deploy IPv6... 5) feedback from ISPs to vendors is also required, so problems can be solved... Rute Rute From owner-v6ops@ops.ietf.org Tue Jul 29 08:48: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 IAA21294 for ; Tue, 29 Jul 2003 08:48:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTpR-000DxG-Pg for v6ops-data@psg.com; Tue, 29 Jul 2003 12:43:45 +0000 Received: from [193.81.246.11] (helo=eins.siemens.at) by psg.com with esmtp (Exim 4.20) id 19hTpP-000Dw4-5U for v6ops@ops.ietf.org; Tue, 29 Jul 2003 12:43:43 +0000 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h6TChgcJ011208 for ; Tue, 29 Jul 2003 14:43:42 +0200 Received: from zagh102a.zag.siemens.hr (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h6TChemv017109 for ; Tue, 29 Jul 2003 14:43:41 +0200 (MET DST) Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 14:42:10 +0200 Message-ID: From: Bilajbegovic Damir To: v6ops@ops.ietf.org Subject: PDP context and IPv4/6 Date: Tue, 29 Jul 2003 14:40:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I am working on IMS, on transition of IPv4 to IPv6, and I need help. Where can I find explained process of activation PDP context, depending on IP version. If you know some file or link, I would be grateful. Thanks in advance Damir Bilajbegovic From owner-v6ops@ops.ietf.org Tue Jul 29 08:49: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 IAA21343 for ; Tue, 29 Jul 2003 08:49:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hTuy-000EPy-1o for v6ops-data@psg.com; Tue, 29 Jul 2003 12:49:28 +0000 Received: from [47.103.122.112] (helo=zrc2s0jx.nortelnetworks.com) by psg.com with esmtp (Exim 4.20) id 19hTuv-000EPh-QP for v6ops@ops.ietf.org; Tue, 29 Jul 2003 12:49:25 +0000 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6TCnLd01960; Tue, 29 Jul 2003 07:49:21 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T65FH>; Tue, 29 Jul 2003 07:49:21 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF648755@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Bilajbegovic Damir'" , v6ops@ops.ietf.org Subject: RE: PDP context and IPv4/6 Date: Tue, 29 Jul 2003 07:49:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C355CF.D174B024" X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_10,HTML_40_50,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C355CF.D174B024 Content-Type: text/plain; charset="iso-8859-1" Look at 3GPP specifications 3G TS 29.061 and 3G TS 23.060. Pete -----Original Message----- From: Bilajbegovic Damir [mailto:damir.bilajbegovic@siemens.com] Sent: Tuesday, July 29, 2003 7:40 AM To: v6ops@ops.ietf.org Subject: PDP context and IPv4/6 Hi, I am working on IMS, on transition of IPv4 to IPv6, and I need help. Where can I find explained process of activation PDP context, depending on IP version. If you know some file or link, I would be grateful. Thanks in advance Damir Bilajbegovic ------_=_NextPart_001_01C355CF.D174B024 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PDP context and IPv4/6

Look at 3GPP specifications 3G TS 29.061 and 3G TS = 23.060.

Pete

-----Original Message-----
From: Bilajbegovic Damir [mailto:damir.bilajbegovic= @siemens.com]
Sent: Tuesday, July 29, 2003 7:40 AM
To: v6ops@ops.ietf.org
Subject: PDP context and IPv4/6


Hi,
    I am working on IMS, on = transition of IPv4 to IPv6, and I need help.
    Where can I find explained = process of activation PDP context, depending
on IP version.
    If you know some file or link, I = would be grateful.
         = Thanks in advance
          &nb= sp;           &nb= sp;        Damir Bilajbegovic =
          &nb= sp;        

------_=_NextPart_001_01C355CF.D174B024-- From owner-v6ops@ops.ietf.org Tue Jul 29 09:21: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 JAA22096 for ; Tue, 29 Jul 2003 09:21:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hUPO-000HaY-Tz for v6ops-data@psg.com; Tue, 29 Jul 2003 13:20:54 +0000 Received: from [193.81.246.11] (helo=eins.siemens.at) by psg.com with esmtp (Exim 4.20) id 19hUPL-000HaH-1P for v6ops@ops.ietf.org; Tue, 29 Jul 2003 13:20:51 +0000 Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id h6TDKhcJ017704; Tue, 29 Jul 2003 15:20:43 +0200 Received: from zagh102a.zag.siemens.hr (atws15tc.sie.siemens.at [158.226.135.41]) by scesie13.sie.siemens.at (8.12.9/8.12.1) with ESMTP id h6TDKfmv014554; Tue, 29 Jul 2003 15:20:42 +0200 (MET DST) Received: by zagh102a.zag.siemens.hr with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jul 2003 15:19:11 +0200 Message-ID: From: Bilajbegovic Damir To: Peter Barany , v6ops@ops.ietf.org Subject: RE: PDP context and IPv4/6 Date: Tue, 29 Jul 2003 15:19:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C355D3.FC6A9650" X-Spam-Status: No, hits=-11.7 required=5.0 tests=BAYES_10,HTML_40_50,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C355D3.FC6A9650 Content-Type: text/plain; charset="iso-8859-1" Hi, thanks for your answer. I have I more question, If you maybe know the answer. If UE is dual-stack, is there a way that UE can say to IMS that it is dual-stack? If you know some file or link, I would be grateful. Thanks in advance Damir Bilajbegovic -----Original Message----- From: Peter Barany [mailto:pbarany@nortelnetworks.com] Sent: Tuesday, July 29, 2003 2:49 PM To: 'Bilajbegovic Damir'; v6ops@ops.ietf.org Subject: RE: PDP context and IPv4/6 Look at 3GPP specifications 3G TS 29.061 and 3G TS 23.060. Pete -----Original Message----- From: Bilajbegovic Damir [ mailto:damir.bilajbegovic@siemens.com ] Sent: Tuesday, July 29, 2003 7:40 AM To: v6ops@ops.ietf.org Subject: PDP context and IPv4/6 Hi, I am working on IMS, on transition of IPv4 to IPv6, and I need help. Where can I find explained process of activation PDP context, depending on IP version. If you know some file or link, I would be grateful. Thanks in advance Damir Bilajbegovic ------_=_NextPart_001_01C355D3.FC6A9650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PDP context and IPv4/6
Hi,
      thanks for your answer. I = have I more question, If you maybe know the = answer. If UE=20 is dual-stack, is there a way that UE can say to IMS that it is=20 dual-stack?
      If you know some file or link, I would be grateful. =
         Thanks in=20 advance =
          &nb= sp;           &nb= sp;       =20 Damir Bilajbegovic
-----Original Message-----
From: Peter Barany=20 [mailto:pbarany@nortelnetworks.com]
Sent: Tuesday, July 29, = 2003=20 2:49 PM
To: 'Bilajbegovic Damir';=20 v6ops@ops.ietf.org
Subject: RE: PDP context and=20 IPv4/6

Look at 3GPP specifications 3G TS 29.061 and 3G TS=20 23.060.

Pete

-----Original Message-----
From:=20 Bilajbegovic Damir [mailto:damir.bilajbegovic= @siemens.com]=20
Sent: Tuesday, July 29, 2003 7:40 AM =
To: v6ops@ops.ietf.org
Subject: = PDP context and=20 IPv4/6


Hi,
    I = am working on=20 IMS, on transition of IPv4 to IPv6, and I need help.
    Where can I find explained process of = activation PDP=20 context, depending
on IP version. =
    If you know some file or link, I would be = grateful.=20
        =20 Thanks in advance
          &nb= sp;           &nb= sp;       =20 Damir Bilajbegovic
          &nb= sp;        =20

------_=_NextPart_001_01C355D3.FC6A9650-- From owner-v6ops@ops.ietf.org Tue Jul 29 10:37: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 KAA25013 for ; Tue, 29 Jul 2003 10:37:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hVZf-000NgY-M2 for v6ops-data@psg.com; Tue, 29 Jul 2003 14:35:35 +0000 Received: from [47.103.122.112] (helo=zrc2s0jx.nortelnetworks.com) by psg.com with esmtp (Exim 4.20) id 19hVZd-000NgM-2L for v6ops@ops.ietf.org; Tue, 29 Jul 2003 14:35:33 +0000 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6TEZTd25590; Tue, 29 Jul 2003 09:35:29 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T673S>; Tue, 29 Jul 2003 09:35:29 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF648758@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Bilajbegovic Damir'" , v6ops@ops.ietf.org Subject: RE: PDP context and IPv4/6 Date: Tue, 29 Jul 2003 09:35:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C355DE.A7424668" X-Spam-Status: No, hits=-12.4 required=5.0 tests=BAYES_01,HTML_40_50,HTML_FONT_COLOR_BLUE,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C355DE.A7424668 Content-Type: text/plain; charset="iso-8859-1" If you are still talking about 3GPP/UMTS, IMS is IPv6-only. Pete -----Original Message----- From: Bilajbegovic Damir [mailto:damir.bilajbegovic@siemens.com] Sent: Tuesday, July 29, 2003 8:19 AM To: Barany, Peter [RICH1:2H16:EXCH]; v6ops@ops.ietf.org Subject: RE: PDP context and IPv4/6 Hi, thanks for your answer. I have I more question, If you maybe know the answer. If UE is dual-stack, is there a way that UE can say to IMS that it is dual-stack? If you know some file or link, I would be grateful. Thanks in advance Damir Bilajbegovic -----Original Message----- From: Peter Barany [mailto:pbarany@nortelnetworks.com] Sent: Tuesday, July 29, 2003 2:49 PM To: 'Bilajbegovic Damir'; v6ops@ops.ietf.org Subject: RE: PDP context and IPv4/6 Look at 3GPP specifications 3G TS 29.061 and 3G TS 23.060. Pete -----Original Message----- From: Bilajbegovic Damir [ mailto:damir.bilajbegovic@siemens.com ] Sent: Tuesday, July 29, 2003 7:40 AM To: v6ops@ops.ietf.org Subject: PDP context and IPv4/6 Hi, I am working on IMS, on transition of IPv4 to IPv6, and I need help. Where can I find explained process of activation PDP context, depending on IP version. If you know some file or link, I would be grateful. Thanks in advance Damir Bilajbegovic ------_=_NextPart_001_01C355DE.A7424668 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PDP context and IPv4/6
If you=20 are still talking about 3GPP/UMTS, IMS is = IPv6-only.
 
Pete
-----Original Message-----
From: Bilajbegovic = Damir=20 [mailto:damir.bilajbegovic@siemens.com]
Sent: Tuesday, July = 29, 2003=20 8:19 AM
To: Barany, Peter [RICH1:2H16:EXCH];=20 v6ops@ops.ietf.org
Subject: RE: PDP context and=20 IPv4/6

Hi,
      thanks for your answer. I = have I more question, If you maybe know the = answer. If=20 UE is dual-stack, is there a way that UE can say to IMS that it is=20 dual-stack?
      If you know some file or link, I would be grateful. =
         Thanks in=20 advance =
          &nb= sp;           &nb= sp;       =20 Damir Bilajbegovic =
-----Original Message-----
From: Peter Barany=20 [mailto:pbarany@nortelnetworks.com]
Sent: Tuesday, July = 29, 2003=20 2:49 PM
To: 'Bilajbegovic Damir';=20 v6ops@ops.ietf.org
Subject: RE: PDP context and=20 IPv4/6

Look at 3GPP specifications 3G TS 29.061 and 3G = TS=20 23.060.

Pete

-----Original Message-----
From:=20 Bilajbegovic Damir [mailto:damir.bilajbegovic= @siemens.com]=20
Sent: Tuesday, July 29, 2003 7:40 AM =
To: v6ops@ops.ietf.org
Subject: = PDP context=20 and IPv4/6


Hi,
    = I am working=20 on IMS, on transition of IPv4 to IPv6, and I need help. =
    Where can I find explained process of = activation=20 PDP context, depending
on IP = version.=20
    If you know some file or = link, I would=20 be grateful.
         Thanks in = advance
          &nb= sp;           &nb= sp;       =20 Damir Bilajbegovic
          &nb= sp;        =20

------_=_NextPart_001_01C355DE.A7424668-- From owner-v6ops@ops.ietf.org Tue Jul 29 10:48: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 KAA25318 for ; Tue, 29 Jul 2003 10:48:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hVlb-000Oah-9I for v6ops-data@psg.com; Tue, 29 Jul 2003 14:47:55 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19hVlY-000OaU-OA for v6ops@ops.ietf.org; Tue, 29 Jul 2003 14:47:52 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hVlW-000GbM-69; Tue, 29 Jul 2003 07:47:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 2003 07:47:49 -0700 To: Kurt Erik Lindqvist Cc: "JORDI PALET MARTINEZ" , Subject: Re: Automatic tunnels References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The alternative is dual-stack, but if I would be a carrier I would be > very reluctant to roll-out dual-stack software (or at least to activate > it) on my routers. i guess that depends on whether you are locked into a router vendor who lacks support of ipv6 in their hardware. randy From owner-v6ops@ops.ietf.org Tue Jul 29 10:52: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 KAA25394 for ; Tue, 29 Jul 2003 10:52:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hVpp-000Oyk-3q for v6ops-data@psg.com; Tue, 29 Jul 2003 14:52:17 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19hVpn-000OyX-E7 for v6ops@ops.ietf.org; Tue, 29 Jul 2003 14:52:15 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hVpj-000Gj1-R6; Tue, 29 Jul 2003 07:52:11 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 2003 07:52:11 -0700 To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: Automatic tunnels References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> <20030729122426.G67740@Space.Net> <20030729103810.GV21531@login.ecs.soton.ac.uk> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The early adoptors are the US and European research networks and > backbones. rofl! From owner-v6ops@ops.ietf.org Tue Jul 29 11:25: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 LAA26239 for ; Tue, 29 Jul 2003 11:25:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hWKb-0001jm-Ke for v6ops-data@psg.com; Tue, 29 Jul 2003 15:24:05 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.20) id 19hWKV-0001jR-4F for v6ops@ops.ietf.org; Tue, 29 Jul 2003 15:23:59 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA11615 for ; Tue, 29 Jul 2003 16:23:57 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id QAA03981 for ; Tue, 29 Jul 2003 16:23:56 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6TFNuk28261 for v6ops@ops.ietf.org; Tue, 29 Jul 2003 16:23:56 +0100 Date: Tue, 29 Jul 2003 16:23:56 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Automatic tunnels Message-ID: <20030729152356.GD27769@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> <20030729122426.G67740@Space.Net> <20030729103810.GV21531@login.ecs.soton.ac.uk> 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=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 29, 2003 at 07:52:11AM -0700, Randy Bush wrote: > > The early adoptors are the US and European research networks and > > backbones. > > rofl! So what exactly is laughable about research networks deploying IPv6? Tim From owner-v6ops@ops.ietf.org Tue Jul 29 11:31: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 LAA26340 for ; Tue, 29 Jul 2003 11:31:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hWRG-0002DK-F3 for v6ops-data@psg.com; Tue, 29 Jul 2003 15:30:58 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19hWRE-0002D7-B9 for v6ops@ops.ietf.org; Tue, 29 Jul 2003 15:30:56 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hWRE-000Hjr-0i; Tue, 29 Jul 2003 08:30:56 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 2003 08:30:55 -0700 To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: Automatic tunnels References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> <20030729122426.G67740@Space.Net> <20030729103810.GV21531@login.ecs.soton.ac.uk> <20030729152356.GD27769@login.ecs.soton.ac.uk> Message-Id: X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> The early adoptors are the US and European research networks and >>> backbones. >> rofl! > So what exactly is laughable about research networks deploying IPv6? what is amusing is ignoring the research and *commercial* deployment in asia. randy From owner-v6ops@ops.ietf.org Tue Jul 29 11:35:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26530 for ; Tue, 29 Jul 2003 11:35:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hWVh-0002hZ-Jm for v6ops-data@psg.com; Tue, 29 Jul 2003 15:35:33 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.20) id 19hWVf-0002gz-72 for v6ops@ops.ietf.org; Tue, 29 Jul 2003 15:35:31 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA11985 for ; Tue, 29 Jul 2003 16:35:29 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id QAA04322 for ; Tue, 29 Jul 2003 16:35:29 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6TFZTi28464 for v6ops@ops.ietf.org; Tue, 29 Jul 2003 16:35:29 +0100 Date: Tue, 29 Jul 2003 16:35:29 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Automatic tunnels Message-ID: <20030729153529.GI27769@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <01f501c35208$5ad99210$870a0a0a@consulintel.es> <679A4C54-C1A5-11D7-958B-000393A638B2@kurtis.pp.se> <20030729092310.GM21531@login.ecs.soton.ac.uk> <20030729122426.G67740@Space.Net> <20030729103810.GV21531@login.ecs.soton.ac.uk> <20030729152356.GD27769@login.ecs.soton.ac.uk> 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=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Jul 29, 2003 at 08:30:55AM -0700, Randy Bush wrote: > >>> The early adoptors are the US and European research networks and > >>> backbones. > >> rofl! > > So what exactly is laughable about research networks deploying IPv6? > > what is amusing is ignoring the research and *commercial* deployment > in asia. Oh, OK, well that's a fair point - I thought you were suggesting something else :) Is there a good reference on what the commercial deployments in Asia are running, the services offered, number of end users etc? Would be good to see some info to learn from. Tim From owner-v6ops@ops.ietf.org Tue Jul 29 15:20:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06288 for ; Tue, 29 Jul 2003 15:20:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hZzW-000KYL-Bw for v6ops-data@psg.com; Tue, 29 Jul 2003 19:18:34 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19hZzT-000KY6-Ll for v6ops@ops.ietf.org; Tue, 29 Jul 2003 19:18:31 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 29 Jul 2003 15:18:30 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF41@ftmail.lab.flarion.com> From: Tsirtsis George To: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Cc: Soliman Hesham , "'Thomas Narten'" Subject: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt Date: Tue, 29 Jul 2003 15:17:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C35606.1B821BD0" X-Spam-Status: No, hits=-9.4 required=5.0 tests=BAYES_20,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C35606.1B821BD0 Content-Type: text/plain Hi all, During the Mobile IP WG meeting in Austria, Hesham and myself brought up the issue of mobility management for dual stack nodes. Thomas N. requested that we put together a problem statement so that we can discuss the issue; the draft below was published today - it is short and I hope to the point - so do read it :) I have copied v6ops since I think this is a v4 - v6 migration issue as well as Mobile IPv4 and Mobile IPv6 issue. Let us know what you think. George -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 29, 2003 5:15 PM Subject: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility management for Dual stack mobile nodes A Problem Statement Author(s) : G. Tsirtsis, H. Soliman Filename : draft-tsirtsis-dsmip-problem-00.txt Pages : 4 Date : 2003-7-29 This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of inefficiencies. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also hints on how current MIPv4 and MIPv6 could be extended so that they can support mobility management for a dual stack node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-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-tsirtsis-dsmip-problem-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-tsirtsis-dsmip-problem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C35606.1B821BD0 Content-Type: message/rfc822 To: Subject: Date: Tue, 29 Jul 2003 12:40:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C35606.1B821BD0" ------_=_NextPart_002_01C35606.1B821BD0 Content-Type: text/plain ------_=_NextPart_002_01C35606.1B821BD0 Content-Type: application/octet-stream; name="ATT19898.txt" Content-Disposition: attachment; filename="ATT19898.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-29122629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tsirtsis-dsmip-problem-00.txt ------_=_NextPart_002_01C35606.1B821BD0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-tsirtsis-dsmip-problem-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C35606.1B821BD0-- ------_=_NextPart_000_01C35606.1B821BD0-- From owner-v6ops@ops.ietf.org Tue Jul 29 19:24: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 TAA15063 for ; Tue, 29 Jul 2003 19:24:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hdmN-000Bmj-Uz for v6ops-data@psg.com; Tue, 29 Jul 2003 23:21:15 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.20) id 19hdmJ-000Bm7-1U for v6ops@ops.ietf.org; Tue, 29 Jul 2003 23:21:11 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6TNLApO020387 for ; Tue, 29 Jul 2003 17:21:10 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIT00MZR7J9U4@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 29 Jul 2003 17:21:10 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIT00IDO7J7P6@mail.sun.net> for v6ops@ops.ietf.org; Tue, 29 Jul 2003 17:21:09 -0600 (MDT) Date: Tue, 29 Jul 2003 16:23:17 -0700 From: Alain Durand Subject: Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt In-reply-to: <748C6D0A58C0F94CA63C198B6674697A0BFF41@ftmail.lab.flarion.com> To: Tsirtsis George Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi George, Thank you for writing this draft, this is an interesting perspective. There is one point you do not mention: what if the IPv6 node is using directly or indirectly IPv6 in IPv4 tunnels for its IPv6 connectivity? For example, it may derive a 6to4 prefix from its home address and then uses MIPv4.... There are extra complexities here that I'm not sure I fully understand. Is it a problem space that you intend to cover? - Alain. On Tuesday, July 29, 2003, at 12:17 PM, Tsirtsis George wrote: > Hi all, > > During the Mobile IP WG meeting in Austria, Hesham and myself brought > up the > issue of mobility management for dual stack nodes. > > Thomas N. requested that we put together a problem statement so that > we can > discuss the issue; the draft below was published today - it is short > and I > hope to the point - so do read it :) > > I have copied v6ops since I think this is a v4 - v6 migration issue as > well > as Mobile IPv4 and Mobile IPv6 issue. > > Let us know what you think. > > George > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, July 29, 2003 5:15 PM > Subject: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Mobility management for Dual stack mobile nodes A > > Problem Statement > Author(s) : G. Tsirtsis, H. Soliman > Filename : draft-tsirtsis-dsmip-problem-00.txt > Pages : 4 > Date : 2003-7-29 > > This draft discusses the issues associated with mobility management > for dual stack mobile nodes. Currently, two mobility management > protocols are defined for IPv4 and IPv6. Deploying both in a dual > stack mobile node introduces a number of inefficiencies. Deployment > and operational issues motivate the use of a single mobility > management protocol. This draft discusses such motivations. The draft > also hints on how current MIPv4 and MIPv6 could be extended so that > they can support mobility management for a dual stack node. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-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-tsirtsis-dsmip-problem-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-tsirtsis-dsmip-problem-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. > > > Date: Tue Jul 29, 2003 9:40:01 AM US/Pacific > To: > Subject: > > > > > From owner-v6ops@ops.ietf.org Tue Jul 29 19:25: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 TAA15087 for ; Tue, 29 Jul 2003 19:25:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hdq5-000C1x-29 for v6ops-data@psg.com; Tue, 29 Jul 2003 23:25:05 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.20) id 19hdq1-000C14-Iy for v6ops@ops.ietf.org; Tue, 29 Jul 2003 23:25:01 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 935D096; Wed, 30 Jul 2003 08:24:59 +0900 (JST) To: Tim Chown Cc: v6ops@ops.ietf.org In-reply-to: tjc's message of Tue, 29 Jul 2003 16:35:29 +0100. <20030729153529.GI27769@login.ecs.soton.ac.uk> 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: Automatic tunnels From: itojun@iijlab.net Date: Wed, 30 Jul 2003 08:24:59 +0900 Message-Id: <20030729232459.935D096@coconut.itojun.org> X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Is there a good reference on what the commercial deployments in Asia are >running, the services offered, number of end users etc? Would be good >to see some info to learn from. contact info@v6pc.jp (or www.v6pc.jp), they may have comprehensive tables/stats. itojun From owner-v6ops@ops.ietf.org Wed Jul 30 03:56:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23111 for ; Wed, 30 Jul 2003 03:56:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hlnY-000L0M-NC for v6ops-data@psg.com; Wed, 30 Jul 2003 07:55:00 +0000 Received: from [192.71.80.74] (helo=adsl-2-173.aland.net) by psg.com with esmtp (Exim 4.20) id 19hlnW-000Kzv-3K; Wed, 30 Jul 2003 07:54:58 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U7sxFJ006644; Wed, 30 Jul 2003 09:55:00 +0200 (CEST) Date: Wed, 30 Jul 2003 09:54:55 +0200 Subject: Re: Automatic tunnels Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: "JORDI PALET MARTINEZ" , To: Randy Bush From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <1C00A8E0-C263-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_01,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> The alternative is dual-stack, but if I would be a carrier I would be >> very reluctant to roll-out dual-stack software (or at least to >> activate >> it) on my routers. > > i guess that depends on whether you are locked into a router vendor > who lacks support of ipv6 in their hardware. To some extent , yes. Or what the cost of getting that hardware is. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyd50aarNKXTPFCVEQKtzwCfd2fs5R10H8gC1RAHLjiSpmWpeMUAn2WU xucA2Ihb0znJr/Xhltj3z/DF =0Umg -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Jul 30 04:49: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 EAA24123 for ; Wed, 30 Jul 2003 04:49:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hmdO-000O7x-Je for v6ops-data@psg.com; Wed, 30 Jul 2003 08:48:34 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19hmdL-000O7k-MM for v6ops@ops.ietf.org; Wed, 30 Jul 2003 08:48:31 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Jul 2003 04:48:31 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF49@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Alain Durand'" Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Wed, 30 Jul 2003 04:48:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, For mobility a node needs a stable address i.e. the Home Address (HoA). All communications are directed to that HoA and a Home Agent (HA) intercepts and forwards to the node's care-of-address (CoA). Now how the Mobile node comes to own a given HoA is not so important from this perspective. It could be native v6 or it could be 6to4...I do not think it matters as long as there is an HA that can intercept packets sent to that HoA and forward them to the CoA. Now, when the mobile is not at home but in some other network, there is an issue about what kind of v4/v6 support there is in the foreign network. The nice thing about Mobile IP is that it is based on tunnels and thus it provides natural way of tunneling over networks that are not compatible with the mobile ...if only Mobile IP could configure v4 over v6 and v6 over v4 tunnels (as opposed to just v4 over v4 and v6 over v6 tunnels). A dual stack mobile in a v4 only foreign network would then be able to create a v4&v6 over v4 (forward and reverse) tunnel with its HA and thus maintain all its connectivity. George -----Original Message----- From: Alain Durand [mailto:Alain.Durand@Sun.COM] Sent: Wednesday, July 30, 2003 12:23 AM To: Tsirtsis George Cc: Mobile-Ip (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org; Soliman Hesham; 'Thomas Narten' Subject: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt Hi George, Thank you for writing this draft, this is an interesting perspective. There is one point you do not mention: what if the IPv6 node is using directly or indirectly IPv6 in IPv4 tunnels for its IPv6 connectivity? For example, it may derive a 6to4 prefix from its home address and then uses MIPv4.... There are extra complexities here that I'm not sure I fully understand. Is it a problem space that you intend to cover? - Alain. On Tuesday, July 29, 2003, at 12:17 PM, Tsirtsis George wrote: > Hi all, > > During the Mobile IP WG meeting in Austria, Hesham and myself brought > up the > issue of mobility management for dual stack nodes. > > Thomas N. requested that we put together a problem statement so that > we can > discuss the issue; the draft below was published today - it is short > and I > hope to the point - so do read it :) > > I have copied v6ops since I think this is a v4 - v6 migration issue as > well > as Mobile IPv4 and Mobile IPv6 issue. > > Let us know what you think. > > George > > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, July 29, 2003 5:15 PM > Subject: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Mobility management for Dual stack mobile nodes A > > Problem Statement > Author(s) : G. Tsirtsis, H. Soliman > Filename : draft-tsirtsis-dsmip-problem-00.txt > Pages : 4 > Date : 2003-7-29 > > This draft discusses the issues associated with mobility management > for dual stack mobile nodes. Currently, two mobility management > protocols are defined for IPv4 and IPv6. Deploying both in a dual > stack mobile node introduces a number of inefficiencies. Deployment > and operational issues motivate the use of a single mobility > management protocol. This draft discusses such motivations. The draft > also hints on how current MIPv4 and MIPv6 could be extended so that > they can support mobility management for a dual stack node. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-00.tx > t > > 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-tsirtsis-dsmip-problem-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-tsirtsis-dsmip-problem-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. > > > Date: Tue Jul 29, 2003 9:40:01 AM US/Pacific > To: > Subject: > > > > > From owner-v6ops@ops.ietf.org Wed Jul 30 05:28:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24907 for ; Wed, 30 Jul 2003 05:28:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hnCI-0000KN-15 for v6ops-data@psg.com; Wed, 30 Jul 2003 09:24:38 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.20) id 19hnCB-0000K6-5Q for v6ops@ops.ietf.org; Wed, 30 Jul 2003 09:24:31 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6U9OMl19177; Wed, 30 Jul 2003 11:24:22 +0200 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 h6U9Nmof001176; Wed, 30 Jul 2003 11:23:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307300923.h6U9Nmof001176@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tsirtsis George cc: "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-reply-to: Your message of Wed, 30 Jul 2003 04:48:20 EDT. <748C6D0A58C0F94CA63C198B6674697A0BFF49@ftmail.lab.flarion.com> Date: Wed, 30 Jul 2003 11:23:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: ... A dual stack mobile in a v4 only foreign network would then be able to create a v4&v6 over v4 (forward and reverse) tunnel with its HA and thus maintain all its connectivity. => as a cross-version tunnel will never be "optimized" (i.e., MN-CN direct communication is not possible), IMHO mobile-ip solutions are clearly overkilling in this kind of environments: a smart "road warrior" IPsec VPN will be enough. Today two parts are missing: - cross-version IPsec tunnels are not commonly available (note for IPsec implementors: they are specified in RFC 2401, why do you not support them?) - a peer address (aka care-of address here) update mechanism is needed to make hand-off support more efficient. I don't consider the side-effect to get communications protected on the wireless section as bad (:-). Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Jul 30 07:19:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26934 for ; Wed, 30 Jul 2003 07:19:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hoxp-0007Ed-BF for v6ops-data@psg.com; Wed, 30 Jul 2003 11:17:49 +0000 Received: from [209.228.32.127] (helo=c001.snv.cp.net) by psg.com with smtp (Exim 4.20) id 19hoxm-0007EQ-UT for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:17:46 +0000 Received: (cpmta 9188 invoked from network); 30 Jul 2003 03:17:44 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 30 Jul 2003 03:17:44 -0700 X-Sent: 30 Jul 2003 10:17:44 GMT Message-ID: <001101c35683$d7601a50$03051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: , References: <200307300923.h6U9Nmof001176@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Wed, 30 Jul 2003 13:17:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit From: "Francis Dupont" > => as a cross-version tunnel will never be "optimized" (i.e., MN-CN direct > communication is not possible), IMHO mobile-ip solutions are clearly > overkilling in this kind of environments: a smart "road warrior" IPsec > VPN will be enough. Today two parts are missing: > - cross-version IPsec tunnels are not commonly available (note for > IPsec implementors: they are specified in RFC 2401, why do you not > support them?) Are you recommending that all mobile phone operators should create IP VPN's for all phones on their network and to maintain them for visitors and roamers on other networks? This sounds like a lot of IP VPNs to create and maintain across multiple networks for people who roam, and unnecessary for those that don't. We are not talking dial-up users or even data users, jut straight 3G, GPRS, or WAP users. From owner-v6ops@ops.ietf.org Wed Jul 30 07:45: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 HAA27291 for ; Wed, 30 Jul 2003 07:45:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hpNx-0008xA-LN for v6ops-data@psg.com; Wed, 30 Jul 2003 11:44:49 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.20) id 19hpNu-0008wx-Rj for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:44:46 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6UBiiTU004639; Wed, 30 Jul 2003 04:44:45 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6UBiiQ18343; Wed, 30 Jul 2003 13:44:44 +0200 (MEST) Date: Wed, 30 Jul 2003 13:42:31 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Defintion of Automatic tunnels To: Christian Huitema 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=-12.2 required=5.0 tests=BAYES_10,CLICK_BELOW,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > During the Vienna meeting, I sensed that there was a split in the WG > constituency between those who like automatic tunneling techniques such > as 6to4 and Teredo because they enable automatic deployment of IPv6, and > those who have an instinctive dislike for these technologies and would > much prefer controlled mechanisms and the orderly deployment of tunnels. > I would like to understand how we can resolve this tension. I suspect that that the issues are complex and interrelated thus trying to make a black and white distinction between automatic and configured tunnels is hard. Thus I've tried to put down different aspects of tunnels below and taken the liberty of using tunnel broker as an example where "configured" can actually look the same to the user as "automatic". 1. IPv6 tunnels on by default Some vendors might want to make IPv6 easier for the users by turning on IPv6 tunneling by default (for instance where there is IPv4 connectivity and no native IPv6 connectivity). Other vendors might prefer a "click here to enable IPv6 tunneling". I think this is only implementation issue except in the case of tunneling across NATs. 1b. IPv6 tunnels across NATs on by default Tunneling across NATs, which by accident will tunnel across many firewall configurations, presumably means that the IETF shouldn't endorse a "default tunnel across NATs" approach but instead suggest that the user be involved in turning this on. Also, there might be a reasonable requirement that it should be easy for network admins to prevent such tunneling by having a simple filter (e.g. filter on a single UDP port.) 2. Single knob "enable IPv6 tunnel" for user I think this can be implemented for a large number of tunneling technologies. For instance, a tunnel broker client could have a list public tunnel brokers and use ping times to select one. Or it would be possible to define an anycast address for the tunnel broker setup (not used for the tunneled packets). 3. Registration and authentication of user Some operators of infrastructure for tunnels, whether they fall in what Christian calls "automatic" or "configured", might want to be able to know who is using their infrastructure. Also, in the case of DoS attacks or other issues such operators might want to be able to point at "the source of that was this IPv4 address" to help tracking down the problems. On the other hand there might be folks, such as ISPs, which want to be able to provide tunneling infrastructure for a subset of IPv4 addresses (such as the subscribers of the ISP) without requiring any explicit registration and authentication of the user. Thus it would seem good if there either is one approach which can optionally do registration and authentication at tunnel establishment time, or there is one approach with and one without registration and authentication. 4. Simple for ISPs to deploy I'm not sure I understand the comparison here between the so called "automatic" (6to4 and Teredo) and so called "configured" (tunnel broker or similar) tunnels. With the latter the ISP can make sure they are only providing service to their subscribers. Is the same true for 6to4 relays and teredo servers? 5. Providing visibility for those providing infrastructure A non-technical issue is whether entities that provide some infrastructure for tunneling ("servers" or "relays") that is not limited to users with which they have a subscriber relationship, are visible to the end users i.e. that the can derive some name recognition for their help. 6. Avoiding traffic concentration at some "server"/"relay" One of the benefits of 6to4 and teredo is that traffic between nodes that use that scheme can avoid going through a single point. I think that this is really separate from terms like "automatic" vs. "configured", and it would be good to understand the tradeoffs in this space better. For instance, it seems to me that this benefit goes away when only one of the communicating parties implement 6to4/teredo. Also, at least in the case of 6to4, this benefit is accomplished at the expense of making certain other things more difficult (such as having multiple 6to4 routers between some cloud and the rest of the Internet). Finally, there are operational implications of this type of "short-cut routing". With tunnel broker configured tunnels I understand how to debug problems thus I think if ISPs want to use them their staff can understand how to debug them as well (try a traceroute to/from the IPv4 address of the tunnel endpoint, etc). And if things don't work one can try switching to different tunnel broker. With the shortcuts provided by teredo and 6to4 it is much harder to determine whether it is an IPv4 problem (IPv4 might work to/from a relay without working on the direct path) or IPv6 (IPv6 tunneling might work to/from a relay without working to/from a particular IPv6 peer). The teredo interactions with the large variation of NAT behavior makes this even harder. [And combining this with anycast to simplify #2 above adds to the troubles to debug.] So color me concerned - I don't think we need the equivalent NHRP for IPv6 tunnels. --- Perhaps there are more facets of the "automatic" vs. "configured" distinction than the ones I've listed above. But hopefully trying to tease apart the different facets makes it easier to come to a shared understanding of the issues. Erik From owner-v6ops@ops.ietf.org Wed Jul 30 09:01: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 JAA29358 for ; Wed, 30 Jul 2003 09:01:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hqXr-000E9e-TZ for v6ops-data@psg.com; Wed, 30 Jul 2003 12:59:07 +0000 Received: from [194.196.100.237] (helo=d12lmsgate-4.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19hqXn-000E9I-UZ for v6ops@ops.ietf.org; Wed, 30 Jul 2003 12:59:04 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6UCwrQk096982; Wed, 30 Jul 2003 14:58:53 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6UCwgqa204410; Wed, 30 Jul 2003 14:58:44 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA49366; Wed, 30 Jul 2003 14:58:40 +0200 Message-ID: <3F27C102.96D7BEF5@zurich.ibm.com> Date: Wed, 30 Jul 2003 14:58:42 +0200 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: Christian Huitema , v6ops@ops.ietf.org Subject: Re: Defintion of Automatic tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is an interesting discussion of the issues (well, it was, but I deleted it to save bits). But I'm not sure that the WG has to, or should, make a choice. The network is already telling us that both tunnel brokers and 6to4 attract users. I guess the jury is still out on Teredo. But I don't think it's for us to make a philosophical decision here. We will need to decide whether to adopt Teredo, but that should drop out of the scenario analysis as a pragmatic decision. Brian From owner-v6ops@ops.ietf.org Wed Jul 30 09:08: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 JAA29585 for ; Wed, 30 Jul 2003 09:08:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hqgg-000Esx-5G for v6ops-data@psg.com; Wed, 30 Jul 2003 13:08:14 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.20) id 19hqgd-000Esj-Gz for v6ops@ops.ietf.org; Wed, 30 Jul 2003 13:08:11 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6UD89IJ025517; Wed, 30 Jul 2003 07:08:10 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h6UD89Q23266; Wed, 30 Jul 2003 15:08:09 +0200 (MEST) Date: Wed, 30 Jul 2003 15:05:57 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Defintion of Automatic tunnels To: Brian E Carpenter Cc: Erik Nordmark , Christian Huitema , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3F27C102.96D7BEF5@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > This is an interesting discussion of the issues (well, it was, but > I deleted it to save bits). But I'm not sure that the WG has to, or > should, make a choice. The network is already telling us that both > tunnel brokers and 6to4 attract users. I guess the jury is still out > on Teredo. But I don't think it's for us to make a philosophical > decision here. We will need to decide whether to adopt Teredo, but that > should drop out of the scenario analysis as a pragmatic decision. Brian, You seem to be making a "the market will decide" argument with respect to 6to4 and tunnel brokers. Is that correct? I find it disconcerting that you didn't want to contribute to the understanding of the issues (with apply to all tunneling approaches - 6to4, teredo, tunnel brokers) and instead deleted the email to "save bits". That doesn't bode well for making forward progress. Sigh Erik From owner-v6ops@ops.ietf.org Wed Jul 30 09:21: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 JAA29889 for ; Wed, 30 Jul 2003 09:21:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hqt6-000Fkz-AI for v6ops-data@psg.com; Wed, 30 Jul 2003 13:21:04 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.20) id 19hqt3-000Fk3-IZ for v6ops@ops.ietf.org; Wed, 30 Jul 2003 13:21:01 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6UDKrv02995; Wed, 30 Jul 2003 15:20:53 +0200 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 h6UDKLof001950; Wed, 30 Jul 2003 15:20:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307301320.h6UDKLof001950@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "EricLKlein" cc: mobile-ip@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-reply-to: Your message of Wed, 30 Jul 2003 13:17:51 +0300. <001101c35683$d7601a50$03051eac@ttitelecom.com> Date: Wed, 30 Jul 2003 15:20:21 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: From: "Francis Dupont" > => as a cross-version tunnel will never be "optimized" (i.e., MN-CN direct > communication is not possible), IMHO mobile-ip solutions are clearly > overkilling in this kind of environments: a smart "road warrior" IPsec > VPN will be enough. Today two parts are missing: > - cross-version IPsec tunnels are not commonly available (note for > IPsec implementors: they are specified in RFC 2401, why do you not > support them?) Are you recommending that all mobile phone operators should create IP VPN's for all phones on their network and to maintain them for visitors and roamers on other networks? => you already have a "VPN" between the MN and the HA in MIPv6, so I feel free to recommend this (:-). This sounds like a lot of IP VPNs to create and maintain across multiple networks for people who roam, and unnecessary for those that don't. => I don't understand the "multiple networks" argument. The "VPN" is just an IPsec SA pair (MIPv6 uses two pairs) between a mobile and a fix point (the mobile-ip Home Agent). We are not talking dial-up users or even data users, jut straight 3G, GPRS, or WAP users. => we are talking about IP users. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Jul 30 09:38: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 JAA00293 for ; Wed, 30 Jul 2003 09:38:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hr9y-000Gv4-08 for v6ops-data@psg.com; Wed, 30 Jul 2003 13:38:30 +0000 Received: from [194.196.100.234] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19hr9u-000Gum-9z for v6ops@ops.ietf.org; Wed, 30 Jul 2003 13:38:26 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6UDcJtx080200; Wed, 30 Jul 2003 15:38:22 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6UDcJ8d192538; Wed, 30 Jul 2003 15:38:19 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA46358; Wed, 30 Jul 2003 15:38:17 +0200 Message-ID: <3F27CA4B.68896B7C@zurich.ibm.com> Date: Wed, 30 Jul 2003 15:38:19 +0200 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: Christian Huitema , v6ops@ops.ietf.org Subject: Re: Defintion of Automatic tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > This is an interesting discussion of the issues (well, it was, but > > I deleted it to save bits). But I'm not sure that the WG has to, or > > should, make a choice. The network is already telling us that both > > tunnel brokers and 6to4 attract users. I guess the jury is still out > > on Teredo. But I don't think it's for us to make a philosophical > > decision here. We will need to decide whether to adopt Teredo, but that > > should drop out of the scenario analysis as a pragmatic decision. > > Brian, > > You seem to be making a "the market will decide" argument with respect > to 6to4 and tunnel brokers. > Is that correct? Not quite. My point is more that since the (so far revenue-free) market already seems to want both solutions, I don't see that a decision is needed. Deployment has moved on since the v6ops charter was written. > I find it disconcerting that you didn't want to contribute to the understanding > of the issues (with apply to all tunneling approaches - 6to4, teredo, tunnel > brokers) and instead deleted the email to "save bits". That doesn't bode well > for making forward progress. I think you and Christian have pretty much covered the arguments, and I don't have anything new to add. These arguments will be very useful, when looking at the scenarios, to decide whether the WG should adopt Teredo as a work item. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-v6ops@ops.ietf.org Wed Jul 30 09:55: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 JAA00994 for ; Wed, 30 Jul 2003 09:55:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hrPa-000I8g-Ka for v6ops-data@psg.com; Wed, 30 Jul 2003 13:54:38 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19hrPY-000I8O-3C for v6ops@ops.ietf.org; Wed, 30 Jul 2003 13:54:36 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Jul 2003 09:54:36 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF4D@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Francis Dupont'" , EricLKlein Cc: mobile-ip@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Wed, 30 Jul 2003 09:54:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-12.9 required=5.0 tests=BAYES_01,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Francis, Not all is solved with VPN tunnels even if you manage to renegotiate the VPN tunnel automatically when the mobile moves...BTW, I think this is a worthy goal too and there are products already that support that kind of idea combining MIPv4 and IPSEC. There are other people, however, that would like to use Mobile IP (v4 or v6) for local mobility management in a wireless operator kind of environment....in which case it would be preferable not to have to use two mobility management protocols. You not being interested in that approach does not make this a non-issue :--) George -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] Sent: Wednesday, July 30, 2003 2:20 PM To: EricLKlein Cc: mobile-ip@sunroof.eng.sun.com; v6ops@ops.ietf.org Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In your previous mail you wrote: From: "Francis Dupont" > => as a cross-version tunnel will never be "optimized" (i.e., MN-CN direct > communication is not possible), IMHO mobile-ip solutions are clearly > overkilling in this kind of environments: a smart "road warrior" IPsec > VPN will be enough. Today two parts are missing: > - cross-version IPsec tunnels are not commonly available (note for > IPsec implementors: they are specified in RFC 2401, why do you not > support them?) Are you recommending that all mobile phone operators should create IP VPN's for all phones on their network and to maintain them for visitors and roamers on other networks? => you already have a "VPN" between the MN and the HA in MIPv6, so I feel free to recommend this (:-). This sounds like a lot of IP VPNs to create and maintain across multiple networks for people who roam, and unnecessary for those that don't. => I don't understand the "multiple networks" argument. The "VPN" is just an IPsec SA pair (MIPv6 uses two pairs) between a mobile and a fix point (the mobile-ip Home Agent). We are not talking dial-up users or even data users, jut straight 3G, GPRS, or WAP users. => we are talking about IP users. Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Jul 30 12:49: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 MAA07869 for ; Wed, 30 Jul 2003 12:49:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hu6I-0004XI-2O for v6ops-data@psg.com; Wed, 30 Jul 2003 16:46:54 +0000 Received: from [205.226.5.12] (helo=mailhost.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19hu6F-0004X2-FM for v6ops@ops.ietf.org; Wed, 30 Jul 2003 16:46:51 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA08647; Wed, 30 Jul 2003 09:46:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6UGkiV19223; Wed, 30 Jul 2003 09:46:44 -0700 X-mProtect: <200307301646> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTXQmzy; Wed, 30 Jul 2003 09:46:42 PDT Message-ID: <3F27F7E5.8050905@iprg.nokia.com> Date: Wed, 30 Jul 2003 09:52:53 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tsirtsis George CC: "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt References: <748C6D0A58C0F94CA63C198B6674697A0BFF49@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.1 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit George, Tsirtsis George wrote: >Now, when the mobile is not at home but in some other network, there is an >issue about what kind of v4/v6 support there is in the foreign network. The >nice thing about Mobile IP is that it is based on tunnels and thus it >provides natural way of tunneling over networks that are not compatible with >the mobile ...if only Mobile IP could configure v4 over v6 and v6 over v4 >tunnels (as opposed to just v4 over v4 and v6 over v6 tunnels). A dual stack >mobile in a v4 only foreign network would then be able to create a v4&v6 >over v4 (forward and reverse) tunnel with its HA and thus maintain all its >connectivity. > When a dual-stack MIPv6 MN encounters a v4-only foregin network, I see (at least) three possibilities for the v6-in-v4 tunnel endpoint: 1) the tunnel endpoint resides in the home network; perhaps even co-located with the HA (potential use case for configured tunnels) 2) the tunnel endpoint resides in the visited netwok (potential use-case for isatap) 3) the tunnel endpoint resides in some 3rd party network (potential use-case for tunnel broker) In any case, the v6-in-v4 tunnel should present an MTU large enough to encapsulate 1280 bytes PLUS the size of the outermost IPv6 header so that the inner MIPv6 IPv6-in-IPv6 tunneling does not incur harmful fragmentation (see RFC 2473, section 7). But, most v6-in-v4 tunneling specifications cap their MTUs at 1280 bytes. Does this seem like a potential performance issue waiting to bite us? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Jul 30 13:08: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 NAA08469 for ; Wed, 30 Jul 2003 13:08:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19huQc-0006Ir-Kt for v6ops-data@psg.com; Wed, 30 Jul 2003 17:07:54 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.20) id 19huQa-0006IW-63 for v6ops@ops.ietf.org; Wed, 30 Jul 2003 17:07:52 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6UH7pVP019842 for ; Wed, 30 Jul 2003 11:07:51 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIU00AXRKX2IP@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:07:51 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIU00IIMKX1TZ@mail.sun.net> for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:07:50 -0600 (MDT) Date: Wed, 30 Jul 2003 10:10:00 -0700 From: Alain Durand Subject: Re: Defintion of Automatic tunnels In-reply-to: <3F27CA4B.68896B7C@zurich.ibm.com> To: Brian E Carpenter Cc: Erik Nordmark , Christian Huitema , v6ops@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Wednesday, July 30, 2003, at 06:38 AM, Brian E Carpenter wrote: > Erik Nordmark wrote: >> Brian, >> >> You seem to be making a "the market will decide" argument with respect >> to 6to4 and tunnel brokers. >> Is that correct? > > Not quite. My point is more that since the (so far revenue-free) market > already seems to want both solutions, I don't see that a decision is > needed. > Deployment has moved on since the v6ops charter was written. Well, I think there is a lot of confusion in that space. We have a number of early adopters who are using both techniques. However, the number of 6to4 relays and tunnel brokers on the planet is still very small, and the traffic is marginal. I think it is still early in this process. IMHO, the jury is still out for many ISPs who would like to offer some kind of sparse, commercial IPv6 service without deploying a full scale native infrastructure. So I think it is still pertinent for the IETF to have an opinion on the matter and to recommend one approach versus the other, or maybe both if it can be proven that there are technical reasons to do so. - Alain. From owner-v6ops@ops.ietf.org Wed Jul 30 13:16: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 NAA08759 for ; Wed, 30 Jul 2003 13:16:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19huZ3-00070E-Aq for v6ops-data@psg.com; Wed, 30 Jul 2003 17:16:37 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.20) id 19huZ1-000700-2P for v6ops@ops.ietf.org; Wed, 30 Jul 2003 17:16:35 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6UHGYEV029070 for ; Wed, 30 Jul 2003 11:16:34 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIU00A9ILBLIP@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:16:34 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIU00I8TLBKU4@mail.sun.net> for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:16:33 -0600 (MDT) Date: Wed, 30 Jul 2003 10:18:44 -0700 From: Alain Durand Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-reply-to: <748C6D0A58C0F94CA63C198B6674697A0BFF49@ftmail.lab.flarion.com> To: Tsirtsis George Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Wednesday, July 30, 2003, at 01:48 AM, Tsirtsis George wrote: > Now, when the mobile is not at home but in some other network, there > is an > issue about what kind of v4/v6 support there is in the foreign > network. The > nice thing about Mobile IP is that it is based on tunnels and thus it > provides natural way of tunneling over networks that are not > compatible with > the mobile ...if only Mobile IP could configure v4 over v6 and v6 over > v4 > tunnels (as opposed to just v4 over v4 and v6 over v6 tunnels). A dual > stack > mobile in a v4 only foreign network would then be able to create a > v4&v6 > over v4 (forward and reverse) tunnel with its HA and thus maintain all > its > connectivity. Call me skeptic, but I am a little concern with the potential effect of double or even worse triple tunneling: Mipv6/Ipv6/Mipv4/IPv4 and I'm sure we could build scenarios even more frightening with various combination of encapsulation. I'm not worried about MTU, but about RTT and debugging. - Alain. From owner-v6ops@ops.ietf.org Wed Jul 30 13:18: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 NAA08876 for ; Wed, 30 Jul 2003 13:18:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hub2-0007BY-8u for v6ops-data@psg.com; Wed, 30 Jul 2003 17:18:40 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19hub0-0007BI-4D for v6ops@ops.ietf.org; Wed, 30 Jul 2003 17:18:38 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jul 2003 10:18:36 -0700 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jul 2003 10:18:36 -0700 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Jul 2003 10:18:35 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jul 2003 10:18:35 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jul 2003 10:18:19 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Jul 2003 10:18:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Defintion of Automatic tunnels Date: Wed, 30 Jul 2003 10:18:33 -0700 Message-ID: Thread-Topic: Defintion of Automatic tunnels Thread-Index: AcNWvR+mPgw+UdNuR7+NcTYVCqAWwwAAP1XA From: "Christian Huitema" To: , "Brian E Carpenter" Cc: "Erik Nordmark" , X-OriginalArrivalTime: 30 Jul 2003 17:18:13.0974 (UTC) FILETIME=[8F04D760:01C356BE] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > So I think it is still pertinent for the IETF to have an opinion on the > matter > and to recommend one approach versus the other, or maybe both if it can > be proven > that there are technical reasons to do so. This is pretty close to recommending operational procedures, and frankly that is not what the IETF does best. The IETF shines when it produces sound specifications, or thorough technical analyses. But operation practices are better left to practicians, which may be another way of saying "to the market." -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Jul 30 13:24: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 NAA09338 for ; Wed, 30 Jul 2003 13:24:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19huga-0007m0-9A for v6ops-data@psg.com; Wed, 30 Jul 2003 17:24:24 +0000 Received: from [205.226.5.12] (helo=mailhost.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19hugY-0007ld-7p for v6ops@ops.ietf.org; Wed, 30 Jul 2003 17:24:22 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA10920; Wed, 30 Jul 2003 10:23:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6UHNvH27177; Wed, 30 Jul 2003 10:23:57 -0700 X-mProtect: <200307301723> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHia40h; Wed, 30 Jul 2003 10:23:56 PDT Message-ID: <3F28009F.80505@iprg.nokia.com> Date: Wed, 30 Jul 2003 10:30:07 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alain Durand CC: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain Durand wrote: > I'm not worried about MTU, but about RTT and debugging. Perhaps except to the extent that MTU and RTT/debugging may be inter-related? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Jul 30 13:44: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 NAA10118 for ; Wed, 30 Jul 2003 13:44:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19huz7-0009Xy-VS for v6ops-data@psg.com; Wed, 30 Jul 2003 17:43:33 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.20) id 19huyu-0009XF-3E for v6ops@ops.ietf.org; Wed, 30 Jul 2003 17:43:20 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6UHhJEV016183 for ; Wed, 30 Jul 2003 11:43:19 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIU009QVMK7UJ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:43:19 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIU00MIWMK5RC@mail.sun.net> for v6ops@ops.ietf.org; Wed, 30 Jul 2003 11:43:19 -0600 (MDT) Date: Wed, 30 Jul 2003 10:45:29 -0700 From: Alain Durand Subject: Re: Defintion of Automatic tunnels In-reply-to: To: Christian Huitema Cc: Brian E Carpenter , Erik Nordmark , v6ops@ops.ietf.org Message-id: <9BF9B7BA-C2B5-11D7-8DDB-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Wednesday, July 30, 2003, at 10:18 AM, Christian Huitema wrote: >> So I think it is still pertinent for the IETF to have an opinion on > the >> matter >> and to recommend one approach versus the other, or maybe both if it > can >> be proven >> that there are technical reasons to do so. > > This is pretty close to recommending operational procedures, and > frankly > that is not what the IETF does best. The IETF shines when it produces > sound specifications, or thorough technical analyses. But operation > practices are better left to practicians, which may be another way of > saying "to the market." You have a point. So, let me rephrase: I think it is still pertinent for the IETF to make a thorough technical analysis of each approach. - Alain. From owner-v6ops@ops.ietf.org Wed Jul 30 17:12: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 RAA18112 for ; Wed, 30 Jul 2003 17:12:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19hyDX-0000cI-Cu for v6ops-data@psg.com; Wed, 30 Jul 2003 21:10:39 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.20) id 19hyDQ-0000c1-M9 for v6ops@ops.ietf.org; Wed, 30 Jul 2003 21:10:32 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6ULAUVa020642; Wed, 30 Jul 2003 14:10:31 -0700 (PDT) Received: from lillen (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 h6ULAPQ25828; Wed, 30 Jul 2003 23:10:26 +0200 (MEST) Date: Wed, 30 Jul 2003 23:08:06 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Defintion of Automatic tunnels To: Brian E Carpenter Cc: Erik Nordmark , Christian Huitema , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3F27CA4B.68896B7C@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-13.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Brian said: > Not quite. My point is more that since the (so far revenue-free) market > already seems to want both solutions, I don't see that a decision is needed. > Deployment has moved on since the v6ops charter was written. Given that this group is supposed to: 1. Solicit input from network operators and users to identify operational or security issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. it sounds like it should gather information about the issues when deploying existing transition mechanisms, and not just do nothing as you seem to suggest. Christian said: > This is pretty close to recommending operational procedures, and frankly > that is not what the IETF does best. The IETF shines when it produces > sound specifications, or thorough technical analyses. But operation > practices are better left to practicians, which may be another way of > saying "to the market." And the charter has: The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides guidance for network operators on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. So there seems to be disconnects between both of your views and the charter. Erik From owner-v6ops@ops.ietf.org Thu Jul 31 00:22:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28712 for ; Thu, 31 Jul 2003 00:22:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i4uD-0005se-W3 for v6ops-data@psg.com; Thu, 31 Jul 2003 04:19:09 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19i4tv-0005rk-L7 for v6ops@ops.ietf.org; Thu, 31 Jul 2003 04:18:51 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Jul 2003 00:18:51 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C18@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Fritsche Wolfgang'" , Tsirtsis George , Alain Durand Cc: mobile-ip@sunroof.eng.sun.com, v6ops@ops.ietf.org, Soliman Hesham , Thomas Narten Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Thu, 31 Jul 2003 00:18:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_30,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Wolfgang, We didn't address solutions yet but it's a good time to talk about it. > As MIPv6 will use IPsec in tunnel mode between MN and HA, => Only for RO messages between the MN and CN (HOTI and HOT) I > assume a MIPv6 MN in a v4 only foreign network will set up a > "v6 over v6 over v4" bi-directional tunnel to its HA (with > the first v6 being the outer header of the IPsec packet > based on the CoA, and the second v6 being the inner header > based on the HoA), not just a v6 over v4 one. => This setup would be applicable to HOTI/HOT messages only, unless the MN decides to protect all traffic through the HA, which is not a MIP issue. But for HOTI/HOT this would be required according to MIPv6. Hesham > > Wolfgang > > > > > George > > > > -----Original Message----- > > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > > Sent: Wednesday, July 30, 2003 12:23 AM > > To: Tsirtsis George > > Cc: Mobile-Ip (mobile-ip@sunroof.eng.sun.com); > > v6ops@ops.ietf.org; Soliman > > Hesham; 'Thomas Narten' > > Subject: [mobile-ip] Re: FW: I-D > > ACTION:draft-tsirtsis-dsmip-problem-00.txt > > > > > > Hi George, > > > > Thank you for writing this draft, this is an interesting > > perspective. There is one point you do not mention: what if > > the IPv6 node is using directly or indirectly IPv6 in IPv4 > > tunnels for its IPv6 connectivity? For example, it may derive > > a 6to4 prefix from its home address and then uses MIPv4.... > > There are extra complexities here that I'm not sure I fully > > understand. Is it a problem space that you intend to cover? > > > > - Alain. > > > > On Tuesday, July 29, 2003, at 12:17 PM, Tsirtsis George wrote: > > > > > Hi all, > > > > > > During the Mobile IP WG meeting in Austria, Hesham and > > myself brought > > > up the issue of mobility management for dual stack nodes. > > > > > > Thomas N. requested that we put together a problem > > statement so that > > > we can discuss the issue; the draft below was published > > today - it is > > > short and I > > > hope to the point - so do read it :) > > > > > > I have copied v6ops since I think this is a v4 - v6 > > migration issue as > > > well as Mobile IPv4 and Mobile IPv6 issue. > > > > > > Let us know what you think. > > > > > > George > > > > > > > > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Tuesday, July 29, 2003 5:15 PM > > > Subject: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts > > > directories. > > > > > > > > > Title : Mobility management for Dual stack > > mobile nodes A > > > > > > Problem Statement > > > Author(s) : G. Tsirtsis, H. Soliman > > > Filename : draft-tsirtsis-dsmip-problem-00.txt > > > Pages : 4 > > > Date : 2003-7-29 > > > > > > This draft discusses the issues associated with mobility > management > > > for dual stack mobile nodes. Currently, two mobility management > > > protocols are defined for IPv4 and IPv6. Deploying both > in a dual > > > stack mobile node introduces a number of inefficiencies. > Deployment > > > and operational issues motivate the use of a single mobility > > > management protocol. This draft discusses such motivations. > > The draft > > > also hints on how current MIPv4 and MIPv6 could be > extended so that > > > they can support mobility management for a dual stack node. > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-00.tx > > t > > > > 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-tsirtsis-dsmip-problem-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-tsirtsis-dsmip-problem-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. > > > > > > Date: Tue Jul 29, 2003 9:40:01 AM US/Pacific > > To: > > Subject: > > > > > > > > > > > From owner-v6ops@ops.ietf.org Thu Jul 31 04:22: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 EAA15974 for ; Thu, 31 Jul 2003 04:22:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i8ev-000Myw-SA for v6ops-data@psg.com; Thu, 31 Jul 2003 08:19:37 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19i8et-000Myh-JW for v6ops@ops.ietf.org; Thu, 31 Jul 2003 08:19:35 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Jul 2003 04:19:35 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF54@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Alain Durand'" Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Thu, 31 Jul 2003 04:19:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-21.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Alain, I am not sure where Mipv6/Ipv6/Mipv4/IPv4 comes from in your e-mail and I am not even sure what it means. MIPv4 and MIPv6 are signaling protocols....and do not introduce overhead in the data path. We can always complicate things but why not deal with the simple and by far most important issue. Today Mobile IP signals HoA to CoA bindings of the same version resulting in either IPv4 over IPv4 encapsulation or IPv6 over IPv6 encapsulation. All I am suggesting is that Mobile IP should be able to signal HoA to CoA bindings of different versions so that IPv4 over IPv6 encapsulation or IPv4 over IPv6 encapsulation is also possible. George -----Original Message----- From: Alain Durand [mailto:Alain.Durand@Sun.COM] Sent: Wednesday, July 30, 2003 6:19 PM To: Tsirtsis George Cc: Mobile-Ip (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org; Soliman Hesham; 'Thomas Narten' Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt On Wednesday, July 30, 2003, at 01:48 AM, Tsirtsis George wrote: > Now, when the mobile is not at home but in some other network, there > is an > issue about what kind of v4/v6 support there is in the foreign > network. The > nice thing about Mobile IP is that it is based on tunnels and thus it > provides natural way of tunneling over networks that are not > compatible with > the mobile ...if only Mobile IP could configure v4 over v6 and v6 over > v4 > tunnels (as opposed to just v4 over v4 and v6 over v6 tunnels). A dual > stack > mobile in a v4 only foreign network would then be able to create a > v4&v6 > over v4 (forward and reverse) tunnel with its HA and thus maintain all > its > connectivity. Call me skeptic, but I am a little concern with the potential effect of double or even worse triple tunneling: Mipv6/Ipv6/Mipv4/IPv4 and I'm sure we could build scenarios even more frightening with various combination of encapsulation. I'm not worried about MTU, but about RTT and debugging. - Alain. From owner-v6ops@ops.ietf.org Thu Jul 31 04:38: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 EAA16333 for ; Thu, 31 Jul 2003 04:38:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i8wU-000OWg-02 for v6ops-data@psg.com; Thu, 31 Jul 2003 08:37:46 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19i8wR-000OWU-O0 for v6ops@ops.ietf.org; Thu, 31 Jul 2003 08:37:43 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Jul 2003 04:37:44 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF56@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Fred Templin'" Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Thu, 31 Jul 2003 04:37:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-18.6 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Fred, I am not sure what you are saying...a dual stack MIPv6 MN encountering a v4 network will have no hope in sending a MIPv6 BU to its v6HA in any way that would allow real mobility. I guess one can imagine that such a mobile detecting a v4 only network could start going through the ngtrans tools and see what may work so that it can somehow get an IPv6 address and then tunnel a MIPv6 BU to its HA....as I said not real mobility. Then I do not understand why you talk about this as if there needs to be "IPv6 over IPv6 over IPv4" tunneling involved. If the HoA is IPv6 and the CoA is IPv4 and MIP could be extended to create a binding between the two then an "IPv6 over IPv4" tunnel would be created. George -----Original Message----- From: Fred Templin [mailto:ftemplin@iprg.nokia.com] Sent: Wednesday, July 30, 2003 5:53 PM To: Tsirtsis George Cc: 'Alain Durand'; Mobile-Ip (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org; Soliman Hesham; 'Thomas Narten' Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt George, Tsirtsis George wrote: >Now, when the mobile is not at home but in some other network, there >is an issue about what kind of v4/v6 support there is in the foreign >network. The nice thing about Mobile IP is that it is based on tunnels >and thus it provides natural way of tunneling over networks that are >not compatible with the mobile ...if only Mobile IP could configure v4 >over v6 and v6 over v4 tunnels (as opposed to just v4 over v4 and v6 >over v6 tunnels). A dual stack mobile in a v4 only foreign network >would then be able to create a v4&v6 over v4 (forward and reverse) >tunnel with its HA and thus maintain all its connectivity. > When a dual-stack MIPv6 MN encounters a v4-only foregin network, I see (at least) three possibilities for the v6-in-v4 tunnel endpoint: 1) the tunnel endpoint resides in the home network; perhaps even co-located with the HA (potential use case for configured tunnels) 2) the tunnel endpoint resides in the visited netwok (potential use-case for isatap) 3) the tunnel endpoint resides in some 3rd party network (potential use-case for tunnel broker) In any case, the v6-in-v4 tunnel should present an MTU large enough to encapsulate 1280 bytes PLUS the size of the outermost IPv6 header so that the inner MIPv6 IPv6-in-IPv6 tunneling does not incur harmful fragmentation (see RFC 2473, section 7). But, most v6-in-v4 tunneling specifications cap their MTUs at 1280 bytes. Does this seem like a potential performance issue waiting to bite us? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Jul 31 04:38: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 EAA16351 for ; Thu, 31 Jul 2003 04:38:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i8xO-000OaD-AQ for v6ops-data@psg.com; Thu, 31 Jul 2003 08:38:42 +0000 Received: from [194.196.100.238] (helo=d12lmsgate-5.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19i8xJ-000OZI-W8 for v6ops@ops.ietf.org; Thu, 31 Jul 2003 08:38:38 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h6V8cZJR025228; Thu, 31 Jul 2003 10:38:35 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6V8cYkA237326; Thu, 31 Jul 2003 10:38:34 +0200 Received: from zurich.ibm.com (dhcp22-107.zurich.ibm.com [9.4.22.107]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA46408; Thu, 31 Jul 2003 10:38:31 +0200 Message-ID: <3F28D588.2786C585@zurich.ibm.com> Date: Thu, 31 Jul 2003 10:38:32 +0200 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: Christian Huitema , v6ops@ops.ietf.org Subject: Re: Defintion of Automatic tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, First of all let me apologise for the tone of my "deleted to save bits" comment, which sounded dismissive of the discussion between you and Christian. That wasn't my intention - in fact I have saved that discussion with every intention of referring to it in the future. Secondly, I do think that the v6ops charter is probably slightly out of date - which is good news, since it means that IPv6 deployment has made progress. I don't think the out-of-dateness is serious enough to open a rechartering discussion now. We should certainly perform the critical review of existing solutions and improve them if we can. And even though it's not in the charter, that should probably include tunnel brokers IMHO. What I think lies outside the IETF's power is to tell network operators which solutions to adopt, although of course we can choose which ones the IETF specifies. Brian Erik Nordmark wrote: > > Brian said: > > Not quite. My point is more that since the (so far revenue-free) market > > already seems to want both solutions, I don't see that a decision is needed. > > Deployment has moved on since the v6ops charter was written. > > Given that this group is supposed to: > 1. Solicit input from network operators and users to identify > operational or security issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. > > it sounds like it should gather information about the issues when deploying > existing transition mechanisms, and not just do nothing as you seem to suggest. > Christian said: > > This is pretty close to recommending operational procedures, and frankly > > that is not what the IETF does best. The IETF shines when it produces > > sound specifications, or thorough technical analyses. But operation > > practices are better left to practicians, which may be another way of > > saying "to the market." > > And the charter has: > The IPv6 Operations Working Group (v6ops) develops guidelines for the > operation of a shared IPv4/IPv6 Internet and provides guidance for > network operators on how to deploy IPv6 into existing IPv4-only > networks, as well as into new network installations. > > So there seems to be disconnects between both of your views and > the charter. > > Erik -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-v6ops@ops.ietf.org Thu Jul 31 04:46: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 EAA16627 for ; Thu, 31 Jul 2003 04:46:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19i952-000PP2-8y for v6ops-data@psg.com; Thu, 31 Jul 2003 08:46:36 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.20) id 19i94y-000PNq-O7 for v6ops@ops.ietf.org; Thu, 31 Jul 2003 08:46:32 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C562296; Thu, 31 Jul 2003 17:46:28 +0900 (JST) To: "Christian Huitema" Cc: v6ops@ops.ietf.org In-reply-to: huitema's message of Fri, 25 Jul 2003 09:57:19 MST. 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: Automatic tunnels From: itojun@iijlab.net Date: Thu, 31 Jul 2003 17:46:28 +0900 Message-Id: <20030731084628.C562296@coconut.itojun.org> X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I guess we agree that the main priority for ISP ought to be, "provide >native IPv6 services". The question then is what should an ISP do when >it wishes to provide IPv6 but is not quite ready. I would expect the ISP >design team to tell us more about the constraints and the >practicalities, but there are clearly three possibilities: do nothing, >provide support for automatic tunneling, or provide configured tunnels. >The support for automatic tunneling is simple: just provide a >6to4-to-native service and advertise a route to 192.88.99.1; to avoid >abuse, make sure that 192.88.99.1 is only reachable by subscribers of >this ISP. The support for configured tunnels is somewhat more complex: >if the ISP really want to provide additional benefits compare to >automatic tunnels, it needs to do some form of customer management to >ensure that customers get stable prefixes, that they use the tunnel end >point closest to home, etc. Frankly, I don't know whether the additional >complexity is worth the cost. for native-to-6to4, there's no way to protect from abuse (since 2002::/16 has to be advertised, more-specific route is not permitted). how do you address the problem? (pekka's draft outlines the problem very well) seriously, with ISP hat on, we have been talking about putting 6to4 relay router in our backbone, but we end up rejecting it due to the possibility of abuse, and the impact of abuse (and the lack of human resource to monitor/track down the source of abuse). i'm very pessimistic about 6to4 relay router deployment. itojun From owner-v6ops@ops.ietf.org Thu Jul 31 12:07: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 MAA02826 for ; Thu, 31 Jul 2003 12:07:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iFuH-0006p1-Qn for v6ops-data@psg.com; Thu, 31 Jul 2003 16:03:57 +0000 Received: from [131.107.3.122] (helo=mail4.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19iFuC-0006of-6o for v6ops@ops.ietf.org; Thu, 31 Jul 2003 16:03:52 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 31 Jul 2003 09:03:50 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 31 Jul 2003 09:03:57 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Jul 2003 09:03:50 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 31 Jul 2003 09:03:50 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 31 Jul 2003 09:03:50 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 31 Jul 2003 09:03:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Automatic tunnels Date: Thu, 31 Jul 2003 09:03:48 -0700 Message-ID: Thread-Topic: Automatic tunnels Thread-Index: AcNXQEHiY0BnMbwdQ56Rls2FZJLtqAAO9BWw From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 31 Jul 2003 16:03:41.0393 (UTC) FILETIME=[4F90E410:01C3577D] X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > for native-to-6to4, there's no way to protect from abuse (since > 2002::/16 has to be advertised, more-specific route is not > permitted). > how do you address the problem? (pekka's draft outlines the problem > very well) Which type of abuse are you concerned with? We can deploy native-to-6to4 relays in several modes: - host specific=20 (host is multi-homed to 6to4, local routing entry to 2002::/16) - AS specific=20 (some routers act as relay, export a route to 2002::/16 in IGP) - Across multiple AS (export a route to 2002::/16 in BGP) The first two modes don't seem particularly prone to abuse. Host specific relays certainly are not an issue, and the abuse to AS specific relay fall in the general category of "abusing peering agreements", which is by no means specific to 6to4. I agree that exporting a route through BGP is hard to control, as the route can be re-exported by peering ASes. But, again, this fall in the category of "peering abuses", which can be contained by proper peering contracts. -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Jul 31 12:35:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03547 for ; Thu, 31 Jul 2003 12:35:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iGN5-0009Rq-NK for v6ops-data@psg.com; Thu, 31 Jul 2003 16:33:43 +0000 Received: from [205.226.5.12] (helo=mailhost.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19iGN2-0009RU-Gr for v6ops@ops.ietf.org; Thu, 31 Jul 2003 16:33:40 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA18225; Thu, 31 Jul 2003 09:33:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6VGXdW18178; Thu, 31 Jul 2003 09:33:39 -0700 X-mProtect: <200307311633> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZpQqGR; Thu, 31 Jul 2003 09:33:37 PDT Message-ID: <3F29465A.6010301@iprg.nokia.com> Date: Thu, 31 Jul 2003 09:39:54 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tsirtsis George CC: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt References: <748C6D0A58C0F94CA63C198B6674697A0BFF56@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit George, Tsirtsis George wrote: >Fred, > >I am not sure what you are saying...a dual stack MIPv6 MN encountering a v4 >network will have no hope in sending a MIPv6 BU to its v6HA in any way that >would allow real mobility. > >I guess one can imagine that such a mobile detecting a v4 only network could >start going through the ngtrans tools and see what may work so that it can >somehow get an IPv6 address and then tunnel a MIPv6 BU to its HA....as I >said not real mobility. > Yes, this is the scenario I was referring to. First order of business is to get some level of IPv6 connectivity in the visited network even if ip-proto-41 is required. >Then I do not understand why you talk about this as if there needs to be >"IPv6 over IPv6 over IPv4" tunneling involved. If the HoA is IPv6 and the >CoA is IPv4 and MIP could be extended to create a binding between the two >then an "IPv6 over IPv4" tunnel would be created. > The IPv6-in-IPv6-in-IPv4 part comes when 1) the HA needs to tunnel IPv6 packets to a MN in an IPv4-only visited network or 2) the MN in an IPv4-only network needs to reverse-tunnel IPv6 packets through the HA to reach a CN. Not sure how you mean about MIP being extended to create a binding between IPv6 and IPv4. Do you see a way around the nested tunneling? (And, is there a specification somewhere that tells how to do it?) Thanks, Fred ftemplin@iprg.nokia.com > >George > >-----Original Message----- >From: Fred Templin [mailto:ftemplin@iprg.nokia.com] >Sent: Wednesday, July 30, 2003 5:53 PM >To: Tsirtsis George >Cc: 'Alain Durand'; Mobile-Ip (mobile-ip@sunroof.eng.sun.com); >v6ops@ops.ietf.org; Soliman Hesham; 'Thomas Narten' >Subject: Re: [mobile-ip] Re: FW: I-D >ACTION:draft-tsirtsis-dsmip-problem-00.txt > > >George, > >Tsirtsis George wrote: > > > >>Now, when the mobile is not at home but in some other network, there >>is an issue about what kind of v4/v6 support there is in the foreign >>network. The nice thing about Mobile IP is that it is based on tunnels >>and thus it provides natural way of tunneling over networks that are >>not compatible with the mobile ...if only Mobile IP could configure v4 >>over v6 and v6 over v4 tunnels (as opposed to just v4 over v4 and v6 >>over v6 tunnels). A dual stack mobile in a v4 only foreign network >>would then be able to create a v4&v6 over v4 (forward and reverse) >>tunnel with its HA and thus maintain all its connectivity. >> >> >> >When a dual-stack MIPv6 MN encounters a v4-only foregin network, I see (at >least) three possibilities for the v6-in-v4 tunnel endpoint: > > 1) the tunnel endpoint resides in the home network; perhaps > even co-located with the HA (potential use case for configured > tunnels) > > 2) the tunnel endpoint resides in the visited netwok (potential > use-case for isatap) > > 3) the tunnel endpoint resides in some 3rd party network > (potential use-case for tunnel broker) > >In any case, the v6-in-v4 tunnel should present an MTU large enough to >encapsulate 1280 bytes PLUS the size of the outermost IPv6 header so that >the inner MIPv6 IPv6-in-IPv6 tunneling does not incur harmful fragmentation >(see RFC 2473, section 7). But, most v6-in-v4 tunneling specifications cap >their MTUs at 1280 bytes. Does this seem like a potential performance issue >waiting to bite us? > >Fred >ftemplin@iprg.nokia.com > > > > From owner-v6ops@ops.ietf.org Thu Jul 31 15:49:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11537 for ; Thu, 31 Jul 2003 15:49:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iJO9-000PyS-PW for v6ops-data@psg.com; Thu, 31 Jul 2003 19:47:01 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19iJO6-000PyA-Uo for v6ops@ops.ietf.org; Thu, 31 Jul 2003 19:46:59 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Jul 2003 15:46:54 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF5E@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Fred Templin'" Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Thu, 31 Jul 2003 15:46:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE, QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Inline.. -----Original Message----- From: Fred Templin [mailto:ftemplin@IPRG.nokia.com] Sent: Thursday, July 31, 2003 5:40 PM To: Tsirtsis George Cc: Mobile-Ip (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt George, Tsirtsis George wrote: >Fred, > >I am not sure what you are saying...a dual stack MIPv6 MN encountering >a v4 network will have no hope in sending a MIPv6 BU to its v6HA in any >way that would allow real mobility. > >I guess one can imagine that such a mobile detecting a v4 only network >could start going through the ngtrans tools and see what may work so >that it can somehow get an IPv6 address and then tunnel a MIPv6 BU to >its HA....as I said not real mobility. > Yes, this is the scenario I was referring to. First order of business is to get some level of IPv6 connectivity in the visited network even if ip-proto-41 is required. GT> Or alternatively use MIPv4 and register you IPv6HoA to the IPv4CoA binding to the HA without having to get an IPv6 address using ngtrans tools. >Then I do not understand why you talk about this as if there needs to >be "IPv6 over IPv6 over IPv4" tunneling involved. If the HoA is IPv6 >and the CoA is IPv4 and MIP could be extended to create a binding >between the two then an "IPv6 over IPv4" tunnel would be created. > The IPv6-in-IPv6-in-IPv4 part comes when 1) the HA needs to tunnel IPv6 packets to a MN in an IPv4-only visited network or GT> This is where I am not getting through. My aim is to extend MIP so that you only need IPv6 over IPv4 when you have IPv6HoA and you can only get an IPv4CoA. 2) the MN in an IPv4-only network needs to reverse-tunnel IPv6 packets through the HA to reach a CN. Not sure how you mean about MIP being extended to create a binding between IPv6 and IPv4. Do you see a way around the nested tunneling? (And, is there a specification somewhere that tells how to do it?) GT> Maybe it a little bit more clear now? In any case I expect to send out the MIPv4 extensions proposal for this early next week some time...and MIPv6 extensions so time later...I hope this will help. Thanks George > >George > >-----Original Message----- >From: Fred Templin [mailto:ftemplin@iprg.nokia.com] >Sent: Wednesday, July 30, 2003 5:53 PM >To: Tsirtsis George >Cc: 'Alain Durand'; Mobile-Ip (mobile-ip@sunroof.eng.sun.com); >v6ops@ops.ietf.org; Soliman Hesham; 'Thomas Narten' >Subject: Re: [mobile-ip] Re: FW: I-D >ACTION:draft-tsirtsis-dsmip-problem-00.txt > > >George, > >Tsirtsis George wrote: > > > >>Now, when the mobile is not at home but in some other network, there >>is an issue about what kind of v4/v6 support there is in the foreign >>network. The nice thing about Mobile IP is that it is based on tunnels >>and thus it provides natural way of tunneling over networks that are >>not compatible with the mobile ...if only Mobile IP could configure v4 >>over v6 and v6 over v4 tunnels (as opposed to just v4 over v4 and v6 >>over v6 tunnels). A dual stack mobile in a v4 only foreign network >>would then be able to create a v4&v6 over v4 (forward and reverse) >>tunnel with its HA and thus maintain all its connectivity. >> >> >> >When a dual-stack MIPv6 MN encounters a v4-only foregin network, I see >(at >least) three possibilities for the v6-in-v4 tunnel endpoint: > > 1) the tunnel endpoint resides in the home network; perhaps > even co-located with the HA (potential use case for configured > tunnels) > > 2) the tunnel endpoint resides in the visited netwok (potential > use-case for isatap) > > 3) the tunnel endpoint resides in some 3rd party network > (potential use-case for tunnel broker) > >In any case, the v6-in-v4 tunnel should present an MTU large enough to >encapsulate 1280 bytes PLUS the size of the outermost IPv6 header so >that the inner MIPv6 IPv6-in-IPv6 tunneling does not incur harmful >fragmentation (see RFC 2473, section 7). But, most v6-in-v4 tunneling >specifications cap their MTUs at 1280 bytes. Does this seem like a >potential performance issue waiting to bite us? > >Fred >ftemplin@iprg.nokia.com > > > > From owner-v6ops@ops.ietf.org Thu Jul 31 16:12: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 QAA12532 for ; Thu, 31 Jul 2003 16:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iJlv-0002MG-QK for v6ops-data@psg.com; Thu, 31 Jul 2003 20:11:35 +0000 Received: from [205.226.5.12] (helo=mailhost.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19iJlr-0002Ly-Pb for v6ops@ops.ietf.org; Thu, 31 Jul 2003 20:11:32 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA00314; Thu, 31 Jul 2003 13:11:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6VKBSD12115; Thu, 31 Jul 2003 13:11:28 -0700 X-mProtect: <200307312011> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdafF4bF; Thu, 31 Jul 2003 13:11:27 PDT Message-ID: <3F297969.2080805@iprg.nokia.com> Date: Thu, 31 Jul 2003 13:17:45 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tsirtsis George CC: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt References: <748C6D0A58C0F94CA63C198B6674697A0BFF5E@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tsirtsis George wrote: >GT> Or alternatively use MIPv4 and register you IPv6HoA to the IPv4CoA >binding to the HA without having to get an IPv6 address using ngtrans tools. > I will be interested to see your proposals when they appear; especially if they also account for the case of the IPv4CoA being from a private addressing space behind a NAT. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Jul 31 16: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 QAA12774 for ; Thu, 31 Jul 2003 16:21:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iJuw-0003EJ-FS for v6ops-data@psg.com; Thu, 31 Jul 2003 20:20:54 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19iJuu-0003Dy-6F for v6ops@ops.ietf.org; Thu, 31 Jul 2003 20:20:52 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 31 Jul 2003 16:20:51 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF60@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Fred Templin'" Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Thu, 31 Jul 2003 16:20:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk I think you might be expecting too much :-) ...but we will try. George -----Original Message----- From: Fred Templin [mailto:ftemplin@IPRG.nokia.com] Sent: Thursday, July 31, 2003 9:18 PM To: Tsirtsis George Cc: Mobile-Ip (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org Subject: Re: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Tsirtsis George wrote: >GT> Or alternatively use MIPv4 and register you IPv6HoA to the IPv4CoA >binding to the HA without having to get an IPv6 address using ngtrans >tools. > I will be interested to see your proposals when they appear; especially if they also account for the case of the IPv4CoA being from a private addressing space behind a NAT. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu Jul 31 19:28: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 TAA18894 for ; Thu, 31 Jul 2003 19:28:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iMon-000J5Y-5X for v6ops-data@psg.com; Thu, 31 Jul 2003 23:26:45 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.20) id 19iMok-000J5L-Cd for v6ops@ops.ietf.org; Thu, 31 Jul 2003 23:26:42 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 80EB013; Fri, 1 Aug 2003 08:26:40 +0900 (JST) To: "Christian Huitema" Cc: v6ops@ops.ietf.org In-reply-to: huitema's message of Thu, 31 Jul 2003 09:03:48 MST. 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: Automatic tunnels From: itojun@iijlab.net Date: Fri, 01 Aug 2003 08:26:40 +0900 Message-Id: <20030731232640.80EB013@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Which type of abuse are you concerned with? We can deploy native-to-6to4 >relays in several modes: > > - host specific=20 > (host is multi-homed to 6to4, local routing entry to 2002::/16) > - AS specific=20 > (some routers act as relay, export a route to 2002::/16 in IGP) > - Across multiple AS > (export a route to 2002::/16 in BGP) > >The first two modes don't seem particularly prone to abuse. Host >specific relays certainly are not an issue, and the abuse to AS specific >relay fall in the general category of "abusing peering agreements", >which is by no means specific to 6to4. I agree that exporting a route >through BGP is hard to control, as the route can be re-exported by >peering ASes. But, again, this fall in the category of "peering abuses", >which can be contained by proper peering contracts. we are afraid of our native-to-6to4 device being used as open relay of packet (bullet 3 in the above, of course). the IPv4 source address will be ours, so we will get compliants from random people, because of malicious traffic from somewhere to 2002::/16. running 6to4 relay router is like running open relay smtp server. itojun From owner-v6ops@ops.ietf.org Thu Jul 31 21:01: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 VAA20536 for ; Thu, 31 Jul 2003 21:01:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19iOGK-0001xj-Ao for v6ops-data@psg.com; Fri, 01 Aug 2003 00:59:16 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19iOGH-0001xX-Vn for v6ops@ops.ietf.org; Fri, 01 Aug 2003 00:59:13 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 31 Jul 2003 17:59:13 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Jul 2003 17:59:07 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 31 Jul 2003 17:59:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 31 Jul 2003 17:59:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 31 Jul 2003 17:59:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Automatic tunnels Date: Thu, 31 Jul 2003 17:59:12 -0700 Message-ID: Thread-Topic: Automatic tunnels Thread-Index: AcNXuzihCs0IofePTNKtnwgWKIyYhAAC3CAw From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 01 Aug 2003 00:59:05.0950 (UTC) FILETIME=[1B4B47E0:01C357C8] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > >Which type of abuse are you concerned with? We can deploy native-to-6to4 > >relays in several modes: > > > > - host specific=3D20 > > (host is multi-homed to 6to4, local routing entry to 2002::/16) > > - AS specific=3D20 > > (some routers act as relay, export a route to 2002::/16 in IGP) > > - Across multiple AS > > (export a route to 2002::/16 in BGP) > > > >The first two modes don't seem particularly prone to abuse. Host > >specific relays certainly are not an issue, and the abuse to AS specific > >relay fall in the general category of "abusing peering agreements", > >which is by no means specific to 6to4. I agree that exporting a route > >through BGP is hard to control, as the route can be re-exported by > >peering ASes. But, again, this fall in the category of "peering abuses", > >which can be contained by proper peering contracts. >=20 > we are afraid of our native-to-6to4 device being used as open relay > of packet (bullet 3 in the above, of course). the IPv4 source > address > will be ours, so we will get compliants from random people, because > of > malicious traffic from somewhere to 2002::/16. running 6to4 relay > router is like running open relay smtp server. The comparison with an open relay smtp server is a bit excessive. In the native to 6to4 direction, the 6to4 relay will send over IPv4 a 6to4 packet (protocol type 41), in which the payload will the original IPv6 packet. The main attack through such gateway is to send packets to IPv4 nodes, which can be either 6to4 or legacy.=20 The attacks to 6to4 nodes are basically the same as attacks over IPv6 to native nodes. From that point of view, running the relay is pretty much equivalent to providing BGP peering to a third party network, and does not seem to create a particular type of concern. The attacks to legacy nodes can only be DoS attacks -- the legacy nodes don't understand 6to4, and will not understand the packets. However, if the attack is serious, someone will analyze the content and find out the source IPv6 address. If the source address cannot be spoofed, then the attacker will be caught. If the source address can be spoofed, then the "open relay" issue is caused by the lack of filtering at the origin, not by 6to4. -- Christian Huitema=20