From owner-v6ops@ops.ietf.org Thu May 1 11:41:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17987 for ; Thu, 1 May 2003 11:41:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BG9k-000Ah8-00 for v6ops-data@psg.com; Thu, 01 May 2003 15:39:32 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19BG9i-000Ags-00 for v6ops@ops.ietf.org; Thu, 01 May 2003 15:39:30 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA12115; Thu, 1 May 2003 08:39:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h41FdQQ18935; Thu, 1 May 2003 08:39:26 -0700 X-mProtect: <200305011539> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhPGAZb; Thu, 01 May 2003 08:39:25 PDT Message-ID: <3EB14086.6070108@iprg.nokia.com> Date: Thu, 01 May 2003 08:43:02 -0700 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: itojun@iijlab.net CC: Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: <20030501024124.323D099@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: >>> 1280 is the only link MTU requirement value appears in RFC2460, and it >>> is the minimum required value for any IPv6 links (which does not >> >>It is true that 1280 is the minimum required value for an IPv6 link. But, >>the reason we use, e.g., 1500 for Ethernet instead of 1280 is that 1500 >>provides greater efficiency w/o resulting in black holes or excessive link >>layer fragmentation. IPv6-in-IPv4 tunnels should strike a similar balance >>by setting an MTU of up to 1380 bytes. > > > i disagree. You disagree that IPv6 links should strive for greater efficiency by setting a larger MTU than the IPv6 minimum of 1280 bytes if possible? > what is the reasoning behind "1380"? See: 'draft-ietf-ngtrans-isatap-13.txt', section 6.1. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu May 1 19:17:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18017 for ; Thu, 1 May 2003 19:17:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BNJG-000LPf-00 for v6ops-data@psg.com; Thu, 01 May 2003 23:17:50 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19BNJD-000LPP-00 for v6ops@ops.ietf.org; Thu, 01 May 2003 23:17:47 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 2545A93; Fri, 2 May 2003 08:17:45 +0900 (JST) To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-reply-to: ftemplin's message of Thu, 01 May 2003 08:43:02 MST. <3EB14086.6070108@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt From: itojun@iijlab.net Date: Fri, 02 May 2003 08:17:45 +0900 Message-Id: <20030501231745.2545A93@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>> 1280 is the only link MTU requirement value appears in RFC2460, and it >>>> is the minimum required value for any IPv6 links (which does not >>> >>>It is true that 1280 is the minimum required value for an IPv6 link. But, >>>the reason we use, e.g., 1500 for Ethernet instead of 1280 is that 1500 >>>provides greater efficiency w/o resulting in black holes or excessive link >>>layer fragmentation. IPv6-in-IPv4 tunnels should strike a similar balance >>>by setting an MTU of up to 1380 bytes. >> i disagree. >You disagree that IPv6 links should strive for greater efficiency by >setting a larger MTU than the IPv6 minimum of 1280 bytes if possible? correct. if you want efficiency, dynamic MTU case in mech-v2 should give you the efficiency. leave non-dynamic as is (1280). itojun From owner-v6ops@ops.ietf.org Thu May 1 19:20:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18161 for ; Thu, 1 May 2003 19:20:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BNO9-000MFm-00 for v6ops-data@psg.com; Thu, 01 May 2003 23:22:53 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19BNO4-000MFO-00 for v6ops@ops.ietf.org; Thu, 01 May 2003 23:22:49 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA07150; Thu, 1 May 2003 16:22:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h41NMk903585; Thu, 1 May 2003 16:22:46 -0700 X-mProtect: <200305012322> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxaCXQB; Thu, 01 May 2003 16:22:44 PDT Message-ID: <3EB1AD1F.4080601@iprg.nokia.com> Date: Thu, 01 May 2003 16:26:23 -0700 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: itojun@iijlab.net CC: Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: <20030501231745.2545A93@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: >>You disagree that IPv6 links should strive for greater efficiency by >>setting a larger MTU than the IPv6 minimum of 1280 bytes if possible? > > > correct. if you want efficiency, dynamic MTU case in mech-v2 > should give you the efficiency. leave non-dynamic as is (1280). Can you state your technical objections to setting a larger non-dynamic value of 1380? Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri May 2 07:12: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 HAA11423 for ; Fri, 2 May 2003 07:12:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BYR9-0008F6-00 for v6ops-data@psg.com; Fri, 02 May 2003 11:10:43 +0000 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 19BYR6-0008En-00 for v6ops@ops.ietf.org; Fri, 02 May 2003 11:10:40 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4DE395580; Fri, 2 May 2003 07:10:36 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 2 May 2003 07:10:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Dynamic DNS Date: Fri, 2 May 2003 07:10:35 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD612@tayexc13.americas.cpqcorp.net> Thread-Topic: Dynamic DNS Thread-Index: AcMLUcSZrX0ng54yQgKIqGvAtUGfegFSV5qA From: "Bound, Jim" To: , "BEGIN, Thomas" , X-OriginalArrivalTime: 02 May 2003 11:10:36.0161 (UTC) FILETIME=[74C5EF10:01C3109B] X-Spam-Status: No, hits=-9.0 required=5.0 tests=BAYES_10,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA11423 Tony, Excuse me but why do you say MS? There are many operating systems that have deployed IPv6 that in fact do autoregisration. Thomas, Send me mail off line you can post this question to an IPv6 Forum implementors list where Linux, BSD, UNIXes, Microsoft, and Proprietary OS developers exist to answer this question. Also handheld developers. Thanks /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Friday, April 25, 2003 1:36 PM > To: 'BEGIN, Thomas'; v6ops@ops.ietf.org > Subject: RE: Dynamic DNS > > > Thomas, > > These questions are more appropriate for an MS mail list on > IPv6. I am not sure which one, but you might start with > IPv6-fb@microsoft.com. > > That said, the early ship versions of many implementations > continue to rely on IPv4 for transport of services like DNS & > SNMP. Trying to build an IPv6-only network in the short term > will be a matter of persistence and working out which > products and services will work without IPv4 in your network. > Over time it will be possible to remove IPv4 from the > network, but if we required that from the start we would > never get anything deployed because there are too many > players to synchronize. > > Tony > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of BEGIN, Thomas > > Sent: Thursday, April 24, 2003 5:45 AM > > To: v6ops@ops.ietf.org > > Subject: Dynamic DNS > > > > > > Hello, > > > > I'm working on the relationship between IPv6 and DynamicDNS > > on several OS. I've succeeded in making my testbed with an > > automatic registration into the DNS at the startup of > > computers. Then IPv4 and v6 addresses are well recorded > > inside the DNS. But the fact is that I still have the IPv4 > > network. Next I tried to put off the IPv4 protocol from the > > network and get an only IPv6 network. > > * For the linux machines -> no problems > > * For the windows 2003 machines -> they are no more recorded > > inside the DNS table > > > > Thus I have few questions about this thema : > > - Is there anything special to setup in the OS to allow > > dynamic updates over IPv6 ? may be in the netsh tool ? I've > > searched myself and haven't found ... > > - Is IPv4 necessary to carry the register messages that > > serves for the dynamic DNS updates ? It would mean that IPv6 > > is not autonomous on the new windows OS ? strange ... > > - Is there an equivalent of the command ipconfig /registerdns > > ... that exists when IPv4 is shut down ? > > > > Regards > > - Thomas > > > > > > > From owner-v6ops@ops.ietf.org Fri May 2 07:56: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 HAA11962 for ; Fri, 2 May 2003 07:56:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BZBU-000FDB-00 for v6ops-data@psg.com; Fri, 02 May 2003 11:58:36 +0000 Received: from [193.72.156.161] (helo=mercury.telscom.ch) by psg.com with esmtp (Exim 3.36 #1) id 19BZBQ-000FCq-00 for v6ops@ops.ietf.org; Fri, 02 May 2003 11:58:33 +0000 Received: from Dell (193.135.153.254) by mercury.telscom.ch with MERCUR-SMTP/POP3/IMAP4-Server (v3.30.09 AS-2621446) for ; Fri, 2 May 2003 13:53:19 +0200 Message-ID: <015501c310a2$162c3c50$3b13a8c0@Dell> From: "Sathya Rao" To: , "BEGIN, Thomas" , References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD612@tayexc13.americas.cpqcorp.net> Subject: Re: Dynamic DNS Date: Fri, 2 May 2003 13:57:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Reply-To: rao@telscom.ch X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, The problem the way I understand is that with MS we cannot get rid of IPv4 stack, whereas with others we can do. That is one of the problem we came across while developing VoIPv6 (6VOICE), which is operational with LINUX but not with MS. Sathya ----- Original Message ----- From: "Bound, Jim" To: ; "BEGIN, Thomas" ; Sent: Friday, May 02, 2003 1:10 PM Subject: RE: Dynamic DNS Tony, Excuse me but why do you say MS? There are many operating systems that have deployed IPv6 that in fact do autoregisration. Thomas, Send me mail off line you can post this question to an IPv6 Forum implementors list where Linux, BSD, UNIXes, Microsoft, and Proprietary OS developers exist to answer this question. Also handheld developers. Thanks /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Friday, April 25, 2003 1:36 PM > To: 'BEGIN, Thomas'; v6ops@ops.ietf.org > Subject: RE: Dynamic DNS > > > Thomas, > > These questions are more appropriate for an MS mail list on > IPv6. I am not sure which one, but you might start with > IPv6-fb@microsoft.com. > > That said, the early ship versions of many implementations > continue to rely on IPv4 for transport of services like DNS & > SNMP. Trying to build an IPv6-only network in the short term > will be a matter of persistence and working out which > products and services will work without IPv4 in your network. > Over time it will be possible to remove IPv4 from the > network, but if we required that from the start we would > never get anything deployed because there are too many > players to synchronize. > > Tony > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of BEGIN, Thomas > > Sent: Thursday, April 24, 2003 5:45 AM > > To: v6ops@ops.ietf.org > > Subject: Dynamic DNS > > > > > > Hello, > > > > I'm working on the relationship between IPv6 and DynamicDNS > > on several OS. I've succeeded in making my testbed with an > > automatic registration into the DNS at the startup of > > computers. Then IPv4 and v6 addresses are well recorded > > inside the DNS. But the fact is that I still have the IPv4 > > network. Next I tried to put off the IPv4 protocol from the > > network and get an only IPv6 network. > > * For the linux machines -> no problems > > * For the windows 2003 machines -> they are no more recorded > > inside the DNS table > > > > Thus I have few questions about this thema : > > - Is there anything special to setup in the OS to allow > > dynamic updates over IPv6 ? may be in the netsh tool ? I've > > searched myself and haven't found ... > > - Is IPv4 necessary to carry the register messages that > > serves for the dynamic DNS updates ? It would mean that IPv6 > > is not autonomous on the new windows OS ? strange ... > > - Is there an equivalent of the command ipconfig /registerdns > > ... that exists when IPv4 is shut down ? > > > > Regards > > - Thomas > > > > > > > From owner-v6ops@ops.ietf.org Fri May 2 10:21: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 KAA16058 for ; Fri, 2 May 2003 10:21:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BbQc-000CiK-00 for v6ops-data@psg.com; Fri, 02 May 2003 14:22:22 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19BbQa-000Ccc-00 for v6ops@ops.ietf.org; Fri, 02 May 2003 14:22:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h42EM0629261; Fri, 2 May 2003 17:22:01 +0300 Date: Fri, 2 May 2003 17:22:00 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: "Fred L. Templin" , Erik Nordmark , Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt In-Reply-To: <20030430070915.7EA8694@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 30 Apr 2003 itojun@iijlab.net wrote: > >I fail to see your point; how is 1280 "simpler" than 1380? It's > >just a static MTU assignment in either case. You will need to > >define "simplicity" for your arguement to even make sense. > > 1280 is the only link MTU requirement value appears in RFC2460, and it > is the minimum required value for any IPv6 links (which does not > require wacky fragmentation header rule at the end of 2460 section 5). > i dunno what word other than "simple" would capture this. Correct me if wrong, but it appears the fragmentation header rule must be included also for the case of MTU 1280 when the IPv4 IP-IP tunnels have DF bit set. Which appears to be the typical case, e.g. one major router vendor doesn't even support anything else. -- 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 May 2 21:04: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 VAA08515 for ; Fri, 2 May 2003 21:04:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BiLB-000LzA-00 for v6ops-data@psg.com; Fri, 02 May 2003 21:45:13 +0000 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 19BiL7-000Lyk-00 for v6ops@ops.ietf.org; Fri, 02 May 2003 21:45:10 +0000 Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 02 May 2003 14:45:08 -0700 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , "'BEGIN, Thomas'" , Subject: RE: Dynamic DNS Date: Fri, 2 May 2003 14:44:58 -0700 Message-ID: <0a3801c310f4$14246520$261e4104@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: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD612@tayexc13.americas.cpqcorp.net> X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA08515 I was commenting on his issue with lack of records in the Windows server dns table. As I read it the linux implementation was working for him, and he was having a problem with the MS one. I was not saying anything else. Tony > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Friday, May 02, 2003 4:11 AM > To: alh-ietf@tndh.net; BEGIN, Thomas; v6ops@ops.ietf.org > Subject: RE: Dynamic DNS > > > Tony, > > Excuse me but why do you say MS? There are many operating > systems that have deployed IPv6 that in fact do autoregisration. > > Thomas, > > Send me mail off line you can post this question to an IPv6 > Forum implementors list where Linux, BSD, UNIXes, Microsoft, > and Proprietary OS developers exist to answer this question. > Also handheld developers. > > Thanks > /jim > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Friday, April 25, 2003 1:36 PM > > To: 'BEGIN, Thomas'; v6ops@ops.ietf.org > > Subject: RE: Dynamic DNS > > > > > > Thomas, > > > > These questions are more appropriate for an MS mail list on > > IPv6. I am not sure which one, but you might start with > > IPv6-fb@microsoft.com. > > > > That said, the early ship versions of many implementations > > continue to rely on IPv4 for transport of services like DNS & > > SNMP. Trying to build an IPv6-only network in the short term > > will be a matter of persistence and working out which > > products and services will work without IPv4 in your network. > > Over time it will be possible to remove IPv4 from the > > network, but if we required that from the start we would > > never get anything deployed because there are too many > > players to synchronize. > > > > Tony > > > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On > > > Behalf Of BEGIN, > Thomas > > > Sent: Thursday, April 24, 2003 5:45 AM > > > To: v6ops@ops.ietf.org > > > Subject: Dynamic DNS > > > > > > > > > Hello, > > > > > > I'm working on the relationship between IPv6 and DynamicDNS on > > > several OS. I've succeeded in making my testbed with an automatic > > > registration into the DNS at the startup of computers. > Then IPv4 and > > > v6 addresses are well recorded inside the DNS. But the > fact is that > > > I still have the IPv4 network. Next I tried to put off the IPv4 > > > protocol from the network and get an only IPv6 network. > > > * For the linux machines -> no problems > > > * For the windows 2003 machines -> they are no more recorded > > > inside the DNS table > > > > > > Thus I have few questions about this thema : > > > - Is there anything special to setup in the OS to allow dynamic > > > updates over IPv6 ? may be in the netsh tool ? I've > searched myself > > > and haven't found ... > > > - Is IPv4 necessary to carry the register messages that > > > serves for the dynamic DNS updates ? It would mean that IPv6 > > > is not autonomous on the new windows OS ? strange ... > > > - Is there an equivalent of the command ipconfig /registerdns > > > ... that exists when IPv4 is shut down ? > > > > > > Regards > > > - Thomas > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Fri May 2 21:14: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 VAA08648 for ; Fri, 2 May 2003 21:14:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BldD-0001i5-00 for v6ops-data@psg.com; Sat, 03 May 2003 01:16:03 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19BldA-0001hk-00 for v6ops@ops.ietf.org; Sat, 03 May 2003 01:16:01 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6E3F193; Sat, 3 May 2003 10:15:56 +0900 (JST) To: Pekka Savola Cc: "Fred L. Templin" , Erik Nordmark , v6ops@ops.ietf.org In-reply-to: pekkas's message of Fri, 02 May 2003 17:22:00 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt From: itojun@iijlab.net Date: Sat, 03 May 2003 10:15:56 +0900 Message-Id: <20030503011556.6E3F193@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> 1280 is the only link MTU requirement value appears in RFC2460, and it >> is the minimum required value for any IPv6 links (which does not >> require wacky fragmentation header rule at the end of 2460 section 5). >> i dunno what word other than "simple" would capture this. >Correct me if wrong, but it appears the fragmentation header rule must be >included also for the case of MTU 1280 when the IPv4 IP-IP tunnels have DF >bit set. Which appears to be the typical case, e.g. one major router >vendor doesn't even support anything else. i don't understand your scenario. even if there's IPv4-over-IPv4 tunnel with outer DF bit set, ICMPv4 too big won't get propagated to IPv6-over-IPv4 endpoint, nor IPv6 source. itojun From owner-v6ops@ops.ietf.org Sat May 3 06:49: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 GAA27613 for ; Sat, 3 May 2003 06:49:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19BuaT-0009X1-00 for v6ops-data@psg.com; Sat, 03 May 2003 10:49:49 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19BuaR-0009Wi-00 for v6ops@ops.ietf.org; Sat, 03 May 2003 10:49:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h43AnTw03905; Sat, 3 May 2003 13:49:30 +0300 Date: Sat, 3 May 2003 13:49:28 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: "Fred L. Templin" , Erik Nordmark , Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt In-Reply-To: <20030503011556.6E3F193@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 3 May 2003 itojun@iijlab.net wrote: > >> 1280 is the only link MTU requirement value appears in RFC2460, and it > >> is the minimum required value for any IPv6 links (which does not > >> require wacky fragmentation header rule at the end of 2460 section 5). > >> i dunno what word other than "simple" would capture this. > >Correct me if wrong, but it appears the fragmentation header rule must be > >included also for the case of MTU 1280 when the IPv4 IP-IP tunnels have DF > >bit set. Which appears to be the typical case, e.g. one major router > >vendor doesn't even support anything else. > > i don't understand your scenario. even if there's IPv4-over-IPv4 > tunnel with outer DF bit set, ICMPv4 too big won't get propagated > to IPv6-over-IPv4 endpoint, nor IPv6 source. What I'm trying to say is that there are implementations of IP-IP tunneling (subsequently, IPv6-over-IPv4), which always set DF bit in the IPv4 header. In case that IPv4 path MTU is below 1300 bytes, the wacky fragmentation header rule needs to stay anyway -- unless these implementations are deemed non-compliant. So, in practice, PMTUD may be necessary (to lower the MTU) in these cases even if IPv6 nodes only send packets of 1280 bytes or smaller. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Sat May 3 13:44:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03819 for ; Sat, 3 May 2003 13:44:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19C14D-000OcJ-00 for v6ops-data@psg.com; Sat, 03 May 2003 17:44:57 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19C14B-000Oc6-00 for v6ops@ops.ietf.org; Sat, 03 May 2003 17:44:56 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id BA92A18; Sun, 4 May 2003 02:44:53 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Sat, 03 May 2003 13:49:28 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt From: itojun@iijlab.net Date: Sun, 04 May 2003 02:44:53 +0900 Message-Id: <20030503174453.BA92A18@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> i don't understand your scenario. even if there's IPv4-over-IPv4 >> tunnel with outer DF bit set, ICMPv4 too big won't get propagated >> to IPv6-over-IPv4 endpoint, nor IPv6 source. >What I'm trying to say is that there are implementations of IP-IP >tunneling (subsequently, IPv6-over-IPv4), which always set DF bit in the >IPv4 header. RFC2893 is rather clear about DF bit handling - it must not be set for tunnel with non-dynamic MTU. so i would consider the above example as "buggy". itojun From owner-v6ops@ops.ietf.org Sun May 4 04:51: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 EAA27499 for ; Sun, 4 May 2003 04:51:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CFBt-000Jfh-00 for v6ops-data@psg.com; Sun, 04 May 2003 08:49:49 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19CFBp-000JbZ-00 for v6ops@ops.ietf.org; Sun, 04 May 2003 08:49:45 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CFBo-0001N5-00; Sun, 04 May 2003 09:49:44 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CFBo-0001Ms-00; Sun, 04 May 2003 09:49:44 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA173452; Sun, 4 May 2003 09:49:41 +0100 Message-ID: <3EB4C542.1B087185@hursley.ibm.com> Date: Sun, 04 May 2003 09:46:10 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations , Fred Baker Subject: Re: I-D ACTION:draft-baker-ipv6-renumber-procedure-00.txt References: <200304141218.IAA01857@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.1 required=5.0 tests=BAYES_01,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, A couple of general comments. 1. It might be worth incorporating the relevant recommendations from RFC 1900, by value or by reference. 2. Along those lines, I think you need to say more about finding and fixing the places where IP addresses are embedded in configuration files, network management systems, and specifically in QOS and security systems (e.g. diffserv filters or firewall rules). This will be the hard part. Brian From owner-v6ops@ops.ietf.org Sun May 4 04:51: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 EAA27498 for ; Sun, 4 May 2003 04:51:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CFC1-000Jgc-00 for v6ops-data@psg.com; Sun, 04 May 2003 08:49:57 +0000 Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by psg.com with esmtp (Exim 3.36 #1) id 19CFBz-000JgO-00 for v6ops@ops.ietf.org; Sun, 04 May 2003 08:49:55 +0000 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CFBz-0001Ol-00 for v6ops@ops.ietf.org; Sun, 04 May 2003 09:49:55 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19CFBz-0001Og-00 for v6ops@ops.ietf.org; Sun, 04 May 2003 09:49:55 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA102658 for ; Sun, 4 May 2003 09:49:53 +0100 Message-ID: <3EB4CE83.8AF3E192@hursley.ibm.com> Date: Sun, 04 May 2003 10:25:39 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt References: <200301091422.JAA10679@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_10,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm wondering what we should do with this draft. It seems to me to be basically correct (i.e. it says that there are specific spoofing and DoS attacks using 6to4 that are harder to trace than "standard" spoofing and DoS attacks). It is more explicit about the checks to be applied than the base 6to4 specification, but those checks cannot eliminate the attacks. The document might also assist intrusion-detection implementors in detecting these attacks. So I think it should probably be published as an Info RFC, and if/when we revise the basic 6to4 spec, Pekka's document would be a source for improving the security section. Brian From owner-v6ops@ops.ietf.org Sun May 4 08:28: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 IAA28935 for ; Sun, 4 May 2003 08:27:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CIbD-000Iqe-00 for v6ops-data@psg.com; Sun, 04 May 2003 12:28:11 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19CIbB-000IqL-00 for v6ops@ops.ietf.org; Sun, 04 May 2003 12:28:09 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C015143BD; Sun, 4 May 2003 08:28:08 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 4 May 2003 08:28:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt Date: Sun, 4 May 2003 08:28:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032411E3@tayexc13.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt Thread-Index: AcMSG814FMVfgV/PQZuxeyCsuhLOfAAHAKbw From: "Bound, Jim" To: "Brian E Carpenter" , "IPv6 Operations" X-OriginalArrivalTime: 04 May 2003 12:28:08.0736 (UTC) FILETIME=[9EC00A00:01C31238] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA28935 Any tunnel creates embedded verification needs unless all parameters are secure to build it or there are checks to do decap at non-secure points in the path. This is not indicative of 6-to-4, but of tunnels. But it can be done. I think it should go to Info RFC too. That being said 6-to-4 is very close and ready for production wide IPv6 deployment and my recommendation to the public. It is the only transition mechanism in this condition mostly because it has been widely implemented. It appears ISATAP is close to being the same from what I can tell of implementations. But, I am still not clear because it is not as clear and straight forward as 6-to-4 for network operators. It requires more bake-off time. No comment on Teredo or DSTM at this point but both have initial implementations and some deployment in some geographies. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, May 04, 2003 4:26 AM > To: IPv6 Operations > Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt > > > I'm wondering what we should do with this draft. > > It seems to me to be basically correct (i.e. it says that > there are specific spoofing and DoS attacks using 6to4 that > are harder to trace than "standard" spoofing and DoS attacks). > > It is more explicit about the checks to be applied than the > base 6to4 specification, but those checks cannot eliminate > the attacks. > > The document might also assist intrusion-detection > implementors in detecting these attacks. > > So I think it should probably be published as an Info RFC, > and if/when we revise the basic 6to4 spec, Pekka's document > would be a source for improving the security section. > > Brian > > > From owner-v6ops@ops.ietf.org Sun May 4 08:44:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29040 for ; Sun, 4 May 2003 08:44:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CItj-000L9d-00 for v6ops-data@psg.com; Sun, 04 May 2003 12:47:19 +0000 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 19CIte-000L9E-00 for v6ops@ops.ietf.org; Sun, 04 May 2003 12:47:15 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 56078C1E9; Sun, 4 May 2003 08:47:08 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 4 May 2003 08:47:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt Date: Sun, 4 May 2003 08:47:07 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD657@tayexc13.americas.cpqcorp.net> Thread-Topic: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt Thread-Index: AcMSG814FMVfgV/PQZuxeyCsuhLOfAAHAKbwAADaxSA= From: "Bound, Jim" To: "Brian E Carpenter" , "IPv6 Operations" X-OriginalArrivalTime: 04 May 2003 12:47:08.0292 (UTC) FILETIME=[45FA7C40:01C3123B] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29040 Just in case when I say deployment I am talking test beds. /jim > -----Original Message----- > From: Bound, Jim > Sent: Sunday, May 04, 2003 8:28 AM > To: Brian E Carpenter; IPv6 Operations > Subject: RE: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt > > > Any tunnel creates embedded verification needs unless all > parameters are secure to build it or there are checks to do > decap at non-secure points in the path. This is not > indicative of 6-to-4, but of tunnels. But it can be done. I > think it should go to Info RFC too. > > That being said 6-to-4 is very close and ready for production > wide IPv6 deployment and my recommendation to the public. It > is the only transition mechanism in this condition mostly > because it has been widely implemented. > > It appears ISATAP is close to being the same from what I can > tell of implementations. But, I am still not clear because it > is not as clear and straight forward as 6-to-4 for network > operators. It requires more bake-off time. > > No comment on Teredo or DSTM at this point but both have > initial implementations and some deployment in some geographies. > > /jim > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Sunday, May 04, 2003 4:26 AM > > To: IPv6 Operations > > Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt > > > > > > I'm wondering what we should do with this draft. > > > > It seems to me to be basically correct (i.e. it says that there are > > specific spoofing and DoS attacks using 6to4 that are > harder to trace > > than "standard" spoofing and DoS attacks). > > > > It is more explicit about the checks to be applied than the > > base 6to4 specification, but those checks cannot eliminate > > the attacks. > > > > The document might also assist intrusion-detection > > implementors in detecting these attacks. > > > > So I think it should probably be published as an Info RFC, > > and if/when we revise the basic 6to4 spec, Pekka's document > > would be a source for improving the security section. > > > > Brian > > > > > > > > From owner-v6ops@ops.ietf.org Mon May 5 02:00:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14359 for ; Mon, 5 May 2003 02:00:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CZ1N-000NCD-00 for v6ops-data@psg.com; Mon, 05 May 2003 06:00:17 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19CZ1K-000NBs-00 for v6ops@ops.ietf.org; Mon, 05 May 2003 06:00:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4560BE23656; Mon, 5 May 2003 09:00:11 +0300 Date: Mon, 5 May 2003 09:00:10 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: IPv6 Operations Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt In-Reply-To: <3EB4CE83.8AF3E192@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'm a bit biased to answer this, but.. On Sun, 4 May 2003, Brian E Carpenter wrote: > I'm wondering what we should do with this draft. I've been wondering about the same too, due to lack of feedback since the last revision from the WG. I must assume it's perfect ;-) > It seems to me to be basically correct (i.e. it says that > there are specific spoofing and DoS attacks using 6to4 that > are harder to trace than "standard" spoofing and DoS attacks). > > It is more explicit about the checks to be applied than the base > 6to4 specification, but those checks cannot eliminate the attacks. True enough, they should make it easier to implement 6to4 properly. This is also possibly something that could form a basis on what to ask from the security side if we progress 6to4 to Draft Standard one day. > The document might also assist intrusion-detection implementors > in detecting these attacks. > > So I think it should probably be published as an Info RFC, and > if/when we revise the basic 6to4 spec, Pekka's document would > be a source for improving the security section. Pretty much agree, informational seems to be the best way here. If we need to fork off separate efforts to modify 6to4 spec or augment that, it should be in separate, short documents referencing this. In short, it seems to me that we can't find a proper solution that would satisfy everyone at the moment (and we may not even need one really badly), so it might make more sense to just push the documentation of the issues out and leave specific solutions for later. Easier to get consensus on this than a specific solution, I think. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon May 5 12:48: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 MAA07488 for ; Mon, 5 May 2003 12:48:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Cj8e-0008Vi-00 for v6ops-data@psg.com; Mon, 05 May 2003 16:48:28 +0000 Received: from web41803.mail.yahoo.com ([66.218.93.137]) by psg.com with smtp (Exim 3.36 #1) id 19Cj8Z-0008V8-00 for v6ops@ops.ietf.org; Mon, 05 May 2003 16:48:23 +0000 Message-ID: <20030505164822.22189.qmail@web41803.mail.yahoo.com> Received: from [65.213.193.49] by web41803.mail.yahoo.com via HTTP; Mon, 05 May 2003 09:48:22 PDT Date: Mon, 5 May 2003 09:48:22 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Participation To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1054250390-1052153302=:21884" X-Spam-Status: No, hits=-0.6 required=5.0 tests=BAYES_30,HTML_10_20 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1054250390-1052153302=:21884 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 http://www.caitr.org/internetworking03/index.htm You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.Important Dates: --------------------- - Early Registration Rates Cut-Off Date: Sept 30 - Tutorials: Oct 27, 1:00-6:00 pm - Conference sessions: October 28-29 8:30am-6:00pmProgram: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - A new routing architecture: Atomised Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - Mobile Handoff Technologies Tuesday June 24 Session: Inter-Domain Routing - Optimizing Route Convergence - Traceroute and BGP AS Path Incongruities - Domain Constrained Multicast: A New Approach for IP Multicast Routing Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: QoS Based Routing - QoS Routing in Networks with Non-Deterministic Information - Active Dynamic Routing - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks - Fluid flow network modeling for hop-by-hop feedback control design and analysis We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-1054250390-1052153302=:21884 Content-Type: text/html; charset=us-ascii
     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
    http://www.caitr.org/internetworking03/index.htm
  
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.
Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.
Important Dates:
---------------------
- Early Registration Rates Cut-Off Date: Sept 30
- Tutorials: Oct 27, 1:00-6:00 pm
- Conference sessions: October 28-29 8:30am-6:00pm
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
Sunday June 22
    Tutorial-1: MPLS VPNs 
    Tutorial-2: IPv6 
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet 
Monday June 23
    Welcome and Keynote 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing
      - Network Processing Building Blocks: Enabling the Routers of the Future
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - A new routing architecture: Atomised Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS 
      - Mobile Authentication and QoS 
      - Mobile Handoff Technologies 
Tuesday June 24
    Session: Inter-Domain Routing
      - Optimizing Route Convergence
      - Traceroute and BGP AS Path Incongruities 
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
 
    Session: Applications & Services
     -  Securing the Web with Next Generation Encryption Technologies
     - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21
     - A novel EAC semantic for the RTSP protocol
     - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session: Network Management & Planning
     -  Pseudowire OAM: A Mandatory Yet Often Overlooked Feature 
     - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems
     - Design Of Fast Fault Restoration System For WDM Networks
     - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session: QoS Based Routing
     - QoS Routing in Networks with Non-Deterministic Information
     - Active Dynamic Routing
     - QoS routing for Differentiated Services: simulations and prototype experiments
     - Probabilistic routing for QoS improvement in GPS networks
     - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
We look forward to seeing you at the Conference.
Regards,
 Conference Technical Co-chairs:
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM

 
--0-1054250390-1052153302=:21884-- From owner-v6ops@ops.ietf.org Mon May 5 15:31:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13527 for ; Mon, 5 May 2003 15:31:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CliG-000ElR-00 for v6ops-data@psg.com; Mon, 05 May 2003 19:33:24 +0000 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 19CliA-000Eky-00 for v6ops@ops.ietf.org; Mon, 05 May 2003 19:33:18 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA21740; Mon, 5 May 2003 12:32:25 -0700 (PDT) Message-Id: <5.1.0.14.2.20030505152648.0458fa48@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 May 2003 15:27:25 -0400 To: Pekka Savola From: Margaret Wasserman Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt Cc: Brian E Carpenter , IPv6 Operations In-Reply-To: References: <3EB4CE83.8AF3E192@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-32.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka, Do you think that this document is ready for WG last call for informational, then? Margaret At 09:00 AM 5/5/2003 +0300, Pekka Savola wrote: >I'm a bit biased to answer this, but.. > >On Sun, 4 May 2003, Brian E Carpenter wrote: > > I'm wondering what we should do with this draft. > >I've been wondering about the same too, due to lack of feedback since the >last revision from the WG. I must assume it's perfect ;-) > > > It seems to me to be basically correct (i.e. it says that > > there are specific spoofing and DoS attacks using 6to4 that > > are harder to trace than "standard" spoofing and DoS attacks). > > > > It is more explicit about the checks to be applied than the base > > 6to4 specification, but those checks cannot eliminate the attacks. > >True enough, they should make it easier to implement 6to4 properly. This >is also possibly something that could form a basis on what to ask from the >security side if we progress 6to4 to Draft Standard one day. > > > The document might also assist intrusion-detection implementors > > in detecting these attacks. > > > > So I think it should probably be published as an Info RFC, and > > if/when we revise the basic 6to4 spec, Pekka's document would > > be a source for improving the security section. > >Pretty much agree, informational seems to be the best way here. > >If we need to fork off separate efforts to modify 6to4 spec or augment >that, it should be in separate, short documents referencing this. > >In short, it seems to me that we can't find a proper solution that would >satisfy everyone at the moment (and we may not even need one really >badly), so it might make more sense to just push the documentation of the >issues out and leave specific solutions for later. > >Easier to get consensus on this than a specific solution, I think. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon May 5 16:08: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 QAA14259 for ; Mon, 5 May 2003 16:08:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CmI5-000MMY-00 for v6ops-data@psg.com; Mon, 05 May 2003 20:10:25 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19CmI2-000MM9-00 for v6ops@ops.ietf.org; Mon, 05 May 2003 20:10:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h45KADm30099; Mon, 5 May 2003 23:10:14 +0300 Date: Mon, 5 May 2003 23:10:13 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Brian E Carpenter , IPv6 Operations Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt In-Reply-To: <5.1.0.14.2.20030505152648.0458fa48@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-30.9 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 5 May 2003, Margaret Wasserman wrote: > Do you think that this document is ready for WG last call for > informational, then? I think it's pretty much ready. (There are two TBD's, but those can be filled in/removed later, and are not crucial; I also need to make a few minor ID-nits -type corrections, but those can be done later.) ... As for the other perspective into this.. One potential problem may be that it isn't formally a WG document (at least yet). The question was asked in a session a couple of IETF's back, but there was pushback then (IIRC -- I think it was because there was belief that we couldn't really secure 6to4 -- and the focus has now been on documenting the issues rather than making it bulletproof), but then again, the document has also evolved since then. Looking at RFC2418, there seems to be no strict guideline for something like this. It seems that any document the WG is working on and touches its area of expertise could be last-called and even sent to the IESG -- no need to have it formally approved. But the practice seems to be different. So, the options would seem like: 1) get WG feedback whether it could be accepted as a WG document, 2) announce a WG last-call, and/or 3) send it to the IESG (after possible modifications). in any possible order (e.g. I could send it to the IESG as an individual submission, and in turn, it would likely be pushed here for Expert review, for which a last-call -like process would be necessary) -- but 1-2-3 or 1+2 concurrently and then 3 would seem the most natural approach to me. Seems a bit confusing, but maybe something like 1+2 would seem appropriate. Getting some action kickstarted before the next IETF, at least, would be excellent and might reduce the WG load then. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon May 5 20:13:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22293 for ; Mon, 5 May 2003 20:12:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Cq62-000KaG-00 for v6ops-data@psg.com; Tue, 06 May 2003 00:14:14 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19Cq60-000Ka1-00 for v6ops@ops.ietf.org; Tue, 06 May 2003 00:14:12 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA16069; Mon, 5 May 2003 17:14:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h460E8u06206; Mon, 5 May 2003 17:14:08 -0700 X-mProtect: <200305060014> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbnQhoS; Mon, 05 May 2003 17:14:07 PDT Message-ID: <3EB6FF41.3030308@iprg.nokia.com> Date: Mon, 05 May 2003 17:18:09 -0700 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: itojun@iijlab.net CC: Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: <20030501231745.2545A93@coconut.itojun.org> <3EB1AD1F.4080601@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Were there any technical objections to setting a larger non-dynamic tunnel MTU of 1380? Fred ftemplin@iprg.nokia.com Fred L. Templin wrote: > itojun@iijlab.net wrote: >> correct. if you want efficiency, dynamic MTU case in mech-v2 >> should give you the efficiency. leave non-dynamic as is (1280). > > Can you state your technical objections to setting a larger non-dynamic > value of 1380? > > Fred > ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Mon May 5 20:54:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23018 for ; Mon, 5 May 2003 20:54:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19CqlY-000MsZ-00 for v6ops-data@psg.com; Tue, 06 May 2003 00:57:08 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19CqlN-000Ms6-00 for v6ops@ops.ietf.org; Tue, 06 May 2003 00:56:58 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id CC8BD92; Tue, 6 May 2003 09:56:53 +0900 (JST) To: "Fred L. Templin" Cc: Erik Nordmark , v6ops@ops.ietf.org In-reply-to: ftemplin's message of Mon, 05 May 2003 17:18:09 MST. <3EB6FF41.3030308@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt From: itojun@iijlab.net Date: Tue, 06 May 2003 09:56:53 +0900 Message-Id: <20030506005653.CC8BD92@coconut.itojun.org> X-Spam-Status: No, hits=-12.0 required=5.0 tests=BAYES_01,IN_REP_TO,NO_REAL_NAME,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>> correct. if you want efficiency, dynamic MTU case in mech-v2 >>> should give you the efficiency. leave non-dynamic as is (1280). >> Can you state your technical objections to setting a larger non-dynamic >> value of 1380? >Were there any technical objections to setting a larger non-dynamic >tunnel MTU of 1380? keep it to 1280. MTU of 1280 is the minimum MTU value any IPv6 link has to support, therefore even minimal router implementation has to support it. if you want to get more efficiency, use dynamic tunnel MTU discovery. keep the simple one "simple" (= 1280). don't try to make simple mechanism more complex when there's more efficient variant (dynamic tunnel MTU) exists. and, i don't think you have convinced me on the technical benefits of 1380 (the particular value). itojun From owner-v6ops@ops.ietf.org Tue May 6 13:32: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 NAA00583 for ; Tue, 6 May 2003 13:32:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D6IW-000KQ0-00 for v6ops-data@psg.com; Tue, 06 May 2003 17:32:12 +0000 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 19D6IS-000KPg-00 for v6ops@ops.ietf.org; Tue, 06 May 2003 17:32:08 +0000 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 839A484EE; Tue, 6 May 2003 13:32:07 -0400 (EDT) Received: from whitestar.zk3.dec.com (whitestar.zk3.dec.com [16.140.64.49]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 18448143F; Tue, 6 May 2003 12:32:06 -0500 (CDT) Received: from hp.com by whitestar.zk3.dec.com (8.12.6/1.1.29.3/18Jul02-1258PM) id h46HW1rm001960; Tue, 6 May 2003 13:32:02 -0400 (EDT) Message-ID: <3EB7F191.3050304@hp.com> Date: Tue, 06 May 2003 13:32:01 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.3b) Gecko/20030318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fred L. Templin" Cc: itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: <20030501231745.2545A93@coconut.itojun.org> <3EB1AD1F.4080601@iprg.nokia.com> <3EB6FF41.3030308@iprg.nokia.com> In-Reply-To: <3EB6FF41.3030308@iprg.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010703070603010508090801" X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms010703070603010508090801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Fred Fred L. Templin wrote: > Were there any technical objections to setting a larger non-dynamic > tunnel MTU of 1380? If you start mandating a default static MTU of 1380 on a configured tunnel, then you may very likely have interoperability problmes with implementations of rfc 2893 that only support static MTU of 1280. Since v6ops-mech-v2-00 draft is updating RFC 2893, lets try to keep it backwards compatible. Neither drafts absolutely require PMTU Discovery and thus having different default MTUs may cause problems and will require reconfiguration. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 --------------ms010703070603010508090801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIISDCC BCAwggOJoAMCAQICEA+U9DHKkQsNror0sgqRSDMwDQYJKoZIhvcNAQEEBQAwgZ4xDzANBgNV BAoTBmhwLmNvbTEaMBgGA1UECxMRSVQgSW5mcmFzdHJ1Y3R1cmUxCzAJBgNVBAYTAlVTMSAw HgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTFAMD4GA1UEAxM3SGV3bGV0dC1QYWNr YXJkIFByaW1hcnkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMjA4MDgw MDAwMDBaFw0wMzA4MDgyMzU5NTlaMIGZMRgwFgYDVQQKFA9IZXdsZXR0LVBhY2thcmQxDjAM BgNVBAsUBUhQIElUMSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVtcGxveWVlczEb MBkGA1UEAxMSVmxhZGlzbGF2IFlhc2V2aWNoMSgwJgYJKoZIhvcNAQkBFhl2bGFkaXNsYXYu eWFzZXZpY2hAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzHlO8KO+ R6jaEmngSK2ilWaxfyQ8ik7qEyISMkYyFpl2NmZH77XLWLoXdDXd6RD8obNCK7/mf9hhOPNp 6SX26bEOMcjXxz0sTIAlyBWmDJEWMa+iwdx5L8VaHxmMu6Nsy/p19WGUh2F0UaQya2X/Y7Mc /T3OzrnkzoC4gLc+tBr/5v/S5H5F9SKDD3K9+mGQQrHSRbxhFWeG8tG6YMSZrsxEm2Mo/uOH qb+/yklnlQbqxmCmsswqlUoXkyaH/utbsUTEfE0ZnFpvZyGqBBJEao66mTeGUfUYPhy/zTHl VqqnhLGhJgc+vznJGzqnqsExqqHUUkYirGoGPiyuSF9VSQIDAQABo4HdMIHaMEMGA1UdEQQ8 MDqBGVZsYWRpc2xhdi5ZYXNldmljaEBocC5jb22BHVZsYWRpc2xhdi5ZYXNldmljaEBjb21w YXEuY29tMAkGA1UdEwQCMAAwYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL29uc2l0ZWNybC52 ZXJpc2lnbi5jb20vSGV3bGV0dFBhY2thcmRDb21wYW55SVRJbmZyYXN0cnVjdHVyZS9MYXRl c3RDUkwuY3JsMBEGCWCGSAGG+EIBAQQEAwIHgDARBgpghkgBhvhFAQYJBAMBAf8wDQYJKoZI hvcNAQEEBQADgYEAdlbR6o5tWkaLOUSG3/Luw+0jKU5w23eikjR8eSrMv2FnMXUQB3o8yFG+ NBEgSGDSJ0G9LXAn5gN5c4/T56ZM0WslR/KYGQGbmFlHgcpcFQo7kWlQa+CDt0ibAX8X93pN H7IVjCY8xD47NaB8qIqpnj5j+iTUaeQeyOD3TL6++WIwggQgMIIDiaADAgECAhAPlPQxypEL Da6K9LIKkUgzMA0GCSqGSIb3DQEBBAUAMIGeMQ8wDQYDVQQKEwZocC5jb20xGjAYBgNVBAsT EUlUIEluZnJhc3RydWN0dXJlMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNr YXJkIENvbXBhbnkxQDA+BgNVBAMTN0hld2xldHQtUGFja2FyZCBQcmltYXJ5IENsYXNzIDIg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIwODA4MDAwMDAwWhcNMDMwODA4MjM1OTU5 WjCBmTEYMBYGA1UEChQPSGV3bGV0dC1QYWNrYXJkMQ4wDAYDVQQLFAVIUCBJVDEmMCQGA1UE CxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxGzAZBgNVBAMTElZsYWRpc2xhdiBZ YXNldmljaDEoMCYGCSqGSIb3DQEJARYZdmxhZGlzbGF2Lnlhc2V2aWNoQGhwLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMx5TvCjvkeo2hJp4EitopVmsX8kPIpO6hMi EjJGMhaZdjZmR++1y1i6F3Q13ekQ/KGzQiu/5n/YYTjzaekl9umxDjHI18c9LEyAJcgVpgyR FjGvosHceS/FWh8ZjLujbMv6dfVhlIdhdFGkMmtl/2OzHP09zs655M6AuIC3PrQa/+b/0uR+ RfUigw9yvfphkEKx0kW8YRVnhvLRumDEma7MRJtjKP7jh6m/v8pJZ5UG6sZgprLMKpVKF5Mm h/7rW7FExHxNGZxab2chqgQSRGqOupk3hlH1GD4cv80x5Vaqp4SxoSYHPr85yRs6p6rBMaqh 1FJGIqxqBj4srkhfVUkCAwEAAaOB3TCB2jBDBgNVHREEPDA6gRlWbGFkaXNsYXYuWWFzZXZp Y2hAaHAuY29tgR1WbGFkaXNsYXYuWWFzZXZpY2hAY29tcGFxLmNvbTAJBgNVHRMEAjAAMGIG A1UdHwRbMFkwV6BVoFOGUWh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQ YWNrYXJkQ29tcGFueUlUSW5mcmFzdHJ1Y3R1cmUvTGF0ZXN0Q1JMLmNybDARBglghkgBhvhC AQEEBAMCB4AwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEBBAUAA4GBAHZW0eqObVpG izlEht/y7sPtIylOcNt3opI0fHkqzL9hZzF1EAd6PMhRvjQRIEhg0idBvS1wJ+YDeXOP0+em TNFrJUfymBkBm5hZR4HKXBUKO5FpUGvgg7dImwF/F/d6TR+yFYwmPMQ+OzWgfKiKqZ4+Y/ok 1GnkHsjg90y+vvliMYIEIDCCBBwCAQEwgbMwgZ4xDzANBgNVBAoTBmhwLmNvbTEaMBgGA1UE CxMRSVQgSW5mcmFzdHJ1Y3R1cmUxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTFAMD4GA1UEAxM3SGV3bGV0dC1QYWNrYXJkIFByaW1hcnkgQ2xhc3Mg MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQD5T0McqRCw2uivSyCpFIMzAJBgUrDgMCGgUA oIICQTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MDYx NzMyMDFaMCMGCSqGSIb3DQEJBDEWBBQFQZns9Jz0/J0nke9o2nrOFq6s6jBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBxAYJKwYBBAGCNxAEMYG2MIGzMIGeMQ8wDQYDVQQKEwZo cC5jb20xGjAYBgNVBAsTEUlUIEluZnJhc3RydWN0dXJlMQswCQYDVQQGEwJVUzEgMB4GA1UE ChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxQDA+BgNVBAMTN0hld2xldHQtUGFja2FyZCBQ cmltYXJ5IENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEA+U9DHKkQsNror0sgqR SDMwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQ8wDQYDVQQKEwZocC5jb20xGjAYBgNVBAsT EUlUIEluZnJhc3RydWN0dXJlMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNr YXJkIENvbXBhbnkxQDA+BgNVBAMTN0hld2xldHQtUGFja2FyZCBQcmltYXJ5IENsYXNzIDIg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEA+U9DHKkQsNror0sgqRSDMwDQYJKoZIhvcNAQEB BQAEggEAxSRTyOGcbrnFb/DApjZdnsb4+urR9gU6FA4FCXy23ZvVKyysZ/JFnypN1/u/9MJe l48iFUBpgGhdtdZEWnvH2bDSobTkGj9Y+o3Umki1uEFC6mPLMH4DxVuUCT/R75TC0g8cZZ22 F6UchAr3ISM7NS8osM8eKFXQg005GGEfTVJov2LKwZe+yAGOysjDUg0YV5n9mvj9CcJ4z42b DOSKbSLamSHPZ+aBsIs+FMAjCV/EbEMCoMHMhfUSLcoz0BOew0D2GkpJZnOb1Ve5/czT7Kzi T/MsfKHm1h7Bf1/8bNVVbiilXx9A1iujOGvHPrv55bwAcosAeyw22hl6rYziIQAAAAAAAA== --------------ms010703070603010508090801-- From owner-v6ops@ops.ietf.org Tue May 6 16:24: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 QAA07115 for ; Tue, 6 May 2003 16:24:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19D90Q-000Pql-00 for v6ops-data@psg.com; Tue, 06 May 2003 20:25:42 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19D90N-000PqV-00 for v6ops@ops.ietf.org; Tue, 06 May 2003 20:25:39 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA07236; Tue, 6 May 2003 13:25:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h46KPZH25431; Tue, 6 May 2003 13:25:35 -0700 X-mProtect: <200305062025> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd21y4wd; Tue, 06 May 2003 13:25:33 PDT Message-ID: <3EB81B35.1070009@iprg.nokia.com> Date: Tue, 06 May 2003 13:29:41 -0700 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: Vladislav Yasevich CC: itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: <20030501231745.2545A93@coconut.itojun.org> <3EB1AD1F.4080601@iprg.nokia.com> <3EB6FF41.3030308@iprg.nokia.com> <3EB7F191.3050304@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Vlad, Vladislav Yasevich wrote: > Fred > > Fred L. Templin wrote: > >> Were there any technical objections to setting a larger non-dynamic >> tunnel MTU of 1380? > > > If you start mandating a default static MTU of 1380 on a configured Perhaps I havn't made myself clear on this point, but I'm not seeking to mandate a static MTU of 1380. What I am meaning to suggest is something along the lines that the static MTU assignment "MUST be no less than 1280 and SHOULD be no greater than 1380". > tunnel, then you may very likely have interoperability problmes > with implementations of rfc 2893 that only support static > MTU of 1280. On this point, it's not clear to me that RFC 2893 specifies a static MTU of 1280. If you read section 3.2 of that document carefully, you will see that 1280 is only mentioned within the context of using the IPv4 path MTU to determine the tunnel MTU. The only text in RFC 2893 that speaks to a static MTU assignment is in the next-to-last paragraph of section 3.2 where it says that a node may: "...avoid using the IPv4 Path MTU algorithm accross the tunnel and instead use the MTU of the link layer (under IPv4)...". (But, in many cases, such a choice would lead to excessive fragmentation). > Since v6ops-mech-v2-00 draft is updating RFC 2893, lets try to > keep it backwards compatible. Neither drafts absolutely require > PMTU Discovery and thus having different default MTUs may cause > problems and will require reconfiguration. As far as I can tell, it is OK for the MTU determination schemes implemented by the tunnel endpoints to be asymmetric. For example, if nodes A and B are the tunnel endpoints it could be the case that A uses a static MTU assignment while B implements the dynamic mechanism. The fact that A and B might be using different default MTUs does not seem to me have any implications for interoperability. Regards, Fred ftemplin@iprg.nokia.com > -vlad > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tru64 UNIX Network Group > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 > From owner-v6ops@ops.ietf.org Tue May 6 17:29: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 RAA09783 for ; Tue, 6 May 2003 17:29:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DA1l-000D7o-00 for v6ops-data@psg.com; Tue, 06 May 2003 21:31:09 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19DA1i-000D7L-00 for v6ops@ops.ietf.org; Tue, 06 May 2003 21:31:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h46LUZg08687; Wed, 7 May 2003 00:30:35 +0300 Date: Wed, 7 May 2003 00:30:34 +0300 (EEST) From: Pekka Savola To: "Fred L. Templin" cc: Vladislav Yasevich , , Erik Nordmark , Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt In-Reply-To: <3EB81B35.1070009@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 6 May 2003, Fred L. Templin wrote: > Vladislav Yasevich wrote: > > Fred > > > > Fred L. Templin wrote: > > > >> Were there any technical objections to setting a larger non-dynamic > >> tunnel MTU of 1380? > > > > > > If you start mandating a default static MTU of 1380 on a configured > > Perhaps I havn't made myself clear on this point, but I'm not > seeking to mandate a static MTU of 1380. What I am meaning to > suggest is something along the lines that the static MTU assignment > "MUST be no less than 1280 and SHOULD be no greater than 1380". I think we were discussing the default value. For default values, "something between 1280 and 1380" might not be sensible. On the other hand, if this is not a default value, I certainly don't want anyone specifying how big MTU's I *SHOULD* use. I may be missing something though. -- 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 May 6 17:52: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 RAA10304 for ; Tue, 6 May 2003 17:52:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DAOS-000ISK-00 for v6ops-data@psg.com; Tue, 06 May 2003 21:54:36 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19DAOO-000IQL-00 for v6ops@ops.ietf.org; Tue, 06 May 2003 21:54:32 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11569; Tue, 6 May 2003 14:54:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h46LsSv17123; Tue, 6 May 2003 14:54:28 -0700 X-mProtect: <200305062154> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYe3rzV; Tue, 06 May 2003 14:54:27 PDT Message-ID: <3EB8300B.5060409@iprg.nokia.com> Date: Tue, 06 May 2003 14:58:35 -0700 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: Pekka Savola CC: Vladislav Yasevich , itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Tue, 6 May 2003, Fred L. Templin wrote: > >>Vladislav Yasevich wrote: >> >>>Fred >>> >>>Fred L. Templin wrote: >>> >>> >>>>Were there any technical objections to setting a larger non-dynamic >>>>tunnel MTU of 1380? >>> >>> >>>If you start mandating a default static MTU of 1380 on a configured >> >>Perhaps I havn't made myself clear on this point, but I'm not >>seeking to mandate a static MTU of 1380. What I am meaning to >>suggest is something along the lines that the static MTU assignment >>"MUST be no less than 1280 and SHOULD be no greater than 1380". > > > I think we were discussing the default value. Yes; can also be thought of as the default static or default stateless value. > For default values, > "something between 1280 and 1380" might not be sensible. OK - then let's continue to discuss about 1380 and not dive into the "something between" rathole. (I am meaning to answer Itojun back on his question about the 1380.) > On the other > hand, if this is not a default value, I certainly don't want anyone > specifying how big MTU's I *SHOULD* use. No - larger MTUs are certainly permissible in some circumstances. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue May 6 18:58: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 SAA13310 for ; Tue, 6 May 2003 18:58:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DBPg-0007Sv-00 for v6ops-data@psg.com; Tue, 06 May 2003 22:59:56 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19DBPd-0007Se-00 for v6ops@ops.ietf.org; Tue, 06 May 2003 22:59:53 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA14425; Tue, 6 May 2003 15:59:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h46Mxpi30764; Tue, 6 May 2003 15:59:51 -0700 X-mProtect: <200305062259> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdusiOTd; Tue, 06 May 2003 15:59:50 PDT Message-ID: <3EB83F5D.8040401@iprg.nokia.com> Date: Tue, 06 May 2003 16:03:57 -0700 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: itojun@iijlab.net CC: Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: <20030506005653.CC8BD92@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-35.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, itojun@iijlab.net wrote: > and, i don't think you have convinced me on the technical benefits > of 1380 (the particular value). The Internet cell size is pretty much 1500 bytes these days, so an IPv6/IPv4 tunnel MTU of 1500 - 20 = 1480 might seem like a natural choice. However, link layer encapsulations below the IPv6/IPv4 tunnel may occur, e.g., when the tunnel is carried over a VPN interface. Microsoft, cisco and others use 1400 bytes as the default MTU for VPN interfaces in order to allow enough room for link layer encapsulations (e.g., IPsec, L2TP, PPPoE, etc.) without exceeding the 1500 byte budget and incurring fragmentation. So, the default IPv6/IPv4 tunnel MTU should be set to at most 1400 - 20 = 1380. There are two reasons to set the default MTU as large as 1380 bytes: 1) 1380 provides a 7.8% efficiency gain over 1280. 2) 1380 allows 100 bytes for an additional layer of IPv6 encapsulation above the IPv6/IPv4 tunnel. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed May 7 03:00: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 DAA18594 for ; Wed, 7 May 2003 03:00:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19DIuw-0000sl-00 for v6ops-data@psg.com; Wed, 07 May 2003 07:00:42 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19DIus-0000sO-00 for v6ops@ops.ietf.org; Wed, 07 May 2003 07:00:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4770PK12095; Wed, 7 May 2003 10:00:27 +0300 Date: Wed, 7 May 2003 10:00:25 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: "Fred L. Templin" , Erik Nordmark , Subject: simple hosts/routers and MTU [Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt] In-Reply-To: <20030506005653.CC8BD92@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 6 May 2003 itojun@iijlab.net wrote: > and, i don't think you have convinced me on the technical benefits > of 1380 (the particular value). I'm trying to look at this from a different angle: what benefits would 1280 really have (except for simplicity etc.etc. vague things)? To me, it seems that the features possibly gained by pushing 1280 could be: - can hosts be implemented so that they do not implement fragmentation and reassembly? (no difference, it seems) - can hosts be implemented so that they don't need to participate actively in PMTUD? (no difference, it seems) - can hosts be implemented so that they don't need to care for received "packet too big" ICMP messages ("passive PMTUD")? (passive PMTUD would seem to be required if the host uses 1380 for sending) - can hosts be implemented so that they can have a lower MRU than 1500 bytes? (no difference, it seems) - ... As for routers, - can routers be implemented so that they do not need to implement IPv4 fragmentation and reassembly *for tunnel packets* (note: IPv6 frag + reass may be needed anyway, from "host part")? - can routers be implemented so that they can have a lower MRU than 1500 bytes? (can't implement that way, I think.) - ... Please try to come up with some concrete thoughts on this? (I'm not sure whether 1380 is the best choice anyway, but I'd like to get some harder data to back up some rather abstract reasons.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed May 14 07:34: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 HAA13133 for ; Wed, 14 May 2003 07:34:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FuVT-000HLu-00 for v6ops-data@psg.com; Wed, 14 May 2003 11:33:11 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19FuVQ-000HLU-00 for v6ops@ops.ietf.org; Wed, 14 May 2003 11:33:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4EBX6c29741 for ; Wed, 14 May 2003 14:33:06 +0300 Date: Wed, 14 May 2003 14:33:05 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3gpp-analysis document and automatic tunneling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-12.3 required=5.0 tests=BAYES_01,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I'd like to raise one issue in the 3gpp-analysis document which bothers me a lot. I'd like to either understand the reasoning for mentioning all the kinds of automatic tunneling mechanism in this draft, or remove the references. (the last paragraph of 2.2 quoted below, and some re-editing of the paragraphs in 3.2.1). In particular, I feel this is an issue about IGP/BGP tunneling. It is possible such methods could be used -- if the network is built just so -- but that's entirely different thing from whether they're a required or even a recommended solution ("we have a hammer, now let's go find the nails"). I fail to see anything 3GPP specific in the description of the network in 3.2.1 and consequently, I'd rather not go down the rathole of describing how an ISP would run its network in the 3GPP scenarios/analysis document. Rather, I'd try to work out generic ISP scenarios in the ISP documents to avoid duplicating the work. Therefore, I'd like to either understand why this is in scope and what's 3GPP specific about it, or try to reword the text appropriately (I can try to help if needed). ==== 2.2 Tunneling Tunneling is a transition mechanism that requires dual IPv4/IPv6 stack functionality in the encapsulating and decapsulating nodes. Basic tunneling alternatives are IPv6-in-IPv4 and IPv4-in-IPv6. IPv6-in-IPv4 tunneling mechanisms perform as virtual IPv6 links over IPv4, and they are implemented by virtual IPv6 interfaces that are configured over one or more physical IPv4 interfaces. Sending nodes encapsulate IPv6 packets in IPv4 packets when the IPv6 routing table determines that the next hop toward the IPv6 destination address is via a tunnel interface. Receiving nodes decapsulate IPv6 packets from IPv4 packets that arrive on tunnel interfaces. Tunneling can be static or dynamic. Static (configured) tunnels are fixed IPv6 links over IPv4. They require static configuration of the IPv6 source, IPv6 next-hop and IPv4 destination addresses for IPv6-in-IPv4 encapsulation. The IPv6 destination address is specified by the application and is used to determine the IPv6 next-hop address via longest-prefix-match in the IPv6 routing table. Configured tunnels are specified in [RFC2893]. Dynamic (automatic) tunnels enable stateless encapsulation of IPv6- in-IPv4. They are virtual IPv6 links over IPv4 where the tunnel endpoints are not configured, i.e. the links are created dynamically, and they only require static configuration of the IPv6 source address. Like in static tunneling, the IPv6 destination address is specified by the application and it is used to determine the IPv6 next-hop address via a longest-prefix-match lookup in the IPv6 routing table. But unlike static tunnels, the IPv4 destination address is not configured (fixed); it is derived from the IPv6 next-hop address in some way. For example, the IPv4 destination address can be embedded in the IPv6 next-hop address. Examples of dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP], [DSTM] and [TEREDO]. [...] 3.2.1 Tunneling inside the 3GPP Operator's Network Many GPRS operators already have IPv4 backbone networks deployed and they are gradually migrating them while introducing IPv6 islands. IPv6 backbones can be considered quite rare in the first phases of the transition. If the 3GPP operator already has IPv6 widely deployed in its network, this subsection is not so relevant. In initial, smaller scale IPv6 deployment, where a small number of IPv6 in IPv4 tunnels are required to connect the IPv6 islands over the 3GPP operator's IPv4 network, manually configured tunnels can be used. In a 3GPP network, one IPv6 island could contain the GGSN while another island contains the operator's IPv6 application servers. However, manually configured tunnels can be an administrative burden when the number of islands and therefore tunnels rises. It is also possible to use dynamic tunneling mechanisms such as "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms [BGP][IGP]. Routing protocol based mechanisms such as [BGP] consist of running BGP between the neighboring router tunnel endpoints and using multi-protocol BGP extensions to exchange reachability information of IPv6 prefixes. The routers use this information to create IPv6 in IPv4 tunnel interfaces and route IPv6 packets over the IPv4 network. It is possible to combine this with different types of tunnels. [...] The conclusion is that in most "internal" 3GPP scenarios it is preferred to use manually configured tunnels or EGP/IGP based tunneling mechanisms, if it is not feasible to enable IPv6 in the network infrastructure yet. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed May 14 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 JAA16564 for ; Wed, 14 May 2003 09:04:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fvxc-00064U-00 for v6ops-data@psg.com; Wed, 14 May 2003 13:06:20 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19FvxZ-000642-00 for v6ops@ops.ietf.org; Wed, 14 May 2003 13:06:18 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.14) id 19FvxY-0000Iw-R3 for v6ops@ops.ietf.org; Wed, 14 May 2003 15:06:16 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 May 2003 15:06:16 +0200 To: v6ops@ops.ietf.org Subject: Chair Changes in v6ops Message-Id: X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun hagino has asked to step down as co-chair of the v6ops wg in order for him to have time to pursue his new duties as a member of the iab. itojun, congratulations and sympathies on your new position, and thank you for your efforts in leading the wg. pekka savola has agreed to serve as co-chair of the v6ops effort, along with margaret wasserman and bob fink. thank you, pekka. randy From owner-v6ops@ops.ietf.org Wed May 14 10:28: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 KAA20007 for ; Wed, 14 May 2003 10:28:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19FxH1-000K49-00 for v6ops-data@psg.com; Wed, 14 May 2003 14:30:27 +0000 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 19FxGd-000K0j-00 for v6ops@ops.ietf.org; Wed, 14 May 2003 14:30:03 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.72.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA14447 for ; Wed, 14 May 2003 07:29:55 -0700 (PDT) Message-Id: <5.1.0.14.2.20030514101942.046e4f70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 May 2003 10:26:01 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Accept Unmanaged Analysis Document as WG Draft? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, In SF, we had consensus that the analysis document produced by the Unmanaged Team would serve as a good starting place for our work, and that we should accept it as a WG draft. The latest version of this document can be found at: http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unmaneval-01.txt Unless there are any objections from the mailing list, I'll ask the Unmanaged Team to publish the next version as a WG I-D. Thanks, Margaret From owner-v6ops@ops.ietf.org Wed May 14 11:18: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 LAA21301 for ; Wed, 14 May 2003 11:18:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Fy3X-000PXp-00 for v6ops-data@psg.com; Wed, 14 May 2003 15:20:35 +0000 Received: from [2001:610:508:3001:200:c5ff:fe0d:e597] (helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #1) id 19Fy3V-000PXb-00 for v6ops@ops.ietf.org; Wed, 14 May 2003 15:20:34 +0000 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6p2/8.11.6) id h4EFKPc20057; Wed, 14 May 2003 17:20:25 +0200 (CEST) Date: Wed, 14 May 2003 17:20:25 +0200 From: Ronald van der Pol To: Margaret Wasserman Cc: v6ops@ops.ietf.org Subject: Re: Accept Unmanaged Analysis Document as WG Draft? Message-ID: <20030514152025.GC3881@rvdp.org> References: <5.1.0.14.2.20030514101942.046e4f70@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.20030514101942.046e4f70@mail.windriver.com> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=-36.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, May 14, 2003 at 10:26:01 -0400, Margaret Wasserman wrote: > > Hi All, > > In SF, we had consensus that the analysis document > produced by the Unmanaged Team would serve as a good > starting place for our work, and that we should accept > it as a WG draft. > > The latest version of this document can be found at: > > http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unmaneval-01.txt The latest version is: http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt rvdp From owner-v6ops@ops.ietf.org Wed May 14 13:45: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 NAA28590 for ; Wed, 14 May 2003 13:45:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G0Ka-000OED-00 for v6ops-data@psg.com; Wed, 14 May 2003 17:46:20 +0000 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 19G0KX-000ODx-00 for v6ops@ops.ietf.org; Wed, 14 May 2003 17:46:17 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.72.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA18478; Wed, 14 May 2003 10:45:59 -0700 (PDT) Message-Id: <5.1.0.14.2.20030514133609.046d8588@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 May 2003 13:36:30 -0400 To: Ronald van der Pol From: Margaret Wasserman Subject: Re: Accept Unmanaged Analysis Document as WG Draft? Cc: v6ops@ops.ietf.org In-Reply-To: <20030514152025.GC3881@rvdp.org> References: <5.1.0.14.2.20030514101942.046e4f70@mail.windriver.com> <5.1.0.14.2.20030514101942.046e4f70@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 05:20 PM 5/14/2003 +0200, Ronald van der Pol wrote: >The latest version is: >http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt Oops! Sorry. Margaret From owner-v6ops@ops.ietf.org Wed May 14 18:50: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 SAA09326 for ; Wed, 14 May 2003 18:50:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G574-0001Bs-00 for v6ops-data@psg.com; Wed, 14 May 2003 22:52:42 +0000 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 19G570-0001Bg-00 for v6ops@ops.ietf.org; Wed, 14 May 2003 22:52:38 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA10842; Wed, 14 May 2003 15:52:29 -0700 (PDT) Message-Id: <5.1.0.14.2.20030514184503.04741eb0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 May 2003 18:48:35 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: NAT-PT Applicability Cc: Bob Fink , Pekka Savola Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, In SF, we discussed the need for an applicability statement for NAT-PT. There was consensus of the WG to produce this applicability statement, and many people said that they were willing to work on it. The chairs would like to spin up this effort before Vienna. Could people who are willing to spend time working on a NAT-PT applicability document please send mail to me, Pekka and Bob by next Wednesday (May 21st)? We'll then put together a design team to do this work. Thanks, Margaret From owner-v6ops@ops.ietf.org Wed May 14 20:05: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 UAA10695 for ; Wed, 14 May 2003 20:05:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19G6GS-000FYg-00 for v6ops-data@psg.com; Thu, 15 May 2003 00:06:28 +0000 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 19G6GM-000FYO-00 for v6ops@ops.ietf.org; Thu, 15 May 2003 00:06:22 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA01935; Wed, 14 May 2003 17:05:54 -0700 (PDT) Message-Id: <5.1.0.14.2.20030514195139.046cbe50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 May 2003 19:56:11 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt Cc: "Fred L. Templin" , v6ops@ops.ietf.org, Erik Nordmark In-Reply-To: References: <"Your message with ID" <3E6D28F6.10003@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, Erik's message (below) and the current Transition Mechanisms draft match the agreement of the WG, as of the last time this issue was discussed. The chairs have discussed this issue, and we don't believe that the recent discussion on this topic has demonstrated a consensus to change the previous decision. So, we don't think that there is a need to modify what the document currently says about MTU values or Path MTU discovery. If anyone believes that there is a blocking technical issue with the current document wording, please let us know. Otherwise, the document should remain as-is. Thanks, Margaret At 09:24 AM 3/11/2003 +0100, Erik Nordmark wrote: > > I notice that in the latest draft version, you are no longer requiring an > > MRU of 4420 bytes in decapsulators and seem to be taking a less > > aggressive approach in the dynamic MTU discovery in the encapsulator. > > Can you say more as to the reasons for the change? > >This change (the non-need for the 4420 limit) was presented in >Atlanta even though it was not in the previous version of the draft. > >The basic results (which I think were on the slides, or perhaps only >in the discussion in Atlanta) is that the decapsulator needs to >support reassembly of up to the max (of its interface MTUs) and 1280+20. >(There is a note in the spec about it really being its neighbors MTU >that matter when the MTU != MRU). > >Then the encapsulator can choose between the static approach of >a fixed tunnel MTU of 1280 and DF not set in the IPv4 header, or a dynamic >tunnel MTU detection using IPv4 path MTU discovery. The latter will never >result in IPv4 packets at the decapsulator larger than the max of the >decapsualtor's interface MTUs. > >Finally the spec allows for manual configuration to override the 1280 number >in the static/fixed MTU case, but only if the receiver can handle reassembly >of the larger IPv4 packets. Thus it requires manual coordination between >the encapsulator and decapsulator to do this manual override. > > Erik From owner-v6ops@ops.ietf.org Thu May 15 08:44: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 IAA07204 for ; Thu, 15 May 2003 08:44:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GI57-000Nr4-00 for v6ops-data@psg.com; Thu, 15 May 2003 12:43:33 +0000 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #1) id 19GI54-000Nqq-00 for v6ops@ops.ietf.org; Thu, 15 May 2003 12:43:30 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4FChS724178 for ; Thu, 15 May 2003 15:43:28 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 15 May 2003 15:42:50 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 15 May 2003 15:42:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp-analysis document and automatic tunneling Date: Thu, 15 May 2003 15:42:47 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3910@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis document and automatic tunneling Thread-Index: AcMaDb+b/tJISpYCS5WeJHdYCZAhPgAzbYmQ From: To: , , Cc: X-OriginalArrivalTime: 15 May 2003 12:42:50.0212 (UTC) FILETIME=[7EB1DA40:01C31ADF] X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_10,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA07204 Hi, Pekka! Trying to briefly answer your questions considering the issue. -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 14 May, 2003 14:33 I'd like to raise one issue in the 3gpp-analysis document which bothers me a lot. I'd like to either understand the reasoning for mentioning all the kinds of automatic tunneling mechanism in this draft, or remove the references. (the last paragraph of 2.2 quoted below, and some re-editing of the paragraphs in 3.2.1). JW: What comes to the tunneling text in 2.2, I am fine with shortening it. There actually isn't anything 3GPP-specific, it is more like general tunneling description that is already described elsewhere (RFC 2893, etc...). As you see, the references to DSTM, ISATAP and TEREDO are informational references and thus not vital in this document. They are just mentioned as examples of tunneling mechanisms. Would making the tunneling text shorter (e.g. one paragraph) and removing the references to mechanisms (that are not used in this document) be a good thing to do in your opinion? In particular, I feel this is an issue about IGP/BGP tunneling. It is possible such methods could be used -- if the network is built just so -- but that's entirely different thing from whether they're a required or even a recommended solution ("we have a hammer, now let's go find the nails"). JW: Well, I don't think we can give unambiguous recommendations. It is much better to discuss different solution alternatives. Anyway, we can't require any solutions to be used by operators. We had some discussion with other authors (especially Karim) how to edit the text. One point that was brough up in the discussion was redundancy. Static tunnels on their own don't give a solution if a route goes down. Instead, EGP/IGP mechanisms support this. Say that I have multiple tunnels to two router endpoints connected to the same network. If one goes down I would like to start tunnelling to the other. Do you have any comments on this? I fail to see anything 3GPP specific in the description of the network in 3.2.1 and consequently, I'd rather not go down the rathole of describing how an ISP would run its network in the 3GPP scenarios/analysis document. Rather, I'd try to work out generic ISP scenarios in the ISP documents to avoid duplicating the work. JW: I fully agree with you that we should not do work that actually belongs to the ISP design team. What kind of text would you suggest in our document? Therefore, I'd like to either understand why this is in scope and what's 3GPP specific about it, or try to reword the text appropriately (I can try to help if needed). JW: Certainly, your help is appreciated! Thanks for your comments, -Juha W.- From owner-v6ops@ops.ietf.org Thu May 15 12:44: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 MAA14682 for ; Thu, 15 May 2003 12:44:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GLr2-000JYU-00 for v6ops-data@psg.com; Thu, 15 May 2003 16:45:16 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19GLqW-000JVT-00 for v6ops@ops.ietf.org; Thu, 15 May 2003 16:44:44 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA25737; Thu, 15 May 2003 09:44:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4FGigv24729; Thu, 15 May 2003 09:44:42 -0700 X-mProtect: <200305151644> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdytUMff; Thu, 15 May 2003 09:44:41 PDT Message-ID: <3EC3C522.2040403@iprg.nokia.com> Date: Thu, 15 May 2003 09:49:38 -0700 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: Margaret Wasserman CC: Erik Nordmark , v6ops@ops.ietf.org Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt References: <"Your message with ID" <3E6D28F6.10003@iprg.nokia.com> <5.1.0.14.2.20030514195139.046cbe50@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, The message from Erik you are quoting is out-dated. In his most recent message to the list, Erik said: At 02:33PM 04/26/2003 Erik Nordmark wrote: > I don't personally have a problem with raising the tunnel MTU in mech-v2 > from 1280 to 1380. > What do others in the WG think? We were in the middle of a discussion on this subject on the list, and I had addressed the technical points raised by itojun and Vlad Yasevich. I find it irregular and indeed unfair that the chairs would go off and make a private decision while the technical discussion was still taking place. In short, I object to this action by the chairs. Fred Templin ftemplin@iprg.nokia.com Margaret Wasserman wrote: > > Hi All, > > Erik's message (below) and the current Transition Mechanisms draft > match the agreement of the WG, as of the last time this issue was > discussed. > > The chairs have discussed this issue, and we don't believe that the > recent discussion on this topic has demonstrated a consensus to > change the previous decision. So, we don't think that there is a > need to modify what the document currently says about MTU values > or Path MTU discovery. > > If anyone believes that there is a blocking technical issue with > the current document wording, please let us know. Otherwise, the > document should remain as-is. > > Thanks, > Margaret > > > At 09:24 AM 3/11/2003 +0100, Erik Nordmark wrote: > >> > I notice that in the latest draft version, you are no longer >> requiring an >> > MRU of 4420 bytes in decapsulators and seem to be taking a less >> > aggressive approach in the dynamic MTU discovery in the encapsulator. >> > Can you say more as to the reasons for the change? >> >> This change (the non-need for the 4420 limit) was presented in >> Atlanta even though it was not in the previous version of the draft. >> >> The basic results (which I think were on the slides, or perhaps only >> in the discussion in Atlanta) is that the decapsulator needs to >> support reassembly of up to the max (of its interface MTUs) and 1280+20. >> (There is a note in the spec about it really being its neighbors MTU >> that matter when the MTU != MRU). >> >> Then the encapsulator can choose between the static approach of >> a fixed tunnel MTU of 1280 and DF not set in the IPv4 header, or a >> dynamic >> tunnel MTU detection using IPv4 path MTU discovery. The latter will never >> result in IPv4 packets at the decapsulator larger than the max of the >> decapsualtor's interface MTUs. >> >> Finally the spec allows for manual configuration to override the 1280 >> number >> in the static/fixed MTU case, but only if the receiver can handle >> reassembly >> of the larger IPv4 packets. Thus it requires manual coordination between >> the encapsulator and decapsulator to do this manual override. >> >> Erik > > > From owner-v6ops@ops.ietf.org Thu May 15 13:40: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 NAA16231 for ; Thu, 15 May 2003 13:40:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GMjU-000Pqa-00 for v6ops-data@psg.com; Thu, 15 May 2003 17:41:32 +0000 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 19GMiz-000Pkc-00 for v6ops@ops.ietf.org; Thu, 15 May 2003 17:41:01 +0000 Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4FHf0sa004137 for ; Thu, 15 May 2003 11:41:00 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEX009JHVSB8O@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 15 May 2003 11:41:00 -0600 (MDT) 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 <0HEX005S0VSA71@mail.sun.net> for v6ops@ops.ietf.org; Thu, 15 May 2003 11:40:59 -0600 (MDT) Date: Thu, 15 May 2003 10:42:38 -0700 From: Alain Durand Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt In-reply-to: <3EC3C522.2040403@iprg.nokia.com> To: "Fred L. Templin" Cc: Margaret Wasserman , Erik Nordmark , v6ops@ops.ietf.org Message-id: <9ED84D42-86FC-11D7-B5D3-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, May 15, 2003, at 09:49 AM, Fred L. Templin wrote: > We were in the middle of a discussion on this subject on the list, and > I had addressed the technical points raised by itojun and Vlad > Yasevich. > I find it irregular and indeed unfair that the chairs would go off and > make a private decision while the technical discussion was still taking > place. In short, I object to this action by the chairs. Fred, Let me respectfully disagree with you. The current discussion does not seem to converge and I'd like to see this document moving forward. As this is, with all due respect, not a major issue, I welcome leadership from the chairs and I say, let's move on, if not, we'll be here again next year. - Alain. From owner-v6ops@ops.ietf.org Thu May 15 15:18: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 PAA20389 for ; Thu, 15 May 2003 15:18:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GOGK-000Cel-00 for v6ops-data@psg.com; Thu, 15 May 2003 19:19:32 +0000 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 19GOFo-000Cdt-00 for v6ops@ops.ietf.org; Thu, 15 May 2003 19:19:00 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA17394 for ; Thu, 15 May 2003 12:18:52 -0700 (PDT) Message-Id: <5.1.0.14.2.20030514183923.046f7b90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 May 2003 18:42:31 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Status on Survey Drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-6.5 required=5.0 tests=BAYES_01,DATE_IN_PAST_12_24 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, I just wanted to let you know what is happening with our various "Survey" drafts... As we discussed in SF, I have sent the drafts to the ADs for each area, so that they can comment on the contents and advise us on the best way to get each draft reviewed within the correct area. Response so far has been quite positive. As expected, there are a number of RFCs that need to be re-categorized, and I will concatenate that information and send it to Phil. Once we have new drafts out with all of the RFCs properly categorized, I hope that we will be able to get the areas to review the contents in more detail. Margaret From owner-v6ops@ops.ietf.org Thu May 15 18:19: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 SAA26195 for ; Thu, 15 May 2003 18:19:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GR5o-000FmW-00 for v6ops-data@psg.com; Thu, 15 May 2003 22:20:52 +0000 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 19GR4u-000Fe5-00 for v6ops@ops.ietf.org; Thu, 15 May 2003 22:19:56 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA19352; Thu, 15 May 2003 15:19:10 -0700 (PDT) Message-Id: <5.1.0.14.2.20030515180641.038bd7f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 15 May 2003 18:15:15 -0400 To: "Fred L. Templin" From: Margaret Wasserman Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: <3EC3C522.2040403@iprg.nokia.com> References: <"Your message with ID" <3E6D28F6.10003@iprg.nokia.com> <5.1.0.14.2.20030514195139.046cbe50@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, At 09:49 AM 5/15/2003 -0700, Fred L. Templin wrote: >We were in the middle of a discussion on this subject on the list, and >I had addressed the technical points raised by itojun and Vlad Yasevich. >I find it irregular and indeed unfair that the chairs would go off and >make a private decision while the technical discussion was still taking >place. In short, I object to this action by the chairs. I am sorry that you interpreted my message this way. I have read the discussion, and it appears to me that this is a situation where one person has made a suggestion to raise the MTU to 1380, and several people have written back indicating that there is no reason to make this change. The current wording in the document was the result of a much more extensive earlier discussion, and we would need some new information or technical justifications to warrant revisiting that decision. IMO, it is not necessary that the people who would like the document to remain as-is provide technical justification for a default MTU of 1280, it is up to you to provide technical justifications for why a change is necessary. If there is some new information available that warrants reconsidering this decision, please let me know what it is. Or, if there is a serious technical flaw with the current wording, please explain. Also, if there are other people who think that we should change the default MTU in this document to 1380, please feel free to speak up and explain why. Margaret From owner-v6ops@ops.ietf.org Fri May 16 07:25: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 HAA19656 for ; Fri, 16 May 2003 07:25:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GdLk-000CB4-00 for v6ops-data@psg.com; Fri, 16 May 2003 11:26:08 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19GdKy-000C7V-00 for v6ops@ops.ietf.org; Fri, 16 May 2003 11:25:20 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19417; Fri, 16 May 2003 07:22:12 -0400 (EDT) Message-Id: <200305161122.HAA19417@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com, v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-park-scalable-multi-natpt-00.txt Date: Fri, 16 May 2003 07:21:57 -0400 X-Spam-Status: No, hits=0.0 required=5.0 tests=BAYES_20,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Scalable mNAT-PT Solution Author(s) : S. Park et al. Filename : draft-park-scalable-multi-natpt-00.txt Pages : 10 Date : 2003-5-15 This document provides scalability extension to NAT-PT. The extension is based on the use of DNS-ALG and exchange of load metrics amongst a cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT. mNAT-PT is valuable in connecting large V6 domains to legacy V4 domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-scalable-multi-natpt-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-park-scalable-multi-natpt-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-park-scalable-multi-natpt-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-5-15150104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-park-scalable-multi-natpt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-park-scalable-multi-natpt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-15150104.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri May 16 18:38: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 SAA13639 for ; Fri, 16 May 2003 18:38:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Gnr0-000FM6-00 for v6ops-data@psg.com; Fri, 16 May 2003 22:39:06 +0000 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 19Gnqw-000FL0-00 for v6ops@ops.ietf.org; Fri, 16 May 2003 22:39:02 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id CF8E76DA; Fri, 16 May 2003 18:39:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 16 May 2003 18:39:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3gpp-analysis document and automatic tunneling Date: Fri, 16 May 2003 18:39:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03411A22@tayexc13.americas.cpqcorp.net> Thread-Topic: 3gpp-analysis document and automatic tunneling Thread-Index: AcMaDWrWYF57iLQjSCGph0zYgmrcYwB6IgFg From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 16 May 2003 22:39:01.0687 (UTC) FILETIME=[F2918470:01C31BFB] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA13639 This does not bother me. But lets move this document forward and my input to the authors is as follows. We need this doc out more than anyother work in the IETF for v6ops. Just scale it back than fighting this battle with Pekka or others here for 3 months. We can build a white paper in the industry and say whatever we want about tunnels and the ones we want to use including Teredo if we want. But for the doc give them what they want and lets move forward. We will build use and methods out of the IETF for deployment and 3GPP authors contact me offline and I can explain how we drive this and get it done in 3GPP implementor community. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, May 14, 2003 7:33 AM > To: v6ops@ops.ietf.org > Subject: 3gpp-analysis document and automatic tunneling > > > Hi, > > I'd like to raise one issue in the 3gpp-analysis document > which bothers me > a lot. > > I'd like to either understand the reasoning for mentioning > all the kinds of automatic tunneling mechanism in this draft, > or remove the references. (the last paragraph of 2.2 quoted > below, and some re-editing of the paragraphs in 3.2.1). > > In particular, I feel this is an issue about IGP/BGP > tunneling. It is possible such methods could be used -- if > the network is built just so -- but that's entirely different > thing from whether they're a required or even a recommended > solution ("we have a hammer, now let's go find the nails"). > > I fail to see anything 3GPP specific in the description of > the network in > 3.2.1 and consequently, I'd rather not go down the rathole of > describing > how an ISP would run its network in the 3GPP > scenarios/analysis document. > Rather, I'd try to work out generic ISP scenarios in the ISP > documents to avoid duplicating the work. > > Therefore, I'd like to either understand why this is in scope > and what's > 3GPP specific about it, or try to reword the text > appropriately (I can > try to help if needed). > > ==== > 2.2 Tunneling > > Tunneling is a transition mechanism that requires dual > IPv4/IPv6 > stack functionality in the encapsulating and > decapsulating nodes. > Basic tunneling alternatives are IPv6-in-IPv4 and > IPv4-in-IPv6. > IPv6-in-IPv4 tunneling mechanisms perform as virtual IPv6 > links > over IPv4, and they are implemented by virtual IPv6 > interfaces that > are configured over one or more physical IPv4 > interfaces. Sending > nodes encapsulate IPv6 packets in IPv4 packets when the IPv6 > routing table determines that the next hop toward the IPv6 > destination address is via a tunnel interface. Receiving nodes > decapsulate IPv6 packets from IPv4 packets that arrive on tunnel > interfaces. Tunneling can be static or dynamic. > > Static (configured) tunnels are fixed IPv6 links over > IPv4. They > require static configuration of the IPv6 source, IPv6 > next-hop and > IPv4 destination addresses for IPv6-in-IPv4 > encapsulation. The IPv6 > destination address is specified by the application and > is used to > determine the IPv6 next-hop address via > longest-prefix-match in the > IPv6 routing table. Configured tunnels are specified in [RFC2893]. > > Dynamic (automatic) tunnels enable stateless > encapsulation of IPv6- > in-IPv4. They are virtual IPv6 links over IPv4 where the tunnel > endpoints are not configured, i.e. the links are created > dynamically, and they only require static configuration > of the IPv6 > source address. Like in static tunneling, the IPv6 > destination > address is specified by the application and it is used > to determine > the IPv6 next-hop address via a longest-prefix-match > lookup in the > IPv6 routing table. But unlike static tunnels, the IPv4 > destination > address is not configured (fixed); it is derived from the > IPv6 > next-hop address in some way. For example, the IPv4 > destination > address can be embedded in the IPv6 next-hop address. > Examples of > dynamic tunneling mechanisms are "6to4" [RFC3056], > [ISATAP], [DSTM] > and [TEREDO]. > > [...] > > 3.2.1 Tunneling inside the 3GPP Operator's Network > > Many GPRS operators already have IPv4 backbone networks deployed > and they are gradually migrating them while introducing IPv6 > islands. IPv6 backbones can be considered quite rare in > the first > phases of the transition. If the 3GPP operator already > has IPv6 > widely deployed in its network, this subsection is not so > relevant. > > In initial, smaller scale IPv6 deployment, where a small number of > IPv6 in IPv4 tunnels are required to connect the IPv6 islands over > the 3GPP operator's IPv4 network, manually configured tunnels can > be used. In a 3GPP network, one IPv6 island could contain the GGSN > while another island contains the operator's IPv6 application > servers. However, manually configured tunnels can be an > administrative burden when the number of islands and therefore > tunnels rises. > > It is also possible to use dynamic tunneling mechanisms > such as > "6to4" [RFC3056] and IGP/EGP routing protocol based > tunneling > mechanisms [BGP][IGP]. Routing protocol based mechanisms > such as > [BGP] consist of running BGP between the neighboring > router tunnel > endpoints and using multi-protocol BGP extensions to > exchange > reachability information of IPv6 prefixes. The routers > use this > information to create IPv6 in IPv4 tunnel interfaces and > route IPv6 > packets over the IPv4 network. It is possible to combine this with > different types of tunnels. > [...] > The conclusion is that in most "internal" 3GPP scenarios it is > preferred to use manually configured tunnels or EGP/IGP based > tunneling mechanisms, if it is not feasible to enable > IPv6 in the > network infrastructure yet. > > > -- > 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 May 16 18:39: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 SAA13654 for ; Fri, 16 May 2003 18:39:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19GnrA-000FTU-00 for v6ops-data@psg.com; Fri, 16 May 2003 22:39:16 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19Gnqz-000FLt-00 for v6ops@ops.ietf.org; Fri, 16 May 2003 22:39:05 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5A964557; Fri, 16 May 2003 18:39:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 16 May 2003 18:39:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3gpp-analysis document and automatic tunneling Date: Fri, 16 May 2003 18:39:03 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03411A24@tayexc13.americas.cpqcorp.net> Thread-Topic: 3gpp-analysis document and automatic tunneling Thread-Index: AcMaDb+b/tJISpYCS5WeJHdYCZAhPgAzbYmQAEbdbwA= From: "Bound, Jim" To: , , , Cc: X-OriginalArrivalTime: 16 May 2003 22:39:04.0179 (UTC) FILETIME=[F40DC430:01C31BFB] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA13654 Juha, We need this for deployment as you have it. I don't agree with Pekka. But lets just build a deployment paper out of here. There are going to many of them rolling out soon. /jim > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: Thursday, May 15, 2003 8:43 AM > To: pekkas@netcore.fi; Jonne.Soininen@nokia.com; > Karim.El-Malki@era.ericsson.se > Cc: v6ops@ops.ietf.org > Subject: RE: 3gpp-analysis document and automatic tunneling > > > > Hi, Pekka! > > Trying to briefly answer your questions considering the issue. > > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 14 May, 2003 14:33 > > I'd like to raise one issue in the 3gpp-analysis document > which bothers me > a lot. > > I'd like to either understand the reasoning for mentioning > all the kinds of automatic tunneling mechanism in this draft, > or remove the references. (the last paragraph of 2.2 quoted > below, and some re-editing of the paragraphs in 3.2.1). > > JW: What comes to the tunneling text in 2.2, I am fine with > shortening it. There actually isn't anything 3GPP-specific, > it is more like general tunneling description that is already > described elsewhere (RFC 2893, etc...). As you see, the > references to DSTM, ISATAP and TEREDO are informational > references and thus not vital in this document. They are just > mentioned as examples of tunneling mechanisms. Would making > the tunneling text shorter (e.g. one paragraph) and removing > the references to mechanisms (that are not used in this > document) be a good thing to do in your opinion? > > In particular, I feel this is an issue about IGP/BGP > tunneling. It is possible such methods could be used -- if > the network is built just so -- but that's entirely different > thing from whether they're a required or even a recommended > solution ("we have a hammer, now let's go find the nails"). > > JW: Well, I don't think we can give unambiguous > recommendations. It is much better to discuss different > solution alternatives. Anyway, we can't require any solutions > to be used by operators. We had some discussion with other > authors (especially Karim) how to edit the text. One point > that was brough up in the discussion was redundancy. Static > tunnels on their own don't give a solution if a route goes > down. Instead, EGP/IGP mechanisms support this. Say that I > have multiple tunnels to two router endpoints connected to > the same network. If one goes down I would like to start > tunnelling to the other. Do you have any comments on this? > > I fail to see anything 3GPP specific in the description of > the network in > 3.2.1 and consequently, I'd rather not go down the rathole of > describing > how an ISP would run its network in the 3GPP > scenarios/analysis document. > Rather, I'd try to work out generic ISP scenarios in the ISP > documents to avoid duplicating the work. > > JW: I fully agree with you that we should not do work that > actually belongs to the ISP design team. What kind of text > would you suggest in our document? > > Therefore, I'd like to either understand why this is in scope > and what's > 3GPP specific about it, or try to reword the text > appropriately (I can > try to help if needed). > > JW: Certainly, your help is appreciated! > > Thanks for your comments, > > -Juha W.- > > From owner-v6ops@ops.ietf.org Sat May 17 02:24: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 CAA01838 for ; Sat, 17 May 2003 02:24:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Gv8I-000F9H-00 for v6ops-data@psg.com; Sat, 17 May 2003 06:25:26 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Gv87-000F87-00 for v6ops@ops.ietf.org; Sat, 17 May 2003 06:25:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4H6PAZ25423; Sat, 17 May 2003 09:25:10 +0300 Date: Sat, 17 May 2003 09:25:10 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: Jonne.Soininen@nokia.com, , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3910@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 15 May 2003 juha.wiljakka@nokia.com wrote: > I'd like to raise one issue in the 3gpp-analysis document which bothers me > a lot. > > I'd like to either understand the reasoning for mentioning all the kinds > of automatic tunneling mechanism in this draft, or remove the references. > (the last paragraph of 2.2 quoted below, and some re-editing of the > paragraphs in 3.2.1). > > JW: What comes to the tunneling text in 2.2, I am fine with shortening > it. There actually isn't anything 3GPP-specific, it is more like general > tunneling description that is already described elsewhere (RFC 2893, > etc...). As you see, the references to DSTM, ISATAP and TEREDO are > informational references and thus not vital in this document. They are > just mentioned as examples of tunneling mechanisms. Would making the > tunneling text shorter (e.g. one paragraph) and removing the references > to mechanisms (that are not used in this document) be a good thing to do > in your opinion? Yes, 1-2 paragraphs (one about tunneling in general, possibly one about static/dynamic distinction) without going too far into the specifics would seem to be a good approach -- enough to give the reader an impression about the basic choices he has. > In particular, I feel this is an issue about IGP/BGP tunneling. It is > possible such methods could be used -- if the network is built just so -- > but that's entirely different thing from whether they're a required or > even a recommended solution ("we have a hammer, now let's go find the > nails"). > > JW: Well, I don't think we can give unambiguous recommendations. It is > much better to discuss different solution alternatives. Anyway, we can't > require any solutions to be used by operators. We had some discussion > with other authors (especially Karim) how to edit the text. One point > that was brough up in the discussion was redundancy. Static tunnels on > their own don't give a solution if a route goes down. Instead, EGP/IGP > mechanisms support this. Say that I have multiple tunnels to two router > endpoints connected to the same network. If one goes down I would like > to start tunnelling to the other. Do you have any comments on this? If an operator wishes redundancy, he will run routing protocol(s) on top of his network infrastructure. This would be the case e.g. if the IPv6 network was run on top of static ATM PVC's. In the case of IPv6-over-IPv4, this is often not (as) necessary (but there are some other failure modes in some scenarios), if the IPv4 infrastructure is redundant and there is an IPv4 routing protocol to ensure the reachability. On the other hand, if you cannot rely on the IPv4 infrastructure, you have to run the routing protocol anyway. It seems to me that IGP/EGP mechanisms provide little added value here -- except if you have a very large number of IPv6-enabled routers you wish to connect in a full-mesh manner, and manual configuration would be a chore. Such operators have a lot of other chores too, as managing the other aspects of the routers is not simple either. I've having difficulty picturing that particular deployment (a lot of routers, dense mesh instead of some hierarchy, etc.) to be a requirement. > I fail to see anything 3GPP specific in the description of the network in > 3.2.1 and consequently, I'd rather not go down the rathole of describing > how an ISP would run its network in the 3GPP scenarios/analysis document. > Rather, I'd try to work out generic ISP scenarios in the ISP > documents to avoid duplicating the work. > > JW: I fully agree with you that we should not do work that actually > belongs to the ISP design team. What kind of text would you suggest in > our document? I'll try to work on something to start with within a week. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon May 19 16: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 QAA04890 for ; Mon, 19 May 2003 16:26:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19HrCU-0006O4-00 for v6ops-data@psg.com; Mon, 19 May 2003 20:25:38 +0000 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by psg.com with esmtp (Exim 3.36 #1) id 19HrCR-0006Nn-00 for v6ops@ops.ietf.org; Mon, 19 May 2003 20:25:35 +0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 19 May 2003 16:25:33 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA50@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Pekka Savola'" , juha.wiljakka@nokia.com Cc: Jonne.Soininen@nokia.com, Karim.El-Malki@era.ericsson.se, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Mon, 19 May 2003 16:25:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, I'm very confused, please see below. > > In particular, I feel this is an issue about IGP/BGP > tunneling. It is > > possible such methods could be used -- if the network is > built just so -- > > but that's entirely different thing from whether they're a > required or > > even a recommended solution ("we have a hammer, now let's > go find the > > nails"). > > > > JW: Well, I don't think we can give unambiguous > recommendations. It is > > much better to discuss different solution alternatives. > Anyway, we can't > > require any solutions to be used by operators. We had some > discussion > > with other authors (especially Karim) how to edit the > text. One point > > that was brough up in the discussion was redundancy. > Static tunnels on > > their own don't give a solution if a route goes down. > Instead, EGP/IGP > > mechanisms support this. Say that I have multiple tunnels > to two router > > endpoints connected to the same network. If one goes down > I would like > > to start tunnelling to the other. Do you have any comments on this? > > If an operator wishes redundancy, he will run routing > protocol(s) on top > of his network infrastructure. This would be the case e.g. > if the IPv6 > network was run on top of static ATM PVC's. > > In the case of IPv6-over-IPv4, this is often not (as) > necessary => Why is it not necesary in this case? I feel like I'm missing something. (but there > are some other failure modes in some scenarios), if the IPv4 > infrastructure is redundant and there is an IPv4 routing protocol to > ensure the reachability. => If you're tunnel end point is a certain IPv4 address and that address is statically configured I don't understand the relevance of the IPv4 routing infrastructure and potential redudancy. If you always tunnel to B and B crashes (B was manually configured) what can IPv4 routing do here ? On the other hand, if you cannot > rely on the > IPv4 infrastructure, you have to run the routing protocol anyway. => Don't see the relevance to the point. Am I missing a few things :( ? > > It seems to me that IGP/EGP mechanisms provide little added > value here -- > except if you have a very large number of IPv6-enabled > routers you wish to > connect in a full-mesh manner, and manual configuration > would be a chore. > Such operators have a lot of other chores too, as managing the other > aspects of the routers is not simple either. => What other choices do they have? > > I've having difficulty picturing that particular deployment (a lot of > routers, dense mesh instead of some hierarchy, etc.) to be a > requirement. => This is the case in many planned networks today. Hesham From owner-v6ops@ops.ietf.org Tue May 20 02:06: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 CAA25173 for ; Tue, 20 May 2003 02:06:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I0HY-0009xx-00 for v6ops-data@psg.com; Tue, 20 May 2003 06:07:28 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19I0HU-0009uk-00 for v6ops@ops.ietf.org; Tue, 20 May 2003 06:07:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4K67Ik27403; Tue, 20 May 2003 09:07:18 +0300 Date: Tue, 20 May 2003 09:07:18 +0300 (EEST) From: Pekka Savola To: Hesham Soliman cc: juha.wiljakka@nokia.com, , , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BA50@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hope I'm able to clarify.. On Mon, 19 May 2003, Hesham Soliman wrote: > > If an operator wishes redundancy, he will run routing > > protocol(s) on top > > of his network infrastructure. This would be the case e.g. > > if the IPv6 > > network was run on top of static ATM PVC's. > > > > In the case of IPv6-over-IPv4, this is often not (as) > > necessary > > => Why is it not necesary in this case? I feel like > I'm missing something. Because the operator must ensure the redundancy of his IPv4 infrastructure *anyway*, thus must run an IPv4 routing protocol. So, if a link becomes unreachable to tunnel end-point X, the IPv4 routing protocol will route around the problem, and X will still be reachable. This is invisible to IPv6. > > (but there > > are some other failure modes in some scenarios), if the IPv4 > > infrastructure is redundant and there is an IPv4 routing protocol to > > ensure the reachability. > > => If you're tunnel end point is a certain IPv4 address > and that address is statically configured I don't > understand the relevance of the IPv4 routing infrastructure > and potential redudancy. If you always tunnel to B and > B crashes (B was manually configured) what can IPv4 > routing do here ? Nothing. But then IPv4 infrastructure will be dead too. When/if you're worried about this (and most are), they create two or three tunnels/connections: backup connectivity. This covers crashing of one single device by routing around it. For more extensive discussion, see below. > > On the other hand, if you cannot > > rely on the > > IPv4 infrastructure, you have to run the routing protocol anyway. > > => Don't see the relevance to the point. Am I missing > a few things :( ? I'm not sure.. see above? The point I tried to make here is that in the real world, connections are like: /-------- [network] -------\ / \ R1 .--''''-. | \ RA ( network ) | - [network] R2 '--____-'\ / RB \-------- [network] -------/ .. they do not rely on just one device, and if that fails, you're in problems. (Actually, many networks do have single points of failure, but that's their operational/security decision. Now, in a rather quick picture above, if you want to tunnel between network on the left and network on the right, you typically have: o an IPv4 routing protocol running which includes everything here o if redundancy is important, both networks have two routers and proper internal infrastructure to handle the redundancy (R1 + R2, RA + RB). o if you want to build a direct tunnel between the two, you can either: 1) build it between virtual loopback interfaces, one from each - that is, create a specific address which is configured at both {R1,R2} and {RA,RB} and put that in the routing protocol and configure the tunnel between R_12 and R_AB on all of them. 2) build it between one of each, e.g. R1-RA (or R2-RB, or whatever) 3) build it between two of each, e.g. R1-RA, R2-RB (or whatever), or 4) build a full mesh between all of them: R1-RA, R1-RB, R2-RA, R2-RB The IPv4 routing protocol ensures that the redundancy in the last bullet is only needed when one of the tunnel endpoints goes down. If there is no IPv4 routing protocol, IPv6 routing protocol must be used to ensure rerouting. Now, between the alternatives of the last bullet. These have different tradeoffs. The first is the easiest thing in a way if you require end-point redundancy as it requires only one tunnel. The second is the most used scenario: there you take a risk that the endpoint goes down; in some cases, it may be acceptable. If you don't want to do it, you can pick the third option: the chance that both devices would be down at the same time is very rare: this is not a single point of failure anymore. That last option is typically too heavy to consider here. Speaking of personal operational ISP experience with IPv6-in-IPv4, we've done 2) and 3). Especially 3) should give you everything you'd wish. So, I think you have to consider how much edge network redundancy you want (and what you're willing to pay for it, as there is no free lunch). Sorry for rambling, just trying to explain better why this is not such a problem (IMHO) as one may think. > > It seems to me that IGP/EGP mechanisms provide little added > > value here -- > > except if you have a very large number of IPv6-enabled > > routers you wish to > > connect in a full-mesh manner, and manual configuration > > would be a chore. > > Such operators have a lot of other chores too, as managing the other > > aspects of the routers is not simple either. > > => What other choices do they have? Which part are you referring to? (The above explanation should also cover this.) > > I've having difficulty picturing that particular deployment (a lot of > > routers, dense mesh instead of some hierarchy, etc.) to be a > > requirement. > > => This is the case in many planned networks today. Unfortunately I think I know (a bit) what you refer to, but please elaborate. I really hope that those who have designed the networks know what they're doing, and what kind of tradeoffs it entails. -- 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 May 20 10:25: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 KAA15458 for ; Tue, 20 May 2003 10:25:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19I85C-000CPk-00 for v6ops-data@psg.com; Tue, 20 May 2003 14:27:14 +0000 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by psg.com with esmtp (Exim 3.36 #1) id 19I859-000CPU-00 for v6ops@ops.ietf.org; Tue, 20 May 2003 14:27:11 +0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Tue, 20 May 2003 10:27:10 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA51@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Pekka Savola'" , Hesham Soliman Cc: juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, Karim.El-Malki@era.ericsson.se, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Tue, 20 May 2003 10:27:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > If an operator wishes redundancy, he will run routing > > > protocol(s) on top > > > of his network infrastructure. This would be the case e.g. > > > if the IPv6 > > > network was run on top of static ATM PVC's. > > > > > > In the case of IPv6-over-IPv4, this is often not (as) > > > necessary > > > > => Why is it not necesary in this case? I feel like > > I'm missing something. > > Because the operator must ensure the redundancy of his IPv4 > infrastructure > *anyway*, thus must run an IPv4 routing protocol. So, if a > link becomes > unreachable to tunnel end-point X, the IPv4 routing protocol > will route > around the problem, and X will still be reachable. This is > invisible to > IPv6. => Hmmm, that's not relevant I think, my point is: what if X crashed? > > => If you're tunnel end point is a certain IPv4 address > > and that address is statically configured I don't > > understand the relevance of the IPv4 routing infrastructure > > and potential redudancy. If you always tunnel to B and > > B crashes (B was manually configured) what can IPv4 > > routing do here ? > > Nothing. But then IPv4 infrastructure will be dead too. => No it won't be dead, unless you consider every router to be a SPF. > > When/if you're worried about this (and most are), they > create two or three > tunnels/connections: backup connectivity. This covers > crashing of one > single device by routing around it. For more extensive > discussion, see > below. => see below. > > The point I tried to make here is that in the real world, > connections are > like: > /-------- [network] -------\ > / \ > R1 .--''''-. | \ RA > ( network ) | - [network] > R2 '--____-'\ / RB > \-------- [network] -------/ > > .. they do not rely on just one device, and if that fails, you're in > problems. (Actually, many networks do have single points of > failure, but > that's their operational/security decision. > > Now, in a rather quick picture above, if you want to tunnel between > network on the left and network on the right, you typically have: > > o an IPv4 routing protocol running which includes everything here > > o if redundancy is important, both networks have two > routers and proper > internal infrastructure to handle the redundancy (R1 + R2, RA + RB). > > o if you want to build a direct tunnel between the two, you > can either: > 1) build it between virtual loopback interfaces, one from each > - that is, create a specific address which is configured at > both {R1,R2} and {RA,RB} and put that in the > routing protocol > and configure the tunnel between R_12 and R_AB on > all of them. > 2) build it between one of each, e.g. R1-RA (or R2-RB, > or whatever) > 3) build it between two of each, e.g. R1-RA, R2-RB (or > whatever), or > 4) build a full mesh between all of them: R1-RA, R1-RB, > R2-RA, R2-RB > > The IPv4 routing protocol ensures that the redundancy in the > last bullet > is only needed when one of the tunnel endpoints goes down. > If there is no > IPv4 routing protocol, IPv6 routing protocol must be used to ensure > rerouting. > > Now, between the alternatives of the last bullet. These > have different > tradeoffs. The first is the easiest thing in a way if you require > end-point redundancy as it requires only one tunnel. The > second is the > most used scenario: there you take a risk that the endpoint > goes down; in > some cases, it may be acceptable. If you don't want to do > it, you can > pick the third option: the chance that both devices would be > down at the > same time is very rare: this is not a single point of > failure anymore. > That last option is typically too heavy to consider here. > > Speaking of personal operational ISP experience with > IPv6-in-IPv4, we've > done 2) and 3). Especially 3) should give you everything you'd wish. > > So, I think you have to consider how much edge network > redundancy you want > (and what you're willing to pay for it, as there is no free lunch). > > Sorry for rambling, just trying to explain better why this > is not such a > problem (IMHO) as one may think. => Thanks for the summary. It seems to me that you are agreeing with the redundancy argument but you don't want to automate the whole process, why? Instead of configuring multiple tunnels why not allow the routing to give you the full mesh (option 4) of tunnels in a dynamic manner? Your argument boils down to (I think): we can do this manually, therefore solving it dynamically is not needed. We can also configure addresses manually but having dynamic address allocation makes things easier so I don't think that's a reason to discourage dynamic mechanisms. Hesham From owner-v6ops@ops.ietf.org Wed May 21 03:34: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 DAA11039 for ; Wed, 21 May 2003 03:34:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IO3c-000AGb-00 for v6ops-data@psg.com; Wed, 21 May 2003 07:30:40 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19IO3Y-000AFA-00 for v6ops@ops.ietf.org; Wed, 21 May 2003 07:30:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4L7UM408311; Wed, 21 May 2003 10:30:22 +0300 Date: Wed, 21 May 2003 10:30:21 +0300 (EEST) From: Pekka Savola To: Hesham Soliman cc: juha.wiljakka@nokia.com, , , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BA51@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 20 May 2003, Hesham Soliman wrote: > > > > If an operator wishes redundancy, he will run routing > > > > protocol(s) on top > > > > of his network infrastructure. This would be the case e.g. > > > > if the IPv6 > > > > network was run on top of static ATM PVC's. > > > > > > > > In the case of IPv6-over-IPv4, this is often not (as) > > > > necessary > > > > > > => Why is it not necesary in this case? I feel like > > > I'm missing something. > > > > Because the operator must ensure the redundancy of his IPv4 > > infrastructure > > *anyway*, thus must run an IPv4 routing protocol. So, if a > > link becomes > > unreachable to tunnel end-point X, the IPv4 routing protocol > > will route > > around the problem, and X will still be reachable. This is > > invisible to > > IPv6. > > => Hmmm, that's not relevant I think, my point is: > what if X crashed? The point is not have X crash. If this is considered a problem, a backup connection is built&configured so that the routing protocol can switch over to it in case it does. > > > => If you're tunnel end point is a certain IPv4 address > > > and that address is statically configured I don't > > > understand the relevance of the IPv4 routing infrastructure > > > and potential redudancy. If you always tunnel to B and > > > B crashes (B was manually configured) what can IPv4 > > > routing do here ? > > > > Nothing. But then IPv4 infrastructure will be dead too. > > => No it won't be dead, unless you consider every router > to be a SPF. I assume you mean SPoF. Right, it depends on your network infrastructure. Networks are typically hierarchical, with some added routers for redundancy depending on the level you want. If you tunnel from an edge router to some router and your edge router dies, your connectivity in the edge dies too unless you've backed them up. If the edge networks where the tunnels originate are not backed up, backing up in the core may not be justified. > > The point I tried to make here is that in the real world, > > connections are > > like: > > /-------- [network] -------\ > > / \ > > R1 .--''''-. | \ RA > > ( network ) | - [network] > > R2 '--____-'\ / RB > > \-------- [network] -------/ > > > > .. they do not rely on just one device, and if that fails, you're in > > problems. (Actually, many networks do have single points of > > failure, but > > that's their operational/security decision. > > > > Now, in a rather quick picture above, if you want to tunnel between > > network on the left and network on the right, you typically have: > > > > o an IPv4 routing protocol running which includes everything here > > > > o if redundancy is important, both networks have two > > routers and proper > > internal infrastructure to handle the redundancy (R1 + R2, RA + RB). > > > > o if you want to build a direct tunnel between the two, you > > can either: > > 1) build it between virtual loopback interfaces, one from each > > - that is, create a specific address which is configured at > > both {R1,R2} and {RA,RB} and put that in the > > routing protocol > > and configure the tunnel between R_12 and R_AB on > > all of them. > > 2) build it between one of each, e.g. R1-RA (or R2-RB, > > or whatever) > > 3) build it between two of each, e.g. R1-RA, R2-RB (or > > whatever), or > > 4) build a full mesh between all of them: R1-RA, R1-RB, > > R2-RA, R2-RB > > > > The IPv4 routing protocol ensures that the redundancy in the > > last bullet > > is only needed when one of the tunnel endpoints goes down. > > If there is no > > IPv4 routing protocol, IPv6 routing protocol must be used to ensure > > rerouting. > > > > Now, between the alternatives of the last bullet. These > > have different > > tradeoffs. The first is the easiest thing in a way if you require > > end-point redundancy as it requires only one tunnel. The > > second is the > > most used scenario: there you take a risk that the endpoint > > goes down; in > > some cases, it may be acceptable. If you don't want to do > > it, you can > > pick the third option: the chance that both devices would be > > down at the > > same time is very rare: this is not a single point of > > failure anymore. > > That last option is typically too heavy to consider here. > > > > Speaking of personal operational ISP experience with > > IPv6-in-IPv4, we've > > done 2) and 3). Especially 3) should give you everything you'd wish. > > > > So, I think you have to consider how much edge network > > redundancy you want > > (and what you're willing to pay for it, as there is no free lunch). > > > > Sorry for rambling, just trying to explain better why this > > is not such a > > problem (IMHO) as one may think. > > => Thanks for the summary. It seems to me that you are > agreeing with the redundancy argument but you don't > want to automate the whole process, why? > Instead of configuring multiple tunnels why not allow > the routing to give you the full mesh (option 4) of tunnels > in a dynamic manner? > > Your argument boils down to (I think): we can do this > manually, therefore solving it dynamically is not needed. Yes. And it adds complexity which is unnecessary, and has some other problems as well (e.g. automated, open-to-the-world tunneling is always dangerous). Also, did you know that BGP tunneling has IPR claims? Another point is that it seems to be much easier to just deploy/upgrade to a dual-stack backbone than start with an overlay network, and just add a few tunnels here and there when appropriate or where necessary, the number to be reduced at will. But some ISPs are so fond of overlay network model they may want to build such networks anyway. AFAICS, this is nothing specific to 3GPP. Therefore, an extensive analysis of this case -- whether it's really neeeded, how to address it, etc. -- belongs to the ISP documents, not 3GPP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed May 21 09:29: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 JAA20598 for ; Wed, 21 May 2003 09:29:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19ITcq-000Cgf-00 for v6ops-data@psg.com; Wed, 21 May 2003 13:27:24 +0000 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by psg.com with esmtp (Exim 3.36 #1) id 19ITcc-000Cfr-00 for v6ops@ops.ietf.org; Wed, 21 May 2003 13:27:10 +0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 21 May 2003 09:27:08 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA55@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Pekka Savola'" , Hesham Soliman Cc: juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, Karim.El-Malki@era.ericsson.se, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Wed, 21 May 2003 09:27:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Yes. And it adds complexity which is unnecessary, and has > some other > problems as well (e.g. automated, open-to-the-world > tunneling is always > dangerous). => That words between brackets above are not relevant to this tunnelling mechanism, this is more relevant to a 6-to-4 relay model, which is not what is being discussed. Routing protocols can be secured. Also, did you know that BGP tunneling has IPR claims? => No. > Another point is that it seems to be much easier to just > deploy/upgrade to > a dual-stack backbone than start with an overlay network, => I think this depends greatly on who you talk to and what their network looks like. > But some ISPs are so fond of overlay network model they may > want to build > such networks anyway. AFAICS, this is nothing specific to 3GPP. > Therefore, an extensive analysis of this case -- whether it's really > neeeded, how to address it, etc. -- belongs to the ISP documents, not > 3GPP. => I agree that it's not specific to 3GPP, it is relevant to any operator deploying an IP network so perhaps a general discussion on whether this is needed is better than associating it with any draft. Hesham From owner-v6ops@ops.ietf.org Thu May 22 01:58: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 BAA19718 for ; Thu, 22 May 2003 01:58:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ij3H-000GIU-00 for v6ops-data@psg.com; Thu, 22 May 2003 05:55:43 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Ij31-000GFX-00 for v6ops@ops.ietf.org; Thu, 22 May 2003 05:55:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4M5tHB22480; Thu, 22 May 2003 08:55:18 +0300 Date: Thu, 22 May 2003 08:55:17 +0300 (EEST) From: Pekka Savola To: Hesham Soliman cc: juha.wiljakka@nokia.com, , , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BA55@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 21 May 2003, Hesham Soliman wrote: > > Yes. And it adds complexity which is unnecessary, and has > > some other > > problems as well (e.g. automated, open-to-the-world > > tunneling is always > > dangerous). > > => That words between brackets above are not relevant > to this tunnelling mechanism, this is more relevant > to a 6-to-4 relay model, which is not what is being > discussed. Routing protocols can be secured. It's not as bad as 6to4 but any mechanism implementing any kind of automatic tunneling requires very careful review. The spec is very weak on security considerations. For example, there is no description how the route advertisements in practice build and tear down the tunnel. My fear is that implementations doing this would implement something similar to "automatic tunneling interface with compatible addresses", which is inherently insecure. There must be prior authentication before a tunneled packet is accepted. But being a routing protocol, this might be doable (automatic configured tunneling vs. automatic tunneling). > Also, did you know that BGP tunneling has IPR claims? > > => No. Now you do. I have been quite critical of the technique in the past, and this does nothing to change it, quite the contrary. > > But some ISPs are so fond of overlay network model they may > > want to build > > such networks anyway. AFAICS, this is nothing specific to 3GPP. > > Therefore, an extensive analysis of this case -- whether it's really > > neeeded, how to address it, etc. -- belongs to the ISP documents, not > > 3GPP. > > => I agree that it's not specific to 3GPP, it is relevant > to any operator deploying an IP network so perhaps > a general discussion on whether this is needed is better > than associating it with any draft. Well, there has been general discussion of NAT-PT (or translation) too -- but that's something that's applicable in all scenarios. This is really only an option in the ISP networks, so I think examining it in the ISP context only, in those documents, seems the most useful approach. -- 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 May 22 10:44: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 KAA16751 for ; Thu, 22 May 2003 10:44:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19IrG9-0008sI-00 for v6ops-data@psg.com; Thu, 22 May 2003 14:41:33 +0000 Received: from mail.flarion.com ([63.103.94.23] helo=rrmail01.lab.flarion.com) by psg.com with esmtp (Exim 3.36 #1) id 19IrG4-0008qi-00 for v6ops@ops.ietf.org; Thu, 22 May 2003 14:41:28 +0000 Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 22 May 2003 10:41:25 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA59@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Pekka Savola'" , Hesham Soliman Cc: juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, Karim.El-Malki@era.ericsson.se, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Thu, 22 May 2003 10:41:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > => That words between brackets above are not relevant > > to this tunnelling mechanism, this is more relevant > > to a 6-to-4 relay model, which is not what is being > > discussed. Routing protocols can be secured. > > It's not as bad as 6to4 but any mechanism implementing any kind of > automatic tunneling requires very careful review. The spec > is very weak > on security considerations. For example, there is no > description how the > route advertisements in practice build and tear down the tunnel. > > My fear is that implementations doing this would implement something > similar to "automatic tunneling interface with compatible > addresses", > which is inherently insecure. => That can be clarified of course. But I don't see a fundamental security issue with this approach. You advertise reachability as you do today. > > Well, there has been general discussion of NAT-PT (or > translation) too -- > but that's something that's applicable in all scenarios. > This is really > only an option in the ISP networks, so I think examining it > in the ISP > context only, in those documents, seems the most useful approach. => It's applicable to anyone running a large IP network. There is a complete overlap in some cases between the different scenarios being considered. Hesham From owner-v6ops@ops.ietf.org Mon May 26 05:45:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06839 for ; Mon, 26 May 2003 05:45:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KETl-0005vB-00 for v6ops-data@psg.com; Mon, 26 May 2003 09:41:17 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19KETi-0005uz-00 for v6ops@ops.ietf.org; Mon, 26 May 2003 09:41:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4Q9f9211935; Mon, 26 May 2003 12:41:09 +0300 Date: Mon, 26 May 2003 12:41:08 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: Jonne.Soininen@nokia.com, , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-26.7 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I've tried to think of ways how to edit the text a bit. Let's see..: Examples of dynamic tunneling mechanisms are "6to4" [RFC3056], [ISATAP], [DSTM] and [TEREDO]. ==> replace with: An example of dynamic tunneling mechanism is "6to4" [RFC3056]. In 3.2.1, replace: Many GPRS operators already have IPv4 backbone networks deployed and they are gradually migrating them while introducing IPv6 islands. IPv6 backbones can be considered quite rare in the first phases of the transition. If the 3GPP operator already has IPv6 widely deployed in its network, this subsection is not so relevant. In initial, smaller scale IPv6 deployment, where a small number of IPv6 in IPv4 tunnels are required to connect the IPv6 islands over the 3GPP operator's IPv4 network, manually configured tunnels can be used. In a 3GPP network, one IPv6 island could contain the GGSN while another island contains the operator's IPv6 application servers. However, manually configured tunnels can be an administrative burden when the number of islands and therefore tunnels rises. It is also possible to use dynamic tunneling mechanisms such as "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms [BGP][IGP]. Routing protocol based mechanisms such as [BGP] consist of running BGP between the neighboring router tunnel endpoints and using multi-protocol BGP extensions to exchange reachability information of IPv6 prefixes. The routers use this information to create IPv6 in IPv4 tunnel interfaces and route IPv6 packets over the IPv4 network. It is possible to combine this with different types of tunnels. "6to4" nodes use special IPv6 addresses with a "6to4" prefix containing the IPv4 address of the corresponding "IPv6 in IPv4" tunnel endpoint ("6to4" router) which performs encapsulation / decapsulation. When connecting two nodes with "6to4" addresses, the corresponding "6to4" routers use the IPv4 addresses specified in the "6to4" prefixes to tunnel IPv6 packets through the IPv4 network. But if only one of them has a "6to4" address, a "6to4" relay must be present to perform the missing "6to4" router functionality for the native-IPv6 node. In this case there are two deployment options for "IPv6 in IPv4" tunneling between the "6to4" router and the relay. The first option assumes that "6to4" routers using a given relay each have a default IPv6 route (configured tunnel) pointing to that relay. The other one consists of using an IPv6 exterior routing protocol; this way the set of "6to4" routers using a given relay obtain native IPv6 routes from it using a routing protocol such as BGP4+ [RFC2283]. Although this solution is more complex, it provides effective policy control, i.e. BGP4+ policy determines which "6to4" routers are able to use which relay. The conclusion is that in most "internal" 3GPP scenarios it is preferred to use manually configured tunnels or EGP/IGP based tunneling mechanisms, if it is not feasible to enable IPv6 in the network infrastructure yet. with: Many GPRS operators already have IPv4 backbone networks deployed and they are gradually migrating them while introducing IPv6 islands. IPv6 backbones can be considered quite rare in the first phases of the transition. If the 3GPP operator already has IPv6 widely deployed in its network, this subsection is not so relevant. In initial, smaller scale IPv6 deployment, where a small number of IPv6 in IPv4 tunnels are required to connect the IPv6 islands over the 3GPP operator's IPv4 network, manually configured tunnels can be used. In a 3GPP network, one IPv6 island could contain the GGSN while another island contains the operator's IPv6 application servers. However, manually configured tunnels can be an administrative burden when the number of islands and therefore tunnels rises. In that case, upgrading parts of the backbone to dual stack may be the simplest choice. The administrative burden could also be mitigated by using automated management tools which are typically necessary to manage large networks anyway. Even a dynamic tunneling mechanism could be used if other methods are not suitable. As there is nothing 3GPP-specific in how the core networks are built, further analysis is done in the context of ISP scenarios and solutions [ISP]. (The first two paragraphs are basically unchanged; removed the dynamic tunneling chapter, longer 6to4 consideration and the conclusion. Also, add an informative reference to the ISP scenarios document.) Thoughts? On Sat, 17 May 2003, Pekka Savola wrote: > On Thu, 15 May 2003 juha.wiljakka@nokia.com wrote: > > I'd like to raise one issue in the 3gpp-analysis document which bothers me > > a lot. > > > > I'd like to either understand the reasoning for mentioning all the kinds > > of automatic tunneling mechanism in this draft, or remove the references. > > (the last paragraph of 2.2 quoted below, and some re-editing of the > > paragraphs in 3.2.1). > > > > JW: What comes to the tunneling text in 2.2, I am fine with shortening > > it. There actually isn't anything 3GPP-specific, it is more like general > > tunneling description that is already described elsewhere (RFC 2893, > > etc...). As you see, the references to DSTM, ISATAP and TEREDO are > > informational references and thus not vital in this document. They are > > just mentioned as examples of tunneling mechanisms. Would making the > > tunneling text shorter (e.g. one paragraph) and removing the references > > to mechanisms (that are not used in this document) be a good thing to do > > in your opinion? > > Yes, 1-2 paragraphs (one about tunneling in general, possibly one about > static/dynamic distinction) without going too far into the specifics would > seem to be a good approach -- enough to give the reader an impression > about the basic choices he has. > > > In particular, I feel this is an issue about IGP/BGP tunneling. It is > > possible such methods could be used -- if the network is built just so -- > > but that's entirely different thing from whether they're a required or > > even a recommended solution ("we have a hammer, now let's go find the > > nails"). > > > > JW: Well, I don't think we can give unambiguous recommendations. It is > > much better to discuss different solution alternatives. Anyway, we can't > > require any solutions to be used by operators. We had some discussion > > with other authors (especially Karim) how to edit the text. One point > > that was brough up in the discussion was redundancy. Static tunnels on > > their own don't give a solution if a route goes down. Instead, EGP/IGP > > mechanisms support this. Say that I have multiple tunnels to two router > > endpoints connected to the same network. If one goes down I would like > > to start tunnelling to the other. Do you have any comments on this? > > If an operator wishes redundancy, he will run routing protocol(s) on top > of his network infrastructure. This would be the case e.g. if the IPv6 > network was run on top of static ATM PVC's. > > In the case of IPv6-over-IPv4, this is often not (as) necessary (but there > are some other failure modes in some scenarios), if the IPv4 > infrastructure is redundant and there is an IPv4 routing protocol to > ensure the reachability. On the other hand, if you cannot rely on the > IPv4 infrastructure, you have to run the routing protocol anyway. > > It seems to me that IGP/EGP mechanisms provide little added value here -- > except if you have a very large number of IPv6-enabled routers you wish to > connect in a full-mesh manner, and manual configuration would be a chore. > Such operators have a lot of other chores too, as managing the other > aspects of the routers is not simple either. > > I've having difficulty picturing that particular deployment (a lot of > routers, dense mesh instead of some hierarchy, etc.) to be a requirement. > > > I fail to see anything 3GPP specific in the description of the network in > > 3.2.1 and consequently, I'd rather not go down the rathole of describing > > how an ISP would run its network in the 3GPP scenarios/analysis document. > > Rather, I'd try to work out generic ISP scenarios in the ISP > > documents to avoid duplicating the work. > > > > JW: I fully agree with you that we should not do work that actually > > belongs to the ISP design team. What kind of text would you suggest in > > our document? > > I'll try to work on something to start with within a week. > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon May 26 13:51: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 NAA19437 for ; Mon, 26 May 2003 13:51:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KM4t-000Mws-00 for v6ops-data@psg.com; Mon, 26 May 2003 17:48:07 +0000 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 19KM4p-000Mwf-00 for v6ops@ops.ietf.org; Mon, 26 May 2003 17:48:03 +0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4QHlx0J020663; Mon, 26 May 2003 19:47:59 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 26 May 2003 19:47:49 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28AA2@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" , juha.wiljakka@nokia.com Cc: Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Mon, 26 May 2003 19:47:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Pekka > I've tried to think of ways how to edit the text a bit. Let's see..: > > > Examples of > dynamic tunneling mechanisms are "6to4" [RFC3056], > [ISATAP], [DSTM] > and [TEREDO]. > > ==> replace with: > > An example of dynamic tunneling mechanism is "6to4" [RFC3056]. That removes some useful info for 3gpp people. What did you not like about pointing out the main mechanisms which 3gpp should be aware of? IMO we should keep all the above. Or are you saying that the other mechanisms except 6to4 should not be considered because they are not RFCs? > > In 3.2.1, replace: > > Many GPRS operators already have IPv4 backbone networks deployed > and they are gradually migrating them while introducing IPv6 > islands. IPv6 backbones can be considered quite rare in the first > phases of the transition. If the 3GPP operator already has IPv6 > widely deployed in its network, this subsection is not > so relevant. > > In initial, smaller scale IPv6 deployment, where a small > number of > IPv6 in IPv4 tunnels are required to connect the IPv6 > islands over > the 3GPP operator's IPv4 network, manually configured tunnels can > be used. In a 3GPP network, one IPv6 island could > contain the GGSN > while another island contains the operator's IPv6 > application > servers. However, manually configured tunnels can be an > administrative burden when the number of islands and therefore > tunnels rises. > > It is also possible to use dynamic tunneling mechanisms such as > "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling > mechanisms [BGP][IGP]. Routing protocol based mechanisms such as > [BGP] consist of running BGP between the neighboring > router tunnel > endpoints and using multi-protocol BGP extensions to exchange > reachability information of IPv6 prefixes. The routers use this > information to create IPv6 in IPv4 tunnel interfaces and > route IPv6 > packets over the IPv4 network. It is possible to combine > this with > different types of tunnels. > > "6to4" nodes use special IPv6 addresses with a "6to4" prefix > containing the IPv4 address of the corresponding "IPv6 in IPv4" > tunnel endpoint ("6to4" router) which performs encapsulation / > decapsulation. When connecting two nodes with "6to4" > addresses, the > corresponding "6to4" routers use the IPv4 addresses > specified in > the "6to4" prefixes to tunnel IPv6 packets through the IPv4 > network. But if only one of them has a "6to4" address, a "6to4" > relay must be present to perform the missing "6to4" router > functionality for the native-IPv6 node. In this case > there are two > deployment options for "IPv6 in IPv4" tunneling between > the "6to4" > router and the relay. The first option assumes that > "6to4" routers > using a given relay each have a default IPv6 route > (configured > tunnel) pointing to that relay. The other one consists > of using an > IPv6 exterior routing protocol; this way the set of > "6to4" routers > using a given relay obtain native IPv6 routes from it using a > routing protocol such as BGP4+ [RFC2283]. Although this > solution is > more complex, it provides effective policy control, i.e. BGP4+ > policy determines which "6to4" routers are able to use > which relay. > > The conclusion is that in most "internal" 3GPP scenarios it is > preferred to use manually configured tunnels or EGP/IGP based > tunneling mechanisms, if it is not feasible to enable IPv6 in the > network infrastructure yet. > > with: > > Many GPRS operators already have IPv4 backbone networks deployed > and they are gradually migrating them while introducing IPv6 > islands. IPv6 backbones can be considered quite rare in the first > phases of the transition. If the 3GPP operator already has IPv6 > widely deployed in its network, this subsection is not > so relevant. > > In initial, smaller scale IPv6 deployment, where a small > number of > IPv6 in IPv4 tunnels are required to connect the IPv6 > islands over > the 3GPP operator's IPv4 network, manually configured tunnels can > be used. In a 3GPP network, one IPv6 island could > contain the GGSN > while another island contains the operator's IPv6 application > servers. > > However, manually configured tunnels can be an > administrative burden when the number of islands and therefore > tunnels rises. In that case, upgrading parts of the backbone > to dual stack may be the simplest choice. I don't think this is a viable or simple choice in many cases. The operator should be free to upgrade the backbone independently of the number of sites. Some may want to delay that upgrade. Also there is no discussion about reliability of connections. Doing this with static tunnels (manually configuring a mesh of static tunnels) and relying on v4 routing protocols does not seem like something we can recommend above everything else. It's an option but using a routing protocol you would achieve the same thing without the mesh of static routes. Most importantly there are some routing scenarios in which you will not detect a route failure if you are using static routes. I have been involved in several mobile network designs and these cases are quite common, just like in any other network. So I would not recommend static tunnels as the first choice. Putting the technical aspect aside, you brought up the patent issue with one of the routing protocol mechanisms. Although we should favour non-patented solutions, are we cutting out all routing protocol based solutions because of this patent? The administrative > burden could also be mitigated by using automated management > tools which are typically necessary to manage large networks > anyway. Even a dynamic tunneling mechanism could be used > if other methods are not suitable. Do you mean automated management tools for configuring static tunnels? Seems like you want us to clearly say we prefer static instead of dynamic tunnelling but I don't think we have an agreement here. Maybe we should pose this issue to routing folks? > > As there is nothing 3GPP-specific in how the core networks > are built, further analysis is done in the context of ISP > scenarios and solutions [ISP]. I would replace "core" with backbone since there are some differences in 3gpp terms. The last time I looked at the ISP case, they recommended sticking with BGP for exchanging info over the EGP boundary. That is different from what you are suggesting we write above. Rgds /Karim From owner-v6ops@ops.ietf.org Tue May 27 03:44:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02007 for ; Tue, 27 May 2003 03:44:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KZ5k-0000Vo-00 for v6ops-data@psg.com; Tue, 27 May 2003 07:41:52 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19KZ5g-0000Vc-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 07:41:48 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4R7fgQ21781; Tue, 27 May 2003 10:41:42 +0300 Date: Tue, 27 May 2003 10:41:42 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: juha.wiljakka@nokia.com, , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28AA2@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 26 May 2003, Karim El-Malki (EAB) wrote: > Hi Pekka > > I've tried to think of ways how to edit the text a bit. Let's see..: > > > > > > Examples of > > dynamic tunneling mechanisms are "6to4" [RFC3056], > > [ISATAP], [DSTM] > > and [TEREDO]. > > > > ==> replace with: > > > > An example of dynamic tunneling mechanism is "6to4" [RFC3056]. > > That removes some useful info for 3gpp people. > What did you not like about pointing out the main mechanisms > which 3gpp should be aware of? IMO we should keep all the above. I fail to see how those techniques would be useful for 3GPP people. Well, maybe DSTM could be leveraged, a bit, but it's not really even an automatic tunneling mechanism. It's all just irrelevant information in this context. > Or are you saying that the other mechanisms except 6to4 should > not be considered because they are not RFCs? 6to4 is only one of those currently on our charter, widely deployed and used, and RFC. If we have to pick an example of automatic tunneling, 6to4 is the best candidate. Alternatively, the whole automatic tunneling section could be deleted. > > In 3.2.1, replace: > > > > Many GPRS operators already have IPv4 backbone networks deployed > > and they are gradually migrating them while introducing IPv6 > > islands. IPv6 backbones can be considered quite rare in the first > > phases of the transition. If the 3GPP operator already has IPv6 > > widely deployed in its network, this subsection is not > > so relevant. > > > > In initial, smaller scale IPv6 deployment, where a small > > number of > > IPv6 in IPv4 tunnels are required to connect the IPv6 > > islands over > > the 3GPP operator's IPv4 network, manually configured tunnels can > > be used. In a 3GPP network, one IPv6 island could > > contain the GGSN > > while another island contains the operator's IPv6 > > application > > servers. However, manually configured tunnels can be an > > administrative burden when the number of islands and therefore > > tunnels rises. > > > > It is also possible to use dynamic tunneling mechanisms such as > > "6to4" [RFC3056] and IGP/EGP routing protocol based tunneling > > mechanisms [BGP][IGP]. Routing protocol based mechanisms such as > > [BGP] consist of running BGP between the neighboring > > router tunnel > > endpoints and using multi-protocol BGP extensions to exchange > > reachability information of IPv6 prefixes. The routers use this > > information to create IPv6 in IPv4 tunnel interfaces and > > route IPv6 > > packets over the IPv4 network. It is possible to combine > > this with > > different types of tunnels. > > > > "6to4" nodes use special IPv6 addresses with a "6to4" prefix > > containing the IPv4 address of the corresponding "IPv6 in IPv4" > > tunnel endpoint ("6to4" router) which performs encapsulation / > > decapsulation. When connecting two nodes with "6to4" > > addresses, the > > corresponding "6to4" routers use the IPv4 addresses > > specified in > > the "6to4" prefixes to tunnel IPv6 packets through the IPv4 > > network. But if only one of them has a "6to4" address, a "6to4" > > relay must be present to perform the missing "6to4" router > > functionality for the native-IPv6 node. In this case > > there are two > > deployment options for "IPv6 in IPv4" tunneling between > > the "6to4" > > router and the relay. The first option assumes that > > "6to4" routers > > using a given relay each have a default IPv6 route > > (configured > > tunnel) pointing to that relay. The other one consists > > of using an > > IPv6 exterior routing protocol; this way the set of > > "6to4" routers > > using a given relay obtain native IPv6 routes from it using a > > routing protocol such as BGP4+ [RFC2283]. Although this > > solution is > > more complex, it provides effective policy control, i.e. BGP4+ > > policy determines which "6to4" routers are able to use > > which relay. > > > > The conclusion is that in most "internal" 3GPP scenarios it is > > preferred to use manually configured tunnels or EGP/IGP based > > tunneling mechanisms, if it is not feasible to enable IPv6 in the > > network infrastructure yet. > > > > with: > > > > Many GPRS operators already have IPv4 backbone networks deployed > > and they are gradually migrating them while introducing IPv6 > > islands. IPv6 backbones can be considered quite rare in the first > > phases of the transition. If the 3GPP operator already has IPv6 > > widely deployed in its network, this subsection is not > > so relevant. > > > > In initial, smaller scale IPv6 deployment, where a small > > number of > > IPv6 in IPv4 tunnels are required to connect the IPv6 > > islands over > > the 3GPP operator's IPv4 network, manually configured tunnels can > > be used. In a 3GPP network, one IPv6 island could > > contain the GGSN > > while another island contains the operator's IPv6 application > > servers. > > > > However, manually configured tunnels can be an > > administrative burden when the number of islands and therefore > > tunnels rises. In that case, upgrading parts of the backbone > > to dual stack may be the simplest choice. > > I don't think this is a viable or simple choice in many cases. The > operator should be free to upgrade the backbone independently of the > number of sites. Some may want to delay that upgrade. The operator can, of course, do however he/she wants to. IETF cannot and should not mandate it. But we can document some ways which seem preferable. I've been been there when IPv6 coexistance has been planned and implemented for at least 3 ISP networks (each with gigabit-level traffic levels). In all of those cases, dual stack has been *by far* the simplest choice, augmented by a tunnel here and there. There may be other cases, of course, too -- to be identified in the ISP scenarios if necessary. > Also there is no discussion about reliability of connections. > Doing this with static tunnels (manually configuring a mesh of > static tunnels) and relying on v4 routing protocols does not > seem like something we can recommend above everything else. > It's an option but using a routing protocol you would achieve > the same thing without the mesh of static routes. There isn't because that discussion is not specific to 3GPP. We could tail down the section more if that'd be closer what you expect? > Most importantly there are some routing scenarios in which you > will not detect a route failure if you are using static routes. > I have been involved in several mobile network designs and > these cases are quite common, just like in any other network. > So I would not recommend static tunnels as the first choice. Static tunnels include routing protocols, as above. Or maybe it should be spelled out that in case of configured tunnels, it may be desirable to have redundancy and run a routing protocol. > Putting the technical aspect aside, you brought up the patent > issue with one of the routing protocol mechanisms. Although > we should favour non-patented solutions, are we cutting out > all routing protocol based solutions because of this patent? Not explicitly. I think there is a need to identify the real scenarios and which approaches seem to make the most sense. I'm unconvinced there's anything 3GPP-specific here. This doesn't exclude some (future) findings in the ISP scenarios. > The administrative > > burden could also be mitigated by using automated management > > tools which are typically necessary to manage large networks > > anyway. Even a dynamic tunneling mechanism could be used > > if other methods are not suitable. > > Do you mean automated management tools for configuring static tunnels? Yes. > Seems like you want us to clearly say we prefer static instead > of dynamic tunnelling but I don't think we have an agreement here. Yes. > Maybe we should pose this issue to routing folks? This seems more like an operational issue, not a protocol issue. And this happens to be an ops working group :-). > > As there is nothing 3GPP-specific in how the core networks > > are built, further analysis is done in the context of ISP > > scenarios and solutions [ISP]. > > I would replace "core" with backbone since there are some differences > in 3gpp terms. I'm not sure with the terminology, but backbone is probably better, yes. > The last time I looked at the ISP case, they recommended sticking > with BGP for exchanging info over the EGP boundary. That is > different from what you are suggesting we write above. I'm not sure what you're saying. The last time I looked, the ISP scenarios didn't include *any* discussion to warrant any automatic routing protocol tunneling mechanisms, yes. But the document isn't finished yet. -- 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 May 27 10:01: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 KAA11894 for ; Tue, 27 May 2003 10:01:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kexh-0001Lw-00 for v6ops-data@psg.com; Tue, 27 May 2003 13:57:57 +0000 Received: from web41808.mail.yahoo.com ([66.218.93.142]) by psg.com with smtp (Exim 3.36 #1) id 19KexW-0001Gl-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 13:57:46 +0000 Message-ID: <20030527135744.8143.qmail@web41808.mail.yahoo.com> Received: from [65.213.193.49] by web41808.mail.yahoo.com via HTTP; Tue, 27 May 2003 06:57:44 PDT Date: Tue, 27 May 2003 06:57:44 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Participation To: v6ops@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1209882818-1054043864=:7791" X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_10_20 version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1209882818-1054043864=:7791 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 =================================================================== http://www.caitr.org/internetworking03/index.htm =================================================================== You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials. Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and are valid till June 1, 2003. To register, go to: http://www.caitr.org/internetworking03/registration.htm Important Dates: --------------------- - Early Registration Rates Cut-Off Date: June 1 - Tutorials: June 22, 8:00am - 6:00 pm - Conference sessions: June 23-24, 8:30am-6:00pm Program: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details) Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - Domain Constrained Multicast: A New Approach for IP Multicast Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - An Analysis of Hand-off methods in some WAN and LAN networks Tuesday June 24 Session: Routing Performance - Optimizing Route Convergence - Active Dynamic Routing - Fluid flow network modeling for hop-by-hop feedback control design and analysis Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Problems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: Routing Architecture & QoS - QoS Routing in Networks with Non-Deterministic Information - A new routing architecture: Atomised Routing - Traceroute and BGP AS Path Incongruities - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs : - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-1209882818-1054043864=:7791 Content-Type: text/html; charset=us-ascii
 
     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
