From owner-v6ops@ops.ietf.org Sat Aug 2 00:36: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 AAA22308 for ; Sat, 2 Aug 2003 00:36:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19io4M-0009US-Jq for v6ops-data@psg.com; Sat, 02 Aug 2003 04:32:38 +0000 Received: from [209.249.147.145] (helo=addr-mx01.addr.com) by psg.com with esmtp (Exim 4.20) id 19io4C-0009U7-DI for v6ops@ops.ietf.org; Sat, 02 Aug 2003 04:32:28 +0000 Received: from proxy1.addr.com (proxy1.addr.com [209.249.147.28]) by addr-mx01.addr.com (8.12.8/8.12.2) with ESMTP id h724WOdo004153 for ; Fri, 1 Aug 2003 21:32:24 -0700 (PDT) Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.12.8/8.12.8/Submit) with ESMTP id h724WNWw073482 for ; Fri, 1 Aug 2003 21:32:23 -0700 (PDT) Message-Id: <5.2.0.9.0.20030801212949.0272d310@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 01 Aug 2003 21:32:22 -0700 To: v6ops@ops.ietf.org From: Bob Fink Subject: draft minutes of v6ops Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_20,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 The draft minutes from the v6ops working group sessions at the Vienna IETF are available at the url below. Note that Bob has constructed this from various sets of notes sent to him, as he didn't attend the meeting. So please review carefully and send us comments and corrections. Thanks, Bob, Pekka & Margaret From owner-v6ops@ops.ietf.org Sun Aug 3 12:45: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 MAA21925 for ; Sun, 3 Aug 2003 12:45:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jLta-0000mx-HL for v6ops-data@psg.com; Sun, 03 Aug 2003 16:39:46 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19jLtW-0000mk-Gs for v6ops@ops.ietf.org; Sun, 03 Aug 2003 16:39:42 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C784FB19C; Sun, 3 Aug 2003 12:39:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 3 Aug 2003 12:39:41 -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: Defintion of Automatic tunnels Date: Sun, 3 Aug 2003 12:39:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B049D13B5@tayexc13.americas.cpqcorp.net> Thread-Topic: Defintion of Automatic tunnels Thread-Index: AcNWm78dck6dyOkQQJ2k2OIhKB8oaQDQa8Gw From: "Bound, Jim" To: "Erik Nordmark" , "Brian E Carpenter" Cc: "Christian Huitema" , X-OriginalArrivalTime: 03 Aug 2003 16:39:41.0294 (UTC) FILETIME=[D634E0E0:01C359DD] 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 Erik, The market will decide. Also there is ISATAP and DSTM and being deployed now. I am working with networks that use them in Pilots now. Market it not going to wait for IETF brainstorming anymore. Vendors who wait will loose opportunity to influence pilots that will define next step production and be part of that revenue stream. You need to add DSTM and ISATAP to this fray not just Teredo. =20 Also the options to tunnel on products will be done based on market input to the product suppliers. Our job here is to define what options we will work on in the IETF others will be worked on out of the IETF or move to Experimental in the IETF. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 > Sent: Wednesday, July 30, 2003 9:06 AM > To: Brian E Carpenter > Cc: Erik Nordmark; Christian Huitema; v6ops@ops.ietf.org > Subject: Re: Defintion of Automatic tunnels >=20 >=20 > > This is an interesting discussion of the issues (well, it=20 > was, but I=20 > > deleted it to save bits). But I'm not sure that the WG has to, or=20 > > should, make a choice. The network is already telling us that both=20 > > tunnel brokers and 6to4 attract users. I guess the jury is=20 > still out=20 > > on Teredo. But I don't think it's for us to make a philosophical=20 > > decision here. We will need to decide whether to adopt Teredo, but=20 > > that should drop out of the scenario analysis as a=20 > pragmatic decision. >=20 > Brian, >=20 > You seem to be making a "the market will decide" argument=20 > with respect to 6to4 and tunnel brokers. Is that correct? >=20 > I find it disconcerting that you didn't want to contribute to=20 > the understanding of the issues (with apply to all tunneling=20 > approaches - 6to4, teredo, tunnel > brokers) and instead deleted the email to "save bits". That=20 > doesn't bode well for making forward progress. >=20 > Sigh > Erik >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun Aug 3 12:45: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 MAA21949 for ; Sun, 3 Aug 2003 12:45:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jLvR-0000u7-HN for v6ops-data@psg.com; Sun, 03 Aug 2003 16:41:41 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19jLvO-0000tv-RO for v6ops@ops.ietf.org; Sun, 03 Aug 2003 16:41:38 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 53B7B707; Sun, 3 Aug 2003 12:41:38 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 3 Aug 2003 12:41: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: Defintion of Automatic tunnels Date: Sun, 3 Aug 2003 12:41:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B049D13B6@tayexc13.americas.cpqcorp.net> Thread-Topic: Defintion of Automatic tunnels Thread-Index: AcNWoAawRLwmaSzNQXmFxh9/6Gz3CwDPds/Q From: "Bound, Jim" To: "Brian E Carpenter" , "Erik Nordmark" Cc: "Christian Huitema" , X-OriginalArrivalTime: 03 Aug 2003 16:41:38.0215 (UTC) FILETIME=[1BE59B70:01C359DE] 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 tunnel brokers and 6to4 are the most pervasive used tunnels in deployment today across Asia, Europe, and now the U.S. Done deal. Tunnel broker is done deal too. It will compete with Teredo as solution too once proto 41 gets through cablemodem and dsl products and ISPs provide it. there are 100,000 users using freenet6 tunnels. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Wednesday, July 30, 2003 9:38 AM > To: Erik Nordmark > Cc: Christian Huitema; v6ops@ops.ietf.org > Subject: Re: Defintion of Automatic tunnels >=20 >=20 > Erik Nordmark wrote: > >=20 > > > This is an interesting discussion of the issues (well, it=20 > was, but I=20 > > > deleted it to save bits). But I'm not sure that the WG has to, or=20 > > > should, make a choice. The network is already telling us=20 > that both=20 > > > tunnel brokers and 6to4 attract users. I guess the jury=20 > is still out=20 > > > on Teredo. But I don't think it's for us to make a philosophical=20 > > > decision here. We will need to decide whether to adopt=20 > Teredo, but=20 > > > that should drop out of the scenario analysis as a pragmatic=20 > > > decision. > >=20 > > Brian, > >=20 > > You seem to be making a "the market will decide" argument=20 > with respect=20 > > to 6to4 and tunnel brokers. Is that correct? >=20 > Not quite. My point is more that since the (so far=20 > revenue-free) market already seems to want both solutions, I=20 > don't see that a decision is needed. Deployment has moved on=20 > since the v6ops charter was written. >=20 > > I find it disconcerting that you didn't want to contribute to the=20 > > understanding of the issues (with apply to all tunneling=20 > approaches -=20 > > 6to4, teredo, tunnel > > brokers) and instead deleted the email to "save bits". That=20 > doesn't bode well > > for making forward progress. >=20 > I think you and Christian have pretty much covered the arguments, and=20 > I don't have anything new to add. These arguments will be=20 > very useful,=20 > when looking at the scenarios, to decide whether the WG=20 > should adopt Teredo=20 > as a work item.=20 >=20 > Brian >=20 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=20 > - - Brian E Carpenter=20 > Distinguished Engineer, Internet Standards & Technology, IBM=20 >=20 > NEW ADDRESS PLEASE UPDATE ADDRESS BOOK >=20 >=20 From owner-v6ops@ops.ietf.org Sun Aug 3 12:45: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 MAA21970 for ; Sun, 3 Aug 2003 12:45:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jLyt-000176-IZ for v6ops-data@psg.com; Sun, 03 Aug 2003 16:45:15 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19jLyq-00016j-BY for v6ops@ops.ietf.org; Sun, 03 Aug 2003 16:45:12 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D69BA71D3; Sun, 3 Aug 2003 12:45:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 3 Aug 2003 12:45:10 -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: Defintion of Automatic tunnels Date: Sun, 3 Aug 2003 12:45:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B049D13B7@tayexc13.americas.cpqcorp.net> Thread-Topic: Defintion of Automatic tunnels Thread-Index: AcNWvR+mPgw+UdNuR7+NcTYVCqAWwwAAP1XAAMgD9HA= From: "Bound, Jim" To: "Christian Huitema" , , "Brian E Carpenter" Cc: "Erik Nordmark" , X-OriginalArrivalTime: 03 Aug 2003 16:45:10.0756 (UTC) FILETIME=[9A94CA40:01C359DE] 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 100% agree with Christian I strongly suggest to the chairs and ADs work on the specs and stop trying to tell vendors how to build or what to provide in products we won't listen to your here simply because the folks here do not do budgets and product decisions per se it is done based on revenue not computer science. Like Pekka awhile ago saying "just state no one can deploy IPv6 only devices" that is completely absurd no one is going to even listen to such diatribe in the market. also I have figured out a way to avoid nat in IM for 3GPP the question for me is it even worth sharing that pearl here in the IETF or just take it to 3GPP and TEMS vendors. Hint is option I found in pdp context packet. /jim > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20 > Sent: Wednesday, July 30, 2003 1:19 PM > To: Alain.Durand@Sun.COM; Brian E Carpenter > Cc: Erik Nordmark; v6ops@ops.ietf.org > Subject: RE: Defintion of Automatic tunnels >=20 >=20 > > 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. >=20 > This is pretty close to recommending operational procedures,=20 > and frankly that is not what the IETF does best. The IETF=20 > shines when it produces sound specifications, or thorough=20 > technical analyses. But operation practices are better left=20 > to practicians, which may be another way of saying "to the market." >=20 > -- Christian Huitema >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Sun Aug 3 13:30: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 NAA22503 for ; Sun, 3 Aug 2003 13:30:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jMft-0003mz-AJ for v6ops-data@psg.com; Sun, 03 Aug 2003 17:29:41 +0000 Received: from [193.72.156.161] (helo=mercury.telscom.ch) by psg.com with esmtp (Exim 4.20) id 19jMfq-0003mn-IR for v6ops@ops.ietf.org; Sun, 03 Aug 2003 17:29:38 +0000 Received: from vaiooo (193.72.156.77) by mercury.telscom.ch with MERCUR-SMTP/POP3/IMAP4-Server (v3.30.09 AS-2621446) for ; Sun, 3 Aug 2003 19:20:29 +0200 From: "Marcin Michalak" Organization: Telscom To: v6ops@ops.ietf.org Date: Sun, 03 Aug 2003 19:29:31 +0200 MIME-Version: 1.0 Subject: RE: Defintion of Automatic tunnels Message-ID: <3F2D629B.9222.917492B@localhost> In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B049D13B7@tayexc13.americas.cpqcorp.net> X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Reply-To: marcin@telscom.ch X-Spam-Status: No, hits=-22.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On 3 Aug 2003 at 12:45, Bound, Jim wrote: > 100% agree with Christian I strongly suggest to the chairs and ADs work > on the specs and stop trying to tell vendors how to build or what to > provide in products we won't listen to your here simply because the > folks here do not do budgets and product decisions per se it is done > based on revenue not computer science. > > Like Pekka awhile ago saying "just state no one can deploy IPv6 only > devices" that is completely absurd no one is going to even listen to > such diatribe in the market. > > also I have figured out a way to avoid nat in IM for 3GPP the question > for me is it even worth sharing that pearl here in the IETF or just take > it to 3GPP and TEMS vendors. Hint is option I found in pdp context > packet. > > /jim Hello, Whatever you decide, please let know the solution? I'd be interested in getting to know it, probably others as well. Enjoy the Sunday, or what's left of it, Marcin ---------------------------------------------------------- Marcin Michalak Research Engineer Mobile: +41 79 330 83 51 Telscom AG From owner-v6ops@ops.ietf.org Sun Aug 3 14:44: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 OAA23913 for ; Sun, 3 Aug 2003 14:44:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jNnn-0007u1-AQ for v6ops-data@psg.com; Sun, 03 Aug 2003 18:41:55 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.20) id 19jNnj-0007tn-QC for v6ops@ops.ietf.org; Sun, 03 Aug 2003 18:41: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 26-md50000000023.tmp for ; Sun, 03 Aug 2003 20:43:29 +0200 Message-ID: <037301c359ee$df628490$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-palet-v6ops-proto41-nat-01.txt Date: Sun, 3 Aug 2003 20:41:36 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Processed: consulintel.es, Sun, 03 Aug 2003 20:43:29 +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=-1.5 required=5.0 tests=BAYES_20,RCVD_IN_NJABL,X_NJABL_OPEN_PROXY version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, The revision of the document indicated in the subject, has been published a few days ago, as indicated below. I will be happy to get new comments from the WG. Regards, Jordi A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Forwarding Protocol 41 in NAT Boxes Author(s) : J. Palet et al. Filename : draft-palet-v6ops-proto41-nat-01.txt Pages : 12 Date : 2003-7-31 Some NAT boxes/routers allow the establishment of IPv6 tunnels from systems in the private LAN (using private IPv4 addresses) to routers or tunnel servers in the public Internet. As far as we know this is not a common way of use IPv6 tunnels; the usual way is to finish the tunnel directly in a device with an IPv4 public address. This behavior provides a big opportunity to rapidly deploy a huge number of IPv6 nodes and networks, without the need of new transition mechanism. This option is very important to facilitate the IPv6 deployment. This document describes this behavior and provides hints that should be applied in the NAT boxes and tunnel brokers to facilitate it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Mon Aug 4 16:42:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11394 for ; Mon, 4 Aug 2003 16:42:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19jm4x-0007r7-7l for v6ops-data@psg.com; Mon, 04 Aug 2003 20:37:15 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19jm4v-0007ql-BA; Mon, 04 Aug 2003 20:37:13 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19jm4v-000M2V-R6; Mon, 04 Aug 2003 13:37:13 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 4 Aug 2003 13:37:13 -0700 To: "Bound, Jim" Cc: "Brian E Carpenter" , "Erik Nordmark" , "Christian Huitema" , Subject: RE: Defintion of Automatic tunnels References: <9C422444DE99BC46B3AD3C6EAFC9711B049D13B6@tayexc13.americas.cpqcorp.net> Message-Id: 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 > tunnel brokers and 6to4 are the most pervasive used tunnels in > deployment today across Asia, Europe, and now the U.S. all 12 of them From owner-v6ops@ops.ietf.org Tue Aug 5 09:13: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 JAA09470 for ; Tue, 5 Aug 2003 09:13:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19k1Zp-00049D-BZ for v6ops-data@psg.com; Tue, 05 Aug 2003 13:10:09 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19k1Zl-00048A-MC for v6ops@ops.ietf.org; Tue, 05 Aug 2003 13:10:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h75D9tE29462; Tue, 5 Aug 2003 16:09:56 +0300 Date: Tue, 5 Aug 2003 16:09:55 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: Christian Huitema , Subject: Re: Automatic tunnels In-Reply-To: <20030731232640.80EB013@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-17.9 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 1 Aug 2003 itojun@iijlab.net wrote: [...] > 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. .. which is one reason why we force our 6to4 relay to use 192.88.99.1 as the source address when it encapsulates packets in proto-41 :-) That way, "our" IPv4 address cannot be traced to be the source of the abuse. It cuts both ways, of course .. and might be prone to even increase the amount of anonymous abuse later on.. -- 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 Aug 5 09: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 JAA10884 for ; Tue, 5 Aug 2003 09:48:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19k2AE-00063Q-2Y for v6ops-data@psg.com; Tue, 05 Aug 2003 13:47:46 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19k2AA-000636-T0 for v6ops@ops.ietf.org; Tue, 05 Aug 2003 13:47:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h75DlSe29998; Tue, 5 Aug 2003 16:47:28 +0300 Date: Tue, 5 Aug 2003 16:47:27 +0300 (EEST) From: Pekka Savola To: Tsirtsis George cc: "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0BFF54@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 Sorry for a late reply.. On Thu, 31 Jul 2003, Tsirtsis George wrote: > 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. That is incorrect. MIPv6 and MIPv4 do introduce a data path overhead, in the form of the inclusion of IP-in-IP encapsulation, Routing headers and Home Address options (etc.). I think this is what Alain was referring to. > 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. And what benefit, exactly, would the change in encapsulation have? The Home Agents and the nodes would still have to support both versions, you would just end up with two Mobile IP protocols which (to some extent) supported both IPv4 and IPv6. Looking briefly at the conclusions section gives me an impression you want a transport-protocol independent MobileIP++ that's agnostic of IPv4 or IPv6, with an understanding that you would not have to solve the problem of the direct communication between IPv6-only and IPv4-only nodes. It seems like HIP fits the bill quite nicely, and would be architecturally better approach than trying to glue MIPv4 and MIPv6 together somehow. -- 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 Aug 5 11:03: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 LAA15420 for ; Tue, 5 Aug 2003 11:03:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19k3Kl-000AYy-HI for v6ops-data@psg.com; Tue, 05 Aug 2003 15:02:43 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19k3Kj-000AYl-CA for v6ops@ops.ietf.org; Tue, 05 Aug 2003 15:02:41 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 5 Aug 2003 11:02:39 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C3F@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Tsirtsis George Cc: "'Alain Durand'" , "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: Tue, 5 Aug 2003 11:02:18 -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 > > 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. > > And what benefit, exactly, would the change in encapsulation > have? => Did you see the problems in the draft? I'll sumarise: - half the signalling in the local and home domain - One mobility management protocol is used. - IPv6 Connections survive moving from a dual stack network to a V4 only network. The > Home Agents and the nodes would still have to support both > versions, you > would just end up with two Mobile IP protocols which (to > some extent) > supported both IPv4 and IPv6. => Only one MIP version is needed. Of course a dual stack is needed in the HA and MNs but _not_ dual MIP versions. > It seems like HIP fits the bill quite nicely, and would be > architecturally > better approach than trying to glue MIPv4 and MIPv6 together somehow. => This is not a research project though. MIP is deployed as we speak. Hesham From owner-v6ops@ops.ietf.org Tue Aug 5 11:11: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 LAA15719 for ; Tue, 5 Aug 2003 11:11:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19k3So-000B6s-Au for v6ops-data@psg.com; Tue, 05 Aug 2003 15:11:02 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19k3Sl-000B6Y-1e for v6ops@ops.ietf.org; Tue, 05 Aug 2003 15:10:59 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 5 Aug 2003 11:10:57 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFF79@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Pekka Savola'" Cc: "'Alain Durand'" , "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: Tue, 5 Aug 2003 11:10:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_01,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: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Tuesday, August 05, 2003 9:47 AM To: Tsirtsis George Cc: 'Alain Durand'; 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 ... > 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. And what benefit, exactly, would the change in encapsulation have? The Home Agents and the nodes would still have to support both versions, you would just end up with two Mobile IP protocols which (to some extent) supported both IPv4 and IPv6. GT> Running IPv6 over MIPv4 today means that you need to somehow encapsulate IPv6 over the existing IPv4 over IPv4 tunnel created by MIPv4 i.e.: double tunnel. With the suggested approach MIPv4 is itself able to create IPv6 over IPv4 tunnels as well as IPv4 over IPv4 tunnels i.e.: single tunneling. And yes, if we extend both MIPv4 and MIPv6 with dual stack extensions then we will have two protocols but a network or a mobile can choose to utilize only one of the two which will take it long way towards ubiquitous connectivity. Looking briefly at the conclusions section gives me an impression you want a transport-protocol independent MobileIP++ that's agnostic of IPv4 or IPv6, with an understanding that you would not have to solve the problem of the direct communication between IPv6-only and IPv4-only nodes. GT> I am clearly not suggesting transport independency since I am basing the extension on transport dependant MIPv4 and MIPv6. I am merely suggesting that these transport dependant protocols should be able to set up version independent tunnels It seems like HIP fits the bill quite nicely, and would be architecturally better approach than trying to glue MIPv4 and MIPv6 together somehow. GT>...with the addition that I view this as an *evolutionary* approach. The extensions I am talking about are suitable for networks that already utilize or want to utilize MIP (v4 or v6) for mobility management. GT> With respect, HIP has a long way to go before it becomes real and in any case I have never seen how HIP is going to solve the mobility management problem...if it does fantastic and the market I am sure will look at this when it becomes available...in the mean time people are deploying Mobile IP. Regards George From owner-v6ops@ops.ietf.org Wed Aug 6 04:48: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 EAA09648 for ; Wed, 6 Aug 2003 04:48:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kJsx-000EaU-TN for v6ops-data@psg.com; Wed, 06 Aug 2003 08:43:07 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19kJsu-000EaI-Lh for v6ops@ops.ietf.org; Wed, 06 Aug 2003 08:43:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h768gwV08054; Wed, 6 Aug 2003 11:42:59 +0300 Date: Wed, 6 Aug 2003 11:42:58 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: Erik Nordmark , 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=-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 Responding to a very old post.. On Wed, 16 Jul 2003, Christian Huitema wrote: > In fact, the document could get some editing. I certainly agree it could be clearer :-) > 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. But I'm not sure what you mean especially with the first two. Could you create an example threat based on the structure you'd propose to make us see the difference? > 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... Yes, it's very important to decide this. That's what I tried to raise in the v6ops security session in Vienna, but apparently there are no silver bullets which make it easier for you to consider what is the acceptable level of security. (.. and more importantly, whether it would warrant scrapping 6to4, trying to fix it somehow, documenting mitigation methods, encouraging folks to use different kind of mechanisms or what..) -- 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 Aug 6 05:02: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 FAA09856 for ; Wed, 6 Aug 2003 05:02:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kK9s-000FgG-2a for v6ops-data@psg.com; Wed, 06 Aug 2003 09:00:36 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19kK9o-000Ffy-R0 for v6ops@ops.ietf.org; Wed, 06 Aug 2003 09:00:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7690IO08240; Wed, 6 Aug 2003 12:00:18 +0300 Date: Wed, 6 Aug 2003 12:00:17 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org, , , Subject: RE: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047C9E94@tayexc13.americas.cpqcorp.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 Thanks Jim for your review. A couple of comments; from the others also very welcome (especially on the second point of recommended actions for IPv4-only specifications). On Sat, 26 Jul 2003, Bound, Jim wrote: > > 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 > > 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. I can see that section 1.2 is a bit off-topic. However, I think the core message is "don't just plan for upgrading from IPv4 to IPv6, consider IP version independence in general too". Perhaps the text could be tightened a bit if you agree with it? > 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. This is a double-edged sword. We could remove all the recommendations (even weak recommendations), but I think it would diminish the value of the documents slightly. That is, there are TONS of documents which document obsolete, historic or dubious protocols and we give the subject matter experts an opportunity to say "we don't need an upgrade for this [and possibly also state the reason]" instead of doing the paperwork to get them historic etc. I think this gives an average reader a better picture of what documents would need IPv6 updates and what not. Would you agree with this reasoning? If not, is there something else than removing all the Note that these are still "only" Informational documents. Also note that all the uppercase SHOULD/MUST statements wrt. what should be done should have been replaced with the lowercase ones, to give the right impression that this is not a normative documents. Some have certainly slipped through (it seems to me at least).) > I think the INTRO should be fixed before the others can move to INFO. Yes, it includes everything besides and is a normative reference. -- 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 Aug 6 05:05: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 FAA09882 for ; Wed, 6 Aug 2003 05:05:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kKER-000G2K-SE for v6ops-data@psg.com; Wed, 06 Aug 2003 09:05:19 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19kKEO-000G1l-Mz for v6ops@ops.ietf.org; Wed, 06 Aug 2003 09:05:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h76959f08297; Wed, 6 Aug 2003 12:05:09 +0300 Date: Wed, 6 Aug 2003 12:05:08 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Security considerations In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922BFC@ftmail.lab.flarion.com> 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, Soliman Hesham wrote: > Do you want to send text? Perhaps when you get back. > This comment is a bit too open. I think we had better to first try to settle the rest of the document (wrt. transition scenarios, etc.) because changes in those would affect the security considerations a lot too. > > -----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 > > > > > > > -- 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 Aug 6 05:17: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 FAA10027 for ; Wed, 6 Aug 2003 05:17:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kKPX-000GrO-94 for v6ops-data@psg.com; Wed, 06 Aug 2003 09:16:47 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19kKPU-000Gr4-AD for v6ops@ops.ietf.org; Wed, 06 Aug 2003 09:16:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h769Gcv08401; Wed, 6 Aug 2003 12:16:38 +0300 Date: Wed, 6 Aug 2003 12:16:37 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C3F@ftmail.lab.flarion.com> 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 Tue, 5 Aug 2003, Soliman Hesham wrote: > > > 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. > > > > And what benefit, exactly, would the change in encapsulation > > have? > > => Did you see the problems in the draft? I'll sumarise: I looked at them quickly, but was not convinced. > - half the signalling in the local and home domain Assuming the signalling is identical enough that they could be bundled together, and only one protocol could be used. I don't believe this is the case.. > - One mobility management protocol is used. These mobility management protocols are not interchangeable. They have significant differences. I do not think it is appropriate to think that we could accomplish the functions of one with the other. If so, it would certainly require some (even a great deal of) glue to hold it together, and the end result might be even worse than the other alternatives. > - IPv6 Connections survive moving from a dual stack network > to a V4 only network. Already happens if you enable e.g. 6to4 to gain IPv6 connectivity. If you had IPv6 connectivity in the past, but move somewhere where there is none, I think surviving the connections is not your biggest worry. > > The > > Home Agents and the nodes would still have to support both > > versions, you > > would just end up with two Mobile IP protocols which (to > > some extent) > > supported both IPv4 and IPv6. > > => Only one MIP version is needed. Of course a dual stack > is needed in the HA and MNs but _not_ dual MIP versions. Which means the one MIP version would have to include all the features of the other MIP version because otherwise it would not work? I.e., in practice dual MIP versions but just glued together in one? -- 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 Aug 6 05:54: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 FAA10679 for ; Wed, 6 Aug 2003 05:54:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kKyU-000IvK-71 for v6ops-data@psg.com; Wed, 06 Aug 2003 09:52:54 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19kKyQ-000Iuw-0p for v6ops@ops.ietf.org; Wed, 06 Aug 2003 09:52:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h769qaE08832; Wed, 6 Aug 2003 12:52:36 +0300 Date: Wed, 6 Aug 2003 12:52:36 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Christian Huitema , Subject: Re: Defintion of Automatic tunnels 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,CLICK_BELOW,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, 30 Jul 2003, Erik Nordmark wrote: > 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". This is a very good post, and I agree it's very important to try to get to the root causes why automatic tunnels are considered better/worse than configured tunnels in some aspects. My personal belief is that from Christian's Point-of-View (at least), it mainly boils down to point 6 -- I think he estimates that the number of nodes implementing the automatic tunneling mechanisms capable of "short-cut" routes is very high, so that the relay/server deployment is not so important. Personally, I think the non-optimal routing not an important factor; if the traffic gets too rough, it just gives people incentive to deploy dual-stack (or better tunnels, e.g. to their direct ISP). And if traffic gets too rough, it's just a sign of us succeeding and the time to retire automatic tunnels! :-) On the other hand, relays are critical because they're needed *ANYWAY* for communication with native IPv6 addresses, and providing a direct communication when that criterium is not met is a non-goal for IPv6. Better not deploy it at all (i.e. wait for ISP/NAT vendor) than improperly. .. some more comments inline .. > 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. True. > 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.) Agreed. However, there are likely to be counter-arguments for a single UDP port ("firewall FOO blocks that by default"), some of them maybe valid and others not. If we do so, we need to figure out when someone wants to use a more flexible port number.. > 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. Yes.. assuming that such a list could be kept up to date somehow (not an issue), and that registration to each tunnel broker would be similar (so filling one form would be enough, you'd just send it to anyone you'd like to connect to). > Or it would be > possible to define an anycast address for the tunnel broker setup (not > used for the tunneled packets). A good alternative, this could be similar to 192.88.99.0/24. The two of your proposals do not need to be exclusive, of course (could try 192.88.99.0 and pop up the list of addresses). > 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. True. > 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. Yes. Note that there may have to be a mechanism for the subscribers to keep the same prefix. It may be sufficient to depend on the IPv4 address of the SOHO DSL/cable box (if it's acting as a router), and when that changes (DHCP), the v6 prefix would also change. In most cases, this would probably be sufficient. For full-fledged solution, you'd need registration (ie. AAA system to keep track of the prefixes). So, I guess an important point is to figure out whether the IPv6 prefixes can be somehow magically tied to some IP[v4] addresses or other tokens when AAA system is not handy. > 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. See above. > 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? I think the ISP can reasonably well control that 6to4 relays are only used by their customers. But there is more to being simple for ISPs to deploy. For example, the point above: does it require an AAA system to keep track of prefixes given to the users? The authentication of users? 6to4 does not require it; you just add one box to the network, and you're pretty much done (as an ISP). Tunnel brokering is undeniably at least a bit more of a task. Of course, we can mitigate that by giving advice etc. Note that the ISP will need an AAA system anyway when it starts to offer IPv6 dual stack service (for prefix delegation/address assignment), so this is just having to implement it a bit earlier; maybe not a problem but could be. > 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. Agreed. > 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. Agreed. > For instance, it seems to me that this benefit goes away > when only one of the communicating parties implement 6to4/teredo. Exactly! [..] > 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. Exactly; more than once I've been bitten by a non-functioning 6to4 relay (for one reason or the other) at 192.88.99.0/24.. > 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). Yes. > The teredo interactions > with the large variation of NAT behavior makes this even harder. Exactly my concern as well. -- 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 Aug 6 08:42: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 IAA14268 for ; Wed, 6 Aug 2003 08:42:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kNaG-0000nZ-2D for v6ops-data@psg.com; Wed, 06 Aug 2003 12:40:04 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19kNaD-0000mt-0N for v6ops@ops.ietf.org; Wed, 06 Aug 2003 12:40:01 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 6 Aug 2003 08:39:59 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C46@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "'Alain Durand'" , "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: Wed, 6 Aug 2003 08:39:03 -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 > > - half the signalling in the local and home domain > > Assuming the signalling is identical enough that they could > be bundled > together, and only one protocol could be used. I don't > believe this is > the case.. => Why not? Let's take a simple example: A dual stack node that wants to be reachable on IPv4 and IPv6 addresses. It gets one v4 and one v6 home address. If it uses both MIP versions, every time it moves it will send two separate messages to its HA. Even worse, if we try to get a decent handover performance then another two messages will need to be sent to routers in the local network. > > > - One mobility management protocol is used. > > These mobility management protocols are not interchangeable. > They have > significant differences. I do not think it is appropriate > to think that > we could accomplish the functions of one with the other. If > so, it would > certainly require some (even a great deal of) glue to hold > it together, > and the end result might be even worse than the other alternatives. => We're not trying to get the full advantage of each one, this is a transition mechanism. Just like any tunnelling mechanism will make you lose some of IPv6's feature. This mechanism is not a goal, it's a mean to short term deployment for mobile nodes. > > > - IPv6 Connections survive moving from a dual stack network > > to a V4 only network. > > Already happens if you enable e.g. 6to4 to gain IPv6 > connectivity. If you > had IPv6 connectivity in the past, but move somewhere where > there is none, > I think surviving the connections is not your biggest worry. => What is your biggest worry then? I can't imagine a wireless operator deploying a service that works sometimes. This is a key problem to address. > > => Only one MIP version is needed. Of course a dual stack > > is needed in the HA and MNs but _not_ dual MIP versions. > > Which means the one MIP version would have to include all > the features of > the other MIP version because otherwise it would not work? => Absolutely not our intention. We're trying to walk first then run. Meaning, get basic connectivity and handover working then worry about optimal communication. Like I said above, this is a transitional issue, ultimately (I hope) only MIPv6 will be used and we can get all the benefits. I.e., in > practice dual MIP versions but just glued together in one? => Not really, George and I are working on two solutions and we'll publish them soon and hopefully this will be clarified. Hesham > > -- > 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 Aug 6 10:18: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 KAA18266 for ; Wed, 6 Aug 2003 10:18:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kP5M-0005uJ-Ak for v6ops-data@psg.com; Wed, 06 Aug 2003 14:16:16 +0000 Received: from [47.103.122.112] (helo=zrc2s0jx.nortelnetworks.com) by psg.com with esmtp (Exim 4.20) id 19kP5I-0005tz-Qq for v6ops@ops.ietf.org; Wed, 06 Aug 2003 14:16:12 +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 h76EGA720569 for ; Wed, 6 Aug 2003 09:16:10 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0DTN>; Wed, 6 Aug 2003 09:16:11 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF648791@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'v6ops@ops.ietf.org'" Subject: FW: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-01.txt Date: Wed, 6 Aug 2003 09:16:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C35C25.47FAE078" X-Spam-Status: No, hits=-7.8 required=5.0 tests=BAYES_20,HTML_20_30,ORIGINAL_MESSAGE version=2.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_01C35C25.47FAE078 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C25.47FAE078" ------_=_NextPart_001_01C35C25.47FAE078 Content-Type: text/plain; charset="iso-8859-1" Hi, I took a look at this document and have a comment: Before the IPv4 survey I-D (the latest "old" version was ) was split up into separate I-Ds corresponding to IETF areas, there was discussion of SIP, SDP, RTSP (and there should have been some discussion of RTP/RTCP since SDES CNAME can carry IP addresses). However, upon reviewing the I-D I see no mention of these protocols. Was there a specific reason for not including them? Granted, there are a lot of SIP-based RFCs and Internet drafts, but at a minimum, shouldn't we mention the basic ones (don't know about the RFCbis I-Ds): (1) RFC 3261 "SIP: Session Initiation Protocol" (2) RFC 3266 "Support for IPv6 in Session Description Protocol (SDP)" (3) RFC 2327 "SDP: Session Description Protocol" -> being updated by (4) RFC 2326 "Real Time Streaming Protocol (RTSP)-> being updated by (5) RFC 3550 "RTP: A Transport Protocol for Real-Time Applications" Regards, Pete -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 02, 2003 5:11 PM Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-01.txt 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_001_01C35C25.47FAE078 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-01.txt

Hi,

I took a look at this document and have a = comment:

Before the IPv4 survey I-D (the latest = "old" version was <draft-ietf-v6ops-ipv4survey-00.txt>) = was split up into separate I-Ds corresponding to IETF areas, there was = discussion of SIP, SDP, RTSP (and there should have been some = discussion of RTP/RTCP since SDES CNAME can carry IP addresses). = However, upon reviewing the I-D = <draft-ietf-v6ops-ipv4survey-apps-01.txt> I see no mention of = these protocols. Was there a specific reason for not including = them?

Granted, there are a lot of SIP-based RFCs and = Internet drafts, but at a minimum, shouldn't we mention the basic ones = (don't know about the RFCbis I-Ds):

(1) RFC 3261 "SIP: Session Initiation = Protocol"
(2) RFC 3266 "Support for IPv6 in Session = Description Protocol (SDP)"
(3) RFC 2327 "SDP: Session Description = Protocol" -> being updated by = <draft-ietf-mmusic-sdp-new-13.txt>
(4) RFC 2326 "Real Time Streaming Protocol = (RTSP)-> being updated by = <draft-ietf-mmusic-rfc2326bis-04.txt>
(5) RFC 3550 "RTP: A Transport Protocol for = Real-Time Applications"

Regards,

Pete

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Wednesday, July 02, 2003 5:11 PM
Cc: v6ops@ops.ietf.org
Subject: I-D = ACTION:draft-ietf-v6ops-ipv4survey-apps-01.txt


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
          &nb= sp;           &nb= sp;   Application Area Standards
        Author(s)       : P. Nesser = II
        Filename        : = draft-ietf-v6ops-ipv4survey-apps-01.txt
        Pages           : = 69
        Date    =         : 2003-7-2
       =20
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-i= pv4survey-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".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C35C25.47FAE078-- ------_=_NextPart_000_01C35C25.47FAE078 Content-Type: message/rfc822 To: Subject: Date: Thu, 3 Jul 2003 07:40:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C35C25.47FAE078" ------_=_NextPart_002_01C35C25.47FAE078 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C35C25.47FAE078" ------_=_NextPart_003_01C35C25.47FAE078 Content-Type: text/plain ------_=_NextPart_003_01C35C25.47FAE078 Content-Type: text/html

  ------_=_NextPart_003_01C35C25.47FAE078-- ------_=_NextPart_002_01C35C25.47FAE078 Content-Type: application/octet-stream; name="ATT12156" Content-Disposition: attachment; filename="ATT12156" 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 ------_=_NextPart_002_01C35C25.47FAE078 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-v6ops-ipv4survey-apps-01"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C35C25.47FAE078-- ------_=_NextPart_000_01C35C25.47FAE078-- From owner-v6ops@ops.ietf.org Wed Aug 6 11:21:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21065 for ; Wed, 6 Aug 2003 11:21:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kQ5E-0009Xs-9C for v6ops-data@psg.com; Wed, 06 Aug 2003 15:20:12 +0000 Received: from [194.196.100.236] (helo=d12lmsgate-3.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19kQ5A-0009Xe-RY for v6ops@ops.ietf.org; Wed, 06 Aug 2003 15:20:09 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h76FK6ch112538 for ; Wed, 6 Aug 2003 17:20:06 +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 h76FK6f5282370 for ; Wed, 6 Aug 2003 17:20:06 +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 RAA39320 for ; Wed, 6 Aug 2003 17:20:05 +0200 Message-ID: <3F311CA4.40FE34A0@zurich.ibm.com> Date: Wed, 06 Aug 2003 17:20:04 +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: v6ops@ops.ietf.org Subject: Re: Residual threats in draft-savola-v6ops-6to4-security-02.txt? 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 below... Pekka Savola wrote: > > Responding to a very old post.. > > On Wed, 16 Jul 2003, Christian Huitema wrote: > > In fact, the document could get some editing. > > I certainly agree it could be clearer :-) > > > 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. > > But I'm not sure what you mean especially with the first two. Could you > create an example threat based on the structure you'd propose to make us > see the difference? > > > 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... > > Yes, it's very important to decide this. That's what I tried to raise in > the v6ops security session in Vienna, but apparently there are no silver > bullets which make it easier for you to consider what is the acceptable > level of security. > > (.. and more importantly, whether it would warrant scrapping 6to4, trying > to fix it somehow, documenting mitigation methods, encouraging folks to > use different kind of mechanisms or what..) Not just because it's my baby, but I don't see any realistic prospect of "scrapping" it at this point. Even if the IETF declared it Historic, it wouldn't go away. I don't think there is any realistic fix. IP address fields are spoofable, and this is just an example, with some negative consequences. So I think documenting the methods of mitigation is the only option in practice. Of course, if someone comes up with another low-configuration solution for hopping over uncooperative ISPs, that's fine too. That's where the recent conversation about tunnel brokers came from. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-v6ops@ops.ietf.org Wed Aug 6 14:05: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 OAA27410 for ; Wed, 6 Aug 2003 14:05:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kSda-000KsX-9A for v6ops-data@psg.com; Wed, 06 Aug 2003 18:03:50 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.20) id 19kSdX-000KsL-VT for v6ops@ops.ietf.org; Wed, 06 Aug 2003 18:03:48 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 11:03:51 -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, 6 Aug 2003 11:03:48 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Aug 2003 11:03:47 -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); Wed, 6 Aug 2003 11:03:53 -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, 6 Aug 2003 11:03: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); Wed, 6 Aug 2003 11:03:45 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Residual threats in draft-savola-v6ops-6to4-security-02.txt? Date: Wed, 6 Aug 2003 11:03:42 -0700 Message-ID: Thread-Topic: Residual threats in draft-savola-v6ops-6to4-security-02.txt? Thread-Index: AcNcMA62JBa+j4VYT/SpBvJnFau7ggAExPRy From: "Christian Huitema" To: "Brian E Carpenter" , X-OriginalArrivalTime: 06 Aug 2003 18:03:45.0190 (UTC) FILETIME=[13D79460:01C35C45] 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 > So I think documenting the methods of mitigation is the only option > in practice. Of course, if someone comes up with another = low-configuration > solution for hopping over uncooperative ISPs, that's fine too. That's > where the recent conversation about tunnel brokers came from. The recent discussion showed some new concerns, and also some possible = solutions. Itojun raised an important point: if your relay is used as = part of a DoS attack from IPv6 to an unsuspecting IPv4 node, then all = packets will appear to come from the relay's IPv4 address. Pekka = proposed a simple fix: just source the packets from 196.88.99.1, so they = won't be traceable to the ISP, and the ISP won't be easily sued. That's = a bit of a cope-out, though, and removing traceability is not = necessarily very good. If we are concerned with DoS attacks, the proper = solution is probably some form of rate-limiting, e.g. applying a fair = queuing algorithm based on the destination address. =20 -- Christian Huitema From owner-v6ops@ops.ietf.org Thu Aug 7 06: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 GAA06057 for ; Thu, 7 Aug 2003 06:09:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19khe0-000D2i-Fk for v6ops-data@psg.com; Thu, 07 Aug 2003 10:05:16 +0000 Received: from [194.196.100.235] (helo=d12lmsgate-2.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19khdv-000D2S-JX for v6ops@ops.ietf.org; Thu, 07 Aug 2003 10:05:11 +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 h77A597o099370 for ; Thu, 7 Aug 2003 12:05:09 +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 h77A59nQ260822 for ; Thu, 7 Aug 2003 12:05:09 +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 MAA27978 for ; Thu, 7 Aug 2003 12:05:08 +0200 Message-ID: <3F322453.A4DA3569@zurich.ibm.com> Date: Thu, 07 Aug 2003 12:05:07 +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: v6ops@ops.ietf.org Subject: Re: Residual threats in draft-savola-v6ops-6to4-security-02.txt? 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 Sure. I'd be happy to see this covered in the final version of Pekka's document. Brian Christian Huitema wrote: > > > So I think documenting the methods of mitigation is the only option > > in practice. Of course, if someone comes up with another low-configuration > > solution for hopping over uncooperative ISPs, that's fine too. That's > > where the recent conversation about tunnel brokers came from. > > The recent discussion showed some new concerns, and also some possible solutions. Itojun raised an important point: if your relay is used as part of a DoS attack from IPv6 to an unsuspecting IPv4 node, then all packets will appear to come from the relay's IPv4 address. Pekka proposed a simple fix: just source the packets from 196.88.99.1, so they won't be traceable to the ISP, and the ISP won't be easily sued. That's a bit of a cope-out, though, and removing traceability is not necessarily very good. If we are concerned with DoS attacks, the proper solution is probably some form of rate-limiting, e.g. applying a fair queuing algorithm based on the destination address. > > -- Christian Huitema -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-v6ops@ops.ietf.org Thu Aug 7 17:08: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 RAA03131 for ; Thu, 7 Aug 2003 17:08:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19kry1-0002ne-Q7 for v6ops-data@psg.com; Thu, 07 Aug 2003 21:06:37 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.20) id 19krxp-0002mX-4b for v6ops@ops.ietf.org; Thu, 07 Aug 2003 21:06:25 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h77L6NgM018097; Thu, 7 Aug 2003 23:06:23 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 7 Aug 2003 23:06:23 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F03768220@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, 7 Aug 2003 23:05:42 +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=-0.7 required=5.0 tests=BAYES_30,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 A late reply to Pekka below. Hope this can help in closing the loop on the tunnelling issue. > 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. When I plug into Ethernet or WLAN I don't know if the network supports IPv6 until I get an RA. In this case we know before activating the PDP Context i.e. L2 link. So this doesn't look like a flaw to me, although it could be improved with what you write above. > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > support in > remote SGSN's/GGSN's be avoided ? You could do that, but it would be an overkill IMO to run PPP over wireless. Since we're dealing with an expensive bandwidth limited link it's not an attractive alternative. > > > > 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. For example today operators have gprs (IPv4) roaming agreements with certain operators and only voice with others. > > > > 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? This is done using 3gpp protocols. > 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? Don't think so. You would try to set up this type of handoff (which involves passing PDP Context info from old to new SGSN) and the local SGSN would reject it if it didn't understand PDP type IPv6. > If SGSN doesn't support IPv6 PDP contexts but GGSN does, > you're out of > luck? (without tunneling by the UE) Yes. There's also another element involved (HLR) which needs to have some knowledge of IPv6 to authorise the user to use the IPv6 service. Basically the GGSN is not the only device that needs to know what IPv6 is in order for things to work, although it is the most important one from our IP-centric point of view. If you're in this special case (which will hopefully become rare in future) and you want to have a way of using IPv6 services then tunnelling is an attractive solution. > 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? For one thing you cannot open multiple connections to different operators at the same time. Apart from that you can try and connect to any operator which has roaming agreements with your home operator. > 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? You could if there are other roaming partners. But you could also just be wasting your time and it does waste quite a bit of time to detect the networks, pick an operator, check connectivity, detect again etc. > 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)? You can't do that. You can only be connected to one operator at a time. /Karim From owner-v6ops@ops.ietf.org Sat Aug 9 14:40: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 OAA03313 for ; Sat, 9 Aug 2003 14:40:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lYXc-000FUj-Fj for v6ops-data@psg.com; Sat, 09 Aug 2003 18:34:12 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19lYXY-000FUW-GN for v6ops@ops.ietf.org; Sat, 09 Aug 2003 18:34:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h79IXsj17293; Sat, 9 Aug 2003 21:33:54 +0300 Date: Sat, 9 Aug 2003 21:33:53 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C46@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.7 required=5.0 tests=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, 6 Aug 2003, Soliman Hesham wrote: > > > - half the signalling in the local and home domain > > > > Assuming the signalling is identical enough that they could > > be bundled > > together, and only one protocol could be used. I don't > > believe this is > > the case.. > > => Why not? Let's take a simple example: > A dual stack node that wants to be reachable on IPv4 > and IPv6 addresses. It gets one v4 and one v6 home > address. If it uses both MIP versions, every time > it moves it will send two separate messages to its > HA. Even worse, if we try to get a decent handover performance > then another two messages will need to be sent to > routers in the local network. You gave a description of a case where there seems to be unnecessary signalling that one could try to optimize away (using some means). My feeling is that there are workarounds (operational ones, i.e. no extensions for mobility management protocols) for this non-optimized signalling problem so the actual problem does not seem particularly attractive. Here, however, my point was not that: but rather, whether the two mobility management protocols are similar enough so that their signalling would be interchangeable or reasonably well doable with the other protocol (without significant drawbacks). My feeling is that this is not worth the effort. > > > - One mobility management protocol is used. > > > > These mobility management protocols are not interchangeable. > > They have > > significant differences. I do not think it is appropriate > > to think that > > we could accomplish the functions of one with the other. If > > so, it would > > certainly require some (even a great deal of) glue to hold > > it together, > > and the end result might be even worse than the other alternatives. > > => We're not trying to get the full advantage of each > one, this is a transition mechanism. Just like any > tunnelling mechanism will make you lose some of IPv6's > feature. This mechanism is not a goal, it's a mean to short > term deployment for mobile nodes. Transition to *WHAT*? IPv6-only mobility management and IPv6 being run on every subnet where a mobile node might roam to? I suspect both; the latter could take a very long while.. Wouldn't then it be just so much simpler to require the IPv6-capable node to always use IPv6? > > > - IPv6 Connections survive moving from a dual stack network > > > to a V4 only network. > > > > Already happens if you enable e.g. 6to4 to gain IPv6 > > connectivity. If you > > had IPv6 connectivity in the past, but move somewhere where > > there is none, > > I think surviving the connections is not your biggest worry. > > => What is your biggest worry then? When IPv6-capable node uses IPv6 but moves to a subnet where IPv6 is not supported, and IPv6 services are required for some purpose, it's first and primary problem is re-establishing IPv6 support in that subnet, in any means necessary. > I can't imagine a wireless > operator deploying a service that works sometimes. This is > a key problem to address. I'm not sure of the context you're referring to, so I can't comment on whether I would see this as a problem or not. What kind of devices are we talking about here? And what kind of networks? Would the network terminal devices be smart enough to be used (and expected to work) in the Internet by themselves (e.g. laptop with a WLAN) or not (e.g. 3GPP device)? > > > => Only one MIP version is needed. Of course a dual stack > > > is needed in the HA and MNs but _not_ dual MIP versions. > > > > Which means the one MIP version would have to include all > > the features of > > the other MIP version because otherwise it would not work? > > => Absolutely not our intention. We're trying to walk first > then run. Meaning, get basic connectivity and handover working > then worry about optimal communication. Like I said above, > this is a transitional issue, ultimately (I hope) only > MIPv6 will be used and we can get all the benefits. In transition, it's good to try to figure out questions like: - transition to _where_, - transition _how_, and - transition for _how long_? (for example). With IPv6 (ngtrans/v6ops) we haven't always been too successful in figuring that out though (and I'm not saying we're necessarily enlightened at the moment either :-).. :-/ -- 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 Aug 9 14:57: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 OAA03716 for ; Sat, 9 Aug 2003 14:57:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lYsf-000GUN-0Y for v6ops-data@psg.com; Sat, 09 Aug 2003 18:55:57 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19lYsc-000GU7-0Z for v6ops@ops.ietf.org; Sat, 09 Aug 2003 18:55:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h79Itce17483; Sat, 9 Aug 2003 21:55:39 +0300 Date: Sat, 9 Aug 2003 21:55:38 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Christian Huitema , , Brian E Carpenter , Erik Nordmark , Subject: RE: Defintion of Automatic tunnels In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B049D13B7@tayexc13.americas.cpqcorp.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 On Sun, 3 Aug 2003, Bound, Jim wrote: [...] > also I have figured out a way to avoid nat in IM for 3GPP the question > for me is it even worth sharing that pearl here in the IETF or just take > it to 3GPP and TEMS vendors. Hint is option I found in pdp context > packet. Please share it; I bet that could avoid a lot of pain in the specification and implementation perspectives (plus causing confusion due to IETF spec saying one thing and vendors doing the other). It would likely avoid doing NAT, NAT being something neither of us (and probably a huge majority of the community) don't want. > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: Wednesday, July 30, 2003 1:19 PM > > To: Alain.Durand@Sun.COM; Brian E Carpenter > > Cc: Erik Nordmark; v6ops@ops.ietf.org > > Subject: RE: Defintion of Automatic tunnels > > > > > > > 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 > > > > > > > -- 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 Aug 9 15:21: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 PAA05399 for ; Sat, 9 Aug 2003 15:21:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lZFd-000HXu-Lf for v6ops-data@psg.com; Sat, 09 Aug 2003 19:19:41 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19lZFZ-000HXh-N2 for v6ops@ops.ietf.org; Sat, 09 Aug 2003 19:19:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h79JJZq17673; Sat, 9 Aug 2003 22:19:35 +0300 Date: Sat, 9 Aug 2003 22:19:35 +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: <76E5F712842F5F49A35738622BAA0F4F03768220@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-27.3 required=5.0 tests=BAYES_30,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, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > 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. > > When I plug into Ethernet or WLAN I don't know if the network > supports IPv6 until I get an RA. Very true, but the expectations are entirely different (or that's my take at least). When I use my laptop and roam in the world, I generally *DON'T* expect IPv6 to be available. Hence, I'm equipped with some useful tools to enable IPv6 in the case network doesn't support it (e.g. 6to4 or configured tunnels). However, I think the expectation with 3GPP is entirely different: network supports IPv6, period. (And it would be unreasonable to assume the huge number of 3GPP devices to implement all the possible mechanisms required in every possible network scenario, be it 3GPP or regular old-fashioned Internet.) > In this case we know before > activating the PDP Context i.e. L2 link. So this doesn't look like > a flaw to me, although it could be improved with what you > write above. But we don't know it before the activation of PDP context (at least as far as I've understood). If the network doesn't support it, the PDP context activation is denied (for PDP type IPv6). This seems very much the same (both for the time consumed and otherwise) as sending re-transmissions for RFC2461/RFC2462 Router Discovery and ultimately deciding that IPv6 is not available. On the other hand, if we knew beforehand which PDP context types were supported (and by which roaming partners), picking the one with IPv6 support might be significantly easier. The other improvement I was suggesting (just to rephrase, trying to summarize) was referring to the ability to support gradual IPv6 deployment of 3GPP operator's equipment. That is, to make the tunneling IP protocol-transparent so that SGSN's, HLR's or GGSN's wouldn't have to support the PDP context type they would be serving, but would tunnel it nonetheless to its home network. > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > support in > > remote SGSN's/GGSN's be avoided ? > > You could do that, but it would be an overkill IMO to run PPP > over wireless. Since we're dealing with an expensive bandwidth > limited link it's not an attractive alternative. I think it would be useful to try to analyze the overhead of PPP in this scenario. It might not be that high, and it might only be the fallback solution where other mechanisms (i.e. finding an operator which would support IPv6, or refraining from using IPv6) would not work. > > > > 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. > > For example today operators have gprs (IPv4) roaming agreements > with certain operators and only voice with others. Do you know if there is a regional perspective to this? That is, if there are multiple potential roaming partners in an area, could you say that they often support different capabilities? If they support different capabilties, it might be easier to conclude that it's reasonable to expect some of them to support IPv6 (while some others wouldn't) -- and then cycling through roaming partners until finding a correct might be a thinkable approach. > > 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? > > Don't think so. You would try to set up this type of handoff (which > involves passing PDP Context info from old to new SGSN) and the local > SGSN would reject it if it didn't understand PDP type IPv6. Ok. > > If SGSN doesn't support IPv6 PDP contexts but GGSN does, > > you're out of > > luck? (without tunneling by the UE) > > Yes. There's also another element involved (HLR) which needs > to have some knowledge of IPv6 to authorise the user to use > the IPv6 service. Basically the GGSN is not the only device > that needs to know what IPv6 is in order for things to work, > although it is the most important one from our IP-centric point > of view. Ok. > If you're in this special case (which will hopefully become > rare in future) and you want to have a way of using IPv6 services > then tunnelling is an attractive solution. What I'm looking for is a way or two to work around that requirement; I would loath to see a requirement to implement tunneing solutions on mobile terminals to make the service work in areas where the 3GPP operator doesn't suddenly support IPv6. I think we should try to ways to leverage 3GPP network's capabilities to ensure that either: 1) the user is able to obtain IPv6 PDP context somehow; this is an issue when roaming to some other operator's network. Whether from that operator or by trying someone else doesn't matter. 2) the user is able to work around the issue by requesting PPP PDP context until the roaming partner supports IPv6 3) the user is able to stick to just using IPv4 when roaming in a network where there are no ways at all to get IPv6 using any means. > > 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? > > For one thing you cannot open multiple connections to different > operators at the same time. Apart from that you can try and connect > to any operator which has roaming agreements with your home operator. Ok. > > 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? > > You could if there are other roaming partners. Ok (typically there are..) > But you could > also just be wasting your time and it does waste quite a > bit of time to detect the networks, pick an operator, check > connectivity, detect again etc. How long is that usually? I'm not sure of your terminology, but I assume you'd actually only have to loop through "pick an operator" (simple) and "check connectivity" (when the PDP context activation has succeeded or failed). > > 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)? > > You can't do that. You can only be connected to one operator at > a time. Ok. -- 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 Aug 9 22:55: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 WAA13645 for ; Sat, 9 Aug 2003 22:55:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19lgIY-000AWm-QV for v6ops-data@psg.com; Sun, 10 Aug 2003 02:51:10 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19lgIV-000AWV-J2 for v6ops@ops.ietf.org; Sun, 10 Aug 2003 02:51:07 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sat, 9 Aug 2003 22:51:07 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C58@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "'Alain Durand'" , "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: Sat, 9 Aug 2003 22:50:43 -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 > > => Why not? Let's take a simple example: > > A dual stack node that wants to be reachable on IPv4 > > and IPv6 addresses. It gets one v4 and one v6 home > > address. If it uses both MIP versions, every time > > it moves it will send two separate messages to its > > HA. Even worse, if we try to get a decent handover performance > > then another two messages will need to be sent to > > routers in the local network. > > You gave a description of a case where there seems to be unnecessary > signalling that one could try to optimize away (using some means). My ^^^^^^^^^^^^^^^^^^ > feeling is that there are workarounds (operational ones, i.e. no ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > extensions for mobility management protocols) for this non-optimized > signalling problem so the actual problem does not seem particularly > attractive. => if you can solve this problem operationally please elaborate. It will be enlightning for me to see how. I.e. please elaborate on the underlined points above. Otherwise, I woulodn't be able to follow your conclusion. > > Here, however, my point was not that: but rather, whether > the two mobility > management protocols are similar enough so that their > signalling would be > interchangeable or reasonably well doable with the other > protocol (without > significant drawbacks). => And my answer is that they certainly have commonalities but not everything done in v6 can be done in V4. So we cannot get every feature if MIPv4 is used. My feeling is that this is not > worth the effort. => I don't understand how you reach this feeling. But then again, feelings don't have to be logical :) > > => We're not trying to get the full advantage of each > > one, this is a transition mechanism. Just like any > > tunnelling mechanism will make you lose some of IPv6's > > feature. This mechanism is not a goal, it's a mean to short > > term deployment for mobile nodes. > > Transition to *WHAT*? IPv6-only mobility management and > IPv6 being run on > every subnet where a mobile node might roam to? I suspect both; the > latter could take a very long while.. => Of course it will take time. > > Wouldn't then it be just so much simpler to require the > IPv6-capable node > to always use IPv6? => Huh? How does this help with the problem we're trying to solve? It's not about "using v6", it's about using it while you're moving. > > > Already happens if you enable e.g. 6to4 to gain IPv6 > > > connectivity. If you > > > had IPv6 connectivity in the past, but move somewhere where > > > there is none, > > > I think surviving the connections is not your biggest worry. > > > > => What is your biggest worry then? > > When IPv6-capable node uses IPv6 but moves to a subnet where > IPv6 is not > supported, and IPv6 services are required for some purpose, > it's first and > primary problem is re-establishing IPv6 support in that > subnet, in any > means necessary. => I'm really confused. This is the problem we are trying to solve! I thought you said it's not the biggest worry. How can you get IPv6 services when you don't have an IPv6 address and you're mobile...? > > > I can't imagine a wireless > > operator deploying a service that works sometimes. This is > > a key problem to address. > > I'm not sure of the context you're referring to, so I can't > comment on > whether I would see this as a problem or not. What kind of > devices are we > talking about here? => Doesn't matter, any host as defined in 2460. And what kind of networks? => Wireless IP networks. Would the network > terminal devices be smart enough to be used (and expected to > work) in the > Internet by themselves (e.g. laptop with a WLAN) => This is not the only example of a device, but yes this is one example. > In transition, it's good to try to figure out questions like: > - transition to _where_, > - transition _how_, and => Agreed. > - transition for _how long_? => Not sure why this question is relevant. I think trying to answer this is an exercise in futility. At least we never had an answer for it so far. Why is this needed? > (for example). > > With IPv6 (ngtrans/v6ops) we haven't always been too successful in > figuring that out though (and I'm not saying we're > necessarily enlightened > at the moment either :-).. :-/ => I thought the scenarios docs were going to enlighten everyone ;) Hesham From owner-v6ops@ops.ietf.org Mon Aug 11 10:24: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 KAA18003 for ; Mon, 11 Aug 2003 10:24:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mDWG-0002Dg-In for v6ops-data@psg.com; Mon, 11 Aug 2003 14:19:32 +0000 Received: from [194.196.100.235] (helo=d12lmsgate-2.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19mDWC-0002DT-Kl for v6ops@ops.ietf.org; Mon, 11 Aug 2003 14:19:28 +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 h7BEJQ7o019166 for ; Mon, 11 Aug 2003 16:19:26 +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 h7BEJQOA219608 for ; Mon, 11 Aug 2003 16:19:26 +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 QAA47232 for ; Mon, 11 Aug 2003 16:19:24 +0200 Message-ID: <3F37A5E9.29A387F4@zurich.ibm.com> Date: Mon, 11 Aug 2003 16:19:21 +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: v6ops@ops.ietf.org Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-24.3 required=5.0 tests=BAYES_30,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 Hi, This is important work and IMHO it's almost ready to ship. 1. draft-ietf-v6ops-ipv4survey-intro-01.txt Section 1.1 is too editorial, and section 1.2 is irrelevant. I would simply delete them. If a historical reference is wanted, use RFC 1752. The second and third paragraphs of Section 1.3 are also irrelevant, and should be removed, and tossed over the fence to the Problem WG. [I happen to agree with these paragraphs, but they don't belong here.] The rest of this draft is excellent. 2. draft-ietf-v6ops-ipv4survey-subip-01.txt No comments 3. draft-ietf-v6ops-ipv4survey-ops-01.txt No substantive comments. s/depreciated/deprecated/ (at least twice) Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK Pekka Savola wrote: > > 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 Aug 12 07:06: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 HAA08472 for ; Tue, 12 Aug 2003 07:06:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mWvb-000Iuv-On for v6ops-data@psg.com; Tue, 12 Aug 2003 11:02:59 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19mWvT-000IuY-5o for v6ops@ops.ietf.org; Tue, 12 Aug 2003 11:02:51 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 12 Aug 2003 07:02:48 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C5C@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Nikander'" , Tsirtsis George Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.tx t Date: Tue, 12 Aug 2003 07:02:44 -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 Pekka, Thanks for the comments. Response below. > Thanks for putting up this draft. I think it is very useful > in defining the problem. > > However, unfortunately I do not personally agree at all with > the recommendations in the draft: > > To me, it looks like such a solution might be workable, but the > resulting protocols might be very complex. Too complex, in my > humble opinion. => This week we plan on submitting at least one solution and we can assess complexity from there. But I'd like to emphasise that we are not aiming to have one protocol that will solve everything. Even now, MIPv4 cannot provide all of the features in MIPv6. I'd completely agree with the complexity argument if that were our goal, but we only aim to have a transitional solution. > > HIP provides already now an implemented, demonstrated alternativity. > It does not only allow seamless mobility between IPv4 and IPv6, but > it also integrates multi-address multi-homing with mobility. > > For an early draft describing what has been implemented, see > draft-nikander-hip-mm-00.txt. While that requires much more work, > for example, to determine how to deal with NAT devices etc, the > basic approach has been implemented and demonstrated. > > Hence, I would request that you drop the Mobile IP specific > recommendations from the problem statement draft, or at least > acknowledge that there are other approaches that may be able > to solve the problem in a different and perhaps better way. => Sure there are other approaches. However, our limiting factor is existing deployment. We want to deal with existing problems on the Internet that can be solved gradually. HIP does not do that now because a) it does not exist in standards or products, b) clearly not deployed, c) it has difficult problems that have not begun to be addressed (e.g. hierarchical name space ...etc). At this moment in time it is an idea that was prototyped and we all know the time it takes from conception to deployment. Look at v6 which was introduced for a much more tangible problem than the problems HIP is intended to solve, yet, 10 years later, deployment is still in its infancy (on a global level). So we need to realise these issues (in fact they are _the_ issues to think about) and not only look at the technical challenges. Hesham > > --Pekka Nikander > > From owner-v6ops@ops.ietf.org Tue Aug 12 08:25:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10579 for ; Tue, 12 Aug 2003 08:25:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mYAy-000PQU-8D for v6ops-data@psg.com; Tue, 12 Aug 2003 12:22:56 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19mYAw-000PQI-1E for v6ops@ops.ietf.org; Tue, 12 Aug 2003 12:22:54 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 12 Aug 2003 08:22:53 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C60@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Nikander'" , Soliman Hesham Cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, "'Thomas Narten'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.tx t Date: Tue, 12 Aug 2003 08:22:49 -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 > > > HIP provides already now an implemented, demonstrated > alternativity. > > > It does not only allow seamless mobility between IPv4 > and IPv6, but > > > it also integrates multi-address multi-homing with mobility. > ... > > > Hence, I would request that you drop the Mobile IP specific > > > recommendations from the problem statement draft, or at least > > > acknowledge that there are other approaches that may be able > > > to solve the problem in a different and perhaps better way. > > > > => Sure there are other approaches. However, our limiting factor > > is existing deployment. We want to deal with existing problems > > on the Internet that can be solved gradually. > > Well, I don't necessarily agree with respect to a problem > statement, as I wrote above. > > OTOH, if you want to restrict the problem statement to > incremental solutions, please state so already in the very > beginning. That is, either make clear that your problem statement > is a very narrowly scoped problem statement, aiming at providing > integrated IPv4/v6 mobility basing on existing deployment and > deployed protocols, or remove the MIP specific recommendations. > > In other words, I can see two different problem statements: one > focusing on incremental changes based on deployed protocols, and > another one that takes a look just at the problem, being not so > much concerned with existing deployment. => We're definitely concerned with existing deployment and its evolution (read: incremental approaches). I don't think this is a very narrow scope at all but we can certainly add that to the draft. IMHO, right now at > least I remain confused which one your draft refers to. > (Maybe I just read the draft too quickly.) => Hopefully this makes things clearer. We can add text to that effect. Hesham From owner-v6ops@ops.ietf.org Tue Aug 12 09:39: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 JAA12919 for ; Tue, 12 Aug 2003 09:39:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mZKD-0005TH-Mv for v6ops-data@psg.com; Tue, 12 Aug 2003 13:36:33 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.20) id 19mZK9-0005Sz-Ix for v6ops@ops.ietf.org; Tue, 12 Aug 2003 13:36:29 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7CDaRgM015079; Tue, 12 Aug 2003 15:36:27 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 12 Aug 2003 15:36:27 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F0376822C@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: Tue, 12 Aug 2003 15:36:25 +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, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > 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. > > > > When I plug into Ethernet or WLAN I don't know if the network > > supports IPv6 until I get an RA. > > Very true, but the expectations are entirely different (or > that's my take > at least). When I use my laptop and roam in the world, I generally > *DON'T* expect IPv6 to be available. Hence, I'm equipped > with some useful > tools to enable IPv6 in the case network doesn't support it > (e.g. 6to4 or > configured tunnels). > > However, I think the expectation with 3GPP is entirely > different: network > supports IPv6, period. (And it would be unreasonable to > assume the huge > number of 3GPP devices to implement all the possible > mechanisms required > in every possible network scenario, be it 3GPP or regular > old-fashioned > Internet.) To be precise it's 3GPP IMS services that support IPv6. I hope this will get all operators to support IPv6 for the obvious reasons such as peer-to-peer connectivity. However it is a different thing to expect any 3GPP network in general to support IPv6 from day one. In fact there are commercial 3GPP operators today (WCDMA and GSM) whose networks do not support IPv6. Also, all I have been saying is to recommend support for at least one type of tunnelling in this case. ISATAP does what is needed IMO, so you don't need to support every possible mechanism. > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > > support in > > > remote SGSN's/GGSN's be avoided ? > > > > You could do that, but it would be an overkill IMO to run PPP > > over wireless. Since we're dealing with an expensive bandwidth > > limited link it's not an attractive alternative. > > I think it would be useful to try to analyze the overhead of > PPP in this > scenario. It might not be that high, and it might only be > the fallback > solution where other mechanisms (i.e. finding an operator which would > support IPv6, or refraining from using IPv6) would not work. That would be asking for equipment to support IPv4, IPv6 and PPP to cater for a case which we hope will be rare. I would definitely limit it to IPv4 and IPv6 so that people would have to tunnel for the special cases and operators would have an incentive to migrate to native IPv6. PPP will not solve the problem in a clean way and will be a disincentive to migrate to native IPv6. > > For example today operators have gprs (IPv4) roaming agreements > > with certain operators and only voice with others. > > Do you know if there is a regional perspective to this? > That is, if there > are multiple potential roaming partners in an area, could > you say that > they often support different capabilities? > If they support different capabilties, it might be easier to > conclude that > it's reasonable to expect some of them to support IPv6 > (while some others > wouldn't) -- and then cycling through roaming partners until > finding a > correct might be a thinkable approach. Personally I wouldn't see why an operator would want to limit its market to certain type of services in a certain area. From what I know the above cannot be taken as a rule. I don't think I would design a standard based on a single business model anyway. > > If you're in this special case (which will hopefully become > > rare in future) and you want to have a way of using IPv6 services > > then tunnelling is an attractive solution. > > What I'm looking for is a way or two to work around that > requirement; I > would loath to see a requirement to implement tunneing > solutions on mobile > terminals to make the service work in areas where the 3GPP operator > doesn't suddenly support IPv6. > > I think we should try to ways to leverage 3GPP network's > capabilities to > ensure that either: > > 1) the user is able to obtain IPv6 PDP context somehow; > this is an issue > when roaming to some other operator's network. Whether from > that operator > or by trying someone else doesn't matter. > > 2) the user is able to work around the issue by requesting PPP PDP > context until the roaming partner supports IPv6 > > 3) the user is able to stick to just using IPv4 when > roaming in a network > where there are no ways at all to get IPv6 using any means. Number 1) is unworkable as I've explained before. There are also business issues that will make it useless in many cases (i.e. there is only one data roaming partner which is common today). Number 2) isn't workable either. You're not going to convince operators to get support for PPP (which is normally not there today) only because they need IPv6; they would get native IPv6 directly. Tunnelling is fine as a migration tool and we've tested it. It's the only feasible choice and it will lead to a migration to native IPv6. /Karim From owner-v6ops@ops.ietf.org Tue Aug 12 09:58: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 JAA13601 for ; Tue, 12 Aug 2003 09:58:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mZeg-0007an-F0 for v6ops-data@psg.com; Tue, 12 Aug 2003 13:57:42 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19mZea-0007aR-H8 for v6ops@ops.ietf.org; Tue, 12 Aug 2003 13:57:36 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19mZea-000FsZ-4Q for v6ops@ops.ietf.org; Tue, 12 Aug 2003 06:57:36 -0700 Message-ID: <3F38BB93.1060900@nomadiclab.com> MIME-Version: 1.0 References: <748C6D0A58C0F94CA63C198B6674697A0BFF41@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0BFF41@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Aug 2003 13:04:03 +0300 From: Pekka Nikander To: Tsirtsis George Cc: "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Subject: Re: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt 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 Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] [Slowly catching up old e-mail] George and Hesham, Tsirtsis George wrote: > 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. Thanks for putting up this draft. I think it is very useful in defining the problem. However, unfortunately I do not personally agree at all with the recommendations in the draft: > 3. Conclusion and recommendations > > It is reasonable to assume that the separation between mobility > signaling and IP version used in media planes could be adopted by the > Mobile IP protocol. > > To that effect, the following work areas seem to be reasonable: > - it should be possible to create IPv4 extensions to Mobile IPv6 so > that a dual stack mobile node can register its IPv4 and IPv6 HoAs to > a dual stack Home Agent using MIPv6 signaling only. > - it should be possible to create IPv6 extensions to MIPv4 so that a > dual stack mobile node can register its IPv4 and IPv6 HoAs to a dual > stack Home Agent using MIPv4 signaling only. > - it should also be possible to extend MIPv4 and MIPv6 so that a > mobile can register a single CoA (IPv4 or IPv6) to which IPv4 and/or > IPv6 packets can be diverted to. To me, it looks like such a solution might be workable, but the resulting protocols might be very complex. Too complex, in my humble opinion. HIP provides already now an implemented, demonstrated alternativity. It does not only allow seamless mobility between IPv4 and IPv6, but it also integrates multi-address multi-homing with mobility. For an early draft describing what has been implemented, see draft-nikander-hip-mm-00.txt. While that requires much more work, for example, to determine how to deal with NAT devices etc, the basic approach has been implemented and demonstrated. Hence, I would request that you drop the Mobile IP specific recommendations from the problem statement draft, or at least acknowledge that there are other approaches that may be able to solve the problem in a different and perhaps better way. --Pekka Nikander From owner-v6ops@ops.ietf.org Tue Aug 12 10:00: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 KAA13748 for ; Tue, 12 Aug 2003 10:00:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mZgs-0007ih-Lk for v6ops-data@psg.com; Tue, 12 Aug 2003 13:59:58 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19mZgq-0007iV-9N for v6ops@ops.ietf.org; Tue, 12 Aug 2003 13:59:56 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19mZgp-000FwF-Ui for v6ops@ops.ietf.org; Tue, 12 Aug 2003 06:59:56 -0700 Message-ID: <3F38D45F.7020908@nomadiclab.com> MIME-Version: 1.0 References: <748C6D0A58C0F94CA63C198B6674697A01922C5C@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C5C@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Aug 2003 14:49:51 +0300 From: Pekka Nikander To: Soliman Hesham Cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, "'Thomas Narten'" Subject: Re: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.tx t X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,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 Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Soliman Hesham wrote: > > However, unfortunately I do not personally agree at all with > > the recommendations in the draft: > > > > To me, it looks like such a solution might be workable, but the > > resulting protocols might be very complex. Too complex, in my > > humble opinion. > > => This week we plan on submitting at least one solution > and we can assess complexity from there. But I'd like to > emphasise that we are not aiming to have one protocol that > will solve everything. Even now, MIPv4 cannot provide all > of the features in MIPv6. I'd completely agree with the > complexity argument if that were our goal, but we only > aim to have a transitional solution. I see. However, I'd still like to see a non-biased problem statement, stating the problem and not skewed towards some specific kind of a solution. > > HIP provides already now an implemented, demonstrated alternativity. > > It does not only allow seamless mobility between IPv4 and IPv6, but > > it also integrates multi-address multi-homing with mobility. ... > > Hence, I would request that you drop the Mobile IP specific > > recommendations from the problem statement draft, or at least > > acknowledge that there are other approaches that may be able > > to solve the problem in a different and perhaps better way. > > => Sure there are other approaches. However, our limiting factor > is existing deployment. We want to deal with existing problems > on the Internet that can be solved gradually. Well, I don't necessarily agree with respect to a problem statement, as I wrote above. OTOH, if you want to restrict the problem statement to incremental solutions, please state so already in the very beginning. That is, either make clear that your problem statement is a very narrowly scoped problem statement, aiming at providing integrated IPv4/v6 mobility basing on existing deployment and deployed protocols, or remove the MIP specific recommendations. In other words, I can see two different problem statements: one focusing on incremental changes based on deployed protocols, and another one that takes a look just at the problem, being not so much concerned with existing deployment. IMHO, right now at least I remain confused which one your draft refers to. (Maybe I just read the draft too quickly.) > At this moment in time [HIP] is an idea that was prototyped and > we all know the time it takes from conception to deployment. I completely agree. I just want to have a clear scope for the problem statement. As a side issue, I want to remind people, especially in the light of the Vienna IAB open meeting, that there are a number of complex architectural problems that we need to solve at some point of time, and as we proceed to solve them, some of the hard problems that people currently use much effort to solve may suddenly completely change their nature. --Pekka Nikander From owner-v6ops@ops.ietf.org Tue Aug 12 10:11: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 KAA14717 for ; Tue, 12 Aug 2003 10:11:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mZqg-0008tM-Pr for v6ops-data@psg.com; Tue, 12 Aug 2003 14:10:06 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19mZqd-0008sG-Np for v6ops@ops.ietf.org; Tue, 12 Aug 2003 14:10:03 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19mZqd-000GEK-Cj for v6ops@ops.ietf.org; Tue, 12 Aug 2003 07:10:03 -0700 Message-ID: <3F38E180.9000708@nomadiclab.com> MIME-Version: 1.0 References: <748C6D0A58C0F94CA63C198B6674697A01922C60@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C60@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Aug 2003 15:45:52 +0300 From: Pekka Nikander To: Soliman Hesham Cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org, "'Thomas Narten'" Subject: Re: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.tx t 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 Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Soliman Hesham wrote: > => We're definitely concerned with existing deployment > and its evolution (read: incremental approaches). I don't > think this is a very narrow scope at all but we can certainly > add that to the draft. > > IMHO, right now at > > least I remain confused which one your draft refers to. > > (Maybe I just read the draft too quickly.) > > => Hopefully this makes things clearer. We can add text > to that effect. Please do add text, already at the abstract at least. Just to avoid any further confusion. --Pekka Nikander From owner-v6ops@ops.ietf.org Tue Aug 12 11:59: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 LAA19631 for ; Tue, 12 Aug 2003 11:59:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mbTC-000JJY-Ae for v6ops-data@psg.com; Tue, 12 Aug 2003 15:53:58 +0000 Received: from [216.98.102.225] (helo=fridge.docomolabs-usa.com) by psg.com with esmtp (Exim 4.20) id 19mbT9-000JJM-8A for v6ops@ops.ietf.org; Tue, 12 Aug 2003 15:53:55 +0000 Message-ID: <00bf01c360e9$f3c4bff0$9f6015ac@dclkempt40> From: "James Kempf" To: "Soliman Hesham" , "'Pekka Nikander'" , "Tsirtsis George" Cc: , , "Soliman Hesham" , "'Thomas Narten'" References: <748C6D0A58C0F94CA63C198B6674697A01922C5C@ftmail.lab.flarion.com> Subject: Re: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt Date: Tue, 12 Aug 2003 08:54:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Hesham, > => Sure there are other approaches. However, our limiting factor > is existing deployment. We want to deal with existing problems > on the Internet that can be solved gradually. HIP does not do > that now because a) it does not exist in standards or products, > b) clearly not deployed, c) it has difficult problems that > have not begun to be addressed (e.g. hierarchical name space ...etc). > At this moment in time it is an idea that was prototyped and > we all know the time it takes from conception to deployment. > Look at v6 which was introduced for a much more tangible problem > than the problems HIP is intended to solve, yet, 10 years later, > deployment is still in its infancy (on a global level). So we need > to realise these issues (in fact they are _the_ issues to > think about) and not only look at the technical challenges. I believe the intent of surfacing HIP is not to produce a Proposed Standard but rather to do a set of Experimental drafts that would serve as a basis for further work, somewhat similar to mipshop and the FMIPv4 work. That work would presumably involve the operational issues you talk about [1], in addition to technical issues. jak [1] Note that these issues also apply to MIPv6. I don't know of anybody today offering commercial MIPv6 service, and when somebody does, we will probably see the same kind of operational issues arise in the MIPv6 WG that are currently being dealt with by the MIPv4 WG. From owner-v6ops@ops.ietf.org Tue Aug 12 14:49: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 OAA24554 for ; Tue, 12 Aug 2003 14:49:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19meBW-000CtX-Vr for v6ops-data@psg.com; Tue, 12 Aug 2003 18:47:54 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19meAW-000ClV-Sx for v6ops@ops.ietf.org; Tue, 12 Aug 2003 18:46:52 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.20) id 19me4a-0006Lv-Ia for v6ops@ops.ietf.org; Tue, 12 Aug 2003 11:40:44 -0700 Message-ID: <3F391931.3080902@iprg.nokia.com> MIME-Version: 1.0 References: <748C6D0A58C0F94CA63C198B6674697A01922C5C@ftmail.lab.flarion.com> <00bf01c360e9$f3c4bff0$9f6015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 12 Aug 2003 09:43:29 -0700 From: Charlie P To: James Kempf CC: mobile-ip@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: Re: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt X-Spam-Status: No, hits=-16.1 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,REFERENCES version=2.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 [ 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. ] Hello Jim, I do not doubt that Mobile IPv6 will face certain operational issues. In fact, some have already been mentioned in the context of GGSN operation. But ... James Kempf wrote: >[1] Note that these issues also apply to MIPv6. I don't know of anybody >today offering commercial MIPv6 service, and when somebody does, we will >probably see the same kind of operational issues arise in the MIPv6 WG that are currently being dealt with by the MIPv4 WG. > ... this isn't guaranteed. I would hope that some of the basic features of IPv6, and the "improved" security features of Mobile IPv6 might go a long way towards avoiding some of the difficulties of NAT traversal, and might be a major improvement over the (eek!) tri-tunnel VPN suggestion. It's at least a hope. Regards, Charlie P. From owner-v6ops@ops.ietf.org Tue Aug 12 19:17:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03577 for ; Tue, 12 Aug 2003 19:17:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19miMt-000Mcp-UV for v6ops-data@psg.com; Tue, 12 Aug 2003 23:15:55 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19miMr-000McY-Cs for v6ops@ops.ietf.org; Tue, 12 Aug 2003 23:15:53 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 12 Aug 2003 19:15:51 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFFAB@ftmail.lab.flarion.com> From: Tsirtsis George To: "'Charlie P'" , James Kempf Cc: mobile-ip@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: RE: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.tx t Date: Tue, 12 Aug 2003 19:15:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-Spam-Status: No, hits=-15.9 required=5.0 tests=BAYES_20,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 It will most certainly do. Dual Stack is still the best way to move to IPv6 for a mobile or any end device. Mobile IPv6 today does not allow the end node to manage an IPv4 HoA together with its IPv6 HoA and thus will have the same issues. As Hesham said we are almost ready to publish the MIPv4 extensions draft but we are also working on appropriate MIPv6 extensions. HIP ways of doing this...no pan intended :-) can be investigated separately...so as per the discussion between Pekka N. and Hesham we will also update the problem statement to reflect that. Stay tuned. George -----Original Message----- From: Charlie P [mailto:charliep@iprg.nokia.com] Sent: Tuesday, August 12, 2003 5:43 PM To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com; v6ops@ops.ietf.org Subject: Re: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.txt Hello Jim, I do not doubt that Mobile IPv6 will face certain operational issues. In fact, some have already been mentioned in the context of GGSN operation. But ... James Kempf wrote: >[1] Note that these issues also apply to MIPv6. I don't know of anybody >today offering commercial MIPv6 service, and when somebody does, we >will probably see the same kind of operational issues arise in the >MIPv6 WG that are currently being dealt with by the MIPv4 WG. > ... this isn't guaranteed. I would hope that some of the basic features of IPv6, and the "improved" security features of Mobile IPv6 might go a long way towards avoiding some of the difficulties of NAT traversal, and might be a major improvement over the (eek!) tri-tunnel VPN suggestion. It's at least a hope. Regards, Charlie P. From owner-v6ops@ops.ietf.org Tue Aug 12 21:59: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 VAA06640 for ; Tue, 12 Aug 2003 21:59:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mkso-0006PS-IH for v6ops-data@psg.com; Wed, 13 Aug 2003 01:57:02 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19mksm-0006PB-6t for v6ops@ops.ietf.org; Wed, 13 Aug 2003 01:57:00 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 12 Aug 2003 21:56:58 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C67@ftmail.lab.flarion.com> From: Soliman Hesham To: "'James Kempf'" , Soliman Hesham , "'Pekka Nikander'" , Tsirtsis George Cc: mobile-ip@sunroof.eng.sun.com, v6ops@ops.ietf.org, Soliman Hesham , "'Thomas Narten'" Subject: RE: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-dsmip-problem-00.tx t Date: Tue, 12 Aug 2003 21:56:55 -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 > > => Sure there are other approaches. However, our limiting factor > > is existing deployment. We want to deal with existing problems > > on the Internet that can be solved gradually. HIP does not do > > that now because a) it does not exist in standards or products, > > b) clearly not deployed, c) it has difficult problems that > > have not begun to be addressed (e.g. hierarchical name > space ...etc). > > At this moment in time it is an idea that was prototyped and > > we all know the time it takes from conception to deployment. > > Look at v6 which was introduced for a much more tangible problem > > than the problems HIP is intended to solve, yet, 10 years later, > > deployment is still in its infancy (on a global level). So we need > > to realise these issues (in fact they are _the_ issues to > > think about) and not only look at the technical challenges. > > I believe the intent of surfacing HIP is not to produce a > Proposed Standard > but rather to do a set of Experimental drafts that would > serve as a basis > for further work, somewhat similar to mipshop and the FMIPv4 > work. That work > would presumably involve the operational issues you talk > about [1], in > addition to technical issues. => Ok, good to know. But HIP (whatever it becomes) is not useful for us or any deployment right now because this is a transition problem from existing MIPv4 deployment. > [1] Note that these issues also apply to MIPv6. I don't know > of anybody > today offering commercial MIPv6 service, and when somebody > does, we will > probably see the same kind of operational issues arise in > the MIPv6 WG that > are currently being dealt with by the MIPv4 WG. => I'm sure there will be. The issues I mentioned above about HIP are not operational, they are fundamental and non-trivial technical issues. But I don't want to discuss it here because it's off topic for this draft. Hesham > From owner-v6ops@ops.ietf.org Wed Aug 13 01:27: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 BAA12700 for ; Wed, 13 Aug 2003 01:27:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mo8j-000GL8-TR for v6ops-data@psg.com; Wed, 13 Aug 2003 05:25:41 +0000 Received: from [2002:425c:4242:0:250:daff:fe82:1c39] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.20) id 19mo8d-000GIw-LW for v6ops@ops.ietf.org; Wed, 13 Aug 2003 05:25:36 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 35CE718DB; Wed, 13 Aug 2003 01:25:25 -0400 (EDT) Date: Wed, 13 Aug 2003 01:25:25 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: "IPv6 transition security" problem statement from a workshop that never happened User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Wed_Aug_13_01:25:25_2003-1" Message-Id: <20030813052525.35CE718DB@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.1 required=5.0 tests=BAYES_20,USER_AGENT version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Multipart_Wed_Aug_13_01:25:25_2003-1 Content-Type: text/plain; charset=US-ASCII As promised in Vienna, here's the draft problem statement that I wrote for the IAB workshop on "IPv6 Transition Security" that never happened. I'm sending this to the WG in the hopes that it will be useful. If you think it's a waste of time, well, feel free to ignore it, or print it out and throw darts at it, or whatever amuses you. Credit for any of this that's useful goes to a long list of people, including but not limited to the folks who chaired this WG or were on the IAB or IESG when I was writing this text late last year. If something in this is wrong or offends you, blame me, not them. See the minutes from IETF57 for background on the origin of this text. In brief: late last year we started trying to pull together a workshop on these topics, but it never quite jelled, in part because upon examination some of these topics didn't seem particularly well suited to the IAB workshop format. --Multipart_Wed_Aug_13_01:25:25_2003-1 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="problem-statement.txt" Content-Transfer-Encoding: 7bit $Id: problem-statement.txt,v 1.8 2003/07/23 20:12:12 sra Exp $ Proposed Workshop on IPv6 Transition Security Now that we have started deploying IPv6 "for real", there are a number of pesky little (or perhaps not so little) issues that we need to examine. Preliminary discussion has lumped these under the general heading of "IPv6 transition security". This note is an attempt to state what we mean by this phrase. Basic premise: transition is going to take a -long- time, on the order of a decade, maybe longer. During this decade or more of transition we're going to be living in a dual protocol Internet, with parts of the network running IPv4, parts running dual stack, parts either running IPv6 only or wishing that they could, and parts that are running only IPv6 wishing that they could still run IPv4 as well in order to use old software or protocols that didn't make it through the transition. The transition solutions that we deploy will be part of the operational network, will be attacked (like everything else) and will have to operate and scale well (like everything else). Most of the issues we're talking about here are not really problems with IPv6 per se, and many of them are not even issues with specific transition solutions. Rather, a number of them fall into the general category of possible unexpected interactions between the IPv4 and IPv6 worlds, or between the transition solutions we've developed and other seemingly unrelated parts of the network or of the protocol suite. Some general issues: - A number of proposed transition mechanism use some form of IP-in-IP tunneling. Tunneling makes the network topology more complex, which can have serious implications for topologically-based security mechanisms (including, but not limited to, the specific kind of packet filtering known as "ingress filtering"). Tunneling issues go way beyond the IPv6 transition scope per se (we have examples of these same problems in the IPv4-only world), but tunneling as used in IPv6 transition schemes require special attention for two reasons: a) These transition solutions propose heavy operational reliance on tunneling for the next decade; and b) In the general Internet it's quite common not to know the party or service with which one wishes to connect. So in the IPv6 transition cases, tunneling is much more likely to occur between parties who are total strangers and thus have no pre-established trust relationship than is usually the case in IPv4 tunneling (ignoring the MBONE, which arguably is a special case). Thus, a number of trust relationship issues arise that we need to examine very carefully. None of the above is intended to pass judgment on whether tunneling mechanisms are good or bad. The point here is just that we don't understand all of the risks in detail yet (and have not had our noses rubbed in them to the same extent that we have with the alternative class of translation-based transition mechanisms). - A number of transition mechanisms define ways of constructing IPv6 addresses using IPv4 addresses. There are a number of kinds of IPv4 addresses that require careful treatment due to known security issues. This implies that these transition mechanisms in effect mean that we have to think about all the possible issues arising from the cross product of { every known perverse form of IPv4 address } X { every form of IPv6 address that's built using IPv4 addresses } For example: what bad things might an IPv6 node do with a packet containing an address such as 2002:0a03:002c::7f00:0002? Note that this is an -addressing- issue, so even a pure IPv6-only implementation has to worry about all these whacky addresses. Another sub-issue here is interactions between different mechanisms that use the same whacky address in different whacky ways. For example, see the issues that Itojun raised regarding mapped addresses meaning one thing on the wire and another thing altogether in the sockets API. In effect these interactions can turn into another kind of topological defense issue. - There are some obvious interactions between some kinds of transition mechanisms (for example, translation-based mechanisms) and various cryptographic security mechanisms (IPsec, DNSSEC, ...). There may be other interactions that are not so obvious, and some of the obvious interactions may include questionable assumptions (see, for example, the debate about whether the interaction between DNSSEC and NAT-PT matters for cases in which NAT-PT is being used to support hosts that arguably are never going to use DNSSEC anyway). - We have stated repeatedly that IPsec is a basic mandatory to implement service in IPv6, and there are some transition tools that might benefit from suitable application of the IPsec protocols. There is, however, still some question about how deployable IPsec is due to key management issues. Transition related applications of the IPsec protocols may escalate the priority of examining these operational issues to see what, if anything, we can do about them. - Moving to a mixed IPv4/IPv6 world increases the number of possible interactions between protocols and the security mechanisms that we have designed to protect them. This is not the fault of IPv6 (or of IPv4 for that matter), it is an unavoidable complexity problem that we need to examine, particularly given that, of the two major families of transition mechanisms that we have, one uses translation (which is known to be hostile to many security mechanisms) and the other uses tunneling (which may produce topologies that violate assumptions that application protocol designers or implementors have chosen to make). - The intense focus on DNS issues in thinking about IPv6 transition issues in the last year or so is arguably grounds for concern, because DNS is in most respects not that different from most of the other protocols that build on top of the basic network and transport layers. The concern here is that many of the DNS-related issues may just be the nose of the camel, and that we're focused on DNS just because it's usually the first of these protocols that any application has to deal with. So in addition to solving whatever DNS problems may exist, we also need to ask ourselves the question "assuming that all the DNS issues were solved, what breaks next?" - Some transition tools attempt to piggyback tasks that arguably ought to be done on the IPv6 network onto existing IPv4 mechanisms. This is most obvious in the area of routing, where some transition solutions use IPv4 anycast (ie, the IPv4 routing infrastructure) to build what is in effect a single gigantic virtual link layer network over which IPv6 can run. Unsurprisingly, such gigantic link layer networks have some of the same problems that have haunted other large link layer networks (for example, the difficulty of applying ingress control and other forms of fault isolation). The "obvious" solution is to break up the gigantic link layer networks using routers at the IPv6 layer, but doing so may create other problems that defeat the purpose of the transition mechanism. We need to examine such cases carefully and determine the best (or least bad) ways of dealing with these issues. - Some transition tools produce overlay network topologies in which the control plane is not congruent with the data plane. While separation of the control and data planes can be useful in certain environments, in general such separation is robust only when the separated control and data planes are congruent and coordinated to work towards a shared goal. The overlay networks produced by some transition tools do not satisfy this prerequisite condition, and the lack of coordination between control and data planes can result in the different layers working at odds with each other. For example, updating an IPv6 routing table to avoid a known link fault may not have the desired effect when the IPv6 network is overlaid on top of an IPv4 network that is making its own routing decisions, or when the overlay mechanism forces the IPv4 network to send all traffic through a particular intermediary device in the middle of the network. So it would be good to understand what kinds of weaknesses our transition solutions have: - Individually: for example, for each of the long list of mechanisms that have come out of the NGTRANS WG over the years and mostly been ignored by the rest of the IETF, let alone the rest of the world: have we looked hard enough at the security considerations[*], and under what circumstances is this protocol safe to use? - In groups: for example, are there generic issues that apply to all tunneling protocols, and generic recommendations we can make about how to use tunneling protocols safely? - In various forms of interplay with the IPv4 network: for example, how serious is the threat of using one or more of the transition schemes that defines "relay routers" as a launching point for IPv4 DDoS attacks, and will the threat of such attacks provoke responses that render these transition schemes unusable? So the soundbite goal is that we want to avoid the attacks that are avoidable and defend against the attacks that are unavoidable, for however long the transition takes. [*] Please note that folks in the IPv6 WGs are trying very hard to get the security considerations sections in their drafts right, for which they deserve our thanks. But this stuff is complex and is still being ignored by way too much of the IETF, let alone the rest of the world, so they need our help. --Multipart_Wed_Aug_13_01:25:25_2003-1-- From owner-v6ops@ops.ietf.org Wed Aug 13 01:55: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 BAA13412 for ; Wed, 13 Aug 2003 01:55:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19moaf-000I98-HT for v6ops-data@psg.com; Wed, 13 Aug 2003 05:54:33 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19moaa-000I8C-KG for v6ops@ops.ietf.org; Wed, 13 Aug 2003 05:54:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7D5sKg06518; Wed, 13 Aug 2003 08:54:20 +0300 Date: Wed, 13 Aug 2003 08:54:20 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C58@ftmail.lab.flarion.com> 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 Sat, 9 Aug 2003, Soliman Hesham wrote: > > > => Why not? Let's take a simple example: > > > A dual stack node that wants to be reachable on IPv4 > > > and IPv6 addresses. It gets one v4 and one v6 home > > > address. If it uses both MIP versions, every time > > > it moves it will send two separate messages to its > > > HA. Even worse, if we try to get a decent handover performance > > > then another two messages will need to be sent to > > > routers in the local network. > > > > You gave a description of a case where there seems to be unnecessary > > signalling that one could try to optimize away (using some means). My > ^^^^^^^^^^^^^^^^^^ > > feeling is that there are workarounds (operational ones, i.e. no > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > extensions for mobility management protocols) for this non-optimized > > signalling problem so the actual problem does not seem particularly > > attractive. > > => if you can solve this problem operationally please elaborate. > It will be enlightning for me to see how. I.e. please elaborate on > the underlined points above. Otherwise, I woulodn't be able to > follow your conclusion. See below ("just run MIPv6 over MIPv4?"). > > > => We're not trying to get the full advantage of each > > > one, this is a transition mechanism. Just like any > > > tunnelling mechanism will make you lose some of IPv6's > > > feature. This mechanism is not a goal, it's a mean to short > > > term deployment for mobile nodes. > > > > Transition to *WHAT*? IPv6-only mobility management and > > IPv6 being run on > > every subnet where a mobile node might roam to? I suspect both; the > > latter could take a very long while.. > > => Of course it will take time. Wouldn't it be beneficial if we could avoid Yet Another Endless Transition? :-) > > Wouldn't then it be just so much simpler to require the > > IPv6-capable node > > to always use IPv6? > > => Huh? How does this help with the problem we're trying to > solve? It's not about "using v6", it's about using it > while you're moving. There seem to be two issues here, enabling IPv6 access and enabling smooth roaming with IPv4/IPv6 mobile-Ip environment. See below for more. > > > > Already happens if you enable e.g. 6to4 to gain IPv6 > > > > connectivity. If you > > > > had IPv6 connectivity in the past, but move somewhere where > > > > there is none, > > > > I think surviving the connections is not your biggest worry. > > > > > > => What is your biggest worry then? > > > > When IPv6-capable node uses IPv6 but moves to a subnet where > > IPv6 is not > > supported, and IPv6 services are required for some purpose, > > it's first and > > primary problem is re-establishing IPv6 support in that > > subnet, in any > > means necessary. > > => I'm really confused. This is the problem we are trying to > solve! I thought you said it's not the biggest worry. How can > you get IPv6 services when you don't have an IPv6 address and you're > mobile...? What I basically said was, "if you don't even have IPv6 connectivity, IPv6 session survivability is not your biggest worry". We agree that enabling v6 is the most important thing to do first. But I guess the question is, "how?". As I understood your description, you wanted to use MIPv6 signalling to set up an IPv6-in-IPv4 tunnel to enable that IPv6 connectivity. My view is that you can enable the same using e.g. 6to4 or some other mechanisms, _independent_ of any mobility management. Now, assume that one is using MIPv_4_ to enable mobility management for IPv4. If 6to4 or such is used on top of that mobility-managed IP address, we don't actually have to do anything MIPv6-wise when we move, as the IPv4 address stays the same. Then we've reduced the problem back to plain old regular MIPv6. :-) > > In transition, it's good to try to figure out questions like: > > - transition to _where_, > > - transition _how_, and > > => Agreed. > > > - transition for _how long_? > > => Not sure why this question is relevant. I think trying to > answer this is an exercise in futility. At least we never > had an answer for it so far. Why is this needed? Because we're trying to think what's the right thing to do (also in the longer term), not just what works (or could be made to work :-). That's one reason why e.g. IAB has required UNSAF considerations sections (including e.g. the sunset strategy) in NAT traversal mechanism proposals. I.e., if a hack has a very limited applicability and lifetime, it might be much easier to accept it; if it's open-ended, the requirements are likely much stricter because we have to consider it in the context of "ok, if we'll specify this, we'll have to live with it for a long time..". -- 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 Aug 13 02:23: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 CAA02933 for ; Wed, 13 Aug 2003 02:23:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mp1Z-000JTn-RR for v6ops-data@psg.com; Wed, 13 Aug 2003 06:22:21 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19mp1W-000JTa-RA for v6ops@ops.ietf.org; Wed, 13 Aug 2003 06:22:18 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19mp1W-000Esd-85 for v6ops@ops.ietf.org; Tue, 12 Aug 2003 23:22:18 -0700 Approved: cia In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B04285214@tayexc13.americas.cpqcorp.net> Message-ID: <20030812154211.P80443-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 12 Aug 2003 16:18:59 -0400 (EDT) From: "Alan E. Beard" To: "Bound, Jim" cc: "Alan E. Beard" , Subject: RE: Concerning draft-pouffary-v6ops-ent-v6net-04 X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, 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. ] Jim: First, my apologies for a grossly delayed reply; since IETF 57 I have been traveling continuously, and away from email. I'll try to answer your queries below, although I know this response is very tardy indeed. AEB On Fri, 18 Jul 2003, Bound, Jim wrote: > Hi Alan, > [...] > Two quesitons to you and the working group. > > 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? > Pekka was kind enough to let me know, gently and courteously, that I had somewhat misapprehended the target audience for the draft I reviewed: that draft was intended for the guidance of the IETF ipv6 Enterprise Network Engineering Team rather than, as I had imagined, for the Network Engineering Teams of commercial or public enterprises. Now disabused of my error, it seems to me that the audience for which this draft was intended, because they are not in a user environment, would have little need or use for text which explains why an end user should care about any of the issues. However, it does seem a shame to fail to make available to end user administrative managers and end user network engineers information which could be of significant assistance in planning a migration to IPv6, particularly since the work done so far on the draft is sound in structure and content. If the completed work is to be made more generally available (that is, beyond the IPv6 Enterprise Network Engineering Team), then "why we should care" language is probably warranted and desirable. > 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. > The draft now contains information which would be of value to managers, network admins, and network engineers in commmercial or educational environments. In practice, documents originating from the IETF are most likely to be noticed by network engineers, or perhaps by more astute network admins. However, administrative managers, who are largely responsible for strategic policy decisions, are likely to ignore or discount such documents as applicable only to technical staff unless the document specifically announces that administrative managers are among the intended audience. This issue is relate to the response above: if we intend the final document to see wide distribution in end-user environments, we should probably specify a wider target audience (including administrative managers) lest the document fail to reach the persons who might most benefit from its counsel. If however, the final document is intended as internal to the IETF only, we need make no such enumeration of target audience. > thanks > /jim > The above are my opinions based on observation of the decision-making processes which frequently exist in commercial environments. However, I am far from authoritative on these issues. And I _did_ misapprehend the target audience for the draft. :-/ What think the rest of the group? Regards, AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 From owner-v6ops@ops.ietf.org Wed Aug 13 03:15: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 DAA11042 for ; Wed, 13 Aug 2003 03:15:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mppc-000LsK-Ue for v6ops-data@psg.com; Wed, 13 Aug 2003 07:14:04 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19mppZ-000Ls7-Km for v6ops@ops.ietf.org; Wed, 13 Aug 2003 07:14:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7D7DwT07326; Wed, 13 Aug 2003 10:13:58 +0300 Date: Wed, 13 Aug 2003 10:13:58 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com, , Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents 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 Hello all, Thanks to those who have sent feedback (both on and off-list). However, a couple of people reading through them is not enough. PLEASE review the documents ASAP and provide feedback. We NEED stronger support and acknowledgement from the WG that these have actually been read! On Tue, 22 Jul 2003, Pekka Savola wrote: > 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 > > -- 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 Aug 13 05:34: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 FAA13630 for ; Wed, 13 Aug 2003 05:34:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mrzK-00030e-0N for v6ops-data@psg.com; Wed, 13 Aug 2003 09:32:14 +0000 Received: from [147.11.1.11] (helo=mail.wrs.com) by psg.com with esmtp (Exim 4.20) id 19mrzH-00030E-MN for v6ops@ops.ietf.org; Wed, 13 Aug 2003 09:32:11 +0000 Received: from ala-mrwtemp.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA16919 for ; Wed, 13 Aug 2003 02:32:01 -0700 (PDT) Message-Id: <5.1.0.14.2.20030813053039.058b0218@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 13 Aug 2003 05:30:48 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: On Vacation: 16-Aug through 1-Sep Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Just FYI -- I will be on vacation for the next two weeks, from Saturday, August 16th through Monday, September 1st. I will be reading mail occasionally during my vacation, to deal with critical issues. However, I probably won't keep up-to-date on the WG mailing list. Margaret From owner-v6ops@ops.ietf.org Wed Aug 13 13:42: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 NAA27358 for ; Wed, 13 Aug 2003 13:42:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19mzar-000501-0Y for v6ops-data@psg.com; Wed, 13 Aug 2003 17:39:29 +0000 Received: from [209.208.32.195] (helo=cerberus.aebeard.com) by psg.com with esmtp (Exim 4.20) id 19mzam-0004zX-4c for v6ops@ops.ietf.org; Wed, 13 Aug 2003 17:39:24 +0000 Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h7DHdL9c009349 for ; Wed, 13 Aug 2003 13:39:21 -0400 (EDT) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h7DHdKNx082128 for ; Wed, 13 Aug 2003 13:39:20 -0400 (EDT) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h7DHdK0O082125 for ; Wed, 13 Aug 2003 13:39:20 -0400 (EDT) Date: Wed, 13 Aug 2003 13:39:20 -0400 (EDT) From: "Alan E. Beard" To: IETF IPv6 operations WG Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: <20030813131026.D80443-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Folks: Hereinafter a few comments on 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 per Pekka's request below. I'll review the other documents queued for last call within a few days. AEB On Wed, 13 Aug 2003, Pekka Savola wrote: > Hello all, > > Thanks to those who have sent feedback (both on and off-list). > > However, a couple of people reading through them is not enough. > > PLEASE review the documents ASAP and provide feedback. We NEED stronger > support and acknowledgement from the WG that these have actually been > read! > The comments below pertain to section 1.1 of -ipv4survey-intro-01. Further comments on this document, mostly concerning section 4, will follow. Most of the comments are changes in text for enhanced readability and for clarification of ambiguous terms. Changes which do not effect substantial modification in the meaning of the original (as interpreted by this reader) are interpolated into the body of the text, with original wording shown in brackets immediately following the replacement text. In a few cases suggesting for alternative wording are given which may alter the substantive meaning of the original: these changes are given in brackets immediately following the paragraph in which the original text appears, along with some explanation of the reasoning which prompted the suggested changes. I will be interested to learn the reactions of the WG participants to the changes suggested below. Comments are welcome; also flames, within reason. ;-) Herewith the suggestions: 1.1 Short Historical Perspective There are many challenges that face the Internet Engineering community. The foremost of these challenges has been the scaling issue: how to grow a network that was envisioned to handle thousands of hosts to one that will handle tens of millions of networks with billions of hosts. Over the years this scaling problem has been overcome with changes to the network layer and to routing protocols. (Although largely ignored in the changes to network layer and routing protocols, the tremendous advances in computational hardware during the past two decades have been of significant benefit in managment of scaling problems encountered thus far.) [Alternative text for sentence 2 of the paragraph above: Over the years this scaling issue has been managed, with varying degrees of success, by changes made to the network layer and to routing protocols. Reasoning: In light of our current discussions, it seems to me that the scaling issue (in actuality, a group of entangled issues) is still with us; we have so far avoided the worst of the postulated adverse effects by changes to routing protocols, network layer conventions, operational techniques described in later paragraphs of the extant draft. Given the nature and extent of current activities which purport to address "the scaling issue", I don't think we have "overcome" the problem; it seems to me that scaling issues will be a fact of life in the IP world for the foreseeable future, although we now have a limited set of tools and techniques for dealing with some of the more pernicious effects, and it is within our capability to develop more such tools.] The first "modern" transition to the network layer occurred in during the early 1980's from the Network Control Protocol (NCP) to IPv4. This culminated in the famous "flag day" of January 1, 1983. IP Version 4 originally specified an 8 bit network and 24 bit host addresses, as documented in RFC 760. A year later IPv4 was updated in RFC 791 to include the famous A, B, C, D, & E class system. [note: much of the above paragraph has been re-written, but, I think, without any substantive change in meaning. AEB] Networks were growing in such a way that it was clear that a convention for [original text: ...a need for...] breaking networks into smaller pieces was needed. In October of 1984 RFC 917 was published formalizing the practice of subnetting. By the late 1980's it was clear that the current exterior routing protocol used by the Internet (EGP) was insufficiently robust to [original: was not sufficient to] scale with the growth of the Internet. The first version of BGP was documented in 1989 in RFC 1105. Yet another scaling issue, exhaustion of the Class B address space, became apparent in the early 1990s. [original text: The next scaling issues to became apparent in the early 1990's was the exhaustion of the Class B address space.] The growth and commercialization of the Internet stimulated organizations to request IP [original text: ...Internet had organizations requesting IP...] addresses in alarming numbers. By May [original text: In May...] of 1992 over 45% of the Class B space was allocated. In early 1993 RFC 1466 was published directing assignment of blocks of Class Cs to be given out in lieu of Class B allocations. [original text: ...Class C's be given out instead of Class B's.] This solved the problem of address space exhaustion but had significant impact of the routing infrastructure. [In the last sentence above, perhaps the word "solved" might be replaced by any of these words or phrases: "palliated" or "temporarily circumvented" or "alleviated" or "delayed the most pernicious effects of". The problem of exhaustion of IPv4 address space is still with us, and is likely to be extant until a substantial proportion of existing IPv4 networks migrate to IPv6 and surrender their v4 allocations. This appears as a suggestion because the wording change also effects a significant alteration in the meaning of the original text: this extends well beyond a mere clarification.] The number of entries in the "core" routing tables began to grow exponentially as a result of RFC 1466. This led to the implementation of BGP4 and CIDR prefix addressing. This may have solved the problem for the present but there are still potential scaling issues. [Again, regarding the last sentence above, perhaps a more accurate reading of the current state of the technology would substitute for the word "solved" any of the following: "alleviated" or "circumvented". This appears as a suggestion because the wording change also effects a significant change in meaning.] Growth in the population of Internet hosts since the mid-1980s would have long overwhelmed the IPv4 address space if industry had not supplied a solution in the form of Network Address Translators (NATs).[original text: Current Internet growth would have long overwhelmed the current address space if industry didn't supply a solution in Network Address Translators (NATs).] To do this the Internet has sacrificed the underlying "End-to-End" principle. [Regarding the first sentence in the paragraph immediately above: some of the IPv6 WG members consider NAT not a solution at all; rather, they proclaim NAT an unmitigatedly BAD THING (emphasis in the original) and, even in the most generous and flattering of all possible interpretations, not better than a crude kludge. Perhaps the word "solution" might be replaced with "circumvention" for a reading more consistent with the common wisdom concerning NAT. Additionally, should we make some mention of PNN address spaces (RFC 1918), without which NAT would probably not have become as widely implemented as it is today? Based on what we see in enterprise implementations, either NAT or PNN alone would probably have been insufficient to relieve, even temporarily, the demand for v4 address space arising from the rapid growth of IP host counts in business and academic environments.] In the early 1990's the IETF was aware of these potential problems and began a long design process to create a successor to IPv4 that would address these issues. The outcome of that process was IPv6. The purpose of this document is not to discuss the merits or problems of IPv6. That is a debate that is still ongoing and will eventually be decided on how well the IETF defines transition mechanisms and how industry accepts the solution. The question is not "should," but "when." ************ Now, what think ye all? Regards, AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 From owner-v6ops@ops.ietf.org Wed Aug 13 22:07: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 WAA14413 for ; Wed, 13 Aug 2003 22:07:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19n7Uo-0008Jb-20 for v6ops-data@psg.com; Thu, 14 Aug 2003 02:05:46 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19n7Ul-0008JJ-6S for v6ops@ops.ietf.org; Thu, 14 Aug 2003 02:05:43 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 13 Aug 2003 22:05:40 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C68@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Soliman Hesham Cc: Tsirtsis George , "'Alain Durand'" , "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: Wed, 13 Aug 2003 22:05:31 -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=-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 I've cut the first parts of the email because I'm hoping that my answer below will address the earlier comments. >> => I'm really confused. This is the problem we are trying to >> solve! I thought you said it's not the biggest worry. How can >> you get IPv6 services when you don't have an IPv6 address and you're >> mobile...? >What I basically said was, "if you don't even have IPv6 connectivity, IPv6 >session survivability is not your biggest worry". => By default, if you have an IPv6 home address then you _do_ have IPv6 connectivity unless you cannot reach the HA. If this happens you lose connectivity and session survivability. >We agree that enabling v6 is the most important thing to do first. >But I guess the question is, "how?". >As I understood your description, you wanted to use MIPv6 signalling to >set up an IPv6-in-IPv4 tunnel to enable that IPv6 connectivity. => This is one of the solutions we're about to publish. You could also use MIPv4 to setup an IPv6 in an IPv4 tunnel. This is another solution that we're publishing. I get the impression that you've made "intelligent guesses" about what solutions we want to do and based on these guesses you have decided that this problem is not worth solving. The reason that we published a problem statement was that we wanted to see whether people agree and understand the problem. Discussing solutions is another step. So do you agree/understand the problem independently of the solution that you think we might propose? >My view is that you can enable the same using e.g. 6to4 or some other >mechanisms, _independent_ of any mobility management. => And my (persistent) question is: how? >Now, assume that one is using MIPv_4_ to enable mobility management for >IPv4. If 6to4 or such is used on top of that mobility-managed IP address, >we don't actually have to do anything MIPv6-wise when we move, as the IPv4 >address stays the same. => Do you mean 6-to-4 in the home network or in the visited network? Obviously we cannot expect anything from the visited network. If 6-to-4 is in the home network what does that buy us? How does the MN receive traffic in the visited network and send in the reverse direction? Of course, as I'm sure you know, 6-to-4 is not intended to be used for end hosts (i.e. a separate v4 address for each host). >Then we've reduced the problem back to plain old regular MIPv6. :-) => I don't understand :( Please elaborate, what does MIPv6 have to do with your proposal? >> > - transition for _how long_? >> >> => Not sure why this question is relevant. I think trying to >> answer this is an exercise in futility. At least we never >> had an answer for it so far. Why is this needed? >Because we're trying to think what's the right thing to do (also in the >longer term), not just what works (or could be made to work :-). => I don't see why : 1. You assume that I'm not thinking the same way 2. You think that such thinking requires us to know how long the transition will take. If we need to do a clean job then we just do it. Assuming that we know when a solution will stop being deployed and making design shortcuts based on that is a really bad idea IMHO. There is no point in figuring out what the future holds. >That's one reason why e.g. IAB has required UNSAF considerations sections >(including e.g. the sunset strategy) in NAT traversal mechanism proposals. => I bet the IAB thought this was a short term solution as well :/. People might have also thought that NATs were a short term solution and that they'll go away when IPv6 is in DS :( >I.e., if a hack has a very limited applicability and lifetime, it might be >much easier to accept it; => Again I don't know who proposed a hack. Also see my comment above about the hack's lifetime. Hesham From owner-v6ops@ops.ietf.org Thu Aug 14 23:30: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 XAA05400 for ; Thu, 14 Aug 2003 23:30:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nVCE-000GNC-2n for v6ops-data@psg.com; Fri, 15 Aug 2003 03:24:10 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19nVCA-000GMv-ND for v6ops@ops.ietf.org; Fri, 15 Aug 2003 03:24:06 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F32529B0D; Thu, 14 Aug 2003 23:24:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 14 Aug 2003 23:24:05 -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: Defintion of Automatic tunnels Date: Thu, 14 Aug 2003 23:24:05 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B049D160A@tayexc13.americas.cpqcorp.net> Thread-Topic: Defintion of Automatic tunnels Thread-Index: AcNaySSZa5l5xbtBRqK1lkcVvx924gIE4jPw From: "Bound, Jim" To: "Randy Bush" Cc: "Brian E Carpenter" , "Erik Nordmark" , "Christian Huitema" , X-OriginalArrivalTime: 15 Aug 2003 03:24:05.0850 (UTC) FILETIME=[AE9F2BA0:01C362DC] 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 no about all 100,000 of them. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com]=20 > Sent: Monday, August 04, 2003 4:37 PM > To: Bound, Jim > Cc: Brian E Carpenter; Erik Nordmark; Christian Huitema;=20 > v6ops@ops.ietf.org > Subject: RE: Defintion of Automatic tunnels >=20 >=20 > > tunnel brokers and 6to4 are the most pervasive used tunnels in=20 > > deployment today across Asia, Europe, and now the U.S. >=20 > all 12 of them >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Aug 14 23:30: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 XAA05416 for ; Thu, 14 Aug 2003 23:30:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nVF5-000GXQ-In for v6ops-data@psg.com; Fri, 15 Aug 2003 03:27:07 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19nVF2-000GXE-Lr for v6ops@ops.ietf.org; Fri, 15 Aug 2003 03:27:04 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 08AC7B7B2; Thu, 14 Aug 2003 23:27:04 -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, 14 Aug 2003 23:27:04 -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: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Date: Thu, 14 Aug 2003 23:27:03 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B049D160B@tayexc13.americas.cpqcorp.net> Thread-Topic: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt Thread-Index: AcNbY+wm5C7gafg9Sqi6fu2Xf2mm4wHeOwBw From: "Bound, Jim" To: "Tsirtsis George" , "Pekka Savola" Cc: "Alain Durand" , , X-OriginalArrivalTime: 15 Aug 2003 03:27:04.0074 (UTC) FILETIME=[18D9FEA0:01C362DD] 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 there is not point of even worrying about Mobile IPv4 it will not be widely deployed and the market will wait for Mobile IPv6 is my view. also the address space limitation of IPv4 will prevent MObile IPv4 and with NAT it simply will not work. /jim > -----Original Message----- > From: Tsirtsis George [mailto:G.Tsirtsis@flarion.com]=20 > Sent: Tuesday, August 05, 2003 11:11 AM > To: 'Pekka Savola' > Cc: 'Alain Durand'; Mobile-Ip=20 > (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org > Subject: RE: [mobile-ip] Re: FW: I-D=20 > ACTION:draft-tsirtsis-dsmip-problem-0 0.txt >=20 >=20 > Inline... >=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Tuesday, August 05, 2003 9:47 AM > To: Tsirtsis George > Cc: 'Alain Durand'; Mobile-Ip=20 > (mobile-ip@sunroof.eng.sun.com); v6ops@ops.ietf.org > Subject: RE: [mobile-ip] Re: FW: I-D=20 > ACTION:draft-tsirtsis-dsmip-problem-0 > 0.txt >=20 > ... >=20 > > We can always complicate things but why not deal with the simple and > > by far most important issue. > >=20 > > Today Mobile IP signals HoA to CoA bindings of the same version > > resulting in either IPv4 over IPv4 encapsulation or IPv6 over IPv6=20 > > encapsulation. > >=20 > > All I am suggesting is that Mobile IP should be able to=20 > signal HoA to > > CoA bindings of different versions so that IPv4 over IPv6=20 > > encapsulation or IPv4 over IPv6 encapsulation is also possible. >=20 > And what benefit, exactly, would the change in encapsulation=20 > have? The=20 > Home Agents and the nodes would still have to support both=20 > versions, you=20 > would just end up with two Mobile IP protocols which (to some extent)=20 > supported both IPv4 and IPv6. >=20 > GT> Running IPv6 over MIPv4 today means that you need to somehow=20 > GT> encapsulate > IPv6 over the existing IPv4 over IPv4 tunnel created by MIPv4=20 > i.e.: double tunnel. With the suggested approach MIPv4 is=20 > itself able to create IPv6 over IPv4 tunnels as well as IPv4=20 > over IPv4 tunnels i.e.: single tunneling. And yes, if we=20 > extend both MIPv4 and MIPv6 with dual stack extensions then=20 > we will have two protocols but a network or a mobile can=20 > choose to utilize only one of the two which will take it long=20 > way towards ubiquitous connectivity. >=20 > Looking briefly at the conclusions section gives me an=20 > impression you want a transport-protocol independent=20 > MobileIP++ that's agnostic of IPv4 or IPv6, with an=20 > understanding that you would not have to solve the problem of=20 > the direct communication between IPv6-only and IPv4-only nodes. >=20 > GT> I am clearly not suggesting transport independency since=20 > I am basing=20 > GT> the > extension on transport dependant MIPv4 and MIPv6. I am merely=20 > suggesting that these transport dependant protocols should be=20 > able to set up version independent tunnels >=20 > It seems like HIP fits the bill quite nicely, and would be=20 > architecturally=20 > better approach than trying to glue MIPv4 and MIPv6 together somehow. >=20 > GT>...with the addition that I view this as an *evolutionary*=20 > approach.=20 > GT>The > extensions I am talking about are suitable for networks that=20 > already utilize or want to utilize MIP (v4 or v6) for=20 > mobility management.=20 >=20 > GT> With respect, HIP has a long way to go before it becomes=20 > real and in=20 > GT> any > case I have never seen how HIP is going to solve the mobility=20 > management problem...if it does fantastic and the market I am=20 > sure will look at this when it becomes available...in the=20 > mean time people are deploying Mobile IP. >=20 > Regards > George >=20 >=20 From owner-v6ops@ops.ietf.org Thu Aug 14 23:35: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 XAA05502 for ; Thu, 14 Aug 2003 23:35:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nVKr-000Go5-4T for v6ops-data@psg.com; Fri, 15 Aug 2003 03:33:05 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19nVKo-000Gns-HN for v6ops@ops.ietf.org; Fri, 15 Aug 2003 03:33:02 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 10AFBB871; Thu, 14 Aug 2003 23:33:02 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 14 Aug 2003 23:33:01 -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 transition security" problem statement from a workshop that never happened Date: Thu, 14 Aug 2003 23:33:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B049D160C@tayexc13.americas.cpqcorp.net> Thread-Topic: "IPv6 transition security" problem statement from a workshop that never happened Thread-Index: AcNhW6FSlX6HZbyBQFS2spkC/4e7QABgfRXg From: "Bound, Jim" To: "Rob Austein" , X-OriginalArrivalTime: 15 Aug 2003 03:33:01.0912 (UTC) FILETIME=[EE23BD80:01C362DD] 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 Rob, These are well understood in the deployment efforts for IPv6 and will be addressed operationally too. Also key management is not a problem for many users with IPsec if they own the network and the PKI within their Intranet or Fully-Owned Internet. Clearly PKI as I roam from U.S. to China is an issue. thanks /jim > -----Original Message----- > From: Rob Austein [mailto:sra+v6ops@hactrn.net]=20 > Sent: Wednesday, August 13, 2003 1:25 AM > To: v6ops@ops.ietf.org > Subject: "IPv6 transition security" problem statement from a=20 > workshop that never happened >=20 >=20 > As promised in Vienna, here's the draft problem statement=20 > that I wrote for the IAB workshop on "IPv6 Transition=20 > Security" that never happened. I'm sending this to the WG in=20 > the hopes that it will be useful. If you think it's a waste=20 > of time, well, feel free to ignore it, or print it out and=20 > throw darts at it, or whatever amuses you. >=20 > Credit for any of this that's useful goes to a long list of=20 > people, including but not limited to the folks who chaired=20 > this WG or were on the IAB or IESG when I was writing this=20 > text late last year. If something in this is wrong or=20 > offends you, blame me, not them. >=20 > See the minutes from IETF57 for background on the origin of=20 > this text. In brief: late last year we started trying to pull=20 > together a workshop on these topics, but it never quite=20 > jelled, in part because upon examination some of these topics=20 > didn't seem particularly well suited to the IAB workshop format. >=20 >=20 From owner-v6ops@ops.ietf.org Thu Aug 14 23:43: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 XAA05572 for ; Thu, 14 Aug 2003 23:43:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nVTH-000HKJ-A3 for v6ops-data@psg.com; Fri, 15 Aug 2003 03:41:47 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19nVTD-000HIg-Eo for v6ops@ops.ietf.org; Fri, 15 Aug 2003 03:41:43 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E5138B9DB; Thu, 14 Aug 2003 23:41:42 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 14 Aug 2003 23:41:42 -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: Defintion of Automatic tunnels Date: Thu, 14 Aug 2003 23:41:42 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047C9F63@tayexc13.americas.cpqcorp.net> Thread-Topic: Defintion of Automatic tunnels Thread-Index: AcNZ6/MMQ0wByc81SJmXgvSwoiRb1AI8jhEA From: "Bound, Jim" To: , X-OriginalArrivalTime: 15 Aug 2003 03:41:42.0631 (UTC) FILETIME=[24832770:01C362DF] 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 roughly speaking for now. The IPv4 PDP context to IM IPv6 systems to IPv4 capable node is encaped at the SGSN in IPv6 and delivered to IM system IPv4 capable node. Either the IPv4 capable node would need to support IPv6 and IPv4 or use Multimedia IM redirect server in IM to decap and send to the IPv4 IM capable node. Security is done at each packet state change during encap and decap and if IPsec or ME-ID is used would remain in tact across the connection for 3GPP. For IP IPsec is used by the IPv4 packet. It avoids the need for NAT and can assume dual stack deployment or until that can happen use one of the redirect servers that will have to exist in the IM deployment system (e.g. SIP, Streaming Media). Don't want to put this in the core at the GGSN and bog it down and I why I say the SGSN. Also HSS (old HLR) can also do AUC (authentication) or locate Tunnel End Point for such an operation as the packet leaves the SGSN. This on GGSN would cause perforance hit me thinks but it could be done there too. /jim > -----Original Message----- > From: Marcin Michalak [mailto:marcin@telscom.ch]=20 > Sent: Sunday, August 03, 2003 1:30 PM > To: v6ops@ops.ietf.org > Subject: RE: Defintion of Automatic tunnels >=20 >=20 > On 3 Aug 2003 at 12:45, Bound, Jim wrote: >=20 > > 100% agree with Christian I strongly suggest to the chairs and ADs=20 > > work on the specs and stop trying to tell vendors how to=20 > build or what=20 > > to provide in products we won't listen to your here simply=20 > because the=20 > > folks here do not do budgets and product decisions per se=20 > it is done=20 > > based on revenue not computer science. > >=20 > > Like Pekka awhile ago saying "just state no one can deploy=20 > IPv6 only=20 > > devices" that is completely absurd no one is going to even=20 > listen to=20 > > such diatribe in the market. > >=20 > > also I have figured out a way to avoid nat in IM for 3GPP=20 > the question=20 > > for me is it even worth sharing that pearl here in the IETF or just=20 > > take it to 3GPP and TEMS vendors. Hint is option I found in pdp=20 > > context packet. > >=20 > > /jim > Hello, > Whatever you decide, please let know the solution? I'd be interested=20 > in getting to know it, probably others as well. > Enjoy the Sunday, or what's left of it, > Marcin > ---------------------------------------------------------- > Marcin Michalak Research Engineer > Mobile: +41 79 330 83 51 Telscom AG =09 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Aug 14 23:58: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 XAA05715 for ; Thu, 14 Aug 2003 23:58:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nVhc-000IO5-RB for v6ops-data@psg.com; Fri, 15 Aug 2003 03:56:36 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19nVha-000INp-Aa for v6ops@ops.ietf.org; Fri, 15 Aug 2003 03:56:34 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19nVhY-0007Pj-FJ; Thu, 14 Aug 2003 20:56:32 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 14 Aug 2003 20:56:31 -0700 To: "Bound, Jim" Cc: "Rob Austein" , Subject: RE: "IPv6 transition security" problem statement from a workshop that never happened References: <9C422444DE99BC46B3AD3C6EAFC9711B049D160C@tayexc13.americas.cpqcorp.net> Message-Id: X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,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 > These are well understood in the deployment efforts for IPv6 great! where will we find them documented? > and will be addressed operationally too. as i am a bit familiar with some actual operational v6 networks, i really look forward to this. > Also key management is not a problem for many users with IPsec if > they own the network and the PKI within their Intranet or > Fully-Owned Internet. this will be a great relief to all those folk going through key management hell with ipsec. jim, we're from engineering, not marketing. and so are you. give us a break. these are non-trivial issues. they need to be actually addressed. they can be. but not by pretending they're already solved. randy From owner-v6ops@ops.ietf.org Fri Aug 15 00:21: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 AAA05945 for ; Fri, 15 Aug 2003 00:21:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nW3b-000Jox-9v for v6ops-data@psg.com; Fri, 15 Aug 2003 04:19:19 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19nW3Y-000Jog-Ar for v6ops@ops.ietf.org; Fri, 15 Aug 2003 04:19:16 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C62A1B9A5; Fri, 15 Aug 2003 00:19:15 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 15 Aug 2003 00:19:16 -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 transition security" problem statement from a workshop that never happened Date: Fri, 15 Aug 2003 00:19:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047C9F64@tayexc13.americas.cpqcorp.net> Thread-Topic: "IPv6 transition security" problem statement from a workshop that never happened Thread-Index: AcNi4TovpS4j2jwmR02sGoffC3HKqAAABiQA From: "Bound, Jim" To: "Randy Bush" Cc: "Rob Austein" , X-OriginalArrivalTime: 15 Aug 2003 04:19:16.0047 (UTC) FILETIME=[63A725F0:01C362E4] 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 > > These are well understood in the deployment efforts for IPv6 >=20 > great! where will we find them documented? You won't its a deployment strategy within a private company and none of your business. Your free to work on the problem to but no one is waiting for your wisdom and briliance in the standards community for what is a deployment problem today. >=20 > > and will be addressed operationally too. >=20 > as i am a bit familiar with some actual operational v6=20 > networks, i really look forward to this. I am too and you won't see it unless you have a cutomer that is deployinug IPv6 in the world you live and I bet when you do or if you do they are not waiting for this list here. My comment to Rob is that these are valid deployment statements and they are being seen by industry too. I would also argue very normal deployment issues for any technology. Not show stoppers though. >=20 > > Also key management is not a problem for many users with=20 > IPsec if they=20 > > own the network and the PKI within their Intranet or Fully-Owned=20 > > Internet. >=20 > this will be a great relief to all those folk going through=20 > key management hell with ipsec. Hey life is tough isn't it. The PKI for the roaming Internet is a problem. But that user is minimal compared to the others. Knowing you I will say I am not saying that does not make the Internet user not an important PKI problem to solve. Just that its not a problem in most industry scenarios where control is maintained for IPv6 deployment. >=20 > jim, we're from engineering, not marketing. and so are you. =20 > give us a break. Now that was nasty OK. Just so you know. Now I will be nasty. I deleted what I wanted to say to you but will recall it maybe next time I see you in person. I deal with reality not abstractions holding up the evolution of the Internet planet that is our disconnect always in the IETF on work and my disconnect with many here. Look I don't care for your view at all nor you for mine, we are opposed on the most basic principles that lead us to our technical assumptions and fixes that is just a fact. The point is if something is being deployed which is all I was saying we cannot wait for the IETF time-to-market issues we all know we have here currently. But in this case deployment would have happened anyway so not the IETF's fault in this case. >=20 > these are non-trivial issues. they need to be actually=20 > addressed. they can be. but not by pretending they're already solved. Never said they should not be addressed or solved in standard manner that was your subjective superiority putting your brain on me. My input was to Rob and this list that we see this in deployment of IPv6 and it has to be addressed now in addition to whatever happens here. I will present representative solutions I have seen work if this becomes a technical operational discussion for sure. You want to be nasty and attack come to my training school your a neophyte I will give you lessons you have never seen. You poke my eye I poke both your eyes. Just remember that if we to continue to be nasty. We can also take it off the list and resolve offline, your call not mine. You want to be professional that is great lets get some work done to adddress this issue, but my view will be to not reinvent the world and hold up progress or the market and that is what an engineers job is as opposed to a computer scientist which I am not. /jim >=20 > randy >=20 >=20 From owner-v6ops@ops.ietf.org Fri Aug 15 00:48: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 AAA06252 for ; Fri, 15 Aug 2003 00:48:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nWTQ-000LTW-D4 for v6ops-data@psg.com; Fri, 15 Aug 2003 04:46:00 +0000 Received: from [209.20.253.166] (helo=ran.psg.com) by psg.com with esmtp (Exim 4.20) id 19nWTO-000LTK-9g for v6ops@ops.ietf.org; Fri, 15 Aug 2003 04:45:58 +0000 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19nWTN-0008jx-Hl; Thu, 14 Aug 2003 21:45:57 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 14 Aug 2003 21:45:57 -0700 To: "Bound, Jim" Cc: v6ops@ops.ietf.org Subject: RE: "IPv6 transition security" problem statement from a workshop that never happened References: <9C422444DE99BC46B3AD3C6EAFC9711B047C9F64@tayexc13.americas.cpqcorp.net> Message-Id: 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 > these are valid deployment statements and they are being seen by > industry too. I would also argue very normal deployment issues > for any technology. Not show stoppers though. ah, then we are not far from agreement, though a bit violently, at least for my taste (but i was brought up by an uncle who was a pacifist in ww2). like too much of our work, the world is far more complex than it used to be. what are "normal deployment" issues today can be a bit more daunting than those of a few years back, e.g., we used not to consider security at all. so what we are trying to do today is being examined using criteria which are more stringent than in previous technology deployments. so i am not as sanguine about how easy it is and will be than you seem to be. but the proof will be in the pudding, eh? so best to go about making the pudding. randy From owner-v6ops@ops.ietf.org Fri Aug 15 07:17: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 HAA24256 for ; Fri, 15 Aug 2003 07:17:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ncW0-000Hgo-Hf for v6ops-data@psg.com; Fri, 15 Aug 2003 11:13:04 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.20) id 19ncVx-000HgT-6W for v6ops@ops.ietf.org; Fri, 15 Aug 2003 11:13:01 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 82EB59AE4; Fri, 15 Aug 2003 07:13:00 -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, 15 Aug 2003 07:13:00 -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 transition security" problem statement from a workshop that never happened Date: Fri, 15 Aug 2003 07:12:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047C9F65@tayexc13.americas.cpqcorp.net> Thread-Topic: "IPv6 transition security" problem statement from a workshop that never happened Thread-Index: AcNi6CZWkeIp8UZtRT6ZOWVqvYJdGAANHxWg From: "Bound, Jim" To: "Randy Bush" Cc: X-OriginalArrivalTime: 15 Aug 2003 11:13:00.0381 (UTC) FILETIME=[301BE8D0:01C3631E] X-Spam-Status: No, hits=-8.9 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RISK_FREE 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 > like too much of our work, the world is far more complex than=20 > it used to be. what are "normal deployment" issues today can=20 > be a bit more daunting than those of a few years back, e.g.,=20 > we used not to consider security at all. so what we are=20 > trying to do today is being examined using criteria which are=20 > more stringent than in previous technology deployments. We do agree here yes. And I have found deployment more intense than Rob's warts but nothing is perfect. The key is to fix the warts in trials, implementations, and pilots so no one gets killed. So objective is to reduce risk and thats what Rob's paper will help all do for sure. But taking no risk at key points for technology deployment or in life I personally believe means you don't evolve at a correct rate to survive. In this case worst case is continuing to live with NAT and loss of e2e principles, and those early Internet precepts are quite important to several customers goals I work with hence today some risk is required to get back to e2e and IPv6 is that path. >=20 > so i am not as sanguine about how easy it is and will be than=20 > you seem to be. but the proof will be in the pudding, eh? =20 > so best to go about making the pudding. All for making the pudding 100%. p.s. complete opposite of pacifist here, genealogy and training all the way back to great great grandpa who was warrior too, but objective of any true warrior that has honor is peace and at that intersection I believe we converge. Its the roads we take to get there where we diverge most likely. /jim From owner-v6ops@ops.ietf.org Fri Aug 15 10:01: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 KAA27511 for ; Fri, 15 Aug 2003 10:01:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19nf5b-0000r4-13 for v6ops-data@psg.com; Fri, 15 Aug 2003 13:57:59 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19nf5V-0000ql-7T for v6ops@ops.ietf.org; Fri, 15 Aug 2003 13:57:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7FDvlC05884; Fri, 15 Aug 2003 16:57:48 +0300 Date: Fri, 15 Aug 2003 16:57:47 +0300 (EEST) From: Pekka Savola To: "Alan E. Beard" cc: IETF IPv6 operations WG Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: <20030813131026.D80443-100000@amneris.aebeard.net> 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, 13 Aug 2003, Alan E. Beard wrote: > per Pekka's request below. I'll review the other documents queued for last > call within a few days. Thanks. > On Wed, 13 Aug 2003, Pekka Savola wrote: > > > Hello all, > > > > Thanks to those who have sent feedback (both on and off-list). > > > > However, a couple of people reading through them is not enough. > > > > PLEASE review the documents ASAP and provide feedback. We NEED stronger > > support and acknowledgement from the WG that these have actually been > > read! > > > > The comments below pertain to section 1.1 of -ipv4survey-intro-01. > Further comments on this document, mostly concerning section 4, will > follow. > > Most of the comments are changes in text for enhanced readability and for > clarification of ambiguous terms. Changes which do not effect substantial > modification in the meaning of the original (as interpreted by this > reader) are interpolated into the body of the text, with original wording > shown in brackets immediately following the replacement text. > > In a few cases suggesting for alternative wording are given which may > alter the substantive meaning of the original: these changes are given in > brackets immediately following the paragraph in which the original text > appears, along with some explanation of the reasoning which prompted the > suggested changes. > > I will be interested to learn the reactions of the WG participants to the > changes suggested below. Comments are welcome; also flames, within > reason. ;-) > > Herewith the suggestions: > > > > 1.1 Short Historical Perspective > > There are many challenges that face the Internet Engineering community. > The foremost of these challenges has been the scaling issue: how to grow a > network that was envisioned to handle thousands of hosts to one that will > handle tens of millions of networks with billions of hosts. Over the > years this scaling problem has been overcome with changes to the network > layer and to routing protocols. (Although largely ignored in the changes > to network layer and routing protocols, the tremendous advances in > computational hardware during the past two decades have been of > significant benefit in managment of scaling problems encountered thus > far.) > > [Alternative text for sentence 2 of the paragraph above: > > Over the years this scaling issue has been managed, with varying degrees > of success, by changes made to the network layer and to routing protocols. > > Reasoning: In light of our current discussions, it seems to me that the > scaling issue (in actuality, a group of entangled issues) is still with > us; we have so far avoided the worst of the postulated adverse effects by > changes to routing protocols, network layer conventions, operational > techniques described in later paragraphs of the extant draft. Given the > nature and extent of current activities which purport to address "the > scaling issue", I don't think we have "overcome" the problem; it seems to > me that scaling issues will be a fact of life in the IP world for the > foreseeable future, although we now have a limited set of tools and > techniques for dealing with some of the more pernicious effects, and it is > within our capability to develop more such tools.] Agreed. > The first "modern" transition to the network layer occurred in during the > early 1980's from the Network Control Protocol (NCP) to IPv4. This > culminated in the famous "flag day" of January 1, 1983. IP Version 4 > originally specified an 8 bit network and 24 bit host addresses, as > documented in RFC 760. A year later IPv4 was updated in RFC 791 to > include the famous A, B, C, D, & E class system. > > [note: much of the above paragraph has been re-written, but, I think, > without any substantive change in meaning. AEB] Agreed. > Networks were growing in such a way that it was clear that a convention > for [original text: ...a need for...] breaking networks into smaller > pieces was needed. In October of 1984 RFC 917 was published formalizing > the practice of subnetting. > > By the late 1980's it was clear that the current exterior routing protocol > used by the Internet (EGP) was insufficiently robust to [original: was not > sufficient to] scale with the growth of the Internet. The first version > of BGP was documented in 1989 in RFC 1105. > > Yet another scaling issue, exhaustion of the Class B address space, became > apparent in the early 1990s. [original text: The next scaling issues to > became apparent in the early 1990's was the exhaustion of the Class B > address space.] The growth and commercialization of the Internet > stimulated organizations to request IP [original text: ...Internet had > organizations requesting IP...] addresses in alarming numbers. By May > [original text: In May...] of 1992 over 45% of the Class B space was > allocated. In early 1993 RFC 1466 was published directing assignment of > blocks of Class Cs to be given out in lieu of Class B allocations. > [original text: ...Class C's be given out instead of Class B's.] This > solved the problem of address space exhaustion but had significant impact > of the routing infrastructure. Agreed. > [In the last sentence above, perhaps the word "solved" might be replaced > by any of these words or phrases: "palliated" or "temporarily > circumvented" or "alleviated" or "delayed the most pernicious effects of". > The problem of exhaustion of IPv4 address space is still with us, and is > likely to be extant until a substantial proportion of existing IPv4 > networks migrate to IPv6 and surrender their v4 allocations. This appears > as a suggestion because the wording change also effects a significant > alteration in the meaning of the original text: this extends well beyond > a mere clarification.] I think "temporarily circumvented" would be both simple enough and to the point. > The number of entries in the "core" routing tables began to grow > exponentially as a result of RFC 1466. This led to the implementation > of BGP4 and CIDR prefix addressing. This may have solved the problem > for the present but there are still potential scaling issues. > > [Again, regarding the last sentence above, perhaps a more accurate reading > of the current state of the technology would substitute for the word > "solved" any of the following: "alleviated" or "circumvented". This > appears as a suggestion because the wording change also effects a > significant change in meaning.] Agree. Solved is fine here, but a stronger wording is also fine, and perhaps better, e.g. alleviated. It's clear that there is a scaling issue here. > Growth in the population of Internet hosts since the mid-1980s would > have long overwhelmed the IPv4 address space if industry had not supplied > a solution in the form of Network Address Translators (NATs).[original > text: Current Internet growth would have long overwhelmed the current > address space if industry didn't supply a solution in Network Address > Translators (NATs).] To do this the Internet has sacrificed the underlying > "End-to-End" principle. Ok. > [Regarding the first sentence in the paragraph immediately above: some of > the IPv6 WG members consider NAT not a solution at all; rather, they > proclaim NAT an unmitigatedly BAD THING (emphasis in the original) and, > even in the most generous and flattering of all possible interpretations, > not better than a crude kludge. Perhaps the word "solution" might be > replaced with "circumvention" for a reading more consistent with the > common wisdom concerning NAT. Additionally, should we make some mention > of PNN address spaces (RFC 1918), without which NAT would probably not > have become as widely implemented as it is today? Based on what we see > in enterprise implementations, either NAT or PNN alone would probably > have been insufficient to relieve, even temporarily, the demand for v4 > address space arising from the rapid growth of IP host counts in business > and academic environments.] I agree that mentioning private address space in conjunction with NAT would seem like the right thing to do. "Solve" might not be optimal here either, but either way is fine with me. > In the early 1990's the IETF was aware of these potential problems and > began a long design process to create a successor to IPv4 that would > address these issues. The outcome of that process was IPv6. > > The purpose of this document is not to discuss the merits or problems of > IPv6. That is a debate that is still ongoing and will eventually be > decided on how well the IETF defines transition mechanisms and how > industry accepts the solution. The question is not "should," but > "when." Ok. > ************ > > Now, what think ye all? Very good suggestions, 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 Sat Aug 16 01:54: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 BAA23732 for ; Sat, 16 Aug 2003 01:54:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ntvM-000Ce8-L6 for v6ops-data@psg.com; Sat, 16 Aug 2003 05:48:24 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19ntvI-000Cdw-QE for v6ops@ops.ietf.org; Sat, 16 Aug 2003 05:48:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7G5mIS12975; Sat, 16 Aug 2003 08:48:19 +0300 Date: Sat, 16 Aug 2003 08:48:18 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: andreas.bergstrom@hiof.no Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents 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, I'd like to poll the WG on one bigger potential change to the Introduction document. Personally I've started to think that section 3.1-3.4, i.e. the details of the results which have been copied all the other survey documents, should be removed from the document. The reason for this would be that keeping these in sync is rather difficult, and people really should look at the area-specific documents if they want the details. But I don't have firm opinions either way. Thoughts on how to proceed with this? On Wed, 13 Aug 2003, Pekka Savola wrote: > On Tue, 22 Jul 2003, Pekka Savola wrote: > > > 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 > > > > > > -- 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 Aug 17 13:48: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 NAA16682 for ; Sun, 17 Aug 2003 13:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19oRZ0-000CUP-Qf for v6ops-data@psg.com; Sun, 17 Aug 2003 17:43:34 +0000 Received: from [209.208.32.195] (helo=cerberus.aebeard.com) by psg.com with esmtp (Exim 4.20) id 19oRYx-000CRH-Fk for v6ops@ops.ietf.org; Sun, 17 Aug 2003 17:43:31 +0000 Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h7HHhM9c020508; Sun, 17 Aug 2003 13:43:23 -0400 (EDT) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h7HHhMNx090967; Sun, 17 Aug 2003 13:43:22 -0400 (EDT) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h7HHhGHl090964; Sun, 17 Aug 2003 13:43:17 -0400 (EDT) Date: Sun, 17 Aug 2003 13:43:16 -0400 (EDT) From: "Alan E. Beard" To: Pekka Savola cc: IETF IPv6 operations WG Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: <20030817133011.W90645-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,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 Pekka: I have reviewed the drafts enumerated below, and I find nothing objectionable in either of them. Additionally, I checked some of the documents explictly referenced (both those listed as clean and those shown with v4 dependencies): in each case, my findings agreed with those in the drafts under review. I did not do a complete canvas, but the results of my spot checks lead me to believe that the authors have probably done a complete and substantially accurate survey. In short, these documents look good to me; I think we can send these two to the IESG without risking embarrasment. ;-) Specific documents reviewed: > On Tue, 22 Jul 2003, Pekka Savola wrote: > > > > > 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: > > [...] > > 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. > > The Intro document, also part of the last call announcement, I reviewed earlier, and some comments have been submitted. Additional comments on section 4 of the Intro document will be forthcoming shortly. Regards, AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 From owner-v6ops@ops.ietf.org Sun Aug 17 14:01: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 OAA16965 for ; Sun, 17 Aug 2003 14:01:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19oRoo-000FD1-FF for v6ops-data@psg.com; Sun, 17 Aug 2003 17:59:54 +0000 Received: from [209.208.32.195] (helo=cerberus.aebeard.com) by psg.com with esmtp (Exim 4.20) id 19oRol-000FBa-PN for v6ops@ops.ietf.org; Sun, 17 Aug 2003 17:59:51 +0000 Received: from amneris.aebeard.net (amneris.aebeard.net [192.168.232.3]) by cerberus.aebeard.com (8.12.6/8.12.6) with ESMTP id h7HHxb9c020521; Sun, 17 Aug 2003 13:59:37 -0400 (EDT) (envelope-from aeb1@amneris.aebeard.net) Received: from amneris.aebeard.net (localhost.aebeard.net [127.0.0.1]) by amneris.aebeard.net (8.12.6/8.12.6) with ESMTP id h7HHxbNx090986; Sun, 17 Aug 2003 13:59:37 -0400 (EDT) (envelope-from aeb1@amneris.aebeard.net) Received: from localhost (aeb1@localhost) by amneris.aebeard.net (8.12.6/8.12.6/Submit) with ESMTP id h7HHxagQ090983; Sun, 17 Aug 2003 13:59:36 -0400 (EDT) Date: Sun, 17 Aug 2003 13:59:36 -0400 (EDT) From: "Alan E. Beard" To: Pekka Savola cc: IETF IPv6 operations WG , Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: <20030817134610.M90645-100000@amneris.aebeard.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Pekka: Responses inline. AEB On Sat, 16 Aug 2003, Pekka Savola wrote: > Hi, > > I'd like to poll the WG on one bigger potential change to the Introduction > document. > > Personally I've started to think that section 3.1-3.4, i.e. the details of > the results which have been copied all the other survey documents, should > be removed from the document. > IMHO the information in section 3 is valuable to the reader, but the information would be equally valuable if incorporated by reference to the source documents rather than by being copied in. This might present logistical problems, but if we defer publication of the intro document until the specific survey documents have been published... > The reason for this would be that keeping these in sync is rather > difficult, and people really should look at the area-specific documents if > they want the details. > Agreed. This is sound logic. And better we hear it straight from the horse's mouth. > But I don't have firm opinions either way. > > Thoughts on how to proceed with this? > See above. It seems not unreasonable that an intro document is published after the survey documents enumerated therein; the contrary order would result in a document of prophecy, rather than an introduction. ;-) That's my $.02 worth. AEB -- Alan E. Beard AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 From owner-v6ops@ops.ietf.org Mon Aug 18 11:55: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 LAA24678 for ; Mon, 18 Aug 2003 11:55:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19omJf-000NtH-RF for v6ops-data@psg.com; Mon, 18 Aug 2003 15:53:07 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19omJd-000Nt3-4t for v6ops@ops.ietf.org; Mon, 18 Aug 2003 15:53:05 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 18 Aug 2003 11:53:04 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFFDD@ftmail.lab.flarion.com> From: Tsirtsis George To: mobile-ip@sunroof.eng.sun.com, "'v6ops@ops.ietf.org'" Subject: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-01.txt Date: Mon, 18 Aug 2003 11:52:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C365A0.C82F1F50" 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_01C365A0.C82F1F50 Content-Type: text/plain We have updated the problem statement to satisfy a few comments we received on the mailing list. The Conclusions section is the only thing that changed and it now recognizes explicitly that the scope of this work is incremental to Mobile IP while there might be other ways of dealing with the general problem, possibly outside Mobile IP...but which are outside the scope of this particular work. Thanks George (and Hesham) -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, August 18, 2003 4:14 PM Subject: I-D ACTION:draft-tsirtsis-dsmip-problem-01.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-01.txt Pages : 5 Date : 2003-8-18 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-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-tsirtsis-dsmip-problem-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-tsirtsis-dsmip-problem-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_000_01C365A0.C82F1F50 Content-Type: message/rfc822 To: Subject: Date: Mon, 18 Aug 2003 11:44:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C365A0.C82F1F50" ------_=_NextPart_002_01C365A0.C82F1F50 Content-Type: text/plain ------_=_NextPart_002_01C365A0.C82F1F50 Content-Type: application/octet-stream; name="ATT06045.txt" Content-Disposition: attachment; filename="ATT06045.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18112733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tsirtsis-dsmip-problem-01.txt ------_=_NextPart_002_01C365A0.C82F1F50 Content-Type: message/external-body; site="internet-drafts"; dir="draft-tsirtsis-dsmip-problem-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C365A0.C82F1F50-- ------_=_NextPart_000_01C365A0.C82F1F50-- From owner-v6ops@ops.ietf.org Mon Aug 18 12:03: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 MAA25041 for ; Mon, 18 Aug 2003 12:03:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19omTq-000Oaq-2q for v6ops-data@psg.com; Mon, 18 Aug 2003 16:03:38 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19omTn-000Oab-GW for v6ops@ops.ietf.org; Mon, 18 Aug 2003 16:03:35 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 18 Aug 2003 12:03:35 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BFFDE@ftmail.lab.flarion.com> From: Tsirtsis George To: "'mobile-ip@sunroof.eng.sun.com'" , "'v6ops@ops.ietf.org'" Cc: "'Pete McCann'" , "'Henrik Levkowetz'" , Soliman Hesham Subject: FW: I-D ACTION:draft-tsirtsis-v4v6-mipv4-00.txt Date: Mon, 18 Aug 2003 12:03:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C365A2.42C91E90" 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 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_01C365A2.42C91E90 Content-Type: text/plain All, Here is a first stub on the Mobile IPv4 changes that we propose so that we deal with most of the issues described in We are also working on the MIPv6 version which we hope to publish soon. I did not copy the MIP4 list to avoid too much cross-posting but I copy the MIP4 chairs (Pete/Henrik) for their consideration. Regards George (and Hesham) -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, August 18, 2003 4:14 PM Subject: I-D ACTION:draft-tsirtsis-v4v6-mipv4-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, H. Soliman Filename : draft-tsirtsis-v4v6-mipv4-00.txt Pages : 17 Date : 2003-8-18 This specification provides IPv6 extensions to the Mobile IPv4 [MIPv4] protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as move between IPv4 and dual stack network infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-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-v4v6-mipv4-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-v4v6-mipv4-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_01C365A2.42C91E90 Content-Type: message/rfc822 To: Subject: Date: Mon, 18 Aug 2003 11:44:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C365A2.42C91E90" ------_=_NextPart_002_01C365A2.42C91E90 Content-Type: text/plain ------_=_NextPart_002_01C365A2.42C91E90 Content-Type: application/octet-stream; name="ATT06041.txt" Content-Disposition: attachment; filename="ATT06041.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-18112636.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tsirtsis-v4v6-mipv4-00.txt ------_=_NextPart_002_01C365A2.42C91E90 Content-Type: message/external-body; site="internet-drafts"; dir="draft-tsirtsis-v4v6-mipv4-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C365A2.42C91E90-- ------_=_NextPart_000_01C365A2.42C91E90-- From owner-v6ops@ops.ietf.org Mon Aug 18 13:39: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 NAA26874 for ; Mon, 18 Aug 2003 13:39:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19onwv-0003FG-Mr for v6ops-data@psg.com; Mon, 18 Aug 2003 17:37:45 +0000 Received: from [158.130.12.194] (helo=lion.seas.upenn.edu) by psg.com with esmtp (Exim 4.20) id 19onwr-0003Eu-K0 for v6ops@ops.ietf.org; Mon, 18 Aug 2003 17:37:41 +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 h7IHbbD4020751 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 18 Aug 2003 13:37:37 -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 h7IHbaOM026352; Mon, 18 Aug 2003 13:37:36 -0400 (EDT) Received: from localhost (rsofia@localhost) by blue.seas.upenn.edu (8.12.9/8.12.9/Submit) with ESMTP id h7IHba5j026349; Mon, 18 Aug 2003 13:37:36 -0400 (EDT) Date: Mon, 18 Aug 2003 13:37:36 -0400 (EDT) From: "Rute C. Sofia" To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: draft-palet-v6ops-proto41-nat-01.txt In-Reply-To: <037301c359ee$df628490$870a0a0a@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 Hi Jordi, comments on the draft: - abstract, 3rd paragraph "this behavior provides a big opportunity...when is not possible to offer native IPv6 or 6to4" *Suggestion: change this paragraph to something such as" this is a fallback option only to be used either when there is no possibility of offering native IPv6, or 6to4 (reference here)" - Introduction * the first 2 paragraphs are a copy of the abstract. My suggestion would be to take them out, and re-write this section...however, I believe that the abstract should contemplate some info presented such as: not only that this is a temporary fallback solution (as stated), but also, that this is only aplicable to the subset of NATs that allow protocol 41. - section 3., NAT types. *This section is a bit confusing; I believe that you are following the nomenclature presented in rfc 2766; Basic is the "Traditional" type, right? Basic is confusing, given that NAPT-PT (I believe that's what you mean in section 3.2) is a form of the traditional NAT-PT; * Also, in 3.2. , you say "...This can also be combined with basic NAT". So I'm lost here. * Isn't 3.4 a subset of 3.3? - Section 4., Applicability *1st paragraph states a problem with NAT, not IPv6+NAT. Now, the paragraph seems to imply that this is due to IPv6 and NAT. * 5th paragraph, "This configuration can be a default one...". Even though you speak of private addresses, this option is a bit limiting, isn't it? *6th,7th paragraph are out of context in this section; should be moved to the intro. - Section 5. * you say that most vendors support proto-41. How many were checked? which percentage support ip proto-41 and how many provided bidirectionality? This would be interesting data to be include. * 3rd paragraph. It is a fact that 6to4 and proto-41 can coexist in the same box. But the question is? Why would they, when you claim that the current solution is simply a "temporary fallback" one, when there is either no 6to4 or native support? This paragraph contradicts the abstract, the intro and the previous one. Rute On Sun, 3 Aug 2003, JORDI PALET MARTINEZ wrote: > Hi all, > > The revision of the document indicated in the subject, has been published a few days ago, as indicated below. > > I will be happy to get new comments from the WG. > > Regards, > Jordi > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Forwarding Protocol 41 in NAT Boxes > Author(s) : J. Palet et al. > Filename : draft-palet-v6ops-proto41-nat-01.txt > Pages : 12 > Date : 2003-7-31 > > Some NAT boxes/routers allow the establishment of IPv6 tunnels from > systems in the private LAN (using private IPv4 addresses) to routers > or tunnel servers in the public Internet. > As far as we know this is not a common way of use IPv6 tunnels; the > usual way is to finish the tunnel directly in a device with an IPv4 > public address. > This behavior provides a big opportunity to rapidly deploy a huge > number of IPv6 nodes and networks, without the need of new transition > mechanism. This option is very important to facilitate the IPv6 > deployment. > This document describes this behavior and provides hints that should > be applied in the NAT boxes and tunnel brokers to facilitate it. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt > > > ***************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on-line at: > http://www.ipv6-es.com > > > From owner-v6ops@ops.ietf.org Tue Aug 19 02: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 CAA28726 for ; Tue, 19 Aug 2003 02:26:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ozsP-000Hq6-6z for v6ops-data@psg.com; Tue, 19 Aug 2003 06:21:53 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19ozsL-000Hpk-7M for v6ops@ops.ietf.org; Tue, 19 Aug 2003 06:21:50 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.20) id 19ozsK-0001fN-5R for v6ops@ops.ietf.org; Tue, 19 Aug 2003 15:21:48 +0900 Message-Id: <200308182246.h7IMkGJ04979@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3574 on Transition Scenarios for 3GPP Networks Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Mon, 18 Aug 2003 15:46:16 -0700 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 Request for Comments is now available in online RFC libraries. RFC 3574 Title: Transition Scenarios for 3GPP Networks Author(s): J. Soininen, Ed. Status: Informational Date: August 2003 Mailbox: jonne.soininen@nokia.com Pages: 12 Characters: 23359 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-3gpp-cases-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3574.txt This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030818154450.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3574 --OtherAccess Content-Type: Message/External-body; name="rfc3574.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030818154450.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Aug 19 02:26: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 CAA28742 for ; Tue, 19 Aug 2003 02:26:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ozsw-000HtK-8q for v6ops-data@psg.com; Tue, 19 Aug 2003 06:22:26 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19ozsu-000Hsx-3z for v6ops@ops.ietf.org; Tue, 19 Aug 2003 06:22:24 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.20) id 19ozst-0001fn-2q for v6ops@ops.ietf.org; Tue, 19 Aug 2003 15:22:23 +0900 Message-Id: <200308182246.h7IMkGJ04979@gamma.isi.edu> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+164775_6302132497479_52091249439" To: IETF-Announce: ; Subject: RFC 3574 on Transition Scenarios for 3GPP Networks Cc: rfc-editor@rfc-editor.org, v6ops@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Mon, 18 Aug 2003 15:46:16 -0700 X-Spam-Status: No, hits=-3.0 required=5.0 tests=BAYES_10,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 --MIMEStream=_0+164775_6302132497479_52091249439 A new Request for Comments is now available in online RFC libraries. RFC 3574 Title: Transition Scenarios for 3GPP Networks Author(s): J. Soininen, Ed. Status: Informational Date: August 2003 Mailbox: jonne.soininen@nokia.com Pages: 12 Characters: 23359 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-3gpp-cases-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3574.txt This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e., General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. This document is a product of the IPv6 Operations Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --MIMEStream=_0+164775_6302132497479_52091249439 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+72230_89417484018306_72056233385" --MIMEStream=_1+72230_89417484018306_72056233385 Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030818154450.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3574 --MIMEStream=_1+72230_89417484018306_72056233385 Content-Type: Message/External-body; name="rfc3574.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030818154450.RFC@RFC-EDITOR.ORG> --MIMEStream=_1+72230_89417484018306_72056233385-- --MIMEStream=_0+164775_6302132497479_52091249439-- From owner-v6ops@ops.ietf.org Tue Aug 19 10:22: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 KAA13541 for ; Tue, 19 Aug 2003 10:22:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19p7LA-000KSa-I4 for v6ops-data@psg.com; Tue, 19 Aug 2003 14:20:04 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.20) id 19p7L5-000KRL-Gs for v6ops@ops.ietf.org; Tue, 19 Aug 2003 14:19:59 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7JEJv412878 for ; Tue, 19 Aug 2003 17:19:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Aug 2003 17:19:57 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 17:19:57 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 19 Aug 2003 17:19:57 +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: 3gpp-analysis: the way forward to revision -05 Date: Tue, 19 Aug 2003 17:19:57 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A3E@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: Editorial issues Thread-Index: AcNPh8ZnjE1Xg7f1SVqgqb6tdPDfAQAPU7AABaUCRdA= From: To: X-OriginalArrivalTime: 19 Aug 2003 14:19:57.0711 (UTC) FILETIME=[F7CFA1F0:01C3665C] X-Spam-Status: No, hits=-2.1 required=5.0 tests=BAYES_20,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 all! I just returned back from holidays and will start working on 3GPP = Analysis document again. Quite many comments have been given on Analysis = doc revision -04 and I try to compose version -05 by next week Tuesday, = August 26th (if not sooner). I want to thank Pekka for his comments. The comment categories are the following: ----------- 1) Editorial issues: updating them is not a major task. [what comes to 2) - 11), I will go the mails through soon and possibly = send some comments on the mailing list] 2) Use of NAT-PT in IPv6 UE -> IPv4 node 3) Necessity for protocol translators in sect. 2.3 4) The use of 6to4 5) DNS guidelines 6) Transition mechanisms at UEs 7) Tunnels out of 3GPP operator's network 8) Need for UE <-> 3GPP Configuration 9) Automatic tunneling inside 3GPP operator's network 10) SIP/SDP transition 11) Security considerations ------------- Did I miss any? Cheers, -Juha- From owner-v6ops@ops.ietf.org Wed Aug 20 13:49: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 NAA24580 for ; Wed, 20 Aug 2003 13:49:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pX1I-000Aqh-Ja for v6ops-data@psg.com; Wed, 20 Aug 2003 17:45:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19pX1D-000Aq4-2L for v6ops@ops.ietf.org; Wed, 20 Aug 2003 17:45:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7KHi7J07346; Wed, 20 Aug 2003 20:44:07 +0300 Date: Wed, 20 Aug 2003 20:44:06 +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: <76E5F712842F5F49A35738622BAA0F4F0376822C@ESEALNT442.al.sw.ericsson.se> 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 Sorry for the delay. Basically I think we disagree on some fundamental issues, and it may be best if we maange to get others to give their thoughts on the subject. On Tue, 12 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > > 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. > > > > > > When I plug into Ethernet or WLAN I don't know if the network > > > supports IPv6 until I get an RA. > > > > Very true, but the expectations are entirely different (or > > that's my take > > at least). When I use my laptop and roam in the world, I generally > > *DON'T* expect IPv6 to be available. Hence, I'm equipped > > with some useful > > tools to enable IPv6 in the case network doesn't support it > > (e.g. 6to4 or > > configured tunnels). > > > > However, I think the expectation with 3GPP is entirely > > different: network > > supports IPv6, period. (And it would be unreasonable to > > assume the huge > > number of 3GPP devices to implement all the possible > > mechanisms required > > in every possible network scenario, be it 3GPP or regular > > old-fashioned > > Internet.) > > To be precise it's 3GPP IMS services that support IPv6. > I hope this will get all operators to support IPv6 for the > obvious reasons such as peer-to-peer connectivity. However > it is a different thing to expect any 3GPP network in general > to support IPv6 from day one. Sure, but is it reasonable to expect that you would be able to use IPv6 in everywhere you move to in the world, and expect IPv6 to work, from day one? It may not be. A possibly valid answer could be, "just use IPv4 then", I don't know. > In fact there are commercial 3GPP operators today (WCDMA and GSM) whose > networks do not support IPv6. Also, all I have been saying is to > recommend support for at least one type of tunnelling in this case. > ISATAP does what is needed IMO, so you don't need to support every > possible mechanism. I do not know the tradeoffs in enough detail to say anything conclusive, but ONE mechanism which: 1) uses your uses an allocated ISP prefix, (i.e. not 6to4 or like) 2) is simple, both specification and code-wise, 3) does not have security problems, 4) has a very clear and definitive sunset strategy, and 5) is ACTUALLY NEEDED, might be a possibility; but I don't want to really consider it because I'm not sure the most important point, 5), has benefited from enough feedback and we actually know that this is the right place and the right way to fix the problem. [note: the list was made ad-hoc, and it probably isn't conclusive] > > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > > > support in > > > > remote SGSN's/GGSN's be avoided ? > > > > > > You could do that, but it would be an overkill IMO to run PPP > > > over wireless. Since we're dealing with an expensive bandwidth > > > limited link it's not an attractive alternative. > > > > I think it would be useful to try to analyze the overhead of > > PPP in this > > scenario. It might not be that high, and it might only be > > the fallback > > solution where other mechanisms (i.e. finding an operator which would > > support IPv6, or refraining from using IPv6) would not work. > > That would be asking for equipment to support IPv4, IPv6 and PPP to > cater for a case which we hope will be rare. The 100% same argument can be applied to including a transition mechanism like ISATAP in an UE. > I would definitely limit > it to IPv4 and IPv6 so that people would have to tunnel for the special > cases and operators would have an incentive to migrate to native IPv6. > PPP will not solve the problem in a clean way and will be a disincentive > to migrate to native IPv6. I fail to see how th euse of PPP would be any less disincentive to migrate to native IPv6, than to use IPv6-over-IPv4 tunneling as a backup. (note, I'm not talking about moving *all* IPv6 communication to over PPP.) [snip a non-technical part of discussion] > > > If you're in this special case (which will hopefully become > > > rare in future) and you want to have a way of using IPv6 services > > > then tunnelling is an attractive solution. > > > > What I'm looking for is a way or two to work around that > > requirement; I > > would loath to see a requirement to implement tunneing > > solutions on mobile > > terminals to make the service work in areas where the 3GPP operator > > doesn't suddenly support IPv6. > > > > I think we should try to ways to leverage 3GPP network's > > capabilities to > > ensure that either: > > > > 1) the user is able to obtain IPv6 PDP context somehow; > > this is an issue > > when roaming to some other operator's network. Whether from > > that operator > > or by trying someone else doesn't matter. > > > > 2) the user is able to work around the issue by requesting PPP PDP > > context until the roaming partner supports IPv6 > > > > 3) the user is able to stick to just using IPv4 when > > roaming in a network > > where there are no ways at all to get IPv6 using any means. > > Number 1) is unworkable as I've explained before. There are also > business issues that will make it useless in many cases (i.e. there is > only one data roaming partner which is common today). Number 2) isn't > workable either. You're not going to convince operators to get support > for PPP (which is normally not there today) only because they need IPv6; > they would get native IPv6 directly. Tunnelling is fine as a migration > tool and we've tested it. It's the only feasible choice and it will lead > to a migration to native IPv6. I think I disagree with this conclusion, but we need more review and feedback on this case. -- 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 Aug 20 14:46: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 OAA29293 for ; Wed, 20 Aug 2003 14:46:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pXxL-000JjE-Oh for v6ops-data@psg.com; Wed, 20 Aug 2003 18:45:15 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19pXxH-000Jio-NO for v6ops@ops.ietf.org; Wed, 20 Aug 2003 18:45:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7KIfdB08161; Wed, 20 Aug 2003 21:41:40 +0300 Date: Wed, 20 Aug 2003 21:41:39 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C68@ftmail.lab.flarion.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 Sorry for the delay in responding, there was a load of work piling, (and I'm not sure it's getting much lower.. :-) On Wed, 13 Aug 2003, Soliman Hesham wrote: > >> => I'm really confused. This is the problem we are trying to > >> solve! I thought you said it's not the biggest worry. How can > >> you get IPv6 services when you don't have an IPv6 address and you're > >> mobile...? > > >What I basically said was, "if you don't even have IPv6 connectivity, IPv6 > >session survivability is not your biggest worry". > > => By default, if you have an IPv6 home address then you _do_ > have IPv6 connectivity unless you cannot reach the HA. If this > happens you lose connectivity and session survivability. True, but you write this the other way than it's normally written, that is: By default, if you have a working IPv6 care-of address, you have IPv6 connectivity. If you can reach the HA, you also have session survivability. By changing the typical assumptions around, you build a case on top of HA-centralized IPv6 connectivity. IPv6 connectivity is independent of the HA. > >We agree that enabling v6 is the most important thing to do first. > > >But I guess the question is, "how?". > > >As I understood your description, you wanted to use MIPv6 signalling to > >set up an IPv6-in-IPv4 tunnel to enable that IPv6 connectivity. > > => This is one of the solutions we're about to publish. > You could also use MIPv4 to setup an IPv6 in an IPv4 tunnel. > This is another solution that we're publishing. > I get the impression that you've made "intelligent guesses" > about what solutions we want to do and based on these guesses > you have decided that this problem is not worth solving. Possibly partially, yes. > The reason that we published a problem statement > was that we wanted to see whether people agree and understand > the problem. Discussing solutions is another step. > > So do you agree/understand the problem independently of the > solution that you think we might propose? Let's see. I think I can see why some people see these issues as problems. However, I can't see why some people see these as really important issues, requiring changes. However, I do not think there is sufficient justification in the document why those are problems _worth_ solving, or how big problems they actually are (even small problems could be used to justify work). For example, how do we evaluate the solutions whether they are justified to solve the perceived problems? I guess I don't understand the problem, then. > >My view is that you can enable the same using e.g. 6to4 or some other > >mechanisms, _independent_ of any mobility management. > > => And my (persistent) question is: how? Please see below, I think I've managed to answer this. > >Now, assume that one is using MIPv_4_ to enable mobility management for > >IPv4. If 6to4 or such is used on top of that mobility-managed IP address, > >we don't actually have to do anything MIPv6-wise when we move, as the IPv4 > >address stays the same. > > => Do you mean 6-to-4 in the home network or in the visited > network? Obviously we cannot expect anything from the visited > network. If 6-to-4 is in the home network what does that buy > us? How does the MN receive traffic in the visited network > and send in the reverse direction? I'm not sure if I understand your question. Assume the node uses MIPv4, and has a configured home IPv4 address HADDR_v4. Why couldn't it just start (e.g.) 6to4 using that address, generating the prefix 2002:HADDR_v4::/48 and use an address from there? Then, when the node moves and executes IPv4 mobility management, the network where HADDR_v4 is routed automatically changes with it -- and 2002:HADDR_v4::/48 stays the same. There is no need to run any IPv6 mobility management protocol at all. The node need not have any _IPv6_ care-of addresses at all. Hey, it's you who want simplicity, not me! :-) Obviously, you could just replace 6to4 and 2002:HADDR_v4 with any (configured) IPv6-over-IPv4 tunneling mechanism whose end-point is HADDR_v4 -- and again it would be "sticky" and you would have to do nothing at all. > Of course, as I'm sure you know, 6-to-4 is not intended > to be used for end hosts (i.e. a separate v4 address for > each host). Nothing prevents that, but that's not the point here. > >Then we've reduced the problem back to plain old regular MIPv6. :-) > > => I don't understand :( Please elaborate, what does MIPv6 have to > do with your proposal? What I'm saying (badly, sorry -- took me while to figure out what I meant :-) that we can reduce the the problem, with above to the case where we have to figure out whether we want to run MIPv6 or not. It may not be necessary, but would be beneficial in some cases. Beneficial where? I guess I can think of one. When native IPv6 is available in the visited networks so you wouldn't have to do the extra IPv4 mobility roundtrip home (which may or may not be a problem) -- but isn't this whole point about networks where MIPv4 is deployed and NOT IPv6? It seems to me that when IPv6 would be deployed in those networks, you could retire MIPv4 -- and problem solved ! :-) > >> > - transition for _how long_? > >> > >> => Not sure why this question is relevant. I think trying to > >> answer this is an exercise in futility. At least we never > >> had an answer for it so far. Why is this needed? > > >Because we're trying to think what's the right thing to do (also in the > >longer term), not just what works (or could be made to work :-). > > => I don't see why : > 1. You assume that I'm not thinking the same way Different people often think differently, especially if there is no dialogue to try to share the views :-) > 2. You think that such thinking requires us to know > how long the transition will take. I think, yes -- a ballpark figure would be quite useful. The worse the hack one is proposing, the bigger the need is to consider ("how long do we have to live with this?"). > If we need to do a clean job then we just do it. Assuming > that we know when a solution will stop being deployed > and making design shortcuts based on that is a really > bad idea IMHO. There is no point in figuring out what > the future holds. I'm not sure what you're referring to, but IMHO we should try to avoid doing EITHER: 1) short-term fixes to solve long-term problems, or 2) long-term fixes to solve short-term problems. 2) is probably even worse (and what I'm fearing here), because if we come across with 1), and the fix proves to be too short-term, we can just try again. This of course has its pitfalls too. -- 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 Aug 20 15:05: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 PAA00349 for ; Wed, 20 Aug 2003 15:05:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pYFc-000MSZ-Us for v6ops-data@psg.com; Wed, 20 Aug 2003 19:04:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19pYFZ-000MRv-Og for v6ops@ops.ietf.org; Wed, 20 Aug 2003 19:04:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7KJ33w08390 for ; Wed, 20 Aug 2003 22:03:03 +0300 Date: Wed, 20 Aug 2003 22:03:02 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis: the way forward to revision -05 In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3A3E@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Writing as co-chair.. Thanks to Juha for taking this list together. For reference, I think we can separate the issues that weren't downright closed (e.g. seem to have been resolved or waiting for some other action) in two. Topics which don't seem to be closed which probably require more attention, in some form or another (possibly cannot be settled by textual updates without further WG feedback etc.): > 2) Use of NAT-PT in IPv6 UE -> IPv4 node > > 6) Transition mechanisms at UEs > > 9) Automatic tunneling inside 3GPP operator's network and those issues which were not discussed at all (or in limited scale); that could of might or might not mean that there are no objections to the comments. > 4) The use of 6to4 > > 7) Tunnels out of 3GPP operator's network > > 8) Need for UE <-> 3GPP Configuration <-- probably rather important?! > > 10) SIP/SDP transition Anything I've missed? Disagreements on the classification? If you have comments on these issues (please do! :-), please send them to the specific threads. -- 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 Aug 20 16:13: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 QAA07562 for ; Wed, 20 Aug 2003 16:13:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pZIt-0004QF-SY for v6ops-data@psg.com; Wed, 20 Aug 2003 20:11:35 +0000 Received: from [206.157.224.254] (helo=hatl0ms21.CORP.COX.COM) by psg.com with esmtp (Exim 4.20) id 19pZIq-0004Pw-AJ for v6ops@ops.ietf.org; Wed, 20 Aug 2003 20:11:32 +0000 Received: from mail pickup service by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC; Wed, 20 Aug 2003 15:52:40 -0400 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Aug 2003 14:04:11 -0400 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7+Sun/8.11.6) with SMTP id h7KI4AU01349 for ; Wed, 20 Aug 2003 14:04:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pX1I-000Aqh-Ja for v6ops-data@psg.com; Wed, 20 Aug 2003 17:45:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19pX1D-000Aq4-2L for v6ops@ops.ietf.org; Wed, 20 Aug 2003 17:45:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7KHi7J07346; Wed, 20 Aug 2003 20:44:07 +0300 Date: Wed, 20 Aug 2003 20:44:06 +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: <76E5F712842F5F49A35738622BAA0F4F0376822C@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 20 Aug 2003 18:04:11.0031 (UTC) FILETIME=[75071A70:01C36745] 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 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Sorry for the delay. Basically I think we disagree on some fundamental issues, and it may be best if we maange to get others to give their thoughts on the subject. On Tue, 12 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > On Thu, 7 Aug 2003, Karim El-Malki (HF/EAB) wrote: > > > > 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. > > > > > > When I plug into Ethernet or WLAN I don't know if the network > > > supports IPv6 until I get an RA. > > > > Very true, but the expectations are entirely different (or > > that's my take > > at least). When I use my laptop and roam in the world, I generally > > *DON'T* expect IPv6 to be available. Hence, I'm equipped > > with some useful > > tools to enable IPv6 in the case network doesn't support it > > (e.g. 6to4 or > > configured tunnels). > > > > However, I think the expectation with 3GPP is entirely > > different: network > > supports IPv6, period. (And it would be unreasonable to > > assume the huge > > number of 3GPP devices to implement all the possible > > mechanisms required > > in every possible network scenario, be it 3GPP or regular > > old-fashioned > > Internet.) > > To be precise it's 3GPP IMS services that support IPv6. > I hope this will get all operators to support IPv6 for the > obvious reasons such as peer-to-peer connectivity. However > it is a different thing to expect any 3GPP network in general > to support IPv6 from day one. Sure, but is it reasonable to expect that you would be able to use IPv6 in everywhere you move to in the world, and expect IPv6 to work, from day one? It may not be. A possibly valid answer could be, "just use IPv4 then", I don't know. > In fact there are commercial 3GPP operators today (WCDMA and GSM) whose > networks do not support IPv6. Also, all I have been saying is to > recommend support for at least one type of tunnelling in this case. > ISATAP does what is needed IMO, so you don't need to support every > possible mechanism. I do not know the tradeoffs in enough detail to say anything conclusive, but ONE mechanism which: 1) uses your uses an allocated ISP prefix, (i.e. not 6to4 or like) 2) is simple, both specification and code-wise, 3) does not have security problems, 4) has a very clear and definitive sunset strategy, and 5) is ACTUALLY NEEDED, might be a possibility; but I don't want to really consider it because I'm not sure the most important point, 5), has benefited from enough feedback and we actually know that this is the right place and the right way to fix the problem. [note: the list was made ad-hoc, and it probably isn't conclusive] > > > > If UE's were to run PPP PDP Contexts, could the lack of IPv6 > > > > support in > > > > remote SGSN's/GGSN's be avoided ? > > > > > > You could do that, but it would be an overkill IMO to run PPP > > > over wireless. Since we're dealing with an expensive bandwidth > > > limited link it's not an attractive alternative. > > > > I think it would be useful to try to analyze the overhead of > > PPP in this > > scenario. It might not be that high, and it might only be > > the fallback > > solution where other mechanisms (i.e. finding an operator which would > > support IPv6, or refraining from using IPv6) would not work. > > That would be asking for equipment to support IPv4, IPv6 and PPP to > cater for a case which we hope will be rare. The 100% same argument can be applied to including a transition mechanism like ISATAP in an UE. > I would definitely limit > it to IPv4 and IPv6 so that people would have to tunnel for the special > cases and operators would have an incentive to migrate to native IPv6. > PPP will not solve the problem in a clean way and will be a disincentive > to migrate to native IPv6. I fail to see how th euse of PPP would be any less disincentive to migrate to native IPv6, than to use IPv6-over-IPv4 tunneling as a backup. (note, I'm not talking about moving *all* IPv6 communication to over PPP.) [snip a non-technical part of discussion] > > > If you're in this special case (which will hopefully become > > > rare in future) and you want to have a way of using IPv6 services > > > then tunnelling is an attractive solution. > > > > What I'm looking for is a way or two to work around that > > requirement; I > > would loath to see a requirement to implement tunneing > > solutions on mobile > > terminals to make the service work in areas where the 3GPP operator > > doesn't suddenly support IPv6. > > > > I think we should try to ways to leverage 3GPP network's > > capabilities to > > ensure that either: > > > > 1) the user is able to obtain IPv6 PDP context somehow; > > this is an issue > > when roaming to some other operator's network. Whether from > > that operator > > or by trying someone else doesn't matter. > > > > 2) the user is able to work around the issue by requesting PPP PDP > > context until the roaming partner supports IPv6 > > > > 3) the user is able to stick to just using IPv4 when > > roaming in a network > > where there are no ways at all to get IPv6 using any means. > > Number 1) is unworkable as I've explained before. There are also > business issues that will make it useless in many cases (i.e. there is > only one data roaming partner which is common today). Number 2) isn't > workable either. You're not going to convince operators to get support > for PPP (which is normally not there today) only because they need IPv6; > they would get native IPv6 directly. Tunnelling is fine as a migration > tool and we've tested it. It's the only feasible choice and it will lead > to a migration to native IPv6. I think I disagree with this conclusion, but we need more review and feedback on this case. -- 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 Aug 20 20:20: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 UAA21283 for ; Wed, 20 Aug 2003 20:20:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pdAA-0006BH-JH for v6ops-data@psg.com; Thu, 21 Aug 2003 00:18:50 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.20) id 19pdA4-0006Ap-EH for v6ops@ops.ietf.org; Thu, 21 Aug 2003 00:18:44 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8ABB891; Thu, 21 Aug 2003 09:18:41 +0900 (JST) To: Pekka Savola , v6ops@ops.ietf.org, bob@thefinks.com, mrw@windriver.com, andreas.bergstrom@hiof.no In-reply-to: itojun's message of Tue, 22 Jul 2003 19:40:48 +0900. <20030722104048.6CF4999@coconut.itojun.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: Re: comment: draft-ietf-v6ops-ipv4survey-intro-01.txt From: itojun@iijlab.net Date: Thu, 21 Aug 2003 09:18:41 +0900 Message-Id: <20030821001841.8ABB891@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 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]. pekka contacted apps people, and confirmed that domain-literal syntax is still there, and RFC2822 defines domain-literal syntax for IPv6, which is itojun@[IPv6:2001:240::1]. therefore 3.1.6 is incorrect. how about just removing the text, or "support for IPv6 in RFC2822 domain-literal syntax (foo@[10.1.1.1]) is defined in RFC2821 4.1.3." itojun From owner-v6ops@ops.ietf.org Wed Aug 20 20:21: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 UAA21322 for ; Wed, 20 Aug 2003 20:21:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pdCe-0006Ss-Lb for v6ops-data@psg.com; Thu, 21 Aug 2003 00:21:24 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.20) id 19pdCb-0006S5-L8 for v6ops@ops.ietf.org; Thu, 21 Aug 2003 00:21:21 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D669391; Thu, 21 Aug 2003 09:21:19 +0900 (JST) To: Pekka Savola , v6ops@ops.ietf.org, bob@thefinks.com, mrw@windriver.com, andreas.bergstrom@hiof.no In-reply-to: itojun's message of Thu, 21 Aug 2003 09:18:41 +0900. 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: Thu, 21 Aug 2003 09:21:19 +0900 Message-Id: <20030821002119.D669391@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 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]. > > pekka contacted apps people, and confirmed that domain-literal syntax > is still there, and RFC2822 defines domain-literal syntax for IPv6, > which is itojun@[IPv6:2001:240::1]. therefore 3.1.6 is incorrect. > > how about just removing the text, or "support for IPv6 in RFC2822 > domain-literal syntax (foo@[10.1.1.1]) is defined in RFC2821 4.1.3." correction: 'RFC2821 defines domain-literal syntax for IPv6". itojun From owner-v6ops@ops.ietf.org Wed Aug 20 21:47: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 VAA25059 for ; Wed, 20 Aug 2003 21:47:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19peVk-000HU3-Ec for v6ops-data@psg.com; Thu, 21 Aug 2003 01:45:12 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19peVh-000HPs-Li; Thu, 21 Aug 2003 01:45:09 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.20) id 19pdFA-0000t6-UV; Thu, 21 Aug 2003 09:24:01 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 21 Aug 2003 09:24:00 +0900 To: v6ops@ops.ietf.org Cc: IESG Secretary Subject: changing the deck chairs Message-Id: 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 as margaret wasserman has succumbed to the iesg, jonne soinen has agreed to replace her as co-chair, with pekka savola and bob fink, of the v6ops wg. margaret, thanks for the hard work and progress. jonne, welcome to the too often thankless job and thans for your volunteering. randy From owner-v6ops@ops.ietf.org Wed Aug 20 23:45:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29887 for ; Wed, 20 Aug 2003 23:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pgM0-0006k9-30 for v6ops-data@psg.com; Thu, 21 Aug 2003 03:43:16 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.20) id 19pgLt-0006jN-8t for v6ops@ops.ietf.org; Thu, 21 Aug 2003 03:43:09 +0000 Received: from mail pickup service by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC; Wed, 20 Aug 2003 23:43:08 -0400 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Aug 2003 20:35:13 -0400 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.6+Sun/8.11.6) with SMTP id h7L0YUU08239 for ; Wed, 20 Aug 2003 20:34:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pdAA-0006BH-JH for v6ops-data@psg.com; Thu, 21 Aug 2003 00:18:50 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.20) id 19pdA4-0006Ap-EH for v6ops@ops.ietf.org; Thu, 21 Aug 2003 00:18:44 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8ABB891; Thu, 21 Aug 2003 09:18:41 +0900 (JST) To: Pekka Savola , v6ops@ops.ietf.org, bob@thefinks.com, mrw@windriver.com, andreas.bergstrom@hiof.no In-reply-to: itojun's message of Tue, 22 Jul 2003 19:40:48 +0900. <20030722104048.6CF4999@coconut.itojun.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: Re: comment: draft-ietf-v6ops-ipv4survey-intro-01.txt From: itojun@iijlab.net Date: Thu, 21 Aug 2003 09:18:41 +0900 Message-Id: <20030821001841.8ABB891@coconut.itojun.org> X-OriginalArrivalTime: 21 Aug 2003 00:35:16.0947 (UTC) FILETIME=[17CDBA30:01C3677C] X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.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 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]. pekka contacted apps people, and confirmed that domain-literal syntax is still there, and RFC2822 defines domain-literal syntax for IPv6, which is itojun@[IPv6:2001:240::1]. therefore 3.1.6 is incorrect. how about just removing the text, or "support for IPv6 in RFC2822 domain-literal syntax (foo@[10.1.1.1]) is defined in RFC2821 4.1.3." itojun From owner-v6ops@ops.ietf.org Wed Aug 20 23: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 XAA00004 for ; Wed, 20 Aug 2003 23:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pgQo-0007V8-Du for v6ops-data@psg.com; Thu, 21 Aug 2003 03:48:14 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19pgQk-0007Ua-CL for v6ops@ops.ietf.org; Thu, 21 Aug 2003 03:48:10 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 20 Aug 2003 23:48:09 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922C9E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Soliman Hesham Cc: Tsirtsis George , "'Alain Durand'" , "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: Wed, 20 Aug 2003 23:48:05 -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 > Sorry for the delay in responding, there was a load of work piling, > (and I'm not sure it's getting much lower.. :-) => No probs, I can do with more time ;) > > => By default, if you have an IPv6 home address then you _do_ > > have IPv6 connectivity unless you cannot reach the HA. If this > > happens you lose connectivity and session survivability. > > True, but you write this the other way than it's normally > written, that > is: > > By default, if you have a working IPv6 care-of address, you have IPv6 > connectivity. If you can reach the HA, you also have session > survivability. => sure, and the reason I twisted it is this: While your statement above is correct, it is not a reality and will not be for a very long time (I mean the part about IPv6 CoA) as far as mobile nodes are concerned. Obviously this is due to the fact that mobiles can be basically anywhere. Therefore, the only IPv6 address that a MN is sure exists everywhere is its home address. So I suppose I assumed all that when I made the statement above. > > By changing the typical assumptions around, you build a case > on top of > HA-centralized IPv6 connectivity. => Correct, this is intentional for MNs because you cannot assume otherwise. IPv6 connectivity is > independent of the > HA. => Correct as a general statement, but not completely correct for MNs. > > The reason that we published a problem statement > > was that we wanted to see whether people agree and understand > > the problem. Discussing solutions is another step. > > > > So do you agree/understand the problem independently of the > > solution that you think we might propose? > > Let's see. > > I think I can see why some people see these issues as > problems. However, > I can't see why some people see these as really important issues, > requiring changes. > > However, I do not think there is sufficient justification in > the document > why those are problems _worth_ solving, or how big problems > they actually > are (even small problems could be used to justify work). => What does it take for a problem to be worth solving? George and I think it's worth solving because of the problems listed in the draft. If you try to deploy MNs on a large scale, using a wireless network, the problems in the draft become quite serious. There are two ways to avoid them with current standards: - Avoid IPv6 deployment - Move to IPv6-only networks The latter is not going to happen this decade. I'm sure we don't want the first bullet to happen either. > > For example, how do we evaluate the solutions whether they > are justified > to solve the perceived problems? => Solutions are the next step, I get the feeling that you don't think it's a worthwhile problem. Perhaps others can shed more light on this better than I can. > > I guess I don't understand the problem, then. => I'm happy to help. If you can pick on specific sections in the problem statement draft that might help us move forward. > > >Now, assume that one is using MIPv_4_ to enable mobility > management for > > >IPv4. If 6to4 or such is used on top of that > mobility-managed IP address, > > >we don't actually have to do anything MIPv6-wise when we > move, as the IPv4 > > >address stays the same. > > > > => Do you mean 6-to-4 in the home network or in the visited > > network? Obviously we cannot expect anything from the visited > > network. If 6-to-4 is in the home network what does that buy > > us? How does the MN receive traffic in the visited network > > and send in the reverse direction? > > I'm not sure if I understand your question. Assume the node > uses MIPv4, > and has a configured home IPv4 address HADDR_v4. Why > couldn't it just > start (e.g.) 6to4 using that address, generating the prefix > 2002:HADDR_v4::/48 and use an address from there? => Sure it can...see below though. > > Then, when the node moves and executes IPv4 mobility management, the > network where HADDR_v4 is routed automatically changes with it => Now... this is not clear. HADDR_v4 belongs to the home link. If the MN generates a 6-to-4 address then an IPv6 node contacted it using that address after the MN has left the home network, how does the HA forward those IPv6 packets to the MN? The same goes for traffic sent from the MN using 2002:HADDR_v4::/48. > > The node need not have any _IPv6_ care-of addresses at all. > Hey, it's you > who want simplicity, not me! :-) > > Obviously, you could just replace 6to4 and 2002:HADDR_v4 with => You could replace 2002:.... with any other prefix because as I explained above it doesn't do anything for us. It doesn't setup a tunnel between the MN and the HA in any way. any > (configured) IPv6-over-IPv4 tunneling mechanism whose end-point is > HADDR_v4 -- and again it would be "sticky" and you would have to do > nothing at all. => But we're talking about *_mobile_* nodes. A configured tunnel is not useful. if you're saying that you could have a configured tunnel inside the HA to tunnel IPv6 to the MN's IPv4 _home_ address which then gets tunneled to the MN's IPv4 care-of address (the MIP part) then yes this is possible and it is explained in the draft that George announced on the list. But there is a more BW effifcient scenario that would require some assistance from the FA. Both options are explained in the solutions draft (MIPv4 one) that George sent to the MIP mailing list. > What I'm saying (badly, sorry -- took me while to figure out > what I meant > :-) that we can reduce the the problem, with above to the > case where we > have to figure out whether we want to run MIPv6 or not. It > may not be > necessary, but would be beneficial in some cases. > > Beneficial where? I guess I can think of one. > > When native IPv6 is available in the visited networks so you > wouldn't have > to do the extra IPv4 mobility roundtrip home (which may or > may not be a > problem) -- but isn't this whole point about networks where MIPv4 is > deployed and NOT IPv6? It seems to me that when IPv6 would > be deployed in > those networks, you could retire MIPv4 -- and problem solved ! :-) => This is a binary transition mechanism :) You're basically saying that "today V4 is used, tomorrow we will have dual stack networks and we can retire MIPv4." Hmmm...not that simple unfortunately because there is more than one network and there is a different "tomorrow" for each of those networks. So what is going to happen is that we will have v4-only and dual stack networks at the same time. Also, we can't just "retire" MIPv4 unless there is a flag day. So we can phase it out. From the two solutions drafts that we have (second one coming soon), you could conclude that we assumed the following scenario: 1. Use MIPv4 (present) 2. Extended MIPv4 to allow for IPv6 home address (near future) 3. Extended MIPv6 to allow for v4 home addresses (future) 2) and 3) can coexist (i.e. in different MNs). That's a more likely transition IMHO. > > 2. You think that such thinking requires us to know > > how long the transition will take. > > I think, yes -- a ballpark figure would be quite useful. > The worse the > hack one is proposing, the bigger the need is to consider > ("how long do we > have to live with this?"). => I'm not assuming that a hack is being proposed. > I'm not sure what you're referring to, but IMHO we should > try to avoid > doing EITHER: > > 1) short-term fixes to solve long-term problems, or > 2) long-term fixes to solve short-term problems. > > 2) is probably even worse (and what I'm fearing here), > because if we come > across with 1), and the fix proves to be too short-term, we > can just try > again. This of course has its pitfalls too. => I'm not going to anticipate how long a solution will last because I know that people who do that are usually wrong. So, if you want to answer those questions I think you should say what is "short term problem", "long term problem", "short term fixes" and "long term fixes". I think this is a can of worms.... I don't think we'll go anywhere trying to answer those questions. Worse, we won't get consensus on those definitions (just call it a hunch ;) ). Hesham From owner-v6ops@ops.ietf.org Wed Aug 20 23:54: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 XAA00252 for ; Wed, 20 Aug 2003 23:54:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pgWu-0008Y4-1y for v6ops-data@psg.com; Thu, 21 Aug 2003 03:54:32 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.20) id 19pgWr-0008XV-I3 for v6ops@ops.ietf.org; Thu, 21 Aug 2003 03:54:29 +0000 Received: from mail pickup service by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC; Wed, 20 Aug 2003 23:53:47 -0400 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Aug 2003 20:36:32 -0400 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7+Sun/8.11.6) with SMTP id h7L0aVV09421 for ; Wed, 20 Aug 2003 20:36:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19pdCe-0006Ss-Lb for v6ops-data@psg.com; Thu, 21 Aug 2003 00:21:24 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.20) id 19pdCb-0006S5-L8 for v6ops@ops.ietf.org; Thu, 21 Aug 2003 00:21:21 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D669391; Thu, 21 Aug 2003 09:21:19 +0900 (JST) To: Pekka Savola , v6ops@ops.ietf.org, bob@thefinks.com, mrw@windriver.com, andreas.bergstrom@hiof.no In-reply-to: itojun's message of Thu, 21 Aug 2003 09:18:41 +0900. 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: Thu, 21 Aug 2003 09:21:19 +0900 Message-Id: <20030821002119.D669391@coconut.itojun.org> X-OriginalArrivalTime: 21 Aug 2003 00:36:36.0855 (UTC) FILETIME=[476EB870:01C3677C] X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.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 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]. > > pekka contacted apps people, and confirmed that domain-literal syntax > is still there, and RFC2822 defines domain-literal syntax for IPv6, > which is itojun@[IPv6:2001:240::1]. therefore 3.1.6 is incorrect. > > how about just removing the text, or "support for IPv6 in RFC2822 > domain-literal syntax (foo@[10.1.1.1]) is defined in RFC2821 4.1.3." correction: 'RFC2821 defines domain-literal syntax for IPv6". itojun From owner-v6ops@ops.ietf.org Fri Aug 22 03:45: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 DAA09377 for ; Fri, 22 Aug 2003 03:45:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19q6X2-00044U-Py for v6ops-data@psg.com; Fri, 22 Aug 2003 07:40:24 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19q6WW-0003lN-KT for v6ops@ops.ietf.org; Fri, 22 Aug 2003 07:39:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7M7coP32581; Fri, 22 Aug 2003 10:38:50 +0300 Date: Fri, 22 Aug 2003 10:38:49 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com, , , Subject: WG Last Call: three draft-ietf-v6ops-ipv4survey-*01 documents 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, This is a WG Last Call for comments on sending the following the next three "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents to the IESG for consideration as Informational RFCs: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-01.txt Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-01.txt Please review these documents carefully, and send your feedback to the list (editorial modifications may also be sent to the editors, Cesar for the first, Andreas for the other two). 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. The last call will end in 3 weeks, on 12th September. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Fri Aug 22 05:12: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 FAA12271 for ; Fri, 22 Aug 2003 05:12:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19q7ve-000K6n-TZ for v6ops-data@psg.com; Fri, 22 Aug 2003 09:09:54 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.20) id 19q7us-000K0c-5l for v6ops@ops.ietf.org; Fri, 22 Aug 2003 09:09:06 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7M994422895 for ; Fri, 22 Aug 2003 12:09:04 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 22 Aug 2003 12:09:03 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 12:09:02 +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: 3gpp-analysis: issue tracker on the web Date: Fri, 22 Aug 2003 12:08:46 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A4C@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis: the way forward to revision -05 Thread-Index: AcNnTi2t/+gib2EyTS6X/KPFHFxICABPVK3Q From: To: Cc: X-OriginalArrivalTime: 22 Aug 2003 09:09:02.0777 (UTC) FILETIME=[07D7DA90:01C3688D] X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_01,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 Content-Transfer-Encoding: quoted-printable Hi all! An issue tracker has been created for 3GPP analysis, pls have a look at http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-analysis/index Using this tracker, you can see the latest status of our 3GPP Analysis = document. I hope that this tool helps us to complete the document soon. = What comes to the classification of issues suggested by Pekka, I mostly = agree with it. Thanks, Dan, for your help setting up the tool! Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 20 August, 2003 22:03 Thanks to Juha for taking this list together. For reference, I think we can separate the issues that weren't downright closed (e.g. seem to have been resolved or waiting for some other action) in two. Topics which don't seem to be closed which probably require more attention, in some form or another (possibly cannot be settled by = textual updates without further WG feedback etc.): > 2) Use of NAT-PT in IPv6 UE -> IPv4 node >=20 > 6) Transition mechanisms at UEs >=20 > 9) Automatic tunneling inside 3GPP operator's network and those issues which were not discussed at all (or in limited scale); = that could of might or might not mean that there are no objections to = the comments. > 4) The use of 6to4 > > 7) Tunnels out of 3GPP operator's network >=20 > 8) Need for UE <-> 3GPP Configuration <-- probably rather important?! >=20 > 10) SIP/SDP transition From owner-v6ops@ops.ietf.org Fri Aug 22 07:51: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 HAA18540 for ; Fri, 22 Aug 2003 07:51:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qAPE-000K1b-N5 for v6ops-data@psg.com; Fri, 22 Aug 2003 11:48:36 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.20) id 19qAOi-000JsF-8z for v6ops@ops.ietf.org; Fri, 22 Aug 2003 11:48:04 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7MBm2402098 for ; Fri, 22 Aug 2003 14:48:03 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Aug 2003 14:48:02 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 14:48:02 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 14:48:01 +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: Need for UE<->3GPP Configuration? [issue 8] Date: Fri, 22 Aug 2003 14:48:01 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A4D@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: Need for UE<->3GPP Configuration? Thread-Index: AcNRw+JrWJSHqz93R92Bk7XhkFliEgW1ZXew From: To: , X-OriginalArrivalTime: 22 Aug 2003 11:48:01.0851 (UTC) FILETIME=[3D9308B0:01C368A3] 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! Some comments below with JW: -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 24 July, 2003 12:12 Looking at the document, it is not clear to me how the UE's will be=20 configured. JW: That's right, those issues have not been discussed in our drafts. = However, many settings (example: how to define what GGSN Access Point = Name is used when you use e.g. MMS application) can be manufacturer = specific. Also using OTA (Over The Air) configuration is very common = today. An example: you go to your operator www home page and subscribe = "MMS settings". Then you receive them via SMS message and approve them = in the phone. You can also type in that information manually. For example, how will they be provisioned with: - the DNS server addresses (search path is a definite non-goal) JW: Yep, that is an important point. In getting DNS server addresses, = you can use 3GPP specific mechanism (so-called PCO Information Element) = and you receive the DNS server address(es) in PDP context activation - = i.e. that is a control plane mechanism. You can also use, for example, = stateless DHCPv6. It is a shame that "well-known site-local addresses" = cannot make its way to a standard. Anyways, dnsop is working on the = general IPv6 DNS disc. problem. - addresses of web proxies, and possibly other ALG's=20 JW: Yep, and one important thing is the P-CSCF IPv6 address. = 3GPP-specific mechanism (PCO IE) or (stateless) DHCPv6 can be used for = that. Of course, OTA mechanism could be used. - the NTP servers, if needed JW: Well...I don't think that is necessary in our case.. - 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.). JW: Summarizing all the above, some descriptive text can be written, but = I am not so sure that it is vitally needed. Thanks, =09 -Juha- From owner-v6ops@ops.ietf.org Fri Aug 22 08:01: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 IAA19103 for ; Fri, 22 Aug 2003 08:01:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qAb6-000LsZ-Bf for v6ops-data@psg.com; Fri, 22 Aug 2003 12:00:52 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.20) id 19qAaC-000Lme-53 for v6ops@ops.ietf.org; Fri, 22 Aug 2003 11:59:56 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7MBxsB29631 for ; Fri, 22 Aug 2003 14:59:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Aug 2003 14:59:54 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 14:59:54 +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: tunnels out of 3GPP operator's network Date: Fri, 22 Aug 2003 14:59:53 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A4F@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: tunnels out of 3GPP operator's network Thread-Index: AcNRvPLB8QbkvaMVSze83gSaoY19xwW5sKxg From: To: , X-OriginalArrivalTime: 22 Aug 2003 11:59:54.0083 (UTC) FILETIME=[E6190330:01C368A4] X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_01,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, yep - this is an area that is somewhat overlapping with the ISP = documents (and that's why we refer to ISP scenarios and analysis (when = it will be published)).=20 =3D> In my opinion, it is fine to do your proposed changes. Let's make = further changes, if somebody is not happy with that. Making these = changes also means removing 6to4 references from this section. Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 24 July, 2003 11:22 To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: tunnels out of 3GPP operator's network Hi, In section 3.2.2, "Tunneling outside the 3GPP Operator's Network",=20 describes the case where the 3GPP operator has to obtain Internet=20 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=20 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??) =20 I'd remove the last paragraph completely (as was already mentioned in = some=20 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=20 best approach, as the number of the tunnels outside of the 3GPP=20 network is very limited; no more than a couple of tunnels should=20 be needed. ISP transition scenarios are described in [ISP-scen] and=20 [ISP-analysis]. (or leave the last one out completely; it should already be addresses in = at the start of section 3.2) =3D=3D=3D=3D 3.2.2 Tunneling outside the 3GPP Operator's Network = =20 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. = =20 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. --=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 Aug 22 08:31: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 IAA20331 for ; Fri, 22 Aug 2003 08:31:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qB3W-0000e3-MD for v6ops-data@psg.com; Fri, 22 Aug 2003 12:30:14 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.20) id 19qB30-0000Yz-B4 for v6ops@ops.ietf.org; Fri, 22 Aug 2003 12:29:42 +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 h7MCTeB28001 for ; Fri, 22 Aug 2003 15:29:40 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Aug 2003 15:29:40 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 15:29:40 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 15:29:39 +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: SIP/SDP transition [issue10] Date: Fri, 22 Aug 2003 15:29:38 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A50@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: SIP/SDP transition Thread-Index: AcNSYPoG/W2951t7SHSfTec9GPkm+gWRA7/Q From: To: , X-OriginalArrivalTime: 22 Aug 2003 12:29:39.0786 (UTC) FILETIME=[0E75AAA0:01C368A9] 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, that's right. SIP/SDP transition scenarios still need more work and I = think the generic SIP/SDP transition problem (mainly) belongs to SIP = wg(s), not our wg. Anyway, main lines of a recommended "IMS = interworking" mechanism should be written out in our document. 3GPP = Analysis currently describes SIP ALG that modifies SIP/SDP, and no = changes are needed in basic Rel5/Rel6 UEs. Draft-elmalki... describes a = bit modified solution proposing some changes in the UEs, i.e. the UE = needs to understand a new header to put the IPv4 address received into = SDP using the ALT extension. Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 25 July, 2003 06:20 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. = =20 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. =3D=3D=3D=3D=3D 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. From owner-v6ops@ops.ietf.org Fri Aug 22 09:01: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 JAA21583 for ; Fri, 22 Aug 2003 09:01:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qBT0-0004bs-BX for v6ops-data@psg.com; Fri, 22 Aug 2003 12:56:34 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.20) id 19qBRp-0004P1-Kb for v6ops@ops.ietf.org; Fri, 22 Aug 2003 12:55:21 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7MCtJB23375 for ; Fri, 22 Aug 2003 15:55:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Aug 2003 15:55:19 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 15:55:19 +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: The use of 6to4 [issue 4] Date: Fri, 22 Aug 2003 15:55:18 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A51@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: The use of 6to4 Thread-Index: AcNRAYY66zZHbj+ISUSmuGgyRw9ZtgXqJTAA From: To: , X-OriginalArrivalTime: 22 Aug 2003 12:55:19.0280 (UTC) FILETIME=[A411CF00:01C368AC] X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_01,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi again, yep... I have cut quite a lot text introducing "6to4" in the previous = version, and I could actually remove the rest of that text in the = beginning of section 3.2.1. Furthermore, I will consider rewording based on your proposals. This = issue is also related to issue 7, and I agreed to (initially) remove = 6to4 from chapter 3.2.2. Brian Carpenter also commented that "...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." Of course, that kind of situation is possible, but can we consider it as = a special case that needs not be included in this document trying to = find general solutions? BR, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 23 July, 2003 12:37 To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: The use of 6to4 The first issue of today. --8<-- In the document, the use of 6to4 is mentioned several times. However,=20 this method needs some scoping: IMHO, it is clear that 6to4 is not a=20 useful approach for ISP-like networks, so it is not useful to recommend=20 that 3GPP networks use it for example for Internet connectivity. It is=20 just so much easier to get a configured tunnel or native IPv6 from the=20 upstream providers. You just can't build a service like 3GPP networks=20 intend to using 6to4; for some internal piloting, etc. it may be = possible,=20 yes, but that's mostly outside of the scope of the document (but could = be=20 mentioned for completeness if enough folks feel like it). The text in the document is already healthily skeptical of 6to4's=20 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=20 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 [...] = =20 "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.=20 [note: could split to two paragraphs around here, the paragraph is both=20 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 [...] = =20 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=20 or parts of the 3GPP network is strongly discouraged; configured=20 tunneling or preferably native IPv6 connectivity is preferred. The end of the paragraph of 3.2.1 is also confusing things: tunneling=20 inside the operator's network ("replacement for BGP tunneling"; as=20 described in section 2.4.3 of draft-savola-v6ops-6to4-security-02.txt = but=20 IMHO a bit bad practice) -- and addressing the needs of the 3GPP UE's=20 (pun intended). If you want to only use 6to4 internally, you can't = deploy=20 6to4 addresses on the UE's. If you wan to use it externally, the=20 considerations in the next section step out. So, I think at least the end of the last paragraph of section 3.2.1 = should=20 be removed/reworded. I also fail to see a strict need for the 6to4 introduction (the first = part=20 of the paragraph in 3.2.1) here, at least at this point. --=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 Aug 22 09:11: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 JAA22003 for ; Fri, 22 Aug 2003 09:11:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qBfu-0007jO-03 for v6ops-data@psg.com; Fri, 22 Aug 2003 13:09:54 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.20) id 19qBfF-0007cx-KW for v6ops@ops.ietf.org; Fri, 22 Aug 2003 13:09:13 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7MD9B428034 for ; Fri, 22 Aug 2003 16:09:12 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Aug 2003 16:09:11 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 16:09:10 +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: DNS guidelines [issue 5] Date: Fri, 22 Aug 2003 16:05:01 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A52@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: DNS guidelines Thread-Index: AcNRNw+u+UvkCBV8RrGQChULVH+n5gXdgf5Q From: To: , Cc: X-OriginalArrivalTime: 22 Aug 2003 13:09:10.0678 (UTC) FILETIME=[939F1360:01C368AE] X-Spam-Status: No, hits=-12.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,NO_REAL_NAME,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 Hi! Thanks to Alain's comments, I think this issue is more or less resolved. I will make reference to: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-transport-guide= lines-00.txt -> Alain, is this ok version, or is revision -01 coming any time soon?=20 One additional editorial comment by Pekka is ok for me. Cheers, -Juha- -----Original Message----- From: ext Alain Durand [mailto:Alain.Durand@Sun.COM] Sent: 23 July, 2003 19:25 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-04: DNS guidelines 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=20 > because > I'm leaving for vacation on Friday and want to send all of them out=20 > before > that.) > ---- > > Actually, there are five related issues here regarding DNS guidelines=20 > in > the document. > > * The statement about IPv6-only DNS servers, "every recursive DNS=20 > server > should be either IPv4-only or dual stack", it not entirely accurate. =20 > It > is perfectly OK to have a IPv6-only DNS server which recursively=20 > 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=20 > 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=20 server... Although, I agree, there is a lot of confusion in the terminology in=20 that area. This will be cleared up in the upcoming revision of=20 draft-ietf-dnsop-ipv6-transport-guidelines-00.txt > > * The analysis only refers to [DNStrans]; it should also refer to=20 > (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=20 now is draft-ietf-dnsop-ipv6-transport-guidelines-00.txt > > * " When thinking the DNS issues, [...]" sounds bad and should be=20 > reworded > (sorry, forgot to add this to the editorial section.) > > * The description in section 3.5 is very terse. The problems here=20 > 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=20 > 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=20 > 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=20 > 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]. =3D=3D> this is where draft-ietf-dnsop-ipv6-transport-guidelines-00.txt=20 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=20 be dual stack according to=20 draft-ietf-dnsop-ipv6-transport-guidelines-00.txt. - Alain. From owner-v6ops@ops.ietf.org Fri Aug 22 09:12: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 JAA22114 for ; Fri, 22 Aug 2003 09:12:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qBi5-00085Q-0x for v6ops-data@psg.com; Fri, 22 Aug 2003 13:12:09 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.20) id 19qBh1-0007vM-7G for v6ops@ops.ietf.org; Fri, 22 Aug 2003 13:11:04 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7MDB0400304 for ; Fri, 22 Aug 2003 16:11:01 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Aug 2003 16:10:57 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 16:10:55 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 22 Aug 2003 16:10:53 +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: Security considerations [issue 11] Date: Fri, 22 Aug 2003 16:06:52 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F01907660@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: Security considerations Thread-Index: AcNb+sBWNnosnRaETZG6aAGVptF9qAMs1Lpg From: To: , Cc: X-OriginalArrivalTime: 22 Aug 2003 13:10:53.0581 (UTC) FILETIME=[D0F4D3D0:01C368AE] X-Spam-Status: No, hits=-15.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,NO_REAL_NAME,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 Yep, let's freeze this for a moment and try to complete the content of = the doc first. Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 06 August, 2003 12:05 To: Soliman Hesham Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Security considerations On Thu, 24 Jul 2003, Soliman Hesham wrote: > Do you want to send text? Perhaps when you get back. > This comment is a bit too open. I think we had better to first try to settle the rest of the document=20 (wrt. transition scenarios, etc.) because changes in those would affect=20 the security considerations a lot too. > > -----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 > >=20 > >=20 > > Hi, > >=20 > > The security consideration section of the 3GPP analysis=20 > > document is still=20 > > very weak; in principle, they only cover three points=20 > > related to NAT-PT=20 > > and/or DNSSEC. A more thorough analysis is required. =20 > >=20 > > In addition to NAT-PT/DNSSEC issues (I'm not sure if the=20 > > three points are=20 > > a conclusive list, though), the security properties of different=20 > > transition scenarios and mechanisms should be briefly described. =20 > >=20 > > The exact contents depends a lot on which mechanisms we seem to get > > rough consensus on. > >=20 > > =3D=3D=3D=3D=3D > > 5. Security Considerations > > =20 > > =20 > > 1. NAT-PT DNS ALG problems are described in [NATPT-DNS] = and > > [v4v6trans]. > > =20 > > =20 > > 2. The 3GPP specifications do not currently define the = usage > > of DNS Security. They neither disallow the usage=20 > > of DNSSEC, > > nor do they mandate it. > > =20 > > =20 > > 3. NAT-PT breaks DNSSEC. > > --=20 > > Pekka Savola "You each name yourselves king, yet = the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of = Kings > >=20 > >=20 > >=20 >=20 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 22 10:04: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 KAA25252 for ; Fri, 22 Aug 2003 10:04:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qCUW-000GG8-Ud for v6ops-data@psg.com; Fri, 22 Aug 2003 14:02:12 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19qCTx-000GDl-MR for v6ops@ops.ietf.org; Fri, 22 Aug 2003 14:01:37 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24819; Fri, 22 Aug 2003 10:01:20 -0400 (EDT) Message-Id: <200308221401.KAA24819@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-02.txt Date: Fri, 22 Aug 2003 10:01:20 -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-02.txt Pages : 0 Date : 2003-8-22 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-ops-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22090022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-ops-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22090022.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Aug 22 10:34: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 KAA29409 for ; Fri, 22 Aug 2003 10:34:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qCxH-000KcP-Qi for v6ops-data@psg.com; Fri, 22 Aug 2003 14:31:55 +0000 Received: from [131.137.245.203] (helo=mx03.forces.gc.ca) by psg.com with esmtp (Exim 4.20) id 19qCvL-000KKg-75 for v6ops@ops.ietf.org; Fri, 22 Aug 2003 14:29:55 +0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 0DB81206609 for ; Fri, 22 Aug 2003 10:25:54 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19qCUB-0004G4-45 for ietf-announce-list@asgard.ietf.org; Fri, 22 Aug 2003 10:01:51 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19qCTp-00044k-LO for all-ietf@asgard.ietf.org; Fri, 22 Aug 2003 10:01:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24844; Fri, 22 Aug 2003 10:01:24 -0400 (EDT) Message-Id: <200308221401.KAA24844@ietf.org> 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-02.txt Date: Fri, 22 Aug 2003 10:01:24 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+48454_87806320875842_01114687091" X-Spam-Status: No, hits=-0.3 required=5.0 tests=BAYES_20,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 --MIMEStream=_0+48454_87806320875842_01114687091 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-02.txt Pages : 0 Date : 2003-8-22 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-subip-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+48454_87806320875842_01114687091 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+192715_1848593818075_048890855" --MIMEStream=_1+192715_1848593818075_048890855 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22090047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-02.txt --MIMEStream=_1+192715_1848593818075_048890855 Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-subip-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22090047.I-D@ietf.org> --MIMEStream=_1+192715_1848593818075_048890855-- --MIMEStream=_0+48454_87806320875842_01114687091-- From owner-v6ops@ops.ietf.org Fri Aug 22 10:48: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 KAA00554 for ; Fri, 22 Aug 2003 10:48:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qDBG-000N2k-Iq for v6ops-data@psg.com; Fri, 22 Aug 2003 14:46:22 +0000 Received: from [131.137.245.203] (helo=mx03.forces.gc.ca) by psg.com with esmtp (Exim 4.20) id 19qD8g-000Mbp-G1 for v6ops@ops.ietf.org; Fri, 22 Aug 2003 14:43:42 +0000 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 6C6B2206631 for ; Fri, 22 Aug 2003 10:26:54 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19qCUA-0004Fs-Vl for ietf-announce-list@asgard.ietf.org; Fri, 22 Aug 2003 10:01:50 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19qCTh-000425-Tf for all-ietf@asgard.ietf.org; Fri, 22 Aug 2003 10:01:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24802; Fri, 22 Aug 2003 10:01:16 -0400 (EDT) Message-Id: <200308221401.KAA24802@ietf.org> 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-02.txt Date: Fri, 22 Aug 2003 10:01:16 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+297999_53512794821673_9287245323" X-Spam-Status: No, hits=-0.3 required=5.0 tests=BAYES_20,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 --MIMEStream=_0+297999_53512794821673_9287245323 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-02.txt Pages : 0 Date : 2003-8-22 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-intro-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+297999_53512794821673_9287245323 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+233213_97704457113678_0866529715" --MIMEStream=_1+233213_97704457113678_0866529715 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22090014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-02.txt --MIMEStream=_1+233213_97704457113678_0866529715 Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22090014.I-D@ietf.org> --MIMEStream=_1+233213_97704457113678_0866529715-- --MIMEStream=_0+297999_53512794821673_9287245323-- From owner-v6ops@ops.ietf.org Fri Aug 22 11:14: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 LAA02168 for ; Fri, 22 Aug 2003 11:14:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qDT0-0000tS-AI for v6ops-data@psg.com; Fri, 22 Aug 2003 15:04:42 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19qDRy-0000Tw-E9 for v6ops@ops.ietf.org; Fri, 22 Aug 2003 15:03:38 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24802; Fri, 22 Aug 2003 10:01:16 -0400 (EDT) Message-Id: <200308221401.KAA24802@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-02.txt Date: Fri, 22 Aug 2003 10:01:16 -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-02.txt Pages : 0 Date : 2003-8-22 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-intro-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22090014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22090014.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Aug 22 11:15: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 LAA02200 for ; Fri, 22 Aug 2003 11:15:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qDTU-00013Z-CT for v6ops-data@psg.com; Fri, 22 Aug 2003 15:05:12 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.20) id 19qDS3-0000Tw-47 for v6ops@ops.ietf.org; Fri, 22 Aug 2003 15:03:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24844; Fri, 22 Aug 2003 10:01:24 -0400 (EDT) Message-Id: <200308221401.KAA24844@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-02.txt Date: Fri, 22 Aug 2003 10:01:24 -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-02.txt Pages : 0 Date : 2003-8-22 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-subip-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22090047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-subip-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-22090047.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Aug 22 19:45: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 TAA28394 for ; Fri, 22 Aug 2003 19:45:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qLWb-000DE1-1G for v6ops-data@psg.com; Fri, 22 Aug 2003 23:40:57 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19qLVA-000Cjp-DK for v6ops@ops.ietf.org; Fri, 22 Aug 2003 23:39:28 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7MNdQj15336 for ; Fri, 22 Aug 2003 16:39:26 -0700 X-mProtect: <200308222339> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFYVqew; Fri, 22 Aug 2003 16:39:24 PDT Message-ID: <3F46ABA4.7090408@iprg.nokia.com> Date: Fri, 22 Aug 2003 16:47:48 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: RFC 2893-style automatic tunneling References: <245DBCAEEC4F074CB77B3F984FF9834F01907660@esebe005.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Is RFC 2893-style automatic tunneling (i.e., with IPv4-compatible IPv6 addresses) used in any active deployments? It seems to me that the functionality is obsoleted by newer automatic tunneling mechanisms (e.g., 6to4, isatap, etc.) but I'd like to hear from those with more current operational experience. Thanks - Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Sat Aug 23 01:40: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 BAA10283 for ; Sat, 23 Aug 2003 01:40:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qR5d-000Hvu-0B for v6ops-data@psg.com; Sat, 23 Aug 2003 05:37:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19qR4q-000Hkd-5u for v6ops@ops.ietf.org; Sat, 23 Aug 2003 05:36:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7N5Zbw12879; Sat, 23 Aug 2003 08:35:37 +0300 Date: Sat, 23 Aug 2003 08:35:37 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: The use of 6to4 [issue 4] In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3A51@esebe005.ntc.nokia.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 On Fri, 22 Aug 2003 juha.wiljakka@nokia.com wrote: > yep... I have cut quite a lot text introducing "6to4" in the previous > version, and I could actually remove the rest of that text in the > beginning of section 3.2.1. > > Furthermore, I will consider rewording based on your proposals. This > issue is also related to issue 7, and I agreed to (initially) remove > 6to4 from chapter 3.2.2. OK. > Brian Carpenter also commented that "...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." > > Of course, that kind of situation is possible, but can we consider it as > a special case that needs not be included in this document trying to > find general solutions? I think my original comment was aimed at 3GPP operators specifically (the doc had a lot of text describing how a 3GPP _operator_ itself could run on top of 6to4). Brian's comment may be valid ("transition mechanisms at UEs discussion"), but in different context. Sorry for picking overly generic term for this. > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 23 July, 2003 12:37 > To: v6ops@ops.ietf.org > Subject: 3gpp-analysis-04: The use of 6to4 > > > 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 Sat Aug 23 03:28: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 DAA25565 for ; Sat, 23 Aug 2003 03:28:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qSlE-000OIs-PH for v6ops-data@psg.com; Sat, 23 Aug 2003 07:24:32 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19qSkb-000O40-62 for v6ops@ops.ietf.org; Sat, 23 Aug 2003 07:23:53 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sat, 23 Aug 2003 03:23:51 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CAD@ftmail.lab.flarion.com> From: Soliman Hesham To: v6ops@ops.ietf.org Subject: FW: [mobile-ip] I-D ACTION:draft-soliman-v4v6-mipv4-00.txt Date: Sat, 23 Aug 2003 03:23:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C36947.7CBE8100" 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 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_01C36947.7CBE8100 Content-Type: text/plain; charset="iso-8859-1" FYI Hesham > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, August 22, 2003 10:02 AM > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] I-D ACTION:draft-soliman-v4v6-mipv4-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Dual Stack Mobile IPv6 > Author(s) : H. Soliman, G. Tsirtsis > Filename : draft-soliman-v4v6-mipv4-00.txt > Pages : 11 > Date : 2003-8-22 > > This specification adds IPv4 extensions to Mobile IPv6 to allow dual > stack mobile nodes to roam within the Internet using Mobile IPv6 > only while simultaneously maintaining connections using their IPv4 > and IPv6 home addresses. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-soliman-v4v6-mipv4-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-soliman-v4v6-mipv4-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-soliman-v4v6-mipv4-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_01C36947.7CBE8100 Content-Type: message/rfc822 To: Subject: Date: Sat, 23 Aug 2003 03:23:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C36947.7CBE8100" ------_=_NextPart_002_01C36947.7CBE8100 Content-Type: text/plain ------_=_NextPart_002_01C36947.7CBE8100 Content-Type: application/octet-stream; name="ATT22329.txt" Content-Disposition: attachment; filename="ATT22329.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-22102037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-soliman-v4v6-mipv4-00.txt ------_=_NextPart_002_01C36947.7CBE8100 Content-Type: message/external-body; site="internet-drafts"; dir="draft-soliman-v4v6-mipv4-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C36947.7CBE8100-- ------_=_NextPart_000_01C36947.7CBE8100-- From owner-v6ops@ops.ietf.org Sun Aug 24 07:35: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 HAA03110 for ; Sun, 24 Aug 2003 07:35:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qt4b-0009QX-WE for v6ops-data@psg.com; Sun, 24 Aug 2003 11:30:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19qt3g-0009BV-BP for v6ops@ops.ietf.org; Sun, 24 Aug 2003 11:29:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7OBS8800889; Sun, 24 Aug 2003 14:28:08 +0300 Date: Sun, 24 Aug 2003 14:28:07 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C9E@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-27.3 required=5.0 tests=BAYES_30,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, On Wed, 20 Aug 2003, Soliman Hesham wrote: > > > => By default, if you have an IPv6 home address then you _do_ > > > have IPv6 connectivity unless you cannot reach the HA. If this > > > happens you lose connectivity and session survivability. > > > > True, but you write this the other way than it's normally > > written, that > > is: > > > > By default, if you have a working IPv6 care-of address, you have IPv6 > > connectivity. If you can reach the HA, you also have session > > survivability. > > => sure, and the reason I twisted it is this: While your > statement above is correct, it is not a reality and will not > be for a very long time (I mean the part about IPv6 CoA) as > far as mobile nodes are concerned. Obviously this is due to > the fact that mobiles can be basically anywhere. Therefore, > the only IPv6 address that a MN is sure exists everywhere > is its home address. So I suppose I assumed all that when > I made the statement above. Yes, you made that assumption -- and also assumed that using IPv6-over-IPv4 tunneling to the home agent would be the way to fix that. This is a critical difference in our opinions, and how people think of operating Mobile IP. It needs to be spelled out, even though it is not an DSMIP-specific issue. > > By changing the typical assumptions around, you build a case > > on top of > > HA-centralized IPv6 connectivity. > > => Correct, this is intentional for MNs because you cannot > assume otherwise. As I've shown, you certainly can (i.e. that MNs obtain IPv6 connectivity independent of that HA). > IPv6 connectivity is > > independent of the > > HA. > > => Correct as a general statement, but not completely correct for > MNs. Same as above. > > > The reason that we published a problem statement > > > was that we wanted to see whether people agree and understand > > > the problem. Discussing solutions is another step. > > > > > > So do you agree/understand the problem independently of the > > > solution that you think we might propose? > > > > Let's see. > > > > I think I can see why some people see these issues as > > problems. However, > > I can't see why some people see these as really important issues, > > requiring changes. > > > > However, I do not think there is sufficient justification in > > the document > > why those are problems _worth_ solving, or how big problems > > they actually > > are (even small problems could be used to justify work). > > => What does it take for a problem to be worth solving? Good question :-) > George and I think it's worth solving because of the > problems listed in the draft. If you try to deploy > MNs on a large scale, using a wireless network, the > problems in the draft become quite serious. There > are two ways to avoid them with current standards: > > - Avoid IPv6 deployment > - Move to IPv6-only networks > > The latter is not going to happen this decade. I'm > sure we don't want the first bullet to happen either. The draft lists several problems, some of which I don't agree with, some of which I think can be solved with other approaches, and some of which I agree may be potential issues but which I don't see really huge problems. I think these separate problems have to be teased out from one big lump leading to your conclusion. > > I guess I don't understand the problem, then. > > => I'm happy to help. If you can pick on specific sections > in the problem statement draft that might help us > move forward. I had a closer look at parts of it, and I'll be sending some comments shortly. > > Then, when the node moves and executes IPv4 mobility management, the > > network where HADDR_v4 is routed automatically changes with it > > => Now... this is not clear. HADDR_v4 belongs to the home link. More to the point: HADDR_v4 is part of the home link address space. Home agent proxies it for the mobile node, and the address itself is configured on the mobile node. > If the MN generates a 6-to-4 address then an IPv6 node contacted > it using that address after the MN has left the home network, how > does the HA forward those IPv6 packets to the MN? Easily. Note that those are *NOT* IPv6 packets. They're proto-41 IPv4 packets :-). It's double encapsulation, but hey.. it works and is trivial! > The same goes for traffic sent from the MN using 2002:HADDR_v4::/48. Works equally well, as above. > > The node need not have any _IPv6_ care-of addresses at all. > > Hey, it's you > > who want simplicity, not me! :-) > > > > Obviously, you could just replace 6to4 and 2002:HADDR_v4 with > > => You could replace 2002:.... with any other prefix because as > I explained above it doesn't do anything for us. Yes, it fixes the problem altogether, see above. > It doesn't setup > a tunnel between the MN and the HA in any way. For some weird reason, you keep having this fixation that tunnel MUST BE between MN and the HA. There is *NO* reason for that. The tunnel can be to whatever box in the network, as long as it provides IPv6 support. However, it could very easily be the HA too, just by being the 6to4 relay or the (somehow) configured tunnel's endpoint. But that's certainly *not* a requirement. > any > > (configured) IPv6-over-IPv4 tunneling mechanism whose end-point is > > HADDR_v4 -- and again it would be "sticky" and you would have to do > > nothing at all. > > => But we're talking about *_mobile_* nodes. A configured tunnel > is not useful. It is very useful if it's between the Home agent's IPv4 address and the Mobile Node's home address. No need to reconfigure everything, always works if MIPv4 works, etc :-). > if you're saying that you could have a configured tunnel inside > the HA to tunnel IPv6 to the MN's IPv4 _home_ address which then > gets tunneled to the MN's IPv4 care-of address (the MIP part) > then yes this is possible and it is explained in the draft > that George announced on the list. Yes, that's exactly the possibility. It needs to go to the problem statement (if you keep considering there being a problem) to be taken seriously. > But there is a more > BW effifcient scenario that would require some assistance > from the FA. Both options are explained in the solutions > draft (MIPv4 one) that George sent to the MIP mailing list. Bandwidth efficiency is just ONE trade-off here. What I'd like is that the problem statement would list all the issues so that the readers could have better idea of the tradeoffs. Actually, maybe the document should be called "goals" or "requirements", not a problem statement, because "problem statement" doesn't give enough coverage on other tradeoffs of finding a solution. > > What I'm saying (badly, sorry -- took me while to figure out > > what I meant > > :-) that we can reduce the the problem, with above to the > > case where we > > have to figure out whether we want to run MIPv6 or not. It > > may not be > > necessary, but would be beneficial in some cases. > > > > Beneficial where? I guess I can think of one. > > > > When native IPv6 is available in the visited networks so you > > wouldn't have > > to do the extra IPv4 mobility roundtrip home (which may or > > may not be a > > problem) -- but isn't this whole point about networks where MIPv4 is > > deployed and NOT IPv6? It seems to me that when IPv6 would > > be deployed in > > those networks, you could retire MIPv4 -- and problem solved ! :-) > > => This is a binary transition mechanism :) > You're basically saying that "today V4 is used, tomorrow > we will have dual stack networks and we can retire MIPv4." > Hmmm...not that simple unfortunately because there is more > than one network and there is a different "tomorrow" for each > of those networks. So what is going to happen is that we will > have v4-only and dual stack networks at the same time. > > Also, we can't just "retire" MIPv4 unless there is a flag > day. So we can phase it out. From the two solutions drafts > that we have (second one coming soon), you could conclude > that we assumed the following scenario: > > 1. Use MIPv4 (present) > 2. Extended MIPv4 to allow for IPv6 home address (near future) > 3. Extended MIPv6 to allow for v4 home addresses (future) > > 2) and 3) can coexist (i.e. in different MNs). > That's a more likely transition IMHO. Sure, but there are multiple problems in your problem statement. I agree with about one of them (to an extent :-) -- the double signalling. It's all about tradeoffs. As long as things work to some extent, we can accept a bit more overhead, a bit more unoptimized connectivity, etc. -- if the costs of solving those issues would have costs of its own. > > I'm not sure what you're referring to, but IMHO we should > > try to avoid > > doing EITHER: > > > > 1) short-term fixes to solve long-term problems, or > > 2) long-term fixes to solve short-term problems. > > > > 2) is probably even worse (and what I'm fearing here), > > because if we come > > across with 1), and the fix proves to be too short-term, we > > can just try > > again. This of course has its pitfalls too. > > => I'm not going to anticipate how long a solution will last > because I know that people who do that are usually wrong. > So, if you want to answer those questions I think you > should say what is "short term problem", "long term problem", > "short term fixes" and "long term fixes". > > I think this is a can of worms.... I don't think we'll go anywhere > trying to answer those questions. Worse, we won't > get consensus on those definitions (just call it a hunch ;) ). Yes, these can be problematic :-). But if we can restrict the problems somewhat, it may be easier to get a feeling about this. First we just have to figure out the exact scenarios where these apply to. -- 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 Aug 24 08:00: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 IAA03690 for ; Sun, 24 Aug 2003 08:00:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qtX3-000Hsp-BM for v6ops-data@psg.com; Sun, 24 Aug 2003 11:59:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19qtWW-000Hdz-2A for v6ops@ops.ietf.org; Sun, 24 Aug 2003 11:59:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7OBw3H01241; Sun, 24 Aug 2003 14:58:03 +0300 Date: Sun, 24 Aug 2003 14:58:02 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: Comments on draft-tsirtsis-dsmip-problem-01.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922C9E@ftmail.lab.flarion.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, I did a quick pass on the dsmip-problem draft. I tried to concentrate only on a couple of specific sections. There are a lot of issues in the others as well, but it isn't worth the time to argue about the rest at this point. To summarize: - most of the problems are not important or portrayed with specific assumptions - the most important remaining issue seems to be duplicate hand-off signalling - it might be best to change this to a requirements/goals document and give better coverage to other features which speak against any changes like these - I think you have to spell out your assumptions more explictly - I think you have to consider what your aim is in more detail: do you want bidirectional tunneling through the HA or do you want some more advanced mobility as well (the latter is probably highly problematic using your proposals, consider e.g. return routability checks) - based on this, I do not think the problem statement can be taken seriously, and I would recommend not starting any activity based on it. I'll just argue the problem description and it's subsections. 2.0 Problem description Mobile IP (v4 and v6) uses a signaling protocol (Registration requests in MIPv4 and BUs in MIPv6) to set up tunnels between two end points. At the moment MIP "signaling" is tightly coupled with the "address family (i.e. IPv4 or IPv6)" used in the connections that it attempts to manipulate. There are no fundamental technical reasons for such coupling. ==> the last statement is wrong. The fundamental technical reason is that MIPv4 and MIPv6 are *two* different protocols. If Mobile IP were viewed as a tunnel setup protocol, it should be able to setup IP in IP tunnels, independently of the IP version used in the outer and inner headers. ==> this is a very flawed analogy. MIP is *not* a tunnel setup protocol. If you wanted a tunnel setup protocol, you would not need MIP in the first place, just dynamic VPN mechanism. Other protocols, for example SIP, are able to use either IPv4 or IPv6 based signaling plane to manipulate IPv4 AND IPv6 bearers. ==> there is a fundamental difference there. SIP was architected *from the start* to deal with two protocols (AFAIK). As I stated, if we want to do it, something like HIP is possible a right direction (not necessarily THE right direction, though). ==> A more correct analogies would be plugging H.323 interoperability to SIP and SIP interoperability to H.323. Architecturally, this seems like a very similar approach.. A mobile node using both Mobile IPv4 and Mobile IPv6 to roam within the Internet will require the following: - Both implementations available in the mobile node ==> analogy: Both IPv4 and IPv6 must be implemented in the mobile node, and it is a problem. - The network operator needs to ensure that the home agent supports both protocols or that it has two separate Home Agents supporting the two protocols, each requiring its own management. ==> analogy: The network operator must manage both DHCPv4 and stateless address autoconfiguration (or more closely, DHCPv6) and this is a problem. - Double the amount of configuration in the mobile node and the home agent (e.g. security associations). ==> analogy: applications must manage the access controls (like IP addresses, etc.) for both IPv4 and IPv6 nodes, and this is a problem. - Local network optimizations for handovers will also need to be duplicated. ==> roughly ok, even though I don't really think it's a major problem myself. ==> See? Even though the analogies are not 100% accurate, you are describing issues inherent to dual-stack deployment (which are not considered serious problems in general, but in all fairness, there hasn't been much discussion on this in v6ops), and extrapolating them to be serious Mobile IP problems which must be addressed. Want to run both IPv4 and IPv6 but any new configuration is unacceptable? Tough. 2.1. Implementation burdens As mentioned above, a dual stack mobile node would require both mobility protocols implemented to roam seamlessly within the Internet. Clearly this will add implementation efforts, which we argue are not necessary. ==> implementations are already there; the same argument as IPv4/6 dual-stack deployment. 2.2. Operational burdens As mentioned earlier, deploying both protocols will require managing both protocols in the mobile node and the home agent. This adds significant operational issues for the network operator. It would certainly require the network operator to have deep knowledge in both protocols. This might add a significant cost for deployment that an operator cannot justify due to the lack of substantial gains. ==> "significant" --> these certainly aren't ==> "deep knowledge" --> operators generally don't need such deep knowledge, the basics are enough. The experts are another subject, but they already know both protocols and that's no news. 2.3. Mobility management inefficiencies ==> I can kind of see the point in some of the issues of mobility management. 2.4. The impossibility of maintaining connectivity A final point to consider is that even if both mobility protocols are supported by a mobile node seamless connectivity would not in fact be guarantied since that also depends on the IPv4/IPv6 capabilities of the networks the mobile is visiting i.e.: a dual stack node attempting to connect via a IPv4 only network would not be able to maintain connectivity of its IPv6 applications and vice versa. ==> this is totally incorrect as shown many, many times; you are just assuming that the mobile node could not run a transition mechanism on its own to enable IP protocol access. -- 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 Aug 24 08:04: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 IAA03747 for ; Sun, 24 Aug 2003 08:04:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qtb8-000IyA-O3 for v6ops-data@psg.com; Sun, 24 Aug 2003 12:03:54 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19qtac-000Ipt-W8 for v6ops@ops.ietf.org; Sun, 24 Aug 2003 12:03:23 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 24 Aug 2003 08:03:18 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CAF@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "'Alain Durand'" , "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: Sun, 24 Aug 2003 08:03:11 -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 > > George and I think it's worth solving because of the > > problems listed in the draft. If you try to deploy > > MNs on a large scale, using a wireless network, the > > problems in the draft become quite serious. There > > are two ways to avoid them with current standards: > > > > - Avoid IPv6 deployment > > - Move to IPv6-only networks > > > > The latter is not going to happen this decade. I'm > > sure we don't want the first bullet to happen either. > > The draft lists several problems, some of which I don't > agree with, some > of which I think can be solved with other approaches, and > some of which I > agree may be potential issues but which I don't see really > huge problems. > > I think these separate problems have to be teased out from > one big lump > leading to your conclusion. > > > > I guess I don't understand the problem, then. > > > > => I'm happy to help. If you can pick on specific sections > > in the problem statement draft that might help us > > move forward. > > I had a closer look at parts of it, and I'll be sending some > comments > shortly. => I'll look forward to your specific comments then. > > If the MN generates a 6-to-4 address then an IPv6 node contacted > > it using that address after the MN has left the home network, how > > does the HA forward those IPv6 packets to the MN? > > Easily. Note that those are *NOT* IPv6 packets. They're > proto-41 IPv4 > packets :-). > > It's double encapsulation, but hey.. it works and is trivial! => As I described earlier, double encapsulation is one option, there are others. The aim is not necessarily to provide a trivial solution at all cost (it's obviously your aim but not mine). If you read the mipv4 solution (draft-tsirtsis) you can see that it's possible, but there is a need for a more BW-efficient solution. > > > The same goes for traffic sent from the MN using > 2002:HADDR_v4::/48. > > Works equally well, as above. => No it doesn't. How does the MN reverse tunnel to the HA? MIPv4 does not assume reverse tunnelling. > > => You could replace 2002:.... with any other prefix because as > > I explained above it doesn't do anything for us. > > Yes, it fixes the problem altogether, see above. => Not the reverse part. > > It doesn't setup > > a tunnel between the MN and the HA in any way. > > For some weird reason, you keep having this fixation that > tunnel MUST BE > between MN and the HA. There is *NO* reason for that. The > tunnel can be > to whatever box in the network, as long as it provides IPv6 support. > > However, it could very easily be the HA too, just by being > the 6to4 relay > or the (somehow) configured tunnel's endpoint. But that's > certainly *not* > a requirement. => I don't understand how you assume that 6-to-4 provides bidirectional communication... This is why I think the HA is a good TEP because it's there, doesn't assume 6-to-4 relays, and doesn't assume that the CNs have 6-to-4 addresses. > > if you're saying that you could have a configured tunnel inside > > the HA to tunnel IPv6 to the MN's IPv4 _home_ address which then > > gets tunneled to the MN's IPv4 care-of address (the MIP part) > > then yes this is possible and it is explained in the draft > > that George announced on the list. > > Yes, that's exactly the possibility. It needs to go to the problem > statement (if you keep considering there being a problem) to > be taken > seriously. => I don't think the problem statement should consider solutions. In fact, perhaps we need to change the recommendations section to indicate that a gradual transition based on existing standards is needed without being more specific. > > > But there is a more > > BW effifcient scenario that would require some assistance > > from the FA. Both options are explained in the solutions > > draft (MIPv4 one) that George sent to the MIP mailing list. > > Bandwidth efficiency is just ONE trade-off here. => Ah, one important trade-off! If you ask anyone deploying or working with a WWAN how important BW is, they'll choose it over simplicity anytime. What I'd > like is that > the problem statement would list all the issues so that the > readers could > have better idea of the tradeoffs. => I'll look forward to specific comments ;) > > Actually, maybe the document should be called "goals" or > "requirements", => If it were a requirements doc we would call it so, but we were asked to describe the problem, that's why it's a problem statement. > not a problem statement, because "problem statement" doesn't > give enough > coverage on other tradeoffs of finding a solution. => It's not meant to. It's a problem statement. By all means, others are welcome to look into requirements ...etc > > => This is a binary transition mechanism :) > > You're basically saying that "today V4 is used, tomorrow > > we will have dual stack networks and we can retire MIPv4." > > Hmmm...not that simple unfortunately because there is more > > than one network and there is a different "tomorrow" for each > > of those networks. So what is going to happen is that we will > > have v4-only and dual stack networks at the same time. > > > > Also, we can't just "retire" MIPv4 unless there is a flag > > day. So we can phase it out. From the two solutions drafts > > that we have (second one coming soon), you could conclude > > that we assumed the following scenario: > > > > 1. Use MIPv4 (present) > > 2. Extended MIPv4 to allow for IPv6 home address (near future) > > 3. Extended MIPv6 to allow for v4 home addresses (future) > > > > 2) and 3) can coexist (i.e. in different MNs). > > That's a more likely transition IMHO. > > Sure, but there are multiple problems in your problem > statement. I agree > with about one of them (to an extent :-) -- the double signalling. > > It's all about tradeoffs. As long as things work to some > extent, we can > accept a bit more overhead, a bit more unoptimized > connectivity, etc. => Who is "we"? Different operators have different requirements for different types of networks. Optimised signalling over a wireless link is crucial. Optimised mobility is not an option, it's a must for any serious wireless operator. Minimal overhead is also a must and won't be tolerated by a WWAN operator. Hesham From owner-v6ops@ops.ietf.org Sun Aug 24 09:03: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 JAA05265 for ; Sun, 24 Aug 2003 09:03:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19quUC-000AgT-HO for v6ops-data@psg.com; Sun, 24 Aug 2003 13:00:48 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19quTd-000Adu-OH for v6ops@ops.ietf.org; Sun, 24 Aug 2003 13:00:15 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 24 Aug 2003 09:00:12 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CB0@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: RE: Comments on draft-tsirtsis-dsmip-problem-01.txt Date: Sun, 24 Aug 2003 09:00:06 -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 Pekka, Thanks for the specific commments. Answers below (I don't have comments on the ommitted text): > I did a quick pass on the dsmip-problem draft. > > I tried to concentrate only on a couple of specific > sections. There are a > lot of issues in the others as well, but it isn't worth the > time to argue > about the rest at this point. > > To summarize: > - most of the problems are not important or portrayed with specific > assumptions > - the most important remaining issue seems to be duplicate hand-off > signalling > - it might be best to change this to a requirements/goals > document and > give better coverage to other features which speak against > any changes > like these > - I think you have to spell out your assumptions more explictly > - I think you have to consider what your aim is in more > detail: do you > want bidirectional tunneling through the HA or do you want some more > advanced mobility as well (the latter is probably highly > problematic using > your proposals, consider e.g. return routability checks) > - based on this, I do not think the problem statement can be taken > seriously, and I would recommend not starting any activity > based on it. => I can't argue against any of the points above...too vague for me. I'll answer the specific comments below > > I'll just argue the problem description and it's subsections. > > 2.0 Problem description > > Mobile IP (v4 and v6) uses a signaling protocol (Registration > requests in MIPv4 and BUs in MIPv6) to set up tunnels > between two end > points. At the moment MIP "signaling" is tightly coupled with the > "address family (i.e. IPv4 or IPv6)" used in the > connections that it > attempts to manipulate. There are no fundamental > technical reasons > for such coupling. > > ==> the last statement is wrong. The fundamental technical > reason is that > MIPv4 and MIPv6 are *two* different protocols. => And what is the fundamental reason for having those 2?? See draft-soliman-v4v6-mipv6 for example > > If Mobile IP were viewed as a > tunnel setup > protocol, it should be able to setup IP in IP tunnels, > independently > of the IP version used in the outer and inner headers. > > ==> this is a very flawed analogy. MIP is *not* a tunnel > setup protocol. => That's news to me. How do you describe the relationship between the MN and the HA? What is the relationship between the MN and CN in MIPv6? I remember a couple of years ago draft-nordmark-foresight.. proposed that IP in IP is used between the MN and CN instead of the current spec, no technical opposition was given. So what do you call it if it's not setting up tunnels? > If you wanted a tunnel setup protocol, you would not need > MIP in the first > place, just dynamic VPN mechanism. => Like what ?? MIP sets up tunnels dynamically between the MN and HA (v4 and v6) and any-to-any (MIPv6 RO). > Other > protocols, for example SIP, are able to use either IPv4 > or IPv6 based > signaling plane to manipulate IPv4 AND IPv6 bearers. > > ==> there is a fundamental difference there. SIP was > architected *from > the start* to deal with two protocols (AFAIK). => So because it was designed like that from the start you are arguing that it's not analogous? The only difference here is foresight on the SIP designers' behalf and the ease of doing so on the application layer. I wish we had that foresight in MIPv6, it would have saved us arguing about it now. As I stated, > if we want to > do it, something like HIP is possible a right direction (not > necessarily => I'm confused, so you do agree that one protocol can do the job? > A mobile node using both Mobile IPv4 and Mobile IPv6 to > roam within > the Internet will require the following: > > - Both implementations available in the mobile node > > ==> analogy: Both IPv4 and IPv6 must be implemented in the > mobile node, > and it is a problem. => But we argue that you don't need both MIPv4 and MIPv6. > > - The network operator needs to ensure that the home > agent supports > both protocols or that it has two separate Home Agents > supporting > the two protocols, each requiring its own management. > > ==> analogy: The network operator must manage both DHCPv4 > and stateless > address autoconfiguration (or more closely, DHCPv6) and this > is a problem. => Yes it is, different WG. But clearly there are no significant performance issues here compared to mobility. > > - Double the amount of configuration in the mobile node > and the home > agent (e.g. security associations). > > ==> analogy: applications must manage the access controls (like IP > addresses, etc.) for both IPv4 and IPv6 nodes, and this is a problem. => Finding analogies does not mean that there is no problem and doesn't tell me whethere you agree/understand that there are problems and how serious. > ==> See? Even though the analogies are not 100% accurate, you are > describing issues inherent to dual-stack deployment (which are not > considered serious problems in general, but in all fairness, > there hasn't > been much discussion on this in v6ops), and extrapolating them to be > serious Mobile IP problems which must be addressed. Want to > run both IPv4 > and IPv6 but any new configuration is unacceptable? Tough. => Tough for v6 I suppose... Who said _any_ new configuration is not acceptable? We are saying that there are significant performance and service quality issues involved. And the only answer I'm getting from you is a dismissive "not a significant problem". Even if that's your opinion I don't know what scale is used to decide what is significant and what's not. In the cases I'm talking about these performance and service quality problems are very significant by a wireless operator's standard. > > 2.1. Implementation burdens > > As mentioned above, a dual stack mobile node would require both > mobility protocols implemented to roam seamlessly within the > Internet. Clearly this will add implementation efforts, which we > argue are not necessary. > > ==> implementations are already there; the same argument as IPv4/6 > dual-stack deployment. => Which implementations ?? Have you seen commercial MIPv4 running on windows? how widely deployed is it? > 2.4. The impossibility of maintaining connectivity > > A final point to consider is that even if both mobility > protocols are > supported by a mobile node seamless connectivity would > not in fact be > guarantied since that also depends on the IPv4/IPv6 > capabilities of > the networks the mobile is visiting i.e.: a dual stack node > attempting to connect via a IPv4 only network would not > be able to > maintain connectivity of its IPv6 applications and vice versa. > > ==> this is totally incorrect as shown many, many times; you > are just > assuming that the mobile node could not run a transition > mechanism on its > own to enable IP protocol access. => You have not shown that at all. the solution you showed: - Lacks Bidirectionality (6-to-4). - BW inefficient - Only runs with MIPv4 (or at least you didn't explain it for MIPv6). Hesham From owner-v6ops@ops.ietf.org Sun Aug 24 10:09: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 KAA07345 for ; Sun, 24 Aug 2003 10:09:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qvWH-0003WF-Dc for v6ops-data@psg.com; Sun, 24 Aug 2003 14:07:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19qvUz-00035b-2v for v6ops@ops.ietf.org; Sun, 24 Aug 2003 14:05:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7OE4TB02467; Sun, 24 Aug 2003 17:04:29 +0300 Date: Sun, 24 Aug 2003 17:04:28 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922CAF@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 Sun, 24 Aug 2003, Soliman Hesham wrote: > > > If the MN generates a 6-to-4 address then an IPv6 node contacted > > > it using that address after the MN has left the home network, how > > > does the HA forward those IPv6 packets to the MN? > > > > Easily. Note that those are *NOT* IPv6 packets. They're > > proto-41 IPv4 > > packets :-). > > > > It's double encapsulation, but hey.. it works and is trivial! > > => As I described earlier, double encapsulation is one > option, there are others. The aim is not necessarily > to provide a trivial solution at all cost (it's obviously > your aim but not mine). If you read the mipv4 solution > (draft-tsirtsis) you can see that it's possible, but there > is a need for a more BW-efficient solution. Obviously, the problem statement should elaborate why double encapsulation does not solve the problem. > > > The same goes for traffic sent from the MN using > > 2002:HADDR_v4::/48. > > > > Works equally well, as above. > > => No it doesn't. How does the MN reverse tunnel to the > HA? MIPv4 does not assume reverse tunnelling. It has worked just fine for me w/ Dynamics (http://www.cs.hut.fi/Research/Dynamics/), AFAIR. Are you saying that mobile nodes do not tunnel back to the HA themselves, just (optionally) rely on the FA's doing it? > > > It doesn't setup > > > a tunnel between the MN and the HA in any way. > > > > For some weird reason, you keep having this fixation that > > tunnel MUST BE > > between MN and the HA. There is *NO* reason for that. The > > tunnel can be > > to whatever box in the network, as long as it provides IPv6 support. > > > > However, it could very easily be the HA too, just by being > > the 6to4 relay > > or the (somehow) configured tunnel's endpoint. But that's > > certainly *not* > > a requirement. > > => I don't understand how you assume that 6-to-4 provides > bidirectional communication... This is why I think the HA > is a good TEP because it's there, doesn't assume 6-to-4 > relays, and doesn't assume that the CNs have 6-to-4 addresses. If you're worried about bidir communication, all you have to do is to give the HA also a 6to4 address: then 6to4 gives you bidirectionality as well. > > > if you're saying that you could have a configured tunnel inside > > > the HA to tunnel IPv6 to the MN's IPv4 _home_ address which then > > > gets tunneled to the MN's IPv4 care-of address (the MIP part) > > > then yes this is possible and it is explained in the draft > > > that George announced on the list. > > > > Yes, that's exactly the possibility. It needs to go to the problem > > statement (if you keep considering there being a problem) to > > be taken > > seriously. > > => I don't think the problem statement should consider solutions. > In fact, perhaps we need to change the recommendations section > to indicate that a gradual transition based on existing standards > is needed without being more specific. You don't have to consider solutions. What I'm saying is that it would be useful to try to phrase the _problem statement_ so that it excludes certain solutions you do not consider appropriate (instead of just silently rejecting them). I.e., this seems to indicate that the problem statement is not worded as well as it could be. > > > But there is a more > > > BW effifcient scenario that would require some assistance > > > from the FA. Both options are explained in the solutions > > > draft (MIPv4 one) that George sent to the MIP mailing list. > > > > Bandwidth efficiency is just ONE trade-off here. > > => Ah, one important trade-off! If you ask anyone deploying > or working with a WWAN how important BW is, they'll > choose it over simplicity anytime. You may have different WWAN's in mind, but I disagree. For example 802.11 deployments have ample capacity, and it is much more important to have simple solutions which require no upgrades to network components or mobile nodes. > > Actually, maybe the document should be called "goals" or > > "requirements", > > => If it were a requirements doc we would call it so, but > we were asked to describe the problem, that's why it's > a problem statement. Requirements can also describe a problem, but additionally those give a better idea how to evaluate solutions to the problem. -- 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 Aug 24 10:17: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 KAA08095 for ; Sun, 24 Aug 2003 10:17:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qvg1-0005rO-4D for v6ops-data@psg.com; Sun, 24 Aug 2003 14:17:05 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19qveZ-0005cK-Hw for v6ops@ops.ietf.org; Sun, 24 Aug 2003 14:15:35 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 24 Aug 2003 10:15:34 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CB1@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "'Alain Durand'" , "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: Sun, 24 Aug 2003 10:15:28 -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 > > => As I described earlier, double encapsulation is one > > option, there are others. The aim is not necessarily > > to provide a trivial solution at all cost (it's obviously > > your aim but not mine). If you read the mipv4 solution > > (draft-tsirtsis) you can see that it's possible, but there > > is a need for a more BW-efficient solution. > > Obviously, the problem statement should elaborate why double > encapsulation > does not solve the problem. => Reverse tunnelling and BW efficiency. > > > > The same goes for traffic sent from the MN using > > > 2002:HADDR_v4::/48. > > > > > > Works equally well, as above. > > > > => No it doesn't. How does the MN reverse tunnel to the > > HA? MIPv4 does not assume reverse tunnelling. > > It has worked just fine for me w/ Dynamics > (http://www.cs.hut.fi/Research/Dynamics/), AFAIR. > > Are you saying that mobile nodes do not tunnel back to the > HA themselves, > just (optionally) rely on the FA's doing it? => Yes. I don't know what you did with the Dynamics SW. > > => I don't understand how you assume that 6-to-4 provides > > bidirectional communication... This is why I think the HA > > is a good TEP because it's there, doesn't assume 6-to-4 > > relays, and doesn't assume that the CNs have 6-to-4 addresses. > > If you're worried about bidir communication, all you have to > do is to give > the HA also a 6to4 address: then 6to4 gives you > bidirectionality as well. => what makes the MN reverse tunnel a packet sent to an IPv6 address to an IPv4 address? > > > > But there is a more > > > > BW effifcient scenario that would require some assistance > > > > from the FA. Both options are explained in the solutions > > > > draft (MIPv4 one) that George sent to the MIP mailing list. > > > > > > Bandwidth efficiency is just ONE trade-off here. > > > > => Ah, one important trade-off! If you ask anyone deploying > > or working with a WWAN how important BW is, they'll > > choose it over simplicity anytime. > > You may have different WWAN's in mind, but I disagree. For > example 802.11 => I said WWAN not WLAN. Hesham From owner-v6ops@ops.ietf.org Sun Aug 24 11: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 LAA09266 for ; Sun, 24 Aug 2003 11:01:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qwKl-000HDV-5A for v6ops-data@psg.com; Sun, 24 Aug 2003 14:59:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19qwKC-000Gyd-DB for v6ops@ops.ietf.org; Sun, 24 Aug 2003 14:58:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7OEvRb02895; Sun, 24 Aug 2003 17:57:27 +0300 Date: Sun, 24 Aug 2003 17:57:26 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: Comments on draft-tsirtsis-dsmip-problem-01.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922CB0@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 Sun, 24 Aug 2003, Soliman Hesham wrote: > > I'll just argue the problem description and it's subsections. > > > > 2.0 Problem description > > > > Mobile IP (v4 and v6) uses a signaling protocol (Registration > > requests in MIPv4 and BUs in MIPv6) to set up tunnels > > between two end > > points. At the moment MIP "signaling" is tightly coupled with the > > "address family (i.e. IPv4 or IPv6)" used in the > > connections that it > > attempts to manipulate. There are no fundamental > > technical reasons > > for such coupling. > > > > ==> the last statement is wrong. The fundamental technical > > reason is that > > MIPv4 and MIPv6 are *two* different protocols. > > => And what is the fundamental reason for having those 2?? Probably that MIPv4 was developed before they could seriously consider IPv6? If we were designing Mobile IP *today*, we'd probably intergrate the two versions somehow. But we aren't, what's done is done. The possiblity that if we would now design it differently doesn't automatically mean that it would be useful to to try to enhance the two protocols or re-engineer them to work together. > > tunnel setup > > protocol, it should be able to setup IP in IP tunnels, > > independently > > of the IP version used in the outer and inner headers. > > > > ==> this is a very flawed analogy. MIP is *not* a tunnel > > setup protocol. > > => That's news to me. How do you describe the relationship between > the MN and the HA? An IPsec tunnel. > What is the relationship between the > MN and CN in MIPv6? Direct communication between two nodes (sharing the same IP protocol), if route optimization is used. [...] > So what do you call it if it's not setting up tunnels? Maybe "method for enabling connection survivability for the IP protocol". > I remember a couple of years ago draft-nordmark-foresight.. (it was hindsight, a year or so ago) > proposed that IP in IP is used between the MN and CN instead > of the current spec, no technical opposition was given. I do not think it was reviewed that much (I don't recall many comments), but as your remember, it was _hindsight_. If we could go back to when Mobile IP(v6) was designed, we could certainly do things differently but that doesn't mean we should (r)evolve Mobile IP to the same outcome as it would be if we designed it from scratch. > > If you wanted a tunnel setup protocol, you would not need > > MIP in the first > > place, just dynamic VPN mechanism. > > => Like what ?? MIP sets up tunnels dynamically between the > MN and HA (v4 and v6) and any-to-any (MIPv6 RO). If you just wanted MN<->HA communication, all you would need is a VPN which updates your care-of address to the HA regularly. RO is the thing that sets it apart. I would not call MIPv6 RO a tunnel, and it is not parcticularly useful in this context as the transport is heavily IPv6-specific. > > Other > > protocols, for example SIP, are able to use either IPv4 > > or IPv6 based > > signaling plane to manipulate IPv4 AND IPv6 bearers. > > > > ==> there is a fundamental difference there. SIP was > > architected *from > > the start* to deal with two protocols (AFAIK). > > => So because it was designed like that from the start > you are arguing that it's not analogous? The only difference > here is foresight on the SIP designers' behalf and the ease > of doing so on the application layer. Yes, we don't have two entirely differently specified protocols, SIPv4 and SIPv6 which we would like to merge to some extent. Note that it's just not about the address family used, the differences in the design and the details are significantly different with MIPv4 and MIPv6. > I wish we had that foresight in MIPv6, it would have saved > us arguing about it now. That would not be enough, we'd then be arguing about MIPv4 -- we would have needed the foresight with MIPv4 too :-) > As I stated, > > if we want to > > do it, something like HIP is possible a right direction (not > > necessarily > > => I'm confused, so you do agree that one protocol can do the job? One protocol, designed from scratch, could do the job. > > A mobile node using both Mobile IPv4 and Mobile IPv6 to > > roam within > > the Internet will require the following: > > > > - Both implementations available in the mobile node > > > > ==> analogy: Both IPv4 and IPv6 must be implemented in the > > mobile node, > > and it is a problem. > > => But we argue that you don't need both MIPv4 and MIPv6. Yep, but another argument might be that it would be better to have them separate because they were designed to be two separate protocols, and that they are in fact quite different. > > - The network operator needs to ensure that the home > > agent supports > > both protocols or that it has two separate Home Agents > > supporting > > the two protocols, each requiring its own management. > > > > ==> analogy: The network operator must manage both DHCPv4 > > and stateless > > address autoconfiguration (or more closely, DHCPv6) and this > > is a problem. > > => Yes it is, different WG. But clearly there are no > significant performance issues here compared to mobility. We were discussing menagement and operations here, and I fail to see the difference in this specific case. > > ==> See? Even though the analogies are not 100% accurate, you are > > describing issues inherent to dual-stack deployment (which are not > > considered serious problems in general, but in all fairness, > > there hasn't > > been much discussion on this in v6ops), and extrapolating them to be > > serious Mobile IP problems which must be addressed. Want to > > run both IPv4 > > and IPv6 but any new configuration is unacceptable? Tough. > > => Tough for v6 I suppose... Sure, that's probably an indicator that they do not care about v6 all that much in the first place. > Who said _any_ new configuration is not acceptable? > We are saying that there are significant performance > and service quality issues involved. And the only > answer I'm getting from you is a dismissive > "not a significant problem". You do not seem to spell out those problems clearly in the problem statement. > > 2.1. Implementation burdens > > > > As mentioned above, a dual stack mobile node would require both > > mobility protocols implemented to roam seamlessly within the > > Internet. Clearly this will add implementation efforts, which we > > argue are not necessary. > > > > ==> implementations are already there; the same argument as IPv4/6 > > dual-stack deployment. > > => Which implementations ?? Have you seen commercial MIPv4 running > on windows? how widely deployed is it? Right. That's the other point: if there has been no interest to implement and deploy MIPv4, why should we care to add the support in MIPv6? Isn't this a clear indication that a) MIPv4 isn't sufficiently deployed to be worth implementing in the majority systems, b) MIPv4 may be technically flawed to be interesting (FA requirements) for general deployment, and c) MIPv6 may be the much better direction all-in-all? IMHO, this seems to just prove that there is no MIPv4 deployment except perhaps in very restricted scenarios w/ very small set of hosts. And why then MIPv6 would have to care? > > 2.4. The impossibility of maintaining connectivity > > > > A final point to consider is that even if both mobility > > protocols are > > supported by a mobile node seamless connectivity would > > not in fact be > > guarantied since that also depends on the IPv4/IPv6 > > capabilities of > > the networks the mobile is visiting i.e.: a dual stack node > > attempting to connect via a IPv4 only network would not > > be able to > > maintain connectivity of its IPv6 applications and vice versa. > > > > ==> this is totally incorrect as shown many, many times; you > > are just > > assuming that the mobile node could not run a transition > > mechanism on its > > own to enable IP protocol access. > > => You have not shown that at all. the solution you showed: > > - Lacks Bidirectionality (6-to-4). By adding 6to4 on HA, you should be able to obtain that. > - BW inefficient Just one tradeoff, it's a transition mechanism after all. > - Only runs with MIPv4 (or at least you didn't explain it > for MIPv6). I'm not sure if I understood your point. Did you mean that I didn't describe how to enable MIPv4 mobility in an IPv6-only network? Seems like a non-problem to me, due to how IPv6 is deployed (nodes that don't cope with MIPv6 are retired before IPv6-only networks are deployed). -- 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 Aug 24 11:43: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 LAA10433 for ; Sun, 24 Aug 2003 11:43:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19qwzS-00032H-U4 for v6ops-data@psg.com; Sun, 24 Aug 2003 15:41:14 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19qwyw-0002tK-G8 for v6ops@ops.ietf.org; Sun, 24 Aug 2003 15:40:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7OFaJX03268; Sun, 24 Aug 2003 18:36:19 +0300 Date: Sun, 24 Aug 2003 18:36:18 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922CB1@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 Sun, 24 Aug 2003, Soliman Hesham wrote: > > > => No it doesn't. How does the MN reverse tunnel to the > > > HA? MIPv4 does not assume reverse tunnelling. > > > > It has worked just fine for me w/ Dynamics > > (http://www.cs.hut.fi/Research/Dynamics/), AFAIR. > > > > Are you saying that mobile nodes do not tunnel back to the > > HA themselves, > > just (optionally) rely on the FA's doing it? > > => Yes. I don't know what you did with > the Dynamics SW. RFC3024 and MIPv4 spec at: Home agents MUST decapsulate packets addressed to themselves, sent by a mobile node for the purpose of maintaining location privacy, as described in Section 5.5. This feature is also required for support of reverse tunneling [27]. I don't think the non-reverse tunneled (from MN) scenario even worked here. So, it seems pretty reasonable to expect many (most?) MN's implement tunneling back to HA .. if not for any other reason than being able to operate in networks where there are no foreign agents. > > > => I don't understand how you assume that 6-to-4 provides > > > bidirectional communication... This is why I think the HA > > > is a good TEP because it's there, doesn't assume 6-to-4 > > > relays, and doesn't assume that the CNs have 6-to-4 addresses. > > > > If you're worried about bidir communication, all you have to > > do is to give > > the HA also a 6to4 address: then 6to4 gives you > > bidirectionality as well. > > => what makes the MN reverse tunnel a packet sent to an > IPv6 address to an IPv4 address? The enabling of 6to4 pseudo-interface, for example? (i.e., enabling the pseudo-interface, resulting in the 2002::/16 route). > > > > > But there is a more > > > > > BW effifcient scenario that would require some assistance > > > > > from the FA. Both options are explained in the solutions > > > > > draft (MIPv4 one) that George sent to the MIP mailing list. > > > > > > > > Bandwidth efficiency is just ONE trade-off here. > > > > > > => Ah, one important trade-off! If you ask anyone deploying > > > or working with a WWAN how important BW is, they'll > > > choose it over simplicity anytime. > > > > You may have different WWAN's in mind, but I disagree. For > > example 802.11 > > => I said WWAN not WLAN. I'm not familiar with the term but I assume you mean something like GSM networks. -- 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 Aug 24 21:12: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 VAA04436 for ; Sun, 24 Aug 2003 21:12:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19r5rb-000IfL-QI for v6ops-data@psg.com; Mon, 25 Aug 2003 01:09:43 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19r5rZ-000If4-JK for v6ops@ops.ietf.org; Mon, 25 Aug 2003 01:09:41 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 24 Aug 2003 21:09:40 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CB2@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "'Alain Durand'" , "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: Sun, 24 Aug 2003 21:09:33 -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 > On Sun, 24 Aug 2003, Soliman Hesham wrote: > > > > => No it doesn't. How does the MN reverse tunnel to the > > > > HA? MIPv4 does not assume reverse tunnelling. > > > > > > It has worked just fine for me w/ Dynamics > > > (http://www.cs.hut.fi/Research/Dynamics/), AFAIR. > > > > > > Are you saying that mobile nodes do not tunnel back to the > > > HA themselves, > > > just (optionally) rely on the FA's doing it? > > > > => Yes. I don't know what you did with > > the Dynamics SW. > > RFC3024 and MIPv4 spec at: => This is not relevant, this is for topologically correct addresses, which is not the case in most MIPv4 deployments. Normally the FA would reverse tunnel. > > So, it seems pretty reasonable to expect many (most?) => More like "none" than "most". Even if they implement it, the encapsulation is normally done in the FA otherwise the local domain's ingress filter will drop the packets. MN's implement > tunneling back to HA .. if not for any other reason than > being able to > operate in networks where there are no foreign agents. => It's not required for operating in such networks. Please see RFC 3220 > > > > => what makes the MN reverse tunnel a packet sent to an > > IPv6 address to an IPv4 address? > > The enabling of 6to4 pseudo-interface, for example? (i.e., > enabling the > pseudo-interface, resulting in the 2002::/16 route). => see above... > > => I said WWAN not WLAN. > > I'm not familiar with the term but I assume you mean > something like GSM > networks. => Wireless Wide Area Networks, cellular networks. GSM is one example. Hesham From owner-v6ops@ops.ietf.org Sun Aug 24 21:28: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 VAA05067 for ; Sun, 24 Aug 2003 21:28:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19r69E-000O7S-0L for v6ops-data@psg.com; Mon, 25 Aug 2003 01:27:56 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19r699-000O5x-VT for v6ops@ops.ietf.org; Mon, 25 Aug 2003 01:27:52 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Sun, 24 Aug 2003 21:27:51 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CB4@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , v6ops@ops.ietf.org Subject: RE: Comments on draft-tsirtsis-dsmip-problem-01.txt Date: Sun, 24 Aug 2003 21:27: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=-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 last statement is wrong. The fundamental technical > > > reason is that > > > MIPv4 and MIPv6 are *two* different protocols. > > > > => And what is the fundamental reason for having those 2?? > > Probably that MIPv4 was developed before they could > seriously consider > IPv6? => In other words there is no fundamental reason. > > If we were designing Mobile IP *today*, we'd probably > intergrate the two > versions somehow. But we aren't, what's done is done. The > possiblity > that if we would now design it differently doesn't > automatically mean that > it would be useful to to try to enhance the two protocols or > re-engineer > them to work together. => Are these comments in the context of the two drafts or in general? I think they can be extended with very little work as we showed in the drafts. Others might have even simpler ways. > > > ==> this is a very flawed analogy. MIP is *not* a tunnel > > > setup protocol. > > > > => That's news to me. How do you describe the relationship between > > the MN and the HA? > > An IPsec tunnel. => This is factually wrong for MIPv4 and MIPv6. Neither has any requirement for IPsec protection of the tunnel. It's an IP in IP tunnel! > > > What is the relationship between the > > MN and CN in MIPv6? > > Direct communication between two nodes (sharing the same IP > protocol), if > route optimization is used. => Again, factually wrong. RO in MIPv6 is effectively a tunnelling mechanism that instead of using IP in IP, uses RH and HAO to save bits. This was discussed many years ago and discussed again when Erik published his draft. > > > ==> there is a fundamental difference there. SIP was > > > architected *from > > > the start* to deal with two protocols (AFAIK). > > > > => So because it was designed like that from the start > > you are arguing that it's not analogous? The only difference > > here is foresight on the SIP designers' behalf and the ease > > of doing so on the application layer. > > Yes, we don't have two entirely differently specified > protocols, SIPv4 and > SIPv6 which we would like to merge to some extent. > > Note that it's just not about the address family used, the > differences in > the design and the details are significantly different with > MIPv4 and > MIPv6. => Not as far as the MN-HA relationship is concerned. That part is very similar. RO is the only real difference IMO. RO is not impacted in our proposals. > > As I stated, > > > if we want to > > > do it, something like HIP is possible a right direction (not > > > necessarily > > > > => I'm confused, so you do agree that one protocol can do the job? > > One protocol, designed from scratch, could do the job. => I think this is becoming a bit argumentative. You do acknowledge that one protocol can do the job and I've shown you examples of how to do it using either MIPv4 and MIPv6. > > => But we argue that you don't need both MIPv4 and MIPv6. > > Yep, but another argument might be that it would be better > to have them > separate because they were designed to be two separate > protocols, and > that they are in fact quite different. => This is a baseless argument though because they are not that different if RO for IPv4 is ignored. > > > ==> implementations are already there; the same > argument as IPv4/6 > > > dual-stack deployment. > > > > => Which implementations ?? Have you seen commercial MIPv4 running > > on windows? how widely deployed is it? > > Right. That's the other point: if there has been no > interest to implement > and deploy MIPv4, why should we care to add the support in > MIPv6? Isn't > this a clear indication that a) MIPv4 isn't sufficiently > deployed to be > worth implementing in the majority systems, b) MIPv4 may be > technically > flawed to be interesting (FA requirements) for general > deployment, => MIPv4 is widely deployed today and used by on a commercial level. My point was that there are not many implementations with both MIPv4 and MIPv6. You took that to another meaning and the conclusion isn't accurate. and c) > MIPv6 may be the much better direction all-in-all? => Of course, so is IPv6, hence the need for transition... > > IMHO, this seems to just prove that there is no MIPv4 > deployment except > perhaps in very restricted scenarios w/ very small set of > hosts. => Factually wrong. It is deployed on a large scale. > > > ==> this is totally incorrect as shown many, many times; you > > > are just > > > assuming that the mobile node could not run a transition > > > mechanism on its > > > own to enable IP protocol access. > > > > => You have not shown that at all. the solution you showed: > > > > - Lacks Bidirectionality (6-to-4). > > By adding 6to4 on HA, you should be able to obtain that. => If you have a proposal I suggest you write something up; designing it on email won't work. The above suggestion won't work in the reverse tunnel ,I've already said that many times... > > > - Only runs with MIPv4 (or at least you didn't explain it > > for MIPv6). > > I'm not sure if I understood your point. Did you mean that I didn't > describe how to enable MIPv4 mobility in an IPv6-only > network? => No. You didn't show how MIPv6-only can be used for both IPv4 and IPv6. Hesham From owner-v6ops@ops.ietf.org Mon Aug 25 02:51:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28902 for ; Mon, 25 Aug 2003 02:51:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rB9s-000N9G-NO for v6ops-data@psg.com; Mon, 25 Aug 2003 06:48:56 +0000 Received: from [194.196.100.234] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19rB5L-000Lbp-W8 for v6ops@ops.ietf.org; Mon, 25 Aug 2003 06:44:16 +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 h7P6hmMD038060 for ; Mon, 25 Aug 2003 08:43:59 +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 h7P6hXW1162992 for ; Mon, 25 Aug 2003 08:43:39 +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 IAA34894 for ; Mon, 25 Aug 2003 08:43:26 +0200 Message-ID: <3F49B007.DF549DE9@zurich.ibm.com> Date: Mon, 25 Aug 2003 08:43: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: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ipv4survey-intro-02.txt References: <200308221401.KAA24802@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 still object to the out-of-scope material in sections 1.1 and 1.2 (previously 1.3). There is less irrelevance than before, but surely this document is not the place for editorializing. Brian > Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents > Date: Mon, 11 Aug 2003 16:19:21 +0200 > From: Brian E Carpenter > Organization: IBM > To: v6ops@ops.ietf.org > > > Hi, > > This is important work and IMHO it's almost ready to ship. > > 1. draft-ietf-v6ops-ipv4survey-intro-01.txt > > Section 1.1 is too editorial, and section 1.2 is irrelevant. > I would simply delete them. If a historical reference is wanted, > use RFC 1752. > > The second and third paragraphs of Section 1.3 are also irrelevant, > and should be removed, and tossed over the fence to the Problem WG. > [I happen to agree with these paragraphs, but they don't belong here.] > From owner-v6ops@ops.ietf.org Mon Aug 25 06:13: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 GAA08145 for ; Mon, 25 Aug 2003 06:13:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rEJS-000OHn-Kl for v6ops-data@psg.com; Mon, 25 Aug 2003 10:11:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19rEJP-000OGx-69 for v6ops@ops.ietf.org; Mon, 25 Aug 2003 10:10:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7PA9uw12447; Mon, 25 Aug 2003 13:09:56 +0300 Date: Mon, 25 Aug 2003 13:09:55 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org, Subject: Re: I-D ACTION:draft-ietf-v6ops-ipv4survey-intro-02.txt In-Reply-To: <3F49B007.DF549DE9@zurich.ibm.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 Hi, On Mon, 25 Aug 2003, Brian E Carpenter wrote: > I still object to the out-of-scope material in sections 1.1 and 1.2 > (previously 1.3). There is less irrelevance than before, but surely this > document is not the place for editorializing. It seems the second part of your comment was not implemented. I agree that those two paragraphs should be removed. Andreas, please do that and resubmit at the end of this week unless other comments come up. Thanks for persistence, Pekka (speaking as co-chair) > > Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents > > Date: Mon, 11 Aug 2003 16:19:21 +0200 > > From: Brian E Carpenter > > Organization: IBM > > To: v6ops@ops.ietf.org > > > > > > Hi, > > > > This is important work and IMHO it's almost ready to ship. > > > > 1. draft-ietf-v6ops-ipv4survey-intro-01.txt > > > > Section 1.1 is too editorial, and section 1.2 is irrelevant. > > I would simply delete them. If a historical reference is wanted, > > use RFC 1752. > > > > The second and third paragraphs of Section 1.3 are also irrelevant, > > and should be removed, and tossed over the fence to the Problem WG. > > [I happen to agree with these paragraphs, but they don't belong here.] > > > -- 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 Aug 25 06:30: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 GAA08732 for ; Mon, 25 Aug 2003 06:30:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rEb8-0001yg-2P for v6ops-data@psg.com; Mon, 25 Aug 2003 10:29:18 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19rEb2-0001xU-Jn for v6ops@ops.ietf.org; Mon, 25 Aug 2003 10:29:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7PAS2Y12658; Mon, 25 Aug 2003 13:28:02 +0300 Date: Mon, 25 Aug 2003 13:28:01 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922CB2@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 Sun, 24 Aug 2003, Soliman Hesham wrote: > > So, it seems pretty reasonable to expect many (most?) > > => More like "none" than "most". Even if they implement > it, the encapsulation is normally done in the FA otherwise > the local domain's ingress filter will drop the packets. Have you even ever deployed MIPv4? MN would encapsulate packets using its care-of address, and local domain's ingress filter would certainly NOT drop those packets. Or what are you referring to? > MN's implement > > tunneling back to HA .. if not for any other reason than > > being able to > > operate in networks where there are no foreign agents. > > => It's not required for operating in such networks. Please > see RFC 3220 If ingress filters are in place in the visited network (i.e., you have to always plan for it even if sometimes that's not the case), it surely is, unless there is something I've missed (if so, please give a specific pointer to what in RFC3220). > > > => what makes the MN reverse tunnel a packet sent to an > > > IPv6 address to an IPv4 address? > > > > The enabling of 6to4 pseudo-interface, for example? (i.e., > > enabling the > > pseudo-interface, resulting in the 2002::/16 route). > > => see above... I do not see how the above is relevant to this part of the discussion. -- 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 Aug 25 06: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 GAA09620 for ; Mon, 25 Aug 2003 06:49:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rEtU-000622-Ry for v6ops-data@psg.com; Mon, 25 Aug 2003 10:48:16 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19rEtP-000612-B8 for v6ops@ops.ietf.org; Mon, 25 Aug 2003 10:48:11 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 25 Aug 2003 06:48:10 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CB6@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: Tsirtsis George , "'Alain Durand'" , "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: Mon, 25 Aug 2003 06:47:55 -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 > > > So, it seems pretty reasonable to expect many (most?) > > > > => More like "none" than "most". Even if they implement > > it, the encapsulation is normally done in the FA otherwise > > the local domain's ingress filter will drop the packets. > > Have you even ever deployed MIPv4? MN would encapsulate > packets using its > care-of address, and local domain's ingress filter would > certainly NOT > drop those packets. Or what are you referring to? => Have you read RFC 3220? Which CoA are you referring to? When you have an FA (almost always) the MN doesn't get a colocated CoA. Please read 3220. And yes I've worked with MIP (v4 and v6) for some time... I won't comment on the rest of the mail because there is obviously some fundamental misunderstanding of MIPv4. Hesham From owner-v6ops@ops.ietf.org Mon Aug 25 07:05: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 HAA10174 for ; Mon, 25 Aug 2003 07:05:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rF9w-0009wD-M6 for v6ops-data@psg.com; Mon, 25 Aug 2003 11:05:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19rF9s-0009ty-Og for v6ops@ops.ietf.org; Mon, 25 Aug 2003 11:05:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7PB1uf13040; Mon, 25 Aug 2003 14:01:56 +0300 Date: Mon, 25 Aug 2003 14:01:55 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "'Alain Durand'" , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922CB6@ftmail.lab.flarion.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 On Mon, 25 Aug 2003, Soliman Hesham wrote: > > > > So, it seems pretty reasonable to expect many (most?) > > > > > > => More like "none" than "most". Even if they implement > > > it, the encapsulation is normally done in the FA otherwise > > > the local domain's ingress filter will drop the packets. > > > > Have you even ever deployed MIPv4? MN would encapsulate > > packets using its > > care-of address, and local domain's ingress filter would > > certainly NOT > > drop those packets. Or what are you referring to? > > => Have you read RFC 3220? No. > Which CoA are you referring to? > When you have an FA (almost always) the MN doesn't get a > colocated CoA. Please read 3220. I'm referring to the local address (obtained e.g. through DHCP) configured on the mobile node, whether given by FA or not. That seems to be the only reasonable way to deploy Mobile IP, as you can't be sure that the hosts implement or enable Mobile IP (so you will have to provide DHCP service giving local addresses), and you can't be sure the routers implement Mobile IP (so the hosts have to be able to reverse tunnel back to HA). That's how Mobile IP is deployed here, and works. You probably have some specific specialized networks in mind. -- 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 Aug 25 07:08:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10299 for ; Mon, 25 Aug 2003 07:08:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rFCr-000Ac3-Tn for v6ops-data@psg.com; Mon, 25 Aug 2003 11:08:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19rFCm-000AbO-MV for v6ops@ops.ietf.org; Mon, 25 Aug 2003 11:08:12 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7PB57513063; Mon, 25 Aug 2003 14:05:07 +0300 Date: Mon, 25 Aug 2003 14:05:07 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: Tsirtsis George , "Mobile-Ip (mobile-ip@sunroof.eng.sun.com)" , Subject: RE: Comments on draft-tsirtsis-dsmip-problem-01.txt In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922CB4@ftmail.lab.flarion.com> 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 Note, I don't think continuing this thread is likely going to be productive, so this is probably my last message on this subject. On Sun, 24 Aug 2003, Soliman Hesham wrote: > > > > ==> the last statement is wrong. The fundamental technical > > > > reason is that > > > > MIPv4 and MIPv6 are *two* different protocols. > > > > > > => And what is the fundamental reason for having those 2?? > > > > Probably that MIPv4 was developed before they could > > seriously consider > > IPv6? > > => In other words there is no fundamental reason. Well, I'm not sure what you'd call a fundamental reason, but different protocol design seems like one to me. > > If we were designing Mobile IP *today*, we'd probably > > intergrate the two > > versions somehow. But we aren't, what's done is done. The > > possiblity > > that if we would now design it differently doesn't > > automatically mean that > > it would be useful to to try to enhance the two protocols or > > re-engineer > > them to work together. > > => Are these comments in the context of the two drafts > or in general? I think they can be extended with very > little work as we showed in the drafts. Others might > have even simpler ways. In general. > > > > ==> this is a very flawed analogy. MIP is *not* a tunnel > > > > setup protocol. > > > > > > => That's news to me. How do you describe the relationship between > > > the MN and the HA? > > > > An IPsec tunnel. > > => This is factually wrong for MIPv4 and MIPv6. > Neither has any requirement for IPsec protection > of the tunnel. It's an IP in IP tunnel! MIPv4 not, MIPv6 requires it for signalling at least .. and if you MUST have it for signalling, why not use the same for the rest? It would seem to be *much* simpler if it was done that way. > > > What is the relationship between the > > > MN and CN in MIPv6? > > > > Direct communication between two nodes (sharing the same IP > > protocol), if > > route optimization is used. > > => Again, factually wrong. RO in MIPv6 is effectively > a tunnelling mechanism that instead of using IP in IP, > uses RH and HAO to save bits. This was discussed many > years ago and discussed again when Erik published his draft. Nope. If you look at RH and HAO (applied together) you note that they don't really save bits. There are MUCH more important points to consider, for example, being open tunnel decapsulation points from everywhere. > > > > ==> there is a fundamental difference there. SIP was > > > > architected *from > > > > the start* to deal with two protocols (AFAIK). > > > > > > => So because it was designed like that from the start > > > you are arguing that it's not analogous? The only difference > > > here is foresight on the SIP designers' behalf and the ease > > > of doing so on the application layer. > > > > Yes, we don't have two entirely differently specified > > protocols, SIPv4 and > > SIPv6 which we would like to merge to some extent. > > > > Note that it's just not about the address family used, the > > differences in > > the design and the details are significantly different with > > MIPv4 and > > MIPv6. > > => Not as far as the MN-HA relationship is concerned. That > part is very similar. RO is the only real difference IMO. > RO is not impacted in our proposals. I'm not sure what you're saying with the latter -- that your proposals will not enable route optimization with dual-stack MIP at all, just the HA-MN communication? (i.e., doing bidirectional tunneling, that's all.) > > > As I stated, > > > > if we want to > > > > do it, something like HIP is possible a right direction (not > > > > necessarily > > > > > > => I'm confused, so you do agree that one protocol can do the job? > > > > One protocol, designed from scratch, could do the job. > > => I think this is becoming a bit argumentative. You do > acknowledge that one protocol can do the job and I've shown > you examples of how to do it using either MIPv4 and MIPv6. No, you're hacking in a part of the MIP support for the other MIP protocol. That's not the same as having a solution which would natively support both IPv4 and IPv6 from the start. > > > => But we argue that you don't need both MIPv4 and MIPv6. > > > > Yep, but another argument might be that it would be better > > to have them > > separate because they were designed to be two separate > > protocols, and > > that they are in fact quite different. > > => This is a baseless argument though because they are not > that different if RO for IPv4 is ignored. Well, I see no words on this -- that you're only interested in bidirectional tunneling between MN (or maybe FA in MIP4) and HA -- in the problem statement. > > > > ==> implementations are already there; the same > > argument as IPv4/6 > > > > dual-stack deployment. > > > > > > => Which implementations ?? Have you seen commercial MIPv4 running > > > on windows? how widely deployed is it? > > > > Right. That's the other point: if there has been no > > interest to implement > > and deploy MIPv4, why should we care to add the support in > > MIPv6? Isn't > > this a clear indication that a) MIPv4 isn't sufficiently > > deployed to be > > worth implementing in the majority systems, b) MIPv4 may be > > technically > > flawed to be interesting (FA requirements) for general > > deployment, > > => MIPv4 is widely deployed today and used by on a commercial > level. I hope I could believe that.. :-) > My point was that there are not many implementations with > both MIPv4 and MIPv6. You took that to another meaning and > the conclusion isn't accurate. Yes, but the question is, why there are no such implementations. There might be reasons for those, like the market segmentation (e.g., implementors don't think their product will be used in places where MIP4 is deployed, so any MIP4-in-MIPv6 or vice versa seem irrelevant too). > > IMHO, this seems to just prove that there is no MIPv4 > > deployment except > > perhaps in very restricted scenarios w/ very small set of > > hosts. > > => Factually wrong. It is deployed on a large scale. I guess someone's large scale could be someone else's very restricted scenario. :-) > > > > ==> this is totally incorrect as shown many, many times; you > > > > are just > > > > assuming that the mobile node could not run a transition > > > > mechanism on its > > > > own to enable IP protocol access. > > > > > > => You have not shown that at all. the solution you showed: > > > > > > - Lacks Bidirectionality (6-to-4). > > > > By adding 6to4 on HA, you should be able to obtain that. > > => If you have a proposal I suggest you write something > up; designing it on email won't work. The above suggestion > won't work in the reverse tunnel ,I've already said that > many times... Unfortunately I don't see this as a serious problem and thus writing up a proposal like this is not all that high on my priorities list :-) > > > - Only runs with MIPv4 (or at least you didn't explain it > > > for MIPv6). > > > > I'm not sure if I understood your point. Did you mean that I didn't > > describe how to enable MIPv4 mobility in an IPv6-only > > network? > > => No. You didn't show how MIPv6-only can be used > for both IPv4 and IPv6. I'm still not sure what you're asking, but my position is that I don't see this as a necessity. -- 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 Aug 25 07:44: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 HAA11712 for ; Mon, 25 Aug 2003 07:44:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rFiJ-000HkW-27 for v6ops-data@psg.com; Mon, 25 Aug 2003 11:40:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19rFiB-000Hik-Ev for v6ops@ops.ietf.org; Mon, 25 Aug 2003 11:40:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7PBdZV13486; Mon, 25 Aug 2003 14:39:35 +0300 Date: Mon, 25 Aug 2003 14:39:35 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: Need for UE<->3GPP Configuration? [issue 8] In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3A4D@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 22 Aug 2003 juha.wiljakka@nokia.com wrote: [...] > JW: Summarizing all the above, some descriptive text can be written, but > I am not so sure that it is vitally needed. I think it would be useful to include at least something, so that folks reading the spec would get an idea "ooh, ok, we'll have to figure out the configuration somehow", even though it was actually done using some 3GPP-specific or implementation-dependant processes. Think of it as a "reminder" not to forget the configuration requirement if you may :-) -- 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 Aug 25 08:53: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 IAA14255 for ; Mon, 25 Aug 2003 08:53:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rGoZ-0006oM-JJ for v6ops-data@psg.com; Mon, 25 Aug 2003 12:51:19 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.20) id 19rGoW-0006k8-Ah for v6ops@ops.ietf.org; Mon, 25 Aug 2003 12:51:16 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 25 Aug 2003 08:50:52 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CB7@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Soliman Hesham Cc: Tsirtsis George , "'Alain Durand'" , "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: Mon, 25 Aug 2003 08:50:45 -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 > On Mon, 25 Aug 2003, Soliman Hesham wrote: > > > > > So, it seems pretty reasonable to expect many (most?) > > > > > > > > => More like "none" than "most". Even if they implement > > > > it, the encapsulation is normally done in the FA otherwise > > > > the local domain's ingress filter will drop the packets. > > > > > > Have you even ever deployed MIPv4? MN would encapsulate > > > packets using its > > > care-of address, and local domain's ingress filter would > > > certainly NOT > > > drop those packets. Or what are you referring to? > > > > => Have you read RFC 3220? > > No. => Then it's more productive to delay this discussion till you do. > > > Which CoA are you referring to? > > When you have an FA (almost always) the MN doesn't get a > > colocated CoA. Please read 3220. > > I'm referring to the local address (obtained e.g. through > DHCP) configured > on the mobile node, whether given by FA or not. => When you read the RFC you will see that if an FA exists and is used as a CoA by the MN there is NO COA from DHCP. The rest of the comments below do not apply to MIPv4 as we know it in 3220 unless you have colocated CoAs. I have yet to see any serious deployment/standards (3GPP2, 3GPP, our (Flarion) young cellular link layer ...etc) that deploys MIP without an FA. I don't know where you refer to by "here" below. Hesham > > That seems to be the only reasonable way to deploy Mobile > IP, as you can't > be sure that the hosts implement or enable Mobile IP (so you > will have to > provide DHCP service giving local addresses), and you can't > be sure the > routers implement Mobile IP (so the hosts have to be able to reverse > tunnel back to HA). > > That's how Mobile IP is deployed here, and works. > > You probably have some specific specialized networks in mind. > > -- > 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 Aug 25 09:33: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 JAA16290 for ; Mon, 25 Aug 2003 09:33:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rHQw-000EWj-1h for v6ops-data@psg.com; Mon, 25 Aug 2003 13:30:58 +0000 Received: from [194.196.100.236] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19rHQP-000EN0-7A for v6ops@ops.ietf.org; Mon, 25 Aug 2003 13:30:25 +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 h7PDUDJ4024314; Mon, 25 Aug 2003 15:30:13 +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 h7PDUJW1189388; Mon, 25 Aug 2003 15:30:20 +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 PAA42628; Mon, 25 Aug 2003 15:30:12 +0200 Message-ID: <3F4A0F5D.B946371F@zurich.ibm.com> Date: Mon, 25 Aug 2003 15:30:05 +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: juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-04: The use of 6to4 [issue 4] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-30.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, 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 Pekka Savola wrote: > > On Fri, 22 Aug 2003 juha.wiljakka@nokia.com wrote: > > yep... I have cut quite a lot text introducing "6to4" in the previous > > version, and I could actually remove the rest of that text in the > > beginning of section 3.2.1. > > > > Furthermore, I will consider rewording based on your proposals. This > > issue is also related to issue 7, and I agreed to (initially) remove > > 6to4 from chapter 3.2.2. > > OK. > > > Brian Carpenter also commented that "...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." > > > > Of course, that kind of situation is possible, but can we consider it as > > a special case that needs not be included in this document trying to > > find general solutions? > > I think my original comment was aimed at 3GPP operators specifically (the > doc had a lot of text describing how a 3GPP _operator_ itself could run > on top of 6to4). > > Brian's comment may be valid ("transition mechanisms at UEs discussion"), > but in different context. Sorry for picking overly generic term for this. I agree. There is no special reason to go into details. I certainly never thought of 6to4 as something to be installed in telephones. Brian > > > -----Original Message----- > > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: 23 July, 2003 12:37 > > To: v6ops@ops.ietf.org > > Subject: 3gpp-analysis-04: The use of 6to4 > > > > > > 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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-v6ops@ops.ietf.org Tue Aug 26 04:52:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23877 for ; Tue, 26 Aug 2003 04:52:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rZW5-0007nL-UV for v6ops-data@psg.com; Tue, 26 Aug 2003 08:49:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.20) id 19rZW0-0007lm-DF for v6ops@ops.ietf.org; Tue, 26 Aug 2003 08:49:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7Q8nFE26494; Tue, 26 Aug 2003 11:49:16 +0300 Date: Tue, 26 Aug 2003 11:49:14 +0300 (EEST) From: Pekka Savola To: Antonio Querubin cc: ipng@sunroof.eng.sun.com, Subject: Re: reverse delegation of 2002:xxxx:xxxx:: ? 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_01,EMAIL_ATTRIBUTION,HOT_NASTY,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, 25 Aug 2003, Antonio Querubin wrote: > Does anybody know what the current procedure (if any) is for getting > reverse delegation of 6to4 address space going? I see 2.0.0.2.ip6.int but > no 2.0.0.2.in-addr.arpa zone. Btw, this should be in v6ops WG list, I think. (Please remove ipng from possible follow-ups.) As for the current procedure, currently there is none. draft-ymbk-6to4-arpa-delegation-00.txt should be in IETF Last Call, though. That would enable the owner of the IPv4 address space to get 6to4 reverse delegations from the RIRs, I think. Whether that solves Joe Random's need for reverse 6to4 delegation is an entirely different thing, because I'd assume that if you have to use 6to4 in an ISP's network, they aren't interested in IPv6, much less making delegations to *you*. -- 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 Aug 26 05:00: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 FAA24143 for ; Tue, 26 Aug 2003 05:00:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rZgi-000Am2-DI for v6ops-data@psg.com; Tue, 26 Aug 2003 09:00:28 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.20) id 19rZgd-000Akd-3l; Tue, 26 Aug 2003 09:00:23 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.20) id 19rZgc-00010V-7R; Tue, 26 Aug 2003 18:00:22 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 26 Aug 2003 18:00:21 +0900 To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: reverse delegation of 2002:xxxx:xxxx:: ? References: Message-Id: X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_01,HOT_NASTY,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 > Whether that solves Joe Random's need for reverse 6to4 delegation is an > entirely different thing, because I'd assume that if you have to use > 6to4 in an ISP's network, they aren't interested in IPv6, much less making > delegations to *you*. see From owner-v6ops@ops.ietf.org Tue Aug 26 06:32: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 GAA27435 for ; Tue, 26 Aug 2003 06:32:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rb5z-0004Kx-FZ for v6ops-data@psg.com; Tue, 26 Aug 2003 10:30:39 +0000 Received: from [3ffe:805::230:48ff:fe22:6a53] (helo=karoshi.com) by psg.com with esmtp (Exim 4.20) id 19rb5u-0004Kg-1a for v6ops@ops.ietf.org; Tue, 26 Aug 2003 10:30:34 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h7QAZe432696; Tue, 26 Aug 2003 03:35:40 -0700 From: bmanning@karoshi.com Message-Id: <200308261035.h7QAZe432696@karoshi.com> Subject: Re: reverse delegation of 2002:xxxx:xxxx:: ? To: pekkas@netcore.fi (Pekka Savola) Date: Tue, 26 Aug 2003 03:35:40 -0700 (PDT) Cc: tony@lava.net (Antonio Querubin), ipng@sunroof.eng.sun.com, v6ops@ops.ietf.org In-Reply-To: from "Pekka Savola" at Aug 26, 2003 11:49:14 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-11.2 required=5.0 tests=BAYES_01,HOT_NASTY,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 Content-Transfer-Encoding: 7bit > On Mon, 25 Aug 2003, Antonio Querubin wrote: > > Does anybody know what the current procedure (if any) is for getting > > reverse delegation of 6to4 address space going? I see 2.0.0.2.ip6.int but > > no 2.0.0.2.in-addr.arpa zone. > > Btw, this should be in v6ops WG list, I think. (Please remove ipng from > possible follow-ups.) > > As for the current procedure, currently there is none. > > draft-ymbk-6to4-arpa-delegation-00.txt should be in IETF Last Call, > though. That would enable the owner of the IPv4 address space to get 6to4 > reverse delegations from the RIRs, I think. Presuming the RIRs even want to do this. Until/Unless such time as the draft passes and the RIRs adopt such a stratagy, registration in 2.0.0.2.ip6.int is still available. --bill From owner-v6ops@ops.ietf.org Tue Aug 26 10:18: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 KAA07080 for ; Tue, 26 Aug 2003 10:18:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19reaI-0001F2-MU for v6ops-data@psg.com; Tue, 26 Aug 2003 14:14:10 +0000 Received: from [194.196.100.237] (helo=d12lmsgate.de.ibm.com) by psg.com with esmtp (Exim 4.20) id 19rea6-0001Br-61 for v6ops@ops.ietf.org; Tue, 26 Aug 2003 14:13:58 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h7QED3oU047644; Tue, 26 Aug 2003 16:13:03 +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 h7QED9Hm059168; Tue, 26 Aug 2003 16:13:10 +0200 Received: from zurich.ibm.com (dhcp22-49.zurich.ibm.com [9.4.22.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA31876; Tue, 26 Aug 2003 16:13:02 +0200 Message-ID: <3F4B6AE6.B86840D1@zurich.ibm.com> Date: Tue, 26 Aug 2003 16:12:54 +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: bmanning@karoshi.com, v6ops@ops.ietf.org CC: Pekka Savola , Antonio Querubin Subject: Re: reverse delegation of 2002:xxxx:xxxx:: ? References: <200308261035.h7QAZe432696@karoshi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,HOT_NASTY,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 I've heard it suggested that reverse lookup should maybe not even be set up at all for 6to4, or that it should simply be synthesized automatically. I've certainly heard it suggested that this is a topic for dnsops, not for either IPv6 WG. Brian bmanning@karoshi.com wrote: > > > On Mon, 25 Aug 2003, Antonio Querubin wrote: > > > Does anybody know what the current procedure (if any) is for getting > > > reverse delegation of 6to4 address space going? I see 2.0.0.2.ip6.int but > > > no 2.0.0.2.in-addr.arpa zone. > > > > Btw, this should be in v6ops WG list, I think. (Please remove ipng from > > possible follow-ups.) > > > > As for the current procedure, currently there is none. > > > > draft-ymbk-6to4-arpa-delegation-00.txt should be in IETF Last Call, > > though. That would enable the owner of the IPv4 address space to get 6to4 > > reverse delegations from the RIRs, I think. > > Presuming the RIRs even want to do this. > Until/Unless such time as the draft passes and > the RIRs adopt such a stratagy, registration in > 2.0.0.2.ip6.int is still available. > > --bill -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS PLEASE UPDATE ADDRESS BOOK From owner-v6ops@ops.ietf.org Tue Aug 26 16:04: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 QAA03344 for ; Tue, 26 Aug 2003 16:04:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rjzI-0002sr-2J for v6ops-data@psg.com; Tue, 26 Aug 2003 20:00:20 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19rjyv-0002jf-Lr for v6ops@ops.ietf.org; Tue, 26 Aug 2003 19:59:57 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7QJxud29352; Tue, 26 Aug 2003 12:59:56 -0700 X-mProtect: <200308261959> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduAQ43L; Tue, 26 Aug 2003 12:59:54 PDT Message-ID: <3F4BBE48.6050808@iprg.nokia.com> Date: Tue, 26 Aug 2003 13:08:40 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Templin CC: v6ops@ops.ietf.org Subject: Re: RFC 2893-style automatic tunneling References: <245DBCAEEC4F074CB77B3F984FF9834F01907660@esebe005.ntc.nokia.com> <3F46ABA4.7090408@iprg.nokia.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 There was no answer to my question on RFC 2893-style automatic tunneling, so I take this as a possible indication that no one is still using this mechanism. Should we move to deprecate, then? If so, what form should the deprecation take? Thanks - Fred ftemplin@iprg.nokia.com Fred Templin wrote: > Is RFC 2893-style automatic tunneling (i.e., with IPv4-compatible IPv6 > addresses) > used in any active deployments? It seems to me that the functionality > is obsoleted > by newer automatic tunneling mechanisms (e.g., 6to4, isatap, etc.) but > I'd like to > hear from those with more current operational experience. > > Thanks - Fred > ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue Aug 26 19:30: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 TAA21889 for ; Tue, 26 Aug 2003 19:30:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rluv-000CLd-8q for v6ops-data@psg.com; Tue, 26 Aug 2003 22:03:57 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.20) id 19rleq-0009iL-9W for v6ops@ops.ietf.org; Tue, 26 Aug 2003 21:47:20 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id C3A4818DC for ; Tue, 26 Aug 2003 17:47:06 -0400 (EDT) Date: Tue, 26 Aug 2003 17:47:06 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: reverse delegation of 2002:xxxx:xxxx:: ? In-Reply-To: <3F4B6AE6.B86840D1@zurich.ibm.com> References: <200308261035.h7QAZe432696@karoshi.com> <3F4B6AE6.B86840D1@zurich.ibm.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030826214706.C3A4818DC@thrintun.hactrn.net> Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Tue, 26 Aug 2003 16:12:54 +0200, Brian E Carpenter wrote: > > I've certainly heard it suggested that this is a topic for dnsops, > not for either IPv6 WG. Yep. From owner-v6ops@ops.ietf.org Tue Aug 26 20:15: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 UAA25378 for ; Tue, 26 Aug 2003 20:15:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rntD-0000kl-0q for v6ops-data@psg.com; Wed, 27 Aug 2003 00:10:19 +0000 Received: from [4.65.21.158] (helo=tndh.net) by psg.com with esmtp (Exim 4.20) id 19rnCN-000EjZ-Cq for v6ops@ops.ietf.org; Tue, 26 Aug 2003 23:26:03 +0000 Received: from eagleswings (127.0.0.1:3976) by tndh.net with [XMail 1.16 (Win32/Ix86) ESMTP Server] id for from ; Tue, 26 Aug 2003 16:24:27 -0700 From: "Tony Hain" To: "'Fred Templin'" Cc: Subject: RE: RFC 2893-style automatic tunneling Date: Tue, 26 Aug 2003 16:23:18 -0700 Message-ID: <043f01c36c29$08b9d040$63124104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3F4BBE48.6050808@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In fact I just had to deal with a customer asking about automated = tunneling of IPv4 over an IPv6-only network in the last couple of weeks. At this = point I am not sure if 2893 is the only way to solve the problem, but it is at least one way. While it is creates some routing issues if used in the greater Internet, it may have applicability in some closed = configurations without a massive number of routes. It would be premature to deprecate = it at this time. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Templin > Sent: Tuesday, August 26, 2003 1:09 PM > To: Fred Templin > Cc: v6ops@ops.ietf.org > Subject: Re: RFC 2893-style automatic tunneling >=20 >=20 > There was no answer to my question on RFC 2893-style=20 > automatic tunneling, so I take this as a possible indication=20 > that no one is still using this=20 > mechanism. >=20 > Should we move to deprecate, then? If so, what form should the=20 > deprecation take? >=20 > Thanks - Fred > ftemplin@iprg.nokia.com >=20 > Fred Templin wrote: >=20 > > Is RFC 2893-style automatic tunneling (i.e., with=20 > IPv4-compatible IPv6 > > addresses) > > used in any active deployments? It seems to me that the=20 > functionality=20 > > is obsoleted > > by newer automatic tunneling mechanisms (e.g., 6to4,=20 > isatap, etc.) but=20 > > I'd like to > > hear from those with more current operational experience. > > > > Thanks - Fred > > ftemplin@iprg.nokia.com >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Aug 26 20:19: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 UAA25637 for ; Tue, 26 Aug 2003 20:19:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19rnQ9-000G4f-L3 for v6ops-data@psg.com; Tue, 26 Aug 2003 23:40:17 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.20) id 19rmwk-000Dec-D5 for v6ops@ops.ietf.org; Tue, 26 Aug 2003 23:09:54 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7QN9nc07277; Tue, 26 Aug 2003 16:09:49 -0700 X-mProtect: <200308262309> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIN8XG2; Tue, 26 Aug 2003 16:09:47 PDT Message-ID: <3F4BEAC9.1030500@iprg.nokia.com> Date: Tue, 26 Aug 2003 16:18:33 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alain Durand CC: v6ops@ops.ietf.org Subject: Re: RFC 2893-style automatic tunneling References: <245DBCAEEC4F074CB77B3F984FF9834F01907660@esebe005.ntc.nokia.com> <3F46ABA4.7090408@iprg.nokia.com> <3F4BBE48.6050808@iprg.nokia.com> <3F4BD956.9020704@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit OK. When will we see this document advanced for last-call? Fred ftemplin@iprg.nokia.com Alain Durand wrote: > The answer is in draft-ietf-v6ops-mech-v2-00.txt: > > Types of IPv6 Addresses > > IPv4-compatible IPv6 address: > > An IPv6 address bearing the high-order 96-bit prefix > 0:0:0:0:0:0, and an IPv4 address in the low-order 32- > bits. IPv4-compatible addresses are no longer used by > this specification, thus this definition is preserved in > the specification merely to clarify their non-use. > > > - Alain. > > Fred Templin wrote: > >> There was no answer to my question on RFC 2893-style automatic >> tunneling, >> so I take this as a possible indication that no one is still using >> this mechanism. >> >> Should we move to deprecate, then? If so, what form should the >> deprecation take? >> >> Thanks - Fred >> ftemplin@iprg.nokia.com >> >> Fred Templin wrote: >> >>> Is RFC 2893-style automatic tunneling (i.e., with IPv4-compatible >>> IPv6 addresses) >>> used in any active deployments? It seems to me that the >>> functionality is obsoleted >>> by newer automatic tunneling mechanisms (e.g., 6to4, isatap, etc.) >>> but I'd like to >>> hear from those with more current operational experience. >>> >>> Thanks - Fred >>> ftemplin@iprg.nokia.com >> >> >> >> >> >> > > From owner-v6ops@ops.ietf.org Tue Aug 26 20:27: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 UAA26229 for ; Tue, 26 Aug 2003 20:27:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19ro5c-00022s-Of for v6ops-data@psg.com; Wed, 27 Aug 2003 00:23:08 +0000 Received: from [66.92.66.67] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 4.20) id 19ro3w-0001u4-1W for v6ops@ops.ietf.org; Wed, 27 Aug 2003 00:21:24 +0000 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E8E6118F3 for ; Tue, 26 Aug 2003 20:21:10 -0400 (EDT) Date: Tue, 26 Aug 2003 20:21:10 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: reverse delegation of 2002:xxxx:xxxx:: ? In-Reply-To: <3F4B6AE6.B86840D1@zurich.ibm.com> References: <200308261035.h7QAZe432696@karoshi.com> <3F4B6AE6.B86840D1@zurich.ibm.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030827002110.E8E6118F3@thrintun.hactrn.net> X-Spam-Status: No, hits=-6.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,HOT_NASTY,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Tue, 26 Aug 2003 16:12:54 +0200, Brian E Carpenter wrote: > > I've certainly heard it suggested that this is a topic for dnsops, > not for either IPv6 WG. Yep. From owner-v6ops@ops.ietf.org Tue Aug 26 20:51: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 UAA28245 for ; Tue, 26 Aug 2003 20:51:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.20) id 19roW1-0005XZ-3t for v6ops-data@psg.com; Wed, 27 Aug 2003 00:50:25 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.20) id 19roVV-0005R1-Gw for v6ops@ops.ietf.org; Wed, 27 Aug 2003 00:49:53 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h7QM48mZ001141 for ; Tue, 26 Aug 2003 16:04:08 -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 <0HK800959YMVG5@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Tue, 26 Aug 2003 16:04:08 -0600 (MDT) Received: from sun.com ([129.146.12.20]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HK800KHIYMUTO@mail.sun.net> for v6ops@ops.ietf.org; Tue, 26 Aug 2003 16:04:07 -0600 (MDT) Date: Tue, 26 Aug 2003 15:04:06 -0700 From: Alain Durand Subject: Re: RFC 2893-style automatic tunneling To: Fred Templin Cc: v6ops@ops.ietf.org Message-id: <3F4BD956.9020704@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: <245DBCAEEC4F074CB77B3F984FF9834F01907660@esebe005.ntc.nokia.com> <3F46ABA4.7090408@iprg.nokia.com> <3F4BBE48.6050808@iprg.nokia.com> X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT The answer is in draft-ietf-v6ops-mech-v2-00.txt: Types of IPv6 Addresses IPv4-compatible IPv6 address: An IPv6 address bearing the high-order 96-bit prefix 0:0:0:0:0:0, and an IPv4 address in the low-order 32- bits. IPv4-compatible addresses are no longer used by this specification, thus this definition is preserved in the specification merely to clarify their non-use. - Alain. Fred Templin wrote: > There was no answer to my question on RFC 2893-style automatic tunneling, > so I take this as a possible indication that no one is still using > this mechanism. > > Should we move to deprecate, then? If so, what form should the > deprecation take? > > Thanks - Fred > ftemplin@iprg.nokia.com > > Fred Templin wrote: > >> Is RFC 2893-style automatic tunneling (i.e., with IPv4-compatible >> IPv6 addresses) >> used in any active deployments? It seems to me that the functionality >> is obsoleted >> by newer automatic tunneling mechanisms (e.g., 6to4, isatap, etc.) >> but I'd like to >> hear from those with more current operational experience. >> >> Thanks - Fred >> ftemplin@iprg.nokia.com > > > > > From owner-v6ops@ops.ietf.org Thu Aug 28 11:45: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 LAA25363 for ; Thu, 28 Aug 2003 11:45:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sOsS-000DEV-Ak for v6ops-data@psg.com; Thu, 28 Aug 2003 15:40:00 +0000 Received: from [12.25.1.120] (helo=ctron-dnm.enterasys.com) by psg.com with esmtp (Exim 4.22) id 19sOrw-000DDU-Vs for v6ops@ops.ietf.org; Thu, 28 Aug 2003 15:39:29 +0000 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA20418 for ; Thu, 28 Aug 2003 11:39:29 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma020364; Thu, 28 Aug 03 11:38:53 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.122]) by NHROCAVG2 with InterScan Messaging Security Suite; Thu, 28 Aug 2003 11:38:49 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 28 Aug 2003 11:38:49 -0400 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_01C36D7A.79B41B7F" Subject: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 Date: Thu, 28 Aug 2003 11:38:49 -0400 Message-ID: <05829C8A6277594395457B34D6A3A6DD2840B9@MAANDMBX2.ets.enterasys.com> Thread-Topic: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 Thread-Index: AcNtenmxhRokZ8FDTrKrWsdD2j/IZQ== From: "Follen, Stephen" To: X-OriginalArrivalTime: 28 Aug 2003 15:38:49.0305 (UTC) FILETIME=[79C75490:01C36D7A] X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,HTML_50_60 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C36D7A.79B41B7F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A question related to Ingress Filtering of decapsulated [tunneled] IPv6-in-IPv4 packets: =20 Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that "... a decapsulated packet MUST NOT be forwarded unless the node has been explicitly configured to forward such packets ..." and in section 4.3 "The decapsulating node MUST verify that the tunnel source address is acceptable before forwarding decapsulated packets ..." (the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 Transition Mechanisms provides similar guidance in sections 3.6, 3.9 and 4.1) =20 The question is what to do in the case that the packets are filtered / not forwarded: =20 1. silently drop the packet - simple, but provides no feedback of the "broken link" (see below); =20 2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a poor approach since (a) the IPv4 [tunnel endpoint] address was reached and (b) a response may never get back to the originating IPv6 host (section 3.4 of RFC 2893 indicates that an encapsulating node MAY generate a v6 ICMP when it gets a v4 ICMP back); =20 3. send a v6 ICMP DU - this probably won't get back to the originating host either since its unlikely that there's a path back to it (the do not forward decision occurred because the tunnel was not set up); =20 4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information in the incoming IPv6-in-IPv4 packet to generate this, and it would likely get back to the originating host, but to do so would effectively send a packet via a tunnel which had not been configured. =20 "broken link" - [in the case of legitimate traffic] the filtering which would occur here is not the result of a specifically configured ingress filter, rather, it is the result of not fully configuring the tunnel; a tunnel is effectively a link, so I see the filtering to be similar to a broken link. =20 Any thoughts would be greatly appreciated. - Thank you =20 Steve Follen sfollen@enterasys.com =20 =20 =20 =20 ------_=_NextPart_001_01C36D7A.79B41B7F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

A question=20 related to Ingress Filtering of decapsulated [tunneled] IPv6-in-IPv4 packets:
 
Section 3.6 of RFC=20 2893, IPv6 Transition=20 Mechanisms, indicates that "... a decapsulated packet MUST = NOT be=20 forwarded unless the node has been explicitly configured to forward such = packets=20 ..." and in section 4.3 "The decapsulating node MUST verify that the = tunnel=20 source address is acceptable before forwarding decapsulated packets=20 ..."
(the more recent draft-ietf-v6ops-mech-v2-00.txt, = Basic IPv6=20 Transition Mechanisms provides similar guidance in sections 3.6, 3.9 and = 4.1)
 
The = question is what=20 to do in the case that the packets are = filtered=20 / not forwarded:
 
1. = silently drop=20 the packet - simple, but provides no feedback of=20 the "broken link" (see = below);
 
2. send a v4 ICMP, Destination = Unreachable (DU)=20 - this seems like a poor approach since
   (a) the IPv4 [tunnel = endpoint]=20 address was reached and
  =  (b) a response may never get back to = the=20 originating IPv6=20 host
      =  (section=20 3.4 of RFC 2893 indicates that an encapsulating node MAY=20 generate
       a = v6 ICMP=20 when it gets a v4 ICMP = back);
 
3. send a v6 ICMP DU - this probably = won't get=20 back to the originating host either since
    its unlikely that = there's a=20 path back to it (the do not forward decision occurred=20 because
   =  the tunnel was not set=20 up);
 
4. send a ICMPv6 DU encapsulated in = IPv4 - there=20 is enough information in the incoming
    IPv6-in-IPv4 packet = to=20 generate this, and it would likely get back to the originating=20 host,
    but = to do so=20 would effectively send a packet via a tunnel which had not been=20 configured.
 
"broken link" - [in the case of legitimate = traffic] the=20 filtering which would occur here is not
the result of a specifically configured ingress = filter,=20 rather, it is the = result of not=20 fully configuring
the tunnel; a tunnel is effectively a link, so=20 I see the = filtering to be=20 similar to a broken link.
 
Any=20 thoughts would be greatly appreciated.  - Thank=20 you
 
Steve Follen
sfollen@enterasys.com
 
 
 
 
=00 ------_=_NextPart_001_01C36D7A.79B41B7F-- From owner-v6ops@ops.ietf.org Thu Aug 28 12:43:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29100 for ; Thu, 28 Aug 2003 12:43:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sPpS-000HvW-LB for v6ops-data@psg.com; Thu, 28 Aug 2003 16:40:58 +0000 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.22) id 19sPpH-000Huo-9g for v6ops@ops.ietf.org; Thu, 28 Aug 2003 16:40:47 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 870C37F4C; Thu, 28 Aug 2003 18:40:22 +0200 (CEST) From: "Jeroen Massar" To: "'Follen, Stephen'" , Subject: RE: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 Date: Thu, 28 Aug 2003 18:40:20 +0200 Organization: Unfix Message-ID: <003101c36d83$1240b600$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <05829C8A6277594395457B34D6A3A6DD2840B9@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Follen, Stephen wrote: > A question related to Ingress Filtering of decapsulated=20 > [tunneled] IPv6-in-IPv4 packets: > =20 > Section 3.6 of RFC 2893, IPv6 Transition Mechanisms,=20 > indicates that "... a decapsulated packet MUST NOT be=20 > forwarded unless the node has been explicitly configured to=20 > forward such packets ..." and in section 4.3 "The=20 > decapsulating node MUST verify that the tunnel source address=20 > is acceptable before forwarding decapsulated packets ..." > (the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6=20 > Transition Mechanisms provides similar guidance in sections=20 > 3.6, 3.9 and 4.1) > =20 > The question is what to do in the case that the packets are=20 > filtered / not forwarded: SixXS POPs have the following policy: - Unconfigured tunnels, thus if a 'tunnel' is not known to the POP return a proto 41 icmp unreachable (IPv4) - Configured tunnels, but with the wrong source prefix will return a IPv6 Administrative Filter. Note that if the OS of the POP doesn't support this it will be silently dropped, but that is currently only the case on of the POPs. Thus the POPs cannot be used if they a tunnel is not configured. And they can only be used then when the source prefix is correct that is the prefix that was assigned to go over the tunnel. Unfortunatly I know of a couple of tunnelbrokers that do not filter based on source prefix allowing them to be used for abusive means which cannot be tracked unless one checks every hop's traffic stats and as these are unavailable... Also read up in: http://ip6.de.easynet.net/ipv6-minimum-peering.txt aka "Minimum Technical IPv6 Peering Requirements (MIPP)" by Robert = Kiessling. Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP04wdCmqKFIzPnwjEQLCYgCfUF7kiYeyrZ99trZ0AxcxuFBSLi8AnRf7 tYxrmgaFVabdQgJVJUXqTJn6 =3DLvDQ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Thu Aug 28 17:29: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 RAA20697 for ; Thu, 28 Aug 2003 17:29:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sUHP-000GRA-Dq for v6ops-data@psg.com; Thu, 28 Aug 2003 21:26:07 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19sUH4-000GPA-H9 for v6ops@ops.ietf.org; Thu, 28 Aug 2003 21:25:46 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7SLPej04364; Thu, 28 Aug 2003 14:25:40 -0700 X-mProtect: <200308282125> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmsJuw3; Thu, 28 Aug 2003 14:25:38 PDT Message-ID: <3F4E756C.8010807@iprg.nokia.com> Date: Thu, 28 Aug 2003 14:34:36 -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: "Follen, Stephen" CC: v6ops@ops.ietf.org Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 References: <05829C8A6277594395457B34D6A3A6DD2840B9@MAANDMBX2.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Are you suggesting perhaps that some additional specification is needed in 'draft-ietf-v6ops-mech-v2-00.txt'? Fred ftemplin@iprg.nokia.com Follen, Stephen wrote: > A question related to Ingress Filtering of decapsulated [tunneled] > IPv6-in-IPv4 packets: > > Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that > "... a decapsulated packet MUST NOT be forwarded unless the node has > been explicitly configured to forward such packets ..." and in section > 4.3 "The decapsulating node MUST verify that the tunnel source address > is acceptable before forwarding decapsulated packets ..." > (the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 > Transition Mechanisms provides similar guidance in sections 3.6, 3.9 > and 4.1) > > The question is what to do in the case that the packets are filtered > / not forwarded: > > 1. silently drop the packet - simple, but provides no feedback of the > "broken link" (see below); > > 2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a > poor approach since > (a) the IPv4 [tunnel endpoint] address was reached and > (b) a response may never get back to the originating IPv6 host > (section 3.4 of RFC 2893 indicates that an encapsulating node > MAY generate > a v6 ICMP when it gets a v4 ICMP back); > > 3. send a v6 ICMP DU - this probably won't get back to the originating > host either since > its unlikely that there's a path back to it (the do not forward > decision occurred because > the tunnel was not set up); > > 4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information > in the incoming > IPv6-in-IPv4 packet to generate this, and it would likely get back > to the originating host, > but to do so would effectively send a packet via a tunnel which > had not been configured. > > "broken link" - [in the case of legitimate traffic] the filtering > which would occur here is not > the result of a specifically configured ingress filter, rather, it is > the result of not fully configuring > the tunnel; a tunnel is effectively a link, so I see the filtering to > be similar to a broken link. > > Any thoughts would be greatly appreciated. - Thank you > > Steve Follen > sfollen@enterasys.com > > > > From owner-v6ops@ops.ietf.org Thu Aug 28 18:17: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 SAA24958 for ; Thu, 28 Aug 2003 18:17:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sV3S-000KY2-HU for v6ops-data@psg.com; Thu, 28 Aug 2003 22:15:46 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19sV2W-000KTh-Bs for v6ops@ops.ietf.org; Thu, 28 Aug 2003 22:14:48 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7SMEa000667; Fri, 29 Aug 2003 01:14:36 +0300 Date: Fri, 29 Aug 2003 01:14:35 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: Alain Durand , Subject: Re: RFC 2893-style automatic tunneling In-Reply-To: <3F4BEAC9.1030500@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Perhaps an update is in order. On Tue, 26 Aug 2003, Fred Templin wrote: > OK. When will we see this document advanced for last-call? The document is being revised as we speak -- and hope to have a new version out soon. Last call should be soon to follow. Our updated milestones list moving RFC2893bis to DS for November 2003, but whether the changes are too extensive to warrant for that (and whether we can get implementation reports by then, etc.etc.) remains to be seen. Pekka (speaking as co-chair) From owner-v6ops@ops.ietf.org Fri Aug 29 00:56: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 AAA26243 for ; Fri, 29 Aug 2003 00:56:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sbFz-00029c-TF for v6ops-data@psg.com; Fri, 29 Aug 2003 04:53:07 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 19sbFx-00029O-N9 for v6ops@ops.ietf.org; Fri, 29 Aug 2003 04:53:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7T4qwk04771; Fri, 29 Aug 2003 07:52:58 +0300 Date: Fri, 29 Aug 2003 07:52:57 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: "'Fred Templin'" , Subject: RE: RFC 2893-style automatic tunneling In-Reply-To: <043f01c36c29$08b9d040$63124104@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 26 Aug 2003, Tony Hain wrote: > In fact I just had to deal with a customer asking about automated tunneling > of IPv4 over an IPv6-only network in the last couple of weeks. At this point > I am not sure if 2893 is the only way to solve the problem, but it is at > least one way. While it is creates some routing issues if used in the > greater Internet, it may have applicability in some closed configurations > without a massive number of routes. It would be premature to deprecate it at > this time. Having to use automatic tunneling over IPv6-only network would seem to suggest a failure to consider dual-stack. Or if the need for tunnels is not high, manual tunnels and a routing protocol could also suffice. The automatic tunneling in its present form is simply too flawed (in particular, the security considerations was never well defined), and has to go. > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Templin > > Sent: Tuesday, August 26, 2003 1:09 PM > > To: Fred Templin > > Cc: v6ops@ops.ietf.org > > Subject: Re: RFC 2893-style automatic tunneling > > > > > > There was no answer to my question on RFC 2893-style > > automatic tunneling, so I take this as a possible indication > > that no one is still using this > > mechanism. > > > > Should we move to deprecate, then? If so, what form should the > > deprecation take? > > > > Thanks - Fred > > ftemplin@iprg.nokia.com > > > > Fred Templin wrote: > > > > > Is RFC 2893-style automatic tunneling (i.e., with > > IPv4-compatible IPv6 > > > addresses) > > > used in any active deployments? It seems to me that the > > functionality > > > is obsoleted > > > by newer automatic tunneling mechanisms (e.g., 6to4, > > isatap, etc.) but > > > I'd like to > > > hear from those with more current operational experience. > > > > > > Thanks - Fred > > > ftemplin@iprg.nokia.com > > > > > > > > > > -- 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 Aug 29 09:41: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 JAA23270 for ; Fri, 29 Aug 2003 09:41:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sjQM-00084J-5A for v6ops-data@psg.com; Fri, 29 Aug 2003 13:36:22 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.22) id 19sjPi-00081v-Cw for v6ops@ops.ietf.org; Fri, 29 Aug 2003 13:35:42 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h7TDZb403698 for ; Fri, 29 Aug 2003 16:35:40 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 29 Aug 2003 16:35:35 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 29 Aug 2003 16:35:34 +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: necessity for protocol translators in sect 2.3 [issue 3] Date: Fri, 29 Aug 2003 16:35:34 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A6E@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: necessity for protocol translators in sect 2.3 Thread-Index: AcNQKyFLEDAINLR9S6661b0hwngCEweBrG4Q From: To: , Cc: X-OriginalArrivalTime: 29 Aug 2003 13:35:34.0539 (UTC) FILETIME=[6C9155B0:01C36E32] X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Hesham & Pekka! Very late reply to this issue (too): I agree with the text below and we = can now make this issue "Accepted" in the issue tracker. http://danforsberg.info:8080/draft-ietf-v6ops-3gpp-analysis/index Cheers, -Juha- -----Original Message----- From: ext Soliman Hesham [mailto:H.Soliman@flarion.com] Sent: 22 July, 2003 11:26 To: 'Pekka Savola' Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: necessity for protocol translators in sect 2.3 This text is fine with me.=20 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 >=20 >=20 > On Tue, 22 Jul 2003, Soliman Hesham wrote: > > > modify the last paragraph to (for example): > > > =20 > > > =20 > > > Translators may be needed in some cases when the=20 > > > communicating nodes > > > do not share the same IP version.=20 > >=20 > > =3D> 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. >=20 > If this is a worry, we could expand it a bit, maybe like: >=20 > Translators may be needed in some cases when the=20 > communicating nodes > do not share the same IP version; in others, it may be=20 > possible to=20 > avoid such communication altogether. Translation can=20 > actually happen > at Layer 3 (using NAT-like techniques), Layer 4 (using a TCP/UDP > proxy) or Layer 7 (using application relays). > =20 > (or just remove "in some cases", it's not really a problem for me.) >=20 > > Actually, I think maybe we should not associate > > translation with ALGs, after all, they don't actually > > translate. >=20 > If we'd do this, the above would hold without modifications.=20 > I'm not sure > whether having proxies and such under translators is too big=20 > 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=20 > certainly require > some new text and shift balances around quite a bit. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Fri Aug 29 10:08: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 KAA25280 for ; Fri, 29 Aug 2003 10:08:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sju5-000Ah0-6c for v6ops-data@psg.com; Fri, 29 Aug 2003 14:07:05 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 19sjtJ-000Ab7-M1 for v6ops@ops.ietf.org; Fri, 29 Aug 2003 14:06:17 +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 h7TE6FB13331 for ; Fri, 29 Aug 2003 17:06:16 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 29 Aug 2003 17:06:14 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 29 Aug 2003 17:06:14 +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: use of NAT-PT in IPv6 UE -> IPv4 node [issue 2] Date: Fri, 29 Aug 2003 17:06:06 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A6F@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node Thread-Index: AcNQPdmdf51dnpF5QQa7SRqbIOFGQAd9f2sA From: To: , Cc: X-OriginalArrivalTime: 29 Aug 2003 14:06:14.0152 (UTC) FILETIME=[B5100080:01C36E36] X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Hesham, Pekka et co.! This issue has been open for a while (over one month...). I now try to = summarize it and give some comments. The issue raised by Pekka is about general description of IPv6 = translators used in a case in which an IPv6(-only) UE communicates with = an IPv4(-only) node. And whether we are allowed to describe NAT-PT type = of "general" solution to this problem. Pekka commented that it is not a = good approach to use NAT-PT as a general purpose translation device for = all kinds of traffic. And we should 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. A long discussion by Hesham & Pekka followed - there was quite a lot = discussion of 3GPP architecture, radio resource usage, limitations in = the number of different PDP contexts, etc. One concrete suggestion was = to remove NAT64/NAT46 reference, does the wg think that it is a correct = thing to do? Furthermore, this issue is clearly overlapping with the = NAT-PT applicability team work. So we probably should make a reference = to that draft once it is published. -> I think that we can describe (that does not automatically mean = strongly recommending that solution!) the NAT-PT type of solution for = the general IPv6 -> IPv4 case in our document, and also refer to NAT-PT = applicability draft. I personally think that clearly the most important = 3GPP-related use case for NA(P)T-PT is the IMS interworking case (IMS = scenario 1), that's a place where we clearly need a translator. -> Hesham, you promised some text on PDP context / radio channel usage = below - could you send some suggested text on the list? Cheers, -Juha- -----Original Message----- From: ext Soliman Hesham [mailto:H.Soliman@flarion.com] Sent: 22 July, 2003 13:37 To: 'Pekka Savola' Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node >=20 > The text in elmalki draft seems to suggest that there a UE=20 > with only v6=20 > PDP context requires one radio channel, while a UE with=20 > v4/v6 PDP contexts=20 > require two radio channels (regardless of the fact that the=20 > aggregate=20 > bandwidth usage is the same). >=20 > I don't know the radio technology well enough to to say whether this=20 > perception is true or not. =3D> Ok, we can add some text to clarify this. > > =3D> 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?=20 >=20 > I don't know what (if any) signalling there is between the UE and the > network where some hints about network utilization could be=20 > piggybacked. =20 > Probably a lot. =3D> None exists today.=20 >=20 > But even if there wasn't any, the first UE's could be=20 > programmed to open > both PDP contexts when they start, and possibly discard the=20 > other one if > it is not used in X minutes (or even keep it, no matter). =3D> 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. > > =3D> What types of translation are there? We need IP > > address and port translation, hence NAPT-PT.=20 >=20 > No. =3D> No what? >=20 > > The > > draft discusses how to install the translation > > state in the translator (i.e. installing it before=20 > > traffic goes through the translator).=20 >=20 > Yes, but for a very specific purpose only. =3D> The draft discusses a specific case, it doesn't _design_ a new translator for it. It discussed the use of the existing translator. > > =3D> It doesn't, but how can you restrict > > that in an IETF spec? If a UE doesn't get an IPv4 context,=20 > > it will go through the translator. >=20 > Please, we're discussing the 3GPP solutions document. We as=20 > the WG can do > it any way we see fit. Hopefully the solutions are=20 > reasonable though. =20 > If operators or vendors want to do something else, that's=20 > their problem > and fine too. >=20 > We should not write the document based on what people think=20 > might happen, > but what we think *should* happen=20 =3D> 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.=20 At least this is the aim of the existing keywords in=20 RFC 2119.=20 Hesham From owner-v6ops@ops.ietf.org Fri Aug 29 10:34: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 KAA29032 for ; Fri, 29 Aug 2003 10:34:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19skIQ-000Ckp-CM for v6ops-data@psg.com; Fri, 29 Aug 2003 14:32:14 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 19skHW-000CiE-Ge for v6ops@ops.ietf.org; Fri, 29 Aug 2003 14:31:18 +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 h7TEVGB06278 for ; Fri, 29 Aug 2003 17:31:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 29 Aug 2003 17:31:13 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 29 Aug 2003 17:31:13 +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: Automatic tunneling inside 3GPP operator's network [issue 9] Date: Fri, 29 Aug 2003 17:31:12 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3A70@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-04: Automatic tunneling inside 3GPP operator's network Thread-Index: AcNSXExPm7wZwpmmTlS9RpDJNuS5+Ab3DaiA From: To: , Cc: X-OriginalArrivalTime: 29 Aug 2003 14:31:13.0074 (UTC) FILETIME=[327D5920:01C36E3A] X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_30,NO_REAL_NAME version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Pekka et co.! This is an issue I need to get more wg discussion. If I have not missed = any e-mails, no comments on this have been given, but there was quite a = long e-mail rally (mostly by Pekka & Karim) before publishing 3GPP = Analysis -04. The main points are: Pekka does not like to see automatic tunneling = mechanisms in 3GPP operators' backbones and recommends dual-stack based = solution coupled with a couple of tunnels. Explicitely: - removing 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 - discussing 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). Can anybody (Karim??) provide suggested text on the redundancy = requirements on the list? So: more wg discussion on this issue, please! But: please have a look at = the older thread "3gpp-analysis document and automatic tunneling" to = avoid repeating the same comments again and again and making no = conclusion at all (that is unfortunately very typical in the IETF). Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 25 July, 2003 06:20 To: v6ops@ops.ietf.org Subject: 3gpp-analysis-04: Automatic tunneling inside 3GPP operator's network Hi, This is my last issue in the document. This has already been discussed=20 before, at least in the thread starting May 14, 2003, with subject=20 "3gpp-analysis document and automatic tunneling", but without concrete=20 resolution. Perhaps rereading that discussion would be in order prior = to=20 starting the same debate again. The text basically includes healthy disclaimers (based on my insistence = I=20 guess) why running automatic tunneling mechanisms in 3GPP operators'=20 backbones is not a good idea, and dual-stack should be done instead,=20 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=20 tunneling mechanisms, in particular in three paragraphs I've marked with = a=20 "*" in the text below. I've also marked a section which might use some more description with = "@": =20 "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=20 small islands connected with bridges! What I want is to: - remove all references to the use of 6to4 (for the use of automatic=20 tunneling in the 3GPP operator's core network) or IGP/BGP tunneling=20 mechanisms from this document, and - discuss connection redundancy requirements (if any) and how they=20 could be met with regular, already specified, simple methods (like = running=20 IPv6 routing protocols, using configured tunnneling and deploying=20 dual-stack infrastructure). =3D=3D=3D=3D=3D 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 = =20 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. = =20 * 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. = =20 * 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. --=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 Aug 29 11:28: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 LAA02804 for ; Fri, 29 Aug 2003 11:28:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sl6R-000HZ0-Fn for v6ops-data@psg.com; Fri, 29 Aug 2003 15:23:55 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 19sl5H-000HRh-Lg for v6ops@ops.ietf.org; Fri, 29 Aug 2003 15:22:43 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Fri, 29 Aug 2003 11:22:42 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922CC1@ftmail.lab.flarion.com> From: Soliman Hesham To: "'juha.wiljakka@nokia.com'" , pekkas@netcore.fi Cc: v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node [issu e 2] Date: Fri, 29 Aug 2003 11:22:32 -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=-0.9 required=5.0 tests=BAYES_30 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Juha, Thanks for bringing this up. A couple of comments below. not deploy IPv6-only UE's if they have a need > to reach IPv4 services, and use application proxies => To my knowledge, no one is arguing for IPv6-only UEs. I tried to make that clear in the discussion. > A long discussion by Hesham & Pekka followed - there was > quite a lot discussion of 3GPP architecture, radio resource > usage, limitations in the number of different PDP contexts, > etc. One concrete suggestion was to remove NAT64/NAT46 > reference, does the wg think that it is a correct thing to > do? => Fine with me. Furthermore, this issue is clearly overlapping with the > NAT-PT applicability team work. So we probably should make a > reference to that draft once it is published. => Agreed. > -> I think that we can describe (that does not automatically > mean strongly recommending that solution!) the NAT-PT type > of solution for the general IPv6 -> IPv4 case in our > document, and also refer to NAT-PT applicability draft. I > personally think that clearly the most important > 3GPP-related use case for NA(P)T-PT is the IMS interworking > case (IMS scenario 1), that's a place where we clearly need > a translator. => Agreed. > > -> Hesham, you promised some text on PDP context / radio > channel usage below - could you send some suggested text on the list? => I was referring to the use of the term "channel" which is not quite accurate. I'll send text. Hesham > > Cheers, > -Juha- > > -----Original Message----- > From: ext Soliman Hesham [mailto:H.Soliman@flarion.com] > Sent: 22 July, 2003 13:37 > To: 'Pekka Savola' > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node > > > > > > > > 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 Fri Aug 29 16:35: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 QAA02728 for ; Fri, 29 Aug 2003 16:35:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19sppa-0002cu-Bq for v6ops-data@psg.com; Fri, 29 Aug 2003 20:26:50 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.22) id 19spoY-0002VC-0p for v6ops@ops.ietf.org; Fri, 29 Aug 2003 20:25:46 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7TKPhV08508; Fri, 29 Aug 2003 13:25:43 -0700 X-mProtect: <200308292025> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdATiGZx; Fri, 29 Aug 2003 13:25:42 PDT Message-ID: <3F4FB8E5.5090204@iprg.nokia.com> Date: Fri, 29 Aug 2003 13:34: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: "Follen, Stephen" CC: v6ops@ops.ietf.org Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 References: <05829C8A6277594395457B34D6A3A6DD2840B9@MAANDMBX2.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On further consideration, isn't the situation here logically equivalent to the case of the filter occurring somewhere in the network between the IPv6 source and the tunnel decapsulator; for example, at a firewall? What do firewalls do when they discard a packet due to filtering? I don't know this for certain, but don't they simply do a silent discard w/no ICMP sent back to the source? In any event, I don't see why the tunnel decapsulator should do anything different. Your thoughts? Fred ftemplin@iprg.nokia.com P.S. I could be wrong, but wouldn't sending back an ICMP DU run the risk of a reflection attack when the original packet uses a spoofed IPv6 source address? Follen, Stephen wrote: > A question related to Ingress Filtering of decapsulated [tunneled] > IPv6-in-IPv4 packets: > > Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that > "... a decapsulated packet MUST NOT be forwarded unless the node has > been explicitly configured to forward such packets ..." and in section > 4.3 "The decapsulating node MUST verify that the tunnel source address > is acceptable before forwarding decapsulated packets ..." > (the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 > Transition Mechanisms provides similar guidance in sections 3.6, 3.9 > and 4.1) > > The question is what to do in the case that the packets are filtered > / not forwarded: > > 1. silently drop the packet - simple, but provides no feedback of the > "broken link" (see below); > > 2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a > poor approach since > (a) the IPv4 [tunnel endpoint] address was reached and > (b) a response may never get back to the originating IPv6 host > (section 3.4 of RFC 2893 indicates that an encapsulating node > MAY generate > a v6 ICMP when it gets a v4 ICMP back); > > 3. send a v6 ICMP DU - this probably won't get back to the originating > host either since > its unlikely that there's a path back to it (the do not forward > decision occurred because > the tunnel was not set up); > > 4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information > in the incoming > IPv6-in-IPv4 packet to generate this, and it would likely get back > to the originating host, > but to do so would effectively send a packet via a tunnel which > had not been configured. > > "broken link" - [in the case of legitimate traffic] the filtering > which would occur here is not > the result of a specifically configured ingress filter, rather, it is > the result of not fully configuring > the tunnel; a tunnel is effectively a link, so I see the filtering to > be similar to a broken link. > > Any thoughts would be greatly appreciated. - Thank you > > Steve Follen > sfollen@enterasys.com > > > > From owner-v6ops@ops.ietf.org Sun Aug 31 13:36:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10013 for ; Sun, 31 Aug 2003 13:36:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 19tW33-000HCE-Ff for v6ops-data@psg.com; Sun, 31 Aug 2003 17:31:33 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtp (Exim 4.22) id 19tW1z-000H6k-Q1; Sun, 31 Aug 2003 17:30:27 +0000 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h7VHV7kH024451; Sun, 31 Aug 2003 10:31:08 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h7VHU4p08661; Sun, 31 Aug 2003 10:30:05 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 31 Aug 2003 10:30:03 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: v6ops@ops.ietf.org cc: ops-area@ops.ietf.org Subject: Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 22 Jul 2003, Pekka Savola wrote: > Feedback & Review is sought. Please take a look at the ops IPv4 survey > document: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-01.txt > > It's very very short; please send feedback. In particular, it would be > good to identify specifications which have incorrect information, or > specifications which are not longer relevant and could be moved to > historic (if someone bothered to do that, but that's a different topic), > or the like. I'm aware that the WG last call deadline was August 12th and that http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-02.txt has now replaced the above-mentioned document. However, in an off-line e-mail exchange Pekka Savola encouraged me to send comments even if they would be late, so I offer the following comments on the -02 draft. In general, this draft is on the right track, and the author/editor deserve much thanks for all the work they put in to create the document, but in my opinion there are quite a few minor issues that need to be resolved before it is published. Comments are inserted in-line with the text of the draft, which is indicated by a vertical bar in the left margin. Proposed replacement text is has no vertical bar but is always indented relative to the commentary. | 2.0 Document Organization | | The document is organized as described below: | | Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, | and Proposed Standards, and Experimental RFCs. Each RFC is discussed in | its turn starting with RFC 1 and ending with RFC 3247. The comments for | each RFC is "raw" in nature. That is, each RFC is discussed in a | vacuum and problems or issues discussed do not "look ahead" to see if | the problems have already been fixed. | | Section 7 is an analysis of the data presented in Sections 3, 4, 5, and | 6. It is here that all of the results are considered as a whole and the | problems that have been resolved in later RFCs are correlated. There are some important technical specifications that do not fall into any of these classifications. For instance, RFC 1215, which is part of the (obsolescent) SMIv1 specification, is an Informational RFC. And RFC 3584 (the coexistence document that replaces RFC 2576) is a BCP. I'm not aware of any other such specs, but some may exist. Certainly it behooves us to include at least those two in the survey. One possible way to handle RFC 1215 would be to include it in Sections 3 and 7 along with its companion SMIv1 documents (RFCs 1155 and 1212). I'm not really sure what to do for RFC 3584; maybe a separate section for BCPs would be appropriate. One thing for sure, it would not be a good idea to lump all non-standards-track stuff (BCP + informational + experimental) together. | 3.0 Full Standards | | Full Internet Standards (most commonly simply referred to as | "Standards") are fully mature protocol specification that are widely | implemented and used throughout the Internet. | | | 3.1 RFC 1157 Simple Network Management Protocol | | Beginning in Section 3.2.6.3.2 atTable Object Type Names thru the rest | of Section 3 there are numerous references to the use of IPv4 addresses | as part of OIDs. | | Section 4. Protocol Specification specifies the format of an SNMP | packet which uses the overall format of: | | RFC1157-SNMP DEFINITIONS ::= BEGIN | IMPORTS | ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks | FROM RFC1155-SMI; | | | Section 4.1.3.1. Example of Table Traversal has many uses of IPv4 | addresses in its example of table transversal. | | Section 5. Definitions reiterates the use of IPv4 addresses. | | RFC1157-SNMP DEFINITIONS ::= BEGIN | | IMPORTS | ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks | FROM RFC1155-SMI; As previously noted by Juergen Schoenwaelder, RFC 1157 is HISTORIC (i.e., is no longer an Internet Standard) and should therefore be excluded from the survey. | 3.2 RFC 1155 Structure of Management Information | | Section 3.2.3.2. IpAddress defines the following: | | This application-wide type represents a 32-bit internet address. It | is represented as an OCTET STRING of length 4, in network byte-order. | | There are several instances of the use of this definition in the rest of | the document. There should also be a subsection for RFC 1212, and perhaps also RFC 1215, since RFCs 1155 and 1212 form STD 16, and together with RFC 1215 define SMIv1. | 3.3 RFC 1213 Management Information Base | | There are far too many instances of IPv4 addresses is this document | to enumerate here. Clearly the entire IP OID sub tree is rife with | IPv4 dependencies. A new sub tree needs to be defined to deal with | IPv6 addresses leaving the current sub tree intact for IPv4 address | information. The above paragraph contains the first of many instances where the term "OID" is misused. It is an abbreviation meaning "object identifier," and is NOT the same thing as an object definition, a textual convention, or any SMI construct other than an object identifier. I am sorry to be so picky but I find this abuse of terminology really annoying, and I'll be asking that it be fixed everywhere I see it below. In addition, it is useful for the sake of later analysis to identify the problems in this MIB module a little more concretely. Here is the proposed rewrite: There are far too many instances of IPv4 addresses is this document to enumerate here. The particular object groups that are affected are the IP group, the ICMP group, the TCP group, the UDP group, and the EGP group. | 3.4 RFC 1643 Definitions of Managed Objects for the Ethernet-like | Interface Types | | There are no IPv4 dependencies in this specification. In the recent protocol action which elevated the following documents to Proposed Standard: o draft-ietf-hubmib-etherif-mib-v3-03.txt o draft-ietf-hubmib-mau-mib-v3-04.txt o draft-ietf-hubmib-wis-mib-07.txt the IESG also approved the following as an informational RFC: o draft-ietf-hubmib-1643-to-historic-01.txt and reclassified RFC 1643 to HISTORIC as it recommends. I therefore suggest that RFC 1643 be dropped from this survey. | 3.5 RFC 2578 Structure of Management Information Version 2 (SMIv2) | | Section 7.1.5. IpAddress defines: Rewrite the above sentence as: Section 7.1.5 defines the IpAddress data type: | The IpAddress type represents a 32-bit internet address. It is | represented as an OCTET STRING of length 4, in network byte-order. | | Note that the IpAddress type is a tagged type for historical reasons. | Network addresses should be represented using an invocation of the | TEXTUAL-CONVENTION macro. | | Note the deprecated status of this type; see RFC 3291 for details on | TEXTUAL-CONVENTION macro. Rewrite the last sentence as: Note the deprecated status of this type; see RFC 3291 for details on the replacement TEXTUAL-CONVENTION definitions. | 3.6 RFC 2579 Textual Conventions for SMIv2 | | There are no IPv4 dependencies in this specification. There is no mention of RFC 2580 (which is also an OPS Area Internet Standard). I don't think there are any IPv4 dependencies in RFC 2580, but it should be mentioned here for sake of completeness. | 3.7 RFC 2819 Remote Network Monitoring Management Information Base | (RMON-MIB) | | There are no IPv4 dependencies in this specification. RFCs 3411, 3412, 3413, 3414, and 3415 are also Internet Standards; they replace RFCs 2571, 2572, 2573, 2574, and 2575. Please move the sections for those last five RFCs here and update the RFC numbers. | 3.8 RFC 3416 Protocol Operations for Version 2 of the Simple Network | Management Protocol (SNMPv2) (OPS-MIB) Remove "(OPS-MIB)" ... the mnemonic is misleading, as this document does not contain a MIB module. See also the note below. | Section 4.2.2.1. Example of Table Traversal and Section 4.2.3.1. | Another Example of Table Traversal both use OID's from MIB2 whose | data contains IPv4 addresses. Other than their use in these example | sections there are no IPv4 dependencies in this specification. Please correct this usage error: s/OID's/objects/ | 3.9 RFC 3417 Transport Mappings for Version 2 of the Simple Network | Management Protocol (SNMPv2) (TRANS-MIB) NOTE: I would like to suggest that it is more useful in the case of standards that contain a single MIB module to use the MIB module names instead of the sometimes strange and seldom-used mnemonics that are listed in STD 1, Official Internet Protocol Standards. I will be making this suggestion for each spec that contains a single MIB module; in the present case the change would be: s/TRANS-MIB/SNMPv2-TM/ | Section 2 Definitions contains the following OID definition: Please correct this usage error: s/OID definition/definition/ (a TEXTUAL-CONVENTION is not an OID)/ | | SnmpUDPAddress ::= TEXTUAL-CONVENTION | DISPLAY-HINT "1d.1d.1d.1d/2d" | STATUS current | DESCRIPTION | "Represents a UDP address: | | octets contents encoding | 1-4 IP-address network-byte order | 5-6 UDP-port network-byte order | " | SYNTAX OCTET STRING (SIZE (6)) | | Section 8.1. Usage Example also contains examples which use IPv4 | address, but it has no significance in the operation of the | specification. Wordsmith the last paragraph: Section 8.1, "Usage Example," also contains examples which uses IPv4 addresse, but it has no significance in the operation of the specification. | 3.10 RFC 3418 Management Information Base for Version 2 of the Simple | Network Management Protocol (SNMPv2) (SNMPv2-MIB) | | There are no IPv4 dependencies in this specification. | | | | 4.0 Draft Standards | | Draft Standards represent the penultimate standard level in the IETF. | A protocol can only achieve draft standard when there are multiple, | independent, interoperable implementations. Draft Standards are usually | quite mature and widely used. | | | 4.01 RFC 1493 Definitions of Managed Objects for Bridges (BRIDGE-MIB) | | There are no IPv4 dependencies in this specification. | | | 4.02 RFC 1559 DECnet Phase IV MIB Extensions (DECNET-MIB) s/DECNET-MIB/DECNET-PHIV-MIB/ | There are no IPv4 dependencies in this specification. | | | 4.03 RFC 1657 Definitions of Managed Objects for the Fourth | Version of the Border Gateway Protocol (BGP-4) using SMIv2 (BGP-4-MIB) s/BGP-4-MIB/BGP4-MIB/ | The MIB defined in this RFC deals with objects in a BGP4 based routing | system and therefore contain many objects that are limited by the | IpAddress 32-bit value defined in MIB2. Clearly the values of this MIB | are limited to IPv4 addresses. No update is needed, although a new MIB | should be defined for BGP++ to allow management of IPv6 addresses and | routes. | | | 4.04 RFC 1658 Definitions of Managed Objects for Character Stream | Devices using SMIv2 | | There are no IPv4 dependencies in this specification. | | | 4.05 RFC 1659 Definitions of Managed Objects for RS-232-like Hardware | Devices using SMIv2 | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 4.06 RFC 1660 Definitions of Managed Objects for Parallel-printer-like | Hardware Devices using SMIv2 | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 4.07 RFC 1694 Definitions of Managed Objects for SMDS Interfaces using | SMIv2 (SIP-MIB) | | This MIB definition defines the following subtree: s/MIB/MIB module/ | ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 } | | -- Although the objects in this group are read-only, at the | -- agent's discretion they may be made read-write so that the | -- management station, when appropriately authorized, may | -- change the addressing information related to the | -- configuration of a logical IP subnetwork implemented on | -- top of SMDS. | | -- This table is necessary to support RFC1209 (IP-over-SMDS) | -- and gives information on the Group Addresses and ARP | -- Addresses used in the Logical IP subnetwork. | -- One SMDS address may be associated with multiple IP | -- addresses. One SNI may be associated with multiple LISs. | | ipOverSMDSTable OBJECT-TYPE | SYNTAX SEQUENCE OF IpOverSMDSEntry | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The table of addressing information relevant to | this entity's IP addresses." | ::= { ipOverSMDS 1 } | | ipOverSMDSEntry OBJECT-TYPE | SYNTAX IpOverSMDSEntry | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The addressing information for one of this | entity's IP addresses." | INDEX { ipOverSMDSIndex, ipOverSMDSAddress } | ::= { ipOverSMDSTable 1 } | | IpOverSMDSEntry ::= | SEQUENCE { | ipOverSMDSIndex IfIndex, | ipOverSMDSAddress IpAddress, | ipOverSMDSHA SMDSAddress, | ipOverSMDSLISGA SMDSAddress, | ipOverSMDSARPReq SMDSAddress | } | | ipOverSMDSIndex OBJECT-TYPE | SYNTAX IfIndex | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The value of this object identifies the | interface for which this entry contains management | information. " | ::= { ipOverSMDSEntry 1 } | | ipOverSMDSAddress OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The IP address to which this entry's addressing | information pertains." | ::= { ipOverSMDSEntry 2 } | | ipOverSMDSHA OBJECT-TYPE | SYNTAX SMDSAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The SMDS Individual address of the IP station." | ::= { ipOverSMDSEntry 3 } | | ipOverSMDSLISGA OBJECT-TYPE | SYNTAX SMDSAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The SMDS Group Address that has been configured | to identify the SMDS Subscriber-Network Interfaces | (SNIs) of all members of the Logical IP Subnetwork | (LIS) connected to the network supporting SMDS." | ::= { ipOverSMDSEntry 4 } | | ipOverSMDSARPReq OBJECT-TYPE | SYNTAX SMDSAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The SMDS address (individual or group) to which | ARP Requests are to be sent." | ::= { ipOverSMDSEntry 5 } | | | Although these OIDs are intended for IPv4 addresses, a similar MIB | can be defined for IPv6 addressing. s/these OIDs/these object definitions/ | 4.08 RFC 1724 RIP Version 2 MIB Extension (RIP2-MIB) s/RIP2-MIB/RIPv2-MIB/ | As might be expected, this RFC is filled with IPv4 dependencies since | it defines a MIB for an IPv4 only routing protocol. A new MIB for RIPng | is required. s/a MIB/a MIB module/ s/IPv4 only/IPv4-only/ | 4.09 RFC 1748 IEEE 802.5 MIB using SMIv2 (802.5-MIB) s/802.5-MIB/TOKENRING-MIB/ | There are no IPv4 dependencies in this specification. | | | 4.10 RFC 1850 OSPF Version 2 Management Information Base (OSPF-MIB) | | This MIB defines managed objects for OSPFv2 which is a protocol used | to exchange IPv4 routing information. Since OSPFv2 is limited to IPv4 | addresses a new MIB is required to support a new version of OSPF that | is IPv6 aware. | | | 4.11 RFC 2115 Management Information Base for Frame Relay DTEs | Using SMIv2 (FRAME-MIB) s/FRAME-MIB/FRAME-RELAY-DTE-MIB/ | This MIB has several examples of mapping IPv4 addresses to multiple | Frame Relay DLCI's and monitoring their connections. A new set of OID's | needs to be defined to allow this functionality for IPv6. The last sentence is incorrect: there are NO IPv4 dependencies in the actual MIB objects, only in some explanatory text describing how table entries in the MIB module might relate to entries in MIB-II's ipAddrTable. This relationship is expressed by ifIndex values, not by IP address values. Ergo, rewrite: This specification has several examples of how IPv4 addresses might be mapped to Frame Relay DLCIs. Other than those examples there are no IPv4 dependencies in this specification. | 4.12 RFC 2571 An Architecture for Describing SNMP Management Frameworks | (ARCH-SNMP) | | There are no IPv4 dependencies in this specification. This document has been replaced by RFC 3411, which is an Internet Standard (see note above), so this sub-section needs to be retitled and moved into Section 3. | 4.13 RFC 2572 Message Processing and Dispatching for the Simple Network | Management Protocol (SNMP) (MPD-SNMP) | | There are no IPv4 dependencies in this specification. This document has been replaced by RFC 3412, which is an Internet Standard (see note above), so this sub-section needs to be retitled and moved into Section 3. | 4.14 RFC 2573 SNMP Applications (SNMP-APP) | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ This document has been replaced by RFC 3413, which is an Internet Standard (see note above), so this sub-section needs to be retitled and moved into Section 3. | 4.15 RFC 2574 User-based Security Model (USM) for version 3 of the | Simple Network Management Protocol (SNMPv3) (USM-SNMPV3) | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ This document has been replaced by RFC 3414, which is an Internet Standard (see note above), so this sub-section needs to be retitled and moved into Section 3. | 4.16 RFC 2575 View-based Access Control Model (VACM) for the Simple | Network Management Protocol (SNMP) (VACM-SNMP) | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ This document has been replaced by RFC 3415, which is an Internet Standard (see note above), so this sub-section needs to be retitled and moved into Section 3. | 4.17 RFC 2790 Host Resources MIB | | There are no IPv4 dependencies in this specification. | | | 4.18 RFC 2863 The Interfaces Group MIB (INTERGRMIB) s/INTERGRMIB/IF-MIB/ | There are no IPv4 dependencies in this specification. There is some | discussion in one OID about an interface performing a self test, but it | is IP version independent. s/OID/object definition/ s/it/the object itself/ | 5.0 Proposed Standards | | Proposed Standards are introductory level documents. There are no | requirements for even a single implementation. In many cases Proposed | are never implemented or advanced in the IETF standards process. They | therefore are often just proposed ideas that are presented to the | Internet community. Sometimes flaws are exposed or they are one of | many competing solutions to problems. In these later cases, no | discussion is presented as it would not serve the purpose of this | discussion. | | | 5.001 RFC 1239 Reassignment of experimental MIBs to standard MIBs | (STD-MIBs) | | There are no IPv4 dependencies in this specification. | | | 5.002 RFC 1269 Definitions of Managed Objects for the Border Gateway | Protocol: Version 3 (BGP-MIB) s/BGP-MIB/RFC1269-MIB/ | The use of BGP3 has been deprecated and is not discussed. | | | 5.003 RFC 1285 FDDI Management Information Base (FDDI-MIB) s/FDDI-MIB/RFC1285-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.004 RFC 1381 SNMP MIB Extension for X.25 LAPB (SNMP-LAPB) s/SNMP-LAPB/RFC1381-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.005 RFC 1382 SNMP MIB Extension for the X.25 Packet Layer (SNMP-X.25) s/SNMP-X.25/RFC1382-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.006 RFC 1414 Identification MIB (IDENT-MIB) s/IDENT-MIB/RFC1414-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.007 RFC 1418 SNMP over OSI (SNMP-OSI) | | There are no IPv4 dependencies in this protocol. | | | 5.008 RFC 1419 SNMP over AppleTalk (SNMP-AT) | | There are no IPv4 dependencies in this protocol. | | | 5.009 RFC 1420 SNMP over IPX (SNMP-IPX) | | There are no IPv4 dependencies in this protocol. | | | 5.010 RFC 1441 Introduction to version 2 of the Internet-standard | Network Management Framework (SNMPv2) | | There are no IPv4 dependencies in this protocol. This document is HISTORIC and should be removed from the survey (otherwise, I'd say s/protocol/specification/) | 5.011 RFC 1461 SNMP MIB extension for Multiprotocol Interconnect | over X.25 (X25-MIB) s/X25-MIB/MIOX25-MIB/ | The following OIDs are defined in Section 4 "Definitions": s/OIDs/objects/ | mioxPleLastFailedEnAddr OBJECT-TYPE | SYNTAX OCTET STRING (SIZE(2..128)) | ACCESS read-only | STATUS mandatory | DESCRIPTION | "The last Encapsulated address that failed | to find a corresponding X.121 address and | caused mioxPleEnAddrToX121LkupFlrs to be | incremented. The first octet of this object | contains the encapsulation type, the | remaining octets contain the address of that | type that failed. Thus for an IP address, | the length will be five octets, the first | octet will contain 204 (hex CC), and the | last four octets will contain the IP | address. For a snap encapsulation, the | first byte would be 128 (hex 80) and the | rest of the octet string would have the snap | header." | ::= { mioxPleEntry 4 } | | mioxPeerEnAddr OBJECT-TYPE | SYNTAX OCTET STRING (SIZE (0..128)) | ACCESS read-write | STATUS mandatory | DESCRIPTION | "The Encapsulation address of the remote | host mapped by this table entry. A length | of zero indicates the remote IP address is | unknown or unspecified for use as a PLE | default. | | The first octet of this object contains the | encapsulation type, the remaining octets | contain an address of that type. Thus for | an IP address, the length will be five | octets, the first octet will contain 204 | (hex CC), and the last four octets will | contain the IP address. For a snap | encapsulation, the first byte would be 128 | (hex 80) and the rest of the octet string | would have the snap header." | DEFVAL { ''h } | ::= { mioxPeerEntry 7 } | | mioxPeerEncType OBJECT-TYPE | SYNTAX INTEGER (0..256) | ACCESS read-write | STATUS mandatory | DESCRIPTION | "The value of the encapsulation type. For | IP encapsulation this will have a value of | 204 (hex CC). For SNAP encapsulated | packets, this will have a value of 128 (hex | 80). For CLNP, ISO 8473, this will have a | value of 129 (hex 81). For ES-ES, ISO 9542, | this will have a value of 130 (hex 82). A | value of 197 (hex C5) identifies the Blacker | X.25 encapsulation. A value of 0, | identifies the Null encapsulation. | | This value can only be written when the | mioxPeerStatus object with the same | mioxPeerIndex has a value of underCreation. | Setting this object to a value of 256 | deletes the entry. When deleting an entry, | all other entries in the mioxPeerEncTable | with the same mioxPeerIndex and with an | mioxPeerEncIndex higher then the deleted | entry, will all have their mioxPeerEncIndex | values decremented by one." | ::= { mioxPeerEncEntry 2 } | | Updated values of the first byte of these OID's can be defined to | support IPv6 addresses. s/OID's/objects/ | 5.012 RFC 1471 The Definitions of Managed Objects for the Link | Control Protocol of the Point-to-Point Protocol (PPP/LCPMIB) s?PPP/LCPMIB?PPP-LCP-MIB? | There are no IPv4 dependencies in this specification. | | | 5.013 RFC 1472 The Definitions of Managed Objects for the Security | Protocols of the Point-to-Point Protocol (PPP/SECMIB) s?PPP/SECMIB?PPP-SEC-MIB? | There are no IPv4 dependencies in this specification. | | | 5.014 RFC 1473 The Definitions of Managed Objects for the IP Network | Control Protocol of the Point-to-Point Protocol (PPP/IPMIB) s?PPP/IPMIB?PPP-IP-NCP-MIB? | Every OID in the MIB contain IPv4 addresses. A new MIB must be defined | for OIDs for similar IPv6 addresses. The general idea is right, but this is not accurate as written. Here is the proposed replacement text: This MIB module is targeted specifically at IPv4 over PPP. A new MIB moduld would need to be defined to support IPv6 over PPP. Note that the problem is not IPv4 vs. IPv6 addresses per se, but rather IPCP (PPP IPv4 Control Protocol) vs. IPV6CP (PPP IPv6 Control Protocol). See RFC 2472 and citations therein for more details. | 5.015 RFC 1474 The Definitions of Managed Objects for the Bridge | Network Control Protocol of the Point-to-Point Protocol | (PPP/Bridge) s?PPP/BRIDGE?PPP-BRIDGE-NCP-MIB? | There are no IPv4 dependencies in this specification. | | | 5.016 RFC 1512 FDDI Management Information Base (FDDI-MIB) s/FDDI-MIB/FDDI-SMT73-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.017 RFC 1513 Token Ring Extensions to the Remote Network | Monitoring MIB | | There are no IPv4 dependencies in this specification. | | | 5.018 RFC 1515 Definitions of Managed Objects for IEEE 802.3 | Medium Attachment Units (MAUs) | | There are no IPv4 dependencies in this protocol. This specification will soon be officially obsoleted by draft-ietf-hubmib-mau-mib-v3-04.txt, which will also replace RFC 2668. Since draft-ietf-hubmib-mau-mib-v3-04.txt is in the RFC Editor's queue as we speak, I think it would be reasonable to drop RFC 1515 from the survey. Note that it actually should have been obsoleted by RFC 2668 but was not, owing to an oversight. | 5.019 RFC 1525 Definitions of Managed Objects for Source Routing | Bridges (SRB-MIB) s/SRB-MIB/SOURCE-ROUTING-MIB/ | There are no IPv4 dependencies in this specification. Regarding these sections: | 5.020 RFC 1611 DNS Server MIB Extensions (DNS-S-MIB) ... | 5.021 RFC 1612 DNS Resolver MIB Extensions (DNS-R-MIB) ... As Juergen Schoenwaelder has pointed out, RFCs 1611 and 1612 have been declared HISTORIC and should be dropped from the survey. (Once a document has been declared HISTORIC, it is no longer a standard of any kind.) | 5.022 RFC 1628 UPS Management Information Base (UPS-MIB) | | There are no IPv4 dependencies in this specification. | | | 5.023 RFC 1666 Definitions of Managed Objects for SNA NAUs | using SMIv2 SNANAU-MIB s/SNANAU-MIB/(SNA-NAU-MIB) | There are no IPv4 dependencies in this specification. | | 5.024 RFC 1696 Modem Management Information Base (MIB) using SMIv2 | MODEM-MIB s/MODEM-MIB/(Modem-MIB)/ | There are no IPv4 dependencies in this specification. | | | 5.025 RFC 1697 Relational Database Management System (RDBMS) | Management Information Base (MIB) using SMIv2 RDBMS-MIB s/RDBMS-MIB/(RDBMS-MIB)/ | There are no IPv4 dependencies in this specification. | | | 5.026 RFC 1742 AppleTalk Management Information Base II (AT-MIB) s/AT-MIB/APPLETALK-MIB/ | The following OIDs are defined: s/OIDs/objects/ | KipEntry ::= SEQUENCE { | kipNetStart ATNetworkNumber, | kipNetEnd ATNetworkNumber, | kipNextHop IpAddress, | kipHopCount INTEGER, | kipBCastAddr IpAddress, | kipCore INTEGER, | kipType INTEGER, | kipState INTEGER, | kipShare INTEGER, | kipFrom IpAddress | } | | kipNextHop OBJECT-TYPE | SYNTAX IpAddress | ACCESS read-write | STATUS mandatory | DESCRIPTION | "The IP address of the next hop in the route to this | entry's destination network." | ::= { kipEntry 3 } | | kipBCastAddr OBJECT-TYPE | SYNTAX IpAddress | ACCESS read-write | STATUS mandatory | DESCRIPTION | "The form of the IP address used to broadcast on this | network." | ::= { kipEntry 5 } | | kipFrom OBJECT-TYPE | SYNTAX IpAddress | ACCESS read-only | STATUS mandatory | DESCRIPTION | "The IP address from which the routing entry was | learned via the AA protocol. If this entry was not | created via the AA protocol, it should contain IP | address 0.0.0.0." | ::= { kipEntry 10 } | | | 5.027 RFC 1747 Definitions of Managed Objects for SNA Data Link | Control (SDLC) using SMIv2 SDLCSMIv2 s/SDLCSMIv2/(SNA-SDLC-MIB)/ | There are no IPv4 dependencies in this protocol. s/protocol/specification | 5.028 RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2 | 802.5-SSR s/802.5-SSR/(TOKENRING-STATION-SR-MIB)/ | There are no IPv4 dependencies in this specification. | | | 5.029 RFC 1759 Printer MIB (Print-MIB) s/Print-MIB/Printer-MIB/ | There are no IPv4 dependencies in this specification. Note: this document is slated to be replaced someday "soon" by . When you issue an update of this draft, check the status of RFC 1759 to see if it has been replaced. | | 5.030 RFC 2006 The Definitions of Managed Objects for IP Mobility | Support using SMIv2 (MOBILEIPMI) s/MOBILEIPMI/MIP-MIB/ | This document defines a MIB for the Mobile IPv4 documents described | immediately above. Without enumeration, let it be stated that a new | MIB for IPv6 Mobility is required. | | | 5.031 RFC 2011 SNMPv2 Management Information Base for the Internet | Protocol using SMIv2 (MIB-IP) s/MIB-IP/IP-MIB/ | Approximately 1/3 of the OIDs defined in this document are clearly | IPv4 dependent. A new MIB for IPv6 OIDs is required. Rewrite as follows: Approximately 1/3 of the objects defined in this document are IPv4-dependent. New objects need to be defined to support IPv6. | 5.032 RFC 2012 SNMPv2 Management Information Base for the | Transmission Control Protocol using SMIv2 (MIB-TCP) s/MIB-TCP/TCP-MIB/ | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in | the note reproduced below: s/OIDs/object definitions/ | IESG Note: | | The IP, UDP, and TCP MIB modules currently support only IPv4. These | three modules use the IpAddress type defined as an OCTET STRING of | length 4 to represent the IPv4 32-bit internet addresses. (See RFC | 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 | internet addresses. | | | 5.033 RFC 2013 SNMPv2 Management Information Base for the User | Datagram Protocol using SMIv2 (MIB-UDP) s/MIB-UDP/UDP-MIB/ | A number of OIDs in this MIB assumes IPv4 addresses, as is noted in | the note reproduced below: s/OIDs/object definitions/ | IESG Note: | | The IP, UDP, and TCP MIB modules currently support only IPv4. These | three modules use the IpAddress type defined as an OCTET STRING of | length 4 to represent the IPv4 32-bit internet addresses. (See RFC | 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 | internet addresses. | | | 5.034 RFC 2020 IEEE 802.12 Interface MIB (802.12-MIB) s/802.12-MIB/DOT12-IF-MIB/ Note: the actual title is "Definitions of Managed Objects for IEEE 802.12 Interfaces" ... I've not been checking this; does it matter? | There are no IPv4 dependencies in this specification. | | | 5.035 RFC 2021 Remote Network Monitoring Management Information Base | Version 2 using SMIv2 (RMON-MIB) s/RMON-MIB/RMON2-MIB/ | The following OIDs are defined: s/OIDs/objects/ | addressMapNetworkAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The network address for this relation. | | This is represented as an octet string with | specific semantics and length as identified | by the protocolDirLocalIndex component of the | index. | | For example, if the protocolDirLocalIndex indicates an | encapsulation of ip, this object is encoded as a length | octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { addressMapEntry 2 } | | nlHostAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The network address for this nlHostEntry. | | This is represented as an octet string with | specific semantics and length as identified | by the protocolDirLocalIndex component of the index. | | For example, if the protocolDirLocalIndex indicates an | encapsulation of ip, this object is encoded as a length | octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { nlHostEntry 2 } | | nlMatrixSDSourceAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The network source address for this nlMatrixSDEntry. | | This is represented as an octet string with | specific semantics and length as identified | by the protocolDirLocalIndex component of the index. | | For example, if the protocolDirLocalIndex indicates an | encapsulation of ip, this object is encoded as a length | octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { nlMatrixSDEntry 2 } | | nlMatrixSDDestAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The network destination address for this | nlMatrixSDEntry. | | This is represented as an octet string with | specific semantics and length as identified | by the protocolDirLocalIndex component of the index. | | For example, if the protocolDirLocalIndex indicates an | encapsulation of ip, this object is encoded as a length | octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { nlMatrixSDEntry 3 } | | nlMatrixDSSourceAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The network source address for this nlMatrixDSEntry. | | This is represented as an octet string with | specific semantics and length as identified | by the protocolDirLocalIndex component of the index. | | For example, if the protocolDirLocalIndex indicates an | encapsulation of ip, this object is encoded as a length | octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { nlMatrixDSEntry 2 } | | nlMatrixDSDestAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION | "The network destination address for this | nlMatrixDSEntry. | | This is represented as an octet string with | specific semantics and length as identified | by the protocolDirLocalIndex component of the index. | | For example, if the protocolDirLocalIndex indicates an | encapsulation of ip, this object is encoded as a length | octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { nlMatrixDSEntry 3 } | | nlMatrixTopNSourceAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The network layer address of the source host in this | conversation. | | This is represented as an octet string with | specific semantics and length as identified | by the associated nlMatrixTopNProtocolDirLocalIndex. | | For example, if the protocolDirLocalIndex indicates an | encapsulation of ip, this object is encoded as a length | octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { nlMatrixTopNEntry 3 } | | nlMatrixTopNDestAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The network layer address of the destination host in this | conversation. | | This is represented as an octet string with | specific semantics and length as identified | by the associated nlMatrixTopNProtocolDirLocalIndex. | | For example, if the nlMatrixTopNProtocolDirLocalIndex | indicates an encapsulation of ip, this object is encoded as a | length octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { nlMatrixTopNEntry 4 } | | alMatrixTopNSourceAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The network layer address of the source host in this | conversation. | This is represented as an octet string with | specific semantics and length as identified | by the associated alMatrixTopNProtocolDirLocalIndex. | | For example, if the alMatrixTopNProtocolDirLocalIndex | indicates an encapsulation of ip, this object is encoded as a | length octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { alMatrixTopNEntry 3 } | | alMatrixTopNDestAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The network layer address of the destination host in this | conversation. | | This is represented as an octet string with | specific semantics and length as identified | by the associated alMatrixTopNProtocolDirLocalIndex. | | For example, if the alMatrixTopNProtocolDirLocalIndex | indicates an encapsulation of ip, this object is encoded as a | length octet of 4, followed by the 4 octets of the ip address, | in network byte order." | ::= { alMatrixTopNEntry 4 } | | trapDestProtocol OBJECT-TYPE | SYNTAX INTEGER { | ip(1), | ipx(2) | } | MAX-ACCESS read-create | STATUS current | DESCRIPTION | "The protocol with which to send this trap." | ::= { trapDestEntry 3 } | | trapDestAddress OBJECT-TYPE | SYNTAX OCTET STRING | MAX-ACCESS read-create | STATUS current | DESCRIPTION | "The address to send traps on behalf of this entry. | | If the associated trapDestProtocol object is equal to ip(1), | the encoding of this object is the same as the snmpUDPAddress | textual convention in [RFC1906]: | -- for a SnmpUDPAddress of length 6: | -- | -- octets contents encoding | -- 1-4 IP-address network-byte order | -- 5-6 UDP-port network-byte order | | If the associated trapDestProtocol object is equal to ipx(2), | the encoding of this object is the same as the snmpIPXAddress | textual convention in [RFC1906]: | -- for a SnmpIPXAddress of length 12: | -- | -- octets contents encoding | -- 1-4 network-number network-byte order | -- 5-10 physical-address network-byte order | -- 11-12 socket-number network-byte order | | This object may not be modified if the associated | trapDestStatus object is equal to active(1)." | ::= { trapDestEntry 4 } | | All of the OIDs above (except trapDestProtocol) imply IPv4 addresses | but since they use a SYNTAX of OCTET STRING, they should work fine | for IPv6 addresses. A new legitimate value of trapDestProtocol (i.e. | SYNTAX addition of ipv6(3) should make this specification IPv6 | functional. s/OIDs/object definitions/ s/imply IPv4 addresses/mention only IPv4 addresses,/ s/IPv6 functional./functional for IPv6./ | 5.036 RFC 2024 Definitions of Managed Objects for Data Link Switching | using SMIv2 (DLSW-MIB) | | The following OIDs are defined: s/OIDs/textual conventions/ | TAddress ::= TEXTUAL-CONVENTION | STATUS current | DESCRIPTION | "Denotes a transport service address. | For dlswTCPDomain, a TAddress is 4 octets long, | containing the IP-address in network-byte order." | SYNTAX OCTET STRING (SIZE (0..255)) | | -- DLSw over TCP | dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 } | -- for an IP address of length 4: | -- | -- octets contents encoding | -- 1-4 IP-address network-byte order | -- | DlswTCPAddress ::= TEXTUAL-CONVENTION | DISPLAY-HINT "1d.1d.1d.1d" | STATUS current | DESCRIPTION | "Represents the IP address of a DLSw which uses | TCP as a transport protocol." | SYNTAX OCTET STRING (SIZE (4)) | | Additionally there are many OIDs that use a SYNTAX of TAddress within | the document. Interestingly the SYNTAX for TAddress is an OCTET | string of up to 256 characters. It could easily accommodate a similar | hybrid format for IPv6 addresses. above: s/OIDs/object definitions/ | A new OID to enhance functionality for DlswTCPAddress can be added | to support IPv6 addresses. above: s/OID/textual convention/, s/can/could/ | 5.037 RFC 2051 Definitions of Managed Objects for APPC using SMIv2 | (SNANAU-APP) s/SNANAU-APP/APPC-MIB/ | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.038 RFC 2096 IP Forwarding Table MIB (TABLE-MIB) s/TABLE-MIB/IP-FORWARD-MIB/ | This MIB defines many OIDs that are IPv4 dependent. It is expected | that another MIB for similar IPv6 addresses will be developed. Rewrite the last paragraph: The MIB module's main conceptual table ipCidrRouteTable uses IPv4 addresses as index objects and is therefore incapbable of representing an IPv6 forwarding information base. A new conceptual table needs to be defined to support IPv6 addresses. | 5.039 RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater | Devices using SMIv2 802 (3-MIB) s/3-MIB/SNMP-REPEATER-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.040 RFC 2127 ISDN Management Information Base using SMIv2 | (ISDN-MIB) | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.041 RFC 2128 Dial Control Management Information Base using | SMIv2 (DC-MIB) s/DC-MIB/DIAL-CONTROL-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.042 RFC 2206 RSVP Management Information Base using SMIv2 | (RSVP-MIB) | | All OIDs in this MIB have options for both IPv4 and IPv6. There | are no IPv4 dependencies in this specification. s/All OIDs/All of the relevant object definitions/ | 5.043 RFC 2213 Integrated Services Management Information | Base using SMIv2 | | This MIB is IPv6 aware and therefore there are no IPv4 | dependencies in this specification. | | | 5.044 RFC 2214 Integrated Services Management Information | Base Guaranteed Service Extensions using SMIv2 | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.045 RFC 2232 Definitions of Managed Objects for DLUR using | SMIv2 (DLUR-MIB) s/DLUR-MIB/APPN-DLUR-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.046 RFC 2238 Definitions of Managed Objects for HPR using | SMIv2 (HPR-MIB) | | There are no IPv4 dependencies in this specification. | | | 5.047 RFC 2266 Definitions of Managed Objects for IEEE 802.12 | Repeater Devices | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.048 RFC 2287 Definitions of System-Level Managed Objects for | Applications (SLM-APP) s/SLM-APP/SYSAPPL-MIB/ | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.049 RFC 2320 Definitions of Managed Objects for Classical IP | and ARP Over ATM Using SMIv2 (IPOA-MIB) (IPOA-MIB) Remove the second occurrence of "(IPOA-MIB)" | This MIB is wholly dependent of IPv4. A new MIB for IPv6 is | required to provide the same functionality | | | 5.050 RFC 2417 Definitions of Managed Objects for Multicast | over UNI 3.0/3.1 based ATM Networks | | There are many OIDs defined in this MIB which are IPv4 only. A | similar MIB for IPv6 OIDs should be created. Rewrite, by stealing from previous section: This MIB is wholly dependent of IPv4. A new MIB for IPv6 is required to provide the same functionality | 5.051 RFC 2452 IP Version 6 Management Information Base for the | Transmission Control Protocol | | This RFC documents an IPv6 MIB and is not considered in this | discussion. s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ | 5.052 RFC 2454 IP Version 6 Management Information Base for | the User Datagram Protocol | | This RFC documents an IPv6 MIB and is not considered in this | discussion. s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ | 5.053 RFC 2455 Definitions of Managed Objects for APPN | (APPN-MIB) | | There are no IPv4 dependencies in this specification. | | | 5.054 RFC 2456 Definitions of Managed Objects for APPN TRAPS | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.055 RFC 2457 Definitions of Managed Objects for Extended Border | Node (EBN-MIB) | | There are no IPv4 dependencies in this specification. | | | 5.056 RFC 2465 Management Information Base for IP Version 6: | Textual Conventions and General Group | | This RFC documents an IPv6 MIB and is not considered in this | discussion. s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ | 5.057 RFC 2466 Management Information Base for IP Version 6: | ICMPv6 Group (ICMPv6-MIB) s/ICMPv6-MIB/IPV6-ICMP-MIB/ | This RFC documents an IPv6 MIB and is not considered in this | discussion. s/an IPv6 MIB/a soon-to-be-obsoleted IPv6 MIB/ | 5.058 RFC 2493 Textual Conventions for MIB Modules Using | Performance History Based on 15 Minute Intervals | | There are no IPv4 dependencies in this specification. Note: this document is due to be replaced by RFC 3593, which will be a Draft Standard and will have the same title. | 5.059 RFC 2494 Definitions of Managed Objects for the DS0 | and DS0 Bundle Interface Type | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.060 RFC 2495 Definitions of Managed Objects for the DS1 E1 | DS2 and E2 Interface Types s/DS1 E1/DS1, E1,/ | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.061 RFC 2496 Definitions of Managed Object for the DS3/E3 | Interface Type (DS3-E3-MIB) s/(DS3-E3-MIB)/(DS3-MIB)/ | There are no IPv4 dependencies in this specification. s/protocol/specification/ | 5.062 RFC 2512 Accounting Information for ATM Networks | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.063 RFC 2513 Managed Objects for Controlling the Collection | and Storage of Accounting Information for Connection- | Oriented Networks | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.064 RFC 2514 Definitions of Textual Conventions and | OBJECT-IDENTITIES for ATM Management (ATM-TC-OID) s/ATM-TC-OID/ATM-TC-MIB/ | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.065 RFC 2515 Definitions of Managed Objects for ATM | Management (ATM-MIBMAN) s/ATM-MIBMAN/ATM-MIB/ | This MIB defines the following OIDs: s/OIDs/objects/ | AtmInterfaceConfEntry ::= SEQUENCE { | atmInterfaceMaxVpcs INTEGER, | atmInterfaceMaxVccs INTEGER, | atmInterfaceConfVpcs INTEGER, | atmInterfaceConfVccs INTEGER, | atmInterfaceMaxActiveVpiBits INTEGER, | atmInterfaceMaxActiveVciBits INTEGER, | atmInterfaceIlmiVpi AtmVpIdentifier, | atmInterfaceIlmiVci AtmVcIdentifier, | atmInterfaceAddressType INTEGER, | atmInterfaceAdminAddress AtmAddr, | atmInterfaceMyNeighborIpAddress IpAddress, | atmInterfaceMyNeighborIfName DisplayString, | atmInterfaceCurrentMaxVpiBits INTEGER, | atmInterfaceCurrentMaxVciBits INTEGER, | atmInterfaceSubscrAddress AtmAddr | } | | atmInterfaceMyNeighborIpAddress OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS read-write | STATUS current | DESCRIPTION | "The IP address of the neighbor system connected to | the far end of this interface, to which a Network | Management Station can send SNMP messages, as IP | datagrams sent to UDP port 161, in order to access | network management information concerning the | operation of that system. Note that the value | of this object may be obtained in different ways, | e.g., by manual configuration, or through ILMI | interaction with the neighbor system." | ::= { atmInterfaceConfEntry 11 } | | atmInterfaceConfGroup2 OBJECT-GROUP | OBJECTS { | atmInterfaceMaxVpcs, atmInterfaceMaxVccs, | atmInterfaceConfVpcs, atmInterfaceConfVccs, | atmInterfaceMaxActiveVpiBits, | atmInterfaceMaxActiveVciBits, | atmInterfaceIlmiVpi, | atmInterfaceIlmiVci, | atmInterfaceMyNeighborIpAddress, | atmInterfaceMyNeighborIfName, | atmInterfaceCurrentMaxVpiBits, | atmInterfaceCurrentMaxVciBits, | atmInterfaceSubscrAddress } | STATUS current | DESCRIPTION | "A collection of objects providing configuration | information about an ATM interface." | ::= { atmMIBGroups 10 } | | | Clearly a subsequent MIB must define equivalent IPv6 OIDs. s/subsequent MIB/subsequent revision of this MIB module/ s/OIDs/objects/ s/must/should/ | 5.066 RFC 2558 Definitions of Managed Objects for the SONET/SDH | Interface Type | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ Note: this document is due to be replaced by RFC 3592, which will be a Draft Standard and will have the title "Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type" | 5.067 RFC 2561 Base Definitions of Managed Objects for TN3270E | Using SMIv2 | | The document states: | | The MIB defined by this memo supports use of both IPv4 and IPv6 | addressing. | | This specification is both IPv4 and IPv6 aware. | | | 5.068 RFC 2562 Definitions of Protocol and Managed Objects for | TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) | (TN2370E-RT) remove "(TN3270E-RT)" at the end | Several OIDs rely on imports from RFC 2561 and therefore the | protocol is both IPv4 and IPv6 aware. rewrite: This MIB module inherits IP version-independence by virtue of importing the appropriate definitions from RFC 2561. | 5.069 RFC 2564 Application Management MIB (APP-MIB) s/APP-MIB/APPLICATION-MIB/ | The following OID is defined: s/OID/textual convention/ | ApplTAddress ::= TEXTUAL-CONVENTION | STATUS current | DESCRIPTION | "Denotes a transport service address. | | For snmpUDPDomain, an ApplTAddress is 6 octets long, | the initial 4 octets containing the IP-address in | network-byte order and the last 2 containing the UDP | port in network-byte order. Consult 'Transport Mappings | for Version 2 of the Simple Network Management Protocol | (SNMPv2)' for further information on snmpUDPDomain." | SYNTAX OCTET STRING (SIZE (0..255)) | | | A new OID should be defined to handle IPv6 addresses. s/OID/TC/ | 5.070 RFC 2576 Coexistence between Version 1 Version 2 and Version | 3 of the Internet-standard Network Management Framework (SNMP) remove "(SNMP)" | This document states: | | (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST | be changed to IpAddress. Note that the use of NetworkAddress in | new MIB documents is strongly discouraged (in fact, new MIB | documents should be written using SMIv2, which does not define | NetworkAddress). | | and defines the OID: s/OID/object/ | snmpTrapAddress OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS accessible-for-notify | STATUS current | DESCRIPTION | "The value of the agent-addr field of a Trap PDU which | is forwarded by a proxy forwarder application using | an SNMP version other than SNMPv1. The value of this | object SHOULD contain the value of the agent-addr field | from the original Trap PDU as generated by an SNMPv1 | agent." | ::= { snmpCommunityMIBObjects 3 } | | This clearly points out a lack of IPv6 awareness in this specification. That last sentence is incorrect. The presence of this stuff is not because the specification has a lack of IPv6 awareness; it is there because it is necessary to allow a MIB translator or a proxy forwarder to do its job ... and that job is to allow legacy versions of the SNMP (SNMPv1 and SNMPv2c, both now Historic protocols) to coexist with SNMPv3. I think Randy Presuhn has complained about this before. Here is the suggested replacement: Since purpose of this document is to describe how legacy specifications with IPv4 dependencies (SMIv1, SNMPv1, and SNMPv2c) can coexist with current ones (SMIv2 and SNMPv3), the IPv4 dependencies documented above are acceptable and, indeed, unavoidable. In addition, note that RFC 2576 has been replaced by RFC 3584, which is a BCP. So the title needs to changed, and sub-section itself needs to be moved. | 5.071 RFC 2564 Application Management MIB (APP-MIB) | | The following OID is defined: | | ApplTAddress ::= TEXTUAL-CONVENTION | STATUS current | DESCRIPTION | "Denotes a transport service address. | | For snmpUDPDomain, an ApplTAddress is 6 octets long, | the initial 4 octets containing the IP-address in | network-byte order and the last 2 containing the UDP | port in network-byte order. Consult 'Transport Mappings | for Version 2 of the Simple Network Management Protocol | (SNMPv2)' for further information on snmpUDPDomain." | SYNTAX OCTET STRING (SIZE (0..255)) | | | A new OID should be defined to handle IPv6 addresses. This sub-section is a duplicate of 5.069 and should be removed. | 5.072 RFC 2576 Coexistence between Version 1 Version 2 and Version | 3 of the Internet-standard Network Management Framework (SNMP) | | This document states: | | (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST | be changed to IpAddress. Note that the use of NetworkAddress in | new MIB documents is strongly discouraged (in fact, new MIB | documents should be written using SMIv2, which does not define | NetworkAddress). | | and defines the OID: | | snmpTrapAddress OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS accessible-for-notify | STATUS current | DESCRIPTION | "The value of the agent-addr field of a Trap PDU which | is forwarded by a proxy forwarder application using | an SNMP version other than SNMPv1. The value of this | object SHOULD contain the value of the agent-addr field | from the original Trap PDU as generated by an SNMPv1 | agent." | ::= { snmpCommunityMIBObjects 3 } | | This clearly points out a lack of IPv6 awareness in this specification. This sub-section is a duplicate of 5.070 and should be removed. | 5.073 RFC 2584 Definitions of Managed Objects for APPN/HPR in | IP Networks | | Many of the OIDs described in this document assume the use of the | IPv4 only TOS header bits. It is therefore IPv4 only in nature and | will not support IPv6 interfaces. An updated MIB should be created. s/OIDs/object definitions/ s/IPv4-only/ | 5.074 RFC 2591 Definitions of Managed Objects for Scheduling | Management Operations | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.075 RFC 2592 Definitions of Managed Objects for the Delegation | of Management Script | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.076 RFC 2594 Definitions of Managed Objects for WWW Services | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.077 RFC 2605 Directory Server Monitoring MIB | | There are no IPv4 dependencies in this specification. | | | 5.078 RFC 2613 Remote Network Monitoring MIB Extensions for | Switched Networks Version 1.0 | | There are no IPv4 dependencies in this specification. | | | 5.079 RFC 2618 RADIUS Authentication Client MIB | | This RFC defines the following OIDs: | | RadiusAuthServerEntry ::= SEQUENCE { | radiusAuthServerIndex Integer32, | radiusAuthServerAddress IpAddress, | radiusAuthClientServerPortNumber Integer32, | radiusAuthClientRoundTripTime TimeTicks, | radiusAuthClientAccessRequests Counter32, | radiusAuthClientAccessRetransmissions Counter32, | radiusAuthClientAccessAccepts Counter32, | radiusAuthClientAccessRejects Counter32, | radiusAuthClientAccessChallenges Counter32, | radiusAuthClientMalformedAccessResponses Counter32, | radiusAuthClientBadAuthenticators Counter32, | radiusAuthClientPendingRequests Gauge32, | radiusAuthClientTimeouts Counter32, | radiusAuthClientUnknownTypes Counter32, | radiusAuthClientPacketsDropped Counter32 | } | | radiusAuthServerAddress OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The IP address of the RADIUS authentication server | referred to in this table entry." | ::= { radiusAuthServerEntry 2 } | | There needs to be an update to allow an IPv6 based OID for this | value. | | | 5.080 RFC 2619 RADIUS Authentication Server MIB | | This MIB defines the followings OIDs: s/OIDs/objects/ | RadiusAuthClientEntry ::= SEQUENCE { | radiusAuthClientIndex Integer32, | radiusAuthClientAddress IpAddress, | radiusAuthClientID SnmpAdminString, | radiusAuthServAccessRequests Counter32, | radiusAuthServDupAccessRequests Counter32, | radiusAuthServAccessAccepts Counter32, | radiusAuthServAccessRejects Counter32, | radiusAuthServAccessChallenges Counter32, | radiusAuthServMalformedAccessRequests Counter32, | radiusAuthServBadAuthenticators Counter32, | radiusAuthServPacketsDropped Counter32, | radiusAuthServUnknownTypes Counter32 | } | | radiusAuthClientAddress OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The NAS-IP-Address of the RADIUS authentication client | referred to in this table entry." | ::= { radiusAuthClientEntry 2 } | | There needs to be an update to allow an IPv6 based OID for this | value. rewrite: This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses. | 5.081 RFC 2622 Routing Policy Specification Language (RPSL) | (RPSL) remove 2nd occurrence of "(RPSL)" | The only objects in the version of RPSL that deal with IP addresses | are defined as: | | An IPv4 address is represented as a sequence of four | integers in the range from 0 to 255 separated by the character dot | ".". For example, 128.9.128.5 represents a valid IPv4 address. | In the rest of this document, we may refer to IPv4 addresses as IP | addresses. | | An address prefix is represented as an IPv4 address | followed by the character slash "/" followed by an integer in the | range from 0 to 32. The following are valid address prefixes: | 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address | prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not | strings containing four integers. | | There seems to be an awareness of IPv6 because of the terminology but | it is not specifically defined. Therefore additional objects for IPv6 | addresses and masks need to be defined. | | | 5.082 RFC 2662 Definitions of Managed Objects for the ADSL | Lines (MIB) remove "(MIB)" | There are no IPv4 dependencies in this specification. | | | 5.083 RFC 2665 Definitions of Managed Objects for the | Ethernet-like Interface Types (MIB) s/MIB/EtherLike-MIB/ | There are no IPv4 dependencies in this specification. Note: this document is due to be replaced by draft-ietf-hubmib-etherif-mib-v3-03.txt, which the IESG recently approved as a Proposed Standard. When you issue an update of this draft, check the status of RFC 2665 to see if it has been replaced. | 5.084 RFC 2667 IP Tunnel MIB | | The Abstract of this document says: | | This memo defines a Management Information Base (MIB) for use with | network management protocols in the Internet community. In | particular, it describes managed objects used for managing tunnels of | any type over IPv4 networks. Extension MIBs may be designed for | managing protocol-specific objects. Likewise, extension MIBs may be | designed for managing security-specific objects. This MIB does not | support tunnels over non-IPv4 networks (including IPv6 networks). | Management of such tunnels may be supported by other MIBs. | | A similar MIB for tunneling over IPv6 should be defined. | | | 5.085 RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium | Attachment Units (MAUs) (MAU-MIB) | | There are no IPv4 dependencies in this specification. Note: this document is due to be replaced by draft-ietf-hubmib-mau-mib-v3-04.txt, which the IESG recently approved as a Proposed Standard. When you issue an update of this draft, check the status of RFC 2668 to see if it has been replaced. | 5.086 RFC 2669 DOCSIS Cable Device MIB Cable Device Management | Information Base for DOCSIS compliant Cable Modems and | Cable Modem Termination Systems | | This document states: | | Please note that the DOCSIS 1.0 standard only requires Cable | Modems to implement SNMPv1 and to process IPv4 customer traffic. | Design choices in this MIB reflect those requirements. Future | versions of the DOCSIS standard are expected to require support | for SNMPv3 and IPv6 as well. | | | 5.087 RFC 2670 Radio Frequency (RF) Interface Management Information | Base for MCNS/DOCSIS compliant RF interfaces (MIB) remove "(MIB)" | This MIB defines the following OIDs: s/OIDs/objects | DocsIfCmtsCmStatusEntry ::= SEQUENCE { | docsIfCmtsCmStatusIndex Integer32, | docsIfCmtsCmStatusMacAddress MacAddress, | docsIfCmtsCmStatusIpAddress IpAddress, | docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero, | docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero, | docsIfCmtsCmStatusRxPower TenthdBmV, | docsIfCmtsCmStatusTimingOffset Unsigned32, | docsIfCmtsCmStatusEqualizationData OCTET STRING, | docsIfCmtsCmStatusValue INTEGER, | docsIfCmtsCmStatusUnerroreds Counter32, | docsIfCmtsCmStatusCorrecteds Counter32, | docsIfCmtsCmStatusUncorrectables Counter32, | docsIfCmtsCmStatusSignalNoise TenthdB, | docsIfCmtsCmStatusMicroreflections Integer32 | } | | docsIfCmtsCmStatusIpAddress OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "IP address of this Cable Modem. If the Cable Modem has no | IP address assigned, or the IP address is unknown, this | object returns a value of 0.0.0.0. If the Cable Modem has | multiple IP addresses, this object returns the IP address | associated with the Cable interface." | ::= { docsIfCmtsCmStatusEntry 3 } | | IPv6 OIDs should be defined. Rewrite this last sentence: This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses. | 5.088 RFC 2674 Definitions of Managed Objects for Bridges with | Traffic Classes, Multicast Filtering and Virtual LAN | Extensions (MIB) s/(MIB)/(P-BRIDGE-MIB)/ | There are no IPv4 dependencies in this specification. | | | 5.089 RFC 2677 Definitions of Managed Objects for the NBMA Next | Hop Resolution Protocol (NHRP) (NHRP-MIB) | | There are no IPv4 dependencies in this specification. | | | 5.90 RFC 2720 Traffic Flow Measurement: Meter MIB | | This protocol is both IPv4 and IPv6 aware and needs no changes. s/protocol/specification/ | 5.091 RFC 2725 Routing Policy System Security | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.092 RFC 2726 PGP Authentication for RIPE Database Updates | | There are no IPv4 dependencies in this protocol. Is this actually an OPS Area specification? | 5.093 RFC 2737 Entity MIB (Version 2) | | The TAddress Syntax is used in this MIB which contains IPv4 | assumptions and need to be updated. | | entLogicalTAddress OBJECT-TYPE | SYNTAX TAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The transport service address by which the logical entity | receives network management traffic, formatted according to | the corresponding value of entLogicalTDomain. | | For snmpUDPDomain, a TAddress is 6 octets long, the initial | 4 octets containing the IP-address in network-byte order and | the last 2 containing the UDP port in network-byte order. | Consult 'Transport Mappings for Version 2 of the Simple | Network Management Protocol' (RFC 1906 [RFC1906]) for | further information on snmpUDPDomain." The statement that the TAddress SYNTAX value "contains IPv4 assumptions" is actually not correct. The TDomain/TAddress types allow for arbitrary transport domains and addresses to be represented. It is true that the DESCRIPTION clause quoted above spells out details only for snmpUDPDomain, but that does not mean that entLogicalTDomain and entLogicalTAddress can't represent IPv6 transport domains and addresses. See RFC 2579 and RFC 3419 for further information. I therefore propose to replace the preceding two paragraphs with this: There are no IPv4 dependencies in this specification. Note: this RFC is due to be replaced by draft-ietf-entmib-v3-03.txt or a successor; when published it will be a Draft Standard. Check ftp://ftp.isi.edu/in-notes/rfc-index.txt before updating this memo to determine if this has happened. | 5.094 RFC 2741 Agent Extensibility (AgentX) Protocol Version | 1 (SNMP) remove "(SNMP)" | This protocol contains definitions for IPv4 only objects, by reference | and all examples use only IPv4 addressing. However, there does not | seem to be any reason that it could not easily be modified to support | IPv6 addresses. I think that a more accurate statement would be: Although the examples in the document are for IPv4 transport only, there is no IPv4 dependency in the AgentX protocol itself. | 5.095 RFC 2742 Definitions of Managed Objects for Extensible SNMP | Agents | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.096 RFC 2748 The COPS (Common Open Policy Service) Protocol | (COPS) remove "(COPS)" | This protocol is both IPv4 and IPv6 aware and needs no changes. | | | 5.097 RFC 2749 COPS usage for RSVP | | There are no IPv4 dependencies in this protocol. | | 5.098 RFC 2769 Routing Policy System Replication (RPSL) remove "(RPSL)" | There are no IPv4 dependencies in this protocol. Is this an OPS Area spec? It looks like a routine area spec to me. | 5.099 RFC 2787 Definitions of Managed Objects for the Virtual | Router Redundancy Protocol | | As stated in the Overview section: | | Since the VRRP protocol is intended for use with IPv4 routers only, | this MIB uses the SYNTAX for IP addresses which is specific to IPv4. | Thus, changes will be required for this MIB to interoperate in an | IPv6 environment. | | | 5.100 RFC 2788 Network Services Monitoring MIB | | There are no IPv4 dependencies in this specification. | | | 5.101 RFC 2789 Mail Monitoring MIB | | There are no IPv4 dependencies in this specification. | | | 5.102 RFC 2837 Definitions of Managed Objects for the Fabric Element | in Fibre Channel Standard | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.103 RFC 2851 Textual Conventions for Internet Network Addresses | | This MIB defines a new set of OIDs for that allow new MIB's to | use multiple versions of IP. Currently IPv4 and IPv6 addressing | is defined. Update of the many MIBs previously identified as | having IPv4 dependencies could easily be updated using this new | set of IP address abstractions. This document has been replaced by RFC 3291 (also a proposed standard). Please update this subsection accordingly. | 5.104 RFC 2856 Textual Conventions for Additional High Capacity | Data Types (SNMP) remove "(SNMP)" | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.105 RFC 2864 The Inverted Stack Table Extension to the Interfaces | Group MIB | | There are no IPv4 dependencies in this specification. | | | 5.106 RFC 2895 Remote Network Monitoring MIB Protocol Identifier | Reference (RMON-MIB) remove "(RMON-MIB)" | This MIB is both IPv4 and IPv6 aware and needs no changes. s/MIB/specification/ (the document does not contain a MIB module) | 5.107 RFC 2925 Definitions of Managed Objects for Remote | Ping, Traceroute, and Lookup Operations | | This MIB mostly is IPv4 and IPv6 aware. There are a few | assumptions that are problems thought. In the following OIDs: s/problems thought./problems, though./ s/OIDs/object definitions/ | pingCtlDataSize OBJECT-TYPE | SYNTAX Unsigned32 (0..65507) | UNITS "octets" | MAX-ACCESS read-create | STATUS current | DESCRIPTION | "Specifies the size of the data portion to be | transmitted in a ping operation in octets. A ping | request is usually an ICMP message encoded | into an IP packet. An IP packet has a maximum size | of 65535 octets. Subtracting the size of the ICMP | or UDP header (both 8 octets) and the size of the IP | header (20 octets) yields a maximum size of 65507 | octets." | DEFVAL { 0 } | ::= { pingCtlEntry 5 } | | | traceRouteCtlDataSize OBJECT-TYPE | SYNTAX Unsigned32 (0..65507) | UNITS "octets" | MAX-ACCESS read-create | STATUS current | DESCRIPTION | "Specifies the size of the data portion of a traceroute | request in octets. A traceroute request is essentially | transmitted by encoding a UDP datagram into a | IP packet. So subtracting the size of a UDP header | (8 octets) and the size of a IP header (20 octets) | yields a maximum of 65507 octets." | DEFVAL { 0 } | ::= { traceRouteCtlEntry 6 } | | There is clearly an assumption of IPv4 header sizes. Please rewrite this last sentence: The DESCRIPTION clauses need to be updated to remove the IPv4 dependencies. Note that there is nothing wrong with the objects themselves. | 5.108 RFC 2932 IPv4 Multicast Routing MIB | | This specification is only defined for IPv4 and a similar MIB | must be defined for IPv6. | | | 5.109 RFC 2933 Internet Group Management Protocol MIB | | As stated in this document: | | Since IGMP is specific to IPv4, this MIB does not support management | of equivalent functionality for other address families, such as IPv6. | | | 5.110 RFC 2940 Definitions of Managed Objects for Common | Open Policy Service (COPS) Protocol Clients | | This MIB is both IPv4 and IPv6 aware and needs no changes. | | | 5.111 RFC 2954 Definitions of Managed Objects for Frame | Relay Service (FR-MIB) s/FR-MIB/FRNETSERV-MIB/ | There are no IPv4 dependencies in this specification. | | | 5.112 RFC 2955 Definitions of Managed Objects for Monitoring | and Controlling the Frame Relay/ATM PVC Service | Interworking Function | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.113 RFC 2959 Real-Time Transport Protocol Management | Information Base | | There are numerous uses of the included TAddress Syntax which is | IPv4 dependent as noted above. | | For example: | | rtpSessionRemAddr OBJECT-TYPE | SYNTAX TAddress | MAX-ACCESS read-create | STATUS current | DESCRIPTION | "The address to which RTP packets are sent by the RTP system. | In an IP multicast RTP session, this is the single address used | by all senders and receivers of RTP session data. In a unicast | RTP session this is the unicast address of the remote RTP system. | 'The destination address pair may be common for all participants, | as in the case of IP multicast, or may be different for each, as | in the case of individual unicast network address pairs.' See | RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' | sec. 3. The transport service is identified by rtpSessionDomain. | For snmpUDPDomain, this is an IP address and even-numbered UDP | Port with the RTCP being sent on the next higher odd-numbered | port, see RFC 1889, sec. 5." | ::= { rtpSessionEntry 3 } | | There are a total of 8 instances of this. As explained above under 5.093, this does not necessarily mean that there is an IPv4 dependency. Please re-evaluate this MIB module and update this section accordingly. I'd bet that this spec doesn't really have any IPv4 dependencies after all. | 5.114 RFC 2981 Event MIB | | There are no IPv4 dependencies in this specification. | | | 5.115 RFC 2982 Distributed Management Expression MIB | | There are no IPv4 dependencies in this specification. | | | 5.116 RFC 3014 Notification Log MIB | | This document contains OIDs that are IPv4 specific: | | nlmLogVariableIpAddressVal OBJECT-TYPE | SYNTAX IpAddress | MAX-ACCESS read-only | STATUS current | DESCRIPTION | "The value when nlmLogVariableType is 'ipAddress'. | Although this seems to be unfriendly for IPv6, we | have to recognize that there are a number of older | MIBs that do contain an IPv4 format address, known | as IpAddress. | | IPv6 addresses are represented using TAddress or | InetAddress, and so the underlying datatype is | OCTET STRING, and their value would be stored in | the nlmLogVariableOctetStringVal column." | ::= { nlmLogVariableEntry 9 } | | | Not withstanding the note in the DESCRIPTION. THIS DOES NOT CONSTITUTE AN IPv4 DEPENDENCY. As explained in previous comments to one of the authors, this MIB module has the means to represent in a log ANY object syntax that is allowed by the SNMP and the SMI. The fact that it can represent objects of type IpAddress in a log does NOT make it IPv4-specific or IPv6-unfriendly, as the last paragraph in the above DESCRIPTION clause makes amply clear. So, please remove ALL of the verbiage in the section and say instead: There are no IPv4 dependencies in this specification. | 5.117 RFC 3019 IP Version 6 Management Information Base for | The Multicast Listener Discovery Protocol | | This is an IPv6 related document and is not discussed in this | document. | | | 5.118 RFC 3020 Definitions of Managed Objects for Monitoring | and Controlling the UNI/NNI Multilink Frame Relay Function | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.119 RFC 3055 Management Information Base for the PINT Services | Architecture | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.120 RFC 3060 Policy Core Information Model -- Version 1 | Specification (CIM) | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 5.121 RFC 3084 COPS Usage for Policy Provisioning (COPS-PR) | (COPS-PR) remove redundant "(COPS-PR)" | This is an IPv4 only protocol. A version for IPv6 must be defined. s/must be/may ned to be/ | 6.0 Experimental RFCs | | Experimental RFCs typically define protocols that do not have widescale | implementation or usage on the Internet. They are often propriety in | nature or used in limited arenas. They are documented to the Internet | community in order to allow potential interoperability or some other | potential useful scenario. In a few cases they are presented as | alternatives to the mainstream solution to an acknowledged problem. | | | 6.01 RFC 1187 Bulk Table Retrieval with the SNMP (SNMP-BULK) | | There are no IPv4 dependencies in this protocol. | | | 6.02 RFC 1224 Techniques for managing asynchronously generated | alerts (ALERTS) | | There are no IPv4 dependencies in this protocol. | | | 6.03 RFC 1238 CLNS MIB for use with Connectionless Network Protocol | (ISO 8473) and End System to Intermediate System (ISO 9542) | (CLNS-MIB) | | There are no IPv4 dependencies in this specification. | | | 6.04 RFC 1592 Simple Network Management Protocol Distributed Protocol | Interface Version 2.0 (SNMP-DPI) | | There are no IPv4 dependencies in this protocol. | | | 6.05 RFC 1792 TCP/IPX Connection Mib Specification (TCP/IPXMIB) s?TCP/IPXMIB?TCPIPX-MIB? | There are no IPv4 dependencies in this specification. s/protocol/specification/ | 6.06 RFC 1901 Introduction to Community-based SNMPv2 (SNMPV2CB) | | There are no IPv4 dependencies in this protocol. RFC 1901 is now HISTORIC and should be dropped from this survey. | 6.07 RFC 1909 An Administrative Infrastructure for SNMPv2 | (SNMPV2AI) | | There are no IPv4 dependencies in this protocol. RFC 1909 is now HISTORIC and should be dropped from this survey. | 6.08 RFC 1910 User-based Security Model for SNMPv2 (SNMPV2SM) | | There are no IPv4 dependencies in this protocol. RFC 1910 is now HISTORIC and should be dropped from this survey. | 6.09 RFC 2593 Script MIB Extensibility Protocol Version 1.0 | | There are no IPv4 dependencies in this specification. This document has been obsoleted by RFC 3179, which specifies Version 1.1 of the protocol. Please update this section accordingly. | 6.10 RFC 2724 RTFM: New Attributes for Traffic Flow Measurement | | There are no IPv4 dependencies in this protocol. | | | 6.11 RFC 2758 Definitions of Managed Objects for Service Level | Agreements Performance Monitoring | | This protocol is both IPv4 and IPv6 aware and needs no changes. s/protocol/specification/ | 6.12 RFC 2786 Diffie-Helman USM Key Management Information Base and | Textual Convention | | There are no IPv4 dependencies in this protocol. s/protocol/specification/ | 6.13 RFC 2903 Generic AAA Architecture | | There are no IPv4 dependencies in this protocol. | | | 6.14 RFC 2934 Protocol Independent Multicast MIB for IPv4 | | This document is specific to IPv4. | | | 7.0 Summary of Results | | In the initial survey of RFCs 41 positives were identified out of a | total of 163, broken down as follows: | | Standards 6 of 10 or 60.00% | Draft Standards 3 of 18 or 16.67% | Proposed Standards 31 of 121 or 25.62% | Experimental RFCs 1 of 14 or 7.14% | | Of those identified many require no action because they document | outdated and unused protocols, while others are document protocols | that are actively being updated by the appropriate working groups. | Additionally there are many instances of standards that should be | updated but do not cause any operational impact if they are not | updated. The remaining instances are documented below. This may need to be updated based on corrections above. I've not checked it. | 7.1 Standards | | | 7.1.1 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) | | The limitations identified have been addressed; RFC 1157 is HISTORIC, | RFC1155 is obsoleted by RFC 2578-2580, and RFC1213 has been split to | multiple modules which have been seen to. The above actually concerns three separate STDs. STD 15, RFC 1157, is SNMPv1, but it has been retired ... that is, it has been reclassified as HISTORIC and therefore is no longer an Internet Standard. So it should be dropped from the survey. STD 16, RFCs 1155 and 1212, is SMIv1. Officially it's still in force, although it's no longer used for new work. Note that RFC 1215 is part of the same document set, although it is an Informational RFC. STD 17, RFC 1213, is MIB-II. Officially it's still in force, but the parts which are still relevant have been or are being replaced. So I would suggest replacing the above with something along these lines: 7.1.1 STD 16, Structure of Management Information (RFCs 1155 and 1212) RFCs 1155 and RFCs 1212 (along with the informational document RFC 1215) define SMIv1. These documents have been superseded by RFCs 2578, 2579, and 2580 which define SMIv2. Since SMIv1 is no longer being used as the basis for new IETF MIB modules, the limitations identified in this Internet Standard do not require any action. 7.1.2 STD 17, Management Information Base MIB II (RFC 1213) The limitations identified are being addressed: the IP group, the ICMP group, the TCP group, and the UDP group are being replaced by IP version-independent MIB modules now in development in the IPv6 working group (for more details see the entries below for RFCs 2011, 2012, 2013, and 2096). No replacement is being contemplated for the EGP group because EGP is a historic protocol that is no longer in significant use in the Internet. | 7.2 Draft Standards | | | 7.2.1 BGP4 MIB (RFC 1657) | | This problem is currently being addressed by the Inter Domain Routing | (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt). s/draft-ietf-idr-bgp4-mib-09.txt/draft-ietf-idr-bgp4-mib-11.txt/ | 7.2.2 SMDS MIB (RFC 1694) | | See Section 7.1.22. Once a specification for IPv6 over SMDS is | created a new MIB must be defined. Where is Section 7.1.22? I agree with the 2nd sentence, BTW, if "must" is changed to "should"; it stands alone quite nicely. | 7.2.3 RIPv2 MIB (RFC 1724) | | See Section 7.1.24. This problem is currently being addressed by the | RIP WG and an ID exists (draft-ietf-rip-mib-01.txt). Where is Section 7.1.24? I agree with the 2nd sentence, except that the draft is now draft-ietf-rip-mib-01.txt; it stands alone quite nicely. | 7.2.4 OSPFv2 MIB (RFC 1850) | | This problem is currently being addressed by the OSPF WG and an ID | exists (draft-ietf-ospf-ospfv3-mib-04.txt). s/draft-ietf-ospf-ospfv3-mib-04.txt/draft-ietf-ospf-ospfv3-mib-07.txt/ | 7.2.5 Transport MIB (RFC 1906) s/Transport MIB/Transport Mappings for SNMP/ s/1906/3417/ | The problem has been fixed in RFC 2454, IPv6 Management Information | Base for the User Datagram Protocol. RFC 1906 has been replaced by 3417, and RFC 2454 is irrelevant. So, move this section to the Full Standards part, change the section heading, to point to RFC 3417, and rewrite the text as follows: The limitations of this specification have been addressed by RFC 3419, which defines TCs that can be used to specify transport domains in an IP version-independent way. RFC 3419 recommends that those TCs be used in place of SnmpUDPAddress when IPv6 support is required and for all new applications that are not SNMP-specific. | 7.2.6 Frame Relay MIB (RFC 2115) | | The problem has been fixed in RFC 2954, Definitions of Managed Objects | for Frame Relay Service. This section should be deleted. As noted above, there is actually no problem with RFC 2115 to begin with; and anyway, 2115 is the MIB module for Frame Relay DTEs whilst 2954 is the MIB module for the Frame Relay service implemented on network elements. | 7.3 Proposed Standards | | | 7.3.01 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) | | This problem has not been addressed. A new specification should | be created. rewrite: This problem has not been addressed. If a user requirement for IPv6 over X.25 develops (which is thought to be unlikely) then this MIB module will need to be updated in order to accomodate it. Note that the analysis in Section 6 suggests that a whole new MIB module isn't necessary, just updates to some object definitions. | 7.3.02 PPP IPCP MIB (RFC 1473) | | There is no updated MIB to cover the problems outlined. A new MIB | must be defined. s/must/should/ | 7.3.03 DNS Server MIB (RFC 1611) | | This document is HISTORIC and no action is required. If it's HISTORIC it's not a Proposed Standard anymore. Drop it from the survey. | 7.3.04 DNS Resolver MIB (RFC 1612) | | This document is HISTORIC and no action is required. If it's HISTORIC it's not a Proposed Standard anymore. Drop it from the survey. | 7.3.05 Appletalk MIB (RFC 1742) | | The problems have not been addressed and a new MIB should be defined. rewrite: This problem has not been addressed. If a user requirement for IPv6 over Appletalk develops (which is thought to be unlikely) then this MIB module will need to be updated (or a new MIB module will need to be created) in order to accomodate it. | 7.3.06 The Definitions of Managed Objects for IP Mobility | Support using SMIv2 (RFC 2006) | | The problems are being resolved by the Mobile IP WG and there is | an ID (draft-ietf-mobileip-rfc2006bis-00.txt) s/draft-ietf-mobileip-rfc2006bis-00.txt/draft-ietf-mobileip-rfc2006bis-02.txt/ | 7.3.07 SMIv2 MIB IP (RFC 2011) s/SMIv2 MIB IP/SMIv2 IP MIB/ | The problems have been addressed in RFC 2851, Textual Conventions | for Internet Network Addresses, and RFC 2465, Management Information | Base for IP Version 6: Textual Conventions and General Group. RFC 2851 has been replaced by RFC 3291, and RFC 2465 is going to be replaced because implementation experience has indicated that it was the wrong approach. I therefore recommend that the above paragraph be rewritten as follows: This issue is being resolved by the IPv6 WG and there is an ID (draft-ietf-ipv6-rfc2011-update-03.txt). Note: please insert the tag for the latest version of the I-D; my understanding is that -04 is expected "any day now" with changes to resolve WG last call comments. | 7.3.08 SNMPv2 MIB TCP (RFC 2012) s/SNMPv2 MIB TCP/SMIv2 TCP MIB/ | The problems have been addressed in RFC 2452, IPv6 Management | Information Base for the Transmission Control Protocol. RFC 2452 is headed to the dustbin, so pls rewrite: This issue is being resolved by the IPv6 WG and there is an ID (draft-ietf-ipv6-rfc2012-update-03.txt). Note: insert that tag for the latest version of the I-D; my understanding is that -04 is expected "any day now" with changes to resolve WG last call comments. | 7.3.09 SNMPv2 MIB UDP (RFC 2013) s/SNMPv2 MIB UDP/SMIv2 UDP MIB/ | The problems have been addressed in RFC 2454, IPv6 Management | Information Base for the User Datagram Protocol. RFC 2454 is headed for dustbin, so pls rewrite: This issue is being resolved by the IPv6 WG. At this time there is no I-D: draft-ietf-ipv6-rfc2013-update-00.txt did exist but it has expired. A new version has been promised; the main obstacle is lack of an editor (volunteers welcome). | 7.3.10 RMON MIB (RFC 2021)? s/RMON MIB/RMON-II MIB/ remove question mark | The problems have been addressed in RFC 2819, Remote Network | Monitoring Management Information Base. That is false: RFC 2021 is RMON-II, and RFC 2819 is the full standard version of RMON-I (formerly RFCs 1271 and 1757). There is a work underway to update RFC 2021, however; so the correct statement is probably this: This issue is being resolved by the RMONMIB WG and there is an ID (draft-ietf-rmonmib-rmon2-v2-00.txt). In fact draft-ietf-rmonmib-rmon2-v2-00.txt doesn't actually address the problem but I have raised the issue on the RMONMIB mailing list. | 7.3.11 DataLink Switching using SMIv2 MIB (RFC 2022) s/2022/2024/ Note: RFC 2022 is the multicast over ATM spec (MARS and so on) | The problems have not been addressed and a new MIB should be | defined. s/a new/an updated/ | 7.3.12 IP Forwarding Table MIB (RFC 2096) | | This issue is being worked on by the IPv6 WG and an ID exists to | address this (draft-ietf-ipngwg-rfc2096-update-00.txt) s/draft-ietf-ipngwg-rfc2096-update-00.txt/draft-ietf-ipv6-rfc2096-update-05.txt/ (it was posted on 29 Aug 2003, should be listed on IPv6 WG charter page by now) | 7.3.13 Classical IP & ARP over ATM MIB (RFC 2320) | | The problems identified are not addressed and a new MIB must be | defined. The previous paragraph should be rewritten along the following lines: The current version of Classical IP and ARP over ATM (RFC xxxx) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module. | 7.3.14 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) | | The problems identified are not addressed and a new MIB must be | defined. The previous paragraph should be rewritten along the following lines: The current version of Multicast over UNI 3.0/3.1 ATM (RFC xxxx) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module. | 7.3.15 ATM MIB (RFC 2515) | | The problems identified are not addressed and a new MIB must be | defined. rewrite: The AToM MIB WG is currently collecting implementation reports for RFC 2515 and is considering whether to advance, revise, or retire this specification. The problems identified have been brought to the attention of the WG. I know that last sentence is true, since I just sent a message to that effect to atommib@research.telcordia.com :-) | 7.3.16 TN3270 MIB (RFC 2562) | | The problems identified are not addressed and a new MIB may be | defined. rewrite: The problems identified are not being addressed and a new MIB module may need to be defined. | 7.3.17 Application MIB (RFC 2564) | | The problems identified are not addressed and a new MIB may be | defined. | One possible solution is to use RFC 3419 TCs. rewrite: The problems identified are not being addressed and a new MIB module may need to be defined. One possible solution might be to use the RFC 3419 TCs. | 7.3.18 Coexistence of SNMP v1, v2, & v3 (RFC 2576) | | There are no real issues that can be resolved. rewrite: There are no issues that need to be resolved. Note also that the coex doc is now RF 3584, which is a BCP. | 7.3.19 Definitions of Managed Objects for APPN/HPR in IP Networks | (RFC 2584) | | The problems identified are not addressed and a new MIB may be | defined. | | | 7.3.20 RADIUS MIB (RFC 2618) | | The problems have not been addressed and a new MIB should be defined. | | | 7.3.21 RADIUS Authentication Server MIB (RFC 2619) | | The problems have not been addressed and a new MIB should be defined. | | | 7.3.22 IPv4 Tunnel MIB (RFC 2667) | | The problems have not been addressed and a new MIB should be defined. | | | 7.3.23 DOCSIS MIB (RFC 2669) | | This problem is currently being addressed by the IPCDN WG and an ID | is available (draft-ietf-ipcdn-device-mibv2-01.txt). s/draft-ietf-ipcdn-device-mibv2-01.txt/draft-ietf-ipcdn-device-mibv2-05.txt/ | 7.3.24 RF MIB For DOCSIS (RFC 2670) | | This problem is currently being addressed by the IPCDN WG and an ID | is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt). s/draft-ietf-ipcdn-docs-rfmibv2-01.txt/draft-ietf-ipcdn-docs-rfmibv2-06.txt/ | 7.3.25 Entity MIB Version 2 (RFC 2737) | | The problems have not been addressed and a new MIB should be defined. Delete the above paragraph, as there really are no problems in the ENTITY-MIB. | 7.3.26 AgentX Protocol V1 (RFC 2741) | | The problems have not been addressed and a new protocol may be | defined. Delete the above paragraph, as there really are no problems in the AgentX protocol. | 7.3.27 VRRP MIB (RFC 2787) | | The problems have not been addressed and a new MIB should be defined. | | | 7.3.28 MIB For Traceroute, Pings and Lookups (RFC 2925) | | The problems have not been addressed and a new MIB may be defined. s/may be/may need to be/ | 7.3.29 IPv4 Multicast Routing MIB (RFC 2932) | | This problem is currently being addressed by the IDR WG and several | IDs exist. | | | 7.3.30 IGMP MIB (RFC 2933) | | This problem is currently being addressed by the IDR WG. | | | 7.3.31 RPSL (RFC 2622) | | Additional objects must be defined for IPv6 addresses and prefixes. s/must/should/ | 7.4 Experimental RFCs | | | 7.4.1 Protocol Independent Multicast MIB for IPv4 (RFC 2934) | | The problems have not been addressed and a new MIB should be defined. s/should be/may need to be/ This concludes my comments on draft-ietf-v6ops-ipv4survey-ops-02.txt. Regards, Mike Heard