From owner-v6ops@ops.ietf.org Sun Feb 2 12:25: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 MAA09148 for ; Sun, 2 Feb 2003 12:25:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fNsc-000MEN-00 for v6ops-data@psg.com; Sun, 02 Feb 2003 09:26:06 -0800 Received: from pop-ls-09-1-dialup-193.freesurf.ch ([194.230.235.193] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18fNsW-000ME9-00 for v6ops@ops.ietf.org; Sun, 02 Feb 2003 09:26:02 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h12HQihE022838; Sun, 2 Feb 2003 18:26:45 +0100 (CET) Date: Sat, 1 Feb 2003 11:06:17 +0100 Subject: Re: agenda items for v6ops in San Francisco Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Pekka Savola , v6ops@ops.ietf.org To: Randy Bush From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.6 required=5.0 tests=DATE_IN_PAST_24_48,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> As a general note, I think we should try to discuss "transition >> architecture" in a more aggregated fashion: now it has spread all >> over the >> analysis documents (consider e.g. NAT/PT vs dual-stack etc.). >> >> One way trying to get some coherence here might be to try to have some >> discussion (like 10-20 mins) on some specific topics before (or >> after) the >> scenarios. > > this has some appeal. also, i think a generic discussion of they > types of > security issues raised by transition mechanisms might be worthwhile. i > suspect that we would benefit from a common and consistent story for > both of > these. > I agree with Randy and Pekka, but a small remark - what do we want the outcome to be? An I-D containing an overview aka the site-local I-Ds? - kurtis - From owner-v6ops@ops.ietf.org Mon Feb 3 15:40: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 PAA20910 for ; Mon, 3 Feb 2003 15:40:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fnNv-000NRK-00 for v6ops-data@psg.com; Mon, 03 Feb 2003 12:40:07 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18fnNn-000NQV-00 for v6ops@ops.ietf.org; Mon, 03 Feb 2003 12:39:59 -0800 Received: from esunmail ([129.147.58.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27202 for ; Mon, 3 Feb 2003 13:39:58 -0700 (MST) Received: from xpa-fe1 (esunmail-ge0 [129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0H9R00L9G2QL6M@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Mon, 03 Feb 2003 13:39:58 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0H9R00B782QKD8@mail.sun.net> for v6ops@ops.ietf.org; Mon, 03 Feb 2003 13:39:57 -0700 (MST) Date: Mon, 03 Feb 2003 12:39:55 -0800 From: Alain Durand Subject: Re: agenda items for SF ? ISPs document To: MicklesCK Cc: Jun-ichiro itojun Hagino , Margaret Wasserman , JORDI PALET MARTINEZ , v6ops@ops.ietf.org Message-id: <3E3ED39B.80704@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_00_01, TO_LOCALPART_EQ_REAL,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT MicklesCK wrote: > We do not have an author for the datacenter >section. I propose we drop the additional datacenter >section since, as I pointed out at the interim meeting, there >would be overlap with the Enterprise draft. > One point I would like to raise about IPv6 in the datacenter is load balancers. They basically are NAT boxes dispatching the traffic to a number of servers. Are we going to need NATv6 afterall? Anyway, I think this concern is specific to the big datacenter and should be addressed in the ISP scenario. - Alain. From owner-v6ops@ops.ietf.org Mon Feb 3 16:22:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22215 for ; Mon, 3 Feb 2003 16:22:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fo67-000PWm-00 for v6ops-data@psg.com; Mon, 03 Feb 2003 13:25:47 -0800 Received: from e32.co.us.ibm.com ([32.97.110.130]) by psg.com with esmtp (Exim 3.36 #1) id 18fo64-000PWZ-00 for v6ops@ops.ietf.org; Mon, 03 Feb 2003 13:25:44 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h13LPg2d048624; Mon, 3 Feb 2003 16:25:43 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h13LPfSe162176; Mon, 3 Feb 2003 14:25:41 -0700 In-Reply-To: <3E3ED39B.80704@sun.com> To: Alain Durand Cc: v6ops@ops.ietf.org Subject: Re: agenda items for SF ? ISPs document MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: Roy Brabson X-MIMETrack: S/MIME Sign by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 02/03/2003 04:25:27 PM, Serialize by Notes Client on Roy Brabson/Raleigh/IBM(Release 6.0|September 26, 2002) at 02/03/2003 04:25:27 PM, Serialize complete at 02/03/2003 04:25:27 PM, S/MIME Sign failed at 02/03/2003 04:25:27 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/03/2003 14:25:41, Serialize complete at 02/03/2003 14:25:41 Message-ID: Date: Mon, 3 Feb 2003 16:25:40 -0500 Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > One point I would like to raise about IPv6 in the datacenter > is load balancers. They basically are NAT boxes dispatching the traffic > to a number of servers. Are we going to need NATv6 afterall? I guess that depends on the load balancing device. I'm familiar with many which do not use NAT for dispatching traffic. Instead, the load balancer(s) advertise a server address to which client traffic is directed. Each server which is part of the load balancing group also defines the same address, but in a manner such that the address is not advertised if the server is running dynamic routing protocol. Depending on the proximity of the load balancer to the servers, the load balancer may rewrite the destination MAC address to direct the packet to the chosen server or may use some form of tunneling (such as GRE) to send the packet to the chosen server. Neither approach requires the use of NAT. > Anyway, I think this concern is specific to the big datacenter > and should be addressed in the ISP scenario. I don't agree, at least not for the enterprise customers I work with. Many use and deploy load balancers within the datacenter and do not rely on the ISP to provide this type of service. I would see this as belonging within the Enterprise scenario document instead of the ISP scenario document. Roy From owner-v6ops@ops.ietf.org Mon Feb 3 17:06: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 RAA23344 for ; Mon, 3 Feb 2003 17:06:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18folP-0001kE-00 for v6ops-data@psg.com; Mon, 03 Feb 2003 14:08:27 -0800 Received: from x98a3a62e.pix.aol.com ([152.163.166.46] helo=mailbox.office.aol.com) by psg.com with esmtp (Exim 3.36 #1) id 18folN-0001jg-00 for v6ops@ops.ietf.org; Mon, 03 Feb 2003 14:08:25 -0800 Received: from pcsn630877 (micklesck2-2p05.office.aol.com [10.0.31.6]) by mailbox.office.aol.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id RAA10131; Mon, 3 Feb 2003 17:07:30 -0500 (EST) Reply-To: From: "Cleve Mickles" To: "MicklesCK" , "Alain Durand" Cc: , "JORDI PALET MARTINEZ" , "Margaret Wasserman" , "Jun-ichiro itojun Hagino" Subject: RE: agenda items for SF ? ISPs document Date: Mon, 3 Feb 2003 17:08:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3E3ED39B.80704@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, TO_LOCALPART_EQ_REAL,USER_AGENT_OUTLOOK version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've asked existing L4 vendors about this over the past year and even though this is widely done in the IPv4 world, the vendors don't have any plans to add this IPv6 functionality until market forces dictate it. From what I see today, the only alternative is to use DNS to load balance. We know using DNS to load balance won't give us the best performance. We also will probably run into the same UDP packet size limits with IPv4 DNS rotors. It does however gives us something to work with until we have a critical mass of IPv6 capable servers which we can then go to the vendors and ask them to give us the functionality. NATv6 is a possible solution and the WG may decide that is the best recommendation in the long run. The vendors will probably end up doing their own proprietary solutions as I have not seem many interoperable L4 load balancers to date. I would assume the work on NATv6 would be done in the IPv6 WG. Whether we describe this in the ISP document or Enterprise document is up to the WG. At the interim meeting the WG wanted a datacenter description in both, at last IETF the status of whether to include datacenters in the ISP scenarios was inconclusive. In any event, no authors have come forward to work on the section so it will not be included unless the WG feels it should be retained and someone steps forward. Cleve... > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Alain Durand > Sent: Monday, February 03, 2003 3:40 PM > To: MicklesCK > Cc: Jun-ichiro itojun Hagino; Margaret Wasserman; JORDI PALET MARTINEZ; > v6ops@ops.ietf.org > Subject: Re: agenda items for SF ? ISPs document > > > > > MicklesCK wrote: > > > We do not have an author for the datacenter > >section. I propose we drop the additional datacenter > >section since, as I pointed out at the interim meeting, there > >would be overlap with the Enterprise draft. > > > One point I would like to raise about IPv6 in the datacenter > is load balancers. They basically are NAT boxes dispatching the traffic > to a number of servers. Are we going to need NATv6 afterall? > > Anyway, I think this concern is specific to the big datacenter > and should be addressed in the ISP scenario. > > - Alain. > > > > > From owner-v6ops@ops.ietf.org Tue Feb 4 08:58: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 IAA22572 for ; Tue, 4 Feb 2003 08:58:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g3bf-000H4a-00 for v6ops-data@psg.com; Tue, 04 Feb 2003 05:59:23 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18g3bV-000H42-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 05:59:13 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h14DwqH3056180; Tue, 4 Feb 2003 14:59:02 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h14DwkHF080338; Tue, 4 Feb 2003 14:58:50 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27026 from ; Tue, 4 Feb 2003 14:58:44 +0100 Message-Id: <3E3FC6E5.F9A8B348@hursley.ibm.com> Date: Tue, 04 Feb 2003 14:57:57 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: micklesc@aol.net, v6ops@ops.ietf.org Subject: Re: agenda items for SF ? ISPs document References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Cleve Mickles wrote: ... > NATv6 is a possible solution and the WG may decide that is the best > recommendation in the long run. Only over numerous dead bodies. As Roy Brabson pointed out, this is by no means a requirement for server load balancing (and wouldn't be too helpful if you happened to be using IPSEC or any other address-sensitive protocol). Also, I can't see why it would become an IETF recommendation anyway. IPv4 load balancing is widely implemented without any help from the IETF. We just need to avoid making it harder. Certainly, this topic belongs in the enterprise scenario. Brian From owner-v6ops@ops.ietf.org Tue Feb 4 09:50: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 JAA24245 for ; Tue, 4 Feb 2003 09:50:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g4Rn-000JYC-00 for v6ops-data@psg.com; Tue, 04 Feb 2003 06:53:15 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18g4Rk-000JXz-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 06:53:12 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18g4Rj-0000Gd-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 09:53:11 -0500 Message-ID: <18b.15cbfbfb.2b702fd4@aol.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_18b.15cbfbfb.2b702fd4_boundary" From: MicklesCK@aol.com Date: Mon, 3 Feb 2003 15:49:24 EST Subject: Re: agenda items for SF ? ISPs document To: Alain.Durand@Sun.COM CC: itojun@iijlab.net, mrw@windriver.com, jordi.palet@consulintel.es, v6ops@ops.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=EMAIL_ATTRIBUTION,MAILTO_LINK,MIME_LONG_LINE_QP, NO_REAL_NAME,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --part1_18b.15cbfbfb.2b702fd4_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] I've asked existing L4 vendors about this over the past year and even though this is widely done in the IPv4 world, the vendors don't have any plans to add this IPv6 functionality until market forces dictate it. >From what I see today, the only alternative is to use DNS to load balance. We know using DNS to load balance won't give us the best performance. We also will probably run into the same UDP packet size limits with IPv4 DNS rotors. It does however gives us something to work with until we have a critical mass of IPv6 capable servers which we can then go to the vendors and ask them to give us the functionality. Cleve... In a message dated 2/3/2003 3:40:05 PM Eastern Standard Time, Alain.Durand@Sun.COM writes: > Subj: Re: agenda items for SF ? ISPs document > Date: 2/3/2003 3:40:05 PM Eastern Standard Time > From: Alain.Durand@Sun.COM > To: MicklesCK@aol.com > CC: itojun@iijlab.net, mrw@windriver.com, jordi.palet@consulintel.es, > v6ops@ops.ietf.org > Sent from the Internet > > > > > > MicklesCK wrote: > > >We do not have an author for the datacenter > >section. I propose we drop the additional datacenter > >section since, as I pointed out at the interim meeting, there > >would be overlap with the Enterprise draft. > > > One point I would like to raise about IPv6 in the datacenter > is load balancers. They basically are NAT boxes dispatching the traffic > to a number of servers. Are we going to need NATv6 afterall? > > Anyway, I think this concern is specific to the big datacenter > and should be addressed in the ISP scenario. > > - Alain. > --part1_18b.15cbfbfb.2b702fd4_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I've asked existing L4 vendors about this over the past year
and even though this is widely done in the IPv4 world, the vendors
don't have any plans to add this IPv6 functionality until market
forces dictate it.

>From what I see today, the only alternative is to use DNS
to load balance.  We know using DNS to load balance won't
give us the best performance.  We also will probably run into
the same UDP packet size limits with IPv4 DNS rotors.  It
does however gives us something to work with until we have
a critical mass of IPv6 capable servers which we can then go
to the vendors and ask them to give us the functionality.


Cleve...

In a message dated 2/3/2003 3:40:05 PM Eastern Standard Time, Alain.Durand@S= un.COM writes:

Subj: Re: agenda items for S= F ? ISPs document
Date: 2/3/2003 3:40:05 PM Eastern Standard Time
From: Alain.Durand@Sun.COM
To: MicklesCK@aol.com
CC: itojun@iijlab.net, mrw@windriver.com, jordi.palet@consulintel.es, v6ops@ops.ietf.org
Sent from the Internet





MicklesCK wrote:

>We do not have an author for the datacenter
>section.  I propose we drop the additional datacenter
>section since, as I pointed out at the interim meeting, there
>would be overlap with the Enterprise draft.
>
One point I would like to raise about IPv6 in the datacenter
is load balancers. They basically are NAT boxes dispatching the traffic
to a number of servers. Are we going to need NATv6 afterall?

Anyway, I think this concern is specific to the big datacenter
and should be addressed in the ISP scenario.

  - Alain.


 --part1_18b.15cbfbfb.2b702fd4_boundary-- From owner-v6ops@ops.ietf.org Tue Feb 4 10:00: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 KAA24411 for ; Tue, 4 Feb 2003 10:00:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g4bN-000K11-00 for v6ops-data@psg.com; Tue, 04 Feb 2003 07:03:09 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18g4bK-000K0b-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 07:03:06 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18g4bJ-0000Hp-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 10:03:05 -0500 Message-Id: <20030203180303.46fb5c02.moore@cs.utk.edu> In-Reply-To: References: <3E3ED39B.80704@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Mon, 3 Feb 2003 18:03:03 -0500 From: Keith Moore To: Cc: moore@cs.utk.edu, MicklesCK@aol.com, Alain.Durand@Sun.COM, v6ops@ops.ietf.org, jordi.palet@consulintel.es, mrw@windriver.com, itojun@iijlab.net Subject: Re: agenda items for SF ? ISPs document X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > NATv6 is a possible solution and the WG may decide that is the best > recommendation in the long run. It would be very helpful to distinguish between the use of network address translation for the purpose of load-balancing within a network of hosts that are dedicated to support specific applications that are known to be compatible with this practice, and network address translation that is imposed on a set of hosts that are used for a variety of purposes and are expected to support an open-ended set of applications. NAT can work well for specific, carefully chosen cases. It cannot be made to work well in general. Keith From owner-v6ops@ops.ietf.org Tue Feb 4 13:54: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 NAA01291 for ; Tue, 4 Feb 2003 13:54:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18g8Eo-00064R-00 for v6ops-data@psg.com; Tue, 04 Feb 2003 10:56:06 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18g8Ej-00063q-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 10:56:01 -0800 Received: from consulintel02 ([62.235.247.108]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Tue, 04 Feb 2003 19:55:42 +0100 Message-ID: <084701c2cc7e$ed496130$7bf1eb3e@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <3E3FC6E5.F9A8B348@hursley.ibm.com> Subject: Re: agenda items for SF ? ISPs document Date: Tue, 4 Feb 2003 19:21:38 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 62.235.247.108 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.5 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit IPsec, yes, this could be a problem, but as I know the load balancers keep all the session (security association then ?) to the same "server", as otherwise, the database access, bank transactions, and others, will be broken. Anyway, may be there is another way to do load-balancing using anycast, but not sure if the actual architecture supports it, may be again it will depend on how the load-balancers implement it. Regarding if ISP or Enterprise, and ISP "hosting" services (so offering load balancing for large number of users), could be always considered an Enterprise ... but I feel that the boundary between both is not clear enough among both design teams. Regards, Jordi ----- Original Message ----- From: "Brian E Carpenter" To: ; Sent: Tuesday, February 04, 2003 2:57 PM Subject: Re: agenda items for SF ? ISPs document > Cleve Mickles wrote: > ... > > NATv6 is a possible solution and the WG may decide that is the best > > recommendation in the long run. > > Only over numerous dead bodies. As Roy Brabson pointed out, this is > by no means a requirement for server load balancing (and wouldn't > be too helpful if you happened to be using IPSEC or any other > address-sensitive protocol). Also, I can't see why it would become > an IETF recommendation anyway. IPv4 load balancing is widely > implemented without any help from the IETF. We just need to avoid > making it harder. > > Certainly, this topic belongs in the enterprise scenario. > > Brian > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Tue Feb 4 20:19: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 UAA10016 for ; Tue, 4 Feb 2003 20:19:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gEEW-0002Vz-00 for v6ops-data@psg.com; Tue, 04 Feb 2003 17:20:12 -0800 Received: from evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net ([4.65.19.240] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 18gEES-0002Vh-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 17:20:08 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 04 Feb 2003 17:20:06 -0800 Reply-To: From: "Tony Hain" To: "'Fernando Gont'" , Cc: Subject: RE: (ngtrans) DNS support for IPv6 Date: Tue, 4 Feb 2003 17:20:06 -0800 Message-ID: <00db01c2ccb4$b7ce85e0$2f114104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4.3.2.7.2.20030204212938.00d34320@gont.com.ar> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA10016 Fernando Gont wrote: > Hi, > > I'm just about to write a brief explanation about the RRs > that need to be > added to the ones described in RFC 1034 / 1035, in order to > add support for > IPv6. > > I've read RFC 3363, and it recommends that RFC 1886 stay on > standards track > and be advanced, and to move RFC 2874 to Experimental status. > > Shall I make comments on AAAA records, and don't even mention > A6 records? > > About address mapping, RFC 3152 says IP6.ARPA should be used, > instead IP6.INT. The same here: shall I omit the description > of IP6.INT, or it is still > being used, and so, I should describe it? > I believe that at this point for operational deployments, it is appropriate to leave out A6 & IP6.INT. If you were going to discuss them at all, an appendix comment about their current status as experimental and deprecated might reduce some confusion. Since this is more of an operational nature, it should probably be discussed on v6ops (cc'd). Tony From owner-v6ops@ops.ietf.org Tue Feb 4 21:22: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 VAA11476 for ; Tue, 4 Feb 2003 21:22:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gFF0-0006fK-00 for v6ops-data@psg.com; Tue, 04 Feb 2003 18:24:46 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18gFEw-0006eP-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 18:24:42 -0800 Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07714; Tue, 4 Feb 2003 19:24:41 -0700 (MST) Received: from eng.sun.com (reggae.Eng.Sun.COM [129.146.81.32]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h152OeEJ968651; Tue, 4 Feb 2003 18:24:40 -0800 (PST) Message-ID: <3E4075ED.2060902@eng.sun.com> Date: Tue, 04 Feb 2003 18:24:45 -0800 From: Jason Goldschmidt User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: v6ops@ops.ietf.org Subject: Re: agenda items for SF ? ISPs document References: <3E3FC6E5.F9A8B348@hursley.ibm.com> <084701c2cc7e$ed496130$7bf1eb3e@consulintel.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit JORDI PALET MARTINEZ wrote: > IPsec, yes, this could be a problem, but as I know the load balancers keep all the session (security association then ?) to the same > "server", as otherwise, the database access, bank transactions, and others, will be broken. > > Anyway, may be there is another way to do load-balancing using anycast, but not sure if the actual architecture supports it, may be > again it will depend on how the load-balancers implement it. > > Regarding if ISP or Enterprise, and ISP "hosting" services (so offering load balancing for large number of users), could be always > considered an Enterprise ... but I feel that the boundary between both is not clear enough among both design teams. I agree that such a scenario needs documenting by one of the design teams and that the boundary is not clear. If people want it documented sooner, rather then later, the ISP design team would be the best candidate. Simply because they currently are showing greater momentum in producing a completed set of documents. thanks, -Jason > > Regards, > Jordi > > ----- Original Message ----- > From: "Brian E Carpenter" > To: ; > Sent: Tuesday, February 04, 2003 2:57 PM > Subject: Re: agenda items for SF ? ISPs document > > > >>Cleve Mickles wrote: >>... >> >>>NATv6 is a possible solution and the WG may decide that is the best >>>recommendation in the long run. >> >>Only over numerous dead bodies. As Roy Brabson pointed out, this is >>by no means a requirement for server load balancing (and wouldn't >>be too helpful if you happened to be using IPSEC or any other >>address-sensitive protocol). Also, I can't see why it would become >>an IETF recommendation anyway. IPv4 load balancing is widely >>implemented without any help from the IETF. We just need to avoid >>making it harder. >> >>Certainly, this topic belongs in the enterprise scenario. >> >> Brian >> > > > ********************************* > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Pre-register at: > http://www.ipv6-es.com > Interested in participating or sponsoring ? > Contact us at ipv6@consulintel.es > > > -- ********************************* Jason Goldschmidt Sun Microsystems (650)-786-3502 jgoldsch@eng.sun.com ********************************* From owner-v6ops@ops.ietf.org Tue Feb 4 21:46: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 VAA12356 for ; Tue, 4 Feb 2003 21:46:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gFd0-0008G1-00 for v6ops-data@psg.com; Tue, 04 Feb 2003 18:49:34 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18gFcx-0008Fp-00 for v6ops@ops.ietf.org; Tue, 04 Feb 2003 18:49:31 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA21862; Tue, 4 Feb 2003 18:48:10 -0800 (PST) Message-Id: <5.1.0.14.2.20030204214042.0341cc78@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Feb 2003 21:45:54 -0500 To: Bob Fink From: Margaret Wasserman Subject: Re: (ngtrans) ngtrans to finally be removed as a wg from IETF web pages Cc: NGtrans List , Tony Hain , Alain Durand , Jun-ichiro itojun Hagino , Randy Bush , Steve Coya , v6ops@ops.ietf.org In-Reply-To: <5.2.0.9.0.20030204182356.0208e788@mail.addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, To elaborate a bit on Bob's message (attached)... The secretariat will be taking the following steps today or tomorrow to complete the process of shutting down the ngtrans WG: - Removing the ngtrans WG charter page from the list of active OPS area WGs, and moving it to the list of concluded WGs. - Changing the ownership of all ngtrans I-Ds from ngtrans to "none" (returning them to individual submission status). The drafts will not be renamed, but further updates may not be issued under the draft-ietf-ngtrans-* names. - Removing the ngtrans WG from the milestone tracker, and performing other clean-up. As Bob stated, the shutdown of the ngtrans WG will have no affect on the ngtrans mailing list. Please let me know if you have any questions regarding this process. Margaret Former ngtrans co-chair At 06:31 PM 2/4/2003 -0800, Bob Fink wrote: >NGtrans Folk, > >The IETF Secretariat will finally be deleting ngtrans as a wg from its web >pages today or tomorrow. To my understanding that will mean moving all >remaining ngtrans IDs to personal submissions, so don't be surprised if >you see a name change. > >The mailing list, which is provide courtesy of Sun, will stay in place. >The ngtrans information pages on the 6bone web site will be updated to >reflect the changes after the changes happen, and will continue to be >available for your use. > >I'll let you know whatever happens when I know it happens. > > >Thanks, > >Bob From owner-v6ops@ops.ietf.org Wed Feb 5 05:56: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 FAA16988 for ; Wed, 5 Feb 2003 05:56:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gNFo-0008vB-00 for v6ops-data@psg.com; Wed, 05 Feb 2003 02:58:08 -0800 Received: from p-mail2.rd.francetelecom.com ([193.49.124.32] helo=p-mail2) by psg.com with smtp (Exim 3.36 #1) id 18gNFl-0008uy-00 for v6ops@ops.ietf.org; Wed, 05 Feb 2003 02:58:06 -0800 Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by 192.144.74.32 with InterScan Messaging Security Suite; Wed, 05 Feb 2003 12:01:59 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 5 Feb 2003 11:57:00 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: agenda items for SF ? ISPs document Date: Wed, 5 Feb 2003 11:52:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: agenda items for SF ? ISPs document Thread-Index: AcLIImXyJUdHyCaHTsWdKG6Fsb5o6QE1hYpw From: "BAUDOT Alain FTRD/DMI/CAE" To: Cc: X-OriginalArrivalTime: 05 Feb 2003 10:57:00.0984 (UTC) FILETIME=[4F5D4B80:01C2CD05] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA16988 Hi Jordi ! > > Now, trying to be constructive, I will propose that this > document is split into several documents, with more focus, > and the design > team is re-designed in some way. > > For example, why not doing something like: > - Core networks > - Access networks > - IXs > - Management (it could be included in each of the documents) > I think IXs topic is pretty much independ from the others, with some typicall IPv6 aspects related to (possible) PI address allocation. > May be we want to be even more focused, considering different > types of access networks in different documents. Obviously separating > this means that probably we are going to repeat some text > from one document to others, but it makes also the life > easier for those > ISPs that only deploy one technology, as they only need to > read one document that only considers its own scenario. > I am more in favor of splitting the current rather thick document between Core and Access, since these topics address specific issues from an ISP or a telco point of view. Regards, Alain. ---------------------------------------------------------------- Alain Baudot France Telecom R&D FTR&D/DMI/SIR/IPI e-mail : alain.baudot@rd.francetelecom.com 42, rue des Coutures Tel : +33 2 31 75 94 27 B.P. 6243 Fax : +33 2 31 75 56 26 14066 CAEN Cedex 4 ---------------------------------------------------------------- From owner-v6ops@ops.ietf.org Thu Feb 6 15:12: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 PAA02567 for ; Thu, 6 Feb 2003 15:12:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gsOl-000Gir-00 for v6ops-data@psg.com; Thu, 06 Feb 2003 12:13:27 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18gsOi-000GiR-00 for v6ops@ops.ietf.org; Thu, 06 Feb 2003 12:13:24 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h16KDJB01976 for v6ops@ops.ietf.org; Thu, 6 Feb 2003 21:13:19 +0100 (CET) Date: Thu, 6 Feb 2003 21:13:19 +0100 From: Ronald van der Pol To: v6ops@ops.ietf.org Subject: IPv6-only devices? Message-ID: <20030206201319.GA1178@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.9 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Some vendors are thinking about developing IPv6-only appliances. I would like to know why they don't put dual stacks on their appliances. So, if you are a vendor and are thinking about IPv6-only appliances, please let us know why you prefer IPv6-only over dual stack. It may be a cost issue. But IPv6-only makes the architecture more complex than in the case of dual stack. So, it may be a tradeoff between dual stack appliances with a simple home router and IPv6-only appliances with a complex home router (with NAT-PT or similar and all its problems). But do IPv6-only appliances really need NAT-PT? I don't think so. If the PCs in the home network are dual stack, they can communicate to the IPv6-only appliances via IPv6 transport. The same is true for PCs outside of the home network (if the home network is reachable via IPv6 transport). The question is: is it absolutely necessary that IPv6-only devices can communicate to legacy IPv4-only PCs? Thinking about it I think NAT-PT will slow down the move to IPv6. Without it, users are motivated to upgrade their PCs to dual stack to be able to communicate with their new IPv6-only appliances. And they are motivated to request IPv6 connectivity from their ISPs. Comments? rvdp From owner-v6ops@ops.ietf.org Thu Feb 6 15:37:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03422 for ; Thu, 6 Feb 2003 15:37:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gso7-000IUf-00 for v6ops-data@psg.com; Thu, 06 Feb 2003 12:39:39 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50]) by psg.com with esmtp (Exim 3.36 #1) id 18gso3-000ITB-00 for v6ops@ops.ietf.org; Thu, 06 Feb 2003 12:39:35 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id BFF8414039; Thu, 6 Feb 2003 15:39:31 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 19916-01; Thu, 6 Feb 2003 15:39:31 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 2392614038; Thu, 6 Feb 2003 15:39:31 -0500 (EST) Date: Thu, 6 Feb 2003 15:39:30 -0500 From: Keith Moore To: Ronald van der Pol Cc: moore@cs.utk.edu, v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Message-Id: <20030206153930.1e69c56d.moore@cs.utk.edu> In-Reply-To: <20030206201319.GA1178@rvdp.org> References: <20030206201319.GA1178@rvdp.org> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 49018ffb08317fc522c540c50c3d370362d40217 X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 6 Feb 2003 21:13:19 +0100 Ronald van der Pol wrote: > Some vendors are thinking about developing IPv6-only appliances. > > I would like to know why they don't put dual stacks on their > appliances. So, if you are a vendor and are thinking about IPv6-only > appliances, please let us know why you prefer IPv6-only over dual > stack. > > It may be a cost issue. But IPv6-only makes the architecture more > complex than in the case of dual stack. I don't see how. Actually the simplest way to go seems to be to declare some apps IPv6-only, some (legacy) apps IPv4-only, and a few apps dual-stack. It's a lot simpler than trying to teach applications to cope with a mixture of the two - which gets you back to the problems inherent in scoped addresses. Keith From owner-v6ops@ops.ietf.org Thu Feb 6 15:53: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 PAA03956 for ; Thu, 6 Feb 2003 15:53:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gt4m-000JbF-00 for v6ops-data@psg.com; Thu, 06 Feb 2003 12:56:52 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18gt4j-000Jav-00 for v6ops@ops.ietf.org; Thu, 06 Feb 2003 12:56:50 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h16Kuhn02248; Thu, 6 Feb 2003 21:56:43 +0100 (CET) Date: Thu, 6 Feb 2003 21:56:43 +0100 From: Ronald van der Pol To: Keith Moore Cc: Ronald van der Pol , v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Message-ID: <20030206205643.GB1178@rvdp.org> References: <20030206201319.GA1178@rvdp.org> <20030206153930.1e69c56d.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030206153930.1e69c56d.moore@cs.utk.edu> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Feb 06, 2003 at 15:39:30 -0500, Keith Moore wrote: > It's a lot simpler than trying to teach applications to > cope with a mixture of the two - which gets you back to the problems > inherent in scoped addresses. I don't agree. Applications that walk all addresses (v6 and v4) are widely deployed without any problems. I am thinking about ssh, http, smtp, etc. Porting applications to use both v4 and v6 addresses is in many cases easy. It seems like what you are promoting is balkanizing the internet. Some nodes are v4-only and can only talk to v4-only. Other nodes are v6-only and can only talk to v6-only. Is that what you want? rvdp From owner-v6ops@ops.ietf.org Thu Feb 6 15:59: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 PAA04159 for ; Thu, 6 Feb 2003 15:59:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gtAo-000K1s-00 for v6ops-data@psg.com; Thu, 06 Feb 2003 13:03:06 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18gtAl-000K1f-00 for v6ops@ops.ietf.org; Thu, 06 Feb 2003 13:03:04 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h16L2wi23709; Thu, 6 Feb 2003 23:02:58 +0200 Date: Thu, 6 Feb 2003 23:02:57 +0200 (EET) From: Pekka Savola To: Ronald van der Pol cc: Keith Moore , Subject: Re: IPv6-only devices? In-Reply-To: <20030206205643.GB1178@rvdp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 6 Feb 2003, Ronald van der Pol wrote: > On Thu, Feb 06, 2003 at 15:39:30 -0500, Keith Moore wrote: > > > It's a lot simpler than trying to teach applications to > > cope with a mixture of the two - which gets you back to the problems > > inherent in scoped addresses. > > I don't agree. Applications that walk all addresses (v6 and v4) are > widely deployed without any problems. [...] I'm not sure if this is trivial. I have yet to see the influx of "production" services which have both A and AAAA records for a DNS name. It could be harder than we imagine.. > I am thinking about ssh, http, > smtp, etc. Porting applications to use both v4 and v6 addresses is > in many cases easy. I agree, porting is the easy part.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Feb 6 16:14: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 QAA04526 for ; Thu, 6 Feb 2003 16:14:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gtNV-000KzN-00 for v6ops-data@psg.com; Thu, 06 Feb 2003 13:16:13 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50]) by psg.com with esmtp (Exim 3.36 #1) id 18gtNT-000KzA-00 for v6ops@ops.ietf.org; Thu, 06 Feb 2003 13:16:11 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 2792614038; Thu, 6 Feb 2003 16:16:10 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 24587-06; Thu, 6 Feb 2003 16:16:09 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 7ECBC14021; Thu, 6 Feb 2003 16:16:09 -0500 (EST) Date: Thu, 6 Feb 2003 16:16:09 -0500 From: Keith Moore To: Ronald van der Pol Cc: moore@cs.utk.edu, Ronald.vanderPol@rvdp.org, v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Message-Id: <20030206161609.1703f7a8.moore@cs.utk.edu> In-Reply-To: <20030206205643.GB1178@rvdp.org> References: <20030206201319.GA1178@rvdp.org> <20030206153930.1e69c56d.moore@cs.utk.edu> <20030206205643.GB1178@rvdp.org> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 00b50db976f95a0ae59fae2f66513174d9870f09 X-Spam-Status: No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 6 Feb 2003 21:56:43 +0100 Ronald van der Pol wrote: > On Thu, Feb 06, 2003 at 15:39:30 -0500, Keith Moore wrote: > > > It's a lot simpler than trying to teach applications to > > cope with a mixture of the two - which gets you back to the problems > > inherent in scoped addresses. > > I don't agree. Applications that walk all addresses (v6 and v4) are > widely deployed without any problems. I am thinking about ssh, http, > smtp, etc. Porting applications to use both v4 and v6 addresses is > in many cases easy. This works great for some applications; really poorly for others. In general it works for apps that only involve two parties, and thus two network endpoints. There the rules are simple. If both speak v6, use v6. Else, if both speak v4, use v4. Otherwise, you may be out of luck. (actually this is likely to cause painful delays for dual-stack hosts, but for the moment let's ignore that problem) Surprisingly few apps work this way. For instance the web doesn't work this way. The vast majority of the content on the web is accessible only via IPv4. If your client can't get to IPv4, you lose. Email doesn't work this way either. Everyone needs an MX that speaks IPv4. Yes, you can use a web proxy to allow your v6 client to get to the v4 web, and you can use a mail relay to allow your v6 client to relay mail to the v4 mail network. Both protocols already support a form of proxying, so no protocol changes are necessary. But you still end up requiring an operator to make protocol-specific arrangements in order to permit allow cross v4-v6 operation. And if you want your v6-only web server or MTA to be accessible from v4, you're going to need to make special arrangements to do that, also. > It seems like what you are promoting is balkanizing the internet. > Some nodes are v4-only and can only talk to v4-only. Other nodes > are v6-only and can only talk to v6-only. Is that what you want? It's unavoidable and inherent in the fact that there are two different address realms. Trying to mix v4 and v6 has the same problems that exist when trying to mix SL and globals. What I'm pointing out is that trying to make every application speak both IPv4 and IPv6 is a waste of energy. It's not even possible in general, and for many applications there are going to be inherent biases toward either v4 or v6 - e.g. for backward compatibility reasons, because the application inherently requires a large flat global address space, or because the application was initially deployed in portions of the network (e.g. the cell phone newtork, or certain parts of the world) that were more friendly to v6 than to v4. Keith From owner-v6ops@ops.ietf.org Thu Feb 6 17:19: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 RAA06729 for ; Thu, 6 Feb 2003 17:19:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18guOa-000Pm0-00 for v6ops-data@psg.com; Thu, 06 Feb 2003 14:21:24 -0800 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18guOX-000Pln-00 for v6ops@ops.ietf.org; Thu, 06 Feb 2003 14:21:22 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h16MLFp02682; Thu, 6 Feb 2003 23:21:15 +0100 (CET) Date: Thu, 6 Feb 2003 23:21:15 +0100 From: Ronald van der Pol To: Keith Moore Cc: Ronald van der Pol , v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Message-ID: <20030206222115.GC1178@rvdp.org> References: <20030206201319.GA1178@rvdp.org> <20030206153930.1e69c56d.moore@cs.utk.edu> <20030206205643.GB1178@rvdp.org> <20030206161609.1703f7a8.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030206161609.1703f7a8.moore@cs.utk.edu> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote: > What I'm pointing out is that trying to make every application speak > both IPv4 and IPv6 is a waste of energy. I don't agree. Dual stack enables a smooth migration from v4 to v6, but see below. > It's not even possible > in general, and for many applications there are going to be inherent > biases toward either v4 or v6 - e.g. for backward compatibility > reasons, because the application inherently requires a large flat global > address space, or because the application was initially deployed in > portions of the network (e.g. the cell phone newtork, or certain parts > of the world) that were more friendly to v6 than to v4. If you read my initial email again you would see that I also say that it is perfectly OK to have IPv6-only appliances that do not need to communicate to IPv4-only nodes. I think dual stack is the best migration path. I also think that the transition period should be short. Not a flag day, but also not a transition period of decades. I agree with you that running dual stack networks is costly *). I think the transition should be done in a few years. I think this means the IETF should restrict new work to IPv6-only. In other words: either move to IPv6 or abondon the effort. *) Dual stack is costly. ISPs have to maintain 2 number plans, 2 ACL lists, etc. In case of problems ISPs need to figure out if it is an IPv4-only problem, an IPv6-only problem or a problem of both stacks. Vendors need to track IPv6-only bugs, IPv4-only bug and bugs that exist in both protocols. When vendors introduce a new feature, customers have to ask if the feature is supported in IPv4, in IPv6 or in both. Etcetera, etcetera. rvdp From owner-v6ops@ops.ietf.org Thu Feb 6 17:50: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 RAA07589 for ; Thu, 6 Feb 2003 17:50:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18gutZ-0001zq-00 for v6ops-data@psg.com; Thu, 06 Feb 2003 14:53:25 -0800 Received: from grebe.mail.pas.earthlink.net ([207.217.120.46]) by psg.com with esmtp (Exim 3.36 #1) id 18gutV-0001zV-00 for v6ops@ops.ietf.org; Thu, 06 Feb 2003 14:53:21 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gutQ-0002tp-00; Thu, 06 Feb 2003 14:53:16 -0800 Date: Thu, 6 Feb 2003 17:51:13 -0500 From: Keith Moore To: Ronald van der Pol Cc: moore@cs.utk.edu, Ronald.vanderPol@rvdp.org, v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Message-Id: <20030206175113.602e07e2.moore@cs.utk.edu> In-Reply-To: <20030206222115.GC1178@rvdp.org> References: <20030206201319.GA1178@rvdp.org> <20030206153930.1e69c56d.moore@cs.utk.edu> <20030206205643.GB1178@rvdp.org> <20030206161609.1703f7a8.moore@cs.utk.edu> <20030206222115.GC1178@rvdp.org> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 6 Feb 2003 23:21:15 +0100 Ronald van der Pol wrote: > On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote: > > > What I'm pointing out is that trying to make every application speak > > both IPv4 and IPv6 is a waste of energy. > > I don't agree. Dual stack enables a smooth migration from v4 to v6, Uh, no. Not by a longshot. For some applications (for instance, those that do referrals) trying to support a mixture of IPv4 and IPv6 is a nightmare. This is the sort of thing that needs to be evaluated on a per-application basis. Overgeneralizations such as "dual stack enables a smooth migration from v4 to v6" are harmful. And the assumption that both hosts are going to upgrade to dual stack, and networks are going to support it, within a few years, seems highly dubious. The Internet is just too diverse to expect everyone to migrate to v6 in the same way, and in the same timeframe. Keith From owner-v6ops@ops.ietf.org Fri Feb 7 07: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 HAA07306 for ; Fri, 7 Feb 2003 07:44:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h7t6-00062x-00 for v6ops-data@psg.com; Fri, 07 Feb 2003 04:45:48 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 18h7t4-00062h-00 for v6ops@ops.ietf.org; Fri, 07 Feb 2003 04:45:46 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h17Cje89068066; Fri, 7 Feb 2003 13:45:41 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h17Cjd4e132684; Fri, 7 Feb 2003 13:45:40 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45790 from ; Fri, 7 Feb 2003 13:45:37 +0100 Message-Id: <3E43AA42.78E600B6@hursley.ibm.com> Date: Fri, 07 Feb 2003 13:44:50 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Ronald van der Pol Cc: v6ops@ops.ietf.org Subject: Re: IPv6-only devices? References: <20030206201319.GA1178@rvdp.org> <20030206153930.1e69c56d.moore@cs.utk.edu> <20030206205643.GB1178@rvdp.org> <20030206161609.1703f7a8.moore@cs.utk.edu> <20030206222115.GC1178@rvdp.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ronald van der Pol wrote: > > On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote: ... > If you read my initial email again you would see that I also say that > it is perfectly OK to have IPv6-only appliances that do not need to > communicate to IPv4-only nodes. And in a SOHO context or an on-board network on some kind of vehicle, it might be very natural for those IPv6-only devices to communicate with a local server that proxies for them in some way to the outside world. E.g. a "building services" server that doesn't expose individual IPv6 thermostats to the outside world, but does expose room temperatures. That server can be dual stack. This is to me the most natural model for really low-end devices, which will be very price sensitive (i.e. a few dollars difference in the cost of ASIC or memory really matters). Unless you want to build a NAT-PT with a Thermostat ALG for each band of thermostat. > > I think dual stack is the best migration path. I also think that the > transition period should be short. Not a flag day, but also not a > transition period of decades. I agree with you that running dual > stack networks is costly *). I think the transition should be done > in a few years. Er, how to say this politely? "In your dreams." The only realistic thing to plan for is an indefinite period of coexistence. Once IPv6 is seriously out there, I can't see the overlap being less than ten years, and even that is very optimistic. Of course, the day should come when IPv4 is an overpriced legacy service only supported by a couple of dinosaur telcos, but I don't expect that to happen until I'm happily retired. > I think this means the IETF should restrict new > work to IPv6-only. In other words: either move to IPv6 or abondon > the effort. It's a bit soon for that. But we should clearly not accept any WG that does stuff that isn't IPv6-ready. So IPv6 people need to colonise every WG that exists, and read every draft for IPv6ness. Brian From owner-v6ops@ops.ietf.org Fri Feb 7 08:23:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09702 for ; Fri, 7 Feb 2003 08:23:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h8Wo-0007j9-00 for v6ops-data@psg.com; Fri, 07 Feb 2003 05:26:50 -0800 Received: from [193.72.156.161] (helo=mercury.telscom.ch) by psg.com with esmtp (Exim 3.36 #1) id 18h8Wi-0007iS-00 for v6ops@ops.ietf.org; Fri, 07 Feb 2003 05:26:44 -0800 Received: from Dell (193.135.153.254) by mercury.telscom.ch with MERCUR-SMTP/POP3/IMAP4-Server (v3.30.09 AS-2621446) for ; Fri, 7 Feb 2003 14:24:49 +0100 Message-ID: <006701c2ceac$85146bc0$3b13a8c0@Dell> From: "Sathya Rao" To: , "Ronald van der Pol" Cc: References: <20030206201319.GA1178@rvdp.org> <20030206153930.1e69c56d.moore@cs.utk.edu> <20030206205643.GB1178@rvdp.org> <20030206161609.1703f7a8.moore@cs.utk.edu> <20030206222115.GC1178@rvdp.org> <3E43AA42.78E600B6@hursley.ibm.com> Subject: Re: IPv6-only devices? Date: Fri, 7 Feb 2003 14:26:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Reply-To: rao@telscom.ch X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I liked particularly the recommendation of Brian how IETF can make a mileage for early deployment of IPv6. > > I think this means the IETF should restrict new > > work to IPv6-only. In other words: either move to IPv6 or abondon > > the effort. > > It's a bit soon for that. But we should clearly not accept any > WG that does stuff that isn't IPv6-ready. So IPv6 people need to > colonise every WG that exists, and read every draft for > IPv6ness. > Sathya ----- Original Message ----- From: "Brian E Carpenter" To: "Ronald van der Pol" Cc: Sent: Friday, February 07, 2003 1:44 PM Subject: Re: IPv6-only devices? > Ronald van der Pol wrote: > > > > On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote: > ... > > If you read my initial email again you would see that I also say that > > it is perfectly OK to have IPv6-only appliances that do not need to > > communicate to IPv4-only nodes. > > And in a SOHO context or an on-board network on some kind of vehicle, > it might be very natural for those IPv6-only devices to communicate > with a local server that proxies for them in some way to the > outside world. E.g. a "building services" server that doesn't > expose individual IPv6 thermostats to the outside world, but does > expose room temperatures. That server can be dual stack. > > This is to me the most natural model for really low-end devices, which > will be very price sensitive (i.e. a few dollars difference in the cost > of ASIC or memory really matters). Unless you want to build a NAT-PT > with a Thermostat ALG for each band of thermostat. > > > > > I think dual stack is the best migration path. I also think that the > > transition period should be short. Not a flag day, but also not a > > transition period of decades. I agree with you that running dual > > stack networks is costly *). I think the transition should be done > > in a few years. > > Er, how to say this politely? "In your dreams." The only realistic > thing to plan for is an indefinite period of coexistence. Once IPv6 > is seriously out there, I can't see the overlap being less than ten > years, and even that is very optimistic. > > Of course, the day should come when IPv4 is an overpriced > legacy service only supported by a couple of dinosaur telcos, but > I don't expect that to happen until I'm happily retired. > > > I think this means the IETF should restrict new > > work to IPv6-only. In other words: either move to IPv6 or abondon > > the effort. > > It's a bit soon for that. But we should clearly not accept any > WG that does stuff that isn't IPv6-ready. So IPv6 people need to > colonise every WG that exists, and read every draft for > IPv6ness. > > Brian > > From owner-v6ops@ops.ietf.org Fri Feb 7 08:59: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 IAA11515 for ; Fri, 7 Feb 2003 08:59:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18h94K-0009Dh-00 for v6ops-data@psg.com; Fri, 07 Feb 2003 06:01:28 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18h94H-0009DT-00 for v6ops@ops.ietf.org; Fri, 07 Feb 2003 06:01:25 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h17E43m12663 for ; Fri, 7 Feb 2003 16:04:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Feb 2003 16:01:21 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Feb 2003 16:01:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6-only devices? Date: Fri, 7 Feb 2003 16:01:20 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3728@esebe005.ntc.nokia.com> Thread-Topic: IPv6-only devices? Thread-Index: AcLOp7/mToDW/QhnS0y1Tp4JVWxQwgAB/RHQ From: To: , , X-OriginalArrivalTime: 07 Feb 2003 14:01:21.0109 (UTC) FILETIME=[6489F050:01C2CEB1] X-Spam-Status: No, hits=1.3 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA11515 Hi all! This has been a good discussion. So the main question seems to be, is "the dual stack model" sufficient / the only correct way to take care of the IPv6 transition? I certainly admit that it is a very good model for very many cases and it has many positive sides, e.g. use of dual stack & tunneling retains the end-to-end IP connections. But does introducing IPv6 in a device / application always require also IPv4 to be there? I think it doesn't. Allowing some (new) applications / services to be IPv6-only can make IPv6 transition happen more quickly. And if the application is IPv6-only, we don't need to worry about IPv4 NATs either. I think there will certainly be interesting discussions in San Francisco... :-) Best Regards, -Juha W.- -----Original Message----- From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: 07 February, 2003 14:45 To: Ronald van der Pol Cc: v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Ronald van der Pol wrote: > > On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote: ... > If you read my initial email again you would see that I also say that > it is perfectly OK to have IPv6-only appliances that do not need to > communicate to IPv4-only nodes. And in a SOHO context or an on-board network on some kind of vehicle, it might be very natural for those IPv6-only devices to communicate with a local server that proxies for them in some way to the outside world. E.g. a "building services" server that doesn't expose individual IPv6 thermostats to the outside world, but does expose room temperatures. That server can be dual stack. This is to me the most natural model for really low-end devices, which will be very price sensitive (i.e. a few dollars difference in the cost of ASIC or memory really matters). Unless you want to build a NAT-PT with a Thermostat ALG for each band of thermostat. > > I think dual stack is the best migration path. I also think that the > transition period should be short. Not a flag day, but also not a > transition period of decades. I agree with you that running dual > stack networks is costly *). I think the transition should be done > in a few years. Er, how to say this politely? "In your dreams." The only realistic thing to plan for is an indefinite period of coexistence. Once IPv6 is seriously out there, I can't see the overlap being less than ten years, and even that is very optimistic. Of course, the day should come when IPv4 is an overpriced legacy service only supported by a couple of dinosaur telcos, but I don't expect that to happen until I'm happily retired. > I think this means the IETF should restrict new > work to IPv6-only. In other words: either move to IPv6 or abondon > the effort. It's a bit soon for that. But we should clearly not accept any WG that does stuff that isn't IPv6-ready. So IPv6 people need to colonise every WG that exists, and read every draft for IPv6ness. Brian From owner-v6ops@ops.ietf.org Fri Feb 7 13:38:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17592 for ; Fri, 7 Feb 2003 13:38:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hDQ0-000Mho-00 for v6ops-data@psg.com; Fri, 07 Feb 2003 10:40:08 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18hDPx-000Mgx-00 for v6ops@ops.ietf.org; Fri, 07 Feb 2003 10:40:05 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.33]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA08010; Fri, 7 Feb 2003 10:38:37 -0800 (PST) Message-Id: <5.1.0.14.2.20030207104409.0309ffd0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Feb 2003 11:05:05 -0500 To: From: Margaret Wasserman Subject: RE: IPv6-only devices? Cc: , , In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3728@esebe005.ntc.nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >But does introducing IPv6 in a device / application always require also >IPv4 to be there? I think it doesn't. Allowing some (new) applications / >services to be IPv6-only can make IPv6 transition happen more quickly. >And if the application is IPv6-only, we don't need to worry about IPv4 NATs >either. It makes sense to deploy IPv6-only nodes and services in two situations: (1) Closed or limited network situations where you know that all nodes that need to reach the IPv6-only node/service have IPv6 available. This might occur in hospital, a home, a military application, an industrial site, etc. (2) New services/applications that require a software upgrade, anyway. While the client is being upgraded to include the new service, IPv6 can be installed or enabled. A large PC software manufacturer, for example, could support a new peer-to-peer game that was IPv6-only, and could require that IPv6 be installed and enabled as part of the game installation. In these cases, it is valid to assume that any node that needs to communicate to the IPv6-only node or service will use IPv6 to do it. It may be a long time, though, before it will make sense to deploy IPv6-only servers on the public Internet to provide existing services. For example, how long do you think it will be before it makes sense to deploy an IPv6-only e-commerce site? Margaret From owner-v6ops@ops.ietf.org Fri Feb 7 14:14: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 OAA18669 for ; Fri, 7 Feb 2003 14:14:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hE0Q-000OpK-00 for v6ops-data@psg.com; Fri, 07 Feb 2003 11:17:46 -0800 Received: from klutz.cs.utk.edu ([160.36.56.50]) by psg.com with esmtp (Exim 3.36 #1) id 18hE0O-000Op7-00 for v6ops@ops.ietf.org; Fri, 07 Feb 2003 11:17:44 -0800 Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3BFB514015; Fri, 7 Feb 2003 14:17:43 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 22647-08; Fri, 7 Feb 2003 14:17:42 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 9E05C1400E; Fri, 7 Feb 2003 14:17:42 -0500 (EST) Date: Fri, 7 Feb 2003 14:17:40 -0500 From: Keith Moore To: Margaret Wasserman Cc: moore@cs.utk.edu, juha.wiljakka@nokia.com, brian@hursley.ibm.com, Ronald.vanderPol@rvdp.org, v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Message-Id: <20030207141740.3a729dca.moore@cs.utk.edu> In-Reply-To: <5.1.0.14.2.20030207104409.0309ffd0@mail.windriver.com> References: <245DBCAEEC4F074CB77B3F984FF9834FDC3728@esebe005.ntc.nokia.com> <5.1.0.14.2.20030207104409.0309ffd0@mail.windriver.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 6bd371813c739c78cdbcf41637c4afd80096d7cb X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It makes sense to deploy IPv6-only nodes and services in two > situations: > > (1) Closed or limited network situations where you > know that all nodes that need to reach the > IPv6-only node/service have IPv6 available. > > (2) New services/applications that require a > software upgrade, anyway. While the > client is being upgraded to include the new > service, IPv6 can be installed or enabled. not that these are entirely disjoint, but there are other categories worth mentioning. e.g.: (3) services/applications that will make heavy use of portions of the network that are IPv6-only, or network nodes that are only capable of IPv6 in which case it might make more sense to impose a burden on the (presumably far fewer for such applications) nodes that are currently limited to IPv4, to upgrade to v6 stacks and use 6to4 or tunneling or some such to communicate with the other nodes. (4) new services that involve adding large numbers of new individually addressible hosts, for which there are not enough IPv4 addresses available for instance, various kinds of devices that would benefit from remote monitoring or sensing (power meters, traffic sensors, security cameras/sensors, fire/smoke alarms, etc.). > It may be a long time, though, before it will make sense to > deploy IPv6-only servers on the public Internet to provide > existing services. For example, how long do you think it will > be before it makes sense to deploy an IPv6-only e-commerce > site? Right, for services where there is a wide expectation that v4 access is sufficient (email and the web being really obvious examples) you're going to continue need to provide access using IPv4 for many more years. Keith From owner-v6ops@ops.ietf.org Fri Feb 7 16:48: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 QAA22462 for ; Fri, 7 Feb 2003 16:48:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hGMb-0007aQ-00 for v6ops-data@psg.com; Fri, 07 Feb 2003 13:48:49 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18hGMX-0007a9-00 for v6ops@ops.ietf.org; Fri, 07 Feb 2003 13:48:45 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA11561 for ; Fri, 7 Feb 2003 21:48:43 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h17LmgYJ011948 for ; Fri, 7 Feb 2003 21:48:42 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h17LmgX19129 for v6ops@ops.ietf.org; Fri, 7 Feb 2003 21:48:42 GMT Date: Fri, 7 Feb 2003 21:48:42 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: IPv6-only devices? Message-ID: <20030207214842.GI18465@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <245DBCAEEC4F074CB77B3F984FF9834FDC3728@esebe005.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3728@esebe005.ntc.nokia.com> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Feb 07, 2003 at 04:01:20PM +0200, juha.wiljakka@nokia.com wrote: > > I think there will certainly be interesting discussions in San Francisco... :-) If we get the extra slot... :) Tim From owner-v6ops@ops.ietf.org Sat Feb 8 04:23: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 EAA16420 for ; Sat, 8 Feb 2003 04:23:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18hRFN-00056y-00 for v6ops-data@psg.com; Sat, 08 Feb 2003 01:26:05 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18hRFL-00056g-00 for v6ops@ops.ietf.org; Sat, 08 Feb 2003 01:26:03 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Sat, 08 Feb 2003 10:27:19 +0100 Message-ID: <012401c2cf54$43f5cd20$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <245DBCAEEC4F074CB77B3F984FF9834FDC3728@esebe005.ntc.nokia.com><5.1.0.14.2.20030207104409.0309ffd0@mail.windriver.com> <20030207141740.3a729dca.moore@cs.utk.edu> Subject: Re: IPv6-only devices? Date: Sat, 8 Feb 2003 10:27:13 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.5 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I can see also one case that can perfectly match most of this examples, never mind is more a "business" or "marketing" one: - A team of a hardware vendor+service provider that want to create a exclusive "product/service/application", only v6, because they only want to sell it in the provider network (as a value added service to attract new customers). It could be the same for a new application, instead a "hardware product". The service could be installed in a standard PC (requirement: OS IPv6 enabled), but will use only the IPv6 stack. Regards, Jordi ----- Original Message ----- From: "Keith Moore" To: "Margaret Wasserman" Cc: ; ; ; ; Sent: Friday, February 07, 2003 8:17 PM Subject: Re: IPv6-only devices? > > It makes sense to deploy IPv6-only nodes and services in two > > situations: > > > > (1) Closed or limited network situations where you > > know that all nodes that need to reach the > > IPv6-only node/service have IPv6 available. > > > > (2) New services/applications that require a > > software upgrade, anyway. While the > > client is being upgraded to include the new > > service, IPv6 can be installed or enabled. > > not that these are entirely disjoint, but there are other categories > worth mentioning. e.g.: > > (3) services/applications that will make heavy use of portions of the > network that are IPv6-only, or network nodes that are only > capable of IPv6 > > in which case it might make more sense to impose a burden on the > (presumably far fewer for such applications) nodes that are currently > limited to IPv4, to upgrade to v6 stacks and use 6to4 or tunneling or > some such to communicate with the other nodes. > > (4) new services that involve adding large numbers of new > individually addressible hosts, for which there are not enough IPv4 > addresses available > > for instance, various kinds of devices that would benefit from remote > monitoring or sensing (power meters, traffic sensors, security > cameras/sensors, fire/smoke alarms, etc.). > > > It may be a long time, though, before it will make sense to > > deploy IPv6-only servers on the public Internet to provide > > existing services. For example, how long do you think it will > > be before it makes sense to deploy an IPv6-only e-commerce > > site? > > Right, for services where there is a wide expectation that v4 access is > sufficient (email and the web being really obvious examples) you're > going to continue need to provide access using IPv4 for many more years. > > Keith > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Sun Feb 9 19:52:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10434 for ; Sun, 9 Feb 2003 19:52:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18i2AG-0008BY-00 for v6ops-data@psg.com; Sun, 09 Feb 2003 16:51:16 -0800 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 3.36 #1) id 18i2AD-0008BL-00 for v6ops@ops.ietf.org; Sun, 09 Feb 2003 16:51:13 -0800 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HA200H01IB7ZD@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon, 10 Feb 2003 09:49:55 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA200F49IB7AI@mailout2.samsung.com> for v6ops@ops.ietf.org; Mon, 10 Feb 2003 09:49:55 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HA200M6LISG73@mmp1.samsung.com> for v6ops@ops.ietf.org; Mon, 10 Feb 2003 10:00:16 +0900 (KST) Date: Mon, 10 Feb 2003 09:49:40 +0900 From: Soohong Daniel Park Subject: RE: IPv6-only devices? In-reply-to: <20030206222115.GC1178@rvdp.org> To: "'Ronald van der Pol'" , "'Keith Moore'" Cc: v6ops@ops.ietf.org Message-id: <006b01c2d09e$4b271d60$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Ronald van der Pol Sent: Friday, February 07, 2003 7:21 AM To: Keith Moore Cc: Ronald van der Pol; v6ops@ops.ietf.org Subject: Re: IPv6-only devices? On Thu, Feb 06, 2003 at 16:16:09 -0500, Keith Moore wrote: > What I'm pointing out is that trying to make every application speak > both IPv4 and IPv6 is a waste of energy. I don't agree. Dual stack enables a smooth migration from v4 to v6, but see below. > It's not even possible > in general, and for many applications there are going to be inherent > biases toward either v4 or v6 - e.g. for backward compatibility > reasons, because the application inherently requires a large flat global > address space, or because the application was initially deployed in > portions of the network (e.g. the cell phone newtork, or certain parts > of the world) that were more friendly to v6 than to v4. If you read my initial email again you would see that I also say that it is perfectly OK to have IPv6-only appliances that do not need to communicate to IPv4-only nodes. I think dual stack is the best migration path. I also think that the transition period should be short. Not a flag day, but also not a transition period of decades. I agree with you that running dual stack networks is costly *). I think the transition should be done in a few years. I think this means the IETF should restrict new work to IPv6-only. In other words: either move to IPv6 or abondon the effort. ==>I don't agree. As I said, it will be the best not only dual stack but also all kinds of trial toward IPv6. of course dual stack is simple, but don't forget some guys are trying to make a IPv6-only in HOME. Isn't it a final goal to make a legacy IPv6-only ? Daniel *) Dual stack is costly. ISPs have to maintain 2 number plans, 2 ACL lists, etc. In case of problems ISPs need to figure out if it is an IPv4-only problem, an IPv6-only problem or a problem of both stacks. Vendors need to track IPv6-only bugs, IPv4-only bug and bugs that exist in both protocols. When vendors introduce a new feature, customers have to ask if the feature is supported in IPv4, in IPv6 or in both. Etcetera, etcetera. rvdp From owner-v6ops@ops.ietf.org Mon Feb 10 10:20: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 KAA11918 for ; Mon, 10 Feb 2003 10:20:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iFlK-0001W1-00 for v6ops-data@psg.com; Mon, 10 Feb 2003 07:22:26 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18iFlG-0001Vk-00 for v6ops@ops.ietf.org; Mon, 10 Feb 2003 07:22:22 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1AFMJ625826 for ; Mon, 10 Feb 2003 17:22:19 +0200 Date: Mon, 10 Feb 2003 17:22:19 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: transition architecture discussion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, There was some debate on the transition architecture wrt. the agenda for the next meeting. I've sent out a short-ish (11 pages) draft to internet-drafts@ on my take on it. In the meantime, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-transarch-00.txt The abstract is: The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches. .. it is by far not perfect (I didn't have any time to work on it except the last night), and includes personal opinions (of course :-), but could be usable as something concrete to build discussion on, if needed. Note: I'll be off for a week beginning tomorrow. -- 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 Feb 11 06:47: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 GAA28888 for ; Tue, 11 Feb 2003 06:47:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iYtR-000LkS-00 for v6ops-data@psg.com; Tue, 11 Feb 2003 03:48:05 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18iYtO-000LkG-00 for v6ops@ops.ietf.org; Tue, 11 Feb 2003 03:48:02 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28253; Tue, 11 Feb 2003 06:44:17 -0500 (EST) Message-Id: <200302111144.GAA28253@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-transarch-00.txt Date: Tue, 11 Feb 2003 06:44:17 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A View on IPv6 Transition Architecture Author(s) : P. Savola Filename : draft-savola-v6ops-transarch-00.txt Pages : 11 Date : 2003-2-10 The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-transarch-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-transarch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-transarch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10132709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-transarch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-transarch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132709.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Feb 11 09:03: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 JAA05221 for ; Tue, 11 Feb 2003 09:03:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ib1h-00018S-00 for v6ops-data@psg.com; Tue, 11 Feb 2003 06:04:45 -0800 Received: from a80-126-101-63.adsl.xs4all.nl ([80.126.101.63] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 18ib1e-00018G-00 for v6ops@ops.ietf.org; Tue, 11 Feb 2003 06:04:42 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h1BE26X02489; Tue, 11 Feb 2003 15:02:06 +0100 (CET) Date: Tue, 11 Feb 2003 15:02:06 +0100 From: Ronald van der Pol To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: transition architecture discussion Message-ID: <20030211140206.GC692@rvdp.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Feb 10, 2003 at 17:22:19 +0200, Pekka Savola wrote: > .. it is by far not perfect (I didn't have any time to work on it except > the last night), and includes personal opinions (of course :-), but could > be usable as something concrete to build discussion on, if needed. Thanks for starting this discussion. I think we also need to finish the scenario drafts soon (hint, hint). It would also be useful to find out why people are not deploying/ using/requesting IPv6. A few comments. You restrict the architecture discussion to the "process of enabling the use of IPv6". I don't think that's enough. I think it should include at least the phase of a predominantly IPv6 internet. Running dual stack is not without any costs. It is easier and cheaper to run either v4-only or v6-only. If we don't _plan_ for a situation where almost all traffic is v6 it won't happen. You mention the problems of enabling IPv6 for services and bad IPv6 connectivity. That's true. I fully agree. But on the other hand routing approved a lot when people started to use IPv6 on a daily basis. This is just an operational issue. IPv4 networks can be operated badly too. Therefore, I think we should not use separate domain names (like ipv6.example.com) or prefer A over AAAA. We (operators, not the IETF) should put effort in v6 connectivity with the same quality as v4. With respect to tunneling, I think there are a couple of questions: - Should we work on v6-in-v4 tunneling through v4 NATs (e.g. teredo)? I can see its use in 3GPP, where the end user does not have influence on the GGSN. I am not sure about home routers. End users have the choice to buy an IPv6 enabled home router. - Do we have a clear tunnel architecture? I don't think so. We have 6to4 and configured tunnels. Is 6to4 also for single end user systems? Do we agree on the security issues of 6to4? Are tunnel brokers enough? Do we need tsp? Do we need to work on translation (NAT-PT, SIIT, etc)? I am not sure. At least we should discourage it because in many cases there are better alternatives. rvdp From owner-v6ops@ops.ietf.org Tue Feb 11 09:59: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 JAA07218 for ; Tue, 11 Feb 2003 09:59:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ibuv-0003UK-00 for v6ops-data@psg.com; Tue, 11 Feb 2003 07:01:49 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org) by psg.com with esmtp (Exim 3.36 #1) id 18ibur-0003U8-00 for v6ops@ops.ietf.org; Tue, 11 Feb 2003 07:01:45 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 44D197CB2; Tue, 11 Feb 2003 16:01:41 +0100 (CET) Received: from cyan (gprsdemo.azr.nl [::ffff:156.83.254.8]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id C0D977BAD; Tue, 11 Feb 2003 16:01:35 +0100 (CET) From: "Jeroen Massar" To: "'Ronald van der Pol'" , "'Pekka Savola'" Cc: Subject: RE: transition architecture discussion Date: Tue, 11 Feb 2003 16:02:45 +0100 Organization: Unfix Message-ID: <010d01c2d1de$a2e6e120$534510ac@cyan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 In-Reply-To: <20030211140206.GC692@rvdp.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ronald van der Pol wrote: > On Mon, Feb 10, 2003 at 17:22:19 +0200, Pekka Savola wrote: > > > .. it is by far not perfect (I didn't have any time to work > on it except > > the last night), and includes personal opinions (of course > :-), but could > > be usable as something concrete to build discussion on, if needed. > > Thanks for starting this discussion. > > I think we also need to finish the scenario drafts soon (hint, hint). > > It would also be useful to find out why people are not deploying/ > using/requesting IPv6. I think the most important answer to the 'why' is simply the big chicken and egg problem: - Why should an client-access provider get IPv6 when his/her/it's/... customers don't want (but probably do need it because of NAT). - Why should a hoster do IPv6 when there are no clients to use it. - Why should a application programmer do IPv6 when there is no infrastructure to use it's potential? Combining the above with the imho bad excuse of 'bad economy' both the hoster and the access provider won't do a thing in the right direction. Btw.. the application programmer has it the easiest of all, they "only" have to modify a couple of lines of code to make their product mostly IPv6 aware except for dialog boxes, logging, acl's and some odd protocols. Currently there is a nice thread (wonder o wonder) on slashdot: http://slashdot.org/article.pl?sid=03/02/09/2038223 "IPv6 Application Competition - win $10,000" Maybe that will take care of the third issue. Odd part is that slashdot.org doesn't do IPv6 at all even though they did run a couple of articles. Maybe tools like http://ipv6gate.sixxs.net will resolve that at least all sites are available over IPv6... Seeing the recent jumps in TLA allocations some ISP's are on the right way, now we only need to convince the hosters one way or another. Having a google that does IPv6, both the www.google.com and localisations and the bot would be a great leap forward. For the rest we just need to make ISP's & hosters & programmers more IPv6 aware... Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Feb 11 12:50:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12975 for ; Tue, 11 Feb 2003 12:50:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ieYr-000AQJ-00 for v6ops-data@psg.com; Tue, 11 Feb 2003 09:51:13 -0800 Received: from moringa.csuchico.edu ([132.241.82.49] helo=ESCHE.csuchico.edu) by psg.com with esmtp (Exim 3.36 #1) id 18ieYp-000AQ7-00 for v6ops@ops.ietf.org; Tue, 11 Feb 2003 09:51:11 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: transition architecture discussion Date: Tue, 11 Feb 2003 09:50:22 -0800 Message-ID: <9ADE954C5044754C8E0BF406B5A2175547D286@ESCHE.csuchico.edu> Thread-Topic: transition architecture discussion thread-index: AcLR4fT8+RELlU2nTMOQZK8QWrRNlgADLwFA From: "Pike, Ronald" To: "Jeroen Massar" , "Ronald van der Pol" , "Pekka Savola" Cc: X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA12975 >I think the most important answer to the 'why' is simply the big >chicken and egg problem: > - Why should an client-access provider get IPv6 when his/her/it's/... > customers don't want (but probably do need it because of NAT). > - Why should a hoster do IPv6 when there are no clients to use it. > - Why should a application programmer do IPv6 when there is no > infrastructure to use it's potential? Educating end users is one of the next important steps. I am working on a user manual of sorts that I plan to use in classes I am teaching on network design as well as distribute publicly in some forum. I am attempting to develop a mix of information on why IPv6 should be important to many organizations, as well as some howto type of information on deploying the protocol. When there are well designed technical workshops on this subject in vendor conferences such as Cisco's Networkers conference, Linux vendors and Microsoft conferences, as well as planning information being targeted at CIO's through periodicals, then enterprises will start to demand IPv6. When enterprises demand the service, ISP's will scramble to provide it. I appreciate the many great ideas I have received on this mailing list and also any other ideas or information anyone has for raising public awareness on this issue. -Ron Pike California State University, Chico From owner-v6ops@ops.ietf.org Tue Feb 11 14:23:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15937 for ; Tue, 11 Feb 2003 14:23:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ig1W-000Cer-00 for v6ops-data@psg.com; Tue, 11 Feb 2003 11:24:54 -0800 Received: from [3ffe:8114:1000::27] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18ig1S-000Cea-00 for v6ops@ops.ietf.org; Tue, 11 Feb 2003 11:24:50 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id AC67D85FB; Tue, 11 Feb 2003 20:24:45 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 719E07BAD; Tue, 11 Feb 2003 20:24:39 +0100 (CET) From: "Jeroen Massar" To: "'Pike, Ronald'" , "'Ronald van der Pol'" , "'Pekka Savola'" Cc: Subject: RE: transition architecture discussion Date: Tue, 11 Feb 2003 20:24:55 +0100 Organization: Unfix Message-ID: <000c01c2d203$445d5f60$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <9ADE954C5044754C8E0BF406B5A2175547D286@ESCHE.csuchico.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15937 Pike, Ronald [mailto:RPike@csuchico.edu] wrote: > >I think the most important answer to the 'why' is simply the big > >chicken and egg problem: > > - Why should an client-access provider get IPv6 when > his/her/it's/... > > customers don't want (but probably do need it because of NAT). > > - Why should a hoster do IPv6 when there are no clients to use it. > > - Why should a application programmer do IPv6 when there is no > > infrastructure to use it's potential? > I appreciate the many great ideas I have received on this > mailing list > and also any other ideas or information anyone has for raising public > awareness on this issue. I've collected some similar documents in http://www.sixxs.net/presentations/ Especially the one given by Steve Deering, which actually is a masterclass is very interresting and detailed, though one does need quite some insight into the material. If somebody queries about IPv6 I usually point them to that presentation. As for awareness, the talks given at AIAD could give some information about deployment inside ISP's related to AMS-IX. Check the NLNetlabs site at: http://www.nlnetlabs.nl/ipv6/aiad/index.html presentations.html for the presentations, but Ronald can tell you more about that ;) Maybe a good start would be to have a central place where all this is available, there are currently *many* sites having useful information but these sites are all splattered around the internet. There was quite a useful site http://hs247.com but unfortunatly due to time constraints this site has not been updated for quite a while. It would be great if there was a central repository where people could submit their IPv6 stories, links, presentations, tutorials etc. It would ensure that people looking for information could at least find the information they where looking for at a central place, without having to google half of the internet. And no, I am not talking about yet another RFC mirror ;) Any more thoughts about this? Greets, Jeroen From owner-v6ops@ops.ietf.org Tue Feb 11 21:46: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 VAA25928 for ; Tue, 11 Feb 2003 21:46:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18imwu-0000Yg-00 for v6ops-data@psg.com; Tue, 11 Feb 2003 18:48:36 -0800 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 18imws-0000YU-00 for v6ops@ops.ietf.org; Tue, 11 Feb 2003 18:48:34 -0800 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 564194B24 for ; Wed, 12 Feb 2003 11:48:33 +0900 (JST) To: v6ops@ops.ietf.org Subject: no overhead projector starting SF 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 From: itojun@iijlab.net Date: Wed, 12 Feb 2003 11:48:33 +0900 Message-Id: <20030212024833.564194B24@coconut.itojun.org> X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk in case if you plan to use overhead projectors... itojun ------- Forwarded Message From: Marcia Beaulieu Subject: IETF Meetings and Overhead Projectors Hi all, Starting with the IETF meeting in San Francisco, overhead projectors will not be provided in the meeting rooms unless specifically requested. Data projectors will be in all working group and BOF meeting rooms. If you feel there is a need for an overhead projector in your session, please send your request to agenda@ietf.org Thanks, Marcia ------- End of Forwarded Message From owner-v6ops@ops.ietf.org Wed Feb 12 10:03: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 KAA05383 for ; Wed, 12 Feb 2003 10:03:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iyQ0-0003UD-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 07:03:24 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18iyPx-0003Tp-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 07:03:21 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18iyPx-0000SN-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 07:03:21 -0800 Message-Id: <5.2.0.9.0.20030211113742.0223e758@mail.addr.com> In-Reply-To: <000c01c2d203$445d5f60$210d640a@unfix.org> References: <9ADE954C5044754C8E0BF406B5A2175547D286@ESCHE.csuchico.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Tue, 11 Feb 2003 11:38:49 -0800 To: "Jeroen Massar" From: Bob Fink Subject: RE: transition architecture discussion Cc: X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] At 08:24 PM 2/11/2003 +0100, Jeroen Massar wrote: >Pike, Ronald [mailto:RPike@csuchico.edu] wrote: > > > >I think the most important answer to the 'why' is simply the big > > >chicken and egg problem: > > > - Why should an client-access provider get IPv6 when > > his/her/it's/... > > > customers don't want (but probably do need it because of NAT). > > > - Why should a hoster do IPv6 when there are no clients to use it. > > > - Why should a application programmer do IPv6 when there is no > > > infrastructure to use it's potential? > > > I appreciate the many great ideas I have received on this > > mailing list > > and also any other ideas or information anyone has for raising public > > awareness on this issue. > >I've collected some similar documents in >http://www.sixxs.net/presentations/ >Especially the one given by Steve Deering, which actually is a >masterclass >is very interresting and detailed, though one does need quite some >insight >into the material. If somebody queries about IPv6 I usually point them >to >that presentation. As for awareness, the talks given at AIAD could give >some information about deployment inside ISP's related to AMS-IX. >Check the NLNetlabs site at: >http://www.nlnetlabs.nl/ipv6/aiad/index.html presentations.html for the >presentations, but Ronald can tell you more about that ;) > >Maybe a good start would be to have a central place where all this is >available, there are currently *many* sites having useful information >but these sites are all splattered around the internet. There was quite >a useful site http://hs247.com but unfortunatly due to time constraints >this site has not been updated for quite a while. It would be great >if there was a central repository where people could submit their IPv6 >stories, links, presentations, tutorials etc. It would ensure that >people looking for information could at least find the information >they where looking for at a central place, without having to google >half of the internet. And no, I am not talking about yet another >RFC mirror ;) Any more thoughts about this? I'm always willing to host such as this on the 6bone site. Bob From owner-v6ops@ops.ietf.org Wed Feb 12 10:18: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 KAA05835 for ; Wed, 12 Feb 2003 10:18:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iyi8-0004EH-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 07:22:08 -0800 Received: from alc239.alcatel.be ([195.207.101.239] helo=mail.alcatel.be) by psg.com with esmtp (Exim 3.36 #1) id 18iyi4-0004Du-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 07:22:04 -0800 Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h1CFLvG10394 for ; Wed, 12 Feb 2003 16:21:57 +0100 (MET) Received: from alcatel.be ([138.203.64.126]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003021216215503:5379 ; Wed, 12 Feb 2003 16:21:55 +0100 Message-ID: <3E4A668F.5DC7FC34@alcatel.be> Date: Wed, 12 Feb 2003 16:21:52 +0100 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: 3GPP analysis X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/12/2003 16:21:55, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/12/2003 16:21:57, Serialize complete at 02/12/2003 16:21:57 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=1.6 required=5.0 tests=NOSPAM_INC,NO_REAL_NAME,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, After reading section 4.2 'IMS to IPv4 node' of [draft-ietf-v6ops-3gpp-analysis-01.txt] I have a few small questions on how this would work in practice. 1) If the destination is an IPv4 node registered to a dual stack SIP server, is the interworking then by default handled outside the IMS operator's network or are there ways to keep the control whithin the IMS operator's network. 2) How is the SIP-ALG added in the path for outgoing SIP calls (assuming the SIP-ALG is only in the path when needed). Is it a configuration in the S-CSCF, e.g. if DNS resolve only returns a IPv4 address then forward SIP messages to SIP-ALG, SIP-ALG then resends again the same DNS query to find the next 'IPv4' hop. 3) For incomming SIP sessions how is decided if the call should go to the I-CSCF or the SIP-ALG. Is this done based on DNS information in the IMS operator network, IPv6 address corresponding to I-CSCF, IPv4 address to SIP-ALG. This would result in external IPv6 SIP server sending their messages to the I-CSCF and IPv4 servers forwarding SIP to the SIP-ALG. How about external SIP server that are dual stack, where does it forward SIP messages to. Wouldn't it be easier if the ALG functionality for IMS would be integrated in the I-CSCF or S-CSCF although there was heavy resistance for this in 3GPP. My apologies if these questions were already addressed in the past. Regards, Suresh From owner-v6ops@ops.ietf.org Wed Feb 12 10:54: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 KAA07082 for ; Wed, 12 Feb 2003 10:54:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18izG8-0005hj-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 07:57:16 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18izG5-0005hT-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 07:57:14 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5CBCF3D77 for ; Wed, 12 Feb 2003 10:57:11 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 10:57:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: transition architecture discussion Date: Wed, 12 Feb 2003 10:57:10 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06BC@tayexc13.americas.cpqcorp.net> Thread-Topic: transition architecture discussion Thread-Index: AcLSqKe5H06kX3bsTuC/ozC5CVSCcwABhtGw From: "Bound, Jim" To: X-OriginalArrivalTime: 12 Feb 2003 15:57:11.0265 (UTC) FILETIME=[67385510:01C2D2AF] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07082 This is a good draft and piece of work we should expand upon. It adds to the scenarios work and I esp agree about the note that we need to get consensus on our assumptions. That being said in a few days you will get updated Enterprise Scenario draft and the team has come up with a way to check boxes as Pekka's draft suggests for transition for our work on the Enterprise. We need to get people to agree to our algorithm for the Enterprise Scenarios and we hope what you will see in the next draft will do that. Then we can begin to fill in the parts waiting for that agreement.3 But we will keep moving forward. Transition architecture draft should be pursued. Though I don't fully agree with the statements about the usefulness of DSTM and would suggest this work not speak of any specific mechanism and speak only to the architeture discussion. Regards, /jim From owner-v6ops@ops.ietf.org Wed Feb 12 11:04: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 LAA07376 for ; Wed, 12 Feb 2003 11:04:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18izPP-000632-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 08:06:51 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18izPE-00062U-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 08:06:40 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 23BD33C42 for ; Wed, 12 Feb 2003 11:06:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 11:06:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2B0.B96CEDE4" Subject: NGTRANS notes and DSTM Status Date: Wed, 12 Feb 2003 11:06:38 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED3@tayexc13.americas.cpqcorp.net> Thread-Topic: NGTRANS notes and DSTM Status Thread-Index: AcLSsLnqOUTXtt+wROCSjmiY+YuTfg== From: "Bound, Jim" To: X-OriginalArrivalTime: 12 Feb 2003 16:06:39.0046 (UTC) FILETIME=[B9A4D660:01C2D2B0] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D2B0.B96CEDE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Margaret, =20 This is just note on the recent strategies for ngtrans work. Please kill the DSTM drafts that exist now. The designers and implementors of DSTM will build a new specification of DSTM that is complete as it was in the first incantations of DSTM. We then will do two things is the plan. 1) We will submit as Experimental RFC, and 2) Promote this specification within the vendor and user community with implementation code base reference in the public domain. So we will provide an IETF process for this spec, but at the same time provide implemetation and specification to those wanting to do DSTM for the reasons DSTM exists for early adopter IPv6 users that will transition with the strategy to reduce IPv4 routing backbone immediately on their Intranet environment, to support a dominant IPv6 routing backbone as a first phase IPv6 transition strategy. We have also received superb security issues we will address from mission critical early adopters of IPv6 to make it a more secure transition mechanism than previous incantations of the spec. I am still figuring out the Experimental RFC process as documented but it will provide a means for some input from the IETF community in some manner is my knowledge currently. =20 =20 Sincerely, /jim =20 =20 =20 =20 =20 ------_=_NextPart_001_01C2D2B0.B96CEDE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Margaret,
 
This = is just note on=20 the recent strategies for ngtrans work.  Please kill the DSTM = drafts that=20 exist now.  The designers and implementors of DSTM will build a new = specification of DSTM that is complete as it was in the first = incantations of=20 DSTM.
We = then will do two=20 things is the plan.  1) We will submit as Experimental RFC, and 2) = Promote=20 this specification within the vendor and user community with = implementation code=20 base reference in the public domain.  So we will provide an IETF = process=20 for this spec, but at the same time provide implemetation and = specification to=20 those wanting to do DSTM for the reasons DSTM exists for early adopter = IPv6=20 users that will transition with the strategy to reduce IPv4 routing = backbone=20 immediately on their Intranet environment, to support a dominant IPv6 = routing=20 backbone as a first phase IPv6 transition strategy.  We have also = received=20 superb security issues we will address from mission critical early = adopters of=20 IPv6 to make it a more secure transition mechanism than previous=20 incantations of the spec.

I = am still=20 figuring out the Experimental RFC process as documented but it will = provide a=20 means for some input from the IETF community in some manner is my = knowledge=20 currently. 
 
Sincerely,
/jim
 
 
 
 
 
=00 ------_=_NextPart_001_01C2D2B0.B96CEDE4-- From owner-v6ops@ops.ietf.org Wed Feb 12 11:04: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 LAA07390 for ; Wed, 12 Feb 2003 11:04:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18izPb-00063T-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 08:07:03 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18izPY-00063E-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 08:07:00 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18izPY-0000j0-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 08:07:00 -0800 Message-Id: <20030212092106.333a5eb4.join@uni-muenster.de> In-Reply-To: <010d01c2d1de$a2e6e120$534510ac@cyan> References: <20030211140206.GC692@rvdp.org> <010d01c2d1de$a2e6e120$534510ac@cyan> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.AGUTI)WAESm5Qj" Date: Wed, 12 Feb 2003 09:21:06 +0100 From: Christian Strauf To: v6ops@ops.ietf.org Subject: Re: transition architecture discussion X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES, RESENT_TO,SIGNATURE_LONG_SPARSE,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=.AGUTI)WAESm5Qj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > I think the most important answer to the 'why' is simply the big > chicken and egg problem: I think you're right. In my opinion it would be the best idea to simply create a chicken first which then lays the eggs. :-) It probably is a good idea to put a lot of effort into migrating most of the educational networks to IPv6 so that new generations get used to having IPv6 arround. Maybe the convenience of having IPv6 available during their educational phase will then also be important later in their jobs. People usually don't want to give up things they're used to having around. Maybe out of this motivation, the "need" for IPv6 outside the educational sector will arise. It's easier dealing with something that you're "brought up" with (having IPv6, that is) rather than having to implement something completely new that you're not familiar with and that customers also don't have an understanding of. And this will most likely make it easier for those generations to see the advantages of IPv6 in commercial networks (both as customers and as service providers). IMHO it is all about IPv6 becoming a "natural" thing in the internet world. Just my 2-EUR-cents. Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653 --=.AGUTI)WAESm5Qj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+SgP2ouGoCh36qpoRAjSXAJ9wosYF+mEC+lGhP+tt+K26ldtP8wCgsUtw RpYW6GCdQabdQeAZbA2iWYU= =oaVA -----END PGP SIGNATURE----- --=.AGUTI)WAESm5Qj-- From owner-v6ops@ops.ietf.org Wed Feb 12 11:17: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 LAA07729 for ; Wed, 12 Feb 2003 11:17:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18izcq-0006WN-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 08:20:44 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18izck-0006W0-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 08:20:39 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D488A898B; Wed, 12 Feb 2003 11:20:37 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 11:20:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: transition architecture discussion Date: Wed, 12 Feb 2003 11:20:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06BF@tayexc13.americas.cpqcorp.net> Thread-Topic: transition architecture discussion Thread-Index: AcLSsTmWW63V9z9+Toel1N4T8I63SQAATVVw From: "Bound, Jim" To: "Christian Strauf" , X-OriginalArrivalTime: 12 Feb 2003 16:20:37.0078 (UTC) FILETIME=[AD265F60:01C2D2B2] X-Spam-Status: No, hits=0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07729 Do not disagree with the below it is good perspective. But I think the word "transition" is more prudent than "migration" in our deliberations? Also do we want to discuss the business case and reasons for IPv6 deployment here? Regards, /jim >-----Original Message----- >From: Christian Strauf [mailto:join@uni-muenster.de] >Sent: Wednesday, February 12, 2003 3:21 AM >To: v6ops@ops.ietf.org >Subject: Re: transition architecture discussion > > >[ post by non-subscriber. with the massive amount of spam, it >is easy to miss > and therefore delete posts by non-subscribers. if you wish >to regularly > post from an address that is not subscribed to this mailing >list, send a > message to -owner@ops.ietf.org and ask to have the >alternate > address added to the list of addresses from which submissions are > automatically accepted. ] > >> I think the most important answer to the 'why' is simply the big >> chicken and egg problem: >I think you're right. In my opinion it would be the best idea >to simply create a chicken first which then lays the eggs. :-) >It probably is a good idea to put a lot of effort into >migrating most of the educational networks to IPv6 so that new >generations get used to having IPv6 arround. Maybe the >convenience of having IPv6 available during their educational >phase will then also be important later in their jobs. People >usually don't want to give up things they're used to having >around. Maybe out of this motivation, the "need" for IPv6 >outside the educational sector will arise. It's easier dealing >with something that you're "brought up" with (having IPv6, >that is) rather than having to implement something completely >new that you're not familiar with and that customers also >don't have an understanding of. And this will most likely make >it easier for those generations to see the advantages of IPv6 >in commercial networks (both as customers and as service >providers). IMHO it is all about IPv6 becoming a "natural" >thing in the internet world. > >Just my 2-EUR-cents. > >Christian > >-- >JOIN - IP Version 6 in the WiN Christian Strauf >A DFN project Westfaelische >Wilhelms-Universitaet Muenster >http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung >Team: join@uni-muenster.de Roentgenstrasse 9-13 >Priv: strauf@uni-muenster.de D-48149 Muenster / Germany >GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: >+49 251 83 31653 > From owner-v6ops@ops.ietf.org Wed Feb 12 12:11: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 MAA09075 for ; Wed, 12 Feb 2003 12:11:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j0Sa-000874-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 09:14:12 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 18j0SV-00086m-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 09:14:07 -0800 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 12 Feb 2003 09:14:06 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Feb 2003 09:14:06 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Wed, 12 Feb 2003 09:14:06 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 12 Feb 2003 09:13:52 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 12 Feb 2003 09:13:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: transition architecture discussion Date: Wed, 12 Feb 2003 09:13:02 -0800 Message-ID: Thread-Topic: transition architecture discussion thread-index: AcLSsTmWW63V9z9+Toel1N4T8I63SQAATVVwAAHQOkA= From: "Christian Huitema" To: "Bound, Jim" , "Christian Strauf" , X-OriginalArrivalTime: 12 Feb 2003 17:13:15.0208 (UTC) FILETIME=[078AC480:01C2D2BA] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09075 > Do not disagree with the below it is good perspective. But I think the > word "transition" is more prudent than "migration" in our deliberations? The first order work is neither transition nor migration, but deployment. The discussions in the last months have consistently outlined a consensus towards "dual stack deployment", in order to enable new applications, rather than "translation for transition". -- Christian Huitema From owner-v6ops@ops.ietf.org Wed Feb 12 12:18: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 MAA09301 for ; Wed, 12 Feb 2003 12:18:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j0Zu-0008Lz-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 09:21:46 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18j0Zm-0008LV-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 09:21:38 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B516A5FED for ; Wed, 12 Feb 2003 12:21:37 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 12:21:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2BB.32D340E6" Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 12 Feb 2003 12:21:37 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED7@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLSuzNGCA6Ed7kHTO6mtEsvIQ3VRA== From: "Bound, Jim" To: X-OriginalArrivalTime: 12 Feb 2003 17:21:37.0632 (UTC) FILETIME=[33029600:01C2D2BB] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D2BB.32D340E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 I am hearing an need for home users for transition. It could be this is ipv6 wg work but will bounce it off here first. =20 Assume dominant NAT/VPN/Firewall routers in most homes for Internet access. =20 Assume an upstream provider obtains IPv6 prefix to give to subscribers. =20 Assume home routers want to support IPv6 and will eventually but won't move until they believe it can be used over provider networks. =20 Assume there is not enough Ipv4 address space for providers to give out to all subscribers or cannot at reasonable cost. But they can give the subscriber an IPv6 prefix. This means 6to4 or ISATAP won't work in this scenario in the users home. =20 A solution (more on Teredo below) would be to figure a method for an IPv6 on the homelan to be encaped in the NAT packet to the provider who will decap that packet and send to the IPv6 destination and recall the state to the NAT user upon receiving packets back so the session can be established with the home user over the net. =20 This is quick for now as a thought. =20 The home user network encaps the IPv6 packet at NAT with Protocol ID equivalent to "6". The provider then takes that packet and decaps at their edge and uses native IPv6 or 6to4 to encap that packet to where the IPv6 service is located. I realize this has many assumptions and I would work on those with some other folks interested in this problem. =20 =20 I am re-reading Teredo now and working to see if it is addendum to Teredo or completely different solution. I think it is a different solution and possibly much simpler. I also believe this solution we are looking at can do e2e IPsec over the IPv4-NAT. =20 This would be a minor initial update for the home router vendors and basic IPv6 edge tunneling for the Provider. Also I think a tunnel-broker could be used by the Provider to help set this up for users too. The code for the home router on my first analysis could also be a firmware upgrade that is down loadable. =20 Could I get others opinions and thoughts on this before I and some others jump in here. =20 thanks /jim =20 =20 =20 =20 =20 ------_=_NextPart_001_01C2D2BB.32D340E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Folks,
 
I am = hearing an need=20 for home users for transition.  It could be this is ipv6 wg work = but will=20 bounce it off here first.
 
Assume = dominant=20 NAT/VPN/Firewall routers in most homes for Internet = access.
 
Assume = an upstream=20 provider obtains IPv6 prefix to give to subscribers.
 
Assume = home routers=20 want to support IPv6 and will eventually but won't move until they = believe it=20 can be used over provider networks.
 
Assume = there is not=20 enough Ipv4 address space for providers to give out to all subscribers = or cannot=20 at reasonable cost.  But they can give the subscriber an IPv6 = prefix. =20 This means 6to4 or ISATAP won't work in this scenario in the users=20 home.
 
A = solution (more on=20 Teredo below) would be to figure a method for an IPv6 on the homelan to = be=20 encaped in the NAT packet to the provider who will decap that packet and = send to=20 the IPv6 destination and recall the state to the NAT user upon receiving = packets=20 back so the session can be established with the home user over the=20 net.
 
This = is quick for=20 now as a thought.
 
The = home user=20 network encaps the IPv6 packet at NAT with Protocol ID equivalent to = "6". =20 The provider then takes that packet and decaps at their edge and uses = native=20 IPv6 or 6to4 to encap that packet to where the IPv6 service is = located.  I=20 realize this has many assumptions and I would work on those with some = other=20 folks interested in this problem. 
 
I am = re-reading=20 Teredo now and working to see if it is addendum to Teredo or completely=20 different solution.  I think it is a different solution and = possibly much=20 simpler.  I also believe this solution we are looking at can do e2e = IPsec=20 over the IPv4-NAT.
 
This = would be a=20 minor initial update for the home router vendors and basic IPv6 edge = tunneling=20 for the Provider.  Also I think a tunnel-broker could be used by = the=20 Provider to help set this up for users too.  The code for the home = router=20 on my first analysis could also be a firmware upgrade that is down=20 loadable.
 
Could = I get others=20 opinions and thoughts on this before I and some others jump in=20 here.
 
thanks
/jim
 
 
 
 
 
=00 ------_=_NextPart_001_01C2D2BB.32D340E6-- From owner-v6ops@ops.ietf.org Wed Feb 12 12:21: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 MAA09341 for ; Wed, 12 Feb 2003 12:21:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j0cZ-0008Rp-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 09:24:31 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18j0cT-0008RX-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 09:24:25 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4651A1A3C; Wed, 12 Feb 2003 12:24:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 12:24:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: transition architecture discussion Date: Wed, 12 Feb 2003 12:24:23 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06C9@tayexc13.americas.cpqcorp.net> Thread-Topic: transition architecture discussion Thread-Index: AcLSsTmWW63V9z9+Toel1N4T8I63SQAATVVwAAHQOkAAAGUtQA== From: "Bound, Jim" To: "Christian Huitema" , "Christian Strauf" , X-OriginalArrivalTime: 12 Feb 2003 17:24:23.0928 (UTC) FILETIME=[96215780:01C2D2BB] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09341 >> Do not disagree with the below it is good perspective. But I think >the >> word "transition" is more prudent than "migration" in our >deliberations? > >The first order work is neither transition nor migration, but >deployment. The discussions in the last months have >consistently outlined a consensus towards "dual stack >deployment", in order to enable new applications, rather than >"translation for transition". I don't disagree with you and am in tune with the list. I have no clue why my mail elicit this commentary from you? My point is that in the world of deployment it will be a transition not a migration. So I don't get your comments purpose? /jim From owner-v6ops@ops.ietf.org Wed Feb 12 12:35: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 MAA09669 for ; Wed, 12 Feb 2003 12:35:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j0qH-0008yN-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 09:38:41 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 18j0qA-0008xU-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 09:38:34 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18j0q9-00019O-00; Wed, 12 Feb 2003 09:38:34 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 12 Feb 2003 09:38:33 -0800 To: Christian Huitema Cc: v6ops@ops.ietf.org Subject: RE: transition architecture discussion References: Message-Id: X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit i think it was brian who pointed out that the better term may be 'coexistence' randy From owner-v6ops@ops.ietf.org Wed Feb 12 12:40: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 MAA09792 for ; Wed, 12 Feb 2003 12:40:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j0vA-0009A0-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 09:43:44 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18j0v6-00099k-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 09:43:40 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B89DD8491; Wed, 12 Feb 2003 12:43:38 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 12:43:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: transition architecture discussion Date: Wed, 12 Feb 2003 12:43:37 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06CC@tayexc13.americas.cpqcorp.net> Thread-Topic: transition architecture discussion Thread-Index: AcLSveULoGsVATdpSU6wMToo18DeWAAACYDA From: "Bound, Jim" To: "Randy Bush" , "Christian Huitema" Cc: X-OriginalArrivalTime: 12 Feb 2003 17:43:38.0406 (UTC) FILETIME=[4640B460:01C2D2BE] X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09792 I can live with coexistence for sure. Just migration is an illusion. Could we at least here get folks to use that then? This will influence out of the IETF too I think and serve a good purpose from the leadership here for those referencing the process of v6ops for the Internet. /jim >-----Original Message----- >From: Randy Bush [mailto:randy@psg.com] >Sent: Wednesday, February 12, 2003 12:39 PM >To: Christian Huitema >Cc: v6ops@ops.ietf.org >Subject: RE: transition architecture discussion > > >i think it was brian who pointed out that the better term may >be 'coexistence' > >randy > > > From owner-v6ops@ops.ietf.org Wed Feb 12 12:58: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 MAA10208 for ; Wed, 12 Feb 2003 12:58:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j1Cl-0009m0-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 10:01:55 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18j1Ch-0009lm-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 10:01:51 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3E4827347 for ; Wed, 12 Feb 2003 13:01:50 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 13:01:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2C0.D0D0CE32" Subject: Deployment of Dual Stack with Applications Date: Wed, 12 Feb 2003 13:01:49 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED9@tayexc13.americas.cpqcorp.net> Thread-Topic: Deployment of Dual Stack with Applications Thread-Index: AcLSwNE/gMAafiRzSJe446B3Spvp4Q== From: "Bound, Jim" To: X-OriginalArrivalTime: 12 Feb 2003 18:01:50.0148 (UTC) FILETIME=[D0FB5040:01C2D2C0] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D2C0.D0D0CE32 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 First I think the consensus for dual stack is clearly making head way finally in and out of the IETF. =20 But here is a real operational scenario for us I am working on right now. =20 User believe IPv6 is important and they want to deploy. The need to worry about all the things we discuss here but there is another one. When do they tell their suppliers they MUST support IPv6 and how does this work? And when does IPv6 get turned on? =20 The good thing about a dual stack approach is these users can mandate all suppliers must support the dual IPv6/IPv4 stack for procurement at some specified point in time. But they will most likely have to run IPv4 intiially on those procured boxes until the v6ops type parts are figured out and applications are ported. =20 Now to the technical issue. =20 How are the apps ported and at what point on the suppliers boxes? =20 Using IPv4-Mapped addresses in the base API an app could port to IPv6 and take IPv6 addresses and IPv4Mapped addresses from getaddrinfo() (old gethostbyname() for those that don't know getaddrinfo() yet) and pass down IPv4-Mapped addresses to a dual stack implementation and they will be put out over the network as IPv4 by a dual stack node, but to the application layer they are just doing IPv6. =20 This will be part of the deployment recommendations from vendors, consultants, and systems integrators for users and some users will figure this out on their own and large application software providers that only want to release one binary for both IPv4 and IPv6. =20 I am not sure if we should put this into any docs for v6ops or not? It could be viewed as implementation deployment effort and issue not a standars issue? But it should be part of our emerging scenarios is my belief currently (all of them)? =20 Comments. =20 Regards, /jim =20 =20 =20 =20 =20 ------_=_NextPart_001_01C2D2C0.D0D0CE32 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Folks,
 
First = I think the=20 consensus for dual stack is clearly making head way finally in and out = of the=20 IETF.
 
But = here is a real=20 operational scenario for us I am working on right = now.
 
User = believe IPv6 is=20 important and they want to deploy.  The need to worry about all the = things=20 we discuss here but there is another one.  When do they tell their=20 suppliers they MUST support IPv6 and how does this work?  And when = does=20 IPv6 get turned on?
 
The = good thing about=20 a dual stack approach is these users can mandate all suppliers must = support the=20 dual IPv6/IPv4 stack for procurement at some specified point in time. = But they=20 will most likely have to run IPv4 intiially on those procured boxes = until the=20 v6ops type parts are figured out and applications are=20 ported.
 
Now to = the technical=20 issue.
 
How = are the apps=20 ported and at what point on the suppliers boxes?
 
Using = IPv4-Mapped=20 addresses in the base API an app could port to IPv6 and take IPv6 = addresses and=20 IPv4Mapped addresses from getaddrinfo() (old gethostbyname() for those = that=20 don't know getaddrinfo() yet) and pass down IPv4-Mapped addresses to a = dual=20 stack implementation and they will be put out over the network as IPv4 = by a dual=20 stack node, but to the application layer they are just doing=20 IPv6.
 
This = will be part of=20 the deployment recommendations from vendors, consultants, and systems=20 integrators for users and some users will figure this out on their own = and large=20 application software providers that only want to release one binary for = both=20 IPv4 and IPv6.
 
I am = not sure if we=20 should put this into any docs for v6ops or not?  It could be viewed = as=20 implementation deployment effort and issue not a standars issue? But it = should=20 be part of our emerging scenarios is my belief currently (all of=20 them)?
 
Comments.
 
Regards,
/jim
 
 
 
 
 
=00 ------_=_NextPart_001_01C2D2C0.D0D0CE32-- From owner-v6ops@ops.ietf.org Wed Feb 12 13:03: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 NAA10402 for ; Wed, 12 Feb 2003 13:03:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j1He-0009wN-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 10:06:58 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org) by psg.com with esmtp (Exim 3.36 #1) id 18j1HX-0009w0-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 10:06:51 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 881F27C00; Wed, 12 Feb 2003 19:06:47 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 44CF28397; Wed, 12 Feb 2003 19:06:38 +0100 (CET) From: "Jeroen Massar" To: "'Bound, Jim'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 12 Feb 2003 19:06:43 +0100 Organization: Unfix Message-ID: <005401c2d2c1$810a1d40$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED7@tayexc13.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA10402 Bound, Jim wrote: > > I am hearing an need for home users for transition. It could > be this is ipv6 wg work but will bounce it off here first. > Could I get others opinions and thoughts on this before I and > some others jump in here. Based on your assumptions you would have something similar too: { Internet } - { ISP } - - { many endusers } The NAT-box/router will have both have a public IPv4 and IPv6: internet side IPv4: 1.2.3.4 user side IPv4: 10.0.0.1 internet side IPv6: 2001:db8::0:1 user side IPv6: 2001:db8::1:2 First of all the ISP could choose to simply have all its routers understand native IPv6. But ofcourse this is a nogo with most hardware, and as apparently the ISP can't get IPv4 space it prolly won't have enough cash to get new hardware too. Thus the cheap alternative: Fix up a Tunnelbroker on the NAT box (or on a second machine) which can be connected to the public internet giving it the above 2 IPv6 addresses and one private / 'userside' IPv4 address. The endusers can the build a tunnel from their 10.0.0.0/24 IPv4 address to the 10.0.0.1 IPv4 address and route their IPv6 traffic over that. Ofcourse this would require something automatic for the enduser as not every enduser is a computer guru. The Freenet6 TSP protocol and others could be used to complement this. I am currently in the process of finishing up the autoconfig tool for the SixXS project which allows a similar concept to work without any user intervention. Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Feb 12 13:52: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 NAA11710 for ; Wed, 12 Feb 2003 13:52:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j22h-000Boj-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 10:55:35 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18j22V-000Bne-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 10:55:23 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7370E342B for ; Wed, 12 Feb 2003 13:55:21 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 13:55:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2C8.4AC190A9" Subject: RE: Deployment of Dual Stack with Applications Date: Wed, 12 Feb 2003 13:55:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06D3@tayexc13.americas.cpqcorp.net> Thread-Topic: Deployment of Dual Stack with Applications Thread-Index: AcLSwNE/gMAafiRzSJe446B3Spvp4QAByVqw From: "Bound, Jim" To: X-OriginalArrivalTime: 12 Feb 2003 18:55:21.0206 (UTC) FILETIME=[4AEBE160:01C2D2C8] X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_FONT_COLOR_BLUE,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D2C8.4AC190A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is pointer to API paper users are downloading too. I am traveling now so may not respond to email for my interrupts to the mail list till next week depending on schedules and stuff. =20 http://www.nav6tf.org/slides/trans_ipv6_v013.pdf =20 /jim =20 =20 =20 -----Original Message----- From: Bound, Jim=20 Sent: Wednesday, February 12, 2003 1:02 PM To: v6ops@ops.ietf.org Subject: Deployment of Dual Stack with Applications =09 =09 Folks, =20 First I think the consensus for dual stack is clearly making head way finally in and out of the IETF. =20 But here is a real operational scenario for us I am working on right now. =20 User believe IPv6 is important and they want to deploy. The need to worry about all the things we discuss here but there is another one. When do they tell their suppliers they MUST support IPv6 and how does this work? And when does IPv6 get turned on? =20 The good thing about a dual stack approach is these users can mandate all suppliers must support the dual IPv6/IPv4 stack for procurement at some specified point in time. But they will most likely have to run IPv4 intiially on those procured boxes until the v6ops type parts are figured out and applications are ported. =20 Now to the technical issue. =20 How are the apps ported and at what point on the suppliers boxes? =20 Using IPv4-Mapped addresses in the base API an app could port to IPv6 and take IPv6 addresses and IPv4Mapped addresses from getaddrinfo() (old gethostbyname() for those that don't know getaddrinfo() yet) and pass down IPv4-Mapped addresses to a dual stack implementation and they will be put out over the network as IPv4 by a dual stack node, but to the application layer they are just doing IPv6. =20 This will be part of the deployment recommendations from vendors, consultants, and systems integrators for users and some users will figure this out on their own and large application software providers that only want to release one binary for both IPv4 and IPv6. =20 I am not sure if we should put this into any docs for v6ops or not? It could be viewed as implementation deployment effort and issue not a standars issue? But it should be part of our emerging scenarios is my belief currently (all of them)? =20 Comments. =20 Regards, /jim =20 =20 =20 =20 =20 ------_=_NextPart_001_01C2D2C8.4AC190A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Here=20 is pointer to API paper users are downloading too.
I am=20 traveling now so may not respond to email for my interrupts to the mail = list=20 till next week depending on schedules and stuff.
 
http://www.nav6= tf.org/slides/trans_ipv6_v013.pdf
 
/jim
 
 
 
-----Original Message-----
From: = Bound, Jim=20
Sent: Wednesday, February 12, 2003 1:02 PM
To:=20 v6ops@ops.ietf.org
Subject: Deployment of Dual Stack with=20 Applications

Folks,
 
First I think the=20 consensus for dual stack is clearly making head way finally in and out = of the=20 IETF.
 
But = here is a real=20 operational scenario for us I am working on right = now.
 
User = believe IPv6=20 is important and they want to deploy.  The need to worry about = all the=20 things we discuss here but there is another one.  When do they = tell their=20 suppliers they MUST support IPv6 and how does this work?  And = when does=20 IPv6 get turned on?
 
The = good thing=20 about a dual stack approach is these users can mandate all suppliers = must=20 support the dual IPv6/IPv4 stack for procurement at some specified = point in=20 time. But they will most likely have to run IPv4 intiially on those = procured=20 boxes until the v6ops type parts are figured out and applications are=20 ported.
 
Now = to the=20 technical issue.
 
How = are the apps=20 ported and at what point on the suppliers boxes?
 
Using IPv4-Mapped=20 addresses in the base API an app could port to IPv6 and take IPv6 = addresses=20 and IPv4Mapped addresses from getaddrinfo() (old gethostbyname() for = those=20 that don't know getaddrinfo() yet) and pass down IPv4-Mapped addresses = to a=20 dual stack implementation and they will be put out over the network as = IPv4 by=20 a dual stack node, but to the application layer they are just doing=20 IPv6.
 
This = will be part=20 of the deployment recommendations from vendors, consultants, and = systems=20 integrators for users and some users will figure this out on their own = and=20 large application software providers that only want to release one = binary for=20 both IPv4 and IPv6.
 
I am = not sure if=20 we should put this into any docs for v6ops or not?  It could be = viewed as=20 implementation deployment effort and issue not a standars issue? But = it should=20 be part of our emerging scenarios is my belief currently (all of=20 them)?
 
Comments.
 
Regards,
/jim
 
 
 
 
 
=00 ------_=_NextPart_001_01C2D2C8.4AC190A9-- From owner-v6ops@ops.ietf.org Wed Feb 12 13:52: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 NAA11724 for ; Wed, 12 Feb 2003 13:52:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j22W-000Bnt-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 10:55:24 -0800 Received: from evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net ([4.65.19.240] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 18j22P-000Bn7-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 10:55:17 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 12 Feb 2003 10:55:14 -0800 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 12 Feb 2003 10:55:14 -0800 Message-ID: <01c901c2d2c8$4715fa30$b8a623c0@eagleswings> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CA_01C2D285.38F2BA30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED7@tayexc13.americas.cpqcorp.net> X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_FONT_COLOR_BLUE,IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01CA_01C2D285.38F2BA30 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Maybe I misunderstood the scenario, but it looks like you are describing a case where teredo is the appropriate choice. To restate; the ISP is offering support for IPv6, including a tunnel endpoint to transit any non-upgradable PE/CPE gear, though there is a nat in the path, so simple IPv4 encaps using 6to4 or isatap will fail. If the nat can be upgraded, it should become a 6to4 router. If not, it doesn't make sense to insert yet another device to do tunneling, because the end nodes are capable of doing it just as well. =20 Tony -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim Sent: Wednesday, February 12, 2003 9:22 AM To: v6ops@ops.ietf.org Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT Folks, =20 I am hearing an need for home users for transition. It could be this is ipv6 wg work but will bounce it off here first. =20 Assume dominant NAT/VPN/Firewall routers in most homes for Internet access. =20 Assume an upstream provider obtains IPv6 prefix to give to subscribers. =20 Assume home routers want to support IPv6 and will eventually but won't move until they believe it can be used over provider networks. =20 Assume there is not enough Ipv4 address space for providers to give out to all subscribers or cannot at reasonable cost. But they can give the subscriber an IPv6 prefix. This means 6to4 or ISATAP won't work in this scenario in the users home. =20 A solution (more on Teredo below) would be to figure a method for an IPv6 on the homelan to be encaped in the NAT packet to the provider who will decap that packet and send to the IPv6 destination and recall the state to the NAT user upon receiving packets back so the session can be established with the home user over the net. =20 This is quick for now as a thought. =20 The home user network encaps the IPv6 packet at NAT with Protocol ID equivalent to "6". The provider then takes that packet and decaps at their edge and uses native IPv6 or 6to4 to encap that packet to where the IPv6 service is located. I realize this has many assumptions and I would work on those with some other folks interested in this problem. =20 =20 I am re-reading Teredo now and working to see if it is addendum to Teredo or completely different solution. I think it is a different solution and possibly much simpler. I also believe this solution we are looking at can do e2e IPsec over the IPv4-NAT. =20 This would be a minor initial update for the home router vendors and basic IPv6 edge tunneling for the Provider. Also I think a tunnel-broker could be used by the Provider to help set this up for users too. The code for the home router on my first analysis could also be a firmware upgrade that is down loadable. =20 Could I get others opinions and thoughts on this before I and some others jump in here. =20 thanks /jim =20 =20 =20 =20 =20 ------=_NextPart_000_01CA_01C2D285.38F2BA30 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Maybe=20 I misunderstood the scenario, but it looks like you are describing a = case where=20 teredo is the appropriate choice. To restate; the ISP is offering = support for=20 IPv6, including a tunnel endpoint to transit any non-upgradable PE/CPE = gear,=20 though there is a nat in the path, so simple IPv4 encaps using 6to4 = or=20 isatap will fail. If the nat can be upgraded, it should become a 6to4 = router. If=20 not, it doesn't make sense to insert yet another device to do tunneling, = because=20 the end nodes are capable of doing it just as well.
 
Tony
-----Original Message-----
From:=20 owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of=20 Bound, Jim
Sent: Wednesday, February 12, 2003 9:22=20 AM
To: v6ops@ops.ietf.org
Subject: IPv6 Home Use = to=20 stimulate deployment over IPv4-NAT

Folks,
 
I am = hearing an=20 need for home users for transition.  It could be this is ipv6 wg = work but=20 will bounce it off here first.
 
Assume dominant=20 NAT/VPN/Firewall routers in most homes for Internet=20 access.
 
Assume an upstream=20 provider obtains IPv6 prefix to give to = subscribers.
 
Assume home=20 routers want to support IPv6 and will eventually but won't move until = they=20 believe it can be used over provider networks.
 
Assume there is=20 not enough Ipv4 address space for providers to give out to all = subscribers or=20 cannot at reasonable cost.  But they can give the subscriber an = IPv6=20 prefix.  This means 6to4 or ISATAP won't work in this scenario in = the=20 users home.
 
A = solution (more=20 on Teredo below) would be to figure a method for an IPv6 on the = homelan to be=20 encaped in the NAT packet to the provider who will decap that packet = and send=20 to the IPv6 destination and recall the state to the NAT user upon = receiving=20 packets back so the session can be established with the home user over = the=20 net.
 
This = is quick for=20 now as a thought.
 
The = home user=20 network encaps the IPv6 packet at NAT with Protocol ID equivalent to=20 "6".  The provider then takes that packet and decaps at their = edge and=20 uses native IPv6 or 6to4 to encap that packet to where the IPv6 = service is=20 located.  I realize this has many assumptions and I would work on = those=20 with some other folks interested in this problem.  =
 
I am = re-reading=20 Teredo now and working to see if it is addendum to Teredo or = completely=20 different solution.  I think it is a different solution and = possibly much=20 simpler.  I also believe this solution we are looking at can do = e2e IPsec=20 over the IPv4-NAT.
 
This = would be a=20 minor initial update for the home router vendors and basic IPv6 edge = tunneling=20 for the Provider.  Also I think a tunnel-broker could be used by = the=20 Provider to help set this up for users too.  The code for the = home router=20 on my first analysis could also be a firmware upgrade that is down=20 loadable.
 
Could I get others=20 opinions and thoughts on this before I and some others jump in=20 here.
 
thanks
/jim
 
 
 
 
 
------=_NextPart_000_01CA_01C2D285.38F2BA30-- From owner-v6ops@ops.ietf.org Wed Feb 12 14:12: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 OAA12409 for ; Wed, 12 Feb 2003 14:12:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j2Lf-000CZR-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 11:15:11 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18j2LZ-000CYv-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 11:15:05 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id CB01A70DF; Wed, 12 Feb 2003 14:15:04 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 14:15:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D2CB.0C0B04B8" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 12 Feb 2003 14:15:04 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EDB@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLSyFUVWOF+5R1jTsSy4TH2hyjmIQAAWa7Q From: "Bound, Jim" To: , X-OriginalArrivalTime: 12 Feb 2003 19:15:04.0724 (UTC) FILETIME=[0C5A6540:01C2D2CB] X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_FONT_COLOR_BLUE,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2D2CB.0C0B04B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tony, =20 I may suggest alternative to Teredo but looking at that now technically. But if Teredo works that is fine but many have issues with the complexity. So I will reserve comment on Teredo for now OK. Not sure I support it now. We will see. =20 The home router cannot become a 6to4 router because the public address may not be available or duplicated in practice is my assumption? But more than that an ecap of the packet with 6 proto-id is a simple software engineering upgrade for very low end home routers and field deliverable with a patch on the web is my belief, and 6to4 is far more complex and may require an entire release. So the work we do here may be two steps 1) first do simple encap, 2) eventually deploy 6to4 given the home router can use the public address. I am also worried of duplicate public address for the home router for the nat which I have seen at home and in hotels enough and in enough locations that I just have to look further into it. I am speaking with multiple providers now that do this function to get the issues from the horses mouth not second hand. I will also speak with 2 well known home router vendors on my assumptions for patches for upgrades. =20 Regards, /jim =20 =20 =20 -----Original Message----- From: Tony Hain [mailto:alh-ietf@tndh.net]=20 Sent: Wednesday, February 12, 2003 1:55 PM To: Bound, Jim; v6ops@ops.ietf.org Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT =09 =09 Maybe I misunderstood the scenario, but it looks like you are describing a case where teredo is the appropriate choice. To restate; the ISP is offering support for IPv6, including a tunnel endpoint to transit any non-upgradable PE/CPE gear, though there is a nat in the path, so simple IPv4 encaps using 6to4 or isatap will fail. If the nat can be upgraded, it should become a 6to4 router. If not, it doesn't make sense to insert yet another device to do tunneling, because the end nodes are capable of doing it just as well. =20 Tony -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim Sent: Wednesday, February 12, 2003 9:22 AM To: v6ops@ops.ietf.org Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT =09 =09 Folks, =20 I am hearing an need for home users for transition. It could be this is ipv6 wg work but will bounce it off here first. =20 Assume dominant NAT/VPN/Firewall routers in most homes for Internet access. =20 Assume an upstream provider obtains IPv6 prefix to give to subscribers. =20 Assume home routers want to support IPv6 and will eventually but won't move until they believe it can be used over provider networks. =20 Assume there is not enough Ipv4 address space for providers to give out to all subscribers or cannot at reasonable cost. But they can give the subscriber an IPv6 prefix. This means 6to4 or ISATAP won't work in this scenario in the users home. =20 A solution (more on Teredo below) would be to figure a method for an IPv6 on the homelan to be encaped in the NAT packet to the provider who will decap that packet and send to the IPv6 destination and recall the state to the NAT user upon receiving packets back so the session can be established with the home user over the net. =20 This is quick for now as a thought. =20 The home user network encaps the IPv6 packet at NAT with Protocol ID equivalent to "6". The provider then takes that packet and decaps at their edge and uses native IPv6 or 6to4 to encap that packet to where the IPv6 service is located. I realize this has many assumptions and I would work on those with some other folks interested in this problem. =20 =20 I am re-reading Teredo now and working to see if it is addendum to Teredo or completely different solution. I think it is a different solution and possibly much simpler. I also believe this solution we are looking at can do e2e IPsec over the IPv4-NAT. =20 This would be a minor initial update for the home router vendors and basic IPv6 edge tunneling for the Provider. Also I think a tunnel-broker could be used by the Provider to help set this up for users too. The code for the home router on my first analysis could also be a firmware upgrade that is down loadable. =20 Could I get others opinions and thoughts on this before I and some others jump in here. =20 thanks /jim =20 =20 =20 =20 =20 ------_=_NextPart_001_01C2D2CB.0C0B04B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Tony,
 
I=20 may suggest alternative to Teredo but looking at that now=20 technically.  But if Teredo works that is fine but many have issues = with=20 the complexity.  So I will reserve comment on Teredo for now = OK.  Not=20 sure I support it now.  We will see.
 
The=20 home router cannot become a 6to4 router because the public address may = not be=20 available or duplicated in practice is my assumption?  But = more than=20 that an ecap of the packet with 6 proto-id is a simple software = engineering=20 upgrade for very low end home routers and field deliverable with a patch = on the=20 web is my belief, and 6to4 is far more complex and may require an entire = release. So the work we do here may be two steps 1) first do simple = encap, 2)=20 eventually deploy 6to4 given the home router can use the public = address.  I=20 am also worried of duplicate public address for the home router for = the nat=20 which I have seen at home and in hotels enough and in enough locations = that I=20 just have to look further into it.  I am speaking with multiple = providers=20 now that do this function to get the issues from the horses mouth not = second=20 hand.  I will also speak with 2 well known home router vendors on = my=20 assumptions for patches for upgrades.
 
Regards,
/jim
 
 
 
-----Original Message-----
From: Tony = Hain=20 [mailto:alh-ietf@tndh.net]
Sent: Wednesday, February 12, = 2003 1:55=20 PM
To: Bound, Jim; v6ops@ops.ietf.org
Subject: RE: = IPv6=20 Home Use to stimulate deployment over IPv4-NAT

Maybe I misunderstood the scenario, but it looks like you are = describing a case where teredo is the appropriate choice. To restate; = the ISP=20 is offering support for IPv6, including a tunnel endpoint to transit = any=20 non-upgradable PE/CPE gear, though there is a nat in the path, so = simple=20 IPv4 encaps using 6to4 or isatap will fail. If the nat can be = upgraded, it=20 should become a 6to4 router. If not, it doesn't make sense to insert = yet=20 another device to do tunneling, because the end nodes are capable of = doing it=20 just as well.
 
Tony
-----Original Message-----
From:=20 owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of=20 Bound, Jim
Sent: Wednesday, February 12, 2003 9:22=20 AM
To: v6ops@ops.ietf.org
Subject: IPv6 Home Use = to=20 stimulate deployment over IPv4-NAT

Folks,
 
I = am hearing an=20 need for home users for transition.  It could be this is ipv6 = wg work=20 but will bounce it off here first.
 
Assume dominant=20 NAT/VPN/Firewall routers in most homes for Internet=20 access.
 
Assume an=20 upstream provider obtains IPv6 prefix to give to=20 subscribers.
 
Assume home=20 routers want to support IPv6 and will eventually but won't move = until they=20 believe it can be used over provider networks.
 
Assume there is=20 not enough Ipv4 address space for providers to give out to all = subscribers=20 or cannot at reasonable cost.  But they can give the subscriber = an IPv6=20 prefix.  This means 6to4 or ISATAP won't work in this scenario = in the=20 users home.
 
A = solution (more=20 on Teredo below) would be to figure a method for an IPv6 on the = homelan to=20 be encaped in the NAT packet to the provider who will decap that = packet and=20 send to the IPv6 destination and recall the state to the NAT user = upon=20 receiving packets back so the session can be established with the = home user=20 over the net.
 
This is quick=20 for now as a thought.
 
The home user=20 network encaps the IPv6 packet at NAT with Protocol ID equivalent to = "6".  The provider then takes that packet and decaps at their = edge and=20 uses native IPv6 or 6to4 to encap that packet to where the IPv6 = service is=20 located.  I realize this has many assumptions and I would work = on those=20 with some other folks interested in this problem.  =
 
I = am re-reading=20 Teredo now and working to see if it is addendum to Teredo or = completely=20 different solution.  I think it is a different solution and = possibly=20 much simpler.  I also believe this solution we are looking at = can do=20 e2e IPsec over the IPv4-NAT.
 
This would be a=20 minor initial update for the home router vendors and basic IPv6 edge = tunneling for the Provider.  Also I think a tunnel-broker could = be used=20 by the Provider to help set this up for users too.  The code = for the=20 home router on my first analysis could also be a firmware upgrade = that is=20 down loadable.
 
Could I get=20 others opinions and thoughts on this before I and some others jump = in=20 here.
 
thanks
/jim
 
 
 
 
 
=00 ------_=_NextPart_001_01C2D2CB.0C0B04B8-- From owner-v6ops@ops.ietf.org Wed Feb 12 14:19:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12619 for ; Wed, 12 Feb 2003 14:19:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j2Sl-000Ct6-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 11:22:31 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18j2SZ-000CsA-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 11:22:19 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D415572BD; Wed, 12 Feb 2003 14:22:17 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Feb 2003 14:22:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 12 Feb 2003 14:22:17 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EDC@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLSwZLdMHspxD1WSPqik8o4ApQcuQACW6WA From: "Bound, Jim" To: "Jeroen Massar" , X-OriginalArrivalTime: 12 Feb 2003 19:22:17.0834 (UTC) FILETIME=[0E81BCA0:01C2D2CC] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12619 Hi, Thanks for using ascii text as mail interface or rule of convesion to text from html or rtf. > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org] > Sent: Wednesday, February 12, 2003 1:07 PM > To: Bound, Jim; v6ops@ops.ietf.org > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Bound, Jim wrote: > > > > > I am hearing an need for home users for transition. It could > > be this is ipv6 wg work but will bounce it off here first. > > > > > Could I get others opinions and thoughts on this before I and > > some others jump in here. > > Based on your assumptions you would have something similar too: > > { Internet } - { ISP } - - { many endusers } Yes. > > The NAT-box/router will have both have a public IPv4 and > IPv6: internet side IPv4: 1.2.3.4 > user side IPv4: 10.0.0.1 > internet side IPv6: 2001:db8::0:1 > user side IPv6: 2001:db8::1:2 Yes but also I am concerned about the persistance of the NAT box address which affects 6to4 performance. But checking. Also I assume 6to4 2002::/ can be used too at the ISP too in your diagram. > > First of all the ISP could choose to simply have all its > routers understand native IPv6. But ofcourse this is a nogo > with most hardware, and as apparently the ISP can't get IPv4 > space it prolly won't have enough cash to get new hardware too. I think this is the case yes. > > Thus the cheap alternative: Fix up a Tunnelbroker on the NAT > box (or on a second machine) which can be connected to the > public internet giving it the above 2 IPv6 addresses and one > private / 'userside' IPv4 address. The endusers can the build > a tunnel from their 10.0.0.0/24 IPv4 address to the 10.0.0.1 > IPv4 address and route their IPv6 traffic over that. Yes but the IPv6 packet will have to be encaped at the home nat router. That is what I am saying is a cheap and expedient solution and longer solution is 6to4 at the home nat router. I am still thinking about the tunnel broker angle. For example why not the ISP provide this via the web interface to the user that is downloadable. The first and quick deployment strategy should be to reduce the amount of effort the home nat box has to do for initial deployment. So if the tunnel broker can be a service at the ISP to the home net that reduces what is required "initially" for the home nat box. > > Ofcourse this would require something automatic for the > enduser as not every enduser is a computer guru. The Freenet6 > TSP protocol and others could be used to complement this. I > am currently in the process of finishing up the autoconfig > tool for the SixXS project which allows a similar concept to > work without any user intervention. This is why I am thinking the TSP be at the ISP and yes Freenet6 could be used by the ISPs pretty "cheap". Thanks /jim > > Greets, > Jeroen > > From owner-v6ops@ops.ietf.org Wed Feb 12 15:29: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 PAA14862 for ; Wed, 12 Feb 2003 15:29:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j3Xg-000Fdq-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 12:31:40 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org) by psg.com with esmtp (Exim 3.36 #1) id 18j3Xd-000FdP-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 12:31:37 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 0DBC88A64; Wed, 12 Feb 2003 21:31:32 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 90A907C00; Wed, 12 Feb 2003 21:31:27 +0100 (CET) From: "Jeroen Massar" To: "'Bound, Jim'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 12 Feb 2003 21:31:29 +0100 Organization: Unfix Message-ID: <007801c2d2d5$ba7d5c40$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240EDC@tayexc13.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA14862 Bound, Jim wrote: > Thanks for using ascii text as mail interface or rule of convesion to > text from html or rtf. google "outlook readasplain" does the trick for all outlook fans ;) I dislike HTML/RTF etc as a mail format too... > Bound, Jim wrote: > > > > The NAT-box/router will have both have a public IPv4 and > > IPv6: internet side IPv4: 1.2.3.4 > > user side IPv4: 10.0.0.1 > > internet side IPv6: 2001:db8::0:1 > > user side IPv6: 2001:db8::1:2 > > Yes but also I am concerned about the persistance of the NAT > box address > which affects 6to4 performance. But checking. Also I assume 6to4 > 2002::/ can be used too at the ISP too in your diagram. If the infrastructure behind the NAT box supports Native IPv6 all becomes much easier ofcourse and then one could even use the NAT box as 6to4 relay as the IPv6 prefix would then be 2002:0102:0304::/48 But in that case the ISP could better go for native IPv6 deployment. > > Thus the cheap alternative: Fix up a Tunnelbroker on the NAT > > box (or on a second machine) which can be connected to the > > public internet giving it the above 2 IPv6 addresses and one > > private / 'userside' IPv4 address. The endusers can the build > > a tunnel from their 10.0.0.0/24 IPv4 address to the 10.0.0.1 > > IPv4 address and route their IPv6 traffic over that. > > Yes but the IPv6 packet will have to be encaped at the home > nat router. > That is what I am saying is a cheap and expedient solution and longer > solution is 6to4 at the home nat router. > > I am still thinking about the tunnel broker angle. For example why not > the ISP provide this via the web interface to the user that is > downloadable. The first and quick deployment strategy should be to > reduce the amount of effort the home nat box has to do for initial > deployment. So if the tunnel broker can be a service at the > ISP to the home net that reduces what is required "initially" for the > home nat box. One doesn't want a webinterface. Though MSN, Outlook, ICQ and many other sites requiring authentication have shown that the signup process can be done over the web, the user shouldn't have to configure a thing on their machine. Currently a 'apt-get install freenet6' on a debian machine will get you connected over Freenet6 The ISP could provide it's users to a, modified, binary of this tool which connects the user to it's local POP. They could even use a connection to their RADIUS accounting machine to give the user a persistent IPv6 prefix for the tunnel and subnet provided over it. The user should only have to: download + run the tool, maybe give some login information and be done with it. Unfortunatly most homeusers will be running Windows 9x thus unless they install Trumpet's Winsock they can't use IPv6 at all. NT4/Windows 2000 IPv6 requires a somewhat difficult (for endusers mind you) installation and has some problems with newer versions of IE. Windows XP users are best of ofcourse in this row as they can with "ipv6 install". And for all the people running Linux/*BSD they can probably also manage installing an IPv6 stack. There are also quite a number of easy scripts and autoconfig tools for the "free" OS's. All OS's not in the list above are not in the 'enduser' segment IMHO and usually the people using those know what they are doing. > > Ofcourse this would require something automatic for the > > enduser as not every enduser is a computer guru. The Freenet6 > > TSP protocol and others could be used to complement this. I > > am currently in the process of finishing up the autoconfig > > tool for the SixXS project which allows a similar concept to > > work without any user intervention. > > This is why I am thinking the TSP be at the ISP and yes Freenet6 could > be used by the ISPs pretty "cheap". The "POP" as I like to call it, or tunnelbroker as per TSP drafts, should ofcourse be on the NAT box or next to it inside the ISP's network which would save quite some latency and the big problem that the endusers are all NAT'ed and thus can't use any other 'public' POP. Greets, Jeroen From owner-v6ops@ops.ietf.org Wed Feb 12 16:05: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 QAA15654 for ; Wed, 12 Feb 2003 16:05:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18j478-000H51-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 13:08:18 -0800 Received: from evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net ([4.65.19.240] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 18j474-000H4j-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 13:08:14 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 12 Feb 2003 13:08:12 -0800 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 12 Feb 2003 13:08:07 -0800 Message-ID: <01e101c2d2da$d725fe10$b8a623c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B03240EDB@tayexc13.americas.cpqcorp.net> X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA15654 So the case is a double nat? If it is just that the 'public' side of the nat has a private address and needs to tunnel over IPv4 infrastructure, isatap is the appropriate tool. -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Wednesday, February 12, 2003 11:15 AM To: alh-ietf@tndh.net; v6ops@ops.ietf.org Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Tony, I may suggest alternative to Teredo but looking at that now technically. But if Teredo works that is fine but many have issues with the complexity. So I will reserve comment on Teredo for now OK. Not sure I support it now. We will see. The home router cannot become a 6to4 router because the public address may not be available or duplicated in practice is my assumption? But more than that an ecap of the packet with 6 proto-id is a simple software engineering upgrade for very low end home routers and field deliverable with a patch on the web is my belief, and 6to4 is far more complex and may require an entire release. So the work we do here may be two steps 1) first do simple encap, 2) eventually deploy 6to4 given the home router can use the public address. I am also worried of duplicate public address for the home router for the nat which I have seen at home and in hotels enough and in enough locations that I just have to look further into it. I am speaking with multiple providers now that do this function to get the issues from the horses mouth not second hand. I will also speak with 2 well known home router vendors on my assumptions for patches for upgrades. Regards, /jim -----Original Message----- From: Tony Hain [mailto:alh-ietf@tndh.net] Sent: Wednesday, February 12, 2003 1:55 PM To: Bound, Jim; v6ops@ops.ietf.org Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Maybe I misunderstood the scenario, but it looks like you are describing a case where teredo is the appropriate choice. To restate; the ISP is offering support for IPv6, including a tunnel endpoint to transit any non-upgradable PE/CPE gear, though there is a nat in the path, so simple IPv4 encaps using 6to4 or isatap will fail. If the nat can be upgraded, it should become a 6to4 router. If not, it doesn't make sense to insert yet another device to do tunneling, because the end nodes are capable of doing it just as well. Tony -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim Sent: Wednesday, February 12, 2003 9:22 AM To: v6ops@ops.ietf.org Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT Folks, I am hearing an need for home users for transition. It could be this is ipv6 wg work but will bounce it off here first. Assume dominant NAT/VPN/Firewall routers in most homes for Internet access. Assume an upstream provider obtains IPv6 prefix to give to subscribers. Assume home routers want to support IPv6 and will eventually but won't move until they believe it can be used over provider networks. Assume there is not enough Ipv4 address space for providers to give out to all subscribers or cannot at reasonable cost. But they can give the subscriber an IPv6 prefix. This means 6to4 or ISATAP won't work in this scenario in the users home. A solution (more on Teredo below) would be to figure a method for an IPv6 on the homelan to be encaped in the NAT packet to the provider who will decap that packet and send to the IPv6 destination and recall the state to the NAT user upon receiving packets back so the session can be established with the home user over the net. This is quick for now as a thought. The home user network encaps the IPv6 packet at NAT with Protocol ID equivalent to "6". The provider then takes that packet and decaps at their edge and uses native IPv6 or 6to4 to encap that packet to where the IPv6 service is located. I realize this has many assumptions and I would work on those with some other folks interested in this problem. I am re-reading Teredo now and working to see if it is addendum to Teredo or completely different solution. I think it is a different solution and possibly much simpler. I also believe this solution we are looking at can do e2e IPsec over the IPv4-NAT. This would be a minor initial update for the home router vendors and basic IPv6 edge tunneling for the Provider. Also I think a tunnel-broker could be used by the Provider to help set this up for users too. The code for the home router on my first analysis could also be a firmware upgrade that is down loadable. Could I get others opinions and thoughts on this before I and some others jump in here. thanks /jim From owner-v6ops@ops.ietf.org Thu Feb 13 01:17: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 BAA25527 for ; Thu, 13 Feb 2003 01:17:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jChs-000JTe-00 for v6ops-data@psg.com; Wed, 12 Feb 2003 22:18:48 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18jCho-000JSP-00 for v6ops@ops.ietf.org; Wed, 12 Feb 2003 22:18:44 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DB2BF2E8E; Thu, 13 Feb 2003 01:18:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 01:18:40 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 01:18:40 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EDF@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLS2uLNRscRii6yRdWzzeFRixw2lQAS7KFQ From: "Bound, Jim" To: , X-OriginalArrivalTime: 13 Feb 2003 06:18:40.0802 (UTC) FILETIME=[C095C020:01C2D327] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA25527 Tony, You are missing my point for the solution. But yes it could be double NAT too. The solution I am looking for requires no intelligence for any mechanism on the home node except to send IPv6 packets. That is not the case for ISATAP. Or administration of the IPv6 nodes for mechanisms. It is all done by the home nat router. So Microsoft XP, Linux, Freebsd, Symbian, Vxworks, and other home embedded OS system nodes would not have had to implement any of the previous ngtrans mechanisms. It is all accomplished at the home "edge" to the provider or at the apartment complex "edge" to the box for fibre at the curb, etc. etc. If the home nodes can get a public address for their network then yes the previous ngtrans mechanism become usable. What I am discussing is a different case. I believe the home routers can build this and if we can define and specify it. Regards, /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, February 12, 2003 4:08 PM > To: Bound, Jim; v6ops@ops.ietf.org > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > So the case is a double nat? If it is just that the 'public' > side of the nat has a private address and needs to tunnel > over IPv4 infrastructure, isatap is the appropriate tool. > > > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Wednesday, February 12, 2003 11:15 AM > To: alh-ietf@tndh.net; v6ops@ops.ietf.org > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Tony, > > I may suggest alternative to Teredo but looking at that now > technically. But if Teredo works that is fine but many have > issues with the complexity. So I will reserve comment on > Teredo for now OK. Not sure I support it now. We will see. > > The home router cannot become a 6to4 router because the > public address may not be available or duplicated in practice > is my assumption? But more than that an ecap of the packet > with 6 proto-id is a simple software engineering upgrade for > very low end home routers and field deliverable with a patch > on the web is my belief, and 6to4 is far more complex and may > require an entire release. So the work we do here may be two > steps 1) first do simple encap, 2) eventually deploy 6to4 > given the home router can use the public address. I am also > worried of duplicate public address for the home router for > the nat which I have seen at home and in hotels enough and in > enough locations that I just have to look further into it. I > am speaking with multiple providers now that do this function > to get the issues from the horses mouth not second hand. I > will also speak with 2 well known home router vendors on my > assumptions for patches for upgrades. > > Regards, > /jim > > > > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Wednesday, February 12, 2003 1:55 PM > To: Bound, Jim; v6ops@ops.ietf.org > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Maybe I misunderstood the scenario, but it looks like you are > describing a case where teredo is the appropriate choice. To > restate; the ISP is offering support for IPv6, including a > tunnel endpoint to transit any non-upgradable PE/CPE gear, > though there is a nat in the path, so simple IPv4 encaps > using 6to4 or isatap will fail. If the nat can be upgraded, > it should become a 6to4 router. If not, it doesn't make sense > to insert yet another device to do tunneling, because the end > nodes are capable of doing it just as well. > > Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > Sent: Wednesday, February 12, 2003 9:22 AM > To: v6ops@ops.ietf.org > Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Folks, > > I am hearing an need for home users for transition. It could > be this is ipv6 wg work but will bounce it off here first. > > Assume dominant NAT/VPN/Firewall routers in most homes for > Internet access. > > Assume an upstream provider obtains IPv6 prefix to give to > subscribers. > > Assume home routers want to support IPv6 and will eventually > but won't move until they believe it can be used over > provider networks. > > Assume there is not enough Ipv4 address space for providers > to give out to all subscribers or cannot at reasonable cost. > But they can give the subscriber an IPv6 prefix. This means > 6to4 or ISATAP won't work in this scenario in the users home. > > A solution (more on Teredo below) would be to figure a method > for an IPv6 on the homelan to be encaped in the NAT packet to > the provider who will decap that packet and send to the IPv6 > destination and recall the state to the NAT user upon > receiving packets back so the session can be established with > the home user over the net. > > This is quick for now as a thought. > > The home user network encaps the IPv6 packet at NAT with > Protocol ID equivalent to "6". The provider then takes that > packet and decaps at their edge and uses native IPv6 or 6to4 > to encap that packet to where the IPv6 service is located. I > realize this has many assumptions and I would work on those > with some other folks interested in this problem. > > I am re-reading Teredo now and working to see if it is > addendum to Teredo or completely different solution. I think > it is a different solution and possibly much simpler. I also > believe this solution we are looking at can do e2e IPsec over > the IPv4-NAT. > > This would be a minor initial update for the home router > vendors and basic IPv6 edge tunneling for the Provider. Also > I think a tunnel-broker could be used by the Provider to help > set this up for users too. The code for the home router on > my first analysis could also be a firmware upgrade that is > down loadable. > > Could I get others opinions and thoughts on this before I and > some others jump in here. > > thanks > /jim > > From owner-v6ops@ops.ietf.org Thu Feb 13 05:36: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 FAA08891 for ; Thu, 13 Feb 2003 05:36:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jGkL-000CvR-00 for v6ops-data@psg.com; Thu, 13 Feb 2003 02:37:37 -0800 Received: from [194.17.45.16] (helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18jGkH-000Cub-00 for v6ops@ops.ietf.org; Thu, 13 Feb 2003 02:37:34 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1DAcThE029082; Thu, 13 Feb 2003 11:38:30 +0100 (CET) Date: Thu, 13 Feb 2003 11:30:15 +0100 Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED7@tayexc13.americas.cpqcorp.net> Message-Id: <23C1CCA4-3F3E-11D7-874A-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA08891 > Assume there is not enough Ipv4 address space for providers to give > out to all subscribers or cannot at reasonable cost.  But they can > give the subscriber an IPv6 prefix.  This means 6to4 or ISATAP won't > work in this scenario in the users home. > Are you saying this as an alternative to IPv4 NAT or as a complement? (I assume the latter) > The home user network encaps the IPv6 packet at NAT with Protocol ID > equivalent to "6".  The provider then takes that packet and decaps at > their edge and uses native IPv6 or 6to4 to encap that packet to where > the IPv6 service is located.  I realize this has many assumptions and > I would work on those with some other folks interested in this > problem.  If you mean the first of what I wrote above, I could finally see something that could make consumer oriented operators look at IPv6. There are a number of questions still though, as cost and stability of equipment as well as application impact. But the two last doesn't appear to have bothered this type of operators before.... >   > I am re-reading Teredo now and working to see if it is addendum to > Teredo or completely different solution.  I think it is a different > solution and possibly much simpler.  I also believe this solution we > are looking at can do e2e IPsec over the IPv4-NAT. That would be a useful application in a way. But I am worried about the poor performance of IPsec in combination with IPv6 code. - kurtis - From owner-v6ops@ops.ietf.org Thu Feb 13 07:35:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10866 for ; Thu, 13 Feb 2003 07:35:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jIcg-000H6r-00 for v6ops-data@psg.com; Thu, 13 Feb 2003 04:37:50 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18jIcc-000H6f-00 for v6ops@ops.ietf.org; Thu, 13 Feb 2003 04:37:46 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id ECF828A42; Thu, 13 Feb 2003 07:37:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 07:37:45 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 07:37:45 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06E1@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTS+smesUNZCpsTCaBKxigQ4arlwAD+NHQ From: "Bound, Jim" To: "Kurt Erik Lindqvist" Cc: X-OriginalArrivalTime: 13 Feb 2003 12:37:45.0853 (UTC) FILETIME=[B5B11AD0:01C2D35C] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA10866 > > Assume there is not enough Ipv4 address space for providers to give > > out to all subscribers or cannot at reasonable cost.  But they can > > give the subscriber an IPv6 prefix.  This means 6to4 or > ISATAP won't > > work in this scenario in the users home. > > > > Are you saying this as an alternative to IPv4 NAT or as a complement? > (I assume the latter) The latter but an extension to IPv4-NAT to support IPv6. In other words NAT admits it is evil but now has seen the light and trys to help move users to IPv6. The idea is to deal with the reality but move forward. > > > The home user network encaps the IPv6 packet at NAT with > Protocol ID > > equivalent to "6".  The provider then takes that packet and > decaps at > > their edge and uses native IPv6 or 6to4 to encap that > packet to where > > the IPv6 service is located.  I realize this has many > assumptions and > > I would work on those with some other folks interested in this > > problem.  > > If you mean the first of what I wrote above, I could finally see > something that could make consumer oriented operators look at IPv6. That is one of my business goals. Exactly. But I can only help invent the technology. But we do have resources in the v6 deployment community to reach out to these players. > There are a number of questions still though, as cost and > stability of > equipment as well as application impact. But the two last doesn't > appear to have bothered this type of operators before.... I agree. My goal is to make impact to applicaton ZERO. > > >   > > I am re-reading Teredo now and working to see if it is addendum to > > Teredo or completely different solution.  I think it is a different > > solution and possibly much simpler.  I also believe this > solution we > > are looking at can do e2e IPsec over the IPv4-NAT. > > That would be a useful application in a way. But I am worried > about the > poor performance of IPsec in combination with IPv6 code. We all must deal with a fact of life. Until we get wide mass available processors IPsec and other security mechanisms performance for e2e encryption will suck. Period. But in some cases the performance hit will be worth it. But for IPv6 IPsec is MANDATORY. Regards, /jim > > - kurtis - > > From owner-v6ops@ops.ietf.org Thu Feb 13 08:21: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 IAA11675 for ; Thu, 13 Feb 2003 08:21:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jJLo-000Inx-00 for v6ops-data@psg.com; Thu, 13 Feb 2003 05:24:28 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18jJLl-000Inl-00 for v6ops@ops.ietf.org; Thu, 13 Feb 2003 05:24:25 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 666078B95; Thu, 13 Feb 2003 08:24:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 08:24:24 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 13 Feb 2003 08:24:24 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE2@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLS1cb+kUS2qxtbRXmLkdWMa0HmGQAjDGNw From: "Bound, Jim" To: "Jeroen Massar" , X-OriginalArrivalTime: 13 Feb 2003 13:24:24.0320 (UTC) FILETIME=[39B54800:01C2D363] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA11675 Jeroen, > google "outlook readasplain" does the trick for all outlook > fans ;) I dislike HTML/RTF etc as a mail format too... Thanks I will go look at this to learn more ..................... > > > The NAT-box/router will have both have a public IPv4 and > > > IPv6: internet side IPv4: 1.2.3.4 > > > user side IPv4: 10.0.0.1 > > > internet side IPv6: 2001:db8::0:1 > > > user side IPv6: 2001:db8::1:2 > > > > Yes but also I am concerned about the persistance of the NAT > > box address > > which affects 6to4 performance. But checking. Also I assume 6to4 > > 2002::/ can be used too at the ISP too in your diagram. > > If the infrastructure behind the NAT box supports Native IPv6 > all becomes much easier ofcourse and then one could even use > the NAT box as 6to4 relay as the IPv6 prefix would then be > 2002:0102:0304::/48 But in that case the ISP could better go > for native IPv6 deployment. I agree 100% but as other mail stated getting the home router industry to do IPv6 requires a baby step for the business case. Ergo a technical solution that is not painful, robust, and will scale. I am not clear we have developed that here in v60ps or ngtrans. > > > > > > Thus the cheap alternative: Fix up a Tunnelbroker on the NAT > > > box (or on a second machine) which can be connected to the > > > public internet giving it the above 2 IPv6 addresses and one > > > private / 'userside' IPv4 address. The endusers can the build > > > a tunnel from their 10.0.0.0/24 IPv4 address to the 10.0.0.1 > > > IPv4 address and route their IPv6 traffic over that. > > > > Yes but the IPv6 packet will have to be encaped at the home > > nat router. > > That is what I am saying is a cheap and expedient solution > and longer > > solution is 6to4 at the home nat router. > > > > I am still thinking about the tunnel broker angle. For > example why not > > the ISP provide this via the web interface to the user that is > > downloadable. The first and quick deployment strategy should be to > > reduce the amount of effort the home nat box has to do for initial > > deployment. So if the tunnel broker can be a service at the ISP to > > the home net that reduces what is required "initially" for the home > > nat box. > > One doesn't want a webinterface. Though MSN, Outlook, ICQ and > many other sites requiring authentication have shown that the > signup process can be done over the web, the user shouldn't > have to configure a thing on their machine. Currently a > 'apt-get install freenet6' on a debian machine will get you > connected over Freenet6 The ISP could provide it's users to > a, modified, binary of this tool which connects the user to > it's local POP. They could even use a connection to their > RADIUS accounting machine to give the user a persistent IPv6 > prefix for the tunnel and subnet provided over it. The user > should only have to: download + run the tool, maybe give some > login information and be done with it. This is a good point and idea. If this flys and a few of us believe it worth while we should document the above in the spec as appendice. Also using POP is more appropriate for discussion too. > > Unfortunatly most homeusers will be running Windows 9x thus > unless they install Trumpet's Winsock they can't use IPv6 at > all. NT4/Windows 2000 IPv6 requires a somewhat difficult (for > endusers mind > you) > installation and has some problems with newer versions of IE. > Windows XP users are best of ofcourse in this row as they can > with "ipv6 install". And for all the people running > Linux/*BSD they can probably also manage installing an IPv6 > stack. There are also quite a number of easy scripts and > autoconfig tools for the "free" OS's. All OS's not in the > list above are not in the 'enduser' segment IMHO and usually > the people using those know what they are doing. We need to be vendor neutral here though I think trumpet is good comment. My view is if the home box supports IPv6 and sends packets with IPv6 the home router box and possibly the cable modem will simply take care of the coexistence issues to the POP. If it is that simply it will be deployed and it gives a cheap ROI business case to the home routers and the providers. > > > > Ofcourse this would require something automatic for the > > > enduser as not every enduser is a computer guru. The Freenet6 > > > TSP protocol and others could be used to complement this. I > > > am currently in the process of finishing up the autoconfig > > > tool for the SixXS project which allows a similar concept to > > > work without any user intervention. > > > > This is why I am thinking the TSP be at the ISP and yes > Freenet6 could > > be used by the ISPs pretty "cheap". > > The "POP" as I like to call it, or tunnelbroker as per TSP > drafts, should ofcourse be on the NAT box or next to it > inside the ISP's network which would save quite some latency > and the big problem that the endusers are all NAT'ed and thus > can't use any other 'public' POP. I agree 100%. /jim > > Greets, > Jeroen > > From owner-v6ops@ops.ietf.org Thu Feb 13 08:58: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 IAA12321 for ; Thu, 13 Feb 2003 08:58:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jJue-000LAF-00 for v6ops-data@psg.com; Thu, 13 Feb 2003 06:00:28 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18jJuc-000LA3-00 for v6ops@ops.ietf.org; Thu, 13 Feb 2003 06:00:26 -0800 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1DE3Fm14082 for ; Thu, 13 Feb 2003 16:03:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Feb 2003 16:00:24 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Feb 2003 16:00:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3GPP analysis Date: Thu, 13 Feb 2003 16:00:14 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3759@esebe005.ntc.nokia.com> Thread-Topic: 3GPP analysis Thread-Index: AcLSq0PoEgs3F453QzeThzuoJnz+xgAr1h/Q From: To: Cc: X-OriginalArrivalTime: 13 Feb 2003 14:00:24.0463 (UTC) FILETIME=[4140F1F0:01C2D368] X-Spam-Status: No, hits=2.1 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_02_03,SUPERLONG_LINE version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA12321 Hi, Suresh! Thanks for your questions and comments on our document! Firstly, I think that the best way would be to enable IPv6 on end nodes (I see in your questions that you have considered dual stack SIP server in the destination network) and just use IPv6 for SIP/IMS communications. This is the final goal in all IMS communications! But until that has happened we will have to live with this kind of solution in those cases where communications with (legacy) IPv4 nodes are needed. (Another thing is that we have to develop the solution according to 3GPP (Rel5) IMS specifications, i.e. remembering that IMS is IPv6-only. We are not supposed to propose / make any changes in 3GPP specifications.) I try to further analyze your questions below: -----Original Message----- From: ext suresh.leroy@alcatel.be [mailto:suresh.leroy@alcatel.be] Sent: 12 February, 2003 17:22 1) If the destination is an IPv4 node registered to a dual stack SIP server, is the interworking then by default handled outside the IMS operator's network or are there ways to keep the control whithin the IMS operator's network. => When an IPv6 UE connected to IMS tries to reach the external IPv4 node it sends the INVITE request to the SIP proxy at the IMS. Then the SIP proxy at the IMS contacts the DNS to find out the IP address of the SIP proxy where the IPv4-only destination node is registered (so in this case it probably gets both IPv4 and IPv6 addresses as it is dual stack), and after this DNS resolution the originating SIP proxy at the IMS forwards (proxies) the INVITE request to the destination SIP proxy. This procedure does not involve the IP address of the destination SIP client, so the decision to use IPv4 or IPv6 routing for the outgoing INVITE request is based on the addresses returned for the destination SIP proxy and following the address selection policy configured in the IMS, independently of the type of client (IPv4-only in this case) that is registered to the destination SIP proxy. So there are two different possibilities: If the IMS decides to use IPv4 instead of IPv6 (from the edge of the IMS to the destination) to reach the destination SIP proxy, then no further IPv4-IPv6 interworking is needed outside the IMS domain, as IPv6 to IPv4 translation will be performed on the edge of the IMS. If the IMS decides to use IPv6, then protocol translation needs to be performed in the destination network. This decision can be based on the type of SIP proxy (dual stack in this case). I think quite natural place for the translation is on the edge of the IPv6-only IMS. SIP/SDP ALG is needed for SIP/SDP translation and user traffic translation is handled in a translator (e.g. NAT-PT; can also be a subset of NAT-PT, NAT64, etc.). 2) How is the SIP-ALG added in the path for outgoing SIP calls (assuming the SIP-ALG is only in the path when needed). Is it a configuration in the S-CSCF, e.g. if DNS resolve only returns a IPv4 address then forward SIP messages to SIP-ALG, SIP-ALG then resends again the same DNS query to find the next 'IPv4' hop. => At least these two options exist: - The SIP-ALG is implemented together with the NAT-PT in the same box. This allows the SIP-ALG easily control the NAT-PT bindings. However, this may lower the translator performance as more tasks are needed within the one single box. - The SIP-ALG and NAT-PT are in separate boxes and some kind of protocol (e.g. MEGACO) is used to remotely control NAT-PT bindings. 3) For incomming SIP sessions how is decided if the call should go to the I-CSCF or the SIP-ALG. Is this done based on DNS information in the IMS operator network, IPv6 address corresponding to I-CSCF, IPv4 address to SIP-ALG. This would result in external IPv6 SIP server sending their messages to the I-CSCF and IPv4 servers forwarding SIP to the SIP-ALG. How about external SIP server that are dual stack, where does it forward SIP messages to. => Yep, DNS information could be used. And clear rules should exist what to do in the case of ds SIP server... Just thinking, can we know what IP version the peer node is using? Wouldn't it be easier if the ALG functionality for IMS would be integrated in the I-CSCF or S-CSCF although there was heavy resistance for this in 3GPP. => I was not personally active in 3GPP when those discussions were held. However, I would respect 3GPP opinions and as I commented previously, we are not anyhow making changes in 3GPP specifications. Best Regards, -Juha W.- From owner-v6ops@ops.ietf.org Thu Feb 13 11: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 LAA17521 for ; Thu, 13 Feb 2003 11:39:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jMQM-00095a-00 for v6ops-data@psg.com; Thu, 13 Feb 2003 08:41:22 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18jMQI-00094v-00 for v6ops@ops.ietf.org; Thu, 13 Feb 2003 08:41:18 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 68B8E3463; Thu, 13 Feb 2003 11:41:17 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Feb 2003 11:41:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Thu, 13 Feb 2003 11:41:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE4@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLS2uLNRscRii6yRdWzzeFRixw2lQAofrLA From: "Bound, Jim" To: , X-OriginalArrivalTime: 13 Feb 2003 16:41:16.0947 (UTC) FILETIME=[BA951E30:01C2D37E] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA17521 Tony, I will build different solution other than Teredo. Teredo is to complex and breaks a 2 rules for me I use as network engineer/architect for v6ops solutions. 1) We should NEVER use or access port numbers to get things done but only use the IP header whereever possible. 2)Client/Server protocol soulutions should only be developed for v6ops solutions, where the client and server are in the same network domain. Teredo breaks both of these principles for me. ISATAP is to robust for home use and I do not see it being used there at this time. I do see it in other environments for sure (e.g. Military, Manufacturing, Robotics, and a few others I know interested in ISATAP). The home user scenario is clear and well understood. The solution I will proprose will cause NO changes to the client code and will exist in the NAT and POP. The idea is to view it as NAT+IPV6 not working around NAT. This has been an error in our thinking model (mine included). The solution will drive as the underlying end mechanisms to either be Native IPv6 or 6to4 which are cohesive also with v6ops direction and current work. Note Teredo and ISATAP are not at this time. I will suggest it and bring it as idea and solution IETF can reject it if it is not good, whether it is used is another matter. I only say that because this is a real deployment problem for home use. I am now going to propose to a few providers to get feedback (my own included in NH) and a few home router vendors that we are building connections to via the IPv6 Forum. This will take me some time. P.S. If anyone here on the list is interested in working on this let me know and there are others not on this list. thanks Regards, /jim From owner-v6ops@ops.ietf.org Thu Feb 13 17:12: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 RAA12541 for ; Thu, 13 Feb 2003 17:12:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jRce-000DsO-00 for v6ops-data@psg.com; Thu, 13 Feb 2003 14:14:24 -0800 Received: from evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net ([4.65.19.240] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 18jRcb-000Ds9-00 for v6ops@ops.ietf.org; Thu, 13 Feb 2003 14:14:21 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Feb 2003 14:14:19 -0800 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Thu, 13 Feb 2003 14:14:04 -0800 Message-ID: <02b701c2d3ad$388f3ef0$b8a623c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B03240EDF@tayexc13.americas.cpqcorp.net> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12541 Bound, Jim wrote: > Tony, > > You are missing my point for the solution. But yes it could > be double NAT too. The solution I am looking for requires no > intelligence for any mechanism on the home node except to > send IPv6 packets. That is not the case for ISATAP. Or > administration of the IPv6 nodes for mechanisms. It is all > done by the home nat router. So Microsoft XP, Linux, > Freebsd, Symbian, Vxworks, and other home embedded OS system > nodes would not have had to implement any of the previous > ngtrans mechanisms. It is all accomplished at the home > "edge" to the provider or at the apartment complex "edge" to > the box for fibre at the curb, etc. etc. > > If the home nodes can get a public address for their network > then yes the previous ngtrans mechanism become usable. What > I am discussing is a different case. > I will admit I am having a hard time finding the point. For this case the home router may or may not be a nat, but it is downstream from a nat which prevents 6to4 from working. It sounds like that if it weren't for the private addressing on the upstream side, the solution you are looking for would be solved by 6to4. If that is the case, you are looking to define an IPv6 router that can automatically build a tunnel over IPv4 to get out. > I believe the home routers can build this and if we can > define and specify it. Well it would already be specified as the client router to a tunnel broker. If what you are trying to do is establish an anycast model for finding a tunnel broker, you will find it challenging to deal with the identity issue when the upstream nat mangles the header. This is a case where tunnel broker is the right tool, because it already has the mechanism to handle identity and prefix allocation. Tony > > Regards, > /jim > > > > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Wednesday, February 12, 2003 4:08 PM > > To: Bound, Jim; v6ops@ops.ietf.org > > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > So the case is a double nat? If it is just that the 'public' > > side of the nat has a private address and needs to tunnel > > over IPv4 infrastructure, isatap is the appropriate tool. > > > > > > -----Original Message----- > > From: Bound, Jim [mailto:Jim.Bound@hp.com] > > Sent: Wednesday, February 12, 2003 11:15 AM > > To: alh-ietf@tndh.net; v6ops@ops.ietf.org > > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > Tony, > > > > I may suggest alternative to Teredo but looking at that now > > technically. But if Teredo works that is fine but many have > > issues with the complexity. So I will reserve comment on > > Teredo for now OK. Not sure I support it now. We will see. > > > > The home router cannot become a 6to4 router because the > > public address may not be available or duplicated in practice > > is my assumption? But more than that an ecap of the packet > > with 6 proto-id is a simple software engineering upgrade for > > very low end home routers and field deliverable with a patch > > on the web is my belief, and 6to4 is far more complex and may > > require an entire release. So the work we do here may be two > > steps 1) first do simple encap, 2) eventually deploy 6to4 > > given the home router can use the public address. I am also > > worried of duplicate public address for the home router for > > the nat which I have seen at home and in hotels enough and in > > enough locations that I just have to look further into it. I > > am speaking with multiple providers now that do this function > > to get the issues from the horses mouth not second hand. I > > will also speak with 2 well known home router vendors on my > > assumptions for patches for upgrades. > > > > Regards, > > /jim > > > > > > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Wednesday, February 12, 2003 1:55 PM > > To: Bound, Jim; v6ops@ops.ietf.org > > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > Maybe I misunderstood the scenario, but it looks like you are > > describing a case where teredo is the appropriate choice. To > > restate; the ISP is offering support for IPv6, including a > > tunnel endpoint to transit any non-upgradable PE/CPE gear, > > though there is a nat in the path, so simple IPv4 encaps > > using 6to4 or isatap will fail. If the nat can be upgraded, > > it should become a 6to4 router. If not, it doesn't make sense > > to insert yet another device to do tunneling, because the end > > nodes are capable of doing it just as well. > > > > Tony > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > > Sent: Wednesday, February 12, 2003 9:22 AM > > To: v6ops@ops.ietf.org > > Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > Folks, > > > > I am hearing an need for home users for transition. It could > > be this is ipv6 wg work but will bounce it off here first. > > > > Assume dominant NAT/VPN/Firewall routers in most homes for > > Internet access. > > > > Assume an upstream provider obtains IPv6 prefix to give to > > subscribers. > > > > Assume home routers want to support IPv6 and will eventually > > but won't move until they believe it can be used over > > provider networks. > > > > Assume there is not enough Ipv4 address space for providers > > to give out to all subscribers or cannot at reasonable cost. > > But they can give the subscriber an IPv6 prefix. This means > > 6to4 or ISATAP won't work in this scenario in the users home. > > > > A solution (more on Teredo below) would be to figure a method > > for an IPv6 on the homelan to be encaped in the NAT packet to > > the provider who will decap that packet and send to the IPv6 > > destination and recall the state to the NAT user upon > > receiving packets back so the session can be established with > > the home user over the net. > > > > This is quick for now as a thought. > > > > The home user network encaps the IPv6 packet at NAT with > > Protocol ID equivalent to "6". The provider then takes that > > packet and decaps at their edge and uses native IPv6 or 6to4 > > to encap that packet to where the IPv6 service is located. I > > realize this has many assumptions and I would work on those > > with some other folks interested in this problem. > > > > I am re-reading Teredo now and working to see if it is > > addendum to Teredo or completely different solution. I think > > it is a different solution and possibly much simpler. I also > > believe this solution we are looking at can do e2e IPsec over > > the IPv4-NAT. > > > > This would be a minor initial update for the home router > > vendors and basic IPv6 edge tunneling for the Provider. Also > > I think a tunnel-broker could be used by the Provider to help > > set this up for users too. The code for the home router on > > my first analysis could also be a firmware upgrade that is > > down loadable. > > > > Could I get others opinions and thoughts on this before I and > > some others jump in here. > > > > thanks > > /jim > > > > > From owner-v6ops@ops.ietf.org Thu Feb 13 17:52: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 RAA16336 for ; Thu, 13 Feb 2003 17:52:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jSGX-000Hnw-00 for v6ops-data@psg.com; Thu, 13 Feb 2003 14:55:37 -0800 Received: from evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net ([4.65.19.240] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 18jSGU-000HnB-00 for v6ops@ops.ietf.org; Thu, 13 Feb 2003 14:55:34 -0800 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Feb 2003 14:55:31 -0800 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Thu, 13 Feb 2003 14:55:33 -0800 Message-ID: <02c501c2d3b3$0412e8b0$b8a623c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE4@tayexc13.americas.cpqcorp.net> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA16336 Bound, Jim wrote: > ... > I will build different solution other than Teredo. Teredo is > to complex and breaks a 2 rules for me I use as network > engineer/architect for v6ops solutions. 1) We should NEVER > use or access port numbers to get things done but only use > the IP header whereever possible. Well it is arguable that teredo violates this rule, since the origin application port is not referenced. The fact that it uses the available port id bits in the IPv4-UDP encapsulation header to construct the IPv6 address is really a function of the application in the encapsulating endpoint. > 2)Client/Server protocol > soulutions should only be developed for v6ops solutions, > where the client and server are in the same network domain. While this may be a reasonable restriction for a corporate marketing decision, it makes no sense for a standards effort. The whole point for people to move to IPv6 is so that there are no topological restrictions placed on nodes, particularly servers. If one required all servers to live in the same domain as their clients, all web access would require a proxy. v6ops needs to be about building the infrastructure tools and configurations so that IPv6 applications are unaware of the activities going on at the packet handling level. > Teredo breaks both of these principles for me. > > ISATAP is to robust for home use and I do not see it being > used there at this time. I do see it in other environments > for sure (e.g. Military, Manufacturing, Robotics, and a few > others I know interested in ISATAP). > > The home user scenario is clear and well understood. > > The solution I will proprose will cause NO changes to the > client code and will exist in the NAT and POP. The idea is > to view it as NAT+IPV6 not working around NAT. This has been > an error in our thinking model (mine included). Well, it is exactly the model of 6to4. You are adding the wrinkle of the home edge being behind a nat, which tunnel broker deals with. > The solution > will drive as the underlying end mechanisms to either be > Native IPv6 or 6to4 which are cohesive also with v6ops > direction and current work. Note Teredo and ISATAP are not > at this time. I will suggest it and bring it as idea and > solution IETF can reject it if it is not good, whether it is > used is another matter. I only say that because this is a > real deployment problem for home use. Yes and no. Yes the case exists where a home edge nat/router is behind a nat, and we need a solution, but no we can't assume that even the home edge nat is upgradable, as in docsis cable modems. The fact that v6ops is too highly focused on router upgrade solutions is due to the lack of appreciation for the breadth of the problem space. The whole point of the scenario design teams was to provide descriptive documents to help educate about this breadth, but several vocal participants have chosen to dismiss them as out of line with a directive that all deployments must fit a single mold. > > I am now going to propose to a few providers to get feedback > (my own included in NH) and a few home router vendors that we > are building connections to via the IPv6 Forum. This will > take me some time. I am not going to discourage new concepts, but take a hard look at the identity/allocation issues that are solved in tunnel broker, and make sure any new approach works at least that well. Tony > > P.S. If anyone here on the list is interested in working on > this let me know and there are others not on this list. thanks > > Regards, > /jim > From owner-v6ops@ops.ietf.org Fri Feb 14 04:02: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 EAA14125 for ; Fri, 14 Feb 2003 04:02:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jbkZ-000ONQ-00 for v6ops-data@psg.com; Fri, 14 Feb 2003 01:03:15 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 18jbkU-000ONE-00 for v6ops@ops.ietf.org; Fri, 14 Feb 2003 01:03:10 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1E92qhu038740; Fri, 14 Feb 2003 10:02:53 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1E92ln1098322; Fri, 14 Feb 2003 10:02:52 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20168 from ; Fri, 14 Feb 2003 10:02:44 +0100 Message-Id: <3E4CB082.B67D4324@hursley.ibm.com> Date: Fri, 14 Feb 2003 10:01:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: v6ops@ops.ietf.org Subject: Re: Deployment of Dual Stack with Applications References: <9C422444DE99BC46B3AD3C6EAFC9711B03240ED9@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit below... > "Bound, Jim" wrote: > > Folks, > > First I think the consensus for dual stack is clearly making head way finally in and out of the IETF. > > But here is a real operational scenario for us I am working on right now. > > User believe IPv6 is important and they want to deploy. The need to worry about all the things we discuss here but there is > another one. When do they tell their suppliers they MUST support IPv6 and how does this work? And when does IPv6 get turned > on? > > The good thing about a dual stack approach is these users can mandate all suppliers must support the dual IPv6/IPv4 stack for > procurement at some specified point in time. But they will most likely have to run IPv4 intiially on those procured boxes > until the v6ops type parts are figured out and applications are ported. > > Now to the technical issue. > > How are the apps ported and at what point on the suppliers boxes? > > Using IPv4-Mapped addresses in the base API an app could port to IPv6 and take IPv6 addresses and IPv4Mapped addresses from > getaddrinfo() (old gethostbyname() for those that don't know getaddrinfo() yet) and pass down IPv4-Mapped addresses to a dual > stack implementation and they will be put out over the network as IPv4 by a dual stack node, but to the application layer they > are just doing IPv6. > > This will be part of the deployment recommendations from vendors, consultants, and systems integrators for users and some > users will figure this out on their own and large application software providers that only want to release one binary for both > IPv4 and IPv6. > > I am not sure if we should put this into any docs for v6ops or not? It could be viewed as implementation deployment effort > and issue not a standars issue? But it should be part of our emerging scenarios is my belief currently (all of them)? I think this is very hard to document in a vendor-independent and o/s independent way. For example, some vendors may be so Java dependent that their only message to middleware implementors is "use JDK 1.4". Others may simply say "use the latest socket API." Others may go for BIA for the next twenty years. I approve of the goal, I'm just not sure it can be done. The good news is that I have never heard a middleware implementor say that supporting IPv6 is hard. Sometimes they say it's annoying, but that's as bad as it gets. Brian From owner-v6ops@ops.ietf.org Fri Feb 14 04:11: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 EAA14300 for ; Fri, 14 Feb 2003 04:11:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jbv0-000OqI-00 for v6ops-data@psg.com; Fri, 14 Feb 2003 01:14:02 -0800 Received: from dhcp-22.nordnog.org ([194.17.45.22] helo=dhcp-168-17-67.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18jbuz-000Oq4-00 for v6ops@ops.ietf.org; Fri, 14 Feb 2003 01:14:01 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-67.autonomica.se (8.12.2/8.10.2) with ESMTP id h1E9F4hE029871; Fri, 14 Feb 2003 10:15:04 +0100 (CET) Date: Fri, 14 Feb 2003 10:15:03 +0100 Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B034C06E1@tayexc13.americas.cpqcorp.net> Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA14300 >>> Assume there is not enough Ipv4 address space for providers to give >>> out to all subscribers or cannot at reasonable cost.  But they can >>> give the subscriber an IPv6 prefix.  This means 6to4 or >> ISATAP won't >>> work in this scenario in the users home. >>> >> >> Are you saying this as an alternative to IPv4 NAT or as a complement? >> (I assume the latter) > > The latter but an extension to IPv4-NAT to support IPv6. In other > words NAT admits it is evil but now has seen the light and trys to > help move users to IPv6. > The idea is to deal with the reality but move forward. Ok, I was hoping that we could come up with something in the middle that might give consumer oriented ISPs an incentive to start looking at IPv6. But that might be to create to much work and delay the outcome. >> If you mean the first of what I wrote above, I could finally see >> something that could make consumer oriented operators look at IPv6. > > That is one of my business goals. Exactly. But I can only help > invent the technology. But we do have resources in the v6 deployment > community to reach out to these players. Question is if we have the tools for them... - kurtis - From owner-v6ops@ops.ietf.org Fri Feb 14 07:38: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 HAA20616 for ; Fri, 14 Feb 2003 07:38:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jf7z-00099h-00 for v6ops-data@psg.com; Fri, 14 Feb 2003 04:39:39 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18jf7x-00099V-00 for v6ops@ops.ietf.org; Fri, 14 Feb 2003 04:39:37 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 688DE88B5; Fri, 14 Feb 2003 07:39:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Feb 2003 07:39:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Deployment of Dual Stack with Applications Date: Fri, 14 Feb 2003 07:39:35 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C06F4@tayexc13.americas.cpqcorp.net> Thread-Topic: Deployment of Dual Stack with Applications Thread-Index: AcLUB+WoAvrIXiP1Qbmwl8aszaHvTgAHiIeQ From: "Bound, Jim" To: "Brian E Carpenter" Cc: X-OriginalArrivalTime: 14 Feb 2003 12:39:36.0318 (UTC) FILETIME=[21F279E0:01C2D426] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA20616 Hi Brian, I agree. Was just passing it on as thought. thanks /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, February 14, 2003 4:02 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: Deployment of Dual Stack with Applications > > > below... > > > "Bound, Jim" wrote: > > > > Folks, > > > > First I think the consensus for dual stack is clearly > making head way > > finally in and out of the IETF. > > > > But here is a real operational scenario for us I am working > on right > > now. > > > > User believe IPv6 is important and they want to deploy. > The need to > > worry about all the things we discuss here but there is > another one. > > When do they tell their suppliers they MUST support IPv6 > and how does > > this work? And when does IPv6 get turned on? > > > > The good thing about a dual stack approach is these users > can mandate > > all suppliers must support the dual IPv6/IPv4 stack for > procurement at > > some specified point in time. But they will most likely have to run > > IPv4 intiially on those procured boxes until the v6ops type > parts are > > figured out and applications are ported. > > > > Now to the technical issue. > > > > How are the apps ported and at what point on the suppliers boxes? > > > > Using IPv4-Mapped addresses in the base API an app could > port to IPv6 > > and take IPv6 addresses and IPv4Mapped addresses from > > getaddrinfo() (old gethostbyname() for those that don't > know getaddrinfo() yet) and pass down IPv4-Mapped addresses to a dual > > stack implementation and they will be put out over the > network as IPv4 by a dual stack node, but to the application > layer they > > are just doing IPv6. > > > > This will be part of the deployment recommendations from vendors, > > consultants, and systems integrators for users and some users will > > figure this out on their own and large application software > providers > > that only want to release one binary for both IPv4 and IPv6. > > > > I am not sure if we should put this into any docs for v6ops > or not? > > It could be viewed as implementation deployment effort and > issue not a > > standars issue? But it should be part of our emerging > scenarios is my > > belief currently (all of them)? > > I think this is very hard to document in a vendor-independent and > o/s independent way. For example, some vendors may be so Java > dependent > that their only message to middleware implementors is "use JDK 1.4". > Others may simply say "use the latest socket API." Others may > go for BIA for the next twenty years. > > I approve of the goal, I'm just not sure it can be done. > > The good news is that I have never heard a middleware > implementor say that supporting IPv6 is hard. Sometimes they > say it's annoying, but that's as bad as it gets. > > Brian > From owner-v6ops@ops.ietf.org Fri Feb 14 09:09: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 JAA23098 for ; Fri, 14 Feb 2003 09:09:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jgZG-000DNA-00 for v6ops-data@psg.com; Fri, 14 Feb 2003 06:11:54 -0800 Received: from alc250.alcatel.be ([195.207.101.250] helo=mail.alcatel.be) by psg.com with esmtp (Exim 3.36 #1) id 18jgZA-000DM5-00 for v6ops@ops.ietf.org; Fri, 14 Feb 2003 06:11:48 -0800 Received: from bemail04.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id h1EEBXd27105 for ; Fri, 14 Feb 2003 15:11:41 +0100 Received: from alcatel.be ([138.203.64.126]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003021415113084:4698 ; Fri, 14 Feb 2003 15:11:30 +0100 Message-ID: <3E4CF90F.71D9318F@alcatel.be> Date: Fri, 14 Feb 2003 15:11:27 +0100 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: juha.wiljakka@nokia.com CC: v6ops@ops.ietf.org Subject: Re: 3GPP analysis References: <245DBCAEEC4F074CB77B3F984FF9834FDC3759@esebe005.ntc.nokia.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2003 15:11:30, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/14/2003 15:11:41, Serialize complete at 02/14/2003 15:11:41 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, SUPERLONG_LINE,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juha, Thank you for the reply, I did clarify some things for me. First of all I fully agree with you that we have to work with what 3GPP specified, if changes are needed they should be done towards 3GPP directly. I just wanted to know if from a technical point of view it would facilitate things in ALGs and SIP servers would be integrated. For the answer to the first question. If I correctly understood your proposal the decision for adding a SIP ALG in the IMS network would be based on the peer address carried in the first reply. One problem with this is that the destination SIP server will see the peer IP address of the IMS UE in the initial Invite is an IPv6 address and will therefor provide local interworking as the destination peer is IPv4 only. In this case the IMS SIP server will never know the peer is in fact a IPv4 node as the returned address is that of a local NAT-PT box. Personally I was thinking more of a solution where the IMS SIP ALG server would add an IPv4 address (of the NAT-PT) to the SDP in the SIP invite. In this case the SIP server at the destination network doesn't have to add any interworking boxes at the user plane. So it is a split of SDP and SIP interworking. A drawback of this solution is that the IPv4 address is added to every SIP message also the ones that don't require interworking. Do you know if work has been done regarding IPv4-IPv6 interworking for SIP in one of the SIP working groups. The only thing I've found sofar is how to carry IPv6 addresses in SIP and SDP, nothing about the processing or interpretation of these fields by the different SIP agents. Regards and thanks again, Suresh juha.wiljakka@nokia.com wrote: > Hi, Suresh! > > Thanks for your questions and comments on our document! > > Firstly, I think that the best way would be to enable IPv6 on end nodes (I see in your questions that you have considered dual stack SIP server in the destination network) and just use IPv6 for SIP/IMS communications. This is the final goal in all IMS communications! But until that has happened we will have to live with this kind of solution in those cases where communications with (legacy) IPv4 nodes are needed. > > (Another thing is that we have to develop the solution according to 3GPP (Rel5) IMS specifications, i.e. remembering that IMS is IPv6-only. We are not supposed to propose / make any changes in 3GPP specifications.) > > I try to further analyze your questions below: > > -----Original Message----- > From: ext suresh.leroy@alcatel.be [mailto:suresh.leroy@alcatel.be] > Sent: 12 February, 2003 17:22 > > 1) If the destination is an IPv4 node registered to a dual stack SIP > server, is the interworking then by default handled outside the IMS > operator's network or are there ways to keep the control whithin the IMS > operator's network. > > => When an IPv6 UE connected to IMS tries to reach the external IPv4 node it sends the INVITE request to the SIP proxy at the IMS. Then the SIP proxy at the IMS contacts the DNS to find out the IP address of the SIP proxy where the IPv4-only destination node is registered (so in this case it probably gets both IPv4 and IPv6 addresses as it is dual stack), and after this DNS resolution the originating SIP proxy at the IMS forwards (proxies) the INVITE request to the destination SIP proxy. This procedure does not involve the IP address of the destination SIP client, so the decision to use IPv4 or IPv6 routing for the outgoing INVITE request is based on the addresses returned for the destination SIP proxy and following the address selection policy configured in the IMS, independently of the type of client (IPv4-only in this case) that is registered to the destination SIP proxy. > > So there are two different possibilities: If the IMS decides to use IPv4 instead of IPv6 (from the edge of the IMS to the destination) to reach the destination SIP proxy, then no further IPv4-IPv6 interworking is needed outside the IMS domain, as IPv6 to IPv4 translation will be performed on the edge of the IMS. If the IMS decides to use IPv6, then protocol translation needs to be performed in the destination network. This decision can be based on the type of SIP proxy (dual stack in this case). > > I think quite natural place for the translation is on the edge of the IPv6-only IMS. SIP/SDP ALG is needed for SIP/SDP translation and user traffic translation is handled in a translator (e.g. NAT-PT; can also be a subset of NAT-PT, NAT64, etc.). > > 2) How is the SIP-ALG added in the path for outgoing SIP calls (assuming > the SIP-ALG is only in the path when needed). Is it a configuration in > the S-CSCF, e.g. if DNS resolve only returns a IPv4 address then forward > SIP messages to SIP-ALG, SIP-ALG then resends again the same DNS query > to find the next 'IPv4' hop. > > => At least these two options exist: > - The SIP-ALG is implemented together with the NAT-PT in the same box. This allows the SIP-ALG easily control the NAT-PT bindings. However, this may lower the translator performance as more tasks are needed within the one single box. > - The SIP-ALG and NAT-PT are in separate boxes and some kind of protocol (e.g. MEGACO) is used to remotely control NAT-PT bindings. > > 3) For incomming SIP sessions how is decided if the call should go to > the I-CSCF or the SIP-ALG. Is this done based on DNS information in the > IMS operator network, IPv6 address corresponding to I-CSCF, IPv4 address > to SIP-ALG. > This would result in external IPv6 SIP server sending their messages to > the I-CSCF and IPv4 servers forwarding SIP to the SIP-ALG. > How about external SIP server that are dual stack, where does it forward > SIP messages to. > > => Yep, DNS information could be used. And clear rules should exist what to do in the case of ds SIP server... Just thinking, can we know what IP version the peer node is using? > > Wouldn't it be easier if the ALG functionality for IMS would be > integrated in the I-CSCF or S-CSCF although there was heavy resistance > for this in 3GPP. > > => I was not personally active in 3GPP when those discussions were held. However, I would respect 3GPP opinions and as I commented previously, we are not anyhow making changes in 3GPP specifications. > > Best Regards, > -Juha W.- From owner-v6ops@ops.ietf.org Fri Feb 14 19:48:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10905 for ; Fri, 14 Feb 2003 19:48:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18jqW3-000Mm6-00 for v6ops-data@psg.com; Fri, 14 Feb 2003 16:49:15 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18jqVz-000Mlu-00 for v6ops@ops.ietf.org; Fri, 14 Feb 2003 16:49:11 -0800 Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06967 for ; Fri, 14 Feb 2003 17:49:11 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAB009KTRK23J@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 14 Feb 2003 17:48:03 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAB00MTBRK1Z0@mail.sun.net> for v6ops@ops.ietf.org; Fri, 14 Feb 2003 17:48:02 -0700 (MST) Date: Fri, 14 Feb 2003 16:47:59 -0800 From: Alain Durand Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT To: "Bound, Jim" Cc: alh-ietf@tndh.net, v6ops@ops.ietf.org Message-id: <3E4D8E3F.6030608@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: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE4@tayexc13.americas.cpqcorp.net> X-Spam-Status: No, hits=-1.0 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Jim, I like your idea. A lot. the issue I have with solution like teredo is that they are initiated by the end nodes. The implications are: 1- all end node needs to understand this protocol 2- it becomes difficult for the acess router/firewall to enfore any kind of policy on what traffic is acceptable A knob that says 'enable IPv6' is just not enough. We need solutions that enable the user to express easily the same security policy in v4 and v6. Those are the reasons why I think that 'IPv6 connectivity' is a functionality that has to be provided by an access router and not by the end hosts. . The nice thing about this is that it would work the same way in case of simple NAT (the exit router is given a public IPv4 address) and double NAT (the exit router is given a private address) but tunneling over UDP. v4 Internet | | | CPE <--- v4 external address can be either v4 acces router global or private (double NAT) v4 NAT v6 access router (Tunnel Broker client) | | ------------------------------------------ Home lan | | Host1 Host2 Even better, this could be implemented on a different box than the actual v4 exit router! The connection scenario would then be the following: v4 Internet | | | CPE v4 acces router v4 NAT | | ------------------------------------------ Home lan | | | v6 access Host1 Host2 router (Tunnel Broker client) That way folks who do not want to (or can not)replace their CPE just have to add another box in the home network to provide v6 connectivity to the entire home lan. Now, as it has been pointed out, this is a typical case where the access router is a client to a tunnel broker. The question is what can we do to simplify the tunnel set-up from the router to the tunnel broker. If we decide to go that route, a tunnel set up protocol like the one Marc Blanchet was suggesting now become a interesting solution The configuration of the v6 access router would require: - providing the IPv4 address (or name) of the IPS Tunnel Broker - providing the credentials negatiated out of band with the ISP (e.g. username/passwd) - specifying the encapsulation mode: IPv6/IPv4 or IPv6/UDP/IPv4 or IPv6/PPP/IPv4 - specifying the IPv6 security policy Yes, there is manual configuration involved, but I think it is minimal and not too different to what home users do today to configure their DSL router. - Alain. From owner-v6ops@ops.ietf.org Sat Feb 15 11:50: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 LAA04855 for ; Sat, 15 Feb 2003 11:50:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18k5Vr-0004Eq-00 for v6ops-data@psg.com; Sat, 15 Feb 2003 08:50:03 -0800 Received: from unimur.um.es ([155.54.1.1]) by psg.com with esmtp (Exim 3.36 #1) id 18k5Vm-0004E9-00 for v6ops@ops.ietf.org; Sat, 15 Feb 2003 08:49:59 -0800 Received: from zape.um.es (zape.um.es [155.54.0.102]) by unimur.um.es (8.9.1b+Sun/8.9.1) with ESMTP id RAA28835 for ; Sat, 15 Feb 2003 17:49:57 +0100 (MET) Received: from zape.um.es (localhost [127.0.0.1]) by zape.um.es (8.9.1b+Sun/8.9.1) with ESMTP id RAA18585 for ; Sat, 15 Feb 2003 17:49:55 +0100 (MET) Received: from dif.um.es (ifv38.rem.um.es [155.54.192.38]) by zape.um.es (8.9.1b+Sun/8.9.1) with ESMTP id RAA18566; Sat, 15 Feb 2003 17:49:47 +0100 (MET) Message-ID: <3E4E7079.8060709@dif.um.es> Date: Sat, 15 Feb 2003 17:53:13 +0100 From: "Antonio F. =?ISO-8859-1?Q?G=F3mez?= Skarmeta" Organization: Univ. Murcia (Spain) User-Agent: Mozilla/5.0 (Windows; U; Win98; es-ES; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: es-es MIME-Version: 1.0 To: Alain Durand CC: "Bound, Jim" , alh-ietf@tndh.net, v6ops@ops.ietf.org Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT References: <9C422444DE99BC46B3AD3C6EAFC9711B03240EE4@tayexc13.americas.cpqcorp.net> <3E4D8E3F.6030608@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-6.7 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_LONG_DENSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Alain Durand wrote: > Jim, > > I like your idea. A lot. > the issue I have with solution like teredo is that they are > initiated by the end nodes. The implications are: > 1- all end node needs to understand this protocol > 2- it becomes difficult for the acess router/firewall > to enfore any kind of policy on what traffic is acceptable > A knob that says 'enable IPv6' is just not enough. > We need solutions that enable the user to express easily the same > security policy in v4 and v6. I will also like this idea. > > > Those are the reasons why I think that 'IPv6 connectivity' is > a functionality that has to be provided by an access router > and not by the end hosts. > . > Now, as it has been pointed out, this is a typical case > where the access router is a client to a tunnel broker. > The question is what can we do to simplify the tunnel > set-up from the router to the tunnel broker. > If we decide to go that route, a tunnel set up protocol > like the one Marc Blanchet was suggesting now become > a interesting solution This was something we have been looking within projects like Euro6IX and the idea of a set up protocol and an easy to manage tunnel-broker solution will be really valuable and I think we will be interested in collaborate -- ------------------------------------------------------------ Antonio F. Gómez Skarmeta Dept. Ingeniería de la Información y las Comunicaciones Facultad de Informática Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 From owner-v6ops@ops.ietf.org Sun Feb 16 09:22: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 JAA26454 for ; Sun, 16 Feb 2003 09:22:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kPhc-0007vU-00 for v6ops-data@psg.com; Sun, 16 Feb 2003 06:23:32 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org) by psg.com with esmtp (Exim 3.36 #1) id 18kPhY-0007vH-00 for v6ops@ops.ietf.org; Sun, 16 Feb 2003 06:23:29 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 11A2D7D7F; Sun, 16 Feb 2003 15:22:30 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id BF464789D; Sun, 16 Feb 2003 15:18:23 +0100 (CET) From: "Jeroen Massar" To: "'Alain Durand'" , "'Bound, Jim'" Cc: , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Sun, 16 Feb 2003 15:18:28 +0100 Organization: Unfix Message-ID: <002e01c2d5c6$55d3f3f0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3E4D8E3F.6030608@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA26454 Alain Durand wrote: > Even better, this could be implemented on a different > box than the actual v4 exit router! > The connection scenario would then be the following: > > v4 Internet > | > | > | > > CPE > v4 acces router > v4 NAT > | > | > ------------------------------------------ Home lan > | | | > v6 access Host1 Host2 > router > (Tunnel Broker client) > > > That way folks who do not want to (or can not)replace their CPE > just have to add another box in the home network to provide > v6 connectivity to the entire home lan. Which one can do now by simply installing eg the freenet6 client onto one of the existing windows/*nix boxes which will advertise the IPv6 prefix onto the local subnet. The only trick here is to have the CPE forward proto-41 to your v6-gate or using Teredo. Btw 'just have to add' is sometimes expensive for some people. > Now, as it has been pointed out, this is a typical case > where the access router is a client to a tunnel broker. > The question is what can we do to simplify the tunnel > set-up from the router to the tunnel broker. > If we decide to go that route, a tunnel set up protocol > like the one Marc Blanchet was suggesting now become > a interesting solution > > The configuration of the v6 access router would require: > - providing the IPv4 address (or name) of the IPS Tunnel Broker > - providing the credentials negatiated out of band with the ISP (e.g. > username/passwd) > - specifying the encapsulation mode: IPv6/IPv4 or IPv6/UDP/IPv4 or > IPv6/PPP/IPv4 > - specifying the IPv6 security policy > > Yes, there is manual configuration involved, but I think it is minimal > and not too different to what home users do today to configure their > DSL router. Which would usually result in a clickety-click Windows interface to configure one of the machines to be the gateway. Which should be doable for most users as long as there is some nice document available with per-dialog screenshots. Then again... ;) One thing that must be done in these clients is to check wether there is native connectivity already because if there is one should not be using a tunnel (6in4,6to4,isatap,teredo,...). Greets, Jeroen From owner-v6ops@ops.ietf.org Sun Feb 16 13:00: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 NAA28149 for ; Sun, 16 Feb 2003 13:00:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kT3z-000Doi-00 for v6ops-data@psg.com; Sun, 16 Feb 2003 09:58:51 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18kT3v-000DoT-00 for v6ops@ops.ietf.org; Sun, 16 Feb 2003 09:58:48 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA13326; Sun, 16 Feb 2003 17:58:40 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h1GHwbU3024425; Sun, 16 Feb 2003 17:58:37 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1GHwbi12658; Sun, 16 Feb 2003 17:58:37 GMT Date: Sun, 16 Feb 2003 17:58:37 +0000 From: Tim Chown To: Jeroen Massar Cc: "'Alain Durand'" , "'Bound, Jim'" , alh-ietf@tndh.net, v6ops@ops.ietf.org Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Message-ID: <20030216175836.GD12560@login.ecs.soton.ac.uk> Mail-Followup-To: Jeroen Massar , 'Alain Durand' , "'Bound, Jim'" , alh-ietf@tndh.net, v6ops@ops.ietf.org References: <3E4D8E3F.6030608@sun.com> <002e01c2d5c6$55d3f3f0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002e01c2d5c6$55d3f3f0$210d640a@unfix.org> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > Which one can do now by simply installing eg the freenet6 client > onto one of the existing windows/*nix boxes which will advertise > the IPv6 prefix onto the local subnet. The only trick here is > to have the CPE forward proto-41 to your v6-gate or using Teredo. > Btw 'just have to add' is sometimes expensive for some people. This is what our IPv6 students tend to do in their homes. It works nicely, but still requires a tweak in the DSL router. Tim From owner-v6ops@ops.ietf.org Sun Feb 16 13:50: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 NAA28582 for ; Sun, 16 Feb 2003 13:50:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kTvD-000Et9-00 for v6ops-data@psg.com; Sun, 16 Feb 2003 10:53:51 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18kTvB-000Esr-00 for v6ops@ops.ietf.org; Sun, 16 Feb 2003 10:53:49 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Sun, 16 Feb 2003 19:55:20 +0100 Message-ID: <079c01c2d5ec$ed8ec4b0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: "Jeroen Massar" , Cc: "'Alain Durand'" , "'Bound, Jim'" , References: <3E4D8E3F.6030608@sun.com> <002e01c2d5c6$55d3f3f0$210d640a@unfix.org> <20030216175836.GD12560@login.ecs.soton.ac.uk> Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Sun, 16 Feb 2003 19:54:55 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_RELAYS_ORDB_ORG, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've observed, that in most of the cases, a NAT box forwards proto-41 as any other UPD or TCP traffic, so I can use my IPv6 elsewhere ... In my home, hotels, conferences, ... In my case never requires changing my DSL router configuration, but I agree that if the hotel is filtering proto-41, I will not be able to change it either ;-) Regards, Jordi ----- Original Message ----- From: "Tim Chown" To: "Jeroen Massar" Cc: "'Alain Durand'" ; "'Bound, Jim'" ; ; Sent: Sunday, February 16, 2003 6:58 PM Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > Which one can do now by simply installing eg the freenet6 client > > onto one of the existing windows/*nix boxes which will advertise > > the IPv6 prefix onto the local subnet. The only trick here is > > to have the CPE forward proto-41 to your v6-gate or using Teredo. > > Btw 'just have to add' is sometimes expensive for some people. > > This is what our IPv6 students tend to do in their homes. It works nicely, > but still requires a tweak in the DSL router. > > Tim > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Sun Feb 16 14:13: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 OAA28748 for ; Sun, 16 Feb 2003 14:13:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kUGJ-000FLi-00 for v6ops-data@psg.com; Sun, 16 Feb 2003 11:15:39 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org) by psg.com with esmtp (Exim 3.36 #1) id 18kUGG-000FLU-00 for v6ops@ops.ietf.org; Sun, 16 Feb 2003 11:15:36 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 4C2337A64; Sun, 16 Feb 2003 20:15:30 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 7434D786D; Sun, 16 Feb 2003 20:15:20 +0100 (CET) From: "Jeroen Massar" To: "'JORDI PALET MARTINEZ'" , Cc: "'Alain Durand'" , "'Bound, Jim'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Sun, 16 Feb 2003 20:15:37 +0100 Organization: Unfix Message-ID: <000901c2d5ef$cba2cf60$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <079c01c2d5ec$ed8ec4b0$870a0a0a@consulintel.es> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA28748 JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] wrote: > I've observed, that in most of the cases, a NAT box forwards > proto-41 as any other UPD or TCP traffic, so I can use my IPv6 > elsewhere ... In my home, hotels, conferences, ... I wonder to which box (IPv4) behind the NAT it is forwarding the proto-41 packets then. Unless you configured a default/unmatched target ofcourse. But then you already configured it correctly ;) > In my case never requires changing my DSL router > configuration, but I agree that if the hotel is filtering > proto-41, I will not be able to change it either ;-) If you are in a hotel you won't have any access to the CPE either. And the CPE won't know what to do with the proto-41 packets when it reaches it then. But that's why we've got Teredo. Though one can always ask himself if it where a policy decision for not having IPv6 in their network but let's not go there... Greets, Jeroen > ----- Original Message ----- > From: "Tim Chown" > To: "Jeroen Massar" > Cc: "'Alain Durand'" ; "'Bound, Jim'" > ; ; > Sent: Sunday, February 16, 2003 6:58 PM > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > > > Which one can do now by simply installing eg the freenet6 client > > > onto one of the existing windows/*nix boxes which will advertise > > > the IPv6 prefix onto the local subnet. The only trick here is > > > to have the CPE forward proto-41 to your v6-gate or using Teredo. > > > Btw 'just have to add' is sometimes expensive for some people. > > > > This is what our IPv6 students tend to do in their homes. > It works nicely, > > but still requires a tweak in the DSL router. > > > > Tim From owner-v6ops@ops.ietf.org Sun Feb 16 14:30: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 OAA28930 for ; Sun, 16 Feb 2003 14:30:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kUY2-000Fiw-00 for v6ops-data@psg.com; Sun, 16 Feb 2003 11:33:58 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18kUXy-000Fie-00 for v6ops@ops.ietf.org; Sun, 16 Feb 2003 11:33:54 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Sun, 16 Feb 2003 20:35:33 +0100 Message-ID: <084a01c2d5f2$8998f560$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , Cc: "'Alain Durand'" , "'Bound, Jim'" , References: <000901c2d5ef$cba2cf60$210d640a@unfix.org> Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Sun, 16 Feb 2003 20:35:11 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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=EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT, RCVD_IN_RELAYS_ORDB_ORG,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit No ... any host behind the NAT works fine. You can create several tunnels, each one to a different host, and it works, but what I unusually do is: 1) 1 host acts as the IPv6 router, including RA (usually my own PC, if in a conference, or my web/email server in my home). 2) All the local-link IPv6 traffic goes to the host in 1) 3) The host in 1) send it to the DSL/NAT box, as payload of IPv4 packets 4) The NAT box forwards the traffic to the correct host (1), because he only see IPv4 ... The point is that the NAT box isn't configured in any special way, just needs to keep forwarding proto-41, not just UPD/TCP/ICMP. You only need to configure the tunnel and RA in one host (1) behind the NAT box. I found some (I will not mention here), that only forward UDP/TCP/ICMP, so then, it doesn't works. Regards, Jordi ----- Original Message ----- From: "Jeroen Massar" To: "'JORDI PALET MARTINEZ'" ; Cc: "'Alain Durand'" ; "'Bound, Jim'" ; Sent: Sunday, February 16, 2003 8:15 PM Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] wrote: > I've observed, that in most of the cases, a NAT box forwards > proto-41 as any other UPD or TCP traffic, so I can use my IPv6 > elsewhere ... In my home, hotels, conferences, ... I wonder to which box (IPv4) behind the NAT it is forwarding the proto-41 packets then. Unless you configured a default/unmatched target ofcourse. But then you already configured it correctly ;) > In my case never requires changing my DSL router > configuration, but I agree that if the hotel is filtering > proto-41, I will not be able to change it either ;-) If you are in a hotel you won't have any access to the CPE either. And the CPE won't know what to do with the proto-41 packets when it reaches it then. But that's why we've got Teredo. Though one can always ask himself if it where a policy decision for not having IPv6 in their network but let's not go there... Greets, Jeroen > ----- Original Message ----- > From: "Tim Chown" > To: "Jeroen Massar" > Cc: "'Alain Durand'" ; "'Bound, Jim'" > ; ; > Sent: Sunday, February 16, 2003 6:58 PM > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > > > Which one can do now by simply installing eg the freenet6 client > > > onto one of the existing windows/*nix boxes which will advertise > > > the IPv6 prefix onto the local subnet. The only trick here is > > > to have the CPE forward proto-41 to your v6-gate or using Teredo. > > > Btw 'just have to add' is sometimes expensive for some people. > > > > This is what our IPv6 students tend to do in their homes. > It works nicely, > > but still requires a tweak in the DSL router. > > > > Tim ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Mon Feb 17 00:54:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05448 for ; Mon, 17 Feb 2003 00:54:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18keGA-000CC1-00 for v6ops-data@psg.com; Sun, 16 Feb 2003 21:56:10 -0800 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by psg.com with esmtp (Exim 3.36 #1) id 18keG6-000CBo-00 for v6ops@ops.ietf.org; Sun, 16 Feb 2003 21:56:06 -0800 Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18keG0-00030G-00; Sun, 16 Feb 2003 21:56:00 -0800 Date: Mon, 17 Feb 2003 00:53:18 -0500 From: Keith Moore To: "Bound, Jim" Cc: moore@cs.utk.edu, v6ops@ops.ietf.org Subject: Re: Deployment of Dual Stack with Applications Message-Id: <20030217005318.13bccc63.moore@cs.utk.edu> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B034C06D3@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B034C06D3@tayexc13.americas.cpqcorp.net> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,RCVD_IN_UNCONFIRMED_DSBL,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > How are the apps ported and at what point on the suppliers > boxes? there is no simple answer to this question. but changing the behavior of existing APIs to try to hide IPv6 from apps will harm interoperability. the goal should be to facilitate a more capable Internet supporting more capable apps, not merely to get apps to change packet formats whether they know about it or not. apps won't get more capable by being unaware of IPv6. Keith From owner-v6ops@ops.ietf.org Mon Feb 17 12:15: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 MAA26342 for ; Mon, 17 Feb 2003 12:15:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kot2-0006Sf-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 09:17:00 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18kosz-0006SK-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 09:16:57 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.30]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA15923 for ; Mon, 17 Feb 2003 09:15:44 -0800 (PST) Message-Id: <5.1.0.14.2.20030217115420.036575f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Feb 2003 12:04:56 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, This is a WG Last Call for comments on sending the 3GPP scenarios document to the IESG for consideration as an Informational RFC: Title: Transition Scenarios for 3GPP Networks Filename: draft-ietf-v6ops-3gpp-cases-02.txt Editor: J. Soininen Date: January 2003 The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt Abstract This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope of this document. The purpose of the document is to list the scenarios for further discussion and study. Since this is the first WG last call that we have had in the v6ops WG, we would like to remind you of the process that we discussed for WG last calls when we started this WG. The WG Last Call is a final check that the WG has rough consensus to advance the document to the IESG. Advancing a document to the IESG indicates that the WG believes that this document is both technically sound and useful. It also indicates that we believe that the document meets all of the requirements for publication as an RFC. To pass WG last call, this document must be reviewed and actively supported by a significant number of people, including experts in all applicable areas, or it will not be sent to the IESG. Silence does NOT indicate consent during this phase. So, please review this document carefully, and send your feedback to the list, indicating whether or not you believe that this document is ready to go to the IESG. Unless sufficient support is demonstrated on the list, the document will not be send to the IESG. Thanks, Margaret, Itojun and Bob v6ops WG Chairs From owner-v6ops@ops.ietf.org Mon Feb 17 12:15: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 MAA26370 for ; Mon, 17 Feb 2003 12:15:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kotB-0006St-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 09:17:09 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18kot0-0006SW-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 09:16:58 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.30]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA15940 for ; Mon, 17 Feb 2003 09:15:46 -0800 (PST) Message-Id: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Feb 2003 12:11:16 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, This is a WG Last Call for comments on sending the Unmanaged Networks scenarios document to the IESG for consideration as an Informational RFC: Title: Unmanaged Networks IPv6 Transition Scenarios Filename: draft-ietf-v6ops-unman-scenarios-00.txt Authors: C. Huitema, R. Austein, R. van der Pol Date: January 10, 2003 The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt Abstract In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks. Please review this document carefully, and send your feedback to the list, indicating 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 document will not be send to the IESG. Thanks, Margaret, Itojun and Bob v6ops WG Chairs From owner-v6ops@ops.ietf.org Mon Feb 17 19:49: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 TAA04869 for ; Mon, 17 Feb 2003 19:48:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kvxA-000NEU-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 16:49:44 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18kvx7-000NEG-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 16:49:41 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9D2B85655; Mon, 17 Feb 2003 19:49:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 19:49:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 19:49:40 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240F04@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTrU0GdYnk68oBR+Gh1Iak+vfOWwDOSDog From: "Bound, Jim" To: , X-OriginalArrivalTime: 18 Feb 2003 00:49:40.0526 (UTC) FILETIME=[9E876CE0:01C2D6E7] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA04869 Tony, Your not getting it at all. Let me try another way and I think the tunnel broker may work. But that is the solution discussion. Others get it and others don't and I am trying to determine what those not getting it are missing. The idea is to simply get an IPv6 packet to the POP without any mechanism except a tunnel. Home user BOX address 10.1.2.3 To NAT Box 18.1.4.6 (global address) To Tunnel point at POP POP Tunnel End point 128.3.6.8 Two ways this can work. #1 Home user encaps as follows: Src 10.1.2.3 DST 128.3.6.8 IPv6 encap packet in protocol ID 41 THis means the home node has to encap its IPv6 address inside IPv4. #2 Better Edgev6 solution would be as follows: Home user box just sends IPv6 packet (no messing around on the home node) and the NAT box has been upgraded to encap to the tunnel broker or POP tunnel using config tunnels. This means upgrade to home NAT boxes though for simple encap and understanding tunnel end points. #3 Once IPv6 is native the IPv6 packet goes directly to the POP. THe solution change for #2 is the NAT Home Router. This is not done today. As far as the previous architecture point you missed that too. What I believe is that no box on a network should have to look past the header to do perform its function. So looking at port numbers is architecturally impure from my view to be kind. I have enough information to attempt execution now though. Thanks for your time Regards, /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Thursday, February 13, 2003 5:14 PM > To: Bound, Jim; v6ops@ops.ietf.org > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Bound, Jim wrote: > > Tony, > > > > You are missing my point for the solution. But yes it could > > be double NAT too. The solution I am looking for requires no > > intelligence for any mechanism on the home node except to > > send IPv6 packets. That is not the case for ISATAP. Or > > administration of the IPv6 nodes for mechanisms. It is all > > done by the home nat router. So Microsoft XP, Linux, > > Freebsd, Symbian, Vxworks, and other home embedded OS system > > nodes would not have had to implement any of the previous > > ngtrans mechanisms. It is all accomplished at the home > > "edge" to the provider or at the apartment complex "edge" to > > the box for fibre at the curb, etc. etc. > > > > If the home nodes can get a public address for their network > > then yes the previous ngtrans mechanism become usable. What > > I am discussing is a different case. > > > > I will admit I am having a hard time finding the point. For this case > the home router may or may not be a nat, but it is downstream > from a nat > which prevents 6to4 from working. It sounds like that if it > weren't for > the private addressing on the upstream side, the solution you are > looking for would be solved by 6to4. If that is the case, you are > looking to define an IPv6 router that can automatically build a tunnel > over IPv4 to get out. > > > I believe the home routers can build this and if we can > > define and specify it. > > Well it would already be specified as the client router to a tunnel > broker. If what you are trying to do is establish an anycast model for > finding a tunnel broker, you will find it challenging to deal with the > identity issue when the upstream nat mangles the header. This > is a case > where tunnel broker is the right tool, because it already has the > mechanism to handle identity and prefix allocation. > > Tony > > > > > Regards, > > /jim > > > > > > > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Wednesday, February 12, 2003 4:08 PM > > > To: Bound, Jim; v6ops@ops.ietf.org > > > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > So the case is a double nat? If it is just that the 'public' > > > side of the nat has a private address and needs to tunnel > > > over IPv4 infrastructure, isatap is the appropriate tool. > > > > > > > > > -----Original Message----- > > > From: Bound, Jim [mailto:Jim.Bound@hp.com] > > > Sent: Wednesday, February 12, 2003 11:15 AM > > > To: alh-ietf@tndh.net; v6ops@ops.ietf.org > > > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > Tony, > > > > > > I may suggest alternative to Teredo but looking at that now > > > technically. But if Teredo works that is fine but many have > > > issues with the complexity. So I will reserve comment on > > > Teredo for now OK. Not sure I support it now. We will see. > > > > > > The home router cannot become a 6to4 router because the > > > public address may not be available or duplicated in practice > > > is my assumption? But more than that an ecap of the packet > > > with 6 proto-id is a simple software engineering upgrade for > > > very low end home routers and field deliverable with a patch > > > on the web is my belief, and 6to4 is far more complex and may > > > require an entire release. So the work we do here may be two > > > steps 1) first do simple encap, 2) eventually deploy 6to4 > > > given the home router can use the public address. I am also > > > worried of duplicate public address for the home router for > > > the nat which I have seen at home and in hotels enough and in > > > enough locations that I just have to look further into it. I > > > am speaking with multiple providers now that do this function > > > to get the issues from the horses mouth not second hand. I > > > will also speak with 2 well known home router vendors on my > > > assumptions for patches for upgrades. > > > > > > Regards, > > > /jim > > > > > > > > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Wednesday, February 12, 2003 1:55 PM > > > To: Bound, Jim; v6ops@ops.ietf.org > > > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > Maybe I misunderstood the scenario, but it looks like you are > > > describing a case where teredo is the appropriate choice. To > > > restate; the ISP is offering support for IPv6, including a > > > tunnel endpoint to transit any non-upgradable PE/CPE gear, > > > though there is a nat in the path, so simple IPv4 encaps > > > using 6to4 or isatap will fail. If the nat can be upgraded, > > > it should become a 6to4 router. If not, it doesn't make sense > > > to insert yet another device to do tunneling, because the end > > > nodes are capable of doing it just as well. > > > > > > Tony > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > > > Sent: Wednesday, February 12, 2003 9:22 AM > > > To: v6ops@ops.ietf.org > > > Subject: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > Folks, > > > > > > I am hearing an need for home users for transition. It could > > > be this is ipv6 wg work but will bounce it off here first. > > > > > > Assume dominant NAT/VPN/Firewall routers in most homes for > > > Internet access. > > > > > > Assume an upstream provider obtains IPv6 prefix to give to > > > subscribers. > > > > > > Assume home routers want to support IPv6 and will eventually > > > but won't move until they believe it can be used over > > > provider networks. > > > > > > Assume there is not enough Ipv4 address space for providers > > > to give out to all subscribers or cannot at reasonable cost. > > > But they can give the subscriber an IPv6 prefix. This means > > > 6to4 or ISATAP won't work in this scenario in the users home. > > > > > > A solution (more on Teredo below) would be to figure a method > > > for an IPv6 on the homelan to be encaped in the NAT packet to > > > the provider who will decap that packet and send to the IPv6 > > > destination and recall the state to the NAT user upon > > > receiving packets back so the session can be established with > > > the home user over the net. > > > > > > This is quick for now as a thought. > > > > > > The home user network encaps the IPv6 packet at NAT with > > > Protocol ID equivalent to "6". The provider then takes that > > > packet and decaps at their edge and uses native IPv6 or 6to4 > > > to encap that packet to where the IPv6 service is located. I > > > realize this has many assumptions and I would work on those > > > with some other folks interested in this problem. > > > > > > I am re-reading Teredo now and working to see if it is > > > addendum to Teredo or completely different solution. I think > > > it is a different solution and possibly much simpler. I also > > > believe this solution we are looking at can do e2e IPsec over > > > the IPv4-NAT. > > > > > > This would be a minor initial update for the home router > > > vendors and basic IPv6 edge tunneling for the Provider. Also > > > I think a tunnel-broker could be used by the Provider to help > > > set this up for users too. The code for the home router on > > > my first analysis could also be a firmware upgrade that is > > > down loadable. > > > > > > Could I get others opinions and thoughts on this before I and > > > some others jump in here. > > > > > > thanks > > > /jim > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon Feb 17 19:51: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 TAA04909 for ; Mon, 17 Feb 2003 19:51:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kw1x-000NQj-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 16:54:41 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18kw1u-000NQW-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 16:54:38 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id DFC2F4ADB; Mon, 17 Feb 2003 19:54:37 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 19:54:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 19:54:37 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07AF@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTswaIb3XlCw72TviJFIVXZGBYdwDNMQVQ From: "Bound, Jim" To: , X-OriginalArrivalTime: 18 Feb 2003 00:54:37.0841 (UTC) FILETIME=[4FBE1810:01C2D6E8] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA04909 Tony, > Bound, Jim wrote: > > ... > > I will build different solution other than Teredo. Teredo is > > to complex and breaks a 2 rules for me I use as network > > engineer/architect for v6ops solutions. 1) We should NEVER > > use or access port numbers to get things done but only use > > the IP header whereever possible. > > Well it is arguable that teredo violates this rule, since the > origin application port is not referenced. The fact that it > uses the available port id bits in the IPv4-UDP encapsulation > header to construct the IPv6 address is really a function of > the application in the encapsulating endpoint. It has to work with more than the IP header. > > > 2)Client/Server protocol > > soulutions should only be developed for v6ops solutions, > > where the client and server are in the same network domain. > > While this may be a reasonable restriction for a corporate > marketing decision, it makes no sense for a standards effort. > The whole point for people to move to IPv6 is so that there > are no topological restrictions placed on nodes, particularly > servers. If one required all servers to live in the same > domain as their clients, all web access would require a > proxy. v6ops needs to be about building the infrastructure > tools and configurations so that IPv6 applications are > unaware of the activities going on at the packet handling level. I am fine with client/server apps that run across many nets. I am not fine with transition solutions that try to attempt work around NAT. > > > > Teredo breaks both of these principles for me. > > > > ISATAP is to robust for home use and I do not see it being > > used there at this time. I do see it in other environments > > for sure (e.g. Military, Manufacturing, Robotics, and a few > > others I know interested in ISATAP). > > > > The home user scenario is clear and well understood. > > > > The solution I will proprose will cause NO changes to the > > client code and will exist in the NAT and POP. The idea is > > to view it as NAT+IPV6 not working around NAT. This has been > > an error in our thinking model (mine included). > > Well, it is exactly the model of 6to4. You are adding the > wrinkle of the home edge being behind a nat, which tunnel > broker deals with. I believe so except for how to get the packet to the broker. > > > The solution > > will drive as the underlying end mechanisms to either be > > Native IPv6 or 6to4 which are cohesive also with v6ops > > direction and current work. Note Teredo and ISATAP are not > > at this time. I will suggest it and bring it as idea and > > solution IETF can reject it if it is not good, whether it is > > used is another matter. I only say that because this is a > > real deployment problem for home use. > > Yes and no. Yes the case exists where a home edge nat/router > is behind a nat, and we need a solution, but no we can't > assume that even the home edge nat is upgradable, as in > docsis cable modems. I don't agree and will get it from the answer from those suppliers to be sure. >The fact that v6ops is too highly > focused on router upgrade solutions is due to the lack of > appreciation for the breadth of the problem space. The whole > point of the scenario design teams was to provide descriptive > documents to help educate about this breadth, but several > vocal participants have chosen to dismiss them as out of line > with a directive that all deployments must fit a single mold. Don't discount the importance of the v6ops scenarios but deployment may not wait. > > > > > I am now going to propose to a few providers to get feedback > > (my own included in NH) and a few home router vendors that we > > are building connections to via the IPv6 Forum. This will > > take me some time. > > I am not going to discourage new concepts, but take a hard > look at the identity/allocation issues that are solved in > tunnel broker, and make sure any new approach works at least > that well. Of course. /jim > > Tony > > > > > > P.S. If anyone here on the list is interested in working on > > this let me know and there are others not on this list. thanks > > > > Regards, > > /jim > > > > From owner-v6ops@ops.ietf.org Mon Feb 17 19:53: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 TAA04931 for ; Mon, 17 Feb 2003 19:53:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kw4H-000NWa-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 16:57:05 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18kw4F-000NWK-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 16:57:03 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E147045C4; Mon, 17 Feb 2003 19:57:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 19:57:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 19:57:02 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B0@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLUi+Z2YYaEo9g0Q5aSLvfxjnOjSQCXKg/g From: "Bound, Jim" To: "Alain Durand" Cc: , X-OriginalArrivalTime: 18 Feb 2003 00:57:02.0726 (UTC) FILETIME=[A619CA60:01C2D6E8] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA04931 Alain, I am on the exact same page as you today. I also believe this is imperative for IPv6 deployment. Thanks /jim > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: Friday, February 14, 2003 7:48 PM > To: Bound, Jim > Cc: alh-ietf@tndh.net; v6ops@ops.ietf.org > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Jim, > > I like your idea. A lot. > the issue I have with solution like teredo is that they are > initiated by the end nodes. The implications are: > 1- all end node needs to understand this protocol > 2- it becomes difficult for the acess router/firewall > to enfore any kind of policy on what traffic is acceptable > A knob that says 'enable IPv6' is just not enough. > We need solutions that enable the user to express easily the same > security policy in v4 and v6. > > Those are the reasons why I think that 'IPv6 connectivity' is > a functionality that has to be provided by an access router > and not by the end hosts. > . > The nice thing about this is that it would work > the same way in case of simple NAT (the exit router > is given a public IPv4 address) and double NAT > (the exit router is given a private address) > but tunneling over UDP. > > v4 Internet > | > | > | > > CPE <--- v4 external address > can be either > v4 acces router global or private > (double NAT) > v4 NAT > v6 access router > (Tunnel Broker client) > | > | > ------------------------------------------ Home lan > | | > Host1 Host2 > > Even better, this could be implemented on a different > box than the actual v4 exit router! > The connection scenario would then be the following: > > v4 Internet > | > | > | > > CPE > v4 acces router > v4 NAT > | > | > ------------------------------------------ Home lan > | | | > v6 access Host1 Host2 > router > (Tunnel Broker client) > > > That way folks who do not want to (or can not)replace their > CPE just have to add another box in the home network to > provide v6 connectivity to the entire home lan. > > Now, as it has been pointed out, this is a typical case > where the access router is a client to a tunnel broker. > The question is what can we do to simplify the tunnel > set-up from the router to the tunnel broker. > If we decide to go that route, a tunnel set up protocol > like the one Marc Blanchet was suggesting now become > a interesting solution > > The configuration of the v6 access router would require: > - providing the IPv4 address (or name) of the IPS Tunnel Broker > - providing the credentials negatiated out of band with the ISP (e.g. > username/passwd) > - specifying the encapsulation mode: IPv6/IPv4 or IPv6/UDP/IPv4 or > IPv6/PPP/IPv4 > - specifying the IPv6 security policy > > Yes, there is manual configuration involved, but I think it > is minimal and not too different to what home users do today > to configure their DSL router. > > - Alain. > > > > > > From owner-v6ops@ops.ietf.org Mon Feb 17 19:56: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 TAA04971 for ; Mon, 17 Feb 2003 19:56:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kw7B-000Nf0-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 17:00:05 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18kw79-000Neh-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 17:00:03 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 26AA546B1; Mon, 17 Feb 2003 20:00:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 20:00:02 -0500 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" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 20:00:01 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B1@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLVElF4csVZkka+T6+/UIXob00hlwB1mUJA From: "Bound, Jim" To: =?iso-8859-1?Q?Antonio_F=2E_G=F3mez_Skarmeta?= , "Alain Durand" Cc: , X-OriginalArrivalTime: 18 Feb 2003 01:00:02.0029 (UTC) FILETIME=[10F941D0:01C2D6E9] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA04971 Good. I am trying to access the CTOs of two of the largest home provider routers now, and internationally. I am getting help from some industry leaders to set up a discussion to hear feasibility of this. It could be we can use the tunnel broker we have specified now and just go do it. I don't want to spend 3 years here discussing it. We can refine it here but maybe as Tony stated it is not a standards issue and I am not sure yet? I think Alain's point and my problem now of to much work for the home clients has to be resolved. /jim > -----Original Message----- > From: Antonio F. Gómez Skarmeta [mailto:skarmeta@dif.um.es] > Sent: Saturday, February 15, 2003 11:53 AM > To: Alain Durand > Cc: Bound, Jim; alh-ietf@tndh.net; v6ops@ops.ietf.org > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > Alain Durand wrote: > > > Jim, > > > > I like your idea. A lot. > > the issue I have with solution like teredo is that they are > initiated > > by the end nodes. The implications are: > > 1- all end node needs to understand this protocol > > 2- it becomes difficult for the acess router/firewall > > to enfore any kind of policy on what traffic is acceptable > > A knob that says 'enable IPv6' is just not enough. > > We need solutions that enable the user to express easily the same > > security policy in v4 and v6. > > > > I will also like this idea. > > > > > > > Those are the reasons why I think that 'IPv6 connectivity' is a > > functionality that has to be provided by an access router > and not by > > the end hosts. . > > Now, as it has been pointed out, this is a typical case > > where the access router is a client to a tunnel broker. > > The question is what can we do to simplify the tunnel > > set-up from the router to the tunnel broker. > > If we decide to go that route, a tunnel set up protocol > > like the one Marc Blanchet was suggesting now become > > a interesting solution > > > > This was something we have been looking within projects > like Euro6IX > and the idea of a set up protocol and an easy to manage tunnel-broker > solution will be really valuable and I think we will be interested in > collaborate > > > -- > ------------------------------------------------------------ > Antonio F. Gómez Skarmeta > Dept. Ingeniería de la Información y las Comunicaciones > Facultad de Informática Universidad de Murcia Apartado 4021 > 30001 Murcia > Telf: +34-968-364607 > fax: +34-968-364151 > > > > From owner-v6ops@ops.ietf.org Mon Feb 17 19:57:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04986 for ; Mon, 17 Feb 2003 19:57:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kw86-000Ni4-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 17:01:02 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18kw84-000Nhr-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 17:01:00 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D0C551A98; Mon, 17 Feb 2003 20:00:58 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 20:00:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 20:00:58 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B2@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLV5Q3tJRmAUzUgSqWUvAOkcE2LFwBBBtMw From: "Bound, Jim" To: "Tim Chown" , "Jeroen Massar" Cc: "Alain Durand" , , X-OriginalArrivalTime: 18 Feb 2003 01:00:58.0779 (UTC) FILETIME=[32CC9EB0:01C2D6E9] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA04986 What are they tweaking? Thanks /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Sunday, February 16, 2003 12:59 PM > To: Jeroen Massar > Cc: 'Alain Durand'; Bound, Jim; alh-ietf@tndh.net; v6ops@ops.ietf.org > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > Which one can do now by simply installing eg the freenet6 > client onto > > one of the existing windows/*nix boxes which will advertise > the IPv6 > > prefix onto the local subnet. The only trick here is to > have the CPE > > forward proto-41 to your v6-gate or using Teredo. Btw 'just have to > > add' is sometimes expensive for some people. > > This is what our IPv6 students tend to do in their homes. It > works nicely, > but still requires a tweak in the DSL router. > > Tim > From owner-v6ops@ops.ietf.org Mon Feb 17 19:58: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 TAA05003 for ; Mon, 17 Feb 2003 19:58:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kw9G-000Nl5-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 17:02:14 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18kw98-000Nkn-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 17:02:06 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id ACD3A4A76; Mon, 17 Feb 2003 20:02:03 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 20:02:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 20:02:03 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B3@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLV7MHBvT43TN7IQaCs+2jfPqMQIAA/HqyA From: "Bound, Jim" To: "JORDI PALET MARTINEZ" , "Jeroen Massar" , Cc: "Alain Durand" , X-OriginalArrivalTime: 18 Feb 2003 01:02:03.0599 (UTC) FILETIME=[596F5DF0:01C2D6E9] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA05003 So this is method 1 and working. /jim > -----Original Message----- > From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] > Sent: Sunday, February 16, 2003 1:55 PM > To: Jeroen Massar; v6ops@ops.ietf.org > Cc: 'Alain Durand'; Bound, Jim; alh-ietf@tndh.net > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > I've observed, that in most of the cases, a NAT box forwards > proto-41 as any other UPD or TCP traffic, so I can use my > IPv6 elsewhere ... In my home, hotels, conferences, ... > > In my case never requires changing my DSL router > configuration, but I agree that if the hotel is filtering > proto-41, I will not be able to change it either ;-) > > Regards, > Jordi > > ----- Original Message ----- > From: "Tim Chown" > To: "Jeroen Massar" > Cc: "'Alain Durand'" ; "'Bound, Jim'" > ; ; > Sent: Sunday, February 16, 2003 6:58 PM > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > > > Which one can do now by simply installing eg the freenet6 client > > > onto one of the existing windows/*nix boxes which will > advertise the > > > IPv6 prefix onto the local subnet. The only trick here is to have > > > the CPE forward proto-41 to your v6-gate or using Teredo. > Btw 'just > > > have to add' is sometimes expensive for some people. > > > > This is what our IPv6 students tend to do in their homes. It works > > nicely, but still requires a tweak in the DSL router. > > > > Tim > > > > ********************************* > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Pre-register at: > http://www.ipv6-es.com > Interested in participating or sponsoring ? > Contact us at ipv6@consulintel.es > > > From owner-v6ops@ops.ietf.org Mon Feb 17 19:59: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 TAA05017 for ; Mon, 17 Feb 2003 19:59:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kw9r-000No1-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 17:02:51 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18kw9o-000Nno-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 17:02:48 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3B131474E; Mon, 17 Feb 2003 20:02:48 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 20:02:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 20:02:47 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B4@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLV78w0PjC69EowTBa/4yiYvpn0jgA+ZdkQ From: "Bound, Jim" To: "Jeroen Massar" , "JORDI PALET MARTINEZ" , Cc: "Alain Durand" , X-OriginalArrivalTime: 18 Feb 2003 01:02:48.0154 (UTC) FILETIME=[73FDEBA0:01C2D6E9] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA05017 If we have tunnel brokers we don 't need teredo right? That's my take now. /jim > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org] > Sent: Sunday, February 16, 2003 2:16 PM > To: 'JORDI PALET MARTINEZ'; v6ops@ops.ietf.org > Cc: 'Alain Durand'; Bound, Jim; alh-ietf@tndh.net > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] wrote: > > > I've observed, that in most of the cases, a NAT box forwards > > proto-41 as any other UPD or TCP traffic, so I can use my IPv6 > > elsewhere ... In my home, hotels, conferences, ... > > I wonder to which box (IPv4) behind the NAT it is forwarding > the proto-41 packets then. Unless you configured a > default/unmatched target ofcourse. But then you already > configured it correctly ;) > > > In my case never requires changing my DSL router > > configuration, but I agree that if the hotel is filtering > > proto-41, I will not be able to change it either ;-) > > If you are in a hotel you won't have any access to the CPE > either. And the CPE won't know what to do with the proto-41 > packets when it reaches it then. But that's why we've got > Teredo. Though one can always ask himself if it where a > policy decision for not having IPv6 in their network but > let's not go there... > > Greets, > Jeroen > > > ----- Original Message ----- > > From: "Tim Chown" > > To: "Jeroen Massar" > > Cc: "'Alain Durand'" ; "'Bound, Jim'" > > ; ; > > Sent: Sunday, February 16, 2003 6:58 PM > > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > > > > > Which one can do now by simply installing eg the > freenet6 client > > > > onto one of the existing windows/*nix boxes which will > advertise > > > > the IPv6 prefix onto the local subnet. The only trick > here is to > > > > have the CPE forward proto-41 to your v6-gate or using > Teredo. Btw > > > > 'just have to add' is sometimes expensive for some people. > > > > > > This is what our IPv6 students tend to do in their homes. > > It works nicely, > > > but still requires a tweak in the DSL router. > > > > > > Tim > > From owner-v6ops@ops.ietf.org Mon Feb 17 20:03:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05128 for ; Mon, 17 Feb 2003 20:03:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kwDb-000NzE-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 17:06:43 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18kwDX-000Nz1-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 17:06:39 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C242856CF; Mon, 17 Feb 2003 20:06:38 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 20:06:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Deployment of Dual Stack with Applications Date: Mon, 17 Feb 2003 20:06:38 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B5@tayexc13.americas.cpqcorp.net> Thread-Topic: Deployment of Dual Stack with Applications Thread-Index: AcLWSUMHbH4YlHSvR9ONCCIT+o4ufwAoKNpQ From: "Bound, Jim" To: "Keith Moore" Cc: X-OriginalArrivalTime: 18 Feb 2003 01:06:38.0498 (UTC) FILETIME=[FD49A020:01C2D6E9] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA05128 This is a valid point. I view it as an engineering trade-off users have to make given what you say for sure. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, February 17, 2003 12:53 AM > To: Bound, Jim > Cc: moore@cs.utk.edu; v6ops@ops.ietf.org > Subject: Re: Deployment of Dual Stack with Applications > > > > > How are the apps ported and at what point on the > suppliers boxes? > > there is no simple answer to this question. but changing the > behavior of existing APIs to try to hide IPv6 from apps will > harm interoperability. > > the goal should be to facilitate a more capable Internet > supporting more capable apps, not merely to get apps to > change packet formats whether they know about it or not. > apps won't get more capable by being unaware of IPv6. > > Keith > From owner-v6ops@ops.ietf.org Mon Feb 17 20:56: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 UAA06096 for ; Mon, 17 Feb 2003 20:56:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kx2G-0000L9-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 17:59:04 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 18kx2D-0000Kx-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 17:59:01 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 17 Feb 2003 17:59:00 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Feb 2003 17:59:00 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Mon, 17 Feb 2003 17:59:03 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 17 Feb 2003 17:58:50 -0800 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.3765.0); Mon, 17 Feb 2003 17:59:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 17:59:06 -0800 Message-ID: Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTswaIb3XlCw72TviJFIVXZGBYdwDNMQVQAAI46AA= From: "Christian Huitema" To: "Bound, Jim" , , X-OriginalArrivalTime: 18 Feb 2003 01:59:00.0974 (UTC) FILETIME=[4E5968E0:01C2D6F1] X-Spam-Status: No, hits=0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA06096 > > > I will build different solution other than Teredo. Teredo is > > > to complex and breaks a 2 rules for me I use as network > > > engineer/architect for v6ops solutions. 1) We should NEVER > > > use or access port numbers to get things done but only use > > > the IP header whereever possible. > > > > Well it is arguable that teredo violates this rule, since the > > origin application port is not referenced. The fact that it > > uses the available port id bits in the IPv4-UDP encapsulation > > header to construct the IPv6 address is really a function of > > the application in the encapsulating endpoint. > > It has to work with more than the IP header. Uh? The Teredo routing works strictly with the IPv6 header. If you send a packet to a Teredo relay, the relay will not look at anything besides that header. The encapsulation runs over UDP, but you may observe that many encapsulation protocol run with "more than IP" -- L2TP, for example, runs over UDP. > I am fine with client/server apps that run across many nets. I am not > fine with transition solutions that try to attempt work around NAT. Whether you cross the NAT using Teredo or using a tunnel does not change anything to the fact that you "working around the NAT". -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Feb 17 21: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 VAA06170 for ; Mon, 17 Feb 2003 21:01:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kx86-0000c2-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 18:05:06 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 18kx84-0000bo-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 18:05:04 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Mon, 17 Feb 2003 18:05:07 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Feb 2003 18:05:03 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 17 Feb 2003 18:05:06 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 17 Feb 2003 18:04:47 -0800 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.3765.0); Mon, 17 Feb 2003 18:05:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 18:05:10 -0800 Message-ID: Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLV78w0PjC69EowTBa/4yiYvpn0jgA+ZdkQAAIMGWA= From: "Christian Huitema" To: "Bound, Jim" , "Jeroen Massar" , "JORDI PALET MARTINEZ" , Cc: "Alain Durand" , X-OriginalArrivalTime: 18 Feb 2003 02:05:03.0513 (UTC) FILETIME=[26707890:01C2D6F2] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06170 > If we have tunnel brokers we don't need teredo right? That's my take > now. We have debated that many times. The issue is economics, and more precisely the trade-off between how much software you write and how much bandwidth you require from the tunnel server. A Teredo host only uses the Internet bandwidth that was already paid by its owner to the local ISP; a tunnel host uses that bandwidth, plus an equal amount at the end of the tunnel. That may be OK if the tunnel is provided by the same ISP that provides the user connection; but in all other cases, the user ends up with having the equivalent of two ISP subscriptions. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Feb 17 21:45:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07069 for ; Mon, 17 Feb 2003 21:45:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kxoU-00030T-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 18:48:54 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18kxoS-00030H-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 18:48:52 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A2276579D; Mon, 17 Feb 2003 21:48:51 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 21:48:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 21:48:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240F05@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTswaIb3XlCw72TviJFIVXZGBYdwDNMQVQAAI46AAAAY23sA== From: "Bound, Jim" To: "Christian Huitema" , , X-OriginalArrivalTime: 18 Feb 2003 02:48:51.0589 (UTC) FILETIME=[44E50B50:01C2D6F8] X-Spam-Status: No, hits=0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA07069 > > It has to work with more than the IP header. > > Uh? The Teredo routing works strictly with the IPv6 header. > If you send a packet to a Teredo relay, the relay will not > look at anything besides that header. The encapsulation runs > over UDP, but you may observe that many encapsulation > protocol run with "more than IP" -- L2TP, for example, runs over UDP. There are many parts to Teredo that are not just a simple ecap (e.g. bubbles, udp refresh to NAT). I am not against Teredo and I believe it has its case and use. From -08. ---------------------------------------------- 3.2.1 When to use Teredo? Teredo is designed to robustly enable IPv6 traffic through NATs, and the price of robustness is a reasonable amount of overhead, due to UDP encapsulation and transmission of bubbles. Nodes that want to connect to the IPv6 Internet SHOULD only use the Teredo service as a "last resort" option: they SHOULD prefer using direct IPv6 connectivity if it is locally available or if it is provided by a 6to4 router co-located with the local NAT, and they SHOULD prefer using the less onerous "6to4" encapsulation if they can use a global IPv4 address. ------------------------------------------------- It does have overhead. I would just add that in addition to 6to4 Tunnel Brokers should be listed above too. Then the market will decide which one to use. But to compare Teredo with a simple encap at a DSL router of an IPv6 packet to get it to a Tunnel broker that was established is no way the overhead of Teredo. What I say also should not discount Teredo and I supported and still support it as a standards track document. I believe it will take to long and too complex for initial IPv6 deployment and looking for a more simple solution. You sent me mail that we care about deployment. I say exactly. I read ahead and will respond to your economic case in that mail. > > I am fine with client/server apps that run across many > nets. I am not > > fine with transition solutions that try to attempt work around NAT. > > Whether you cross the NAT using Teredo or using a tunnel does > not change anything to the fact that you "working around the NAT". I was referring to the cost and single point of failure in depending on a client server model. Not working around only NAT. Bad prefix to may last statement. I don't like ALGs either. But willing now to compromise for Tunnel Brokers for IPv6 deployment. My main thinking is that the client simply sends IPv6 packets after setting up its tunnel end points to communicate with IPv6 either at the DSL router or the POP. I want to see a fix suggestion for the DSL router and POP. /jim From owner-v6ops@ops.ietf.org Mon Feb 17 21:51: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 VAA07127 for ; Mon, 17 Feb 2003 21:51:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kxuo-0003Kx-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 18:55:26 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 18kxum-0003Kk-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 18:55:24 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 17 Feb 2003 18:55:26 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Feb 2003 18:55:23 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Mon, 17 Feb 2003 18:55:14 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 17 Feb 2003 18:55:21 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Mon, 17 Feb 2003 18:55:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 18:55:34 -0800 Message-ID: Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTswaIb3XlCw72TviJFIVXZGBYdwDNMQVQAAI46AAAAY23sAAAaLlw From: "Christian Huitema" To: "Bound, Jim" , , X-OriginalArrivalTime: 18 Feb 2003 02:55:21.0162 (UTC) FILETIME=[2D192AA0:01C2D6F9] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA07127 > I would just add that in addition to 6to4 Tunnel Brokers should be > listed above too. Then the market will decide which one to use. In fact, we can probably adapt the Teredo spec so the same code can be used for configured tunnels and for dynamic Teredo behavior. > But to compare Teredo with a simple encap at a DSL router of an IPv6 > packet to get it to a Tunnel broker that was established is no way the > overhead of Teredo. I was only referring to the point that not all encapsulations are directly over IP. > What I say also should not discount Teredo and I supported and still > support it as a standards track document. I believe it will take to > long and too complex for initial IPv6 deployment and looking for a more > simple solution. You sent me mail that we care about deployment. I say > exactly. In the IETF, we used to deal with arguments of complexity by considering running code, rather than by theoretical debates. We have running code for Teredo. I have used the code myself. I guess this meet at least 1/2 of the requirements -- the other 1/2 would be to prove Interop with an independent implementation. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Feb 17 22:05: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 WAA07345 for ; Mon, 17 Feb 2003 22:05:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ky7C-000424-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 19:08:14 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18ky79-00041s-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 19:08:11 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3BC694924; Mon, 17 Feb 2003 22:08:10 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 22:08:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 22:08:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240F06@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLV78w0PjC69EowTBa/4yiYvpn0jgA+ZdkQAAIMGWAAAaz+YA== From: "Bound, Jim" To: "Christian Huitema" , "Jeroen Massar" , "JORDI PALET MARTINEZ" , Cc: "Alain Durand" , X-OriginalArrivalTime: 18 Feb 2003 03:08:10.0160 (UTC) FILETIME=[F774F300:01C2D6FA] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA07345 > > > If we have tunnel brokers we don't need teredo right? > That's my take > > now. Clarification. I mean't for initial deployment jump start. Which was the context of my whole thread here. I can envision many reasons for Teredo. > > We have debated that many times. The issue is economics, and > more precisely the trade-off between how much software you > write and how much bandwidth you require from the tunnel > server. A Teredo host only uses the Internet bandwidth that > was already paid by its owner to the local ISP; a tunnel host > uses that bandwidth, plus an equal amount at the end of the > tunnel. That may be OK if the tunnel is provided by the same > ISP that provides the user connection; but in all other > cases, the user ends up with having the equivalent of two ISP > subscriptions. As far as debating issues many times. That means nothing to me. We have debated so many issues so many times on so many topics in the IETF. Are you watching the multi6 email exchange, as one of many examples :--). I agree with your trade off logic for engineering above. On Teredo bandwidth. But each ISP would have to have a Teredo Server? -------------------------------------------------- 2.3 Teredo Server A node that has access to the IPv4 Internet through a globally routable address, and that is used as a helper to provide IPv6 connectivity to Teredo clients. --------------------------------------------------------------- So each ISP would need one? And: --------------------------------------------------------------- 3.2.3 Minimal load on servers During the peak of the transition, there will be a requirement to deploy a large number of servers throughout the Internet. Minimizing the load on the server is a good way to facilitate this deployment. To achieve this goal, servers should be as stateless as possible, and they should also not be required to carry any more traffic than necessary. To achieve this objective, we request that servers only enable the packet exchange between clients, but do not carry the actual data packets: these packets will have to be exchanged directly between the Teredo clients, or through a destination- selected relay for exchanges between Teredo clients and other IPv6 clients. ---------------------------------------------------------------------- Seems like it will require a lot of servers too during peak. What I am driving is lets do it without all these servers before the "peak" (defined as in the above from Teredo). Not that Teredo does not have purpose. Contrary to many opinions most average home users do have one ISP and many new users are going be in an economic condition that does not warrant support for two ISPs. Most non technical/computer professionals I know do not have two ISPs so I question this fact stated and have to see real polls and analysis. But even if true the Tunnel Broker is cost effective for that case. Regarding use of the end tunnel I am not sure I agree with this cost metric, but the point is if it works then use it, and it harms nothing. What I believe is that a Tunnel Broker strategy can assist to get IPv6 deployed for home use far faster than use of Teredo for initial deployment and use. That in turn gives the ISP and other Providers a means to request their IPv6 prefixes and use their entrepreneurial skills with IPv6 for their end users. If they all have to deploy Teredo and other complex schemes they will wait longer to get started. Now I envision Teredo use in IPv4 and IPv6 coexistence for Savy Home Users, Small Businesses, Enterprise Intranets that are NAT'd, and a dual stack path around IPv4 NAT in some mission critical environments where as the Teredo draft states there is no other choice. It is an important tool for IPv4 and IPv6 coexistence. I believe for Home Use we need something very simple that is a no brainer to understand and very simple for operations at the ISP and operations by the Home User. Regards, /jim From owner-v6ops@ops.ietf.org Mon Feb 17 22:08:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07392 for ; Mon, 17 Feb 2003 22:08:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kyAu-0004D3-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 19:12:04 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18kyAs-0004Co-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 19:12:02 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 274995567; Mon, 17 Feb 2003 22:12:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 22:12:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Mon, 17 Feb 2003 22:12:01 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07BC@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTswaIb3XlCw72TviJFIVXZGBYdwDNMQVQAAI46AAAAY23sAAAaLlwAACpXmA= From: "Bound, Jim" To: "Christian Huitema" , , X-OriginalArrivalTime: 18 Feb 2003 03:12:02.0018 (UTC) FILETIME=[81A7AC20:01C2D6FB] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA07392 > > I would just add that in addition to 6to4 Tunnel Brokers should be > > listed above too. Then the market will decide which one to use. > > In fact, we can probably adapt the Teredo spec so the same > code can be used for configured tunnels and for dynamic > Teredo behavior. I am thinking like that too but have not broken tbrough it this is clearly an idea I think worth pursuing. > > > But to compare Teredo with a simple encap at a DSL router > of an IPv6 > > packet to get it to a Tunnel broker that was established is > no way the > > overhead of Teredo. > > I was only referring to the point that not all encapsulations > are directly over IP. ACK. > > > What I say also should not discount Teredo and I supported > and still > > support it as a standards track document. I believe it > will take to > > long and too complex for initial IPv6 deployment and looking for a > more > > simple solution. You sent me mail that we care about deployment. I > say > > exactly. > > In the IETF, we used to deal with arguments of complexity by > considering running code, rather than by theoretical debates. > We have running code for Teredo. I have used the code myself. > I guess this meet at least 1/2 of the requirements -- the > other 1/2 would be to prove Interop with an independent > implementation. I agree this is a very very good argument. I want to do the same but I need find DSL Router folks to make it work. We both have done manual config and 6to4. But I am wondering if some kind of very very simple code patch can make it so the DSL router can assist with the process. /jim > > -- Christian Huitema > From owner-v6ops@ops.ietf.org Mon Feb 17 22:25:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07517 for ; Mon, 17 Feb 2003 22:25:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kyQx-00052A-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 19:28:39 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18kyQt-00051o-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 19:28:35 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA06400 for ; Mon, 17 Feb 2003 19:27:22 -0800 (PST) Message-Id: <5.1.0.14.2.20030217222006.0366f1e8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Feb 2003 22:22:13 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt In-Reply-To: <5.1.0.14.2.20030217115420.036575f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk To clarify, this last call will remain open through Sunday, March 2nd, 2003. At 12:04 PM 2/17/2003 -0500, Margaret Wasserman wrote: >Hi All, > >This is a WG Last Call for comments on sending the 3GPP scenarios >document to the IESG for consideration as an Informational RFC: > >Title: Transition Scenarios for 3GPP Networks >Filename: draft-ietf-v6ops-3gpp-cases-02.txt >Editor: J. Soininen >Date: January 2003 > >The document can be found at: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt From owner-v6ops@ops.ietf.org Mon Feb 17 22:25: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 WAA07531 for ; Mon, 17 Feb 2003 22:25:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kyR4-00053Q-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 19:28:46 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18kyQu-00051y-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 19:28:36 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA06408 for ; Mon, 17 Feb 2003 19:27:23 -0800 (PST) Message-Id: <5.1.0.14.2.20030217222219.03612f08@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Feb 2003 22:22:55 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-Reply-To: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk THis last call will also remain open through Sunday, March 2nd, 2003. At 12:11 PM 2/17/2003 -0500, Margaret Wasserman wrote: >Hi All, > >This is a WG Last Call for comments on sending the Unmanaged >Networks scenarios document to the IESG for consideration as >an Informational RFC: > >Title: Unmanaged Networks IPv6 Transition Scenarios >Filename: draft-ietf-v6ops-unman-scenarios-00.txt >Authors: C. Huitema, R. Austein, R. van der Pol >Date: January 10, 2003 > >The document can be found at: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt From owner-v6ops@ops.ietf.org Mon Feb 17 22:26: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 WAA07554 for ; Mon, 17 Feb 2003 22:26:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kySP-0005DU-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 19:30:09 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18kySL-0005D5-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 19:30:05 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CB36A4A82; Mon, 17 Feb 2003 22:30:01 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 22:30:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Date: Mon, 17 Feb 2003 22:30:01 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07BF@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Thread-Index: AcLWqNu06ZWvqXXZRTeLjxnL3fGk6QAVQKog From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 18 Feb 2003 03:30:01.0386 (UTC) FILETIME=[050228A0:01C2D6FE] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA07554 I believe this is ready go to the IESG. But put the table of contents up front :---) /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, February 17, 2003 12:11 PM > To: v6ops@ops.ietf.org > Subject: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt > > > > > Hi All, > > This is a WG Last Call for comments on sending the Unmanaged > Networks scenarios document to the IESG for consideration as > an Informational RFC: > > Title: Unmanaged Networks IPv6 Transition Scenarios > Filename: draft-ietf-v6ops-unman-scenarios-00.txt > Authors: C. Huitema, R. Austein, R. van der Pol > Date: January 10, 2003 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-sce narios-00.txt Abstract In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks. Please review this document carefully, and send your feedback to the list, indicating 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 document will not be send to the IESG. Thanks, Margaret, Itojun and Bob v6ops WG Chairs From owner-v6ops@ops.ietf.org Mon Feb 17 23:57: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 XAA09193 for ; Mon, 17 Feb 2003 23:57:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18kzr8-000A4l-00 for v6ops-data@psg.com; Mon, 17 Feb 2003 20:59:46 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18kzr6-000A4Z-00 for v6ops@ops.ietf.org; Mon, 17 Feb 2003 20:59:44 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7E85A54A3; Mon, 17 Feb 2003 23:59:43 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Feb 2003 23:59:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Mon, 17 Feb 2003 23:59:42 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C07C8@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLWqP5wvIQVCFimS9+D//NvVLXIzQAYWUxw From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 18 Feb 2003 04:59:43.0404 (UTC) FILETIME=[8CF0EEC0:01C2D70A] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA09193 I believe this is ready for IESG review. Would love to change IMS but that's the way it goes :--) /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, February 17, 2003 12:05 PM > To: v6ops@ops.ietf.org > Subject: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt > > > > > Hi All, > > This is a WG Last Call for comments on sending the 3GPP > scenarios document to the IESG for consideration as an > Informational RFC: > > Title: Transition Scenarios for 3GPP Networks > Filename: draft-ietf-v6ops-3gpp-cases-02.txt > Editor: J. Soininen > Date: January 2003 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt > > Abstract > > This document describes different scenarios in Third Generation > Partnership Project (3GPP) defined packet network, i.e. General > Packet Radio Service (GPRS) that would need IP version 6 and IP > version 4 transition. The focus of this document is on > the scenarios > where the User Equipment (UE) connects to nodes in other networks, > e.g. in the Internet. GPRS network internal transition scenarios, > i.e. between different GPRS elements in the network, are > out of scope > of this document. > > The purpose of the document is to list the scenarios for further > discussion and study. > > Since this is the first WG last call that we have had in the > v6ops WG, we would like to remind you of the process that we > discussed for WG last calls when we started this WG. > > The WG Last Call is a final check that the WG has rough > consensus to advance the document to the IESG. Advancing a > document to the IESG indicates that the WG believes that this > document is both technically sound and useful. It also > indicates that we believe that the document meets all of the > requirements for publication as an RFC. > > To pass WG last call, this document must be reviewed and > actively supported by a significant number of people, > including experts in all applicable areas, or it will not be > sent to the IESG. > > Silence does NOT indicate consent during this phase. > > So, please review this document carefully, and send your > feedback to the list, indicating whether or not you believe > that this document is ready to go to the IESG. Unless > sufficient support is demonstrated on the list, the document > will not be send to the IESG. > > Thanks, > Margaret, Itojun and Bob > v6ops WG Chairs > > > > From owner-v6ops@ops.ietf.org Tue Feb 18 05:16:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24079 for ; Tue, 18 Feb 2003 05:16:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18l4pJ-000O1n-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 02:18:13 -0800 Received: from moebius2.space.net ([195.30.1.100]) by psg.com with smtp (Exim 3.36 #1) id 18l4pE-000O1a-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 02:18:08 -0800 Received: (qmail 63692 invoked by uid 1007); 18 Feb 2003 10:18:00 -0000 Date: Tue, 18 Feb 2003 11:18:00 +0100 From: Gert Doering To: "Bound, Jim" Cc: =?iso-8859-1?Q?Antonio_F=2E_G=F3mez_Skarmeta?= , Alain Durand , alh-ietf@tndh.net, v6ops@ops.ietf.org Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Message-ID: <20030218111800.N15927@Space.Net> References: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B1@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B1@tayexc13.americas.cpqcorp.net>; from Jim.Bound@hp.com on Mon, Feb 17, 2003 at 08:00:01PM -0500 X-NCC-RegID: de.space X-Spam-Status: No, hits=-5.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Mon, Feb 17, 2003 at 08:00:01PM -0500, Bound, Jim wrote: > Good. I am trying to access the CTOs of two of the largest home > provider routers now, and internationally. That's a very good thing. I would prefer, by far, if they would just implement plain & native IPv6 in their boxes. At least over herere (EU region), a fair lot of ISPs are already offering native IPv6 connectivity to their end users, and the main problem is that most of the CPE boxes don't implement IPv6 at all yet. Tunnels on the CPE routers are a nice transition help, but native is much better - and less work to implement for the vendors. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56285 (56029) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Tue Feb 18 11:36: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 LAA01393 for ; Tue, 18 Feb 2003 11:36:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lAkZ-000Cm4-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 08:37:43 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 18lAkU-000Ckx-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 08:37:38 -0800 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 18 Feb 2003 08:37:33 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Feb 2003 08:37:34 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Feb 2003 08:37:34 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Feb 2003 08:37:33 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 18 Feb 2003 08:37:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Clarification on Teredo (was: IPv6 Home Use to stimulate deployment over IPv4-NAT) Date: Tue, 18 Feb 2003 08:36:36 -0800 Message-ID: Thread-Topic: Clarification on Teredo (was: IPv6 Home Use to stimulate deployment over IPv4-NAT) Thread-Index: AcLV78w0PjC69EowTBa/4yiYvpn0jgA+ZdkQAAIMGWAAAaz+YAAcQiNQ From: "Christian Huitema" To: "Bound, Jim" Cc: X-OriginalArrivalTime: 18 Feb 2003 16:37:33.0026 (UTC) FILETIME=[092E3C20:01C2D76C] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01393 > On Teredo bandwidth. But each ISP would have to have a Teredo Server? > > -------------------------------------------------- > 2.3 Teredo Server > > A node that has access to the IPv4 Internet through a globally > routable address, and that is used as a helper to provide IPv6 > connectivity to Teredo clients. > --------------------------------------------------------------- > > So each ISP would need one? Actually, no. The Teredo design allows for deployment of "public servers", in a Hotmail-like fashion. The host chooses a Teredo server, but that server can be anywhere on the Internet, provided it has global IPv4 and IPv6 connectivity. The deployment requirements are pretty simple: there must be at least one Teredo server on the Internet; and the "Teredo correspondent nodes" must have access to a Teredo relay. Deploying a Teredo relay is pretty easy: it requires only the ability to send UDP-IPv4 packets, and the IPv4-UDP "associations" are always initiated by the relay; this pretty much means that every IPv4 host that it not behind a corporate firewall can deploy its own "host specific" relay. However, having IPv6 ISP deploy relays would indeed help. > --------------------------------------------------------------- > 3.2.3 Minimal load on servers > > Seems like it will require a lot of servers too during peak. What I am > driving is lets do it without all these servers before the "peak" > (defined as in the above from Teredo). Not that Teredo does not have > purpose. If you read draft-08, you will observe that the server is only used for a tiny fraction of the traffic: get an IP address through an RS/RA exchange, resolve the address of a peer by routing a bubble. We have performed simulations based on the profiles of key applications, and under most estimates the dominant part of the server traffic is the periodic renewal of the NAT mapping, normally every 1.5 minute. This results on an average traffic load of less than 20 bps per active client. A single PC based server can easily support 100,000 active clients. > I believe for Home Use we need something very simple that is a no > brainer to understand and very simple for operations at the ISP and > operations by the Home User. We designed Teredo to be basically transparent to the home user. I believe that deploying Teredo is actually simpler than deploying tunnel brokers. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Feb 18 11:44:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01638 for ; Tue, 18 Feb 2003 11:44:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lAuA-000DH7-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 08:47:38 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #1) id 18lAu7-000DG3-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 08:47:35 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 18 Feb 2003 08:47:47 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Feb 2003 08:47:32 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Feb 2003 08:47:27 -0800 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.3765.0); Tue, 18 Feb 2003 08:47:27 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Feb 2003 08:47:27 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 18 Feb 2003 08:47:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Tue, 18 Feb 2003 08:47:26 -0800 Message-ID: Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTswaIb3XlCw72TviJFIVXZGBYdwDNMQVQAAI46AAAAY23sAAAaLlwAACpXmAAHDNLEA== From: "Christian Huitema" To: "Bound, Jim" Cc: X-OriginalArrivalTime: 18 Feb 2003 16:47:26.0720 (UTC) FILETIME=[6B0CC000:01C2D76D] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01638 > > In the IETF, we used to deal with arguments of complexity by > > considering running code, rather than by theoretical debates. > > We have running code for Teredo. I have used the code myself. > > I guess this meet at least 1/2 of the requirements -- the > > other 1/2 would be to prove Interop with an independent > > implementation. > > I agree this is a very very good argument. I want to do the same but I > need find DSL Router folks to make it work. We both have done manual > config and 6to4. But I am wondering if some kind of very very simple > code patch can make it so the DSL router can assist with the process. Teredo is not meant to be implemented in the DSL router: it is a single host solution. The only requirement of the DSL router is that it provides "reasonable" support for UDP-IPv4; our tests show that this is the case for the overwhelming majority of the small routers available on the US market. The correction needed by the other routers mostly amount to bug fixes: a slight modification of the "5-tuple" mapping algorithm, and a requirement to not do anything stupid after receiving an ICMP "unreachable" error message. The same fixes are also needed to enable the STUN scenarios that are used by IPv4/VoIP, so I expect market pressure will lead the home router manufacturers to "do the right thing." If these home router manufacturers want to help deploy IPv6, then the obvious requirement is to support 6to4, to allow configured tunnels, and to also allow relaying of an ISP native IPv6 service. This is very much what we are describing in the "unmanaged networks" scenarios. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Feb 18 12:43: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 MAA02839 for ; Tue, 18 Feb 2003 12:43:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lBnf-000GEV-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 09:44:59 -0800 Received: from atlas.fccn.pt ([193.136.7.1]) by psg.com with smtp (Exim 3.36 #1) id 18lBnb-000GEF-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 09:44:55 -0800 Received: (qmail 29066 invoked by uid 2502); 18 Feb 2003 17:44:52 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.214131 secs); 18/02/2003 17:44:52 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2003 17:44:52 -0000 Date: Tue, 18 Feb 2003 17:44:51 +0000 (WET) From: Carlos Friacas To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT In-Reply-To: <084a01c2d5f2$8998f560$870a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.6 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello. Last week you showed at a conference a v6 tunnel over v4, when you had native v6. The roundtrip times you showed on a traceroute left some people in the audience yellow-faced... One thing to have in mind in the future *for you*: check if you have native v6 available. One thing to have in mind *for me* in the future: filter port 41 on a dual stack interface, to avoid the kind of "stunts" people sometimes do... :-) Regards, ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 From owner-v6ops@ops.ietf.org Tue Feb 18 12:58:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03203 for ; Tue, 18 Feb 2003 12:58:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lC3w-000HCU-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 10:01:48 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18lC3t-000HBA-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 10:01:45 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Tue, 18 Feb 2003 19:03:25 +0100 Message-ID: <15a101c2d778$07880fc0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Tue, 18 Feb 2003 19:03:23 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_RELAYS_ORDB_ORG, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Carlos, As you can imagine, I did a tunnel only because the native IPv6 was not working for me. I learn, as a first lesson, to see if there is a RA in the network before I do my own one ! I even asked, and they told me that ONLY v4 was available in that network. In fact I show to some people from the organization that curiously, v4 was not working also. I got an address assigned by DHCP, but no way to use web or pop3/smtp. Some other people experienced the same problem, so I guess it wasn't my own computer. So I tried my own tunnel, and it worked. If you filter port 41, that's still fine for me (unless you mean proto-41). Obviously the round-trip was not good, but it was due to the network configuration itself, as I was doing a ping to my tunnel end. If I ping with v4, the round trip must be almost the same ! Anyway, I tried to show that even when IPv4 is not working, I can use IPv6, and that's was a real situation ... I prefer to have a slower connectivity that _nothing_. Clearly we must improve this, but this is what we are working now, here in this group. I prefer to show the people the true, not just telling them everything is wonderful and we have nothing to do. I'm sure other people is in the same side. Regards, Jordi ----- Original Message ----- From: "Carlos Friacas" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, February 18, 2003 6:44 PM Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > Hello. > > Last week you showed at a conference a v6 tunnel over v4, when you had > native v6. > > The roundtrip times you showed on a traceroute left some people in the > audience yellow-faced... > > One thing to have in mind in the future *for you*: check if you have > native v6 available. > > One thing to have in mind *for me* in the future: filter port 41 on a dual > stack interface, to avoid the kind of "stunts" people sometimes do... :-) > > > Regards, > > ./Carlos > "Networking is fun!" > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Tue Feb 18 13:36: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 NAA04189 for ; Tue, 18 Feb 2003 13:36:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lCer-000JEt-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 10:39:57 -0800 Received: from atlas.fccn.pt ([193.136.7.1]) by psg.com with smtp (Exim 3.36 #1) id 18lCej-000JCo-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 10:39:49 -0800 Received: (qmail 1489 invoked by uid 2502); 18 Feb 2003 18:39:47 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.114713 secs); 18/02/2003 18:39:47 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2003 18:39:47 -0000 Date: Tue, 18 Feb 2003 18:39:47 +0000 (WET) From: Carlos Friacas To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT In-Reply-To: <15a101c2d778$07880fc0$870a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Feb 2003, JORDI PALET MARTINEZ wrote: > Hi Carlos, Hello. > As you can imagine, I did a tunnel only because the native IPv6 was not working for me. I learn, as a first lesson, to see if there > is a RA in the network before I do my own one ! Perhaps your problem was there were several on the link. :-) Miguel from University of Evora noticed that while he was trying to bring the Isabel connection up. > I even asked, and they told me that ONLY v4 was available in that network. Sorry. :-( Probably you were misinformed. There was a note on the reg.desk > In fact I show to some people from the organization that curiously, v4 was not working also. I got an address assigned by DHCP, but > no way to use web or pop3/smtp. Some other people experienced the same problem, so I guess it wasn't my own computer. This was tested ok by our local network folks, that installed the AP, and nobody else complained. Strange at least. > So I tried my own tunnel, and it worked. If you filter port 41, that's still fine for me (unless you mean proto-41). typo... s/port/proto :-) > Obviously the round-trip was not good, but it was due to the network configuration itself, as I was doing a ping to my tunnel end. > If I ping with v4, the round trip must be almost the same ! If you were not able to do simple web browsing over v4, you were very lucky to be able to do v6 over v4. So this proofs v4 was working, no? That LAN is becoming a "case-study"... :-) > Anyway, I tried to show that even when IPv4 is not working, I can use IPv6, and that's was a real situation ... I prefer to have a > slower connectivity that _nothing_. If v4 was not working you couldnt have found your other tunnel end magically... :-) > Clearly we must improve this, but this is what we are working now, here > in this group. > > I prefer to show the people the true, not just telling them everything > is wonderful and we have nothing to do. I'm sure other people > is in the same side. The truth about that particular meeting is that nobody showed up with *any* traffic graphic, even a graphic populated with data generated by test-traffic not users. That was really a deception for me. Another deception was not seing the ISABEL aplication working. I had spent some hours in the previous days troubleshooting ipv6 bgp4+ with people from PTInovacao in order to setup the connectivity to euro6ix, and at the end it was not possible to bring the application up due to a congestion in Madrid. It was a real frustration and it stopped us to show something really running on top of v6. :-( Regards. > Regards, > Jordi > > ----- Original Message ----- > From: "Carlos Friacas" > To: "JORDI PALET MARTINEZ" > Cc: > Sent: Tuesday, February 18, 2003 6:44 PM > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > Hello. > > > > Last week you showed at a conference a v6 tunnel over v4, when you had > > native v6. > > > > The roundtrip times you showed on a traceroute left some people in the > > audience yellow-faced... > > > > One thing to have in mind in the future *for you*: check if you have > > native v6 available. > > > > One thing to have in mind *for me* in the future: filter port 41 on a dual > > stack interface, to avoid the kind of "stunts" people sometimes do... :-) > > > > > > Regards, > > > > ./Carlos > > "Networking is fun!" > > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > > > > ********************************* > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Pre-register at: > http://www.ipv6-es.com > Interested in participating or sponsoring ? > Contact us at ipv6@consulintel.es > > > ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 From owner-v6ops@ops.ietf.org Tue Feb 18 13:58: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 NAA05128 for ; Tue, 18 Feb 2003 13:58:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lCz8-000KZ7-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 11:00:54 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18lCz5-000KYo-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 11:00:51 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Tue, 18 Feb 2003 20:02:29 +0100 Message-ID: <16aa01c2d780$4750ab50$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Tue, 18 Feb 2003 20:02:24 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_RELAYS_ORDB_ORG, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Carlos, As I explained there, I can use v4 with some protocols and destinations, may be it was a combination of firewall/filter+routing problem, not sure, but for sure I was able to bring up the tunnel and then I started to work almost normally (but with v6), I even gained access to our streaming server, under test. It was also pity for me not being able to show the Isabel application, but as you know the people that setup it, had only a couple of days to try to sort out all the problems, and it was impossible to setup it w/o disturbing the running sessions, connecting 25 sites across the world (they worked perfectly). Next time ! Regards, Jordi ----- Original Message ----- From: "Carlos Friacas" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, February 18, 2003 7:39 PM Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > On Tue, 18 Feb 2003, JORDI PALET MARTINEZ wrote: > > > Hi Carlos, > > Hello. > > > > As you can imagine, I did a tunnel only because the native IPv6 was not working for me. I learn, as a first lesson, to see if there > > is a RA in the network before I do my own one ! > > Perhaps your problem was there were several on the link. :-) > Miguel from University of Evora noticed that while he was trying to bring > the Isabel connection up. > > > > I even asked, and they told me that ONLY v4 was available in that network. > > Sorry. :-( > Probably you were misinformed. There was a note on the reg.desk > > > > In fact I show to some people from the organization that curiously, v4 was not working also. I got an address assigned by DHCP, but > > no way to use web or pop3/smtp. Some other people experienced the same problem, so I guess it wasn't my own computer. > > This was tested ok by our local network folks, that installed the AP, and > nobody else complained. Strange at least. > > > > So I tried my own tunnel, and it worked. If you filter port 41, that's still fine for me (unless you mean proto-41). > > typo... s/port/proto :-) > > > > Obviously the round-trip was not good, but it was due to the network configuration itself, as I was doing a ping to my tunnel end. > > If I ping with v4, the round trip must be almost the same ! > > If you were not able to do simple web browsing over v4, you were very > lucky to be able to do v6 over v4. So this proofs v4 was working, no? > That LAN is becoming a "case-study"... :-) > > > > Anyway, I tried to show that even when IPv4 is not working, I can use IPv6, and that's was a real situation ... I prefer to have a > > slower connectivity that _nothing_. > > If v4 was not working you couldnt have found your other tunnel end > magically... :-) > > > > Clearly we must improve this, but this is what we are working now, here > > in this group. > > > > I prefer to show the people the true, not just telling them everything > > is wonderful and we have nothing to do. I'm sure other people > > is in the same side. > > The truth about that particular meeting is that nobody showed up with > *any* traffic graphic, even a graphic populated with data generated by > test-traffic not users. That was really a deception for me. > > Another deception was not seing the ISABEL aplication working. I had > spent some hours in the previous days troubleshooting ipv6 bgp4+ with > people from PTInovacao in order to setup the connectivity to euro6ix, and > at the end it was not possible to bring the application up due to a > congestion in Madrid. It was a real frustration and it stopped us to show > something really running on top of v6. :-( > > > Regards. > > > > Regards, > > Jordi > > > > ----- Original Message ----- > > From: "Carlos Friacas" > > To: "JORDI PALET MARTINEZ" > > Cc: > > Sent: Tuesday, February 18, 2003 6:44 PM > > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > > Hello. > > > > > > Last week you showed at a conference a v6 tunnel over v4, when you had > > > native v6. > > > > > > The roundtrip times you showed on a traceroute left some people in the > > > audience yellow-faced... > > > > > > One thing to have in mind in the future *for you*: check if you have > > > native v6 available. > > > > > > One thing to have in mind *for me* in the future: filter port 41 on a dual > > > stack interface, to avoid the kind of "stunts" people sometimes do... :-) > > > > > > > > > Regards, > > > > > > ./Carlos > > > "Networking is fun!" > > > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > > > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > > > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > > > > > > > ********************************* > > Madrid 2003 Global IPv6 Summit > > 12-14 May 2003 - Pre-register at: > > http://www.ipv6-es.com > > Interested in participating or sponsoring ? > > Contact us at ipv6@consulintel.es > > > > > > > > > > ./Carlos > "Networking is fun!" > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Tue Feb 18 17:26: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 RAA10141 for ; Tue, 18 Feb 2003 17:26:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lGEA-0007h8-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 14:28:38 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18lGE7-0007gw-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 14:28:36 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA07800 for ; Tue, 18 Feb 2003 22:28:33 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h1IMSUU3016427 for ; Tue, 18 Feb 2003 22:28:30 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1IMSTI16283 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 22:28:29 GMT Date: Tue, 18 Feb 2003 22:28:29 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Message-ID: <20030218222829.GQ14372@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B2@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B034C07B2@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Just the protocol 41 forwarding destination on the internal network from the NAT box. So like Jordi but some config needed. They also wrote their own tunnel broker s/w using FreeBSD, ssh and OpenLDAP (all v6). Tim On Mon, Feb 17, 2003 at 08:00:58PM -0500, Bound, Jim wrote: > What are they tweaking? > > Thanks > /jim > > > > > > -----Original Message----- > > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > > Sent: Sunday, February 16, 2003 12:59 PM > > To: Jeroen Massar > > Cc: 'Alain Durand'; Bound, Jim; alh-ietf@tndh.net; v6ops@ops.ietf.org > > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > > > Which one can do now by simply installing eg the freenet6 > > client onto > > > one of the existing windows/*nix boxes which will advertise > > the IPv6 > > > prefix onto the local subnet. The only trick here is to > > have the CPE > > > forward proto-41 to your v6-gate or using Teredo. Btw 'just have to > > > add' is sometimes expensive for some people. > > > > This is what our IPv6 students tend to do in their homes. It > > works nicely, > > but still requires a tweak in the DSL router. > > > > Tim > > From owner-v6ops@ops.ietf.org Tue Feb 18 17:26:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10155 for ; Tue, 18 Feb 2003 17:26:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lGEV-0007iQ-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 14:28:59 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18lGES-0007i4-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 14:28:56 -0800 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA07804 for ; Tue, 18 Feb 2003 22:28:55 GMT Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [152.78.68.162]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h1IMSnU3016533 for ; Tue, 18 Feb 2003 22:28:49 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h1IMSn216293 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 22:28:49 GMT Date: Tue, 18 Feb 2003 22:28:49 +0000 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt Message-ID: <20030218222849.GR14372@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> <5.1.0.14.2.20030217222219.03612f08@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030217222219.03612f08@mail.windriver.com> User-Agent: Mutt/1.4i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Has the enterprise draft gone last call? Tim On Mon, Feb 17, 2003 at 10:22:55PM -0500, Margaret Wasserman wrote: > > THis last call will also remain open through Sunday, March 2nd, > 2003. > > At 12:11 PM 2/17/2003 -0500, Margaret Wasserman wrote: > > >Hi All, > > > >This is a WG Last Call for comments on sending the Unmanaged > >Networks scenarios document to the IESG for consideration as > >an Informational RFC: > > > >Title: Unmanaged Networks IPv6 Transition Scenarios > >Filename: draft-ietf-v6ops-unman-scenarios-00.txt > >Authors: C. Huitema, R. Austein, R. van der Pol > >Date: January 10, 2003 > > > >The document can be found at: > >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt > > From owner-v6ops@ops.ietf.org Tue Feb 18 17:31:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10280 for ; Tue, 18 Feb 2003 17:31:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lGK1-000893-00 for v6ops-data@psg.com; Tue, 18 Feb 2003 14:34:41 -0800 Received: from addr-mx01.addr.com ([209.249.147.145]) by psg.com with esmtp (Exim 3.36 #1) id 18lGJz-00087s-00 for v6ops@ops.ietf.org; Tue, 18 Feb 2003 14:34:39 -0800 Received: from proxy1.addr.com (proxy1.addr.com [209.249.147.28]) by addr-mx01.addr.com (8.12.5/8.12.2) with ESMTP id h1IMY1cB047424; Tue, 18 Feb 2003 14:34:01 -0800 (PST) Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.11.6/8.9.1) with ESMTP id h1IMXxF35899; Tue, 18 Feb 2003 14:34:00 -0800 (PST) (envelope-from bob@thefinks.com)(envelope-to ) Message-Id: <5.2.0.9.0.20030218143246.020623d8@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 18 Feb 2003 14:33:55 -0800 To: Tim Chown , v6ops@ops.ietf.org From: Bob Fink Subject: Re: WG Last Call: draft-ietf-v6ops-unman-scenarios-00.txt In-Reply-To: <20030218222849.GR14372@login.ecs.soton.ac.uk> References: <5.1.0.14.2.20030217222219.03612f08@mail.windriver.com> <5.1.0.14.2.20030217120532.06292ba8@mail.windriver.com> <5.1.0.14.2.20030217222219.03612f08@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) X-Spam-Status: No, hits=0.4 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,REFERENCES, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 10:28 PM 2/18/2003 +0000, Tim Chown wrote: >Has the enterprise draft gone last call? Not yet. It still needs to become a wg draft instead of a personal submission, which requires wg review. This should happen soon. Bob From owner-v6ops@ops.ietf.org Wed Feb 19 06:21:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18910 for ; Wed, 19 Feb 2003 06:21:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lSIM-00038C-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 03:21:46 -0800 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #1) id 18lSIJ-00037z-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 03:21:43 -0800 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1JBKU219069 for ; Wed, 19 Feb 2003 13:20:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Feb 2003 13:21:41 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 13:21:41 +0200 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 13:21:41 +0200 Received: from maebe001.NOE.Nokia.com ([10.209.0.44]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Feb 2003 13:21:40 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Wed, 19 Feb 2003 12:21:39 +0100 Message-ID: <05C8D36DA4EF684D8BD4E309B1CD5AF1A4C181@maebe001.europe.nokia.com> Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLWqP5wvIQVCFimS9+D//NvVLXIzQAYWUxwAD9+UtA= From: To: X-OriginalArrivalTime: 19 Feb 2003 11:21:40.0650 (UTC) FILETIME=[1318E8A0:01C2D809] X-Spam-Status: No, hits=1.3 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA18910 Yes, IMHO this draft is pretty mature; it provides a good description of all possible scenarios in 3GPP from the IPv4-IPv6 transition point of view. I believe it's ready to go to the IESG. Br, Ivan Laloux -----Original Message----- From: ext Bound, Jim [mailto:Jim.Bound@hp.com] Sent: 18 February, 2003 06:00 To: Margaret Wasserman; v6ops@ops.ietf.org Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt I believe this is ready for IESG review. Would love to change IMS but that's the way it goes :--) /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, February 17, 2003 12:05 PM > To: v6ops@ops.ietf.org > Subject: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt > > > > > Hi All, > > This is a WG Last Call for comments on sending the 3GPP > scenarios document to the IESG for consideration as an > Informational RFC: > > Title: Transition Scenarios for 3GPP Networks > Filename: draft-ietf-v6ops-3gpp-cases-02.txt > Editor: J. Soininen > Date: January 2003 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt > > Abstract > > This document describes different scenarios in Third Generation > Partnership Project (3GPP) defined packet network, i.e. General > Packet Radio Service (GPRS) that would need IP version 6 and IP > version 4 transition. The focus of this document is on > the scenarios > where the User Equipment (UE) connects to nodes in other networks, > e.g. in the Internet. GPRS network internal transition scenarios, > i.e. between different GPRS elements in the network, are > out of scope > of this document. > > The purpose of the document is to list the scenarios for further > discussion and study. > > Since this is the first WG last call that we have had in the > v6ops WG, we would like to remind you of the process that we > discussed for WG last calls when we started this WG. > > The WG Last Call is a final check that the WG has rough > consensus to advance the document to the IESG. Advancing a > document to the IESG indicates that the WG believes that this > document is both technically sound and useful. It also > indicates that we believe that the document meets all of the > requirements for publication as an RFC. > > To pass WG last call, this document must be reviewed and > actively supported by a significant number of people, > including experts in all applicable areas, or it will not be > sent to the IESG. > > Silence does NOT indicate consent during this phase. > > So, please review this document carefully, and send your > feedback to the list, indicating whether or not you believe > that this document is ready to go to the IESG. Unless > sufficient support is demonstrated on the list, the document > will not be send to the IESG. > > Thanks, > Margaret, Itojun and Bob > v6ops WG Chairs > > > > From owner-v6ops@ops.ietf.org Wed Feb 19 07:11: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 HAA20547 for ; Wed, 19 Feb 2003 07:11:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT7a-0005BK-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:14:42 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7X-0005B3-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:14:39 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20424; Wed, 19 Feb 2003 07:10:48 -0500 (EST) Message-Id: <200302191210.HAA20424@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-00.txt Date: Wed, 19 Feb 2003 07:10:48 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-apps-00.txt Pages : 0 Date : 2003-2-14 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Application 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-apps-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-apps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-apps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072537.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:11: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 HAA20601 for ; Wed, 19 Feb 2003 07:11:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT7r-0005Co-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:14:59 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7m-0005C7-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:14:55 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20496; Wed, 19 Feb 2003 07:11:04 -0500 (EST) Message-Id: <200302191211.HAA20496@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-00.txt Date: Wed, 19 Feb 2003 07:11:04 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-ops-00.txt Pages : 0 Date : 2003-2-14 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-ops-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-ops-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072611.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:11: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 HAA20620 for ; Wed, 19 Feb 2003 07:11:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT7x-0005E0-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:15:05 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7s-0005Cp-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:15:00 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20514; Wed, 19 Feb 2003 07:11:09 -0500 (EST) Message-Id: <200302191211.HAA20514@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-routing-00.txt Date: Wed, 19 Feb 2003 07:11:09 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-routing-00.txt Pages : 0 Date : 2003-2-14 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-routing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-routing-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-routing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-routing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072626.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07: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 HAA20634 for ; Wed, 19 Feb 2003 07:11:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT7f-0005Bb-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:14:47 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7b-0005BM-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:14:44 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20442; Wed, 19 Feb 2003 07:10:53 -0500 (EST) Message-Id: <200302191210.HAA20442@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-gen-00.txt Date: Wed, 19 Feb 2003 07:10:53 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-gen-00.txt Pages : 0 Date : 2003-2-14 This document seeks to document all usage of IPv4 addresses in currently deployed IETF General 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-gen-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-gen-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-gen-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-gen-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-gen-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072548.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:11: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 HAA20661 for ; Wed, 19 Feb 2003 07:11:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT7W-0005B1-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:14:38 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7T-0005Ak-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:14:35 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20394; Wed, 19 Feb 2003 07:10:44 -0500 (EST) Message-Id: <200302191210.HAA20394@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-entnet-scenarios-00.txt Date: Wed, 19 Feb 2003 07:10:43 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Networks Scenarios Author(s) : Y. Pouffary, J. Bound Filename : draft-ietf-v6ops-entnet-scenarios-00.txt Pages : 17 Date : 2003-2-14 IPv6 will be deployed in Enterprise networks. This scenario has requirements for the adoption of IPv6. This document will focus upon and define: a set of technology scenarios that shall exist for the enterprise network, the set of transition variables, transition methods, and tools required by different scenarios. The document using these definitions will define the points of transition for an Enterprise network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-scenarios-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-entnet-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-entnet-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-entnet-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-entnet-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072524.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:12:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20675 for ; Wed, 19 Feb 2003 07:11:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT7Y-0005BF-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:14:40 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7N-0005AU-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:14:29 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20352; Wed, 19 Feb 2003 07:10:38 -0500 (EST) Message-Id: <200302191210.HAA20352@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-00.txt Date: Wed, 19 Feb 2003 07:10:38 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-intro-00.txt Pages : 0 Date : 2003-2-14 This document seeks to document all usage of IPv4 addresses in currently deployed IETF documented standards. This material was originally presented in a single document, but has subsequently been split into 8 documents based on IETF Areas. This document is a general overview of the project. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-intro-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072509.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:12: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 HAA20694 for ; Wed, 19 Feb 2003 07:12:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT85-0005F0-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:15:13 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7y-0005Dl-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:15:06 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20536; Wed, 19 Feb 2003 07:11:14 -0500 (EST) Message-Id: <200302191211.HAA20536@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-00.txt Date: Wed, 19 Feb 2003 07:11:14 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-sec-00.txt Pages : 0 Date : 2003-2-14 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-sec-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-sec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072639.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:12:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20708 for ; Wed, 19 Feb 2003 07:12:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT7l-0005C4-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:14:53 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT7h-0005Bh-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:14:50 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20460; Wed, 19 Feb 2003 07:10:59 -0500 (EST) Message-Id: <200302191210.HAA20460@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-int-00.txt Date: Wed, 19 Feb 2003 07:10:59 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-int-00.txt Pages : 0 Date : 2003-2-14 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-int-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-int-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-int-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-int-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072558.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:12: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 HAA20725 for ; Wed, 19 Feb 2003 07:12:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT8G-0005Ga-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:15:24 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT89-0005FJ-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:15:18 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20586; Wed, 19 Feb 2003 07:11:26 -0500 (EST) Message-Id: <200302191211.HAA20586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-trans-00.txt Date: Wed, 19 Feb 2003 07:11:25 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-trans-00.txt Pages : 0 Date : 2003-2-14 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-trans-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-trans-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072702.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:12: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 HAA20744 for ; Wed, 19 Feb 2003 07:12:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lT88-0005FF-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:15:16 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18lT82-0005Eh-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:15:10 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20567; Wed, 19 Feb 2003 07:11:19 -0500 (EST) Message-Id: <200302191211.HAA20567@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-00.txt Date: Wed, 19 Feb 2003 07:11:19 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,SUPERLONG_LINE,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-subip-00.txt Pages : 0 Date : 2003-2-14 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-subip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19072651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-subip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19072651.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Feb 19 07:33: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 HAA22053 for ; Wed, 19 Feb 2003 07:33:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lTSe-0006Qn-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:36:28 -0800 Received: from atlas.fccn.pt ([193.136.7.1]) by psg.com with smtp (Exim 3.36 #1) id 18lTSa-0006QZ-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:36:24 -0800 Received: (qmail 55355 invoked by uid 2502); 19 Feb 2003 12:36:21 -0000 Received: from cfriacas@fccn.pt by atlas.fccn.pt with qmail-scanner-0.94 (. Clean. Processed in 0.125416 secs); 19/02/2003 12:36:21 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 19 Feb 2003 12:36:21 -0000 Date: Wed, 19 Feb 2003 12:36:21 +0000 (WET) From: Carlos Friacas To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT In-Reply-To: <16aa01c2d780$4750ab50$870a0a0a@consulintel.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 18 Feb 2003, JORDI PALET MARTINEZ wrote: > Carlos, Hello. > As I explained there, I can use v4 with some protocols and destinations, may be it was a combination of firewall/filter+routing > problem, not sure, but for sure I was able to bring up the tunnel and then I started to work almost normally (but with v6), I even > gained access to our streaming server, under test. No firewall there, the routing (v4 and v6) was ok. As i said, this network is transforming itself on a "case-study". :-) It was very unfortunate that you were not able to show anything from your streaming server. Perhaps the 2Mbps between FCCN and Euro6IX PoP in Lisbon was not enough. :-( > It was also pity for me not being able to show the Isabel application, > but as you know the people that setup it, had only a couple > of days to try to sort out all the problems, and it was impossible to > setup it w/o disturbing the running sessions, connecting 25 > sites across the world (they worked perfectly). Next time ! Circuit dimensioning problem (bugs in planning). I was told that Isabel is really a bandwidth hog. Sometimes just having a good intention and throwing it around is not enough *sigh* :-( I have some questions about Euro6IX too. Do you have the time to answer them Jordi? > Regards, > Jordi Regards. > ----- Original Message ----- > From: "Carlos Friacas" > To: "JORDI PALET MARTINEZ" > Cc: > Sent: Tuesday, February 18, 2003 7:39 PM > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > On Tue, 18 Feb 2003, JORDI PALET MARTINEZ wrote: > > > > > Hi Carlos, > > > > Hello. > > > > > > > As you can imagine, I did a tunnel only because the native IPv6 was not working for me. I learn, as a first lesson, to see if > there > > > is a RA in the network before I do my own one ! > > > > Perhaps your problem was there were several on the link. :-) > > Miguel from University of Evora noticed that while he was trying to bring > > the Isabel connection up. > > > > > > > I even asked, and they told me that ONLY v4 was available in that network. > > > > Sorry. :-( > > Probably you were misinformed. There was a note on the reg.desk > > > > > > > In fact I show to some people from the organization that curiously, v4 was not working also. I got an address assigned by DHCP, > but > > > no way to use web or pop3/smtp. Some other people experienced the same problem, so I guess it wasn't my own computer. > > > > This was tested ok by our local network folks, that installed the AP, and > > nobody else complained. Strange at least. > > > > > > > So I tried my own tunnel, and it worked. If you filter port 41, that's still fine for me (unless you mean proto-41). > > > > typo... s/port/proto :-) > > > > > > > Obviously the round-trip was not good, but it was due to the network configuration itself, as I was doing a ping to my tunnel > end. > > > If I ping with v4, the round trip must be almost the same ! > > > > If you were not able to do simple web browsing over v4, you were very > > lucky to be able to do v6 over v4. So this proofs v4 was working, no? > > That LAN is becoming a "case-study"... :-) > > > > > > > Anyway, I tried to show that even when IPv4 is not working, I can use IPv6, and that's was a real situation ... I prefer to have > a > > > slower connectivity that _nothing_. > > > > If v4 was not working you couldnt have found your other tunnel end > > magically... :-) > > > > > > > Clearly we must improve this, but this is what we are working now, here > > > in this group. > > > > > > I prefer to show the people the true, not just telling them everything > > > is wonderful and we have nothing to do. I'm sure other people > > > is in the same side. > > > > The truth about that particular meeting is that nobody showed up with > > *any* traffic graphic, even a graphic populated with data generated by > > test-traffic not users. That was really a deception for me. > > > > Another deception was not seing the ISABEL aplication working. I had > > spent some hours in the previous days troubleshooting ipv6 bgp4+ with > > people from PTInovacao in order to setup the connectivity to euro6ix, and > > at the end it was not possible to bring the application up due to a > > congestion in Madrid. It was a real frustration and it stopped us to show > > something really running on top of v6. :-( > > > > > > Regards. > > > > > > > Regards, > > > Jordi > > > > > > ----- Original Message ----- > > > From: "Carlos Friacas" > > > To: "JORDI PALET MARTINEZ" > > > Cc: > > > Sent: Tuesday, February 18, 2003 6:44 PM > > > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > > > > > > Hello. > > > > > > > > Last week you showed at a conference a v6 tunnel over v4, when you had > > > > native v6. > > > > > > > > The roundtrip times you showed on a traceroute left some people in the > > > > audience yellow-faced... > > > > > > > > One thing to have in mind in the future *for you*: check if you have > > > > native v6 available. > > > > > > > > One thing to have in mind *for me* in the future: filter port 41 on a dual > > > > stack interface, to avoid the kind of "stunts" people sometimes do... :-) > > > > > > > > > > > > Regards, > > > > > > > > ./Carlos > > > > "Networking is fun!" > > > > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > > > > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > > > > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > > > > > > > > > > ********************************* > > > Madrid 2003 Global IPv6 Summit > > > 12-14 May 2003 - Pre-register at: > > > http://www.ipv6-es.com > > > Interested in participating or sponsoring ? > > > Contact us at ipv6@consulintel.es > > > > > > > > > > > > > > > > > ./Carlos > > "Networking is fun!" > > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > > > > ********************************* > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Pre-register at: > http://www.ipv6-es.com > Interested in participating or sponsoring ? > Contact us at ipv6@consulintel.es > > > ./Carlos "Networking is fun!" -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 From owner-v6ops@ops.ietf.org Wed Feb 19 07:46: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 HAA22867 for ; Wed, 19 Feb 2003 07:46:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lTfR-00072I-00 for v6ops-data@psg.com; Wed, 19 Feb 2003 04:49:41 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18lTfN-00071t-00 for v6ops@ops.ietf.org; Wed, 19 Feb 2003 04:49:38 -0800 Received: from consulintel02 ([10.0.0.135]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Wed, 19 Feb 2003 13:51:17 +0100 Message-ID: <003301c2d815$9735bf30$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Wed, 19 Feb 2003 13:51:15 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 10.0.0.135 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ok. Let's conclude here or somebody will complain about being "off-topic". I can reply you about Euro6IX, of course, but better in private ? Regards, Jordi ----- Original Message ----- From: "Carlos Friacas" To: "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, February 19, 2003 1:36 PM Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > On Tue, 18 Feb 2003, JORDI PALET MARTINEZ wrote: > > > Carlos, > > Hello. > > > > As I explained there, I can use v4 with some protocols and destinations, may be it was a combination of firewall/filter+routing > > problem, not sure, but for sure I was able to bring up the tunnel and then I started to work almost normally (but with v6), I even > > gained access to our streaming server, under test. > > No firewall there, the routing (v4 and v6) was ok. > As i said, this network is transforming itself on a "case-study". :-) > It was very unfortunate that you were not able to show anything from your > streaming server. > Perhaps the 2Mbps between FCCN and Euro6IX PoP in Lisbon was not enough. > :-( > > > > It was also pity for me not being able to show the Isabel application, > > but as you know the people that setup it, had only a couple > > of days to try to sort out all the problems, and it was impossible to > > setup it w/o disturbing the running sessions, connecting 25 > > sites across the world (they worked perfectly). Next time ! > > Circuit dimensioning problem (bugs in planning). I was told that Isabel is > really a bandwidth hog. Sometimes just having a good intention and > throwing it around is not enough *sigh* :-( > > > I have some questions about Euro6IX too. Do you have the time to answer > them Jordi? > > > > > Regards, > > Jordi > > Regards. > > > > ----- Original Message ----- > > From: "Carlos Friacas" > > To: "JORDI PALET MARTINEZ" > > Cc: > > Sent: Tuesday, February 18, 2003 7:39 PM > > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > On Tue, 18 Feb 2003, JORDI PALET MARTINEZ wrote: > > > > > > > Hi Carlos, > > > > > > Hello. > > > > > > > > > > As you can imagine, I did a tunnel only because the native IPv6 was not working for me. I learn, as a first lesson, to see if > > there > > > > is a RA in the network before I do my own one ! > > > > > > Perhaps your problem was there were several on the link. :-) > > > Miguel from University of Evora noticed that while he was trying to bring > > > the Isabel connection up. > > > > > > > > > > I even asked, and they told me that ONLY v4 was available in that network. > > > > > > Sorry. :-( > > > Probably you were misinformed. There was a note on the reg.desk > > > > > > > > > > In fact I show to some people from the organization that curiously, v4 was not working also. I got an address assigned by DHCP, > > but > > > > no way to use web or pop3/smtp. Some other people experienced the same problem, so I guess it wasn't my own computer. > > > > > > This was tested ok by our local network folks, that installed the AP, and > > > nobody else complained. Strange at least. > > > > > > > > > > So I tried my own tunnel, and it worked. If you filter port 41, that's still fine for me (unless you mean proto-41). > > > > > > typo... s/port/proto :-) > > > > > > > > > > Obviously the round-trip was not good, but it was due to the network configuration itself, as I was doing a ping to my tunnel > > end. > > > > If I ping with v4, the round trip must be almost the same ! > > > > > > If you were not able to do simple web browsing over v4, you were very > > > lucky to be able to do v6 over v4. So this proofs v4 was working, no? > > > That LAN is becoming a "case-study"... :-) > > > > > > > > > > Anyway, I tried to show that even when IPv4 is not working, I can use IPv6, and that's was a real situation ... I prefer to have > > a > > > > slower connectivity that _nothing_. > > > > > > If v4 was not working you couldnt have found your other tunnel end > > > magically... :-) > > > > > > > > > > Clearly we must improve this, but this is what we are working now, here > > > > in this group. > > > > > > > > I prefer to show the people the true, not just telling them everything > > > > is wonderful and we have nothing to do. I'm sure other people > > > > is in the same side. > > > > > > The truth about that particular meeting is that nobody showed up with > > > *any* traffic graphic, even a graphic populated with data generated by > > > test-traffic not users. That was really a deception for me. > > > > > > Another deception was not seing the ISABEL aplication working. I had > > > spent some hours in the previous days troubleshooting ipv6 bgp4+ with > > > people from PTInovacao in order to setup the connectivity to euro6ix, and > > > at the end it was not possible to bring the application up due to a > > > congestion in Madrid. It was a real frustration and it stopped us to show > > > something really running on top of v6. :-( > > > > > > > > > Regards. > > > > > > > > > > Regards, > > > > Jordi > > > > > > > > ----- Original Message ----- > > > > From: "Carlos Friacas" > > > > To: "JORDI PALET MARTINEZ" > > > > Cc: > > > > Sent: Tuesday, February 18, 2003 6:44 PM > > > > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > > > > > > > > > > Hello. > > > > > > > > > > Last week you showed at a conference a v6 tunnel over v4, when you had > > > > > native v6. > > > > > > > > > > The roundtrip times you showed on a traceroute left some people in the > > > > > audience yellow-faced... > > > > > > > > > > One thing to have in mind in the future *for you*: check if you have > > > > > native v6 available. > > > > > > > > > > One thing to have in mind *for me* in the future: filter port 41 on a dual > > > > > stack interface, to avoid the kind of "stunts" people sometimes do... :-) > > > > > > > > > > > > > > > Regards, > > > > > > > > > > ./Carlos > > > > > "Networking is fun!" > > > > > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > > > > > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > > > > > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > > > > > > > > > > > > > ********************************* > > > > Madrid 2003 Global IPv6 Summit > > > > 12-14 May 2003 - Pre-register at: > > > > http://www.ipv6-es.com > > > > Interested in participating or sponsoring ? > > > > Contact us at ipv6@consulintel.es > > > > > > > > > > > > > > > > > > > > > > > > ./Carlos > > > "Networking is fun!" > > > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > > > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > > > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > > > > > > > ********************************* > > Madrid 2003 Global IPv6 Summit > > 12-14 May 2003 - Pre-register at: > > http://www.ipv6-es.com > > Interested in participating or sponsoring ? > > Contact us at ipv6@consulintel.es > > > > > > > > > > ./Carlos > "Networking is fun!" > -------------- [http://www.ip6.fccn.pt] http://www.fccn.pt > , CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup > F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167 > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Thu Feb 20 09:00: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 JAA14697 for ; Thu, 20 Feb 2003 09:00:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lrDh-0003mr-00 for v6ops-data@psg.com; Thu, 20 Feb 2003 05:58:37 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18lrDe-0003ma-00 for v6ops@ops.ietf.org; Thu, 20 Feb 2003 05:58:34 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1KE1Vm18757 for ; Thu, 20 Feb 2003 16:01:31 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Feb 2003 15:58:29 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 15:58:29 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Feb 2003 15:58:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3GPP analysis Date: Thu, 20 Feb 2003 15:58:26 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3797@esebe005.ntc.nokia.com> Thread-Topic: 3GPP analysis Thread-Index: AcLUMwHWyBtphE4rQoGyliN29kjkQgEsftEg From: To: Cc: X-OriginalArrivalTime: 20 Feb 2003 13:58:29.0270 (UTC) FILETIME=[257C2360:01C2D8E8] X-Spam-Status: No, hits=1.8 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_01_02,SUPERLONG_LINE version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA14697 Hello, Suresh! Firstly, sorry for the long delay in my reply... :-( -----Original Message----- From: ext suresh.leroy@alcatel.be [mailto:suresh.leroy@alcatel.be] Sent: 14 February, 2003 16:11 First of all I fully agree with you that we have to work with what 3GPP specified, if changes are needed they should be done towards 3GPP directly. JW: Yep, that's true. 3GPP architecture is taken as given in this exercise. I just wanted to know if from a technical point of view it would facilitate things in ALGs and SIP servers would be integrated. For the answer to the first question. If I correctly understood your proposal the decision for adding a SIP ALG in the IMS network would be based on the peer address carried in the first reply. One problem with this is that the destination SIP server will see the peer IP address of the IMS UE in the initial Invite is an IPv6 address and will therefor provide local interworking as the destination peer is IPv4 only. In this case the IMS SIP server will never know the peer is in fact a IPv4 node as the returned address is that of a local NAT-PT box. JW: Right, I see... But anyway, the first priority of IMS scenario 1 is to analyze "IPv4-only SIP client (registered to IPv4-only SIP server) <-> IPv6-only IMS UE" case Personally I was thinking more of a solution where the IMS SIP ALG server would add an IPv4 address (of the NAT-PT) to the SDP in the SIP invite. In this case the SIP server at the destination network doesn't have to add any interworking boxes at the user plane. So it is a split of SDP and SIP interworking. A drawback of this solution is that the IPv4 address is added to every SIP message also the ones that don't require interworking. JW: I think we cannot force the translation to be made on the edge of the IMS, and we can just give short solution guidelines in our document. In your proposal, do you mean allocating a public IPv4 address to every UE connected to IMS? If that is so, it's good to remember that there's a big number of UEs in a 3GPP network. Moreover, I guess that when the destination SIP server is dual stack and IPv4-only nodes are allowed to register to it, then it might be reasonable to assume that the destination domain will be able to perform IPv4-IPv6 translation... Anyway, I try to address these points a bit more in the next revision (-02) I'm planning to make by the end of next week. Do you know if work has been done regarding IPv4-IPv6 interworking for SIP in one of the SIP working groups. The only thing I've found sofar is how to carry IPv6 addresses in SIP and SDP, nothing about the processing or interpretation of these fields by the different SIP agents. JW: I have heard some discussion (I think it was in 3GPP/IETF meeting in San Francisco) on SIP v4/v6 studies to be started in sipping (?) wg. Let's see whether we get more information on that in the next IETF meeting. Best Regards, -Juha W.- From owner-v6ops@ops.ietf.org Thu Feb 20 10:00: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 KAA16587 for ; Thu, 20 Feb 2003 10:00:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lsDV-0006Hc-00 for v6ops-data@psg.com; Thu, 20 Feb 2003 07:02:29 -0800 Received: from alc239.alcatel.be ([195.207.101.239] helo=mail.alcatel.be) by psg.com with esmtp (Exim 3.36 #1) id 18lsDQ-0006HE-00 for v6ops@ops.ietf.org; Thu, 20 Feb 2003 07:02:24 -0800 Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by mail.alcatel.be (8.10.1/8.11.4) with ESMTP id h1KF2Ji28394 for ; Thu, 20 Feb 2003 16:02:19 +0100 (MET) Received: from alcatel.be ([138.203.64.126]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003022016021793:5686 ; Thu, 20 Feb 2003 16:02:17 +0100 Message-ID: <3E54EDF4.EC83E74F@alcatel.be> Date: Thu, 20 Feb 2003 16:02:13 +0100 From: suresh.leroy@alcatel.be Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: juha.wiljakka@nokia.com CC: v6ops@ops.ietf.org Subject: Re: 3GPP analysis References: <245DBCAEEC4F074CB77B3F984FF9834FDC3797@esebe005.ntc.nokia.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/20/2003 16:02:18, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/20/2003 16:02:19, Serialize complete at 02/20/2003 16:02:19 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,NOSPAM_INC,NO_REAL_NAME, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, SUPERLONG_LINE,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Juha, Thanks for the reply. In the solution I described the IPv4 addresses wouldn't be allocated permanently. At session setup time they are added to the SDP, if in the answer it turns out the peer node supports IPv6 this IPv4 address can be released and allocated to another session. Very similar to NAT. Furthermore the I-CSCF could a first filtering based on the SIP-URL to decide if this interworking is needed, this could be done by storing a list of known IMS domain parts in the S-CSCF. Once more and more non-IMS user start supporting IPv6 this feature could be disabled. Anyhow I guess the exact mechanism for SIP interworking would be handled in the SIPPING or SIP group. Greetings, Suresh juha.wiljakka@nokia.com wrote: > Hello, Suresh! > > Firstly, sorry for the long delay in my reply... :-( > > -----Original Message----- > From: ext suresh.leroy@alcatel.be [mailto:suresh.leroy@alcatel.be] > Sent: 14 February, 2003 16:11 > > First of all I fully agree with you that we have to work with what 3GPP specified, if changes are needed they should be done towards 3GPP directly. > > JW: Yep, that's true. 3GPP architecture is taken as given in this exercise. > > I just wanted to know if from a technical point of view it would facilitate things in ALGs and SIP servers would be integrated. > > For the answer to the first question. If I correctly understood your proposal the decision for adding a SIP ALG in the IMS network would be based on the peer address carried in the first reply. One problem with this is that the destination SIP server will see the peer IP address of the IMS UE in the initial Invite is an IPv6 address and will therefor provide local interworking as the destination peer is IPv4 only. In this case the IMS SIP server will never know the peer is in fact a IPv4 node as the returned address is that of a local NAT-PT box. > > JW: Right, I see... But anyway, the first priority of IMS scenario 1 is to analyze "IPv4-only SIP client (registered to IPv4-only SIP server) <-> IPv6-only IMS UE" case > > Personally I was thinking more of a solution where the IMS SIP ALG server would add an IPv4 address (of the NAT-PT) to the SDP in the SIP invite. In this case the SIP server at the destination network doesn't have to add any interworking boxes at the user plane. So it is a split of SDP and SIP interworking. > A drawback of this solution is that the IPv4 address is added to every SIP message also the ones that don't require interworking. > > JW: I think we cannot force the translation to be made on the edge of the IMS, and we can just give short solution guidelines in our document. In your proposal, do you mean allocating a public IPv4 address to every UE connected to IMS? If that is so, it's good to remember that there's a big number of UEs in a 3GPP network. Moreover, I guess that when the destination SIP server is dual stack and IPv4-only nodes are allowed to register to it, then it might be reasonable to assume that the destination domain will be able to perform IPv4-IPv6 translation... Anyway, I try to address these points a bit more in the next revision (-02) I'm planning to make by the end of next week. > > Do you know if work has been done regarding IPv4-IPv6 interworking for SIP in one of the SIP working groups. The only thing I've found sofar is how to carry IPv6 addresses in SIP and SDP, nothing about the processing or interpretation of these fields by the different SIP agents. > > JW: I have heard some discussion (I think it was in 3GPP/IETF meeting in San Francisco) on SIP v4/v6 studies to be started in sipping (?) wg. Let's see whether we get more information on that in the next IETF meeting. > > Best Regards, > -Juha W.- From owner-v6ops@ops.ietf.org Thu Feb 20 11:49: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 LAA20958 for ; Thu, 20 Feb 2003 11:49:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ltvT-000Aw1-00 for v6ops-data@psg.com; Thu, 20 Feb 2003 08:51:59 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18ltvP-000Ava-00 for v6ops@ops.ietf.org; Thu, 20 Feb 2003 08:51:55 -0800 Received: from IDLEWYLDE.windriver.com ([128.224.4.103]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA20850 for ; Thu, 20 Feb 2003 08:50:39 -0800 (PST) Message-Id: <5.1.0.14.2.20030220110122.02bb9970@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 11:46:14 -0500 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Oops! Accepting Enterprise Scenarios as WG Item Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, I made a mistake last week and approved the publication of the enterprise scenarios document as a WG work item without actually checking with the WG first... Sorry. So, let's do this the right way... The enterprise scenarios/analysis team believes that the current version of their scenarios document is ready for consideration as a v6ops WG item. The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-scenarios-00.txt This work is clearly within the charter of v6ops. Could members of the WG please comment on whether you believe that this document should be accepted as a WG item? In other words, does it take the right technical direction, and would it serve as a useful basis for our work? Is it sufficiently complete that it is ready for WG review and refinement? If there is sufficient support to accept this document, it will remain a WG work item. If not, we will move it back to individual submission status. Sorry for my mistake and any confusion it may cause. Margaret From owner-v6ops@ops.ietf.org Thu Feb 20 15:05: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 PAA27777 for ; Thu, 20 Feb 2003 15:05:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18lwz8-000KaZ-00 for v6ops-data@psg.com; Thu, 20 Feb 2003 12:07:58 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18lwz4-000KaJ-00 for v6ops@ops.ietf.org; Thu, 20 Feb 2003 12:07:54 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Thu, 20 Feb 2003 21:09:34 +0100 Message-ID: <037e01c2d91b$fb69e240$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <5.1.0.14.2.20030220110122.02bb9970@mail.windriver.com> Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item Date: Thu, 20 Feb 2003 21:09:31 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=NOSPAM_INC,RCVD_IN_RELAYS_ORDB_ORG,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree to consider this as a WG item. I will try to provide some comments directly to the design team mailing list (as indicated in the document), if any. Regards, Jordi ----- Original Message ----- From: "Margaret Wasserman" To: Sent: Thursday, February 20, 2003 5:46 PM Subject: Oops! Accepting Enterprise Scenarios as WG Item > > Hi All, > > I made a mistake last week and approved the publication > of the enterprise scenarios document as a WG work item > without actually checking with the WG first... Sorry. > > So, let's do this the right way... > > The enterprise scenarios/analysis team believes that > the current version of their scenarios document is ready > for consideration as a v6ops WG item. The document can > be found at: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-scenarios-00.txt > > This work is clearly within the charter of v6ops. > > Could members of the WG please comment on whether you > believe that this document should be accepted as a WG > item? In other words, does it take the right technical > direction, and would it serve as a useful basis for our > work? Is it sufficiently complete that it is ready for > WG review and refinement? > > If there is sufficient support to accept this document, > it will remain a WG work item. If not, we will move it > back to individual submission status. > > Sorry for my mistake and any confusion it may cause. > > Margaret > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Thu Feb 20 19:44: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 TAA04972 for ; Thu, 20 Feb 2003 19:44:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m1Kh-000B7D-00 for v6ops-data@psg.com; Thu, 20 Feb 2003 16:46:31 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18m1Kd-000B70-00 for v6ops@ops.ietf.org; Thu, 20 Feb 2003 16:46:28 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23949 for ; Thu, 20 Feb 2003 17:46:27 -0700 (MST) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAM00MX2VHD5O@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 20 Feb 2003 17:46:26 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAM0074AVHC9Q@mail.sun.net> for v6ops@ops.ietf.org; Thu, 20 Feb 2003 17:46:25 -0700 (MST) Date: Thu, 20 Feb 2003 16:47:32 -0800 From: Alain Durand Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item In-reply-to: <5.1.0.14.2.20030220110122.02bb9970@mail.windriver.com> To: Margaret Wasserman Cc: v6ops@ops.ietf.org Message-id: <0F7CBCE9-4536-11D7-BCB3-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Margaret, First, I would like to say that I appreciate the effort of the design team to address such a difficult issue. However, that said, I'm not very comfortable with this document. On one hand, it is badly needed and already very late, on the other hand, I'm not sure it is taking the right direction. I already have commented several times that this design team is way too 'transition tool' centric in its approach, somehow making the hidden assumption that solving the 'enterprise' case in the (yet to come) analysis/solution document will consist only of picking the 'right' transition tool developed by NGtrans. What I would like to see are things like the following instantiated for a set of 'typical' enterprise environment: - how does the internal networks looks like? - how is the networks are managed? (who is responsible, what is outsourced, is IT competent/reliable or not ...) - what are the procedure/tools in place to manage the network? (not only SNMP, but for example tools to create DNS zone files) - is the public internet used (via VPN...)? - what are the connections to the Internet? - Is the v4 address space private or public? - Is the v4 address space 'portable'? (hint: do they need portable v6 address space) - How much v4 address space is available? - Are they multi-homed? - how is security enforced? - how does the datacenter looks like if there is one? - what kind of applications are used in the Internet/intranet/extranets/...) (is it in-house code? is the source code available? is an Ipv6 version of the code available to buy?....) - how naming service/directory service is performed (two face DNS?) -... There is a little of that buried in section 4, variable description, but I think this document should really instantiate those variables and more (the ones I just described above for example, certainly much more) in a set of several 'typical' enterprise environments instead of focusing on cases describing how enterprises are thinking of deploying v6 at the IP level (section 5, which is basically which networks to connect) or abstract cases of transition mechanisms (section 6, point of transition methods) which belongs not in this document but in the solution document. With this in mind, I would not recommend the wg adopting this document. - Alain. On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman wrote: > > Hi All, > > I made a mistake last week and approved the publication > of the enterprise scenarios document as a WG work item > without actually checking with the WG first... Sorry. > > So, let's do this the right way... > > The enterprise scenarios/analysis team believes that > the current version of their scenarios document is ready > for consideration as a v6ops WG item. The document can > be found at: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-scenarios- > 00.txt > > This work is clearly within the charter of v6ops. > > Could members of the WG please comment on whether you > believe that this document should be accepted as a WG > item? In other words, does it take the right technical > direction, and would it serve as a useful basis for our > work? Is it sufficiently complete that it is ready for > WG review and refinement? > > If there is sufficient support to accept this document, > it will remain a WG work item. If not, we will move it > back to individual submission status. > > Sorry for my mistake and any confusion it may cause. > > Margaret > > > > > > > From owner-v6ops@ops.ietf.org Fri Feb 21 02:36: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 CAA22122 for ; Fri, 21 Feb 2003 02:36:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18m7kX-000AFY-00 for v6ops-data@psg.com; Thu, 20 Feb 2003 23:37:37 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18m7kU-000ADm-00 for v6ops@ops.ietf.org; Thu, 20 Feb 2003 23:37:34 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1L7ZOA20600; Fri, 21 Feb 2003 09:35:25 +0200 Date: Fri, 21 Feb 2003 09:35:24 +0200 (EET) From: Pekka Savola To: Ronald van der Pol cc: v6ops@ops.ietf.org Subject: Re: transition architecture discussion In-Reply-To: <20030211140206.GC692@rvdp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Sorry for the delay, vacation.. On Tue, 11 Feb 2003, Ronald van der Pol wrote: [...] > It would also be useful to find out why people are not deploying/ > using/requesting IPv6. Indeed. I think that for the most, it provides no added value, only complexity and a degradation of their existing usage practises (consider worse IPv6 used instead of better IPv4). I certainly use it nevertheless myself, and advocate it for testing/getting-used-to/pilot-deployments, but "real" uses have to wait for a bit, yet. > You restrict the architecture discussion to the "process of enabling > the use of IPv6". I don't think that's enough. I think it should > include at least the phase of a predominantly IPv6 internet. I agree: this should be mentioned. I just think that the "first phase", gaining enough momentum without hindering current IPv4 use _at all_, is the most important. There are some very usable strategies to go beyond that, but my belief is that "we shouldn't try to run before we can walk", so to speak. > Running > dual stack is not without any costs. It is easier and cheaper to run > either v4-only or v6-only. Yes, there are costs -- but they aren't as significant as some others, IMO. > If we don't _plan_ for a situation where > almost all traffic is v6 it won't happen. Well, I'm not so sure of that myself. Something will happen when we have enough momentum; when that happens, we have a possibility to affect how the long-term planning will go. > You mention the problems of enabling IPv6 for services and bad IPv6 > connectivity. That's true. I fully agree. But on the other hand > routing approved a lot when people started to use IPv6 on a daily > basis. This is just an operational issue. IPv4 networks can be > operated badly too. Yes -- it has gotten better, but nowhere near the levels I think I'd be confortable pushing IPv6 by-default to your avarage home users, for example. IPv6 connectivity doesn't need to perfect (IPv4 surely isn't), but there must not be a really significant difference, to most destinations anyway. > Therefore, I think we should not use separate domain names (like > ipv6.example.com) or prefer A over AAAA. This depends a lot on the transition "schedule". If you want to do things _now_, I would not advocate putting them to the same domain. If you can wait for 1-2 years and hope the connectivity is better (and after that, notice that it actually is good enough), then you can put them in the same names -- in 1-2 years. Preferring A over AAAA and solutions like these provide an entirely different deployment strategy: I'm not sure if it's a good one myself, either -- but if we fear the stable deployment would take a long time, it seems the only way to make (almost) everyone be safe enough to enable IPv6 out of the box. > We (operators, not the > IETF) should put effort in v6 connectivity with the same quality > as v4. Totally agree here, but I'm having hard time seeing that happening .. it's getting better, though. > With respect to tunneling, I think there are a couple of questions: > - Should we work on v6-in-v4 tunneling through v4 NATs (e.g. teredo)? > I can see its use in 3GPP, where the end user does not > have influence on the GGSN. I am not sure about home routers. > End users have the choice to buy an IPv6 enabled home router. As stated previously, I fear Teredo has become a hopeless effort :-(. However, it seems likely that NAT will remain for some time yet, so I'd personally pursue an approach to enable bi-directional tunneling through NAT, including heartbeating and other required features, but *no* bells and whistles. If the spec for this is over 10-15 pages, it's too long. > - Do we have a clear tunnel architecture? > I don't think so. We have 6to4 and configured tunnels. Is > 6to4 also for single end user systems? Do we agree on the > security issues of 6to4? Are tunnel brokers enough? Do we > need tsp? I agree the picture is not clear. There is some resistance to the tunnel broker model (as well as 6to4 model, of course). 6to4 is usable for single end user systems, certainly. > Do we need to work on translation (NAT-PT, SIIT, etc)? I am not sure. > At least we should discourage it because in many cases there are > better alternatives. I don't think such translation is useful in the generic case. In some specific cases, especially in ALG's or similar, it may be useful but that's usually really just "data payload relaying", nothing more. -- 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 Feb 21 07:57:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28228 for ; Fri, 21 Feb 2003 07:57:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mCmB-000L6d-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 04:59:39 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18mCm9-000L6M-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 04:59:37 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00367; Fri, 21 Feb 2003 05:59:35 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1LCxYP03656; Fri, 21 Feb 2003 13:59:34 +0100 (MET) Date: Fri, 21 Feb 2003 13:55:49 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT To: "Bound, Jim" Cc: v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B03240ED7@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Assume home routers want to support IPv6 and will eventually but won't > move until they believe it can be used over provider networks. > > Assume there is not enough Ipv4 address space for providers to give out > to all subscribers or cannot at reasonable cost. But they can give the > subscriber an IPv6 prefix. This means 6to4 or ISATAP won't work in this > scenario in the users home. I think what is needed are four things: 1. A method for the actual encapsulation IPv6 over UDP over IPv4 might be the easiest 2. A method to keep the NAT state up to date ICMPv6 echo's over the tunnel can do that 3. A method to detect when the NAT state has been lost or changed so that it can be restored (perhaps using the same mechanism in #4) 4. A mechanism to determine the tunnel endpoint (IP address and port) Note that draft-ietf-mobileip-nat-traversal-07.txt specifies how to do this when #4 is the Mobile IPv4 registration protocol. I think much of that draft can be used, and for #4 we can use either - TSP as for tunnel broker (makes sense when some authentication of the client is needed) - a DHCPv4 option (makes sense when DHCPv4 is already used by the ISP and no special authentication is needed for the tunnel) > The home user network encaps the IPv6 packet at NAT with Protocol ID > equivalent to "6". The provider then takes that packet and decaps at > their edge and uses native IPv6 or 6to4 to encap that packet to where > the IPv6 service is located. I realize this has many assumptions and I > would work on those with some other folks interested in this problem. Using a separate protocol ID implies that the NAT box has the functionality. Using UDP tunneling provides more flexibility since one can run tunneling across a NAT box one can't modify/control (like the one I have at home). Thus until the home router has been modified one could do this tunneling from the host at home. Erik From owner-v6ops@ops.ietf.org Fri Feb 21 08:21:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28692 for ; Fri, 21 Feb 2003 08:21:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mDAG-000M4e-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 05:24:32 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18mDAD-000M4S-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 05:24:29 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D40361DD8; Fri, 21 Feb 2003 08:24:28 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 08:24:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Oops! Accepting Enterprise Scenarios as WG Item Date: Fri, 21 Feb 2003 08:24:28 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0917@tayexc13.americas.cpqcorp.net> Thread-Topic: Oops! Accepting Enterprise Scenarios as WG Item Thread-Index: AcLZQyaOMzXExvduR2uXgLQmsRLifgAaGgzA From: "Bound, Jim" To: "Alain Durand" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 21 Feb 2003 13:24:28.0740 (UTC) FILETIME=[8FA5B840:01C2D9AC] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA28692 Alain, We can respond as we did in Atlanta but with new data point. We are building the architecture for what you ask with the scenarios. THe chairs, the area directors, and many in the working group, asked us to not go into the weeds as you suggest below of solving the problems or identifying details. It is more I the spirit of Pekka's transition architecture of late, unmanaged, and 3gpp scenarios that also did not do this. It seems to me the working group supports those initial strategies too. I certainly do with my ACK to Margaret to move to IESG call. We will do a follow on doc I believe Margaret is calling the analysis doc and even start it with overlap as umanaged did to reach time-to-market reqs of the working group in this area. What I suggest is we can look at our list for this phase and see if we missed a category but I don't think so but rather as we fill out the sections we can consider your list from an architectural (pekkas draft) use for scenarios. Yanick has assigned each member of the team a section I don't think we will be done with next steps by SanFrancisco but clearly close after. I would suggest unless we hear from others your input is important but will not change our direction and I urge the working group to support this as working group item because we have much time invested here and asking us to invest more with out making this a working group item will be tough for us. Thanks /jim > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: Thursday, February 20, 2003 7:48 PM > To: Margaret Wasserman > Cc: v6ops@ops.ietf.org > Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item > > > Margaret, > > First, I would like to say that I appreciate the effort of > the design team to address such a difficult issue. > > However, that said, I'm not very comfortable with this > document. On one hand, it is badly needed and already very > late, on the other hand, I'm not sure it is taking the right > direction. > > I already have commented several times that this design team > is way too 'transition tool' centric in its approach, somehow making > the hidden > assumption that solving the 'enterprise' case in the (yet to come) > analysis/solution > document will consist only of picking the 'right' transition tool > developed by NGtrans. > > What I would like to see are things like the following > instantiated for a set of 'typical' enterprise environment: > > - how does the internal networks looks like? > - how is the networks are managed? > (who is responsible, what is outsourced, is IT > competent/reliable or > not ...) > - what are the procedure/tools in place to manage the network? > (not only SNMP, but for example tools to create DNS zone files) > - is the public internet used (via VPN...)? > - what are the connections to the Internet? > - Is the v4 address space private or public? > - Is the v4 address space 'portable'? (hint: do they need > portable v6 > address space) > - How much v4 address space is available? > - Are they multi-homed? > - how is security enforced? > - how does the datacenter looks like if there is one? > - what kind of applications are used in the > Internet/intranet/extranets/...) > (is it in-house code? is the source code available? is an Ipv6 > version of the > code available to buy?....) > - how naming service/directory service is performed (two face > DNS?) -... > > > > There is a little of that buried in section 4, variable > description, but I think this document should really > instantiate those variables and more (the ones I just > described above for example, certainly much > more) > in a set of several 'typical' enterprise environments instead of > focusing > on cases describing how enterprises are thinking of deploying > v6 at the > IP level > (section 5, which is basically which networks to connect) or > abstract > cases of transition mechanisms > (section 6, point of transition methods) which belongs not in this > document > but in the solution document. > > With this in mind, I would not recommend the wg adopting this > document. > > - Alain. > > > > > On Thursday, February 20, 2003, at 08:46 AM, Margaret > Wasserman wrote: > > > > > Hi All, > > > > I made a mistake last week and approved the publication > > of the enterprise scenarios document as a WG work item without > > actually checking with the WG first... Sorry. > > > > So, let's do this the right way... > > > > The enterprise scenarios/analysis team believes that > > the current version of their scenarios document is ready > > for consideration as a v6ops WG item. The document can > > be found at: > > > > > http://www.ietf.org/internet-drafts/draft-> ietf-v6ops-entnet-scenarios- > > 00.txt > > > > This work is clearly within the charter of v6ops. > > > > Could members of the WG please comment on whether you > > believe that this document should be accepted as a WG > > item? In other words, does it take the right technical > direction, and > > would it serve as a useful basis for our work? Is it sufficiently > > complete that it is ready for WG review and refinement? > > > > If there is sufficient support to accept this document, > > it will remain a WG work item. If not, we will move it > > back to individual submission status. > > > > Sorry for my mistake and any confusion it may cause. > > > > Margaret > > > > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Fri Feb 21 08:41: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 IAA29201 for ; Fri, 21 Feb 2003 08:41:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mDTc-000Mqt-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 05:44:32 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 18mDTT-000Mqd-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 05:44:23 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1LDiCZk093158; Fri, 21 Feb 2003 14:44:14 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1LDi9cP248936; Fri, 21 Feb 2003 14:44:10 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48196 from ; Fri, 21 Feb 2003 14:44:07 +0100 Message-Id: <3E562CF3.4A35DBA2@hursley.ibm.com> Date: Fri, 21 Feb 2003 14:43:15 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Alain Durand Cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item References: <0F7CBCE9-4536-11D7-BCB3-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I share some of Alain's concerns. I think that enterprise customers will not look at IPv6 as a goal in itself, but as a tool for certain business scenarios they need to support. So I think the draft should start with a set of business scenarios, and then maybe continue with the technology scenarios (plus analysis of which business scenarios they support). At the end, it would then be possible to deduce which technology scenarios are useful. However, I wouldn't advocate pulling back the draft. I think we should just ask the team to go back and develop the business scenarios (or use cases, if you prefer the term). And if necessary, pull in more expertise for this (e.g. to cover Big Iron and major data centers and hosting centers). Brian Alain Durand wrote: > > Margaret, > > First, I would like to say that I appreciate the effort of the > design team to address such a difficult issue. > > However, that said, I'm not very comfortable with this document. > On one hand, it is badly needed and already very late, > on the other hand, I'm not sure it is taking the right direction. > > I already have commented several times that this design team > is way too 'transition tool' centric in its approach, somehow making > the hidden > assumption that solving the 'enterprise' case in the (yet to come) > analysis/solution > document will consist only of picking the 'right' transition tool > developed by NGtrans. > > What I would like to see are things like the following > instantiated for a set of 'typical' enterprise environment: > > - how does the internal networks looks like? > - how is the networks are managed? > (who is responsible, what is outsourced, is IT competent/reliable or > not ...) > - what are the procedure/tools in place to manage the network? > (not only SNMP, but for example tools to create DNS zone files) > - is the public internet used (via VPN...)? > - what are the connections to the Internet? > - Is the v4 address space private or public? > - Is the v4 address space 'portable'? (hint: do they need portable v6 > address space) > - How much v4 address space is available? > - Are they multi-homed? > - how is security enforced? > - how does the datacenter looks like if there is one? > - what kind of applications are used in the > Internet/intranet/extranets/...) > (is it in-house code? is the source code available? is an Ipv6 > version of the > code available to buy?....) > - how naming service/directory service is performed (two face DNS?) > -... > > There is a little of that buried in section 4, variable description, > but I think this document should really instantiate those variables > and more (the ones I just described above for example, certainly much > more) > in a set of several 'typical' enterprise environments instead of > focusing > on cases describing how enterprises are thinking of deploying v6 at the > IP level > (section 5, which is basically which networks to connect) or abstract > cases of transition mechanisms > (section 6, point of transition methods) which belongs not in this > document > but in the solution document. > > With this in mind, I would not recommend the wg adopting this document. > > - Alain. > > On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman wrote: > > > > > Hi All, > > > > I made a mistake last week and approved the publication > > of the enterprise scenarios document as a WG work item > > without actually checking with the WG first... Sorry. > > > > So, let's do this the right way... > > > > The enterprise scenarios/analysis team believes that > > the current version of their scenarios document is ready > > for consideration as a v6ops WG item. The document can > > be found at: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-scenarios- > > 00.txt > > > > This work is clearly within the charter of v6ops. > > > > Could members of the WG please comment on whether you > > believe that this document should be accepted as a WG > > item? In other words, does it take the right technical > > direction, and would it serve as a useful basis for our > > work? Is it sufficiently complete that it is ready for > > WG review and refinement? > > > > If there is sufficient support to accept this document, > > it will remain a WG work item. If not, we will move it > > back to individual submission status. > > > > Sorry for my mistake and any confusion it may cause. > > > > Margaret From owner-v6ops@ops.ietf.org Fri Feb 21 08:42: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 IAA29241 for ; Fri, 21 Feb 2003 08:42:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mDV4-000Mvv-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 05:46:02 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18mDV2-000Mvi-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 05:46:00 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10810; Fri, 21 Feb 2003 06:45:57 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1LDjuP07038; Fri, 21 Feb 2003 14:45:56 +0100 (MET) Date: Fri, 21 Feb 2003 14:42:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT To: "Bound, Jim" Cc: Jeroen Massar , JORDI PALET MARTINEZ , v6ops@ops.ietf.org, Alain Durand , alh-ietf@tndh.net In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B034C07B4@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > If we have tunnel brokers we don 't need teredo right? That's my take > now. Agreed in principle. Two things though: Firstly, for the access router to ISP tunnel config something simpler (like a DHCPv4 option) might make sense - depends on what type of authentication the ISP wants to do specifically for the IPv6 tunnel. If it is sufficient for the ISP to check that the IPv4 source is one of its customers then the TSP authentication features and flexibility isn't needed. Secondly, I've been told that tunnel broker can work trough NAT but the RFC (RFC 3053) says: 3. Known limitations This mechanism may not work if the user is using private IPv4 addresses behind a NAT box. Thus I think it would be useful to have a specification on how tunnel broker works across a NAT. Erik From owner-v6ops@ops.ietf.org Fri Feb 21 08:57: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 IAA29499 for ; Fri, 21 Feb 2003 08:57:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mDiJ-000NUJ-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 05:59:43 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18mDiG-000NU6-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 05:59:40 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 38C1B8BC0; Fri, 21 Feb 2003 08:59:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 08:59:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Oops! Accepting Enterprise Scenarios as WG Item Date: Fri, 21 Feb 2003 08:59:38 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03240F39@tayexc13.americas.cpqcorp.net> Thread-Topic: Oops! Accepting Enterprise Scenarios as WG Item Thread-Index: AcLZr5oKiJIrzg6SQjivU7oQ7CQmvwAAHoQw From: "Bound, Jim" To: "Brian E Carpenter" , "Alain Durand" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 21 Feb 2003 13:59:38.0964 (UTC) FILETIME=[79705940:01C2D9B1] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29499 Brian, > I share some of Alain's concerns. I think that enterprise > customers will not look at IPv6 as a goal in itself, but as a > tool for certain business scenarios they need to support. We discussed this on the team. I agree with business justification. > So > I think the draft should start with a set of business > scenarios, and then maybe continue with the technology > scenarios (plus analysis of which business scenarios they > support). At the end, it would then be possible to deduce > which technology scenarios are useful. We discussed this and this is not an IETF mission or purpose. The business scenarios are not common and will vary. If we pick X business scenarios and leave out Y then the Y types will not be happy. This is not a goal of any scenario document unmanaged, ISP, or 3gpp. So I would suggest that this is not on any of the design teams plates. If your correct and I do not believe you are to add this then none of the current scenarios should be moved to the IESG. > > However, I wouldn't advocate pulling back the draft. I think > we should just ask the team to go back and develop the > business scenarios (or use cases, if you prefer the term). > And if necessary, pull in more expertise for this (e.g. to > cover Big Iron and major data centers and hosting centers). We have that expertise for "operations" and will not focus on data center or big iron. Reason is that one persons belief of data center or big iron is not the same as anothers. In the follow on draft analysis of the enterprise which will be technical will have assumptions that a "data center" could use. That being said I would suggest the IPv6 Forum, Asian IPv6 Task Force, North American IPv6 Task Force have the business scenarios and cases done. It is also those forum charter not the IETF. Also would suggest if we want to focus on the data center specifically we should build a separate draft and set of work to discuss first what it means and then execute on those assumptions it should not be part of the enterprise work. This team and work should be the dumping ground for all the things we have to do that are not covered in the other specs. Or else we will be here for 5 years working on this and this team is not going to do that. Like DNS is the dumping ground for anything we cannot figure out in our community to store data I would suggest and that is wrong too. Regards, /jim > > Brian > > Alain Durand wrote: > > > > Margaret, > > > > First, I would like to say that I appreciate the effort of > the design > > team to address such a difficult issue. > > > > However, that said, I'm not very comfortable with this document. On > > one hand, it is badly needed and already very late, on the > other hand, > > I'm not sure it is taking the right direction. > > > > I already have commented several times that this design team is way > > too 'transition tool' centric in its approach, somehow making the > > hidden assumption that solving the 'enterprise' case in the (yet to > > come) analysis/solution > > document will consist only of picking the 'right' transition tool > > developed by NGtrans. > > > > What I would like to see are things like the following instantiated > > for a set of 'typical' enterprise environment: > > > > - how does the internal networks looks like? > > - how is the networks are managed? > > (who is responsible, what is outsourced, is IT > competent/reliable > > or not ...) > > - what are the procedure/tools in place to manage the network? > > (not only SNMP, but for example tools to create DNS zone files) > > - is the public internet used (via VPN...)? > > - what are the connections to the Internet? > > - Is the v4 address space private or public? > > - Is the v4 address space 'portable'? (hint: do they need > portable v6 > > address space) > > - How much v4 address space is available? > > - Are they multi-homed? > > - how is security enforced? > > - how does the datacenter looks like if there is one? > > - what kind of applications are used in the > > Internet/intranet/extranets/...) > > (is it in-house code? is the source code available? is an Ipv6 > > version of the > > code available to buy?....) > > - how naming service/directory service is performed (two face DNS?) > > -... > > > > There is a little of that buried in section 4, variable > description, > > but I think this document should really instantiate those variables > > and more (the ones I just described above for example, > certainly much > > more) > > in a set of several 'typical' enterprise environments instead of > > focusing on cases describing how enterprises are thinking > of deploying > > v6 at the IP level > > (section 5, which is basically which networks to connect) > or abstract > > cases of transition mechanisms > > (section 6, point of transition methods) which belongs not in this > > document > > but in the solution document. > > > > With this in mind, I would not recommend the wg adopting this > > document. > > > > - Alain. > > > > On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman > > wrote: > > > > > > > > Hi All, > > > > > > I made a mistake last week and approved the publication > > > of the enterprise scenarios document as a WG work item without > > > actually checking with the WG first... Sorry. > > > > > > So, let's do this the right way... > > > > > > The enterprise scenarios/analysis team believes that > > > the current version of their scenarios document is ready for > > > consideration as a v6ops WG item. The document can be found at: > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-sc enario > > s- > > 00.txt > > > > This work is clearly within the charter of v6ops. > > > > Could members of the WG please comment on whether you believe that > > this document should be accepted as a WG item? In other words, does > > it take the right technical direction, and would it serve as a > > useful basis for our work? Is it sufficiently complete that it is > > ready for WG review and refinement? > > > > If there is sufficient support to accept this document, > > it will remain a WG work item. If not, we will move it back to > > individual submission status. > > > > Sorry for my mistake and any confusion it may cause. > > > > Margaret From owner-v6ops@ops.ietf.org Fri Feb 21 09:04: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 JAA00215 for ; Fri, 21 Feb 2003 09:04:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mDph-000NsP-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 06:07:21 -0800 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 18mDpe-000Nr2-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 06:07:18 -0800 Received: from localhost (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id h1LE4Du78916; Fri, 21 Feb 2003 09:04:13 -0500 (EST) Date: Fri, 21 Feb 2003 09:04:11 -0500 From: Marc Blanchet To: Erik Nordmark , "Bound, Jim" cc: Jeroen Massar , JORDI PALET MARTINEZ , v6ops@ops.ietf.org, Alain Durand , alh-ietf@tndh.net Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Message-ID: <547440000.1045836251@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/3.0.0b12 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00215 -- vendredi, février 21, 2003 14:42:11 +0100 Erik Nordmark wrote/a écrit: >> If we have tunnel brokers we don 't need teredo right? That's my take >> now. > > Agreed in principle. > > Two things though: > Firstly, for the access router to ISP tunnel config > something simpler (like a DHCPv4 option) might make sense - depends > on what type of authentication the ISP wants to do specifically > for the IPv6 tunnel. If it is sufficient for the ISP to check that > the IPv4 source is one of its customers then the TSP authentication > features and flexibility isn't needed. > > Secondly, > I've been told that tunnel broker can work trough NAT but the RFC > (RFC 3053) says: > 3. Known limitations > > This mechanism may not work if the user is using private IPv4 > addresses behind a NAT box. > > Thus I think it would be useful to have a specification on how tunnel > broker works across a NAT. done: draft-parent-blanchet-blanchet-ngtrans-tsp-teredo-00.txt (forget the teredo in the filename, it is more appropriate to say: udp encapsulation) Marc. > > Erik > From owner-v6ops@ops.ietf.org Fri Feb 21 09:16: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 JAA00831 for ; Fri, 21 Feb 2003 09:16:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mE1B-000OKo-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 06:19:13 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18mE19-000OKb-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 06:19:11 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id AB0B1544F; Fri, 21 Feb 2003 09:19:10 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 09:19:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Oops! Accepting Enterprise Scenarios as WG Item Date: Fri, 21 Feb 2003 09:19:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C091C@tayexc13.americas.cpqcorp.net> Thread-Topic: Oops! Accepting Enterprise Scenarios as WG Item Thread-Index: AcLZr5oKiJIrzg6SQjivU7oQ7CQmvwAAHoQwAAD/DzA= From: "Bound, Jim" To: "Bound, Jim" , "Brian E Carpenter" , "Alain Durand" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 21 Feb 2003 14:19:10.0506 (UTC) FILETIME=[33BB78A0:01C2D9B4] X-Spam-Status: No, hits=2.2 required=5.0 tests=FROM_AND_TO_SAME_6,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00831 > This team and work should be the dumping ground for all the ^^ NOT be the dumping ground ................ /jim From owner-v6ops@ops.ietf.org Fri Feb 21 09:16: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 JAA00852 for ; Fri, 21 Feb 2003 09:16:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mE2G-000OQ2-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 06:20:20 -0800 Received: from cust.92.136.adsl.cistron.nl ([195.64.92.136] helo=purgatory.unfix.org) by psg.com with esmtp (Exim 3.36 #1) id 18mE2C-000OPB-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 06:20:17 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 341917A40; Fri, 21 Feb 2003 15:20:09 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E347C77EB; Fri, 21 Feb 2003 15:19:56 +0100 (CET) From: "Jeroen Massar" To: "'Erik Nordmark'" , "'Bound, Jim'" Cc: "'JORDI PALET MARTINEZ'" , , "'Alain Durand'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 15:20:26 +0100 Organization: Unfix Message-ID: <000a01c2d9b4$62ee4bc0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00852 Erik Nordmark [mailto:Erik.Nordmark@sun.com] wrote: > > If we have tunnel brokers we don 't need teredo right? > That's my take > > now. > > Agreed in principle. > > Two things though: > Firstly, for the access router to ISP tunnel config > something simpler (like a DHCPv4 option) might make sense - depends > on what type of authentication the ISP wants to do specifically > for the IPv6 tunnel. If it is sufficient for the ISP to check that > the IPv4 source is one of its customers then the TSP authentication > features and flexibility isn't needed. > > Secondly, > I've been told that tunnel broker can work trough NAT but the RFC > (RFC 3053) says: > 3. Known limitations > > This mechanism may not work if the user is using private IPv4 > addresses behind a NAT box. > > Thus I think it would be useful to have a specification on how tunnel > broker works across a NAT. The only thing is that the NAT box needs to know where to send incoming proto-41 packets to. - Some NAT boxes can be configured with a 'default'. Those boxes will then forward any unrelated traffic to that default IP. - Some others explicitly allow to NAT proto-41, or to match the source of the tunnelbroker and forward any traffic from that IP to the endpoint. - And other NAT boxes can base the real destination based on 'established' rules, though this does require that the local machine keeps sending traffic to the tunnel broker to keep the tunnel in the NAT table. Configuration for the local host changes only fractionally; Eg, if we've got a tunnel from 195.64.92.136 (my machine) to 212.19.192.219 (IPng / nlams02.sixxs.net) normally I would use: iface ipng inet6 v4tunnel address 3ffe:8114:1000::27 netmask 127 local 195.64.92.136 endpoint 212.19.192.219 ttl 64 When using any of the three options from above you would need: iface ipng inet6 v4tunnel address 3ffe:8114:1000::27 netmask 127 local 10.100.13.66 endpoint 212.19.192.219 ttl 64 The NAT box will rewrite the 10.100.13.66 to 195.64.92.136 and forward the packets to the TB. On the way back from the TB to the 10.100.13.66 address, the TB will actually only know about 195.64.92.136 and send it there, which is the NAT box which will rewrite the destination of the packet to 10.100.13.66 and pass it to the local host. Note that under some OS's you can avoid setting the local endpoint. Greets, Jeroen From owner-v6ops@ops.ietf.org Fri Feb 21 09:19: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 JAA00938 for ; Fri, 21 Feb 2003 09:19:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mE4b-000OYW-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 06:22:45 -0800 Received: from [3ffe:8114:1000::27] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18mE4Y-000OYG-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 06:22:42 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 84AF87915; Fri, 21 Feb 2003 15:22:34 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id F2AEF77ED; Fri, 21 Feb 2003 15:22:25 +0100 (CET) From: "Jeroen Massar" To: "'Marc Blanchet'" , "'Erik Nordmark'" , "'Bound, Jim'" Cc: "'JORDI PALET MARTINEZ'" , , "'Alain Durand'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 15:22:56 +0100 Organization: Unfix Message-ID: <001201c2d9b4$bbb9eca0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <547440000.1045836251@classic.viagenie.qc.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00938 Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca] wrote: > -- vendredi, février 21, 2003 14:42:11 +0100 Erik Nordmark > wrote/a écrit: > > >> If we have tunnel brokers we don 't need teredo right? > That's my take > >> now. > > > > Agreed in principle. > done: > draft-parent-blanchet-blanchet-ngtrans-tsp-teredo-00.txt > > (forget the teredo in the filename, it is more appropriate to say: udp > encapsulation) You probably mean: draft-parent-blanchet-ngtrans-tsp-teredo-00.txt ;) Greets, Jeroen From owner-v6ops@ops.ietf.org Fri Feb 21 10:27:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03411 for ; Fri, 21 Feb 2003 10:27:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mF6p-0001k0-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 07:29:07 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18mF6j-0001jo-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 07:29:03 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1LFSvSb036026; Fri, 21 Feb 2003 16:28:57 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1LFSvcP206404; Fri, 21 Feb 2003 16:28:57 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20104 from ; Fri, 21 Feb 2003 16:28:55 +0100 Message-Id: <3E564583.41052985@hursley.ibm.com> Date: Fri, 21 Feb 2003 16:28:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: Alain Durand , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item References: <9C422444DE99BC46B3AD3C6EAFC9711B034C091C@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I preferred the first version :-) Brian "Bound, Jim" wrote: > > > This team and work should be the dumping ground for all the > ^^ NOT be the dumping ground ................ > /jim From owner-v6ops@ops.ietf.org Fri Feb 21 10:29: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 KAA03475 for ; Fri, 21 Feb 2003 10:29:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mFAk-0001s8-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 07:33:10 -0800 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 18mFAa-0001rt-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 07:33:00 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11449; Fri, 21 Feb 2003 08:32:51 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1LFWnP19984; Fri, 21 Feb 2003 16:32:49 +0100 (MET) Date: Fri, 21 Feb 2003 16:29:05 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT To: Jeroen Massar Cc: "'Erik Nordmark'" , "'Bound, Jim'" , "'JORDI PALET MARTINEZ'" , v6ops@ops.ietf.org, "'Alain Durand'" , alh-ietf@tndh.net In-Reply-To: "Your message with ID" <000a01c2d9b4$62ee4bc0$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The only thing is that the NAT box needs to know where to send incoming > proto-41 packets to. > > - Some NAT boxes can be configured with a 'default'. > Those boxes will then forward any unrelated traffic to that default > IP. That's nice for those that have control of the NAT box. The Telco that provides me service at home provides me with a NAT box that they control - and they are uninterested in doing anything special. I can't bypass/replace the NAT box because it speaks some odd and probably proprietary stuff on the other side (it's an ISDN line). So I prefer solutions that don't have to rely on configuration in the NAT box yet are simpler than Teredo. Erik From owner-v6ops@ops.ietf.org Fri Feb 21 10:55: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 KAA04469 for ; Fri, 21 Feb 2003 10:55:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mFZh-0003Cc-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 07:58:57 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 18mFZb-0003Br-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 07:58:52 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h1LFwRWT055434; Fri, 21 Feb 2003 16:58:29 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h1LFwLsb106034; Fri, 21 Feb 2003 16:58:22 +0100 Received: from dhcp23-27.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA54806 from ; Fri, 21 Feb 2003 16:58:13 +0100 Message-Id: <3E564C61.3BDAF59A@hursley.ibm.com> Date: Fri, 21 Feb 2003 16:57:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: Alain Durand , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item References: <9C422444DE99BC46B3AD3C6EAFC9711B03240F39@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.3 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, I think you're misinterpreting my use of the b-word. I'm not (of course) talking about business models. I'm talking about scenarios. For example: A bank running a massive ATM network with some number of gazillions of transactions per second against central databases. An engineering company running distributed design systems across 20 different sites around the world. A pharmaceutical company running both compute-intensive and ERP applications. etc. Each one fleshed out with how they do things today, and what they want to achieve by adding IPv6. Brian "Bound, Jim" wrote: > > Brian, > > > I share some of Alain's concerns. I think that enterprise > > customers will not look at IPv6 as a goal in itself, but as a > > tool for certain business scenarios they need to support. > > We discussed this on the team. I agree with business justification. > > > So > > I think the draft should start with a set of business > > scenarios, and then maybe continue with the technology > > scenarios (plus analysis of which business scenarios they > > support). At the end, it would then be possible to deduce > > which technology scenarios are useful. > > We discussed this and this is not an IETF mission or purpose. The > business scenarios are not common and will vary. If we pick X business > scenarios and leave out Y then the Y types will not be happy. This is > not a goal of any scenario document unmanaged, ISP, or 3gpp. So I would > suggest that this is not on any of the design teams plates. If your > correct and I do not believe you are to add this then none of the > current scenarios should be moved to the IESG. > > > > > However, I wouldn't advocate pulling back the draft. I think > > we should just ask the team to go back and develop the > > business scenarios (or use cases, if you prefer the term). > > And if necessary, pull in more expertise for this (e.g. to > > cover Big Iron and major data centers and hosting centers). > > We have that expertise for "operations" and will not focus on data > center or big iron. Reason is that one persons belief of data center or > big iron is not the same as anothers. In the follow on draft analysis of > the enterprise which will be technical will have assumptions that a > "data center" could use. > > That being said I would suggest the IPv6 Forum, Asian IPv6 Task Force, > North American IPv6 Task Force have the business scenarios and cases > done. It is also those forum charter not the IETF. > > Also would suggest if we want to focus on the data center specifically > we should build a separate draft and set of work to discuss first what > it means and then execute on those assumptions it should not be part of > the enterprise work. > > This team and work should be the dumping ground for all the things we > have to do that are not covered in the other specs. Or else we will be > here for 5 years working on this and this team is not going to do that. > Like DNS is the dumping ground for anything we cannot figure out in our > community to store data I would suggest and that is wrong too. > > Regards, > /jim > > > > Brian > > > > Alain Durand wrote: > > > > > > Margaret, > > > > > > First, I would like to say that I appreciate the effort of > > the design > > > team to address such a difficult issue. > > > > > > However, that said, I'm not very comfortable with this document. On > > > one hand, it is badly needed and already very late, on the > > other hand, > > > I'm not sure it is taking the right direction. > > > > > > I already have commented several times that this design team is way > > > too 'transition tool' centric in its approach, somehow making the > > > hidden assumption that solving the 'enterprise' case in the (yet to > > > come) analysis/solution > > > document will consist only of picking the 'right' transition tool > > > developed by NGtrans. > > > > > > What I would like to see are things like the following instantiated > > > for a set of 'typical' enterprise environment: > > > > > > - how does the internal networks looks like? > > > - how is the networks are managed? > > > (who is responsible, what is outsourced, is IT > > competent/reliable > > > or not ...) > > > - what are the procedure/tools in place to manage the network? > > > (not only SNMP, but for example tools to create DNS zone files) > > > - is the public internet used (via VPN...)? > > > - what are the connections to the Internet? > > > - Is the v4 address space private or public? > > > - Is the v4 address space 'portable'? (hint: do they need > > portable v6 > > > address space) > > > - How much v4 address space is available? > > > - Are they multi-homed? > > > - how is security enforced? > > > - how does the datacenter looks like if there is one? > > > - what kind of applications are used in the > > > Internet/intranet/extranets/...) > > > (is it in-house code? is the source code available? is an Ipv6 > > > version of the > > > code available to buy?....) > > > - how naming service/directory service is performed (two face DNS?) > > > -... > > > > > > There is a little of that buried in section 4, variable > > description, > > > but I think this document should really instantiate those variables > > > and more (the ones I just described above for example, > > certainly much > > > more) > > > in a set of several 'typical' enterprise environments instead of > > > focusing on cases describing how enterprises are thinking > > of deploying > > > v6 at the IP level > > > (section 5, which is basically which networks to connect) > > or abstract > > > cases of transition mechanisms > > > (section 6, point of transition methods) which belongs not in this > > > document > > > but in the solution document. > > > > > > With this in mind, I would not recommend the wg adopting this > > > document. > > > > > > - Alain. > > > > > > On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > I made a mistake last week and approved the publication > > > > of the enterprise scenarios document as a WG work item without > > > > actually checking with the WG first... Sorry. > > > > > > > > So, let's do this the right way... > > > > > > > > The enterprise scenarios/analysis team believes that > > > > the current version of their scenarios document is ready for > > > > consideration as a v6ops WG item. The document can be found at: > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-sc > enario > > > s- > > > 00.txt > > > > > > This work is clearly within the charter of v6ops. > > > > > > Could members of the WG please comment on whether you believe that > > > this document should be accepted as a WG item? In other words, does > > > > it take the right technical direction, and would it serve as a > > > useful basis for our work? Is it sufficiently complete that it is > > > ready for WG review and refinement? > > > > > > If there is sufficient support to accept this document, > > > it will remain a WG work item. If not, we will move it back to > > > individual submission status. > > > > > > Sorry for my mistake and any confusion it may cause. > > > > > > Margaret From owner-v6ops@ops.ietf.org Fri Feb 21 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 LAA04773 for ; Fri, 21 Feb 2003 11:03:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mFhH-0003bg-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 08:06:47 -0800 Received: from [3ffe:8114:1000::27] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18mFh7-0003bI-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 08:06:37 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 9DB0D7915; Fri, 21 Feb 2003 17:06:32 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 665AC77ED; Fri, 21 Feb 2003 17:06:27 +0100 (CET) From: "Jeroen Massar" To: "'Erik Nordmark'" Cc: "'Marc Blanchet'" , Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 17:06:58 +0100 Organization: Unfix Message-ID: <001e01c2d9c3$43d0e950$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA04773 Erik Nordmark wrote: > > The only thing is that the NAT box needs to know where to > send incoming > > proto-41 packets to. > > > > - Some NAT boxes can be configured with a 'default'. > > Those boxes will then forward any unrelated traffic to > that default > > IP. > > That's nice for those that have control of the NAT box. > The Telco that provides me service at home provides me with a NAT box > that they control - and they are uninterested in doing > anything special. > I can't bypass/replace the NAT box because it speaks some odd > and probably proprietary stuff on the other side (it's an ISDN line). > > So I prefer solutions that don't have to rely on configuration in > the NAT box yet are simpler than Teredo. Make a ssh/pptp/vtund//* tunnel to the outside and route your packets over there. These mechanisms then ofcourse should be supplied and supported by the Tunnel Broker in question. So if we want a good deployment we need to support all of these options (unfortunatly). Marc can you create such TSP drafts ? Eg: draft-parent-blanchet-ngtrans-tsp--00.txt Which means that an external application is needed for tunneling the packets to the tunnel broker. application ::= ssh|pptp|vtund|httptunnel| Some networks unfortunatly will want to avoid the possibility of using them as a 'transit' service only, eg tunneling to a friendly AS and then routing a own prefix over that, basically only using the ISP's IP for the tunnel. Sidenote: IMHO you don't have a complete IPv4 internet connection either as with your current setup you can't do most thing that have an embedded IP in the packets (read: Netmeeting). Also setting up your own SSH, apache, gameserver etc will not work :( If I had a chance of ISP's in your situation I would surely not go for them, I hate NAT's and I require at least one public IPv4 thats completely unfiltered. In your current situation they could have put you all their customers behind a big rfc1918 subnet and NAT there too and that is what I call localnet access (with an internet gate) and not internet access. Greets, Jeroen From owner-v6ops@ops.ietf.org Fri Feb 21 11:16: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 LAA05227 for ; Fri, 21 Feb 2003 11:16:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mFu1-0004P9-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 08:19:57 -0800 Received: from [3ffe:8114:1000::27] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18mFtn-0004Ou-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 08:19:43 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 8470E7915; Fri, 21 Feb 2003 17:19:40 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 358C677F4; Fri, 21 Feb 2003 17:19:33 +0100 (CET) From: "Jeroen Massar" To: "'Paul Timmins'" Cc: Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 17:20:05 +0100 Organization: Unfix Message-ID: <002601c2d9c5$1907ee10$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <1045842993.859.7.camel@pikachu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=-2.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05227 Paul Timmins [mailto:paul@timmins.net] wrote: > On Fri, 2003-02-21 at 10:29, Erik Nordmark wrote: > > That's nice for those that have control of the NAT box. > > The Telco that provides me service at home provides me with > a NAT box > > that they control - and they are uninterested in doing > anything special. > > I can't bypass/replace the NAT box because it speaks some > odd and probably > > proprietary stuff on the other side (it's an ISDN line). > > > > So I prefer solutions that don't have to rely on configuration in > > the NAT box yet are simpler than Teredo. > > I agree here as well. I've seen -alot- of firewalls that either block, > or don't statefully forward proto-41. Even if they did, that > limits IPv6 > to one end user behind the NAT. If I was using this at a Mariott for > example, they NAT the users of their in room ethernet. I'd be > disappointed if someone else was using v6 tunneling in the hotel, > because it means I couldn't (Assuming they forward proto-41 to begin > with). IMHO we should differentiate between places where the Network Administrator allows such activities and places where those activities are not allowed. If the NetAdmin doesn't want to cooperate you got a big problem which can only be solved by playing naughty sly old fox. A rule of thumb is that as long as you are not in control of the local infrastructure you are not the network administrator and should abide by the policies which are laid upon you how freakish they might be. You are a guest of the network... Yes, I know that sounds bad and yes it will stop 'deployment' but if you want IPv6 at that place you might better start talking to the people administrating that network and educate them so next time you are there they might have it for you as a bonus. You should note that you are opening up the local network for a firewall bypass. And that is not always a wanted situation. You can protect yourself, but are you also protecting other people eg if you announce a /64 with RA and then nicely route over the tunnel ? Clued people can always make a hole in the network if they want it or not, but non-clued people will just break things as they are unaware of the implications that arise from it. Also checking the subject, we where talking about "IPv6 Home Use", in that case you usually are the 'owner' of the IPv4 endpoint... Though for both problems a ssh/pptp and other tunneling solutions could work out just as well, see the other message to Erik. Greets, Jeroen From owner-v6ops@ops.ietf.org Fri Feb 21 11:49: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 LAA06522 for ; Fri, 21 Feb 2003 11:49:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mGP9-00068N-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 08:52:07 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18mGP0-00067e-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 08:51:58 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29294; Fri, 21 Feb 2003 08:51:56 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1LGpsP00161; Fri, 21 Feb 2003 17:51:55 +0100 (MET) Date: Fri, 21 Feb 2003 17:48:10 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT To: Jeroen Massar Cc: "'Erik Nordmark'" , "'Marc Blanchet'" , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <001e01c2d9c3$43d0e950$210d640a@unfix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > IMHO you don't have a complete IPv4 internet connection > either as with your current setup you can't do most thing that > have an embedded IP in the packets (read: Netmeeting). Also > setting up your own SSH, apache, gameserver etc will not work :( What, I thought the Internet = web page access :-) :-) Tunneling IPv4 over UDP/IPv4 works just fine (with effectively a static tunnel server at work). Not efficient but ... But I want something less static with IPv6. Erik From owner-v6ops@ops.ietf.org Fri Feb 21 12:21: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 MAA07616 for ; Fri, 21 Feb 2003 12:21:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mGuZ-0007p6-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 09:24:35 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18mGuT-0007op-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 09:24:29 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10283 for ; Fri, 21 Feb 2003 10:24:26 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAO005SV5OOTC@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 21 Feb 2003 10:24:26 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAO006RQ5OMVU@mail.sun.net> for v6ops@ops.ietf.org; Fri, 21 Feb 2003 10:24:24 -0700 (MST) Date: Fri, 21 Feb 2003 09:25:32 -0800 From: Alain Durand Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item In-reply-to: <3E564C61.3BDAF59A@hursley.ibm.com> To: Brian E Carpenter Cc: "Bound, Jim" , Margaret Wasserman , v6ops@ops.ietf.org Message-id: <7AF66BD8-45C1-11D7-9278-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Jim, What Brian just described are some of the typical network topologies I would like to see described and discussed. - Alain. On Friday, February 21, 2003, at 07:57 AM, Brian E Carpenter wrote: > Jim, I think you're misinterpreting my use of the b-word. I'm not > (of course) talking about business models. I'm talking about scenarios. > For example: > > A bank running a massive ATM network with some number of gazillions > of transactions per second against central databases. > > An engineering company running distributed design systems > across 20 different sites around the world. > > A pharmaceutical company running both compute-intensive and ERP > applications. > > etc. Each one fleshed out with how they do things today, and what > they want to achieve by adding IPv6. > > Brian > > "Bound, Jim" wrote: >> >> Brian, >> >>> I share some of Alain's concerns. I think that enterprise >>> customers will not look at IPv6 as a goal in itself, but as a >>> tool for certain business scenarios they need to support. >> >> We discussed this on the team. I agree with business justification. >> >>> So >>> I think the draft should start with a set of business >>> scenarios, and then maybe continue with the technology >>> scenarios (plus analysis of which business scenarios they >>> support). At the end, it would then be possible to deduce >>> which technology scenarios are useful. >> >> We discussed this and this is not an IETF mission or purpose. The >> business scenarios are not common and will vary. If we pick X >> business >> scenarios and leave out Y then the Y types will not be happy. This is >> not a goal of any scenario document unmanaged, ISP, or 3gpp. So I >> would >> suggest that this is not on any of the design teams plates. If your >> correct and I do not believe you are to add this then none of the >> current scenarios should be moved to the IESG. >> >>> >>> However, I wouldn't advocate pulling back the draft. I think >>> we should just ask the team to go back and develop the >>> business scenarios (or use cases, if you prefer the term). >>> And if necessary, pull in more expertise for this (e.g. to >>> cover Big Iron and major data centers and hosting centers). >> >> We have that expertise for "operations" and will not focus on data >> center or big iron. Reason is that one persons belief of data center >> or >> big iron is not the same as anothers. In the follow on draft analysis >> of >> the enterprise which will be technical will have assumptions that a >> "data center" could use. >> >> That being said I would suggest the IPv6 Forum, Asian IPv6 Task Force, >> North American IPv6 Task Force have the business scenarios and cases >> done. It is also those forum charter not the IETF. >> >> Also would suggest if we want to focus on the data center specifically >> we should build a separate draft and set of work to discuss first what >> it means and then execute on those assumptions it should not be part >> of >> the enterprise work. >> >> This team and work should be the dumping ground for all the things we >> have to do that are not covered in the other specs. Or else we will >> be >> here for 5 years working on this and this team is not going to do >> that. >> Like DNS is the dumping ground for anything we cannot figure out in >> our >> community to store data I would suggest and that is wrong too. >> >> Regards, >> /jim >>> >>> Brian >>> >>> Alain Durand wrote: >>>> >>>> Margaret, >>>> >>>> First, I would like to say that I appreciate the effort of >>> the design >>>> team to address such a difficult issue. >>>> >>>> However, that said, I'm not very comfortable with this document. On >>>> one hand, it is badly needed and already very late, on the >>> other hand, >>>> I'm not sure it is taking the right direction. >>>> >>>> I already have commented several times that this design team is way >>>> too 'transition tool' centric in its approach, somehow making the >>>> hidden assumption that solving the 'enterprise' case in the (yet to >>>> come) analysis/solution >>>> document will consist only of picking the 'right' transition tool >>>> developed by NGtrans. >>>> >>>> What I would like to see are things like the following instantiated >>>> for a set of 'typical' enterprise environment: >>>> >>>> - how does the internal networks looks like? >>>> - how is the networks are managed? >>>> (who is responsible, what is outsourced, is IT >>> competent/reliable >>>> or not ...) >>>> - what are the procedure/tools in place to manage the network? >>>> (not only SNMP, but for example tools to create DNS zone files) >>>> - is the public internet used (via VPN...)? >>>> - what are the connections to the Internet? >>>> - Is the v4 address space private or public? >>>> - Is the v4 address space 'portable'? (hint: do they need >>> portable v6 >>>> address space) >>>> - How much v4 address space is available? >>>> - Are they multi-homed? >>>> - how is security enforced? >>>> - how does the datacenter looks like if there is one? >>>> - what kind of applications are used in the >>>> Internet/intranet/extranets/...) >>>> (is it in-house code? is the source code available? is an Ipv6 >>>> version of the >>>> code available to buy?....) >>>> - how naming service/directory service is performed (two face DNS?) >>>> -... >>>> >>>> There is a little of that buried in section 4, variable >>> description, >>>> but I think this document should really instantiate those variables >>>> and more (the ones I just described above for example, >>> certainly much >>>> more) >>>> in a set of several 'typical' enterprise environments instead of >>>> focusing on cases describing how enterprises are thinking >>> of deploying >>>> v6 at the IP level >>>> (section 5, which is basically which networks to connect) >>> or abstract >>>> cases of transition mechanisms >>>> (section 6, point of transition methods) which belongs not in this >>>> document >>>> but in the solution document. >>>> >>>> With this in mind, I would not recommend the wg adopting this >>>> document. >>>> >>>> - Alain. >>>> >>>> On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman >>>> wrote: >>>> >>>>> >>>>> Hi All, >>>>> >>>>> I made a mistake last week and approved the publication >>>>> of the enterprise scenarios document as a WG work item without >>>>> actually checking with the WG first... Sorry. >>>>> >>>>> So, let's do this the right way... >>>>> >>>>> The enterprise scenarios/analysis team believes that >>>>> the current version of their scenarios document is ready for >>>>> consideration as a v6ops WG item. The document can be found at: >>>>> >>>>> >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-sc >> enario >>>> s- >>>> 00.txt >>>> >>>> This work is clearly within the charter of v6ops. >>>> >>>> Could members of the WG please comment on whether you believe that >>>> this document should be accepted as a WG item? In other words, does >> >>>> it take the right technical direction, and would it serve as a >>>> useful basis for our work? Is it sufficiently complete that it is >>>> ready for WG review and refinement? >>>> >>>> If there is sufficient support to accept this document, >>>> it will remain a WG work item. If not, we will move it back to >>>> individual submission status. >>>> >>>> Sorry for my mistake and any confusion it may cause. >>>> >>>> Margaret From owner-v6ops@ops.ietf.org Fri Feb 21 12:25: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 MAA07771 for ; Fri, 21 Feb 2003 12:25:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mGz1-00087g-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 09:29:11 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18mGyv-00087R-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 09:29:06 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 42D791D72; Fri, 21 Feb 2003 12:29:05 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:29:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Oops! Accepting Enterprise Scenarios as WG Item Date: Fri, 21 Feb 2003 12:29:02 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0932@tayexc13.americas.cpqcorp.net> Thread-Topic: Oops! Accepting Enterprise Scenarios as WG Item Thread-Index: AcLZwlO+GlthacJPR/GgoZbpVhqbogADFANg From: "Bound, Jim" To: "Brian E Carpenter" Cc: "Alain Durand" , "Margaret Wasserman" , X-OriginalArrivalTime: 21 Feb 2003 17:29:05.0146 (UTC) FILETIME=[BB778DA0:01C2D9CE] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07771 OK these will be in there for sure. It has its own section too. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, February 21, 2003 10:57 AM > To: Bound, Jim > Cc: Alain Durand; Margaret Wasserman; v6ops@ops.ietf.org > Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item > > > Jim, I think you're misinterpreting my use of the b-word. I'm > not (of course) talking about business models. I'm talking > about scenarios. For example: > > A bank running a massive ATM network with some number of gazillions > of transactions per second against central databases. > > An engineering company running distributed design systems > across 20 different sites around the world. > > A pharmaceutical company running both compute-intensive and ERP > applications. > > etc. Each one fleshed out with how they do things today, and > what they want to achieve by adding IPv6. > > Brian > > "Bound, Jim" wrote: > > > > Brian, > > > > > I share some of Alain's concerns. I think that enterprise > customers > > > will not look at IPv6 as a goal in itself, but as a tool > for certain > > > business scenarios they need to support. > > > > We discussed this on the team. I agree with business justification. > > > > > So > > > I think the draft should start with a set of business > scenarios, and > > > then maybe continue with the technology scenarios (plus > analysis of > > > which business scenarios they support). At the end, it > would then be > > > possible to deduce which technology scenarios are useful. > > > > We discussed this and this is not an IETF mission or purpose. The > > business scenarios are not common and will vary. If we pick X > > business scenarios and leave out Y then the Y types will > not be happy. > > This is not a goal of any scenario document unmanaged, ISP, > or 3gpp. > > So I would suggest that this is not on any of the design > teams plates. > > If your correct and I do not believe you are to add this > then none of > > the current scenarios should be moved to the IESG. > > > > > > > > However, I wouldn't advocate pulling back the draft. I think we > > > should just ask the team to go back and develop the business > > > scenarios (or use cases, if you prefer the term). And if > necessary, > > > pull in more expertise for this (e.g. to cover Big Iron and major > > > data centers and hosting centers). > > > > We have that expertise for "operations" and will not focus on data > > center or big iron. Reason is that one persons belief of > data center > > or big iron is not the same as anothers. In the follow on draft > > analysis of the enterprise which will be technical will have > > assumptions that a "data center" could use. > > > > That being said I would suggest the IPv6 Forum, Asian IPv6 > Task Force, > > North American IPv6 Task Force have the business scenarios > and cases > > done. It is also those forum charter not the IETF. > > > > Also would suggest if we want to focus on the data center > specifically > > we should build a separate draft and set of work to discuss > first what > > it means and then execute on those assumptions it should > not be part > > of the enterprise work. > > > > This team and work should be the dumping ground for all the > things we > > have to do that are not covered in the other specs. Or > else we will > > be here for 5 years working on this and this team is not > going to do > > that. Like DNS is the dumping ground for anything we cannot > figure out > > in our community to store data I would suggest and that is > wrong too. > > > > Regards, > > /jim > > > > > > Brian > > > > > > Alain Durand wrote: > > > > > > > > Margaret, > > > > > > > > First, I would like to say that I appreciate the effort of > > > the design > > > > team to address such a difficult issue. > > > > > > > > However, that said, I'm not very comfortable with this > document. > > > > On one hand, it is badly needed and already very late, on the > > > other hand, > > > > I'm not sure it is taking the right direction. > > > > > > > > I already have commented several times that this design team is > > > > way too 'transition tool' centric in its approach, > somehow making > > > > the hidden assumption that solving the 'enterprise' case in the > > > > (yet to > > > > come) analysis/solution > > > > document will consist only of picking the 'right' > transition tool > > > > developed by NGtrans. > > > > > > > > What I would like to see are things like the following > > > > instantiated for a set of 'typical' enterprise environment: > > > > > > > > - how does the internal networks looks like? > > > > - how is the networks are managed? > > > > (who is responsible, what is outsourced, is IT > > > competent/reliable > > > > or not ...) > > > > - what are the procedure/tools in place to manage the network? > > > > (not only SNMP, but for example tools to create DNS > zone files) > > > > - is the public internet used (via VPN...)? > > > > - what are the connections to the Internet? > > > > - Is the v4 address space private or public? > > > > - Is the v4 address space 'portable'? (hint: do they need > > > portable v6 > > > > address space) > > > > - How much v4 address space is available? > > > > - Are they multi-homed? > > > > - how is security enforced? > > > > - how does the datacenter looks like if there is one? > > > > - what kind of applications are used in the > > > > Internet/intranet/extranets/...) > > > > (is it in-house code? is the source code available? > is an Ipv6 > > > > version of the > > > > code available to buy?....) > > > > - how naming service/directory service is performed (two face > > > > DNS?) -... > > > > > > > > There is a little of that buried in section 4, variable > > > description, > > > > but I think this document should really instantiate those > > > > variables and more (the ones I just described above for example, > > > certainly much > > > > more) > > > > in a set of several 'typical' enterprise environments > instead of > > > > focusing on cases describing how enterprises are thinking > > > of deploying > > > > v6 at the IP level > > > > (section 5, which is basically which networks to connect) > > > or abstract > > > > cases of transition mechanisms > > > > (section 6, point of transition methods) which belongs > not in this > > > > document but in the solution document. > > > > > > > > With this in mind, I would not recommend the wg adopting this > > > > document. > > > > > > > > - Alain. > > > > > > > > On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman > > > > wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > I made a mistake last week and approved the > publication of the > > > > > enterprise scenarios document as a WG work item > without actually > > > > > checking with the WG first... Sorry. > > > > > > > > > > So, let's do this the right way... > > > > > > > > > > The enterprise scenarios/analysis team believes that > the current > > > > > version of their scenarios document is ready for > consideration > > > > > as a v6ops WG item. The document can be found at: > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-sc > > enario > > > > s- > > > > 00.txt > > > > > > > > This work is clearly within the charter of v6ops. > > > > > > > > Could members of the WG please comment on whether you > believe that > > > > this document should be accepted as a WG item? In other words, > > > > does > > > > > > it take the right technical direction, and would it serve as a > > > > useful basis for our work? Is it sufficiently complete > that it is > > > > ready for WG review and refinement? > > > > > > > > If there is sufficient support to accept this document, it will > > > > remain a WG work item. If not, we will move it back to > individual > > > > submission status. > > > > > > > > Sorry for my mistake and any confusion it may cause. > > > > > > > > Margaret > From owner-v6ops@ops.ietf.org Fri Feb 21 12:30: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 MAA07903 for ; Fri, 21 Feb 2003 12:30:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mH3b-0008Q9-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 09:33:55 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18mH3V-0008OX-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 09:33:50 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 14D948698; Fri, 21 Feb 2003 12:33:49 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:33:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Oops! Accepting Enterprise Scenarios as WG Item Date: Fri, 21 Feb 2003 12:33:48 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0933@tayexc13.americas.cpqcorp.net> Thread-Topic: Oops! Accepting Enterprise Scenarios as WG Item Thread-Index: AcLZzk2f1xcjI1gaRcCY3AAInORdfgAAHJGA From: "Bound, Jim" To: "Alain Durand" , "Brian E Carpenter" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 21 Feb 2003 17:33:48.0866 (UTC) FILETIME=[6493CA20:01C2D9CF] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA07903 Alain, What we did is select a means to get to as many as we can. See the 27 uses cases. Unmanaged came to similar conclusion. What we all face doing any scenarios is we cannot discuss every possible one. So what unmanaged and enterprise are doing is trying to build a best case scenario algorithm. If we need to fix that algroithm that is prudent. I think the ISP and 3GPP case has a more focused paradigm to present with 3GPP being the most focused. As editor for Yanick and team I have added yours and Brian's email to my "edit" queue for the team. My process as editor is like Dr. Spoc in Startrek :--) I am amoral on the outcome as long as it comes from multiple sources. Your stuff is in the queue now as Brian's. It will be reflected. But if the algorithm needs tweaking then we have to do that to cover the varying topologies as best we can. Right now the team all has writing assignments from Yanick. Thanks /jim > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: Friday, February 21, 2003 12:26 PM > To: Brian E Carpenter > Cc: Bound, Jim; Margaret Wasserman; v6ops@ops.ietf.org > Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item > > > Jim, > > What Brian just described are some of the typical network > topologies I would like to see described and discussed. > > - Alain. > > On Friday, February 21, 2003, at 07:57 AM, Brian E Carpenter wrote: > > > Jim, I think you're misinterpreting my use of the b-word. > I'm not (of > > course) talking about business models. I'm talking about scenarios. > > For example: > > > > A bank running a massive ATM network with some number of > gazillions > > of transactions per second against central databases. > > > > An engineering company running distributed design systems > > across 20 different sites around the world. > > > > A pharmaceutical company running both compute-intensive and ERP > > applications. > > > > etc. Each one fleshed out with how they do things today, > and what they > > want to achieve by adding IPv6. > > > > Brian > > > > "Bound, Jim" wrote: > >> > >> Brian, > >> > >>> I share some of Alain's concerns. I think that enterprise > customers > >>> will not look at IPv6 as a goal in itself, but as a tool > for certain > >>> business scenarios they need to support. > >> > >> We discussed this on the team. I agree with business > justification. > >> > >>> So > >>> I think the draft should start with a set of business > scenarios, and > >>> then maybe continue with the technology scenarios (plus > analysis of > >>> which business scenarios they support). At the end, it > would then be > >>> possible to deduce which technology scenarios are useful. > >> > >> We discussed this and this is not an IETF mission or purpose. The > >> business scenarios are not common and will vary. If we pick X > >> business scenarios and leave out Y then the Y types will not be > >> happy. This is not a goal of any scenario document > unmanaged, ISP, > >> or 3gpp. So I would > >> suggest that this is not on any of the design teams plates. If your > >> correct and I do not believe you are to add this then none of the > >> current scenarios should be moved to the IESG. > >> > >>> > >>> However, I wouldn't advocate pulling back the draft. I think we > >>> should just ask the team to go back and develop the business > >>> scenarios (or use cases, if you prefer the term). And if > necessary, > >>> pull in more expertise for this (e.g. to cover Big Iron and major > >>> data centers and hosting centers). > >> > >> We have that expertise for "operations" and will not focus on data > >> center or big iron. Reason is that one persons belief of > data center > >> or big iron is not the same as anothers. In the follow on draft > >> analysis of > >> the enterprise which will be technical will have assumptions that a > >> "data center" could use. > >> > >> That being said I would suggest the IPv6 Forum, Asian IPv6 Task > >> Force, North American IPv6 Task Force have the business > scenarios and > >> cases done. It is also those forum charter not the IETF. > >> > >> Also would suggest if we want to focus on the data center > >> specifically we should build a separate draft and set of work to > >> discuss first what it means and then execute on those > assumptions it > >> should not be part of the enterprise work. > >> > >> This team and work should be the dumping ground for all > the things we > >> have to do that are not covered in the other specs. Or > else we will > >> be here for 5 years working on this and this team is not > going to do > >> that. > >> Like DNS is the dumping ground for anything we cannot > figure out in > >> our > >> community to store data I would suggest and that is wrong too. > >> > >> Regards, > >> /jim > >>> > >>> Brian > >>> > >>> Alain Durand wrote: > >>>> > >>>> Margaret, > >>>> > >>>> First, I would like to say that I appreciate the effort of > >>> the design > >>>> team to address such a difficult issue. > >>>> > >>>> However, that said, I'm not very comfortable with this > document. On > >>>> one hand, it is badly needed and already very late, on the > >>> other hand, > >>>> I'm not sure it is taking the right direction. > >>>> > >>>> I already have commented several times that this design > team is way > >>>> too 'transition tool' centric in its approach, somehow > making the > >>>> hidden assumption that solving the 'enterprise' case in > the (yet to > >>>> come) analysis/solution > >>>> document will consist only of picking the 'right' > transition tool > >>>> developed by NGtrans. > >>>> > >>>> What I would like to see are things like the following > instantiated > >>>> for a set of 'typical' enterprise environment: > >>>> > >>>> - how does the internal networks looks like? > >>>> - how is the networks are managed? > >>>> (who is responsible, what is outsourced, is IT > >>> competent/reliable > >>>> or not ...) > >>>> - what are the procedure/tools in place to manage the network? > >>>> (not only SNMP, but for example tools to create DNS > zone files) > >>>> - is the public internet used (via VPN...)? > >>>> - what are the connections to the Internet? > >>>> - Is the v4 address space private or public? > >>>> - Is the v4 address space 'portable'? (hint: do they need > >>> portable v6 > >>>> address space) > >>>> - How much v4 address space is available? > >>>> - Are they multi-homed? > >>>> - how is security enforced? > >>>> - how does the datacenter looks like if there is one? > >>>> - what kind of applications are used in the > >>>> Internet/intranet/extranets/...) > >>>> (is it in-house code? is the source code available? > is an Ipv6 > >>>> version of the > >>>> code available to buy?....) > >>>> - how naming service/directory service is performed (two > face DNS?) > >>>> -... > >>>> > >>>> There is a little of that buried in section 4, variable > >>> description, > >>>> but I think this document should really instantiate > those variables > >>>> and more (the ones I just described above for example, > >>> certainly much > >>>> more) > >>>> in a set of several 'typical' enterprise environments instead of > >>>> focusing on cases describing how enterprises are thinking > >>> of deploying > >>>> v6 at the IP level > >>>> (section 5, which is basically which networks to connect) > >>> or abstract > >>>> cases of transition mechanisms > >>>> (section 6, point of transition methods) which belongs > not in this > >>>> document but in the solution document. > >>>> > >>>> With this in mind, I would not recommend the wg adopting this > >>>> document. > >>>> > >>>> - Alain. > >>>> > >>>> On Thursday, February 20, 2003, at 08:46 AM, Margaret Wasserman > >>>> wrote: > >>>> > >>>>> > >>>>> Hi All, > >>>>> > >>>>> I made a mistake last week and approved the publication of the > >>>>> enterprise scenarios document as a WG work item without > actually > >>>>> checking with the WG first... Sorry. > >>>>> > >>>>> So, let's do this the right way... > >>>>> > >>>>> The enterprise scenarios/analysis team believes that > >>>>> the current version of their scenarios document is ready for > >>>>> consideration as a v6ops WG item. The document can be found at: > >>>>> > >>>>> > >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-sc > >> enario > >>>> s- > >>>> 00.txt > >>>> > >>>> This work is clearly within the charter of v6ops. > >>>> > >>>> Could members of the WG please comment on whether you > believe that > >>>> this document should be accepted as a WG item? In other words, > >>>> does > >> > >>>> it take the right technical direction, and would it serve as a > >>>> useful basis for our work? Is it sufficiently complete > that it is > >>>> ready for WG review and refinement? > >>>> > >>>> If there is sufficient support to accept this document, > >>>> it will remain a WG work item. If not, we will move it back to > >>>> individual submission status. > >>>> > >>>> Sorry for my mistake and any confusion it may cause. > >>>> > >>>> Margaret > > From owner-v6ops@ops.ietf.org Fri Feb 21 12:47: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 MAA08750 for ; Fri, 21 Feb 2003 12:47:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHK3-0009PF-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 09:50:55 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18mHJu-0009Of-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 09:50:47 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 2B6774638 for ; Fri, 21 Feb 2003 12:50:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:50:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 12:50:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0935@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLTswaIb3XlCw72TviJFIVXZGBYdwDNMQVQAAI46AAAAY23sAAAaLlwAACpXmAAHDNLEACZcK7g From: "Bound, Jim" To: "Christian Huitema" Cc: X-OriginalArrivalTime: 21 Feb 2003 17:50:44.0906 (UTC) FILETIME=[C22F30A0:01C2D9D1] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08750 I agree Christian. /jim > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, February 18, 2003 11:47 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > In the IETF, we used to deal with arguments of complexity by > > > considering running code, rather than by theoretical debates. We > > > have running code for Teredo. I have used the code > myself. I guess > > > this meet at least 1/2 of the requirements -- the other > 1/2 would be > > > to prove Interop with an independent implementation. > > > > I agree this is a very very good argument. I want to do > the same but > I > > need find DSL Router folks to make it work. We both have > done manual > > config and 6to4. But I am wondering if some kind of very > very simple > > code patch can make it so the DSL router can assist with > the process. > > Teredo is not meant to be implemented in the DSL router: it > is a single host solution. The only requirement of the DSL > router is that it provides "reasonable" support for UDP-IPv4; > our tests show that this is the case for the overwhelming > majority of the small routers available on the US market. The > correction needed by the other routers mostly amount to bug > fixes: a slight modification of the "5-tuple" mapping > algorithm, and a requirement to not do anything stupid after > receiving an ICMP "unreachable" error message. The same fixes > are also needed to enable the STUN scenarios that are used by > IPv4/VoIP, so I expect market pressure will lead the home > router manufacturers to "do the right thing." > > If these home router manufacturers want to help deploy IPv6, > then the obvious requirement is to support 6to4, to allow > configured tunnels, and to also allow relaying of an ISP > native IPv6 service. This is very much what we are describing > in the "unmanaged networks" scenarios. > > -- Christian Huitema > From owner-v6ops@ops.ietf.org Fri Feb 21 12:50: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 MAA08938 for ; Fri, 21 Feb 2003 12:50:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHMb-0009XV-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 09:53:33 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18mHMY-0009X8-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 09:53:30 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 170971C16; Fri, 21 Feb 2003 12:53:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:53:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 12:53:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0936@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLXnXWMafliuDvOSwS7hmTOqYArkACNIEUg From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 21 Feb 2003 17:53:29.0640 (UTC) FILETIME=[245F9A80:01C2D9D2] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08938 OK. I have offline come up with code algorithm for DSL/NAT boxes who don't have an IPv6 stack to do config tunnels. I am trying to get people to talk to me in that platform world now. So the tweak can be a patch. Thanks /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Tuesday, February 18, 2003 5:28 PM > To: v6ops@ops.ietf.org > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Just the protocol 41 forwarding destination on the internal > network from > the NAT box. So like Jordi but some config needed. They > also wrote their > own tunnel broker s/w using FreeBSD, ssh and OpenLDAP (all v6). > > Tim > > On Mon, Feb 17, 2003 at 08:00:58PM -0500, Bound, Jim wrote: > > What are they tweaking? > > > > Thanks > > /jim > > > > > > > > > > > -----Original Message----- > > > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > > > Sent: Sunday, February 16, 2003 12:59 PM > > > To: Jeroen Massar > > > Cc: 'Alain Durand'; Bound, Jim; alh-ietf@tndh.net; > v6ops@ops.ietf.org > > > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > > > > > > On Sun, Feb 16, 2003 at 03:18:28PM +0100, Jeroen Massar wrote: > > > > > > > > Which one can do now by simply installing eg the freenet6 > > > client onto > > > > one of the existing windows/*nix boxes which will advertise > > > the IPv6 > > > > prefix onto the local subnet. The only trick here is to > > > have the CPE > > > > forward proto-41 to your v6-gate or using Teredo. Btw > 'just have > > > > to > > > > add' is sometimes expensive for some people. > > > > > > This is what our IPv6 students tend to do in their homes. It > > > works nicely, > > > but still requires a tweak in the DSL router. > > > > > > Tim > > > > > From owner-v6ops@ops.ietf.org Fri Feb 21 12:53: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 MAA09004 for ; Fri, 21 Feb 2003 12:53:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHPV-0009nO-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 09:56:33 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18mHPS-0009mq-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 09:56:30 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 768401D72 for ; Fri, 21 Feb 2003 12:56:29 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:56:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 12:56:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0937@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLZqRjmDjOI06tQTdWOvgUatxsNdAAKVnUg From: "Bound, Jim" To: "Erik Nordmark" Cc: X-OriginalArrivalTime: 21 Feb 2003 17:56:29.0264 (UTC) FILETIME=[8F700D00:01C2D9D2] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09004 Erik, Good thing to parse and the traversal draft thanks. Forget the odd proto-id that was bug in my busy processes below :--) Thanks /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Friday, February 21, 2003 7:56 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > Assume home routers want to support IPv6 and will > eventually but won't > > move until they believe it can be used over provider networks. > > > > Assume there is not enough Ipv4 address space for providers to give > > out to all subscribers or cannot at reasonable cost. But they can > > give the subscriber an IPv6 prefix. This means 6to4 or > ISATAP won't > > work in this scenario in the users home. > > I think what is needed are four things: > 1. A method for the actual encapsulation > IPv6 over UDP over IPv4 might be the easiest > 2. A method to keep the NAT state up to date > ICMPv6 echo's over the tunnel can do that > 3. A method to detect when the NAT state has been lost or changed > so that it can be restored (perhaps using the same > mechanism in #4) 4. A mechanism to determine the tunnel > endpoint (IP address and port) > > Note that draft-ietf-mobileip-nat-traversal-07.txt specifies > how to do this when #4 is the Mobile IPv4 registration protocol. > > I think much of that draft can be used, and for #4 we can use either > - TSP as for tunnel broker (makes sense when some authentication of > the client is needed) > - a DHCPv4 option (makes sense when DHCPv4 is already used by the ISP > and no special authentication is needed for the tunnel) > > > The home user network encaps the IPv6 packet at NAT with > Protocol ID > > equivalent to "6". The provider then takes that packet and > decaps at > > their edge and uses native IPv6 or 6to4 to encap that > packet to where > > the IPv6 service is located. I realize this has many > assumptions and > > I would work on those with some other folks interested in > this problem. > > Using a separate protocol ID implies that the NAT box has the > functionality. Using UDP tunneling provides more flexibility > since one can run tunneling across a NAT box one can't > modify/control (like the one I have at home). > > Thus until the home router has been modified one could do > this tunneling from the host at home. > > Erik > > From owner-v6ops@ops.ietf.org Fri Feb 21 12:56: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 MAA09102 for ; Fri, 21 Feb 2003 12:56:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHSX-000A03-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 09:59:41 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18mHST-0009zE-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 09:59:37 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 06E3A8E63; Fri, 21 Feb 2003 12:59:37 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 12:59:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 12:59:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0938@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLZr5ZXJNhWX+d6RL+bJ+sIHsVtLwAIxMpg From: "Bound, Jim" To: "Erik Nordmark" Cc: "Jeroen Massar" , "JORDI PALET MARTINEZ" , , "Alain Durand" , X-OriginalArrivalTime: 21 Feb 2003 17:59:36.0881 (UTC) FILETIME=[FF442210:01C2D9D2] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09102 I caught that in the rfc too. Yes we need an updated tunnel rfc or draft. Would that be valid work here ? Chairs ? My only concern about dhcpv4 is that is more work and process. Which is fine but we can use vendor class for now? But I agree dhcpv4 is a good mechanism. But we could have something in interim. Some I know would like to see this working in 2004 and deployed. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Friday, February 21, 2003 8:42 AM > To: Bound, Jim > Cc: Jeroen Massar; JORDI PALET MARTINEZ; v6ops@ops.ietf.org; > Alain Durand; alh-ietf@tndh.net > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > > If we have tunnel brokers we don 't need teredo right? > That's my take > > now. > > Agreed in principle. > > Two things though: > Firstly, for the access router to ISP tunnel config > something simpler (like a DHCPv4 option) might make sense - > depends on what type of authentication the ISP wants to do > specifically for the IPv6 tunnel. If it is sufficient for the > ISP to check that the IPv4 source is one of its customers > then the TSP authentication features and flexibility isn't needed. > > Secondly, > I've been told that tunnel broker can work trough NAT but the > RFC (RFC 3053) says: 3. Known limitations > > This mechanism may not work if the user is using private IPv4 > addresses behind a NAT box. > > Thus I think it would be useful to have a specification on > how tunnel broker works across a NAT. > > Erik > > From owner-v6ops@ops.ietf.org Fri Feb 21 12:59: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 MAA09186 for ; Fri, 21 Feb 2003 12:59:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHVU-000ABi-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 10:02:44 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18mHVH-000ABG-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 10:02:31 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 067EB8EEC; Fri, 21 Feb 2003 13:02:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 13:02:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 13:02:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C0939@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLZwS6VMJIqvB63RzSDVY57OoNppwAEhtAQ From: "Bound, Jim" To: "Paul Timmins" , "Erik Nordmark" Cc: "Jeroen Massar" , "JORDI PALET MARTINEZ" , , "Alain Durand" , X-OriginalArrivalTime: 21 Feb 2003 18:02:29.0714 (UTC) FILETIME=[66485B20:01C2D9D3] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09186 I thought I had same problem as Erik but I just got proto 41 through. But I put a box in front of the cable dsl router. As note. But it breaks still :--) /jim > -----Original Message----- > From: Paul Timmins [mailto:paul@timmins.net] > Sent: Friday, February 21, 2003 10:56 AM > To: Erik Nordmark > Cc: Jeroen Massar; Bound, Jim; 'JORDI PALET MARTINEZ'; > v6ops@ops.ietf.org; 'Alain Durand'; alh-ietf@tndh.net > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > On Fri, 2003-02-21 at 10:29, Erik Nordmark wrote: > > That's nice for those that have control of the NAT box. > > The Telco that provides me service at home provides me with > a NAT box > > that they control - and they are uninterested in doing anything > > special. I can't bypass/replace the NAT box because it > speaks some odd > > and probably proprietary stuff on the other side (it's an > ISDN line). > > > > So I prefer solutions that don't have to rely on > configuration in the > > NAT box yet are simpler than Teredo. > > I agree here as well. I've seen -alot- of firewalls that > either block, or don't statefully forward proto-41. Even if > they did, that limits IPv6 to one end user behind the NAT. If > I was using this at a Mariott for example, they NAT the users > of their in room ethernet. I'd be disappointed if someone > else was using v6 tunneling in the hotel, because it means I > couldn't (Assuming they forward proto-41 to begin with). With > UDP tunneling, we could both have our own tunnels. I think a > limitation on how many machines behind a NAT can have a > tunnel would slow transition in places like this, because if > I were offering enterprise services over v6, and had my > employees tunneling back to the office, I'd be pretty upset > if they couldn't get their job done because another employee > (or just another user, depending on the proto-41 forwarding > implementation) has a tunnel open at the hotel at the same time. > > My 0.02. > -Paul > > -- > Paul Timmins > paul@timmins.net / http://www.timmins.net/ > H: 313-586-9514 / C: 248-379-7826 / DC: 130*116*24495 > AIM: noweb4u / Callsign: KC8QAY > > From owner-v6ops@ops.ietf.org Fri Feb 21 13:00: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 NAA09214 for ; Fri, 21 Feb 2003 13:00:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mHWI-000ADY-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 10:03:34 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18mHWB-000ADC-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 10:03:28 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2B5BF5689; Fri, 21 Feb 2003 13:03:27 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 21 Feb 2003 13:03:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Fri, 21 Feb 2003 13:03:26 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B034C093A@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Home Use to stimulate deployment over IPv4-NAT Thread-Index: AcLZw4fRPGCmZQrIRe2ZFpJa31qSEQAD+3sg From: "Bound, Jim" To: "Jeroen Massar" , "Erik Nordmark" Cc: "Marc Blanchet" , X-OriginalArrivalTime: 21 Feb 2003 18:03:26.0990 (UTC) FILETIME=[886BFAE0:01C2D9D3] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA09214 It sounds like getting providers to support TB is a mission? As initial step? /jim > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org] > Sent: Friday, February 21, 2003 11:07 AM > To: 'Erik Nordmark' > Cc: 'Marc Blanchet'; v6ops@ops.ietf.org > Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > > > Erik Nordmark wrote: > > > > The only thing is that the NAT box needs to know where to > > send incoming > > > proto-41 packets to. > > > > > > - Some NAT boxes can be configured with a 'default'. > > > Those boxes will then forward any unrelated traffic to > > that default > > > IP. > > > > That's nice for those that have control of the NAT box. > > The Telco that provides me service at home provides me with > a NAT box > > that they control - and they are uninterested in doing anything > > special. I can't bypass/replace the NAT box because it > speaks some odd > > and probably proprietary stuff on the other side (it's an > ISDN line). > > > > So I prefer solutions that don't have to rely on > configuration in the > > NAT box yet are simpler than Teredo. > > Make a ssh/pptp/vtund//* tunnel to the outside and > route your packets over there. These mechanisms then ofcourse > should be supplied and supported by the Tunnel Broker in > question. So if we want a good deployment we need to support > all of these options (unfortunatly). Marc can you create such > TSP drafts ? > > Eg: draft-parent-blanchet-ngtrans-tsp--00.txt > > Which means that an external application is needed for > tunneling the packets to the tunnel broker. > > application ::= ssh|pptp|vtund|httptunnel| > > Some networks unfortunatly will want to avoid the possibility > of using them as a 'transit' service only, eg tunneling to a > friendly AS and then routing a own prefix over that, > basically only using the ISP's IP for the tunnel. > > Sidenote: > IMHO you don't have a complete IPv4 internet connection > either as with your current setup you can't do most thing > that have an embedded IP in the packets (read: Netmeeting). > Also setting up your own SSH, apache, gameserver etc will not > work :( If I had a chance of ISP's in your situation I would > surely not go for them, I hate NAT's and I require at least > one public IPv4 thats completely unfiltered. In your current > situation they could have put you all their customers behind > a big rfc1918 subnet and NAT there too and that is what I > call localnet access (with an internet gate) and not internet access. > > Greets, > Jeroen > > > From owner-v6ops@ops.ietf.org Fri Feb 21 18:45: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 SAA18644 for ; Fri, 21 Feb 2003 18:45:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mMtS-0006kb-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 15:47:50 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18mMtP-0006k7-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 15:47:47 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18mMtO-000Fkg-00 for v6ops@ops.ietf.org; Sat, 22 Feb 2003 08:47:46 +0900 In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045842993.859.7.camel@pikachu> Mime-Version: 1.0 Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT From: Paul Timmins To: Erik Nordmark Cc: Jeroen Massar , "'Bound, Jim'" , "'JORDI PALET MARTINEZ'" , v6ops@ops.ietf.org, "'Alain Durand'" , alh-ietf@tndh.net Date: 21 Feb 2003 10:56:23 -0500 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 10:29, Erik Nordmark wrote: > That's nice for those that have control of the NAT box. > The Telco that provides me service at home provides me with a NAT box > that they control - and they are uninterested in doing anything special. > I can't bypass/replace the NAT box because it speaks some odd and probably > proprietary stuff on the other side (it's an ISDN line). > > So I prefer solutions that don't have to rely on configuration in > the NAT box yet are simpler than Teredo. I agree here as well. I've seen -alot- of firewalls that either block, or don't statefully forward proto-41. Even if they did, that limits IPv6 to one end user behind the NAT. If I was using this at a Mariott for example, they NAT the users of their in room ethernet. I'd be disappointed if someone else was using v6 tunneling in the hotel, because it means I couldn't (Assuming they forward proto-41 to begin with). With UDP tunneling, we could both have our own tunnels. I think a limitation on how many machines behind a NAT can have a tunnel would slow transition in places like this, because if I were offering enterprise services over v6, and had my employees tunneling back to the office, I'd be pretty upset if they couldn't get their job done because another employee (or just another user, depending on the proto-41 forwarding implementation) has a tunnel open at the hotel at the same time. My 0.02. -Paul -- Paul Timmins paul@timmins.net / http://www.timmins.net/ H: 313-586-9514 / C: 248-379-7826 / DC: 130*116*24495 AIM: noweb4u / Callsign: KC8QAY From owner-v6ops@ops.ietf.org Fri Feb 21 19:06:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19097 for ; Fri, 21 Feb 2003 19:06:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mNEH-0007qC-00 for v6ops-data@psg.com; Fri, 21 Feb 2003 16:09:21 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18mNDm-0007pU-00 for v6ops@ops.ietf.org; Fri, 21 Feb 2003 16:08:50 -0800 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Sat, 22 Feb 2003 01:10:32 +0100 Message-ID: <032b01c2da06$cfb8aa00$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , "Erik Nordmark" Cc: "Jeroen Massar" , "'Bound, Jim'" , , "'Alain Durand'" , References: <1045842993.859.7.camel@pikachu> Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Sat, 22 Feb 2003 01:10:28 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,RCVD_IN_RELAYS_ORDB_ORG, REFERENCES,SPAM_PHRASE_00_01,USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul, My experience is that if the NAT box is forwarding the proto-41, then is forwarded just as any other ICMP, UDP, or TCP, so is reaching the appropriate host in the private network. That means that several tunnels can be setup w/o any problem. Of course, the "manager" of the NAT box can setup a single tunnel for all proto-41 packets, but this is something out of our control, specially in an hotel. Regards, Jordi ----- Original Message ----- From: "Paul Timmins" To: "Erik Nordmark" Cc: "Jeroen Massar" ; "'Bound, Jim'" ; "'JORDI PALET MARTINEZ'" ; ; "'Alain Durand'" ; Sent: Friday, February 21, 2003 4:56 PM Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT > On Fri, 2003-02-21 at 10:29, Erik Nordmark wrote: > > That's nice for those that have control of the NAT box. > > The Telco that provides me service at home provides me with a NAT box > > that they control - and they are uninterested in doing anything special. > > I can't bypass/replace the NAT box because it speaks some odd and probably > > proprietary stuff on the other side (it's an ISDN line). > > > > So I prefer solutions that don't have to rely on configuration in > > the NAT box yet are simpler than Teredo. > > I agree here as well. I've seen -alot- of firewalls that either block, > or don't statefully forward proto-41. Even if they did, that limits IPv6 > to one end user behind the NAT. If I was using this at a Mariott for > example, they NAT the users of their in room ethernet. I'd be > disappointed if someone else was using v6 tunneling in the hotel, > because it means I couldn't (Assuming they forward proto-41 to begin > with). With UDP tunneling, we could both have our own tunnels. I think a > limitation on how many machines behind a NAT can have a tunnel would > slow transition in places like this, because if I were offering > enterprise services over v6, and had my employees tunneling back to the > office, I'd be pretty upset if they couldn't get their job done because > another employee (or just another user, depending on the proto-41 > forwarding implementation) has a tunnel open at the hotel at the same > time. > > My 0.02. > -Paul > > -- > Paul Timmins > paul@timmins.net / http://www.timmins.net/ > H: 313-586-9514 / C: 248-379-7826 / DC: 130*116*24495 > AIM: noweb4u / Callsign: KC8QAY > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Sat Feb 22 17:29: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 RAA16659 for ; Sat, 22 Feb 2003 17:29:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mi8g-0004qy-00 for v6ops-data@psg.com; Sat, 22 Feb 2003 14:28:58 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18mi8e-0004qm-00 for v6ops@ops.ietf.org; Sat, 22 Feb 2003 14:28:56 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA16619; Sat, 22 Feb 2003 14:26:46 -0800 (PST) Message-Id: <5.1.0.14.2.20030222171838.03486bb0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 22 Feb 2003 17:22:11 -0500 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: IPv6 Home Use to stimulate deployment over IPv4-NAT Cc: "Erik Nordmark" , "Jeroen Massar" , "JORDI PALET MARTINEZ" , , "Alain Durand" , In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B034C0938@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, At 12:59 PM 2/21/2003 -0500, Bound, Jim wrote: >I caught that in the rfc too. Yes we need an updated tunnel rfc or >draft. >Would that be valid work here ? Chairs ? I'm not quite sure what you are asking... Are you asking about an update to RFC 3053 that would explain how to use it over a NAT? If the need for something like this is indicated by the unmanaged or enterprise scenario/analysis efforts, we would probably want to pursue this in v6ops (I can't think of another WG that would be more appropriate). Margaret From owner-v6ops@ops.ietf.org Sun Feb 23 00:42:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22026 for ; Sun, 23 Feb 2003 00:42:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mowB-0003ME-00 for v6ops-data@psg.com; Sat, 22 Feb 2003 21:44:31 -0800 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 18mow8-0003M2-00 for v6ops@ops.ietf.org; Sat, 22 Feb 2003 21:44:28 -0800 Received: from esunmail ([129.147.58.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12278 for ; Sat, 22 Feb 2003 22:44:28 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTP id <0HAQ00LQ5YK7FZ@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Sat, 22 Feb 2003 22:43:20 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec 6 2002)) with ESMTPSA id <0HAQ00KO9YK6UN@mail.sun.net> for v6ops@ops.ietf.org; Sat, 22 Feb 2003 22:43:19 -0700 (MST) Date: Sat, 22 Feb 2003 21:45:34 -0800 From: Alain Durand Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT To: Margaret Wasserman Cc: "Bound, Jim" , Erik Nordmark , Jeroen Massar , JORDI PALET MARTINEZ , v6ops@ops.ietf.org, alh-ietf@tndh.net Message-id: <3E585FFE.3090804@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 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <5.1.0.14.2.20030222171838.03486bb0@mail.windriver.com> X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT The unmanaged scenario, case A, calls for tunneling over UDP. 2 possible solutions are teredo or tunnel broker with tunneling over UDP. If we want to explore the tunnel broker solution, I do not think RFC3053 needs an update. It is a framework document that explain the concept of tunnel broker. What is needed are two documents: - one that explain IPv6 over UDP over IPv4 - one that described a simple automatic protocol to set up the configuration parameters between the client (access router) and the tunnel broker. A DHCPv4 extension would work, somethink like marc blanchet's TSP protocol would work also. Maybe the first think to do is to work on some requirements for such a protocol. - Alain. Margaret Wasserman wrote: > > Hi Jim, > > At 12:59 PM 2/21/2003 -0500, Bound, Jim wrote: > >> I caught that in the rfc too. Yes we need an updated tunnel rfc or >> draft. >> Would that be valid work here ? Chairs ? > > > I'm not quite sure what you are asking... Are you asking > about an update to RFC 3053 that would explain how to use > it over a NAT? > > If the need for something like this is indicated by the > unmanaged or enterprise scenario/analysis efforts, we > would probably want to pursue this in v6ops (I can't > think of another WG that would be more appropriate). > > Margaret > > > From owner-v6ops@ops.ietf.org Sun Feb 23 01:28: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 BAA22407 for ; Sun, 23 Feb 2003 01:28:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mpfT-0006bk-00 for v6ops-data@psg.com; Sat, 22 Feb 2003 22:31:19 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18mpfQ-0006bT-00 for v6ops@ops.ietf.org; Sat, 22 Feb 2003 22:31:16 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1N6UDA10099; Sun, 23 Feb 2003 08:30:13 +0200 Date: Sun, 23 Feb 2003 08:30:12 +0200 (EET) From: Pekka Savola To: Alain Durand cc: Margaret Wasserman , "Bound, Jim" , Erik Nordmark , Jeroen Massar , JORDI PALET MARTINEZ , , Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT In-Reply-To: <3E585FFE.3090804@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 22 Feb 2003, Alain Durand wrote: [...] > A DHCPv4 extension would work, somethink like marc blanchet's TSP > protocol would work also. Maybe the first think to do is to work on some > requirements for such a protocol. Indeed, we have to get a better picture on what are the problems and non-problems. For example, DHCP extension works only in scenarios where you obtain the tunnel connectivity from your direct upstream ISP, the same one that provides IPv4 connectivity. In many cases, this is a non-problem: it is often the case that such IPv6-active ISP's could provide v6 access using different means already -- no all though -- if the IPv6-conscious ISP just has to keep natting routers as CPE's and can't change them in the short term, this could still be valuable. So, we need to have a picture on the scenarios we're trying to address. > > At 12:59 PM 2/21/2003 -0500, Bound, Jim wrote: > > > >> I caught that in the rfc too. Yes we need an updated tunnel rfc or > >> draft. > >> Would that be valid work here ? Chairs ? > > > > > > I'm not quite sure what you are asking... Are you asking > > about an update to RFC 3053 that would explain how to use > > it over a NAT? > > > > If the need for something like this is indicated by the > > unmanaged or enterprise scenario/analysis efforts, we > > would probably want to pursue this in v6ops (I can't > > think of another WG that would be more appropriate). > > > > Margaret > > > > > > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sun Feb 23 10:32: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 KAA08893 for ; Sun, 23 Feb 2003 10:32:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18my80-0005Yb-00 for v6ops-data@psg.com; Sun, 23 Feb 2003 07:33:20 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18my7p-0005Xi-00 for v6ops@ops.ietf.org; Sun, 23 Feb 2003 07:33:09 -0800 Received: from consulintel02 ([211.22.80.252]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for ; Sun, 23 Feb 2003 16:34:52 +0100 Message-ID: <024b01c2db51$170d80b0$fc5016d3@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , "Margaret Wasserman" Cc: "Bound, Jim" , "Erik Nordmark" , "Jeroen Massar" , , References: <5.1.0.14.2.20030222171838.03486bb0@mail.windriver.com> <3E585FFE.3090804@sun.com> Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Date: Sun, 23 Feb 2003 23:34:02 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 211.22.80.252 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-0.8 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT_OE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we are talking about the case where the tunnel works over NAT w/o need for UDP encapsulation. About 60% of the NAT boxes that I tested have forwarded proto-41 w/o any problem or special configuration. This could be documented as a possibility in RFC3053 (now is open in "known limitations", but not clear), and may be explored by the tunnel broker or whatever is setting up the mechanism, in order to choose automatically this option or, if not available, UDP or other alternatives. It will be good to document what routers/models/vendors support this, but I'm not sure how to do that, as probably there are hundreds or thousands of ;-) Whatever is decided, I will be happy to work on this. Regards, Jordi ----- Original Message ----- From: "Alain Durand" To: "Margaret Wasserman" Cc: "Bound, Jim" ; "Erik Nordmark" ; "Jeroen Massar" ; "JORDI PALET MARTINEZ" ; ; Sent: Sunday, February 23, 2003 1:45 PM Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT > The unmanaged scenario, case A, calls for tunneling over UDP. > 2 possible solutions are teredo or tunnel broker with tunneling over UDP. > > If we want to explore the tunnel broker solution, I do not think RFC3053 > needs an update. It is a framework document that explain the concept of > tunnel broker. > What is needed are two documents: > - one that explain IPv6 over UDP over IPv4 > - one that described a simple automatic protocol to set up the > configuration parameters > between the client (access router) and the tunnel broker. A DHCPv4 > extension would work, > somethink like marc blanchet's TSP protocol would work also. Maybe the > first think to > do is to work on some requirements for such a protocol. > > - Alain. > > Margaret Wasserman wrote: > > > > > Hi Jim, > > > > At 12:59 PM 2/21/2003 -0500, Bound, Jim wrote: > > > >> I caught that in the rfc too. Yes we need an updated tunnel rfc or > >> draft. > >> Would that be valid work here ? Chairs ? > > > > > > I'm not quite sure what you are asking... Are you asking > > about an update to RFC 3053 that would explain how to use > > it over a NAT? > > > > If the need for something like this is indicated by the > > unmanaged or enterprise scenario/analysis efforts, we > > would probably want to pursue this in v6ops (I can't > > think of another WG that would be more appropriate). > > > > Margaret > > > > > > > > > ********************************* Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Pre-register at: http://www.ipv6-es.com Interested in participating or sponsoring ? Contact us at ipv6@consulintel.es From owner-v6ops@ops.ietf.org Sun Feb 23 12:42: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 MAA10318 for ; Sun, 23 Feb 2003 12:42:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n0B7-000CJG-00 for v6ops-data@psg.com; Sun, 23 Feb 2003 09:44:41 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18n0B4-000CJ2-00 for v6ops@ops.ietf.org; Sun, 23 Feb 2003 09:44:38 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA11549; Sun, 23 Feb 2003 09:43:01 -0800 (PST) Message-Id: <5.1.0.14.2.20030223123510.05bb4db8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 23 Feb 2003 12:38:31 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: IPv6 Home Use to stimulate deployment over IPv4-NAT Cc: Alain Durand , "Bound, Jim" , Erik Nordmark , Jeroen Massar , JORDI PALET MARTINEZ , , In-Reply-To: References: <3E585FFE.3090804@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, > > A DHCPv4 extension would work, somethink like marc blanchet's TSP > > protocol would work also. Maybe the first think to do is to work on some > > requirements for such a protocol. > >Indeed, we have to get a better picture on what are the problems and >non-problems. > >For example, DHCP extension works only in scenarios where you obtain the >tunnel connectivity from your direct upstream ISP, the same one that >provides IPv4 connectivity. > >In many cases, this is a non-problem: it is often the case that such >IPv6-active ISP's could provide v6 access using different means already -- >no all though -- if the IPv6-conscious ISP just has to keep natting >routers as CPE's and can't change them in the short term, this could still >be valuable. > >So, we need to have a picture on the scenarios we're trying to address. This is exactly the type of analysis that I would expect as part of the unmanaged analysis document. We have a scenario that needs to be addressed, and we should now perform an analysis of the possible solutions to address that scenario. If you feel that there are scenarios missing from the unmanaged scenario document, or if you feel that we need to add a bit more detail to the existing scenarios (i.e. break out the cases where an in-house NAT does/doesn't forward packets on port 41 for example), please provide that input as part of the last call on the unmanaged scenarios document. Thanks, Margaret From owner-v6ops@ops.ietf.org Sun Feb 23 20:54:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17420 for ; Sun, 23 Feb 2003 20:54:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18n7qE-000EnM-00 for v6ops-data@psg.com; Sun, 23 Feb 2003 17:55:38 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18n7qC-000En5-00 for v6ops@ops.ietf.org; Sun, 23 Feb 2003 17:55:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18n7qA-0001ud-00 for v6ops@ops.ietf.org; Mon, 24 Feb 2003 10:55:34 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 24 Feb 2003 10:55:33 +0900 To: v6ops@ops.ietf.org Subject: draft-ymbk-6to4-arpa-delegation-00.txt Message-Id: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit fyi, i thought i belonged in dnsop randy --- From: Randy Bush To: dns op wg Subject: draft-ymbk-6to4-arpa-delegation-00.txt Date: Mon, 24 Feb 2003 10:07:23 +0900 would the dnsop wg consder adoptng draft-ymbk-6to4-arpa-delegation-00.txt as a wg document? randy From owner-v6ops@ops.ietf.org Mon Feb 24 17:34: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 RAA28934 for ; Mon, 24 Feb 2003 17:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18nRBm-000IGx-00 for v6ops-data@psg.com; Mon, 24 Feb 2003 14:35:10 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18nRBG-000IFN-00 for v6ops@ops.ietf.org; Mon, 24 Feb 2003 14:34:38 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA23450; Mon, 24 Feb 2003 14:34:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h1OMYXn22257; Mon, 24 Feb 2003 14:34:33 -0800 X-mProtect: <200302242234> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd28PHuo; Mon, 24 Feb 2003 14:22:14 PST Message-ID: <3E5A9BDD.9030909@iprg.nokia.com> Date: Mon, 24 Feb 2003 14:25:33 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alain Durand CC: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: Oops! Accepting Enterprise Scenarios as WG Item References: <0F7CBCE9-4536-11D7-BCB3-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain, Sorry I'm just getting to this now, but I don't agree with your point that the "...design team is way too 'transition tool' centric in its approach...". In section 4, we see the following paragraph: "This document will identify those Points of Transition and discuss them within a set of scenarios. This document will not provide solutions. A set of suggested solutions will be provided in a follow on document to this work." To me, this paragraph seems to be setting the appropriate scope for the document and is not at all 'transition tool' centric. Am I missing your point? In any event, I do think the current document takes the right approach (albeit a bit light on text in some sections) and I support it becoming a wg item. Fred Templin ftemplin@iprg.nokia.com Alain Durand wrote: > Margaret, > > First, I would like to say that I appreciate the effort of the > design team to address such a difficult issue. > > However, that said, I'm not very comfortable with this document. > On one hand, it is badly needed and already very late, > on the other hand, I'm not sure it is taking the right direction. > > I already have commented several times that this design team > is way too 'transition tool' centric in its approach, somehow making > the hidden > assumption that solving the 'enterprise' case in the (yet to come) > analysis/solution > document will consist only of picking the 'right' transition tool > developed by NGtrans. > > What I would like to see are things like the following > instantiated for a set of 'typical' enterprise environment: > > - how does the internal networks looks like? > - how is the networks are managed? > (who is responsible, what is outsourced, is IT competent/reliable or > not ...) > - what are the procedure/tools in place to manage the network? > (not only SNMP, but for example tools to create DNS zone files) > - is the public internet used (via VPN...)? > - what are the connections to the Internet? > - Is the v4 address space private or public? > - Is the v4 address space 'portable'? (hint: do they need portable v6 > address space) > - How much v4 address space is available? > - Are they multi-homed? > - how is security enforced? > - how does the datacenter looks like if there is one? > - what kind of applications are used in the > Internet/intranet/extranets/...) > (is it in-house code? is the source code available? is an Ipv6 > version of the > code available to buy?....) > - how naming service/directory service is performed (two face DNS?) > -... > > > > There is a little of that buried in section 4, variable description, > but I think this document should really instantiate those variables > and more (the ones I just described above for example, certainly much > more) > in a set of several 'typical' enterprise environments instead of focusing > on cases describing how enterprises are thinking of deploying v6 at the > IP level > (section 5, which is basically which networks to connect) or abstract > cases of transition mechanisms > (section 6, point of transition methods) which belongs not in this > document > but in the solution document. > > With this in mind, I would not recommend the wg adopting this document. > > - Alain. From owner-v6ops@ops.ietf.org Thu Feb 27 07:48: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 HAA28157 for ; Thu, 27 Feb 2003 07:48:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oNTH-0003Ay-00 for v6ops-data@psg.com; Thu, 27 Feb 2003 04:49:07 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18oNTD-0003Aj-00 for v6ops@ops.ietf.org; Thu, 27 Feb 2003 04:49:04 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27743; Thu, 27 Feb 2003 07:45:04 -0500 (EST) Message-Id: <200302271245.HAA27743@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-mech-v2-00.txt Date: Thu, 27 Feb 2003 07:45:04 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-00.txt Pages : 25 Date : 2003-2-26 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-mech-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-mech-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-mech-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-mech-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160858.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Feb 27 07:49: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 HAA28204 for ; Thu, 27 Feb 2003 07:49:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oNT2-0003A7-00 for v6ops-data@psg.com; Thu, 27 Feb 2003 04:48:52 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18oNSx-000395-00 for v6ops@ops.ietf.org; Thu, 27 Feb 2003 04:48:47 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27684; Thu, 27 Feb 2003 07:44:47 -0500 (EST) Message-Id: <200302271244.HAA27684@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-mickles-v6ops-isp-analysis-00.txt Date: Thu, 27 Feb 2003 07:44:47 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transition Analysis for ISP Networks Author(s) : C. Mickles Filename : draft-mickles-v6ops-isp-analysis-00.txt Pages : 15 Date : 2003-2-26 This document provides analysis of how to transition the different types of Internet Service Provider (ISP) networks to IPv6. It will provide design recommendations which may be followed to successfully deploy IPv6 services on a network that began as an IPv4 network. This is the companion document to draft-mickles-v6ops-isp-scenarios-04.txt which provides detailed background information on all scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-analysis-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-mickles-v6ops-isp-analysis-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-mickles-v6ops-isp-analysis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-26160825.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mickles-v6ops-isp-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mickles-v6ops-isp-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-26160825.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Feb 27 09:31: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 JAA05238 for ; Thu, 27 Feb 2003 09:31:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oP6r-0007dG-00 for v6ops-data@psg.com; Thu, 27 Feb 2003 06:34:05 -0800 Received: from h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by psg.com with smtp (Exim 3.36 #1) id 18oP6k-0007cv-00 for v6ops@ops.ietf.org; Thu, 27 Feb 2003 06:33:58 -0800 Received: (cpmta 2761 invoked from network); 27 Feb 2003 06:33:54 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.115) with SMTP; 27 Feb 2003 06:33:54 -0800 X-Sent: 27 Feb 2003 14:33:54 GMT Message-ID: <009201c2de6d$6e467cf0$67061eac@ttitelecom.com> From: "EricLKlein" To: References: <200302271244.HAA27684@ietf.org> Subject: Re: I-D ACTION:draft-mickles-v6ops-isp-analysis-00.txt Date: Thu, 27 Feb 2003 16:34:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=3.1 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_MULTIHOP_DSBL, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,USER_AGENT_OE version=2.43 X-Spam-Level: *** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As an outline it looks complete, but most of the sections are only headers in need of some meat. ----- Original Message ----- From: To: Cc: Sent: Thursday, February 27, 2003 2:44 PM Subject: I-D ACTION:draft-mickles-v6ops-isp-analysis-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Transition Analysis for ISP Networks > Author(s) : C. Mickles > Filename : draft-mickles-v6ops-isp-analysis-00.txt > Pages : 15 > Date : 2003-2-26 > > This document provides analysis of how to transition the different > types of Internet Service Provider (ISP) networks to IPv6. It > will provide design recommendations which may be followed to > successfully deploy IPv6 services on a network that began as an > IPv4 network. This is the companion document to > draft-mickles-v6ops-isp-scenarios-04.txt which provides detailed > background information on all scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-analysis-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-mickles-v6ops-isp-analysis-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-mickles-v6ops-isp-analysis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-v6ops@ops.ietf.org Thu Feb 27 16:15: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 QAA24079 for ; Thu, 27 Feb 2003 16:15:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oVM9-0003g8-00 for v6ops-data@psg.com; Thu, 27 Feb 2003 13:14:17 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18oVM5-0003fX-00 for v6ops@ops.ietf.org; Thu, 27 Feb 2003 13:14:13 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h1RLE3Y15786; Thu, 27 Feb 2003 23:14:04 +0200 Date: Thu, 27 Feb 2003 23:14:03 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt In-Reply-To: <5.1.0.14.2.20030217115420.036575f0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, On Mon, 17 Feb 2003, Margaret Wasserman wrote: > > This is a WG Last Call for comments on sending the 3GPP scenarios > document to the IESG for consideration as an Informational RFC: > > Title: Transition Scenarios for 3GPP Networks > Filename: draft-ietf-v6ops-3gpp-cases-02.txt > Editor: J. Soininen > Date: January 2003 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-02.txt I've re-read the document, and it seems excellent. I have only two non-editorial issues (well, you could argue these are kinda editorial too :-): However, the IPv4 addresses might be a scarce resource for the mobile operator or an ISP. In that case, it might not be possible for the UE to have a globally unique IPv4 address allocated all the time. Hence, the UE should either activate the IPv4 PDP Context only when needed, or be allocated an IPv4 address from a private address space. ==> should "should" be really "could"? This document is not meant to give solution(s), or advacate IPv4 NAT. 5. Security Considerations This document does not generate any additional security considerations. ==> as many, many drafts will try to pass with security considerations like these, it might be best to be pre-emptive, and explain that there really *are* no additional security considerations here (try to answer the "why"), like: This document describes possible transition scenarios for 3GPP networks for future study. Solutions and mechanism are explored in other documents: the description of the 3GPP network does not have any security considerations. Below, a few editorial nits. Internet Draft J. Soininen, Document: draft-ietf-v6ops-3gpp-cases-02.txt Editor ==> I'd replace the two lines in the right with, like, "J. Soininen (ed.)" This document will describe the transition scenarios in 3GPP packet ==> s/will describe/describes/ The main purpose of this document is to identify, and document those scenarios for further discussion, and for study in the v6ops working group. ==> minor rewording could clarify this: this use of multiple ", and" make it a bit difficult to connect the sentences. For example: The main purpose of this document is to identify and document those scenarios for further discussion and study in the v6ops working group. This document gives neither an overview, nor an explanation of 3GPP or the 3GPP packet data network, GPRS. A good overview of the 3GPP specified GPRS can be found from [1]. The GPRS architecture specification is defined in [2]. ==> Is this entirely accurate? Section 3 includes a very brief description (of the relevant part of the architecture), including the title "GPRS architecture basics". 2. Scope of the document ==> s/d/D/, similar in certain other titles. scenarios with and without the usage of the SIP based IP Multimedia Core Network Subsystem (IMS). ==> the use of "SIP" for the first time, without reference or spelling out the acronym. I'd suggest at least the latter. ==> "SIP based" or "SIP-based" ? (I have no idea...), same with "SIP capable" later on. The scope of this document does not include scenarios inside the GPRS network, i.e. on the different interfaces of the GPRS network. ==> observation: the term "interfaces" could be misleading to those who nowadays think of interfaces as in "network adapters/interfaces", not the interfaces defined by GPRS architecture. Not sure if it's worth changing. 3. Brief description of the 3GPP network environment ==> s/Brief description of the // (and the upper-casigns) -- I agree that it is *very* brief, but the title should be shorter! There is a dedicated link between the UE, and the GGSN called the Packet Data Protocol (PDP) Context. This link is created through the , or to different GGSNs. The PDP Context can be either of the same, or different types. and: possibility to have simultaneous IPv4, and IPv6 PDP Contexts open. ==> s/,// (the lists are so short a comma looks only confusing) A simplified overview of the IMS is depicted in figure 2. +-------------+ +-------------------------------------+ ==> add an empty line between these The SIP proxies, servers, and registrars shown in Figure 2 are as follows. ==> s/./:/ - I-CSCF (Interrogating-CSCF) is the contact point within an operatorÆs ==> s/Æ/'/g (wrong charset/typo?) -- in a few other places too PDP Type IPv6. This means that an 3GPP IP Multimedia terminal uses ==> s/an/a/ This, of course, does not prevent the usage of other unrelated services (e.g. corporate access) on IPv4. ==> s/ This/This/ (extra space) Thus, in cases where the UE is dual stack capable, and in the network there is a GGSN (or separate GGSNs) that supports both connection to IPv4 and IPv6 networks, it is possible to connect to both at the same time. Figure 3 depicts this scenario. ==> "both connection to [...] networks" sounds strange; a singular/plural mistake, need to reword, or something? In this scenario an IPv6 UE connects to an IPv4 node in the IPv4 Internet. ==> s/scenario/scenario,/ (not really necessary..) | IPv4 | | GPRS Core | | | | | | | +------+ +-----------+ +------+ +---+ +------+ Figure 7: IPv4 node communicating with IPv6 node ==> aliging the figure text with the figures would be nice, but probably something best left to the rfc editor process. The authors would like to thank Basavaraj Patil, Tuomo SipilD, Fred ==> s/D/a/ :-) Informative references [1] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", September 2002, RFC3314. Normative References ==> Normative References are should be listed first, by http://www.rfc-editor.org/policy.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Feb 27 17:56: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 RAA26912 for ; Thu, 27 Feb 2003 17:56:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oWz2-000AN6-00 for v6ops-data@psg.com; Thu, 27 Feb 2003 14:58:32 -0800 Received: from addr-mx01.addr.com ([209.249.147.145]) by psg.com with esmtp (Exim 3.36 #1) id 18oWyy-000ALw-00 for v6ops@ops.ietf.org; Thu, 27 Feb 2003 14:58:28 -0800 Received: from proxy1.addr.com (proxy1.addr.com [209.249.147.28]) by addr-mx01.addr.com (8.12.5/8.12.2) with ESMTP id h1RMwQ7j033481 for ; Thu, 27 Feb 2003 14:58:26 -0800 (PST) Received: from Downieville.thefinks.com ([66.81.111.138]) by proxy1.addr.com (8.11.6/8.9.1) with ESMTP id h1RMwPN47773 for ; Thu, 27 Feb 2003 14:58:26 -0800 (PST) (envelope-from bob@thefinks.com)(envelope-to ) Message-Id: <5.2.0.9.0.20030227140849.02175ff0@mail.addr.com> X-Sender: thefink6@mail.addr.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 27 Feb 2003 14:10:35 -0800 To: v6ops@ops.ietf.org From: Bob Fink Subject: new lead/editor for ISP transition Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang) X-Spam-Status: No, hits=1.7 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops wg, I am pleased to announce that Mikael Lind has agreed to take on the lead/editor role for the v6ops ISP transition team. We want to thank Cleve for all his good work to date, and are pleased that he will stay involved as a contributor. Bob, Margaret and Itojun From owner-v6ops@ops.ietf.org Thu Feb 27 18:53:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28125 for ; Thu, 27 Feb 2003 18:53:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oXsy-000EM1-00 for v6ops-data@psg.com; Thu, 27 Feb 2003 15:56:20 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18oXsw-000ELo-00; Thu, 27 Feb 2003 15:56:18 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18oXtC-000I5H-00; Fri, 28 Feb 2003 08:56:34 +0900 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 28 Feb 2003 07:56:33 +0800 To: Pekka Savola Cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt References: <5.1.0.14.2.20030217115420.036575f0@mail.windriver.com> Message-Id: X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I've re-read the document thank you! there are two keys to ietf success, writing of good documents and serious peer review. randy From owner-v6ops@ops.ietf.org Thu Feb 27 19:08: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 TAA28408 for ; Thu, 27 Feb 2003 19:08:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oY7A-000FKX-00 for v6ops-data@psg.com; Thu, 27 Feb 2003 16:11:00 -0800 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 18oY76-000FJE-00 for v6ops@ops.ietf.org; Thu, 27 Feb 2003 16:10:56 -0800 Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29397 for ; Thu, 27 Feb 2003 17:10:55 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HAZ00LYSSGFQI@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 27 Feb 2003 17:10:14 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HAZ00KJGSG33I@mail.sun.net> for v6ops@ops.ietf.org; Thu, 27 Feb 2003 17:09:45 -0700 (MST) Date: Thu, 27 Feb 2003 16:10:49 -0800 From: Alain Durand Subject: dual stack & IPv6 on by default In-reply-to: To: v6ops@ops.ietf.org Cc: Sebastien Roy , jim.Paugh@Sun.COM Message-id: <17B552A2-4AB1-11D7-A7BB-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT My colleagues (Sebastien Roy & Jim Paugh) from Sun & I wrote a draft on dual stack implementations and turning IPv6 on by default on them. http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-00.txt We would like to offer it as a contribution to v6ops and would like to receive feedback from the wg. - Alain. Abstract The dual stack model is based on the assumption that applications can try communicating to destinations over IPv6 first and fall back to IPv4 if IPv6 doesn't work. Before turning the dual stack on by default, we need to make sure that this assumption holds even in cases where IPv6 connectivity is not perfect. This document looks at scenarios in which things can go wrong if the IPv6 dual stack is enabled by default. From owner-v6ops@ops.ietf.org Fri Feb 28 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 GAA20839 for ; Fri, 28 Feb 2003 06:32:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oikf-0003Fa-00 for v6ops-data@psg.com; Fri, 28 Feb 2003 03:32:29 -0800 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 18oikc-0003FM-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 03:32:26 -0800 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h1SBZYm16863 for ; Fri, 28 Feb 2003 13:35:34 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Feb 2003 13:32:23 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 28 Feb 2003 13:32:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Date: Fri, 28 Feb 2003 13:32:21 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC37CF@esebe005.ntc.nokia.com> Thread-Topic: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Thread-Index: AcLepxHO3cPtgyVXQp6ey/QwIHWHDQAcPjBw From: To: Cc: , , X-OriginalArrivalTime: 28 Feb 2003 11:32:22.0366 (UTC) FILETIME=[0F4EBFE0:01C2DF1D] X-Spam-Status: No, hits=1.8 required=5.0 tests=NO_REAL_NAME,SPAM_PHRASE_01_02 version=2.43 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA20839 Pekka, thank you very much for your review and the comments! Jonne S. may have some additional comments, but I start giving comments below (marked JW): -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 27 February, 2003 23:14 However, the IPv4 addresses might be a scarce resource for the mobile operator or an ISP. In that case, it might not be possible for the UE to have a globally unique IPv4 address allocated all the time. Hence, the UE should either activate the IPv4 PDP Context only when needed, or be allocated an IPv4 address from a private address space. ==> should "should" be really "could"? This document is not meant to give solution(s), or advacate IPv4 NAT. JW: Yep, we do not want to advocat v4 NAT, that's for sure. "Could" (or even "can") makes sense to me. 5. Security Considerations This document does not generate any additional security considerations. ==> as many, many drafts will try to pass with security considerations like these, it might be best to be pre-emptive, and explain that there really *are* no additional security considerations here (try to answer the "why"), like: This document describes possible transition scenarios for 3GPP networks for future study. Solutions and mechanism are explored in other documents: the description of the 3GPP network does not have any security considerations. JW: Thanks for your suggestion! This text is ok at least for me. Below, a few editorial nits. Internet Draft J. Soininen, Document: draft-ietf-v6ops-3gpp-cases-02.txt Editor ==> I'd replace the two lines in the right with, like, "J. Soininen (ed.)" JW: Hmm, why not. I can do the same for the 3GPP analysis doc too (revision -02 with minor changes shall be published soon). This document will describe the transition scenarios in 3GPP packet ==> s/will describe/describes/ JW: Agreed. The main purpose of this document is to identify, and document those scenarios for further discussion, and for study in the v6ops working group. ==> minor rewording could clarify this: this use of multiple ", and" make it a bit difficult to connect the sentences. For example: The main purpose of this document is to identify and document those scenarios for further discussion and study in the v6ops working group. JW: Sounds ok. This document gives neither an overview, nor an explanation of 3GPP or the 3GPP packet data network, GPRS. A good overview of the 3GPP specified GPRS can be found from [1]. The GPRS architecture specification is defined in [2]. ==> Is this entirely accurate? Section 3 includes a very brief description (of the relevant part of the architecture), including the title "GPRS architecture basics". JW: Ok... this text was written when there was no environment description in the document (yet). This kind of text might work better: "This document gives a very brief overview on the 3GPP packet data network, GPRS. A good overview of the 3GPP specified GPRS can be found from [1]. The GPRS architecture specification is defined in [2]." 2. Scope of the document ==> s/d/D/, similar in certain other titles. JW: Yep, this is the US style. :-) I have to do the same for the 3GPP analysis doc... scenarios with and without the usage of the SIP based IP Multimedia Core Network Subsystem (IMS). ==> the use of "SIP" for the first time, without reference or spelling out the acronym. I'd suggest at least the latter. JW: ok. ==> "SIP based" or "SIP-based" ? (I have no idea...), same with "SIP capable" later on. The scope of this document does not include scenarios inside the GPRS network, i.e. on the different interfaces of the GPRS network. JW: I would use hyphen, but maybe some native speaker can enlighten us... ==> observation: the term "interfaces" could be misleading to those who nowadays think of interfaces as in "network adapters/interfaces", not the interfaces defined by GPRS architecture. Not sure if it's worth changing. JW: We have to check this... No opinion yet. 3. Brief description of the 3GPP network environment ==> s/Brief description of the // (and the upper-casigns) -- I agree that it is *very* brief, but the title should be shorter! JW: Maybe... Short subsection can not have too long title. Just using e.g. "3GPP network environment" and just tell in the text that the description is a short one? There is a dedicated link between the UE, and the GGSN called the Packet Data Protocol (PDP) Context. This link is created through the , or to different GGSNs. The PDP Context can be either of the same, or different types. and: possibility to have simultaneous IPv4, and IPv6 PDP Contexts open. ==> s/,// (the lists are so short a comma looks only confusing) JW: Yep, we'll check those. A simplified overview of the IMS is depicted in figure 2. +-------------+ +-------------------------------------+ ==> add an empty line between these JW: Agreed. The SIP proxies, servers, and registrars shown in Figure 2 are as follows. ==> s/./:/ JW: OK. - I-CSCF (Interrogating-CSCF) is the contact point within an operatorÆs ==> s/Æ/'/g (wrong charset/typo?) -- in a few other places too JW: Clearly a non-ASCII char, have to check it. PDP Type IPv6. This means that an 3GPP IP Multimedia terminal uses ==> s/an/a/ JW: Yep. This, of course, does not prevent the usage of other unrelated services (e.g. corporate access) on IPv4. ==> s/ This/This/ (extra space) JW: Got it. Thus, in cases where the UE is dual stack capable, and in the network there is a GGSN (or separate GGSNs) that supports both connection to IPv4 and IPv6 networks, it is possible to connect to both at the same time. Figure 3 depicts this scenario. ==> "both connection to [...] networks" sounds strange; a singular/plural mistake, need to reword, or something? JW: We consider small rewording, that is needed. In this scenario an IPv6 UE connects to an IPv4 node in the IPv4 Internet. ==> s/scenario/scenario,/ (not really necessary..) JW: I would also use the comma here. | IPv4 | | GPRS Core | | | | | | | +------+ +-----------+ +------+ +---+ +------+ Figure 7: IPv4 node communicating with IPv6 node ==> aliging the figure text with the figures would be nice, but probably something best left to the rfc editor process. JW: Ok, we see if something can be done. The authors would like to thank Basavaraj Patil, Tuomo SipilD, Fred ==> s/D/a/ :-) JW: Yup, let's make him Mr. Sipila, not Sipilä. :-) Informative references [1] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", September 2002, RFC3314. Normative References ==> Normative References are should be listed first, by http://www.rfc-editor.org/policy.html JW: Yes, this small fix will be done. Thanks once again! -Juha- From owner-v6ops@ops.ietf.org Fri Feb 28 07:55: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 HAA25158 for ; Fri, 28 Feb 2003 07:55:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ok4k-0006OV-00 for v6ops-data@psg.com; Fri, 28 Feb 2003 04:57:18 -0800 Received: from [3ffe:8114:1000::27] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 18ok4h-0006OA-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 04:57:15 -0800 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id EBC377DE9; Fri, 28 Feb 2003 13:57:10 +0100 (CET) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 095587819; Fri, 28 Feb 2003 13:57:04 +0100 (CET) From: "Jeroen Massar" To: <6bone@ISI.EDU>, Subject: Ghosts for 3ffe:1f00::/24 and 3ffe:3000::/24 - Check your routers Date: Fri, 28 Feb 2003 13:57:43 +0100 Organization: Unfix Message-ID: <005601c2df28$fccc0470$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Spam-Status: No, hits=0.6 required=5.0 tests=NOSPAM_INC,SPAM_PHRASE_02_03 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA25158 Hi, As per usual on http://www.sixxs.net/tools/grh/ghosts/. 3ffe:3000::/24 has been retracted 4 days ago and is still lingering in the routing tables. 3ffe:1f00::/24 has been lingering for 1+ day now. Can people check up their _backbone_ routers and tell what they see about these prefixes? I am very interrested in knowing what people see coming in from SPRINT (AS6175), FIBERTEL (AS10318) and ATT-EMEA (AS5623) Also please submit your IPv6 traceroute's, lookingglasses, Route Servers and ASpaths tools to Jakub if you are maintaining an AS. See http://www.traceroute6.org for more information. Having these would make hunting down these ghosts so much easier. Greets, Jeroen From owner-v6ops@ops.ietf.org Fri Feb 28 13:06: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 NAA07605 for ; Fri, 28 Feb 2003 13:06:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18oovi-000KGC-00 for v6ops-data@psg.com; Fri, 28 Feb 2003 10:08:18 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18oovc-000KFj-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 10:08:12 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18oovc-0000SC-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 10:08:12 -0800 Message-ID: <011901c2df30$3fcd2b30$6ea0fea9@DanLaptop> References: <005601c2df28$fccc0470$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Daniel Austin" To: "Jeroen Massar" , <6bone@ISI.EDU>, Subject: Re: [6bone] Ghosts for 3ffe:1f00::/24 and 3ffe:3000::/24 - Check your routers Date: Fri, 28 Feb 2003 13:49:42 -0000 X-Spam-Status: No, hits=-0.4 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] We see both of these prefixes via AS1752 (BTexact over UK6X) and AS15703 (Trueserver BV over LIPEX). 2 paths to each. (our LG/traceroute is present on traceroute6.org) With Thanks, Daniel Austin, Managing Director, Kewlio.net Limited. ----- Original Message ----- From: "Jeroen Massar" To: <6bone@ISI.EDU>; Sent: Friday, February 28, 2003 12:57 PM Subject: [6bone] Ghosts for 3ffe:1f00::/24 and 3ffe:3000::/24 - Check your routers > Hi, > > As per usual on http://www.sixxs.net/tools/grh/ghosts/. > 3ffe:3000::/24 has been retracted 4 days ago and > is still lingering in the routing tables. > 3ffe:1f00::/24 has been lingering for 1+ day now. > > Can people check up their _backbone_ routers and tell > what they see about these prefixes? > > I am very interrested in knowing what people see coming > in from SPRINT (AS6175), FIBERTEL (AS10318) and ATT-EMEA (AS5623) > > Also please submit your IPv6 traceroute's, lookingglasses, > Route Servers and ASpaths tools to Jakub if you are maintaining an AS. > See http://www.traceroute6.org for more information. > Having these would make hunting down these ghosts so much easier. > > Greets, > Jeroen > > _______________________________________________ > 6bone mailing list > 6bone@mailman.isi.edu > http://mailman.isi.edu/mailman/listinfo/6bone > From owner-v6ops@ops.ietf.org Fri Feb 28 13:11: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 NAA07829 for ; Fri, 28 Feb 2003 13:11:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18op2b-000Kec-00 for v6ops-data@psg.com; Fri, 28 Feb 2003 10:15:25 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18op2V-000KeA-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 10:15:19 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18op2V-0000Vt-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 10:15:19 -0800 Message-ID: <01b401c2df45$3820b400$da213ed2@sinica.edu.tw> References: <005601c2df28$fccc0470$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit From: "Ethern Lin" To: "Jeroen Massar" , <6bone@ISI.EDU>, Subject: Re: Ghosts for 3ffe:1f00::/24 and 3ffe:3000::/24 - Check your routers Date: Sat, 1 Mar 2003 00:19:38 +0800 X-Spam-Status: No, hits=-0.3 required=5.0 tests=DEAR_SOMEBODY,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_03_05 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Dear Jeroen, Here is the routes we received: noc@j1> show route 3ffe:3000::/24 inet6.0: 543 destinations, 549 routes (543 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 3ffe:3000::/24 *[BGP/170] 10:35:18, localpref 180, from 2001:288:3b0::23 AS path: 7660 2500 3549 6175 10318 5623 5609 3320 6939 4725 4697 20834 513 16091 8903 1752 13193 10566 13944 25336 6830 1200 I > to fe80::210:f6ff:fe7f:1180 via fxp1.0 noc@j1> show route 3ffe:1f00::/24 inet6.0: 543 destinations, 549 routes (543 active, 0 holddown, 0 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 3ffe:1f00::/24 *[BGP/170] 23:16:20, localpref 180, from 2001:288:3b0::23 AS path: 7660 2500 4697 3320 293 6175 7580 10566 15180 1251 1916 11537 22 5609 6830 1755 I > to fe80::210:f6ff:fe7f:1180 via fxp1.0 noc@j1> You can check these routes from the following information: http://mrlg.ipv6.ascc.net/ http://bgp.ipv6.ascc.net/ Ethern ASNET/TW ----- Original Message ----- From: "Jeroen Massar" To: <6bone@ISI.EDU>; Sent: Friday, February 28, 2003 8:57 PM Subject: Ghosts for 3ffe:1f00::/24 and 3ffe:3000::/24 - Check your routers > Hi, > > As per usual on http://www.sixxs.net/tools/grh/ghosts/. > 3ffe:3000::/24 has been retracted 4 days ago and > is still lingering in the routing tables. > 3ffe:1f00::/24 has been lingering for 1+ day now. > > Can people check up their _backbone_ routers and tell > what they see about these prefixes? > > I am very interrested in knowing what people see coming > in from SPRINT (AS6175), FIBERTEL (AS10318) and ATT-EMEA (AS5623) > > Also please submit your IPv6 traceroute's, lookingglasses, > Route Servers and ASpaths tools to Jakub if you are maintaining an AS. > See http://www.traceroute6.org for more information. > Having these would make hunting down these ghosts so much easier. > > Greets, > Jeroen > > From owner-v6ops@ops.ietf.org Fri Feb 28 13:38: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 NAA08497 for ; Fri, 28 Feb 2003 13:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18opS4-000M2r-00 for v6ops-data@psg.com; Fri, 28 Feb 2003 10:41:44 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18opRr-000M2Q-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 10:41:31 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.31]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA13658; Fri, 28 Feb 2003 10:40:00 -0800 (PST) Message-Id: <5.1.0.14.2.20030228133659.036b3b70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Feb 2003 13:37:49 -0500 To: juha.wiljakka@nokia.com From: Margaret Wasserman Subject: RE: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Cc: , , In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC37CF@esebe005.ntc.nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Juha, At 01:32 PM 2/28/2003 +0200, juha.wiljakka@nokia.com wrote: >==> "SIP based" or "SIP-based" ? (I have no idea...), same with "SIP >capable" later on. > > The scope of this document does not include scenarios inside the GPRS > network, i.e. on the different interfaces of the GPRS network. > > JW: I would use hyphen, but maybe some native speaker can enlighten us... I'd use a hyphen for both SIP-based and SIP-capable. But, hey, I like hyphens :-). Margaret From owner-v6ops@ops.ietf.org Fri Feb 28 13:38: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 NAA08533 for ; Fri, 28 Feb 2003 13:38:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18opRu-000M2Y-00 for v6ops-data@psg.com; Fri, 28 Feb 2003 10:41:34 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 18opRn-000M2C-00 for v6ops@ops.ietf.org; Fri, 28 Feb 2003 10:41:27 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.31]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA13612; Fri, 28 Feb 2003 10:39:58 -0800 (PST) Message-Id: <5.1.0.14.2.20030228133150.00bbb0a8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 28 Feb 2003 13:32:53 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: WG Last Call: draft-ietf-v6ops-3gpp-cases-02.txt Cc: v6ops@ops.ietf.org In-Reply-To: References: <5.1.0.14.2.20030217115420.036575f0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I've re-read the document, and it seems excellent. Thanks, Pekka. >I have only two non-editorial issues (well, you could argue these are >kinda editorial too :-): > > However, the IPv4 addresses might be a scarce resource for the mobile > operator or an ISP. In that case, it might not be possible for the UE > to have a globally unique IPv4 address allocated all the time. Hence, > the UE should either activate the IPv4 PDP Context only when needed, > or be allocated an IPv4 address from a private address space. > >==> should "should" be really "could"? This document is not meant to give >solution(s), or advacate IPv4 NAT. > >5. Security Considerations > > This document does not generate any additional security > considerations. > >==> as many, many drafts will try to pass with security considerations >like these, it might be best to be pre-emptive, and explain that there >really *are* no additional security considerations here (try to answer the >"why"), like: > > This document describes possible transition scenarios for 3GPP > networks for future study. Solutions and mechanism are explored in > other documents: the description of the 3GPP network does not have > any security considerations. I agree with both of these points. Margaret