===================================================================
    http://www.caitr.org/internetworking03/index.htm
===================================================================
 
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.
Registration for the conference is underway - online registration is now available. The early registration discounts are extremely attractive and are valid till June 1, 2003. To register, go to:
 
Important Dates:
---------------------
- Early Registration Rates Cut-Off Date: June 1
- Tutorials: June 22, 8:00am - 6:00 pm
- Conference sessions: June 23-24, 8:30am-6:00pm
 
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
 
Sunday June 22
    Tutorial-1: MPLS VPNs
    Tutorial-2: IPv6
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet
 
Monday June 23
    Welcome and Keynote
 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing 
      - Network Processing Building Blocks: Enabling the Routers of the Future
 
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
 
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS
      - Mobile Authentication and QoS
      - An Analysis of Hand-off methods in some WAN and LAN networks

Tuesday June 24
    Session: Routing Performance
      - Optimizing Route Convergence
      - Active Dynamic Routing 
      - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
    Session:  Applications & Services
      - Securing the Web with Next Generation Encryption Technologies
      - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 
      - A novel EAC semantic for the RTSP protocol
      - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session:  Network Management & Planning
      - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature
      - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Problems
      - Design Of Fast Fault Restoration System For WDM Networks
      - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session:  Routing Architecture & QoS
      - QoS Routing in Networks with Non-Deterministic Information
      - A new routing architecture: Atomised Routing
      - Traceroute and BGP AS Path Incongruities
      - QoS routing for Differentiated Services: simulations and prototype experiments
      - Probabilistic routing for QoS improvement in GPS networks
 
We look forward to seeing you at the Conference.
 
Regards,
 Conference Technical Co-chairs :
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche

 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM
--0-1209882818-1054043864=:7791-- From owner-v6ops@ops.ietf.org Tue May 27 10:11: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 KAA13122 for ; Tue, 27 May 2003 10:11:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KfAW-0004ur-00 for v6ops-data@psg.com; Tue, 27 May 2003 14:11:12 +0000 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 19KfAR-0004uQ-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 14:11:08 +0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4REBWbj020193; Tue, 27 May 2003 16:11:32 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 May 2003 16:10:49 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28AA6@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Tue, 27 May 2003 16:10:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > Examples of > > > dynamic tunneling mechanisms are "6to4" [RFC3056], > > > [ISATAP], [DSTM] > > > and [TEREDO]. > > > > > > ==> replace with: > > > > > > An example of dynamic tunneling mechanism is "6to4" [RFC3056]. > > > > That removes some useful info for 3gpp people. > > What did you not like about pointing out the main mechanisms > > which 3gpp should be aware of? IMO we should keep all the above. > > I fail to see how those techniques would be useful for 3GPP people. > Well, maybe DSTM could be leveraged, a bit, but it's not > really even an > automatic tunneling mechanism. It's all just irrelevant > information in > this context. I have used ISATAP in 2.5 & 3G mobile networks and think it is a very relevant mechanism. What is your experience of these mechanisms in mobile networks that makes you say this? ..cut some text > > > However, manually configured tunnels can be an > > > administrative burden when the number of islands > and therefore > > > tunnels rises. In that case, upgrading parts of > the backbone > > > to dual stack may be the simplest choice. > > > > I don't think this is a viable or simple choice in many cases. The > > operator should be free to upgrade the backbone > independently of the > > number of sites. Some may want to delay that upgrade. > > The operator can, of course, do however he/she wants to. > IETF cannot > and should not mandate it. But we can document some ways which seem > preferable. What reasons would it be preferable for? Cost? Ease of deployment? I have talked to some who don't think it is cheaper or easier so I don't think we should make this preference. We could say that if the operator finds that the risk/cost allows the backbone to be upgraded then this could avoid tunnelling. But I guess this is quite obvious. > I've been been there when IPv6 coexistance has been planned and > implemented for at least 3 ISP networks (each with > gigabit-level traffic > levels). In all of those cases, dual stack has been *by > far* the simplest > choice, augmented by a tunnel here and there. There may be > other cases, > of course, too -- to be identified in the ISP scenarios if necessary. In my experience (mobile operators) it is not favoured by many. > > Also there is no discussion about reliability of connections. > > Doing this with static tunnels (manually configuring a mesh of > > static tunnels) and relying on v4 routing protocols does not > > seem like something we can recommend above everything else. > > It's an option but using a routing protocol you would achieve > > the same thing without the mesh of static routes. > > There isn't because that discussion is not specific to 3GPP. But there is a requirement of high reliability in general in mobile networks which isn't always there in other scenarios. > We could > tail down the section more if that'd be closer what you expect? No! I want it to say more. This document is supposed to help 3gpp deploy these networks. > > > Most importantly there are some routing scenarios in which you > > will not detect a route failure if you are using static routes. > > I have been involved in several mobile network designs and > > these cases are quite common, just like in any other network. > > So I would not recommend static tunnels as the first choice. > > Static tunnels include routing protocols, as above. Above I talked about running v4 routing protocols while tunnelling v6-in-v4. That doesn't solve all the v6 route failure cases. > > Or maybe it should be spelled out that in case of configured > tunnels, it > may be desirable to have redundancy and run a routing protocol. Run a routing protocol where? Inside the tunnel (v6 routing protocol) and a v4 routing protocol as well? In that case I would simplify things by running a single routing protocol that can exchange both v6 and v4 routes. > > > Putting the technical aspect aside, you brought up the patent > > issue with one of the routing protocol mechanisms. Although > > we should favour non-patented solutions, are we cutting out > > all routing protocol based solutions because of this patent? > > Not explicitly. I hope not implicitly either ;-) > I think there is a need to identify the > real scenarios > and which approaches seem to make the most sense. I'm > unconvinced there's > anything 3GPP-specific here. This doesn't exclude some > (future) findings > in the ISP scenarios. We don't need to cover what is in the ISP scenarios. However we need to give a guideline doc for 3gpp networks. I don't see why we should go and put 3gpp reliability or tunnelling transition mechanism requirements on the ISP doc. Also I've had a look at the ISP work and I thought the 3gpp doc and the ISP doc were pretty much in line when it came to the overlap regions. > > > The administrative > > > burden could also be mitigated by using automated management > > > tools which are typically necessary to manage large networks > > > anyway. Even a dynamic tunneling mechanism could be used > > > if other methods are not suitable. > > > > Do you mean automated management tools for configuring > static tunnels? > > Yes. > > > Seems like you want us to clearly say we prefer static instead > > of dynamic tunnelling but I don't think we have an agreement here. > > Yes. > > > Maybe we should pose this issue to routing folks? > > This seems more like an operational issue, not a protocol > issue. And this > happens to be an ops working group :-). If we have routing experts in this wg I think their input would be helpful. /Karim From owner-v6ops@ops.ietf.org Tue May 27 13:49:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21524 for ; Tue, 27 May 2003 13:49:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KiXA-000CxP-00 for v6ops-data@psg.com; Tue, 27 May 2003 17:46:48 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19KiX4-000Cw9-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 17:46:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4RHkc426315 for ; Tue, 27 May 2003 20:46:38 +0300 Date: Tue, 27 May 2003 20:46:37 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: IP version-independent app development guidelines? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-8.8 required=5.0 tests=BAYES_20,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, It seems that one of the charter items of this working group: 3. Publish Informational RFCs that help application developers (within and outside the IETF) understand how to develop IP version-independent applications. Work with the Applications area, and other areas, to ensure that these documents answer the real-world concerns of application developers. This includes helping to identify IPv4 dependencies in existing IETF application protocols and working with other areas and/or groups within the IETF to resolve them. has seen little progress. Thus, we'd like to solicit input on opinions how to proceed in this area. At least one related individual submission exists in addition to some outside-of-the-IETF documentation: http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-00.txt - do you feel this effort is something that we should be working on? - is this specific draft a good starting point for that work? - do you have ideas for other approaches which might be more suitable (in replacement or in addition to it)? Obviously the abovementioned draft needs more work if the approach should be pursued, but it would be nice to get a feel of the working group where we should go first. Thanks for your comments. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Tue May 27 14:21: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 OAA22594 for ; Tue, 27 May 2003 14:21:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kj42-000Nxg-00 for v6ops-data@psg.com; Tue, 27 May 2003 18:20:46 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Kj3u-000NvB-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 18:20:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4RIKZK26540; Tue, 27 May 2003 21:20:35 +0300 Date: Tue, 27 May 2003 21:20:34 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: juha.wiljakka@nokia.com, , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28AA6@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.5 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > > > > Examples of > > > > dynamic tunneling mechanisms are "6to4" [RFC3056], > > > > [ISATAP], [DSTM] > > > > and [TEREDO]. > > > > > > > > ==> replace with: > > > > > > > > An example of dynamic tunneling mechanism is "6to4" [RFC3056]. > > > > > > That removes some useful info for 3gpp people. > > > What did you not like about pointing out the main mechanisms > > > which 3gpp should be aware of? IMO we should keep all the above. > > > > I fail to see how those techniques would be useful for 3GPP people. > > Well, maybe DSTM could be leveraged, a bit, but it's not > > really even an > > automatic tunneling mechanism. It's all just irrelevant > > information in > > this context. > > I have used ISATAP in 2.5 & 3G mobile networks and think it > is a very relevant mechanism. What is your experience of > these mechanisms in mobile networks that makes you say this? ISATAP doesn't allow you you to connect more than a single host. It doesn't allow routers or networks (e.g. a /64 as recommended to the 3GPP). Thus, I see it being of little use at least in the 3GPP-specific part. > ..cut some text > > > > However, manually configured tunnels can be an > > > > administrative burden when the number of islands > > and therefore > > > > tunnels rises. In that case, upgrading parts of > > the backbone > > > > to dual stack may be the simplest choice. > > > > > > I don't think this is a viable or simple choice in many cases. The > > > operator should be free to upgrade the backbone > > independently of the > > > number of sites. Some may want to delay that upgrade. > > > > The operator can, of course, do however he/she wants to. > > IETF cannot > > and should not mandate it. But we can document some ways which seem > > preferable. > > What reasons would it be preferable for? Cost? Ease of deployment? > I have talked to some who don't think it is cheaper or easier > so I don't think we should make this preference. We could say that > if the operator finds that the risk/cost allows the backbone > to be upgraded then this could avoid tunnelling. But I guess this > is quite obvious. Well, we (as the working group) should document cases how to deploy IPv6 in the common case, using widely applicable mechanisms. Obviously, some approaches are more preferable (without defining the metric, as it isn't a single one) than others. One point to look at might be RFC3439, "Some Internet Architectural Guidelines and Philosophy". I'm not quite convinced that based on 3GPP analysis this yet fulfils the criteria for this. > > I've been been there when IPv6 coexistance has been planned and > > implemented for at least 3 ISP networks (each with > > gigabit-level traffic > > levels). In all of those cases, dual stack has been *by > > far* the simplest > > choice, augmented by a tunnel here and there. There may be > > other cases, > > of course, too -- to be identified in the ISP scenarios if necessary. > > In my experience (mobile operators) it is not favoured by many. That may be due to real or wrong reasons. That's something to be found out by better analysis of it in the ISP context. > > > Also there is no discussion about reliability of connections. > > > Doing this with static tunnels (manually configuring a mesh of > > > static tunnels) and relying on v4 routing protocols does not > > > seem like something we can recommend above everything else. > > > It's an option but using a routing protocol you would achieve > > > the same thing without the mesh of static routes. > > > > There isn't because that discussion is not specific to 3GPP. > > But there is a requirement of high reliability in general > in mobile networks which isn't always there in other scenarios. .. but in most cases, is. > > We could > > tail down the section more if that'd be closer what you expect? > > No! I want it to say more. This document is supposed to help > 3gpp deploy these networks. It's supposed to help in 3GPP environment, not (IMO) in how 3GPP operators could act as ISP's, and how to build their ISP-grade backbone networks. These are two separate issues. > > > Most importantly there are some routing scenarios in which you > > > will not detect a route failure if you are using static routes. > > > I have been involved in several mobile network designs and > > > these cases are quite common, just like in any other network. > > > So I would not recommend static tunnels as the first choice. > > > > Static tunnels include routing protocols, as above. > > Above I talked about running v4 routing protocols while tunnelling > v6-in-v4. That doesn't solve all the v6 route failure cases. Routing protocols can be run in both v4 and v6. Whichever combination seems useful for the operator. Together, they address all concerns. > > Or maybe it should be spelled out that in case of configured > > tunnels, it > > may be desirable to have redundancy and run a routing protocol. > > Run a routing protocol where? Inside the tunnel (v6 routing protocol) > and a v4 routing protocol as well? In that case I would simplify things > by running a single routing protocol that can exchange both v6 and > v4 routes. Yes -- if you want a simple network, you can do this quite easily by running, for example, IS-IS on a dual-stack backbone. For example, we run OSPF for IPv4 and IS-IS for IPv6 only. That's not a problem for us. It's better that way, for now -- we could introduce a new IPv6 routing protocol without disturbing the existing one at all, as they're completely separate. So there are tradeoffs both ways. > > I think there is a need to identify the > > real scenarios > > and which approaches seem to make the most sense. I'm > > unconvinced there's > > anything 3GPP-specific here. This doesn't exclude some > > (future) findings > > in the ISP scenarios. > > We don't need to cover what is in the ISP scenarios. > However we need to give a guideline doc for 3gpp networks. > I don't see why we should go and put 3gpp reliability or > tunnelling transition mechanism requirements on the ISP doc. > Also I've had a look at the ISP work and I thought the 3gpp doc > and the ISP doc were pretty much in line when it came to the > overlap regions. I think we have different concepts of the scope of the 3GPP case. I think it's focus is, and should be, on how the 3GPP-specified part operates (like SIP interactions, providing v4/v6 connectivity to the 3GPP devices, etc.), and how we most fluently merge it with IPv6. *NOT* how to implement backbone networks. (Which is certainly an interesting topic, but really something which is best fit under ISP context because that's where backbone networks of such grade are deployed.) > > > The administrative > > > > burden could also be mitigated by using automated management > > > > tools which are typically necessary to manage large networks > > > > anyway. Even a dynamic tunneling mechanism could be used > > > > if other methods are not suitable. > > > > > > Do you mean automated management tools for configuring > > static tunnels? > > > > Yes. > > > > > Seems like you want us to clearly say we prefer static instead > > > of dynamic tunnelling but I don't think we have an agreement here. > > > > Yes. > > > > > Maybe we should pose this issue to routing folks? > > > > This seems more like an operational issue, not a protocol > > issue. And this > > happens to be an ops working group :-). > > If we have routing experts in this wg I think their input would > be helpful. Agree. I meddle with routing every day, but you already know my opinion *). I'd like to hear others' as well. *) How do you think big operators handle issues like: - updating a piece of configuration (e.g. access-lists, route-maps, policies) on dozens or hundreds of routers - configuring iBGP meshes between routers - update their eBGP filters on their border routers .. other than by (advanced) management tools, or by a lot of manual work? The former would help with tunnels too, but in the latter case the NOC folks are so used to it it doesn't matter anyway. Pick your poison :-). -- 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 May 27 14:43: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 OAA23890 for ; Tue, 27 May 2003 14:43:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KjP2-0004dn-00 for v6ops-data@psg.com; Tue, 27 May 2003 18:42:28 +0000 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 19KjOy-0004X9-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 18:42:24 +0000 Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 8517D7FD3; Tue, 27 May 2003 20:42:03 +0200 (CEST) From: "Jeroen Massar" To: "'Pekka Savola'" , Subject: RE: IP version-independent app development guidelines? Date: Tue, 27 May 2003 20:42:01 +0200 Organization: Unfix Message-ID: <001f01c3247f$a9d4fbe0$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.1165 Importance: Normal X-Spam-Status: No, hits=-25.2 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA23890 Pekka Savola wrote: > Hello all, > > It seems that one of the charter items of this working group: > > 3. Publish Informational RFCs that help application developers > (within and outside the IETF) understand how to develop IP > version-independent applications. Work with the Applications > area, and other areas, to ensure that these documents answer > the real-world concerns of application developers. This > includes helping to identify IPv4 dependencies in existing > IETF application protocols and working with other areas and/or > groups within the IETF to resolve them. > > has seen little progress. Hmm I kinda recall a similar question some time ago ;) > At least one related individual submission exists in addition to some > outside-of-the-IETF documentation: > > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transit ion-00.txt > > - do you feel this effort is something that we should be working on? > - is this specific draft a good starting point for that work? > - do you have ideas for other approaches which might be more > suitable (in replacement or in addition to it)? Yes, yes and see below. > Obviously the abovementioned draft needs more work if the approach should > be pursued, but it would be nice to get a feel of the working group where > we should go first. Along with that draft a good pointer to documents looking like: Implementing AF-independent application by Jun-ichiro itojun Itoh: http://www.kame.net/newsletter/19980604/ (Mentioned as AF-APP in the References section) and: Eva M. Castro's "Porting applications to IPv6": http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html Are good starting points. Maybe these can be merged into one document? Especially Eva's seperate examples make things much clearer than in the current draft. Greets, Jeroen From owner-v6ops@ops.ietf.org Tue May 27 14:54: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 OAA24569 for ; Tue, 27 May 2003 14:54:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KjZa-00083T-00 for v6ops-data@psg.com; Tue, 27 May 2003 18:53:22 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19KjZX-00083B-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 18:53:19 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA01440; Tue, 27 May 2003 11:53:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4RIrHN22735; Tue, 27 May 2003 11:53:17 -0700 X-mProtect: <200305271853> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnct2Lb; Tue, 27 May 2003 11:53:16 PDT Message-ID: <3ED3A65B.4070005@iprg.nokia.com> Date: Tue, 27 May 2003 10:54:35 -0700 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: Pekka Savola CC: "Karim El-Malki (EAB)" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis document and automatic tunneling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-34.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: >>I have used ISATAP in 2.5 & 3G mobile networks and think it >>is a very relevant mechanism. What is your experience of >>these mechanisms in mobile networks that makes you say this? > > > ISATAP doesn't allow you you to connect more than a single host. It > doesn't allow routers or networks (e.g. a /64 as recommended to the 3GPP). > Thus, I see it being of little use at least in the 3GPP-specific part. I don't know exactly the scenarios Karim is referring to, and I don't quite understand Pekka's comment. But, I do see a use case for ISATAP in the text of section 3.1 of "Analysis on IPv6 Transition in 3GPP Networks". Whether/not the case described in this section will be common is a point which can't be proven until significant 3G deployment has occurred, but ISATAP does seem to provide a good fit. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Tue May 27 15:07: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 PAA25636 for ; Tue, 27 May 2003 15:07:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kjmj-000CuV-00 for v6ops-data@psg.com; Tue, 27 May 2003 19:06:57 +0000 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 19Kjmf-000CuI-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 19:06:53 +0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4RJ6eT3008927; Tue, 27 May 2003 21:06:41 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 May 2003 21:06:27 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28AA7@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Fred L. Templin'" , Pekka Savola Cc: juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Tue, 27 May 2003 21:06:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Pekka Savola wrote: > > On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > >>I have used ISATAP in 2.5 & 3G mobile networks and think it > >>is a very relevant mechanism. What is your experience of > >>these mechanisms in mobile networks that makes you say this? > > > > > > ISATAP doesn't allow you you to connect more than a single > host. It > > doesn't allow routers or networks (e.g. a /64 as > recommended to the 3GPP). > > Thus, I see it being of little use at least in the > 3GPP-specific part. > > I don't know exactly the scenarios Karim is referring to, and I don't > quite understand Pekka's comment. But, I do see a use case for ISATAP > in the text of section 3.1 of "Analysis on IPv6 Transition in 3GPP > Networks". That's exactly what I was talking about. I tried it in our lab and in trials over 3G and it worked just fine. > > Whether/not the case described in this section will be > common is a point > which can't be proven until significant 3G deployment has > occurred, but > ISATAP does seem to provide a good fit. We have to make it easy for people to start using IPv6 now that some 3G networks have been deployed and launched commercially. So I agree with Fred that in the above case ISATAP is a good fit. /Karim From owner-v6ops@ops.ietf.org Tue May 27 15:28: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 PAA27210 for ; Tue, 27 May 2003 15:28:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kk6R-000Jbk-00 for v6ops-data@psg.com; Tue, 27 May 2003 19:27:19 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Kk6O-000JbW-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 19:27:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4RJQrL27194; Tue, 27 May 2003 22:26:53 +0300 Date: Tue, 27 May 2003 22:26:53 +0300 (EEST) From: Pekka Savola To: "Fred L. Templin" cc: "Karim El-Malki (EAB)" , , , Subject: Re: 3gpp-analysis document and automatic tunneling In-Reply-To: <3ED3A65B.4070005@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 27 May 2003, Fred L. Templin wrote: > Pekka Savola wrote: > > On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > >>I have used ISATAP in 2.5 & 3G mobile networks and think it > >>is a very relevant mechanism. What is your experience of > >>these mechanisms in mobile networks that makes you say this? > > > > > > ISATAP doesn't allow you you to connect more than a single host. It > > doesn't allow routers or networks (e.g. a /64 as recommended to the 3GPP). > > Thus, I see it being of little use at least in the 3GPP-specific part. > > I don't know exactly the scenarios Karim is referring to, and I don't > quite understand Pekka's comment. But, I do see a use case for ISATAP > in the text of section 3.1 of "Analysis on IPv6 Transition in 3GPP > Networks". > > Whether/not the case described in this section will be common is a point > which can't be proven until significant 3G deployment has occurred, but > ISATAP does seem to provide a good fit. I haven't read the analysis in detail, but the latest Scenarios draft at least *seems* to very explicitly mention that GGSN supports both IPv4 and IPv6. So what appears to be in the analysis document appears to branch into a very questionable direction. -- 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 May 27 16:21: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 QAA29755 for ; Tue, 27 May 2003 16:21:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kkv4-000Chn-00 for v6ops-data@psg.com; Tue, 27 May 2003 20:19:38 +0000 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 19Kkux-000ChQ-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 20:19:31 +0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4RKJKT3012505; Tue, 27 May 2003 22:19:21 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 May 2003 22:19:07 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28AA8@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" Cc: juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Tue, 27 May 2003 22:19:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > > > > > Examples of > > > > > dynamic tunneling mechanisms are "6to4" [RFC3056], > > > > > [ISATAP], [DSTM] > > > > > and [TEREDO]. > > > > > > > > > > ==> replace with: > > > > > > > > > > An example of dynamic tunneling mechanism is > "6to4" [RFC3056]. > > > > > > > > That removes some useful info for 3gpp people. > > > > What did you not like about pointing out the main mechanisms > > > > which 3gpp should be aware of? IMO we should keep all > the above. > > > > > > I fail to see how those techniques would be useful for > 3GPP people. > > > Well, maybe DSTM could be leveraged, a bit, but it's not > > > really even an > > > automatic tunneling mechanism. It's all just irrelevant > > > information in > > > this context. > > > > I have used ISATAP in 2.5 & 3G mobile networks and think it > > is a very relevant mechanism. What is your experience of > > these mechanisms in mobile networks that makes you say this? > > ISATAP doesn't allow you you to connect more than a single host. It > doesn't allow routers or networks (e.g. a /64 as recommended > to the 3GPP). > Thus, I see it being of little use at least in the > 3GPP-specific part. Yes you can connect one host on one tunnel which is useful in early stages and in special roaming cases for example as documented in the draft. /64 is recommended to 3GPP for IPv6-only connections (PDP Contexts). ISATAP is used when you have IPv4-only connections. It's described in the analysis doc. > > > > I've been been there when IPv6 coexistance has been planned and > > > implemented for at least 3 ISP networks (each with > > > gigabit-level traffic > > > levels). In all of those cases, dual stack has been *by > > > far* the simplest > > > choice, augmented by a tunnel here and there. There may be > > > other cases, > > > of course, too -- to be identified in the ISP scenarios > if necessary. > > > > In my experience (mobile operators) it is not favoured by many. > > That may be due to real or wrong reasons. That's something > to be found > out by better analysis of it in the ISP context. It looks to me like the best way to proceed is to keep what we have in the analysis document until we can get the output from the ISP team to see if we are missing things and where to reference the ISP doc. > > > > > Also there is no discussion about reliability of connections. > > > > Doing this with static tunnels (manually configuring a mesh of > > > > static tunnels) and relying on v4 routing protocols does not > > > > seem like something we can recommend above everything else. > > > > It's an option but using a routing protocol you would achieve > > > > the same thing without the mesh of static routes. > > > > > > There isn't because that discussion is not specific to 3GPP. > > > > But there is a requirement of high reliability in general > > in mobile networks which isn't always there in other scenarios. > > .. but in most cases, is. Fine. I assume we'll see it spelled out in the ISP documents. > > > > We could > > > tail down the section more if that'd be closer what you expect? > > > > No! I want it to say more. This document is supposed to help > > 3gpp deploy these networks. > > It's supposed to help in 3GPP environment, not (IMO) in how > 3GPP operators > could act as ISP's, and how to build their ISP-grade > backbone networks. > These are two separate issues. It's hard to define a 3gpp environment as a separate entity. We can consider mobile network sites connected to a generic backbone, which is what we've done in the analysis doc. > > > > > Most importantly there are some routing scenarios in which you > > > > will not detect a route failure if you are using > static routes. > > > > I have been involved in several mobile network designs and > > > > these cases are quite common, just like in any other network. > > > > So I would not recommend static tunnels as the first choice. > > > > > > Static tunnels include routing protocols, as above. > > > > Above I talked about running v4 routing protocols while tunnelling > > v6-in-v4. That doesn't solve all the v6 route failure cases. > > Routing protocols can be run in both v4 and v6. Whichever > combination > seems useful for the operator. Together, they address all concerns. No problem with that. But we must consider both IPv4 and IPv6 backbones between the mobile network sites. > > > > Or maybe it should be spelled out that in case of configured > > > tunnels, it > > > may be desirable to have redundancy and run a routing protocol. > > > > Run a routing protocol where? Inside the tunnel (v6 > routing protocol) > > and a v4 routing protocol as well? In that case I would > simplify things > > by running a single routing protocol that can exchange both v6 and > > v4 routes. > > Yes -- if you want a simple network, you can do this quite easily by > running, for example, IS-IS on a dual-stack backbone. > > For example, we run OSPF for IPv4 and IS-IS for IPv6 only. > That's not a > problem for us. It's better that way, for now -- we could > introduce a new > IPv6 routing protocol without disturbing the existing one at all, as > they're completely separate. > > So there are tradeoffs both ways. That's OK, but your scenario covers the internal backbone routing (IGPs) which is outside the 3gpp analysis scope. However external connectivity from mobile network sites is in scope. That's a different scenario where you typically use EGPs (already deployed). That's why we have the discussion in the doc which considers as one case that in which the backbone has not yet been migrated to v6. I will be looking at the ISP docs when they are out to make sure there are no contradictions. > > > > I think there is a need to identify the > > > real scenarios > > > and which approaches seem to make the most sense. I'm > > > unconvinced there's > > > anything 3GPP-specific here. This doesn't exclude some > > > (future) findings > > > in the ISP scenarios. > > > > We don't need to cover what is in the ISP scenarios. > > However we need to give a guideline doc for 3gpp networks. > > I don't see why we should go and put 3gpp reliability or > > tunnelling transition mechanism requirements on the ISP doc. > > Also I've had a look at the ISP work and I thought the 3gpp doc > > and the ISP doc were pretty much in line when it came to the > > overlap regions. > > I think we have different concepts of the scope of the 3GPP > case. I think > it's focus is, and should be, on how the 3GPP-specified part operates > (like SIP interactions, providing v4/v6 connectivity to the > 3GPP devices, > etc.), and how we most fluently merge it with IPv6. > > *NOT* how to implement backbone networks. (Which is certainly an > interesting topic, but really something which is best fit under ISP > context because that's where backbone networks of such grade are > deployed.) We're covering how to connect mobile network sites (some may be migrated to v6 before others) to the backbone. That creates some overlap with the ISP work but so far it's not been an issue IMO. > > > > > The administrative > > > > > burden could also be mitigated by using > automated management > > > > > tools which are typically necessary to manage > large networks > > > > > anyway. Even a dynamic tunneling mechanism > could be used > > > > > if other methods are not suitable. > > > > > > > > Do you mean automated management tools for configuring > > > static tunnels? > > > > > > Yes. > > > > > > > Seems like you want us to clearly say we prefer static instead > > > > of dynamic tunnelling but I don't think we have an > agreement here. > > > > > > Yes. > > > > > > > Maybe we should pose this issue to routing folks? > > > > > > This seems more like an operational issue, not a protocol > > > issue. And this > > > happens to be an ops working group :-). > > > > If we have routing experts in this wg I think their input would > > be helpful. > > Agree. > > I meddle with routing every day, but you already know my > opinion *). I'd > like to hear others' as well. > > *) How do you think big operators handle issues like: > - updating a piece of configuration (e.g. access-lists, route-maps, > policies) on dozens or hundreds of routers > - configuring iBGP meshes between routers > - update their eBGP filters on their border routers > > .. other than by (advanced) management tools, or by a lot of > manual work? > The former would help with tunnels too, but in the latter > case the NOC > folks are so used to it it doesn't matter anyway. Pick your > poison :-). I was hoping we would not add more manual config than there is already if possible. Also, just to clarify, iBGP meshes and eBGP filters would typically be within the backbone ISP scope. /Karim From owner-v6ops@ops.ietf.org Tue May 27 16:28:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00277 for ; Tue, 27 May 2003 16:28:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kl3U-000Fwg-00 for v6ops-data@psg.com; Tue, 27 May 2003 20:28:20 +0000 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 19Kl3Q-000FwF-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 20:28:17 +0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4RKSgbj015923; Tue, 27 May 2003 22:28:42 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 May 2003 22:27:58 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28AA9@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" , "Fred L. Templin" Cc: juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Tue, 27 May 2003 22:28:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Tue, 27 May 2003, Fred L. Templin wrote: > > Pekka Savola wrote: > > > On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > > >>I have used ISATAP in 2.5 & 3G mobile networks and think it > > >>is a very relevant mechanism. What is your experience of > > >>these mechanisms in mobile networks that makes you say this? > > > > > > > > > ISATAP doesn't allow you you to connect more than a > single host. It > > > doesn't allow routers or networks (e.g. a /64 as > recommended to the 3GPP). > > > Thus, I see it being of little use at least in the > 3GPP-specific part. > > > > I don't know exactly the scenarios Karim is referring to, > and I don't > > quite understand Pekka's comment. But, I do see a use case > for ISATAP > > in the text of section 3.1 of "Analysis on IPv6 Transition in 3GPP > > Networks". > > > > Whether/not the case described in this section will be > common is a point > > which can't be proven until significant 3G deployment has > occurred, but > > ISATAP does seem to provide a good fit. > > I haven't read the analysis in detail, but the latest > Scenarios draft at > least *seems* to very explicitly mention that GGSN supports > both IPv4 and > IPv6. I am pretty certain that's not what the doc says. First, the fact that the GGSN can support IPv6 and IPv4 routing does not mean that it has support for IPv6 native connectivity to mobile hosts. Secondly we cannot guarantee that all GGSNs from all operators will support IPv6 at the same time. Some GGSNs will only support IPv4 as they do today. /Karim From owner-v6ops@ops.ietf.org Tue May 27 16:34: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 QAA00858 for ; Tue, 27 May 2003 16:34:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kl9P-000Hd0-00 for v6ops-data@psg.com; Tue, 27 May 2003 20:34:27 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19Kl9L-000Hck-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 20:34:23 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4RKYGQ27841; Tue, 27 May 2003 23:34:16 +0300 Date: Tue, 27 May 2003 23:34:15 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: "Fred L. Templin" , , , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28AA9@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > > > Whether/not the case described in this section will be > > common is a point > > > which can't be proven until significant 3G deployment has > > occurred, but > > > ISATAP does seem to provide a good fit. > > > > I haven't read the analysis in detail, but the latest > > Scenarios draft at > > least *seems* to very explicitly mention that GGSN supports > > both IPv4 and > > IPv6. > > I am pretty certain that's not what the doc says. > First, the fact that the GGSN can support IPv6 and IPv4 routing does > not mean that it has support for IPv6 native connectivity to mobile hosts. > Secondly we cannot guarantee that all GGSNs from all operators > will support IPv6 at the same time. Some GGSNs will only support > IPv4 as they do today. It seems to that the clear implication from the draft is: "If you want IPv4, use an IPv4 GGSN" "If you want IPv6, use an IPv6 GGSN" These do not need to be the same. This seems clearly stated in Scenarios sect 3.1 PDP contexts could be opened to different service boxes in a service provider's network (whichever support IPv6); and if the service provider does not support *any* IPv6, the user is on its own *anyway*. (of course, the UE could support a transition mechanism itself but I find that a bit questionable approach -- the goal is to make 3GPP devices simple not complex.) -- 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 May 27 16:48: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 QAA01492 for ; Tue, 27 May 2003 16:48:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KlM9-000MzJ-00 for v6ops-data@psg.com; Tue, 27 May 2003 20:47:37 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19KlM2-000MwW-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 20:47:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4RKlPV27917; Tue, 27 May 2003 23:47:26 +0300 Date: Tue, 27 May 2003 23:47:25 +0300 (EEST) From: Pekka Savola To: "Karim El-Malki (EAB)" cc: juha.wiljakka@nokia.com, , Subject: RE: 3gpp-analysis document and automatic tunneling In-Reply-To: <76E5F712842F5F49A35738622BAA0F4FA28AA8@ESEALNT442.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > > > I have used ISATAP in 2.5 & 3G mobile networks and think it > > > is a very relevant mechanism. What is your experience of > > > these mechanisms in mobile networks that makes you say this? > > > > ISATAP doesn't allow you you to connect more than a single host. It > > doesn't allow routers or networks (e.g. a /64 as recommended > > to the 3GPP). > > Thus, I see it being of little use at least in the > > 3GPP-specific part. > > Yes you can connect one host on one tunnel which is useful in early > stages and in special roaming cases for example as documented in > the draft. /64 is recommended to 3GPP for IPv6-only connections > (PDP Contexts). ISATAP is used when you have IPv4-only connections. > It's described in the analysis doc. See the other thread. > > > > I've been been there when IPv6 coexistance has been planned and > > > > implemented for at least 3 ISP networks (each with > > > > gigabit-level traffic > > > > levels). In all of those cases, dual stack has been *by > > > > far* the simplest > > > > choice, augmented by a tunnel here and there. There may be > > > > other cases, > > > > of course, too -- to be identified in the ISP scenarios > > if necessary. > > > > > > In my experience (mobile operators) it is not favoured by many. > > > > That may be due to real or wrong reasons. That's something > > to be found > > out by better analysis of it in the ISP context. > > It looks to me like the best way to proceed is to keep what we have in > the analysis document until we can get the output from the ISP team to > see if we are missing things and where to reference the ISP doc. Disagree. > > > > We could > > > > tail down the section more if that'd be closer what you expect? > > > > > > No! I want it to say more. This document is supposed to help > > > 3gpp deploy these networks. > > > > It's supposed to help in 3GPP environment, not (IMO) in how > > 3GPP operators > > could act as ISP's, and how to build their ISP-grade > > backbone networks. > > These are two separate issues. > > It's hard to define a 3gpp environment as a separate entity. I can imagine but it's not the only thing that's difficult :-) > We can consider mobile network sites connected to a generic > backbone, which is what we've done in the analysis doc. I don't know this scenario in enough detail to say much of anything, but it seems to me that you consider these mobile network sites similar to PoPs (Point of Presence) or even PE (Provider Edge) routers. In which case, there doesn't seem to be anything 3GPP-specific in them. > > > > Or maybe it should be spelled out that in case of configured > > > > tunnels, it > > > > may be desirable to have redundancy and run a routing protocol. > > > > > > Run a routing protocol where? Inside the tunnel (v6 > > routing protocol) > > > and a v4 routing protocol as well? In that case I would > > simplify things > > > by running a single routing protocol that can exchange both v6 and > > > v4 routes. > > > > Yes -- if you want a simple network, you can do this quite easily by > > running, for example, IS-IS on a dual-stack backbone. > > > > For example, we run OSPF for IPv4 and IS-IS for IPv6 only. > > That's not a > > problem for us. It's better that way, for now -- we could > > introduce a new > > IPv6 routing protocol without disturbing the existing one at all, as > > they're completely separate. > > > > So there are tradeoffs both ways. > > That's OK, but your scenario covers the internal backbone routing > (IGPs) which is outside the 3gpp analysis scope. However external > connectivity from mobile network sites is in scope. That's a different > scenario where you typically use EGPs (already deployed). Could you tell me why EGP's are used in such a context? Aren't those mobile network sites under a single administration. Naturally, you run BGP in addition to IGP's, but that's beside the point; the IGP's is basically what you use to ensure redundancy. > That's why we > have the discussion in the doc which considers as one case that in > which the backbone has not yet been migrated to v6. I will be looking > at the ISP docs when they are out to make sure there are no contradictions. The point is, to avoid contradictions *later* and to make it faster to progress the drafts in other fronts (seem to be last-call or almost IESG material already), it would seem to be preferable to try to keep away from non-3GPP discussion in 3GPP documents. > > > > I think there is a need to identify the > > > > real scenarios > > > > and which approaches seem to make the most sense. I'm > > > > unconvinced there's > > > > anything 3GPP-specific here. This doesn't exclude some > > > > (future) findings > > > > in the ISP scenarios. > > > > > > We don't need to cover what is in the ISP scenarios. > > > However we need to give a guideline doc for 3gpp networks. > > > I don't see why we should go and put 3gpp reliability or > > > tunnelling transition mechanism requirements on the ISP doc. > > > Also I've had a look at the ISP work and I thought the 3gpp doc > > > and the ISP doc were pretty much in line when it came to the > > > overlap regions. > > > > I think we have different concepts of the scope of the 3GPP > > case. I think > > it's focus is, and should be, on how the 3GPP-specified part operates > > (like SIP interactions, providing v4/v6 connectivity to the > > 3GPP devices, > > etc.), and how we most fluently merge it with IPv6. > > > > *NOT* how to implement backbone networks. (Which is certainly an > > interesting topic, but really something which is best fit under ISP > > context because that's where backbone networks of such grade are > > deployed.) > > We're covering how to connect mobile network sites (some may be > migrated to v6 before others) to the backbone. That creates some > overlap with the ISP work but so far it's not been an issue IMO. See above. > > > > > The administrative > > > > > > burden could also be mitigated by using > > automated management > > > > > > tools which are typically necessary to manage > > large networks > > > > > > anyway. Even a dynamic tunneling mechanism > > could be used > > > > > > if other methods are not suitable. > > > > > > > > > > Do you mean automated management tools for configuring > > > > static tunnels? > > > > > > > > Yes. > > > > > > > > > Seems like you want us to clearly say we prefer static instead > > > > > of dynamic tunnelling but I don't think we have an > > agreement here. > > > > > > > > Yes. > > > > > > > > > Maybe we should pose this issue to routing folks? > > > > > > > > This seems more like an operational issue, not a protocol > > > > issue. And this > > > > happens to be an ops working group :-). > > > > > > If we have routing experts in this wg I think their input would > > > be helpful. > > > > Agree. > > > > I meddle with routing every day, but you already know my > > opinion *). I'd > > like to hear others' as well. > > > > *) How do you think big operators handle issues like: > > - updating a piece of configuration (e.g. access-lists, route-maps, > > policies) on dozens or hundreds of routers > > - configuring iBGP meshes between routers > > - update their eBGP filters on their border routers > > > > .. other than by (advanced) management tools, or by a lot of > > manual work? > > The former would help with tunnels too, but in the latter > > case the NOC > > folks are so used to it it doesn't matter anyway. Pick your > > poison :-). > > I was hoping we would not add more manual config than there is > already if possible. Yes, that's of a value, but IMHO it seems to me, that it isn't of *that much* value.. as mechanism where these are really needed have to be in place anyway.. > Also, just to clarify, iBGP meshes and eBGP > filters would typically be within the backbone ISP scope. Exactly, why something like this is better analyzed in the ISP context. -- 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 May 27 18:14: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 SAA05807 for ; Tue, 27 May 2003 18:14:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kmh2-0001RH-00 for v6ops-data@psg.com; Tue, 27 May 2003 22:13:16 +0000 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 19Kmh0-0001Qv-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 22:13:14 +0000 Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.9.R) for ; Wed, 28 May 2003 00:14:03 +0200 Message-ID: <062e01c3249d$46de6030$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: IP version-independent app development guidelines? Date: Wed, 28 May 2003 00:13:57 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Status: No, hits=-16.3 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, all, I agree that this work is important, and is a good starting point. As I'm not expert in the applications part, I forwarded it to people that is already working in applications, so they can try to contribute. Regards, Jordi ----- Original Message ----- From: "Pekka Savola" To: Sent: Tuesday, May 27, 2003 7:46 PM Subject: IP version-independent app development guidelines? > Hello all, > > It seems that one of the charter items of this working group: > > 3. Publish Informational RFCs that help application developers > (within and outside the IETF) understand how to develop IP > version-independent applications. Work with the Applications > area, and other areas, to ensure that these documents answer > the real-world concerns of application developers. This > includes helping to identify IPv4 dependencies in existing > IETF application protocols and working with other areas and/or > groups within the IETF to resolve them. > > has seen little progress. > > Thus, we'd like to solicit input on opinions how to proceed in this area. > > At least one related individual submission exists in addition to some > outside-of-the-IETF documentation: > > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-00.txt > > - do you feel this effort is something that we should be working on? > - is this specific draft a good starting point for that work? > - do you have ideas for other approaches which might be more > suitable (in replacement or in addition to it)? > > Obviously the abovementioned draft needs more work if the approach should > be pursued, but it would be nice to get a feel of the working group where > we should go first. > > Thanks for your comments. > > Pekka, Margaret & Bob > ***************************** Madrid 2003 Global IPv6 Summit Presentations and videos on-line at: http://www.ipv6-es.com From owner-v6ops@ops.ietf.org Tue May 27 18:18:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06097 for ; Tue, 27 May 2003 18:18:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KmmE-0003uF-00 for v6ops-data@psg.com; Tue, 27 May 2003 22:18:38 +0000 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 19KmmC-0003u2-00 for v6ops@ops.ietf.org; Tue, 27 May 2003 22:18:37 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F3E2C82 for ; Wed, 28 May 2003 07:18:34 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: jeroen's message of Tue, 27 May 2003 20:42:01 +0200. <001f01c3247f$a9d4fbe0$210d640a@unfix.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IP version-independent app development guidelines? From: itojun@iijlab.net Date: Wed, 28 May 2003 07:18:34 +0900 Message-Id: <20030527221835.F3E2C82@coconut.itojun.org> X-Spam-Status: No, hits=-8.0 required=5.0 tests=BAYES_10,IN_REP_TO,NO_REAL_NAME autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Along with that draft a good pointer to documents looking like: > >Implementing AF-independent application by Jun-ichiro itojun Itoh: >http://www.kame.net/newsletter/19980604/=20 >(Mentioned as AF-APP in the References section) i wrote a book on the topic: 'IPv6 network programming', ISBN 4-7561-4236-2 (in japanese) i'm negotiating w/ outside-of-japan publishers for english version. (i wrote it in english) itojun From owner-v6ops@ops.ietf.org Tue May 27 20:19: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 UAA10765 for ; Tue, 27 May 2003 20:19:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kodn-000Ggf-00 for v6ops-data@psg.com; Wed, 28 May 2003 00:18:03 +0000 Received: from u33.gpu114.samsung.co.kr ([203.254.224.33] helo=mailout3.samsung.com) by psg.com with esmtp (Exim 3.36 #1) id 19Kodk-000GgF-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 00:18:00 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HFK00805M5V6T@mailout3.samsung.com> for v6ops@ops.ietf.org; Wed, 28 May 2003 09:17:55 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HFK001DNM5VK4@mailout3.samsung.com> for v6ops@ops.ietf.org; Wed, 28 May 2003 09:17: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 <0HFK003HOM5UWO@mmp1.samsung.com> for v6ops@ops.ietf.org; Wed, 28 May 2003 09:17:55 +0900 (KST) Date: Wed, 28 May 2003 09:17:05 +0900 From: Soohong Daniel Park Subject: RE: IP version-independent app development guidelines? In-reply-to: To: "'Pekka Savola'" , v6ops@ops.ietf.org Message-id: <002501c324ae$785ee420$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=-16.1 required=5.0 tests=BAYES_01,IN_REP_TO,ORIGINAL_MESSAGE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Pekka For the IPv6 Operation, application consideration should be considered. It's a fit issue. Daniel Mobile Platform Laboratory, SAMSUNG Electronics -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola Sent: Wednesday, May 28, 2003 2:47 AM To: v6ops@ops.ietf.org Subject: IP version-independent app development guidelines? Hello all, It seems that one of the charter items of this working group: 3. Publish Informational RFCs that help application developers (within and outside the IETF) understand how to develop IP version-independent applications. Work with the Applications area, and other areas, to ensure that these documents answer the real-world concerns of application developers. This includes helping to identify IPv4 dependencies in existing IETF application protocols and working with other areas and/or groups within the IETF to resolve them. has seen little progress. Thus, we'd like to solicit input on opinions how to proceed in this area. At least one related individual submission exists in addition to some outside-of-the-IETF documentation: http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transit ion-00.txt - do you feel this effort is something that we should be working on? - is this specific draft a good starting point for that work? - do you have ideas for other approaches which might be more suitable (in replacement or in addition to it)? Obviously the abovementioned draft needs more work if the approach should be pursued, but it would be nice to get a feel of the working group where we should go first. Thanks for your comments. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Wed May 28 06:07: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 GAA23841 for ; Wed, 28 May 2003 06:07:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Kxmu-000KNL-00 for v6ops-data@psg.com; Wed, 28 May 2003 10:04:04 +0000 Received: from gsyc064.dat.escet.urjc.es ([193.147.71.64] helo=gsyc.escet.urjc.es) by psg.com with esmtp (Exim 3.36 #1) id 19KxmP-000KB7-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 10:03:33 +0000 Received: from localhost.localdomain (eva@gsyc104.dat.escet.urjc.es [193.147.71.104]) by gsyc.escet.urjc.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA27559; Wed, 28 May 2003 12:03:25 +0200 X-Authentication-Warning: gsyc.escet.urjc.es: Host eva@gsyc104.dat.escet.urjc.es [193.147.71.104] claimed to be localhost.localdomain Subject: RE: IP version-independent app development guidelines? From: "Eva M. Castro" To: Jeroen Massar Cc: "'Pekka Savola'" , v6ops@ops.ietf.org In-Reply-To: <001f01c3247f$a9d4fbe0$210d640a@unfix.org> References: <001f01c3247f$a9d4fbe0$210d640a@unfix.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 28 May 2003 12:00:49 +0200 Message-Id: <1054116049.5366.12.camel@azul> Mime-Version: 1.0 X-Spam-Status: No, hits=-40.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_XIMIAN,X_AUTH_WARNING autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-05-27 at 20:42, Jeroen Massar wrote: > Pekka Savola wrote: > > > Hello all, > > > > It seems that one of the charter items of this working group: > > > > 3. Publish Informational RFCs that help application developers > > (within and outside the IETF) understand how to develop IP > > version-independent applications. Work with the Applications > > area, and other areas, to ensure that these documents answer > > the real-world concerns of application developers. This > > includes helping to identify IPv4 dependencies in existing > > IETF application protocols and working with other areas and/or > > groups within the IETF to resolve them. > > > > has seen little progress. > > Hmm I kinda recall a similar question some time ago ;) > > > At least one related individual submission exists in addition to some > > outside-of-the-IETF documentation: > > > > > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transit > ion-00.txt > > > > - do you feel this effort is something that we should be working on? > > - is this specific draft a good starting point for that work? > > - do you have ideas for other approaches which might be more > > suitable (in replacement or in addition to it)? > > Yes, yes and see below. I think people is worried about network translation and not many studies arise around application porting. From my point of view, some porting applications guidelines should be described around the socket API as a draft. The IPv6 extensions to the socket API are an RFC, but not only strictly API changes should be considered but also all IP depencies in the source code. > > > Obviously the abovementioned draft needs more work if the approach > should > > be pursued, but it would be nice to get a feel of the working group > where > > we should go first. > > Along with that draft a good pointer to documents looking like: > > Implementing AF-independent application by Jun-ichiro itojun Itoh: > http://www.kame.net/newsletter/19980604/ > (Mentioned as AF-APP in the References section) > > and: > Eva M. Castro's "Porting applications to IPv6": > http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html > > Are good starting points. Maybe these can be merged into one document? > Especially Eva's seperate examples make things much clearer than > in the current draft. I would be to glad to help and complete the previous porting application draft. Regards, eva From owner-v6ops@ops.ietf.org Wed May 28 06:08: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 GAA23880 for ; Wed, 28 May 2003 06:08:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KxpF-000Kez-00 for v6ops-data@psg.com; Wed, 28 May 2003 10:06:29 +0000 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 19Kxp9-000KeX-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 10:06:23 +0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4SA6IT3023198; Wed, 28 May 2003 12:06:18 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 28 May 2003 12:06:02 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4FA28AAA@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (EAB)" To: "'Pekka Savola'" Cc: "Fred L. Templin" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling Date: Wed, 28 May 2003 12:06:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Tue, 27 May 2003, Karim El-Malki (EAB) wrote: > > > > Whether/not the case described in this section will be > > > common is a point > > > > which can't be proven until significant 3G deployment has > > > occurred, but > > > > ISATAP does seem to provide a good fit. > > > > > > I haven't read the analysis in detail, but the latest > > > Scenarios draft at > > > least *seems* to very explicitly mention that GGSN supports > > > both IPv4 and > > > IPv6. > > > > I am pretty certain that's not what the doc says. > > First, the fact that the GGSN can support IPv6 and IPv4 > routing does > > not mean that it has support for IPv6 native connectivity > to mobile hosts. > > Secondly we cannot guarantee that all GGSNs from all operators > > will support IPv6 at the same time. Some GGSNs will only support > > IPv4 as they do today. > > It seems to that the clear implication from the draft is: > > "If you want IPv4, use an IPv4 GGSN" > "If you want IPv6, use an IPv6 GGSN" > > These do not need to be the same. This seems clearly stated > in Scenarios > sect 3.1 You can't really choose to use one or the other GGSN. You request an IPv6 connection and if it doesn't work you revert to using IPv4 and some automated tunnelling like ISATAP. There are other mechanisms also that I don't think we can exclude yet, which is why at least mentioning the few applicable mechanisms in the draft is important. > > PDP contexts could be opened to different service boxes in a service > provider's network (whichever support IPv6); and if the > service provider > does not support *any* IPv6, the user is on its own *anyway*. > > (of course, the UE could support a transition mechanism > itself but I find > that a bit questionable approach -- the goal is to make 3GPP devices > simple not complex.) My view is very different as you have realised already. I think we need to have transition mechanisms for early v6 introduction stages and special roaming cases which allow the user to access those v6 e.g. peer2peer services even when a v6 pdp context is not available. I've tried it in real networks and a simple mechanism like ISATAP works fine. Anyway we seem not to be taking steps forward with this discussion so I'll stop here. /Karim From owner-v6ops@ops.ietf.org Wed May 28 06:23: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 GAA24079 for ; Wed, 28 May 2003 06:23:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19Ky5M-000NlS-00 for v6ops-data@psg.com; Wed, 28 May 2003 10:23:08 +0000 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 19Ky5K-000NlE-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 10:23:07 +0000 Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 351717FD3; Wed, 28 May 2003 12:23:03 +0200 (CEST) From: "Jeroen Massar" To: , Subject: RE: IP version-independent app development guidelines? Date: Wed, 28 May 2003 12:23:02 +0200 Organization: Unfix Message-ID: <000e01c32503$1fac6ff0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20030527221835.F3E2C82@coconut.itojun.org> X-Spam-Status: No, hits=-26.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: > >Along with that draft a good pointer to documents looking like: > > > >Implementing AF-independent application by Jun-ichiro itojun Itoh: > >http://www.kame.net/newsletter/19980604/=20 > >(Mentioned as AF-APP in the References section) > > i wrote a book on the topic: > 'IPv6 network programming', ISBN 4-7561-4236-2 (in japanese) > > i'm negotiating w/ outside-of-japan publishers for english version. > (i wrote it in english) Maybe O'Reilly is a good one? Otherwise I'll just have to learn japanese... (Bye bye spare time that I didn't have already :) hmm www.ascii.co.jp/books/detail/4-7561/4-7561-4236-2.html The example PDF looks promising, I just can't make much out of it :) Greets, Jeroen From owner-v6ops@ops.ietf.org Wed May 28 06:55: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 GAA24491 for ; Wed, 28 May 2003 06:55:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KyaU-0003He-00 for v6ops-data@psg.com; Wed, 28 May 2003 10:55:18 +0000 Received: from mgw-x4.nokia.com ([131.228.20.27]) by psg.com with esmtp (Exim 3.36 #1) id 19KyaR-0003Bd-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 10:55:16 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4SAtDD27108 for ; Wed, 28 May 2003 13:55:14 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 May 2003 13:55:13 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 28 May 2003 13:55:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 3gpp-analysis document and automatic tunneling Date: Wed, 28 May 2003 13:55:05 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F0193CB57@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis document and automatic tunneling Thread-Index: AcMlAWjPw88ahSfQT/Kc98+5WseA7wAAublg From: To: , Cc: , , X-OriginalArrivalTime: 28 May 2003 10:55:07.0655 (UTC) FILETIME=[9A14A970:01C32507] X-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_01,NO_REAL_NAME version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA24491 Hi, Karim and Pekka! In my opinion, the simplest (and most straightforward) way is to use IPv6 PDP context, if you use IPv6 services and use IPv4 PDP context, if you use IPv4 (legacy) services. And that should be the main way, how things are handled. However, it is possible that in the early phases of IPv6 deployment, there is no IPv6-capable GGSN (or SGSN/HLR) in the network (in the home or visited 3gpp network as Karim explained below) and the user still wants to use IPv6 - that's the special case we document in 3.1. I think that the current text "...the UE may activate an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a tunneling mechanism. Tunneling in the UE requires dual stack capability in the UE. ..." is quite good. We can mention some tunneling mechanisms that can be used in that case (informative references), or just mention some dynamic tunneling mechanism alternatives in 2.2, as we do in the current document. Anyway, I feel that we cannot explicitely state, which tunneling mechanism should be used. Cheers, -Juha W.- -----Original Message----- From: ext Karim El-Malki (EAB) [mailto:Karim.El-Malki@era.ericsson.se] Sent: 28 May, 2003 13:06 To: 'Pekka Savola' Cc: Fred L. Templin; Wiljakka Juha (NMP/Tampere); Soininen Jonne (NET/MtView); v6ops@ops.ietf.org Subject: RE: 3gpp-analysis document and automatic tunneling > > > I haven't read the analysis in detail, but the latest > > > Scenarios draft at > > > least *seems* to very explicitly mention that GGSN supports > > > both IPv4 and > > > IPv6. > > > > I am pretty certain that's not what the doc says. > > First, the fact that the GGSN can support IPv6 and IPv4 > routing does > > not mean that it has support for IPv6 native connectivity > to mobile hosts. > > Secondly we cannot guarantee that all GGSNs from all operators > > will support IPv6 at the same time. Some GGSNs will only support > > IPv4 as they do today. > > It seems to that the clear implication from the draft is: > > "If you want IPv4, use an IPv4 GGSN" > "If you want IPv6, use an IPv6 GGSN" > > These do not need to be the same. This seems clearly stated > in Scenarios > sect 3.1 You can't really choose to use one or the other GGSN. You request an IPv6 connection and if it doesn't work you revert to using IPv4 and some automated tunnelling like ISATAP. There are other mechanisms also that I don't think we can exclude yet, which is why at least mentioning the few applicable mechanisms in the draft is important. > > PDP contexts could be opened to different service boxes in a service > provider's network (whichever support IPv6); and if the > service provider > does not support *any* IPv6, the user is on its own *anyway*. > > (of course, the UE could support a transition mechanism > itself but I find > that a bit questionable approach -- the goal is to make 3GPP devices > simple not complex.) My view is very different as you have realised already. I think we need to have transition mechanisms for early v6 introduction stages and special roaming cases which allow the user to access those v6 e.g. peer2peer services even when a v6 pdp context is not available. I've tried it in real networks and a simple mechanism like ISATAP works fine. Anyway we seem not to be taking steps forward with this discussion so I'll stop here. /Karim From owner-v6ops@ops.ietf.org Wed May 28 09:44:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03036 for ; Wed, 28 May 2003 09:44:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L1C5-0006ml-00 for v6ops-data@psg.com; Wed, 28 May 2003 13:42:17 +0000 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 19L1C3-0006mW-00; Wed, 28 May 2003 13:42:15 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA11668; Wed, 28 May 2003 06:41:54 -0700 (PDT) Message-Id: <5.1.0.14.2.20030528092911.04429e68@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 May 2003 09:37:57 -0400 To: Randy Bush , Bert Wijnen From: Margaret Wasserman Subject: Request to Advance "Transition Scenarios for 3GPP Networks" Cc: v6ops@ops.ietf.org, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Randy and Bert, On behalf of the v6ops WG, we request that the following document be published as an Informational RFC: Title : Transition Scenarios for 3GPP Networks Editor : J. Soininen Filename : draft-ietf-v6ops-3gpp-cases-03.txt Date : March 2003 The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-03.txt A working group last call for this document was completed on 2 March 2003, and this draft resolves the issues raised during last call. This document was also reviewed and endorsed by the 3GPP SA2 group in May 2003 and has been endorsed by 3GPP. Thanks, Bob Fink, Pekka Savola and Margaret Wasserman v6ops Working Group Chairs From owner-v6ops@ops.ietf.org Wed May 28 11:16: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 LAA07857 for ; Wed, 28 May 2003 11:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L2bT-000BBW-00 for v6ops-data@psg.com; Wed, 28 May 2003 15:12:35 +0000 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 19L2bQ-000BBK-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 15:12:32 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA27039 for ; Wed, 28 May 2003 08:12:15 -0700 (PDT) Message-Id: <5.1.0.14.2.20030528110217.044149b8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 May 2003 11:04:37 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Re: Accept Unmanaged Analysis Document as WG Draft? In-Reply-To: <5.1.0.14.2.20030514101942.046e4f70@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-12.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Given that the consensus in SF, and the fact that there have been no objections on the list, the following document is now a v6ops work item. http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt Thanks, Christian and the Unmanaged design team. Margaret At 10:26 AM 5/14/2003 -0400, Margaret Wasserman wrote: >Hi All, > >In SF, we had consensus that the analysis document >produced by the Unmanaged Team would serve as a good >starting place for our work, and that we should accept >it as a WG draft. > >The latest version of this document can be found at: > >http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt > > >Unless there are any objections from the mailing list, >I'll ask the Unmanaged Team to publish the next version >as a WG I-D. > >Thanks, >Margaret > > From owner-v6ops@ops.ietf.org Wed May 28 13:19: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 NAA12460 for ; Wed, 28 May 2003 13:19:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L4Yh-000Ktx-00 for v6ops-data@psg.com; Wed, 28 May 2003 17:17:51 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19L4Yb-000Kth-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 17:17:45 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03393; Wed, 28 May 2003 10:17:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4SHHpT23946; Wed, 28 May 2003 10:17:51 -0700 X-mProtect: <200305281717> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtbrfpG; Wed, 28 May 2003 10:17:49 PDT Message-ID: <3ED4E179.7060401@iprg.nokia.com> Date: Wed, 28 May 2003 09:19:05 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: v6ops@ops.ietf.org Subject: Re: Accept Unmanaged Analysis Document as WG Draft? References: <5.1.0.14.2.20030528110217.044149b8@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-36.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Margaret, One comment on the document (perhaps this should go to the authors) is that section 6 needs to add a bullet such as: - To meet case Bprefix sharing requirements, we need a standardized multi-link subnet mechanism Other than that, the document looks good. Fred ftemplin@iprg.nokia.com Margaret Wasserman wrote: > > Given that the consensus in SF, and the fact that there > have been no objections on the list, the following document > is now a v6ops work item. > > http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt > > Thanks, Christian and the Unmanaged design team. > > Margaret > > > At 10:26 AM 5/14/2003 -0400, Margaret Wasserman wrote: > >> Hi All, >> >> In SF, we had consensus that the analysis document >> produced by the Unmanaged Team would serve as a good >> starting place for our work, and that we should accept >> it as a WG draft. >> >> The latest version of this document can be found at: >> >> http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt >> >> >> Unless there are any objections from the mailing list, >> I'll ask the Unmanaged Team to publish the next version >> as a WG I-D. >> >> Thanks, >> Margaret >> >> > > > From owner-v6ops@ops.ietf.org Wed May 28 15:13: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 PAA18371 for ; Wed, 28 May 2003 15:13:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L6Kp-0004Am-00 for v6ops-data@psg.com; Wed, 28 May 2003 19:11:39 +0000 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 19L6Km-0004AY-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 19:11:36 +0000 Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA07651 for ; Wed, 28 May 2003 12:11:19 -0700 (PDT) Message-Id: <5.1.0.14.2.20030528150148.044ebe30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 May 2003 15:07:14 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Document Review Team Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-5.8 required=5.0 tests=BAYES_10 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, As you know, a while back we discussed the formation of a v6ops document review team. Many people volunteered for the team or provided feedback on this idea, for which we thank you. Since our initial discussion, though, the SIRs effort has been initiated to try to build an IETF-wide review process. So, we have decided to place the idea of a v6ops document review team on-hold, until we can determine whether or not the SIRs process will come to fruition. We will let you know when/if we decide to reinitiate this effort. Thanks, Bob Fink, Pekka Savola, Margaret Wasserman v6ops WG chairs From owner-v6ops@ops.ietf.org Wed May 28 16:40: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 QAA22634 for ; Wed, 28 May 2003 16:40:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19L7fb-000DTJ-00 for v6ops-data@psg.com; Wed, 28 May 2003 20:37:11 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19L7fU-000DRH-00 for v6ops@ops.ietf.org; Wed, 28 May 2003 20:37:04 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA14204; Wed, 28 May 2003 13:37:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4SKb2G01338; Wed, 28 May 2003 13:37:02 -0700 X-mProtect: <200305282037> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJz2ixN; Wed, 28 May 2003 13:37:01 PDT Message-ID: <3ED51032.5010100@iprg.nokia.com> Date: Wed, 28 May 2003 12:38:26 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Fred L. Templin" CC: Pekka Savola , "Karim El-Malki (EAB)" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis document and automatic tunneling References: <3ED3A65B.4070005@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-34.8 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Fred L. Templin wrote: > Pekka Savola wrote: > >> ISATAP doesn't allow you you to connect more than a single host. > I think I know now why I was confused by your point on isatap not allowing more than a single host. It is not strictly the case that nodes on an isatap link must use isatap addresses as the source/destination addresses in packets. If there is a way for the isatap router to discover host routes, then nodes on the isatap link can use , e.g., RFC 3041 privacy addresses. In other words, the only addresses that need to be in isatap format are those that appear in the next-hop fields of a node's IPv6 routing table entries. (In many cases, those next-hop addresses could simply be link- local.) As such, a single isatap client can connect many additional hosts. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed May 28 21:03: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 VAA01653 for ; Wed, 28 May 2003 21:03:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LBmB-000Hrn-00 for v6ops-data@psg.com; Thu, 29 May 2003 01:00:15 +0000 Received: from pec.etri.re.kr ([129.254.114.50]) by psg.com with esmtp (Exim 3.36 #1) id 19LBm8-000HrF-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 01:00:13 +0000 Received: from pec.etri.re.kr (mkshin.etri.re.kr [129.254.112.163]) by pec.etri.re.kr (8.11.3/8.11.3) with ESMTP id h4T1CnC14821; Thu, 29 May 2003 10:12:49 +0900 (KST) Message-ID: <3ED55D7F.6DD3FDA9@pec.etri.re.kr> Date: Thu, 29 May 2003 10:08:15 +0900 From: Myung-Ki Shin Organization: ETRI X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: IP version-independent app development guidelines? References: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-28.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-00.txt > > - do you feel this effort is something that we should be working on? > - is this specific draft a good starting point for that work? > - do you have ideas for other approaches which might be more > suitable (in replacement or in addition to it)? > > Obviously the abovementioned draft needs more work if the approach should > be pursued, but it would be nice to get a feel of the working group where > we should go first. I also feel this effort should be working on. Of course, this draft should get a broader view and needs more work. If there is a consensus, I will try to complete this draft (as a starting point). Thanks, Myung-Ki. From owner-v6ops@ops.ietf.org Wed May 28 22:54: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 WAA04055 for ; Wed, 28 May 2003 22:54:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LDXD-000NBE-00 for v6ops-data@psg.com; Thu, 29 May 2003 02:52:55 +0000 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 19LDX7-000NB2-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 02:52:49 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6D40B8397; Wed, 28 May 2003 22:52:48 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 28 May 2003 22:52:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IP version-independent app development guidelines? Date: Wed, 28 May 2003 22:52:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042846A1@tayexc13.americas.cpqcorp.net> Thread-Topic: IP version-independent app development guidelines? Thread-Index: AcMkeKm4Yi34HbhnRRyY25N6v3X6ywBFFKzQ From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 29 May 2003 02:52:48.0250 (UTC) FILETIME=[6343A5A0:01C3258D] X-Spam-Status: No, hits=-6.3 required=5.0 tests=BAYES_20,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA04055 I think this is useful to pursue as work and agree with Eva's caveats from that mail. Richard Stevens book is in process of update too fyi. Just lets not use this to reopen that which has been decided in base and advanced api documents though, as those are being used today now widely. but how to use them operationally. this should not be standards track work either. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, May 27, 2003 1:47 PM > To: v6ops@ops.ietf.org > Subject: IP version-independent app development guidelines? > > > Hello all, > > It seems that one of the charter items of this working group: > > 3. Publish Informational RFCs that help application developers > (within and outside the IETF) understand how to develop IP > version-independent applications. Work with the Applications > area, and other areas, to ensure that these documents answer > the real-world concerns of application developers. This > includes helping to identify IPv4 dependencies in existing > IETF application protocols and working with other areas and/or > groups within the IETF to resolve them. > > has seen little progress. > > Thus, we'd like to solicit input on opinions how to proceed > in this area. > > At least one related individual submission exists in addition to some > outside-of-the-IETF documentation: > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transit ion-00.txt - do you feel this effort is something that we should be working on? - is this specific draft a good starting point for that work? - do you have ideas for other approaches which might be more suitable (in replacement or in addition to it)? Obviously the abovementioned draft needs more work if the approach should be pursued, but it would be nice to get a feel of the working group where we should go first. Thanks for your comments. Pekka, Margaret & Bob From owner-v6ops@ops.ietf.org Thu May 29 00:09:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05907 for ; Thu, 29 May 2003 00:09:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LEiW-0001jV-00 for v6ops-data@psg.com; Thu, 29 May 2003 04:08:40 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19LEiT-0001jG-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 04:08:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4T48RQ08723; Thu, 29 May 2003 07:08:27 +0300 Date: Thu, 29 May 2003 07:08:27 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (EAB)" , , , Subject: Re: 3gpp-analysis document and automatic tunneling In-Reply-To: <3ED51032.5010100@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 28 May 2003, Fred Templin wrote: > > Pekka Savola wrote: > > > >> ISATAP doesn't allow you you to connect more than a single host. > > > I think I know now why I was confused by your point on isatap not > allowing more than a single host. It is not strictly the case that nodes > on an isatap link must use isatap addresses as the source/destination > addresses in packets. If there is a way for the isatap router to discover > host routes, then nodes on the isatap link can use , e.g., RFC 3041 > privacy addresses. > > In other words, the only addresses that need to be in isatap format are > those that appear in the next-hop fields of a node's IPv6 routing table > entries. (In many cases, those next-hop addresses could simply be link- > local.) As such, a single isatap client can connect many additional hosts. Indeed -- but I think this is a rather challenging problem in operator <-> user interface (where it has been proposed in this context), as routing protocol cannot be used. Was your point about ISATAP in general, or did you have some method for host route discovery in mind for this particular case? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu May 29 00:09: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 AAA05922 for ; Thu, 29 May 2003 00:09:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LEgG-0001YM-00 for v6ops-data@psg.com; Thu, 29 May 2003 04:06:20 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19LEgD-0001Y9-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 04:06:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4T464p08711; Thu, 29 May 2003 07:06:04 +0300 Date: Thu, 29 May 2003 07:06:03 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: RE: IP version-independent app development guidelines? In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B042846A1@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 28 May 2003, Bound, Jim wrote: > I think this is useful to pursue as work and agree with Eva's caveats > from that mail. > Richard Stevens book is in process of update too fyi. Ok. > Just lets not use > this to reopen that which has been decided in base and advanced api > documents though, as those are being used today now widely. but how to > use them operationally. this should not be standards track work either. Agree on all points. > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Tuesday, May 27, 2003 1:47 PM > > To: v6ops@ops.ietf.org > > Subject: IP version-independent app development guidelines? > > > > > > Hello all, > > > > It seems that one of the charter items of this working group: > > > > 3. Publish Informational RFCs that help application developers > > (within and outside the IETF) understand how to develop IP > > version-independent applications. Work with the Applications > > area, and other areas, to ensure that these documents answer > > the real-world concerns of application developers. This > > includes helping to identify IPv4 dependencies in existing > > IETF application protocols and working with other areas and/or > > groups within the IETF to resolve them. > > > > has seen little progress. > > > > Thus, we'd like to solicit input on opinions how to proceed > > in this area. > > > > At least one related individual submission exists in addition to some > > outside-of-the-IETF documentation: > > > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transit > ion-00.txt > > - do you feel this effort is something that we should be working on? > - is this specific draft a good starting point for that work? > - do you have ideas for other approaches which might be more > suitable (in replacement or in addition to it)? > > Obviously the abovementioned draft needs more work if the approach > should be pursued, but it would be nice to get a feel of the working > group where we should go first. > > Thanks for your comments. > > Pekka, Margaret & Bob > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu May 29 08: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 IAA29124 for ; Thu, 29 May 2003 08:00:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LM2o-0002uj-00 for v6ops-data@psg.com; Thu, 29 May 2003 11:58:06 +0000 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 19LM2k-0002uD-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 11:58:02 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A9F9B8344; Thu, 29 May 2003 07:58:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 29 May 2003 07:58:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IP version-independent app development guidelines? Date: Thu, 29 May 2003 07:58:01 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B042846AE@tayexc13.americas.cpqcorp.net> Thread-Topic: IP version-independent app development guidelines? Thread-Index: AcMll7UrCdIYtORySie4udIrAIi8GwAQdaRA From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 29 May 2003 11:58:01.0493 (UTC) FILETIME=[8DE06450:01C325D9] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA29124 ack. thanks /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, May 29, 2003 12:06 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: IP version-independent app development guidelines? > > > On Wed, 28 May 2003, Bound, Jim wrote: > > I think this is useful to pursue as work and agree with > Eva's caveats > > from that mail. Richard Stevens book is in process of > update too fyi. > > Ok. > > > Just lets not use > > this to reopen that which has been decided in base and advanced api > > documents though, as those are being used today now widely. > but how > > to use them operationally. this should not be standards track work > > either. > > Agree on all points. > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Tuesday, May 27, 2003 1:47 PM > > > To: v6ops@ops.ietf.org > > > Subject: IP version-independent app development guidelines? > > > > > > > > > Hello all, > > > > > > It seems that one of the charter items of this working group: > > > > > > 3. Publish Informational RFCs that help application developers > > > (within and outside the IETF) understand how to develop IP > > > version-independent applications. Work with the Applications > > > area, and other areas, to ensure that these documents answer > > > the real-world concerns of application developers. This > > > includes helping to identify IPv4 dependencies in existing > > > IETF application protocols and working with other areas and/or > > > groups within the IETF to resolve them. > > > > > > has seen little progress. > > > > > > Thus, we'd like to solicit input on opinions how to proceed > > > in this area. > > > > > > At least one related individual submission exists in addition to > > > some > > > outside-of-the-IETF documentation: > > > > > > http://www.ietf.org/internet-drafts/draft-> shin-v6ops-application-trans > > it > > ion-00.txt > > > > - do you feel this effort is something that we should be > working on? > > - is this specific draft a good starting point for that work? > > - do you have ideas for other approaches which might be more > > suitable (in replacement or in addition to it)? > > > > Obviously the abovementioned draft needs more work if the approach > > should be pursued, but it would be nice to get a feel of > the working > > group where we should go first. > > > > Thanks for your comments. > > > > Pekka, Margaret & Bob > > > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > From owner-v6ops@ops.ietf.org Thu May 29 12:23:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09064 for ; Thu, 29 May 2003 12:23:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LQ7j-000BH3-00 for v6ops-data@psg.com; Thu, 29 May 2003 16:19:27 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19LQ7g-000BGj-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 16:19:24 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA05897; Thu, 29 May 2003 09:19:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4TGJMX04954; Thu, 29 May 2003 09:19:22 -0700 X-mProtect: <200305291619> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqAQH6i; Thu, 29 May 2003 09:19:20 PDT Message-ID: <3ED62552.9070702@iprg.nokia.com> Date: Thu, 29 May 2003 08:20:50 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Karim El-Malki (EAB)" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis document and automatic tunneling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Wed, 28 May 2003, Fred Templin wrote: > > >>>Pekka Savola wrote: >>> >>> >>> >>>>ISATAP doesn't allow you you to connect more than a single host. >>>> >>>> >>I think I know now why I was confused by your point on isatap not >>allowing more than a single host. It is not strictly the case that nodes >>on an isatap link must use isatap addresses as the source/destination >>addresses in packets. If there is a way for the isatap router to discover >>host routes, then nodes on the isatap link can use , e.g., RFC 3041 >>privacy addresses. >> >>In other words, the only addresses that need to be in isatap format are >>those that appear in the next-hop fields of a node's IPv6 routing table >>entries. (In many cases, those next-hop addresses could simply be link- >>local.) As such, a single isatap client can connect many additional hosts. >> >> > >Indeed -- but I think this is a rather challenging problem in operator <-> >user interface (where it has been proposed in this context), as routing >protocol cannot be used. > That's OK. Even better than using a routing protocol is dhcpv6 prefix delegation, with the isatap routers serving as delegating routers. This puts a single /64 into the delegating router's forwarding table instead of a bunch of /128's. >Was your point about ISATAP in general, or did you have some method for >host route discovery in mind for this particular case? > No - my point was that in fact isatap clients can support many hosts (up to 2**64 when prefix delegation is used) contrary to your assertion that only a single host is supported. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu May 29 12:57: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 MAA09970 for ; Thu, 29 May 2003 12:57:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LQhl-000DFL-00 for v6ops-data@psg.com; Thu, 29 May 2003 16:56:41 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19LQhi-000DF9-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 16:56:38 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4TGuUH13548; Thu, 29 May 2003 19:56:30 +0300 Date: Thu, 29 May 2003 19:56:30 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (EAB)" , , , Subject: Re: 3gpp-analysis document and automatic tunneling In-Reply-To: <3ED62552.9070702@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 29 May 2003, Fred Templin wrote: > >>In other words, the only addresses that need to be in isatap format are > >>those that appear in the next-hop fields of a node's IPv6 routing table > >>entries. (In many cases, those next-hop addresses could simply be link- > >>local.) As such, a single isatap client can connect many additional hosts. > >> > >> > > > >Indeed -- but I think this is a rather challenging problem in operator <-> > >user interface (where it has been proposed in this context), as routing > >protocol cannot be used. > > > > That's OK. Even better than using a routing protocol is dhcpv6 prefix > delegation, Careful here: you're proposing to extend ISATAP to be used across multiple administrative boundaries -- which is *specifically* has not meant to be (AFAIR)! > with the isatap routers serving as delegating routers. I assume by "isatap routers" you mean a router supporting ISATAP. > This > puts a single /64 into the delegating router's forwarding table instead > of a bunch of /128's. This seems irrelevant (in practical terms) in itself. -- 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 May 29 13: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 NAA10632 for ; Thu, 29 May 2003 13:11:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LQw3-000E7P-00 for v6ops-data@psg.com; Thu, 29 May 2003 17:11:27 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19LQw0-000E7D-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 17:11:24 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA08591; Thu, 29 May 2003 10:11:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4THBNG18273; Thu, 29 May 2003 10:11:23 -0700 X-mProtect: <200305291711> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwLLmBc; Thu, 29 May 2003 10:11:21 PDT Message-ID: <3ED63183.1020101@iprg.nokia.com> Date: Thu, 29 May 2003 09:12:51 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Karim El-Malki (EAB)" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis document and automatic tunneling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >Careful here: you're proposing to extend ISATAP to be used across multiple >administrative boundaries -- which is *specifically* has not meant to be >(AFAIR)! > Nothing of the sort. The isatap client is within the administrative domain of the isatap router. The isatap router serves a /64 dhcpv6 prefix delegation to the client. The client uses this prefix to connect as many additional hosts as it wishes using, e.g., the multi-link subnet model and RA proxies. It's just like what happens when the GGSN serves a /64 to a mobile via the IPv6 PDP context; it has nothing at all to do with multiple administrative boundaries. Again, the main point is that the isatap client can connect many hosts - not just one. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu May 29 13:29: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 NAA11210 for ; Thu, 29 May 2003 13:29:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LRBw-000FGV-00 for v6ops-data@psg.com; Thu, 29 May 2003 17:27:52 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19LRBs-000FGD-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 17:27:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4THRd513777; Thu, 29 May 2003 20:27:39 +0300 Date: Thu, 29 May 2003 20:27:38 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (EAB)" , , , Subject: Re: 3gpp-analysis document and automatic tunneling In-Reply-To: <3ED63183.1020101@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 29 May 2003, Fred Templin wrote: > Pekka Savola wrote: > > >Careful here: you're proposing to extend ISATAP to be used across multiple > >administrative boundaries -- which is *specifically* has not meant to be > >(AFAIR)! > > > Nothing of the sort. The isatap client is within the administrative > domain of the isatap router. The isatap router serves a /64 dhcpv6 > prefix delegation to the client. The client uses this prefix to connect > as many additional hosts as it wishes using, e.g., the multi-link subnet > model and RA proxies. It's just like what happens when the GGSN serves a > /64 to a mobile via the IPv6 PDP context; it has nothing at all to do > with multiple administrative boundaries. Again, the main point is that > the isatap client can connect many hosts - not just one. Could you describe the scenario in more detail? It seems to me that the approach in above is that ISATAP link-local addresses would be used between the router and the client. The client is in different admin domain as the router (tradeoffs of this might be manageable), as is in a different admin domain as all the other clients (which would also appear to be on the same link). But perhaps I'm missing something here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu May 29 13:46: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 NAA11667 for ; Thu, 29 May 2003 13:46:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LRU4-000GUj-00 for v6ops-data@psg.com; Thu, 29 May 2003 17:46:36 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19LRU0-000GUX-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 17:46:32 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA10247; Thu, 29 May 2003 10:46:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4THkVW23088; Thu, 29 May 2003 10:46:31 -0700 X-mProtect: <200305291746> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5Tuoy9; Thu, 29 May 2003 10:46:29 PDT Message-ID: <3ED64783.10905@iprg.nokia.com> Date: Thu, 29 May 2003 10:46:43 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Karim El-Malki (EAB)" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis document and automatic tunneling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Thu, 29 May 2003, Fred Templin wrote: > > >>Pekka Savola wrote: >> >> >> >>>Careful here: you're proposing to extend ISATAP to be used across multiple >>>administrative boundaries -- which is *specifically* has not meant to be >>>(AFAIR)! >>> >>> >>> >>Nothing of the sort. The isatap client is within the administrative >>domain of the isatap router. The isatap router serves a /64 dhcpv6 >>prefix delegation to the client. The client uses this prefix to connect >>as many additional hosts as it wishes using, e.g., the multi-link subnet >>model and RA proxies. It's just like what happens when the GGSN serves a >>/64 to a mobile via the IPv6 PDP context; it has nothing at all to do >>with multiple administrative boundaries. Again, the main point is that >>the isatap client can connect many hosts - not just one. >> >> > >Could you describe the scenario in more detail? > >It seems to me that the approach in above is that ISATAP link-local >addresses would be used between the router and the client. > In the simplest cases, yes. >The client is >in different admin domain as the router > No. The client gets an RA from the router that contains a non-zero router lifetime and adds it to the default router list. The client is in the same admin domain as the router. >(tradeoffs of this might be >manageable), as is in a different admin domain as all the other clients >(which would also appear to be on the same link). > All the other clients would also be on the same link as the router. Each client can request a dhcpv6 prefix delegation, with the dhcpv6 server implemented on the router as allowed by the specs. Then, each client can connect multiple additional hosts using the prefix delegation it received from the router. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu May 29 14:01: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 OAA12152 for ; Thu, 29 May 2003 14:01:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LRht-000HUH-00 for v6ops-data@psg.com; Thu, 29 May 2003 18:00:53 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19LRhq-000HU4-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 18:00:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4TI0ac14077; Thu, 29 May 2003 21:00:36 +0300 Date: Thu, 29 May 2003 21:00:35 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (EAB)" , , , Subject: Re: 3gpp-analysis document and automatic tunneling In-Reply-To: <3ED64783.10905@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 29 May 2003, Fred Templin wrote: > >The client is > >in different admin domain as the router > > > No. The client gets an RA from the router that contains a non-zero > router lifetime and adds it to the default router list. The client is in > the same admin domain as the router. No. AFAICS, the router belongs to the 3GPP operator. The client belongs to the 3GPP user (user device). Right? These are different entities. Whether RA is used makes no difference. > >(tradeoffs of this might be > >manageable), as is in a different admin domain as all the other clients > >(which would also appear to be on the same link). > > > > All the other clients would also be on the same link as the router. But also on the same link as other clients in the same 3GPP operator (or maybe the particular GGSN), right? In any case, it's *NOT* a point-to-point link between the router and one client, right? > Each > client can request a dhcpv6 prefix delegation, with the dhcpv6 server > implemented on the router as allowed by the specs. Then, each client can > connect multiple additional hosts using the prefix delegation it > received from the router. That much is roughly clear. -- 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 May 29 14: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 OAA12476 for ; Thu, 29 May 2003 14:11:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LRs9-000IAc-00 for v6ops-data@psg.com; Thu, 29 May 2003 18:11:29 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19LRs6-000IAJ-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 18:11:26 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA11869; Thu, 29 May 2003 11:11:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4TIBPI15383; Thu, 29 May 2003 11:11:25 -0700 X-mProtect: <200305291811> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdytCl92; Thu, 29 May 2003 11:11:23 PDT Message-ID: <3ED64D59.8070209@iprg.nokia.com> Date: Thu, 29 May 2003 11:11:37 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Karim El-Malki (EAB)" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis document and automatic tunneling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Thu, 29 May 2003, Fred Templin wrote: > > >>>The client is >>>in different admin domain as the router >>> >>> >>> >>No. The client gets an RA from the router that contains a non-zero >>router lifetime and adds it to the default router list. The client is in >>the same admin domain as the router. >> >> > >No. AFAICS, the router belongs to the 3GPP operator. The client belongs >to the 3GPP user (user device). Right? These are different entities. >Whether RA is used makes no difference. > OK, but there is no difference between this and the model in which the GGSN is serving the mobile a native IPv6 PDP context (i.e., the GGSN belongs to the 3GPP operator and the client belongs to the 3GPP user.) >>>(tradeoffs of this might be >>>manageable), as is in a different admin domain as all the other clients >>>(which would also appear to be on the same link). >>> >>> >>> >>All the other clients would also be on the same link as the router. >> >> > >But also on the same link as other clients in the same 3GPP operator (or >maybe the particular GGSN), right? In any case, it's *NOT* a >point-to-point link between the router and one client, right? > No - it's a multiaccess link just like any other multiaccess link used for IPv6. >>Each >>client can request a dhcpv6 prefix delegation, with the dhcpv6 server >>implemented on the router as allowed by the specs. Then, each client can >>connect multiple additional hosts using the prefix delegation it >>received from the router. >> >> > >That much is roughly clear. > OK. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Thu May 29 14:21:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13002 for ; Thu, 29 May 2003 14:21:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LS1d-000ItK-00 for v6ops-data@psg.com; Thu, 29 May 2003 18:21:17 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 19LS1a-000Irq-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 18:21:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4TIL8P14247; Thu, 29 May 2003 21:21:08 +0300 Date: Thu, 29 May 2003 21:21:07 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Karim El-Malki (EAB)" , , , Subject: Re: 3gpp-analysis document and automatic tunneling In-Reply-To: <3ED64D59.8070209@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 29 May 2003, Fred Templin wrote: > >On Thu, 29 May 2003, Fred Templin wrote: > > > > > >>>The client is > >>>in different admin domain as the router > >>> > >>> > >>> > >>No. The client gets an RA from the router that contains a non-zero > >>router lifetime and adds it to the default router list. The client is in > >>the same admin domain as the router. > >> > >> > > > >No. AFAICS, the router belongs to the 3GPP operator. The client belongs > >to the 3GPP user (user device). Right? These are different entities. > >Whether RA is used makes no difference. > > OK, but there is no difference between this and the model in which the > GGSN is serving the mobile a native IPv6 PDP context (i.e., the GGSN > belongs to the 3GPP operator and the client belongs to the 3GPP user.) Careful: there could be a lot of difference; that is not the original ISATAP model. > >>>(tradeoffs of this might be > >>>manageable), as is in a different admin domain as all the other clients > >>>(which would also appear to be on the same link). > >>> > >>> > >>> > >>All the other clients would also be on the same link as the router. > >> > >> > > > >But also on the same link as other clients in the same 3GPP operator (or > >maybe the particular GGSN), right? In any case, it's *NOT* a > >point-to-point link between the router and one client, right? > > No - it's a multiaccess link just like any other multiaccess link used > for IPv6. Thanks for confirmation. (It isn't 100% clear what you refer to with "No", but I'm assuming the latter sentence.) So, other clients are reachable on the same multiccess link, using link-local addresses. That seems pretty significant to me. All in all, it seems ISATAP is applied in a scenario which it hasn't been originally designed for, but consideration to the differences in scenarios are overlooked. -- 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 May 29 14:54:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14199 for ; Thu, 29 May 2003 14:54:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19LSWt-000L3C-00 for v6ops-data@psg.com; Thu, 29 May 2003 18:53:35 +0000 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 19LSWq-000L1K-00 for v6ops@ops.ietf.org; Thu, 29 May 2003 18:53:32 +0000 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA13896; Thu, 29 May 2003 11:53:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4TIrUm21554; Thu, 29 May 2003 11:53:30 -0700 X-mProtect: <200305291853> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdA72Hra; Thu, 29 May 2003 11:53:28 PDT Message-ID: <3ED65737.6040004@iprg.nokia.com> Date: Thu, 29 May 2003 11:53:43 -0700 From: Fred Templin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Karim El-Malki (EAB)" , juha.wiljakka@nokia.com, Jonne.Soininen@nokia.com, v6ops@ops.ietf.org Subject: Re: 3gpp-analysis document and automatic tunneling References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-25.9 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Thu, 29 May 2003, Fred Templin wrote: > > >>>On Thu, 29 May 2003, Fred Templin wrote: >>> >>> >>> >>> >>>>>The client is >>>>>in different admin domain as the router >>>>> >>>>> >>>>> >>>>> >>>>> >>>>No. The client gets an RA from the router that contains a non-zero >>>>router lifetime and adds it to the default router list. The client is in >>>>the same admin domain as the router. >>>> >>>> >>>> >>>> >>>No. AFAICS, the router belongs to the 3GPP operator. The client belongs >>>to the 3GPP user (user device). Right? These are different entities. >>>Whether RA is used makes no difference. >>> >>> >>OK, but there is no difference between this and the model in which the >>GGSN is serving the mobile a native IPv6 PDP context (i.e., the GGSN >>belongs to the 3GPP operator and the client belongs to the 3GPP user.) >> >> > >Careful: there could be a lot of difference; that is not the original >ISATAP model. > OK. >>>>>(tradeoffs of this might be >>>>>manageable), as is in a different admin domain as all the other clients >>>>>(which would also appear to be on the same link). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>All the other clients would also be on the same link as the router. >>>> >>>> >>>> >>>> >>>But also on the same link as other clients in the same 3GPP operator (or >>>maybe the particular GGSN), right? In any case, it's *NOT* a >>>point-to-point link between the router and one client, right? >>> >>> >>No - it's a multiaccess link just like any other multiaccess link used >>for IPv6. >> >> > >Thanks for confirmation. (It isn't 100% clear what you refer to with >"No", but I'm assuming the latter sentence.) > >So, other clients are reachable on the same multiccess link, using >link-local addresses. That seems pretty significant to me. > >All in all, it seems ISATAP is applied in a scenario which it hasn't been >originally designed for, but consideration to the differences in scenarios >are overlooked. > We are discussing this application for the first time (as far as I can tell), so I believe the term "overlooked" is a bit premature. I believe I have convinced you that there are no functional barriers that keep an isatap client from connecting multiple hosts. I'll grant you that issues in the trust model need to be dealt with in more detail, however. Fred ftemplin@iprg.nokia.com