From owner-v6ops@ops.ietf.org Wed Oct 1 01:40:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02419 for ; Wed, 1 Oct 2003 01:40:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4ZYo-000PUU-50 for v6ops-data@psg.com; Wed, 01 Oct 2003 05:30:02 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.22) id 1A4ZY5-000PRP-Po for v6ops@ops.ietf.org; Wed, 01 Oct 2003 05:29:17 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id D860791; Wed, 1 Oct 2003 14:29:16 +0900 (JST) To: jeroen@unfix.org Cc: v6ops@ops.ietf.org, 6bone@ISI.EDU, bence@darmol.elte.hu Subject: Re: [6bone] Unallocated 2001:248::/32 announced by AS 7675 ? In-Reply-To: Your message of "Mon, 29 Sep 2003 11:06:37 +0200" <00b901c38668$fd8a35c0$210d640a@unfix.org> References: <00b901c38668$fd8a35c0$210d640a@unfix.org> X-Mailer: Cue version 0.6 (030716-1832/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031001052916.D860791@coconut.itojun.org> Date: Wed, 1 Oct 2003 14:29:16 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Status: No, hits=-5.5 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > inet6num: 2001:0200::/23 > netname: APNIC-AP-ALLOCATED-PORTABLES1 > descr: Asia Pacific Network Information Center, Pty. Ltd. > descr: Regional Internet Registry for the Asia-Pacific Region > > This block is *NOT* allocated unless APNIC registry is out of sync: > > 2001:248::/32 3257 2497 2500 7660 9264 2012 7675 IGP > 2001:248::/32 4589 2497 2500 7660 9264 2012 7675 IGP > 2001:248::/32 15516 3257 2497 2500 7660 9264 2012 7675 IGP > 2001:248::/32 25396 1752 6939 6939 9264 2012 7675 IGP > 2001:248::/32 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 12337 3320 5609 9264 2012 7675 IGP > 2001:248::/32 > 6939 6939 9264 2012 7675 IGP > 2001:248::/32 12779 6175 6435 9264 2012 7675 IGP > 2001:248::/32 12902 12859 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 25358 6175 6435 9264 2012 7675 IGP > 2001:248::/32 8758 9044 513 9264 9264 2012 7675 IGP > 2001:248::/32 12859 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 1888 1103 3425 293 6435 9264 2012 7675 IGP > 2001:248::/32 8447 6830 4555 5609 9264 2012 7675 IGP > 2001:248::/32 12634 3265 3549 6939 6939 9264 2012 7675 IGP > 2001:248::/32 12871 8954 4555 5609 9264 2012 7675 IGP > 2001:248::/32 1103 3425 293 6435 9264 2012 7675 > > whois -h whois.nic.ad.jp AS7675 reveals no useful informations though: > > Autonomous System Information: [ASESC$B>pJsESC(B] > a. [ASESC$BHV9fESC(B] 7675 > b. [ASESC$BL>ESC(B] ZEBRA > f. [ESC$BAH?%L>ESC(B] (unknown) > g. [Organization] Digital Magic Labs, Inc. > m. [ESC$B1?MQ@UG$ n. [ESC$B5;=QO"MmC4Ev o. [AS-IN] from AS4691 100 accept ANY > o. [AS-IN] from AS4682 100 accept ANY > o. [AS-IN] from AS7527 100 accept AS7527 > p. [AS-OUT] to AS4691 announce AS7675 > p. [AS-OUT] to AS4682 announce AS7675 > p. [AS-OUT] to AS7527 announce AS7675 > y. [ESC$BDLCN%"%I%l%9ESC(B] > [ESC$B3dEvG/7nF|ESC(B] 1998/04/27 > [ESC$BJV5QG/7nF|ESC(B] > [ESC$B:G=*99?7ESC(B] 1999/06/10 13:50:55 (JST) > ip-alloc@nic.ad.jp > > Anyone having a working contact for this? forwarded it already (ishiguro@ipinfusion.com). itojun From owner-v6ops@ops.ietf.org Wed Oct 1 04:54:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03865 for ; Wed, 1 Oct 2003 04:54:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4ccC-000EKs-84 for v6ops-data@psg.com; Wed, 01 Oct 2003 08:45:44 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.22) id 1A4cab-000E88-EC for v6ops@ops.ietf.org; Wed, 01 Oct 2003 08:44:05 +0000 Received: from fakat.com ([131.115.157.178]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id h918gFmD007686; Wed, 1 Oct 2003 10:42:16 +0200 (CEST) (envelope-from jasko@fakat.com) Message-ID: <3F7A9363.4080704@fakat.com> Date: Wed, 01 Oct 2003 10:42:11 +0200 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Karim El-Malki (HF/EAB)" , "'juha.wiljakka@nokia.com'" , v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Right. Although I would rephrase this: > > I am proposing that the systems either: > > 1) run multiple routing protocol, one for IPv4 and one for IPv6 > (basically, different combinations of OSPFv2|IS-IS and OSPFv3|IS-IS, > excluding RIPv2 and RIPng), or > > 2) run a single routing protocol which includes both IPv4 and IPv6 over > the infrastructure supporting both (basically, IS-IS) > i fail to see why/how this should be discussed/handled within this document. this is something for the isp team to think about and come with solutions. after all, what has been discussed here are small ip backbones and hopefully solutions for those will come out of the isp design team. thus, i suggest completely removing section 3.2.1 or simply referencing to the efforts being done within the isp design team. jasminko From owner-v6ops@ops.ietf.org Wed Oct 1 11:11:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17302 for ; Wed, 1 Oct 2003 11:11:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4iRt-000HDk-Uf for v6ops-data@psg.com; Wed, 01 Oct 2003 14:59:29 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A4iQy-000H7P-35 for v6ops@ops.ietf.org; Wed, 01 Oct 2003 14:58:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16648; Wed, 1 Oct 2003 10:58:24 -0400 (EDT) Message-Id: <200310011458.KAA16648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-routing-02.txt Date: Wed, 01 Oct 2003 10:58:24 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Author(s) : C. Olvera, P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-routing-02.txt Pages : 17 Date : 2003-10-1 This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-routing-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-routing-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-1103429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-routing-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-routing-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1103429.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Oct 1 16:51:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04132 for ; Wed, 1 Oct 2003 16:51:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4nm6-000LGp-WD for v6ops-data@psg.com; Wed, 01 Oct 2003 20:40:42 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.22) id 1A4nlZ-000LCU-SD for v6ops@ops.ietf.org; Wed, 01 Oct 2003 20:40:09 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 28EB14EA0; Wed, 1 Oct 2003 16:40:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 1 Oct 2003 16:40:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Concerning draft-pouffary-v6ops-ent-v6net-04 Date: Wed, 1 Oct 2003 16:40:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E868C9@tayexc13.americas.cpqcorp.net> Thread-Topic: Concerning draft-pouffary-v6ops-ent-v6net-04 Thread-Index: AcNhDwhChMthGxIUSVmGDFEvXCAgjwnR3vCA From: "Bound, Jim" To: "Alan E. Beard" Cc: X-OriginalArrivalTime: 01 Oct 2003 20:40:06.0825 (UTC) FILETIME=[32DD7990:01C3885C] X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Alan, We are updating our doc now from many inputs but want you to know that your input to add why one should care will definitely be in the next release version and your previous input. thanks /jim > -----Original Message----- > From: Alan E. Beard [mailto:aeb1@aebeard.com]=20 > Sent: Tuesday, August 12, 2003 4:19 PM > To: Bound, Jim > Cc: Alan E. Beard; v6ops@ops.ietf.org > Subject: RE: Concerning draft-pouffary-v6ops-ent-v6net-04 >=20 >=20 > Jim: >=20 > First, my apologies for a grossly delayed reply; since IETF=20 > 57 I have been > traveling continuously, and away from email. I'll try to=20 > answer your > queries below, although I know this response is very tardy indeed. >=20 > AEB >=20 > On Fri, 18 Jul 2003, Bound, Jim wrote: >=20 > > Hi Alan, > > > [...] > > Two quesitons to you and the working group. > > > > First one. We have gone back and forth on this work and other=20 > > scenario works if we should put in an IETF doc why a user of this=20 > > should care. I am amoral on this and will go either way. So I ask=20 > > should we explain why this is important to users in this spec and=20 > > other specs? > > > Pekka was kind enough to let me know, gently and courteously,=20 > that I had somewhat misapprehended the target audience for=20 > the draft I reviewed: that draft was intended for the=20 > guidance of the IETF ipv6 Enterprise Network Engineering Team=20 > rather than, as I had imagined, for the Network Engineering=20 > Teams of commercial or public enterprises. Now disabused of=20 > my error, it seems to me that the audience for which this=20 > draft was intended, because they are not in a user=20 > environment, would have little need or use for text which=20 > explains why an end user should care about any of the issues.=20 > However, it does seem a shame to fail to make available to=20 > end user administrative managers and end user network=20 > engineers information which could be of significant=20 > assistance in planning a migration to IPv6, particularly=20 > since the work done so far on the draft is sound in structure=20 > and content. If the completed work is to be made more=20 > generally available (that is, beyond the IPv6 Enterprise=20 > Network Engineering Team), then "why we should care" language=20 > is probably warranted and desirable. >=20 > > Second question is should we target the audience to be the manager,=20 > > admin, and engineer or just one of them. My view is mostly=20 > the admin=20 > > but enough that the engineer knows to go look at the=20 > > solutions/analysis follow on document to the Enterprise scenarios. > > > The draft now contains information which would be of value to=20 > managers, network admins, and network engineers in=20 > commmercial or educational environments. In practice,=20 > documents originating from the IETF are most likely to be=20 > noticed by network engineers, or perhaps by more astute=20 > network admins. However, administrative managers, who are=20 > largely responsible for strategic policy decisions, are=20 > likely to ignore or discount such documents as applicable=20 > only to technical staff unless the document specifically=20 > announces that administrative managers are among the intended=20 > audience. This issue is relate to the response above: if we=20 > intend the final document to see wide distribution in=20 > end-user environments, we should probably specify a wider=20 > target audience (including administrative managers) lest the=20 > document fail to reach the persons who might most benefit=20 > from its counsel. If however, the final document is intended=20 > as internal to the IETF only, we need make no such=20 > enumeration of target audience. >=20 > > thanks > > /jim > > >=20 > The above are my opinions based on observation of the=20 > decision-making processes which frequently exist in=20 > commercial environments. However, I am far from=20 > authoritative on these issues. And I _did_ misapprehend the=20 > target audience for the draft. :-/ What think the rest of the group? >=20 > Regards, >=20 > AEB >=20 > --=20 > Alan E. Beard > AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Oct 2 02:35:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04670 for ; Thu, 2 Oct 2003 02:35:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4wxg-000BCF-Fz for v6ops-data@psg.com; Thu, 02 Oct 2003 06:29:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A4wxA-000BBO-AQ for v6ops@ops.ietf.org; Thu, 02 Oct 2003 06:28:44 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h926SXD06508; Thu, 2 Oct 2003 09:28:33 +0300 Date: Thu, 2 Oct 2003 09:28:33 +0300 (EEST) From: Pekka Savola To: Jasminko Mulahusic cc: "Karim El-Malki (HF/EAB)" , "'juha.wiljakka@nokia.com'" , Subject: Re: 3gpp-analysis-05: Automatic tunneling inside 3GPP operator's network In-Reply-To: <3F7A9363.4080704@fakat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 1 Oct 2003, Jasminko Mulahusic wrote: > > Right. Although I would rephrase this: > > > > I am proposing that the systems either: > > > > 1) run multiple routing protocol, one for IPv4 and one for IPv6 > > (basically, different combinations of OSPFv2|IS-IS and OSPFv3|IS-IS, > > excluding RIPv2 and RIPng), or > > > > 2) run a single routing protocol which includes both IPv4 and IPv6 over > > the infrastructure supporting both (basically, IS-IS) > > > > i fail to see why/how this should be discussed/handled within this > document. this is something for the isp team to think about and come > with solutions. after all, what has been discussed here are small ip > backbones and hopefully solutions for those will come out of the isp > design team. Right.. there's already some text relating to this overlap in the document. > thus, i suggest completely removing section 3.2.1 or simply referencing > to the efforts being done within the isp design team. That would be OK by me .. or if we can come up with a very minimalistic proposal, that's fine too. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Oct 2 02:38: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 CAA04713 for ; Thu, 2 Oct 2003 02:38:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4x4o-000BXC-DF for v6ops-data@psg.com; Thu, 02 Oct 2003 06:36:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A4x4A-000BUW-Os for v6ops@ops.ietf.org; Thu, 02 Oct 2003 06:35:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h926ZAd06622 for ; Thu, 2 Oct 2003 09:35:10 +0300 Date: Thu, 2 Oct 2003 09:35:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: ISATAP security model wrt. 3GPP networks [Re: 3gpp-analysis-05: miscellaneous non-critical issues] In-Reply-To: <3F79B657.9010802@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 30 Sep 2003, Fred Templin wrote: > >Let's try not to get sidetracked too much on ISATAP.. > > Not my intention, but see my brief comments below: [...] Let's continue this thread off-list. -- 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 Oct 2 02:57: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 CAA05139 for ; Thu, 2 Oct 2003 02:56:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A4xMi-000D3W-Jy for v6ops-data@psg.com; Thu, 02 Oct 2003 06:55:08 +0000 Received: from [138.190.3.48] (helo=sbe3777.swissptt.ch) by psg.com with esmtp (Exim 4.22) id 1A4xMC-000D0y-T7 for v6ops@ops.ietf.org; Thu, 02 Oct 2003 06:54:37 +0000 Received: from sxmcmp02.corproot.net (138.190.70.98) by sbe3778.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Thu, 2 Oct 2003 08:54:35 +0200 Received: from sxmbx01.corproot.net ([138.190.70.160]) by sxsmtp01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 08:54:32 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxmbx01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 08:54:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Thu, 2 Oct 2003 08:54:32 +0200 Message-ID: <595362761E89B640A907F5112F8B89B801FBBEC1@sxmbx03.corproot.net> Thread-Topic: 3gpp-analysis-05: miscellaneous non-critical issues Thread-Index: AcOHXAhnfJekR6E2R3Ohr7KKdUhd/gA+CoIQ From: To: , CC: , X-OriginalArrivalTime: 02 Oct 2003 06:54:30.0593 (UTC) FILETIME=[07621310:01C388B2] X-Spam-Status: No, hits=0.7 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > > My point of removing "native or tunneled" is that because > > > there should not=20 > > > be any (or close to any) tunneled connectivity (from the UE)=20 > > > in the first=20 > > > place, pointing it out here is irrelevant. > >=20 > > What leads you to this conclusion? Do you have practical experience=20 > > that leads you to this view? I have practical experience of this=20 > > tunneled service in real mobile networks that proves the=20 > opposite of=20 > > what you are saying. I can see that you are expressing a strong=20 > > opinion but I have not read and cannot see a reason for it=20 > from what I=20 > > know about IPv6 in mobile networks. >=20 > I don't have a lot of experience in 3GPP networks (obviously), but=20 > discussing these issues with some folks who have (e.g. from=20 > Nokia), there=20 > seem to be a huge distinction on what you're saying and what=20 > others are=20 > saying. Well, let's add a comment from an operator here... Here are some facts: - Today's 2.5/3G networks are running on IPv4. - Today's economic situation is quite difficult. - Nobody operating a network wants to touch a running system if not absolutely necessary. It is therefore very much needed to think about a phased introduction of IPv6. It is just _not_ realistic to think of a direct move from IPv4 to native IPv6 - let's make this clear here! Operators _need_ mechanisms to introduce IPv6 in phases. A first phase should be fully non-intrusive, cheap but still secure. Tunneling from the UE (e.g. using ISATAP) seems to perfectly be suited to meet these requirements.=20 I expect the v6ops WG to write guidelines that help the operators in the introduction of IPv6 in their networks. Such guidelines just have to consider a phased introduction. Everything else is just not realistic and not of use for operators. I am looking forward to such documents from this group. Regards Andreas >=20 > > There is always a starting point for the > > introduction of IPv6 and we must consider this case. >=20 > Introduction of IPv6 works fine in the operator's own=20 > network. It works=20 > fine if the user is satisfied with only v4 when he goes=20 > abroad and the=20 > roaming partner doesn't support v6, etc. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Oct 2 07:44: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 HAA13158 for ; Thu, 2 Oct 2003 07:44:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A51mH-00029m-Pu for v6ops-data@psg.com; Thu, 02 Oct 2003 11:37:49 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A51kM-00022Q-BD for v6ops@ops.ietf.org; Thu, 02 Oct 2003 11:35:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12940; Thu, 2 Oct 2003 07:35:41 -0400 (EDT) Message-Id: <200310021135.HAA12940@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-trans-02.txt Date: Thu, 02 Oct 2003 07:35:41 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-trans-02.txt Pages : 0 Date : 2003-10-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-trans-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-1115102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-trans-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1115102.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 2 07:44: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 HAA13188 for ; Thu, 2 Oct 2003 07:44:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A51kd-00023O-Rf for v6ops-data@psg.com; Thu, 02 Oct 2003 11:36:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A51k8-00020P-9t for v6ops@ops.ietf.org; Thu, 02 Oct 2003 11:35:36 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12883; Thu, 2 Oct 2003 07:35:28 -0400 (EDT) Message-Id: <200310021135.HAA12883@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-intro-04.txt Date: Thu, 02 Oct 2003 07:35:27 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-intro-04.txt Pages : 0 Date : 2003-10-1 This document is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in currently deployed IETF documented standards. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which type of RFCs that has been documented, and a concatenated summary of results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-intro-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-04.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-10-1114957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-intro-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-intro-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1114957.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 2 07:45: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 HAA13216 for ; Thu, 2 Oct 2003 07:45:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A51lA-00026b-IF for v6ops-data@psg.com; Thu, 02 Oct 2003 11:36:40 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A51kG-00022H-Vq for v6ops@ops.ietf.org; Thu, 02 Oct 2003 11:35:45 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12924; Thu, 2 Oct 2003 07:35:36 -0400 (EDT) Message-Id: <200310021135.HAA12924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-subip-03.txt Date: Thu, 02 Oct 2003 07:35:36 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-subip-03.txt Pages : 0 Date : 2003-10-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-subip-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-1115032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-subip-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-subip-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1115032.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 2 07:45: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 HAA13233 for ; Thu, 2 Oct 2003 07:45:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A51lk-00027Q-ID for v6ops-data@psg.com; Thu, 02 Oct 2003 11:37:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A51kC-00021s-55 for v6ops@ops.ietf.org; Thu, 02 Oct 2003 11:35:40 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12899; Thu, 2 Oct 2003 07:35:31 -0400 (EDT) Message-Id: <200310021135.HAA12899@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-sec-02.txt Date: Thu, 02 Oct 2003 07:35:31 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-sec-02.txt Pages : 0 Date : 2003-10-1 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Sandards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-sec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-1115020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-sec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-sec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-1115020.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 2 08:51:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16692 for ; Thu, 2 Oct 2003 08:51:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A52sZ-000745-Ou for v6ops-data@psg.com; Thu, 02 Oct 2003 12:48:23 +0000 Received: from [81.226.50.80] (helo=lord.fakat.com) by psg.com with esmtp (Exim 4.22) id 1A52s3-00072O-Fb for v6ops@ops.ietf.org; Thu, 02 Oct 2003 12:47:51 +0000 Received: from fakat.com ([131.115.157.178]) by lord.fakat.com (8.12.10/8.12.8) with ESMTP id h92ClHEO011896; Thu, 2 Oct 2003 14:47:17 +0200 (CEST) (envelope-from jasko@fakat.com) Message-ID: <3F7C1E4D.9010802@fakat.com> Date: Thu, 02 Oct 2003 14:47:09 +0200 From: Jasminko Mulahusic User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andreas.Schmid1@swisscom.com CC: v6ops@ops.ietf.org Subject: Re: 3gpp-analysis-05: miscellaneous non-critical issues References: <595362761E89B640A907F5112F8B89B801FBBEC1@sxmbx03.corproot.net> In-Reply-To: <595362761E89B640A907F5112F8B89B801FBBEC1@sxmbx03.corproot.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.7 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Operators _need_ mechanisms to introduce IPv6 in phases. A first phase > should be fully non-intrusive, cheap but still secure. Tunneling from > the UE (e.g. using ISATAP) seems to perfectly be suited to meet these > requirements. > not clear to me at all how tunneling is cheaper and more secure than introducing native v6 for this particular environment. if you would care to educate me off list, i am all ears. jasminko From owner-v6ops@ops.ietf.org Thu Oct 2 08:52: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 IAA16708 for ; Thu, 2 Oct 2003 08:52:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A52qv-0006wm-0g for v6ops-data@psg.com; Thu, 02 Oct 2003 12:46:41 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.22) id 1A52q1-0006s3-9H for v6ops@ops.ietf.org; Thu, 02 Oct 2003 12:45:45 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h92Cjh600353 for ; Thu, 2 Oct 2003 15:45:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 Oct 2003 15:45:43 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 2 Oct 2003 15:45:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Thu, 2 Oct 2003 15:45:43 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDF0F@esebe005.ntc.nokia.com> Thread-Topic: 3gpp-analysis-05: miscellaneous non-critical issues Thread-Index: AcOHXAhnfJekR6E2R3Ohr7KKdUhd/gA+CoIQACLWsGA= From: To: , , Cc: X-OriginalArrivalTime: 02 Oct 2003 12:45:43.0577 (UTC) FILETIME=[17DC4090:01C388E3] X-Spam-Status: No, hits=2.0 required=5.0 tests=NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Andreas, I'm glad to get more operator comments on the v6ops mailing list; thanks = for your comments! Some short replies below. -----Original Message----- From: ext [mailto:Andreas.Schmid1@swisscom.com] Sent: 02 October, 2003 09:55 Well, let's add a comment from an operator here... Here are some facts: - Today's 2.5/3G networks are running on IPv4. - Today's economic situation is quite difficult. - Nobody operating a network wants to touch a running system if not absolutely necessary. It is therefore very much needed to think about a phased introduction of IPv6. It is just _not_ realistic to think of a direct move from IPv4 to native IPv6 - let's make this clear here! Operators _need_ mechanisms to introduce IPv6 in phases. A first phase should be fully non-intrusive, cheap but still secure. Tunneling from the UE (e.g. using ISATAP) seems to perfectly be suited to meet these requirements.=20 I expect the v6ops WG to write guidelines that help the operators in the introduction of IPv6 in their networks. Such guidelines just have to consider a phased introduction. Everything else is just not realistic and not of use for operators. I am looking forward to such documents from this group. JW: I know that the current situation is not an easy one. And I fully = agree that the principle of phased IPv6 induction is correct. I can also see that IPv6 can be tested / demonstrated etc. using = tunneling in the UE. But putting basic IPv6 support in the GPRS network = is not that difficult. IPv6 support in a GPRS nw includes (at least) the = following points: * Upgrading (a) GGSN to support IPv6 PDP contexts (that basically means = dual stack support in the GGSN). This is only needed on the "upper IP = layer" / user layer in the 3GPP architecture. Network layer (below GTP = tunnels) can still be IPv4. See RFC3314, Figure 2. * SGSN should support IPv6 PDP context signalling (especially if = charging is considered..), i.e. it must be possible to activate an IPv6 = PDP context. * HLR support for IPv6 * IPv6 Access Point Names should also be configured to the packet core = DNS * you also might want to put up a (configured) IPv6-in-IPv4 tunnel from = the GGSN e.g. to the IPv6 island (can be in the operator's network or = elsewhere) that provides IPv6 services * IPv6 capable firewall can also be considered According to my current understanding, the above does not require big = investments and in many cases software upgrades are sufficient. Furthermore, introducing (some) IPv6 support in the network does not = cause problems with the current IPv4 network, i.e. IPv6 can be run = simultaneously without disrupting IPv4 traffic! This is not a = 3GPP-specific thing; this is one of the good sides of the dual stack = deployment. There is no need to immediately move from native IPv4 to = native IPv6 support in the cellular networks. Best Regards,=20 -Juha W.- From owner-v6ops@ops.ietf.org Thu Oct 2 09:30:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18402 for ; Thu, 2 Oct 2003 09:30:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A53V3-0009i8-Pi for v6ops-data@psg.com; Thu, 02 Oct 2003 13:28:09 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A53UW-0009f8-SW for v6ops@ops.ietf.org; Thu, 02 Oct 2003 13:27:36 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J44YW>; Thu, 2 Oct 2003 09:27:35 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D73@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" , Soliman Hesham Cc: "Karim El-Malki (HF/EAB)" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Thu, 2 Oct 2003 09:27: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=0.0 required=5.0 tests=none version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > => I didn't ask to have "don't tunnel from the UE" > > in the text. I was commenting on the new text. > > I don't think the draft should include opinions on how > > easy it is to upgrade to V6 and whether that involves > > SW or HW upgrades. It's not useful. > > It seems very useful to me, although the wording may not be > optimal. If > upgrading to v6 is relatively easy, we can recommend > upgrading to IPv6. => I'm afraid that we cannot make a general assessment here of how "easy" it is to upgrade to v6. Leave it to the operators because we have no "one statement fits all". As a general comment. I'd like to minimise opinions in IETF specs and keep it concrete and straight forward. If operators think it's easy to upgrade, I'm sure they will do what they need to do. Putting it in the draft will not "make them believe". > > That's > > > also expected to happen during the early phases of > > > transition. If the > > > operator doesn't care about IPv6 users at all, the users can > > > just stay out > > > of those networks. > > > > => The point is: Your operator cares about v6 and wants > > to offer you the services that IPv6 enables > > Right so far.. > > > while you're > > roaming. > > If your SP wants to enable services while you're roaming, > your SP needs to > convince those networks it has roaming agreements with to enable v6? => No way... What's the incentive for another operator to do that? Even if this is possible. I think we should refrain from anticipating business dealings that do not exist. We should handle the technology part and let operators run their business. On this note, please see the note from Andreas Schmidt (Swisscom) on the need for tunneling in the early days of IPv6. > > > It is not relevant how the visited operator feels > > about v6. > > I fear this is very relevant. Your home operator can't > really offer what > it can't provide. So, it should not *guarantee* you IPv6 > services while > you roam, as simple as that.. => Well, it can when tunneling is used. But you seem to say that it "shouldn't", despite the fact that it can. > > But the point is, > > requiring an operator to support v6 will not necessarily > > eliminate tunneling when the UE roams to another network > > (whose managers don't want to support v6 and will implement > > v6ops recommendations). > > So, don't use v6 in those networks then? => Unless you provide a serious reason we can't support this suggestion, especially when there are ways of achieving this. > > => But in this case the visited network doesn't care about > > v6. I'm not sure how eliminating the use of V6 through > > a tunnel will give the visited network an incentive to > > deploy v6. > > For example, if the customers select a different operator > when they roam > because the one they tried first doesn't support v6 > ("v4-only operator > loses customers and thus money"), I guess the operator which didn't > support v6 would start to see some benefit in deploying v6 > if the number > of users warrants that. There could also be some PR > gains/losses involved > here. => I just can't relate this to what's happening today. This is really speculative and I prefer to keep the draft technical and concrete. The draft doesn't mandate tunnelling but it doesn't discount it either. I don't see any good reasons for discounting it. If people think it's too complex (I don't) then they won't implement it or deploy it. This is not our call though. This is up to vendors and operators to choose. Hesham From owner-v6ops@ops.ietf.org Thu Oct 2 10:40: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 KAA22400 for ; Thu, 2 Oct 2003 10:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A54W8-000E3f-LK for v6ops-data@psg.com; Thu, 02 Oct 2003 14:33:20 +0000 Received: from [138.190.3.49] (helo=sbe3778.swissptt.ch) by psg.com with esmtp (Exim 4.22) id 1A54V6-000Dz2-Mo for v6ops@ops.ietf.org; Thu, 02 Oct 2003 14:32:16 +0000 Received: from sxmcmp01.corproot.net (138.190.70.99) by sbe3777.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Thu, 2 Oct 2003 16:32:14 +0200 Received: from sxmbx01.corproot.net ([138.190.70.160]) by sxsmtp01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 16:31:16 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxmbx01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 2 Oct 2003 16:31:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Thu, 2 Oct 2003 16:31:16 +0200 Message-ID: <595362761E89B640A907F5112F8B89B80179BFF4@sxmbx03.corproot.net> Thread-Topic: 3gpp-analysis-05: miscellaneous non-critical issues Thread-Index: AcOHXAhnfJekR6E2R3Ohr7KKdUhd/gA+CoIQACLWsGAABDBHAA== From: To: , , CC: X-OriginalArrivalTime: 02 Oct 2003 14:31:17.0268 (UTC) FILETIME=[D708CD40:01C388F1] X-Spam-Status: No, hits=0.7 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Well, let's add a comment from an operator here... >=20 > Here are some facts: > - Today's 2.5/3G networks are running on IPv4. > - Today's economic situation is quite difficult. > - Nobody operating a network wants to touch a running system=20 > if not absolutely necessary. >=20 > It is therefore very much needed to think about a phased=20 > introduction of IPv6. It is just _not_ realistic to think of=20 > a direct move from IPv4 to native IPv6 - let's make this clear here! >=20 > Operators _need_ mechanisms to introduce IPv6 in phases. A=20 > first phase should be fully non-intrusive, cheap but still=20 > secure. Tunneling from the UE (e.g. using ISATAP) seems to=20 > perfectly be suited to meet these requirements.=20 >=20 > I expect the v6ops WG to write guidelines that help the=20 > operators in the introduction of IPv6 in their networks. Such=20 > guidelines just have to consider a phased introduction.=20 > Everything else is just not realistic and not of use for=20 > operators. I am looking forward to such documents from this group. >=20 > JW: I know that the current situation is not an easy one. And=20 > I fully agree that the principle of phased IPv6 induction is correct. >=20 > I can also see that IPv6 can be tested / demonstrated etc.=20 > using tunneling in the UE. But putting basic IPv6 support in=20 > the GPRS network is not that difficult. IPv6 support in a=20 > GPRS nw includes (at least) the following points: >=20 > * Upgrading (a) GGSN to support IPv6 PDP contexts (that=20 > basically means dual stack support in the GGSN). This is only=20 > needed on the "upper IP layer" / user layer in the 3GPP=20 > architecture. Network layer (below GTP tunnels) can still be=20 > IPv4. See RFC3314, Figure 2. > * SGSN should support IPv6 PDP context signalling (especially=20 > if charging is considered..), i.e. it must be possible to=20 > activate an IPv6 PDP context. > * HLR support for IPv6 > * IPv6 Access Point Names should also be configured to the=20 > packet core DNS > * you also might want to put up a (configured) IPv6-in-IPv4=20 > tunnel from the GGSN e.g. to the IPv6 island (can be in the=20 > operator's network or elsewhere) that provides IPv6 services > * IPv6 capable firewall can also be considered Thanks for that. However, we know what is needed. We run extensive tests in our R&D site for years. But the transfer to the operating unit is much easier if the running systems is just not touched at all. >=20 > According to my current understanding, the above does not=20 > require big investments and in many cases software upgrades=20 > are sufficient. It's not about investments. It's about touching the running system. People do not trust IPv6 at the moment. Tunneling is a way to show them what could be done in a very inexpensive and easy way. >=20 > Furthermore, introducing (some) IPv6 support in the network=20 > does not cause problems with the current IPv4 network, i.e.=20 > IPv6 can be run simultaneously without disrupting IPv4=20 > traffic! This is not a 3GPP-specific thing; this is one of=20 > the good sides of the dual stack deployment. There is no need=20 > to immediately move from native IPv4 to native IPv6 support=20 > in the cellular networks. Of course, still you have to touch the running system. Operating people don't like that. One of the hidden problem might be that IPv6 testing had been done mainly in the R&D site. These guys know what it is all about and have enough trust to implement it. The operations guys have to go through this step first.=20 Regards Andreas >=20 > Best Regards,=20 > -Juha W.- >=20 From owner-v6ops@ops.ietf.org Thu Oct 2 10:48:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22759 for ; Thu, 2 Oct 2003 10:48:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A54he-000F1C-OA for v6ops-data@psg.com; Thu, 02 Oct 2003 14:45:14 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A54gd-000EvK-3B for v6ops@ops.ietf.org; Thu, 02 Oct 2003 14:44:11 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J4V17>; Thu, 2 Oct 2003 10:44:11 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D74@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alain Durand'" Cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: 3GPP Analysis Document Date: Thu, 2 Oct 2003 10:43:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > 2- No transition mechanism on the UE > > (no tunelling, no translation on the UE) > This is one of the main recommendation. The philosophy > here is to say, those are new devices and new networks, > so we can put the burden of transition on the network itself > to make the devices simpler/more reliable. > > I think this tradeoff is right but should be discussed more clearly > in the document. => I think tunnelling from the UE is a useful thing for roaming nodes at least. We already saw that some operators are agreeing with this. So, I don't think we should have strong statements that completely discount tunnelling. > 3- Dual stack vs IPv6-only UE > > This is the other key recommendation. The tradeoffs should > be discussed > more: > > - v6only device: easier to build/manage. Require all > services to be v6 > ready. > If the supported "legacy" services are limited to > web/mail, they can > be easily proxied, > if not, the situation is more complex. > > - dual stack: require management of 2 networks (v4&v6) > The philosophy is that "legacy" applications keep using v4 > for the foreseeable future and new applications requiring > end-to-end connectivity (peer2peer & friends) will use v6 > This second scenario is somehow what we see hapening > on the "classic" non 3GPP internet. > In that scenario, if someone want to participate in the new > applications requiring end to end, they upgrade as transparently > as they can to v6. This is what we are seeing with > Microsoft three > degree. => Agreed. > > So, IMHO recommending dual stack UE for now sound reasonable > but in these tradeoffs should be discussed more clearly. => The dual stack is the recommended approach. Perhaps more analysis would make that more justified. > 3- Seamless connectivity with IPv4 legacy node. > > For 'traditional' applications, if we recommend the dual > stack approach, > this is not needed. > > The point that is really specific to 3GPP is that 3GPP chose to > mandate that the IMS is IPv6 only. > > Trying to achieve seamless connectivity between v6-only nodes > and legacy v4 nodes for those applications requiring end-to-end > IP connectivity seems to me a non starter. If this was possible > to make this work and scale, there will be no need for > IPv6, period. => Hmm. It's not meant to really scale, more below. > > The analysis document is making the point that: > "It is assumed that the solution described here is used > for limited > cases, in which > communications with a small number of legacy IPv4 SIP > equipment are > needed." > However, this claim is not substanciated. > If it is the case that such communications are only required in > limited environments, > why not recommending that those environments upgrade to v6? => I'd love to do that. However, how does this happen in practice? Let's say 3GPP went with IPv6 only and 3GPP2 did dual stack or IPv4 only for their IMS. And let's say that some operators decide to enable IPv4 only in their 3GPP2 networks, or in their fixed broadband networks. Now a 3GPP operator has three options: 1. Tell the others to upgrade to v6 2. Tell its subscribers that they can't contact certain networks. 3. Provide a mechanism that allows subscribers to talk to those v4 only people. 1) is unrealistic. If it can be done, then why hasn't it been done already? 2) doesn't seem realistic either from a commercial point of view. Hesham From owner-v6ops@ops.ietf.org Thu Oct 2 10:53: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 KAA23471 for ; Thu, 2 Oct 2003 10:53:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A54nr-000Fm7-88 for v6ops-data@psg.com; Thu, 02 Oct 2003 14:51:39 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.22) id 1A54n3-000Ff5-T6 for v6ops@ops.ietf.org; Thu, 02 Oct 2003 14:50:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23193; Thu, 2 Oct 2003 10:50:37 -0400 (EDT) Message-Id: <200310021450.KAA23193@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-ops-03.txt Date: Thu, 02 Oct 2003 10:50:37 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-ops-03.txt Pages : 0 Date : 2003-10-2 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Operations & Management Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-ops-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-2105913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-ops-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-ops-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2105913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 2 14:31: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 OAA18781 for ; Thu, 2 Oct 2003 14:31:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A584o-0006LQ-Q8 for v6ops-data@psg.com; Thu, 02 Oct 2003 18:21:22 +0000 Received: from [209.128.95.10] (helo=smtpout1.bayarea.net) by psg.com with esmtp (Exim 4.22) id 1A583n-0006GJ-Aq; Thu, 02 Oct 2003 18:20:19 +0000 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.8/8.12.8) with ESMTP id h92IQXYV000768; Thu, 2 Oct 2003 11:26:33 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h92IKGo23577; Thu, 2 Oct 2003 11:20:16 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 2 Oct 2003 11:20:15 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: v6ops@ops.ietf.org cc: ops-area@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-v6ops-ipv4survey-ops-03.txt In-Reply-To: <200310021450.KAA23193@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE, X_AUTH_WARNING version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 2 Oct 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > IPv6 Operations Working Group of the IETF. > > Title : Survey of IPv4 Addresses in Currently Deployed IETF > Operations & Management Area Standards > Author(s) : P. Nesser II, A. Bergstrom > Filename : draft-ietf-v6ops-ipv4survey-ops-03.txt > Pages : 0 > Date : 2003-10-2 ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-03.txt I won't have time to do a second complete review of this document, so I would suggest that any OPS area experts who can should read it over. I did notice a couple of small things: - the sub-section headings in Section 3 need to be renumbered. - the text for RFCs 2665 and 2668 could be improved a bit (apologies to the author for not catching this earlier). Here are the suggestions. In this section: | 5.073 RFC 2665 Definitions of Managed Objects for the | Ethernet-like Interface Types | | There are no IPv4 dependencies in this specification. | | Note that this specification is Obsoleted. s/is Obsoleted/has been replaced by RFC 3635/ In this section: | 5.075 RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium | Attachment Units (MAUs) | | There are no IPv4 dependencies in this specification. add the following sentence: + Note that this specification has been replaced by RFC 3636. Alternatively, the document could just refer to 3635 and 3636. It's not terribly important either way because there are no IPv4 dependencies to confront. //cmh From owner-v6ops@ops.ietf.org Thu Oct 2 14:48:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19413 for ; Thu, 2 Oct 2003 14:48:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A58SA-0008JY-8u for v6ops-data@psg.com; Thu, 02 Oct 2003 18:45:30 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.22) id 1A58Re-0008GQ-BP for v6ops@ops.ietf.org; Thu, 02 Oct 2003 18:44:58 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h92Iivkv011970 for ; Thu, 2 Oct 2003 12:44:58 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HM5005H382XMI@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 02 Oct 2003 12:44:57 -0600 (MDT) Received: from sun.com ([129.146.11.160]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HM50018182WNM@mail.sun.net> for v6ops@ops.ietf.org; Thu, 02 Oct 2003 12:44:57 -0600 (MDT) Date: Thu, 02 Oct 2003 11:44:56 -0700 From: Alain Durand Subject: Re: WG Last Call: 3GPP Analysis Document To: Soliman Hesham Cc: v6ops@ops.ietf.org Message-id: <3F7C7228.3080500@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <748C6D0A58C0F94CA63C198B6674697A01922D74@ftmail.lab.flarion.com> X-Spam-Status: No, hits=-0.9 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Soliman Hesham wrote: > > Trying to achieve seamless connectivity between v6-only nodes > > and legacy v4 nodes for those applications requiring end-to-end > > IP connectivity seems to me a non starter. If this was possible > > to make this work and scale, there will be no need for > > IPv6, period. > >=> Hmm. It's not meant to really scale, more below. > > > > > > The analysis document is making the point that: > > "It is assumed that the solution described here is used > > for limited > > cases, in which > > communications with a small number of legacy IPv4 SIP > > equipment are > > needed." > > However, this claim is not substanciated. > > If it is the case that such communications are only required in > > limited environments, > > why not recommending that those environments upgrade to v6? > >=> I'd love to do that. However, how does this happen in >practice? Let's say 3GPP went with IPv6 only and 3GPP2 >did dual stack or IPv4 only for their IMS. And let's >say that some operators decide to enable IPv4 only >in their 3GPP2 networks, or in their fixed broadband >networks. Now a 3GPP operator has three options: > >1. Tell the others to upgrade to v6 >2. Tell its subscribers that they can't contact certain > networks. >3. Provide a mechanism that allows subscribers to talk > to those v4 only people. > >1) is unrealistic. If it can be done, then why hasn't >it been done already? 2) doesn't seem realistic either >from a commercial point of view > I'm a bit confused here. The voice communication using standard technology would still work fine, right? So, this is only the value-added services, SIP-driven that won't work between 3GPP & 3GPP2, right? So, are you not trying to solve a social problem here instead of a technical one? Also, if this is the scenario that you are trying to solve, as 3GPP & 3GPP2 are targeting very large deployment, I have a hard time to undestand your comment: "It's not meant to really scale" - Alain. From owner-v6ops@ops.ietf.org Fri Oct 3 02:07: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 CAA18237 for ; Fri, 3 Oct 2003 02:07:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Iy9-000MDD-9a for v6ops-data@psg.com; Fri, 03 Oct 2003 05:59:13 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A5Ixc-000MAC-OL for v6ops@ops.ietf.org; Fri, 03 Oct 2003 05:58:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h935wVN24444; Fri, 3 Oct 2003 08:58:31 +0300 Date: Fri, 3 Oct 2003 08:58:31 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "'Alain Durand'" , Subject: 3GPP v6-only IMS [RE: WG Last Call: 3GPP Analysis Document] In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D74@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 2 Oct 2003, Soliman Hesham wrote: [...] > => I'd love to do that. However, how does this happen in > practice? Let's say 3GPP went with IPv6 only and 3GPP2 > did dual stack or IPv4 only for their IMS. And let's > say that some operators decide to enable IPv4 only > in their 3GPP2 networks, or in their fixed broadband networks. > Now a 3GPP operator has three options: > > 1. Tell the others to upgrade to v6 > 2. Tell its subscribers that they can't contact certain > networks. > 3. Provide a mechanism that allows subscribers to talk > to those v4 only people. > > 1) is unrealistic. If it can be done, then why hasn't > it been done already? 2) doesn't seem realistic either > from a commercial point of view. If 3GPP2 would deliberately choose to build a non-interopreable network, would it be 3GPP's fault? The only _realistic_ choices for 3GPP2 would seem to be IPv6-only or dual-stack. And in both cases, there would be a common protocol, IPv6 -- no problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 3 02:14: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 CAA22994 for ; Fri, 3 Oct 2003 02:14:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5JBa-000Mqk-8l for v6ops-data@psg.com; Fri, 03 Oct 2003 06:13:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A5JB4-000Mos-52 for v6ops@ops.ietf.org; Fri, 03 Oct 2003 06:12:34 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h936CMN24583; Fri, 3 Oct 2003 09:12:22 +0300 Date: Fri, 3 Oct 2003 09:12:22 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "Karim El-Malki (HF/EAB)" , , Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D73@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 2 Oct 2003, Soliman Hesham wrote: > > > => I didn't ask to have "don't tunnel from the UE" > > > in the text. I was commenting on the new text. > > > I don't think the draft should include opinions on how > > > easy it is to upgrade to V6 and whether that involves > > > SW or HW upgrades. It's not useful. > > > > It seems very useful to me, although the wording may not be > > optimal. If > > upgrading to v6 is relatively easy, we can recommend > > upgrading to IPv6. > > => I'm afraid that we cannot make a general assessment > here of how "easy" it is to upgrade to v6. Leave it to > the operators because we have no "one statement fits all". > As a general comment. I'd like to minimise opinions in > IETF specs and keep it concrete and straight forward. > > If operators think it's easy to upgrade, I'm sure they > will do what they need to do. Putting it in the draft > will not "make them believe". I think this is not true at all. Remember that we're not specifying a protocol here .. but giving recommendations on deployment. We can, and should, "make them believe". Education is one important part of the solutions specs. > > > That's > > > > also expected to happen during the early phases of > > > > transition. If the > > > > operator doesn't care about IPv6 users at all, the users can > > > > just stay out > > > > of those networks. > > > > > > => The point is: Your operator cares about v6 and wants > > > to offer you the services that IPv6 enables > > > > Right so far.. > > > > > while you're > > > roaming. > > > > If your SP wants to enable services while you're roaming, > > your SP needs to > > convince those networks it has roaming agreements with to enable v6? > > => No way... What's the incentive for another operator to do that? Not to lose money from the customers it would bring, simple as that. > Even if this is possible. I think we should refrain from > anticipating business dealings that do not exist. > We should handle the technology part and let operators > run their business. > > On this note, please see the note from Andreas Schmidt > (Swisscom) on the need for tunneling in the early days of > IPv6. Tunneling inside the operator, a completely different beast than roaming.. > > > It is not relevant how the visited operator feels > > > about v6. > > > > I fear this is very relevant. Your home operator can't > > really offer what > > it can't provide. So, it should not *guarantee* you IPv6 > > services while > > you roam, as simple as that.. > > => Well, it can when tunneling is used. But you seem > to say that it "shouldn't", despite the fact that it > can. Yeah, it *could* provide a service, if we recommend a tunneling mechanism (or multiple ones) to be implemented in all UE's. If it isn't implemented in all UE's it's not going to fly. So, we have to balance whether we want the transition mechanism at the UE, or not; and which kind of transition mechanism it would be (i.e., whether there would be any problems in that). Configured tunneling could be acceptable to me _in the roaming case (only)_, but a bit unsure yet. Depending on how 3GPP architecture is built up, "automatic this" (in conjunction with v4 PDP context activation procedures), this the difficulty could range from trivial to really difficult. > > > But the point is, > > > requiring an operator to support v6 will not necessarily > > > eliminate tunneling when the UE roams to another network > > > (whose managers don't want to support v6 and will implement > > > v6ops recommendations). > > > > So, don't use v6 in those networks then? > > => Unless you provide a serious reason we can't support > this suggestion, especially when there are ways of achieving > this. Ways which may jeopardize the simplicity and robustness of the 3GPP transition. > > > => But in this case the visited network doesn't care about > > > v6. I'm not sure how eliminating the use of V6 through > > > a tunnel will give the visited network an incentive to > > > deploy v6. > > > > For example, if the customers select a different operator > > when they roam > > because the one they tried first doesn't support v6 > > ("v4-only operator > > loses customers and thus money"), I guess the operator which didn't > > support v6 would start to see some benefit in deploying v6 > > if the number > > of users warrants that. There could also be some PR > > gains/losses involved > > here. > > => I just can't relate this to what's happening today. > This is really speculative and I prefer to keep the > draft technical and concrete. The draft doesn't mandate > tunnelling but it doesn't discount it either. I don't > see any good reasons for discounting it. If people think > it's too complex (I don't) then they won't implement it > or deploy it. This is not our call though. This is up to vendors > and operators to choose. It is our business to make the best recommendations we can. Saying "do whatever you want [or whatever some others seem to be doing]" or listing 3-4 different options of possible ways forward is not useful advice. We should figure out which recommandations are best, and if someone chooses to ignore them for whatever reason, that's not our problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 3 02:24:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23924 for ; Fri, 3 Oct 2003 02:24:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5JJJ-000NSJ-ED for v6ops-data@psg.com; Fri, 03 Oct 2003 06:21:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A5JIm-000NPA-Ug for v6ops@ops.ietf.org; Fri, 03 Oct 2003 06:20:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h936K4W24666; Fri, 3 Oct 2003 09:20:04 +0300 Date: Fri, 3 Oct 2003 09:20:03 +0300 (EEST) From: Pekka Savola To: Andreas.Schmid1@swisscom.com cc: juha.wiljakka@nokia.com, , Subject: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] In-Reply-To: <595362761E89B640A907F5112F8B89B80179BFF4@sxmbx03.corproot.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 2 Oct 2003 Andreas.Schmid1@swisscom.com wrote: [...] > > According to my current understanding, the above does not > > require big investments and in many cases software upgrades > > are sufficient. > > It's not about investments. It's about touching the running system. > People do not trust IPv6 at the moment. Tunneling is a way to show them > what could be done in a very inexpensive and easy way. Would it be easier to convince the ops folks that IPv6 is non-intrusive if you _added_ (not upgraded_) one IPv6-capable GGSN, (and other components as needed), which would not serve regular IPv4 users? Partially parallel infrastructure ("dedicated low-end IPv6 router running tunnels") is how many have done it during the first phases in ISP space. Would this be a possibility for 3GPP as well? > > Furthermore, introducing (some) IPv6 support in the network > > does not cause problems with the current IPv4 network, i.e. > > IPv6 can be run simultaneously without disrupting IPv4 > > traffic! This is not a 3GPP-specific thing; this is one of > > the good sides of the dual stack deployment. There is no need > > to immediately move from native IPv4 to native IPv6 support > > in the cellular networks. > > Of course, still you have to touch the running system. Operating people > don't like that. > > One of the hidden problem might be that IPv6 testing had been done > mainly in the R&D site. These guys know what it is all about and have > enough trust to implement it. The operations guys have to go through > this step first. Right... this is not an uncommon problem, and comes up in every space, not just 3GPP. The problem seems to be (speaking wearing both R&D and ops hats) that R&D polishes the technology too long in it's own circles, and doesn't involve ops folks early enough. The ops guys need to get involved with the stuff 1-2 years (at least) before you start talking about putting it in the backbone... -- 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 Oct 3 03:18:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25474 for ; Fri, 3 Oct 2003 03:18:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5K7G-0000UM-MH for v6ops-data@psg.com; Fri, 03 Oct 2003 07:12:42 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A5K6N-0000Rz-Ay for v6ops@ops.ietf.org; Fri, 03 Oct 2003 07:11:47 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J4XY3>; Fri, 3 Oct 2003 03:11:41 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D79@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: "'Alain Durand'" , v6ops@ops.ietf.org Subject: RE: 3GPP v6-only IMS [RE: WG Last Call: 3GPP Analysis Document] Date: Fri, 3 Oct 2003 03:11:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > On Thu, 2 Oct 2003, Soliman Hesham wrote: > [...] > > => I'd love to do that. However, how does this happen in > > practice? Let's say 3GPP went with IPv6 only and 3GPP2 > > did dual stack or IPv4 only for their IMS. And let's > > say that some operators decide to enable IPv4 only > > in their 3GPP2 networks, or in their fixed broadband networks. > > Now a 3GPP operator has three options: > > > > 1. Tell the others to upgrade to v6 > > 2. Tell its subscribers that they can't contact certain > > networks. > > 3. Provide a mechanism that allows subscribers to talk > > to those v4 only people. > > > > 1) is unrealistic. If it can be done, then why hasn't > > it been done already? 2) doesn't seem realistic either > > from a commercial point of view. > > If 3GPP2 would deliberately choose to build a => 3GPP2 is only one example. There are ISPs offering VoIP to fixed broadband users today in the US with a large subscriber base. > non-interopreable network, > would it be 3GPP's fault? => No, but no one said that "if one market chooses AMPS and another chooses GSM then there is no need for those subscribers in the different market to communicate". That would have been a disaster for the industry. > > The only _realistic_ choices for 3GPP2 would seem to be IPv6-only or > dual-stack. And in both cases, there would be a common > protocol, IPv6 -- > no problem. => Famous last words. Hesham > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From owner-v6ops@ops.ietf.org Fri Oct 3 03:18:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25501 for ; Fri, 3 Oct 2003 03:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5KB8-0000f3-6B for v6ops-data@psg.com; Fri, 03 Oct 2003 07:16:42 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A5KAc-0000dg-6u for v6ops@ops.ietf.org; Fri, 03 Oct 2003 07:16:10 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J4XYR>; Fri, 3 Oct 2003 03:16:05 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D7A@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Alain Durand'" Cc: v6ops@ops.ietf.org Subject: RE: WG Last Call: 3GPP Analysis Document Date: Fri, 3 Oct 2003 03:16: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=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Alain, > >=> I'd love to do that. However, how does this happen in > >practice? Let's say 3GPP went with IPv6 only and 3GPP2 > >did dual stack or IPv4 only for their IMS. And let's > >say that some operators decide to enable IPv4 only > >in their 3GPP2 networks, or in their fixed broadband > >networks. Now a 3GPP operator has three options: > > > >1. Tell the others to upgrade to v6 > >2. Tell its subscribers that they can't contact certain > > networks. > >3. Provide a mechanism that allows subscribers to talk > > to those v4 only people. > > > >1) is unrealistic. If it can be done, then why hasn't > >it been done already? 2) doesn't seem realistic either > >from a commercial point of view > > > > I'm a bit confused here. The voice communication using standard > technology would still work fine, right? => If you mean "using circuit switched voice" then I agree. But any service using IP (including voice) would not work. > So, this is only the value-added services, SIP-driven > that won't work between 3GPP & 3GPP2, right? => SIP services are intended for any peer to peer application that uses IP. > > So, are you not trying to solve a social problem here instead > of a technical one? => :) am I? I think allowing people using difference technologies to communicate is a good thing socially, technically and commercially. Hesham From owner-v6ops@ops.ietf.org Fri Oct 3 03:25: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 DAA25656 for ; Fri, 3 Oct 2003 03:25:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5KIT-0001BC-KD for v6ops-data@psg.com; Fri, 03 Oct 2003 07:24:17 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A5KHS-000165-8v for v6ops@ops.ietf.org; Fri, 03 Oct 2003 07:23:14 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J4XYX>; Fri, 3 Oct 2003 03:23:13 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D7B@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: "Karim El-Malki (HF/EAB)" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Fri, 3 Oct 2003 03:23:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=EXCUSE_3,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > => I just can't relate this to what's happening today. > > This is really speculative and I prefer to keep the > > draft technical and concrete. The draft doesn't mandate > > tunnelling but it doesn't discount it either. I don't > > see any good reasons for discounting it. If people think > > it's too complex (I don't) then they won't implement it > > or deploy it. This is not our call though. This is up to vendors > > and operators to choose. > > It is our business to make the best recommendations we can. > Saying "do > whatever you want [or whatever some others seem to be > doing]" or listing > 3-4 different options of possible ways forward is not useful > advice. => Of course we can improve that by listing one preferred option for each scenario. But what you seem to be asking for is to eliminate scenarios which others think are useful. We > should figure out which recommandations are best, and if > someone chooses > to ignore them for whatever reason, that's not our problem. => We don't seem to agree on the possible communication scenarios. This is the problem here. I don't know why you didn't ask for some scenarios to be removed from the scenarios document if you think they are not worth solving. Hesham From owner-v6ops@ops.ietf.org Fri Oct 3 03:34:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25812 for ; Fri, 3 Oct 2003 03:34:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5KQL-0001i6-7l for v6ops-data@psg.com; Fri, 03 Oct 2003 07:32:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A5KPB-0001dm-Hp for v6ops@ops.ietf.org; Fri, 03 Oct 2003 07:31:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h937V6u25494; Fri, 3 Oct 2003 10:31:06 +0300 Date: Fri, 3 Oct 2003 10:31:06 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "'Alain Durand'" , Subject: RE: 3GPP v6-only IMS [RE: WG Last Call: 3GPP Analysis Document] In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D79@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 3 Oct 2003, Soliman Hesham wrote: > > On Thu, 2 Oct 2003, Soliman Hesham wrote: > > [...] > > > => I'd love to do that. However, how does this happen in > > > practice? Let's say 3GPP went with IPv6 only and 3GPP2 > > > did dual stack or IPv4 only for their IMS. And let's > > > say that some operators decide to enable IPv4 only > > > in their 3GPP2 networks, or in their fixed broadband networks. > > > Now a 3GPP operator has three options: > > > > > > 1. Tell the others to upgrade to v6 > > > 2. Tell its subscribers that they can't contact certain > > > networks. > > > 3. Provide a mechanism that allows subscribers to talk > > > to those v4 only people. > > > > > > 1) is unrealistic. If it can be done, then why hasn't > > > it been done already? 2) doesn't seem realistic either > > > from a commercial point of view. > > > > If 3GPP2 would deliberately choose to build a > > => 3GPP2 is only one example. There are ISPs offering > VoIP to fixed broadband users today in the US with > a large subscriber base. Are these connected to the global Internet, or terminated at the ISP? Especially in this case, the v4 NATs are particulatly troublesome, upgrading those voip boxes to dual-stack would (help) the two birds with one stone: make it easier to use VoIP by the broadband users, and to be able to better interconnect to other phones, like 3GPP. > > non-interopreable network, > > would it be 3GPP's fault? > > => No, but no one said that "if one market > chooses AMPS and another chooses GSM then there > is no need for those subscribers in the different > market to communicate". That would have been a disaster > for the industry. There is no physical problem here. Using your analogy, in this case, AMPS (or GSM) could fix the interoperability problem using a software upgrade (to IPv6). I think the point here is whether the markets wish to co-operate or not. We can't force them to.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 3 04:46: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 EAA27538 for ; Fri, 3 Oct 2003 04:46:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5LTf-0005Sv-Am for v6ops-data@psg.com; Fri, 03 Oct 2003 08:39:55 +0000 Received: from [138.190.3.49] (helo=sbe3778.swissptt.ch) by psg.com with esmtp (Exim 4.22) id 1A5LT1-0005Pb-Ec for v6ops@ops.ietf.org; Fri, 03 Oct 2003 08:39:15 +0000 Received: from sxmcmp02.corproot.net (138.190.70.98) by sbe3778.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Fri, 3 Oct 2003 10:39:13 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxsmtp01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Oct 2003 10:38:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Date: Fri, 3 Oct 2003 10:38:09 +0200 Message-ID: <595362761E89B640A907F5112F8B89B80179BFF7@sxmbx03.corproot.net> Thread-Topic: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Thread-Index: AcOJdmYGmQ/K4eaDTpaLQbvhoVi7kwAEMydw From: To: CC: , , X-OriginalArrivalTime: 03 Oct 2003 08:38:10.0213 (UTC) FILETIME=[ACFA8550:01C38989] X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Thu, 2 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > [...] > > > According to my current understanding, the above does not > > > require big investments and in many cases software upgrades=20 > > > are sufficient. > >=20 > > It's not about investments. It's about touching the running system.=20 > > People do not trust IPv6 at the moment. Tunneling is a way to show=20 > > them what could be done in a very inexpensive and easy way. >=20 > Would it be easier to convince the ops folks that IPv6 is=20 > non-intrusive if=20 > you _added_ (not upgraded_) one IPv6-capable GGSN, (and other=20 > components=20 > as needed), which would not serve regular IPv4 users? Yes, easier but still not as easy as tunneling since there is other equipment to touch (as written by in an earlier email): - SGSN support for IPv6 signalling - HLR support for IPv6 >=20 > Partially parallel infrastructure ("dedicated low-end IPv6=20 > router running=20 > tunnels") is how many have done it during the first phases in=20 > ISP space. =20 > Would this be a possibility for 3GPP as well? I'd prefer to do tunneling instead of a parallel infrastructure. Parallel infrastructures cost money to run them - tunneling infrastructure is probably cheaper. >=20 > > > Furthermore, introducing (some) IPv6 support in the network > > > does not cause problems with the current IPv4 network, i.e.=20 > > > IPv6 can be run simultaneously without disrupting IPv4=20 > > > traffic! This is not a 3GPP-specific thing; this is one of=20 > > > the good sides of the dual stack deployment. There is no need=20 > > > to immediately move from native IPv4 to native IPv6 support=20 > > > in the cellular networks. > >=20 > > Of course, still you have to touch the running system. Operating=20 > > people don't like that. > >=20 > > One of the hidden problem might be that IPv6 testing had been done=20 > > mainly in the R&D site. These guys know what it is all=20 > about and have=20 > > enough trust to implement it. The operations guys have to=20 > go through=20 > > this step first. >=20 > Right... this is not an uncommon problem, and comes up in=20 > every space, not just 3GPP. =20 >=20 > The problem seems to be (speaking wearing both R&D and ops=20 > hats) that R&D polishes the technology too long in it's own=20 > circles, and doesn't involve ops folks early enough. The ops=20 > guys need to get involved with the stuff 1-2 years (at least)=20 > before you start talking about putting it in the backbone... > We are trying to involve them since about 1-2 years. But they have enough other things to do that directly have an impact on the revenue. So it's not that easy. I guess it's a problem in the design of the innovation process. But we are probably not the only operator with such problems. I still think that having tunneling mechanisms in the v6ops standards is a good thing and would convince more service providers to do the first steps of the IPv6 introduction. And this is needed to spread out IPv6 to the users and service developers to facilitate the development of services using IPv6 which will finally lead to the full success of IPv6. Just my opinion here.... andreas =20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Fri Oct 3 05:00: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 FAA27779 for ; Fri, 3 Oct 2003 05:00:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Llv-0006rQ-44 for v6ops-data@psg.com; Fri, 03 Oct 2003 08:58:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A5LlP-0006qT-1l for v6ops@ops.ietf.org; Fri, 03 Oct 2003 08:58:15 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h938w8m26418; Fri, 3 Oct 2003 11:58:08 +0300 Date: Fri, 3 Oct 2003 11:58:07 +0300 (EEST) From: Pekka Savola To: Andreas.Schmid1@swisscom.com cc: juha.wiljakka@nokia.com, , Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] In-Reply-To: <595362761E89B640A907F5112F8B89B80179BFF7@sxmbx03.corproot.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 3 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > On Thu, 2 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > [...] > > > > According to my current understanding, the above does not > > > > require big investments and in many cases software upgrades > > > > are sufficient. > > > > > > It's not about investments. It's about touching the running system. > > > People do not trust IPv6 at the moment. Tunneling is a way to show > > > them what could be done in a very inexpensive and easy way. > > > > Would it be easier to convince the ops folks that IPv6 is > > non-intrusive if > > you _added_ (not upgraded_) one IPv6-capable GGSN, (and other > > components > > as needed), which would not serve regular IPv4 users? > > Yes, easier but still not as easy as tunneling since there is other > equipment to touch (as written by in an earlier email): > - SGSN support for IPv6 signalling > - HLR support for IPv6 Right.. but could these be served in some other node as well? (I don't know the 3GPP arch in enough detail..) > > Partially parallel infrastructure ("dedicated low-end IPv6 router > > running tunnels") is how many have done it during the first phases in > > ISP space. Would this be a possibility for 3GPP as well? > > I'd prefer to do tunneling instead of a parallel infrastructure. > Parallel infrastructures cost money to run them - tunneling > infrastructure is probably cheaper. The problem here is that this doesn't seem to do anything to convince the ops folks that they should be enabling the v6 support in the main network -- which is the goal here. They wouldn't get any experience with native v6 or other nice new features this way. So, it seems if we do something like this, it will stay around for a long time, and we won't get to the goal, the real IPv6 service, any time soon. So, tunneling might be counter-productive here. (Note that the situation is slightly different when your home networks support v6, but the network you roam to, doesn't.) > > > > Furthermore, introducing (some) IPv6 support in the network > > > > does not cause problems with the current IPv4 network, i.e. > > > > IPv6 can be run simultaneously without disrupting IPv4 > > > > traffic! This is not a 3GPP-specific thing; this is one of > > > > the good sides of the dual stack deployment. There is no need > > > > to immediately move from native IPv4 to native IPv6 support > > > > in the cellular networks. > > > > > > Of course, still you have to touch the running system. Operating > > > people don't like that. > > > > > > One of the hidden problem might be that IPv6 testing had been done > > > mainly in the R&D site. These guys know what it is all > > about and have > > > enough trust to implement it. The operations guys have to > > go through > > > this step first. > > > > Right... this is not an uncommon problem, and comes up in > > every space, not just 3GPP. > > > > The problem seems to be (speaking wearing both R&D and ops > > hats) that R&D polishes the technology too long in it's own > > circles, and doesn't involve ops folks early enough. The ops > > guys need to get involved with the stuff 1-2 years (at least) > > before you start talking about putting it in the backbone... > > > > We are trying to involve them since about 1-2 years. But they have > enough other things to do that directly have an impact on the revenue. > So it's not that easy. Yep.. which is when you have to start talking to their superiors, i.e. use the administrative methods. Any other means is going to fail (and if the admin methods fail also, I don't see how enabling tunneling is going to help either).. > I guess it's a problem in the design of the innovation process. But we > are probably not the only operator with such problems. Right.. > I still think that having tunneling mechanisms in the v6ops standards is > a good thing and would convince more service providers to do the first > steps of the IPv6 introduction. And this is needed to spread out IPv6 to > the users and service developers to facilitate the development of > services using IPv6 which will finally lead to the full success of IPv6. There is a doubt that such mechanisms are counter-productive for IPv6 deployment (see above for example), and whether such mechanisms could be done reliably/easily/robustly/etc. enough without influencing too much on what must be done at the UE side (I'd prefer to keep that minimal). -- 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 Oct 3 05:03: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 FAA27875 for ; Fri, 3 Oct 2003 05:03:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5LpI-0007CY-1b for v6ops-data@psg.com; Fri, 03 Oct 2003 09:02:16 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A5Lom-00078L-5O for v6ops@ops.ietf.org; Fri, 03 Oct 2003 09:01:44 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J4X7M>; Fri, 3 Oct 2003 05:01:40 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D7D@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: "'Alain Durand'" , v6ops@ops.ietf.org Subject: RE: 3GPP v6-only IMS [RE: WG Last Call: 3GPP Analysis Document] Date: Fri, 3 Oct 2003 05:01:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > => 3GPP2 is only one example. There are ISPs offering > > VoIP to fixed broadband users today in the US with > > a large subscriber base. > > Are these connected to the global Internet, or terminated at the ISP? => Connected to global internet. > Especially in this case, the v4 NATs are particulatly troublesome, > upgrading those voip boxes to dual-stack would (help) the > two birds with > one stone: make it easier to use VoIP by the broadband > users, and to be > able to better interconnect to other phones, like 3GPP. => You don't have to convince me that upgrading to v6 is a good thing. Trust me, I believe it. But the fact is, lots of people won't do it for a very long time. From owner-v6ops@ops.ietf.org Fri Oct 3 05:07: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 FAA28007 for ; Fri, 3 Oct 2003 05:07:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Lsw-0007bX-PL for v6ops-data@psg.com; Fri, 03 Oct 2003 09:06:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A5LsR-0007W0-3K for v6ops@ops.ietf.org; Fri, 03 Oct 2003 09:05:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9395LJ26575; Fri, 3 Oct 2003 12:05:21 +0300 Date: Fri, 3 Oct 2003 12:05:21 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "'Alain Durand'" , Subject: RE: 3GPP v6-only IMS [RE: WG Last Call: 3GPP Analysis Document] In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D7D@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 3 Oct 2003, Soliman Hesham wrote: > > Especially in this case, the v4 NATs are particulatly troublesome, > > upgrading those voip boxes to dual-stack would (help) the > > two birds with > > one stone: make it easier to use VoIP by the broadband > > users, and to be > > able to better interconnect to other phones, like 3GPP. > > => You don't have to convince me that upgrading to > v6 is a good thing. Trust me, I believe it. But the > fact is, lots of people won't do it for a very long time. So, we need to give the people an incentive to do the upgrade. Calls between 3GPP and their home systems ( == cheaper calls) could be a very selling argument. -- 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 Oct 3 05:11: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 FAA28059 for ; Fri, 3 Oct 2003 05:11:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5LwV-0007pX-RU for v6ops-data@psg.com; Fri, 03 Oct 2003 09:09:43 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.22) id 1A5Lw0-0007o5-Ks for v6ops@ops.ietf.org; Fri, 03 Oct 2003 09:09:12 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J4X7X>; Fri, 3 Oct 2003 05:09:12 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D7F@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: "'Alain Durand'" , v6ops@ops.ietf.org Subject: RE: 3GPP v6-only IMS [RE: WG Last Call: 3GPP Analysis Document] Date: Fri, 3 Oct 2003 05:09:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, I have mo more to add to this discussion. Good luck with this noble goal. Hesham > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, October 03, 2003 5:05 AM > To: Soliman Hesham > Cc: 'Alain Durand'; v6ops@ops.ietf.org > Subject: RE: 3GPP v6-only IMS [RE: WG Last Call: 3GPP > Analysis Document] > > > On Fri, 3 Oct 2003, Soliman Hesham wrote: > > > Especially in this case, the v4 NATs are particulatly > troublesome, > > > upgrading those voip boxes to dual-stack would (help) the > > > two birds with > > > one stone: make it easier to use VoIP by the broadband > > > users, and to be > > > able to better interconnect to other phones, like 3GPP. > > > > => You don't have to convince me that upgrading to > > v6 is a good thing. Trust me, I believe it. But the > > fact is, lots of people won't do it for a very long time. > > So, we need to give the people an incentive to do the upgrade. Calls > between 3GPP and their home systems ( == cheaper calls) > could be a very > selling argument. > > -- > 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 Oct 3 05:11: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 FAA28078 for ; Fri, 3 Oct 2003 05:11:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5LxZ-0007wH-0K for v6ops-data@psg.com; Fri, 03 Oct 2003 09:10:49 +0000 Received: from [138.190.3.49] (helo=sbe3778.swissptt.ch) by psg.com with esmtp (Exim 4.22) id 1A5Lx2-0007tF-HU for v6ops@ops.ietf.org; Fri, 03 Oct 2003 09:10:16 +0000 Received: from sxmcmp02.corproot.net (138.190.70.98) by sbe3778.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Fri, 3 Oct 2003 11:10:14 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxsmtp02.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 3 Oct 2003 11:09:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Date: Fri, 3 Oct 2003 11:09:20 +0200 Message-ID: <595362761E89B640A907F5112F8B89B80179BFFA@sxmbx03.corproot.net> Thread-Topic: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Thread-Index: AcOJjHlTVBpMmPoPSG2b8FfunqIo6wAABXIg From: To: CC: , , X-OriginalArrivalTime: 03 Oct 2003 09:09:21.0114 (UTC) FILETIME=[081F5BA0:01C3898E] X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > On Fri, 3 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > > On Thu, 2 Oct 2003 Andreas.Schmid1@swisscom.com wrote: [...] > > > > > According to my current understanding, the above does not=20 > > > > > require big investments and in many cases software=20 > upgrades are=20 > > > > > sufficient. > > > >=20 > > > > It's not about investments. It's about touching the running=20 > > > > system. > > > > People do not trust IPv6 at the moment. Tunneling is a=20 > way to show=20 > > > > them what could be done in a very inexpensive and easy way. > > >=20 > > > Would it be easier to convince the ops folks that IPv6 is > > > non-intrusive if=20 > > > you _added_ (not upgraded_) one IPv6-capable GGSN, (and other=20 > > > components=20 > > > as needed), which would not serve regular IPv4 users? > >=20 > > Yes, easier but still not as easy as tunneling since there is other=20 > > equipment to touch (as written by in an earlier email): > > - SGSN support for IPv6 signalling > > - HLR support for IPv6 >=20 > Right.. but could these be served in some other node as well?=20 > (I don't=20 > know the 3GPP arch in enough detail..) Also if you serve it in some other node, you have to implement the functionality. There is less to implement if you do tunneling (very little signalling). >=20 > > > Partially parallel infrastructure ("dedicated low-end IPv6 router=20 > > > running tunnels") is how many have done it during the=20 > first phases=20 > > > in ISP space. Would this be a possibility for 3GPP as well? > >=20 > > I'd prefer to do tunneling instead of a parallel infrastructure.=20 > > Parallel infrastructures cost money to run them - tunneling=20 > > infrastructure is probably cheaper. >=20 > The problem here is that this doesn't seem to do anything to=20 > convince the ops folks that they should be enabling the v6=20 > support in the main network > -- which is the goal here. They wouldn't get any experience=20 > with native v6 or other nice new features this way. >=20 > So, it seems if we do something like this, it will stay=20 > around for a long time, and we won't get to the goal, the=20 > real IPv6 service, any time soon. >=20 > So, tunneling might be counter-productive here. =20 >=20 > (Note that the situation is slightly different when your home=20 > networks support v6, but the network you roam to, doesn't.) Maybe. But if the hurdle to go native is too high then we have no IPv6 at all. And that's even worse!=20 Native IPv6 will come once IPv6 usage takes up and apps are around that use IPv6. But to initiate the app development it is crucial to have a network out that supports IPv6. This network has to be built without business case. Therefore, tunneling is the only way to do this IMHO. I don't think that this is counter-productive here. > =20 > > I still think that having tunneling mechanisms in the v6ops=20 > standards=20 > > is a good thing and would convince more service providers to do the=20 > > first steps of the IPv6 introduction. And this is needed to=20 > spread out=20 > > IPv6 to the users and service developers to facilitate the=20 > development=20 > > of services using IPv6 which will finally lead to the full=20 > success of=20 > > IPv6. >=20 > There is a doubt that such mechanisms are counter-productive=20 > for IPv6 deployment (see above for example), and whether such=20 > mechanisms could be done reliably/easily/robustly/etc. enough=20 > without influencing too much on what must be done at the UE=20 > side (I'd prefer to keep that minimal). I don't care too much about reliability/robustness/etc of the first IPv6 introduction step. By the way, often 3G UE will be used as modem for PCs. And, on the PC side tunneling mechanisms are already implemented and very easy to use (at least in the case of Windows XP with ISATAP). I see tunneling as a quite easy and cheap mechanism to bring IPv6 to the users. As in the IPv4-Internet, applications will just appear. And once they appear for IPv6, native IPv6 will be needed (robustness, etc) but the business case will be there to do this! Regards Andreas >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Fri Oct 3 10:40: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 KAA10215 for ; Fri, 3 Oct 2003 10:40:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5Qzm-0002rr-Bt for v6ops-data@psg.com; Fri, 03 Oct 2003 14:33:26 +0000 Received: from [193.180.251.47] (helo=penguin-ext.wise.edt.ericsson.se) by psg.com with esmtp (Exim 4.22) id 1A5QzG-0002qM-DG for v6ops@ops.ietf.org; Fri, 03 Oct 2003 14:32:54 +0000 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h93EWjN1011650; Fri, 3 Oct 2003 16:32:49 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 3 Oct 2003 16:35:47 +0200 Message-ID: <76E5F712842F5F49A35738622BAA0F4F0376831C@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Pekka Savola '" , "'Soliman Hesham '" Cc: "'juha.wiljakka@nokia.com '" , "'v6ops@ops.ietf.org '" Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Fri, 3 Oct 2003 16:32:22 +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=1.4 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > => I didn't ask to have "don't tunnel from the UE" > > > in the text. I was commenting on the new text. > > > I don't think the draft should include opinions on how > > > easy it is to upgrade to V6 and whether that involves > > > SW or HW upgrades. It's not useful. > > > > It seems very useful to me, although the wording may not be > > optimal. If > > upgrading to v6 is relatively easy, we can recommend > > upgrading to IPv6. > > => I'm afraid that we cannot make a general assessment > here of how "easy" it is to upgrade to v6. Leave it to > the operators because we have no "one statement fits all". > As a general comment. I'd like to minimise opinions in > IETF specs and keep it concrete and straight forward. > > If operators think it's easy to upgrade, I'm sure they > will do what they need to do. Putting it in the draft > will not "make them believe". I think this is not true at all. Remember that we're not specifying a protocol here .. but giving recommendations on deployment. We can, and should, "make them believe". Education is one important part of the solutions specs. (KEM) Falling behind on emails but this one caught my eye. I don't think operators are as dumb as you are making them. Many have been working on IPv6 for some time and will not just blindly accept what is in a draft. The reasoning is important. > > > That's > > > > also expected to happen during the early phases of > > > > transition. If the > > > > operator doesn't care about IPv6 users at all, the users can > > > > just stay out > > > > of those networks. > > > > > > => The point is: Your operator cares about v6 and wants > > > to offer you the services that IPv6 enables > > > > Right so far.. > > > > > while you're > > > roaming. > > > > If your SP wants to enable services while you're roaming, > > your SP needs to > > convince those networks it has roaming agreements with to enable v6? > > => No way... What's the incentive for another operator to do that? Not to lose money from the customers it would bring, simple as that. (KEM) From what I know your thinking is way too simplistic. We should leave the business decisions to those who know how to run a mobile network. > > > It is not relevant how the visited operator feels > > > about v6. > > > > I fear this is very relevant. Your home operator can't > > really offer what > > it can't provide. So, it should not *guarantee* you IPv6 > > services while > > you roam, as simple as that.. > > => Well, it can when tunneling is used. But you seem > to say that it "shouldn't", despite the fact that it > can. Yeah, it *could* provide a service, if we recommend a tunneling mechanism (or multiple ones) to be implemented in all UE's. If it isn't implemented in all UE's it's not going to fly. So, we have to balance whether we want the transition mechanism at the UE, or not; and which kind of transition mechanism it would be (i.e., whether there would be any problems in that). Configured tunneling could be acceptable to me _in the roaming case (only)_, but a bit unsure yet. Depending on how 3GPP architecture is built up, "automatic this" (in conjunction with v4 PDP context activation procedures), this the difficulty could range from trivial to really difficult. (KEM) So you've basically described ISATAP, not configured tunnelling. > > > But the point is, > > > requiring an operator to support v6 will not necessarily > > > eliminate tunneling when the UE roams to another network > > > (whose managers don't want to support v6 and will implement > > > v6ops recommendations). > > > > So, don't use v6 in those networks then? > > => Unless you provide a serious reason we can't support > this suggestion, especially when there are ways of achieving > this. Ways which may jeopardize the simplicity and robustness of the 3GPP transition. (KEM) Simplicity in terms of Operations? I wouldn't think so. > > > => But in this case the visited network doesn't care about > > > v6. I'm not sure how eliminating the use of V6 through > > > a tunnel will give the visited network an incentive to > > > deploy v6. > > > > For example, if the customers select a different operator > > when they roam > > because the one they tried first doesn't support v6 > > ("v4-only operator > > loses customers and thus money"), I guess the operator which didn't > > support v6 would start to see some benefit in deploying v6 > > if the number > > of users warrants that. There could also be some PR > > gains/losses involved > > here. > > => I just can't relate this to what's happening today. > This is really speculative and I prefer to keep the > draft technical and concrete. The draft doesn't mandate > tunnelling but it doesn't discount it either. I don't > see any good reasons for discounting it. If people think > it's too complex (I don't) then they won't implement it > or deploy it. This is not our call though. This is up to vendors > and operators to choose. It is our business to make the best recommendations we can. Saying "do whatever you want [or whatever some others seem to be doing]" or listing 3-4 different options of possible ways forward is not useful advice. We should figure out which recommandations are best, and if someone chooses to ignore them for whatever reason, that's not our problem. (KEM) Being reasonable and getting IPv6 deployed is our business. Being unreasonable and unrealistic will automatically mean that other solutions will be sought. I don't want the latter to happen. /Karim From owner-v6ops@ops.ietf.org Fri Oct 3 15:20:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22646 for ; Fri, 3 Oct 2003 15:20:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.22) id 1A5VKS-0001ad-Ck for v6ops-data@psg.com; Fri, 03 Oct 2003 19:11:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.22) id 1A5VJw-0001WS-SU for v6ops@ops.ietf.org; Fri, 03 Oct 2003 19:10:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h93JAKZ03262 for ; Fri, 3 Oct 2003 22:10:25 +0300 Date: Fri, 3 Oct 2003 22:10:17 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_20,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, This should be known already, but if someone missed that..: Oct 13: chairs must know if any draft-ietf-v6ops-xxx-00 documents will be submitted, and with which names: Oct 20: DL for all -00 submissions Oct 27: DL for the revisions (no placeholders) Please also try to notify us of if you think you'll have something you'd like to present, we're already building up the agenda.. (see the request for agenda items earlier.) Thanks, Pekka, Jonne & Bob ---------- Forwarded message ---------- Date: Fri, 03 Oct 2003 07:30:42 -0400 From: Internet-Drafts Administrator To: IETF-Announce: ; Subject: Internet-Draft Cutoff Dates for Minneapolis, MN, USA NOTE: There are two (2) Internet-Draft Cutoff dates October 20th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Monday, October 20th, at 09:00 ET. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, October 13th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of October 20th will NOT be accepted. October 27th: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Monday, October 27th, 2003 at 09:00 ET. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_58.html From owner-v6ops@ops.ietf.org Mon Oct 6 03:10:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20176 for ; Mon, 6 Oct 2003 03:10:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6PKG-000EsI-36 for v6ops-data@psg.com; Mon, 06 Oct 2003 06:58:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6PJj-000EH4-2k for v6ops@ops.ietf.org; Mon, 06 Oct 2003 06:58:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h966vaX12687; Mon, 6 Oct 2003 09:57:36 +0300 Date: Mon, 6 Oct 2003 09:57:35 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "Karim El-Malki (HF/EAB)" , , Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D7B@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.1 required=5.0 tests=EMAIL_ATTRIBUTION,EXCUSE_3,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 3 Oct 2003, Soliman Hesham wrote: > > > => I just can't relate this to what's happening today. > > > This is really speculative and I prefer to keep the > > > draft technical and concrete. The draft doesn't mandate > > > tunnelling but it doesn't discount it either. I don't > > > see any good reasons for discounting it. If people think > > > it's too complex (I don't) then they won't implement it > > > or deploy it. This is not our call though. This is up to vendors > > > and operators to choose. > > > > It is our business to make the best recommendations we can. > > Saying "do > > whatever you want [or whatever some others seem to be > > doing]" or listing > > 3-4 different options of possible ways forward is not useful > > advice. > > => Of course we can improve that by listing one preferred > option for each scenario. But what you seem to be asking for > is to eliminate scenarios which others think are useful. Having one solution would be vastly preferable. In some cases, where there is clear reason (and significant use for multiple ones) it might be possible to list some options, but I'm not sure if that has really come up. I want to eliminate some scenarios because that would seem to give bad advice to the folks reading the document. One purpose of the documents was to *limit* and *clarify* the transitition scenarios -- not to document every single one of them, and everything such a model would require to operate. I guess it might be possible to include a paragraph like "doing FOO or BAR is not recommended, because..." if folks think that would be a good idea. > We > > should figure out which recommandations are best, and if > > someone chooses > > to ignore them for whatever reason, that's not our problem. > > => We don't seem to agree on the possible communication > scenarios. This is the problem here. I don't know why > you didn't ask for some scenarios to be removed from the > scenarios document if you think they are not worth solving. I think the scenarios were meant to point out the different *possible* ways to deploy v6 in 3GPP space. It didn't intend to include the normative text on, "these all are scenarios required to be solved". One should be allowed to excercise judgment in the Analysis documents, or consider whether a given direction already taken in the analysis document (e.g. wider application of dual-stack than maybe anticipated when writing the scenarios) already eliminates/mitigates the need for a solution in each specific original scenario listed (instead of "already solved"). The bottom line is that the scenarios as a whole has to be dealt with. -- 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 Oct 6 03:31: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 DAA20536 for ; Mon, 6 Oct 2003 03:31:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6PnL-000JxC-LP for v6ops-data@psg.com; Mon, 06 Oct 2003 07:28:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6PmR-000J2h-GG for v6ops@ops.ietf.org; Mon, 06 Oct 2003 07:27:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h967RaT13053; Mon, 6 Oct 2003 10:27:36 +0300 Date: Mon, 6 Oct 2003 10:27:35 +0300 (EEST) From: Pekka Savola To: Andreas.Schmid1@swisscom.com cc: juha.wiljakka@nokia.com, , Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] In-Reply-To: <595362761E89B640A907F5112F8B89B80179BFFA@sxmbx03.corproot.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 3 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > On Fri, 3 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > > > On Thu, 2 Oct 2003 Andreas.Schmid1@swisscom.com wrote: [...] > > > > > > According to my current understanding, the above does not > > > > > > require big investments and in many cases software > > upgrades are > > > > > > sufficient. > > > > > > > > > > It's not about investments. It's about touching the running > > > > > system. > > > > > People do not trust IPv6 at the moment. Tunneling is a > > way to show > > > > > them what could be done in a very inexpensive and easy way. > > > > > > > > Would it be easier to convince the ops folks that IPv6 is > > > > non-intrusive if > > > > you _added_ (not upgraded_) one IPv6-capable GGSN, (and other > > > > components > > > > as needed), which would not serve regular IPv4 users? > > > > > > Yes, easier but still not as easy as tunneling since there is other > > > equipment to touch (as written by in an earlier email): > > > - SGSN support for IPv6 signalling > > > - HLR support for IPv6 > > > > Right.. but could these be served in some other node as well? > > (I don't > > know the 3GPP arch in enough detail..) > > Also if you serve it in some other node, you have to implement the > functionality. There is less to implement if you do tunneling (very > little signalling). You'll have to implement _something_ anyway, because the tunnels have to be terminated. The termination need not be done at a 3GPP equipment though.. I guess what you are saying that you don't want to implement any 3GPP IPv6 functinality before the business case, but would be OK to implement generic IPv6 features which wouldn't clash with current v4 3GPP operations? > > > > Partially parallel infrastructure ("dedicated low-end IPv6 router > > > > running tunnels") is how many have done it during the > > first phases > > > > in ISP space. Would this be a possibility for 3GPP as well? > > > > > > I'd prefer to do tunneling instead of a parallel infrastructure. > > > Parallel infrastructures cost money to run them - tunneling > > > infrastructure is probably cheaper. > > > > The problem here is that this doesn't seem to do anything to > > convince the ops folks that they should be enabling the v6 > > support in the main network > > -- which is the goal here. They wouldn't get any experience > > with native v6 or other nice new features this way. > > > > So, it seems if we do something like this, it will stay > > around for a long time, and we won't get to the goal, the > > real IPv6 service, any time soon. > > > > So, tunneling might be counter-productive here. > > > > (Note that the situation is slightly different when your home > > networks support v6, but the network you roam to, doesn't.) > > Maybe. But if the hurdle to go native is too high then we have no IPv6 > at all. And that's even worse! > > Native IPv6 will come once IPv6 usage takes up and apps are around that > use IPv6. But to initiate the app development it is crucial to have a > network out that supports IPv6. This network has to be built without > business case. Therefore, tunneling is the only way to do this IMHO. > > I don't think that this is counter-productive here. I'm not saying the networks have to be native through-out. Tunneling can very well be applied in many places if folks feel like it. However, recommending tunneling at the 3GPP network <-> UE interface would have a significant impact on how 3GPP networks would get deployed & implemented. The changes at this interface would not be transparent. > > > I still think that having tunneling mechanisms in the v6ops > > standards > > > is a good thing and would convince more service providers to do the > > > first steps of the IPv6 introduction. And this is needed to > > spread out > > > IPv6 to the users and service developers to facilitate the > > development > > > of services using IPv6 which will finally lead to the full > > success of > > > IPv6. > > > > There is a doubt that such mechanisms are counter-productive > > for IPv6 deployment (see above for example), and whether such > > mechanisms could be done reliably/easily/robustly/etc. enough > > without influencing too much on what must be done at the UE > > side (I'd prefer to keep that minimal). > > I don't care too much about reliability/robustness/etc of the first IPv6 > introduction step. Oh, you should care! :-) It has been a reason why IPv6 deployment hasn't kicked off yet. A reason why vendors aren't putting on v6 by default, etc. Everything is about reliability and robustness. If folks try IPv6, and it doesn't work, they're not likely to try again any time soon! For a couple of perspectives, have a look at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-6bone-mess-01.txt http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-01.txt > By the way, often 3G UE will be used as modem for > PCs. And, on the PC side tunneling mechanisms are already implemented > and very easy to use (at least in the case of Windows XP with ISATAP). This has nothing to do with 3GPP (except that it's done on top of v4 3GPP network), right? The UE doesn't know anything of v6, and the 3GPP network doesn't know anything of v6. The 3GPP operator is just acting as an IPv4 ISP, offering tunneled v6 service for folks using its private v4 addresses? > I see tunneling as a quite easy and cheap mechanism to bring IPv6 to the > users. As in the IPv4-Internet, applications will just appear. And once > they appear for IPv6, native IPv6 will be needed (robustness, etc) but > the business case will be there to do this! I fear the robustness etc. which you shrug away are preconditions for more generic deployment and application development. -- 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 Oct 6 06:35: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 GAA24200 for ; Mon, 6 Oct 2003 06:35:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6SXk-000MR3-1k for v6ops-data@psg.com; Mon, 06 Oct 2003 10:24:44 +0000 Received: from [63.103.94.23] (helo=ftmail.lab.flarion.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6SXD-000Lwu-Ja for v6ops@ops.ietf.org; Mon, 06 Oct 2003 10:24:11 +0000 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6J48B0>; Mon, 6 Oct 2003 06:24:10 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A01922D8E@ftmail.lab.flarion.com> From: Soliman Hesham To: "'Pekka Savola'" Cc: "Karim El-Malki (HF/EAB)" , juha.wiljakka@nokia.com, v6ops@ops.ietf.org Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues Date: Mon, 6 Oct 2003 06:24:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.9 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Having one solution would be vastly preferable. In some > cases, where > there is clear reason (and significant use for multiple > ones) it might be > possible to list some options, but I'm not sure if that has > really come > up. > > I want to eliminate some scenarios because that would seem > to give bad > advice to the folks reading the document. One purpose of > the documents > was to *limit* and *clarify* the transitition scenarios -- => I thought the purpose was to limit the number of solutions needed for each scenario. There are limited scenarios already and I thought we agreed on them in another RFC. Otherwise, why would each DT have produced a different scenarios doc? > I think the scenarios were meant to point out the different > *possible* > ways to deploy v6 in 3GPP space. It didn't intend to include the > normative text on, "these all are scenarios required to be solved". => If that were the case we could have put all possible scenarios from all DTs in one doc. Because, come to think about it, there are huge overlaps. The specific scenarios for each DT were very very limited compared to the overall number. > > One should be allowed to excercise judgment in the Analysis > documents, or > consider whether a given direction already taken in the > analysis document => That's what we did and clearly we believe that some of those scenarios are needed. It also seems like some operators agree. If there is a WG concensus against one or more of those scenarios then it would be nice to know that. Right now, I'm only seeing your commentary. Hesham From owner-v6ops@ops.ietf.org Mon Oct 6 11:19: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 LAA07022 for ; Mon, 6 Oct 2003 11:19:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6X2P-000OT9-0j for v6ops-data@psg.com; Mon, 06 Oct 2003 15:12:41 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6X1r-000NtM-6x for v6ops@ops.ietf.org; Mon, 06 Oct 2003 15:12:07 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06442; Mon, 6 Oct 2003 11:11:56 -0400 (EDT) Message-Id: <200310061511.LAA06442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-trans-03.txt Date: Mon, 06 Oct 2003 11:11:56 -0400 X-Spam-Status: No, hits=2.9 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Author(s) : P. Nesser II, A. Bergstrom Filename : draft-ietf-v6ops-ipv4survey-trans-03.txt Pages : 0 Date : 2003-10-6 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-trans-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-6113209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-trans-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-trans-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-6113209.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 6 17:31: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 RAA23779 for ; Mon, 6 Oct 2003 17:31:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6cpx-000HQZ-KF for v6ops-data@psg.com; Mon, 06 Oct 2003 21:24:13 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6cow-000GLS-EA for v6ops@ops.ietf.org; Mon, 06 Oct 2003 21:23:10 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h96LMtF17577; Mon, 6 Oct 2003 14:22:55 -0700 X-mProtect: <200310062122> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdj8EUvV; Mon, 06 Oct 2003 14:22:53 PDT Message-ID: <3F81DDF6.5080803@iprg.nokia.com> Date: Mon, 06 Oct 2003 14:26:14 -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: "Follen, Stephen" , v6ops@ops.ietf.org, Fred Templin Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sorry for letting this thread grow cold, but see below: Pekka Savola wrote: >Hi, > >Thanks for bringing this up. The RFC is under revision, and this thing >should probably be specified in more detail. > >There are two-three distinct cases here (I think): > > 1) "node receives packets from an unknown ("unconfigured") tunnel >endpoint" > > ==> the node should _not_ "acknowledge" the existence of the tunnel, >otherwise this could be used to probe the acceptable tunnel endpoint >addresses. That is, node should either silently discard the packet, or >send an ICMPv4 Protocol Unreachable message. (I guess that depends on >what happens when a node receives a packet of an unknown protocol -- >whether it sends anything back or not.) > > 2) "node receives packets from a configured tunnel endpoint, but from the >wrong direction (e.g. "internal IP address" from the direction of the >Internet), if that kind of policing is implemented/enabled. > > ==> silently discard, I think. > > 3) "node receives packets through a valid tunnel which fail IPv6 ingress >filtering tests" > > ==> silently discard, I think (if ingress filtering fails, the error >won't probably get back anyway) > In case 3) above, send an ICMPv6 DU to the originating source. It might not get back, but may very well help the situation in the decapsulator for the next time around... Fred ftemplin@iprg.nokia.com >On Thu, 28 Aug 2003, Follen, Stephen wrote: > > >>A question related to Ingress Filtering of decapsulated [tunneled] >>IPv6-in-IPv4 packets: >> >>Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that "... >>a decapsulated packet MUST NOT be forwarded unless the node has been >>explicitly configured to forward such packets ..." and in section 4.3 >>"The decapsulating node MUST verify that the tunnel source address is >>acceptable before forwarding decapsulated packets ..." >>(the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 Transition >>Mechanisms provides similar guidance in sections 3.6, 3.9 and 4.1) >> >>The question is what to do in the case that the packets are filtered / >>not forwarded: >> >>1. silently drop the packet - simple, but provides no feedback of the >>"broken link" (see below); >> >>2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a poor >>approach since >> (a) the IPv4 [tunnel endpoint] address was reached and >> (b) a response may never get back to the originating IPv6 host >> (section 3.4 of RFC 2893 indicates that an encapsulating node MAY >>generate >> a v6 ICMP when it gets a v4 ICMP back); >> >>3. send a v6 ICMP DU - this probably won't get back to the originating >>host either since >> its unlikely that there's a path back to it (the do not forward >>decision occurred because >> the tunnel was not set up); >> >>4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information >>in the incoming >> IPv6-in-IPv4 packet to generate this, and it would likely get back >>to the originating host, >> but to do so would effectively send a packet via a tunnel which had >>not been configured. >> >>"broken link" - [in the case of legitimate traffic] the filtering which >>would occur here is not >>the result of a specifically configured ingress filter, rather, it is >>the result of not fully configuring >>the tunnel; a tunnel is effectively a link, so I see the filtering to be >>similar to a broken link. >> >>Any thoughts would be greatly appreciated. - Thank you >> >>Steve Follen >>sfollen@enterasys.com >> >> >> >> >> >> >> > > > From owner-v6ops@ops.ietf.org Tue Oct 7 01:51: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 BAA07622 for ; Tue, 7 Oct 2003 01:51:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6khV-0002v7-TN for v6ops-data@psg.com; Tue, 07 Oct 2003 05:48:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6kgz-0002VQ-4c for v6ops@ops.ietf.org; Tue, 07 Oct 2003 05:47:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h975l4L31944; Tue, 7 Oct 2003 08:47:04 +0300 Date: Tue, 7 Oct 2003 08:47:04 +0300 (EEST) From: Pekka Savola To: Soliman Hesham cc: "Karim El-Malki (HF/EAB)" , , Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922D8E@ftmail.lab.flarion.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 6 Oct 2003, Soliman Hesham wrote: > > Having one solution would be vastly preferable. In some > > cases, where > > there is clear reason (and significant use for multiple > > ones) it might be > > possible to list some options, but I'm not sure if that has > > really come > > up. > > > > I want to eliminate some scenarios because that would seem > > to give bad > > advice to the folks reading the document. One purpose of > > the documents > > was to *limit* and *clarify* the transitition scenarios -- > > => I thought the purpose was to limit the number of solutions > needed for each scenario. There are limited scenarios already > and I thought we agreed on them in another RFC. Otherwise, why > would each DT have produced a different scenarios doc? The scenarios which need to be *considered* are different across the different solutions/scenarios teams. > > I think the scenarios were meant to point out the different > > *possible* > > ways to deploy v6 in 3GPP space. It didn't intend to include the > > normative text on, "these all are scenarios required to be solved". > > => If that were the case we could have put all possible > scenarios from all DTs in one doc. Because, come to think > about it, there are huge overlaps. The specific scenarios > for each DT were very very limited compared to the overall > number. Hindsight is a powerful tool.. but I don't think it would have worked. The different cases (ISP, enterprise, etc.) do seem to have their own characteristics. Trying to lump them in one would probably have resulted in one giant document which would have been too generic to be useful. > > One should be allowed to excercise judgment in the Analysis > > documents, or > > consider whether a given direction already taken in the > > analysis document > > => That's what we did and clearly we believe that some of > those scenarios are needed. It also seems like some > operators agree. If there is a WG concensus against > one or more of those scenarios then it would be nice > to know that. Right now, I'm only seeing your commentary. Look closer, there have been other comments like mine. The document is currently in Last Call, so I'm hoping to see more WG members give their opinion on the subject. As it is, it is rather difficult to judge one way or the other. -- 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 Oct 7 01:51: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 BAA07642 for ; Tue, 7 Oct 2003 01:51:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6kal-000MwH-P5 for v6ops-data@psg.com; Tue, 07 Oct 2003 05:41:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6kaE-000MNV-BG for v6ops@ops.ietf.org; Tue, 07 Oct 2003 05:40:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h975eH131863; Tue, 7 Oct 2003 08:40:17 +0300 Date: Tue, 7 Oct 2003 08:40:16 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Follen, Stephen" , Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 In-Reply-To: <3F81DDF6.5080803@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_OSIRUSOFT_COM,REPLY_WITH_QUOTES,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 6 Oct 2003, Fred Templin wrote: > Pekka Savola wrote: [...] > > 3) "node receives packets through a valid tunnel which fail IPv6 ingress > >filtering tests" > > > > ==> silently discard, I think (if ingress filtering fails, the error > >won't probably get back anyway) > > > > In case 3) above, send an ICMPv6 DU to the originating source. > > It might not get back, but may very well help the situation > in the decapsulator for the next time around... Huh? Which node do you refer by decapsulator -- the one sending ICMPv6 DU, or the one receiving it (over the tunnel) and decapsulating it? If the former, I don't really understand how sending a reply would help. If the latter, I'm not sure if there is enough of a guarantee to warrant it because the message would probably never get through. One special case in which it _might_ help is host<->router tunnels, as you would know that the host is responsible for sending such illegitimate packets (and not just anyone at all behind another router). -- 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 Oct 7 03: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 DAA22411 for ; Tue, 7 Oct 2003 03:57:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6mX7-000A6G-UO for v6ops-data@psg.com; Tue, 07 Oct 2003 07:45:25 +0000 Received: from [138.190.3.49] (helo=sbe3778.swissptt.ch) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6mWa-0009kY-Lz for v6ops@ops.ietf.org; Tue, 07 Oct 2003 07:44:52 +0000 Received: from sxmcmp02.corproot.net (138.190.70.98) by sbe3778.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Tue, 7 Oct 2003 09:44:51 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxsmtp02.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Oct 2003 09:44:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Date: Tue, 7 Oct 2003 09:44:28 +0200 Message-ID: <595362761E89B640A907F5112F8B89B801FBBF74@sxmbx03.corproot.net> Thread-Topic: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Thread-Index: AcOL22GvzYREj4dLTmOq9jT2ytnIKwAwYa7w From: To: CC: , , X-OriginalArrivalTime: 07 Oct 2003 07:44:27.0101 (UTC) FILETIME=[D581A8D0:01C38CA6] X-Spam-Status: No, hits=0.7 required=5.0 tests=NO_REAL_NAME,QUOTED_EMAIL_TEXT version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > > > > > > According to my current understanding, the above does not > > > > > > > require big investments and in many cases software=20 > > > upgrades are > > > > > > > sufficient. > > > > > >=20 > > > > > > It's not about investments. It's about touching the running > > > > > > system. > > > > > > People do not trust IPv6 at the moment. Tunneling is a=20 > > > way to show > > > > > > them what could be done in a very inexpensive and easy way. > > > > >=20 > > > > > Would it be easier to convince the ops folks that IPv6 is=20 > > > > > non-intrusive if you _added_ (not upgraded_) one IPv6-capable=20 > > > > > GGSN, (and other components > > > > > as needed), which would not serve regular IPv4 users? > > > >=20 > > > > Yes, easier but still not as easy as tunneling since there is=20 > > > > other > > > > equipment to touch (as written by in an earlier email): > > > > - SGSN support for IPv6 signalling > > > > - HLR support for IPv6 > > >=20 > > > Right.. but could these be served in some other node as well? > > > (I don't=20 > > > know the 3GPP arch in enough detail..) > >=20 > > Also if you serve it in some other node, you have to implement the=20 > > functionality. There is less to implement if you do tunneling (very=20 > > little signalling). >=20 > You'll have to implement _something_ anyway, because the=20 > tunnels have to be terminated. The termination need not be=20 > done at a 3GPP equipment though.. Of course, we have to implement something. But the IPv6 implementation will be totally non-intrusive. Therefore, the 3GPP equipment does not have to be "touched". >=20 > I guess what you are saying that you don't want to implement=20 > any 3GPP IPv6 functinality before the business case, but=20 > would be OK to implement generic IPv6 features which wouldn't=20 > clash with current v4 3GPP operations? Yes. >=20 > > > > > Partially parallel infrastructure ("dedicated low-end IPv6=20 > > > > > router running tunnels") is how many have done it during the > > > first phases > > > > > in ISP space. Would this be a possibility for 3GPP as well? > > > >=20 > > > > I'd prefer to do tunneling instead of a parallel infrastructure. > > > > Parallel infrastructures cost money to run them - tunneling=20 > > > > infrastructure is probably cheaper. > > >=20 > > > The problem here is that this doesn't seem to do anything to > > > convince the ops folks that they should be enabling the v6=20 > > > support in the main network > > > -- which is the goal here. They wouldn't get any experience=20 > > > with native v6 or other nice new features this way. > > >=20 > > > So, it seems if we do something like this, it will stay > > > around for a long time, and we won't get to the goal, the=20 > > > real IPv6 service, any time soon. > > >=20 > > > So, tunneling might be counter-productive here. > > >=20 > > > (Note that the situation is slightly different when your home > > > networks support v6, but the network you roam to, doesn't.) > >=20 > > Maybe. But if the hurdle to go native is too high then we=20 > have no IPv6=20 > > at all. And that's even worse! > >=20 > > Native IPv6 will come once IPv6 usage takes up and apps are around=20 > > that use IPv6. But to initiate the app development it is crucial to=20 > > have a network out that supports IPv6. This network has to be built=20 > > without business case. Therefore, tunneling is the only way=20 > to do this=20 > > IMHO. > >=20 > > I don't think that this is counter-productive here. >=20 > I'm not saying the networks have to be native through-out. =20 > Tunneling can very well be applied in many places if folks=20 > feel like it. However, recommending tunneling at the 3GPP=20 > network <-> UE interface would have a significant impact on=20 > how 3GPP networks would get deployed & implemented. =20 > The changes at this interface would not be transparent. True. But I still think that recommending a tunneling approach to the UE would help a lot to convince operators making the first steps to the IPv6 introduction. Remember, that this is just a first step. And, the native solution would follow within 1-2 years (which would again bring transparency back). >=20 > > > > I still think that having tunneling mechanisms in the v6ops > > > standards > > > > is a good thing and would convince more service providers to do=20 > > > > the > > > > first steps of the IPv6 introduction. And this is needed to=20 > > > spread out > > > > IPv6 to the users and service developers to facilitate the > > > development > > > > of services using IPv6 which will finally lead to the full > > > success of > > > > IPv6. > > >=20 > > > There is a doubt that such mechanisms are counter-productive > > > for IPv6 deployment (see above for example), and whether such=20 > > > mechanisms could be done reliably/easily/robustly/etc. enough=20 > > > without infl uencing too much on what must be done at the UE=20 > > > side (I'd prefer to keep that minimal). > >=20 > > I don't care too much about reliability/robustness/etc of the first=20 > > IPv6 introduction step. >=20 > Oh, you should care! :-) It has been a reason why IPv6=20 > deployment hasn't=20 > kicked off yet. A reason why vendors aren't putting on v6 by=20 > default,=20 > etc. Everything is about reliability and robustness. If=20 > folks try IPv6,=20 > and it doesn't work, they're not likely to try again any time soon! Well, from our experience (running an ISATAP solution almost half a year operationally in our fixed network) we have seen that tunneling mechanisms like ISATAP are robust enough if not as robust as native solutions. The main difference is performance. And performance is anyway bad in today's 2.5/3G networks and applications using these networks are used to bad performance. Therefore, it is not that a big issue. >=20 > For a couple of perspectives, have a look at:=20 > http://www.netcore.fi/pekkas/ietf/draft-> savola-v6ops-6bone-mess-01.txt > http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefa ult-01.txt > By the way, often 3G UE will be used as modem for > PCs. And, on the PC side tunneling mechanisms are already implemented=20 > and very easy to use (at least in the case of Windows XP with ISATAP). This has nothing to do with 3GPP (except that it's done on top of v4 3GPP network), right? The UE doesn't know anything of v6, and the 3GPP network doesn't know anything of v6. The 3GPP operator is just acting as an IPv4 ISP, offering tunneled v6 service for folks using its private v4 addresses? =3D> yes. But the operator has to place the tunnel server in its Gi backbone because he is generally using private IPv4 address space and the user cannot use a tunnel server in the Internet therefore. Furthermore, the UE will probably soon also implement tunneling mechanism (we are asking SonyEricsson and Nokia to implement ISATAP in their handsets). =20 > I see tunneling as a quite easy and cheap mechanism to bring IPv6 to=20 > the users. As in the IPv4-Internet, applications will just appear. And > once they appear for IPv6, native IPv6 will be needed (robustness,=20 > etc) but the business case will be there to do this! I fear the robustness etc. which you shrug away are preconditions for more=20 generic deployment and application development. =3D> as stated above, tunneling is quite robust. Just performance is a problem. But application development is exactly the reason why I am in favor of a quick (and dirty) IPv6 introduction in the networks. You know, it's a quicken-egg problem. We have to see that we "lay the egg" as soon as possible to let application developers start implementing applications using IPv6. And tunneling is for me one very viable way to do the first step (of course it is still somehow "quick and dirty"). Remember, that sometimes it is better to go for a 80/20 solution than to wait for the 100% solution... Regards Andreas --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Oct 7 05:05:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23981 for ; Tue, 7 Oct 2003 05:05:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6nd0-000OME-K3 for v6ops-data@psg.com; Tue, 07 Oct 2003 08:55:34 +0000 Received: from [158.38.62.77] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6ncS-000Nx2-77 for v6ops@ops.ietf.org; Tue, 07 Oct 2003 08:55:00 +0000 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id BE98A292C2; Tue, 7 Oct 2003 10:54:58 +0200 (CEST) Date: Tue, 07 Oct 2003 10:54:58 +0200 (CEST) Message-Id: <20031007.105458.105235812.he@uninett.no> To: Andreas.Schmid1@swisscom.com Cc: pekkas@netcore.fi, Juha.Wiljakka@nokia.com, Karim.El-Malki@ericsson.com, v6ops@ops.ietf.org Subject: Re: 3GPP and 'not touching a running system' From: Havard Eidnes In-Reply-To: <595362761E89B640A907F5112F8B89B801FBBF74@sxmbx03.corproot.net> References: <595362761E89B640A907F5112F8B89B801FBBF74@sxmbx03.corproot.net> X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, guys, please allow myself to supply a remark on the style of the text in this e-mail discussion: it really would make it so much easier for those of us trying to follow the discussion from the sidelines if a few simple and commonly accepted rules were adhered to with regard to quoting of material: 1) please cut down on the included comments to narrow down to just what you are commenting on. Adding 5 lines of your own text to 100 lines of (recursively) included comments makes it unneccessarily hard to find the 5 new lines, especially in combination with violations of rule number 2 below. 2) it would make it much easier to follow the discussion if the commonly accepted quoting practice of "indent each line with '> '" was adhered to. The alternative makes it Really Difficult to see who said what, as in > This has nothing to do with 3GPP (except that it's done on top of v4 > 3GPP network), right? The UE doesn't know anything of v6, and the 3G= PP > network doesn't know anything of v6. The 3GPP operator is just actin= g > as an IPv4 ISP, offering tunneled v6 service for folks using its priv= ate > v4 addresses? > > =3D> yes. But the operator has to place the tunnel server in its Gi > backbone because he is generally using private IPv4 address space and= > the user cannot use a tunnel server in the Internet therefore. > Furthermore, the UE will probably soon also implement tunneling > mechanism (we are asking SonyEricsson and Nokia to implement ISATAP i= n > their handsets). Inserting an inconspicious "=3D>" at the front of a possibly multi-paragraph reply (just a single paragraph here, I'll concede) doesn't quite provide the same visual cues that the "indent every included line with '> '" does. And the message I'm replying to was signed: > Regards > Andreas > > > -- = > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Now, who wrote this?!? ;-) I now return you to the discussion at hand. Regards, - H=E5vard From owner-v6ops@ops.ietf.org Tue Oct 7 15:06:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17140 for ; Tue, 7 Oct 2003 15:06:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6x2V-0009FI-Ky for v6ops-data@psg.com; Tue, 07 Oct 2003 18:58:31 +0000 Received: from [127.0.0.1] (helo=roam.psg.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6x2P-0009Ee-FQ for v6ops@ops.ietf.org; Tue, 07 Oct 2003 18:58:29 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by roam.psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6x2F-000Jy2-Ls for v6ops@ops.ietf.org; Tue, 07 Oct 2003 11:58:15 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE807E19A@TMS031MB.tcad.telia.se> Thread-Topic: WG Last Call: 3GPP Analysis Document Thread-Index: AcOGr9LJivg/OMT7RBiUJkRAky9FoQGK97qQ Subject: RE: WG Last Call: 3GPP Analysis Document Date: Tue, 7 Oct 2003 18:21:50 +0200 From: To: X-Spam-Status: No, hits=1.1 required=5.0 tests=NO_REAL_NAME version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] here are some more comments on this document: ---- 3.2.2 Tunneling outside the 3GPP Operator's Network=20 =20 This subsection includes the case when the peer node is outside the=20 operator's network. In that case the IPv6-in-IPv4 tunnel starting=20 point can be in the operator's network - encapsulating node can be=20 e.g. the GGSN or the edge router.=20 =20 The case is pretty straightforward if the upstream ISP provides=20 native IPv6 connectivity to the Internet. If there is no native=20 IPv6 connectivity available in the 3GPP network, an IPv6-in-IPv4=20 tunnel should be configured from e.g. the GGSN to the dual stack=20 border gateway in order to access the upstream ISP.=20 =20 If the ISP only provides IPv4 connectivity, then the IPv6 traffic=20 initiated from the 3GPP network should be transported tunneled in=20 IPv4 to the ISP.=20 =20 Usage of configured IPv6-in-IPv4 tunneling is recommended. As the=20 number of the tunnels outside of the 3GPP network is limited, no=20 more than a couple of tunnels should be needed.=20 =20 ISP transition scenarios are described in [ISP-scen].=20 ---- =20 it is somehow difficult to follow this section. there are three important parts here: gprs access network, 3gpp ip backbone (if the 3gpp operator has one) and upstream isp. it is hard to decide which is which in the text. is this what is meant or something else? This subsection includes the case when the peer node is outside the operator's network. In that case an IPv6-in-IPv4 tunnel should be configured in order to obtain IPv6 connectivity and reach other IPv6 nodes. Starting point can be in the operator's network and will depend on how far the 3GPP operator has come in implementing IPv6. If the 3GPP operator does not have an IP backbone or has not implemented IPv6 in the backbone, the encapsulating node can be the GGSN. If the 3GPP operator does have an own IP backbone, and has implemented IPv6, but upstream ISP does not provide IPv6 connectivity to the Internet, the encapsulating node can be the edge router.=20 =20 The case is pretty straightforward if the upstream ISP provides=20 IPv6 connectivity to the Internet. In that case the 3GPP operator does not have to configure any tunnels, since the upstream ISP will take care of routing IPv6 packets. If the upstream ISP does not provide IPv6 connectivity, an IPv6-in-IPv4 tunnel should be configured from e.g. the edge router to a dual stack border gateway operated by another ISP which is offering IPv6 connectivity. Usage of configured IPv6-in-IPv4 tunneling is recommended. As the=20 number of the tunnels outside of the 3GPP network is limited, no=20 more than a couple of tunnels should be needed.=20 jasminko From owner-v6ops@ops.ietf.org Tue Oct 7 15:40: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 PAA19057 for ; Tue, 7 Oct 2003 15:40:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A6xca-000Dmo-3w for v6ops-data@psg.com; Tue, 07 Oct 2003 19:35:48 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A6xXY-000DEh-1e for v6ops@ops.ietf.org; Tue, 07 Oct 2003 19:30:36 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h97JUMW15596; Tue, 7 Oct 2003 12:30:22 -0700 X-mProtect: <200310071930> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBGmQT7; Tue, 07 Oct 2003 12:30:20 PDT Message-ID: <3F83151A.5030602@iprg.nokia.com> Date: Tue, 07 Oct 2003 12:33:46 -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: "Follen, Stephen" , v6ops@ops.ietf.org Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,RCVD_IN_OSIRUSOFT_COM, REFERENCES,USER_AGENT_MOZILLA_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: >On Mon, 6 Oct 2003, Fred Templin wrote: > > >>Pekka Savola wrote: >> >> >[...] > > >>>3) "node receives packets through a valid tunnel which fail IPv6 ingress >>>filtering tests" >>> >>>==> silently discard, I think (if ingress filtering fails, the error >>>won't probably get back anyway) >>> >>> >>> >>In case 3) above, send an ICMPv6 DU to the originating source. >> >>It might not get back, but may very well help the situation >>in the decapsulator for the next time around... >> >> > >Huh? Which node do you refer by decapsulator -- the one sending ICMPv6 >DU, or the one receiving it (over the tunnel) and decapsulating it? > The former (i.e., the one sending ICMPv6 DU). But, you seem to be assuming that it would be sent back over the bidirectional tunnel from which the original packet arrived. I am not. >If the former, I don't really understand how sending a reply would help. > Well, it could elicit an ICMPv6 Redirect from a router that would provide information satisfying future ingress filter checks in the decapsulator, it could provide a traceback mechanism to detect IPv6 source address spoofing attacks, etc. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Oct 8 02:49:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04035 for ; Wed, 8 Oct 2003 02:49:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A780w-000NEq-23 for v6ops-data@psg.com; Wed, 08 Oct 2003 06:41:38 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A780Q-000NCA-4s for v6ops@ops.ietf.org; Wed, 08 Oct 2003 06:41:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h986f2Y19880 for ; Wed, 8 Oct 2003 09:41:02 +0300 Date: Wed, 8 Oct 2003 09:41:01 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Making discussion easier... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_PINE version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, Thanks Havard for reminding us. Sometimes we forget to tail down the responses to be readable. Let's try to remember these to make the discussion more useful. My personal favourites are: - don't quote a lot, and avoid dozens of levels of recursive quoting, and - change the Subject title as appropriate Pekka writing as co-chair ---------- Forwarded message ---------- Date: Tue, 07 Oct 2003 10:54:58 +0200 (CEST) From: Havard Eidnes To: Andreas.Schmid1@swisscom.com Cc: pekkas@netcore.fi, Juha.Wiljakka@nokia.com, Karim.El-Malki@ericsson.com, v6ops@ops.ietf.org Subject: Re: 3GPP and 'not touching a running system' Hi, guys, please allow myself to supply a remark on the style of the text in this e-mail discussion: it really would make it so much easier for those of us trying to follow the discussion from the sidelines if a few simple and commonly accepted rules were adhered to with regard to quoting of material: 1) please cut down on the included comments to narrow down to just what you are commenting on. Adding 5 lines of your own text to 100 lines of (recursively) included comments makes it unneccessarily hard to find the 5 new lines, especially in combination with violations of rule number 2 below. 2) it would make it much easier to follow the discussion if the commonly accepted quoting practice of "indent each line with '> '" was adhered to. The alternative makes it Really Difficult to see who said what, as in > This has nothing to do with 3GPP (except that it's done on top of v4 > 3GPP network), right? The UE doesn't know anything of v6, and the 3GPP > network doesn't know anything of v6. The 3GPP operator is just acting > as an IPv4 ISP, offering tunneled v6 service for folks using its private > v4 addresses? > > => yes. But the operator has to place the tunnel server in its Gi > backbone because he is generally using private IPv4 address space and > the user cannot use a tunnel server in the Internet therefore. > Furthermore, the UE will probably soon also implement tunneling > mechanism (we are asking SonyEricsson and Nokia to implement ISATAP in > their handsets). Inserting an inconspicious "=>" at the front of a possibly multi-paragraph reply (just a single paragraph here, I'll concede) doesn't quite provide the same visual cues that the "indent every included line with '> '" does. And the message I'm replying to was signed: > Regards > Andreas > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Now, who wrote this?!? ;-) I now return you to the discussion at hand. Regards, - Håvard From owner-v6ops@ops.ietf.org Wed Oct 8 06:56: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 GAA09421 for ; Wed, 8 Oct 2003 06:56:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7Bpm-000BrW-SW for v6ops-data@psg.com; Wed, 08 Oct 2003 10:46:22 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7BpH-000Bpw-9e for v6ops@ops.ietf.org; Wed, 08 Oct 2003 10:45:51 +0000 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h98Ajn611047 for ; Wed, 8 Oct 2003 13:45:49 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 8 Oct 2003 13:45:49 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 8 Oct 2003 13:45:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Last Call: 3GPP Analysis Document Date: Wed, 8 Oct 2003 13:45:48 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDF30@esebe005.ntc.nokia.com> Thread-Topic: WG Last Call: 3GPP Analysis Document Thread-Index: AcOGr9LJivg/OMT7RBiUJkRAky9FoQGK97qQACnzMWA= From: To: Cc: X-OriginalArrivalTime: 08 Oct 2003 10:45:49.0147 (UTC) FILETIME=[561FDAB0:01C38D89] X-Spam-Status: No, hits=1.1 required=5.0 tests=BAYES_30,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Jasiminko! Thanks for your comments! It is true that the current text may not be clear enough - and I think = your suggested text is mostly fine. I made some minor modifications in = it (see below): ---- This subsection includes the case in which the peer node is outside the operator's network. In that case IPv6-in-IPv4 tunneling can be necessary to obtain IPv6 connectivity and reach other IPv6 nodes. Tunnel starting point can be in the operator's network depending on how far the 3GPP operator has come in implementing IPv6. If the=20 3GPP operator does not have an IP backbone, or has not=20 implemented IPv6 in it, the encapsulating node can be the GGSN.=20 If the 3GPP operator has an IP backbone, and has implemented=20 IPv6 in it, but the upstream ISP does not provide IPv6 connectivity=20 to the Internet, the encapsulating node can be the edge router. The case is pretty straightforward if the upstream ISP provides=20 IPv6 connectivity to the Internet and the operator's backbone network supports IPv6. Then the 3GPP operator does not have to configure any tunnels, since the upstream ISP will take care of routing IPv6 packets. If the upstream ISP does not provide IPv6 connectivity,=20 an IPv6-in-IPv4 tunnel should be configured e.g. from the edge=20 router to a dual stack border gateway operated by another ISP which is offering IPv6 connectivity. In the tunneling scenarios above, usage of configured IPv6-in-IPv4=20 tunneling is recommended. As the number of the tunnels outside of the 3GPP network is limited, no more than a couple of tunnels=20 should be needed. ---- By the way, did you intentionally leave the [ISP-scen] reference out? = That might be rational, because that reference is already mentioned in = 3.2 just before subsection 3.2.1. Cheers, -Juha- -----Original Message----- From: ext [mailto:Jasminko.Mulahusic@teliasonera.com] Sent: 07 October, 2003 19:22 ---- 3.2.2 Tunneling outside the 3GPP Operator's Network=20 =20 This subsection includes the case when the peer node is outside the=20 operator's network. In that case the IPv6-in-IPv4 tunnel starting=20 point can be in the operator's network - encapsulating node can be=20 e.g. the GGSN or the edge router.=20 =20 The case is pretty straightforward if the upstream ISP provides=20 native IPv6 connectivity to the Internet. If there is no native=20 IPv6 connectivity available in the 3GPP network, an IPv6-in-IPv4=20 tunnel should be configured from e.g. the GGSN to the dual stack=20 border gateway in order to access the upstream ISP.=20 =20 If the ISP only provides IPv4 connectivity, then the IPv6 traffic=20 initiated from the 3GPP network should be transported tunneled in=20 IPv4 to the ISP.=20 =20 Usage of configured IPv6-in-IPv4 tunneling is recommended. As the=20 number of the tunnels outside of the 3GPP network is limited, no=20 more than a couple of tunnels should be needed.=20 =20 ISP transition scenarios are described in [ISP-scen].=20 ---- =20 it is somehow difficult to follow this section. there are three important parts here: gprs access network, 3gpp ip backbone (if the 3gpp operator has one) and upstream isp. it is hard to decide which is which in the text. is this what is meant or something else? This subsection includes the case when the peer node is outside the operator's network. In that case an IPv6-in-IPv4 tunnel should be configured in order to obtain IPv6 connectivity and reach other IPv6 nodes. Starting point can be in the operator's network and will depend on how far the 3GPP operator has come in implementing IPv6. If the 3GPP operator does not have an IP backbone or has not implemented IPv6 in the backbone, the encapsulating node can be the GGSN. If the 3GPP operator does have an own IP backbone, and has implemented IPv6, but upstream ISP does not provide IPv6 connectivity to the Internet, the encapsulating node can be the edge router.=20 =20 The case is pretty straightforward if the upstream ISP provides=20 IPv6 connectivity to the Internet. In that case the 3GPP operator does not have to configure any tunnels, since the upstream ISP will take care of routing IPv6 packets. If the upstream ISP does not provide IPv6 connectivity, an IPv6-in-IPv4 tunnel should be configured from e.g. the edge router to a dual stack border gateway operated by another ISP which is offering IPv6 connectivity. Usage of configured IPv6-in-IPv4 tunneling is recommended. As the=20 number of the tunnels outside of the 3GPP network is limited, no=20 more than a couple of tunnels should be needed.=20 jasminko From owner-v6ops@ops.ietf.org Wed Oct 8 10: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 KAA19966 for ; Wed, 8 Oct 2003 10:58:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7FdO-0001oG-Uh for v6ops-data@psg.com; Wed, 08 Oct 2003 14:49:50 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7Fcy-0001mb-Bj for v6ops@ops.ietf.org; Wed, 08 Oct 2003 14:49:24 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18699; Wed, 8 Oct 2003 10:49:14 -0400 (EDT) Message-Id: <200310081449.KAA18699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-6to4-security-00.txt Date: Wed, 08 Oct 2003 10:49:13 -0400 X-Spam-Status: No, hits=3.8 required=5.0 tests=MIME_BOUND_NEXTPART,NO_REAL_NAME,RCVD_IN_OSIRUSOFT_COM, TO_MALFORMED version=2.55 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Security Considerations for 6to4 Author(s) : P. Savola Filename : draft-ietf-v6ops-6to4-security-00.txt Pages : 32 Date : 2003-10-8 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 Routers and Relay Routers, which accept and decapsulate IPv4 protocol-41 ('IPv6-in-IPv4') traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-6to4-security-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-6to4-security-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-10-8102639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-6to4-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-8102639.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 10 03:30: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 DAA12518 for ; Fri, 10 Oct 2003 03:30:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7rY2-0007so-4h for v6ops-data@psg.com; Fri, 10 Oct 2003 07:18:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7rXh-0007s0-Hx for v6ops@ops.ietf.org; Fri, 10 Oct 2003 07:18:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9A7HuQ25024; Fri, 10 Oct 2003 10:17:57 +0300 Date: Fri, 10 Oct 2003 10:17:56 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Follen, Stephen" , Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 In-Reply-To: <3F83151A.5030602@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_10 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 7 Oct 2003, Fred Templin wrote: > Pekka Savola wrote: > >Huh? Which node do you refer by decapsulator -- the one sending ICMPv6 > >DU, or the one receiving it (over the tunnel) and decapsulating it? > > The former (i.e., the one sending ICMPv6 DU). But, you seem > to be assuming that it would be sent back over the bidirectional > tunnel from which the original packet arrived. I am not. What are the scenarios where you wouldn't use bidirectional tunneling? It has been considered to kill unidirectional tunnels from trans-mech-bis, and it would be useful to know whether they're really relevant. > >If the former, I don't really understand how sending a reply would help. > > Well, it could elicit an ICMPv6 Redirect from a router that would > provide information satisfying future ingress filter checks in the > decapsulator, it could provide a traceback mechanism to detect > IPv6 source address spoofing attacks, etc. Do you have more information on these? I fail to see how Redirects would help here, as the source address selection is already done at that phase, and Redirects only look at the destination addresses, as far as I've understood. I'd like to understand how useful this would be before going forward with it. Sending packets to ingress-filtered sources may only aggravate the problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 10 03:48: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 DAA12953 for ; Fri, 10 Oct 2003 03:48:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7rxv-0008pV-FM for v6ops-data@psg.com; Fri, 10 Oct 2003 07:45:35 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7rxq-0008pE-Pz for v6ops@ops.ietf.org; Fri, 10 Oct 2003 07:45:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9A7j0N25333; Fri, 10 Oct 2003 10:45:00 +0300 Date: Fri, 10 Oct 2003 10:44:59 +0300 (EEST) From: Pekka Savola To: Andreas.Schmid1@swisscom.com cc: juha.wiljakka@nokia.com, , Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] In-Reply-To: <595362761E89B640A907F5112F8B89B801FBBF74@sxmbx03.corproot.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_10 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Clipping the text quite a bit and tailing it down.. On Tue, 7 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > [me:] > > I'm not saying the networks have to be native through-out. > > Tunneling can very well be applied in many places if folks > > feel like it. However, recommending tunneling at the 3GPP > > network <-> UE interface would have a significant impact on > > how 3GPP networks would get deployed & implemented. > > The changes at this interface would not be transparent. > > True. But I still think that recommending a tunneling approach to the UE > would help a lot to convince operators making the first steps to the > IPv6 introduction. Remember, that this is just a first step. And, the > native solution would follow within 1-2 years (which would again bring > transparency back). I'm not sure how much that would help. There seem to be two cases, one with two subcases here: 1) UE is used as a "modem" for a laptop (seems common in current GPRS networks) o UE doesn't have to know about IPv6 at all o UE implements only IPv4 stack, and not even much of that o The laptop performs the tunneling and has IPv6 ==> this is not really (IMHO) a 3GPP scenario, but could perhaps be considered here as the "zeroeth step". The solutions are probably pretty much the same as with Unmanaged/ISP scenarios behind NAT. One could employ some tunneling mechanism at the laptop. 2) UE is used standalone or as IPv6 router for a laptop o UE implements IPv6 o Native IPv6 packets flow between the UE and the laptop (if plugged in) o UE acts as an IPv6 router/bridge for the laptop o compared to the above, useful mostly if you want IPv6 connectivity at the UE as well as the laptop a) UE uses an IPv6 PDP context for its IPv6 connectivity ==> pretty straightforward, and long term good approach ==> in all other cases than this, the user pays (money, performance) for the IPv6 tunneling overhead. b) UE uses a form of tunneling for its IPv6 connectivity ==> putting complexity to the UE ==> which are the cases where 1) above is not applicable? ==> could configured tunneling be made to work? My initial take on this is that 1) would probably be pretty useful in the short term, but doesn't really require much at all. 2.b) seems like a case which is not so short-term solution, maybe needed if the UE implements and wants to use IPv6 services itself -- but aren't we then already quite far in the transition process, and IPv6 PDP context should be used instead. (Are there other cases, like the laptop initiating a PDP context of its own or something.. I'm not sure..) > => as stated above, tunneling is quite robust. Just performance is a > problem. But application development is exactly the reason why I am in > favor of a quick (and dirty) IPv6 introduction in the networks. You > know, it's a quicken-egg problem. We have to see that we "lay the egg" > as soon as possible to let application developers start implementing > applications using IPv6. And tunneling is for me one very viable way to > do the first step (of course it is still somehow "quick and dirty"). > Remember, that sometimes it is better to go for a 80/20 solution than to > wait for the 100% solution... I agree that some simple forms of tunneling, at least (configured tunnels, what more do you need? :-) can be rather robust. The more complexity you add, the more fragile it gets. But I'm not sure whether the tunnels (especially the more complex forms of) are best applicable in 3GPP networks; the tunneling is absolutely a major way in some other cases, like unmanaged networks. The 3GPP scenarios are supposed to be somewhat special. -- 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 Oct 10 05:57: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 FAA15936 for ; Fri, 10 Oct 2003 05:57:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7tvw-000Cww-6I for v6ops-data@psg.com; Fri, 10 Oct 2003 09:51:40 +0000 Received: from [212.198.2.71] (helo=smtp.noos.fr) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7tvZ-000Cw1-MN for v6ops@ops.ietf.org; Fri, 10 Oct 2003 09:51:17 +0000 Received: (qmail 3713551 invoked by uid 0); 10 Oct 2003 09:50:14 -0000 Received: (qmail 3154121 invoked by uid 0); 8 Oct 2003 15:46:12 -0000 Received: from unknown (HELO asgard.ietf.org) ([132.151.6.40]) (envelope-sender ) by 212.198.2.71 (qmail-ldap-1.03) with SMTP for ; 8 Oct 2003 15:46:12 -0000 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1A7G3p-0007Wi-74 for ietf-announce-list@asgard.ietf.org; Wed, 08 Oct 2003 11:17:09 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1A7Fcz-0007PS-Hj for all-ietf@asgard.ietf.org; Wed, 08 Oct 2003 10:49:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18699; Wed, 8 Oct 2003 10:49:14 -0400 (EDT) Message-Id: <200310081449.KAA18699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-6to4-security-00.txt Date: Wed, 08 Oct 2003 10:49:13 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Security Considerations for 6to4 Author(s) : P. Savola Filename : draft-ietf-v6ops-6to4-security-00.txt Pages : 32 Date : 2003-10-8 The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over- IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 Routers and Relay Routers, which accept and decapsulate IPv4 protocol-41 ('IPv6-in-IPv4') traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-6to4-security-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-6to4-security-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-10-8102639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-6to4-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-6to4-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-8102639.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 10 10:03: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 KAA28573 for ; Fri, 10 Oct 2003 10:03:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A7xkk-000LlH-Gz for v6ops-data@psg.com; Fri, 10 Oct 2003 13:56:22 +0000 Received: from [138.190.3.48] (helo=sbe3777.swissptt.ch) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A7xkc-000Lko-PR for v6ops@ops.ietf.org; Fri, 10 Oct 2003 13:56:15 +0000 Received: from sxmcmp01.corproot.net (138.190.70.99) by sbe3777.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Fri, 10 Oct 2003 15:56:12 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxsmtp01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Fri, 10 Oct 2003 15:55:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Date: Fri, 10 Oct 2003 15:55:47 +0200 Message-ID: <595362761E89B640A907F5112F8B89B802180568@sxmbx03.corproot.net> Thread-Topic: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Thread-Index: AcOPAm1Q0lw3LZ5wTS6MJAQsttdVGwAMOQRA From: To: CC: , , X-OriginalArrivalTime: 10 Oct 2003 13:55:47.0462 (UTC) FILETIME=[34E03260:01C38F36] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.7 required=5.0 tests=BAYES_10,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Clipping the text quite a bit and tailing it down.. >=20 > On Tue, 7 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > > [me:] > > > I'm not saying the networks have to be native through-out. > > > Tunneling can very well be applied in many places if folks=20 > > > feel like it. However, recommending tunneling at the 3GPP=20 > > > network <-> UE interface would have a significant impact on=20 > > > how 3GPP networks would get deployed & implemented. =20 > > > The changes at this interface would not be transparent. > >=20 > > True. But I still think that recommending a tunneling=20 > approach to the=20 > > UE would help a lot to convince operators making the first steps to=20 > > the IPv6 introduction. Remember, that this is just a first=20 > step. And,=20 > > the native solution would follow within 1-2 years (which=20 > would again=20 > > bring transparency back). >=20 > I'm not sure how much that would help. >=20 > There seem to be two cases, one with two subcases here: >=20 > 1) UE is used as a "modem" for a laptop (seems common in=20 > current GPRS=20 > networks) > o UE doesn't have to know about IPv6 at all > o UE implements only IPv4 stack, and not even much of that > o The laptop performs the tunneling and has IPv6 > =3D=3D> this is not really (IMHO) a 3GPP scenario, but could perhaps = be=20 > considered here as the "zeroeth step". The solutions are=20 > probably pretty=20 > much the same as with Unmanaged/ISP scenarios behind NAT. One could=20 > employ some tunneling mechanism at the laptop. True, but we made quite bad experiences with this kind of tunneling mechanisms (Teredo). They are not stable enough and really just a hack.=20 I think, that even if it's not a "real" 3GPP scenario, the (3GPP) service provider could offer the IPv6 tunnel server to get an acceptable performance. We are looking at what is available in commercial products today. Most of our customers are using Windows (even if we don't like it - it's a fact). And there, you have Teredo, ISATAP and 6to4 as automatic tunneling mechanisms (I don't count on configured tunnels since the user should not have to configure anything for IPv6). Teredo is not really stable and very complex. 6to4 is just applicable if you have a public address (and this is not the case for most if not all 3GPP networks of today). So ISATAP seems to be the solution of choice?!? Of course, you could argue that you could convince Microsoft to implement something else. But this could be difficult.... >=20 > 2) UE is used standalone or as IPv6 router for a laptop > o UE implements IPv6 > o Native IPv6 packets flow between the UE and the laptop=20 > (if plugged in) > o UE acts as an IPv6 router/bridge for the laptop > o compared to the above, useful mostly if you want IPv6=20 > connectivity at=20 > the UE as well as the laptop >=20 > a) UE uses an IPv6 PDP context for its IPv6 connectivity > =3D=3D> pretty straightforward, and long term good approach Right. But still, the operations department don't want this today (I am repeating this again. But you can believe me this!) > =3D=3D> in all other cases than this, the user pays (money,=20 > performance)=20 > for the IPv6 tunneling overhead. Yes, but it's not much.... >=20 > b) UE uses a form of tunneling for its IPv6 connectivity > =3D=3D> putting complexity to the UE Yes, I know this is probably only useful for smartphones... > =3D=3D> which are the cases where 1) above is not applicable? Where you want to use an application on the handset that is only running on IPv6. > =3D=3D> could configured tunneling be made to work? No, we need automatic tunnels. Configuring the handsets is already too complex for our customers! We need something plug&play... >=20 > My initial take on this is that 1) would probably be pretty=20 > useful in the=20 > short term, but doesn't really require much at all. 2.b)=20 > seems like a=20 > case which is not so short-term solution, maybe needed if the UE=20 > implements and wants to use IPv6 services itself -- but=20 > aren't we then=20 > already quite far in the transition process, and IPv6 PDP=20 > context should=20 > be used instead. I hope that IPv6-capable apps will appear soon - even for use on the handsets. I am talking to game developers and try to tell them what the advantages are of IPv6. Remember that IPv6 is an enabler. The services will not be developed if the network is not there. If we put the network there (cheap but still automatic) the services will appear. But if we wait for the services to implement IPv6 to the handsets this will never happen.... >=20 > (Are there other cases, like the laptop initiating a PDP=20 > context of its=20 > own or something.. I'm not sure..) No idea, but I don't see them. >=20 > > =3D> as stated above, tunneling is quite robust. Just=20 > performance is a=20 > > problem. But application development is exactly the reason=20 > why I am in=20 > > favor of a quick (and dirty) IPv6 introduction in the networks. You=20 > > know, it's a quicken-egg problem. We have to see that we=20 > "lay the egg"=20 > > as soon as possible to let application developers start=20 > implementing=20 > > applications using IPv6. And tunneling is for me one very=20 > viable way=20 > > to do the first step (of course it is still somehow "quick and=20 > > dirty"). Remember, that sometimes it is better to go for a 80/20=20 > > solution than to wait for the 100% solution... >=20 > I agree that some simple forms of tunneling, at least=20 > (configured tunnels, what more do you need? :-)=20 Configured tunnels are not what we want (see my remark above).=20 > can be rather=20 > robust. The more complexity you add, the more fragile it gets. Yes, but a solution like ISATAP is quite stable (as said in an earlier mail, we use it in our operational intranet for months without problems). >=20 > But I'm not sure whether the tunnels (especially the more=20 > complex forms > of) are best applicable in 3GPP networks; the tunneling is=20 > absolutely a major way in some other cases, like unmanaged=20 > networks. The 3GPP scenarios are supposed to be somewhat special. As said above, I would not see 3GPP networks as unmanaged networks..... This is a long discussion we have. I am not that used to IETF mailing lists. But I am happy to send you my comments off the list if you like. Just respond me off the list if you think this is better. Regards Andreas From owner-v6ops@ops.ietf.org Fri Oct 10 15:44: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 PAA16553 for ; Fri, 10 Oct 2003 15:44:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A835k-0009JT-5M for v6ops-data@psg.com; Fri, 10 Oct 2003 19:38:24 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A835h-0009J8-Et for v6ops@ops.ietf.org; Fri, 10 Oct 2003 19:38:21 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15647; Fri, 10 Oct 2003 15:38:11 -0400 (EDT) Message-Id: <200310101938.PAA15647@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-firewalling-02.txt Date: Fri, 10 Oct 2003 15:38:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.7 required=5.0 tests=BAYES_44,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Firewalling Considerations for IPv6 Author(s) : P. Savola Filename : draft-savola-v6ops-firewalling-02.txt Pages : 15 Date : 2003-10-10 There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end- to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-firewalling-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-firewalling-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-10143117.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-firewalling-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-firewalling-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-10143117.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Sat Oct 11 19:18: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 TAA16796 for ; Sat, 11 Oct 2003 19:18:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8Snw-000ENv-Ln for v6ops-data@psg.com; Sat, 11 Oct 2003 23:05:44 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8Snp-000ENc-JJ for v6ops@ops.ietf.org; Sat, 11 Oct 2003 23:05:37 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9BN5X5R020643; Sat, 11 Oct 2003 16:05:34 -0700 (PDT) Received: from cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AML07173; Sat, 11 Oct 2003 16:01:06 -0700 (PDT) Message-ID: <3F888CBC.6050909@cisco.com> Date: Sat, 11 Oct 2003 16:05:32 -0700 From: Fred Baker Reply-To: v6ops@ops.ietf.org Organization: Cisco Systems, IOS Technologies Division User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: fred@cisco.com, rdroms@cisco.com, lear@cisco.com, Pekka Savola , jonne.soininen@nokia.com, bob@thefinks.com, randy@psg.com, bwijnen@lucent.com Subject: draft-baker-ipv6-renumber-procedure-01.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Apologies if you receive something like this twice. I sent such a note yesterday morning, and I have yet to see it on the reflector. I suspect that it is either stuck in a queue or a casualty of whatever ate ietf.org yesterday. Document in question: http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-01.txt Ralph Droms, Eliot Lear, and I are soliciting commentary on the above. If accepted by the working group, it will be updated according to working group comments and republished as draft-ietf-v6ops-renumber-procedure... The intent of the draft is three-fold. First, if I was a network operator and someone told me to renumber my network, any suggestions as to how to do so would be welcome. This document is intended to propose a first draft of that procedure, to be seasoned to taste and employed by the network operator faced with that task. Second, there is a bit of a debate in the community on the topic of renumbering, with some saying "solved problem" and others saying "my worst nightmare". Reality is almost assuredly somewhere in between: there are operational aspects of this which not technological and are far from being solved problems, and aspects where IPv6 technologies do in fact make a problem that is *really* hard in IPv4 a little easier. In this sense, the document is intended to help each side of that debate understand the viewpoint of the other and hopefully produce a better discussion. Something that is sure to come out of the discussion is a set of action items for various vendors and various working groups. Pekka's document on proposals to improve ingress filtering is an example of such an effort. It doesn't have anything to do with renumbering, but points out issues that renumbering exacerbates, and suggests approaches to dealing with them. One could imagine similar lessons learned - and potentially, protocols or procedures improved - for other IPv6-related protocols or operational procedures. I will be giving a breif talk on the topic, and then we will go to open discussion, with the authors in the room. Constructive comments on the document, especially if they include proposed text, are welcome, and should be sent to the list. -- /=====================================================================/ | Fred Baker | 1121 Via Del Rey | | Cisco Fellow | Santa Barbara, California | +--------------------------------+ 93117 USA | | Nothing will ever be attempted,| phone: +1-408-526-4257 | | if all possible objections must| fax: +1-413-473-2403 | | be first overcome. | mobile:+1-805-637-0529 | | Dr. Johnson, Rasselas, 1759| | /=====================================================================/ From owner-v6ops@ops.ietf.org Mon Oct 13 02:47:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24894 for ; Mon, 13 Oct 2003 02:47:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8wJg-000GEl-FL for v6ops-data@psg.com; Mon, 13 Oct 2003 06:36:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8wJa-000GDm-64 for v6ops@ops.ietf.org; Mon, 13 Oct 2003 06:36:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9D6ZWK10480; Mon, 13 Oct 2003 09:35:32 +0300 Date: Mon, 13 Oct 2003 09:35:31 +0300 (EEST) From: Pekka Savola To: Andreas.Schmid1@swisscom.com cc: juha.wiljakka@nokia.com, , Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] In-Reply-To: <595362761E89B640A907F5112F8B89B802180568@sxmbx03.corproot.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 10 Oct 2003 Andreas.Schmid1@swisscom.com wrote: > > There seem to be two cases, one with two subcases here: > > > > 1) UE is used as a "modem" for a laptop (seems common in > > current GPRS > > networks) > > o UE doesn't have to know about IPv6 at all > > o UE implements only IPv4 stack, and not even much of that > > o The laptop performs the tunneling and has IPv6 > > ==> this is not really (IMHO) a 3GPP scenario, but could perhaps be > > considered here as the "zeroeth step". The solutions are > > probably pretty > > much the same as with Unmanaged/ISP scenarios behind NAT. One could > > employ some tunneling mechanism at the laptop. > > True, but we made quite bad experiences with this kind of tunneling > mechanisms (Teredo). They are not stable enough and really just a hack. Note that nowhere did I imply anything about Teredo at all. But I guess that's easily assumed by a reader.. :-) > I think, that even if it's not a "real" 3GPP scenario, the (3GPP) > service provider could offer the IPv6 tunnel server to get an acceptable > performance. No disagreement there, I certainly think this would be a very useful approach for many service providers. > We are looking at what is available in commercial products today. Most > of our customers are using Windows (even if we don't like it - it's a > fact). And there, you have Teredo, ISATAP and 6to4 as automatic > tunneling mechanisms (I don't count on configured tunnels since the user > should not have to configure anything for IPv6). Configured tunneling methods don't need to be manually configured, unless you want them to be (see more below). > Teredo is not really stable and very complex. 6to4 is just applicable if > you have a public address (and this is not the case for most if not all > 3GPP networks of today). Right.. > So ISATAP seems to be the solution of choice?!? > Of course, you could argue that you could convince Microsoft to > implement something else. But this could be difficult.... I suppose one can run your own applications on top of a Microsoft operating system. For example, a very simple GUI application which transparently configures/unconfigures configured tunnels. Shouldn't be too difficult. The point is, the current basic transition mechanism framework gives a lot of tools, if one is just willing to take them and use them. > > 2) UE is used standalone or as IPv6 router for a laptop > > o UE implements IPv6 > > o Native IPv6 packets flow between the UE and the laptop > > (if plugged in) > > o UE acts as an IPv6 router/bridge for the laptop > > o compared to the above, useful mostly if you want IPv6 > > connectivity at > > the UE as well as the laptop > > > > a) UE uses an IPv6 PDP context for its IPv6 connectivity > > ==> pretty straightforward, and long term good approach > > Right. But still, the operations department don't want this today (I am > repeating this again. But you can believe me this!) Some operators probably see this as more desirable than others. [...] > > b) UE uses a form of tunneling for its IPv6 connectivity > > ==> putting complexity to the UE > > Yes, I know this is probably only useful for smartphones... > > > ==> which are the cases where 1) above is not applicable? > > Where you want to use an application on the handset that is only running > on IPv6. Right. The question is, is this scenario near-term enough? Couldn't we be able to proceed with just "laptop tunneling" and recommending using IPv6 PDP context when the phones leveraging IPv6 emerge? > > ==> could configured tunneling be made to work? > > No, we need automatic tunnels. Configuring the handsets is already too > complex for our customers! We need something plug&play... Note that "configured tunneling" refers to _somehow_ configuring the tunnel endpoints. The configuration itself need not be done manually by the user. At the face value, this may not be obvious.. For example, one might be able to use a number of different Over the Air techniques for configuring the tunnel -- see the section in the analysis document? (I haven't discussed whether this is possible with 3GPP experts, but I don't see any reason why not..) [...] > Remember that IPv6 is an enabler. The services will not be developed if > the network is not there. If we put the network there (cheap but still > automatic) the services will appear. But if we wait for the services to > implement IPv6 to the handsets this will never happen.... Some others would probably count adding a few new 3GPP IPv6 features (as a start-up phase installation, until the services are there) as an acceptably cheap and automatic mechanism -- one which could be expanded easily when needed. But I agree with you that the startup phase must be rather cheap and relatively automatic. Simplicity, reliability and security also come to the mind. I guess the argument is only about how much of these is enough or too much.. [... snip to the end, except ...] > This is a long discussion we have. I am not that used to IETF mailing > lists. But I am happy to send you my comments off the list if you like. > Just respond me off the list if you think this is better. I'm seeing at least some convergence here, and clarifications on what "configured tunneling" means. Therefore, it seemed useful to continue on list at least for now. If you are more confortable with an off-list discussion, that's fine too. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Oct 13 02:48: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 CAA24915 for ; Mon, 13 Oct 2003 02:48:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A8wNA-000GaC-Go for v6ops-data@psg.com; Mon, 13 Oct 2003 06:40:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A8wN5-000GZE-SI for v6ops@ops.ietf.org; Mon, 13 Oct 2003 06:40:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9D6duI10528 for ; Mon, 13 Oct 2003 09:39:56 +0300 Date: Mon, 13 Oct 2003 09:39:55 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: REMINDER: WG Last Call: 3GPP Analysis Document In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I'd like to remind you that the Last Call is ending soon. We've received only a few mails of feedback on this (thanks for those!). This is nowhere near enough to go forward with the document. So, if you haven't planned to review the document and send feedback, I'd recommend to try to change the plans if at all possible.. :-) Thanks, Pekka writing as co-chair On Mon, 29 Sep 2003, Pekka Savola wrote: > Hello everybody, > > This is a WG Last Call for comments on sending the 3GPP Analysis > document to the IESG for considetation as BCP RFC: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt > > Please review the document carefully, and send your feedback to the list. > > In particular, there has been a lot of discussion (without necessarily > leading into a clear consensus) at least on the following: > > - whether to recommend the UE's to implement tunneling-based transition > mechanism(s), > > - whether the strong recommendation to deploy at least a minimal amount > of IPv6 support to enable IPv6 support in the visited ("roaming") networks > is sufficient, > > - what to say about the general use of NAT-PT or other generic > translation mechanisms (note, there is a dependency on the > soon-to-be-published NAT-PT applicability statement work here), > > - whether to discourage the IPv6-only UE deployment until the transition > has progressed further (related to the need of generic translators, > above), > > - whether the 3GPP networks are special (compared to the ISP) and whether > we should recommend (or list) BGP/IGP -based tunneling mechanisms (on > top of IPv4 infrastructure) in the 3GPP operator's network > > - what kind of transition mechanism is needed for the IMS scenario, and > whether tasking an another WG (e.g. a SIP WG) to specify it is a good > idea. > > It would be especially useful to keep these issues in mind when reviewing > the document and providing feedback. > > Please also indicate whether or not you believe that this document is > ready to go to the IESG. Silence does NOT indicate consent. Unless > sufficient support is demonstrated on the list, the documents will not be > send to the IESG. > > The last call will end in about 2 weeks, on 14th October. > > Pekka, Jonne & Bob > > ---------- Forwarded message ---------- > Date: Mon, 29 Sep 2003 10:57:09 -0400 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-06.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Analysis on IPv6 Transition in 3GPP Networks > Author(s) : J. Wiljakka > Filename : draft-ietf-v6ops-3gpp-analysis-06.txt > Pages : 21 > Date : 2003-9-29 > > This document analyzes the transition to IPv6 in Third Generation > Partnership Project (3GPP) General Packet Radio Service (GPRS) > packet networks. The focus is on analyzing different transition > scenarios, applicable transition mechanisms and finding solutions > for those transition scenarios. In these scenarios, the User > Equipment (UE) connects to other nodes, e.g. in the Internet, and > IPv6/IPv4 transition mechanisms are needed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt > > > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Oct 13 07:03: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 HAA00095 for ; Mon, 13 Oct 2003 07:03:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A90Ny-000EJp-J9 for v6ops-data@psg.com; Mon, 13 Oct 2003 10:57:10 +0000 Received: from [131.115.230.132] (helo=tms001bb.han.telia.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A90Nq-000EJQ-L1 for v6ops@ops.ietf.org; Mon, 13 Oct 2003 10:57:02 +0000 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Oct 2003 12:57:01 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: REMINDER: WG Last Call: 3GPP Analysis Document Date: Mon, 13 Oct 2003 12:57:00 +0200 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE807E1A1@TMS031MB.tcad.telia.se> Thread-Topic: REMINDER: WG Last Call: 3GPP Analysis Document Thread-Index: AcORVlth6epKR/1hRnyYjfEG9EmlGgAFbzYQ From: To: , X-OriginalArrivalTime: 13 Oct 2003 10:57:01.0541 (UTC) FILETIME=[BAF7C950:01C39178] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.2 required=5.0 tests=BAYES_44,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > I'd like to remind you that the Last Call is ending soon. >=20 > We've received only a few mails of feedback on this (thanks=20 > for those!). >=20 > This is nowhere near enough to go forward with the document. >=20 > So, if you haven't planned to review the document and send=20 > feedback, I'd recommend to try to change the plans if at all=20 > possible.. :-) >=20 i have reviewed this document and discussed some issues with juha. i support going forward with the document. jasminko From owner-v6ops@ops.ietf.org Tue Oct 14 05:15: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 FAA00916 for ; Tue, 14 Oct 2003 05:15:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9L3f-0003zm-Mn for v6ops-data@psg.com; Tue, 14 Oct 2003 09:01:35 +0000 Received: from [138.190.3.48] (helo=sbe3777.swissptt.ch) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9L3Y-0003zP-F0 for v6ops@ops.ietf.org; Tue, 14 Oct 2003 09:01:28 +0000 Received: from sxmcmp02.corproot.net (138.190.70.98) by sbe3778.swissptt.ch (MX V5.3 AnHp) with ESMTP for ; Tue, 14 Oct 2003 11:01:26 +0200 Received: from sxmbx01.corproot.net ([138.190.70.160]) by sxsmtp02.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Oct 2003 11:01:01 +0200 Received: from sxmbx03.corproot.net ([138.190.70.162]) by sxmbx01.corproot.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 14 Oct 2003 11:01:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Date: Tue, 14 Oct 2003 11:01:01 +0200 Message-ID: <595362761E89B640A907F5112F8B89B80218059B@sxmbx03.corproot.net> Thread-Topic: 3GPP and 'not touching a running system' [RE: 3gpp-analysis-05: miscellaneous non-critical issues] Thread-Index: AcORVDvLzHKbp6zJTLKXZiEYFg6BewAvx1wQ From: To: CC: , , X-OriginalArrivalTime: 14 Oct 2003 09:01:02.0013 (UTC) FILETIME=[B12DD6D0:01C39231] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Montag, 13. Oktober 2003 08:36 > On Fri, 10 Oct 2003 Andreas.Schmid1@swisscom.com wrote: <...snip...> > =20 > > We are looking at what is available in commercial products=20 > today. Most=20 > > of our customers are using Windows (even if we don't like=20 > it - it's a=20 > > fact). And there, you have Teredo, ISATAP and 6to4 as automatic=20 > > tunneling mechanisms (I don't count on configured tunnels since the=20 > > user should not have to configure anything for IPv6). >=20 > Configured tunneling methods don't need to be manually=20 > configured, unless=20 > you want them to be (see more below). >=20 > > Teredo is not really stable and very complex. 6to4 is just=20 > applicable=20 > > if you have a public address (and this is not the case for=20 > most if not=20 > > all 3GPP networks of today). >=20 > Right.. >=20 > > So ISATAP seems to be the solution of choice?!? > > Of course, you could argue that you could convince Microsoft to=20 > > implement something else. But this could be difficult.... >=20 > I suppose one can run your own applications on top of a=20 > Microsoft operating system. For example, a very simple GUI=20 > application which=20 > transparently configures/unconfigures configured tunnels. =20 > Shouldn't be=20 > too difficult. Yes, that's not too difficult. But it is much better if the users can just use the new services without having to configure something. If the user has to configure, you either distribute the tunnel-enabling app with the new service app or let the user be aware of IPv6. The second solution is bad because users should not be aware of IPv6 (but just use it). The first solution would be possible but is still not good. Operators want to offer new services without the user having to install something. The OS (and the network) should take care of that. >=20 > The point is, the current basic transition mechanism=20 > framework gives a lot of tools, if one is just willing to=20 > take them and use them. Yes, right - many tools there - _too many_ for the average operator. The operators are lost! I guess that's one of the reasons why the v6ops WG has been established; to break down the number of tools and make proposals on what to use where. >=20 > > > 2) UE is used standalone or as IPv6 router for a laptop > > > o UE implements IPv6 > > > o Native IPv6 packets flow between the UE and the laptop > > > (if plugged in) > > > o UE acts as an IPv6 router/bridge for the laptop > > > o compared to the above, useful mostly if you want IPv6=20 > > > connectivity at=20 > > > the UE as well as the laptop > > >=20 > > > a) UE uses an IPv6 PDP context for its IPv6 connectivity > > > =3D=3D> pretty straightforward, and long term good approach > >=20 > > Right. But still, the operations department don't want this=20 > today (I=20 > > am repeating this again. But you can believe me this!) >=20 > Some operators probably see this as more desirable than others. Yes, maybe... >=20 > [...] > > > b) UE uses a form of tunneling for its IPv6 connectivity > > > =3D=3D> putting complexity to the UE > >=20 > > Yes, I know this is probably only useful for smartphones... > > > > > =3D=3D> which are the cases where 1) above is not applicable? > >=20 > > Where you want to use an application on the handset that is only=20 > > running on IPv6. >=20 > Right. The question is, is this scenario near-term enough? =20 > Couldn't we=20 > be able to proceed with just "laptop tunneling" and=20 > recommending using=20 > IPv6 PDP context when the phones leveraging IPv6 emerge? Ok, we could do that. But even if we recommend IPv6 PDP context for the phones we should add a side note that automatic tunneling as done in the "laptop tunneling" case would also be possible if the phones support that. We (Swisscom) are currently asking the handset vendors (Nokia, SonyEricsson, etc) to implement ISATAP in their phones. I know that SonyEricsson has ISATAP in a pre-commercial phone implemented.=20 >=20 > > > =3D=3D> could configured tunneling be made to work? > >=20 > > No, we need automatic tunnels. Configuring the handsets is=20 > already too=20 > > complex for our customers! We need something plug&play... >=20 > Note that "configured tunneling" refers to _somehow_ configuring the=20 > tunnel endpoints. The configuration itself need not be done=20 > manually by=20 > the user. At the face value, this may not be obvious.. >=20 > For example, one might be able to use a number of different=20 > Over the Air=20 > techniques for configuring the tunnel -- see the section in=20 > the analysis=20 > document? (I haven't discussed whether this is possible with 3GPP=20 > experts, but I don't see any reason why not..) > =20 If it's possible to automate configured tunneling (the automation mechanism has to be built in the OS!) then this is fine for us. Because what we need is the automated nature of IPv6 from a user point of view (how this user experience is achieved is not that important for us). > [...] > > Remember that IPv6 is an enabler. The services will not be=20 > developed=20 > > if the network is not there. If we put the network there (cheap but=20 > > still > > automatic) the services will appear. But if we wait for the=20 > services to > > implement IPv6 to the handsets this will never happen.... >=20 > Some others would probably count adding a few new 3GPP IPv6=20 > features (as a=20 > start-up phase installation, until the services are there) as an=20 > acceptably cheap and automatic mechanism -- one which could=20 > be expanded=20 > easily when needed. >=20 > But I agree with you that the startup phase must be rather=20 > cheap and relatively automatic. Simplicity, reliability and=20 > security also come to the mind. I guess the argument is only=20 > about how much of these is enough or too much.. Yes, exactly right! >=20 > [... snip to the end, except ...] >=20 > > This is a long discussion we have. I am not that used to=20 > IETF mailing=20 > > lists. But I am happy to send you my comments off the list if you=20 > > like. Just respond me off the list if you think this is better. >=20 > I'm seeing at least some convergence here, and clarifications on what=20 > "configured tunneling" means. Therefore, it seemed useful to=20 > continue on=20 > list at least for now. If you are more confortable with an off-list=20 > discussion, that's fine too. No problem from me with on-list discussion. I just don't want to fill people's email inbox with something that is not useful for them. Regards Andreas From owner-v6ops@ops.ietf.org Wed Oct 15 15:45:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19002 for ; Wed, 15 Oct 2003 15:45:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9rNm-000GQ7-GR for v6ops-data@psg.com; Wed, 15 Oct 2003 19:32:30 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9rNj-000GPS-Gr for v6ops@ops.ietf.org; Wed, 15 Oct 2003 19:32:27 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18273; Wed, 15 Oct 2003 15:32:18 -0400 (EDT) Message-Id: <200310151932.PAA18273@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-savola-v6ops-transarch-01.txt Date: Wed, 15 Oct 2003 15:32:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A View on IPv6 Transition Architecture Author(s) : P. Savola Filename : draft-savola-v6ops-transarch-01.txt Pages : 13 Date : 2003-10-15 The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-transarch-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-savola-v6ops-transarch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-savola-v6ops-transarch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-15142419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-savola-v6ops-transarch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-savola-v6ops-transarch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-15142419.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Oct 15 15:46:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19030 for ; Wed, 15 Oct 2003 15:46:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9rNg-000GPH-QK for v6ops-data@psg.com; Wed, 15 Oct 2003 19:32:24 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9rNd-000GOr-SO for v6ops@ops.ietf.org; Wed, 15 Oct 2003 19:32:22 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18259; Wed, 15 Oct 2003 15:32:13 -0400 (EDT) Message-Id: <200310151932.PAA18259@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shirasaki-dualstack-service-02.txt Date: Wed, 15 Oct 2003 15:32:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_01,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Model of IPv6/IPv4 Dual Stack Internet Access Service Author(s) : Y. Shirasaki, et. al. Filename : draft-shirasaki-dualstack-service-02.txt Pages : 11 Date : 2003-10-15 This memo shows an example of how to provide IPv6 / IPv4 dual stack services to home users. In order to simplify user setup, these service should have mechanism to configure IPv6 specific parameters automatically. We focus on two basic parameters, prefix and addresses of IPv6 DNS servers, and specify the way to deliver them to Customer Premises Equipments (CPE) automatically. This memo is a digest of the user network interface specification of NTT communications' dual stack ADSL access service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shirasaki-dualstack-service-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shirasaki-dualstack-service-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shirasaki-dualstack-service-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-15142405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shirasaki-dualstack-service-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-shirasaki-dualstack-service-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-15142405.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Oct 15 21:18: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 VAA01957 for ; Wed, 15 Oct 2003 21:18:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1A9wew-000BOo-DA for v6ops-data@psg.com; Thu, 16 Oct 2003 01:10:34 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1A9wer-000BOR-SX for v6ops@ops.ietf.org; Thu, 16 Oct 2003 01:10:29 +0000 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Oct 2003 18:11:16 -0700 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 15 Oct 2003 18:10:29 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Oct 2003 18:10:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Oct 2003 18:10:28 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 15 Oct 2003 18:10:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt Date: Wed, 15 Oct 2003 18:10:27 -0700 Message-ID: Thread-Topic: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt thread-index: AcOTgkkiKz8LLHKNRBu5B6Bhh1pt5w== From: "Dave Thaler" To: , , X-OriginalArrivalTime: 16 Oct 2003 01:10:27.0860 (UTC) FILETIME=[49237D40:01C39382] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Forwarding this announcement to the most relevant WG's... RFC 2667, entitled "IP Tunnel MIB", only supported=20 point-to-point tunnels over IPv4. This draft updates=20 RFC 2667 to also support tunnels over IPv6, as well as=20 tunnels which aren't just point-to-point (e.g. 6to4). It also clarifies the use of the ifRcvAddressTable for all tunnels. It uses the InetAddress types like the other MIBs that have been done by the IPv6MIB Design Team. -Dave * To: IETF-Announce: ;=20 * Subject: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt=20 * From: Internet-Drafts@ietf.org=20 * Date: Tue, 14 Oct 2003 15:35:25 -0400=20 * Reply-to: Internet-Drafts@ietf.org=20 * Sender: owner-ietf-announce@ietf.org=20 ________________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Tunnel MIB Author(s) : D. Thaler Filename : draft-thaler-inet-tunnel-mib-00.txt Pages : 26 Date : 2003-10-14 =09 This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIBs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thaler-inet-tunnel-mib-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-thaler-inet-tunnel-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-thaler-inet-tunnel-mib-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Thu Oct 16 08:34: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 IAA00544 for ; Thu, 16 Oct 2003 08:34:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AA7Bu-000I9q-1m for v6ops-data@psg.com; Thu, 16 Oct 2003 12:25:18 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AA7Bc-000I7m-Kt for v6ops@ops.ietf.org; Thu, 16 Oct 2003 12:25:00 +0000 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 7B48E2F44D9; Thu, 16 Oct 2003 08:23:16 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Thu, 16 Oct 2003 08:23:16 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id 3B8DD7704E; Thu, 16 Oct 2003 08:23:16 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: psavola@funet.fi Date: Thu, 16 Oct 2003 17:53:16 +0530 X-Epoch: 1066306996 X-Sasl-enc: gsQx8DiTjakgIf6lUeb8FQ Cc: v6ops@ops.ietf.org Subject: Comments on draft-ietf-v6ops-6to4-security-00 Message-Id: <20031016122316.3B8DD7704E@smtp.us2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, draft-ietf-v6ops-6to4-security-00 turned out to be quite thought prvoking document, and hence I am sending you my comments on the same. At a high level I think a bit more work needs to go about in the document in terms of organization, and using the correct technical terms.=20 There are still some comments pending on my side, which I will probably send later, as I still need to develop an understanding about few parts of the document. regards, CP Editorial comments: ------------------- 1. Abstract "Spoofing traffic from non-6to4 addresses as if it was coming from a relay, to a 6to4 relay mode" - This behavior can also be used to perform a DOS. Are these type of DOS's same as proxy DOS (I have a question about proxy DOS later on)? If yes, then the Abstract should be rephrases. 2. Section 1. 2nd paragraph s/malicious parties/malicious IPv6 nodes/ 3. Section 1. 3nd paragraph s/anyone/any IPv4 node outside of the 6to4 site/ You might want to review the usage of "anyone" in the document, and use specific terminology as applicable. 4. Section 2.1. 1st paragraph s/2002:V4ADDR/2002:V4ADDR::\/48/ Check for the same in the remaining document. 5. Section 2. 1st paragraph Rephrase the last sentence to: Because of this, it is not feasible to limit relays from which 6to4 routers may accept traffic.=20 6. Section 2.2. 1st paragraph s/6to4 address 2002:V4ADDR/6to4 prefix 2002:V4ADDR::\/48/ Make similar change in the figure. Also instead of 9.0.0.1, you can use V4ADDR in the text, and the figure. The same comment applies for the figure in section 2.3. 7. Section 2.4.1 2nd paragraph Rephrase to If the 6to4 router established a BGP session with few of the 6to4 relays, the traffic to non-6to4 sites would always go through these relays. An alternative would be to advertise more specific 6to4 routes between 6to4 relays, and 6to4 routers, as described later (section???, also give reference to 6to4??) in this document. 8. Section 2.4.2 s/Some seem/Some sites seem/ s/Some also publish/These sites also publish/ Remove the last sentence of the last paragraph. It does not add anything. Security threats will always be reduced if hosts follow the specs. 9. Section 3. 1st paragraph Rephrase to "This section describes the functionality of the various nodes of a 6to4 network. Note, the functions listed in this section are not exhaustive, and are presented to help understand the behavior of the various nodes" The section can also be renamed to "Functionality of nodes in the 6to4 network" 10. Rename section 3 to "Major functions of 6to4 network nodes" I would also like if the section was organized into 3. Major functions of 6to4 network nodes 3.1. 6to4 host 3.2. 6to4 router 3.3. 6to4 relay ... ... Divide each subsection into "Functions", and "Security checks" (this is essentially the section 3.2, just that it has been worded differently). "Non-functions" is a non-standard word. 11. I am not able to understand the significance of section 4. It talks about the special (what is so special?) processing of 6to4. IMHO, this section can be merged with the previous section.=20 12. The flow of text for all the threats is not similar. It hampers readability, and it is difficult to identify the missing pieces.=20 My suggestion is that the text for each threat should be divided amongst the following headings. (More headings may be headed as required) ------------------------------------------------------------------------ THREAT DESCRIPTION EXTENSIONS MESSAGES INVOLVED THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS COMPARISON TO SITUATION WITHOUT 6to4 ------------------------------------------------------------------------ 13. Section 6 s/number number/number Technical comments: ------------------- 1. Section 1. What is the meaning of the term "proxy denial of service"? I have not observed the term word "proxy" used along with "denial of service". It appears from Section 1, that it is the same as distributed reflection DOS.=20 =09 2. Section 1. What is the meaning of traffic laundering? It does not seem to be standard terminology. Incase it is, can you give a reference? 3. Section 1. 4th Paragraph Can you elaborate a little about which "quite a few" security considerations have been difficult to implement? I think the only security consideration that has been difficult to implement is that "6to4 routers must be configured to accept traffic from relay routers". 6to4 routers do not know of all the relay routers, and hence a susceptible to attacks. The paragraph should be rephrased to say - 1) Security considerations in 6to4 specifications are not complete, and some of them have not been implemented due to their abstract nature, and 2) Additional security considerations have been discovered after the 6to4 specifications have been released. I am guessing that the 2nd point is true based on the "Acknowledgements" section. My association with 6to4 has been very recent. 4. Section 2.1. 2nd paragraph. Three comments here: 1. s/It is required/It is mandated/ 2. My opinion is to delete all text from the 2nd sentence onwards "If this is restricted", as it is speculative, and would violate 6to4 specification (section 5.2, and section 5.3) 5. Section 2.4.3 2nd paragraph. I don't understand the example. What does the following line mean? This assumes that all outgoing traffic from the main organization (but not between branch offices) uses one or more non-6to4 connections. You have not mentioned the relationship between the main organization, the branch office, and the native IPv6 internet. Perhaps then the sentence would be clear. I also fail to see how it is similar to the "optimization method".=20 6. Section 5, 1st paragraph You mention about the security checks listed in 6to4. Can you summarize the security checks within this document? If not, can you give specific references? Are these same as the checks listed in section 3? You also mention - "Many implementations are known to be problematic at least in some cases". Can you enumerate the implementations, and the specific cases? I guess Linux is one of them based on the Acknowledgements section. 7. Section 5.1. Do you mean 6to4 hosts as compared to 6to4 nodes? 8. Section 5.2 Remove the 1st paragraph. It is quite confusing. Instead of interpreting "6to4 routers" as all nodes that have a 6to4 pseudo-interfaces, it would be better to use the triplet of 6to4 routers, 6to4 hosts, and relay routers.=20 9. Section 5.2.1. The attacks are not against the 6to4 pseudo-interface. They are against nodes -- 6to4 routers, 6to4 hosts, and relay routers -- and they employ a specific method - ND (or are you implying other types of attacks?). Maybe the section can be renamed to "ND attacks against 6to4 nodes". In the 3rd paragraph you mention future uses of 6to4. What are the future uses? I can't locate anything in section 3.1 of 6to4. 10. Section 5.2.1.1. What is the "situation without 6to4"? Do you mean all forms of *IPv6, and IPv4* networks that do not employ 6to4?=20 In he same section. What is open decapsulation? I am also a bit confused about this section. Are you trying to list networks that face a similar threat, and how the threat is handled in those networks? 11. Section 5.2.2 When you refer to IPv6 nodes, I am assuming that you mean *any* (native IPv6 node, 6to4 router, 6to4 host, 6to4 relay, native IPv6 router etc) node on the global IPv6 network. Correct? What is unidirectional address spoofing? I am a bit ignorant on this front. The text should mention a concise definition or provide a reference.=20 12. Section 5.2.2.1 I don't understand the first paragraph. See below for questions embedded within the text. The unidirectional spoofing attack exists without 6to4 too, but it requires the attacker is able to spoof IPv6 source addresses. With 6to4, one is able to launch this attack without any spoofing at all. How can the attack be launched without spoofing? A restriction is that the source address cannot be spoofed to belong ^^^^^^^^^^^ Restriction on what? =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 to the destination site as only non-6to4 addresses can be spoofed (assuming correct implementations). Blindly trusting source address of packets coming from the Internet without other precautions is very bad practise, though -- and this attack would typically be useful only for spoofing destination site -- which is not possible, and can be protected against with egress filtering. Who does the egress filtering, and at what layer - IPv4, IPv6? I think I have too many questions in this section, and despite rereading it, I am not able to make much sense. Rephrasing seems to be only recourse.=20 13. Section 5.2.2.1=20 I am not in agreement with some of the points made about why the DOS attack is not critical. o 6to4 as an enabling mechanism does not provide any possibility for packet multiplication, attacks are generally 1:1, The word enabling can be removed.=20 Packet multiplication can be achieved by distributed DOS? Isn=92t the same property (1:1) exhibited in reflection attacks in the IPv4 internet? o victim receives packets as replies from "dst": unless echo service (e.g. UDP port 7) is used, the attacker has reasonably little control on the content of packets; for example, pure "SYN" TCP packets often used for flooding cannot be sent, If the Reflection attacks are distributed, then they might be severe.=20 o attack packets pass through choke point(s), namely (one or more) 6to4 relays; in addition to physical limitations, these could implement some form 6to4-site-specific traffic limiting, and Yes. Traffic limiting may be done. But it is not a deterministic property of 6to4 relays, and if the reflection attacks are distributed, then a large number of relays will be involved, and traffic limiting might not work. o one has to know a valid destination address (however, this is easily guessable or deducible with e.g. an ICMP echo request with a limited Hop Count). This is a moot point. If you are attacking someone you will *have to* know their address. The 3rd last para mentions - "The attack can be launched from hosts...". Which hosts do you mean? IPv4 hosts that can access the 6to4 routers? Don't understand the 2nd last paragraph. Which point is not a real factor? The last sentence says that "This is one of the most serious threats". Whereas, the section contains many points to argue that the attack is not critical. Which is it? 15. I have yet to review the document beyond this point thoroughly. I am getting a bit confused with the text organization, and mainly with the usage of the terms - hosts, routers, IPv6 nodes, 6to4 routers - and some of the contents in particular. I will try to send out remaining comments in another mail. 16. Ok a quick one before I send of this mail. The algorithms also need some work to make them more readable, and organized. I am still not able to appreciate the difference between the generic, and simplified approach, and the language used for depicting the algorithm needs to be made more generic (for eg. "src=3D=3D2002" can be changed to "prefix (src) matches 2002".=20 From owner-v6ops@ops.ietf.org Thu Oct 16 15:39: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 PAA19588 for ; Thu, 16 Oct 2003 15:39:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AADpj-000P3t-P8 for v6ops-data@psg.com; Thu, 16 Oct 2003 19:30:51 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AADpf-000P34-0h for v6ops@ops.ietf.org; Thu, 16 Oct 2003 19:30:47 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19107; Thu, 16 Oct 2003 15:30:36 -0400 (EDT) Message-Id: <200310161930.PAA19107@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unman-scenarios-03.txt Date: Thu, 16 Oct 2003 15:30:36 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Unmanaged Networks IPv6 Transition Scenarios Author(s) : C. Huitema, R. Austein, S. Satapati, R. van der Pol Filename : draft-ietf-v6ops-unman-scenarios-03.txt Pages : 19 Date : 2003-10-16 In order to evaluate the suitability of IPv6 transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the 'unmanaged network', which typically corresponds to a home or small office network. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unman-scenarios-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-16143738.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-unman-scenarios-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-16143738.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 16 15:40:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19622 for ; Thu, 16 Oct 2003 15:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AADpe-000P3D-RY for v6ops-data@psg.com; Thu, 16 Oct 2003 19:30:46 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AADpb-000P2Q-8k for v6ops@ops.ietf.org; Thu, 16 Oct 2003 19:30:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19049; Thu, 16 Oct 2003 15:30:31 -0400 (EDT) Message-Id: <200310161930.PAA19049@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ent-scenarios-00.txt Date: Thu, 16 Oct 2003 15:30:30 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Enterprise Network Scenarios Author(s) : J. Bound Filename : draft-ietf-v6ops-ent-scenarios-00.txt Pages : 15 Date : 2003-10-16 This document describes the scenarios for IPv6 deployment within Enterprise networks. It will focus upon an Enterprise set of network base scenarios with assumptions, coexistence with legacy IPv4 nodes, networks, and applications, and network infrastructure requirements. These requirements will be used to provide analysis to determine a set of Enterprise solutions in a later document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ent-scenarios-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-16143721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ent-scenarios-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ent-scenarios-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-16143721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 17 02:09:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17224 for ; Fri, 17 Oct 2003 02:09:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AANaQ-0009Xe-EG for v6ops-data@psg.com; Fri, 17 Oct 2003 05:55:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AANaG-0009WV-CF; Fri, 17 Oct 2003 05:55:32 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9H5tRr22103; Fri, 17 Oct 2003 08:55:28 +0300 Date: Fri, 17 Oct 2003 08:55:27 +0300 (EEST) From: Pekka Savola To: randy@psg.com cc: bwijnen@lucent.com, , Subject: I-D ACTION:draft-ietf-v6ops-unman-scenarios-03.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Randy, We believe the revised I-D addresses the comments raised in IESG review. Hopefully its publication can continue on track on. Thanks, Pekka, Jonne & Bob ---------- Forwarded message ---------- Date: Thu, 16 Oct 2003 15:30:36 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unman-scenarios-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Unmanaged Networks IPv6 Transition Scenarios Author(s) : C. Huitema, R. Austein, S. Satapati, R. van der Pol Filename : draft-ietf-v6ops-unman-scenarios-03.txt Pages : 19 Date : 2003-10-16 In order to evaluate the suitability of IPv6 transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the 'unmanaged network', which typically corresponds to a home or small office network. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unman-scenarios-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Fri Oct 17 02:29: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 CAA20849 for ; Fri, 17 Oct 2003 02:29:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAO2R-000BXZ-Uu for v6ops-data@psg.com; Fri, 17 Oct 2003 06:24:39 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAO2N-000BX9-V2 for v6ops@ops.ietf.org; Fri, 17 Oct 2003 06:24:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9H6Nl822372 for ; Fri, 17 Oct 2003 09:23:47 +0300 Date: Fri, 17 Oct 2003 09:23:47 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-savola-v6ops-transarch-01.txt In-Reply-To: <200310151932.PAA18273@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, As a lot of people had brought up ideas about IPv6-only deployments (and possibly, the use of NAT-PT for generic translation) -- which have been discouraged as a consequence -- I thought it might make sense to update my older document to include my (and actually many others') thoughts about these as well, so that at least one person's view is recorded somewhere. Comments are welcome on everything on the document, of course. On Wed, 15 Oct 2003 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A View on IPv6 Transition Architecture > Author(s) : P. Savola > Filename : draft-savola-v6ops-transarch-01.txt > Pages : 13 > Date : 2003-10-15 > > The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is > a subject of much debate. However, the big picture of the transition > seems not to have been discussed sufficiently. Therefore, different > people have different assumptions on the process, which makes > planning the transition architecture very difficult: indeed, it seems > that there is a lack of architecture in the transition process. This > memo tries to point out some issues that will need consideration in > the transition architecture, as well as point out a few personal > views on certain transition approaches. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-savola-v6ops-transarch-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-savola-v6ops-transarch-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-savola-v6ops-transarch-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- 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 Oct 17 08:16: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 IAA29397 for ; Fri, 17 Oct 2003 08:16:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AATRR-0004r8-13 for v6ops-data@psg.com; Fri, 17 Oct 2003 12:10:49 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AATRM-0004qn-PW for v6ops@ops.ietf.org; Fri, 17 Oct 2003 12:10:44 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9HCAhX08510 for ; Fri, 17 Oct 2003 15:10:43 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 17 Oct 2003 15:10:43 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 15:10:43 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 17 Oct 2003 15:10:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: More comments needed! [WG Last Call: 3GPP Analysis Document] Date: Fri, 17 Oct 2003 15:03:22 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDF81@esebe005.ntc.nokia.com> Thread-Topic: More comments needed! [WG Last Call: 3GPP Analysis Document] Thread-Index: AcOUpqiYn/ow8tJ5QDCs/asdQps5qg== From: To: X-OriginalArrivalTime: 17 Oct 2003 12:10:43.0031 (UTC) FILETIME=[B0089E70:01C394A7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all! The wglc for 3GPP Analysis http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-06.txt= ended on Oct 14th. Quite many comments were given, and these=20 were the main "open issues" before starting the wglc: - tunneling in the UE (what is the exact recommendation) - what is the exact recommendation on NAT-PT or other generic=20 translation mechanisms (well, I think this is quite much solved, and we can refer to NAT-PT applicability doc that will be published soon) - need to discourage IPv6-only UE deployment until the transition has progressed further - listing BGP/IGP based tunnels as a solution alternative in the=20 3GPP operator's network; or do we leave all such details to=20 ISP document? - closer details for IMS scenario 1 solution; to be specified elsewhere=20 (Sipping wg)? The comments included: - Alain Durand's (high level) comments -> some edits will be done based=20 on those comments - Based on Jasminko Mulahusic's comments, especially text in 3.2.2=20 was modified - Jasminko M. also recommended going forward with this document - quite many operator comments from Andreas Schmid; lengthy discussion in which Pekka S. and others were also involved. =3D> So, what to do next? It is inevitable that a new revision is needed (deadline before = Minneapolis is Oct 27th, so basically one week time for that). But before that, I would like to = know what the chairs are thinking about the situation.=20 I would also like to get more wg comments, at least comments like: A) I support moving forward with this document (and I have these = comments...), or B) I don't support moving forward with this doucment, because... Many thanks, -Juha W.- From owner-v6ops@ops.ietf.org Fri Oct 17 08:37:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29866 for ; Fri, 17 Oct 2003 08:37:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AATpr-0006KM-W2 for v6ops-data@psg.com; Fri, 17 Oct 2003 12:36:03 +0000 Received: from [66.218.79.72] (helo=web80502.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AATpk-0006Jr-Ni for v6ops@ops.ietf.org; Fri, 17 Oct 2003 12:35:56 +0000 Message-ID: <20031017123556.32857.qmail@web80502.mail.yahoo.com> Received: from [63.197.18.101] by web80502.mail.yahoo.com via HTTP; Fri, 17 Oct 2003 05:35:56 PDT Date: Fri, 17 Oct 2003 05:35:56 -0700 (PDT) From: Fred Templin Subject: Re: I-D ACTION:draft-ietf-v6ops-unman-scenarios-03.txt (fwd) To: Pekka Savola , randy@psg.com Cc: bwijnen@lucent.com, v6ops@ops.ietf.org, iesg-secretary@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2013684820-1066394156=:32302" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-2013684820-1066394156=:32302 Content-Type: text/plain; charset=us-ascii The document text cites references to [6TO4], but the references section lists it as [RFC3056]. Please fix before publication. Fred Templin osprey67@yahoo.com Pekka Savola wrote: Hi Randy, We believe the revised I-D addresses the comments raised in IESG review. Hopefully its publication can continue on track on. Thanks, Pekka, Jonne & Bob ---------- Forwarded message ---------- Date: Thu, 16 Oct 2003 15:30:36 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-unman-scenarios-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Unmanaged Networks IPv6 Transition Scenarios Author(s) : C. Huitema, R. Austein, S. Satapati, R. van der Pol Filename : draft-ietf-v6ops-unman-scenarios-03.txt Pages : 19 Date : 2003-10-16 In order to evaluate the suitability of IPv6 transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the 'unmanaged network', which typically corresponds to a home or small office network. The scenarios are specific to single link subnet, and are defined in terms of IP connectivity supported by the home gateway and the ISP. We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-unman-scenarios-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --0-2013684820-1066394156=:32302 Content-Type: text/html; charset=us-ascii
The document text cites references to [6TO4], but the references
section lists it as [RFC3056].
 
Please fix before publication.
 
Fred Templin
osprey67@yahoo.com

Pekka Savola <pekkas@netcore.fi> wrote:
Hi Randy,

We believe the revised I-D addresses the comments raised in IESG review.
Hopefully its publication can continue on track on.

Thanks,
Pekka, Jonne & Bob

---------- Forwarded message ----------
Date: Thu, 16 Oct 2003 15:30:36 -0400
From: Internet-Drafts@ietf.org
To: IETF-Announce: ;
Cc: v6ops@ops.ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-unman-scenarios-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

Title : Unmanaged Networks IPv6 Transition Scenarios
Author(s) : C. Huitema, R. Austein, S. Satapati, R. van der Pol
Filename : draft-ietf-v6ops-unman-scenarios-03.txt
Pages : 19
Date : 2003-10-16

In order to evaluate the suitability of IPv6 transition mechanisms,
we need to define the scenarios in which these mechanisms have to be
used. One specific scope is the 'unmanaged network', which typically
corresponds to a home or small office network. The scenarios are
specific to single link subnet, and are defined in terms of IP
connectivity supported by the home gateway and the ISP. We first
examine the generic requirements of four classes of applications:
local, client, peer to peer and server. Then, for each scenario, we
infer transition requirements by analyzing the needs for smooth
migration of applications from IPv4 to IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-v6ops-unman-scenarios-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-v6ops-unman-scenarios-03.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--0-2013684820-1066394156=:32302-- From owner-v6ops@ops.ietf.org Fri Oct 17 09:03: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 JAA00456 for ; Fri, 17 Oct 2003 09:03:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAUEq-00082e-UI for v6ops-data@psg.com; Fri, 17 Oct 2003 13:01:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAUEc-00081f-J0 for v6ops@ops.ietf.org; Fri, 17 Oct 2003 13:01:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9HD1E826136; Fri, 17 Oct 2003 16:01:17 +0300 Date: Fri, 17 Oct 2003 16:01:13 +0300 (EEST) From: Pekka Savola To: Chirayu Patel cc: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-v6ops-6to4-security-00 In-Reply-To: <20031016122316.3B8DD7704E@smtp.us2.messagingengine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Hi, (more inline) *WG chair hat=ON* First, thanks a lot for the bunch of very good and timely comments. Second, we asked Chirayu to step in as co-author, to help edit the document; it is a long and rather complex document. Thanks a lot for that as well. It's very nice to see fresh faces in active participation in the WG. :-) Pekka, Jonne & Bob *WG chair hat=OFF* Now, after the formal rounds, I'll try to comment on the proposed modifications so that I'll have easier time syncing up opinions when editing the document with my new co-author.. :-) We can probably continue from here off-list as necessary. On Thu, 16 Oct 2003, Chirayu Patel wrote: > draft-ietf-v6ops-6to4-security-00 turned out to be quite thought prvoking > document, and hence I am sending you my comments on the same. At a high > level I think a bit more work needs to go about in the document in terms > of organization, and using the correct technical terms. Agreed. > Editorial comments: > ------------------- > > 1. Abstract > > "Spoofing traffic from non-6to4 addresses as if it was coming from a > relay, to a 6to4 relay mode" - This behavior can also be used to perform > a DOS. Are these type of DOS's same as proxy DOS (I have a question about > proxy DOS later on)? If yes, then the Abstract should be rephrases. This behaviour can be used for both spoofing and DoS. The definition of DoS, proxy DoS, etc. are probably rather inconsistent, and we'll probably need to use better terminology here. > 2. Section 1. 2nd paragraph > > s/malicious parties/malicious IPv6 nodes/ > > 3. Section 1. 3nd paragraph > > s/anyone/any IPv4 node outside of the 6to4 site/ > > You might want to review the usage of "anyone" in the document, and use > specific terminology as applicable. Agreed with these. Good and more consistent terminology would make it easier to read the document. > 4. Section 2.1. 1st paragraph > > s/2002:V4ADDR/2002:V4ADDR::\/48/ > > Check for the same in the remaining document. Agreed. > 5. Section 2. 1st paragraph > > Rephrase the last sentence to: > > Because of this, it is not feasible to limit relays from which 6to4 > routers may accept traffic. OK. > 6. Section 2.2. 1st paragraph > > s/6to4 address 2002:V4ADDR/6to4 prefix 2002:V4ADDR::\/48/ > > Make similar change in the figure. > > Also instead of 9.0.0.1, you can use V4ADDR in the text, and the figure. > The same comment applies for the figure in section 2.3. Agreed. > 7. Section 2.4.1 2nd paragraph > > Rephrase to > > If the 6to4 router established a BGP session with few of the 6to4 relays, > the traffic to non-6to4 sites would always go through these relays. An > alternative would be to advertise more specific 6to4 routes between 6to4 > relays, and 6to4 routers, as described later (section???, also give > reference to 6to4??) in this document. I'm not sure if I agree here. This seems to change the point of the paragraph, that is, the return path from the non-6to4 sites is a problem unless you have a BGP session to all the relays (or some other infrastructure) -- sending *to* non-6to4 sites is a simpler issue. (Also note the use of "few" ? intentional or "a few" ?) > 8. Section 2.4.2 > > s/Some seem/Some sites seem/ > > s/Some also publish/These sites also publish/ OK. > Remove the last sentence of the last paragraph. It does not add anything. > Security threats will always be reduced if hosts follow the specs. I'm OK with removal even though I'm I think keeping this in here might not hurt. > 9. Section 3. 1st paragraph > > Rephrase to > > "This section describes the functionality of the various nodes of a > 6to4 network. > > Note, the functions listed in this section are not exhaustive, and > are presented to help understand the behavior of the various nodes" > > The section can also be renamed to "Functionality of nodes in the 6to4 > network" OK. > 10. Rename section 3 to "Major functions of 6to4 network nodes" > > I would also like if the section was organized into > > 3. Major functions of 6to4 network nodes > 3.1. 6to4 host > 3.2. 6to4 router > 3.3. 6to4 relay > ... > ... > > Divide each subsection into "Functions", and "Security checks" (this is > essentially the section 3.2, just that it has been worded differently). > "Non-functions" is a non-standard word. That's OK, and probably better. I haven't been too satisfied at the way section 3 has looked like myself :-) > 11. I am not able to understand the significance of section 4. It talks > about the special (what is so special?) processing of 6to4. IMHO, this > section can be merged with the previous section. OK with the merge. The point of the section is to try to summarize, hopefully briefly, how 6to4 differs from e.g. native IPv6 use, i.e., what kind of functionalities result from the 6to4 implementation depending on which function it serves. > 12. The flow of text for all the threats is not similar. It hampers > readability, and it is difficult to identify the missing pieces. Totally agree on there (difficult to identify the missing pieces) > My suggestion is that the text for each threat should be divided amongst > the following headings. (More headings may be headed as required) > > ------------------------------------------------------------------------ > > THREAT DESCRIPTION > > > > EXTENSIONS > > different for each extension then mention that.> > > MESSAGES INVOLVED > > its extensions. For example ND messages, or DATA messages, or specific > DATA messages> > > THREAT ANALYSIS AND SOLUTIONS/MITIGATION METHODS > > if available, and provide a reference for each known solution wherever > possible.> > > > > COMPARISON TO SITUATION WITHOUT 6to4 > > implement 6to4.> This seems to make sense. This is probably also close to what Christian Huitema was suggesting some months ago, but which I was not sure how to proceed with. The reason why I chose the current model was that I wanted it to be easy for folks just using 6to4 as a router, relay etc. to look which threats apply to them and exactly how. With threat-centric approach, this needs to be ensured otherwise (but probably makes more sense, as a whole). > 13. Section 6 > > s/number number/number OK > Technical comments: > ------------------- > > 1. Section 1. > > What is the meaning of the term "proxy denial of service"? I have not > observed the term word "proxy" used along with "denial of service". It > appears from Section 1, that it is the same as distributed reflection > DOS. Yep, "proxy" in this case is used more or less interchangeably with reflection DoS attacks.. :-( > 2. Section 1. > > What is the meaning of traffic laundering? It does not seem to be > standard terminology. Incase it is, can you give a reference? I'm not sure if this is standard terminology, or whether something else would better fit here. I used it to basically refer to sending traffic through some other nodes, to make it seem as if the other would have sent it itself -- to make it more difficult to trace the trails. Perhaps something else would be more appropriate, or at the very least, the term needs to be explained better.. > 3. Section 1. 4th Paragraph > > Can you elaborate a little about which "quite a few" security > considerations have been difficult to implement? I think the only > security consideration that has been difficult to implement is that "6to4 > routers must be configured to accept traffic from relay routers". 6to4 > routers do not know of all the relay routers, and hence a susceptible to > attacks. In particular, the security checks are difficult when multiple tunneling techniques are used, as noted in section 7.1. > The paragraph should be rephrased to say - 1) Security considerations in > 6to4 specifications are not complete, and some of them have not been > implemented due to their abstract nature, and 2) Additional security > considerations have been discovered after the 6to4 specifications have > been released. > > I am guessing that the 2nd point is true based on the "Acknowledgements" > section. My association with 6to4 has been very recent. I guess the above characterization is also pretty close to the mark. The 6to4 spec does mention some checks, but does not spell them out and discuss them properly. This draft (in particular, section 6), tries to spell these out. Additionally, the draft includes a) a better introduction to 6to4 operational modes (sections 2-4), b) threat analysis, and c) some other stuff, like thoughts on ways to enhance 6to4 to better cope with security stuff. Confusing, eh... :-) If it seems appropriate, some of these will probably need to be killed from the document at some point and/or moved elsewhere. > 4. Section 2.1. 2nd paragraph. > > Three comments here: > > 1. s/It is required/It is mandated/ > > 2. My opinion is to delete all text from the 2nd sentence onwards "If > this is restricted", as it is speculative, and would violate 6to4 > specification (section 5.2, and section 5.3) The reason why the text was in there was because at least one implementation had (or has, not sure) a knob to tune that behaviour, and I wanted to illustrate why it didn't work. Maybe this needs rewording, moved somewhere else, or whatnot. > 5. Section 2.4.3 2nd paragraph. > > I don't understand the example. What does the following line mean? > > This assumes that all > outgoing traffic from the main organization (but not between branch > offices) uses one or more non-6to4 connections. > > You have not mentioned the relationship between the main organization, > the branch office, and the native IPv6 internet. Perhaps then the > sentence would be clear. > > I also fail to see how it is similar to the "optimization method". True.. the text takes a bit of assumptions that's for sure :-). The line is used to refer to the fact that 6to4, in this case, would only be used in the "tunnel-endpoint mesh", not in the regular nodes at all. In this case, 6to4 addresses should never be used as source address outside of the site. As for the optimization method, I agree that it's not really all that similar: the reason I used the term is because it's used for optimization within the set of border routers (those still have to have non-6to4 addresses) which use 6to4 as the tunnel-endpoint number technique. > 6. Section 5, 1st paragraph > > You mention about the security checks listed in 6to4. Can you summarize > the security checks within this document? If not, can you give specific > references? Are these same as the checks listed in section 3? This is a bit confusing aspect here. Initially the draft set out as to elaborate, *expand* and enhance the 6to4 security considerations section. It has evolved since. Thus, the relation what's required by RFC3056 and what's included in this draft is not always clear (this draft also adds some checks and spells out the encapsulation/decapsulation rules more). Perhaps their differences should be looked at in more detail... > You also mention - "Many implementations are known to be problematic at > least in some cases". Can you enumerate the implementations, and the > specific cases? I guess Linux is one of them based on the > Acknowledgements section. Linux is one of them, yes. It includes no security checks at all. BSD implementations also missed some checks, at least when I checked over a year ago. > 7. Section 5.1. > > Do you mean 6to4 hosts as compared to 6to4 nodes? No, I think this issue is more generic than that and encompasses all 6to4 nodes. > 8. Section 5.2 > > Remove the 1st paragraph. It is quite confusing. Instead of interpreting > "6to4 routers" as all nodes that have a 6to4 pseudo-interfaces, it would > be better to use the triplet of 6to4 routers, 6to4 hosts, and relay > routers. Yeah, it's confusing, but 6to4 is a bit like that at times. Note that 6to4 hosts don't necessarily have to have a 6to4 pseudo-interface. By "6to4 host", I mean e.g. a node that has autoconfigured a 6to4 address from a RA from a 6to4 router -- it is sometimes also used to refer to an IPv6 host which implements the 6to4 pseudointerface and uses it (but is not a router). The RFC3056 terminology is also confusing on this one, as there is no explicit definion for an IPv6 host which has the pseudo-interface. > 9. Section 5.2.1. > > The attacks are not against the 6to4 pseudo-interface. They are against > nodes -- 6to4 routers, 6to4 hosts, and relay routers -- and they employ a > specific method - ND (or are you implying other types of attacks?). Maybe > the section can be renamed to "ND attacks against 6to4 nodes". Correct, but these attacks come in through the pseudo-interface, and thus the wording. I'm fine with either way as long as this is clear. Note that the security properties of "open to everyone" 6to4 pseudointerface and your regular physical link are likely to be quite different. > In the 3rd paragraph you mention future uses of 6to4. What are the future > uses? I can't locate anything in section 3.1 of 6to4. For example, some mechanism to send link-local packets between 6to4 nodes. Section 3.1 of RFC3056 lists how the address would be created but can't figure out any way how to use it currently -- as it would require some kind of odd IPv4 link-layer mapping technique. A case here could be routing site-local addresses (or some of their counterparts) through 6to4 interfaces, with 6to4 used as a tunnel endpoint mechanism. Not sure if relevant.. This text refers to the case if such a future use would be invented (e.g., relating to multicast w/ 6to4). Not sure if it's really relevant here. > 10. Section 5.2.1.1. > > What is the "situation without 6to4"? Do you mean all forms of *IPv6, and > IPv4* networks that do not employ 6to4? It's a bit of hand-waving, all right :-). The originally I thought it like "if 6to4 did not exist", but that may not be practical .. :-) > In he same section. What is open decapsulation? I use the term "open decapsulation" to refer to an issue in most automatic tunneling techniques, where the decapsulator of the tunnel packets has little or no way to guarantee the tunnel end-point, that is, basically "every packet must be decapsulated". E.g. configured tunneling is not "open" in this sense, as the address of the end-point is known before the fact, and e.g. packets from other sources can even be firewalled away. With open encapsulation, the protocol must be open to the whole world. > I am also a bit confused about this section. Are you trying to list > networks that face a similar threat, and how the threat is handled in > those networks? Yep, that's maybe a bit bad idea.. > 11. Section 5.2.2 > > When you refer to IPv6 nodes, I am assuming that you mean *any* (native > IPv6 node, 6to4 router, 6to4 host, 6to4 relay, native IPv6 router etc) > node on the global IPv6 network. Correct? I think I used the term "native IPv6 node", which I used to mean non-6to4 nodes. As a matter of fact, the critical thing here should probably be the existance of the the 6to4 pseudo-interface. > What is unidirectional address spoofing? I am a bit ignorant on this > front. The text should mention a concise definition or provide a > reference. I don't think this has been coined up, it's a term made up by me (figures ... :-). I use it to refer to spoofing the address to be able to inject packets to a target network for some, typically non-DoS, gain. For example, assume an UDP port in the target host is configured to allow packets only from its on-link neighbor. Now, assume the service behind that UDP port has a security hole which can be exploited using a single (or a couple of packets, no extensive interaction required) packet after passing the "access-list". Using "unidirectional address spoofing", the attacker could try to spoof the source address to be the on-link neighbor and hope to circumvent the access-list ("get better privileges"). The response packets, if any, are naturally lost. > 12. Section 5.2.2.1 > > I don't understand the first paragraph. See below for questions embedded > within the text. > > The unidirectional spoofing attack exists without 6to4 too, but it > requires the attacker is able to spoof IPv6 source addresses. With > 6to4, one is able to launch this attack without any spoofing at all. > > How can the attack be launched without spoofing? Good catch. I meant spoofing that the attacker's ISP could catch, because the attacker doesn't have to spoof anything at the IPv4 layer, just IPv6 which is encapsulated. > A restriction is that the source address cannot be spoofed to belong > ^^^^^^^^^^^ > Restriction on what? On the source address to be forged in the encapsulated packet. > to the destination site as only non-6to4 addresses can be spoofed > (assuming correct implementations). Blindly trusting source address > of packets coming from the Internet without other precautions is very > bad practise, though -- and this attack would typically be useful > only for spoofing destination site -- which is not possible, and can > be protected against with egress filtering. > > Who does the egress filtering, and at what layer - IPv4, IPv6? I think this should actually be the ingress filtering, btw. -- typically it would be done at the IPv6 layer. > I think I have too many questions in this section, and despite rereading > it, I am not able to make much sense. Rephrasing seems to be only > recourse. Right :-) > 13. Section 5.2.2.1 > > I am not in agreement with some of the points made about why the DOS > attack is not critical. > > o 6to4 as an enabling mechanism does not provide any possibility > for packet multiplication, attacks are generally 1:1, > > The word enabling can be removed. OK. > Packet multiplication can be achieved by distributed DOS? Isn’t the same > property (1:1) exhibited in reflection attacks in the IPv4 internet? Yep, that's true. I was trying to refer that 6to4 is not "directed-broadcast" -type DDoS attack, which does provide multiplication. Granted, those are pretty scarce.. > o victim receives packets as replies from "dst": unless echo > service (e.g. UDP port 7) is used, the attacker has reasonably > little control on the content of packets; for example, pure "SYN" > TCP packets often used for flooding cannot be sent, > > If the Reflection attacks are distributed, then they might be severe. Agreed > o attack packets pass through choke point(s), namely (one or more) > 6to4 relays; in addition to physical limitations, these could > implement some form 6to4-site-specific traffic limiting, and > > Yes. Traffic limiting may be done. But it is not a deterministic property > of 6to4 relays, and if the reflection attacks are distributed, then a > large number of relays will be involved, and traffic limiting might not > work. Agreed, there are problems with this model, and if implemented, it would require new specification, implementation etc. This should have been fleshed out a bit at 5.4.3, but is still "TBD." :-) > o one has to know a valid destination address (however, this is > easily guessable or deducible with e.g. an ICMP echo request with > a limited Hop Count). > > This is a moot point. If you are attacking someone you will *have to* > know their address. You have know about the address of the ultimate target, yes, but you may not have to know about the address of the reflector (if just the prefix was enough)? > The 3rd last para mentions - "The attack can be launched from hosts...". > Which hosts do you mean? IPv4 hosts that can access the 6to4 routers? IPv4 hosts, as the attack is done using the encapsulated 6to4 packets. > Don't understand the 2nd last paragraph. Which point is not a real > factor? This tries to (badly) to phrase that sometimes it is not important to spoof your source address anyway, if the attacker is not real you but just a couple of hundred compromized, zombie hosts you don't even know where they are.. > The last sentence says that "This is one of the most serious threats". > Whereas, the section contains many points to argue that the attack is not > critical. Which is it? Good question.. depends on how you evaluate the tradeoffs :-) > 15. I have yet to review the document beyond this point thoroughly. I am > getting a bit confused with the text organization, and mainly with the > usage of the terms - hosts, routers, IPv6 nodes, 6to4 routers - and some > of the contents in particular. I will try to send out remaining comments > in another mail. Agreed. > 16. Ok a quick one before I send of this mail. The algorithms also need > some work to make them more readable, and organized. I am still not able > to appreciate the difference between the generic, and simplified > approach, The simplified just tries to state what the generic says shorter, with a few assumptions -- to be more readable, basically. > and the language used for depicting the algorithm needs to be > made more generic (for eg. "src==2002" can be changed to "prefix (src) > matches 2002". True, I think "src == 2002" should be enough, but as long as the syntax stays simple enough, more precise one should be used instead. Whew.. Thanks for a lot of comments.. I didn't think I would ever be able to get to the end of the document :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 17 17:48: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 RAA25770 for ; Fri, 17 Oct 2003 17:48:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAcKn-0002bk-2v for v6ops-data@psg.com; Fri, 17 Oct 2003 21:40:33 +0000 Received: from [66.218.79.73] (helo=web80503.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AAcKg-0002b4-F4 for v6ops@ops.ietf.org; Fri, 17 Oct 2003 21:40:26 +0000 Message-ID: <20031017214025.75073.qmail@web80503.mail.yahoo.com> Received: from [63.67.101.6] by web80503.mail.yahoo.com via HTTP; Fri, 17 Oct 2003 14:40:25 PDT Date: Fri, 17 Oct 2003 14:40:25 -0700 (PDT) From: Fred Templin Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 To: Pekka Savola Cc: "Follen, Stephen" , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1140651231-1066426825=:74688" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1140651231-1066426825=:74688 Content-Type: text/plain; charset=us-ascii Pekka, I'd rather not get into specifics on your questions just yet in the interest of not bringing confusion into the discussion. But, I have one question relative to a message you posted to this thread on 09/04/2003 where you said: > 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint" > > ==> the node should _not_ "acknowledge" the existence of the tunnel, > otherwise this could be used to probe the acceptable tunnel endpoint > addresses. That is, node should either silently discard the packet, or > send an ICMPv4 Protocol Unreachable message. My question is, why should the node send ICMPv4 *Protocol* Unreachable instead of ICMPv4 *Port* Unreachable? To send "Protocol Unreachable" would seem a bit disingenuous in that it would seem to indicate to the peer that the node's IPv6 stack is down and that future attempts to establish a tunnel with the node would be unsuccessful. "Port Unreachable" would indicate that the node's IPv6 stack is up, but that the tunnel endpoint was not configured. In either case (Protocol vs. Port Unreachable), malicious nodes can probe for acceptable tunnel endpoints, so I see no little value in sending Protocol Unreachable from a security standpoint and the potential for interoperability issues if a legitimate peer wrongly infers that the node's IPv6 stack is down. Comments? Fred Templin osprey67@yahoo.com Pekka Savola wrote: On Tue, 7 Oct 2003, Fred Templin wrote: > Pekka Savola wrote: > >Huh? Which node do you refer by decapsulator -- the one sending ICMPv6 > >DU, or the one receiving it (over the tunnel) and decapsulating it? > > The former (i.e., the one sending ICMPv6 DU). But, you seem > to be assuming that it would be sent back over the bidirectional > tunnel from which the original packet arrived. I am not. What are the scenarios where you wouldn't use bidirectional tunneling? It has been considered to kill unidirectional tunnels from trans-mech-bis, and it would be useful to know whether they're really relevant. > >If the former, I don't really understand how sending a reply would help. > > Well, it could elicit an ICMPv6 Redirect from a router that would > provide information satisfying future ingress filter checks in the > decapsulator, it could provide a traceback mechanism to detect > IPv6 source address spoofing attacks, etc. Do you have more information on these? I fail to see how Redirects would help here, as the source address selection is already done at that phase, and Redirects only look at the destination addresses, as far as I've understood. I'd like to understand how useful this would be before going forward with it. Sending packets to ingress-filtered sources may only aggravate the problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --0-1140651231-1066426825=:74688 Content-Type: text/html; charset=us-ascii
Pekka,
 
I'd rather not get into specifics on your questions just yet in the interest
of not bringing confusion into the discussion. But, I have one question
relative to a message you posted to this thread on 09/04/2003 where
you said:
 
> 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint"
>
>  ==> the node should _not_ "acknowledge" the existence of the tunnel,
> otherwise this could be used to probe the acceptable tunnel endpoint
> addresses.  That is, node should either silently discard the packet, or
> send an ICMPv4 Protocol Unreachable message.
 
My question is, why should the node send ICMPv4 *Protocol* Unreachable
instead of ICMPv4 *Port* Unreachable? To send "Protocol Unreachable" would
seem a bit disingenuous in that it would seem to indicate to the peer that
the node's IPv6 stack is down and that future attempts to establish a tunnel
with the node would be unsuccessful. "Port Unreachable" would indicate
that the node's IPv6 stack is up, but that the tunnel endpoint was not
configured.
 
In either case (Protocol vs. Port Unreachable), malicious nodes can probe
for acceptable tunnel endpoints, so I see no little value in sending
Protocol Unreachable from a security standpoint and the potential for
interoperability issues if a legitimate peer wrongly infers that the node's
IPv6 stack is down.
 
Comments?
 
Fred Templin
osprey67@yahoo.com    

Pekka Savola <pekkas@netcore.fi> wrote:
On Tue, 7 Oct 2003, Fred Templin wrote:
> Pekka Savola wrote:
> >Huh? Which node do you refer by decapsulator -- the one sending ICMPv6
> >DU, or the one receiving it (over the tunnel) and decapsulating it?
>
> The former (i.e., the one sending ICMPv6 DU). But, you seem
> to be assuming that it would be sent back over the bidirectional
> tunnel from which the original packet arrived. I am not.

What are the scenarios where you wouldn't use bidirectional tunneling? It
has been considered to kill unidirectional tunnels from trans-mech-bis,
and it would be useful to know whether they're really relevant.

> >If the former, I don't really understand how sending a reply would help.
>
> Well, it could elicit an ICMPv6 Redirect from a router that would
> provide information satisfying future ingress filter checks in the
> decapsulator, it could provide a traceback mechanism to detect
> IPv6 source address spoofing attacks, etc.

Do you have more information on these? I fail to see how Redirects would
help here, as the source address selection is already done at that phase,
and Redirects only look at the destination addresses, as far as I've
understood.

I'd like to understand how useful this would be before going forward with
it. Sending packets to ingress-filtered sources may only aggravate the
problem.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--0-1140651231-1066426825=:74688-- From owner-v6ops@ops.ietf.org Fri Oct 17 18:35:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28315 for ; Fri, 17 Oct 2003 18:35:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAd9B-0006aA-0w for v6ops-data@psg.com; Fri, 17 Oct 2003 22:32:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AAd94-0006ZX-Ct for v6ops@ops.ietf.org; Fri, 17 Oct 2003 22:32:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9HMVHS02519; Sat, 18 Oct 2003 01:31:17 +0300 Date: Sat, 18 Oct 2003 01:31:16 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Follen, Stephen" , Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 In-Reply-To: <20031017214025.75073.qmail@web80503.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, 17 Oct 2003, Fred Templin wrote: > > 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint" > > > > ==> the node should _not_ "acknowledge" the existence of the tunnel, > > otherwise this could be used to probe the acceptable tunnel endpoint > > addresses. That is, node should either silently discard the packet, or > > send an ICMPv4 Protocol Unreachable message. > > My question is, why should the node send ICMPv4 *Protocol* Unreachable > instead of ICMPv4 *Port* Unreachable? To send "Protocol Unreachable" would > seem a bit disingenuous in that it would seem to indicate to the peer that > the node's IPv6 stack is down and that future attempts to establish a tunnel > with the node would be unsuccessful. "Port Unreachable" would indicate > that the node's IPv6 stack is up, but that the tunnel endpoint was not > configured. My reasoning here was simple: the tunneling uses ip-proto-41, so obviously "port unreachable" would seem to be wrong, as ip-proto-41 doesn't use _ports_ in the first place. The issue would be different if IPv6 was encapsulated on top of UDP, of course. Of course, I'm not saying a message needs to be sent, necessarily .. it depends on what implementations do when they receive an unknown protocol packets. The treatment should probably be the same. I guess most discard them without any further consideration. I think returning a port unreachable would just be overloading a special case semantics into an ICMP message, like "port unreachable in this very specific case implies X", while "protocol unreachable would imply Y" -- I'm not sure that's wise or reasonable considering that port unreachable doesn't *seem* to be directly related to the matter at hand (again, the port vs protocol argument..). > In either case (Protocol vs. Port Unreachable), malicious nodes can probe > for acceptable tunnel endpoints, so I see no little value in sending > Protocol Unreachable from a security standpoint and the potential for > interoperability issues if a legitimate peer wrongly infers that the node's > IPv6 stack is down. The point here is that the attacker should not, by sending a packet or two, be able to distinguish whether the ip-proto-41 tunneling has been enabled in the node in the first place or not. Sending the same ICMP packets as with an unrecognized IP protocol packet would imply that. Another level of "invisibility" would be that the admin of the node would find it's acceptable to say that "yes, I do have a tunnel here, but I just don't tell you what the endpoint is". Maybe that would be acceptable too, I don't know. The other dimension to this debate is, of course, also having the same external behaviour whether the tunnel endpoint was unconfigured, ingress filtering failed, TTL hop limit was wrong, or whatever reasons. This is typical. If the "default" behaviour is to silently discard, this would help in the sense that the attacker would not be able to deduce even: - whether the ip-proto-41 is implemented (if regular behaviour regarding unrecognized protocols is to discard the packets) - whether the tunnel endpoint was configured correctly or not - whether the packet passed the ingress filter - whether the packet passed all the other tests - etc. Yet another angle seems to be the tradeoffs in treatment when the source address of the packet is forged; perhaps sending back ICMP errors would be just what the attacker wants as well, and it might be better to stay silent? (In co-operative environments, this has its downsides as well.) So, I think one could state that not revealing the reason why the packet is dropped and keeping consistent external behaviour seem to be the most important things to consider if one values the "security" tradeoff in this debate. -- 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 Oct 17 20:13: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 UAA00924 for ; Fri, 17 Oct 2003 20:13:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AAed7-000EKS-29 for v6ops-data@psg.com; Sat, 18 Oct 2003 00:07:37 +0000 Received: from [66.218.79.81] (helo=web80511.mail.yahoo.com) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AAecu-000EJq-9E for v6ops@ops.ietf.org; Sat, 18 Oct 2003 00:07:24 +0000 Message-ID: <20031018000723.64248.qmail@web80511.mail.yahoo.com> Received: from [63.67.101.5] by web80511.mail.yahoo.com via HTTP; Fri, 17 Oct 2003 17:07:23 PDT Date: Fri, 17 Oct 2003 17:07:23 -0700 (PDT) From: Fred Templin Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 To: Pekka Savola Cc: "Follen, Stephen" , v6ops@ops.ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1935312511-1066435643=:63232" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1935312511-1066435643=:63232 Content-Type: text/plain; charset=us-ascii Pekka, Only a couple of cursory thoughts to add to the debate at this time; perhaps more later: 1) As to "port unreachable", my thought process is that ip-proto-41 is the "protocol" and the set of all tunnels configured by the node would be the "ports". Using this logic, an unconfigured tunnel would therefore be an "unreachable port". (This does not seem like a showstopper issue to get hung up over, however.) 2) Agree that ICMPv4 Port/Protocol Unreachables do not necessarily need to be sent; RFC 792, P. 4-5 lists them as a *may*. 3) I don't quite agree with the default behavior of silently discard in the case that the tunnel endpoint was correctly configured, but ingress filtering failed. That would be analagous to firewall filtering, and RFC 2463, section 3.1 says that sending an ICMPv6 Destination Unreachable with code 1 (communication with destination administratively prohibited) is a SHOULD. Thanks - Fred osprey67@yahoo.com Pekka Savola wrote: Hi, On Fri, 17 Oct 2003, Fred Templin wrote: > > 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint" > > > > ==> the node should _not_ "acknowledge" the existence of the tunnel, > > otherwise this could be used to probe the acceptable tunnel endpoint > > addresses. That is, node should either silently discard the packet, or > > send an ICMPv4 Protocol Unreachable message. > > My question is, why should the node send ICMPv4 *Protocol* Unreachable > instead of ICMPv4 *Port* Unreachable? To send "Protocol Unreachable" would > seem a bit disingenuous in that it would seem to indicate to the peer that > the node's IPv6 stack is down and that future attempts to establish a tunnel > with the node would be unsuccessful. "Port Unreachable" would indicate > that the node's IPv6 stack is up, but that the tunnel endpoint was not > configured. My reasoning here was simple: the tunneling uses ip-proto-41, so obviously "port unreachable" would seem to be wrong, as ip-proto-41 doesn't use _ports_ in the first place. The issue would be different if IPv6 was encapsulated on top of UDP, of course. Of course, I'm not saying a message needs to be sent, necessarily .. it depends on what implementations do when they receive an unknown protocol packets. The treatment should probably be the same. I guess most discard them without any further consideration. I think returning a port unreachable would just be overloading a special case semantics into an ICMP message, like "port unreachable in this very specific case implies X", while "protocol unreachable would imply Y" -- I'm not sure that's wise or reasonable considering that port unreachable doesn't *seem* to be directly related to the matter at hand (again, the port vs protocol argument..). > In either case (Protocol vs. Port Unreachable), malicious nodes can probe > for acceptable tunnel endpoints, so I see no little value in sending > Protocol Unreachable from a security standpoint and the potential for > interoperability issues if a legitimate peer wrongly infers that the node's > IPv6 stack is down. The point here is that the attacker should not, by sending a packet or two, be able to distinguish whether the ip-proto-41 tunneling has been enabled in the node in the first place or not. Sending the same ICMP packets as with an unrecognized IP protocol packet would imply that. Another level of "invisibility" would be that the admin of the node would find it's acceptable to say that "yes, I do have a tunnel here, but I just don't tell you what the endpoint is". Maybe that would be acceptable too, I don't know. The other dimension to this debate is, of course, also having the same external behaviour whether the tunnel endpoint was unconfigured, ingress filtering failed, TTL hop limit was wrong, or whatever reasons. This is typical. If the "default" behaviour is to silently discard, this would help in the sense that the attacker would not be able to deduce even: - whether the ip-proto-41 is implemented (if regular behaviour regarding unrecognized protocols is to discard the packets) - whether the tunnel endpoint was configured correctly or not - whether the packet passed the ingress filter - whether the packet passed all the other tests - etc. Yet another angle seems to be the tradeoffs in treatment when the source address of the packet is forged; perhaps sending back ICMP errors would be just what the attacker wants as well, and it might be better to stay silent? (In co-operative environments, this has its downsides as well.) So, I think one could state that not revealing the reason why the packet is dropped and keeping consistent external behaviour seem to be the most important things to consider if one values the "security" tradeoff in this debate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --0-1935312511-1066435643=:63232 Content-Type: text/html; charset=us-ascii
Pekka,
 
Only a couple of cursory thoughts to add to the debate at this
time; perhaps more later:
 
 1) As to "port unreachable", my thought process is that ip-proto-41 is
    the "protocol" and the set of all tunnels configured by the node would
    be the "ports". Using this logic, an unconfigured tunnel would therefore
    be an "unreachable port". (This does not seem like a showstopper issue
    to get hung up over, however.)
 
 2) Agree that ICMPv4 Port/Protocol Unreachables do not necessarily
    need to be sent; RFC 792, P. 4-5 lists them as a *may*.
 
 3) I don't quite agree with the default behavior of silently discard
    in the case that the tunnel endpoint was correctly configured,
    but ingress filtering failed. That would be analagous to firewall
    filtering, and RFC 2463, section 3.1 says that sending an
    ICMPv6 Destination Unreachable with code 1 (communication
    with destination administratively prohibited) is a SHOULD. 
 
Thanks - Fred
osprey67@yahoo.com

Pekka Savola <pekkas@netcore.fi> wrote:

Hi,

On Fri, 17 Oct 2003, Fred Templin wrote:
> > 1) "node receives packets from an unknown ("unconfigured") tunnel endpoint"
> >
> > ==> the node should _not_ "acknowledge" the existence of the tunnel,
> > otherwise this could be used to probe the acceptable tunnel endpoint
> > addresses. That is, node should either silently discard the packet, or
> > send an ICMPv4 Protocol Unreachable message.
>
> My question is, why should the node send ICMPv4 *Protocol* Unreachable
> instead of ICMPv4 *Port* Unreachable? To send "Protocol Unreachable" would
> seem a bit disingenuous in that it would seem to indicate to the peer that
> the node's IPv6 stack is down and that future attempts to establish a tunnel
> with the node would be unsuccessful. "Port Unreachable" would indicate
> that the node's IPv6 stack is up, but that the tunnel endpoint was not
> configured.

My reasoning here was simple: the tunneling uses ip-proto-41, so obviously
"port unreachable" would seem to be wrong, as ip-proto-41 doesn't use
_ports_ in the first place. The issue would be different if IPv6 was
encapsulated on top of UDP, of course.

Of course, I'm not saying a message needs to be sent, necessarily .. it
depends on what implementations do when they receive an unknown protocol
packets. The treatment should probably be the same. I guess most discard
them without any further consideration.

I think returning a port unreachable would just be overloading a special
case semantics into an ICMP message, like "port unreachable in this very
specific case implies X", while "protocol unreachable would imply Y" --
I'm not sure that's wise or reasonable considering that port unreachable
doesn't *seem* to be directly related to the matter at hand (again, the
port vs protocol argument..).

> In either case (Protocol vs. Port Unreachable), malicious nodes can probe
> for acceptable tunnel endpoints, so I see no little value in sending
> Protocol Unreachable from a security standpoint and the potential for
> interoperability issues if a legitimate peer wrongly infers that the node's
> IPv6 stack is down.

The point here is that the attacker should not, by sending a packet or
two, be able to distinguish whether the ip-proto-41 tunneling has been
enabled in the node in the first place or not. Sending the same ICMP
packets as with an unrecognized IP protocol packet would imply that.

Another level of "invisibility" would be that the admin of the node would
find it's acceptable to say that "yes, I do have a tunnel here, but I just
don't tell you what the endpoint is". Maybe that would be acceptable too,
I don't know.

The other dimension to this debate is, of course, also having the same
external behaviour whether the tunnel endpoint was unconfigured, ingress
filtering failed, TTL hop limit was wrong, or whatever reasons. This is
typical.

If the "default" behaviour is to silently discard, this would help in the
sense that the attacker would not be able to deduce even:
- whether the ip-proto-41 is implemented (if regular behaviour regarding
unrecognized protocols is to discard the packets)
- whether the tunnel endpoint was configured correctly or not
- whether the packet passed the ingress filter
- whether the packet passed all the other tests
- etc.

Yet another angle seems to be the tradeoffs in treatment when the source
address of the packet is forged; perhaps sending back ICMP errors would be
just what the attacker wants as well, and it might be better to stay
silent? (In co-operative environments, this has its downsides as well.)

So, I think one could state that not revealing the reason why the packet
is dropped and keeping consistent external behaviour seem to be the most
important things to consider if one values the "security" tradeoff in this
debate.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--0-1935312511-1066435643=:63232-- From owner-v6ops@ops.ietf.org Sat Oct 18 08:10: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 IAA26560 for ; Sat, 18 Oct 2003 08:10:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AApjd-0005zY-5v for v6ops-data@psg.com; Sat, 18 Oct 2003 11:59:05 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AApjU-0005yW-Eu for v6ops@ops.ietf.org; Sat, 18 Oct 2003 11:58:56 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA02338 for ; Sat, 18 Oct 2003 12:58:55 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA04981 for ; Sat, 18 Oct 2003 12:58:54 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9IBwsF13999 for v6ops@ops.ietf.org; Sat, 18 Oct 2003 12:58:54 +0100 Date: Sat, 18 Oct 2003 12:58:54 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Comments on draft-ietf-v6ops-ent-scenarios-00 Message-ID: <20031018115854.GI12272@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, Here are some (long) comments on draft 00. I am sorry they are later than ideal but I hope they are still useful prior to Minneapolis. The document is absolutely on the right track, in my view. The detail of comments is mainly for clarification :) The introduction generally reads very well and sets the scene nicely. > Each enterprise will select the transition that best supports their > business requirements. Any attempt to define a default or one-size- > fits-all transition scenario, will simply not work. This document > does not try to depict the drivers for adoption of IPv6 by an > Enterprise. OK, so the next paragraph shouldn't mention drivers = motivations: > While it is difficult to quantify all the potential motivations for s/motivations/scenarios > enterprise network teams to move to IPv6, there are some cases where > an abstract description is possible. The document presents three > example motivations as a general use case. This model can be used to s/motivations/base scenarios > define additional abstractions, for the Enterprise to define > scenarios to fit their requirements. s/scenarios/specific scenarios > The first scenario assumes the Enterprise decides to deploy IPv6 in > parallel with IPv4. The second scenario assumes the Enterprise > decides to deploy IPv6 because of a specific set of applications the > Enterprise wants to use over an IPv6 network. The third scenario > assumes an Enterprise is building a new network or re-structuring an > existing network and decides to deploy IPv6. The document then > defines a set of characteristics that must be analyzed. The document > then provides several scenario examples using the characteristics to s/several/three specific > depict the requirements. These are common Enterprise deployment cases > to depict the challenges for the Enterprise to transition a network > to IPv6. I think one "danger" we have here is that by generalising as we do later down the text, that the requirements become so generalised that the analysis can apply any mechanism to any scenario :) I'm not sure whether that is a real (or important) concern. > The interoperation with legacy functions within the Enterprise will > be required for all transition except possibly by a new network that > will be IPv6 from inception. The network infrastructure components Well, not maybe for scenario 2 below, because we are adding IPv6 for a specific application (let's say a specific IPv6 p2p app like Napster6 :) and in that case we don't care to access legacy networks, as we are purely interested in the v6 app, as the scenario states. > will inform the Enterprise of key points of transition in their > networks that require consideration for IPv6 deployment and > transition. I think "point of transition" is ambiguous - so see below we should define what you mean. > Using the scenarios, characteristics, and examples in the document an > Enterprise can define a scenario. Understanding the legacy functions > and network infrastructure components required, the Enterprise can > determine the network operations required to deploy IPv6. The tools The wording is confusing here: "using a scenario to define a scenario", so we need to write something else... do we mean: Using the base scenarios, characteristics, and examples in the document an Enterprise can define its specific scenario requirements. > Enterprise Network - An Enterprise Network is a network that has > multiple links, a router connection to a > Provider, and is actively managed by a > network operations entity. s/multiple/multiple internal s/a router connection/one or more router connections s/a Provider/one or more Providers (since you mention multihoming in characteristics below) Should we define "point of transition" and "characteristic"? I think it would help. Still a nice short set of definitions :) > Three base scenarios are defined to capture the essential abstraction > set for the Enterprise. Each scenario has assumptions and > requirements. This is not an exhaustive set of scenarios, but a base > set of general cases. We might add another base scenario in Minneapolis but we must ensure that any such addition really adds value so we keep the doc as simple as possible. > 3.1 Base Scenarios Defined > > Scenario 1: Enterprise with an existing IPv4 network wants to deploy > IPv6 in parallel with their IPv4 network. > > **Note To V6ops WG: Would a network topology map be useful here? I don't think such a map is necessary for any of the base scenarios. However, by "in parallel" do you mean dual-stack infrastructure or separate infrastructure, or is that irrelevant? > Assumptions: The IPv4 characteristics have an equivalent in > IPv6. Where might they not do? > Requirements: Don't break IPv4 network characteristics > assumptions with IPv6. IPv6 should be equivalent or > "better" than the ones in IPv4, however, it is > understood that IPv6 is not required to solve every > single problem. Maybe this could say "that IPv6 functionality may not be required, or feasible to deploy, on all parts of the Enterprise's infrastructure" ? > Scenario 2: Enterprise with an existing IPv4 network wants to deploy a > set of particular IPv6 "applications" (application is > voluntarily loosely defined here, e.g. peer to peer). > The IPv6 deployment is limited to the minimum required to > operate this set of applications. > > Assumptions: IPv6 software/hardware components for the application > are available. Hmmm. If the reason is to deploy an IPv6 application (e.g. p2p VoIP) the solution will depend on whether the host is dual-stack (IPv4/IPv6) or IPv6(-only). Clarify, or does it not matter? > Requirements: Don't break IPv4 network operations. That's always a requirement :) For "operations" read "functionality, operation or security" maybe, and probably more beyond. > Scenario 3: Enterprise deploying a new network or re-structuring an > existing network, decides IPv6 is the basis for network > communication. Does this mean IPv6-only network infrastructure? Remember you have defined IPv6 above as equal to IPv6-only, so is that what you mean here? > Assumptions: Required IPv6 network components are available, or > available over some defined timeline. Again, do you really mean IPv6-only, or IPv6-capable? > Requirements: Interoperation and Coexistence with IPv4 network > operations and applications are required for > communications. So is scenario 3 an IPv6-only network into which IPv6-only or dual-stack hosts may be deployed? If so maybe state that 3 paragraphs up. I think the four sets of characteristics below are fine to cover the basic requirements. > Characteristic 1 - Providers for External Network Operation > - IPv4 existing address ownership (Provider based addresses vs. > Provider independent addresses)? And number of globally routable IPv4 addresses available? > - Do ISPs offer IPv6 service? By service do you mean native service, or tunnelled, or any service...? > Characteristic 3 - Enterprise IT Department Operations Analysis > - Is inter-site communications required? You have "one site vs multiple sites" in characteristic 1? > - External IPv4 routing protocols used? That one belongs in characteristic 1? > - List of "network operation" software that may be impacted by IPv6? > - DNS > - Management (SNMP & ad-hoc tools) > - Enterprise Network Servers > - Mail Servers > - High Availability Software for Nodes > - Directory Services - Other services (NTP, others...?) > - Are all these software functions upgradeable to IPv6? > - If not upgradeable, then what are the workarounds? - If not upgradeable, can an equivalent upgradeable software function be substituted for the one that is not upgradeable? (e.g. a different directory service mechanism) > Characteristics 4 - Enterprise Network Management System > - Management of Transition Tools and Mechanisms? This is an important area the WG needs to take on board. > - What new considerations does IPv6 create for Network > Management? Does this affect the transition tool analysis, e.g. if RFC3041 means that IP-based authentication is no longer possible? I guess it may affect a specific implementation of a security policy? > This section presents a set of Base Scenario Examples and is not an > exhaustive list of examples. These examples were selected to provide > further clarity of Base Scenarios within an Enterprise of a less > abstract nature. I think these are now Specific Scenario Examples not Base ones? The answering of the characteristics against the base scenarios higher up in the document leads to these specific examples? > A bank running a large ATM network supporting an order of magnitude > number of transactions per second, with access to a central database > on an external network from the ATM network: "An order of magnitude number of transactions" is missing a word or two :) > - External connectivity not required. > - Multiple sites connected by VPN. > - Multiple sites connected by Native IP protocol. Perhaps add that it may use Net10 addressing? We should not hide from the Net10/ANT issues for transitioning networks. We have the Hinden draft on the way, although this example probably uses RFC1918 but not NAT :) > 4. Support for Legacy IPv4 Nodes and Applications s/Nodes/Nodes, Services ? > The Enterprise network will have to support the coexistence of IPv6 > and IPv4, to support legacy IPv4 applications and nodes. The > Enterprise user has the following choices for that coexistence to > consider today. Does this mean "of IPv6-only and IPv4-only"? This is what is implied by the definition of terms at the start of the document. Do we actually mean "IPv6-capable and IPv4-capable" or, in the language of the definitions, "IPv6, IPv4 and IPv4/IPv6" applications and nodes? > 4.3 IPv6 communicating with IPv4 > > An IPv6 only node wants to communicate with an IPv4 only node. Note the node can be IPv4/IPv6 but the application may be IPv4, e.g. if the source code is lost or the language it is written in has no IPv6 API? So do we actually mean "node" or "application"? We probably mean "services or applications on a node" as RPC, NIS, SMTP etc are services. > In cases where the IPv6 host cannot be a dual stack, in order to > continue support of communications with IPv4 nodes an IPv4/v6 > translator is required. Introduction of such translator will prevent > usage of end-to-end security and application carrying embedded IP > addressing information. You could say the translator may be at the network, transport or application layer. > **Note to V6ops WG: Should we discuss porting of applications too in > the legacy section? I think this is done in the "application aspects" draft fine already, i.e. in draft-shin-v6ops-application-transition-01. > 5. Network Infrastructure Requirements > > The Enterprise will need to determine what network infrastructure > components require enhancements or to be added for deployment of > IPv6. This infrastructure will need to be analyzed and understood as > a critical resource to manage. > > 5.1 DNS > > DNS will now have to support both IPv4 and IPv6 DNS records and the > Enterprise will need to determine how the DNS is to be managed and > accessed, and secured. > > **Note to V6ops WG: Should we get into other DNS issues? There are three categories of issues I think, i.e. - standards: dns resolver discovery, 512-byte response format, reverse zone managemnt and dynamic dns - transport: root servsers, OS supporting native lookup, and whether the upstream ISPs filter the root space /48's - registry: registering domains with IPv6 DNS servers Also, do you have control over your own DNS? And is it important that reverse DNS lookup works, e.g. for sendmail to verify sender hosts? If so reverse population of statelessly autoconfiguring will be needed, and 6to4 use will be problematic? > 5.2 Routing > > IPv6/IPv4 routers should be monitored to ensure the router has > sufficient storage for both IPv6 and IPv4 route tables. Existing > network design principles to limit the number of routes in the > network, such as prefix aggregation, become more critical with the > addition of IPv6 to an existing IPv4 network. > > **Note to V6ops WG: Above is example of additional text we could add > to each component we list here. Are there other Routing issues? Other issues are whether the upstream provider supports IPv6 natively or offers transition aids, e.g. 6to4, site tunnel broker. > 5.3 Autoconfiguration > > IPv6 introduces the concept of stateless autoconfiguration in > addition to statefull autoconfiguration. The enterprise will have to > determine the best method of autoconfiguration, for their network. > > **Note to V6ops WG: Should we get into other autoconfiguration > issues? Will the enterprise need IPv6 prefix delegation? Will it need DHCPv6 forwarding? > 5.4 Security > > Current existing mechanisms used for IPv4 to provide security need to > be supported for IPv6 within the Enterprise. IPv6 should create no > new security concerns for IPv4. > > **Note to V6ops WG: Should we get into other security issues? I think Pekka's security draft could be cited: draft-savola-v6ops-security-overview-00 Issues include backdoors for tunnels, handling firewall policy for end-to-end encryption, dual-stack possibly adding complexity to analysis, and DoS relay type attacks (e.g. 6to4 relays). > 5.5 Applications > > Existing applications will need to be ported to support both IPv4 and > IPv6. > > **Note to V6ops WG: Should we get into other application issues? Not beyond the shin-v6ops draft. > 5.6 Network Management > > The addition of IPv6 and points of transition will need to be managed > by the Enterprise network operations center. This will affect many > components of the network and software required on nodes. > > **Note to V6ops WG: Should we get into other Management issues? Probably not. > 5.7 Address Planning > > The address space within the Enterprise will need to be defined and > coordinated with the routing topology of the Enterprise network. > > **Note to V6ops WG: Should we get into other Address Planning issues? Would IPv4 and IPv6 subnets be congruent? An advantage of IPv6 is that you are unlikely to ever need to resize the subnets (up or down). Available IPv4 address space affects (for example) the DSTM pool, NAT-PT, etc. Do we have address space independence from provider? > **Note to V6ops WG: What other components are we missing? Here are some additional possible components: 5.8 Multicast Both from routing aspects, but also things like MLDv1/2 snooping to help avoid traffic flooding. If multicast is needed then some tools may not be useful, e.g. 6to4 (there was a draft on 6to4 and multicast, but it seemed to have died). 5.9 Service discovery mechanisms The infrastructure may need to support many of these because there is little harmonisation of techniques in various standards, e.g. - LDAP or NIS - Well-known names - Well-known addresses - IPv4 or IPv6 anycast - LLMNR - DHCPv6 (Lite) - SLP, etc > 7. References Maybe the applications draft (see above) and Pekka's transition architectures doc? (draft-savola-v6ops-transarch-01) And his security doc: draft-savola-v6ops-security-overview-00 ? There's also RFC1752 which we could either cite or state that we no longer use as a yardstick. It talked about transition goals like: - incremental upgrade (hosts not routers) - incremental deployment (routers) - easy addressing (use dual-stack) - low start-up costs (procure wisely so infra enabled) Other general comments: ----------------------- What about preference of use of IPv4 or IPv6? How do we handle the "NAT is our policy" sites? Are IPv6-specific features out of scope... e.g. privacy extensions which may impact policy implementations like (weak) IP-based authentication? What about remote IPv4 nodes wishing to access your site IPv6(-only) services? Do you deploy (say) NAT-PT yourself, or rely on the remote site to introduce its own tools? Maybe this is covered OK in 4.3, but we could explicitly expand on it. What about use of existing "software functions" that may ease transition, e.g. if already using proxies like web, mail, etc already, or using VLANs? We should capture general transition tool requirements somewhere, e.g. a site depends on handling 100,000 remote transactions per hour, then any proxies, translators, etc must be able to support that level. Tim From owner-v6ops@ops.ietf.org Sun Oct 19 21:24: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 VAA25178 for ; Sun, 19 Oct 2003 21:24:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABOZl-000FPk-24 for v6ops-data@psg.com; Mon, 20 Oct 2003 01:11:13 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABOZc-000FOi-95 for v6ops@ops.ietf.org; Mon, 20 Oct 2003 01:11:04 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 65729A34B; Sun, 19 Oct 2003 21:11:03 -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, 19 Oct 2003 21:11:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 Date: Sun, 19 Oct 2003 21:11:02 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA146@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOVcPdnWKGVipjYRf+bM5WEQ5mnAwBNQvYA From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 20 Oct 2003 01:11:03.0179 (UTC) FILETIME=[07D7BDB0:01C396A7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Tim, Thanks for your review. I am on R&R this week so cannot respond. Also the document when announced should have said Jim Bound (EDITOR). I will hope that my other team members can comment and begin this discussion with you. Wherever you have "you" below though, WG should replace with "design team" in their mind. So its not "my" view or "my" doc or whatever. Point is this is great to see and it would be good of if the WG could have good discussion on this mail list. Though Tim you are on the Enterprise Design team and you know we had a deadline to make the -00 and we would have loved to have received this input off line before ID submission date, but good you found time to review quickly. You should answer your own questions here too as member of the team :--) I will keep all of these responses and answers as Editor and record. If I have input from study of the responses, I will assemble as few responses as possible from my view to support the chairs wanting to keep email well thought out and constructive and reduced. Tim's mail IMO is a good example of that case too. After R&R time-out this week of course. thanks /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk]=20 > Sent: Saturday, October 18, 2003 7:59 AM > To: v6ops@ops.ietf.org > Subject: Comments on draft-ietf-v6ops-ent-scenarios-00 >=20 >=20 >=20 > Hi Jim, >=20 > Here are some (long) comments on draft 00. I am sorry they=20 > are later than=20 > ideal but I hope they are still useful prior to Minneapolis. >=20 > The document is absolutely on the right track, in my view. =20 > The detail of comments is mainly for clarification :) >=20 > The introduction generally reads very well and sets the scene nicely. >=20 > > Each enterprise will select the transition that best=20 > supports their > > business requirements. Any attempt to define a default=20 > or one-size- > > fits-all transition scenario, will simply not work. This document > > does not try to depict the drivers for adoption of IPv6 by an > > Enterprise. >=20 > OK, so the next paragraph shouldn't mention drivers =3D motivations: >=20 > > While it is difficult to quantify all the potential=20 > motivations for >=20 > s/motivations/scenarios >=20 > > enterprise network teams to move to IPv6, there are some=20 > cases where > > an abstract description is possible. The document presents three > > example motivations as a general use case. This model=20 > can be used to >=20 > s/motivations/base scenarios=20 >=20 > > define additional abstractions, for the Enterprise to define > > scenarios to fit their requirements. >=20 > s/scenarios/specific scenarios >=20 > > The first scenario assumes the Enterprise decides to=20 > deploy IPv6 in > > parallel with IPv4. The second scenario assumes the Enterprise > > decides to deploy IPv6 because of a specific set of=20 > applications the > > Enterprise wants to use over an IPv6 network. The third scenario > > assumes an Enterprise is building a new network or=20 > re-structuring an > > existing network and decides to deploy IPv6. The document then > > defines a set of characteristics that must be analyzed. =20 > The document > > then provides several scenario examples using the=20 > characteristics=20 > > to >=20 > s/several/three specific >=20 > > depict the requirements. These are common Enterprise=20 > deployment cases > > to depict the challenges for the Enterprise to=20 > transition a network > > to IPv6. >=20 > I think one "danger" we have here is that by generalising as=20 > we do later down the text, that the requirements become so=20 > generalised that the analysis can > apply any mechanism to any scenario :) I'm not sure whether that is > a real (or important) concern. >=20 > > The interoperation with legacy functions within the=20 > Enterprise will > > be required for all transition except possibly by a new=20 > network that > > will be IPv6 from inception. The network infrastructure=20 > components >=20 > Well, not maybe for scenario 2 below, because we are adding=20 > IPv6 for a specific application (let's say a specific IPv6=20 > p2p app like Napster6 :) and in that case we don't care to=20 > access legacy networks, as we are purely interested in the v6=20 > app, as the scenario states. >=20 > > will inform the Enterprise of key points of transition in their > > networks that require consideration for IPv6 deployment and > > transition. >=20 > I think "point of transition" is ambiguous - so see below we=20 > should define what you mean. > =20 > > Using the scenarios, characteristics, and examples in=20 > the document an > > Enterprise can define a scenario. Understanding the=20 > legacy functions > > and network infrastructure components required, the=20 > Enterprise can > > determine the network operations required to deploy=20 > IPv6. The tools > =20 > The wording is confusing here: "using a scenario to define a=20 > scenario", so we need to write something else... do we mean: >=20 > Using the base scenarios, characteristics, and examples=20 > in the document=20 > an Enterprise can define its specific scenario requirements. >=20 > > Enterprise Network - An Enterprise Network is a=20 > network that has > > multiple links, a router connection to a > > Provider, and is actively managed by a > > network operations entity. >=20 > s/multiple/multiple internal >=20 > s/a router connection/one or more router connections > s/a Provider/one or more Providers > (since you mention multihoming in characteristics below) >=20 > Should we define "point of transition" and "characteristic"? =20 > I think it would help. Still a nice short set of definitions :) =20 >=20 > > Three base scenarios are defined to capture the=20 > essential abstraction > > set for the Enterprise. Each scenario has assumptions and > > requirements. This is not an exhaustive set of=20 > scenarios, but a base > > set of general cases. >=20 > We might add another base scenario in Minneapolis but we must=20 > ensure that any such addition really adds value so we keep=20 > the doc as simple as possible. > =20 > > 3.1 Base Scenarios Defined > >=20 > > Scenario 1: Enterprise with an existing IPv4 network=20 > wants to deploy > > IPv6 in parallel with their IPv4 network. > >=20 > > **Note To V6ops WG: Would a network topology map be useful here? >=20 > I don't think such a map is necessary for any of the base scenarios. > =20 > However, by "in parallel" do you mean dual-stack=20 > infrastructure or separate=20 > infrastructure, or is that irrelevant? >=20 > > Assumptions: The IPv4 characteristics have an equivalent in > > IPv6. >=20 > Where might they not do? > =20 > > Requirements: Don't break IPv4 network characteristics > > assumptions with IPv6. IPv6 should be=20 > equivalent or > > "better" than the ones in IPv4, however, it is > > understood that IPv6 is not required to=20 > solve every > > single problem. >=20 > Maybe this could say "that IPv6 functionality may not be=20 > required, or feasible to deploy, on all parts of the=20 > Enterprise's infrastructure" ? >=20 > > Scenario 2: Enterprise with an existing IPv4 network=20 > wants to deploy a > > set of particular IPv6 "applications"=20 > (application is > > voluntarily loosely defined here, e.g. peer=20 > to peer). > > The IPv6 deployment is limited to the=20 > minimum required to > > operate this set of applications. > > > > Assumptions: IPv6 software/hardware components for the=20 > application > > are available. >=20 > Hmmm. If the reason is to deploy an IPv6 application (e.g.=20 > p2p VoIP) the solution will depend on whether the host is=20 > dual-stack (IPv4/IPv6) or=20 > IPv6(-only). Clarify, or does it not matter? >=20 > > Requirements: Don't break IPv4 network operations. >=20 > That's always a requirement :) For "operations" read "functionality, > operation or security" maybe, and probably more beyond. >=20 > > Scenario 3: Enterprise deploying a new network or=20 > re-structuring an > > existing network, decides IPv6 is the basis=20 > for network > > communication. >=20 > Does this mean IPv6-only network infrastructure? Remember=20 > you have defined > IPv6 above as equal to IPv6-only, so is that what you mean here? > =20 > > Assumptions: Required IPv6 network components are available, or > > available over some defined timeline. >=20 > Again, do you really mean IPv6-only, or IPv6-capable? >=20 > > Requirements: Interoperation and Coexistence with IPv4 network > > operations and applications are required for > > communications. >=20 > So is scenario 3 an IPv6-only network into which IPv6-only or=20 > dual-stack hosts may be deployed? If so maybe state that 3=20 > paragraphs up. > =20 > I think the four sets of characteristics below are fine to=20 > cover the basic requirements. >=20 > > Characteristic 1 - Providers for External Network Operation > > - IPv4 existing address ownership (Provider based addresses vs. > > Provider independent addresses)? >=20 > And number of globally routable IPv4 addresses available? >=20 > > - Do ISPs offer IPv6 service? >=20 > By service do you mean native service, or tunnelled, or any=20 > service...? >=20 > > Characteristic 3 - Enterprise IT Department Operations Analysis > > - Is inter-site communications required? >=20 > You have "one site vs multiple sites" in characteristic 1? >=20 > > - External IPv4 routing protocols used? >=20 > That one belongs in characteristic 1? >=20 > > - List of "network operation" software that may be=20 > impacted by IPv6? > > - DNS > > - Management (SNMP & ad-hoc tools) > > - Enterprise Network Servers > > - Mail Servers > > - High Availability Software for Nodes > > - Directory Services >=20 > - Other services (NTP, others...?) >=20 > > - Are all these software functions upgradeable to IPv6? > > - If not upgradeable, then what are the workarounds? >=20 > - If not upgradeable, can an equivalent upgradeable=20 > software function=20 > be substituted for the one that is not upgradeable?=20 > (e.g. a different > directory service mechanism) >=20 > > Characteristics 4 - Enterprise Network Management System > > - Management of Transition Tools and Mechanisms? >=20 > This is an important area the WG needs to take on board. >=20 > > - What new considerations does IPv6 create for Network > > Management? >=20 > Does this affect the transition tool analysis, e.g. if=20 > RFC3041 means that IP-based authentication is no longer=20 > possible? I guess it may affect a=20 > specific implementation of a security policy? >=20 > > This section presents a set of Base Scenario Examples=20 > and is not an > > exhaustive list of examples. These examples were=20 > selected to provide > > further clarity of Base Scenarios within an Enterprise of a less > > abstract nature. >=20 > I think these are now Specific Scenario Examples not Base=20 > ones? The answering of the characteristics against the base=20 > scenarios higher up in the document leads to these specific examples? > =20 > > A bank running a large ATM network supporting an order=20 > of magnitude > > number of transactions per second, with access to a=20 > central database > > on an external network from the ATM network: >=20 > "An order of magnitude number of transactions" is missing a=20 > word or two :) > =20 > > - External connectivity not required. > > - Multiple sites connected by VPN. > > - Multiple sites connected by Native IP protocol. >=20 > Perhaps add that it may use Net10 addressing? We should not=20 > hide from the > Net10/ANT issues for transitioning networks. We have the=20 > Hinden draft on the way, although this example probably uses=20 > RFC1918 but not NAT :) > =20 > > 4. Support for Legacy IPv4 Nodes and Applications >=20 > s/Nodes/Nodes, Services ? > =20 > > The Enterprise network will have to support the=20 > coexistence of IPv6 > > and IPv4, to support legacy IPv4 applications and nodes. The > > Enterprise user has the following choices for that coexistence to > > consider today. >=20 > Does this mean "of IPv6-only and IPv4-only"? This is what is=20 > implied by the definition of terms at the start of the=20 > document. Do we actually mean "IPv6-capable and=20 > IPv4-capable" or, in the language of the definitions,=20 > "IPv6, IPv4 and IPv4/IPv6" applications and nodes? >=20 > > 4.3 IPv6 communicating with IPv4 > >=20 > > An IPv6 only node wants to communicate with an IPv4 only node. >=20 > Note the node can be IPv4/IPv6 but the application may be=20 > IPv4, e.g. if the source code is lost or the language it is=20 > written in has no IPv6 API? >=20 > So do we actually mean "node" or "application"? We probably=20 > mean "services > or applications on a node" as RPC, NIS, SMTP etc are services. >=20 > > In cases where the IPv6 host cannot be a dual stack, in order to > > continue support of communications with IPv4 nodes an IPv4/v6 > > translator is required. Introduction of such translator=20 > will prevent > > usage of end-to-end security and application carrying embedded IP > > addressing information. >=20 > You could say the translator may be at the network, transport=20 > or application layer. > =20 > > **Note to V6ops WG: Should we discuss porting of=20 > applications too in > > the legacy section? >=20 > I think this is done in the "application aspects" draft fine=20 > already, i.e. in draft-shin-v6ops-application-transition-01. > =20 > > 5. Network Infrastructure Requirements > >=20 > > The Enterprise will need to determine what network infrastructure > > components require enhancements or to be added for deployment of > > IPv6. This infrastructure will need to be analyzed and=20 > understood as > > a critical resource to manage. > >=20 > > 5.1 DNS > >=20 > > DNS will now have to support both IPv4 and IPv6 DNS=20 > records and the > > Enterprise will need to determine how the DNS is to be=20 > managed and > > accessed, and secured. > >=20 > > **Note to V6ops WG: Should we get into other DNS issues? >=20 > There are three categories of issues I think, i.e. >=20 > - standards: dns resolver discovery, 512-byte response format,=20 > reverse zone managemnt and dynamic dns >=20 > - transport: root servsers, OS supporting native lookup,=20 > and whether the > upstream ISPs filter the root space /48's >=20 > - registry: registering domains with IPv6 DNS servers >=20 > Also, do you have control over your own DNS? >=20 > And is it important that reverse DNS lookup works, e.g. for=20 > sendmail to verify sender hosts? If so reverse population of=20 > statelessly autoconfiguring will be needed, and 6to4 use will=20 > be problematic? > =20 > > 5.2 Routing > >=20 > > IPv6/IPv4 routers should be monitored to ensure the router has > > sufficient storage for both IPv6 and IPv4 route tables. Existing > > network design principles to limit the number of routes in the > > network, such as prefix aggregation, become more=20 > critical with the > > addition of IPv6 to an existing IPv4 network. > >=20 > > **Note to V6ops WG: Above is example of additional text=20 > we could add > > to each component we list here. Are there other Routing issues? >=20 > Other issues are whether the upstream provider supports IPv6=20 > natively or offers transition aids, e.g. 6to4, site tunnel broker. > =20 > > 5.3 Autoconfiguration > >=20 > > IPv6 introduces the concept of stateless autoconfiguration in > > addition to statefull autoconfiguration. The enterprise=20 > will have to > > determine the best method of autoconfiguration, for=20 > their network. > >=20 > > **Note to V6ops WG: Should we get into other autoconfiguration > > issues? >=20 > Will the enterprise need IPv6 prefix delegation? >=20 > Will it need DHCPv6 forwarding? > =20 > > 5.4 Security > >=20 > > Current existing mechanisms used for IPv4 to provide=20 > security need to > > be supported for IPv6 within the Enterprise. IPv6=20 > should create no > > new security concerns for IPv4. > >=20 > > **Note to V6ops WG: Should we get into other security issues? >=20 > I think Pekka's security draft could be cited:=20 > draft-savola-v6ops-security-overview-00 >=20 > Issues include backdoors for tunnels, handling firewall=20 > policy for end-to-end encryption, dual-stack possibly adding=20 > complexity to analysis, and DoS relay type attacks (e.g. 6to4 relays). >=20 > > 5.5 Applications > >=20 > > Existing applications will need to be ported to support=20 > both IPv4 and > > IPv6. > >=20 > > **Note to V6ops WG: Should we get into other application issues? >=20 > Not beyond the shin-v6ops draft. > =20 > > 5.6 Network Management > >=20 > > The addition of IPv6 and points of transition will need=20 > to be managed > > by the Enterprise network operations center. This will=20 > affect many > > components of the network and software required on nodes. > >=20 > > **Note to V6ops WG: Should we get into other Management issues? >=20 > Probably not. > =20 > > 5.7 Address Planning > >=20 > > The address space within the Enterprise will need to be=20 > defined and > > coordinated with the routing topology of the Enterprise network. > >=20 > > **Note to V6ops WG: Should we get into other Address Planning=20 > > issues? >=20 > Would IPv4 and IPv6 subnets be congruent? >=20 > An advantage of IPv6 is that you are unlikely to ever need to=20 > resize the subnets (up or down). >=20 > Available IPv4 address space affects (for example) the DSTM=20 > pool, NAT-PT, etc. >=20 > Do we have address space independence from provider? > =20 > > **Note to V6ops WG: What other components are we missing? >=20 > Here are some additional possible components: >=20 > 5.8 Multicast >=20 > Both from routing aspects, but also things like MLDv1/2=20 > snooping to help avoid traffic flooding. >=20 > If multicast is needed then some tools may not be useful,=20 > e.g. 6to4 (there was a draft on 6to4 and multicast, but it=20 > seemed to have died). >=20 > 5.9 Service discovery mechanisms >=20 > The infrastructure may need to support many of these because=20 > there is little harmonisation of techniques in various standards, e.g. > - LDAP or NIS > - Well-known names > - Well-known addresses > - IPv4 or IPv6 anycast > - LLMNR > - DHCPv6 (Lite) > - SLP, etc >=20 >=20 > > 7. References >=20 > Maybe the applications draft (see above) and Pekka's transition=20 > architectures doc? (draft-savola-v6ops-transarch-01) And=20 > his security > doc: draft-savola-v6ops-security-overview-00 ? >=20 > There's also RFC1752 which we could either cite or state that we no=20 > longer use as a yardstick. It talked about transition goals like: > - incremental upgrade (hosts not routers) > - incremental deployment (routers) > - easy addressing (use dual-stack) > - low start-up costs (procure wisely so infra enabled) >=20 >=20 > Other general comments: > ----------------------- >=20 > What about preference of use of IPv4 or IPv6? >=20 > How do we handle the "NAT is our policy" sites? >=20 > Are IPv6-specific features out of scope... e.g. privacy=20 > extensions which may impact policy implementations like=20 > (weak) IP-based authentication? >=20 > What about remote IPv4 nodes wishing to access your site=20 > IPv6(-only) services? Do you deploy (say) NAT-PT yourself, or=20 > rely on the remote site to introduce=20 > its own tools? Maybe this is covered OK in 4.3, but we=20 > could explicitly > expand on it. >=20 > What about use of existing "software functions" that may ease=20 > transition, e.g. if already using proxies like web, mail, etc=20 > already, or using VLANs? >=20 > We should capture general transition tool requirements=20 > somewhere, e.g. a site depends on handling 100,000 remote=20 > transactions per hour, then any proxies, > translators, etc must be able to support that level. =20 >=20 >=20 > Tim >=20 >=20 From owner-v6ops@ops.ietf.org Mon Oct 20 01:39:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01041 for ; Mon, 20 Oct 2003 01:39:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABScK-000FiM-LC for v6ops-data@psg.com; Mon, 20 Oct 2003 05:30:08 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABSbx-000FfF-UE for v6ops@ops.ietf.org; Mon, 20 Oct 2003 05:29:46 +0000 Received: from consulintel02 ([202.133.104.44]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 18-md50000000001.tmp for ; Mon, 20 Oct 2003 07:33:29 +0200 Message-ID: <38a801c396cb$7fa8c400$69ee62c3@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: draft-palet-v6ops-proto41-nat-01.txt Date: Mon, 20 Oct 2003 12:47:24 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 20 Oct 2003 07:33:29 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 202.133.104.44 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Rute, Finally I've got some time to update this document. I'm posting a new draft in a couple of hours. I've tried to reply to your comments (also in-line in your email, but you need to look into the new draft to match them). Regards, Jordi ----- Original Message ----- From: "Rute C. Sofia" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, August 19, 2003 1:37 AM Subject: Re: draft-palet-v6ops-proto41-nat-01.txt > Hi Jordi, > > comments on the draft: > > - abstract, 3rd paragraph "this behavior provides a big > opportunity...when is not possible to offer native IPv6 or 6to4" > *Suggestion: change this paragraph to something such as" this is a > fallback option only to be used either when there > is > no possibility of offering native IPv6, or 6to4 (reference here)" This reference is there already. > > - Introduction > * the first 2 paragraphs are a copy of the abstract. My suggestion would > be to take them out, and re-write this section...however, I believe that > the abstract should contemplate some info presented such as: not only that > this is a temporary fallback solution (as stated), but also, that this is > only aplicable to the subset of NATs that allow protocol 41. I rewrite it in part. As the number of boxes that support it seems quite high, I think is more relevant in the Applicability section. > > - section 3., NAT types. > *This section is a bit confusing; I believe that you are following the > nomenclature > presented in rfc 2766; Basic is the "Traditional" type, right? Basic is > confusing, given that NAPT-PT (I believe that's what you mean in section > 3.2) is a form of the traditional NAT-PT; > * Also, in 3.2. , you say "...This can also be combined with basic NAT". > So I'm lost here. > * Isn't 3.4 a subset of 3.3? No, as indicated in the document, it comes from RFC2663. > > - Section 4., Applicability > *1st paragraph states a problem with NAT, not IPv6+NAT. Now, the paragraph > seems to imply that this is due to IPv6 and NAT. I think now is more clear. > * 5th paragraph, "This configuration can be a default one...". Even though > you speak of private addresses, this option is a bit limiting, isn't it? > No, a lot of NAT boxes, come with a default configuration, so why not proto41 also ? > *6th,7th paragraph are out of context in this section; should be moved to > the intro. I agree un part only ;-) > > - Section 5. > * you say that most vendors support proto-41. How many were checked? which > percentage support ip proto-41 and how many provided bidirectionality? > This would be interesting data to be include. I put some numbers, but we need to understand that the survey we did is not an "universal" one, that's why I thought is better don't put the figures initially. Anyway, considering that some big manufacturers replied, and that they have a big portion of the market ... > * 3rd paragraph. It is a fact that 6to4 and proto-41 can coexist in the > same box. But the question is? Why would they, when you claim that the > current solution is simply a "temporary fallback" one, when there is > either no 6to4 or native support? This paragraph contradicts the abstract, > the intro and the previous one. No, isn't contradictory, and it was requested by somebody in Vienna. To clarify it, I put an example with mobile users. > > Rute > > > > > > > > On Sun, 3 Aug 2003, JORDI PALET MARTINEZ wrote: > > > Hi all, > > > > The revision of the document indicated in the subject, has been published a few days ago, as indicated below. > > > > I will be happy to get new comments from the WG. > > > > Regards, > > Jordi > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : Forwarding Protocol 41 in NAT Boxes > > Author(s) : J. Palet et al. > > Filename : draft-palet-v6ops-proto41-nat-01.txt > > Pages : 12 > > Date : 2003-7-31 > > > > Some NAT boxes/routers allow the establishment of IPv6 tunnels from > > systems in the private LAN (using private IPv4 addresses) to routers > > or tunnel servers in the public Internet. > > As far as we know this is not a common way of use IPv6 tunnels; the > > usual way is to finish the tunnel directly in a device with an IPv4 > > public address. > > This behavior provides a big opportunity to rapidly deploy a huge > > number of IPv6 nodes and networks, without the need of new transition > > mechanism. This option is very important to facilitate the IPv6 > > deployment. > > This document describes this behavior and provides hints that should > > be applied in the NAT boxes and tunnel brokers to facilitate it. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-palet-v6ops-proto41-nat-01.txt > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on-line at: > > http://www.ipv6-es.com > > > > > > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Oct 20 02:52: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 CAA15027 for ; Mon, 20 Oct 2003 02:52:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABTo1-000Nex-Ik for v6ops-data@psg.com; Mon, 20 Oct 2003 06:46:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABTns-000Ndi-8K for v6ops@ops.ietf.org; Mon, 20 Oct 2003 06:46:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9K6jpB07240; Mon, 20 Oct 2003 09:45:51 +0300 Date: Mon, 20 Oct 2003 09:45:51 +0300 (EEST) From: Pekka Savola To: Fred Templin cc: "Follen, Stephen" , Subject: Re: RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4 In-Reply-To: <20031018000723.64248.qmail@web80511.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, 17 Oct 2003, Fred Templin wrote: > 1) As to "port unreachable", my thought process is that ip-proto-41 is > the "protocol" and the set of all tunnels configured by the node would > be the "ports". Using this logic, an unconfigured tunnel would therefore > be an "unreachable port". (This does not seem like a showstopper issue > to get hung up over, however.) This seems like one rather reasonable technical interpretation of this issue. I'm not sure if I agree with it, but I wouldn't have objections if folks think this is the best way forward. [...] > 3) I don't quite agree with the default behavior of silently discard > in the case that the tunnel endpoint was correctly configured, > but ingress filtering failed. That would be analagous to firewall > filtering, and RFC 2463, section 3.1 says that sending an > ICMPv6 Destination Unreachable with code 1 (communication > with destination administratively prohibited) is a SHOULD. Note that sending any messages back from a router or a firewall only makes sense if there is reasonable guarantee/"hope" that the node really who sent the triggering will be able to receive the ICMP unreachable message. In particular with ingress filtering (based on the source address), this assumption may not hold. That is, if the address is spoofed or otherwise wrong, it by definition does not get back to the *right* source node, and sending a message could maybe even be considered counter-productive. On the other hand, if the address is not spoofed, but only comes from a wrong direction (e.g., consider an ISP ingress filtering a customer that is connected to two ISPs with two provider-aggregatable prefixes, and the customer sends a packet using the wrong source address to the wrong ISP), there *might* be a reason for sending such an unreachable message. The question then would be whether these two cases can be reasonably easily distinguished. As it is, if we had to put on a requirements language on these, I'd probably say "an ICMP message MAY be sent". -- 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 Oct 20 02:52:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAB15056 for ; Mon, 20 Oct 2003 02:52:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABTqp-000O1W-0H for v6ops-data@psg.com; Mon, 20 Oct 2003 06:49:11 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABTqm-000O0y-LC for v6ops@ops.ietf.org; Mon, 20 Oct 2003 06:49:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9K6mwx07249; Mon, 20 Oct 2003 09:48:58 +0300 Date: Mon, 20 Oct 2003 09:48:57 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 In-Reply-To: <20031018115854.GI12272@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 18 Oct 2003, Tim Chown wrote: > Here are some (long) comments on draft 00. I am sorry they are later than > ideal but I hope they are still useful prior to Minneapolis. > > The document is absolutely on the right track, in my view. The detail of > comments is mainly for clarification :) [...] Thanks Tim. These kind of comments are exactly what we need to move the scenarios documents forward. Hopefully other folks also have a chance to read and comment on the document. Pekka writing as WG co-chair From owner-v6ops@ops.ietf.org Tue Oct 21 02:15:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06993 for ; Tue, 21 Oct 2003 02:15:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABpUr-000EZb-OX for v6ops-data@psg.com; Tue, 21 Oct 2003 05:55:57 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABpUc-000EYp-5H for v6ops@ops.ietf.org; Tue, 21 Oct 2003 05:55:42 +0000 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 96875327A4B; Tue, 21 Oct 2003 01:55:40 -0400 (EDT) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Tue, 21 Oct 2003 01:55:40 -0400 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id 836BC76E27; Tue, 21 Oct 2003 01:55:40 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Tue, 21 Oct 2003 11:25:40 +0530 X-Epoch: 1066715740 X-Sasl-enc: 6IJg2Gg4EOva/w+bx+O2jQ Cc: "Pekka Savola" , "Tim Chown" , jim.bound@hp.com Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 References: ARRAY(0x9f2e578) In-Reply-To: ARRAY(0x9f2405c) Message-Id: <20031021055540.836BC76E27@smtp.us2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Some quick comments: 1. The definition of scenario needs to be clarified. I was under the assumption that a scenario would correspond to a stage in the deployment of IPv6 in the enterprise network. For example, the cases described in section 5 in http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman- scenarios-03.txt. 2. The scenario description in section 3.1, and the examples in section 3.3 do not seem to be in tune. The purpose of section 3.3 is to provide clarity on the base scenarios but, IMHO, it does not do that. For example, how does the example network A shed more light on Scenario 1, or 2, or 3? CP On Mon, 20 Oct 2003 09:48:57 +0300 (EEST), "Pekka Savola" said: > On Sat, 18 Oct 2003, Tim Chown wrote: > > Here are some (long) comments on draft 00. I am sorry they are later > > than ideal but I hope they are still useful prior to Minneapolis. > > > > The document is absolutely on the right track, in my view. The > > detail of comments is mainly for clarification :) > [...] > > Thanks Tim. These kind of comments are exactly what we need to move > the scenarios documents forward. Hopefully other folks also have a > chance to read and comment on the document. > > Pekka writing as WG co-chair > > From owner-v6ops@ops.ietf.org Tue Oct 21 05:40: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 FAA11432 for ; Tue, 21 Oct 2003 05:40:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABspn-000NwF-JU for v6ops-data@psg.com; Tue, 21 Oct 2003 09:29:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABspb-000NvZ-Ig for v6ops@ops.ietf.org; Tue, 21 Oct 2003 09:29:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9L9TVc26392; Tue, 21 Oct 2003 12:29:31 +0300 Date: Tue, 21 Oct 2003 12:29:30 +0300 (EEST) From: Pekka Savola To: juha.wiljakka@nokia.com cc: v6ops@ops.ietf.org Subject: Re: More comments needed! [WG Last Call: 3GPP Analysis Document] In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F020CDF81@esebe005.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Folks, please read the document and send comments. We really can't go forward with this yet! I had hoped to send the document to the IESG before Minneapolis IETF, but with the low level of input from the WG this doesn't seem to reasonable at this phase. On Fri, 17 Oct 2003 juha.wiljakka@nokia.com wrote: [...] > The comments included: > - Alain Durand's (high level) comments -> some edits will be done based > on those comments [...] One item which may need to be discussed also is whether folks feel the ipv4-only SIP is a worthy goal for 3GPP, i.e., whether the IMS translation is necessary. > - quite many operator comments from Andreas Schmid; lengthy discussion > in which Pekka S. and others were also involved. I think these comments call for, at least, some description of the 3GPP UE being used as a "modem" (without a need to implement v6 on it), and maybe some text/consideration how configured tunneling could be made easier (my belief is that it should be doable..) > It is inevitable that a new revision is needed (deadline before > Minneapolis is Oct 27th, so basically one week time for that). But > before that, I would like to know what the chairs are thinking about the > situation. A new revision would not hurt. However, there would really need to be more discussion/pull from the WG before we can ship the document to the IESG as there are a number of contious issues. I'd recomment revising the document before the cut-off, and giving a presentation at Minneapolis (will you be there, or will someone else do it?) on the major issues which need discussion -- we might be able get some input how to proceed there and be able to revise the document after Minneapolis and ship it them. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Oct 21 05:40: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 FAA11467 for ; Tue, 21 Oct 2003 05:40:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABsy0-000OK7-Ey for v6ops-data@psg.com; Tue, 21 Oct 2003 09:38:16 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABsxx-000OJi-Ey for v6ops@ops.ietf.org; Tue, 21 Oct 2003 09:38:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9L9bVC26462; Tue, 21 Oct 2003 12:37:32 +0300 Date: Tue, 21 Oct 2003 12:37:31 +0300 (EEST) From: Pekka Savola To: Dave Thaler cc: ipv6@ietf.org, , Subject: Re: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 15 Oct 2003, Dave Thaler wrote: > Forwarding this announcement to the most relevant WG's... > > RFC 2667, entitled "IP Tunnel MIB", only supported > point-to-point tunnels over IPv4. This draft updates > RFC 2667 to also support tunnels over IPv6, as well as > tunnels which aren't just point-to-point (e.g. 6to4). > It also clarifies the use of the ifRcvAddressTable > for all tunnels. > > It uses the InetAddress types like the other MIBs > that have been done by the IPv6MIB Design Team. Thanks Dave. Two very high-level comments. An obvious oversight (or intentional one :-) is that I see an IANA registry being created, but no guidance on how new values should be added to it (IETF Consensus, Standards Action, FCFS, etc.) Also, it was not clear which WG you intend to run this through officially. I'm assuming ifmib. (Just trying to figure out what will be the role of v6ops WG in this process..) Pekka > Title : IP Tunnel MIB > Author(s) : D. Thaler > Filename : draft-thaler-inet-tunnel-mib-00.txt > Pages : 26 > Date : 2003-10-14 > > This memo defines a Management Information Base (MIB) for use with > network management protocols in the Internet community. In > particular, it describes managed objects used for managing tunnels > of any type over IPv4 and IPv6 networks. Extension MIBs may be > designed for managing protocol-specific objects. Likewise, > extension MIBs may be designed for managing security-specific > objects. This MIB does not support tunnels over non-IP networks. > Management of such tunnels may be supported by other MIBs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-thaler-inet-tunnel-mib-00.txt [...] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Oct 21 06:03:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11876 for ; Tue, 21 Oct 2003 06:03:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABtIY-000POD-4p for v6ops-data@psg.com; Tue, 21 Oct 2003 09:59:30 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABtIR-000PNx-II for v6ops@ops.ietf.org; Tue, 21 Oct 2003 09:59:23 +0000 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9L9xMX05833 for ; Tue, 21 Oct 2003 12:59:22 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Oct 2003 12:59:19 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 21 Oct 2003 12:59:18 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 21 Oct 2003 12:59:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: More comments needed! [WG Last Call: 3GPP Analysis Document] Date: Tue, 21 Oct 2003 12:59:04 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F020CDF8E@esebe005.ntc.nokia.com> Thread-Topic: More comments needed! [WG Last Call: 3GPP Analysis Document] Thread-Index: AcOXtdd8MgVGGUs8StyC094ZBKF0iAAAUbOg From: To: Cc: X-OriginalArrivalTime: 21 Oct 2003 09:59:18.0912 (UTC) FILETIME=[FE628800:01C397B9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, some comments below (JW): -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 21 October, 2003 12:30 > - quite many operator comments from Andreas Schmid; lengthy discussion > in which Pekka S. and others were also involved. I think these comments call for, at least, some description of the 3GPP = UE=20 being used as a "modem" (without a need to implement v6 on it), and = maybe=20 some text/consideration how configured tunneling could be made easier = (my=20 belief is that it should be doable..) JW: That case was described in a previous revision of our document = (tunneling done in the laptop and IPv4-based GPRS network used for transport). And = I have no problems putting it there again. The user can in practise use those = IPv6-in-IPv4 tunneling mechanisms that can be found in the laptop computer, but there = really aren't (many) 3GPP specific details in that scenario. > It is inevitable that a new revision is needed (deadline before > Minneapolis is Oct 27th, so basically one week time for that). But > before that, I would like to know what the chairs are thinking about = the > situation. A new revision would not hurt. However, there would really need to be=20 more discussion/pull from the WG before we can ship the document to the=20 IESG as there are a number of contious issues. I'd recomment revising the document before the cut-off, and giving a=20 presentation at Minneapolis (will you be there, or will someone else do=20 it?) on the major issues which need discussion -- we might be able get=20 some input how to proceed there and be able to revise the document after = Minneapolis and ship it them. JW: Sure, I will try to compose next revision by Monday. And keeping a = short presentation (on the remaining issues) in MPLS is ok for me. Cheers, -Juha- From owner-v6ops@ops.ietf.org Tue Oct 21 09:08:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16271 for ; Tue, 21 Oct 2003 09:08:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABw5b-0005wx-Cs for v6ops-data@psg.com; Tue, 21 Oct 2003 12:58:19 +0000 Received: from [193.147.71.64] (helo=gsyc.escet.urjc.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABw4z-0005vR-Sq for v6ops@ops.ietf.org; Tue, 21 Oct 2003 12:57:42 +0000 Received: from gsyc.escet.urjc.es (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 OAA04504; Tue, 21 Oct 2003 14:57:39 +0200 X-Authentication-Warning: gsyc.escet.urjc.es: Host gsyc104.dat.escet.urjc.es [193.147.71.104] claimed to be gsyc.escet.urjc.es Message-ID: <3F952D48.1010907@gsyc.escet.urjc.es> Date: Tue, 21 Oct 2003 14:57:44 +0200 From: "Eva M. Castro" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown , v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 References: <20031018115854.GI12272@login.ecs.soton.ac.uk> In-Reply-To: <20031018115854.GI12272@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, First, thanks for this draft, I think it is very useful to analyze and understand transition aspects. Im also agree with the idea that defining a default transition scenario, will not work. However, this draft helps to think about key aspects when moving to IPv6. Some comments around this draft: --> In table of contents: " 3. Base Scenarios..............................................6 3.1 Base Scenarios Defined.....................................6 3.2 Scenarios Characteristics..................................6 3.3 Base Scenario Examples.....................................8 " I understand point 3.1 and 3.3 are very different, point 3.1 explains transition scenarios, or IPv6 scenarios, and point 3.3 explains existing enterprise scenarios. Maybe, it is more clear if the name of these subsections is changed: 3.1 IPv6 transition base scenarios. 3.2 Scenarios Characteristics. 3.3 Enterprise specific scenario examples. Tim Chown wrote: >>3.1 Base Scenarios Defined >> >> Scenario 1: Enterprise with an existing IPv4 network wants to deploy >> IPv6 in parallel with their IPv4 network. >> >>**Note To V6ops WG: Would a network topology map be useful here? >> >> > >I don't think such a map is necessary for any of the base scenarios. > >However, by "in parallel" do you mean dual-stack infrastructure or separate >infrastructure, or is that irrelevant? > > --> If it was not dual-stack infrastructure, I think it would be scenario 3. If this scenario is related to dual-stack, maybe it could be named dual-network. >> Assumptions: The IPv4 characteristics have an equivalent in >> IPv6. >> > >Where might they not do? > > --> Maybe scenario 2, only some specific IPv6 applications should work, so not all IPv4 services are required in the IPv6 network. >> Scenario 3: Enterprise deploying a new network or re-structuring an >> existing network, decides IPv6 is the basis for network >> communication. >> >> > >Does this mean IPv6-only network infrastructure? Remember you have defined >IPv6 above as equal to IPv6-only, so is that what you mean here? > > --> I suppose this scenario is an IPv4 and IPv6 heterogeneous network which will converge to an IPv6 network, where an IPv4 and IPv6 heterogeneous network is a set of network zones, IPv4-only, IPv6-only and dual stack. >> Assumptions: Required IPv6 network components are available, or >> available over some defined timeline. >> >> > >Again, do you really mean IPv6-only, or IPv6-capable? > > --> I understand every kind of node, without loosing IPv4/IPv6 interoperability. Not sure if it is required to emphasize the different kind of nodes in this scope. >> Requirements: Interoperation and Coexistence with IPv4 network >> operations and applications are required for >> communications. >> >> > >So is scenario 3 an IPv6-only network into which IPv6-only or dual-stack >hosts may be deployed? If so maybe state that 3 paragraphs up. > > --> I thought scenario 3 was an IPv4 and IPv6 heterogeneous network, since dual-stack network was scenario 1. >> Characteristic 1 - Providers for External Network Operation >> - IPv4 existing address ownership (Provider based addresses vs. >> Provider independent addresses)? >> >> > >And number of globally routable IPv4 addresses available? > --> Very important for some transition mechanisms which require a pool of routable IPv4 addresses. >> The Enterprise network will have to support the coexistence of IPv6 >> and IPv4, to support legacy IPv4 applications and nodes. The >> Enterprise user has the following choices for that coexistence to >> consider today. >> >> > >Does this mean "of IPv6-only and IPv4-only"? This is what is implied by >the definition of terms at the start of the document. Do we actually mean >"IPv6-capable and IPv4-capable" or, in the language of the definitions, >"IPv6, IPv4 and IPv4/IPv6" applications and nodes? > --> In my opinion, coexistence means interoperability between every kind of node and application that enterprise requires. Again, not sure if the different kind of nodes and applications should be distinguished in this scope. --> Section 4 is named "Support for Legacy IPv4 Nodes and Applications" however applications are not mentioned in this section. So, maybe it should be named "Support for Legacy IPv4 Nodes". --> maybe 4.1 and 4.2 cases could be more general if they are considered as: 4.1. Communicating IPv4 networks through IPv6 zone 4.2. Communicating IPv6 networks through IPv4 zone. These two cases include that end-point nodes are dual stack or single stack and tunnels can be started from end-point nodes (dual stack) or from intermediate router (end point nodes are single stack). Besides, I think it is more coherent with the name of the subsection 4.3, "IPv6 communication with IPv4" which is about connecting networks, not nodes. Regards, eva -- Eva M. Castro From owner-v6ops@ops.ietf.org Tue Oct 21 09:09:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16306 for ; Tue, 21 Oct 2003 09:09:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABwC0-0006EC-Se for v6ops-data@psg.com; Tue, 21 Oct 2003 13:04:56 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABwBs-0006Dq-MN for v6ops@ops.ietf.org; Tue, 21 Oct 2003 13:04:48 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA26420 for ; Tue, 21 Oct 2003 14:04:47 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA25651 for ; Tue, 21 Oct 2003 14:04:46 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9LD4kf28582 for v6ops@ops.ietf.org; Tue, 21 Oct 2003 14:04:46 +0100 Date: Tue, 21 Oct 2003 14:04:46 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 Message-ID: <20031021130446.GL27817@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20031018115854.GI12272@login.ecs.soton.ac.uk> <3F952D48.1010907@gsyc.escet.urjc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F952D48.1010907@gsyc.escet.urjc.es> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Oct 21, 2003 at 02:57:44PM +0200, Eva M. Castro wrote: > I understand point 3.1 and 3.3 are very different, point 3.1 explains > transition scenarios, or IPv6 scenarios, and point 3.3 explains > existing enterprise scenarios. Maybe, it is more clear if the name > of these subsections is changed: > > 3.1 IPv6 transition base scenarios. > 3.2 Scenarios Characteristics. > 3.3 Enterprise specific scenario examples. I guess my comments were too long for you - I suggested the same :) There was some confusion between motivations, scenarios, base scenarios which I suggested some changes for. Jim will be back in a week or so and I'm sure will start collating comments. So some reinforcement in suggestions is good. > >Again, do you really mean IPv6-only, or IPv6-capable? > > > --> I understand every kind of node, without loosing IPv4/IPv6 > interoperability. Not sure if it is required to emphasize the different > kind of nodes in this scope. So this is a terminology issue. In the definitions section, IPv6 is defined as IPv6-only. Then in the text "IPv6" is used freely and may mean either IPv6 in general or IPv6-only. Maybe we should explicitly write IPv6-only when we really mean it, to avoid any possible confusion. > --> In my opinion, coexistence means interoperability between every kind > of node and application that enterprise requires. Again, not sure if the > different kind of nodes and applications should be distinguished in this > scope. Agree - the interworking is between nodes and applications; not all apps will be capable of both protocols, some will be IPv6-only, like new p2p apps for v6 - these may never talk to v4 except by proxies. Tim From owner-v6ops@ops.ietf.org Tue Oct 21 09:26: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 JAA16718 for ; Tue, 21 Oct 2003 09:26:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ABwTU-000773-7v for v6ops-data@psg.com; Tue, 21 Oct 2003 13:23:00 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ABwTN-00076i-B3 for v6ops@ops.ietf.org; Tue, 21 Oct 2003 13:22:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9LDLWR29179; Tue, 21 Oct 2003 16:21:32 +0300 Date: Tue, 21 Oct 2003 16:21:31 +0300 (EEST) From: Pekka Savola To: discuss@apps.ietf.org cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-shin-v6ops-application-transition-02.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, The application "transition" document has seen significant revision: http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-02.txt All comments would be appreciated. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Mon, 20 Oct 2003 15:40:02 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-shin-v6ops-application-transition-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application Aspects of IPv6 Transition Author(s) : M. Shin, et. al. Filename : draft-shin-v6ops-application-transition-02.txt Pages : 26 Date : 2003-10-20 The document specifies application aspects of IPv6 transition. As IPv6 is deployed, the application developers and the administrators will face several problems. This draft clarifies the problems and considerations occurring in transition period between IPv4 applications and IPv6 applications. It also proposes guidelines that help application developers understand how to develop IP version-independent applications during the transition period. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-02.txt From owner-v6ops@ops.ietf.org Tue Oct 21 14:21: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 OAA29058 for ; Tue, 21 Oct 2003 14:21:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC0xP-000L6v-Ay for v6ops-data@psg.com; Tue, 21 Oct 2003 18:10:11 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC0xG-000L5O-6w for v6ops@ops.ietf.org; Tue, 21 Oct 2003 18:10:02 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 74A24FE34 for ; Tue, 21 Oct 2003 14:10:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 21 Oct 2003 14:10:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments: draft-savola-v6ops-transarch-01.txt Date: Tue, 21 Oct 2003 14:10:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122050@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments: draft-savola-v6ops-transarch-01.txt Thread-Index: AcOX/jucABtFjxrRSUKK+/Btnfb/BQAAEJ1A From: "Bound, Jim" To: X-OriginalArrivalTime: 21 Oct 2003 18:10:02.0734 (UTC) FILETIME=[8C4538E0:01C397FE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This draft can become useful, but needs more WG discussion and I suggest we have that here and give Pekka input. Document needs spell checker for some wordsm, and sentence structure check. Also to mahy cliches used that convey no technical message to me as a reader. I think the document important but needs much more work here in the WG. Specific Comments: Robustness is also essential: the mechanism and the architecture must be reliable and robust, to encourage the adoption. Also, mechanisms must not be less robust than their IPv4 counterparts: quite the contrary. It is highly desirable to aim for building the architecture which does not depend on known-unreliable components (for example, certain operational modes of IPv4 NAT's); otherwise, the whole architecture is easily deemed unreliable. Confused on what is trying to be said regarding IPv4 counter parts? How can an IPv6/IPv4 transition mechanism have a counter part. I get the point but this needs word-smithing to tighten up the point for robustness. Also I don't think any mechanisms proposed in our history rely on IPv4 parts that do not work well? In absence of a plan, the transition must be made so that the future transition options will not be end-ran, and only "safe" transitionary actions are executed. For example, deploying dual-stack nodes with currently only IPv4 connectivity does not end-run any transitionary goals, but is an important step that must be done anyway. Not sure what end-ran or end-run defines?=20 What exactly does "safe transitonary actions" mean? I am having a hard time parsing the point of this paragraph?=20 Mechanisms: o Providing IPv6 connectivity o Protocol translation o Application-specific protocol interoperability (ie. ALG or proxy) Deployment models for IP nodes: o IPv4-only o Dual-stack with only IPv4 connectivity o Dual-stack w/ IPv4/6 connectivity o Dual-stack with only IPv6 connectivity o IPv6-only And services: o IPv4-only o Separate IPv4 and IPv6 o IPv4/6 o IPv6-only Each of the above should be their own section with descriptions in depth technically what they mean and imply to a transition architecture. Bullets are simply not enough in this case for a document labeled with the word "architecture" in it. I am willing to help with this offline as I can find the spare cycles. 2.3. Transition Mechanism Deployment Considerations There are a few very important questions which must be addressed in the cases where a transition mechanism deployment is deemed necessary. For example: o if I deploy IPv6-only service, whose burden is it to enable its use by all clients I wish to make it accessible to? o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6 connectivity, whose burden is it to enable them to access all the services they want? o how much easier would it be to go for dual-stack approach instead? The intuitive answer to both of these would appear to be: "if you really want to shoot yourself in the foot, do not blame the person who sold you the gun -- or at least get prepared for a big hospital bill." Could we get technical or architecture statements to replace the above please :--) The desire to go straight to IPv6-only seems to be mainly caused by a dream of fast transition especially in some more evolved networks. However, this seems counter-productive. Important. My impression is the hot button for this draft is that nodes and networks will best be served by dual IPv4 and IPv6 layers being supported, not that the draft is against IPv6 applications being deployed or IPv6 gradually becoming dominant for network operations over time. I think this point is very important to be clear on in this work. /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Tue Oct 21 14:33: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 OAA29529 for ; Tue, 21 Oct 2003 14:33:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC1GE-000MIJ-GL for v6ops-data@psg.com; Tue, 21 Oct 2003 18:29:38 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC1G9-000MHy-9d for v6ops@ops.ietf.org; Tue, 21 Oct 2003 18:29:33 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9DEB213B3B; Tue, 21 Oct 2003 14:29:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 21 Oct 2003 14:29:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Comments: draft-shin-v6ops-application-transition-02.txt Date: Tue, 21 Oct 2003 14:28:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA15A@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments: draft-shin-v6ops-application-transition-02.txt Thread-Index: AcOYAR5SoRGo6phhRsS1dXF/u8orjg== From: "Bound, Jim" To: Cc: "Eva M. Castro" X-OriginalArrivalTime: 21 Oct 2003 18:29:30.0071 (UTC) FILETIME=[440EB670:01C39801] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I believe this draft is an excellent and important piece of work for v6ops and should be working group item. I also suggest it be for Informational RFC not Standards Track.=20 I would also suggest we need review of this work by Eva Castro as Subject Matter Expert in this area in the IPv6 implementation community, and the authors should view API work Eva and others did on Programming Transition IPv6 White Paper as one authority technical document in the market for IPv6 current deployment URL below. Might want to compare the code examples to this paper too. Possibly reference this document too as pointer for the reader. http://www.nav6tf.org/slides/trans_ipv6_v013.pdf I have no major edits and the document is written well. Technically all I found thus far on first read appears to be technically accurate. Not sure the section called Transport API is correct labeling of that API infrastructure as note to authors. User space typically does not call actual transport (tcp/udp) APIs? =20 One edit was change reference of 2133 to 3493 in the document. Good Job, /jim From owner-v6ops@ops.ietf.org Tue Oct 21 15:02: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 PAA00818 for ; Tue, 21 Oct 2003 15:02:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AC1iO-000Nzd-7Z for v6ops-data@psg.com; Tue, 21 Oct 2003 18:58:44 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AC1iH-000NzG-8G for v6ops@ops.ietf.org; Tue, 21 Oct 2003 18:58:37 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9LIwVU01370; Tue, 21 Oct 2003 21:58:31 +0300 Date: Tue, 21 Oct 2003 21:58:30 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org, "Eva M. Castro" Subject: Re: Comments: draft-shin-v6ops-application-transition-02.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA15A@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Tue, 21 Oct 2003, Bound, Jim wrote: > I believe this draft is an excellent and important piece of work for > v6ops and should be working group item. I also suggest it be for > Informational RFC not Standards Track. [..] Thanks for review, Jim. We (as in, the authors) certainly take these edits into consideration.. all seem very useful. To clarify to the WG where we stand with this document.. In Minneapolis, there will be presentation + discussion of this. We'll try to gauge whether folks feel this should be a WG document. Currently, there seems to me a rather clear sense that this work is going on the right track. The target category is indeed Informational RFC. The only other option for the category would be BCP, but I'm not convinced it would be useful to fully formalize the coding practices and advice given in the document.. and whether that would be our job. -- 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 Oct 22 03:00: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 DAA26916 for ; Wed, 22 Oct 2003 03:00:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACCkh-000IXz-MF for v6ops-data@psg.com; Wed, 22 Oct 2003 06:45:51 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACCkZ-000IXT-Hm for v6ops@ops.ietf.org; Wed, 22 Oct 2003 06:45:43 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9M6jQO10188; Wed, 22 Oct 2003 09:45:32 +0300 Date: Wed, 22 Oct 2003 09:45:26 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: Re: Comments: draft-savola-v6ops-transarch-01.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05122050@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for comments, Jim. Basically I agree with about all of them. More inline.. On Tue, 21 Oct 2003, Bound, Jim wrote: > Specific Comments: > > Robustness is also essential: the mechanism and the architecture must > be reliable and robust, to encourage the adoption. Also, mechanisms > must not be less robust than their IPv4 counterparts: quite the > contrary. It is highly desirable to aim for building the > architecture which does not depend on known-unreliable components > (for example, certain operational modes of IPv4 NAT's); otherwise, > the whole architecture is easily deemed unreliable. > > Confused on what is trying to be said regarding IPv4 counter parts? How > can an IPv6/IPv4 transition mechanism have a counter part. I get the > point but this needs word-smithing to tighten up the point for > robustness. Also I don't think any mechanisms proposed in our history > rely on IPv4 parts that do not work well? Agree that this should probably be reworded to flesh out the point better. The point was basically that mechanisms which rely on certain behaviour of NATs are likely rather unreliable. There may be other pieces in the IPv4 infrastructure which might crash down if we started building something on top of them.. > In absence of a plan, the transition must be made so that the future > transition options will not be end-ran, and only "safe" transitionary > actions are executed. For example, deploying dual-stack nodes with > currently only IPv4 connectivity does not end-run any transitionary > goals, but is an important step that must be done anyway. > > Not sure what end-ran or end-run defines? > > What exactly does "safe transitonary actions" mean? > > I am having a hard time parsing the point of this paragraph? Agreed. The point is that when we don't know for sure how the transition would progress, it seems to make most sense only to actively engage in activities that progress the transition in any case (e.g., deployment of dual-stack). In that way, even if there will be problems in other fronts, we don't lose anything. > Mechanisms: > Deployment models for IP nodes: > And services: > > Each of the above should be their own section with descriptions in depth > technically what they mean and imply to a transition architecture. > Bullets are simply not enough in this case for a document labeled with > the word "architecture" in it. I am willing to help with this offline > as I can find the spare cycles. The mechanisms is already covered at some length, but some of these could indeed be fleshed out a bit. I didn't do it because it didn't seem as if there was a lot to be said of each.. but I'm certain some words can be found, at least. Any text/ideas would be helpful. > The intuitive answer to both of these would appear to be: "if you > really want to shoot yourself in the foot, do not blame the person > who sold you the gun -- or at least get prepared for a big hospital > bill." > > Could we get technical or architecture statements to replace the above > please :--) Maybe, if I can think of one ;-) > The desire to go straight to IPv6-only seems to be mainly caused by a > dream of fast transition especially in some more evolved networks. > However, this seems counter-productive. > > Important. My impression is the hot button for this draft is that nodes > and networks will best be served by dual IPv4 and IPv6 layers being > supported, Yep. > not that the draft is against IPv6 applications being > deployed or IPv6 gradually becoming dominant for network operations over > time. I think this point is very important to be clear on in this work. Of course not. It probably would use some wordsmithing as well, yes. -- 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 Oct 22 03:26: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 DAA27470 for ; Wed, 22 Oct 2003 03:26:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACDKK-000Ki4-RH for v6ops-data@psg.com; Wed, 22 Oct 2003 07:22:40 +0000 Received: from [193.147.71.64] (helo=gsyc.escet.urjc.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACDJm-000Kfe-Pk for v6ops@ops.ietf.org; Wed, 22 Oct 2003 07:22:06 +0000 Received: from gsyc.escet.urjc.es (62-151-100-22.jazzfree.ya.com [62.151.100.22]) by gsyc.escet.urjc.es (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA23456; Wed, 22 Oct 2003 09:22:03 +0200 X-Authentication-Warning: gsyc.escet.urjc.es: Host 62-151-100-22.jazzfree.ya.com [62.151.100.22] claimed to be gsyc.escet.urjc.es Message-ID: <3F963020.9010907@gsyc.escet.urjc.es> Date: Wed, 22 Oct 2003 09:22:08 +0200 From: "Eva M. Castro" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 References: <20031018115854.GI12272@login.ecs.soton.ac.uk> <3F952D48.1010907@gsyc.escet.urjc.es> <20031021130446.GL27817@login.ecs.soton.ac.uk> In-Reply-To: <20031021130446.GL27817@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: >On Tue, Oct 21, 2003 at 02:57:44PM +0200, Eva M. Castro wrote: > >>I understand point 3.1 and 3.3 are very different, point 3.1 explains >>transition scenarios, or IPv6 scenarios, and point 3.3 explains >>existing enterprise scenarios. Maybe, it is more clear if the name >>of these subsections is changed: >> >>3.1 IPv6 transition base scenarios. >>3.2 Scenarios Characteristics. >>3.3 Enterprise specific scenario examples. >> > >I guess my comments were too long for you - I suggested the same :) > > ups! sorry :) >There was some confusion between motivations, scenarios, base scenarios >which I suggested some changes for. Jim will be back in a week or so >and I'm sure will start collating comments. So some reinforcement in >suggestions is good. > --> Agree with you and Chirayu. Maybe, think of steps to get IPv6 in the enterprise scenario and try to connect aims of enterprise, network characteristics and final scenario: 1) Think of applications will be run in the enterprise network. 2) Select the enterprise scenario based on the applications. 3) Get existing enterprise network characteristics. 4) Ways to obtain the enterprise scenario. Chirayu Patel wrote: >2. The scenario description in section 3.1, and the examples in section > 3.3 do not seem to be in tune. The purpose of section 3.3 is to > provide clarity on the base scenarios but, IMHO, it does not do that. > For example, how does the example network A shed more light on > Scenario 1, or 2, or 3? Regards, eva From owner-v6ops@ops.ietf.org Wed Oct 22 05:10:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29897 for ; Wed, 22 Oct 2003 05:10:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACEuT-0002FF-0K for v6ops-data@psg.com; Wed, 22 Oct 2003 09:04:05 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACEuM-0002Eo-Kv for v6ops@ops.ietf.org; Wed, 22 Oct 2003 09:03:58 +0000 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Oct 2003 02:01:08 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9M93ujP024197 for ; Wed, 22 Oct 2003 02:03:57 -0700 (PDT) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AMT41515; Wed, 22 Oct 2003 02:03:00 -0700 (PDT) Date: Wed, 22 Oct 2003 02:03:56 -0700 (PDT) From: Suresh K Satapati To: v6ops@ops.ietf.org Subject: NAT-PT Applicability Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Comments are welcome !!! -- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT-PT Applicability Author(s) : S. Satapati, et. al. Filename : draft-satapati-v6ops-natpt-applicability-00.txt Pages : 17 Date : 2003-10-20 This document discusses the applicability RFC 2766, Network Address Translation - Protocol Translation (NAT-PT) employing the Stateless IP/ICMP Translation (SIIT) algorithm, as an IPv4-to-IPv6 transition and co-existence mechanism. It highlights the NAT-PT/SIIT operational principles and the network context for which NAT-PT was designed. Known limitations of NAT-PT/SIIT are presented. Applicable scenarios A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-satapati-v6ops-natpt-applicability-00.txt -- Sk From owner-v6ops@ops.ietf.org Wed Oct 22 05: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 FAA00414 for ; Wed, 22 Oct 2003 05:23:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACFAD-0003NG-2J for v6ops-data@psg.com; Wed, 22 Oct 2003 09:20:21 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACFA6-0003Mn-Ar for v6ops@ops.ietf.org; Wed, 22 Oct 2003 09:20:14 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9M9KAe11864 for ; Wed, 22 Oct 2003 12:20:10 +0300 Date: Wed, 22 Oct 2003 12:20:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Subject: NAT-PT Applicability Team to Conclude Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, (WG chair hat=on) In the San Francisco IETF in March 2003, the WG felt that clarifying the applicability of NAT-PT and what it meant was in order. A design team was formed during the Summer to tackle this issue and to write a draft about it; this has now been done: http://www.ietf.org/internet-drafts/draft-satapati-v6ops-natpt-applicability-00.txt Publishing this document concludes the Design Team. Now, it is the WG's turn to give input on how to improve the document, or where to go from here. We thank the DT for their hard work, especially the lead, Suresh, for bearing up with in the face of very different views among the DT: Suresh Satapati Senthil Sivakumar Peter Barany Satomi Okazaki Hao H. Wang Rob Austein Thanks for bringing this together! Pekka, Jonne, Bob v6ops co-chairs -- 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 Oct 22 05:23:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00477 for ; Wed, 22 Oct 2003 05:23:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACFBV-0003UT-8b for v6ops-data@psg.com; Wed, 22 Oct 2003 09:21:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACFBS-0003U8-RH for v6ops@ops.ietf.org; Wed, 22 Oct 2003 09:21:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9M9LZJ11879 for ; Wed, 22 Oct 2003 12:21:35 +0300 Date: Wed, 22 Oct 2003 12:21:35 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: NAT-PT applicability considerations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, (WG chair hat=on) The NAT-PT Applicability Design Team's draft has been published as: http://www.ietf.org/internet-drafts/draft-satapati-v6ops-natpt-applicability-00.txt Now, it's the WG's turn to give input on how to proceed. This topic will also (barring last-minute changes) be discussed in Minneapolis. As an input to the working group process, there were a couple of topics which were not animous among the Design Team -- if you read the draft, it might make sense to pay special attention to (at least) these: 1. The definition of NAT-PT. Some felt that the term "NAT-PT" can also be used when ALGs (e.g. DNS-ALG) are not being used; the others disagreed. The draft is closer to first at this point. It is not clear whether this is appropriate as the NAT-PT mechanism does not seem to even really function without additional code as a replacement for DNS-ALG. 2. The treatment of IPv6-only networks. It was not clear whether it makes sense to include either: a) generic IPv6-only networks (currently in the Appendix), or b) only a more limited set of IPv6-only networks in the applicability statement. These scenarios, may be counterproductive in the face of dual-stack deployment. As an additional point, if the deployment of IPv6-only networks were decreed out of scope, some felt that no NAT-PT applicability statement would need to be published in the first place as it would not be applicable anywhere. Some disagreed, in that the analysis of the shortcomings of NAT-PT would still be useful. 3. The recommendation of the specific scenarios. In the body of the text, some applicability was identified in two kinds of networks: the legacy IPv4 equipment and 3GPP. There was no full consensus that going down that deployment path (the point above) would necessarily make sense. Pekka, Jonne, Bob v6ops co-chairs -- 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 Oct 22 06:54:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03061 for ; Wed, 22 Oct 2003 06:54:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACGWw-000AyN-EZ for v6ops-data@psg.com; Wed, 22 Oct 2003 10:47:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACGWo-000Axl-Jr for v6ops@ops.ietf.org; Wed, 22 Oct 2003 10:47:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9MAlgc12850 for ; Wed, 22 Oct 2003 13:47:42 +0300 Date: Wed, 22 Oct 2003 13:47:42 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Subject: NAT-PT Applicability Team to Conclude In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Sorry, for forgetting one name from the Design Team, Karim El-Malki Apologies. On Wed, 22 Oct 2003, Pekka Savola wrote: [...] > We thank the DT for their hard work, especially the lead, Suresh, for > bearing up with in the face of very different views among the DT: > > Suresh Satapati > Senthil Sivakumar > Peter Barany > Satomi Okazaki > Hao H. Wang > Rob Austein > [...] -- 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 Oct 22 07:32: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 HAA03996 for ; Wed, 22 Oct 2003 07:32:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACH9S-000EJO-T7 for v6ops-data@psg.com; Wed, 22 Oct 2003 11:27:42 +0000 Received: from [128.176.188.111] (helo=batch13.uni-muenster.de) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACH9K-000EHX-As for v6ops@ops.ietf.org; Wed, 22 Oct 2003 11:27:34 +0000 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch13.uni-muenster.de (Postfix) with ESMTP id E0F3A11E4; Wed, 22 Oct 2003 13:26:53 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 31D8E312D7; Wed, 22 Oct 2003 13:26:52 +0200 (CEST) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 69D58312D5; Wed, 22 Oct 2003 13:26:51 +0200 (CEST) Subject: Re: NAT-PT Applicability From: "Christian Strauf (JOIN)" To: Suresh K Satapati Cc: v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1066822051.2164.40.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 22 Oct 2003 13:27:31 +0200 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > Comments are welcome !!! Here are my comments. Para 3.2: If more than one box implementing NAT-PT is present, then the scalability problem may be circumvented by using e.g. DNS-ALGs that can do round-robin or some other form of load-balancing. Load-balancing also has its drawbacks as the majority of hosts cache answers to DNS queries. And additionally, if the NAT-PT box and the DNS-ALG are not one unit, failures of one or the other are diffcult to handle (due to the current lack of some form of communication/surveillance between the two). It is probably worth to mention that it is to some extent possible to do load-balancing. Apart from that, I think that the draft is very nice and surely a good help to get an overview of what problems one can expect when deploying NAT-PT. Load balancing NAT-PT is quite a challenge. When using NAT-PT+DNS-ALG to help IPv6 hosts to connect to the IPv4 world it is more complicated than simply using a balancing DNS-ALG. It will work nicely until a NAT-PT box dies or can't handle the amount of traffic anymore. When this is the case, there have to be some means of notifying the DNS-ALG that this NAT-PT box is unavailable and has to be left out when assigning IPv6 prefixes to converted IPv4 addresses (assuming that each NAT-PT box handles the translation for one of those assigned IPv6 prefixes for converted IPv4 addresses). The question is how this can be done efficiently. Does the DNS-ALG have to check the NAT-PT boxes somehow? Do the NAT-PT boxes have to send out notifications that they can't translate traffic anymore (if there is only a partial failure like too much traffic/too much CPU usage/...)? Just a thought. Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westfälische Wilhelms-Universität Münster http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung Team: join@uni-muenster.de Röntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 Münster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653 From owner-v6ops@ops.ietf.org Wed Oct 22 18:44:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02847 for ; Wed, 22 Oct 2003 18:44:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACRX2-000Cac-ML for v6ops-data@psg.com; Wed, 22 Oct 2003 22:32:44 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACRWz-000CZu-Va for v6ops@ops.ietf.org; Wed, 22 Oct 2003 22:32:42 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02172; Wed, 22 Oct 2003 18:32:30 -0400 (EDT) Message-Id: <200310222232.SAA02172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ksinant-v6ops-isp-analysis-00.txt Date: Wed, 22 Oct 2003 18:32:30 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Transition Mechanisms for Introducing IPv6 into ISP Networks Author(s) : V. Ksinant, et. al. Filename : draft-ksinant-v6ops-isp-analysis-00.txt Pages : 15 Date : 2003-10-22 In a companion document, different scenarios for the introduction of IPv6 in an IPv4 ISP network are described. This document analyses these ISP scenarios and evaluates the suitability of the already defined transition mechanisms in this context. Known challenges are also identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ksinant-v6ops-isp-analysis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ksinant-v6ops-isp-analysis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ksinant-v6ops-isp-analysis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-22182525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ksinant-v6ops-isp-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ksinant-v6ops-isp-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22182525.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Oct 22 18: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 SAA02871 for ; Wed, 22 Oct 2003 18:44:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACRar-000CrP-HT for v6ops-data@psg.com; Wed, 22 Oct 2003 22:36:41 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACRao-000Cqw-Vf for v6ops@ops.ietf.org; Wed, 22 Oct 2003 22:36:39 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02410; Wed, 22 Oct 2003 18:36:26 -0400 (EDT) Message-Id: <200310222236.SAA02410@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chown-v6ops-unmanaged-connectivity-00.txt Date: Wed, 22 Oct 2003 18:36:26 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Considerations for IPv6 Tunneling Solutions in Small End Sites Author(s) : T. Chown, et. al. Filename : draft-chown-v6ops-unmanaged-connectivity-00.txt Pages : 16 Date : 2003-10-22 Tunneling IPv6 packets over the IPv4 Internet played a major role in the early stages of IPv6 deployment. This was useful because in the early days the routers in the internet did not support IPv6. Nowadays, tunneling is used to get across legacy equipment and ISPs that do not support IPv6. Many different tunneling mechanisms have been invented. This document describes the drivers for IPv6 tunneling, the general architectures of existing mechanisms, and a set of desirable properties against which subsequent analysis of the mechanisms may be made. The document is aimed at small end sites that may typically utilise tunneling methods in an early IPv6 deployment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-v6ops-unmanaged-connectivity-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-chown-v6ops-unmanaged-connectivity-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-chown-v6ops-unmanaged-connectivity-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-10-22182706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-chown-v6ops-unmanaged-connectivity-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-chown-v6ops-unmanaged-connectivity-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22182706.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Wed Oct 22 21:47:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12976 for ; Wed, 22 Oct 2003 21:47:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUU8-000P7B-Ec for v6ops-data@psg.com; Thu, 23 Oct 2003 01:41:56 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTw-000P5l-IR for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:44 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AF36EFCB7; Wed, 22 Oct 2003 21:41:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:43 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BAF@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOXl/qkceBtT8ywRiaJBJgbOKNpLQBay/kw From: "Bound, Jim" To: "Chirayu Patel" , Cc: "Pekka Savola" , "Tim Chown" X-OriginalArrivalTime: 23 Oct 2003 01:41:43.0347 (UTC) FILETIME=[CFE85830:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable CP, Thanks for the comments. > Some quick comments: > > 1. The definition of scenario needs to be clarified. I was under the > assumption that a scenario would correspond to a stage in the > deployment of IPv6 in the enterprise network. For example, > the cases described in section 5 in > =20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-sce narios-03.txt. The Enterprise Scenarios are exponentially greater than uman scenarios. Thus the potential stages of deployment within those is even greater. What we could do is add a stages of deployment section to try to provide a reference for users to be aware of to take those into consideration. But Enterprises are quite different and will approach this in many different ways. 2. The scenario description in section 3.1, and the examples in section 3.3 do not seem to be in tune. The purpose of section 3.3 is to provide clarity on the base scenarios but, IMHO, it does not do that. For example, how does the example network A shed more light on Scenario 1, or 2, or 3? Fair question. We need to provide that in an appendix. All three examples 3.1 could apply to all specific examples in 3.3. And we need to cover this in the spec and then show examples in the spec. For example: Example Network A: A distributed network across a number of geographically separated campuses Each scenario in 3.0 could be applied to Network A. Then: - External network operation. - External connectivity required. - Multiple sites connected by leased lines. - Provider independent IPv4 addresses. - ISP does not offer IPv6 service. - Private Leased Lines no Service Provider Used Each apply for this example from each scenario. Applications run by the enterprise: - Internal Web/Mail. - File servers. - Java applications. - Collaborative development tools. - Enterprise Resource Applications. - Multimedia Applications. - Financial Enterprise Applications. - Data Warehousing Applications. These could be required in all 3.0 scenarios. Internal network operation: - In house operation of the network. - DHCP (v4) is used for all desktops, servers use static address configuration. - The DHCP server to update naming records for dynamic desktops uses dynamic DNS. - A web based tool is used to enter name to address mappings for statically addressed servers. - Network management is done using SNMP. - All routers and switches are upgradeable to IPv6. - Existing firewalls can be upgraded to support IPv6 rules. - Load balancers do not support IPv6, upgrade path unclear. - Peer-2-Peer Application and Security supported. This could be the case for each scenario too. The idea is 3.0 scenarios state generic base solutions that cover a wide range of Enterprise approaches to IPv6 deployment. Then 3.3 "specific examples" give types of networks that could use any of the base scenarios. /jim CP On Mon, 20 Oct 2003 09:48:57 +0300 (EEST), "Pekka Savola" said: > On Sat, 18 Oct 2003, Tim Chown wrote: > > Here are some (long) comments on draft 00. I am sorry they are > > later than ideal but I hope they are still useful prior to > > Minneapolis. > > > > The document is absolutely on the right track, in my view. The > > detail of comments is mainly for clarification :) > [...] > > Thanks Tim. These kind of comments are exactly what we need to move > the scenarios documents forward. Hopefully other folks also have a > chance to read and comment on the document. > > Pekka writing as WG co-chair > > From owner-v6ops@ops.ietf.org Wed Oct 22 21:47:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13006 for ; Wed, 22 Oct 2003 21:47:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUUP-000P8o-2w for v6ops-data@psg.com; Thu, 23 Oct 2003 01:42:13 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTw-000P5m-MN for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:44 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0B46E13ABE; Wed, 22 Oct 2003 21:41:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:43 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BB0@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOX1J2KD0NKCDjeTNm/zKEuG9D1DgBMEm+w From: "Bound, Jim" To: "Eva M. Castro" , "Tim Chown" , X-OriginalArrivalTime: 23 Oct 2003 01:41:43.0691 (UTC) FILETIME=[D01CD5B0:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Eva, > First, thanks for this draft, I think it is very useful to=20 > analyze and understand transition aspects. Im also agree with=20 > the idea that defining a default transition scenario, will=20 > not work. However, this draft helps to think about key=20 > aspects when moving to IPv6. Thanks we appreciate the comment and support. >=20 > Some comments around this draft: >=20 > --> In table of contents: >=20 > " > 3. Base Scenarios..............................................6 > 3.1 Base Scenarios Defined.....................................6 > 3.2 Scenarios Characteristics..................................6 > 3.3 Base Scenario Examples.....................................8 > " >=20 > I understand point 3.1 and 3.3 are very different, point 3.1=20 > explains transition scenarios, or IPv6 scenarios, and point=20 > 3.3 explains existing enterprise scenarios. Maybe, it is more=20 > clear if the name of these subsections is changed: > =20 > 3.1 IPv6 transition base scenarios. > 3.2 Scenarios Characteristics. > 3.3 Enterprise specific scenario examples. Yes this is similar to Tim's input. Agreed. >=20 >=20 >=20 > Tim Chown wrote: >=20 > >>3.1 Base Scenarios Defined > >> > >> Scenario 1: Enterprise with an existing IPv4 network=20 > wants to deploy > >> IPv6 in parallel with their IPv4 network. > >> > >>**Note To V6ops WG: Would a network topology map be useful here? > >> =20 > >> > > > >I don't think such a map is necessary for any of the base scenarios. > >=20 > >However, by "in parallel" do you mean dual-stack infrastructure or=20 > >separate > >infrastructure, or is that irrelevant? > > =20 > > >=20 > --> If it was not dual-stack infrastructure, I think it would be > scenario 3. If this scenario is related to dual-stack, maybe=20 > it could be named dual-network. Hmmm. Might be good idea. Good point. We need to think about that. >=20 >=20 > >> Assumptions: The IPv4 characteristics have an equivalent in > >> IPv6. =20 > >> > > > >Where might they not do? > >=20 > > > --> Maybe scenario 2, only some specific IPv6 applications=20 > should work, > so not all IPv4 services are required in the IPv6 network. Yes we need to fix this set of statements. >=20 >=20 > >> Scenario 3: Enterprise deploying a new network or=20 > re-structuring an > >> existing network, decides IPv6 is the basis=20 > for network > >> communication. > >> =20 > >> > > > >Does this mean IPv6-only network infrastructure? Remember=20 > you have defined > >IPv6 above as equal to IPv6-only, so is that what you mean here? > >=20 > > > --> I suppose this scenario is an IPv4 and IPv6 heterogeneous network=20 > --> which > will converge to an IPv6 network, where an IPv4 and IPv6=20 > heterogeneous network is a set of network zones, IPv4-only,=20 > IPv6-only and dual stack. Yep. The tricky part here is what does IPv6 only mean and imply and do we go there in the spec? >=20 > >> Assumptions: Required IPv6 network components are available, or > >> available over some defined timeline. > >> =20 > >> > > > >Again, do you really mean IPv6-only, or IPv6-capable? > > =20 > > > --> I understand every kind of node, without loosing IPv4/IPv6 > interoperability. Not sure if it is required to emphasize the=20 > different kind of nodes in this scope. Thats why if we can leave it as IPv6 capable for the draft it will let us evolve to the real work. >=20 > >> Requirements: Interoperation and Coexistence with IPv4 network > >> operations and applications are required for > >> communications. > >> =20 > >> > > > >So is scenario 3 an IPv6-only network into which IPv6-only or=20 > >dual-stack hosts may be deployed? If so maybe state that 3=20 > paragraphs=20 > >up. > >=20 > > > --> I thought scenario 3 was an IPv4 and IPv6 heterogeneous network,=20 > --> since > dual-stack network was scenario 1. It is but we can make this more clear or I as Editor. >=20 > >> Characteristic 1 - Providers for External Network Operation > >> - IPv4 existing address ownership (Provider based addresses vs. > >> Provider independent addresses)? > >> =20 > >> > > > >And number of globally routable IPv4 addresses available? > > > --> Very important for some transition mechanisms which require a > pool of routable IPv4 addresses. Agreed. This will get added. >=20 > >> The Enterprise network will have to support the=20 > coexistence of IPv6 > >> and IPv4, to support legacy IPv4 applications and nodes. The > >> Enterprise user has the following choices for that coexistence to > >> consider today. > >> =20 > >> > > > >Does this mean "of IPv6-only and IPv4-only"? This is what=20 > is implied=20 > >by the definition of terms at the start of the document. Do we=20 > >actually mean "IPv6-capable and IPv4-capable" or, in the language of=20 > >the definitions, "IPv6, IPv4 and IPv4/IPv6" applications and nodes? > > > --> In my opinion, coexistence means interoperability between=20 > every kind > of node and application that enterprise requires. Again, not=20 > sure if the different kind of nodes and applications should=20 > be distinguished in this scope. I hope that differentiation is not required and agree with you. >=20 >=20 > --> Section 4 is named "Support for Legacy IPv4 Nodes and=20 > Applications" > however applications are not mentioned in this section. So,=20 > maybe it should be named "Support for Legacy IPv4 Nodes". Interesting point. Need to think. >=20 >=20 > --> maybe 4.1 and 4.2 cases could be more general if they are > considered as: >=20 > 4.1. Communicating IPv4 networks through IPv6 zone > 4.2. Communicating IPv6 networks through IPv4 zone. Yep. >=20 > These two cases include that end-point nodes are dual stack=20 > or single stack > and tunnels can be started from end-point nodes (dual stack) or from > intermediate router (end point nodes are single stack).=20 > Besides, I think > it is more coherent with the name of the subsection 4.3, "IPv6=20 > communication > with IPv4" which is about connecting networks, not nodes. Good input and words for us too. Thanks. Thanks /jim >=20 > Regards, >=20 > eva >=20 > --=20 > Eva M. Castro >=20 >=20 >=20 >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Oct 22 21:48: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 VAA13023 for ; Wed, 22 Oct 2003 21:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUU3-000P6z-RC for v6ops-data@psg.com; Thu, 23 Oct 2003 01:41:51 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTu-000P5Z-Nd for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:42 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F38C5110B0; Wed, 22 Oct 2003 21:41:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:41 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BA8@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOVcPdnWKGVipjYRf+bM5WEQ5mnAwDhvyyw From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 23 Oct 2003 01:41:41.0613 (UTC) FILETIME=[CEDFC1D0:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Tim, Thanks for your hard work and thorough read of the specs and good input to the work. > Here are some (long) comments on draft 00. I am sorry they=20 > are later than=20 > ideal but I hope they are still useful prior to Minneapolis. Very useful. >=20 > The document is absolutely on the right track, in my view. =20 > The detail of comments is mainly for clarification :) The team thanks you for that comment. >=20 > The introduction generally reads very well and sets the scene nicely. Thanks. >=20 > > Each enterprise will select the transition that best=20 > supports their > > business requirements. Any attempt to define a default=20 > or one-size- > > fits-all transition scenario, will simply not work. This document > > does not try to depict the drivers for adoption of IPv6 by an > > Enterprise. >=20 > OK, so the next paragraph shouldn't mention drivers =3D motivations: Good catch. >=20 > > While it is difficult to quantify all the potential=20 > motivations for >=20 > s/motivations/scenarios yep. >=20 > > enterprise network teams to move to IPv6, there are some=20 > cases where > > an abstract description is possible. The document presents three > > example motivations as a general use case. This model=20 > can be used to >=20 > s/motivations/base scenarios=20 yep. >=20 > > define additional abstractions, for the Enterprise to define > > scenarios to fit their requirements. >=20 > s/scenarios/specific scenarios excellent. >=20 > > The first scenario assumes the Enterprise decides to=20 > deploy IPv6 in > > parallel with IPv4. The second scenario assumes the Enterprise > > decides to deploy IPv6 because of a specific set of=20 > applications the > > Enterprise wants to use over an IPv6 network. The third scenario > > assumes an Enterprise is building a new network or=20 > re-structuring an > > existing network and decides to deploy IPv6. The document then > > defines a set of characteristics that must be analyzed. =20 > The document > > then provides several scenario examples using the=20 > characteristics=20 > > to >=20 > s/several/three specific Yep. >=20 > > depict the requirements. These are common Enterprise=20 > deployment cases > > to depict the challenges for the Enterprise to=20 > transition a network > > to IPv6. >=20 > I think one "danger" we have here is that by generalising as=20 > we do later down the text, that the requirements become so=20 > generalised that the analysis can > apply any mechanism to any scenario :) I'm not sure whether that is > a real (or important) concern. I think it is an important concern and the hope is we fine tune the generalizations to be specific enough to keep a focused effort for the analysis. =20 >=20 > > The interoperation with legacy functions within the=20 > Enterprise will > > be required for all transition except possibly by a new=20 > network that > > will be IPv6 from inception. The network infrastructure=20 > components >=20 > Well, not maybe for scenario 2 below, because we are adding=20 > IPv6 for a specific application (let's say a specific IPv6=20 > p2p app like Napster6 :) and in that case we don't care to=20 > access legacy networks, as we are purely interested in the v6=20 > app, as the scenario states. This is good point about secenario 2 and good catch. >=20 > > will inform the Enterprise of key points of transition in their > > networks that require consideration for IPv6 deployment and > > transition. >=20 > I think "point of transition" is ambiguous - so see below we=20 > should define what you mean. Agreed in next release we will remove all references of "point of transition" it is here now to get folks to think points of transition and now its time to define them I personally agree with you. > =20 > > Using the scenarios, characteristics, and examples in=20 > the document an > > Enterprise can define a scenario. Understanding the=20 > legacy functions > > and network infrastructure components required, the=20 > Enterprise can > > determine the network operations required to deploy=20 > IPv6. The tools > =20 > The wording is confusing here: "using a scenario to define a=20 > scenario", so we need to write something else... do we mean: >=20 > Using the base scenarios, characteristics, and examples=20 > in the document=20 > an Enterprise can define its specific scenario requirements. Yes much better. >=20 > > Enterprise Network - An Enterprise Network is a=20 > network that has > > multiple links, a router connection to a > > Provider, and is actively managed by a > > network operations entity. >=20 > s/multiple/multiple internal Yes. >=20 > s/a router connection/one or more router connections > s/a Provider/one or more Providers > (since you mention multihoming in characteristics below) Yes. >=20 > Should we define "point of transition" and "characteristic"? =20 > I think it would help. Still a nice short set of definitions :) =20 I think point of trasition for a spec is going give us trouble but I do think defining characteristic is good idea. >=20 > > Three base scenarios are defined to capture the=20 > essential abstraction > > set for the Enterprise. Each scenario has assumptions and > > requirements. This is not an exhaustive set of=20 > scenarios, but a base > > set of general cases. >=20 > We might add another base scenario in Minneapolis but we must=20 > ensure that any such addition really adds value so we keep=20 > the doc as simple as possible. This has 100% consensus by the team. I agree. > =20 > > 3.1 Base Scenarios Defined > >=20 > > Scenario 1: Enterprise with an existing IPv4 network=20 > wants to deploy > > IPv6 in parallel with their IPv4 network. > >=20 > > **Note To V6ops WG: Would a network topology map be useful here? >=20 > I don't think such a map is necessary for any of the base scenarios. Thanks for that input. > =20 > However, by "in parallel" do you mean dual-stack=20 > infrastructure or separate=20 > infrastructure, or is that irrelevant? I think we need to explain what we mean in next release. But some nodes will be dual stack and some nodes will be IPv4. I don't think to many will be IPv6 only. >=20 > > Assumptions: The IPv4 characteristics have an equivalent in > > IPv6. >=20 > Where might they not do? I just wrote this one down as it came from last input. I think we need to discuss what this means as a team and be great if our WG colleagues would jump in on this specific too. I think it is vague and unclear. IPv6 will have functions that do not exist in IPv4 as one example. > =20 > > Requirements: Don't break IPv4 network characteristics > > assumptions with IPv6. IPv6 should be=20 > equivalent or > > "better" than the ones in IPv4, however, it is > > understood that IPv6 is not required to=20 > solve every > > single problem. >=20 > Maybe this could say "that IPv6 functionality may not be=20 > required, or feasible to deploy, on all parts of the=20 > Enterprise's infrastructure" ? Yes I like this much better. Note again I just copied this from input. So we may have to have some discussion but I support your suggestion. >=20 > > Scenario 2: Enterprise with an existing IPv4 network=20 > wants to deploy a > > set of particular IPv6 "applications"=20 > (application is > > voluntarily loosely defined here, e.g. peer=20 > to peer). > > The IPv6 deployment is limited to the=20 > minimum required to > > operate this set of applications. > > > > Assumptions: IPv6 software/hardware components for the=20 > application > > are available. >=20 > Hmmm. If the reason is to deploy an IPv6 application (e.g.=20 > p2p VoIP) the solution will depend on whether the host is=20 > dual-stack (IPv4/IPv6) or=20 > IPv6(-only). Clarify, or does it not matter? Well I cheated and admit it to all :---). Bringing IPv6 only into this complicates the discussion and eventual consensus for this work. I think in this case it does not matter in the node instance and the network instance if the IPv6 packet is delivered. But, what it affects is the transition mechanisms required if the node is IPv6 ONLY to speak with legacy IPv6 nodes. That is the one area where translation is required. =20 But does IPv6 only mean that the node simply does not have an IPv4 stack at all. I don't see that happening for a long time. I suggest we assume dual stack for this work and not IPv6 only. That for IPv6 ONLY a future addendum to this spec be written? What does the WG think about my suggestion above? Thanks. >=20 > > Requirements: Don't break IPv4 network operations. >=20 > That's always a requirement :) For "operations" read "functionality, > operation or security" maybe, and probably more beyond. Yep. But it was felt it needed to be said in the spec. >=20 > > Scenario 3: Enterprise deploying a new network or=20 > re-structuring an > > existing network, decides IPv6 is the basis=20 > for network > > communication. >=20 > Does this mean IPv6-only network infrastructure? Remember=20 > you have defined > IPv6 above as equal to IPv6-only, so is that what you mean here? > =20 > > Assumptions: Required IPv6 network components are available, or > > available over some defined timeline. >=20 > Again, do you really mean IPv6-only, or IPv6-capable? IPv6 Capable. I need to fix that above ok. >=20 > > Requirements: Interoperation and Coexistence with IPv4 network > > operations and applications are required for > > communications. >=20 > So is scenario 3 an IPv6-only network into which IPv6-only or=20 > dual-stack hosts may be deployed? If so maybe state that 3=20 > paragraphs up. IPv6 capable but will fix that above too. I want to start another specific thread on this for the WG to discuss to from your input. Good catch. > =20 > I think the four sets of characteristics below are fine to=20 > cover the basic requirements. Thanks. >=20 > > Characteristic 1 - Providers for External Network Operation > > - IPv4 existing address ownership (Provider based addresses vs. > > Provider independent addresses)? >=20 > And number of globally routable IPv4 addresses available? Yes. >=20 > > - Do ISPs offer IPv6 service? >=20 > By service do you mean native service, or tunnelled, or any=20 > service...? Any. But we should differentiate the two as it relates to what the Enterprise can do. >=20 > > Characteristic 3 - Enterprise IT Department Operations Analysis > > - Is inter-site communications required? >=20 > You have "one site vs multiple sites" in characteristic 1? Will fix I figured providers as plural implied "multiple".=20 >=20 > > - External IPv4 routing protocols used? >=20 > That one belongs in characteristic 1? Yes. >=20 > > - List of "network operation" software that may be=20 > impacted by IPv6? > > - DNS > > - Management (SNMP & ad-hoc tools) > > - Enterprise Network Servers > > - Mail Servers > > - High Availability Software for Nodes > > - Directory Services >=20 > - Other services (NTP, others...?) Lets add to the list but at some point we need to add at the end "etc.. etc..". >=20 > > - Are all these software functions upgradeable to IPv6? > > - If not upgradeable, then what are the workarounds? >=20 > - If not upgradeable, can an equivalent upgradeable=20 > software function=20 > be substituted for the one that is not upgradeable?=20 > (e.g. a different > directory service mechanism) This I think is to be done in the analysis spec?????????? >=20 > > Characteristics 4 - Enterprise Network Management System > > - Management of Transition Tools and Mechanisms? >=20 > This is an important area the WG needs to take on board. Yep. I think Management Scenarios could be its own spec? >=20 > > - What new considerations does IPv6 create for Network > > Management? >=20 > Does this affect the transition tool analysis, e.g. if=20 > RFC3041 means that IP-based authentication is no longer=20 > possible? I guess it may affect a=20 > specific implementation of a security policy? Yep. But what I was thinking here is what new problems does transition introduce onto the network of the enterprise? That list would be useful I think. Esp. in Ent Scenarios to feed Ent Analysis doc. >=20 > > This section presents a set of Base Scenario Examples=20 > and is not an > > exhaustive list of examples. These examples were=20 > selected to provide > > further clarity of Base Scenarios within an Enterprise of a less > > abstract nature. >=20 > I think these are now Specific Scenario Examples not Base=20 > ones? The answering of the characteristics against the base=20 > scenarios higher up in the document leads to these specific examples? Excellent. I knew this in the head but could not hit my fingers while editing. Thanks. > =20 > > A bank running a large ATM network supporting an order=20 > of magnitude > > number of transactions per second, with access to a=20 > central database > > on an external network from the ATM network: >=20 > "An order of magnitude number of transactions" is missing a=20 > word or two :) Well we don't have data to say numbers. Nor should we. We do need to say this better I was as Editor taking liberty to get the point across we need better wording yes. But trying to state hard facts is not good. > =20 > > - External connectivity not required. > > - Multiple sites connected by VPN. > > - Multiple sites connected by Native IP protocol. >=20 > Perhaps add that it may use Net10 addressing? We should not=20 > hide from the > Net10/ANT issues for transitioning networks. We have the=20 > Hinden draft on the way, although this example probably uses=20 > RFC1918 but not NAT :) Yes and was not hiding just missed it as I hate it so bad and needed the reminder :--) > =20 > > 4. Support for Legacy IPv4 Nodes and Applications >=20 > s/Nodes/Nodes, Services ? Yes. > =20 > > The Enterprise network will have to support the=20 > coexistence of IPv6 > > and IPv4, to support legacy IPv4 applications and nodes. The > > Enterprise user has the following choices for that coexistence to > > consider today. >=20 > Does this mean "of IPv6-only and IPv4-only"? This is what is=20 > implied by the definition of terms at the start of the=20 > document. Do we actually mean "IPv6-capable and=20 > IPv4-capable" or, in the language of the definitions,=20 > "IPv6, IPv4 and IPv4/IPv6" applications and nodes? I will fix all this in the doc to relay IPv6 capable. >=20 > > 4.3 IPv6 communicating with IPv4 > >=20 > > An IPv6 only node wants to communicate with an IPv4 only node. >=20 > Note the node can be IPv4/IPv6 but the application may be=20 > IPv4, e.g. if the source code is lost or the language it is=20 > written in has no IPv6 API? >=20 > So do we actually mean "node" or "application"? We probably=20 > mean "services > or applications on a node" as RPC, NIS, SMTP etc are services. Nope I was bringing out the case of an IPv6 stack only node. That should be changed. >=20 > > In cases where the IPv6 host cannot be a dual stack, in order to > > continue support of communications with IPv4 nodes an IPv4/v6 > > translator is required. Introduction of such translator=20 > will prevent > > usage of end-to-end security and application carrying embedded IP > > addressing information. >=20 > You could say the translator may be at the network, transport=20 > or application layer. We can add that but for this "reference" model document I don't think it matters? > =20 > > **Note to V6ops WG: Should we discuss porting of=20 > applications too in > > the legacy section? >=20 > I think this is done in the "application aspects" draft fine=20 > already, i.e. in draft-shin-v6ops-application-transition-01. I agree and we can point to this work too. > =20 > > 5. Network Infrastructure Requirements > >=20 > > The Enterprise will need to determine what network infrastructure > > components require enhancements or to be added for deployment of > > IPv6. This infrastructure will need to be analyzed and=20 > understood as > > a critical resource to manage. > >=20 > > 5.1 DNS > >=20 > > DNS will now have to support both IPv4 and IPv6 DNS=20 > records and the > > Enterprise will need to determine how the DNS is to be=20 > managed and > > accessed, and secured. > >=20 > > **Note to V6ops WG: Should we get into other DNS issues? >=20 > There are three categories of issues I think, i.e. >=20 > - standards: dns resolver discovery, 512-byte response format,=20 > reverse zone managemnt and dynamic dns >=20 > - transport: root servsers, OS supporting native lookup,=20 > and whether the > upstream ISPs filter the root space /48's >=20 > - registry: registering domains with IPv6 DNS servers Agree but is Enterprise Scenarios the only spec that needs to address that what about Umanaged, 3GPP, or ISP docs? =20 >=20 > Also, do you have control over your own DNS? This is important to state yes. >=20 > And is it important that reverse DNS lookup works, e.g. for=20 > sendmail to verify sender hosts? If so reverse population of=20 > statelessly autoconfiguring will be needed, and 6to4 use will=20 > be problematic? This is true for all scenario documents, is Enterprise work the only spec that has to do this or do we need a generic DNS transition document as Management etc... > =20 > > 5.2 Routing > >=20 > > IPv6/IPv4 routers should be monitored to ensure the router has > > sufficient storage for both IPv6 and IPv4 route tables. Existing > > network design principles to limit the number of routes in the > > network, such as prefix aggregation, become more=20 > critical with the > > addition of IPv6 to an existing IPv4 network. > >=20 > > **Note to V6ops WG: Above is example of additional text=20 > we could add > > to each component we list here. Are there other Routing issues? >=20 > Other issues are whether the upstream provider supports IPv6=20 > natively or offers transition aids, e.g. 6to4, site tunnel broker. Yes. > =20 > > 5.3 Autoconfiguration > >=20 > > IPv6 introduces the concept of stateless autoconfiguration in > > addition to statefull autoconfiguration. The enterprise=20 > will have to > > determine the best method of autoconfiguration, for=20 > their network. > >=20 > > **Note to V6ops WG: Should we get into other autoconfiguration > > issues? >=20 > Will the enterprise need IPv6 prefix delegation? I think so :--). But we should add that to the list too. >=20 > Will it need DHCPv6 forwarding? Do you mean relaying? > =20 > > 5.4 Security > >=20 > > Current existing mechanisms used for IPv4 to provide=20 > security need to > > be supported for IPv6 within the Enterprise. IPv6=20 > should create no > > new security concerns for IPv4. > >=20 > > **Note to V6ops WG: Should we get into other security issues? >=20 > I think Pekka's security draft could be cited:=20 > draft-savola-v6ops-security-overview-00 I want to not respond and need to do more in depth read of that spec. I think being paranoid is not good :--) (no refelection on Pekka's security draft I just think we live in a very dangerous world and thats life. Trying to correct that to far is not worth the time and one is better off to die :--)). Just kidding. I will reread Pekka's work. >=20 > Issues include backdoors for tunnels, handling firewall=20 > policy for end-to-end encryption, dual-stack possibly adding=20 > complexity to analysis, and DoS relay type attacks (e.g. 6to4 relays). Yes for sure. >=20 > > 5.5 Applications > >=20 > > Existing applications will need to be ported to support=20 > both IPv4 and > > IPv6. > >=20 > > **Note to V6ops WG: Should we get into other application issues? >=20 > Not beyond the shin-v6ops draft. Agreed. > =20 > > 5.6 Network Management > >=20 > > The addition of IPv6 and points of transition will need=20 > to be managed > > by the Enterprise network operations center. This will=20 > affect many > > components of the network and software required on nodes. > >=20 > > **Note to V6ops WG: Should we get into other Management issues? >=20 > Probably not. I agree. But we proabably need a network management draft of its own. > =20 > > 5.7 Address Planning > >=20 > > The address space within the Enterprise will need to be=20 > defined and > > coordinated with the routing topology of the Enterprise network. > >=20 > > **Note to V6ops WG: Should we get into other Address Planning=20 > > issues? >=20 > Would IPv4 and IPv6 subnets be congruent? I think parallel is more correct? >=20 > An advantage of IPv6 is that you are unlikely to ever need to=20 > resize the subnets (up or down). ERRRRRRRRRRRRRRRRR. Need to think about that. One could blow the bits to the left on a site boundary with sensors :--). >=20 > Available IPv4 address space affects (for example) the DSTM=20 > pool, NAT-PT, etc. Yes but that has to be in analysis but we should generically point to all this list. >=20 > Do we have address space independence from provider? I don't believe this is true at all? We do not even more so with IPv6 and I don't like that quite frankly ................... > =20 > > **Note to V6ops WG: What other components are we missing? >=20 > Here are some additional possible components: >=20 > 5.8 Multicast >=20 > Both from routing aspects, but also things like MLDv1/2=20 > snooping to help avoid traffic flooding. >=20 > If multicast is needed then some tools may not be useful,=20 > e.g. 6to4 (there was a draft on 6to4 and multicast, but it=20 > seemed to have died). We should add this yes. >=20 > 5.9 Service discovery mechanisms >=20 > The infrastructure may need to support many of these because=20 > there is little harmonisation of techniques in various standards, e.g. > - LDAP or NIS > - Well-known names > - Well-known addresses > - IPv4 or IPv6 anycast > - LLMNR > - DHCPv6 (Lite) > - SLP, etc Yes. >=20 >=20 > > 7. References >=20 > Maybe the applications draft (see above) and Pekka's transition=20 > architectures doc? (draft-savola-v6ops-transarch-01) And=20 > his security > doc: draft-savola-v6ops-security-overview-00 ? Yes. But want to reread Pekka's security overview ok. >=20 > There's also RFC1752 which we could either cite or state that we no=20 > longer use as a yardstick. It talked about transition goals like: > - incremental upgrade (hosts not routers) > - incremental deployment (routers) > - easy addressing (use dual-stack) > - low start-up costs (procure wisely so infra enabled) Good point. Yes. >=20 >=20 > Other general comments: > ----------------------- >=20 > What about preference of use of IPv4 or IPv6? Ouch. I fear a 1000 mail message debate. I suggest we avoid this and leave scenarios for the enterprise to have that debate when they deploy. OK. >=20 > How do we handle the "NAT is our policy" sites? We do need to add this as you stated above. But not get into email war. >=20 > Are IPv6-specific features out of scope... e.g. privacy=20 > extensions which may impact policy implementations like=20 > (weak) IP-based authentication? In the scenarios I think they are but will have to see once we start analysis. >=20 > What about remote IPv4 nodes wishing to access your site=20 > IPv6(-only) services? Do you deploy (say) NAT-PT yourself, or=20 > rely on the remote site to introduce=20 > its own tools? Maybe this is covered OK in 4.3, but we=20 > could explicitly > expand on it. We should have a reference in scenarios so this can be discussed in analysis. >=20 > What about use of existing "software functions" that may ease=20 > transition, e.g. if already using proxies like web, mail, etc=20 > already, or using VLANs? Possibly a footnote. But we should stay within the charter expertise of this IETF WG. >=20 > We should capture general transition tool requirements=20 > somewhere, e.g. a site depends on handling 100,000 remote=20 > transactions per hour, then any proxies, > translators, etc must be able to support that level. Maybe for sure in scenarios as long as it does not point to or suggest any specific mechanism ok. thanks /jim =20 >=20 >=20 > Tim >=20 >=20 From owner-v6ops@ops.ietf.org Wed Oct 22 21:48:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13040 for ; Wed, 22 Oct 2003 21:48:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUUG-000P8b-Rl for v6ops-data@psg.com; Thu, 23 Oct 2003 01:42:04 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTw-000P5n-Ni for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:44 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3D908FDC9; Wed, 22 Oct 2003 21:41:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:43 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BB1@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOX1PtuoZh6d1CrSzanG77AQjZ4xABMOhQQ From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 23 Oct 2003 01:41:43.0909 (UTC) FILETIME=[D03E1950:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Note to WG and the counter for mail messages. I am going to be responding to lots of mail as Editor for Enterprise Scenarios. I will do my best to keep my opinions and diatribe out of this mail but need to acknowledge the responses. I will be as Terminator 1 and mission is to get edits right and verify corrections or ask for clarification. So I may appear on the counter next week or the next few. But as Editor. Other inputs I try to keep to no more than 10 mails a week. /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk]=20 > Sent: Tuesday, October 21, 2003 9:05 AM > To: v6ops@ops.ietf.org > Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 >=20 >=20 > On Tue, Oct 21, 2003 at 02:57:44PM +0200, Eva M. Castro wrote: > > I understand point 3.1 and 3.3 are very different, point=20 > 3.1 explains=20 > > transition scenarios, or IPv6 scenarios, and point 3.3 explains=20 > > existing enterprise scenarios. Maybe, it is more clear if=20 > the name of=20 > > these subsections is changed: > >=20 > > 3.1 IPv6 transition base scenarios. > > 3.2 Scenarios Characteristics. > > 3.3 Enterprise specific scenario examples. >=20 > I guess my comments were too long for you - I suggested the same :) > =20 > There was some confusion between motivations, scenarios, base=20 > scenarios which I suggested some changes for. Jim will be=20 > back in a week or so > and I'm sure will start collating comments. So some reinforcement in > suggestions is good. I am not back really, I just love you people so much I had to jump back to cyberspace :--). I will try to fix this confusion as Editor ok. But need to think and send short message to the WG to state a suggestion of text for direction for the spec. See if all can support it ok. Thanks. >=20 > > >Again, do you really mean IPv6-only, or IPv6-capable? > > > > > --> I understand every kind of node, without loosing IPv4/IPv6 > > interoperability. Not sure if it is required to emphasize the=20 > > different kind of nodes in this scope. >=20 > So this is a terminology issue. In the definitions section,=20 > IPv6 is defined as IPv6-only. Then in the text "IPv6" is=20 > used freely and may mean either IPv6 in general or IPv6-only.=20 > Maybe we should explicitly write IPv6-only when we really=20 > mean it, to avoid any possible confusion. Same response as above. > =20 > > --> In my opinion, coexistence means interoperability between every=20 > > --> kind > > of node and application that enterprise requires. Again,=20 > not sure if=20 > > the different kind of nodes and applications should be=20 > distinguished=20 > > in this scope. >=20 > Agree - the interworking is between nodes and applications;=20 > not all apps will be capable of both protocols, some will be=20 > IPv6-only, like new p2p apps for v6 - these may never talk to=20 > v4 except by proxies. > =20 > Tim Thanks /jim >=20 >=20 From owner-v6ops@ops.ietf.org Thu Oct 23 02:06: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 CAA27782 for ; Thu, 23 Oct 2003 02:06:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACYVh-000GlU-KX for v6ops-data@psg.com; Thu, 23 Oct 2003 05:59:49 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACYVZ-000Gk2-TO for v6ops@ops.ietf.org; Thu, 23 Oct 2003 05:59:42 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id BD52091; Thu, 23 Oct 2003 14:59:40 +0900 (JST) To: ipng@uni-muenster.de Cc: satapati@cisco.com, v6ops@ops.ietf.org Subject: Re: NAT-PT Applicability In-Reply-To: Your message of "Wed, 22 Oct 2003 13:27:31 +0200" <1066822051.2164.40.camel@kummerog.uni-muenster.de> References: <1066822051.2164.40.camel@kummerog.uni-muenster.de> X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031023055940.BD52091@coconut.itojun.org> Date: Thu, 23 Oct 2003 14:59:40 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Comments are welcome !!! > Here are my comments. > > Para 3.2: > If more than one box implementing NAT-PT is present, then the > scalability problem may be circumvented by using e.g. DNS-ALGs > that can do round-robin or some other form of load-balancing. > > Load-balancing also has its drawbacks as the majority of hosts > cache answers to DNS queries. And additionally, if the NAT-PT > box and the DNS-ALG are not one unit, failures of one or the > other are diffcult to handle (due to the current lack of some > form of communication/surveillance between the two). > > It is probably worth to mention that it is to some extent possible to do > load-balancing. Apart from that, I think that the draft is very nice and > surely a good help to get an overview of what problems one can expect > when deploying NAT-PT. > > Load balancing NAT-PT is quite a challenge. When using NAT-PT+DNS-ALG to > help IPv6 hosts to connect to the IPv4 world it is more complicated than > simply using a balancing DNS-ALG. It will work nicely until a NAT-PT box > dies or can't handle the amount of traffic anymore. When this is the > case, there have to be some means of notifying the DNS-ALG that this > NAT-PT box is unavailable and has to be left out when assigning IPv6 > prefixes to converted IPv4 addresses (assuming that each NAT-PT box > handles the translation for one of those assigned IPv6 prefixes for > converted IPv4 addresses). The question is how this can be done > efficiently. Does the DNS-ALG have to check the NAT-PT boxes somehow? Do > the NAT-PT boxes have to send out notifications that they can't > translate traffic anymore (if there is only a partial failure like too > much traffic/too much CPU usage/...)? Just a thought. with a commercial implementation (from Yokogawa) DNS-ALG monitors live/dead status of NAT-PT box by some means (ping?) and returns fabricated AAAA response with NAT-PT prefix associated with live boxes. i don't think we need to go into such implementation details in this document. itojun From owner-v6ops@ops.ietf.org Thu Oct 23 03:37: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 DAA06774 for ; Thu, 23 Oct 2003 03:37:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACZxN-000Mrl-Tv for v6ops-data@psg.com; Thu, 23 Oct 2003 07:32:29 +0000 Received: from [212.153.235.109] (helo=gw-nl5.philips.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACZxA-000Mqs-ME for v6ops@ops.ietf.org; Thu, 23 Oct 2003 07:32:16 +0000 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id 981DB55691; Thu, 23 Oct 2003 09:32:15 +0200 (MET DST) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 31CE119C52; Thu, 23 Oct 2003 09:32:14 +0200 (MEST) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 851E619C4A; Thu, 23 Oct 2003 09:32:13 +0200 (MEST) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id JAA04488; Thu, 23 Oct 2003 09:32:12 +0200 (MEST) From: mariana.nikolova@philips.com To: "JORDI PALET MARTINEZ" Cc: v6ops@ops.ietf.org Subject: Comments draft-palet-v6ops-proto41-nat-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 23 Oct 2003 09:31:20 +0200 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 23/10/2003 09:31:21, Serialize complete at 23/10/2003 09:31:21 Content-Type: multipart/alternative; boundary="=_alternative 00296B8AC1256DC8_=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.2 required=5.0 tests=BAYES_01, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 00296B8AC1256DC8_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jordi, my "last minutes" comments on your draft. Hope they are not "too late"=20 comments.=20 In general, I am very positive over the document. The remarks are mainly=20 for extra clarification! General comment:=20 1) "NAT boxes" is very often used in the draft meaning actually=20 "IPv4-only NAT node". An IPv6/IPv4 node that is a 6to4 router implements=20 also NAT only for IPv4 packets. Then, it can be referred to as a NAT boxes = as well. However, no need to implement proto41 on this box (although it=20 can be and you mention this in the draft but then it's overdone and rather = confusing for the router producer what (6to4 or proto41) and when=20 (IPv4-only or IPv6/IPv4 node) to implement ). The strong need for support=20 of proto41 is in "IPv4-only NAT nodes" in order to support IPv6 tunnels.=20 That is why I recommend the use of "IPv4-only NAT nodes" instead of "NAT=20 boxes". Further see my remark in section 5. 2) Very often in the draft "this behavior" is used meaning=20 "forwarding protocol 41" or the nickname "proto41". Replacing the former=20 with the latter is more tangible and I recommend it. Specific comments:=20 - Abstract I agree with the Rute's comment here 1. Introduction 1-2 paragraphs: Substitute with a short intro to the scene, e.g.=20 Nowadays homogeneous IPv4 private networks are massively deployed. The=20 first migration step from IPv4 to IPv6 for these networks is adding an=20 IPv6 node (or cluster of IPv6 nodes). In this case the IPv6 node=20 communicates with IPv6 peers in the public Internet via IPv6 packets=20 tunneled into IPv4 ones. Most of the existing solutions suppose that the=20 router of the private network is begin-/end-point of the tunnels. Typical=20 examples of such routers are 6to4 IPv6/IPv4 routers that have already been = commercially deployed. However, nowadays most of users have IPv4-only NAT=20 routers in their private networks and they are not willing immediately to=20 invest in a new router for whatever reasons, mostly financial. That is why in this draft we propose to make use of protocol 41 forwarding = in IPv4-only NAT routers. This mechanism allows IPv6 tunnels and therefore = facilitates the migration path from IPv4 to IPv6.=20 4 paragraph: revise, for example The scenario illustrated above has been tested with several IPv4-only NAT=20 boxes/routers that have successfully established IPv6 tunnels between=20 tunnel clients in a private network and tunnel servers in the public=20 Internet. In the test we have used three well-known Tunnel Broker=20 implementations (BT, Freenet6 and TILAB) and routers from 6Bone,=20 Consulintel, Euro6IX and UPM networks. 5 paragraph: This can --> This scenario can .. 2. Rationale for this behavior --> Rationale for using protocol 41 forward= ing 3. Behavior of different NAT types I do not understand Rute's confusion here since Basic (or Traditional)=20 NAT, NAPT and Bidirectional (or two-way) NAT is commonly used terminology. = 5 paragraph in 3.2: This can also be combined with basic NAT. -->This port= forwarding is often combined with basic NAT leading to NAPT. 2 paragraph in 3.3: Revision required. What you wanna say is written so=20 compact that it is rather getting non-understandable. 1 paragraph in 3.4: N.B. At the beginning of this section make clear that=20 "configurable" NAT can be either 3.1 or 3.2 or 3.3. Each of the first=20 three types can act as a fully bidirectional NAT for 41-packets if it is=20 configurable.=20 4. Applicability 1 paragraph:=20 inside-to-outside sessions outgoing sessions, outside-to-inside sessions = incoming sessions So, this is consistent with the terminology you use later. If my first general comment is applied here the Rute's remark is resolved. = 6 paragraph: the application of this procedure --> the application of 41-p= ackets forwarding=20 7 paragraph: move to Introduction and consider language revision 8 paragraph: move to Introduction after the intro paragraph I suggested. 5. NAT design consideration --> NAT design consideration and recommendatio= ns I agree with the Rute's first comment here.=20 3 paragraph: confusing the reader and contradicting the general idea. I=20 would rather say something like=20 The proto41 and 6to4 are complementary transition mechanisms that=20 facilitate the migration from IPv4 to IPv6.These two mechanisms are in=20 general applicable in different migration steps. The proto41 mechanism is=20 mostly relevant and applicable for IPv4-only NAT routers whereas 6to4=20 mechanism is mostly relevant and applicable for IPv6/IPv4 routers. Notice=20 that an IPv6/IPv4 router that is 6to4 enabled and implements NAT only for=20 IPv4 packets does not need to be proto41 enabled.=20 Some extra conclusions that you may add to make this section complete: =B7 The proto41 adds an enhanced feature to the IPv4-only NAT routers= , namely=20 enabling them to forward IPv6 packets encapsulated into IPv4 ones, i.e.,=20 allowing for IPv6 tunneling. =B7 The proto41 completely preserves the users investments in the exi= sting=20 IPv4 networks. This is essential for gaining market acceptance. =B7 The proto41 allows for gradual migration from IPv4 to IPv6 networ= ks making=20 the migration path easy and acceptable for the users.=20 Greetings,=20 Mariana ---------------------------------------------------------------------------= -------------------------------------- Dr. Mariana Nikolova=20 Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com=20 ---------------------------------------------------------------------------= -------------------------------------- --=_alternative 00296B8AC1256DC8_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Jordi,

my "last minutes" comments= on your draft. Hope they are not "too late" comments.
In general, I am very positive over = the document. The remarks are mainly for extra clarification!

General comment:

1)        "= NAT boxes" is very often used in the draft meaning actually "IPv4= -only NAT node". An IPv6/IPv4 node that is a 6to4 router implements al= so NAT only for IPv4 packets. Then, it can be referred to as a NAT boxes as= well. However, no need to implement proto41 on this box (although it can b= e and you mention this in the draft but then it's overdone and rather confu= sing for the router producer what (6to4 or proto41) and when (IPv4-only or = IPv6/IPv4 node) to implement ). The strong need for support of proto41 is i= n "IPv4-only NAT nodes" in order to support IPv6 tunnels. That is= why I recommend the use of "IPv4-only NAT nodes" instead of &quo= t;NAT boxes". Further see my remark in section 5.
2)        Very o= ften in the draft "this behavior" is used meaning "forwardin= g protocol 41" or the nickname "proto41". Replacing the form= er with the latter is more tangible and I recommend it.

Specific comments:

- Abstract
I agree with the Rute's comment here=

1. Introduction
1-2 paragraphs: Substitute with a sh= ort intro to the scene, e.g.  

Nowadays homogeneous IP= v4 private networks are massively deployed. The first migration step from I= Pv4 to IPv6 for these networks is adding an IPv6 node (or cluster of IPv6 n= odes). In this case the IPv6 node communicates with IPv6 peers in the publi= c Internet via IPv6 packets tunneled into IPv4 ones. Most of the existing s= olutions suppose that the router of the private network is begin-/end-point= of the tunnels. Typical examples of such routers are 6to4 IPv6/IPv4 router= s that have already been commercially deployed. However, nowadays most of u= sers have IPv4-only NAT routers in their private networks and they are not = willing immediately to invest in a new router for whatever reasons, mostly = financial.
That is why in this dra= ft we propose to make use of protocol 41 forwarding in IPv4-only NAT router= s. This mechanism allows IPv6 tunnels and therefore facilitates the migrati= on path from IPv4 to IPv6.  

4 paragraph: revise, for example
The scenario illustrate= d above has been tested with several IPv4-only NAT boxes/routers that have = successfully established IPv6 tunnels between tunnel clients in a private n= etwork and tunnel servers in the public Internet. In the test we have used = three well-known Tunnel Broker implementations (BT, Freenet6 and TILAB) and= routers from 6Bone, Consulintel, Euro6IX and UPM networks.

5 paragraph: This can -->  <= /font>This scenario can ..<= /font>

2. Rationale for this behavior  --> Rationale for using protocol 41 forwarding

3. Behavior of different NAT type= s
I do not understand Rute's confusion= here since Basic (or Traditional) NAT, NAPT and Bidirectional (or two-way)= NAT is commonly used terminology.

5 paragraph in 3.2: This can also be= combined with basic NAT.  -->This port forwarding is often combi= ned with basic NAT leading to NAPT.

2 paragraph in 3.3: Revision require= d. What you wanna say is written so compact that it is rather getting non-u= nderstandable.

1 paragraph in 3.4: N.B. At the begi= nning of this section make clear that "configurable" NAT can be e= ither 3.1 or 3.2 or 3.3. Each of the first three types can act as a fully b= idirectional NAT for 41-packets if it is configurable.

4. Applicability

1 paragraph:
inside-to-outside sessions  outgoing sessions, outside-to-inside sessions  incoming sessions
So, this is consistent with the term= inology you use later.
If my first general comment is appli= ed here the Rute's remark is resolved.

6 paragraph: the application of this= procedure  --> the application of 41-packets forwarding

7 paragraph: move to Introduction an= d consider language revision

8 paragraph: move to Introduction af= ter the intro paragraph I suggested.


5. NAT design consideration <= /font> --> NAT design consideration and recommendations

I agree with the Rute's first commen= t here.

3 paragraph: confusing the reader an= d contradicting the general idea. I would rather say something like

The proto41 and 6to4 ar= e complementary transition mechanisms that facilitate the migration from IP= v4 to IPv6.These two mechanisms are in general applicable in different migr= ation steps. The proto41 mechanism is mostly relevant and applicable for IP= v4-only NAT routers whereas 6to4 mechanism is mostly relevant and applicabl= e for IPv6/IPv4 routers. Notice that an IPv6/IPv4 router that is 6to4 enabl= ed and implements NAT only for IPv4 packets does not need to be proto41 ena= bled.

Some extra conclusions that you may = add to make this section complete:

=B7       &n= bsp;The proto41 adds= an enhanced feature to the IPv4-only NAT routers, namely enabling them to = forward IPv6 packets encapsulated into IPv4 ones, i.e., allowing for IPv6 t= unneling.
=B7       &n= bsp;The proto41 comp= letely preserves the users investments in the existing IPv4 networks. This = is essential for gaining market acceptance.
=B7       &n= bsp;The proto41 allo= ws for gradual migration from IPv4 to IPv6 networks making the migration pa= th easy and acceptable for the users.  


Greetings,
Mariana
---------------------------------------------------------------------------= --------------------------------------
Dr. Mariana Nikolova    
Philips Research Laboratories Eindhoven (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands
room: WDC 1.35,     phone: +31-40-27-45455
e-mail: mariana.nikolova@philips.com
---------------------------------------------------------------------------= -------------------------------------- --=_alternative 00296B8AC1256DC8_=-- From owner-v6ops@ops.ietf.org Thu Oct 23 08:46: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 IAA16275 for ; Thu, 23 Oct 2003 08:46:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACeig-000Jcy-IO for v6ops-data@psg.com; Thu, 23 Oct 2003 12:37:38 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACeiY-000JcI-8m for v6ops@ops.ietf.org; Thu, 23 Oct 2003 12:37:30 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA01700 for ; Thu, 23 Oct 2003 13:37:28 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA04794 for ; Thu, 23 Oct 2003 13:37:28 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9NCbSr23839 for v6ops@ops.ietf.org; Thu, 23 Oct 2003 13:37:28 +0100 Date: Thu, 23 Oct 2003 13:37:28 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 Message-ID: <20031023123728.GC22430@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BA8@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BA8@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Oct 22, 2003 at 09:41:41PM -0400, Bound, Jim wrote: > > But does IPv6 only mean that the node simply does not have an IPv4 stack > at all. I don't see that happening for a long time. I suggest we > assume dual stack for this work and not IPv6 only. That for IPv6 ONLY a > future addendum to this spec be written? [Comments on the open replies - everything you say looks fine to me Jim] The way many enterprises will add IPv6 functionality is to put dual-stack on the network and enable as many devices and applications as they can/need. The common method in universities at present is to inject Router Advertisements into existing IPv4 VLANs, such that the IPv4/IPv6 subnets are congruent. The nice property of IPv6 here is that you can add devices that communicate only over IPv6 (IPv4 may be in the stack but not enabled), keeping the same IPv4 subnet plan. So small, IPv6-enabled devices that support "ambience" can be introduced into the enterprise while keeping the existing addressing plan, and dual stack devices and proxies provide the communication to the new devices. It's one quite reasonable path for introduction of IPv6(-only) devices. The question is how this fits into the v6ops-ent-scenarios document - I think the introduction of such devices has to be in here somewhere or at worst referenced as a future work later. I would hope/expect this is realistic inside 4 years for example. > > - If not upgradeable, can an equivalent upgradeable > > software function > > be substituted for the one that is not upgradeable? > > (e.g. a different > > directory service mechanism) > > This I think is to be done in the analysis spec?????????? I think it's again implementation specific (e.g. one directory service has no IPv6 support while another does) and thus should probably be treated in the same way (whatever that is :) as certain host or router platforms that as yet lack certain IPv6 functionality. I think we have to just use terms like "legacy IPv4-only devices" in a generic way and the analysis for introducing IPv6 has to determine if/how to interact with such devices (or applications, as we can have "legacy IPv4-only applications" on dual-stack devices). > > This is an important area the WG needs to take on board. > > Yep. I think Management Scenarios could be its own spec? Agree. > > Does this affect the transition tool analysis, e.g. if > > RFC3041 means that IP-based authentication is no longer > > possible? I guess it may affect a > > specific implementation of a security policy? > > Yep. But what I was thinking here is what new problems does transition > introduce onto the network of the enterprise? That list would be useful > I think. Esp. in Ent Scenarios to feed Ent Analysis doc. OK, this is a good question but as you suggest maybe a separate doc. > > You could say the translator may be at the network, transport > > or application layer. > > We can add that but for this "reference" model document I don't think it > matters? OK. > > There are three categories of issues I think, i.e. > > > > - standards: dns resolver discovery, 512-byte response format, > > reverse zone managemnt and dynamic dns > > > > - transport: root servsers, OS supporting native lookup, > > and whether the > > upstream ISPs filter the root space /48's > > > > - registry: registering domains with IPv6 DNS servers > > Agree but is Enterprise Scenarios the only spec that needs to address > that what about Umanaged, 3GPP, or ISP docs? There are many commonalities between the scenerio documents, but I think it's been very useful for each of the four to use its own approach as each is then taking a different view of a similar problem to get best insight. The standards issues need analysis by dnsop (e.g. I think Alain has a draft on reverse zone population for autoconf networks) while the transport and registry issues are "implementation specific" issues that will (have to be :) fixed one day, but not by the IETF. > This is true for all scenario documents, is Enterprise work the only > spec that has to do this or do we need a generic DNS transition document > as Management etc... It's maybe beginning to look that way... we need some vertical analysis (or horizontal, depending on which way you look at it!) across the scenarios on some specific items. So far it looks like we have network management, maybe transition management as part of that, and DNS. > > Will it need DHCPv6 forwarding? > > Do you mean relaying? Yes, sorry. > > Would IPv4 and IPv6 subnets be congruent? > > I think parallel is more correct? OK. (Congruent when I look it up says "coinciding exactly when superimposed", by which I mean the IPv4 and IPv6 subnets are laid onto the same set of devices). > > An advantage of IPv6 is that you are unlikely to ever need to > > resize the subnets (up or down). > > ERRRRRRRRRRRRRRRRR. Need to think about that. One could blow the bits > to the left on a site boundary with sensors :--). OK, maybe when we get into really big networks :):) What I mean is that now an enterprise will slice up its IPv4 address space into the smallest subnets that it can, to conserve address space (and to be able to go back to ask for more IPv4 address space). So you'll quite commonly need to fiddle with those subnet sizes as the number of workstations or whatever in an existing subnet grows or shrinks. In IPv6 you have (relative) flexibility there. > > Do we have address space independence from provider? > > I don't believe this is true at all? We do not even more so with IPv6 > and I don't like that quite frankly ................... OK. > > What about preference of use of IPv4 or IPv6? > > Ouch. I fear a 1000 mail message debate. I suggest we avoid this and > leave scenarios for the enterprise to have that debate when they deploy. > OK. Yes :) Tim From owner-v6ops@ops.ietf.org Thu Oct 23 09:29: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 JAA18539 for ; Thu, 23 Oct 2003 09:29:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACfV0-000NxS-8o for v6ops-data@psg.com; Thu, 23 Oct 2003 13:27:34 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACfUy-000NxE-0z for v6ops@ops.ietf.org; Thu, 23 Oct 2003 13:27:32 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18337; Thu, 23 Oct 2003 09:27:21 -0400 (EDT) Message-Id: <200310231327.JAA18337@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chown-v6ops-vlan-usage-00.txt Date: Thu, 23 Oct 2003 09:27:21 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks Author(s) : T. Chown, et. al. Filename : draft-chown-v6ops-vlan-usage-00.txt Pages : 10 Date : 2003-10-22 Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, including the most likely scenario of subnets running IPv6 in parallel with the existing IPv4 subnets in the enterprise. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-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-chown-v6ops-vlan-usage-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-chown-v6ops-vlan-usage-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-10-22183820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-chown-v6ops-vlan-usage-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-chown-v6ops-vlan-usage-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183820.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 23 09:32: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 JAA18842 for ; Thu, 23 Oct 2003 09:32:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACfXz-000OE1-Af for v6ops-data@psg.com; Thu, 23 Oct 2003 13:30:39 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACfXo-000OD5-T8 for v6ops@ops.ietf.org; Thu, 23 Oct 2003 13:30:29 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18587; Thu, 23 Oct 2003 09:30:18 -0400 (EDT) Message-Id: <200310231330.JAA18587@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-v6onbydefault-00.txt Date: Thu, 23 Oct 2003 09:30:18 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Dual Stack IPv6 on by Default Author(s) : S. Roy Filename : draft-ietf-v6ops-v6onbydefault-00.txt Pages : 18 Date : 2003-10-22 This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network security. Its purpose is to raise awareness of these problems so that they can be fixed or worked around. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-v6onbydefault-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-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-10-22183942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-v6onbydefault-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183942.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 23 09:32: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 JAA18890 for ; Thu, 23 Oct 2003 09:32:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACfYX-000OLO-Pl for v6ops-data@psg.com; Thu, 23 Oct 2003 13:31:13 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACfYO-000OKf-Rd for v6ops@ops.ietf.org; Thu, 23 Oct 2003 13:31:04 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18645; Thu, 23 Oct 2003 09:30:54 -0400 (EDT) Message-Id: <200310231330.JAA18645@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-onlinkassumption-00.txt Date: Thu, 23 Oct 2003 09:30:54 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Neighbor Discovery On-Link Assumption Considered Harmful Author(s) : S. Roy, et. al. Filename : draft-ietf-v6ops-onlinkassumption-00.txt Pages : 11 Date : 2003-10-22 This document proposes a change to the IPv6 Neighbor Discovery conceptual host sending algorithm. According to the algorithm, when a host's default router list is empty, the host assumes that all destinations are on-link. This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-onlinkassumption-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-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-10-22183955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-onlinkassumption-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183955.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 23 11:42: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 LAA00641 for ; Thu, 23 Oct 2003 11:42:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AChVk-000AWa-RU for v6ops-data@psg.com; Thu, 23 Oct 2003 15:36:28 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AChVg-000AW2-Oy for v6ops@ops.ietf.org; Thu, 23 Oct 2003 15:36:25 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29811; Thu, 23 Oct 2003 11:36:13 -0400 (EDT) Message-Id: <200310231536.LAA29811@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chown-v6ops-port-scanning-implications-00.txt Date: Thu, 23 Oct 2003 11:36:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Implications for TCP/UDP Port Scanning Author(s) : T. Chown Filename : draft-chown-v6ops-port-scanning-implications-00.txt Pages : 12 Date : 2003-10-23 The 128 bits of IPv6 address space is considerably bigger than the 32 bits of address space in IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space. As a result, traditional methods of remote TCP or UDP port scanning to discover open or running services on a host will potentially become far less computationally feasible, due to the larger search space in the subnet. This document discusses that property of IPv6 subnets, and describes related issues for site administrators of IPv6 networks to consider. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chown-v6ops-port-scanning-implications-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-chown-v6ops-port-scanning-implications-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-chown-v6ops-port-scanning-implications-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-10-23112654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-chown-v6ops-port-scanning-implications-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-chown-v6ops-port-scanning-implications-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-23112654.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 23 14:06: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 OAA10353 for ; Thu, 23 Oct 2003 14:06:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACjkU-000P5H-P0 for v6ops-data@psg.com; Thu, 23 Oct 2003 17:59:50 +0000 Received: from [206.157.224.254] (helo=hatl0ms21.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACjkP-000P4f-Og for v6ops@ops.ietf.org; Thu, 23 Oct 2003 17:59:45 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Oct 2003 13:59:44 -0400 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Thu, 23 Oct 2003 13:59:12 -0400 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:51:07 -0400 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:51:06 -0400 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9N1p6108077 for ; Wed, 22 Oct 2003 21:51:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUU8-000P7B-Ec for v6ops-data@psg.com; Thu, 23 Oct 2003 01:41:56 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTw-000P5l-IR for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:44 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AF36EFCB7; Wed, 22 Oct 2003 21:41:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:43 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BAF@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOXl/qkceBtT8ywRiaJBJgbOKNpLQBay/kw From: "Bound, Jim" To: "Chirayu Patel" , Cc: "Pekka Savola" , "Tim Chown" X-OriginalArrivalTime: 23 Oct 2003 01:41:43.0347 (UTC) FILETIME=[CFE85830:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable CP, Thanks for the comments. > Some quick comments: > > 1. The definition of scenario needs to be clarified. I was under the > assumption that a scenario would correspond to a stage in the > deployment of IPv6 in the enterprise network. For example, > the cases described in section 5 in > =20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-sce narios-03.txt. The Enterprise Scenarios are exponentially greater than uman scenarios. Thus the potential stages of deployment within those is even greater. What we could do is add a stages of deployment section to try to provide a reference for users to be aware of to take those into consideration. But Enterprises are quite different and will approach this in many different ways. 2. The scenario description in section 3.1, and the examples in section 3.3 do not seem to be in tune. The purpose of section 3.3 is to provide clarity on the base scenarios but, IMHO, it does not do that. For example, how does the example network A shed more light on Scenario 1, or 2, or 3? Fair question. We need to provide that in an appendix. All three examples 3.1 could apply to all specific examples in 3.3. And we need to cover this in the spec and then show examples in the spec. For example: Example Network A: A distributed network across a number of geographically separated campuses Each scenario in 3.0 could be applied to Network A. Then: - External network operation. - External connectivity required. - Multiple sites connected by leased lines. - Provider independent IPv4 addresses. - ISP does not offer IPv6 service. - Private Leased Lines no Service Provider Used Each apply for this example from each scenario. Applications run by the enterprise: - Internal Web/Mail. - File servers. - Java applications. - Collaborative development tools. - Enterprise Resource Applications. - Multimedia Applications. - Financial Enterprise Applications. - Data Warehousing Applications. These could be required in all 3.0 scenarios. Internal network operation: - In house operation of the network. - DHCP (v4) is used for all desktops, servers use static address configuration. - The DHCP server to update naming records for dynamic desktops uses dynamic DNS. - A web based tool is used to enter name to address mappings for statically addressed servers. - Network management is done using SNMP. - All routers and switches are upgradeable to IPv6. - Existing firewalls can be upgraded to support IPv6 rules. - Load balancers do not support IPv6, upgrade path unclear. - Peer-2-Peer Application and Security supported. This could be the case for each scenario too. The idea is 3.0 scenarios state generic base solutions that cover a wide range of Enterprise approaches to IPv6 deployment. Then 3.3 "specific examples" give types of networks that could use any of the base scenarios. /jim CP On Mon, 20 Oct 2003 09:48:57 +0300 (EEST), "Pekka Savola" said: > On Sat, 18 Oct 2003, Tim Chown wrote: > > Here are some (long) comments on draft 00. I am sorry they are > > later than ideal but I hope they are still useful prior to > > Minneapolis. > > > > The document is absolutely on the right track, in my view. The > > detail of comments is mainly for clarification :) > [...] > > Thanks Tim. These kind of comments are exactly what we need to move > the scenarios documents forward. Hopefully other folks also have a > chance to read and comment on the document. > > Pekka writing as WG co-chair > > From owner-v6ops@ops.ietf.org Thu Oct 23 14:52:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12396 for ; Thu, 23 Oct 2003 14:52:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACkVG-0003j4-Ht for v6ops-data@psg.com; Thu, 23 Oct 2003 18:48:10 +0000 Received: from [206.157.224.254] (helo=hatl0ms21.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACkVB-0003io-D4 for v6ops@ops.ietf.org; Thu, 23 Oct 2003 18:48:05 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Oct 2003 14:48:04 -0400 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Thu, 23 Oct 2003 14:47:29 -0400 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:51:07 -0400 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:51:06 -0400 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9N1p6108077 for ; Wed, 22 Oct 2003 21:51:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUU8-000P7B-Ec for v6ops-data@psg.com; Thu, 23 Oct 2003 01:41:56 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTw-000P5l-IR for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:44 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AF36EFCB7; Wed, 22 Oct 2003 21:41:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:43 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BAF@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOXl/qkceBtT8ywRiaJBJgbOKNpLQBay/kw From: "Bound, Jim" To: "Chirayu Patel" , Cc: "Pekka Savola" , "Tim Chown" X-OriginalArrivalTime: 23 Oct 2003 01:41:43.0347 (UTC) FILETIME=[CFE85830:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable CP, Thanks for the comments. > Some quick comments: > > 1. The definition of scenario needs to be clarified. I was under the > assumption that a scenario would correspond to a stage in the > deployment of IPv6 in the enterprise network. For example, > the cases described in section 5 in > =20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-sce narios-03.txt. The Enterprise Scenarios are exponentially greater than uman scenarios. Thus the potential stages of deployment within those is even greater. What we could do is add a stages of deployment section to try to provide a reference for users to be aware of to take those into consideration. But Enterprises are quite different and will approach this in many different ways. 2. The scenario description in section 3.1, and the examples in section 3.3 do not seem to be in tune. The purpose of section 3.3 is to provide clarity on the base scenarios but, IMHO, it does not do that. For example, how does the example network A shed more light on Scenario 1, or 2, or 3? Fair question. We need to provide that in an appendix. All three examples 3.1 could apply to all specific examples in 3.3. And we need to cover this in the spec and then show examples in the spec. For example: Example Network A: A distributed network across a number of geographically separated campuses Each scenario in 3.0 could be applied to Network A. Then: - External network operation. - External connectivity required. - Multiple sites connected by leased lines. - Provider independent IPv4 addresses. - ISP does not offer IPv6 service. - Private Leased Lines no Service Provider Used Each apply for this example from each scenario. Applications run by the enterprise: - Internal Web/Mail. - File servers. - Java applications. - Collaborative development tools. - Enterprise Resource Applications. - Multimedia Applications. - Financial Enterprise Applications. - Data Warehousing Applications. These could be required in all 3.0 scenarios. Internal network operation: - In house operation of the network. - DHCP (v4) is used for all desktops, servers use static address configuration. - The DHCP server to update naming records for dynamic desktops uses dynamic DNS. - A web based tool is used to enter name to address mappings for statically addressed servers. - Network management is done using SNMP. - All routers and switches are upgradeable to IPv6. - Existing firewalls can be upgraded to support IPv6 rules. - Load balancers do not support IPv6, upgrade path unclear. - Peer-2-Peer Application and Security supported. This could be the case for each scenario too. The idea is 3.0 scenarios state generic base solutions that cover a wide range of Enterprise approaches to IPv6 deployment. Then 3.3 "specific examples" give types of networks that could use any of the base scenarios. /jim CP On Mon, 20 Oct 2003 09:48:57 +0300 (EEST), "Pekka Savola" said: > On Sat, 18 Oct 2003, Tim Chown wrote: > > Here are some (long) comments on draft 00. I am sorry they are > > later than ideal but I hope they are still useful prior to > > Minneapolis. > > > > The document is absolutely on the right track, in my view. The > > detail of comments is mainly for clarification :) > [...] > > Thanks Tim. These kind of comments are exactly what we need to move > the scenarios documents forward. Hopefully other folks also have a > chance to read and comment on the document. > > Pekka writing as WG co-chair > > From owner-v6ops@ops.ietf.org Thu Oct 23 18:19: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 SAA22449 for ; Thu, 23 Oct 2003 18:19:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACnhG-0005DH-3c for v6ops-data@psg.com; Thu, 23 Oct 2003 22:12:46 +0000 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACnhB-0005Cu-Ti for v6ops@ops.ietf.org; Thu, 23 Oct 2003 22:12:41 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Oct 2003 18:12:41 -0400 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Thu, 23 Oct 2003 18:05:42 -0400 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:52:21 -0400 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:52:17 -0400 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9N1qG108831 for ; Wed, 22 Oct 2003 21:52:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUUG-000P8b-Rl for v6ops-data@psg.com; Thu, 23 Oct 2003 01:42:04 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTw-000P5n-Ni for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:44 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3D908FDC9; Wed, 22 Oct 2003 21:41:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:43 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BB1@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOX1PtuoZh6d1CrSzanG77AQjZ4xABMOhQQ From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 23 Oct 2003 01:41:43.0909 (UTC) FILETIME=[D03E1950:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Note to WG and the counter for mail messages. I am going to be responding to lots of mail as Editor for Enterprise Scenarios. I will do my best to keep my opinions and diatribe out of this mail but need to acknowledge the responses. I will be as Terminator 1 and mission is to get edits right and verify corrections or ask for clarification. So I may appear on the counter next week or the next few. But as Editor. Other inputs I try to keep to no more than 10 mails a week. /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk]=20 > Sent: Tuesday, October 21, 2003 9:05 AM > To: v6ops@ops.ietf.org > Subject: Re: Comments on draft-ietf-v6ops-ent-scenarios-00 >=20 >=20 > On Tue, Oct 21, 2003 at 02:57:44PM +0200, Eva M. Castro wrote: > > I understand point 3.1 and 3.3 are very different, point=20 > 3.1 explains=20 > > transition scenarios, or IPv6 scenarios, and point 3.3 explains=20 > > existing enterprise scenarios. Maybe, it is more clear if=20 > the name of=20 > > these subsections is changed: > >=20 > > 3.1 IPv6 transition base scenarios. > > 3.2 Scenarios Characteristics. > > 3.3 Enterprise specific scenario examples. >=20 > I guess my comments were too long for you - I suggested the same :) > =20 > There was some confusion between motivations, scenarios, base=20 > scenarios which I suggested some changes for. Jim will be=20 > back in a week or so > and I'm sure will start collating comments. So some reinforcement in > suggestions is good. I am not back really, I just love you people so much I had to jump back to cyberspace :--). I will try to fix this confusion as Editor ok. But need to think and send short message to the WG to state a suggestion of text for direction for the spec. See if all can support it ok. Thanks. >=20 > > >Again, do you really mean IPv6-only, or IPv6-capable? > > > > > --> I understand every kind of node, without loosing IPv4/IPv6 > > interoperability. Not sure if it is required to emphasize the=20 > > different kind of nodes in this scope. >=20 > So this is a terminology issue. In the definitions section,=20 > IPv6 is defined as IPv6-only. Then in the text "IPv6" is=20 > used freely and may mean either IPv6 in general or IPv6-only.=20 > Maybe we should explicitly write IPv6-only when we really=20 > mean it, to avoid any possible confusion. Same response as above. > =20 > > --> In my opinion, coexistence means interoperability between every=20 > > --> kind > > of node and application that enterprise requires. Again,=20 > not sure if=20 > > the different kind of nodes and applications should be=20 > distinguished=20 > > in this scope. >=20 > Agree - the interworking is between nodes and applications;=20 > not all apps will be capable of both protocols, some will be=20 > IPv6-only, like new p2p apps for v6 - these may never talk to=20 > v4 except by proxies. > =20 > Tim Thanks /jim >=20 >=20 From owner-v6ops@ops.ietf.org Thu Oct 23 19:31: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 TAA24408 for ; Thu, 23 Oct 2003 19:31:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACory-0008fO-6f for v6ops-data@psg.com; Thu, 23 Oct 2003 23:27:54 +0000 Received: from [138.162.0.44] (helo=gate5-norfolk.nmci.navy.mil) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACoru-0008ew-Fr for v6ops@ops.ietf.org; Thu, 23 Oct 2003 23:27:50 +0000 Received: from naeanrfkms03.nmci.navy.mil by gate5-norfolk.nmci.navy.mil via smtpd (for psg.com [147.28.0.62]) with ESMTP; Fri, 24 Oct 2003 00:27:50 +0100 Received: (private information removed) Received: from no.name.available by naeanrfkfw01c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Fri, 24 Oct 2003 00:27:49 +0100 Received: (private information removed) Received: from mail pickup service by NAEANRFKEG02.nadsusea.nads.navy.mil with Microsoft SMTPSVC; Thu, 23 Oct 2003 19:26:32 -0400 Received: from naeanrfkfw05.nmci.navy.mil ([10.16.0.45]) by NAEANRFKEG02.nadsusea.nads.navy.mil with Microsoft SMTPSVC(5.0.2195.4453); Fri, 12 Sep 2003 10:35:48 -0400 Received: from naeanrfkms02.nadsusea.nads.navy.mil by naeanrfkfw05.nmci.navy.mil via smtpd (for insidesmtp.navy.mil [10.16.20.70]) with ESMTP; Fri, 12 Sep 2003 15:35:48 +0100 Received: from naeanrfkfw04c.nmci.navy.mil (naeanrfkfw04c.nmci.navy.mil [10.16.0.164]) by naeanrfkms02.nadsusea.nads.navy.mil (Switch-2.2.5/Switch-2.2.0) with SMTP id h8CETCx20906 for ; Fri, 12 Sep 2003 14:29:13 GMT Received: from chsfinch.spawar.navy.mil ([198.253.39.45]) by naeanrfkfw04c.nmci.navy.mil via smtpd (for [10.16.0.173]) with ESMTP; Fri, 12 Sep 2003 15:35:47 +0100 Received: from 198.253.39.45 by chsfinch.spawar.navy.mil (InterScan E-Mail VirusWall NT); Fri, 12 Sep 2003 10:40:13 -0400 Received: by chsfinch.spawar.navy.mil with Internet Mail Service (5.5.2655.55) id ; Fri, 12 Sep 2003 10:40:12 -0400 Received: from scraven.atlantic.spawar.navy.mil ([172.17.45.11]) by scraven.atlantic.spawar.navy.mil with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SXCLL87N; Fri, 12 Sep 2003 10:25:49 -0400 Received: from 128.49.251.3 by scraven.atlantic.spawar.navy.mil (InterScan E-Mail VirusWall NT); Fri, 12 Sep 2003 10:25:48 -0400 Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by droid6.spawar.navy.mil (8.12.8/8.12.8) with ESMTP id h8CEYsZg022597 for ; Fri, 12 Sep 2003 07:34:54 -0700 Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h8CEPGN28291; Fri, 12 Sep 2003 07:25:16 -0700 (PDT) Received: from purgatory.unfix.org (postfix@cust.92.136.adsl.cistron.nl [195.64.92.136]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h8CEMSN27791 for <6bone@mailman.isi.edu>; Fri, 12 Sep 2003 07:22:28 -0700 (PDT) Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 96AF08033; Fri, 12 Sep 2003 16:22:24 +0200 (CEST) From: Jeroen Massar To: "'Duncan Rogerson'" Cc: 6bone@mailman.isi.edu, users@ipv6.org, v6ops@ops.ietf.org Subject: RE: [6bone] Awareness of breaking RFC3056 with 6to4 more specifics Organization: Unfix Message-ID: <005301c37939$497384b0$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.4510 In-Reply-To: <1063375492.30895.44.camel@dixon.fizzypop.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gamma.isi.edu id h8CEMSN27791 X-BeenThere: 6bone@mailman.isi.edu X-Mailman-Version: 2.0.5 List-Help: List-Archive: Date: Fri, 12 Sep 2003 16:22:23 +0200 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.01, required 5, FORGED_RCVD_HELO 0.00, LINES_OF_YELLING 0.01) X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang) X-OriginalArrivalTime: 12 Sep 2003 14:35:51.0592 (UTC) FILETIME=[2A485280:01C3793B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Duncan Rogerson [mailto:d.rogerson@ukerna.ac.uk] wrote: > Jeroen, > > > Are the ones in the To line aware that you are breaking RFC3056 > > by announcing 6to4 more specifics? > > Thanks for bringing this to our (AS786) attention. We are > aware of the RFCs, however were not aware this route was leaking. > Hopefully it is fixed now. It is indeed gone out of the tables collected by GRT. So is another anomaly I reported in private to which was carrying a private ASN in it's ASPath. And so is the one carried from ACO.Net. Thank you all for the quick responses and fixes. Only 5 prefixes to go sourced from 3 ASN's. > (btw, I don't know if it was intended, or if it was a > non-native English speaker problem, but fyi, the tone of your message was pretty > offensive) That was certainly _not_ my intention. Raising awareness in these kind of 'problems', which are not really destructive, goes much better when you don't offend someone and does solve the problems. The reason for CC'ing the several lists is thus also for raising awareness, not for laughing at people in the To: line. I should have bcc'd them. This is a bigger issue as apparently many ISP's don't filter this prefix, which they should according to the RFC. Excuses if I offended anyone unintended. If you can followup in private which wordings you think where offensive I can alter them next time as indeed I am not a native english speaker, though I do try to do my best. Greets, Jeroen ps: cut off everybody except the ml's and bcc'd them now. Which I should have done in the first place actually... -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2HWnymqKFIzPnwjEQKHqACfUihmEs+SuDBXGjfa3hphxb6AhIsAn0MI TooZRIrc6QR3GCOpyxT3o7+A =GtFq -----END PGP SIGNATURE----- _______________________________________________ 6bone mailing list 6bone@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/6bone From owner-v6ops@ops.ietf.org Thu Oct 23 19:37: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 TAA24523 for ; Thu, 23 Oct 2003 19:37:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACoyL-0008vQ-8S for v6ops-data@psg.com; Thu, 23 Oct 2003 23:34:29 +0000 Received: from [206.157.224.254] (helo=hatl0ms21.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACoyE-0008v3-Fz for v6ops@ops.ietf.org; Thu, 23 Oct 2003 23:34:22 +0000 Received: from CATL0MS82.corp.cox.com ([10.62.200.232]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Oct 2003 19:34:21 -0400 Received: from mail pickup service by CATL0MS82.corp.cox.com with Microsoft SMTPSVC; Thu, 23 Oct 2003 19:34:19 -0400 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms22.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:51:49 -0400 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Oct 2003 21:51:49 -0400 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9N1plB07754 for ; Wed, 22 Oct 2003 21:51:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACUU3-000P6z-RC for v6ops-data@psg.com; Thu, 23 Oct 2003 01:41:51 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACUTu-000P5Z-Nd for v6ops@ops.ietf.org; Thu, 23 Oct 2003 01:41:42 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F38C5110B0; Wed, 22 Oct 2003 21:41:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 22 Oct 2003 21:41:41 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-v6ops-ent-scenarios-00 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 22 Oct 2003 21:41:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B04E86BA8@tayexc13.americas.cpqcorp.net> Thread-Topic: Comments on draft-ietf-v6ops-ent-scenarios-00 Thread-Index: AcOVcPdnWKGVipjYRf+bM5WEQ5mnAwDhvyyw From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 23 Oct 2003 01:41:41.0613 (UTC) FILETIME=[CEDFC1D0:01C39906] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Tim, Thanks for your hard work and thorough read of the specs and good input to the work. > Here are some (long) comments on draft 00. I am sorry they=20 > are later than=20 > ideal but I hope they are still useful prior to Minneapolis. Very useful. >=20 > The document is absolutely on the right track, in my view. =20 > The detail of comments is mainly for clarification :) The team thanks you for that comment. >=20 > The introduction generally reads very well and sets the scene nicely. Thanks. >=20 > > Each enterprise will select the transition that best=20 > supports their > > business requirements. Any attempt to define a default=20 > or one-size- > > fits-all transition scenario, will simply not work. This document > > does not try to depict the drivers for adoption of IPv6 by an > > Enterprise. >=20 > OK, so the next paragraph shouldn't mention drivers =3D motivations: Good catch. >=20 > > While it is difficult to quantify all the potential=20 > motivations for >=20 > s/motivations/scenarios yep. >=20 > > enterprise network teams to move to IPv6, there are some=20 > cases where > > an abstract description is possible. The document presents three > > example motivations as a general use case. This model=20 > can be used to >=20 > s/motivations/base scenarios=20 yep. >=20 > > define additional abstractions, for the Enterprise to define > > scenarios to fit their requirements. >=20 > s/scenarios/specific scenarios excellent. >=20 > > The first scenario assumes the Enterprise decides to=20 > deploy IPv6 in > > parallel with IPv4. The second scenario assumes the Enterprise > > decides to deploy IPv6 because of a specific set of=20 > applications the > > Enterprise wants to use over an IPv6 network. The third scenario > > assumes an Enterprise is building a new network or=20 > re-structuring an > > existing network and decides to deploy IPv6. The document then > > defines a set of characteristics that must be analyzed. =20 > The document > > then provides several scenario examples using the=20 > characteristics=20 > > to >=20 > s/several/three specific Yep. >=20 > > depict the requirements. These are common Enterprise=20 > deployment cases > > to depict the challenges for the Enterprise to=20 > transition a network > > to IPv6. >=20 > I think one "danger" we have here is that by generalising as=20 > we do later down the text, that the requirements become so=20 > generalised that the analysis can > apply any mechanism to any scenario :) I'm not sure whether that is > a real (or important) concern. I think it is an important concern and the hope is we fine tune the generalizations to be specific enough to keep a focused effort for the analysis. =20 >=20 > > The interoperation with legacy functions within the=20 > Enterprise will > > be required for all transition except possibly by a new=20 > network that > > will be IPv6 from inception. The network infrastructure=20 > components >=20 > Well, not maybe for scenario 2 below, because we are adding=20 > IPv6 for a specific application (let's say a specific IPv6=20 > p2p app like Napster6 :) and in that case we don't care to=20 > access legacy networks, as we are purely interested in the v6=20 > app, as the scenario states. This is good point about secenario 2 and good catch. >=20 > > will inform the Enterprise of key points of transition in their > > networks that require consideration for IPv6 deployment and > > transition. >=20 > I think "point of transition" is ambiguous - so see below we=20 > should define what you mean. Agreed in next release we will remove all references of "point of transition" it is here now to get folks to think points of transition and now its time to define them I personally agree with you. > =20 > > Using the scenarios, characteristics, and examples in=20 > the document an > > Enterprise can define a scenario. Understanding the=20 > legacy functions > > and network infrastructure components required, the=20 > Enterprise can > > determine the network operations required to deploy=20 > IPv6. The tools > =20 > The wording is confusing here: "using a scenario to define a=20 > scenario", so we need to write something else... do we mean: >=20 > Using the base scenarios, characteristics, and examples=20 > in the document=20 > an Enterprise can define its specific scenario requirements. Yes much better. >=20 > > Enterprise Network - An Enterprise Network is a=20 > network that has > > multiple links, a router connection to a > > Provider, and is actively managed by a > > network operations entity. >=20 > s/multiple/multiple internal Yes. >=20 > s/a router connection/one or more router connections > s/a Provider/one or more Providers > (since you mention multihoming in characteristics below) Yes. >=20 > Should we define "point of transition" and "characteristic"? =20 > I think it would help. Still a nice short set of definitions :) =20 I think point of trasition for a spec is going give us trouble but I do think defining characteristic is good idea. >=20 > > Three base scenarios are defined to capture the=20 > essential abstraction > > set for the Enterprise. Each scenario has assumptions and > > requirements. This is not an exhaustive set of=20 > scenarios, but a base > > set of general cases. >=20 > We might add another base scenario in Minneapolis but we must=20 > ensure that any such addition really adds value so we keep=20 > the doc as simple as possible. This has 100% consensus by the team. I agree. > =20 > > 3.1 Base Scenarios Defined > >=20 > > Scenario 1: Enterprise with an existing IPv4 network=20 > wants to deploy > > IPv6 in parallel with their IPv4 network. > >=20 > > **Note To V6ops WG: Would a network topology map be useful here? >=20 > I don't think such a map is necessary for any of the base scenarios. Thanks for that input. > =20 > However, by "in parallel" do you mean dual-stack=20 > infrastructure or separate=20 > infrastructure, or is that irrelevant? I think we need to explain what we mean in next release. But some nodes will be dual stack and some nodes will be IPv4. I don't think to many will be IPv6 only. >=20 > > Assumptions: The IPv4 characteristics have an equivalent in > > IPv6. >=20 > Where might they not do? I just wrote this one down as it came from last input. I think we need to discuss what this means as a team and be great if our WG colleagues would jump in on this specific too. I think it is vague and unclear. IPv6 will have functions that do not exist in IPv4 as one example. > =20 > > Requirements: Don't break IPv4 network characteristics > > assumptions with IPv6. IPv6 should be=20 > equivalent or > > "better" than the ones in IPv4, however, it is > > understood that IPv6 is not required to=20 > solve every > > single problem. >=20 > Maybe this could say "that IPv6 functionality may not be=20 > required, or feasible to deploy, on all parts of the=20 > Enterprise's infrastructure" ? Yes I like this much better. Note again I just copied this from input. So we may have to have some discussion but I support your suggestion. >=20 > > Scenario 2: Enterprise with an existing IPv4 network=20 > wants to deploy a > > set of particular IPv6 "applications"=20 > (application is > > voluntarily loosely defined here, e.g. peer=20 > to peer). > > The IPv6 deployment is limited to the=20 > minimum required to > > operate this set of applications. > > > > Assumptions: IPv6 software/hardware components for the=20 > application > > are available. >=20 > Hmmm. If the reason is to deploy an IPv6 application (e.g.=20 > p2p VoIP) the solution will depend on whether the host is=20 > dual-stack (IPv4/IPv6) or=20 > IPv6(-only). Clarify, or does it not matter? Well I cheated and admit it to all :---). Bringing IPv6 only into this complicates the discussion and eventual consensus for this work. I think in this case it does not matter in the node instance and the network instance if the IPv6 packet is delivered. But, what it affects is the transition mechanisms required if the node is IPv6 ONLY to speak with legacy IPv6 nodes. That is the one area where translation is required. =20 But does IPv6 only mean that the node simply does not have an IPv4 stack at all. I don't see that happening for a long time. I suggest we assume dual stack for this work and not IPv6 only. That for IPv6 ONLY a future addendum to this spec be written? What does the WG think about my suggestion above? Thanks. >=20 > > Requirements: Don't break IPv4 network operations. >=20 > That's always a requirement :) For "operations" read "functionality, > operation or security" maybe, and probably more beyond. Yep. But it was felt it needed to be said in the spec. >=20 > > Scenario 3: Enterprise deploying a new network or=20 > re-structuring an > > existing network, decides IPv6 is the basis=20 > for network > > communication. >=20 > Does this mean IPv6-only network infrastructure? Remember=20 > you have defined > IPv6 above as equal to IPv6-only, so is that what you mean here? > =20 > > Assumptions: Required IPv6 network components are available, or > > available over some defined timeline. >=20 > Again, do you really mean IPv6-only, or IPv6-capable? IPv6 Capable. I need to fix that above ok. >=20 > > Requirements: Interoperation and Coexistence with IPv4 network > > operations and applications are required for > > communications. >=20 > So is scenario 3 an IPv6-only network into which IPv6-only or=20 > dual-stack hosts may be deployed? If so maybe state that 3=20 > paragraphs up. IPv6 capable but will fix that above too. I want to start another specific thread on this for the WG to discuss to from your input. Good catch. > =20 > I think the four sets of characteristics below are fine to=20 > cover the basic requirements. Thanks. >=20 > > Characteristic 1 - Providers for External Network Operation > > - IPv4 existing address ownership (Provider based addresses vs. > > Provider independent addresses)? >=20 > And number of globally routable IPv4 addresses available? Yes. >=20 > > - Do ISPs offer IPv6 service? >=20 > By service do you mean native service, or tunnelled, or any=20 > service...? Any. But we should differentiate the two as it relates to what the Enterprise can do. >=20 > > Characteristic 3 - Enterprise IT Department Operations Analysis > > - Is inter-site communications required? >=20 > You have "one site vs multiple sites" in characteristic 1? Will fix I figured providers as plural implied "multiple".=20 >=20 > > - External IPv4 routing protocols used? >=20 > That one belongs in characteristic 1? Yes. >=20 > > - List of "network operation" software that may be=20 > impacted by IPv6? > > - DNS > > - Management (SNMP & ad-hoc tools) > > - Enterprise Network Servers > > - Mail Servers > > - High Availability Software for Nodes > > - Directory Services >=20 > - Other services (NTP, others...?) Lets add to the list but at some point we need to add at the end "etc.. etc..". >=20 > > - Are all these software functions upgradeable to IPv6? > > - If not upgradeable, then what are the workarounds? >=20 > - If not upgradeable, can an equivalent upgradeable=20 > software function=20 > be substituted for the one that is not upgradeable?=20 > (e.g. a different > directory service mechanism) This I think is to be done in the analysis spec?????????? >=20 > > Characteristics 4 - Enterprise Network Management System > > - Management of Transition Tools and Mechanisms? >=20 > This is an important area the WG needs to take on board. Yep. I think Management Scenarios could be its own spec? >=20 > > - What new considerations does IPv6 create for Network > > Management? >=20 > Does this affect the transition tool analysis, e.g. if=20 > RFC3041 means that IP-based authentication is no longer=20 > possible? I guess it may affect a=20 > specific implementation of a security policy? Yep. But what I was thinking here is what new problems does transition introduce onto the network of the enterprise? That list would be useful I think. Esp. in Ent Scenarios to feed Ent Analysis doc. >=20 > > This section presents a set of Base Scenario Examples=20 > and is not an > > exhaustive list of examples. These examples were=20 > selected to provide > > further clarity of Base Scenarios within an Enterprise of a less > > abstract nature. >=20 > I think these are now Specific Scenario Examples not Base=20 > ones? The answering of the characteristics against the base=20 > scenarios higher up in the document leads to these specific examples? Excellent. I knew this in the head but could not hit my fingers while editing. Thanks. > =20 > > A bank running a large ATM network supporting an order=20 > of magnitude > > number of transactions per second, with access to a=20 > central database > > on an external network from the ATM network: >=20 > "An order of magnitude number of transactions" is missing a=20 > word or two :) Well we don't have data to say numbers. Nor should we. We do need to say this better I was as Editor taking liberty to get the point across we need better wording yes. But trying to state hard facts is not good. > =20 > > - External connectivity not required. > > - Multiple sites connected by VPN. > > - Multiple sites connected by Native IP protocol. >=20 > Perhaps add that it may use Net10 addressing? We should not=20 > hide from the > Net10/ANT issues for transitioning networks. We have the=20 > Hinden draft on the way, although this example probably uses=20 > RFC1918 but not NAT :) Yes and was not hiding just missed it as I hate it so bad and needed the reminder :--) > =20 > > 4. Support for Legacy IPv4 Nodes and Applications >=20 > s/Nodes/Nodes, Services ? Yes. > =20 > > The Enterprise network will have to support the=20 > coexistence of IPv6 > > and IPv4, to support legacy IPv4 applications and nodes. The > > Enterprise user has the following choices for that coexistence to > > consider today. >=20 > Does this mean "of IPv6-only and IPv4-only"? This is what is=20 > implied by the definition of terms at the start of the=20 > document. Do we actually mean "IPv6-capable and=20 > IPv4-capable" or, in the language of the definitions,=20 > "IPv6, IPv4 and IPv4/IPv6" applications and nodes? I will fix all this in the doc to relay IPv6 capable. >=20 > > 4.3 IPv6 communicating with IPv4 > >=20 > > An IPv6 only node wants to communicate with an IPv4 only node. >=20 > Note the node can be IPv4/IPv6 but the application may be=20 > IPv4, e.g. if the source code is lost or the language it is=20 > written in has no IPv6 API? >=20 > So do we actually mean "node" or "application"? We probably=20 > mean "services > or applications on a node" as RPC, NIS, SMTP etc are services. Nope I was bringing out the case of an IPv6 stack only node. That should be changed. >=20 > > In cases where the IPv6 host cannot be a dual stack, in order to > > continue support of communications with IPv4 nodes an IPv4/v6 > > translator is required. Introduction of such translator=20 > will prevent > > usage of end-to-end security and application carrying embedded IP > > addressing information. >=20 > You could say the translator may be at the network, transport=20 > or application layer. We can add that but for this "reference" model document I don't think it matters? > =20 > > **Note to V6ops WG: Should we discuss porting of=20 > applications too in > > the legacy section? >=20 > I think this is done in the "application aspects" draft fine=20 > already, i.e. in draft-shin-v6ops-application-transition-01. I agree and we can point to this work too. > =20 > > 5. Network Infrastructure Requirements > >=20 > > The Enterprise will need to determine what network infrastructure > > components require enhancements or to be added for deployment of > > IPv6. This infrastructure will need to be analyzed and=20 > understood as > > a critical resource to manage. > >=20 > > 5.1 DNS > >=20 > > DNS will now have to support both IPv4 and IPv6 DNS=20 > records and the > > Enterprise will need to determine how the DNS is to be=20 > managed and > > accessed, and secured. > >=20 > > **Note to V6ops WG: Should we get into other DNS issues? >=20 > There are three categories of issues I think, i.e. >=20 > - standards: dns resolver discovery, 512-byte response format,=20 > reverse zone managemnt and dynamic dns >=20 > - transport: root servsers, OS supporting native lookup,=20 > and whether the > upstream ISPs filter the root space /48's >=20 > - registry: registering domains with IPv6 DNS servers Agree but is Enterprise Scenarios the only spec that needs to address that what about Umanaged, 3GPP, or ISP docs? =20 >=20 > Also, do you have control over your own DNS? This is important to state yes. >=20 > And is it important that reverse DNS lookup works, e.g. for=20 > sendmail to verify sender hosts? If so reverse population of=20 > statelessly autoconfiguring will be needed, and 6to4 use will=20 > be problematic? This is true for all scenario documents, is Enterprise work the only spec that has to do this or do we need a generic DNS transition document as Management etc... > =20 > > 5.2 Routing > >=20 > > IPv6/IPv4 routers should be monitored to ensure the router has > > sufficient storage for both IPv6 and IPv4 route tables. Existing > > network design principles to limit the number of routes in the > > network, such as prefix aggregation, become more=20 > critical with the > > addition of IPv6 to an existing IPv4 network. > >=20 > > **Note to V6ops WG: Above is example of additional text=20 > we could add > > to each component we list here. Are there other Routing issues? >=20 > Other issues are whether the upstream provider supports IPv6=20 > natively or offers transition aids, e.g. 6to4, site tunnel broker. Yes. > =20 > > 5.3 Autoconfiguration > >=20 > > IPv6 introduces the concept of stateless autoconfiguration in > > addition to statefull autoconfiguration. The enterprise=20 > will have to > > determine the best method of autoconfiguration, for=20 > their network. > >=20 > > **Note to V6ops WG: Should we get into other autoconfiguration > > issues? >=20 > Will the enterprise need IPv6 prefix delegation? I think so :--). But we should add that to the list too. >=20 > Will it need DHCPv6 forwarding? Do you mean relaying? > =20 > > 5.4 Security > >=20 > > Current existing mechanisms used for IPv4 to provide=20 > security need to > > be supported for IPv6 within the Enterprise. IPv6=20 > should create no > > new security concerns for IPv4. > >=20 > > **Note to V6ops WG: Should we get into other security issues? >=20 > I think Pekka's security draft could be cited:=20 > draft-savola-v6ops-security-overview-00 I want to not respond and need to do more in depth read of that spec. I think being paranoid is not good :--) (no refelection on Pekka's security draft I just think we live in a very dangerous world and thats life. Trying to correct that to far is not worth the time and one is better off to die :--)). Just kidding. I will reread Pekka's work. >=20 > Issues include backdoors for tunnels, handling firewall=20 > policy for end-to-end encryption, dual-stack possibly adding=20 > complexity to analysis, and DoS relay type attacks (e.g. 6to4 relays). Yes for sure. >=20 > > 5.5 Applications > >=20 > > Existing applications will need to be ported to support=20 > both IPv4 and > > IPv6. > >=20 > > **Note to V6ops WG: Should we get into other application issues? >=20 > Not beyond the shin-v6ops draft. Agreed. > =20 > > 5.6 Network Management > >=20 > > The addition of IPv6 and points of transition will need=20 > to be managed > > by the Enterprise network operations center. This will=20 > affect many > > components of the network and software required on nodes. > >=20 > > **Note to V6ops WG: Should we get into other Management issues? >=20 > Probably not. I agree. But we proabably need a network management draft of its own. > =20 > > 5.7 Address Planning > >=20 > > The address space within the Enterprise will need to be=20 > defined and > > coordinated with the routing topology of the Enterprise network. > >=20 > > **Note to V6ops WG: Should we get into other Address Planning=20 > > issues? >=20 > Would IPv4 and IPv6 subnets be congruent? I think parallel is more correct? >=20 > An advantage of IPv6 is that you are unlikely to ever need to=20 > resize the subnets (up or down). ERRRRRRRRRRRRRRRRR. Need to think about that. One could blow the bits to the left on a site boundary with sensors :--). >=20 > Available IPv4 address space affects (for example) the DSTM=20 > pool, NAT-PT, etc. Yes but that has to be in analysis but we should generically point to all this list. >=20 > Do we have address space independence from provider? I don't believe this is true at all? We do not even more so with IPv6 and I don't like that quite frankly ................... > =20 > > **Note to V6ops WG: What other components are we missing? >=20 > Here are some additional possible components: >=20 > 5.8 Multicast >=20 > Both from routing aspects, but also things like MLDv1/2=20 > snooping to help avoid traffic flooding. >=20 > If multicast is needed then some tools may not be useful,=20 > e.g. 6to4 (there was a draft on 6to4 and multicast, but it=20 > seemed to have died). We should add this yes. >=20 > 5.9 Service discovery mechanisms >=20 > The infrastructure may need to support many of these because=20 > there is little harmonisation of techniques in various standards, e.g. > - LDAP or NIS > - Well-known names > - Well-known addresses > - IPv4 or IPv6 anycast > - LLMNR > - DHCPv6 (Lite) > - SLP, etc Yes. >=20 >=20 > > 7. References >=20 > Maybe the applications draft (see above) and Pekka's transition=20 > architectures doc? (draft-savola-v6ops-transarch-01) And=20 > his security > doc: draft-savola-v6ops-security-overview-00 ? Yes. But want to reread Pekka's security overview ok. >=20 > There's also RFC1752 which we could either cite or state that we no=20 > longer use as a yardstick. It talked about transition goals like: > - incremental upgrade (hosts not routers) > - incremental deployment (routers) > - easy addressing (use dual-stack) > - low start-up costs (procure wisely so infra enabled) Good point. Yes. >=20 >=20 > Other general comments: > ----------------------- >=20 > What about preference of use of IPv4 or IPv6? Ouch. I fear a 1000 mail message debate. I suggest we avoid this and leave scenarios for the enterprise to have that debate when they deploy. OK. >=20 > How do we handle the "NAT is our policy" sites? We do need to add this as you stated above. But not get into email war. >=20 > Are IPv6-specific features out of scope... e.g. privacy=20 > extensions which may impact policy implementations like=20 > (weak) IP-based authentication? In the scenarios I think they are but will have to see once we start analysis. >=20 > What about remote IPv4 nodes wishing to access your site=20 > IPv6(-only) services? Do you deploy (say) NAT-PT yourself, or=20 > rely on the remote site to introduce=20 > its own tools? Maybe this is covered OK in 4.3, but we=20 > could explicitly > expand on it. We should have a reference in scenarios so this can be discussed in analysis. >=20 > What about use of existing "software functions" that may ease=20 > transition, e.g. if already using proxies like web, mail, etc=20 > already, or using VLANs? Possibly a footnote. But we should stay within the charter expertise of this IETF WG. >=20 > We should capture general transition tool requirements=20 > somewhere, e.g. a site depends on handling 100,000 remote=20 > transactions per hour, then any proxies, > translators, etc must be able to support that level. Maybe for sure in scenarios as long as it does not point to or suggest any specific mechanism ok. thanks /jim =20 >=20 >=20 > Tim >=20 >=20 From owner-v6ops@ops.ietf.org Fri Oct 24 00:40: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 AAA03013 for ; Fri, 24 Oct 2003 00:40:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACtfa-000LAx-Kb for v6ops-data@psg.com; Fri, 24 Oct 2003 04:35:26 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACtfY-000LAf-Ga for v6ops@ops.ietf.org; Fri, 24 Oct 2003 04:35:24 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C3F44FC7F for ; Fri, 24 Oct 2003 00:35:23 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Oct 2003 00:35:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: IPv6 Capable and IPv6 ONLY for Scenarios Date: Fri, 24 Oct 2003 00:35:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA181@tayexc13.americas.cpqcorp.net> Thread-Topic: IPv6 Capable and IPv6 ONLY for Scenarios Thread-Index: AcOZ6D9dDHQjGYFJSrKBmTfOLqwDdA== From: "Bound, Jim" To: X-OriginalArrivalTime: 24 Oct 2003 04:35:23.0554 (UTC) FILETIME=[3D3F8020:01C399E8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Folks, Want to do logic check here for IPv6 ONLY. IPv6 capable does not imply or preclude IPv6 ONLY. Does anyone disagree? IPv6 ONLY should only mean a node that has NO IPv4 stack to process IPv4 packets? To reference a network that is IPv6 capable can imply IPv4 is possible but not used or use is limited. Or IPv6 is not turned on or IPv6 is limited. Any objecttions to these assumptions or can others add useful clarifiations. thanks /jim From owner-v6ops@ops.ietf.org Fri Oct 24 00:50: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 AAA03197 for ; Fri, 24 Oct 2003 00:50:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACtrd-000LaI-OT for v6ops-data@psg.com; Fri, 24 Oct 2003 04:47:53 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACtrZ-000LZo-S4 for v6ops@ops.ietf.org; Fri, 24 Oct 2003 04:47:49 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6C39613962 for ; Fri, 24 Oct 2003 00:47:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Oct 2003 00:47:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Proposal : Common issues across Scenarios Design Team should be new work item Date: Fri, 24 Oct 2003 00:47:48 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA182@tayexc13.americas.cpqcorp.net> Thread-Topic: Proposal : Common issues across Scenarios Design Team should be new work item Thread-Index: AcOZ6fvi2gyhO0WFSseuz7uGJtxciA== From: "Bound, Jim" To: X-OriginalArrivalTime: 24 Oct 2003 04:47:49.0220 (UTC) FILETIME=[F9B31A40:01C399E9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Folks, We got some input to address this in DNS or that in DNS or address this for Mail or that for Mail for Enterprise work. These I am thinking common problems for all scenarios. How dynamic DNS updates work in secure manner over an IPv4 Tunnel, as example, is the same issue/resolution for Enterprise, 3GPP, ISP, and Unmanaged. Do we need to select out common scenario issues for any network and make that its own scenario document. This would also avoid having to identify these issues in the above spec work because the common scenarios spec would be first read or second read to define how one deploys or transtions to IPv6. Why do this: 1. This would speed up efforts to deliver the four scenarios documents. 2. It would support a focus for the common scenario issues. 3. ISP, 3GPP, and Umanaged have not put this in their specs for the most part thus it is no work for them. 4. Enterprise work does not become the designated v6ops dumping ground for common problems for application issues that are relevant to all scenarios. And this will slow down the process to complete the Enterprise. ISP scenarios face similar problem potentially. 5. Users of any scenario focus we need to create can learn the base common application or infrastructure scenarios common to any network definition scenario. Proposal: Begin a new design team and effort to work on the common IPv6 operational issues across any scenario that must be addressed (e.g. DNS, Porting, Mail). There are also probably common security issues for all scenarios in addition to the specific ones for each scenario work effort in v6ops. Comments? thanks /jim From owner-v6ops@ops.ietf.org Fri Oct 24 01:42: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 BAA04143 for ; Fri, 24 Oct 2003 01:42:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACueS-000O8e-M5 for v6ops-data@psg.com; Fri, 24 Oct 2003 05:38:20 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACueL-000O8M-CW for v6ops@ops.ietf.org; Fri, 24 Oct 2003 05:38:13 +0000 Received: from consulintel02 ([202.133.104.44]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 27-md50000000018.tmp for ; Fri, 24 Oct 2003 07:42:04 +0200 Message-ID: <0a1a01c399f1$525becb0$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Comments draft-palet-v6ops-proto41-nat-01.txt Date: Fri, 24 Oct 2003 13:40:19 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A17_01C39A34.5D62F890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 24 Oct 2003 07:42:04 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 202.133.104.44 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0A17_01C39A34.5D62F890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mariana, v02, was already posted, so most of you comments, I think are already = addressed, but I still don't see it published by the RFC editor. Anyway, = today I will post -03, so I'm addressing your comments also. See in-line my comments. Regards, Jordi ----- Original Message -----=20 From: mariana.nikolova@philips.com=20 To: JORDI PALET MARTINEZ=20 Cc: v6ops@ops.ietf.org=20 Sent: Thursday, October 23, 2003 3:31 PM Subject: Comments draft-palet-v6ops-proto41-nat-01.txt Hi Jordi,=20 my "last minutes" comments on your draft. Hope they are not "too late" = comments.=20 In general, I am very positive over the document. The remarks are = mainly for extra clarification!=20 General comment:=20 1) "NAT boxes" is very often used in the draft meaning actually = "IPv4-only NAT node". An IPv6/IPv4 node that is a 6to4 router implements = also NAT only for IPv4 packets. Then, it can be referred to as a NAT = boxes as well. However, no need to implement proto41 on this box = (although it can be and you mention this in the draft but then it's = overdone and rather confusing for the router producer what (6to4 or = proto41) and when (IPv4-only or IPv6/IPv4 node) to implement ). The = strong need for support of proto41 is in "IPv4-only NAT nodes" in order = to support IPv6 tunnels. That is why I recommend the use of "IPv4-only = NAT nodes" instead of "NAT boxes". Further see my remark in section 5.=20 [Jordi] Very good catch. Addressed. 2) Very often in the draft "this behavior" is used meaning = "forwarding protocol 41" or the nickname "proto41". Replacing the former = with the latter is more tangible and I recommend it.=20 [Jordi] Already addressed. Specific comments:=20 - Abstract=20 I agree with the Rute's comment here=20 [Jordi] Already addressed. 1. Introduction=20 1-2 paragraphs: Substitute with a short intro to the scene, e.g. =20 Nowadays homogeneous IPv4 private networks are massively deployed. The = first migration step from IPv4 to IPv6 for these networks is adding an = IPv6 node (or cluster of IPv6 nodes). In this case the IPv6 node = communicates with IPv6 peers in the public Internet via IPv6 packets = tunneled into IPv4 ones. Most of the existing solutions suppose that the = router of the private network is begin-/end-point of the tunnels. = Typical examples of such routers are 6to4 IPv6/IPv4 routers that have = already been commercially deployed. However, nowadays most of users have = IPv4-only NAT routers in their private networks and they are not willing = immediately to invest in a new router for whatever reasons, mostly = financial.=20 That is why in this draft we propose to make use of protocol 41 = forwarding in IPv4-only NAT routers. This mechanism allows IPv6 tunnels = and therefore facilitates the migration path from IPv4 to IPv6. =20 [Jordi] Already addressed. In my opinion this is a generic comment for = transition (not migration) in general, but we have already several = transition mechanism that don't rely on IPv6 routers, so I included a = "short" version of your text. 4 paragraph: revise, for example=20 The scenario illustrated above has been tested with several IPv4-only = NAT boxes/routers that have successfully established IPv6 tunnels = between tunnel clients in a private network and tunnel servers in the = public Internet. In the test we have used three well-known Tunnel Broker = implementations (BT, Freenet6 and TILAB) and routers from 6Bone, = Consulintel, Euro6IX and UPM networks.=20 [Jordi] Already addressed. 5 paragraph: This can --> This scenario can ..=20 [Jordi] Already addressed. 2. Rationale for this behavior --> Rationale for using protocol 41 = forwarding=20 [Jordi] Already addressed. 3. Behavior of different NAT types=20 I do not understand Rute's confusion here since Basic (or Traditional) = NAT, NAPT and Bidirectional (or two-way) NAT is commonly used = terminology.=20 [Jordi] My understanding is that she is reading another draft = regarding NAT. 5 paragraph in 3.2: This can also be combined with basic NAT. -->This = port forwarding is often combined with basic NAT leading to NAPT.=20 [Jordi] Already addressed. 2 paragraph in 3.3: Revision required. What you wanna say is written = so compact that it is rather getting non-understandable.=20 [Jordi] Already addressed. 1 paragraph in 3.4: N.B. At the beginning of this section make clear = that "configurable" NAT can be either 3.1 or 3.2 or 3.3. Each of the = first three types can act as a fully bidirectional NAT for 41-packets if = it is configurable.=20 [Jordi] Already addressed. 4. Applicability=20 1 paragraph:=20 inside-to-outside sessions outgoing sessions, outside-to-inside = sessions incoming sessions=20 So, this is consistent with the terminology you use later.=20 If my first general comment is applied here the Rute's remark is = resolved.=20 [Jordi] Already addressed. 6 paragraph: the application of this procedure --> the application of = 41-packets forwarding=20 [Jordi] Already addressed. 7 paragraph: move to Introduction and consider language revision=20 [Jordi] Already addressed. 8 paragraph: move to Introduction after the intro paragraph I = suggested.=20 [Jordi] Already addressed. 5. NAT design consideration --> NAT design consideration and = recommendations=20 I agree with the Rute's first comment here.=20 [Jordi] Already addressed. 3 paragraph: confusing the reader and contradicting the general idea. = I would rather say something like=20 The proto41 and 6to4 are complementary transition mechanisms that = facilitate the migration from IPv4 to IPv6.These two mechanisms are in = general applicable in different migration steps. The proto41 mechanism = is mostly relevant and applicable for IPv4-only NAT routers whereas 6to4 = mechanism is mostly relevant and applicable for IPv6/IPv4 routers. = Notice that an IPv6/IPv4 router that is 6to4 enabled and implements NAT = only for IPv4 packets does not need to be proto41 enabled.=20 [Jordi] Already addressed. Some extra conclusions that you may add to make this section complete: = =B7 The proto41 adds an enhanced feature to the IPv4-only NAT = routers, namely enabling them to forward IPv6 packets encapsulated into = IPv4 ones, i.e., allowing for IPv6 tunneling.=20 =B7 The proto41 completely preserves the users investments in = the existing IPv4 networks. This is essential for gaining market = acceptance.=20 =B7 The proto41 allows for gradual migration from IPv4 to IPv6 = networks making the migration path easy and acceptable for the users. =20 Greetings,=20 Mariana = -------------------------------------------------------------------------= ---------------------------------------- Dr. Mariana Nikolova =20 Philips Research Laboratories Eindhoven (IST/SwA/DS) Prof. Holstlaan 4, 5656 AA, Eindhoven, The Netherlands room: WDC 1.35, phone: +31-40-27-45455 e-mail: mariana.nikolova@philips.com=20 = -------------------------------------------------------------------------= ---------------------------------------- ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ------=_NextPart_000_0A17_01C39A34.5D62F890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mariana,
 
v02, was already posted, so most of you = comments, I=20 think are already addressed, but I still don't see it published by the = RFC=20 editor. Anyway, today I will post -03, so I'm addressing your comments=20 also.
 
See in-line my comments.
 
Regards,
Jordi
----- Original Message -----
From:=20 mariana.nikolova@philips.com= =20
Sent: Thursday, October 23, = 2003 3:31=20 PM
Subject: Comments=20 draft-palet-v6ops-proto41-nat-01.txt


Hi Jordi, =

my "last minutes" comments on your draft. = Hope they are=20 not "too late" comments.
In general, I=20 am very positive over the document. The remarks are mainly for extra=20 clarification!

General comment:=20

1)     =  =20  "NAT boxes" is very often used in the draft meaning actually = "IPv4-only=20 NAT node". An IPv6/IPv4 node that is a 6to4 router implements also NAT = only=20 for IPv4 packets. Then, it can be referred to as a NAT boxes as well. = However,=20 no need to implement proto41 on this box (although it can be and you = mention=20 this in the draft but then it's overdone and rather confusing for the = router=20 producer what (6to4 or proto41) and when (IPv4-only or IPv6/IPv4 node) = to=20 implement ). The strong need for support of proto41 is in "IPv4-only = NAT=20 nodes" in order to support IPv6 tunnels. That is why I recommend the = use of=20 "IPv4-only NAT nodes" instead of "NAT boxes". Further see my remark in = section=20 5.
[Jordi] Very good catch.=20 Addressed.

2)       =  Very often=20 in the draft "this behavior" is used meaning "forwarding protocol 41" = or the=20 nickname "proto41". Replacing the former with the latter is more = tangible and=20 I recommend it.
[Jordi] Already = addressed.

Specific comments: =

- Abstract
I=20 agree with the Rute's comment here
[Jordi] Already = addressed.

1. Introduction
1-2 paragraphs: Substitute with a short intro to the scene, = e.g.=20  

Nowadays=20 homogeneous IPv4 private networks are massively deployed. The first = migration=20 step from IPv4 to IPv6 for these networks is adding an IPv6 node (or = cluster=20 of IPv6 nodes). In this case the IPv6 node communicates with IPv6 = peers in the=20 public Internet via IPv6 packets tunneled into IPv4 ones. Most of the = existing=20 solutions suppose that the router of the private network is = begin-/end-point=20 of the tunnels. Typical examples of such routers are 6to4 IPv6/IPv4 = routers=20 that have already been commercially deployed. However, nowadays most = of users=20 have IPv4-only NAT routers in their private networks and they are not = willing=20 immediately to invest in a new router for whatever reasons, mostly=20 financial.
That is why in=20 this draft we propose to make use of protocol 41 forwarding in = IPv4-only NAT=20 routers. This mechanism allows IPv6 tunnels and therefore facilitates = the=20 migration path from IPv4 to IPv6.  
[Jordi] Already addressed. In my = opinion this is=20 a generic comment for transition (not migration) in general, but = we have=20 already several transition mechanism that don't rely on IPv6 routers, = so I=20 included a "short" version of your text.

4 paragraph: revise, for example
The scenario illustrated above has been tested = with several=20 IPv4-only NAT boxes/routers that have successfully established IPv6 = tunnels=20 between tunnel clients in a private network and tunnel servers in the = public=20 Internet. In the test we have used three well-known Tunnel Broker=20 implementations (BT, Freenet6 and TILAB) and routers from 6Bone, = Consulintel,=20 Euro6IX and UPM networks.
[Jordi] Already = addressed.

5 paragraph: This can --> =  This scenario can .. =
[Jordi] Already = addressed.

2. Rationale for this behavior =  --> = Rationale for=20 using protocol 41 forwarding
[Jordi] Already = addressed.

3. Behavior of different NAT = types=20
I do not understand Rute's = confusion here=20 since Basic (or Traditional) NAT, NAPT and Bidirectional (or two-way) = NAT is=20 commonly used terminology.
[Jordi] My understanding is that she = is reading=20 another draft regarding NAT.

5=20 paragraph in 3.2: This can also be combined with basic NAT. =  -->This port=20 forwarding is often combined with basic NAT leading to NAPT. =
[Jordi] Already addressed.

2 paragraph in 3.3: Revision = required.=20 What you wanna say is written so compact that it is rather getting=20 non-understandable.
[Jordi] = Already=20 addressed.

1 paragraph in 3.4: N.B. At = the=20 beginning of this section make clear that "configurable" NAT can be = either 3.1=20 or 3.2 or 3.3. Each of the first three types can act as a fully = bidirectional=20 NAT for 41-packets if it is configurable.
[Jordi] Already addressed.

4. = Applicability=20

1 paragraph:
inside-to-outside sessions  outgoing sessions, outside-to-inside sessions  incoming sessions
So,=20 this is consistent with the terminology you use later. =
If my first general comment is applied here = the Rute's=20 remark is resolved.
[Jordi] = Already=20 addressed.

6 paragraph: the application = of this=20 procedure  --> the=20 application of 41-packets forwarding
[Jordi] Already addressed.

7 paragraph: move to = Introduction and=20 consider language revision
[Jordi] Already=20 addressed.

8 paragraph: move to = Introduction after=20 the intro paragraph I suggested.
[Jordi]=20 Already addressed.


5. NAT design = consideration=20  -->=20 NAT design consideration and recommendations =

I agree with the Rute's first comment here. =
[Jordi] Already=20 addressed.

3 paragraph: confusing the reader and = contradicting the=20 general idea. I would rather say something like

The proto41 and 6to4 are = complementary=20 transition mechanisms that facilitate the migration from IPv4 to = IPv6.These=20 two mechanisms are in general applicable in different migration steps. = The=20 proto41 mechanism is mostly relevant and applicable for IPv4-only NAT = routers=20 whereas 6to4 mechanism is mostly relevant and applicable for IPv6/IPv4 = routers. Notice that an IPv6/IPv4 router that is 6to4 enabled and = implements=20 NAT only for IPv4 packets does not need to be proto41 enabled. =
[Jordi] Already = addressed.

Some extra conclusions that you may add to = make this=20 section complete:

=B7  =20      The proto41=20 adds an enhanced feature to the IPv4-only NAT routers, namely enabling = them to=20 forward IPv6 packets encapsulated into IPv4 ones, i.e., allowing for = IPv6=20 tunneling.
=B7 =    =20    The = proto41=20 completely preserves the users investments in the existing IPv4 = networks. This=20 is essential for gaining market acceptance.
=B7        The proto41 allows for gradual migration from = IPv4 to IPv6=20 networks making the migration path easy and acceptable for the users.=20  


Greetings,=20 =
Mariana
----------------------------------------------------------= -------------------------------------------------------
Dr.=20 Mariana Nikolova    
Philips Research Laboratories = Eindhoven=20 (IST/SwA/DS)
Prof. Holstlaan 4, 5656 AA, Eindhoven, The=20 Netherlands
room: WDC 1.35,     phone: = +31-40-27-45455
e-mail:=20 mariana.nikolova@philips.com=20 =
---------------------------------------------------------------------= --------------------------------------------

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ------=_NextPart_000_0A17_01C39A34.5D62F890-- From owner-v6ops@ops.ietf.org Fri Oct 24 03:55:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20321 for ; Fri, 24 Oct 2003 03:55:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACwjS-0003fU-OQ for v6ops-data@psg.com; Fri, 24 Oct 2003 07:51:38 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACwjM-0003f4-AO for v6ops@ops.ietf.org; Fri, 24 Oct 2003 07:51:32 +0000 Received: from consulintel02 ([202.133.104.44]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 30-md50000000021.tmp for ; Fri, 24 Oct 2003 09:55:26 +0200 Message-ID: <007b01c39a03$f3f03150$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: draft-palet-v6ops-proto41-nat-03.txt Date: Fri, 24 Oct 2003 15:53:41 +0800 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 24 Oct 2003 09:55:26 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 202.133.104.44 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've announced send this document to the editor, but as it seems is taking long to be uploaded, a copy is available at: http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-proto41-nat-03.txt Hope to get any comments. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Oct 24 03: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 DAA20385 for ; Fri, 24 Oct 2003 03:58:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACwnk-0003r5-Ty for v6ops-data@psg.com; Fri, 24 Oct 2003 07:56:04 +0000 Received: from [128.176.188.113] (helo=batch15.uni-muenster.de) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACwnh-0003qm-3M for v6ops@ops.ietf.org; Fri, 24 Oct 2003 07:56:01 +0000 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch15.uni-muenster.de (Postfix) with ESMTP id 4130A1042 for ; Fri, 24 Oct 2003 09:55:20 +0200 (MES) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id B1346312EF for ; Fri, 24 Oct 2003 09:55:19 +0200 (CEST) Received: from kummerog.uni-muenster.de (KUMMEROG.UNI-MUENSTER.DE [128.176.184.156]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id F1F5E312F0 for ; Fri, 24 Oct 2003 09:55:18 +0200 (CEST) Subject: Re: IPv6 Capable and IPv6 ONLY for Scenarios From: "Christian Strauf (JOIN)" To: v6ops@ops.ietf.org In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA181@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B047CA181@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-15 Organization: JOIN-Team, WWU-Muenster Message-Id: <1066982159.23382.37.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 24 Oct 2003 09:55:59 +0200 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Jim > IPv6 capable does not imply or preclude IPv6 ONLY. Does anyone > disagree? This is the way it should be ideally. I've seen cases though where an IPv6 capable OS and also IPv6 capable applications do not work in IPv6 only environments. > IPv6 ONLY should only mean a node that has NO IPv4 stack to process IPv4 > packets? My impression is that in a lot of cases it makes sense to clearly differentiate between IPv6 only stack and IPv6 only connectivity (sometimes you can see people talking about IPv6 only hosts where the hosts are dual-stacked but have IPv6 only connectivity) because pinning IPv6 to either the stack or the connectivity can be ambiguous. In some transition scenarios it makes quite a difference if you have a dual-stack host with an IPv6 only connection or a IPv6 only stack host with an IPv6 only connection. > To reference a network that is IPv6 capable can imply IPv4 is possible > but not used or use is limited. Or IPv6 is not turned on or IPv6 is > limited. At the moment my understanding is that the last case (IPv6 is limited) is meant when talking about an IPv6 capable network and only the number of limitations varies from network to network. If IPv4 and IPv6 is equally well supported ("fully IPv6 capable network"), one would rather talk about dual-stack networks, wouldn't one? Just my 2-¤-cents. Christian -- JOIN - IP Version 6 in the WiN Christian Strauf A DFN project Westfälische Wilhelms-Universität Münster http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung Team: join@uni-muenster.de Röntgenstrasse 9-13 Priv: strauf@uni-muenster.de D-48149 Münster / Germany GPG-/PGP-Key-ID: 1DFAAA9A Fon: +49 251 83 31639, Fax: +49 251 83 31653 From owner-v6ops@ops.ietf.org Fri Oct 24 04:15:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20715 for ; Fri, 24 Oct 2003 04:15:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACx3a-0004do-FM for v6ops-data@psg.com; Fri, 24 Oct 2003 08:12:26 +0000 Received: from [3ffe:805::230:48ff:fe22:6a53] (helo=karoshi.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACx3Y-0004dZ-Ef for v6ops@ops.ietf.org; Fri, 24 Oct 2003 08:12:24 +0000 Received: (from bmanning@localhost) by karoshi.com (8.11.6/8.11.6 - yeah right) id h9O8CLW11514; Fri, 24 Oct 2003 01:12:21 -0700 From: bmanning@karoshi.com Message-Id: <200310240812.h9O8CLW11514@karoshi.com> Subject: Re: IPv6 Capable and IPv6 ONLY for Scenarios To: jim.bound@hp.com (Bound, Jim) Date: Fri, 24 Oct 2003 01:12:21 -0700 (PDT) Cc: v6ops@ops.ietf.org In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA181@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at Oct 24, 2003 12:35:23 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Folks, > > Want to do logic check here for IPv6 ONLY. > > IPv6 capable does not imply or preclude IPv6 ONLY. Does anyone > disagree? > > IPv6 ONLY should only mean a node that has NO IPv4 stack to process IPv4 > packets? one could make the argument that this is a correct statement but it may be overly restrictive. practically, there is no distinction between "no ipv4 stack" and "no interface w/ ipv4 enabled" > > To reference a network that is IPv6 capable can imply IPv4 is possible > but not used or use is limited. Or IPv6 is not turned on or IPv6 is > limited. > > Any objecttions to these assumptions or can others add useful > clarifiations. > > thanks > /jim > From owner-v6ops@ops.ietf.org Fri Oct 24 04:17: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 EAA20847 for ; Fri, 24 Oct 2003 04:17:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACx6X-0004ly-VG for v6ops-data@psg.com; Fri, 24 Oct 2003 08:15:29 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACx6V-0004le-Dt for v6ops@ops.ietf.org; Fri, 24 Oct 2003 08:15:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9O8FOh20950; Fri, 24 Oct 2003 11:15:24 +0300 Date: Fri, 24 Oct 2003 11:15:24 +0300 (EEST) From: Pekka Savola To: "Christian Strauf (JOIN)" cc: v6ops@ops.ietf.org Subject: Re: IPv6 Capable and IPv6 ONLY for Scenarios In-Reply-To: <1066982159.23382.37.camel@kummerog.uni-muenster.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 24 Oct 2003, Christian Strauf (JOIN) wrote: > > IPv6 ONLY should only mean a node that has NO IPv4 stack to process IPv4 > > packets? > > My impression is that in a lot of cases it makes sense to clearly > differentiate between IPv6 only stack and IPv6 only connectivity [...] Agreed -- there is a potential for confusion here. I'm not sure whether it makes sense to try to define and ratify exact semantics here, but at least the terminology used should be made clear. (pretty much agree with other points as well -- I also think that "dual-stack network" is closer, and in a way more honest way or saying that the network is mostly (or fully) IPv6 capable) -- 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 Oct 24 05:22: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 FAA22325 for ; Fri, 24 Oct 2003 05:22:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACy5J-0007dN-KF for v6ops-data@psg.com; Fri, 24 Oct 2003 09:18:17 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACy5F-0007ct-Bk for v6ops@ops.ietf.org; Fri, 24 Oct 2003 09:18:13 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9O9I8521665; Fri, 24 Oct 2003 12:18:08 +0300 Date: Fri, 24 Oct 2003 12:18:07 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: Re: Proposal : Common issues across Scenarios Design Team should be new work item In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA182@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thanks for the proposal. We'll take it in the consideration. There have been a bit similar activities in the past, and a few others in the pipeline (examples: the NAT-PT applicability work, the unmanaged connectivity document), but these have been specific rather than generic documents. A few personal initial thoughts below. On Fri, 24 Oct 2003, Bound, Jim wrote: > We got some input to address this in DNS or that in DNS or address this > for Mail or that for Mail for Enterprise work. These I am thinking > common problems for all scenarios. How dynamic DNS updates work in > secure manner over an IPv4 Tunnel, as example, is the same > issue/resolution for Enterprise, 3GPP, ISP, and Unmanaged. Right. It would seem to make sense to bundle certain kinds of things together. Of course, it would be useful to have a couple of specific examples on the table to see what kind of activities would be needed. That is, there are often similar activity (e.g. on DNS), but the actual perspective may be entirely different (more of this at the end of this mail). A potential downside of this may be that the "common scenarios" might lose the focus of the scenarios. > 1. This would speed up efforts to deliver the four scenarios documents. This is possible. It might also mean that the scenarios documents themselves could be rather compact and would have to wait for the common scenarios document. The question here is whether the four scenarios documents could stand on their own and progress independently of the common scenarios. I.e., I think it would be useful to try to identify whether this "common" work would be additional text, clarification and suggestions -- and the original document would still contain a very short summary of the issue -- or whether the common work would replace portions of the scenarios documents. > 4. Enterprise work does not become the designated v6ops dumping ground > for common problems for application issues that are relevant to all > scenarios. And this will slow down the process to complete the > Enterprise. ISP scenarios face similar problem potentially. This is a valid concern, and we should try to avoid this. We've tried avoiding this (at least at this point) in ISP by omitting some details, but they could be useful later on, or separately analyzed.. so it's difficult to say. > Proposal: Begin a new design team and effort to work on the common IPv6 > operational issues across any scenario that must be addressed (e.g. DNS, > Porting, Mail). There are also probably common security issues for all > scenarios in addition to the specific ones for each scenario work effort > in v6ops. To be able to get a better idea what this would entail, it would probably make sense to try to summarize a bit more detailed "requirements" for these common scenarios (e.g., which parts of DNS need to be handled like this, what are the issues in mail handling, etc.). Without a clear "charter for the work", it'd be difficult to trying to figure out the best way to solve the problem. One thing to be kept in mind here is that these "common scenarios" could be either descriptions on how you go about doing things in general (like itojun's IPv6 SMTP document from IPv6 WG), or targeted at the scenarios identified in the scenarios documents. If there is a disconnect here, we could be down the rathole of "transition mechanisms without scenarios". That is, either the primary purpose of the documents is dissemination of information how one could go about deploying IPv6 (highly useful), or identifying mechanisms or protocol actions needed for the deployment (when the connection the scenarios themselves must be clearer). -- 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 Oct 24 05:48:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22967 for ; Fri, 24 Oct 2003 05:48:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACyWC-0008ud-4Q for v6ops-data@psg.com; Fri, 24 Oct 2003 09:46:04 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACyW7-0008uN-Vf for v6ops@ops.ietf.org; Fri, 24 Oct 2003 09:46:00 +0000 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA28007 for ; Fri, 24 Oct 2003 10:45:58 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA01504 for ; Fri, 24 Oct 2003 10:45:58 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h9O9jw503670 for v6ops@ops.ietf.org; Fri, 24 Oct 2003 10:45:58 +0100 Date: Fri, 24 Oct 2003 10:45:58 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: IPv6 Capable and IPv6 ONLY for Scenarios Message-ID: <20031024094558.GF2210@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1066982159.23382.37.camel@kummerog.uni-muenster.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Oct 24, 2003 at 11:15:24AM +0300, Pekka Savola wrote: > On Fri, 24 Oct 2003, Christian Strauf (JOIN) wrote: > > > IPv6 ONLY should only mean a node that has NO IPv4 stack to process IPv4 > > > packets? > > > > My impression is that in a lot of cases it makes sense to clearly > > differentiate between IPv6 only stack and IPv6 only connectivity [...] > > Agreed -- there is a potential for confusion here. I'm not sure whether > it makes sense to try to define and ratify exact semantics here, but at > least the terminology used should be made clear. I think that there are many "IPv6 only" testbeds running Linux, BSD etc where you only configure IPv6, and only use IPv6 connectivity, despite IPv4 being present but not enabled. So what Pekka says is fine by me "dual stack with only IPv6 enabled" (or perhaps more accurately "hybrid stack"). While innovative new, really IPv6 only devices may emerge soon, there's little chance we'll see, for example, "Windows v6" without any IPv4 support for a long, long time. The question is really what is enabled for comms and what the apps actually use. It would be nice to have common agreed language to use in all v6ops (and wider) IETF docs. Tim From owner-v6ops@ops.ietf.org Fri Oct 24 06:06: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 GAA23388 for ; Fri, 24 Oct 2003 06:06:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACyme-0009mi-D0 for v6ops-data@psg.com; Fri, 24 Oct 2003 10:03:04 +0000 Received: from [161.114.112.27] (helo=zdemail03.zdem.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACyma-0009mK-W4 for v6ops@ops.ietf.org; Fri, 24 Oct 2003 10:03:01 +0000 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63]) by zdemail03.zdem.compaq.com (Postfix) with ESMTP id 96FD81075; Fri, 24 Oct 2003 12:02:59 +0200 (CEST) Received: from vbeexc02.emea.cpqcorp.net ([16.188.146.229]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 24 Oct 2003 12:02:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal : Common issues across Scenarios Design Team should be new work item Date: Fri, 24 Oct 2003 12:02:54 +0200 Message-ID: <06CAA4D3753C53408D2CE6340B6844420372226B@vbeexc02.emea.cpqcorp.net> Thread-Topic: Proposal : Common issues across Scenarios Design Team should be new work item Thread-Index: AcOaEI5JzqGD+9r/Sa2UX3hD+997bgABBOww From: "Pouffary, Yanick" To: "Pekka Savola" , "Bound, Jim" Cc: X-OriginalArrivalTime: 24 Oct 2003 10:02:58.0429 (UTC) FILETIME=[00776AD0:01C39A16] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka The list of 'subjects' transition related issues we came up with is: - DNS=20 - Application=20 - Security=20 - Transition tool management=20 - Possibly Stateless/Stateful policy interactions - others? We do not expect everything to belong to this WG for sure.=20 BTW individual documents have already been written for some of these subjects like the one for application draft-shin-v6ops-application-transition-01. This activity would not take away from the scenarios document it would help avoiding each document to have to cover these 'subjects' in full depth. We believe this activity should be done in parallel. Yanick -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Friday, October 24, 2003 11:18 AM To: Bound, Jim Cc: v6ops@ops.ietf.org Subject: Re: Proposal : Common issues across Scenarios Design Team should be new work item Hi, Thanks for the proposal. We'll take it in the consideration. There have been a bit similar activities in the past, and a few others in the pipeline (examples: the NAT-PT applicability work, the unmanaged connectivity document), but these have been specific rather than generic documents. A few personal initial thoughts below. On Fri, 24 Oct 2003, Bound, Jim wrote: > We got some input to address this in DNS or that in DNS or address this > for Mail or that for Mail for Enterprise work. These I am thinking > common problems for all scenarios. How dynamic DNS updates work in > secure manner over an IPv4 Tunnel, as example, is the same > issue/resolution for Enterprise, 3GPP, ISP, and Unmanaged. Right. It would seem to make sense to bundle certain kinds of things=20 together. Of course, it would be useful to have a couple of specific examples on the=20 table to see what kind of activities would be needed. That is, there are=20 often similar activity (e.g. on DNS), but the actual perspective may be=20 entirely different (more of this at the end of this mail). A potential downside of this may be that the "common scenarios" might lose the focus of the scenarios. > 1. This would speed up efforts to deliver the four scenarios documents. This is possible. It might also mean that the scenarios documents=20 themselves could be rather compact and would have to wait for the common scenarios document. The question here is whether the four scenarios=20 documents could stand on their own and progress independently of the=20 common scenarios. I.e., I think it would be useful to try to identify whether this "common" =20 work would be additional text, clarification and suggestions -- and the original document would still contain a very short summary of the issue -- or whether the common work would replace portions of the scenarios documents. > 4. Enterprise work does not become the designated v6ops dumping ground > for common problems for application issues that are relevant to all > scenarios. And this will slow down the process to complete the > Enterprise. ISP scenarios face similar problem potentially. This is a valid concern, and we should try to avoid this. We've tried avoiding this (at least at this point) in ISP by omitting some details, but they could be useful later on, or separately analyzed.. so it's=20 difficult to say. =20 > Proposal: Begin a new design team and effort to work on the common IPv6 > operational issues across any scenario that must be addressed (e.g. DNS, > Porting, Mail). There are also probably common security issues for all > scenarios in addition to the specific ones for each scenario work effort > in v6ops. To be able to get a better idea what this would entail, it would probably make sense to try to summarize a bit more detailed "requirements" for these common scenarios (e.g., which parts of DNS need to be handled like this, what are the issues in mail handling, etc.). Without a clear "charter for the work", it'd be difficult to trying to figure out the best way to solve the problem. One thing to be kept in mind here is that these "common scenarios" could be either descriptions on how you go about doing things in general (like itojun's IPv6 SMTP document from IPv6 WG), or targeted at the scenarios=20 identified in the scenarios documents. If there is a disconnect here, we=20 could be down the rathole of "transition mechanisms without scenarios". That is, either the primary purpose of the documents is dissemination of information how one could go about deploying IPv6 (highly useful), or identifying mechanisms or protocol actions needed for the deployment (when the connection the scenarios themselves must be clearer). --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 24 06:25: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 GAA23909 for ; Fri, 24 Oct 2003 06:25:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ACz4a-000AcI-82 for v6ops-data@psg.com; Fri, 24 Oct 2003 10:21:36 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ACz4X-000Ac1-B5 for v6ops@ops.ietf.org; Fri, 24 Oct 2003 10:21:33 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9OALUm22276; Fri, 24 Oct 2003 13:21:30 +0300 Date: Fri, 24 Oct 2003 13:21:29 +0300 (EEST) From: Pekka Savola To: "Pouffary, Yanick" cc: "Bound, Jim" , Subject: RE: Proposal : Common issues across Scenarios Design Team should be new work item In-Reply-To: <06CAA4D3753C53408D2CE6340B6844420372226B@vbeexc02.emea.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, A few additional personal thoughts below. On Fri, 24 Oct 2003, Pouffary, Yanick wrote: > The list of 'subjects' transition related issues we came up with is: > - DNS > - Application > - Security > - Transition tool management > - Possibly Stateless/Stateful policy interactions > - others? Thanks. Do you (yet) have a better picture of what in particular with these subjects would profit from the discussion (just trying to be explicit so that folks have the same idea what we'd be talking about in practice)? Or would you mean generic documents like, "how to do DNS in IPv4/IPv6 environments"? As I see it, there are at least a couple of reasons when additional work might be useful: 1) when the work touches several scenarios and is controversial, it may make sense to try to gain consensus on it in just one, separate document, and: a) wait and feed the results back, b) proceed without the controversial issue (raises the question whether the usefulness of the document is impaired) 2) when the subject itself is at some form of consensus, but would use to be spelled out more, and maybe generalized a bit (the list is not exclusive, but these came from the top of my head.) 1) can't typically be completely done in parallel, while 2) can. In this field, especially the item "transition tool management" may be problematic, as the scenarios may not be useful without it, and it may be a potential source of a lot of debate. > This activity would not take away from the scenarios document it would > help avoiding each document to have to cover these 'subjects' in full > depth. Ok. > We believe this activity should be done in parallel. Good to hear. -- 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 Oct 24 09:54: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 JAA00561 for ; Fri, 24 Oct 2003 09:54:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD2KE-000KbU-JG for v6ops-data@psg.com; Fri, 24 Oct 2003 13:49:58 +0000 Received: from [200.153.64.2] (helo=mail.internetbrasil.net) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AD2K9-000Kb5-8w for v6ops@ops.ietf.org; Fri, 24 Oct 2003 13:49:53 +0000 Received: (qmail 9867 invoked by uid 89); 24 Oct 2003 13:45:59 -0000 Received: from unknown (HELO ipv6brspw2k) (robson.oliveira@ipv6dobrasil.com.br@200.158.204.84) by 0 with SMTP; 24 Oct 2003 13:45:59 -0000 From: "Robson Oliveira" To: "Tim Chown" Cc: Subject: RE: IPv6 Capable and IPv6 ONLY for Scenarios Date: Fri, 24 Oct 2003 11:48:31 -0200 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <20031024094558.GF2210@login.ecs.soton.ac.uk> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim, For sure "Windows v6" without any IPv4 support for a long, long time, but we could manager the DNS to answer only v6 to conclude our objectives: "IPv6 only connectivity". Robson -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Tim Chown Sent: Friday, October 24, 2003 7:46 AM To: v6ops@ops.ietf.org Subject: Re: IPv6 Capable and IPv6 ONLY for Scenarios On Fri, Oct 24, 2003 at 11:15:24AM +0300, Pekka Savola wrote: > On Fri, 24 Oct 2003, Christian Strauf (JOIN) wrote: > > > IPv6 ONLY should only mean a node that has NO IPv4 stack to process IPv4 > > > packets? > > > > My impression is that in a lot of cases it makes sense to clearly > > differentiate between IPv6 only stack and IPv6 only connectivity [...] > > Agreed -- there is a potential for confusion here. I'm not sure whether > it makes sense to try to define and ratify exact semantics here, but at > least the terminology used should be made clear. I think that there are many "IPv6 only" testbeds running Linux, BSD etc where you only configure IPv6, and only use IPv6 connectivity, despite IPv4 being present but not enabled. So what Pekka says is fine by me "dual stack with only IPv6 enabled" (or perhaps more accurately "hybrid stack"). While innovative new, really IPv6 only devices may emerge soon, there's little chance we'll see, for example, "Windows v6" without any IPv4 support for a long, long time. The question is really what is enabled for comms and what the apps actually use. It would be nice to have common agreed language to use in all v6ops (and wider) IETF docs. Tim From owner-v6ops@ops.ietf.org Fri Oct 24 09:55: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 JAA00586 for ; Fri, 24 Oct 2003 09:55:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD2NE-000Kk2-IL for v6ops-data@psg.com; Fri, 24 Oct 2003 13:53:04 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD2N8-000Kjl-Kt for v6ops@ops.ietf.org; Fri, 24 Oct 2003 13:52:58 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id AE0B011372; Fri, 24 Oct 2003 09:52:57 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 24 Oct 2003 09:52:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C39A36.20F98DD5" Subject: RE: IPv6 Capable and IPv6 ONLY for Scenarios Date: Fri, 24 Oct 2003 09:52:56 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122143@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: yes Thread-Topic: IPv6 Capable and IPv6 ONLY for Scenarios Thread-Index: AcOaFBLpdrvsW3GeReqPeFsypeK6QwAIUkqw From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 24 Oct 2003 13:52:57.0384 (UTC) FILETIME=[2148DA80:01C39A36] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C39A36.20F98DD5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable What I will do Tim is listen to all inputs till next week on this thread and then send out a new message to define what this means as part II to hear if WG has issue. Also I agree hybrid is far better than dual stack as dual stack is a misnomer WG please see PDF attachment.=20 thanks /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown > Sent: Friday, October 24, 2003 5:46 AM > To: v6ops@ops.ietf.org > Subject: Re: IPv6 Capable and IPv6 ONLY for Scenarios >=20 >=20 > On Fri, Oct 24, 2003 at 11:15:24AM +0300, Pekka Savola wrote: > > On Fri, 24 Oct 2003, Christian Strauf (JOIN) wrote: > > > > IPv6 ONLY should only mean a node that has NO IPv4 stack to=20 > > > > process IPv4 packets? > > > > > > My impression is that in a lot of cases it makes sense to clearly=20 > > > differentiate between IPv6 only stack and IPv6 only connectivity=20 > > > [...] > >=20 > > Agreed -- there is a potential for confusion here. I'm not sure=20 > > whether > > it makes sense to try to define and ratify exact semantics=20 > here, but at=20 > > least the terminology used should be made clear. >=20 > I think that there are many "IPv6 only" testbeds running=20 > Linux, BSD etc where you only configure IPv6, and only use=20 > IPv6 connectivity, despite IPv4 being present but not enabled. >=20 > So what Pekka says is fine by me "dual stack with only IPv6=20 > enabled" (or perhaps more accurately "hybrid stack"). >=20 > While innovative new, really IPv6 only devices may emerge=20 > soon, there's=20 > little chance we'll see, for example, "Windows v6" without=20 > any IPv4 support > for a long, long time. The question is really what is=20 > enabled for comms > and what the apps actually use. >=20 > It would be nice to have common agreed language to use in all=20 > v6ops (and > wider) IETF docs. >=20 > Tim >=20 >=20 ------_=_NextPart_001_01C39A36.20F98DD5 Content-Type: application/octet-stream; name="dual_IP_Layer_slides.pdf" Content-Description: dual_IP_Layer_slides.pdf Content-Disposition: attachment; filename="dual_IP_Layer_slides.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjggMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDEwIA0vSCBbIDg5 NyAyMzkgXSANL0wgNTMyNzggDS9FIDQ5Njg2IA0vTiAyIA0vVCA1MzAwMSANPj4gDWVuZG9iag0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTggMjUgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDg0NCAwMDAwMCBuDQowMDAw MDAxMTM2IDAwMDAwIG4NCjAwMDAwMDEyOTAgMDAwMDAgbg0KMDAwMDAwMTU2NiAwMDAwMCBuDQow MDAwMDAyMDA4IDAwMDAwIG4NCjAwMDAwMDIwNTcgMDAwMDAgbg0KMDAwMDAwMjI0NSAwMDAwMCBu DQowMDAwMDAyNDI0IDAwMDAwIG4NCjAwMDAwMDI4MjEgMDAwMDAgbg0KMDAwMDAwMzAwMSAwMDAw MCBuDQowMDAwMDAzMDUwIDAwMDAwIG4NCjAwMDAwMDQ2NzEgMDAwMDAgbg0KMDAwMDAwNDg1MiAw MDAwMCBuDQowMDAwMDA1MjgwIDAwMDAwIG4NCjAwMDAwMDU0NjYgMDAwMDAgbg0KMDAwMDAwNTg2 MCAwMDAwMCBuDQowMDAwMDA4NzIxIDAwMDAwIG4NCjAwMDAwMTQ1OTcgMDAwMDAgbg0KMDAwMDAy NTE3MCAwMDAwMCBuDQowMDAwMDQ4MjM4IDAwMDAwIG4NCjAwMDAwNDgzMTYgMDAwMDAgbg0KMDAw MDA0OTA3NSAwMDAwMCBuDQowMDAwMDAwODk3IDAwMDAwIG4NCjAwMDAwMDExMTUgMDAwMDAgbg0K dHJhaWxlcg08PA0vU2l6ZSAzMw0vSW5mbyA3IDAgUiANL1Jvb3QgOSAwIFIgDS9QcmV2IDUyOTky IA0vSURbPDk4NTA2ZWRkZTMyMGI4NDIyYTA3MjZhZTAyMGZmNWMxPjw5ODUwNmVkZGUzMjBiODQy MmEwNzI2YWUwMjBmZjVjMT5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTkgMCBvYmoNPDwg DS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgNiAwIFIgDT4+IA1lbmRvYmoNMzEgMCBvYmoNPDwgL1Mg ODcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMiAwIFIgPj4gDXN0cmVhbQ0KSIliYGBg BqJGBlYGBi4VBgEGBBAAirEysDBwTGDY9JqBYQoDslzRjLJVV8V3CS9pAPKYjc3LKzqADLZ0IA1S DAQsDAyntgBpUSAWB4sYMvAzXGLu4fFgYBBMUGhYx9DMwCAxgUVBfIOgQphrndjhIMv0NQwvdBKM E9IaPEA6AAIMAA24HJwNZW5kc3RyZWFtDWVuZG9iag0zMiAwIG9iag0xMzQgDWVuZG9iag0xMCAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNiAwIFIgDS9SZXNvdXJjZXMgMTEgMCBSIA0v Q29udGVudHMgMTkgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0v Q3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMTEgMCBvYmoNPDwgDS9Qcm9jU2V0 IFsgL1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMiAxNiAwIFIgL1RU NCAxMiAwIFIgL1RUNiAyMyAwIFIgL1RUOCAyMSAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgMjcg MCBSIC9JbTIgMjYgMCBSIC9JbTMgMjQgMCBSIC9JbTQgMjUgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgMjggMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDE3IDAgUiAvQ3M5IDEzIDAgUiAv Q3MxMCAxOCAwIFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3Vi dHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAy OTMgMCAwIDAgMCAwIDAgMCA0NTQgNDU0IDAgMCAzMTMgMCAzMTMgNTc3IDAgMCAwIDAgNjM3IDAg NjM3IDAgMCANMCAwIDAgMCAwIDAgMCAwIDY4NSAwIDY2NyA3NTcgMCAwIDAgNzY0IDQ4MyAwIDAg NTcyIDg5MyAwIDAgNjU3IA0wIDcyNiA2MzMgNjEyIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU5 OSA2MzIgNTI3IDYyOSA1OTQgMzgyIDYyOSANNjQwIDMwMiAwIDYwMyAzMDIgOTU0IDY0MCA2MTcg NjI5IDAgNDM0IDUxNSA0MTYgNjQwIDU3OSA4OTAgMCA1NzYgDV0gDS9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nIA0vQmFzZUZvbnQgL1RhaG9tYSxCb2xkIA0vRm9udERlc2NyaXB0b3IgMTQgMCBS IA0+PiANZW5kb2JqDTEzIDAgb2JqDVsgDS9JbmRleGVkIDE3IDAgUiAyNTUgMzAgMCBSIA1dDWVu ZG9iag0xNCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDEwMDAgDS9D YXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIwNiANL0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjk4IC0y MDcgMTYyNSAxMDY1IF0gDS9Gb250TmFtZSAvVGFob21hLEJvbGQgDS9JdGFsaWNBbmdsZSAwIA0v U3RlbVYgMTMzIA0+PiANZW5kb2JqDTE1IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3Ig DS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiANL0Zv bnRCQm94IFsgLTY2NSAtMzI1IDIwMjggMTAwNiBdIA0vRm9udE5hbWUgL0FyaWFsIA0vSXRhbGlj QW5nbGUgMCANL1N0ZW1WIDAgDT4+IA1lbmRvYmoNMTYgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0v U3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMTggDS9XaWR0aHMg WyAyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDAgNTU2IDU1NiA1NTYgMCA1 NTYgMCAwIDAgMCANMCAwIDAgMCAwIDAgNjY3IDAgNzIyIDcyMiA2NjcgNjExIDAgMCAyNzggMCAw IDAgMCA3MjIgNzc4IDY2NyAwIA0wIDAgNjExIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCAw IDU1NiA1MDAgMCA1NTYgMCAwIDAgMCAwIDAgDTAgMCAwIDU1NiAwIDAgMzMzIDAgMjc4IDAgNTAw IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0FyaWFsIA0vRm9udERl c2NyaXB0b3IgMTUgMCBSIA0+PiANZW5kb2JqDTE3IDAgb2JqDVsgDS9DYWxSR0IgPDwgL1doaXRl UG9pbnQgWyAwLjk1MDUgMSAxLjA4OSBdIC9HYW1tYSBbIDIuMjIyMjEgMi4yMjIyMSAyLjIyMjIx IF0gDS9NYXRyaXggWyAwLjQxMjQgMC4yMTI2IDAuMDE5MyAwLjM1NzYgMC43MTUxOSAwLjExOTIg MC4xODA1IDAuMDcyMiAwLjk1MDUgXSA+PiANDV0NZW5kb2JqDTE4IDAgb2JqDVsgDS9JbmRleGVk IDE3IDAgUiAyNTUgMjkgMCBSIA1dDWVuZG9iag0xOSAwIG9iag08PCAvTGVuZ3RoIDE1NDYgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm8V9ty2zYQfedX4BHMVDQuC4B8dO2kdaZJ nVqdPjiZjiwpiRJLckTZmXxI/7dnAZKWdXVbN+MZgyB3sQdnr/qSaTERmfUiOC8cKdELRonFOPvj mZhlRye1E8Na6PhXD7Ojny60+FBn1hVl2eoU2kQ1XqH5/ln2JvvSHLxHLlrYZTm9Z8n206pWC+NL pgR/qrzoOa0LXwoFhVAYAcvOiOE0OzqbanE6j5jupa0qgmHhEIpKV9UDeZPk32Q/9rOjft/g7v33 UNZUKO+t6PEDsbYri5KEKSs23Z92hKn4t0JYTxVKKyP6wwxPypHof80u5a95ryyCHOY9J5d5T9ui kvNcySt+7+U4LQt8KUgKwVsnjUqvlc3f9V9mnXPYhiUt4gJTp09k4Hk/Ugf4hQoWPnSWvYrrezwE kBda5uw9076K/oZs8I1scJD1VDbClIQTydSSbE2hQRBcZBLJlRWVKTwxvx2vfFely5ZPFfmUZ+d3 dIR/Xvz87WoxGYl6ORh+zvufMmYlVP5emXQkinQkao8mbt8xHGOagipMKayt2PcewaQ1NYEf/X9y 0STMxQk0XsLmJ7buxFdRilfi8p0So3gKIse45pDmjIuMSir4dIPPyIIeQKez14LRcAw68GRiJHL0 syuM53M3qFJVpKpjqbtZQ0vBFEK4uRxV8P/a3RJiC3h+C2CqdKH9BuKdOElXLL8KlIH5BhhQmA4b /8d36wJ4IST3Q2D83iCvzQNYNmiGazzH3yFYFveFNxCstC3OmDv5++n5AXBUhsJuQ2eDbT6swaNS PRIbqXITmIkJIPsn5+uRaqCOWsAURzi2bAzwB6MsO5nhpPcXmUG6Uow6Du14Ac/KO1GZysf4JS4F m8ASZccv/jx7/by/hzaG44wtXIPT+RWc1geuq4wzvW9xOtQxanBa5vEATIvgrMzDYGuwdQGHRNVI VBDAiaoVMjWzHK0cFxWrT9GV3Mr+OiOkL0gy8CV/Jri5214D7cP0QjmwODrj0MchVcVnQQu3pJgP 2LLWBk9QbGA1wqaKivEcQq3cYyshJLS3sAKx2e+yZvHNkOcbo8baUO6wAIrJJmIUP3FrPXQDC29D nXzsoY1q2iQjTeXk+gpNh8QuWazZIhkSmlQOfdebXYGq0uOFq7wlirGPTp06x4MuqVInvkTFSZ3u Loeil9T2u+1k2hBhdpCa7SqkTSCh5D54D2TDqG+NbmONdOyfDmUsEt3svSLe7zJKOvCD1yH1glTF bNst0fri9MFAKkwHAEJo+5RDzkkxADw5G2EYCNiuCSW0YL7c3oi0MQywdMVawVL3DeivrR3Z4gbc kWM/jiKrYwE4VyHgjkalsYANYWLTSNFyW82uutuW6bavJvVsPh0vxCQPcsYTj5Wrz6PbnHDPern4 JnIvp/N6KSbTm+vxdDxbDpaTeY6caYVrFhksxmIgtgxhLt6ElziE/a+W7wlOFiFkrHVsORFh1t1+ eju45kPOzsUvg3j0txxdEsMgZmO5wAQUt3EMgtjFMkc0ycEQb438LN7Kq/H1HBuSX/MepjX5Nv9B zOZLILq5xXkkgQ6Kyc5Bdr4/nEOUmS5TkJCRMnRYTIfJPOZCMbq9uZ4M4RrY9fAMslF+EPPlRzh5 OJ/CtdNcy/lMQKm+nSwhVsrxI8h4SkMHI0N3KXkp3zNVTs6YVisRc7O4r4vDmPer7i4VJvX9HaXi aaoE27B7qoTvksO1NRG/AY7Pz8RoHGPqDsF1M8bvgbnguVkMRqPFuK7HMQ2HHK9WzsRVjLDbGoKD +hFufjIre3zcWFl+XMxZ60PMl48p02Di1eAmvrlBmhmJI4+jzbznkV21+G18g11Cx5VHcto5OeAe 4aOTHxEZ3wPAniHAILQwJjpM5X7D94bawmhb3x+j1WGIAT6smlshHgzJ9vUd923iPmm5NMUG6eXx CEIlKhSvoF8usLLDxo0croQoJKyMF13LaR8dpdVKzSlXkvHFYDrBlRWK2TXWEGtiVEbpI/ySBDjn qVX+91fx//UqRDpeRdl/eJOtQxbPk6qdJ3nHA87fAwCA6hOwCmVuZHN0cmVhbQ1lbmRvYmoNMjAg MCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCAxMDAwIA0vQ2FwSGVpZ2h0 IDAgDS9EZXNjZW50IC0yMDYgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTYwMCAtMjA3IDEzMzgg MTAzNCBdIA0vRm9udE5hbWUgL1RhaG9tYSANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+PiAN ZW5kb2JqDTIxIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmly c3RDaGFyIDMyIA0vTGFzdENoYXIgMTQ5IA0vV2lkdGhzIFsgMzEzIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAw IDAgMCAwIDAgMCA1ODggMCAwIDAgNzA4IDAgMCAwIDU1NyAwIDAgMCAwIDAgMCAwIDAgMCANMCAw IDAgMCAwIDAgMCAwIDUyNiAwIDAgMCAwIDAgMCAyMjkgMCA1NTggMCAwIDAgMzYwIDAgMCAwIDAg MCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDQ1NSBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UYWhvbWEg DS9Gb250RGVzY3JpcHRvciAyMCAwIFIgDT4+IA1lbmRvYmoNMjIgMCBvYmoNPDwgDS9UeXBlIC9G b250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxMSAN L0ZsYWdzIDMyIA0vRm9udEJCb3ggWyAtNjI4IC0zNzYgMjAzNCAxMDEwIF0gDS9Gb250TmFtZSAv QXJpYWwsQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMzMgDT4+IA1lbmRvYmoNMjMgMCBv YmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9M YXN0Q2hhciAxMjEgDS9XaWR0aHMgWyAyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA1NTYgMCA1NTYgMCAwIDAgMCAwIDAgMCANMCAwIDAgNzIyIDAgMCAwIDAgNjExIDAg MCAyNzggMCAwIDAgMCAwIDAgNjY3IDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDU1 NiAwIDAgNjExIDU1NiAwIDAgMCAyNzggMCAwIDI3OCA4ODkgNjExIDAgMCAwIDM4OSANNTU2IDAg MCA1NTYgMCAwIDU1NiBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9B cmlhbCxCb2xkIA0vRm9udERlc2NyaXB0b3IgMjIgMCBSIA0+PiANZW5kb2JqDTI0IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTAyIC9IZWlnaHQgNTQgL0Jp dHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTcgMCBSIC9MZW5ndGggMjY5NSAvRmlsdGVy IC9EQ1REZWNvZGUgPj4gDXN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB/9sAhAAOCgoKCwoOCwsO FQ0MDRUYEg4OEhgcFhYXFhYcGxUXFxcXFRsbICEjISAbKysuLisrPj09PT5AQEBAQEBAQEBAAQ8N DQ8RDxMQEBMUDxEPFBcSFBQSFyIXFxkXFyIsHxsbGxsfLCYpIyMjKSYvLywsLy87Ozk7O0BAQEBA QEBAQED/wAARCAA2AGYDASIAAhEBAxEB/90ABAAH/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQF BgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhED BCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfS VeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIB AgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYW orKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3 R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDrHZuQ3IyadztryW1u/dcPD5K2/qFtQbWyv1nV1tfc6Y0g aoj+mUvZc0uP6V/qbtJafJNb0xjyHNtdWdgrfEe5oVKOLmYiVSu9jeoHqNa+JH0ZTKBrRb9o2WXM rx6vU3sbZJMQ0+PwlU3ZmW7FfYSQRcA1wOvmz5IeZ1nofSMqbMgutFYr9GsbyAD3I0B07lUGfWH6 uGp4OXY1rrBYKzW6QRPg0qWXLc3IWOM3xj07akcPRZ72EGiYiq3/ABelw8p2R6jXs2WVO2uAMjVU Oo511eWBU6GUQ54mN2urVz1313oxMnIOFR9oZcQ5tj3FuvcbdkhZmR9Zr8xobRj7chz/AFLHkh2j ddo00b4qXJyXOTxRA9BviMpGtvluvoxjmcAkdeLpQD3+T1A1Eek0WS3fzHt8UOvq0h5sq2BrPUZr MtJAH5Vx9eRkZHSX9SozdcSTdS4GddG1/T+ieyxW9X6rkPrbXussrcXNDQ5xLT+YRr7QkOV5yZlK Mow4bBjLYGjvp5KPMYo0CCb1BHUPpFfWN1Nr3VgPrAdtBkEFIZl32ql1zTUCx7jWHSCAJBKpdF6f l5GCbM79C+5oHpsEbQDIme62H4Vb7q7XEn02Fm3sQRCgGPmP0pAmNdq+Y3t4Uy8UOgq/4IaOoXWA vOORUWl1bwRBjsfBRZ1Mure4sG5rPUABnSYgp2dKraC02vczaWMboNod8OU1fSWMDx6rjvr9PgCB M6JVzNDXXhN2RvWnQdU+j8WLeqWlry6iHNrFzRu5ZIn8DKSMOnVgk7zrT6HbiIlJHgz8Pzm78NuL fbekXC9n/9Dr+v8AXX9IrrcysWGwkAGY0WUfrVk5XSMrINQqh3oh9biHAuboR/em+vR/Q42s+5/8 Fh43/ibzP/DLP+oVTJlnHKQDoB+x3OU5Ll58nhyThc55hCRs/LxVTlgYh3m1tllj5JsL9ZPfjVU7 K9h0Mt8eFr4bGu6fnuLQ5zBUWmNR7ncLNu/mz8R/FWeS53mJcxCE58cchog/sW/FfhXIw5PPkxYv aycuY1ISOt1vfmgaQHAkSAdR4rT6h1HEvrx68DEGK5o/TRDi8z7W8arMa1z3BjAXOcYDRqSV3HQP qZQ7Hbk9RBNr4cK5LdnftGq1+YnjhwynZkPliP4PKYozlcY1R3P9qf6rNw8/oeThZFIr2lzMgAbf 5U+IhaXTKeh9MpFVBGnL3Alx+JhalGBiY7XNqqa0PEPgD3ACNfFZ1OPRb1axgrb6NTTLIG2eOFic 1ly8cBj4QM2T5ZWdau9xs6WLHER9WphHcOic3FZS24vit/0TB1jyRvVr9MW7h6ZAcHeRWBmvrvvN TCK6aWkMaNAT4BXnM9TpNdJsa1+0NbJgEtMQoIc3KRyiIjIY4+ij80hofKzsyHGBw3Ys6+Taq6ji XWemywbjwDpPwRPtVHr+hu/SxO3yWLjsqN1ONlUmi1hAZYyGlxHG7TX4oOTba7KyLKp7tJHZsqM8 9OOMSkBM8ZiRGJEgIxsgxOxCfaBNDTTq7wzcYkw8HaYJ7DskqLasRvR3vbIa9oc935xeDoP87RJW Pdy1viv2vc3O9/8ARrqs4Y/1vmp//9HZ+vU+jjSI9z/4eZWFjAf83Ms9/tDP+pW59eSDTja/nvH5 FiY3/ibzP/DLP+oVHN/PS/u/sel5H/tfy/8A50R/6bV6djdTyhfR09jrA5o9ZrS0aTpO4hTyei5u C/HOfQ70HvabSz3hrQdWu2TqVtfUMB2Rmt8a2D8StajJ+zMy63+5xIDJ11EgpuLNDBPHkmLBGTW6 oxH5tb4xzGWcs3KR4YwPtmREfVLY6lzsVmFmNZk9NwWV/Y7dxZIZY8RtDo26BwPBXVYGY3Lp3ip9 MaFlgAOnwJCwHVX1lmrvVyAIaOdpOg+a0ekhoyLGAvrdWINLjI+M/FSw505MogcfB09UiSDXFw3V GurjezwxvivyFeFuusir0qnZAGUz1rzDDB0krUvfspsd4NJ/BY2JVe3HFv2etzPc/wBV0F/c6fNH mJfrICrqMpE0TQOnQj7UwGh16hNXi9OqZ9nuex2S6fefE8KNuLRXitxb8hrbmOLmOgxB7Qgurxz0 n1nAOvtcfcfpTMQo3WPF11r6hcK2NY8ughriOdfgqk5QEaOOFGEa4RIgQkDKjR1I4RqyAG9zuft2 /a2qsaHMzMvKFjWD9GRqJ8UTEx6cfHudda17bj7nDQRHH4qrRQBkYuPc4Or2utj80ky4J80Y5rLM Ukm60Nc06AOGkD71JEiEDIQiJQuPCZGUjOQHF59AtNk1Zo634dF6q6BiX432pjq3FrwYPtAc2fv0 SVmui8VW7sWgOIaGNAEHWTuKSd7I4fk/yXt/LL5eL5fmVxa7/pXuN632f//S7/M/Z0N+3ejGuz1t vzjehN/YnoO2/Zfs+4b49PZu7T2lfPiSjl8x+T67s0flH87v+j8v0fofD/Zm532H0N0Df6OyY7Ts WXbVh/tFzrb2ivfLmbXTPgTtjleGJKrzXDWG/Z/nRXFxVfhw9fPROvFP+c+Xr831ffOpMacuh1Nj W5IjaxwMHw1AIU+mMY2+4vsD8p302tBAaJ8wF4AklDh+8n5eL3JfvV8nT9Hj7+C03wddh27/AJP0 Zkio49guJFce4iZj5JY4pGMwVGadvtJ8POV85pK3/lD8vyj+9v8Akx9Ou/0fe6WdHFzXMscZd7GO 3bA7ylsfijtb0/08v3ktJ/WJmQfLRfPqSq4vk/8AAv6fyfLt/K/Bklv/AJTpvu+/Xs6WacdtljgA 39C5u7cW/JqjYzpBoqHqObWCdhbuknvMN5XgaSbPfJ/uT5Y/N9Pn8O30SP0f5zc7fsffqmdO+z3h llhrOz1Sd+4a+2PbKS8BSR/R/wDAv819Pm/6H7Udf8p837Pzf//ZCmVuZHN0cmVhbQ1lbmRvYmoN MjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNDAgL0hl aWdodCAxMDkgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMTggMCBSIC9MZW5ndGgg NTcwNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibyXe0wbhx3H/7WxCf+t3VqS Kki8TODODjg2fpAskJEHJkAMxATz8OVIuyXc4Eo636UGVVRApKVq1UYNKUMi5IVCgsAiYEIkFFla E2uZ15HVVd2l2O5pcmX3j8CFEe93Z2yfk1RqXvsZbMP5fB9/v7+XI5FXFmyIYRjfjYsXL56DuHjO 4XDfvQE3X4AJsa/usk8E44O4f+PcXz4//cmpgf6+vr7+02ORyKMIG/TOTU87Fn0+5v/BwcLH/5Zh 7o+e/vPABzZbt60HfnsHx9nIf6immi1yFEFRRUH7Ncf3r1IdlmUC7rtu9hE7f/6THlvi1vvxePjr DkN6aqpUKuV+pdJfpeYe6HIwD18NCfiy6AvAZ2WvDJ3kCOIoJ0d8tzradpf+Oi11Y3aOLJsPWY5M pm53vwKrwBgfs7y6Bk/HBwfAFQHMp+P/PlZltRs2bSxMkxZVFm2QSjdkK4sqKytzZAe67r9cDsbH GRN9fmUwChC/Gzh3/7pxf0NTs0KhQBFELVcrpSKRWIRU1tTUAE2zY2X1ZZEEwJq40EvD/bYke3rP XP6qVSmXK5WQsxDotm3FGoVEIhIra2preJqmaebRywBhfW4fEy+HtcunepJIbH0jy+GOTVKxOEUi Fou4kEg2oAoJClFcC8HBHJhefnEQ8IZZi8QUXls6C1dfp+AqGcpnPhJ+Jy0FHIn+SFRIlEgkQrY1 t2AYR1OZo55efjGbWKgaYRGsjX3cnSRKT+/wg1X2eJoUIGIw63cSuCmI5nacwHiYJseLtBrW7WaS zx/tT1jDP3x4fiUSuWWQpoiSYOBBIpcjKcUY2dk5R/Iwss7FtecFYdxuIQj0uBuf9wp6G3f3yTgc +bHu9ZQUxFhsbFChKCJG9OCRWCKRIKALOeV0OeYmcS5nirqer8+wAd9iEgk0OcfpD+IUUZ6zS9yx E2VvoIp64hiGUVM3VWLkAsoljRjVShAtjePkzNVOHOdduvE8LgXcviQSHzS5B2fieRK96x3iS+Mn wxvyd0wdNIVjx3AVKpZcUInFKokI1Wu12rcxHMPx1s5Joha63rT/mTVh7voiDwV/QtpEHi192p3c VfpHo7gnNioO1ZlIyrVA4zMLekSvRVR6VI8g4JNY3oIdxjGsddo1S0BhP2PGgDtCTbjFIASPDz4T dhUO5VK0RMP1yjpDncmE4SQYcghBtVr0S5VEr9dKtCo5ojiM4YcxrP1dwlu7r/LayrOgMEJ3HoXd 30criR1M6vm2nv5L6y/72mDYw7NAdExgCqDQ35Rwuav9J0EajWYMO2Q2A0zo3b3l7c+QvUkkiUpa XR7qETYVGEBjsVe9v3uXwQSBU0SHaxY7qNDf/BsK/Vcsb7TjNF0slysONljMLZNT1P7fHfj2l5JA Z0v0RjawGOdaG+lNruW+sdh0We3YYfjTH0AW6/WjBE1YGusb9CoORSSvJxsVIMshMySM2dxuMuze WX37F6L4hHuGzx1IKHSlTygKoIzGkcNtZYaq92gMVIFLWsygULVcnLYBep6yXpmCKBrNLYeKjQfN TYRhz46qq7Hz/mqnKbK1pWY/yXYYKvjYp9xXqawsUhepNbp2XXPnta+CLF9JAcEyNn+yO9ZUonN5 NHEsbCor2zNDH8NxooPEMUutyVRXVZiWthGmtHQD9F5FsQJ6HyJXdlbtKjPEWZyUlcQBpfzI6pEd JSXbS9K3p6dvhZBlyzQ6TV5eBoSmy+e/7xOuhQ8GBfZwj8OCIfdjfdkuw3uN5Kzd7g3OEBauoOqq DBWbCtPkhcZ6k1Fh1KPcZBBrjaVle7pi5906QfEse488bCvdybO8ybHkvLZFp9mSl5uXtxlgsroc YaF1a6O93cK0tX32QHCU1wXaC0l0UBRxlKZxi9Vk4KOqDsrLZDaqtCouf1CV9LcVAl2iLOU4pwvA bOd0Sd8qU+vUslxZ3mYQJl+jyyqYFjbd+b5klI/mhbP/p8YdZXuqqk1mC1fUkDA0dQR04VCq6qoB xaIQS1AtwKAq0esV1+IsJ6wxlraShC5Fmqai7Oxc0CUjv0BXkJWRmTWduNjymaR10tZ/WShahD2y s4wrahzemjhKkFba46ctdabfm0xVvCxmOc8BM0ElSq24E/eIinu0rks66KJuVmdDwuSCRfk6XUFG RmZGZoEvfrHzvd1CmO6R5F1x1bp9N5SOqdXj9TgpnLROOJmgx/mN9xua+7fJYpZzY1uLcrqkKr1P 8ait9DdRXfaCKFtzACY3F+wp4LIXWDJ1sWY9f6o7kbjcaH68iy/g9S6y2oRRM+9P8CZZyBlP0B9i Qh7KYoZQ6CWcSxJUJU5tineNuEe8Lts5XZSaA5C82VtBF7VOk58RY8lcd4kd7hHmSs9HS4+hRELe esxjqqVdFA01DWMZegxG25kQe480myCLzCoJgiJ6PYzw17rinyTJIz5flM1Kro4AJQ9EgaLezLO8 FRdmqS9pIH449sTOuuqdaPHX1uPWCZqwYri9Y3aBJBb84RBDkUBiwe03Jage/S6gRxGZI37a43VU rmkoryYIor2zvbmrS6POz4vqwgc/Oda+EK63tp6Rp3yx8E60umprqUm7c2qGxEnC6Q0FmRDjpBZm +Hnpden/EdCyjOPvmuYfEixCj3aWFDYZy9Nbua7GLrphsQjdaY6ZBMJc4A6M9yWvlE/9XtFeOWdv IeCysMJYccruDIS8XhrHokF4gvSMlwlcuLt8XbB9CzxqKy3Z27wfcheHw2F3YD07uvJj+fKWDiRY GxKmrS0xEZPiXlPXPYKCCYjTXpfVG/KHQn7vDMnDHMaPkhRG0Mxxrf67wGLiJKFHpcrWCq6m32ZX fYkdO9yeybOALlnw55WBbuHWMvQz62rQH5x0EZxB/qAHCogJOSmPk4RE5nh4Jlj30C8dgnOEHhU3 VHB99008nDR8vAXrumRmMlwRCQfRwBM1FIsQc91F3XFRlDe0HFoJL4cZPnNIO7fSARHZAJu46q5w X0x4xF49WB6dja23A0lvq4vpkrkYeZD4NsTdhn8OJcL6iclZ0uWlaSa8wqyEGS9td3pnXTNcFpF/ pL3HRSrtbXdIqEvMo5bF1t18TacXPr71XY3lS9ZcZET4BcQ2IBiJ7NoyRGKRZl0EbZ1yOnHKz8EE Z6dAoeCCi5pwkq5/4cduqvSLgaThH/eowQ+5y1lU2HxN+AKIufUygm7331PdgirqGY4pzM6PjQ6f HTwzNHxpPFZYqx4rafX4Fxa8IRZ8YkJg1Q9caYcWnPb/EV+1MVGkd3whs0vST8cuL9FAIh53h9SX LyAEtlSSu+RsUhrugtHNmgB+MNIP1StCL73S3Y3Zc4UUFKJefcV6eAJh4YxGUiu5EHKxKU02Y0Mo rQRw3UzNEsaYhWeny/T/PDOz88ybqEfS/26WeXmY5zf/3+//9kn5j36SEDSTn7EeQao78UKLZRrn F0LSg6HTdDPXOULSXCr8p0vdoYCEMth1aUh2TgqIWeHXVtaAJR5oWl1BHJxgZAuf//KnD2C80Oyj r0cVTXUQRwa/yMnu/hVN639xVUwlwjd6ggHVW3B06nxYfgKSAKAVgoTHIuawjyADcw9SKKIdjXT1 CEMxYGmXOdr2we0uOrcEB14O9feS7XWf0IACBmCAK/D+SPbMGsaEwCfCok6X2npEEgzJdZQJNRJH YNeD9JaBvrMhn18zDSh/QzcV1SCeQCBgVCTiGou4qO6dtbnOK+c6rVz2EI6weC9qdpW+wS9DnaGQ ZlTy+3zBG+mHCAgRBEQt/CoAWRfBJyiiT5M0R3VNcq7TLIrXpGvAe6fpbk5ywMWbI08TE8PXuugi hSEO0g9JoSQiJkgSiT1BrCFjUxy1HamTcp3GL3zNbqU0vv+ez0fXaPhcGJa5QOEL2ju+HsuUjGdR FI0ZrqoccaO/IPmlsKB5mX/BI57nV+LzY+6dUs+AY7pTh0RVBViiTyNfv5p8DIaW+NiSoetROWqO HPtQno/qm5ubmpuONDXi9kXqX4hePtBNrZ3Dmt3CIUq/8PnDhHE7ydgYx5pcvqtw5OHS/S6Z1XaU kN679N3SdI+pyEUGo+v+092EvMAfuGWBJRrljGKBy3cUjlqScg0AksoKocUEMHgOKFX63W01XwXo THJmUP+wkU46EfoCl8xJikW5GZM7XPTPab0g2i/5uN8tgVlt57ulSpP5zXn6vYMDKf3TVlX5SmhN Wz5uhmM5k+ss99cvfivHkSDPAXhuxHPADsxRKRlhiV9qJnpotVw2ebUburxnFkmINYcCcTVF1aMP 922V/QIcSXopVeaA92tiI7Q2u832GQ6q0sU/w4YV67wFFCzmdEyTeiTpRfFLCaXdGi55iwrnoEEs 2J7SVRxW3zKsgDZ6xgzK+hO4OtWhn4+kONqRD275MbiFxPSedqjI/dQ+l0ylgGjPwfemYQEbM/UK CDdlnI+wWwrlOMIxvXP37j3u0WewEl1WvR8Km4ZrqlNbsvVYOAuCQLhYfVM0R7Jffu5p8DY0NjY2 NTUdbx/9e1wKmNWz6htfNX2gKHZpa5IOCwdeWTH9P0RSn3Y+2kr0cvjEr44dazl2FyVFKm5HtxVv Ky4uxpucnrDC4teAGaDvJTk2apbisEklW8sRjumCwpaDH3388b7aTzXL+b0MY7PZtuFtrq1ZYDmj TTC0wIUYyNYCCrck0n6hOCpsOblv39atW/Y/p9eP59kzAEwx7BIyxqpkKER5Bb5h6lZ0xtIrYlQS kVIbFY6wXo7OfgQqdtV20OuP59gZhnHgXS6YBhHYqhrT5EfNQWgpykYt/gtwrmn9clTNuy0rB8Ev tS4P9R58dQb2C6YoMGBVfyeCmlYzlMYMqo1w61ZYOBmlWRwd5T8Hkra46v+prp8uw1gcWLqhhPkj 5byrZsSzsvIRVq2VxCgs3+viSOrrpn5WC37Zf091QFsOQGEceLM+y4cOBOjsErgq+RVFo+wSsvKl mJaLCUeF0O8uH9y6z7XFpTabyJuN/bINb2HIpooJ1yinwIeUAAGx0UjMkh9srDynft9hEkdI+HUt cOSqT0fScn52JpNhI9klbPXM1fOaAaETL0zG2CWLXJu2iKj1iyaOkDi1H45dhY+U5ZM5mRl2LBdo 5yzlMkHPAr5AXwIn1KWIfgyyxGLMdWQO4D8BvwBJyvIjmdmZ72RAFMEWVhEtDgb90nREAOHem8P8 bIAEONL5RRNH8CLHsF5c9fIr8XuzsV6KKUUaTep302oJjfBRdsYyv70CizaORPERUFTrKpCj+hHI JZNhMEW+G1ZPT/RQuvUFehZnWHZjp5j5RRNH4Ik6zJHrMykAWp2Z4BdSiwLGPle2YU1r7r8OUF7D KWZYNHEEodiCA8l1gMeL+OrsbIij4gCeNAYsnihcUmULnzMPNwqftEXkiDfJdcQv4ne1QJGrjkTS bBlgycgqJm9s2l2CTYT8NJg/Lr6eU0S5kRKpuVEbR6L473rsl4I2nC+/zQW3ZO/9ioSHsYklhvoD tFq6zDs/U4sZ8i7MR1QcicnDtSAYpwdISnqdgMXeNBQ0NEiqhbs0/aWlwk3MWI/UfldK/b8vwI4p h9TLl2EsueMJst2A6S5qZ05+usxGFitDcjbUz0dgkl/E53WuWqfLeRciGqBkZ5fw4lW/ZUyHg2kc rww2U5OL47+m7n37RduJZk8H6jh08BA2z2+kWuXBHLk8kHQxlkwv3hD2uWKGJdHr91Fg+v77JlDk 1lsUktwMeiEk+SQcIvjCRy6b94Ajp7OcFyqyAUzOXVz8YMdek3qEbgRoiiybUCuLxvQHOlveD3px Fkw+wnLJLlsQccXxBb40SiE1GNIIt/8NhCuZEtbJqHknijwAxeVs/iwXY/Hi1YkLJoEkoKEQNYu8 qnpaGqcUc2QORvgd6MXprKh3Ake5oyRfDIJEezW6hFnjdqefFm4o/MZQgBwFAgwMKZPUNFuH/eLK xVjK5qSVl/y+4JACRkghNrI00KnpLIPmQb+RzaSVEjMrHrwH+wUMsHjlDZ7CCNQdlnBwUZaNLl4P aofFNxeLZOrMwkcXjWhOFmDHYCy5bfKl1E2Qb28YCJ6JQk/Nfn3ulE+TWS5btn0bGFJnuRQPfY/u lR7tJ1AwlgXlWuIi1OrO67djscUHQ1/3ap0Cc8ibJFw9GqodRdD7cDQc4VOFo2ppAeI4bqiH7Nt1 7lz3KVoopHD2Tbw9FHh+LEqhgZMZ6rxN4agtxcdgCgWLrdwmviBtrU+jWp/vh0ERyVjHomT6DN6d ZSMPI2w0xk3LHOWOgcvWeA6hmQi7OBDSQVBAnf8BBKlwICA4DT3iOmCKPamXSKpexuyAVEm4oaFO PQp8EOp/3UZuIzScRI8WkNBWXl6Qn59/HNOjaik13OOnwZBv9+BbBrM5HkTeHfgBhsjvw/tjY/f/ 8nhuWR9hE1eCPg1Lwf6J12/k3sgEMSVu8OiRy50BBcjpnv7NUMrbGwoPXOnr6eruvdw/9P9Fgi2F Ei+fvkysbqZOXmG8ZCs8YWydX5hfkHcW5FvJ9ELyF/ErQDC+sS6d8ZuF9LnH4znQUN1Q7cY1IN7m 3rur0j1ObsUb3NXuKre7sR2DQI0NxwmYdrd7Tpw/UtXQABhQO6wY3SQsHSTVZWYyeXFRnK7KYxjG xhS141edtDP4zGbLqgGfzeZlVOGrfKVt+7R4J8/O2AHaQqnNYWvfJMccdhUc8nq9Dd4mUZwrybBX NrVWZTmKxuBWK8NUNbi9lXD6NygWOQyZ6v5RaquMp1rtABTQtwIUx/3NgSLUbyn/j3yMqu1MY1wQ +SaHzQ3vXGW34/YKuR0OgNZoz7uDO6zxIpsb8d53SrKYORGV2rY7ih5vDhYYkQ7E5ePxvIyKZ/gg VuTYHhdRib0kTrDYssZEviqjZBbfbHU4WsV4BQN0zomjWVmVjsr5zcHy3X7XobuTk5Pjs0iAN5dU KOyyFS2AQJiq2fj83PEsx6458XGZvYoga7Rl3Rfn8+ytecx0vNLmhu8myeXkPperwJmbAxstVDB7 pZZX3G4reiaO/q/VMnZpGIjC+FXvcqtie6JbnIJym6ThWqTdnASRioIKRwcdM8T232rrlFHFsU5d apDSSYq0eGMayvnuSoujQzLl3hvu4+X3fXklzAI/8BxEAc4ntmWXULje/dIx2Yo9HD9RGnFH5iNl fltb+qh4o5KjDbFMkLHr8JluglOMjyjvKp1FpNha2B7imY4KuwMPtxuIxwe0nY+W76ud88QGWqrf j3FlOW1AQqZKENZ+DV2LsVaNDdY3vRihE60rWIx9fENxt0ONyfJ4Ps5ql6sda+gT32I8Aly6euwT IFlJABesPC0Tb2aaVeTEgPW2BC0u8iYhcnPaad5O9+5X79MKZq1soVWVwiwWr17BBOuAOsEPzEVs mjDUiYvcmR6VSGsq4PuFqop4PlKyx1r9eX3qsAJtdCIPIT422UZCU60iBOkyD4vEjzrStSD3CIsV aDkcQu6e5LPVzO/265/rU9pkBQtr0DeXQ7aZauygAH6CScWSjKmc6EwW/YHRItOEopzQnT9cXP8J B9ULGKZBG7IXhJXFyBYFFyYBR02PYCbAUzoLy3KahoF40X3O/5O6vxC+3DwKZW5kc3RyZWFtDWVu ZG9iag0yNiAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDc1 MSAvSGVpZ2h0IDMyIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEzIDAgUiAvTGVu Z3RoIDEwNDA0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvJftf9rIFYVtByGB hBGwENuABMKIIrSWQeAka7A3aZwmTtJk7XiTNi/dvm3T9v//3nPujARxsl97f04QQi8zd5577pmt bR07Ozt3trcLBaNYNE1LhVEqlW2nslt1XbdWb3zXbN3d298/2G93up7v+/W62+sHA8c5PByaCMe2 i0Xbts2i4+CEXakECPweBLthtVZza7XR78YIv4bo9aIoDIMgDPEZRb0sJoxIH/DFDNfz4tjHcZ2v jXEc4+2uW8d33+WRh8Hgibyx5rrfe7Hvx7in7n7PXxET+TmKOKaQwwp09LODcBdnB4MjGTWiwv/U V/kZww0DJynsFAzDSBLLxMWYHWfMjJm2Y5tWUmIUCgV+GOpCy0oMnGJ6Gdvbd3bu6Dgu4YKyVbQH tjlNppZpMZP4KOuwisWi9a0oG7einP2AFx8fqyX9MjAAGdv27chGc4df9BglChwexs4ZyDsSfs4Y +q3Mw9C2HSQC059aNgPHw6CK5XL9WtjvCwQDx2SO7EEAFqpcCSY+cv30u/Z8b3Fy7/79Bw9Oflic zperLldvfKZjHE+Opsb5j4Ebp8t262FrPm83l51O51ET0W7Ll1UDserwzHLJP1zVmm8tccRTeKTX aO+nv89ywdRjcpZtyuIl5TLmWTLOTftxJSC5QKmmAshUMCGZlYCeh62DiPejXfBBlIEl0Ys9bwxs /VF95NZ6nG0Fj3kc9EP8CYoXvV5VSgGUy8GIVwLTCbiOGb4/QhIF3lpVLsHvE5ypTVg+/X6POca1 Hl8n7+Mnbqzx+RfIfUVqEOMuOkg9TvYV34rrfv9CsEbsBkGgSjYDPox2A2c4narJDlkxFa4z0pUQ azwTzy0L24RmVprNCjMCXT43jNJxocTrSAlzbfCO4fDwEE9wmHQCmyREBo9MFLymmavP+oScRCng y3oBIDZyVsaB2kmMJwyMgNBaFqWIV1tTSBhmUfoa+22NO+vlmBPA+J88EajVsBG6ivUpGQNePeSq Y6CUOwfABDXfO/O8bnoGkYp2sc6DytHAtivACOuGtZIqCPoTHwjP/3D69N6zZ/i7vLx8cNpajkWt vC4iTT2v3guQkKlT7T5f3Mcll89ePD2Yb4F4oNxqNXHQWa06q3TVlDrIa6GpCqLZSLt42stO/MdX r16/Fmk/LhVmM+BOrVKzE6FC+nWOVdky9NxM9Tldh1ylpFDVhjtCYMgvX6ZpF68UUQaZoq+HfJDD a6nIRLZONnERcSfNFHdKftSbuD5nP2YipLPUfRVa/nFxtfpTGNZGAvsYV0quUkkanklF0RyzWm3i znFG/U2c2R0i1XZYAjLbQRZZuxrqcKQL4IqypiBBAoifxfSJvPNfmcIv4kfmVMgJPDCrpkFOsWXK jyLz0itvhX078joYbqgNO62tR0ntHXB2u7uiUw4q+8gxjW/jrjqQNKeSUnIjR93QfUs3LZy3NO6K GtOBmITVEdeF2jRysTzVnyh5UT/qQSYjrms1F/cguKj5cXfVWbbv7u3tHRxcXS3gHlY0D0SBC7gS bNgqvFXr9MXl9fX1m5ubn99cX784Od1vPYTWL0F62iD9Dx+Sb805q6CzpPQDPtqKbueVCPv29jGn Bj1KmHHdsWTKkCce4QTFP8mkzbSz1Ofig8wOOAOCLv6BMDJiHW5PO5ijo6MBgePtqHfmRyiOOT3A Gddq4jxgaHpSNtUeK6GrwI2lUegD35V66KlX1pA84fwlY8UYy11xPBpJCxX/pDyWRu1oMBhoW9On 5AR9XQCOFk5HY09uKiT8UON+qH6w7bIIeoENHr3dlkIRP5LQqeAuqRbOWOuFo74LiOq3jGbH5gOp wgrc38Yd1w35ktI6zsui4Y4aMeqTswll1qrUmXdHytWcGoWvYo27EI1pGXQta9xnBbmipCyaJf/r UZmYqx1EPTfuvky9GEgjDYegg7ICrR+PvTpatpvh3hN970eiZGz/sC1c/rSBu+kH4oz3lLq1aj48 WCyenjxAoAu8vb5596c/v7tc7Lcp6FBvuQRue+8K15yoWFwhDvbuzluth1IAPyhdx9ToBnNLhtTJ tPi5815lQQtVHlaW+mwJmdmqBl35DSWUYWYKBnqhckxsASiqaovuUrFF2XXt9yPloFyxQ0r463Ts SEZdeXLlitA8XfHq/ribEnPV3lKt7jTxUhlK4WVIuUtRvGmhJl25oqsR2hU12KGZafFgE1reVbQU 75Iic9BH8xrI+iv8oQIVxuN1rsR2cG+UaUXWH4fKb0xz13Lbs2+QD1marZ242n3BblPopZQo4yhe 7EkqFT03Pq48TbLucys07SURtiTfHyTi1cS9aOVPcpeVix81ckgv7qXpGZQtZJqGFrc4Qc1rwEKv uj6kKcddlC+qivl0a1obtT3t1epK1NigsY7dtNOeH3w4QJyeLu49u/fxLQX+44vFvNnoQtEaWPJH y/b+wdXJ209/+eXTzSWs0duPf/348eMl/lgkqIL7N5T2whNZGGPG2WJHIzPKcC/oHMxo1Iq2plRv zhjDrNeLMGIe/CfNSnX6rAFIPzDzTq6BB+6h7my4uadqXvyGgitk9btxptGSECknnZdIFDkMcY2Y nXSlo9FA2s/OaN+xX6i7m7hHUajdS7ibI08Ep8jDTFz48FBtRJ1KRVjlWANdJBnug6xiKgK8QUks /2g7R9IZxA4K76BPTXcNbyYqeWT6mZnkjc/fCIjTl3bkjtpybs9Ao71RkLY2V7LF5FIa3FIop6Vi pqNwfCxjOZe+lBn2JMlrLVFjPVcOZlP6aAlKU8j7pO6dYamQ7AnFCEuXNppbcxjsLoogCte497hT o0elsT6D3UALlrZOb+uvcRczknaUQYFvWS3/1v773b0PV1utra1m52XXwys6siXd2j84uf7lH//8 9c2Lxd7du//6AHN0glbw+fP155uf//3pjdqnUhu21Y6V39jLMv/GXUtJ1bslJlSJoMW61Vu2zSDc tuQ58wKiAGtVkgrJL84thcI941HhXlG4c/JUdjoZbFVHI1+2rAhR9552/npvk6roarvja8czqYvt oZkR3CE+qnuEysGIlhdFc+lWFaNDsRsVZfZtKVYyfrRR4NzSwhNX7KJF92KpWh6K2IkhsHJuyffa BJeMTZeQo5c5CX2mMDNuxVeSnDmR9+/RhgtcLcMqyr6goncWs8J7WeQvncs3ai07Liunonlf084Z MqSxO04GvCUwsOATEw3lQrZgUB/22ObW1vPnra12h/a7p5y78u6RsqC4FquVNpYrmPS4DuNaE8Ff mxmx4HgWPXkaTwDHxcTnWmNLJ01deSDwDubb86tnN58+vbu+9589eJjWfG9x/+3n6+tL9INPvy6Y h9eIV+pgR4zLrLT27nk6FO56H7SBe5aDctZsZW8LDd90nF/hro+pnkrGQd1FT4hEIr7CnbPHNjVW Fl/7dhGAWKyN57osg3FXtiSI//rZfkBwr/ZqVI5v4K7ag0JYrSAWeSobxaKp7ZbGnbLH/e0t3KU8 xSqgKahNKaaX+5FptsHjR5bR41IGvKZqDa/sDTNxn21S+XXwkgxfATrbPiCvToa79X/CnXdMh6Y9 RMb61TWIaTr2wTlyTmO6ibu4gAmV3Os2sHTownrfdwv3JaO5bD5qeC43vbT2vn8EjcFOKRx5WHfK ///YLhfntLErjBsHkEBgXgHbMbKECFAEAQPOo1njTNJ1pkmHPDfedNNm2um0M560dRtv2u1r+/rH +33n3Ctkp3cmsQ0S6J77ne/8viWsf7Xc+xUM/fT09PXTu/fuAmm+evvmyb1XgPr7PwxeiLdnqfAC DIJco8ypaVVh3pyJPcC8bHGqAGcBD0Uq6oyjtSVUp+TT46tOaS0TnsPNXsKySjSkOZJJHF+CGTFv CJd6paEPgiStcgbKz2FAuoHeTYAVEAxkjYmGcVypSCcp+ugE6cdruVssEVBHNyagLGwSSc6Uo/e6 a7knGZf0IuNK8MEkRd6Ha3uzx1mo+wFWoqtcdq52kjBMCmbka3uqo88DZUqjl90dUmebcrpi4Xwc Y0692W+zmU1F0oPLXXdF7va89cCF3flmsfjArGJRu8HRk9PDNXKXbmfhZhiM3ZI6QSgl5rQmr4ZG 7Sp3HnOZJZSEFuCUcboC8UFVPE3VvqTYSSrtBnS/XBzvy9nD6Gr9cm+KZ/UQDsg6j0A9/njsr5qt nfs//+rt2dnZ+/dnv3vz+snOw9/D8arj/DkMvaBa5fwVSWObD4rW25MJPDUMN50WzU/9u5g4FH0l L3J3LdmLewMHjLxCia8dpRWWy8a9aMuUZTJRlrcSVLlr0ASoS4zBn4Fpf3+1INMHQW1UYc8Pg0Gg Wle54z4wD+7sG2Xzg+VHp9+3sk8vbcaSh+05CaFP5CVtAqdUNlKfTPjPplczsMyuuW0edojIVnKm 86yUcz5f10rt9OBAWTFxUPMJnsk2zh+m08eC3JavL2OMxqoCj08aDTfmXeHogrzs8pNuOpgSGQ21 tmNyBSvwbDb5TE5wY9gcTq4hsmLRTCIeNcwdAvCS8GXlLvMQdcNP2lePPd+dWExl+XGWNqra0DXp 2ggU18TXOakDzmsIvYH82VgsV22zRPRtvHTMke4jm/lB7SQqzWa9aOS3m0ir7RUmBKx+1W7ufnHn 7pOnT5/evfNqe6M9rGD+wl7/+AxyP8hmDlgyFA1lKOYKoPdNRFgGG+seBdv5qfDiqPq51sZElxMV w507/QqteTw85qTCbkjbFTZ6WSMv9opSqPjgwCOsKlmlXq9y/InXg0Po2mQ/TsNabSCYYoLMYoEt 1iosGDtAhV7V0rF4UsXRiAXub231+7Fda6FPZAntKvEKjbgl++bJSRifQNJwapiJRBNP3NuE1W5Z korL4uXUBUW2kU7vqOusGV3lUywouM+tLbueWQnzlXTM4EGmOSo1iZOJmc/VefFdJZlUfUSIPNLk ehDAvXAWKDWezMRalfucDt1T/njMDxLjz3XlNPooe1fThznZgvAN5KwmhvvyeYYUGWclnWY3eya0 KujwJVZnYsUuBiYTPA6J56G1tEnEX+KKdTDGrX16+h5YHW7uL6lj1fsRIH6JlwbxCPQD6TeWqyEk P5n0hZ0YdznrhxR8a/cQq7WHdOtz+sdRKTp/BmDffP6MJm8co5BFXr323MBegbVOhmha7hbcLLvP OMy4SWTOWGycQvVXy+beQ3CVv69A8hL0HLFkjodz6leq2GRdBTpm5FhiLgFRwNuoEQQq5QnQ8ryG V3EifhywiTnp2g1/XA0h4woZcGwvEwKk4PHfrVt19grl3YnDtdy5LMpMxGiStQaVCJEiRKNxKkQl mdo6v7D33AyyVECmLt2CpYQDGZj5kpha2XMTuSf0MJ2pKyo2kPZ0Wft3PKEjoUbpiqtyn8ttiKSS QTDyQpqll4JLnk4PjQnChdubSZAVE3dlRPUseaNRcy66M1A/qiHY9Pi1c/vM2qNFt6j86kqTeTr7 gOkCjLH0iBlPdi6aEpLTjb8gosVmysc6aeXNWpXscnx8Se57zaM2znip8C6JFVrHeVc6bBleRMYZ Q/CyAPXUPIBm7C/be4eH29vbInl8jL9fDzvVi4uLb7+9+PTp/EcvMmbgzpl6Np//ickHnW/lbiVv 2U463ZZL5S+c2wlHIxUc+m3IR1rhIdFeusc+3dBDwRxUKqz7q0eCZYiYkG+DEwo9GsaS/hgTxZDV 1UXEgVBNXPn4A9yAOxbSuRV9CwZR16agyA3gHx8T9yAHGHVK7nZpkIC0LI+nD0qOCtMXX3lygi7F cyvUSiky85zQglGmk0tQWqrkOoI5efeyuRcEXpRZDAJ5JSv3nlleEgKnubXPrBtGFAiwMh1JAYmc JGSklysInisk4J9Dk3YjHkPS3Byy8cfgA4rHkdrp3uzJF+cukb2OEk2sCvAsFAglgE73b43gnr0U z3m2jJ2TGvRLIddHITJUTfQhVCti52FBpnA6koqELyTXtvA6nBly1yVih2zHYdcRq6wPV9IEi/1R B41eRBfHA3+hcW4Bue+8un3/DtaPb+wctpptf3x4cfHpz5++++78xbXMX7ixv+LAMpT75rtMVu0+ GYLqMSmicdZq1xnG3cd8eq4xdCvRcUsRuVz+kpdwYLIIo/EQRr73kM6PShg9owpbxHpUi1BEAE6t GPNBWByUNPgwHA7H/HzagcmlRu7VOkUuqCMLBUC3nUh1L4s9DJUghcASZ5c42zEkz6cXP4q+dB/k NOhZNADbOCpZalQFQjopUhPUg+eocNZJVP5wjTkq/npruduHcGw+Mu56dT5I4MQASd0kjVpa85C9 Wh/KTG4uxytv9aNJyU6wTj+sBh8wTrFhz0nimJi+TvLi1UWE5Z7xAVsx2UQIFUjnpZbKvROP9htH G/DqvaPrEjRlAo/E3ulkMpV95lDIuyFaRUZdWnhZiMrRDCJtGOJ+7GTfZTIFrz/wBXHai1shEtLM BcTX6O7wQH/56G9/3925/eT16dufvj97i7x65/YX987PofXnm+9E4dfA66Q8knrWss0luZtmT5KN sXkdYF0lbQqQ3DIgQoibG7OEN6IBO6Nbx8dglqPmQw6rpT8OakLpWBpuyiUNqYShap3B03pBRJBh HKhUBkNUgLOAuvYX8p1C7QT8+j4GRaPRlvqwQmOd0rWU2CUtxLxaMbJslWZ9nQhrpVTGoKyVnRz6 HaU2Ykfnm5YXbBCNahAlqEElece54ux2WblLugQUJxKxMFMsWnGbYVG4sg54JmnrTdrB4k7GtGQi dEvuxKz1+OrDOQYkW49PW5BIIKdbtDNbO8hNyd61LVVaQ5+Yg50Ya7nTYYLj65Du3sYG5jg5Fc0h GUqht0bqhhyaey2A9nIhcofe1dYJM5A81LKxR7uHuv0OqCmbzXnRYAHyfUjfxvPjCKNYaAaBFrc9 ah41WzfufH36zT++//6fv/7N6euvf/kC6H4tm+OI7t1k/Sclnp6n3kCOyWTQBVopgUetPFFQaz01 4UQGKyijRriGmLa2bA2SUjDjRGHVbywbMpfAIRVwohnJUnvGUswEYRCkUKDakLCico8iSQTcEneD RctgnNkfjoOqUXso7i6GgK9B4XyqnR2o3Zc+6VjCU185wCybYbdggPZYYWMxZihAYDZ9nDP6YaMb GpHZYGDYcYrQOxGiOL0qdusS1tyFPVzNQrJSrGIlrhK9KvfPVvaKzFOJq6CfYHEmW5g6pa0YiK6T CyH3X65wiuk11zTbVMFkPTCM4F3ns4zTSWtex4zATEeAJWZCI3z6PIsaJkHXvKNyB8oIvND/GryI eqfkKXVyTLO1/bPtlq6NVnO5Goew8165XwmGC3+1Wg0xM8iuMFIYvo6BBX85at3499P33/ziP2en b9781+BX1ccn/mSjeeRXIi+fR7rJaOU2M1buySlY0+cw1U6n2mXbrF1FdIktp+jAWGSXPdGRa16+ hKpC4J4n6RaJtTpAXFkc7bUQLXZ3W2jl9nX/A8MtHN3SjHAdRsMj8YLDw50bO7vY/X4AMqwS36vk IZSwOjbkzipwfFLtYX8t6q55YCv0NK/ruQkI26Pm2I56OGcJZFTxXKxdMNtus6dM03OmdPf/a+uI qNywCoW/9C4PAOvu6+YwerdivuLn1t/NrE3jzjpspREcF81mvVIEBbLNKXf4erGQ/R/j5frTxnZF cTD4gT1gD7k2xtjGD+zIY4ODH6RJDFWaF01vgFJV90PyqfdbpZamV+gi9VOlXvpvd6299zkzDkl1 jxC2x2N7Zp/fXnutdM63ncu74551s3nVoKcpNVfYxEoWK1I1ipF3UZVMuzNaLfG5sKKuQSjvQ1Ei 6LvYc3A6Je70JDQ0ZTr2U2h/ZWeXqXO2u/uuNp9f12anpc4BLjXzenOruA/KF39Z0UXbxP+LRRnD AjN+UTn5/v2ffvjhz3872VvBF1Rr18+fPX16Ui3//Z8dTGxz70A9tYS7VyiJr8lxF1iTs3rFFn0c 7pk1sckm934E+85CeIMKA1GAbA4PG3VcIAlf2a1Wqzsz2PnGfhi5AlIEoNiHh4ffLfRWVNgrs53r T9UfXy4aI9JOVVeBR+1F5XFEPrlN6BFWCbAPaNahfpPatpZ0Si+Xzh49iZ7YQouCUUmQ5J24F1z/ GO5QbHwmC7CWXDdW3hxfpNXqxrg7Rh/inv4G7kll96+T6q5PMfTdF42PxXX1juQSIqNdc1Uvl56s T9gzOFuvFULWUxOjjlVkPqfiTtgZaGAEmQKCjiubG43Sy3FR9UkkG2Qx1XYWtGMww8CrZYeWTxvK O2jnAKczEfTLFQocYP0PwufJb+aV6fZR7i0vNbsVNvZ2r/96jfUCAri7W6vhYVYWh7RXrj9aVHaq n+bPpu9//+zk/Pw5Auz8x9PW60wahF9dyALqQH5saXScs8xlVZ+MLaGKOrN+yDqwZDAzwzc0vaIG blLLtHehKqmv/XBwWp5Vr+fz+afqbnWn8q/TAbnseP0tshS8X176yfn8GvdRgYdT4nkvDcmnBD2K rOXo+0MxN6LuIwJfGrZ1I0RVIp2yke+pzqYtL/r2+nXB2tn0XxB1S2XfdpjHWZCunpPeWKNSoFpj 54nc/HcBU717Isw61t3jxnqC6CTlae7L+KGnX2oMmqZC1iyJVBOTtUhXV/S0R1qsFsYW1Ed5tnuT 2UZn4+52nHbvZnUa9hPRbGk02gpiEWmrEYWb2S8N+eu8miFnOuRd8x59d0MNe4Nyr7jvGfBcOLYo U6DB9GwPoljqdw+O366P+6fVfwscswpkEFyAqedPT2b1aV0C76nMjMb778+re981mjByQTr1CsH1 9udffr67uEqlNnKsECsgWubtoK9mPluQJi+iQXk1DVVYwCqet5CAwgJPwbrAfA6iTqc4qO+xZ3H5 lTpSTESenNy2SvsDDLK9Gbq1xt7FbVZo8HALUhOSbHIRib2X7Cmgy4yEoSfvYJ24v0HRI4E8Hrzx swTuS6834wGtct9T3C2idv0G842szAHxQdm8spFNLHmBGuS8BezK+Mu4Svk5kDMr/dU37OfH/xf3 nAQEd9nea9IbCuxeUVRU0AHyBq2mHovCETvDzmdFgoIlVo+71UrfN0X3vC8NzUhxbwruGpgwH0JB hns1MvvZsDV1uJd1r413bj0cL5boNrNdiF8pDhaghF2AxXdnO7Xrk/NZGfgI74AFtJw1t1ud4B/p 9dTl5ztdt3eXH9NiUHjZnLU0L6mLC6RaMzmcrtnNztYfobwjyRVoydG+JUHM+rxWRaUgDjryIHsr Y58VQdhoyp2ytNHWZtBDk1FMOfqauOOXFQ4wWhw07UKum7GneQjXErWdRhNhc4dStZFT9ZJYGYux ERqI45RZKd7rX7EkUqpV8djK817gNT8Q326etWuf0A7XhJeXBOjiYE49oKlgXCNphELgEp+awWzW 4Z6opg6Fb+JuFjKxRMuLxdCWJRk5CyCSuIHYCSCEJU8FNAjtdMCR0JfkIjanu/S91kuiNS0qVkfT UD/mPdJMJbiHLd0x2bKWDuJmUzgQ7EmUx30h2mZNACdexvE9al6F9hfqv6Dfx+kL8bcwMnNZ5+e1 lcUHvIHM6nB/8mR9/WPq8uLq8ubiCpMXVF+mJrmAl5sdw89JXsW6Auxr5ByynuuhkqBR9HOfnA7p l2FhhIlsciIq7vLo2M+ldbuzOgj7LuX0W6wnwmwkhgNknklHP+Ii5dulkepNS+Q8sjqKhxR9Vy2n RDQd7eZp+MCPhdR6cfEO963YwS4T7lU+oKiBLEHcNy7BFry7SjvecribZiujRnnSrYg1VOl1+cBB HHgZVrPBNqLdeRB8x7nxePzlwSW7k8368SG/shnYpDIHUySZ0RYzlagw7OhooIZZ8yFZF9oHgGUw 2g4xers90o6LT+COb8OIfwxIP3ygZ4DuSSsx7hju4pgEazC3LzvhdtC9M3JLTHwC93rd8U5DXxcL S9xJt7zNjuAAOBXx35tJpq1UVnCO9EFDMWK3wF2mrm5uf7m9u7t5lUq9uruHkVlbT48nE/aBRFWX fCZpjla9QWqEXTHqhZ4/PraJm6f2EexeINbP2T4bzIK7l32OEAOtjXuW1GSFbHPSlUpDrFZIV8Kp Ghrqbdk0bJsV0oxMWPKTUa1MGC7jPlStD52bQbn7X8c9DhjCotyQrdiHG+/OyFgT6PH41pPLBN+c TEe9e+JMh7u7mq6z6D7DOu/+LdqTjRVLTWK6YqtkNAUdG4tRS8rBcTqSOV0XvG3kcvlwycFNcS8E irHD/XGj8YG2mmzW2SzDKGFtFGkVcSdYoWxlFOOuFv4rZuaU3+nk/VFd9B4/BUMz293Zna0spDen /mMLWVB8wF+XXpk6AzJFJL35CXb9/v727ubz59v728+XKb9WJfCkf5tXXyLFEhIOOKJ1549Z2GXt sp0NzPeP4/mt6u/PKOjYJiAU9chRZ3rfPjo6ct2lI1g7TFaMRNsV3qy78+2sa+sLdS+VtNA6SVnp 6Evc7esSvGPfHMTERIE33NXhaBfkNIvaGwADchokVyHrMqoprlYoHSdRcXnup0QaRK+Rdh3uv3pt 2Ib4nUnIv7zG1aLUYekx8SuGj/eZwRoDOkG66zjVdAr+HtWhGu7ulH6/hGRplroCQ33WjGQuOfuu 8zdkgBo5FQptH1wfUKe+6t0F2lMNqnz+6AxqXS9XEFiv4Vmua9XZS67y7+raFdO6Tafp1GTdcK83 7+/v/wvSb3+6gYu5oJMRy7K+mt54QoeezscOXMcnBQYGZ22itZtMVrUp8mnbDvzL5/FknM2avfRK Y1G1UFBJ04lPsbGIJ9i1Kdqir50gFgilU8ewmpcE7pJT5V/R556mjs2QBkeKSdyjYeiGgSpOAnef qSIJXjHubtMDj7lRjidZF1nVyfikxjvLp8XD8/wla4466OGCyYGhmZAMj/bGw6O/lvulE5Of1A2F 1RrnCt32cHvfWFPfDKvXp4EL0Nd5230XPXJZp2TdTt/qZEAjgj0C74hX0xFMz9GRlq5ruA+pPNv4 ctJu8iMxquWiapxX1dE0YjOjzoopFa9Op2wtijvU/V0NxD8/f1F7MZ/XkO5eluuC+dnZmZh2Qd5S LtY2tB025uIVjPkaQJ8w6Jimc2DmMnkAPXn7dpKmCE0+OtlfXQPfaTtb1sTpkIg9nkxiNUmLDcqY sHUt+uWOZbJnMgVbonjU86S4Bl4ktBv6qsle3lFLKL8UCnQ/NtRFJJiKSoq7RVV8su1TkvL+AHfp hiXeLTT22PCq4D1t0EAnlbSy2ng/aZBj8nn2MoGb2Hrr5p868mzuAbzuRd4d/iblG8kW+dpyHubY Bq5vOPdL+VxmsxOJ6FqFKLyRxFETOFmZjBvHmYIYu3wOw1hx72v+YvAalkYDWCA4HxzsFbT1j5Zx HxnulCHnNtXFxMZpyPdGS7iLL+HLvXL9w/S0/BLenJaGxyqzWm33D+9ezK/xB6F3fh8NsQIPv0KH Xxez02werqVSl1R0sjmxCnLYbRDcyYQPGlXX1lfRECmefqk254nE2NXVjx/V2pupfCKS7/jXoIbK AuzXSEoY7ygPhzw474nKqzLKP3O04HorYaPbfeWbloaL46/lohzwB+MjmX8o9kCWjOQmlUrqOcTH XTiK3DBotfhN+NLoi/XmTVvy6QFWwqsLN6TkWA95V+NR6vUOurBf0DX8HUhv6HRLkMnOONAKbNIU Hhx4s//Q7o8TsqzftIS7uhVVk3H+gfxzHR9LplLQ+WJss5c7AkMCBA9HJrei8PsaR51nKajjz2Rk LmWyhf+xX7Y/TWRRGC/qLoRS+jIpZTqlQCs1FLTRjhWwQ0LXlxZx7fLSsijQxLUJnzZ82ewXJTF+ 0FV3/+V9nnPunSnqf6AnsTiv9865z33O74j5ED1H2N0GmJPIgo62IgVOTk5XbBlNGmSBrrEuN+ZT xoQwcGa1uIzl4nbJrFTZYt2UrjTLXjTbpEULwZPJg8Bp+vl3eTcWywbF1eWnrS2fRj+bv9+G3nOu 6z52fXLOO5AOUCeHUz7a1gL0PkYx44fCFgNiIu+IXK9phzoGkXe7Ec93uzwauzY2EmLvkUFR73ci uU+oKaLUUwfl60umkCvbwN3HKXRmMpFQE7eqVk1Xzf8XVLVcmRVjyvytLiBdKF7cvqsjoe2tIcSK OPqi+rp9m4Gah4uL0dIZbzYKtIZo5Cdyx6eE7B4f2Q0KZFoKcPZ2LQJm9Ve2LUsW3cOwBUS8oDwK +vGlaPCaNkERV0waFYsTT9a+hp0wJqh6UyrkmZ/jS+VSNUl8KS5D7EmTZqJgBva+OKWIPimfXCPM sM+CXS+wEMBFDB2mUraLknKIHD5UQE+zU1XTr0Q+IpVUkSaVmQ+pRnhztYjW0iGYZ7jYK6lMEU0n 1U6hAlBa4tpZCh4k41PDFDF8vODlZhE5X7ycN/m+m7/bWFtvQ+vYCl4MtYAeX5+78kU8p3CfPxfH Vmy5qgrvPnvWtaq/esUSjAUZhl2HmtH7JbnXQr4dt36jMD819eCBCD0hWmd62FCanZ/8TRKVtNgu l+nXUkYN3DDFAjBCnilbl0O1q9wjMhedLyoSic5pyUBzZSkpv2XZlqNSjnRvelPcnrAIDga/PTER yT0uRq09jz6iKk+oiEcM3BY3bVKmR4uapIQQHVdzVa6Ih+RnksYyEZ/4trmPABBVO75UVjNRgGD5 S6Ol5HcoRKJxTSNpJQ4ZzhAjJaanq0lwYl0bQJZR7BQU0YxwEP1Zkr6yIsWU1RTvLek+qFgGTSYp dyAPBi6yDgM2b5jCklklu8xArkHxZoabKbPpNI3CIeksLXxry+Mhz2AbxHw3l8tB8hR/7uVWKzCN 6RwemsnN3t247xrmQfCxoHh+jv701/Pzv0nw6FT/+lL/IBhR+y9/4npXsD3080jrlhUjF/zpC7kb l4HPPHqk5DipnpEoXQ6gSzUdhkUNVbcqX4l7BOYXpO8R8jMAOG/UrrWAclf7Fv/h6apFeOClaLYs SrWT+abc46YiqfFPqUBK1MrUeC0sYOVy6M6q8bDZxYVxgyiX+0kSB6R4q3S5YbB9r2ySUHmhxs0N +JmGPkf6gK/Fjsldv1VSY2CKpM9JwdYX2UXFTUNleCSdSlZkUAVLCJ2dkWA5yTyd1GK5gv2yCXHp heW5uhMUnLpTnytmmPiKLo+unKxdMn2DW6LI/tEJcHcBdrs8H+p9ud704dK+13SKnOMmaKapht7M br0Epvi0apyQ5hWuHpsBmAvfBE+fkl/n6viLwPuDgufm4e58oAX6R6Pr1FM5KQQSeQY6XBPtdvvu xsZGo9Hgv8YGjtv4u37PxLqNHQRPdDo7O/b/a2trcq2xLo/z2faGvnf3vgyUx4gvXuR3d2WIBt7S QWxv9/sHB71DxNnJcHh0Ohicnp6+QlxcXLx58/7Dhw/v3/8hcRHFq1ev9fANQq/9c3Hx+vToCK84 GgwGb9++HZ6cHPZ6Hz/u7+/1+/3tjgzHAY8/9fcQOCfR6dgLnz/j4jFuPkZsdz7v4AN2Me/Hrvvk SYxtENOPBfB0TVAvYTju49n8LhK1gzd82tvb3z/o9fR7zg7PMIPD309Ohvyo08FwiE8c8vdE4vCs Z+JAA3Pdw7Q6zGmnc9w/QE4GA7n7DK/r7fU799axMrt5PxsAe+m0mTAs1OnB5r+O44jLNc1P4IgV SqtDiTAcUSEdvK7neKLZ9NjvZcnOBbF3YWl+sWSAVz3mA3jhClDgUguCa7WAIK0WzbVV0Ax5WU8z pzHjiZol8DbR4KyrTOJ5M3y7H4sx2cgriSXHZ2Q2cHAdmvLntAI0sdhxjiNTnyvWHX4mj7AhYYbY hf/9iB/x/cT/AwBtA0LyCmVuZHN0cmVhbQ1lbmRvYmoNMjcgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3NTEgL0hlaWdodCA1MzMgL0JpdHNQZXJDb21wb25l bnQgOCANL0NvbG9yU3BhY2UgMTcgMCBSIC9MZW5ndGggMjI5MDAgL0ZpbHRlciAvRENURGVjb2Rl ID4+IA1zdHJlYW0NCv/Y/+4ADkFkb2JlAGSAAAAAAf/bAIQADgoKCgsKDgsLDhUNDA0VGBIODhIY HBYWFxYWHBsVFxcXFxUbGyAhIyEgGysrLi4rKz49PT0+QEBAQEBAQEBAQAEPDQ0PEQ8TEBATFA8R DxQXEhQUEhciFxcZFxciLB8bGxsbHywmKSMjIykmLy8sLC8vOzs5OztAQEBAQEBAQEBA/8AAEQgC FQLvAwEiAAIRAQMRAf/dAAQAL//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUB AQEBAQEAAAAAAAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJx gTIGFJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePz RieUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYF NQEAAhEDITESBEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNU oxdkRVU2dGXi8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//a AAwDAQACEQMRAD8AqVY9BrYTW0kgSSB4Kf2bH/0bf80IjWw0DwACkAtez3Y0P2ej/Rt/zQn+z0f6 Nv8AmhG2pw1LiPdSD7NR/om/5oS+zUf6Jn+aFY2pbUOI91IPs1H+iZ/mhL7NR/o2/wCaFY2pbUuI 91Nf7NT/AKNv+aE32en/AEbf80KxtS2pcRU1/s9P+jb9wS+z0/6Nv+aEfaltS4j3Ug+zU/6Nv3BM car/AEbfuCtBqeEuIqaRxq/9G37gmOPX+437gr20eCW1vgjxlTRFFf7g+4KYx6v3G/cFcDG+Cm2s eCBmppjHr/0bfuCkMervW37groqCkKghxpppDHo/0bf80KX2ejtUz/NCt+gn+zlDj8VNP7NT/omf 5oS+z0/6Jn+aFd9IjlN6XkhxeKmn9no/0Tf80J/s1H+jb/mhXPQCb0ilx+Kmp9mo/wBG3/NCY4tP +jb/AJoVv00tiPEe6ml9lq/0bfuCb7NT/o2/5oV41qDm+SXEVNI4tXZjfuCgcasfmN+4K4QhlOEi hrejUOa2/cEjVT/o2/5oRioFoRtSE11D/Bt+4JttP+jb9wU3BCOicFJNtH+jb/mhRLKf9G37goSm kpUpd1dXZjfuCjsr/dH3BPKRRUx9Ov8AdH3JenX+6PuCRlIFFTMMq/cb9wRGtp7sb9wQdycu0QUm ij/Rt+4Jw2g81t/zQqpeUhYUuFTebXjH/BM/zQiCjFP+CZ/mhUW2nxRW3lNMT3U2vs+N/omf5oUT jUf6Jg/shRbcpiyU3VLA49I/wbf80KBpq/0bf80I8yltlKyhreiw/wCDb9wTtpp71t/zQrOwJjWj xKRenj/6Nn+aFAsx/wDRt/zQjGqUN1UJA+KkDm1fuN+4Ks9jJ0A+5Wn1lVyyE8KR7G/uj7k+xv7o +5ShKE5THY390fcltHgpQlCSmO0eCW0eAU0oSUw2N8B9yfY3wH3KUJQlamO0eAS2N8ApwlCFqYbB 4J9o8FJJK1MdjfAfclsb4BSSStTHaPBLaFJJJTHaPBLY3wH3KSSSmOxvgPuS2N8AppkrUttHgltC dJJTHaPAJbR4BTTJKWhNtHgpQlCSmMJQpQlCSmMBNCnCUJWpGQmjyRIShG1IoSg9kXafBOKiUrQg Id4ptp8VbbjzypfZglxBL//Qn6LuYT+k7wVupoNTD4tH5E+xafEsafplPtVotCba1LiU1tqlsKNA S0StSIVlOK0SU8oWVI/SCcVBT3J9yVlSP0gl6YRNyUhKypGax2UfTRZSSsqQmtyjscrCSVqQgEKQ ROUoCVqWEIgAKZrR4qYbHBQKlwFIFRkhLcmqSAyn2tKFuThxSpLI1lRLSFLc7wSknskpGZ8FGUUe YUi1pStCDcFElpRXVhCc2OE4KRODUMtCNHiEjCdamsWobmq2Q0ob2hEFTTcxyGayrLmlDcCE8FCH 0wl6YRC7yUSUbKkRYmhEUSEVLbQolgU4lLYfFFSEthRgo/plIVJWpBCUKz6JT+glxBTVUgSEY0Ec KPolKwpYWKbXlIUFL0XjhLRSRr4RBagCqxTFT000pLvTGwhM2h6l6DkNFMTe7souucVP0T3TGtLR SEvJ5UHaoxrPgoOYQnAhSAhJEhMWhOtSNJS2jxShJTFOknhJSySltKaCkpZJOlCSlkk6UJKWSTp4 SUskn2lKElLJJ4CUBBSySeAkkpZJOngpKYpQitqJRBSlamvCaFbFEpfZ0OIKakJQroxvJTGIPApc QU56UErR+yDwUhisCHGFOc2tx7Ijcdx7LQ9JjU8tagZ9lU1G0R2RBUO4RTY1CdaELJUzFbR2T7Ag G5N6yVFT/9HTxwDj1f1G/kUnNTY4/V6v6jfyKZV87laiLCoEI+0pbD4I2hrwlCOWeSjsStSKEoRd ibYjakcJQp7UoStSOExCJCaErUj1CW5ynCaEVMd5TGwpy1RLUlK9VP6oUCFEhGgpMLWp/XjuqxBU SCjwhTb9dL1h4qkSVEkpcIU3vXCYZTQqBJTFxR4Ap025rUUZLSscWQiNt80DjCrdUXNKkLGlZjbx 4ogyB4ppgq2/uae6eGFUDkDxUTlFLgKm+a2ngoRqCrDKKY5JS4SpO6vwQy0qH2geKiclvinUVMiF EhpCG7KYhnJaUREqZuYOyE5hUHX+CEbXFPAKGbmlQmOUxeSoynUpnvCkHoSSVKTh7VMOaqqeShSm 4HhOHNVLcfFPvPilwqbw2lPDFR3lOLXDuhwqb4a1TFcqi3IcEZmX4ppiVNn0imLCEzMlrkT1GkJu qWMkJt4Uo3DRBewpKSEgptoQCS1QN8J3D2Q2DtQngFCdfKEbHFERKkpDQhO29k24qKeApSUJJ0lL QpNhMkElJQJ4SNbkzHwiC0IaqQ+k5OKnIwsCW8JWVIvQcl6JRd6cOnlCypEKlP0UUQiNc1AyKmqa iE3pE9ldgHspBgQ4lNEUeSX2daQrHgl6cdkONLnjGPgpjFHgrseSRCXGVNL7KAnFACskKPCXEVMG 1QiBrVEvQnP80tSpsQ3snDQqXrOHdL7Q7xS4Sp0mhoUvasz7S7xTjId4ocBVboO2hCJVYXOPdS3z 3S4VJHShlrk4I8VLcEVICHKBb4qw5w8FAkeCIKEDo7BDJMjRHc4IRJlPCn//0tfHYfs9R8WN/Ip7 SlRpRWPBrfyIkhXidStR7XJ4KlolCFqY7Utg8FOU4StSPYEvTRYCSVqQmpRNSswE+0JcSmmaz4KJ rKvbAl6QR4lOeWqMK+afJDdT5IiSmntUS1WzQFE0o8QQ1C1RLVZdSUN1bk4FTXIUSEc1lCc0hOBU iIUSEUhQIRCkZCiVMhRIRQwIUSEQhRITlMJKaSpFRSUtud4pFzh3SKYyipXqP8U/qvUYTJKZF5Ki XFJJFSyZOkkpZKEpTpKWhKE6SSmMJ08JQkpaEoTpJKWhJOkkpZJOkkpaEk6SSlBzhwYRBc8d0NJJ TYblOCl9q3eSqpwhwhSZ1soToKUeCW0pBTFJPCUIqWSTwnhJTFJShKElLQlCeE6SmMJQpQlCSloS kp0oQUqSn3FNCUJKZB8IjbENrZRBWEDSkzbCiNeUJlYlWq6x3TDSVNeUQOJUg1qltCYSphEqJYSj QAlLfFC1Nc1kKDgPBWjtPCGWtKIKmq5pQi1XTW3xQ3VgJ4kppmsFMavBWTX5Jeg4o8SGoKzKIKiV Zbja6oooACRmlpbCE4Cuek0KJYOyHEprtbKn6aJtShK1Itqi5ohG0US2UrU1XDVRMcKyak3olOsI f//T2KjNTCO7R+RT1UMWTjUmOWNP4BGgq8dytYSU4KeE8DwQUtKcEJ9oSgJKXBClIUYShBTP2p5C GlJSUlkJ9EGSluKFKTaJtELcU25KlJSGqJDfBQ3FLcO6NKUWhDNcogc3xUgWI2VNR1SE6ryWiQwq BDfBESU5pqHgoOoWg5jUJ1fgnCSGiaD4qBocrprKbZHKdxKaJoco+iVec0QhlvgncRU1DSfBCdU4 dleLCmLR3RElOcWnwTEK+4MUSxhTuJDQhMYVx1DTwo/ZSjxBTUTK0cV3gonFejxBTXTI5xrBwFH0 LPBKwpEkiei8dlEscOyNqWSSgpJKUkklCSlJJ4ShJSyeEoUhCSmMJQp7QnDJQtSOEoRPSd21Tip3 glakUJQUb0XeCRqd4JWpFCUKZreOyWwpWphCfVPBSgpKWhKFLafBKCkpjCSkGlOGHulamCdFFQTi oIWFIUkf0ZUhjFLiCmskrYxfEJ/sZPCHEFU00lcGG7wRG4be4S4wqmi1snhHZUTwFerw2jUBWG0t HZMOQJpzm47p4hEGKVo7K1FxYOCE3jKqazceOynshJ1iGbgO6WpUl2gd1E6IZuCgbO6VFSUvTbwg F6gbCncKmwX+CG558UH1DKW5xREVLmx/iU2+w90RuvIRWsrPKV+CkDS890ZkojWVIrW1ppkpGAU4 ZYeFZb6Y7Sn3NHZM4lIG0uPKJ9mHipOsAUPWSspV9mCX2dveFB15QnZPiiBJCU0VjuFAsa1Adkgc lCdljxThEqbDy0IRtbI1VZ2SD3lBdkDcPiniBQ//1NrDP6nj/wDFs/6kIxhRxK/1Sj/i2f8AUhE9 Mq4TqfNaxClqkG+SmNOyCke1x7Jww90YEJ9ErUi9NN6Y8UQlDcT2CSlto8VB0BIklRKKlSlKaEtp RUsXJanumLXeCbY/wRUufilI8VEtI5QyPNGlJN4TeqAgnTuoEhGlNn7SAonJlVXFDLoREQhuG/zQ zcqxeVE2FERU2Dd5qBtKrmwqJencKmwbVE3IBeo7ijwqTm/yUTkAdkIpi0FGghm7Ib4JC9qCaie6 iaiEaCmx6oPdSa4fvKp6ZShyXCFN9rm/vKUt7LPEqYLvFAxU3w9qf9GeyphxUxYQhwpTOa3wUTW0 9lD1VIWO7BLVTB2OPBQOMCjb3nsptBSshTUOGYkIZxrB2Wq1umqZ1IPdL3CqnJNTx2TbD3C1fQ+a iaAOQj7iKc0MlP6Y8VeNLeyGccI8SmsGeCm2o+KJ6RCbhK1MxUfFEYyDqq5scOE3ru8UKKW9DI4U CGqqMlyZ17ihwlSchh7whOYPFCJc5NDk6vFCSG9yptaw90AgpQUq8VNoNYVL0az3VXUd1JryEKPd TabjsHCK2pncKp67h3Um5JHKaRJLdFFZUvs7OyrNymojchp7ppElMzSAm9MBI3eagbJS1UlCm1o5 Vb1HJeo5Kipte3hNs8CgB7u5RG2tAgoUVJAC3uo73dk3rVpnX1xolR7KYv3nhCLndyk/JZ4qq+4E 6FPESpOf6yE5w8UEvKjJThFCQvhIWTyhapI0psBwUvaq0pJUpsQzxT7W+KrAkJ9xSpTaDR4qJkd1 X3u7FNvd3KHCpP6pHdL7UQq5MpkeEKbjctyl9rKoymS4ApvHLUHZZ8VUShLhCk5yXHuoGwu7oUJb QjQUu4eaCQfFGAlP6Uo2pqmVEjVWzQoGrWJREgp//9Xo8Et+xY//ABTP+pCPDFWwtMLH/wCKZ/1I RTKtkanzWsiGpoCgZTSUqUkA80+3xKDJSk+KVKTbR4qJrHihSfFMXO8UqUl9EHupCgeKBvcO6Y2P PdKj3U2fTYPzlFwrHBlVS53iU24o8PipK547ITnv7Jt3km1P5qICkbnHuhklWNnkouZ8k4FTWMqB Vg1jxUS1qdaEBY89k3ovPgiuAHBQnPI/ORFqYmh57pjjP8UjaR3KgbyOE7VSjSe5TekBymOQ9QNx RoqZlrAhkeCXqSn3hHVDCHeKYlynITEhFSIl6jud3Rvao7Wko2pHJSlyLsA7ym2s7pWpHv8AFSBC R2dgol0dklJQ8KYcD2Vb1PJIPKVKbYE9kRtb4VRtsd1Nt8d00gqbQrcisYRyqXru7FFZc7u5Agpb rXDuFPczwVUWyPpqWh/OTKUnJYeNFAslDcJGhUIsHmkB4qSGshRNbvBRm7sE8XHsipgWxygujxVg 1OP0lE448UQQprETwo+mVZNDhwVEsjlOtCA1x3TbUUs/kym2+DUbUj+SYko0FNtJStSKSm1RvTKY tAStSPVPBUgAnIStTCClClt800JKVCQnsU0JJKSBzgptt8UBONUqU2Rc3wCkMgDsFXDR4p9oTaCW x9pZ3CX2mrwVfaltS4QpMbq50Cg54IUNqjBRoIWcFGFL46pj5IqYwkkZSgoqUkm1SgpKUn0TQU0p KZaJtFFKUlMtPFOGtPdQlNKVKSFjfFNtUJS3FGlLpiUxJTSlSmUlNLk25LckpUuSlyW/yTF/kipf e4cJxZZ5KBefBNuJSpTM2P7lRJ1+ko7SUvTKWin/1ukwgPsePr/g2f8AUhFdHiq2LIxaRPFbB+AR dVbI1PmtUQVEp4KbVJSyZPBTIqWTFOmSUuNndPNQ7IZTSipm57OzVDeB+amKjqlSkzXtd2hO7XhA l3gpS7wSpS5Ye7iolo/elLY8+IUSxw8Ufqpi5seaiSB2TPD+yC5rzyU4BC1jwqzkYtA5/BQJZ+6n hSElQKMQD2CgQnoRFMUQgqJBRUjgnslsf4KcO8Utjj3KVqYQ7ulp3KJ6Lz3THHd4pWFIyR4ptyka Xjso+k/wR0Uou800+af0bDwE/wBns7hLRTCUxgqf2d3dI0kd0bCkeweKWzzUtqeErUx2BOGhTDZU g2ELUxACcKY+CkAELUwDo4Tix47qRaPBNtCSlxa/xUxa/wAUPaEoIQoKbLchw7p/tD1WBAUvUA7I cISn9cnlI2z3hB9SeAmIcfJKlMzYPFIOb3Q9p8UocEaUmlig4jsFDcR3UgWnuhSmBfHZRNnkiFrS o7AjohhvT7h4KW1qeB4IqYCD2UvgU/tHZRJHYJKXie6W3zUdx8E0lJTPRSaWd0JNCVKbEVlItZ2K CAfFPDvihXipciOCm3wl8VGEVM/V8kvV8kOHJQ5Kgpn6qXqKG0pBpSoKZbwm3eSbafFIsPikpluC UhQ2FLYUlJBCeGoe2PFP7uwSUyLQUxaE3vTQ9JSxYPFR2eCcz4KMlFSi0qMFPJTaoqWTKUpkVLQn gJ+VIMcUFMICeFL03JemfFK1MSokIgqHin9IeKVqQ7QnAARfSnukaPNKwpHASgKfoFP6B8UrCn// 1+hxj+rUxxsb+QIs+SFjiMeoeDG/kRIVs7laqSpNjuoapapKSkMPdDcxg7qOqiQkpZ0dioypwEoC KkaW0lTLQokEcIqV6Tin9Ad3QmG8JnOf4paqZFm3iSgu3/BSO7xUCCiFMCX+JUSbPEohaVHaipHu d3TFx8kcVMPJhMaa/wB5GwpqO1UC1XDXX3UCyvsiJIa21ncpnNZGko5azwUHAdgnWprlk8BL0XeC KW+SW13ZG1IfSKcNLe4RNjk/pO8ErUi3x5pes4dgiemR2TbPJLRSJ1rz2CiHv8Ub0/JN6XkjYUiL nngqBbYeXKx6Xkl6XklYUg2R3TEKx6JT+g7wS4gprR5JQrP2cpjTCXEFNfaU4Y48I/ppBsdkrUjb U48oooA5KcbgnlyBJUoVVpnNrTy5MWEpfVTD2Dhqidv7qL6SfYAlakMN/dTGPBWIPYJQ49krU1y4 AaAhRkqz6Y8EiweCNhTV1KUFWtnklt8kuJTW2nzSAI7KzB7BRLXJWpDDz2TFj0eHJbXFK1INrwmg o+w+KYs8ErUg2lP6ZRgxPB7I2pB6bvBL0yj7CUxrPihakO2EjCJsT+mjaEMJQUY1pemUrUihyfYS plpSDSlalhUl6ZU9rvFLZ5oWlGWx3S9oU9jU2weEo2phLUtw7aKfpHs1MaXeCVhDCR4ppHiieiUv RPilYUi3DxSknuieim9IpWFMNs8lOK2n85S9MjslsRtTA1N/eS9Fn7ynsS2FK/FTD0mfvJehX+8p bY7JQUr8VMfRr8UvTZ4pyCm2lL6qW9Nnin9OvxKXpuPZL0n+CX1UyArHBT/o1D0X+CXouS07qSez s1NB7AKHpn96Eth/eQUz/SDwCb3d3AKPp+ZT7EVLwO70oZ+8kK1L0wgp/9DqKa/0Nf8AVH5FP01K kzTWfFo/IpyrJOqEPpJekiylKVlSH0im9Io+4JtwSsqQmopvSKNuCW4JWVIfT8k3pnwRt4TbwjZQ h9IpeijeoEvUCVlSD0E3oI/qtTeq1KypD6BUTQVYNrVH1Wo2VNc0FROOVZNrFA2tRsqa5oKgaFZN zVA3MRsqQfZymOOUf1WqPqtRsqQ+gnNPki+q1N6rUbKkXou8FL03eCn6rEvWYlZUj9E+CXoeSJ67 EvXYhZUj9HyTGjyRvWYl6zPFKypF6DfBN6I/dRvWYl67ErKkQp8Al6BKL6zU3rMSsqRfZvNL7Mi+ sxL12I3JSA4xS+zFG9dib12JXJSP7OO6XoNRPXal67PBKypj6TR+am9OeGqfrtT/AGhoS1UiNEpf Z0YXs76pxezsErkpD9nS+zo/rs8ExvYeyFyUh+z+af7MO5RfXYfil6zErkpF9nCb7OEU3tS9ZvZG ypF9mS+ztRPWal6lfilZUj9BqY0NCmbWjhL1mpaqRmlqiaQieqxL1mBGypF6E9k32c+CN67UvWal ZQgNJ8EvQPgjG1iY2NRsqQmk+CXpFF9VqRuYlZUi9Mp/TU/Val6rUrKkRqS9IIvrNTesxKypH6SX pIvrNTeq1KypH6Pkn9IeCn6rUvValZUw9PyS9MKfrMS9ZiWqmHpDwS9L+Sp+sxL1mpaqR+kR2hLY 5E9Zqb1mpWVIzW4pvRRfVYl6rUbKkPoBL0EX1WpeqxKypF6Kb0Ub1WJvValZUh9ApeiUX1WpesxG ypF6TkvTcieqxL1WJWVIvSKb0Si+qxL1WpWVIvRT+ifBE9Vqf1WpWVI/R8k4pRPVYpC1qVlTAU+S IKfJOLWKYtZCaSVP/9Hr8SsnFoPjWw/9EIprUsFoODjGf8FX/wBSEYtBUxlqfNDVNaiWFWSAokBK 1NfaVEtRyAomCjakO1RLUQppCdakceCiQUWQolG0I9U0FTI1USIRUwJUFMqJcEVMSdOVElSJUCRC IUxLj2UC8qZOnghFEKWL1Ev8kzlAmE4BDLeU27zUCUxlOpTPd5pt/ihElIuPxSpSQv8ANLf2Qtyb d4I0pLvKW8oW5IkQlSkhsKXqxqgkpiUaUnNpTCwlAnzSJ7pUpP6pS9VV9yW5KlNg2lI2qvvPgmLi lwqbHqpeoq2qW7zR4VNn1UxsJVeSn3GEqU2PUKXqFV92ibceyHCps+qU/rFVd5CXqEpcKm16xTeq fFVt5Tb0eFTa9XzS9ZVd6W5LhU2vVKXqwNSqu9Ld4pcKmz6o7FL1VW3JbilwqbHqnxTG4+Kr70vU S4VNk3FN6shVi8pF3mlwqbHqFMbiFX3/ADTbkeFDY9Yp/WKq70xeexS4VNv1R4pvVVXf5p94S4VN n1UvV81V3FLelwqbXqnxUfV8FW3pbkeFTa9QpeqVV3aJbilwqbJtKXrFVtyW8QlwqbPqlL1Sqoek HJcKmz6pS9Q+Krh4S3pcKmx6pS9QqvvlOHpcKk/qFL1Sq5eo70uFTZ9XzS9YqtuCW8eKXCps+r5p ep5qtu8029HhU2DaUvUVfeUt6XCpsGwpeqVX3/elu8UuFSc2+af1Cq25OHapcKmx6hT+oq+5PuSp Sf1D4qQsKrbj8k4cQhSmyLSpC0wqwepbtECFP//S7bp8nAxSOPRrmf6oR3SEHp8/s/E/4mv/AKkI 3bwUkvmPmhhPioHyUnHwUDoiFLEqBJTlQMpyliUMqRUCnBTEqMlOZ+SjKKFiT4qJKcmSouniEVLT 4qBKdwKiU5SpHgoEhKVAoqUShknVS81EwnBDA8KBPZTMGVA/kRCliYUSU5AKiU5TEnumk9kiNVH3 IqXPxSlyZKfkEVLgnuouc6JCR5mdFGZBCSlFR1TqMH5IoX1SMqOqXCSl9fFIk+KZInSEVKJnumJj 85LT5qJKSlyfNMD5kpil8EVM5nvCQKh8UtqCkkk8JvdMJogJtUlLkxymLj24UZSBgeKKmW77k++P h2UExPZKlJN6W7XlClJKlJd57J/UQZMJT2lKlJTZqkX68oTZ7lKfBKlJJBHISLvNDSKVKXnXlLeU Mp5PbsjSmW8pF5CgTKWqVKZ7u6juTElRk8JUpluhPvUJhNIRpTPeU+4lDlNJSpSQuKbeeFCUhMpU pJuPdPu04UJTbklM5jVKVEmU0pKZz3TSoSn3JUplPiUp0UNycFKlM5KaVHd5pFxKSmROibd4qMpJ KZbk+4eChKb5o0pnu1SkdlAEpApUpmHJboUCUpSpTPdKW6FCYTyEqUy3J5UAU86oKZ7kt58ioSl+ VJSQOBKcuB4CFKlKVKSSCNPvT7vFQDk+4oUp/9Pt+na9PxP+Jr/6kI7ggdN/5OxDwDTVr/YCsHy/ FSS+Y+aERCgUR0yhuHgiFMDCg5TPgoOCcFMCoFTPioO0n8AnBTA8KBhTJJ/uUDM+SIQxcY81ElOZ 7DlRd5pymJJhRPxTkT20THTj5IqYEH4qJAUiD2hRMlFTDXwUSPNS0UXDsCnBDAqDgpmVAwP4pwUw mSon4KboUSipgUxhOUx+PxRUxJPySk90iJ44TaR59kVL+3g6pi0JiDp4JEGUlMdBymIPinKieUUK +fwTEeJ0KdMZ54hFSvnoowdyWs6lN8eEVLz3SkKGpPknnXzSUuefim1CUnvomHwSUyTz4qPCQP8A vSUylx76JidNOExBISmdPBJSpCaW+EJiPFMTrMoqUXT5eCU+KRhKQElL7gmMpD4cqJPikpePNOPB RCZJS5PgnEpu3imklFTL4JtTpKjMalPI+aSlTqlr2US7xCefBJSwklLhPPYKJ8UlK3T8UpKb8qc+ CKlwmKY6J9eySlTokAmTpKWOhS54KUJH8qSl50hIaeabQeaU9uElL99PuSnVRPb+CX4JKXLtRCUg 8JoA17pR56pKZHVN8EuE3OspKXP4+KSSY6apKXmNIT7jHChoOeSlIA14SUvOnmkTr4KM6ym0RUz3 Af3pbhPCiPimSpSSe6YkKMxEhPp/ckplITgeIUA6fgnBKCmYhOOPNRlN8uO6Smc9klGSlwgpn4/g n7a6FQJPZLdKSmWmnj3UtJ8vFQ3GEpj+9JT/AP/U7jp3/JuJ/wATX/1IRzxCr9M/5Nwxx+gr/wCo CORyFJL5j5lDAntKEedeUQnxUHfciFMCfvUHKZHnqoHz5TgpgSoOUzKhxKcFMDwoaKR8k0CPDyRQ wJ0QyZGqm7yUYTgpgfEqJKkR4woGeyKmLuAVHznROSokkCOE4KWmdeyjz8kiRCjwihXKjE6d1LzU SipgWmdQmc38OVInuokiIRUjcPJR26Ipn5BRMnunKRweUxIlSIHio/l8UVLHjxHkonX+5PJkpbgP NFTDyTEx5qTjOsfJRSQrtqoye3BTmR2S/BFS0fgo6FOSSmKKlo8DKY/cn/CEx/BJS8CJBlR1ITmE pEcwkpWh80j5BMSD3SkQipk1unMR2Sjw9ybcJ1Kbn4IKW1S0PdInT8iYczwipfSdFGdOEvPskSPk ipQLY934JHb4mCok6aflTfkSUz9vilp2UCfLRMXJUplJ+YS3OnQKMyEg4dzqipeSeU25IuCjI1SU yJ1TTKafBNKSmWqYuM8JAiR4Jie4SUvLu/Cc6gJmnRLU/BJS/kUh8U2vKRSUylNqm4S3dgElLyUv ilymkTykplpylqmEEJEpKUQl20STFJSgSkY8UjCbSUlKkzJ4T8ptO6QgBFSpPZPPB8VEylqkpaTx CTjHGninM8ymPySQsTPKXkExCcaIqXAPdIGSmJSBjRBS7tFJugmdVGSOyQ15SUoHUDgKUumI0TQC dU40meySWXHglIKYFvKQ+9BS+kJCSY4TEa8ypageSSlhIMJ5Ex3TbtYSCSmR41TCfkmmdUpB+ISU /wD/1e26ZH7NxOf5irn+oEeR5/6/FVumT+zcTT/AVz/mBWDHcqWXzHzKGLuPH5qB8gpwY8PNQdAH MpBTBxUHfCPMqZBI00UHEcHVOCmBHgoO58B5qZQ3QE4KYnzUD4HhSPmoEgcDVOCGBHft5qO6NOVM +aGfAIhTEnTw+5QJnjUKcQoOMpwUxMeOvkolOfioa+KKFiQo6d1I6KPknKYmEiR3Tn71EpKWJUT5 BO7x5URqPyoqWdJ1/BQPkpn4yoCdU4KWgDso7/ACfgkSSYhR1RUol0pjMpjHfVIn5IoWM+PyUCfA qUjsoHQ8IqXJ/wBQou+lrOnCXEnxTEmUVL/f8UxJI4+af/UpjqkpYwmSmFFxgTqiplPkE0nyTE/6 wmABCSmU+Y0TAtn4qJgiJTD4THKKmce7dPHCbdOpMJpBnn7lFzojSQUqUuSOSU28RzBTOMiB281E vkcahGlMxY0GCmc4SFHdAS3OOu0JUplPc/kTE8+CgXd5+Sf3Ef7UqUuEtToJTa/70tJRUyJ7KLp8 E0SY8eyWg5/KkplwmMBNMJtBM6pKX8zwlIGqYkeUpp8ePBJDLnUSnkD5oYJ00UgY+CSl9wnyT8nR R3A9tUjISSyJMpf66JvdGhURvn+KSkk6DTRIR4fJNJAgpp85SUy8ko80x8RqmB8UlM/ilyP70xhL RBS5TEx5eaRjwkJSElKMSoDlSOqYHVFSnapCANfxSS/J4pKXnv8Aimg8nhNrwkHEjVJC8wIhN28E pKYnVJSg0pJtTqkipcf6ynHxCiJj4JhykpnJifBLlMJhLSYOoQUybqSnJA4TCBJShvbuklcOb5iU 8g99E09kge/gkpeRwnBB0iFElPM/3IKX9seCRGiYE6z8gmJPxSUog9jHkkO8zKUyOI802qKn/9bs +mF37MxBqP0Nf/UBWSY4ElVumuP7Mw9T/M1/9QEfaSZlSy+Y+ZQo7nBQj71Ig9tVA7p4SCkZk6BR IhEiEJ0EpwUxOukqJ0U9AoO8eycpG5R0UtOQoOcPFOQwc4HgqE+akTJUXOCIUwcfMKHfVOT4iVCf JOClna6KHE6qRPyUZMc6pwQxJHYpgRMTqpEu8QoGZ80VKOiafESEtO6jp2MQipRcONQoF+ndIkA6 lNu8DqUaUolQ18lIuMR+JQ3HsiFKM9/wUCCTwUiQ0S7X4KJIAkSBHCcFLuE+Kj5SfmEw45OqY66T PmihR2zyPmo6R2PwS47T8U0s7gj4IqX17BRmDronLWnXgqM6JKXkn4JGR4Sm3Dso7/LVGlLz2PKb dI07Ji7XwUZ7CPijSlGTzwkHQIHdQdukfwTbydO/aUaUyMdylBB0iFEzEFskJjroQR5pKZktGpB+ 9Qkc7vOExJ7O48UiAWzIlFSxIDpGoKdzxETCYDSdwTEadikhlLjzHzTbvkoSCNdPNOSPzXfeipcx pCfUDhR3O8QQfJMCQTpKSmUeWqfcSY1ChI/uTiRr3SUy17aeZTQfIkppPYkJTPeUlL6gJEn4Smnx gpifI/FJS4PxT7v9SFAwNe6aUqUvqdVPdp3QxprCcOE6SkplujvHxTkzrMkcKJd5lMdDPPjokpnr ElKSTpIUeR2+CbfGn5ElM+dDqlt1kk/BRa4g/wC1Ld58JKZfNOBPzQnklM1xGiVKT6cQmPM8BQJ/ 1hLe4DxhKlJBASnvBUR7h2T6+HHmglfzSkcgJuOUtOfFJCp11TiIkcpu/inPGiSltZlL+KZsjunM nXt2SUo6apo0nukTOnKQ0PCSlk0qROvhKjyNNEVKlLRLjzS41JSUvp3Kl7RoonhLzJSUzEeZS3T/ ALlEQIH5VLt5/FBS06qWvPYqOg5OvZKSkplImddEteU2qca+P3pJV5ymmQnG6P4BMAeSkpUkaJQ7 nsnPiO/KhJlJD//X7LphH7NxIP8AgK/+oCskgDVU+mQem4ev+Br/AOoCsmVNIeo+ZQxe7+Uo7vNO 6IUQPApKWPB1JQnA8wUV3Hb5ITp7FOCljH7xUHAeKkSR2mFFxb3EFFCNxAKiSDyU7iAh7mnUpyln ASoEgeKk4g8OgoZB+/unBSxcOIUS6OxSJI0UCXeCdSlnP+/zUC4H81JxPh96juTgEKkqJJnjVLcC OYUHETo+EVMjvOsIZ3TJCRLvzTwmDnxzyipRPMiFH+UYAScSRB58E35vcBFSiSfonRRdu3aJTp3U XADUFFSxBcYIEd0xEdkxBOoOndQO4DQ6JyF3RMSm0+7smB8TPyTO2gcaoqXkxM8KMz8E8N81EbRo kpRA1GijIAkhLb4lMHE6Qipf2nUCE2nM6pcOkj5JEtMiIRUsTAJBQjY4GY0RAGjXlQcQdAEQpZ40 lMAIkt+abc7w4TT3/BFS/tPaE3HcymLz20UZlJDPc7iRr3hRJ8U2vYpGUVLadikeUpPcJEaeCSlw PIpER5fFMTHCckx5pKU0+KfcSU2vfhJJSp15CckjwKj30TxokplHkE3tGpOqbVI+aSlyR27qIJPm ngdtU0AalJS8mNVGRKfQpgR9ySlt2qQPnCW4eCYkHtCKl5d4ynknumkDhMHAclJTLjklMXca/gm3 T8Ei7SCkpfdI7fFM0aqIcAnDgkpmWFIMI1UQfFOSO0pKZe0nkp9YiUPc7slvSpTPfHImE+8E+AKg NpHOqiJnxSpSaQe8qTR2kKAmOE/xEeaCmUjulp8Ew8AE5bBlBSidU0AjwSDmpE6eCSlKJ0T/AIKI JRUome6WqafgnnRJSkgT8k3wlLUCB3RUvJTglRny1TjRBTPw0+aadNAm0OoKfRJS8tTw4Jgn/FBS 8mI7KPwCUgnVPokpeY1CYk8jRIpifBJSteEvmnB8VEkSPBFT/9DremPH7OxQRxTXr/ZCtbwB/sVT pzmnpuIOT6NfP9UI/taJg+cQp5D1HzQp1tffRQLmOOhlSNlXmD5n+5Qcaz/tk/xSClaDtHnKiZP0 XD5/7ExcAPaPyIf2gElpER3TqKly147/AJVEveOYd5Ji9pOh58lB7nDhp+OiICGRmJLYQbCPL4HT 8qi+18d9Oyi61vcJwClEtPaAO4UDHYj5pFzSJMIbiJ0bIPMBPAUu4ef4oR3SpOI4AhRIPhKIQsXH u5Rc+fAj5/7EjuHjCiT2iT4pyljxxA8/96g4AiAR+KkS7z+5Q3e7UaIhS0kNgt+YH96Ybdeyfd8k vLVFSx8AD9396bgazr8FEjvKXu4H9yKmLnGQAfuBTOJ1ghIgzrM+ZTSI4+5FDGCDqdfKUxLtYmPj CdxjiVB/EoqUXSdWjTuDKYkHsfkkONefuTFvf8qKliFEmPFPqNAfuSkjmSipj+bPE90gB2PHeE+8 EQQEvaR/BJTE66z81EHXQgeaJA/OhDcAde3kipdwd3OvioHcOPwThsc/lUDM86IqVucBwU2+PpN1 SPj+VMXfBFTElvmEwg8FMeUjpwihRjslKaT8UpA/NSUuST3lNrPCRITaeaKlGU+saym18U8u4nVJ Spj+5PqfglJjjVITxygpXf8AuTGQUoPwT69zKKlAeOiUax2T6z4+aR07IKYzB8k8hLQptAipXwIT acJyR4KGk+CSl4S9vmmTk6SkpR2+KjI7FLzSg+CKlAHyTyB2+5RjxCUgdklMpB7FNoEtO5hPxwQU lLSPFSMRpymgnwSjXTgJKXAS2+OiQJI4Cbd2I+aCmTfik6ZhR3CONVIlsJKX2vGsyPBSBJ/Nn4FQ kccfBPr8klM9xB8kznGdDp5p2kESdVHcBo7VBS+nYySol1k6ajwKfewEOB+SRa06jWUlKknnQpHh R7xEhIkHsUVLmfBR+KfTTVMTr9JJSpjnjyS9oPKcSe6iT4wkplIHflPB8VHnmPJSnskpeHQlJjUB QM9pU9xjukpee0cqQAjkIc+Sf2+JQUzERomJE6mE0DmU4k6iElKcY/hCeQRqowZ0jRPLj+bASUv2 0Ue6eI7JdklP/9HqOnBhwMXifSr1P9UI1geDoBA7qn09xs6dj7ZbFVbZ3AfmhGbW5oI3NcfPX8hV oj1HzQkY5pHugntHCciZkAeUygPr1HuDe+kpzUTBDnmPBv8AtQod1MthGs7fkoFxn6YP4KLtD7on +VuUfV/lN/st/vTqQsXMB9xE/GUvUBENkpOtAHJPidoCEHtf3/FGlLusA5aPmVEPrdoB8dJTlw4i PmFGBEmB8wEVLOc0ccBDce8/imcWz2EcjlD3axAjx7pwCmRd4kFQc/5qP0QQAfvUDY+YiE8BDNz3 fugAeKG64zP4BQNmsHT4CUjaR3BnxBRpS7rJ1OqgXjmI+Cj6reNJSJJ8D8EaUouDuCR8VEjTxCRA 7td8dISAb2AhFS0mYBj5JGfCSnIcO5+UJg1x1BiPEhFTEh0TMJiXBO5zhoS0qO490UMSCe0KPbUh TLxH96iXuiJ08myipiYdpKYg+EpTr3PyhLXmAEVLGRqJnwTSmJ1jVNrxBj4IqXDZ7wEzmQm2u5Bh Il370pKY7SOPypEngpy+O33pt89xHkipYwNPyqLo8UjB8VEjwRUojzlNrCREcn7lGJ4BRQoptE/x TGPFJS0jxSS2glIjzhFShzqlwU0+cp5jskpWkT3SEDlMSDp3TwCkpQgpwCo6TEpyIOqSlOdBTtIP KYNkzEpwCPLyKSl5+SfUCeyYlp8vgm7QEFLEH/cniBqmlw4KQ11lFSlEtTwokjwKSldkxlIptRyU VKhLhLd4BNLklLyfFNJS3eIT7h4BJSgfFPp2EqMgp9I0MJKX1S40UTKQJ7pKZSRol8U2/wAU/KSl wBzCcQfFQB8JTgOA4SUzJb4JhE+PwUQ4hOHwgplrOungkREGUt7TyJ8EgGd5CSl9hglsFMQ+AOEp hsCI/FNvEREQkpfXk6R3TFxnUE+aju8CpDd8fNJS0jwS08NExLhr2TS48IqZAxwlqfgoy8cnRLeO 4+5JTL2g6pwAoEsPYpwWnySUzgnQJDcEMgNgjX4IgnaIKCly88FIOHfUppM+4wexKcamdwP3JKXl h7QkR4EJizwifJLUGC3RBS4nyKcyDB0UTI/NKQJ7tKSmWspeaaWpEt/2JKf/0t7CafsONDGA+lWd xmT7Qi77RJDmx/JaUHAyIwMcbAC2qsFx14aER2TjkEWXf2WBXDfEdOq1m57w2XlwnuITEPGobHiS 6fwlDNmL+aC8+LimdbY3QBkeJSpS4yQJ3uLXT+a0fxUheHcB0eQ/uQXZTgI3N+TZUDcH/RL3HvGg R4fBSQmxzj7BA7ka/ihlw/M2g9xtlCc+76PuHxQtzwYkApwipO+WiSSR9ygA130mkA95UPUjQgu+ 9L17Bo2tOooU8hujePgoeq8H3EgeSd994Euho+CiLnO5IIRpS+4FupjzJKgX6wHt/Kk4te2HBxCi GAatbt+OqKl/eefo+QCg5odwI+JCk5xiC4/JqDsa46kyiFMhW0c/NRLGuOhnwgwl6bhw8H4lRLSP pO+5H6qXLI0LSfmonaNIKjvf2lSl576IoWP+uiUu/daVMvj/AGIRcZ/hykpfdrwJ+Si92mpS3aat gfBOHNI0KKkXqgd5+9IuJEyncIPP4KDgDrB+KcpUSTKYbRwE0GPpwExbHJJRUuZjgfMqJA4Ij4JQ e0KGo+kUlMhAOmqaHjWE0jxJSJ00lFSziTzPwS3kaQE40EuSJZ4pKWJnkwoSFKWRACjr8PNFS0aK OqTp7mUwPiihR8Sm3DwUiZ4UYHdJS0/JJMSB2TIqXIS45S1SkDjlJS8jVMDqlu8QnHwSUrcO/bsn BEptDon9wOmvgkpfcfFMd3fVO0n4JEnugpU+XxSMkcwmmDqnLhxykpRAjn4pp8kxgcBNIiO/gipW 8d00jxTQO5Slo4RUrVMWjk6pEzwUx05SUv7eyaJ7pSPBNKSl4KSZISkpXyTy2E8n4ppSUoQnhqUh NISUygdimIISjzSkeKSlagKTXOTGOxTQQkpI1w1mJ8UzuZQ4JTx4pKZFzZkjVLcI0mU0AcpAgcJK WnuVJ0kSnBrIgkyouDexKSlCI7ymIj+5IjSQZ8lHVJS8FPwEwlIlJSi8nQpDXWU4aD3SDQZgJKXG ukCVAgykYGndPoOSkpdpPGhHgpe390FNv8IKW4EcAHxSUv7OYj5qX6MjwUWtEe4fNLa094QUvtYf okhOGngO/gVDY6faQVOHd2keYSUohzeTz5yn3O8QfIpvYeSU2pPl2SUzLndwEiTymmNdCo6kyO3Z JT//07+IbHYdALmsHpsidT9EKTt4MF4nwA/2JsOwjCo9Ol0+m2TOkwE+6zcS5kHxMFaJ3PmsUDJ4 L/hol7uRUTH7xkflTaDVz9s+An+CZ5aQAHvfPPISUza4xtG0O8AJUS5zZm2D4Af7E7WbT7BuPx/2 pPke5zm6cjT+9JS9d+3UNLj4uUi/fzUJP5w5/Koh2IR7nGe5AQ3MxHCWPdKFDsVJXO2CDI8II/hK H65do0E+Zj/YohtterGFw/lBMbXGd7Wt/qjX7yUaUlG6JLWmfEhDsBGoLG+cj+9Ce6kjuD4lDb6M 6RPiZ/uRAUkc6saOO8+RKG41zpunwU4eBo4R4wVD1OQ94jtpKcFLevt0DPvKhvJdubAPgNU7nUd3 F39kIZNbjDG7fMlEDwUyD3CQGfEphY7jaouaQdHyoe0fSeR8AjSE++zkiFBzg468+AhQ9Op3G53y Tem5slpgI0FMoA1II+cJocNQ4NH8oyoOfZIBcHA/cmIfoS0EeSNKZGwDmyfgNEPe15Ikx2I0T+p4 sGnAhM4juQ0eEI0pW2NRYPhyVB1rgNHGPgkRS3Uku+ATixkaNRUj9TvuHzSNoH8r8ik62s6ED7k2 ysatPyKP0UwD3HuQPJLeB3k/emeXAHsPkoNgagwT4IqZl7D4hNIJ9rz80xBdyST4pnVtBgkykpR3 g/Sn70twjVqiWujSU+6wIoXEHjRMSe2qRnulAHKSmM+KYv0UjY3hNII8ElMA4lPoeyeGkaKJAjRF Skts8hNqAnlJSiAOxCaT2SkHnVLd24SUvM8tSH3FMeZCiTrqipIGmZ0JSh/Okfiohw4DoUml4EAg tKCmEOlTlw7aeKbc4HVL1G9+UlK3nv8Aipaxx81AkE9/kmMcCUlMgY5SmVEeTiCncSREIqUdRwFG G9ymG5MRCSlE+CUEpjKUlFS6UhNKWiSl9E6inSUrhLVL5p0FK1SBCYpSUlMufNMQE0p5SUuBI5TG eJS0UhPYpKWHHISmEjPcJa8pKX1P+1MASn+BTT8ElLGB8UplPp30Tw2O8pKYw1NHZPomgJKXAce6 RY4cpRCbcfFJS+sdk0kJ9z00nuipUmZKkLAPzVH5JBJTPdWfzfxSds7AhRG35pzEaFBS0E8FL3Du nlh5mU4FXefkkpUj4/KE8jt+VNFZ4JHxTQRxCSl/ceE4afH+CjL/ABUg9wHCSlAwNZS3u8NEhY8p 97/CUFP/1LmGSMWkm6Jrb7dNPaFNz4M/T8Sq2ISaKoq12N92ngrPpuePfa2oHz/uC0iNSsX+0ZB0 a0bfgo73iN8adkxoxh9LNnya0lCfXitEte9/mWkfxSAH8gpIfScfpbT31TClky0GxDYad0Mrc53w EKb7cms+x2wH4BGj0/FTZDrAPbj/AOcEKy+0+zYys94Gqr+tku+ldp3JcgG1ofBO7zElIQU3Q17/ AOde4jwCa2tzR7GSPNV/tEN2ta4n/XzSBc8HduA84CNFTIeu6Dt0PCT67CN9jw0DwQnPY0QHGfGU IuadS6fmiApm/wBM/Re55HlCiLI4bJTh9Wh27ipeqD9GsBFDE2PI1rB81Evj6TAEUutI0G348IFm mryCfIz+REKWD2bphOTWdSfkELfOgb84KeGnvJ+CNKZb2cDcEo8XEfFMPUafaNPGFE2k/wA4ZSpS QnHA1LnHyUQ6sn2+34oRfu0aPkEwbbOjT90o0pO5zjwNyC9zASHM/FS/SD6bXH8FB8chkfEpBS3q 9g3RMX6fzYHmn+0Obo1oUPUL53O2jwATq8FKJrjjVR9WOBBS2Ncfa6R8ExqdOmv4I6IW3gmXSU/q NHDRPmmNbx/s1SLG/nEjyS0UoWO7EBRc90yTKW1naT8lGHj80wjopf1B3Tj3DQEKEOP5vHkkCBo4 FFSSCOSmMHSVElsaNPxUJlClMyO4A0TEnuEwaeU5c3xRUxkeKUHsU+h54UXDwRUuZjUyok6+CeSB Gib2HlJS8gHUylIgpiGgaFNuPCSme1sSoEGfJNInWU5cfHRJS42jQ6p4B0BhMHwNRKaQdAElL7HT qZSOyI4KRDo8vJRiOQkpm0ECWnXwTGxxOqgY7Ja+KVKZ6Eyn4EpgYGspi4eASUoOcOOExJKcOEJi kpR4TSEoThFS0JQnJTQkpWiSSSSl0pSkpikpfcUpCZPLUlL6JaJtE8DxQUsPJPJCbalqkpcGDqn3 KMHlKUlLme6QKU+f3pSeElKJS14Tw3zlLUBJS0QmKfQpASkpinTlqaCipRI7JJkoSUvzwkkkkpXy S0SB8E5MpKUI8E2njCWifRBSySlA+CWyeCkpTSQdCpbi7nlRLSCkBrqUlMpcDwEpI/N5Tho+XxSg 9jogp//VNjVPOLQXWQNjYAA8B3KkaaxqbCT8v7kLFuoZj1BxLvY3SfJTdexxhjAPjqtQ3ZWLElpl rS75wkcvJLdm3TwJKi+28iG6DyCQaXD32FpSrvSl2WWDV0AjwBTHbYZLvuCbaGnV5j4qFrqwOZKN KTN9Fg1Oo/H8E3rkiGUAjxJKq7rIlrR8U7L7QYIIHeEeH6qTP3ke6GHsBqoNbOhIUwKnCXOdPgok Vjxj4pKWexjBMB5PbVDBfMiuFI3tZ9FoJ8Tqm+0W2aEwPgjqhG91hMaN+ahB7uCPtYeQSfFRhswG ElG1ITA5M/JO2xgOrd34KTq3clsDzKg5zOANUVM/Xd+aNqG1zgZBAnlPtES4p9tBGriPkloplvEe +D8k3qU6wD8oUC2kcOJKhoOyVKUSd0tkKZssI1cobmjt8pTSO/CNKZgs5cA4+ahY9pjbp5AJOLAB A1UAQDqEQFLHcfoymId30UzYToNFEmwcFFTAtIUQQDqJRd7o9xJQ3OB7IoWLx2EfBIub2H3pbCRI GicVOPZLRSzXOBkFSdkPPl80xY/iAo+m7xH3paKWNj9YcdedUmy46pzU8dwouBCKme2B+VRDQdZh Qkd04NffRJTItb5lDI104805LeyW4cEIqVtdHKiR4apEzwm3FJSte4S0TtJJ4lI/cElLT4lLdGoK aJTwEVKLyeefFPLSNdPNOG1nmQkatJDp8kNFLAtB8VIlpOh2/BDLHfJIgdpRUzgzz96UnvHwQ5IS 3GUqUyPOoj4J4HYmfNNuHB1Tj0+4MoKYmQkI7hPIE6JB3kipUR2MJSOwTHcUuOUlKTQnkdk0pKUn TJ0lLJ0ydJSpT7k0FJJS+nilHdRT6pKXj5JR5ppPdJJS4kJ9PgopwQkpfXxTyO6iSCfBIR4oKZae GvilMDhMITcpKXEHk/ekY7JoT/ApKVEJphOZ7pklKKaCkkipSdMkkpfXsn4GpUQkkplI8EtD5JiE oKSlERqnn/WFEApzKSmQA7yPgmPkU3zSAPggpcGPNPqdYUU8nxSUrXvol804eRzqn3DwSU//1q9F tTaaxMu2tnTyRw8ETvLfLb/sVfHuDaWAOg7R4eHwRHWucPpuPlJWuRqxsjY6dNxHidE42n+cc0eU k/kQgyxwnWPOVAhg5elSm1vx2CZDviChuto52x8AgggcH8B/FOLIOpj7h/BKlJPVYQQ1rye2ghJr LngkA/MpC25+jSSPCQAkHZDCY0nmdUvsUxdW9v03AfNQ3AnaAHfIohsaf5xzXHwiPyJDJqb9BrWn x1P5Sjr2UxIePzQ0+EJtl7uGu+QUjk3P0a4nyA1/BMftLhBkDzkJa+CmG23iCoyRqXajzUxQ8nkD 4uUXUBp1e0nyJKNhTEvJOvuCl6zhqxjWx5T+VQJa3QOlNLiJEwEaUzL7HmSPwhN6tn+sKHuOmqWz VKgpcRul4JnlSL6AdJHkQhkAfSP4qJPhwjSmb3MP0RHnyoESluHBJUgxk+4n70tlI5jnVS9jhyB8 UQto/NbJ8ygugFLdSi2BIM/JJrbXfRaT8FEPjhNvPiUULuY/ggj4qHHZOS7zTEO8EVLFzkxJShKP NFSoMTKRa6NeFEz4pAkpKUCRqn3g8gJCJ1k+QTOB7CElKIadeFCB4qQP72vkpbmDgIqRJGfBT3AE pi5vhPxKSmCUJyR2EJkVK17JEHuklJ8UlK1SlLcfFNKSlSluKSUJKXBhKZ41+SaB4pklM5d4fgl7 e5AUY08EjPdJTKGn85RLT5pk+93ikpcA+CcjvKbf4iUi4HskpafNIHyT/CPuSgeMfBJSoPgmSSkp KUkkkkpSSSUpKUnlMkkpUpwYTJJKXlLRMkkpkmgeKXCQKSlbUoIS1PdLcUlK1SgpAjsE8n4pKUZS TTKQhJS6SQnskZ4KSlSfkkUySSlRGqSUpSElKhPMd0hqn2wJJSUsZPgngAcmU3t8SnAJ4QUrfHYJ aHyScI7JgSkpeBHITSlMp4A5SUr8Uj8EgY7J5PjCSlvxT89uE0eaeElP/9evS0GpkAn2j8inteR7 W/OUGm5raWDUnaPyKfqvP0Qtgg2xsvTtcI3QPCUjisa0OdcwT25KjN5EAKIqd+eQPmlr3pTL9GzQ P3f2U5Ad3/BJjKx9J4+9H9TEaAC0/HVAnzKmsWuH0S5NseeTPxKLZdQRDGfNV3Nc76LdCiL8lJmU 0RNj2g+GpTEYwPtIPyQTS8chO3cDMAQjXipssvsb/NgN+ATOyMh+mrvkgG4jTdPwKZpc7hwHxKHD 4BS723PMOBH3JCkN1cJ8iVF4eNdwcfIyhguPITlJh6bSSGDy14UXWE6cDwTCOXGPknc+uPadfCEl MBrzomjXQp9jgJdoD4qIEu0KKmRr7qMeCd4I5UfPUpKXJcPgoQ9/AJUy4xwm9x5kfgkpGWunUapB pJiERzXR9JCcHdtUQhltHGgTEAcKEEJpI7o0pL6r2jaNB8FE3P8AHlQknxTEGEqUuT3lRLpS+aWi KlD7k0p+eVEgBFS+ncp9OzlEEeCkdpHgUFMYZOpTuFXYqPmAmMoqVomKfT4piipZJJMkpSXxSlJJ Sk0p0oSUqU0p4HiAmjzSUuNVLQcuUEklMjt8U2ngm08E8tSUtCW0pyWdk0jwlJSiITSnmEueSipa U+qUDxS0QUpPITJJKVKSSSSlJ0ySSl0kySSlap00wnkJKVKWqUeaYJKXnxTyCmgJvgkpkSlqowfF OD9ySlzCXKUSlDvgkpQCUJa9ymSUvqO6UjxTfNPqElK0S+aXzTfBJS+qaCkZTgiNUlK+BSTadkpK SlylKcOEeaXmkpQJ8Uts91IFsaj8EoB+jogpaSO6fc5N70iXDkpKZS3uEiW9oUdxTgt7pKXBHcBP 7exUTHZRSU//0KFL6/TZO4naOPgizWeZ+9CrZ+iYS4D2j8iloPzgtksaUMa4aNMeMqDq2t1Mx4Tq m9QAcSoG0HQNSoqZbmA6AjzJTbyfGPLVRkxAEJNa7gGPFFSRtr+BuPlwme46SSPiSmhzdZhNvjwK FKW3OOm4/cpioHgz5BQ9V86GE8uPfVFSnN2mCI8kwa7s1OA+dBqitbkAS3RK1MNlgGrSEJ7TP0Si WPtn3k/eotsjt80hamBYY1+5IOLfD70QGg6vaT81CzYfoM2j4o2piXudy6fikAf9yiGnsE+o5CKl juPJkJwXt4EpbvLRPurH5xnwASUvJI1gKDmmdPypTPEkpiX+CSmJcQdZKQsdxqFMtJ1UNUUKknzT Frj2T7nDSYUS5xSUsYCbdokW+OqbTwRUsZ7pJyRHmkAkpW090xgDxT7XKMeJSUr5JQfJMYS08UVL QfBMQUifNIEf70lKBKYk905ITIqWSTwkkpaE+iaUklKTfNJJJSkkkklKSGndNISRUykeJTEA8SmT yUFKg+CUEc6JpKUoqXMeKZMnCSl9PFMngpkFKTymSKKl5TJBJBSk+iZJFS6ZKUklKSSSSUoEjhSk fNRkd0tUlLklIFIT3S0KCl9w76pyR8FGAlqO6SlSn/FMZShySl0uU0lP8CkpUQlwkCU6SltCn1UY 7pSe6SmU+KWnhCiITzHCSlEHwT+m+JjT4qMqYPnp5pKW2uHgnDiEx11TbgOySmW937yW554JTbm/ upbXdgkplNg5lOHjuozHMpe1BTJzgeB+Cin2jkSlqeUlKnylKW+CfaPFLb5pKf/RzmA+mzTlo/In InxRqnPbQwC9rfaPbt14QnNdP84SPuW1erGpuh+iSnhs6mFGGgavcfgkDSOziUlJQMZvL3OPgAoO cyfaD807TXOoA+ZKdzq49sH5FD7VInP/AJMKOpUnWOPYAfBMLXN4IHyn8qcpdrHeSTnPH5wUdznm S4/gE+0DkkpKW9R/Z2qmLnRBcU0sj6JPzCiXN7MH3pfRTL1G+EnzTbx4KLYPaB5KXs4hJTEujiEh ZKYgdh/FRMIqSbiOyRf5KIIHAHzUhJ4c0IKYboPCRhx1TugcuB+CiXA6AIoZENHB1UNzpT7ZOp+9 ShoGhJSUjLnHvCj/AGlONeEjPiPuRUwHxS3AaDVS29934IbvjqkpW7wCUHum47pfiipYgJAa+CeD 4JjHwSUo+SaAeU8BNEIqW2/cnkHwCjI7hIkHskpTgOyinmOE2qKlJFMn07pKW+aWifRKElMdE+iR CXzSUsmT6JaJKVp3S9qSSSlGOwTJapIqUkkkkpUlJJJJSkkktElKlJJJJSkkkySlwkUkklKSSSSU pJKUpSUsknSSUslJ8U6UJKVPiUgQm+aUpKXlS+HKingjWQEFLxPPKQMFKT4paeIKSmW4eCjz4JCf BI7klL+7ySOoTc/7U+kdklMeE/yTc+Sfae5SUuA3umJjQcJgYKffPgPkkpkGkjQhR2kdk2qQJn+9 JTLafEJCPAH5qba9wnc1qQrBH0vwCVqYFjvBKCNVMteONfuS1P0tB5pWpGkp7W9iEiwDvPwSUsCf FIEpQ3z+5IAdikpnIP534Jp8x9yYthNEoKf/0sxllbWgEyYCb1mg6CfkmrDdjfgFPQcLb0Y1Cxx/ MJTiTMthSDnRpwoGxo5KClxWeyYseOXAJjYDwokk9kdVMo/lSouTg+UJxCSmLRrqdEUNaT4BP6zW iA0DzSN58ENVKc1nZxQjz3Kc2A94UmtkEl0I7KYgnwhJ7g3vJUTBMDX4py1o5SUxDy7TUpj7TqpG B9EaqJE86ooXkHkJ5YOyhDfNKG+aSlw0Ez2TvFYiB+KbaTwDCgWOHOiSmWo4KUuPKiCOxT757oqZ DcmcHDum18EiSe0JKYFzjoCmLTySnI8wowfFFS0JCeFMNB7pbAO6VqYS4aJTKkZ7KMpKWlPI7pSo 7iTGiKlOI8FFTLT3hQKSlEBINHcpJkVLkN7KMp4TaJKVJSkpQEoSUr4pkkklKSlMnhJSyeEkklLJ 0kkVLSkknSUskklCSlJaJJJKX3FNJTJJKXSTJ0lKSSS0SUsnTJJKUknSSUqUpTJJKXTJ4KUHwSUo FKfJNokkpeU4JKjKSSmUFKIOqYeakC3xQUvuHZKfkmO1RnzSUyOqYfDROPLVIpKYyE5JPAKfZPAU geySkcnuFLc3wRIJ4Cg6t54StS4A8AoECeyWx7T2CI3zhJTDafGUgC0+4Iu6OAFEu3cj7ilalg8d gUj5SnDY1mPmn9ncygpi0E8kqUgaDX4pQ0agEp9zSPD5JKUH9tExdHeU7XA6afGE5akpgHlTGomR omc08RHmm2HxSU//08pgdsboOB3Ug13i0J2D2jXspEDzW3bGtB7u+5IMA1iVEvjsVE2PPAKWqkhc B4IbiJkz9ycPsH5o+ZT77D2aElMQQNQ0kp9zz+bCaHnUuj5JE+LkVKgk+7QKTiwCGtkqPqNA+km9 Vo4SUtr4fgpifBQNx8CU7XuP5iSkzTWD4lJ7hGjVAOI/NAUTDuZCFKXh577QourPiSmLQPFMJnif mihcVdz+JTEa6QPgpyyNUxY3kJWlHuITjcfzfmU5AA5hR57lFDLb4wkGtGqdjHRMfek9zhoSAgpc EHQD7ymNY5KiHujQqJLjpJKNKZkMjQKJA8EgExBHHCSljHbRI8JGeyaCEVK3MSMHhLQcpFw7JKY7 YUSYKkm0KKli4kKBCIWeajt80lMY8FLtrokS1MipYlJLRKUlLJJJQkpZKE8JcJKW0STymSUqUkoS SUpNonSlJSkpTSnSUqUyWiSKlJJJ0lLJJJJKUmTpQkpSZPCSSlk6SSSlJoTpklKhOkkkpSXzTJJK ZQExaPFLcQnB8dUlMfmng+KkY8Ao90lLJQnClAKSmMkJpKkWBKGDlJSgXFPD+4SBA4TxKCle2OSC kASn9EnWU20DklJSx3t8Ug906T96faDz+VIho4ckpmIP0xHxSig6d/ioS7sUmteT2CCkgaAIBSNL uW6lN6dn7wTF1lfLgQkpR3jkApp+P3hTbew/Sb81P0q7BuD4SvupFvcOAnBDu4U/Rr/0ii6mPou3 JWFLtZYfopi14OoEpml7Oyl6wOjglqpRL41hR18kVpq5J+SlLTxwhan/1Mmtzg0e4RAhFD9OZVfd RyeTqfil69Q4C3CGNPqU4AjUIHrtPAcU2+w/RYfmlRU2fZ4BRJA4EoIN58AnAs7u+5ClMy4uEbSo FjifoqQGurj8UpaO8oqWFZH5oRIJEbQFD1GjkhMbmdgSlqpmWHyHzTQR3CDLnHQFOQ/jalSmRJ/e SBH76iK3k6BTFLu4SQxdt/eJTQIRPa3sJUHPHjKSlAEJxryYUN3l96W5x0ACNKZkNn6SbayZlMa7 Ik6DyTQT3KSmZe6IB0Udk8pCue5T7Wj/AHpKXFcd0400lRJZ80g6OCgpdwHkojTzTue4jhDBPgiA pkSmKYuS+KSlESokDwU9E0oqYFIHyTmE27zKSljqokQkSSeZSRUxSKlAS0/1KKmMlIkpzt7KJSUp JIQnI8ElMZSTwPFLRJS0p0koSUpMlCSSl9EySWiSlJJJJKVCZOmSUumTpJKVBTJJIqUknTFJSkkk klKSSSSUpJJJJSkydJJSySdJJSydJPCSlh5pzthKAm9qSlFyQcU42d0js7SkpcOd8lIGeVCQnkIK XITyeyjtHimh3ZJTOCR/FPPbRQBcpAlJTMAeICgYmOVL03O1kJCsg/7EFKawH84BJ7BEDU+IUyKo 9wM+ShsaNRMJWpEWuHina0HmVZa1saEk+B0TFtvYBK1ISxg/OUYjglH32t0eBCf1WdwPuSsqRB47 ozLWxEBMfQcJA18Aoh1Q02EFDdSX1D4fgn31Ee5oKGJPYqX2eRJCGikb/TP0WkKIaYkypGts6E/B SBLQWjUOEanxRU//1ef1BI8E4nsEUMpGrzr3SL8ccSt62Jdvq+ICnLxy8IBuZ+a0qG8nshSmyXfy 0xiJL1XG48BSDHnsUqUz9hOpJUgaQOCUzaX8kKba4MmEjSlt1f5rFLtoxP6obxCZ15KCVS792Pml teewQzY4pbnnujSGe20dwFA7+7khW93dTGP4uS0UiieSnAYPzkQ1MHdROweCVqWPp+JSBYOxT7m9 tUvV8AElMxcIgNKf1B+6VDe48fkSJsKFKZep5Jt7f3VCHdyn2nsUqCknPDYUSPOFJp2juVF0EpKW hvdMQzslp2SCKmJA7KBMI0EqDm6pWpjKaQpbY7qMSipUpaJJHjhJTEkJaJoJTgEIqYkKKmVCEVK0 S0S4T7vJJSoKYhLcUpSUqAU0JCU+qSmKdKEklKShJJJSiE0KWibTwSUtCSlKUpKYpJ0ySlJJJ0lL JJ9PBMkpSZOkipZJOmSUpJJJJSinEd9EySSmUM8SomOySSClJJ5b4J5b4JKYjVI6KW4eCbQ9klKB PYJa+ASjwTykpXwU2x3CHqlJCSkjoKg7XgJxqpECOElI4KkGvTh5HZP6rvBLVTEg+JTQexU/UPgl unskpjr4pc905E9oSAaNYSUoMBUtoHdOHRw1MXg8tIQ1UkbsH52vgnBBMAIQI8FNrGO5Jagpk6Rw RHghEOPgjem1uodI80/6EjQwUrUiZVYeIUy14OsJi2TIKYsJ7pKZbyBwmDmzJmfiomp/ZIY9vl96 WndSdorcOY+KY1NkQ4ROqCWWt51TiYMfMIV4qf/WwyMYckz3Cacf90lWG1NLQ5rOdZKRZHgFu35s SGWfm1FIPcOK0Rzg0xMobnkcBJTIOv7MhI+v30UfUtPeFHba7ulXkpd3qdymg+KkKLHclS9AjlyN hTANHcqQbX3Kl6bRyfxT/oR4IWpYeiPEqYdX2aVA21jgfgm9eOAhRSl9UDgKJtJ/NUPtD+wCbfaU qQvLifoyptY7nYI80Meoe6mNw5dPkiVMtoHgmg9gE5f4BRLj4BBLKbB4BRLndyE4d4wkXt+aSmMP P5wHyTms/vqJJPdO2slFDHYO7lINZ3d+CkKD4p/SA80L8VMPYPNLc1OQB4KOvj9wRUyme/4KJHmm LyO5Tb0lLFNCkdU0BFTAyE25Eg/JRLQkpju8khJ7JwYT7z2SUs5viIUICmXTyVH2+CIUtA7JoTyO wSIKSmOiSlt80xEd0VMU6UJQUlKCScBJJSyaFKUpKSmKSdKCkpZJPCaCkpSSSeSkpjCSeSkkpQKU pJQkpaEoUtpSkhJTGCltKefJPr4JKYwUk5DktpSUxTp9jvBPsd4JKYpJ9pTQkpZPKUJQkpefIJ97 h2CaEoSUy3E8qJlIGCp+qUlI4T6d1Jzy5RjzSUy9vglAPCYJ0lLhjki1wSgpw0lBTGE4lTLCo8JK X1iEo8kxM8JDd4ykpeSDwpepu5kfBQ3eSkkpk2udWuPwhEZZs0c0u+SGHOHBSIc7Ukyh5qZm1hP8 0U8sPFaFD26glTF93EfehXZS4GurYUnbWCTohufY7n8EmOcdJnyKVKV6zFMEEcpGtp0LBKcY+3WY CWilQPFRgTwiTUBqJKgX1SPaUgp//9fD9XIOjZ29vglsyHcmFGLyfbMdvgn9K2Pc6Pmt77GJcUOG pcpCsBQAaOXypgV93IKZgNlTDmBCmhvdRNtPaUKUldcwITrA7jRQNjOzUtw8EQFKJlIfBKXdgpgW fuoqYgDwUoHYKW1/goukeSCl2vI4anNrj2CGSU24pUpkXu8Et5UZKaUaUlDXnkgJ9k8uQpU2tnug plsHjKUDsB96fYzu4Ji2vsZSUr7gm1/ehI7e0Jb2jukpm2wN7kpOtngJhYI0EpjYfAIUpaZSS3Ep /d4IqY/JLd5KUOPZMZCSlpnlMIHCR17JkVLkqKSl7UlMExlEgFQI1SUxkpCCn07pvgipeExSkpAp KWPCQCklASUxPwS3FOlqkpjJKSlB8VEykpSWqcApfNFS2qSlITGEFKTc90oS07IqWhKE+qaCkpZJ PCUJKWSUtqY6JKVBS2lKUklLJSnSg+CSlpKXuUtjk4aR3SUxDXlS2P8AgkXOHdNvd4pKZBh8UxrP io7neKUkoKWiOUlLa49ktjvBFSwk8J9rj2Tt3NOiJqRqELUh2O8Etp8EQ7hw1RO/zSUsJCflNDj2 KIK3eCRUxgJ9o8FL03eCYiOdElLQB3TSngJtvmkpkFLY5RDT+8EZgA5cgVI/Td4KJDhyEdzXO+i6 FA1P+KVqRpyUi13gnaxx7JKZMDI81LRIUvHZKCNCgpYkDgpw6fNMQCow4fRMpKSh4H5oUX20nlsH xCQLu6fb4t/BLRSOGu+g4/BOC9g1JKlDR2hSFjWalspKRG4eGqXrN7hEOVT+5+CibaXEEMiNSPFL 6Kf/0MQ+v+Z9Ht8EKz1f8JK5ZJbw+jE9MJ7JOnvK5lJOU9MI7ojfS/OlcqkgVPXN+z+fzU/Z+bHy hcckm/b9VPYa+B+9Ib+0T5yuPSSU9e71/l5IR3/nSuVSRH0U9T7UjC5ZJFT1Onmn0XKpJKeqEJ9F yiSCnqzt7qQjsuSSSU9bolp2hckkkp69u385EGyNIXGJJpU9kZUVx6SKnrzuTfFcikkp63Tuolco kip6zWFFcqkkp6wSkZXJpJKeqS0XKpJKes08lErlUklPTnlSErlkkVPUJarl0klPT6pxK5dJJT1K guZSSU9NqlquZSRU9NqnELmEkFPTpLmEklPTplzKSSnpjKZc0kip6VJc0kkp6VLVc0kkp6VLVc0k kp6VJc0kkp6VJc0kkp6b3eaXu7yuZSSU9MpDd2lcukgp6seope/yXJJIKet/S+Sf9L2XIpJfYp68 er5JO3RrC5BJBT1JSE9lyyScp6kKQXKJJKetE+fyR27o1n5ri0kwqevfunWYSbPmuQSRU9j7/NRO 785cgkkp7DSElx6SSntat/5sfNFO/uG/IrhUk0pe3fO3UBBXHJIhD1ztvdRHpwZ57Lk0kVP/2Qpl bmRzdHJlYW0NZW5kb2JqDTI4IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2Ug DS9TTSAwLjAyIA0vVFIgL0lkZW50aXR5IA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IC9MZW5ndGgg Njg1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJLI1RSFRBFIYvCAX7EgX2skRQ QdGDhbEPEZIQQsI++LAVtBGUS5Rc6OEiBldaqpslLCaukXYrNe7qapP4cBXNoVVq0K1O5sZouzXh kjHECocomMfbWP18HM7/n5+ZkPnAsDzD9gyLhKyBkO3tMnt3tz0x3IThacydmZat7rXtPf07Mu07 vP6QRQybGB0zRoqFbLLd8ffdIHs7J6vc8ao+ZqTB8CCcpuHu/LYBvzrzqqH5dm3Sq096Udu7efJs a+v9uOVest1Ix0TEYfW3SN1d2uCQxruk6dbYxTvZAyPJo89u1g4PnRgePdhNDz6ar7uXOz44f9p9 HpscOvcwd2qUXR2cvTKb7RimnXk/5EK1/tTlhsdDaR5yedVQaYu3Xt1X2PMAwpmV8Nj6kTQcuw+H B5YPjX052bdU7/HjRERHS2eeFloy72M+NBPROPn19FTpgl86PyVNHy7TYoJKc2rNGvuQnABrqtQ+ vWLSijUtLYq2PjFpsbLNhA3cZGgxHaK9sNE5U7jzsuyAcPLYk1vpWtjoW/w88urT49ViCjDFsRfQ BfT05Oit/vb31/g1mgitifiRCI3oWUc1dZoG2qCJzjU2sWiURWMspomzeJzGEyyeeN18CRIJSJhg msy0cteuM9sB0wKrjbfZ3Ha447xJdZdSXSLdK9KucN3lTHYtk5WEzLxb5NMvJPG/0dyPXA4pQ5ZH gPE3qz4UCcgJXvZB+lwSjoSruaUS5doi5bhU4G/59/LH4i9e9EWRCJwrCyoqvlR07SeViolfTAom kUkFgoMQICQIBKFACi4El0ILpORCctRGLwgSoaK4RC4VRyWkFBKFvuLfxqbRmRZWKhWUqCWkErqp lEQl9VQBokKlCTAIlBD6FSWl+pduKlBBoEvB/y34I8AAiKD54QplbmRzdHJlYW0NZW5kb2JqDTMw IDAgb2JqDTw8IC9MZW5ndGggMzg2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ 7I9XloJQEERnP2ZQEBOiGEiiGBAxh7UZyBkk6NLmLWI+p879667qLpb1YFiBoBcEKdWqgiAqhukY ptXrWq2moqjWaOjNpt5qGe222e1avZ5FEFa/b43HDkU5NO2xrD+ZBDwfTCb+dBowjEdR7nDoDAZ2 v293u2anA7xGqwVyQJrW6Zi9HhiBBQfHTYIwSdImSavd1lFUrVbVel2t1ZTRyOE4XxDCxSJard7L JSCaz6PZLKBpdzwGJ2wEAX/qDONTlFcuv5pNA8cNBFF43p/PQ1F8r9dvjvNWq2g0csvlZ6UCeOG4 NZuFGynebACJLCeSFG+3yW6XHA4pDL+m03C9jne79HjMDodMFGOGcTkuuFw+p9Nnv095HtiT7TYV hIgkHRRVZDkdDt1S6Ylhaqn0IAi7WHwWCoAHBD3z+Uex+IBh0EujaZ9lg9Mpu1y+5/On0TAWi3C/ zyQpEYQgl7vn8/dC4X69fm83sJDJcixJb1EEFeyff/21fgUYABDds2IKZW5kc3RyZWFtDWVuZG9i ag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA2IDAgUiANL1Jlc291cmNlcyAyIDAg UiANL0NvbnRlbnRzIDMgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMiAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAvVFQyIDE2IDAgUiAv VFQ4IDIxIDAgUiAvVFQxMCA0IDAgUiA+PiANL1hPYmplY3QgPDwgL0ltMSAyNyAwIFIgL0ltMiAy NiAwIFIgL0ltMyAyNCAwIFIgL0ltNCAyNSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyOCAw IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMTcgMCBSIC9DczkgMTMgMCBSIC9DczEwIDE4IDAg UiA+PiANPj4gDWVuZG9iag0zIDAgb2JqDTw8IC9MZW5ndGggMjEwOCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIiaxXXXPbRhJ856/YRyAlQvu9i0dFug/lzg5lMslDKg80DSmMZcIG Kfn8769ndgGQkgWncleuMiBigZnt7umZ/TRTYitmxovgvHBWinnQUnTN7JfvxG52frl3YrMXiv/t N7PzfyyVuNvPjKti7N+plObX6Io3b7+b3cw+5Q9PrOMIL0VOv9PK/tHxW30an2ZS0KPai7lTqvJR SLwQKi0Q2Wmx+TA7v/6gxFXLOY2rjayCpsUhVLWq65P1Oq2/mX2/mp2vVhp7X93iZWUr6b0Rc7qx 9LaLVbRCx5pCrz4MgEn+dwTYXFZSSS1WmxnupLNi9Xn2a/FjOY9VKDbl3BWHcq5MVRdtKYu39Lsv mnTp8KSyhRD0pyu0TD9LU/62+mE2kEMxjFWCLwh19X8K8LcVQ4f0KxkMOHSGWMX2PW4CwAs9cmZE 2tfMN9YGn9cGh7XexrzYpsWM2eUyi2x5iQ39gBf+wD6CE59FFK/Er79J8S5JCtApZfEZkOxqS5pY ZqKU7JkyulJAGTzrxBQCK22IooEagkvK2FMifaLkevFoz68XpQUgj6UuvLh6KCHjYn0vrhfi3+sv TScWXXtoN+09VqlCLA/rzfvMBZKu/RjAKubDqszH//R1EKEAyExjV1B4MBXY0KHyQERXcYACMLgK O57ThZLRThFjJiri5DkINYHAtyoL83Vz+FzOPaTTdu/LQOK4WFzvhzS0JcUHzfLH4yg06s/al3NQ FoxZEWXlLaUw70HvI4eM/+4AVYai2/HlUGKvACH99gh0LigvW3z8eL/drCFcFHRetW13Y4aocGBk DNBJEAE0P5VezRBZ7IIRoip1Q3YhZlyAhUbZeJTHoYyVKQCTxKXt+Lf3JUosFuKn9HB7D3JDsT1s +ZreG3OsAZuLGUDY1gR8WgVCXHuIZYCPMIN6KbXi6vWyXP3Bn4UrAeMQmRb+tpJ15aZ2j8XQUvSV jlPk3Py4BA/YGAjpHrd0Xxeb5qkubK0r43thEPAT4szCcBIW78fgZgiuU+yLByqK3S1Z2fbuoVsf ti3T74udaG/Fxbt3XZJss98fpUROQdq3VZ+RUp7M/uWMoqEbg10MWjgCQ9cpoTftw2G7uxOv7sp5 jbAfQLmCKk4DaxNoezky2k+cKpIUWVtHtjVgYUci6tP61Lk+64LTABqURzjJo/ekij6EmtdBVbUW AZ6BgsUrMMG5lzI3bx3YM/PjmttlfqpjZGCwmXoAU7rJLRnJajRosIHpHfoV7ycOW0Pn4q0tW9gd slJFc4AD+iK5Yr8doyMXguXPZonZeiIBrCQCME6YbH4DkyaFXHXr3f5j25GNxBxPkLhdsbpclKY4 L+EmxU9XfL+8XC36bJIVa1cTouwztf0TTqw9LX1mxGoUPYNRvFn+vEjGm0rbKDIJR10NVeYZCMnd +OXtQ39Y7Az72zH+LxV51vWZeM2mu737/W3bnaE97Unn5H4SwGzo2VmpIDjBaGBMU5Wmur2aPa3g 3FvXu3fiVft2e9+IaxoxTAFA8f+jF5frze9j0RoXhOd+kkWGtqGnRBYYC8wceqhYPSor07woHUYd A2W1pKxYUJMVl+0u/dXhj0T69/dZg2Y0a4tyhoBt5AEyY6/NpK1amA72YOuaKOjzGnGxfqhm9AdF vQQf5JJmXxNohvyg6W75ut40KV/6A/mecXbUgOoQjvBP1IaR2hzo5oE2aIvmoWEyTXEmknEo2IYH CBgSHRac0QWmkvAg3jCG5GfbfX9DrQ9KGDEiobGNZ9qoGCa0aTU3NRfIQQa3G7uuyl335213eEi9 Phb3YvWw2zX3lFokiOhGFzQ1eKTc3a436a7Zi8EDU0t0ZL99bo499lst0Wluo89nplFeWvUsplIR 4mq7J3lHFAlNJy3Gli99Kk4raj7UyH2fC7mCn8jFYSohezHUVZ9Z6IiXyXhdvFt/JE0bCIc1lG5v +QoN7QUxSlMoFQTaMyoBTRNFP/gaOpeXPVTI1UzIXFumEZ72NaDUCFTu5Ik/EvItNXJiCxpDO9+N xaaF71WEpjPRrG3kcx+w+Zq7je2FYIKjXrxZCEFTeHZUqx3p1Sl3JNvIlvlySEwskdSks26fhDJP BQE9bFgEiFzSfPjoB6cL8GUQbMaBiUbXqfAGdoLFDqI5GpiSrchs4egb51d/X55TkfvihmYmjG4n TcvWMXUsnF7DFLupZTnpntD7lF0+OuCEs282xz0LUy7Pdxht5FB8up4axmnYrel4J3PPGn2BbbM/ KnCofzVfREkuleawSHPY0fSTog8HAT6pWPr6t6KfHAWOOrMZDopcTv15LnWxtvkP2SMd3BoUli12 cGxOjMfDk8ToPHLiltDw1FiqMZHpZ245HGBzWrm/MiLXBIhF3+Mz1D9pXIZm2OnpMMK+KS7umt2Q lfGau5xU43RVT3JlIs+JFieMNF6dmNNXxuajAYDbvz+uBp5v0DWVHpXyzdmm5nl2QET3iDh7rJNF 13Jj8MWp1eXGPs5wiBrsZG/IfX2c4oadprPY9eWrI4cx3HSO/X76qGchCjaD3u758zV9vjhyLlOD RX2at5J+eiDByedp3s99qzcpK2gUZIqO8MpxDaV3HHfqjJfiGli1YqLGGP6rMRJmJyoEZlPFkUEb ZTiCljlZQGaZkcS4qeVoumBcfXuSM3AT9YTyxHb/7eStDoOPzfaqzCTb2V695OJ+5q/j0U+HZ/WD 8iUYLcHIjjtUsUnHovjnq9iwEQ2HpL9QxZbDn69W0INY3VKQWEnUKMJEPgnC72z6+MmEMBi75C2i U8HUOxrxEqb/HQBYtvF0CmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PCANL1R5cGUgL0ZvbnQg DS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDEyMSANL1dpZHRo cyBbIDI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjUwIDAgMCAyNzggMCAwIDAgMCA1MDAgMCA1 MDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgNzIyIDY2NyA3MjIgNzIyIDAgNjExIDAgNzc4IDM4OSAw IDc3OCA2NjcgOTQ0IDcyMiA3NzggDTYxMSA3NzggNzIyIDU1NiA2NjcgNzIyIDcyMiAwIDAgMCAw IDAgMCAwIDAgMCAwIDUwMCA1NTYgNDQ0IDU1NiANNDQ0IDMzMyA1MDAgNTU2IDI3OCAwIDU1NiAy NzggODMzIDU1NiA1MDAgNTU2IDAgNDQ0IDM4OSAzMzMgNTU2IA01MDAgNzIyIDUwMCA1MDAgXSAN L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvVGltZXNOZXdSb21hbixCb2xk IA0vRm9udERlc2NyaXB0b3IgNSAwIFIgDT4+IA1lbmRvYmoNNSAwIG9iag08PCANL1R5cGUgL0Zv bnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE2IA0v RmxhZ3MgMzQgDS9Gb250QkJveCBbIC01NTggLTMwNyAyMDM0IDEwMjYgXSANL0ZvbnROYW1lIC9U aW1lc05ld1JvbWFuLEJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMzIA0+PiANZW5kb2Jq DTYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyAxMCAwIFIgMSAwIFIgXSANL0NvdW50 IDIgDT4+IA1lbmRvYmoNNyAwIG9iag08PCANL0NyZWF0aW9uRGF0ZSAoRDoyMDAzMTAyNDA5NTAw NSkNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciA0LjA1IGZvciBXaW5kb3dzKQ0vTW9kRGF0 ZSAoRDoyMDAzMTAyNDA5NTAzNy0wNCcwMCcpDT4+IA1lbmRvYmoNeHJlZg0wIDggDTAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDA0OTUzNSAwMDAwMCBuDQowMDAwMDQ5Njg2IDAwMDAwIG4NCjAwMDAw NDk5NDkgMDAwMDAgbg0KMDAwMDA1MjEzMSAwMDAwMCBuDQowMDAwMDUyNTkwIDAwMDAwIG4NCjAw MDAwNTI3ODMgMDAwMDAgbg0KMDAwMDA1Mjg1NCAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDgN L0lEWzw5ODUwNmVkZGUzMjBiODQyMmEwNzI2YWUwMjBmZjVjMT48OTg1MDZlZGRlMzIwYjg0MjJh MDcyNmFlMDIwZmY1YzE+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== ------_=_NextPart_001_01C39A36.20F98DD5-- From owner-v6ops@ops.ietf.org Fri Oct 24 10:53: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 KAA05740 for ; Fri, 24 Oct 2003 10:53:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD3GR-000O57-DO for v6ops-data@psg.com; Fri, 24 Oct 2003 14:50:07 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD3GL-000O3q-EZ for v6ops@ops.ietf.org; Fri, 24 Oct 2003 14:50:02 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05128; Fri, 24 Oct 2003 10:49:49 -0400 (EDT) Message-Id: <200310241449.KAA05128@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-int-02.txt Date: Fri, 24 Oct 2003 10:49:49 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Internet Area: Survey of IPv4 Addresses Currently Deployed Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-int-02.txt Pages : 56 Date : 2003-10-23 This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-int-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-int-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24103521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-int-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-int-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103521.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 24 10:54: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 KAA05803 for ; Fri, 24 Oct 2003 10:54:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD3Go-000O6h-Cx for v6ops-data@psg.com; Fri, 24 Oct 2003 14:50:30 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD3GU-000O5I-Su for v6ops@ops.ietf.org; Fri, 24 Oct 2003 14:50:24 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05147; Fri, 24 Oct 2003 10:49:58 -0400 (EDT) Message-Id: <200310241449.KAA05147@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt Date: Fri, 24 Oct 2003 10:49:58 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-apps-03.txt Pages : 55 Date : 2003-10-23 The transition from an all IPv4 network to an all IPv6 network requires several interim steps, being one of them the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards - Full, Draft, and Proposed - and Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-apps-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-10-24103533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipv4survey-apps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24103533.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Oct 24 11:18: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 LAA08239 for ; Fri, 24 Oct 2003 11:18:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD3ez-000Pm5-93 for v6ops-data@psg.com; Fri, 24 Oct 2003 15:15:29 +0000 Received: from [129.46.51.58] (helo=numenor.qualcomm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD3es-000PlV-VI for v6ops@ops.ietf.org; Fri, 24 Oct 2003 15:15:23 +0000 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OFFKVY012733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Oct 2003 08:15:20 -0700 (PDT) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OFFHFA019658 for ; Fri, 24 Oct 2003 08:15:18 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Oct 2003 08:15:17 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Subject: RE: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt Date: Fri, 24 Oct 2003 08:15:17 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327C37@NAEX01.na.qualcomm.com> Thread-Topic: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt Thread-Index: AcOaQL8rEiqFR1K8Q4qJSuivsIQ49gAAH4gw From: "Barany, Pete" To: X-OriginalArrivalTime: 24 Oct 2003 15:15:17.0929 (UTC) FILETIME=[A2143190:01C39A41] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I made a comment about this Internet draft (-01) back on Aug. 8. I insert it below because it still seems that it does not mention SIP, SDP, RTSP, RTP for some reason. I know the intent is to get this documents out as quickly as possible, but these are significant omissions IMHO. Regards, Pete --> INSERT e-mail Hi,=20 I took a look at this document and have a comment:=20 Before the IPv4 survey I-D (the latest "old" version was ) was split up into separate I-Ds corresponding to IETF areas, there was discussion of SIP, SDP, RTSP (and there should have been some discussion of RTP/RTCP since SDES CNAME can carry IP addresses). However, upon reviewing the I-D I see no mention of these protocols. Was there a specific reason for not including them? Granted, there are a lot of SIP-based RFCs and Internet drafts, but at a minimum, shouldn't we mention the basic ones (don't know about the RFCbis I-Ds): (1) RFC 3261 "SIP: Session Initiation Protocol"=20 (2) RFC 3266 "Support for IPv6 in Session Description Protocol (SDP)"=20 (3) RFC 2327 "SDP: Session Description Protocol" -> being updated by =20 (4) RFC 2326 "Real Time Streaming Protocol (RTSP)-> being updated by =20 (5) RFC 3550 "RTP: A Transport Protocol for Real-Time Applications"=20 Regards,=20 Pete --> End INSERT e-mail -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, October 24, 2003 7:50 AM Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Author(s) : P. Nesser II Filename : draft-ietf-v6ops-ipv4survey-apps-03.txt Pages : 55 Date : 2003-10-23 =09 The transition from an all IPv4 network to an all IPv6 network requires several interim steps, being one of them the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards - Full, Draft, and Proposed - and Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03. txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipv4survey-apps-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Fri Oct 24 11:47: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 LAA11223 for ; Fri, 24 Oct 2003 11:47:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD46X-0001G5-Qf for v6ops-data@psg.com; Fri, 24 Oct 2003 15:43:57 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD46O-0001Fa-Fi for v6ops@ops.ietf.org; Fri, 24 Oct 2003 15:43:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9OFhFk27871; Fri, 24 Oct 2003 18:43:27 +0300 Date: Fri, 24 Oct 2003 18:43:06 +0300 (EEST) From: Pekka Savola To: "Barany, Pete" cc: v6ops@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F327C37@NAEX01.na.qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Fri, 24 Oct 2003, Barany, Pete wrote: > I made a comment about this Internet draft (-01) back on Aug. 8. I > insert it below because it still seems that it does not mention SIP, > SDP, RTSP, RTP for some reason. I know the intent is to get this > documents out as quickly as possible, but these are significant > omissions IMHO. Thanks for the reminder. All of these documents are covered under the _Transport_ area document (except 3266 which was too new, and the forward reference was typoed). The border between the areas is rather blurry at times.. The wording may be a bit unoptimal in the transport document, but suggestions are welcome.. Hope this clarifies.. > --> INSERT e-mail > > Hi, > > I took a look at this document and have a comment: > > Before the IPv4 survey I-D (the latest "old" version was > ) was split up into separate I-Ds > corresponding to IETF areas, there was discussion of SIP, SDP, RTSP (and > there should have been some discussion of RTP/RTCP since SDES CNAME can > carry IP addresses). However, upon reviewing the I-D > I see no mention of these > protocols. Was there a specific reason for not including them? > > Granted, there are a lot of SIP-based RFCs and Internet drafts, but at a > minimum, shouldn't we mention the basic ones (don't know about the > RFCbis I-Ds): > > (1) RFC 3261 "SIP: Session Initiation Protocol" > (2) RFC 3266 "Support for IPv6 in Session Description Protocol (SDP)" > (3) RFC 2327 "SDP: Session Description Protocol" -> being updated by > > (4) RFC 2326 "Real Time Streaming Protocol (RTSP)-> being updated by > > (5) RFC 3550 "RTP: A Transport Protocol for Real-Time Applications" > > Regards, > > Pete > > --> End INSERT e-mail > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Friday, October 24, 2003 7:50 AM > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : Survey of IPv4 Addresses in Currently Deployed > IETF Application Area Standards > Author(s) : P. Nesser II > Filename : draft-ietf-v6ops-ipv4survey-apps-03.txt > Pages : 55 > Date : 2003-10-23 > > The transition from an all IPv4 network to an all IPv6 network > requires several interim steps, being one of them the evolution of > current IPv4 dependent specifications to a format independent of the > type of IP addressing schema used. Hence, it is hoped that > specifications will be re-designed and re-implemented to become > network address independent, or at least to dually support IPv4 and > IPv6. > To achieve that step, it is necessary to survey and document all IPv4 > dependencies experienced by current standards - Full, Draft, and > Proposed - and Experimental RFCs. Hence, this document describes > IPv4 addressing dependencies that deployed IETF Application Area > documented Standards may experience. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03. > txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-v6ops-ipv4survey-apps-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- 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 Oct 24 11:47: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 LAA11308 for ; Fri, 24 Oct 2003 11:47:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD471-0001HN-0h for v6ops-data@psg.com; Fri, 24 Oct 2003 15:44:27 +0000 Received: from [193.136.7.107] (helo=saturno.fccn.pt) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AD46n-0001Gq-SI for v6ops@ops.ietf.org; Fri, 24 Oct 2003 15:44:14 +0000 Received: (qmail 54431 invoked from network); 24 Oct 2003 15:44:12 -0000 Received: (ofmipd unknown); 24 Oct 2003 15:43:50 -0000 Date: 24 Oct 2003 16:44:18 +0000 Message-ID: <3F9956E2.4060609@seas.upenn.edu> From: "Rute Sofia" To: "Barany, Pete" Cc: v6ops@ops.ietf.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: pt, en-us, en MIME-Version: 1.0 Subject: Re: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt References: <17D8F6DF3ED94D40BD607380866D9B7F327C37@NAEX01.na.qualcomm.com> In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F327C37@NAEX01.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm the person reviewing the draft and in fact, I did miss your mail on August. RFCs in the drafts are being surveyed up to 3200. That is why 1, 2 and 5 are missing (3266 is out of the scope of the apps draft, I believe, given that it already addresses IPv6; the current draft is simply a survey). However, 3 and 4 should be there. My fault, it seems. Pekka, should I add them? Rute >I made a comment about this Internet draft (-01) back on Aug. 8. I >insert it below because it still seems that it does not mention SIP, >SDP, RTSP, RTP for some reason. I know the intent is to get this >documents out as quickly as possible, but these are significant >omissions IMHO. > >Regards, > >Pete > >--> INSERT e-mail > >Hi, > >I took a look at this document and have a comment: > >Before the IPv4 survey I-D (the latest "old" version was >) was split up into separate I-Ds >corresponding to IETF areas, there was discussion of SIP, SDP, RTSP (and >there should have been some discussion of RTP/RTCP since SDES CNAME can >carry IP addresses). However, upon reviewing the I-D > I see no mention of these >protocols. Was there a specific reason for not including them? > >Granted, there are a lot of SIP-based RFCs and Internet drafts, but at a >minimum, shouldn't we mention the basic ones (don't know about the >RFCbis I-Ds): > >(1) RFC 3261 "SIP: Session Initiation Protocol" >(2) RFC 3266 "Support for IPv6 in Session Description Protocol (SDP)" >(3) RFC 2327 "SDP: Session Description Protocol" -> being updated by > >(4) RFC 2326 "Real Time Streaming Protocol (RTSP)-> being updated by > >(5) RFC 3550 "RTP: A Transport Protocol for Real-Time Applications" > >Regards, > >Pete > >--> End INSERT e-mail > >-----Original Message----- >From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >Behalf Of Internet-Drafts@ietf.org >Sent: Friday, October 24, 2003 7:50 AM >Cc: v6ops@ops.ietf.org >Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IPv6 Operations Working Group of the >IETF. > > Title : Survey of IPv4 Addresses in Currently Deployed >IETF Application Area Standards > Author(s) : P. Nesser II > Filename : draft-ietf-v6ops-ipv4survey-apps-03.txt > Pages : 55 > Date : 2003-10-23 > >The transition from an all IPv4 network to an all IPv6 network >requires several interim steps, being one of them the evolution of >current IPv4 dependent specifications to a format independent of the >type of IP addressing schema used. Hence, it is hoped that >specifications will be re-designed and re-implemented to become >network address independent, or at least to dually support IPv4 and >IPv6. >To achieve that step, it is necessary to survey and document all IPv4 >dependencies experienced by current standards - Full, Draft, and >Proposed - and Experimental RFCs. Hence, this document describes >IPv4 addressing dependencies that deployed IETF Application Area >documented Standards may experience. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03. >txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the >message. > >Internet-Drafts are also available by anonymous FTP. Login with the >username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-v6ops-ipv4survey-apps-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail >readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > From owner-v6ops@ops.ietf.org Fri Oct 24 12:04: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 MAA12625 for ; Fri, 24 Oct 2003 12:04:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD4Mx-0002Hi-4V for v6ops-data@psg.com; Fri, 24 Oct 2003 16:00:55 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD4Mj-0002H2-Mm for v6ops@ops.ietf.org; Fri, 24 Oct 2003 16:00:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9OG0do28324; Fri, 24 Oct 2003 19:00:39 +0300 Date: Fri, 24 Oct 2003 19:00:39 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com, Subject: WG Last Call: last two draft-ietf-v6ops-ipv4survey-* documents Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi all, This is a WG Last Call for comments on sending the following last two "Survey of IPv4 Addresses in Currently Deployed IETF Standards" documents to the IESG for consideration as Informational RFCs: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-02.txt Please review these documents carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Silence does NOT indicate consent. Unless sufficient support is demonstrated on the list, the documents will not be send to the IESG. The last call will end in 2 weeks, on 7th November. Pekka, Jonne & Bob From owner-v6ops@ops.ietf.org Fri Oct 24 12:22:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13849 for ; Fri, 24 Oct 2003 12:22:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD4eg-0003MG-4F for v6ops-data@psg.com; Fri, 24 Oct 2003 16:19:14 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD4eY-0003Ll-Es for v6ops@ops.ietf.org; Fri, 24 Oct 2003 16:19:06 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OGJ04t005957; Fri, 24 Oct 2003 09:19:00 -0700 (PDT) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OGIwhj012402; Fri, 24 Oct 2003 09:18:58 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 24 Oct 2003 09:18:58 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Subject: RE: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt Date: Fri, 24 Oct 2003 09:18:56 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327C39@NAEX01.na.qualcomm.com> Thread-Topic: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt Thread-Index: AcOaSGDjRL7a/qThR9e2wlte02qG2wAAeuCQ From: "Barany, Pete" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 24 Oct 2003 16:18:58.0062 (UTC) FILETIME=[870E3AE0:01C39A4A] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Ah ... Well, that is at least the second time that I have made the mistake of not remembering that we divided up the original document into "IETF Areas". :) Pete -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola Sent: Friday, October 24, 2003 8:43 AM To: Barany, Pete Cc: v6ops@ops.ietf.org Subject: RE: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt Hi, On Fri, 24 Oct 2003, Barany, Pete wrote: > I made a comment about this Internet draft (-01) back on Aug. 8. I > insert it below because it still seems that it does not mention SIP, > SDP, RTSP, RTP for some reason. I know the intent is to get this > documents out as quickly as possible, but these are significant > omissions IMHO. Thanks for the reminder. All of these documents are covered under the _Transport_ area document=20 (except 3266 which was too new, and the forward reference was typoed). =20 The border between the areas is rather blurry at times.. The wording may be a bit unoptimal in the transport document, but=20 suggestions are welcome.. Hope this clarifies.. > --> INSERT e-mail >=20 > Hi,=20 >=20 > I took a look at this document and have a comment:=20 >=20 > Before the IPv4 survey I-D (the latest "old" version was > ) was split up into separate I-Ds > corresponding to IETF areas, there was discussion of SIP, SDP, RTSP (and > there should have been some discussion of RTP/RTCP since SDES CNAME can > carry IP addresses). However, upon reviewing the I-D > I see no mention of these > protocols. Was there a specific reason for not including them? >=20 > Granted, there are a lot of SIP-based RFCs and Internet drafts, but at a > minimum, shouldn't we mention the basic ones (don't know about the > RFCbis I-Ds): >=20 > (1) RFC 3261 "SIP: Session Initiation Protocol"=20 > (2) RFC 3266 "Support for IPv6 in Session Description Protocol (SDP)"=20 > (3) RFC 2327 "SDP: Session Description Protocol" -> being updated by > =20 > (4) RFC 2326 "Real Time Streaming Protocol (RTSP)-> being updated by > =20 > (5) RFC 3550 "RTP: A Transport Protocol for Real-Time Applications"=20 >=20 > Regards,=20 >=20 > Pete >=20 > --> End INSERT e-mail >=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Friday, October 24, 2003 7:50 AM > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-ietf-v6ops-ipv4survey-apps-03.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. >=20 > Title : Survey of IPv4 Addresses in Currently Deployed > IETF Application Area Standards > Author(s) : P. Nesser II > Filename : draft-ietf-v6ops-ipv4survey-apps-03.txt > Pages : 55 > Date : 2003-10-23 > =09 > The transition from an all IPv4 network to an all IPv6 network > requires several interim steps, being one of them the evolution of > current IPv4 dependent specifications to a format independent of the > type of IP addressing schema used. Hence, it is hoped that > specifications will be re-designed and re-implemented to become > network address independent, or at least to dually support IPv4 and > IPv6. > To achieve that step, it is necessary to survey and document all IPv4 > dependencies experienced by current standards - Full, Draft, and > Proposed - and Experimental RFCs. Hence, this document describes > IPv4 addressing dependencies that deployed IETF Application Area > documented Standards may experience. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03. > txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body of the > message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-v6ops-ipv4survey-apps-03.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-v6ops-ipv4survey-apps-03.txt". > =09 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 24 14:08: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 OAA20676 for ; Fri, 24 Oct 2003 14:08:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AD6Hm-0008ky-8w for v6ops-data@psg.com; Fri, 24 Oct 2003 18:03:42 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AD6Hg-0008kE-Bw for v6ops@ops.ietf.org; Fri, 24 Oct 2003 18:03:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9OI3Qn30602; Fri, 24 Oct 2003 21:03:26 +0300 Date: Fri, 24 Oct 2003 21:03:25 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Tim Chown , Subject: dual vs hybrid stack [RE: IPv6 Capable and IPv6 ONLY for Scenarios] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B05122143@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 24 Oct 2003, Bound, Jim wrote: [tim:] >> So what Pekka says is fine by me "dual stack with only IPv6 >> enabled" (or perhaps more accurately "hybrid stack"). > > Also I agree hybrid is far better than dual stack > as dual stack is a misnomer WG please see PDF attachment. I'm not sure if I understand what is the difference between "dual" and "hybrid" stacks. I'm not 100% sure what the two slides wanted to convey. I got the impression that "hybrid" referred to the practice where the kernel and the rest of the OS tries to implement just one generic IP stack, and reuse and extend that to the IP versions as appropriate (and dual stack would mean literally two completely separate IP stacks or functionalities). Whatever the intent, the key point of course is that the term "dual-stack" has been used to refer to the external behaviour of the implementation, that is, that both the protocols are implemented. I don't think there's really much difference (in the context of IETF) how it's actually done. I would think that "dual stack" is probably the best term to use here, if not for any other reason, than that it seems to have become an established term already.. -- 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 Oct 24 20:03:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06254 for ; Fri, 24 Oct 2003 20:03:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADBnA-000NiU-AK for v6ops-data@psg.com; Fri, 24 Oct 2003 23:56:28 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADBn3-000Ni2-PT for v6ops@ops.ietf.org; Fri, 24 Oct 2003 23:56:22 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HNA0000OD5W4D@mailout2.samsung.com> for v6ops@ops.ietf.org; Sat, 25 Oct 2003 08:56:20 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HNA00D3OD4RHE@mailout2.samsung.com> for v6ops@ops.ietf.org; Sat, 25 Oct 2003 08:55:39 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HNA006QTD4RRG@mmp2.samsung.com> for v6ops@ops.ietf.org; Sat, 25 Oct 2003 08:55:39 +0900 (KST) Date: Sat, 25 Oct 2003 08:55:57 +0900 From: Soohong Daniel Park Subject: FW: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt To: v6ops@ops.ietf.org Cc: "'Soohong Daniel Park'" , Mikael.Lind@teliasonera.com, alain.baudot@rd.francetelecom.com Message-id: <018701c39a8a$5e6cf870$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/mixed; boundary="Boundary_(ID_Ve8itJn6A/aAinejamnvoQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,HTML_FONTCOLOR_BLUE, HTML_MESSAGE autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_Ve8itJn6A/aAinejamnvoQ) Content-type: multipart/alternative; boundary="Boundary_(ID_F38bR8pnNVK+g3ph/FMiug)" --Boundary_(ID_F38bR8pnNVK+g3ph/FMiug) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hello Now, new draft is available in the IETF server as a result of the ISP Design Team. "Scenario for Introducing IPv6 into ISP Networks" Let us know your feedback/comment to move forward. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Friday, October 24, 2003 11:43 PM > To: IETF-Announce: > Subject: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Scenarios for Introducing IPv6 into > ISP Networks > Author(s) : M. Lind, et al. > Filename : draft-lind-v6ops-isp-scenarios-01.txt > Pages : 20 > Date : 2003-10-23 > > This document describes different scenarios for the introduction of > IPv6 in an IPv4 ISP network. The goal is the addition of a native > IPv6 service to the already existing IPv4 service without > interruption of the IPv4 service. During the IPv6 introduction the > network can go through 4 different stages including the initial IPv4 > only stage. To move between the stages there will be some form of > transition that can be defined in different transition scenarios. > > A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lind-v6ops-isp-scenarios-01.tx t To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lind-v6ops-isp-scenarios-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lind-v6ops-isp-scenarios-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_F38bR8pnNVK+g3ph/FMiug) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT FW: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt

Hello

Now, new draft is available in the IETF server as
a result of the ISP Design Team.

"Scenario for Introducing IPv6 into ISP Networks"

Let us know your feedback/comment to move forward.


Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics




> -----Original Message-----
> From: owner-ietf-announce@ietf.org
> [mailto:owner-ietf-announce@ietf.org] On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Friday, October 24, 2003 11:43 PM
> To: IETF-Announce:
> Subject: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>       Title           : Scenarios for Introducing IPv6 into
> ISP Networks
>       Author(s)       : M. Lind, et al.
>       Filename        : draft-lind-v6ops-isp-scenarios-01.txt
>       Pages           : 20
>       Date            : 2003-10-23
>      
> This document describes different scenarios for the introduction of
> IPv6 in an IPv4 ISP network. The goal is the addition of a native
> IPv6 service to the already existing IPv4 service without
> interruption of the IPv4 service. During the IPv6 introduction the
> network can go through 4 different stages including the initial IPv4
> only stage. To move between the stages there will be some form of
> transition that can be defined in different transition scenarios.
>
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lind-v6ops-isp-scenarios-01.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then

        "get draft-lind-v6ops-isp-scenarios-01.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-lind-v6ops-isp-scenarios-01.txt".
       
NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.
               
               
Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. <<...>> <<...>>

--Boundary_(ID_F38bR8pnNVK+g3ph/FMiug)-- --Boundary_(ID_Ve8itJn6A/aAinejamnvoQ) Content-type: Message/External-body; name=ATT00247.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00247.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-24103147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lind-v6ops-isp-scenarios-01.txt --Boundary_(ID_Ve8itJn6A/aAinejamnvoQ) Content-type: Message/External-body; name=draft-lind-v6ops-isp-scenarios-01.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-lind-v6ops-isp-scenarios-01.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-24103147.I-D@ietf.org> --Boundary_(ID_Ve8itJn6A/aAinejamnvoQ)-- From owner-v6ops@ops.ietf.org Sun Oct 26 07:10: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 HAA15770 for ; Sun, 26 Oct 2003 07:10:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADjcU-0000J7-79 for v6ops-data@psg.com; Sun, 26 Oct 2003 12:03:42 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADjcP-0000Ir-5K for v6ops@ops.ietf.org; Sun, 26 Oct 2003 12:03:37 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 21-md50000000001.tmp for ; Sun, 26 Oct 2003 13:07:35 +0100 Message-ID: <198901c39bb9$7d7b8d50$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Cc: References: Subject: Re: I-D ACTION:draft-shin-v6ops-application-transition-02.txt (fwd) Date: Sun, 26 Oct 2003 13:05:31 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sun, 26 Oct 2003 13:07:35 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think is a very good work, just found a couple of minor errors. 1. have been developed to migrate replace with "have been developed to do the transition from IPv4 to IPv6 networks" or "have been developed for the transition of the today's IPv4 networks" or "have been developed for the transition of IPv4 networks to IPv6" (other combinations possible !, key points: avoid using "migration/migrate", and use "networks" instead of "network") 3.2 DNS does not indicate which the IP version will be used replace with "DNS does not indicate which IP version will be used" Regards, Jordi ----- Original Message ----- From: "Pekka Savola" To: Cc: Sent: Tuesday, October 21, 2003 2:21 PM Subject: I-D ACTION:draft-shin-v6ops-application-transition-02.txt (fwd) > Hi, > > The application "transition" document has seen significant revision: > > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-02.txt > > All comments would be appreciated. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ---------- Forwarded message ---------- > Date: Mon, 20 Oct 2003 15:40:02 -0400 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > Subject: I-D ACTION:draft-shin-v6ops-application-transition-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Application Aspects of IPv6 Transition > Author(s) : M. Shin, et. al. > Filename : draft-shin-v6ops-application-transition-02.txt > Pages : 26 > Date : 2003-10-20 > > The document specifies application aspects of IPv6 transition. As > IPv6 is deployed, the application developers and the administrators > will face several problems. This draft clarifies the problems and > considerations occurring in transition period between IPv4 > applications and IPv6 applications. It also proposes guidelines > that help application developers understand how to develop IP > version-independent applications during the transition period. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-shin-v6ops-application-transition-02.txt > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Oct 26 12:19:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22081 for ; Sun, 26 Oct 2003 12:19:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADoSw-000DhJ-1x for v6ops-data@psg.com; Sun, 26 Oct 2003 17:14:10 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADoSr-000Dgr-Bg for v6ops@ops.ietf.org; Sun, 26 Oct 2003 17:14:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9QHE3Y29495; Sun, 26 Oct 2003 19:14:03 +0200 Date: Sun, 26 Oct 2003 19:14:03 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: bob@thefinks.com, Subject: Draft agenda for v6ops Minneapolis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Find below the first draft agenda for v6ops slots in Minneapolis. There will still be modifications to it, but we thought it would be appropriate to give a sneak peek as soon as possible, and to solicitate comments etc. on the agenda contents. Note that we've used a bit more verbose format in the draft agenda, trying to help people focus on what's the goal of each agenda item. Thanks, Pekka, Jonne & Bob v6ops co-chairs ------- *DRAFT* v6ops agenda for Minneapolis IETF --------------------------------- (We've requested for 2.5h + 2.0h slots, but due to scheduling conflicts, they haven't yet appeared on the draft agenda.) First slot, 2h ============== Introduction and agenda bashing - 5 mins, Chairs/Pekka Process issues for the working group, 10-15 mins, Chairs/Jonne - Introduce the changes/enhancements to the WG process. - [more details to come..] - GOAL: enable WG to work more effectively Document status - 5-10 mins, Chairs/Pekka - What has happened with WG documents lately - GOAL: show the status of WG documents 3GPP Analysis Issues discussion, 15 mins, J. Wiljakka - draft-ietf-v6ops-3gpp-analysis-06.txt [maybe updated] - Go through the open issues raised before and during the last call, try to solicit comments from the WG. - GOAL: try to gain some form of consensus on the issues, to be ready to ship the document to the IESG after revision in Dec 2003. ISP Scenarios/Solutions, 30 mins, Chairs/Pekka, M. Lind, V. Ksinant (either one or both) - draft-lind-v6ops-isp-scenarios-01.txt - draft-ksinant-v6ops-isp-analysis-00.txt - present changes, solicit discussion - try to get meta discussion what the WG actually wants to do in ISP space - GOAL: Show the latest developments in ISP space, get WG to discuss what to do to move forward. Adapt both as WG documents. Enterprise Scenarios discussion, 20 mins, Y. Pouffary, or someone else? - draft-ietf-v6ops-ent-scenarios-00.txt - 5-10 mins presentation, the rest discussion - present changes to the draft - bring up the points where WG input would be useful, discuss those - GOAL: allow the WG to go give input on the document, and help it go forward. Unmanaged Connectivity Tradeoffs discussion, 30 mins, R. van der Pol, or T. Chown - draft-chown-v6ops-unmanaged-connectivity-00.txt - 10 mins presentation, 20 mins discussion - describe the connectivity issues currently blocking the unmanaged solutions document, discuss tradeoffs - GOAL: try to get useful discussion on the tradeoffs of connectivity. Get input whether this is the right direction to go to solve these issues. The second slot, 2.5h ===================== Agenda bashing - 5 mins, Chairs/Jonne IPv4 Survey drafts status report - 5-10 mins, Chairs/Pekka - draft-ietf-v6ops-ipv4survey-apps-03.txt draft-ietf-v6ops-ipv4survey-int-02.txt draft-ietf-v6ops-ipv4survey-intro-04.txt draft-ietf-v6ops-ipv4survey-ops-03.txt draft-ietf-v6ops-ipv4survey-routing-02.txt draft-ietf-v6ops-ipv4survey-sec-02.txt draft-ietf-v6ops-ipv4survey-subip-03.txt draft-ietf-v6ops-ipv4survey-trans-03.txt - present the status of IPv4 survey documents - GOAL: present status, try to get people involved in finishing up the drafts Transition mechanisms update, 15 mins, Erik Nordmark or Chairs/Pekka - [to-be-revised:] draft-ietf-v6ops-mech-v2-01.txt - present the changes, 5 mins; discussion of issues, 10 mins - GOAL: Consensus on the changes, prepare for WG last call, decision whether changes are OK to qualify for going to Draft Standard. IPv6 Applications Transition - 20 mins, Myung-Ki Shin - draft-shin-v6ops-application-transition-02.txt - 5 minutes base presentation - 5 minutes framing the discussion - 10 minutes discussion - GOAL: adopt as WG document, provoke discussion on application porting guidelines IPv6-on-by-Default/On-link-bydefault tradeoffs - 25 mins, Sebastien Roy - draft-ietf-v6ops-v6onbydefault-00.txt - draft-ietf-v6ops-onlinkassumption-00.txt - 5-10 minutes presentation/changes - 15 minutes discussion - GOAL: discuss changes since the last version, first time as WG document - GOAL: make clear how to proceed with the onlinkassumption document. IPv6 Firewalling Considerations, 10 mins, Pekka Savola - draft-savola-v6ops-firewalling-02.txt - 5 minutes presentation/changes - 5 minutes discussion, if there are any open issues - GOAL: see whether the WG wants to adapt as WG item for Informational RFC. IPv6 Renumbering Procedures, 20 mins, Fred Baker - draft-baker-ipv6-renumber-procedure-01.txt - 5-10 mins presentation, 10 mins discussion of the issues - GOAL: adapt as WG document, discuss how to make renumbering easier. SIIT/NAT-PT Applicability Statement - 15 mins, Suresh Satapati (or someone else) - draft-satapati-v6ops-natpt-applicability-00.txt - 5 minutes presentation, 10 minutes discussion especially the major issues where the DT was divided - GOAL: provoke discussion on NAT-PT/SIIT and generic translation, see how the WG likes the document Experiences with Dual Stack Service - 15 mins, Yasuhiro Shirasaki - draft-shirasaki-dualstack-service-02.txt - 5-10 minutes presentation - 5 minutes discussion - GOAL: disseminate how dual-stack access service has been deployed already. (Authors pursue the individual Informational RFC path.) From owner-v6ops@ops.ietf.org Sun Oct 26 15:42: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 PAA27926 for ; Sun, 26 Oct 2003 15:42:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADreY-000O3X-V4 for v6ops-data@psg.com; Sun, 26 Oct 2003 20:38:22 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADreT-000O2y-WB for v6ops@ops.ietf.org; Sun, 26 Oct 2003 20:38:18 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 34-md50000000002.tmp for ; Sun, 26 Oct 2003 21:38:11 +0100 Message-ID: <1dd001c39c01$61301fb0$9402a8c0@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <200310222236.SAA02410@ietf.org> Subject: Re: I-D ACTION:draft-chown-v6ops-unmanaged-connectivity-00.txt Date: Sun, 26 Oct 2003 21:40:21 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sun, 26 Oct 2003 21:38:11 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This is a good document in my opinion. Some comments below. I think 1st p. of section 2. needs some clarification. Indeed: "Mechanisms only passing the NAT ... is replaced by an IPv6-aware box." Is wrong, in my point of view, or I'm misinterpreting it. 2.2 typo: Protocol 41 forwarding 3.1 Not sure to understand what do you mean with "Tunnels can be either unidirectional or bi-directional" I think one missing part on the document is to reinforce the unmanaged vs. managed protocols, pros-cons, billing/AAA, from the perspective of the ISP. If I'm an ISP willing to offer some kind of IPv6 services, this document could be a tool to look for the different alternatives. Regards, Jordi ----- Original Message ----- From: To: Cc: Sent: Wednesday, October 22, 2003 11:36 PM Subject: I-D ACTION:draft-chown-v6ops-unmanaged-connectivity-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Considerations for IPv6 Tunneling Solutions in > Small End Sites > Author(s) : T. Chown, et. al. > Filename : draft-chown-v6ops-unmanaged-connectivity-00.txt > Pages : 16 > Date : 2003-10-22 > > Tunneling IPv6 packets over the IPv4 Internet played a major role in > the early stages of IPv6 deployment. This was useful because in the > early days the routers in the internet did not support IPv6. > Nowadays, tunneling is used to get across legacy equipment and ISPs > that do not support IPv6. Many different tunneling mechanisms have > been invented. This document describes the drivers for IPv6 > tunneling, the general architectures of existing mechanisms, and a > set of desirable properties against which subsequent analysis of the > mechanisms may be made. The document is aimed at small end sites > that may typically utilise tunneling methods in an early IPv6 > deployment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chown-v6ops-unmanaged-connectivity-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-chown-v6ops-unmanaged-connectivity-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-chown-v6ops-unmanaged-connectivity-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. > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Oct 26 19:58: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 TAA06734 for ; Sun, 26 Oct 2003 19:58:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1ADvdL-0009Iy-7a for v6ops-data@psg.com; Mon, 27 Oct 2003 00:53:23 +0000 Received: from [144.254.74.5] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ADvdI-0009Ik-LY for v6ops@ops.ietf.org; Mon, 27 Oct 2003 00:53:20 +0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2003 01:51:14 +0100 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h9R0r7a6008360; Mon, 27 Oct 2003 01:53:07 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Oct 2003 00:53:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: A comment on Date: Mon, 27 Oct 2003 00:53:13 -0000 Message-ID: Thread-Topic: A comment on Thread-Index: AcOb5XCH94gfkrRlQ5q/++qNfePYdgAMAokw From: "Francois Le Faucheur (flefauch)" To: Cc: , , , , , , , , , , , "Francois Le Faucheur (flefauch)" X-OriginalArrivalTime: 27 Oct 2003 00:53:14.0773 (UTC) FILETIME=[B3EA2C50:01C39C24] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Vladimir, In section 3.3, I noticed the following: " When MPLS is already deployed in the backbone, it may be desirable=20 to provide IPv6-over-MPLS connectivity. However, the problem is that setting up an IPv6 Label Switched Path (LSP) requires some signaling through the MPLS network. Currently, there is no direct mechanism to do this for IPv6. A workaround is to use BGP for signaling and/or=20 perform IPv6-over-IPv4-over-MPLS encapsulation, as described in=20 [BGPTUNNEL]. More analysis is needed on what is the right approach=20 in this case. " Well, there actually are mechanims specified to set up IPv6 LSPs: both LDP and RSVP-TE specifications cover both label binding for IPv4 and for IPv6.=20 However, in the considered networks where IPv4 MPLS is already deployed, the situation is that : - (i) there is a control place in place which establishes IPv4 LSPs across the core, providing connectivity among all the Edge boxes (Provider Edges) - (ii) these LSPs are already used for transport of multiple services (IPv4, IPV4-VPNs, Layer 2 VPNs, ...) - (iii) there is strong operational pressure to keep core stable for these services - (iv) the LSPs can be used to carry yet another service which is IPv6 (and BTW IPv6-VPNs next) - (iv) this can be achieved without any change to the core neither in terms of software, nor in terms of hardware, nor even in terms of configuration. So, I believe operators see transport of "IPv6 over IPv4/MPLS" more as an opportunity to add services with no impact on the core, than as a workaround to circumvent protocol limitation. Also, while [BGP-TUNNEL] does allow the IPv6-over-IPv4-over-IPv4/MPLS encapsulation option, it also allows the direct IPv6-over-IPv4/MPLS encapsulation option which is the one commonly deployed today. I may be jumping into the "more analysis is needed" discussion you announced, but I thought it may be useful to try converge on the problem description. I hope this is useful. Francois PS: looking forward to seeing you in Minneapolis. From owner-v6ops@ops.ietf.org Mon Oct 27 03:14: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 DAA00483 for ; Mon, 27 Oct 2003 03:14:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE2QR-000OB9-Vg for v6ops-data@psg.com; Mon, 27 Oct 2003 08:08:31 +0000 Received: from [131.115.230.133] (helo=tms002bb.han.telia.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE2QO-000OAs-PD for v6ops@ops.ietf.org; Mon, 27 Oct 2003 08:08:28 +0000 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms002bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Mon, 27 Oct 2003 09:08:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: FW: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Date: Mon, 27 Oct 2003 09:08:26 +0100 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE80185FCC8@TMS031MB.tcad.telia.se> Thread-Topic: FW: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Thread-Index: AcOcYFVFB1o2TNnHR6ywvOZs4J1emgAABeiw From: To: X-OriginalArrivalTime: 27 Oct 2003 08:08:26.0890 (UTC) FILETIME=[7FF306A0:01C39C61] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi,=20 A new version of the ISP scenarios draft is available as well as the first version of the analysis draft http://www.ietf.org/internet-drafts/draft-ksinant-v6ops-isp-analysis-00. txt. Please comment.=20 Regards, Mikael >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Scenarios for Introducing IPv6 into ISP Networks > Author(s) : M. Lind, et al. > Filename : draft-lind-v6ops-isp-scenarios-01.txt > Pages : 20 > Date : 2003-10-23 >=20 > This document describes different scenarios for the introduction of > IPv6 in an IPv4 ISP network. The goal is the addition of a native > IPv6 service to the already existing IPv4 service without > interruption of the IPv4 service. During the IPv6 introduction the > network can go through 4 different stages including the initial IPv4 > only stage. To move between the stages there will be some form of > transition that can be defined in different transition scenarios. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lind-v6ops-isp-scenarios-01.tx t >=20 > 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. >=20 > 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-lind-v6ops-isp-scenarios-01.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lind-v6ops-isp-scenarios-01.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > From owner-v6ops@ops.ietf.org Mon Oct 27 04:18: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 EAA02746 for ; Mon, 27 Oct 2003 04:18:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE2Xk-000OQl-Hq for v6ops-data@psg.com; Mon, 27 Oct 2003 08:16:04 +0000 Received: from [202.97.224.98] (helo=mail.hl.cn) by psg.com with smtp (Exim 4.24; FreeBSD 4.9) id 1AE2XX-000OQL-MC for v6ops@ops.ietf.org; Mon, 27 Oct 2003 08:15:52 +0000 Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jm43f9d2e1b; Mon, 27 Oct 2003 16:04:32 +0800 Received: from asgard.ietf.org([132.151.6.40]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jm03f980faf; Thr, 23 Oct 2003 22:03:31 +0800 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1ACfag-00038S-IK for ietf-announce-list@asgard.ietf.org; Thu, 23 Oct 2003 09:33:26 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1ACfXp-00031b-Hj for all-ietf@asgard.ietf.org; Thu, 23 Oct 2003 09:30:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18587; Thu, 23 Oct 2003 09:30:18 -0400 (EDT) Message-Id: <200310231330.JAA18587@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-v6onbydefault-00.txt Date: Thu, 23 Oct 2003 09:30:18 -0400 X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-announce@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME,RCVD_IN_DSBL,RCVD_IN_NJABL,RCVD_IN_NJABL_RELAY, RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Dual Stack IPv6 on by Default Author(s) : S. Roy Filename : draft-ietf-v6ops-v6onbydefault-00.txt Pages : 18 Date : 2003-10-22 This document discusses problems that can occur when dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. The problems include application connection delays, poor connectivity, and network security. Its purpose is to raise awareness of these problems so that they can be fixed or worked around. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-v6onbydefault-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-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-10-22183942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-v6onbydefault-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-v6onbydefault-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-22183942.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Mon Oct 27 06:52: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 GAA08061 for ; Mon, 27 Oct 2003 06:52:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE5rf-0007ca-3u for v6ops-data@psg.com; Mon, 27 Oct 2003 11:48:51 +0000 Received: from [66.111.4.26] (helo=out2.smtp.messagingengine.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE5ra-0007c1-6X for v6ops@ops.ietf.org; Mon, 27 Oct 2003 11:48:46 +0000 Received: from smtp.us2.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id D3CED36A80F; Mon, 27 Oct 2003 06:48:43 -0500 (EST) Received: from 10.202.2.133 ([10.202.2.133] helo=smtp.us2.messagingengine.com) by messagingengine.com with SMTP; Mon, 27 Oct 2003 06:48:43 -0500 Received: by smtp.us2.messagingengine.com (Postfix, from userid 99) id 8FBC17C127; Mon, 27 Oct 2003 06:48:43 -0500 (EST) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.2 (F2.71; T1.001; A1.51; B2.12; Q2.03) From: "Chirayu Patel" To: v6ops@ops.ietf.org Date: Mon, 27 Oct 2003 17:18:43 +0530 X-Epoch: 1067255323 X-Sasl-enc: m1GrUg+Ifx+VyUzSFvn0cQ Cc: mkshin@pec.etri.re.kr Subject: Comments on drafi-shin-v6ops-application-transition-02.txt Message-Id: <20031027114843.8FBC17C127@smtp.us2.messagingengine.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Just finished going through the draft, and am sending comments. The document seems to be in good shape. CP Comments -------- 1. Section 2. 1st paragraph s/first step/first case/ 2. Section 3.3 5th paragraph "on how to the" is not grammatically correct. My suggestion is to rephrase the first sentence as: "Nevertheless, there should be some reasonable logic to enable the users to use the applications with any supported protocol version." 3. Section 4.2 2nd paragraph s/applications interoperate/applications to interoperate/ 4. Section 4.2 5th paragraph. Rephrase the first sentence to: "Some implementations of dual-stack do not support IPv4 mapped IPv6 addresses." Note: My understanding might be incorrect here. I have posed a question on this one below. 5. Section 4.2 9th paragraph Remove the reference to section 3.2 6. Section 5 8th paragraph s/Next, the problems/In the following sub-sections, the problems/ 7. Section 5.3 2nd paragraph Rephrase: "However, the recommendation is that all configured IP addresses should be go to allow applications to work to every kind of node" 8. Section 2 Transition will include one more case +-------------------+ | appv4/v6 | (appv4/v6 - applications supporting +-------------------+ both IPv4 and IPv6) | TCP / UDP | (transport protocols) +-------------------+ | IPv6 | (IP protocols supported/enabled in the OS) +-------------------+ Add section 4.5 to explain this case. 9. Section 3.3 4th paragraph. The text says: "However, as noted above..." in the context of complexities in wrapper application. I am not sure where "above" refers. The above paragraphs do not seem to contain the required information. IMHO, new text is needed to explain the complexities. 10. Section 4.1 2nd paragraph Text about the scenario where it is difficult to use BIA/BIS can be added here. "It is difficult to use these mechanisms with applications that embed IP addresses." 11. Section 4.1 3rd paragraph Give a reference to the section number where the "previous problem" is described. Are you referring to the problem defined in section 3.2? 12. Section 4.2 5th paragraph It is mentioned that there are some implementations of dual-stack that do not allow IPv4-mapped IPv6 addresses to be used. I assume that some implementations do not *support* these addresses. Can you give examples here? In addition, can you state reasons/references for not supporting IPv4 mapped addresses? Even though there is no explicit requirement in draft-ietf-ipv6-node-requirements-05.txt to support RFC2133, I think all implementations will support it. 13. Section 4.2 Last two points I think the first point is not necessary as the section is written with the assumption that the IPv6 applications will be used on dual- stack nodes. 14. Section 4.2 Last sentence The reference to "next section" in the last sentence is incorrect. 15. Section 4.3. 3rd paragraph Remove the third paragraph. It is redundant. It is a rehash of the 2nd paragraph. 16. Section 4.3 5th paragraph Can you explain what local protocol ordering means in "... but the applications themselves typically need not be aware of the local protocol ordering [RFC 3484]"? 17. Section 5.1 6th paragraph I agree that applications need not parse the zone identifier. It wasn't that obvious immediately (maybe because I am not very familiar with the API's). A small code snippet to show the same will help. 18. Section 5.1 last paragraph Usage of address literals is strongly discouraged for general purpose direct input. Can you provide with reasons, and references. One reason I can think of is - "length of the IPv6 address makes it difficult to remember, and use" 19. Section 5.2 4th paragraph s/applications can use multicast address/applications can use link-local scope all-nodes multicast address/ 20. Section 5.2 Point "Communication API functions" You mention "Their signatures". Is this common terminology? What do they mean? Function Prototypes? 21. Section 5.3 Can you provide function names as examples in this section? I got confused while reading "However, these functions use IP address structures, which are protocol independent" because I did not know which functions were you referring to. The same comment applies to the next paragraph, and 2nd paragraph section 5.4. 22. Section 5.4.3 I am not familiar with collaborative applications. Can you give few examples? Also, what are registry keys? Is this Windows specific? 23. Section 6.1 Set the value of sslen in the example. From owner-v6ops@ops.ietf.org Mon Oct 27 08:43: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 IAA12257 for ; Mon, 27 Oct 2003 08:43:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE7a1-000DkC-Nn for v6ops-data@psg.com; Mon, 27 Oct 2003 13:38:45 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE7Zy-000Djf-1w for v6ops@ops.ietf.org; Mon, 27 Oct 2003 13:38:42 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4B4E513A64 for ; Mon, 27 Oct 2003 08:38:41 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Oct 2003 08:38:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Review: draft-ietf-v6ops-v6onbydefault-00.txt Date: Mon, 27 Oct 2003 08:38:40 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122213@tayexc13.americas.cpqcorp.net> Thread-Topic: Review: draft-ietf-v6ops-v6onbydefault-00.txt Thread-Index: AcObRdHmn5XB1BPyRyi/oaWkaOQmHwBScL+A From: "Bound, Jim" To: X-OriginalArrivalTime: 27 Oct 2003 13:38:41.0022 (UTC) FILETIME=[A217A1E0:01C39C8F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable WG sorry mean't to send this to v6ops. =20 /jim -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Bound, Jim Sent: Saturday, October 25, 2003 6:18 PM To: ipv6@ietf.org Subject: Review: draft-ietf-v6ops-v6onbydefault-00.txt Input on draft-ietf-v6ops-v6onbydefault-00.txt below. This will be a good BCP IPv6 Operational RFC to publish is my input. Neighbor Discovery's [ND] conceptual sending algorithm dictates that when sending a packet to a destination, if a host's default router list is empty, then the host assumes that the destination is on-link. Suggest replace "dictate" with "suggests or states" in the first sentence. Rationale is the conceptual sending algrithm is not required to be implemented in ND. Dictate as word seems inappropriate. For an IPv6 enabled host deployed on a network that has no IPv6 routers as is the case in this scenario, the result is that link-layer address resolution must be performed on all IPv6 addresses to which the host sends packets. If IPv6 is enabled this resolution in most cases before the node completes booting to the user interface. So link-layer address resolution was done anyway. I don't get what the negative concern is in the above sentences. The Application will not receive acknowledgment of the unreachability of destinations that are not on-link until at least address resolution has failed, which is no less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), plus any transport layer connection timeouts which could be minutes in the case of TCP. The delay with respect to TCP is discussed later in Section 2.3. It seems to me a real good implementation feature for a network OS subsystem kernel would be to have a conditional test if any IPv6 route exists early in the stack if dst is IPv6. If IPv6 hosts don't assume that destinations are on-link as described above, then communication with destinations that are not on-link and unreachable will immediately fail. Nodes should only assume this if they received an RA prefix set with L bit set. Otherwise they should not assume this or they are not compliant to ND. If nodes have received the L bit and prefixes after the check I suggest above the next check would be if any prefixes have been announced and if not rejection could take place then. But, some may suggest that always send the packet somewhere for some deployment scenarios I can think of, but not many. The IPv6 implementation should be able to immediately notify applications that it has no route to such IPv6 destinations, and applications won't waste time waiting for address resolution to fail. This is a good suggestion, given the dst address was not on link and known from the L bit. But, whether this works is dependent on the API capability of the application and passing up dst unreachable as a note. If hosts need to communicate with on-link destinations, then then they need to be explicitly configured to have on-link routes for those destinations This is a strong statement. So the spec is saying unless a node receives an L bit set with prefix set do not attempt communications with onlink nodes, I assume except for link-local addresses. As a general rule this might be good, but not as an absolute rule. The on-link assumption is problematic in ways not directly related to the scenario described, but they should still be briefly mentioned here. One problem is that default routes are not special. The on-link assumption as stated in [ND] would have a host assume that all destinations are on-link when its default router list is empty. I don't see ND stating that at all? Can you point to the text that causes you to believe this? Unless an L bit set with prefix set has been received a node can make no actual assumption except guess, when there is no default router available or router for a dst route. Clearly it shouldn't make this assumption if it has an off-link route that covers the destination and that route isn't a default route. The absence of a default route does not mean that destinations are not reachable through more specific routes. Agree. But isn't this just an example of a very bad implementation of IPv6 and common sense to most engineers that build IP stacks? But ok by me if we want to point this out. Another problem is that the on-link assumption behavior is undefined on multi-homed hosts.=20 Not quite absolute. Each link is known if it received an L bit with prefixes. on-link behavior has to be considered link by link case within an implementation, whether they are multihomed nodes or not. Whether the node knows that it has another link to send a packet to for IPv6 is orthognal to IPv6 being on be default, which is a premise for this spec. Not saying IPv6 does not have more work to do on multihoming, but possibly this problem is another section? It is not caused by on-link assumptions in the implementation. When such a host has no default routers and it is trying to reach a destination to which it has no route, should it try NUD on all interfaces at once? That is an implementation decision, not standards decision. Should it simply realize that the destination is unreachable? The latter is the simplest solution. Determining that a destination is unreachable when there is no route to that destination is the simple solution for all cases, not just the multi-homed case. But if node knows from L bit prefixes it can tell if the dst is on-link and an optimization that is important to several user network operations. Using the feature of ND L bit with prefix set helps avoid just sending directly on the link when no route is present for a dst or a default route. 3.2 Poor IPv6 Network Performance By default in dual stack nodes, applications will try IPv6 destinations first. I don't tbink we can say this nor is it required. This will be a configuration option is my belief for users to decide for their network. If the IPv6 connectivity to those destinations is poor while the IPv4 connectivity is better (i.e., the IPv6 traffic experiences higher latency, lower throughput, or more lost packets than IPv4 traffic), applications will still communicate over IPv6 at the expense of network performance. There is no information available to applications in this case to advise them to try another destination address. This is why a good implementation will permit address selection to be configured and dynamically too. Good Analysis and Work Thanks, /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Oct 27 08:44: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 IAA12275 for ; Mon, 27 Oct 2003 08:44:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE7aX-000Dlp-BO for v6ops-data@psg.com; Mon, 27 Oct 2003 13:39:17 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE7aT-000DlW-Po for v6ops@ops.ietf.org; Mon, 27 Oct 2003 13:39:13 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 56B7F13870 for ; Mon, 27 Oct 2003 08:39:13 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 27 Oct 2003 08:39:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Review: draft-ietf-v6ops-onlinkassumption-00.txt Date: Mon, 27 Oct 2003 08:39:12 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B05122214@tayexc13.americas.cpqcorp.net> Thread-Topic: Review: draft-ietf-v6ops-onlinkassumption-00.txt Thread-Index: AcObSLk2Bhl3ZNsvSYCdxgumn+yyewBRvJJQ From: "Bound, Jim" To: X-OriginalArrivalTime: 27 Oct 2003 13:39:13.0150 (UTC) FILETIME=[B53DF9E0:01C39C8F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable WG sorry. mean't to send this one to v6ops too. /jim -----Original Message----- From: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On Behalf Of Bound, Jim Sent: Saturday, October 25, 2003 6:38 PM To: ipv6@ietf.org Subject: Review: draft-ietf-v6ops-onlinkassumption-00.txt Review input on draft-ietf-v6ops-onlinkassumption-00.txt and suggestions for next steps. 1. Introduction Neighbor Discovery for IPv6 [ND] defines a conceptual sending algorithm for hosts. This algorithm states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This assumption creates problems for destination address selection as defined in [ADDRSEL], and adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined in multihomed scenarios, and has some subtle security implications. All of these issues are discussed in this document. This entire spec is predicated on statement in 2461 that are conceptual and not required as compliance to ND RFC 2461. In fact I know multiple implementations that approached some of the specifics of this differently, which is fine as this part of ND gets into a suggestion and not an IETF compliance to the standard. Also below is the wording I think relative I provide from 2461. I also want to note the caveat stated in section 5. below where ND clearly states it is not addressing the issues of source address selection and multihomed hosts. I recall when this was added to ND and the spec in review here is exactly why it made me nervous to put it in ND, thus the lower paragraph in section 5. inroduction below my comments. I believe the L bit with prefix options is an excellent optimzation for communications for IPv6 if used correctly. That is not the issue. So I would like to suggest that the title currently of the draft "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful" is not a good reference to the problem the spec is concerned with. At a minimum it should have something like "conceptual sending algorithm" should be checked or however best to denote this spec's issue. But the current title I feel is misleading. My input to the authors and the IPv6 WG is that providing a BCP update to section 5 for address selection, and then probably a different spec for multihomed hosts is the work to be done. ND section 5 is very clear as a spec this is a "conceptual" reference and that it is specifically not to be used for address selection or multihomed hosts. See 2461 references below. From 2461 5. Conceptual Model of a Host 5. CONCEPTUAL MODEL OF A HOST This section describes a conceptual model of one possible data structure organization that hosts (and to some extent routers) will maintain in interacting with neighboring nodes. The described organization is provided to facilitate the explanation of how the Neighbor Discovery protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document. This model is only concerned with the aspects of host behavior directly related to Neighbor Discovery. In particular, it does not concern itself with such issues as source address selection or the selecting of an outgoing interface on a multihomed host. From 2461 5.2 Conceptual Sending Algorithm Next-hop determination for a given unicast destination operates as follows. The sender performs a longest prefix match against the Prefix List to determine whether the packet's destination is on- or off-link. If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6). If the Default Router List is empty, the sender assumes that the destination is on-link. Thanks, /jim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Oct 27 09:00: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 JAA13150 for ; Mon, 27 Oct 2003 09:00:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE7rs-000Ezj-V3 for v6ops-data@psg.com; Mon, 27 Oct 2003 13:57:12 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE7ro-000EzM-9C for v6ops@ops.ietf.org; Mon, 27 Oct 2003 13:57:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9RDv4W10546 for ; Mon, 27 Oct 2003 15:57:04 +0200 Date: Mon, 27 Oct 2003 15:57:04 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-onlinkassumption-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, There was a follow-up on Jim's post about onlinkassumption on the list which is probably relevant to this WG as well. ---------- Forwarded message ---------- Date: Mon, 27 Oct 2003 11:04:26 +0100 (CET) From: Erik Nordmark To: "Bound, Jim" Cc: ipv6@ietf.org Subject: Re: Review: draft-ietf-v6ops-onlinkassumption-00.txt > This entire spec is predicated on statement in 2461 that are conceptual > and not required as compliance to ND RFC 2461. Well, the behavior is actually used in section 6.3.6 "Default Router Selection" where section 6 is "host specificatio", thus it isn't only a conceptual thing. 6.3.6 says: 3) If the Default Router List is empty, assume that all destinations are on-link as specified in Section 5.2. At a minimum the specification is unclear on the requirements in this space, but the way I read it (and wrote it :-) this is something that nodes are recommended to do. Thus I think we need to change that recommendation and make the specification clearer in the process. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Mon Oct 27 09:45: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 JAA16565 for ; Mon, 27 Oct 2003 09:45:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AE8Yl-000ISz-Ns for v6ops-data@psg.com; Mon, 27 Oct 2003 14:41:31 +0000 Received: from [194.250.197.211] (helo=proxy.6wind.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AE8Yi-000ISi-3C for v6ops@ops.ietf.org; Mon, 27 Oct 2003 14:41:28 +0000 Received: from 6wind.com (unknown [10.0.0.101]) by proxy.6wind.com (Postfix) with ESMTP id 16C9E3C2; Mon, 27 Oct 2003 15:41:27 +0100 (CET) Message-ID: <3F9D2EC6.861507B6@6wind.com> Date: Mon, 27 Oct 2003 15:42:14 +0100 From: Vladimir Ksinant X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" Cc: v6ops@ops.ietf.org, mikael.lind@teliasonera.com, Raffaele.Dalbenzio@TILAB.COM, Roger.Wenner@telekom.de, otter@surfnet.nl, Erik-Jan.Bos@surfnet.nl, ikejiri@byd.ocn.ad.jp, jeremy.de_clercq@alcatel.be, ikejiri@ntt.ocn.ne.jp, stuart.prevost@bt.com, dirk.ooms@alcatel.be Subject: Re: A comment on References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Please see my comments below: "Francois Le Faucheur (flefauch)" wrote: > > Hello Vladimir, > > In section 3.3, I noticed the following: > > " When MPLS is already deployed in the backbone, it may be desirable > to provide IPv6-over-MPLS connectivity. However, the problem is that > setting up an IPv6 Label Switched Path (LSP) requires some signaling > through the MPLS network. Currently, there is no direct mechanism to > do this for IPv6. A workaround is to use BGP for signaling and/or > perform IPv6-over-IPv4-over-MPLS encapsulation, as described in > [BGPTUNNEL]. More analysis is needed on what is the right approach > in this case. > " > > Well, there actually are mechanims specified to set up IPv6 LSPs: both > LDP and RSVP-TE specifications cover both label binding for IPv4 and > for IPv6. > Yes, agreed. In the document, we did not want to cover the various ways to provide IPv6 support on all possible underlying technologies. We also wanted to keep it simple and not to go into too many details. The goal of the text above was to show that when native IPv6 signalling is not yet enabled on the MPLS network, IPv6 support can still be provided. The text can probably be enhanced. Thank you for your comments. Vladimir From owner-v6ops@ops.ietf.org Mon Oct 27 19:22: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 TAA00407 for ; Mon, 27 Oct 2003 19:22:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEHZk-000PYX-0O for v6ops-data@psg.com; Tue, 28 Oct 2003 00:19:08 +0000 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEHZb-000PXb-8s for v6ops@ops.ietf.org; Tue, 28 Oct 2003 00:18:59 +0000 Received: from pec.etri.re.kr (mkshin.etri.re.kr [129.254.112.163]) by pec.etri.re.kr (8.12.10/8.12.10) with ESMTP id h9S0XZ5l027690; Tue, 28 Oct 2003 09:33:35 +0900 (KST) Message-ID: <3F9DB5E5.35BAE00A@pec.etri.re.kr> Date: Tue, 28 Oct 2003 09:18:45 +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: Chirayu Patel CC: v6ops@ops.ietf.org Subject: Re: Comments on drafi-shin-v6ops-application-transition-02.txt References: <20031027114843.8FBC17C127@smtp.us2.messagingengine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_RFCI autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Chirayu, Thanks for your review. I will keep all of these comments. Regards, Myung-Ki. Chirayu Patel wrote: > Hello, > > Just finished going through the draft, and am sending comments. The > document seems to be in good shape. > > CP > > Comments > -------- > > 1. Section 2. 1st paragraph > > s/first step/first case/ > > 2. Section 3.3 5th paragraph > > "on how to the" is not grammatically correct. > > My suggestion is to rephrase the first sentence as: > > "Nevertheless, there should be some reasonable logic to enable the users > to use the applications with any supported protocol version." > > 3. Section 4.2 2nd paragraph > > s/applications interoperate/applications to interoperate/ > > 4. Section 4.2 5th paragraph. > > Rephrase the first sentence to: > > "Some implementations of dual-stack do not support IPv4 mapped IPv6 > addresses." > > Note: My understanding might be incorrect here. I have posed a question > on this one below. > > 5. Section 4.2 9th paragraph > > Remove the reference to section 3.2 > > 6. Section 5 8th paragraph > > s/Next, the problems/In the following sub-sections, the problems/ > > 7. Section 5.3 2nd paragraph > > Rephrase: "However, the recommendation is that all configured IP > addresses should be go to allow applications to work to every kind of > node" > > 8. Section 2 > > Transition will include one more case > > +-------------------+ > | appv4/v6 | (appv4/v6 - applications supporting > +-------------------+ both IPv4 and IPv6) > | TCP / UDP | (transport protocols) > +-------------------+ > | IPv6 | (IP protocols supported/enabled in the OS) > +-------------------+ > > Add section 4.5 to explain this case. > > 9. Section 3.3 4th paragraph. > > The text says: "However, as noted above..." in the context of > complexities in wrapper application. I am not sure where "above" refers. > The above paragraphs do not seem to contain the required information. > IMHO, new text is needed to explain the complexities. > > 10. Section 4.1 2nd paragraph > > Text about the scenario where it is difficult to use BIA/BIS can be added > here. "It is difficult to use these mechanisms with applications that > embed IP addresses." > > 11. Section 4.1 3rd paragraph > > Give a reference to the section number where the "previous problem" is > described. Are you referring to the problem defined in section 3.2? > > 12. Section 4.2 5th paragraph > > It is mentioned that there are some implementations of dual-stack that do > not allow IPv4-mapped IPv6 addresses to be used. I assume that some > implementations do not *support* these addresses. > > Can you give examples here? In addition, can you state reasons/references > for not supporting IPv4 mapped addresses? Even though there is no > explicit requirement in draft-ietf-ipv6-node-requirements-05.txt to > support RFC2133, I think all implementations will support it. > > 13. Section 4.2 Last two points > > I think the first point is not necessary as the section is written > with the assumption that the IPv6 applications will be used on dual- > stack nodes. > > 14. Section 4.2 Last sentence > > The reference to "next section" in the last sentence is incorrect. > > 15. Section 4.3. 3rd paragraph > > Remove the third paragraph. It is redundant. It is a rehash of the 2nd > paragraph. > > 16. Section 4.3 5th paragraph > > Can you explain what local protocol ordering means in "... but the > applications themselves typically need not be aware of the local protocol > ordering [RFC 3484]"? > > 17. Section 5.1 6th paragraph > > I agree that applications need not parse the zone identifier. It wasn't > that obvious immediately (maybe because I am not very familiar with the > API's). A small code snippet to show the same will help. > > 18. Section 5.1 last paragraph > > Usage of address literals is strongly discouraged for general purpose > direct input. Can you provide with reasons, and references. One reason I > can think of is - "length of the IPv6 address makes it difficult to > remember, and use" > > 19. Section 5.2 4th paragraph > > s/applications can use multicast address/applications can use link-local > scope all-nodes multicast address/ > > 20. Section 5.2 Point "Communication API functions" > > You mention "Their signatures". Is this common terminology? What do they > mean? Function Prototypes? > > 21. Section 5.3 > > Can you provide function names as examples in this section? I got > confused while reading "However, these functions use IP address > structures, which are protocol independent" because I did not know which > functions were you referring to. > > The same comment applies to the next paragraph, and 2nd paragraph > section 5.4. > > 22. Section 5.4.3 > > I am not familiar with collaborative applications. Can you give few > examples? Also, what are registry keys? Is this Windows specific? > > 23. Section 6.1 > > Set the value of sslen in the example. From owner-v6ops@ops.ietf.org Tue Oct 28 07:35:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18379 for ; Tue, 28 Oct 2003 07:35:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AESzF-0007G7-CJ for v6ops-data@psg.com; Tue, 28 Oct 2003 12:30:13 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AESz9-0007F9-Sp for v6ops@ops.ietf.org; Tue, 28 Oct 2003 12:30:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9SCU6432719; Tue, 28 Oct 2003 14:30:06 +0200 Date: Tue, 28 Oct 2003 14:30:05 +0200 (EET) From: Pekka Savola To: v6ops@ops.ietf.org cc: ipv6@ietf.org Subject: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (Cc:'ed to ipv6@ietf.org as well, because this seems to have significant impact with the IPv6 APIs as well..) When revising my "transarch" document, I noticed another issue v6 on-by-default might cause. If v6 is enabled by default, all the implementations I know generate the link-local addresses for all the interfaces automatically, unless explicitly configured otherwise (some don't have this knob). This seems to cause an unintended consequence with getaddrinfo and its AI_ADDRCONFIG hint (as specified in the basic socket API RFC). That is, AI_ADDRCONFIG hint causes AAAA DNS queries to be made only if an IPv6 address is configured on the node (similar with v4). Loopback addresses are excluded from this. However, these typically autoconfigured link-local addresses are *not* excluded. In consequence, AI_ADDRCONFIG seems to be of less utility than at least I had hoped. The only reason I could think of for AI_ADDRCONFIG *not* excluding the link-locals as well could be that if a node is expected to be able to communicate using regular, getaddrinfo() -using apps, using the link-local addresses (this would eliminate this possibility). IMHO, using link-local addresses for anything except well-specified purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really counter-productive -- as you'll have to make those apps be able to distinguish the zone identifiers as well, and that's probably something we DON'T want to do. But your mileage may vary. So, I'll conclude by a few questions to give food for thought: - does this seem like a problem, that is, should getaddrinfo() + AI_ADDRCONFIG perform AAAA DNS queries etc. if the node only has v6 link-local/loopback addresses? - is getaddrinfo() + link-local addresses something we should support? - should this be fixed by e.g.: a) recommending that the implementations filter out link-locals as well when doing AI_ADDRCONFIG (a BCP/Info document) b) specifying additional semantics for AI_ADDRCONFIG c) specifying a new hint which would perform this Note: if we go select any of these (especially the latter two), it might make sense to bring this discussion up in the relevant API forums like POSIX as well, because the IETF API documents are just Informational RFCs. -- 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 Oct 28 09:21:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22390 for ; Tue, 28 Oct 2003 09:21:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEUd2-000CU1-5Y for v6ops-data@psg.com; Tue, 28 Oct 2003 14:15:24 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEUcv-000CTS-Fh for v6ops@ops.ietf.org; Tue, 28 Oct 2003 14:15:17 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21440; Tue, 28 Oct 2003 09:15:06 -0500 (EST) Message-Id: <200310281415.JAA21440@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-01.txt Date: Tue, 28 Oct 2003 09:15:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Transition Mechanisms for IPv6 Hosts and Routers Author(s) : E. Nordmark, R. Gilligan Filename : draft-ietf-v6ops-mech-v2-01.txt Pages : 26 Date : 2003-10-27 This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-mech-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-mech-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28093435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-mech-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-mech-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28093435.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Oct 28 16:31:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27628 for ; Tue, 28 Oct 2003 16:31:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEbNk-000C3E-RN for v6ops-data@psg.com; Tue, 28 Oct 2003 21:28:04 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEbNV-000C1p-PN for v6ops@ops.ietf.org; Tue, 28 Oct 2003 21:27:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24928; Tue, 28 Oct 2003 15:42:16 -0500 (EST) Message-Id: <200310282042.PAA24928@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-ipv6use-00.txt Date: Tue, 28 Oct 2003 15:42:16 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 in 3GPP networks satisfying IETF's recommendations Author(s) : J. Yoo Filename : draft-ietf-v6ops-3gpp-ipv6use-00.txt Pages : 11 Date : 2003-10-28 3GPP PS (Packet Switched) domain Standard states the usage of IPv6 as its network protocol to compensate the shortage of Internet address and to use the enhanced network protocol functions. In case of the current IPv6 usage in 3GPP packet domain standards, they have unique IPv6 address allocation scheme which is somewhat different from the one of IETF due to its 3G equipments and packet network elements. Meanwhile, IETF presents 'recommendations to 3GPP networks (RFC3314 [2])' to satisfy compatibility between IETF IPv6 and IPv6 of 3GPP networks and to lift up the IPv6 capabilities. In this situation, this document provides a new IPv6 address allocation scheme in 3GPP networks satisfying IETF' recommendations. Provided scheme keeps rules of recommendations of IETF standards and guarantees backward compatibility with the legacy 3GPP IPv6 autoconfiguration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-ipv6use-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-ipv6use-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-ipv6use-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-10-28155542.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-ipv6use-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-ipv6use-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155542.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Oct 28 16:32: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 QAA27646 for ; Tue, 28 Oct 2003 16:32:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEbNZ-000C2K-9M for v6ops-data@psg.com; Tue, 28 Oct 2003 21:27:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEbNT-000C1p-Q7 for v6ops@ops.ietf.org; Tue, 28 Oct 2003 21:27:48 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24912; Tue, 28 Oct 2003 15:42:09 -0500 (EST) Message-Id: <200310282042.PAA24912@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-07.txt Date: Tue, 28 Oct 2003 15:42:08 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-07.txt Pages : 21 Date : 2003-10-28 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-analysis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-07.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-10-28155529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155529.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Oct 28 21:01: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 VAA16397 for ; Tue, 28 Oct 2003 21:01:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEfah-00002I-U8 for v6ops-data@psg.com; Wed, 29 Oct 2003 01:57:43 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEfac-00001r-DJ for v6ops@ops.ietf.org; Wed, 29 Oct 2003 01:57:38 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 7F44589; Wed, 29 Oct 2003 10:57:37 +0900 (JST) To: pekkas@netcore.fi Cc: v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Your message of "Tue, 28 Oct 2003 14:30:05 +0200 (EET)" References: X-Mailer: Cue version 0.6 (031002-0709/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20031029015737.7F44589@coconut.itojun.org> Date: Wed, 29 Oct 2003 10:57:37 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > So, I'll conclude by a few questions to give food for thought: > > - does this seem like a problem, that is, should getaddrinfo() + > AI_ADDRCONFIG perform AAAA DNS queries etc. if > the node only has v6 link-local/loopback addresses? > > - is getaddrinfo() + link-local addresses something we should support? > > - should this be fixed by e.g.: > a) recommending that the implementations filter out link-locals as well > when doing AI_ADDRCONFIG (a BCP/Info document) > b) specifying additional semantics for AI_ADDRCONFIG > c) specifying a new hint which would perform this d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and way too difficult to specify (for instance, if you have IPv6 global unicast address and no route, is it configured?). also, even without AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will issue the right error). itojun From owner-v6ops@ops.ietf.org Wed Oct 29 00: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 AAA26015 for ; Wed, 29 Oct 2003 00:45:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEj5P-000GRS-Js for v6ops-data@psg.com; Wed, 29 Oct 2003 05:41:39 +0000 Received: from [4.40.179.32] (helo=tndh.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEj5M-000GR2-47 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 05:41:36 +0000 Received: from eaglet (127.0.0.1:3318) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 28 Oct 2003 21:41:36 -0800 From: "Tony Hain" To: "Pekka Savola" , Cc: Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Tue, 28 Oct 2003 21:41:32 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > ... > IMHO, using link-local addresses for anything except well-specified > purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really > counter-productive in your limited world this is undoubtedly true, but there is a wider world out there. > -- as you'll have to make those apps be able to > distinguish the zone identifiers as well, and that's probably > something we > DON'T want to do. But your mileage may vary. > > So, I'll conclude by a few questions to give food for thought: > > - does this seem like a problem, that is, should getaddrinfo() + > AI_ADDRCONFIG perform AAAA DNS queries etc. if > the node only has v6 link-local/loopback addresses? It is not a problem if you follow addr selection rules and prefer matching scopes. This will cause IPv4 to be used if there is only a LL, trying to talk to a AAAA global. > > - is getaddrinfo() + link-local addresses something we should support? Absolutely in the standard. In your specific network, you can turn this off if it causes you to loose sleep at night. > > - should this be fixed by e.g.: > a) recommending that the implementations filter out > link-locals as well > when doing AI_ADDRCONFIG (a BCP/Info document) > b) specifying additional semantics for AI_ADDRCONFIG > c) specifying a new hint which would perform this > > Note: if we go select any of these (especially the latter two), it might > make sense to bring this discussion up in the relevant API forums like > POSIX as well, because the IETF API documents are just Informational RFCs. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Wed Oct 29 01:11:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26757 for ; Wed, 29 Oct 2003 01:11:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjVh-000IWD-If for v6ops-data@psg.com; Wed, 29 Oct 2003 06:08:49 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjVd-000IVc-0Y for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:08:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T68dp19104; Wed, 29 Oct 2003 08:08:39 +0200 Date: Wed, 29 Oct 2003 08:08:39 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org, Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 28 Oct 2003, Tony Hain wrote: [...] > > So, I'll conclude by a few questions to give food for thought: > > > > - does this seem like a problem, that is, should getaddrinfo() + > > AI_ADDRCONFIG perform AAAA DNS queries etc. if > > the node only has v6 link-local/loopback addresses? > > It is not a problem if you follow addr selection rules and prefer > matching scopes. This will cause IPv4 to be used if there is only a LL, > trying to talk to a AAAA global. Uhh, I don't think Default Address Selection helps at all here. The question is NOT how you prefer the addresses after you've queried them, it's whether you query them *at all*. I.e., the point of the AI_ADDRCONFIG as it seems to me is to avoid an unnecessary query of IPv6 addresses in the first place. For example, the app wants to look up www.example.com. Prior to making that lookup, it must know which addresses are configured on the node if AI_ADDRCONFIG is used. It doesn't know about scopes of www.example.com at this point. If there are no IPv6 addresses (including link-locals) configured, it'll query only A records and then perform default address selection as you say, naturally ending up with IPv4 as there are no alternatives. If there are IPv6 addresses (including link-locals), it'll query both A and AAAA records and perform default address selection, probably also resulting in IPv4 if no global IPv6 addresses were configured. -- 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 Oct 29 01:15: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 BAA26958 for ; Wed, 29 Oct 2003 01:15:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjaZ-000Itr-DW for v6ops-data@psg.com; Wed, 29 Oct 2003 06:13:51 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjaW-000ItX-Rn for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:13:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T6DdG19184; Wed, 29 Oct 2003 08:13:40 +0200 Date: Wed, 29 Oct 2003 08:13:38 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029015737.7F44589@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Jun-ichiro itojun Hagino wrote: > d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and > way too difficult to specify (for instance, if you have IPv6 global > unicast address and no route, is it configured?). also, even without > AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will > issue the right error). Agreed, that might be one option. Without the on-link assumption, the default route case should be rather simple, though. You'd only have to look at the addresses. IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in dual-stack deployments where IPv6 connectivity is not yet enabled. Of course, properly written apps would most probably also work there, but some apps are not properly written, but: - there are really misbehaving DNS servers out there, which jeopardize your IPv4 service if you query for AAAA's, and - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA queries - maybe other considerations we haven't figured out / thought out 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 Oct 29 01:24:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27226 for ; Wed, 29 Oct 2003 01:24:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjiV-000JdJ-VB for v6ops-data@psg.com; Wed, 29 Oct 2003 06:22:03 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjiT-000Jct-4g for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:22:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T6L9a19295; Wed, 29 Oct 2003 08:21:09 +0200 Date: Wed, 29 Oct 2003 08:21:08 +0200 (EET) From: Pekka Savola To: nsyracus@ietf.org cc: willow@konkuk.ac.kr, , , Subject: I-D ACTION:draft-ietf-v6ops-3gpp-ipv6use-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, We have not authorized the publication of this document as draft-ietf-v6ops-*. In fact, we've never even heard of it before. It was undoubtedly meant to be a personal -00 submission. Please remove or rename it ASAP. Thanks, Pekka, Jonne, Bob v6ops co-chairs ---------- Forwarded message ---------- Date: Tue, 28 Oct 2003 15:42:16 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-ipv6use-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 in 3GPP networks satisfying IETF's recommendations Author(s) : J. Yoo Filename : draft-ietf-v6ops-3gpp-ipv6use-00.txt Pages : 11 Date : 2003-10-28 3GPP PS (Packet Switched) domain Standard states the usage of IPv6 as its network protocol to compensate the shortage of Internet address and to use the enhanced network protocol functions. In case of the current IPv6 usage in 3GPP packet domain standards, they have unique IPv6 address allocation scheme which is somewhat different from the one of IETF due to its 3G equipments and packet network elements. Meanwhile, IETF presents 'recommendations to 3GPP networks (RFC3314 [2])' to satisfy compatibility between IETF IPv6 and IPv6 of 3GPP networks and to lift up the IPv6 capabilities. In this situation, this document provides a new IPv6 address allocation scheme in 3GPP networks satisfying IETF' recommendations. Provided scheme keeps rules of recommendations of IETF standards and guarantees backward compatibility with the legacy 3GPP IPv6 autoconfiguration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-ipv6use-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-3gpp-ipv6use-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-3gpp-ipv6use-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-v6ops@ops.ietf.org Wed Oct 29 01:27:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27316 for ; Wed, 29 Oct 2003 01:27:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjla-000JtA-LC for v6ops-data@psg.com; Wed, 29 Oct 2003 06:25:14 +0000 Received: from [2001:218:1:1040::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjlY-000Jsf-MY for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:25:12 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 12DB41FE47; Wed, 29 Oct 2003 15:25:12 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 6FD20125FBD; Wed, 29 Oct 2003 15:25:11 +0900 (JST) Date: Wed, 29 Oct 2003 15:25:11 +0900 (JST) Message-Id: <20031029.152511.78736736.yasuhiro@nttv6.jp> To: Mikael.Lind@teliasonera.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt From: SHIRASAKI Yasuhiro In-Reply-To: <7B64D9FB62EB42449683BA51E9AB2AE80185FCC8@TMS031MB.tcad.telia.se> References: <7B64D9FB62EB42449683BA51E9AB2AE80185FCC8@TMS031MB.tcad.telia.se> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Lind, In section 5.7, Figure 7 shows that all of network elements except "Exchange" are converted into "Dual", but the Exchange is still remained as "IPv4 + IPv6". Does it have any specific meaning? Some IXs seemed to be dual stack already. regards, -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Wed Oct 29 01:56: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 BAA28176 for ; Wed, 29 Oct 2003 01:56:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkDZ-000MFv-GN for v6ops-data@psg.com; Wed, 29 Oct 2003 06:54:09 +0000 Received: from [2001:700:1:4:202:55ff:fe67:bc18] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkDW-000MFU-Ee for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:54:06 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id h9T6rPpI003059; Wed, 29 Oct 2003 07:53:25 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id h9T6rPR7031934; Wed, 29 Oct 2003 07:53:25 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id h9T6rOAk031933; Wed, 29 Oct 2003 07:53:24 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 29 Oct 2003 07:53:24 +0100 From: Stig Venaas To: Pekka Savola Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031029065324.GA31918@sverresborg.uninett.no> References: <20031029015737.7F44589@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Oct 29, 2003 at 08:13:38AM +0200, Pekka Savola wrote: > - there are really misbehaving DNS servers out there, which jeopardize > your IPv4 service if you query for AAAA's, and > - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA > queries > - maybe other considerations we haven't figured out / thought out yet. And I've seen cases where you never get a reply to the AAAA query, which means that the application will wait for quite some time. Probably too clever firewalls or broken DNS server software. So I've seen people turn off IPv6 in apps using getaddrinfo() looping through the addresses the normal way, due to this. I don't like the idea of changing getaddrinfo() because of this, one should rather attack the real problem. However that is much harder... Stig From owner-v6ops@ops.ietf.org Wed Oct 29 01:59:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28212 for ; Wed, 29 Oct 2003 01:59:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkGb-000MaO-Re for v6ops-data@psg.com; Wed, 29 Oct 2003 06:57:17 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkGZ-000Ma0-2M for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:57:15 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 75FB096; Wed, 29 Oct 2003 15:57:10 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org, ipv6@ietf.org In-reply-to: pekkas's message of Wed, 29 Oct 2003 08:13:38 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG From: itojun@iijlab.net Date: Wed, 29 Oct 2003 15:57:10 +0900 Message-Id: <20031029065710.75FB096@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and >> way too difficult to specify (for instance, if you have IPv6 global >> unicast address and no route, is it configured?). also, even without >> AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will >> issue the right error). > >Agreed, that might be one option. > >Without the on-link assumption, the default route case should be rather >simple, though. You'd only have to look at the addresses. > >IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in >dual-stack deployments where IPv6 connectivity is not yet enabled. could you clarify what you meant by "dual-stack deployment"? if it means "RA is sent by routers even though there's no glbal IPv6 connectivity", that is a misconfiguration (outside of the issue w/ AI_ADDRCONFIG). if it means "dual-stack host in IPv4-only network", it can live fine without AI_ADDRCONFIG. >Of course, properly written apps would most probably also work there, but >some apps are not properly written, but: > > - there are really misbehaving DNS servers out there, which jeopardize >your IPv4 service if you query for AAAA's, and this is a separate problem (this is not what AI_ADDRCONFIG cares about). > - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA >queries this is a sane reason for keeping AI_ADDRCONFIG, but i doubt the roundtrip makes that much of difference. > - maybe other considerations we haven't figured out / thought out yet. :-) itojun From owner-v6ops@ops.ietf.org Wed Oct 29 02:10: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 CAA08864 for ; Wed, 29 Oct 2003 02:10:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkRN-000Nef-SV for v6ops-data@psg.com; Wed, 29 Oct 2003 07:08:25 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkRJ-000NeD-HS for v6ops@ops.ietf.org; Wed, 29 Oct 2003 07:08:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T78GC19997; Wed, 29 Oct 2003 09:08:16 +0200 Date: Wed, 29 Oct 2003 09:08:15 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029065710.75FB096@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Two points to clarify.. On Wed, 29 Oct 2003 itojun@iijlab.net wrote: > >IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in > >dual-stack deployments where IPv6 connectivity is not yet enabled. > > could you clarify what you meant by "dual-stack deployment"? [...] > if it means "dual-stack host in IPv4-only network", it can live fine > without AI_ADDRCONFIG. Yes, I mean the above. AI_ADDRCONFIG makes one avoid completely unnecessary AAAA DNS lookups in the case that the addresses are not useful in any case. > > - there are really misbehaving DNS servers out there, which jeopardize > >your IPv4 service if you query for AAAA's, and > > this is a separate problem (this is not what AI_ADDRCONFIG cares > about). Yes, this is a separate problem .. but one that AI_ADDRCONFIG works around for the vast majority of nodes which could be dual-stack, but without IPv6 connectivity. So, in that sense, IMHO AI_ADDRCONFIG helps the situation *a lot*, but of course we still have to fix the problem for those dual-stack nodes that do, in fact, have IPv6 connectivity. Remember, the most important thing we should care about is that dual-stack deployments can get more common without causing problems for *IPv4* or services in general. AI_ADDRCONFIG is one step in that 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 Wed Oct 29 02:13: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 CAA10739 for ; Wed, 29 Oct 2003 02:13:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkUE-000Nv1-IG for v6ops-data@psg.com; Wed, 29 Oct 2003 07:11:22 +0000 Received: from [219.101.47.130] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkUC-000NuW-Ao for v6ops@ops.ietf.org; Wed, 29 Oct 2003 07:11:20 +0000 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EA85D13; Wed, 29 Oct 2003 16:11:17 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org, ipv6@ietf.org In-reply-to: pekkas's message of Wed, 29 Oct 2003 09:08:15 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG From: itojun@iijlab.net Date: Wed, 29 Oct 2003 16:11:17 +0900 Message-Id: <20031029071117.EA85D13@coconut.itojun.org> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> > - there are really misbehaving DNS servers out there, which jeopardize >> >your IPv4 service if you query for AAAA's, and >> >> this is a separate problem (this is not what AI_ADDRCONFIG cares >> about). > >Yes, this is a separate problem .. but one that AI_ADDRCONFIG works around >for the vast majority of nodes which could be dual-stack, but without IPv6 >connectivity. So, in that sense, IMHO AI_ADDRCONFIG helps the situation >*a lot*, but of course we still have to fix the problem for those >dual-stack nodes that do, in fact, have IPv6 connectivity. > >Remember, the most important thing we should care about is that dual-stack >deployments can get more common without causing problems for *IPv4* or >services in general. AI_ADDRCONFIG is one step in that direction. for your story to be effective it has to be host-wide configuration knob, not a parameter to library function. (we cannot change every program we use to have AI_ADDRCONFIG) and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they work just fine... itojun From owner-v6ops@ops.ietf.org Wed Oct 29 02:29:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24396 for ; Wed, 29 Oct 2003 02:29:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkjM-000PDz-8p for v6ops-data@psg.com; Wed, 29 Oct 2003 07:27:00 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkjJ-000PDY-3y for v6ops@ops.ietf.org; Wed, 29 Oct 2003 07:26:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T7Qo920283; Wed, 29 Oct 2003 09:26:50 +0200 Date: Wed, 29 Oct 2003 09:26:50 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029071117.EA85D13@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003 itojun@iijlab.net wrote: [...] > >Remember, the most important thing we should care about is that dual-stack > >deployments can get more common without causing problems for *IPv4* or > >services in general. AI_ADDRCONFIG is one step in that direction. > > for your story to be effective it has to be host-wide configuration > knob, not a parameter to library function. (we cannot change every > program we use to have AI_ADDRCONFIG) Yep, or the apps writing guidelines could recommend to turn it on. The basic API spec already defines "AI_DEFAULT" even though it doesn't (AFAIR) specify that it should be the default :-) > and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they > work just fine... Yep, to the extent they're used. Stig already mentioned that some apps are moving to some custom address lookup hacks from getaddrinfo() due to these problems. The use of AI_ADDRCONFIG should help in the majority of cases, i.e., deploying v6-capable apps on nodes which don't have v6 connectivity 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 Oct 29 02:34:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26367 for ; Wed, 29 Oct 2003 02:34:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkp6-000PkG-Dv for v6ops-data@psg.com; Wed, 29 Oct 2003 07:32:56 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkp2-000Pja-0Z for v6ops@ops.ietf.org; Wed, 29 Oct 2003 07:32:52 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T7VMPk001938; Wed, 29 Oct 2003 08:31:23 +0100 (CET) Date: Wed, 29 Oct 2003 08:31:18 +0100 Subject: Re: Proposal : Common issues across Scenarios Design Team should be new work item Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA182@tayexc13.americas.cpqcorp.net> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim, > Proposal: Begin a new design team and effort to work on the common IPv6 > operational issues across any scenario that must be addressed (e.g. > DNS, > Porting, Mail). There are also probably common security issues for all > scenarios in addition to the specific ones for each scenario work > effort > in v6ops. isn't what you are really saying that there might be issues identified by the DTs that really should go to other WGs? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP59syKarNKXTPFCVEQJIUgCeOm6AHZoOZO5VzyPibQ/jxisV0VcAoJaq hVRvHgO8avlxmAteocW/3nqp =nWfQ -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 03:34: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 DAA28255 for ; Wed, 29 Oct 2003 03:33:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEliE-0004wJ-R9 for v6ops-data@psg.com; Wed, 29 Oct 2003 08:29:54 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEliA-0004vU-Qn for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:29:51 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T8TSPk001966; Wed, 29 Oct 2003 09:29:28 +0100 (CET) Date: Wed, 29 Oct 2003 09:29:24 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Mikael.Lind@teliasonera.com, v6ops@ops.ietf.org To: SHIRASAKI Yasuhiro From: Kurt Erik Lindqvist In-Reply-To: <20031029.152511.78736736.yasuhiro@nttv6.jp> Message-Id: <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 07:25 Europe/Stockholm, SHIRASAKI Yasuhiro wrote: > Hello Lind, > > In section 5.7, Figure 7 shows that all of network elements except > "Exchange" are converted into "Dual", but the Exchange is still > remained as "IPv4 + IPv6". Does it have any specific meaning? > > Some IXs seemed to be dual stack already. IXs in themselves should be completely agnostic to what you run over them as they are L2 - no? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP596ZqarNKXTPFCVEQLywwCghDFQBnXbVW90JdZreU6XylL6wRsAoPGt jUuk0RU6J9EJ36HHgVcJGtWT =zvQ7 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 03:34: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 DAA28279 for ; Wed, 29 Oct 2003 03:34:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEljG-00053j-49 for v6ops-data@psg.com; Wed, 29 Oct 2003 08:30:58 +0000 Received: from [131.115.230.132] (helo=tms001bb.han.telia.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEljB-000535-Sl for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:30:54 +0000 Received: from tms031mb.han.telia.se ([131.115.230.162]) by tms001bb.han.telia.se with Microsoft SMTPSVC(5.0.2195.5329); Wed, 29 Oct 2003 09:30:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6318.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Date: Wed, 29 Oct 2003 09:30:51 +0100 Message-ID: <7B64D9FB62EB42449683BA51E9AB2AE80185FCD8@TMS031MB.tcad.telia.se> Thread-Topic: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Thread-Index: AcOd5WvDQRgTNhcPTiuIcyjUr5+ijAAEEiKg From: To: Cc: X-OriginalArrivalTime: 29 Oct 2003 08:30:52.0333 (UTC) FILETIME=[F6B8D5D0:01C39DF6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >=20 > In section 5.7, Figure 7 shows that all of network elements except > "Exchange" are converted into "Dual", but the Exchange is still > remained as "IPv4 + IPv6". Does it have any specific meaning? >=20 > Some IXs seemed to be dual stack already. The intended meaning is that there can be separate exchange points for IPv4 and IPv6 as well as dual stack exchange points.=20 Regards, Mikael From owner-v6ops@ops.ietf.org Wed Oct 29 03:40:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28400 for ; Wed, 29 Oct 2003 03:40:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AElpt-0005o9-77 for v6ops-data@psg.com; Wed, 29 Oct 2003 08:37:49 +0000 Received: from [2001:218:1:1040::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AElpq-0005ne-SK for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:37:47 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 42FA71FE47; Wed, 29 Oct 2003 17:37:46 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 17DE9126909; Wed, 29 Oct 2003 17:37:46 +0900 (JST) Date: Wed, 29 Oct 2003 17:37:44 +0900 (JST) Message-Id: <20031029.173744.74716199.yasuhiro@nttv6.jp> To: kurtis@kurtis.pp.se Cc: Mikael.Lind@teliasonera.com, v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt From: SHIRASAKI Yasuhiro In-Reply-To: <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> References: <20031029.152511.78736736.yasuhiro@nttv6.jp> <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 29 Oct 2003 09:29:24 +0100, Kurt Erik Lindqvist wrote: > On onsdag, okt 29, 2003, at 07:25 Europe/Stockholm, SHIRASAKI Yasuhiro > wrote: > > > Hello Lind, > > > > In section 5.7, Figure 7 shows that all of network elements except > > "Exchange" are converted into "Dual", but the Exchange is still > > remained as "IPv4 + IPv6". Does it have any specific meaning? > > > > Some IXs seemed to be dual stack already. > > IXs in themselves should be completely agnostic to what you run over > them as they are L2 - no? IX based address assignment, health monitoring, statistics services, etc. might be IP version aware. -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Wed Oct 29 03:43: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 DAA28477 for ; Wed, 29 Oct 2003 03:43:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AElsr-00069a-Rt for v6ops-data@psg.com; Wed, 29 Oct 2003 08:40:53 +0000 Received: from [2001:218:1:1040::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AElso-00068x-9K for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:40:51 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id AF3411FE47; Wed, 29 Oct 2003 17:40:49 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 760CA125FBD; Wed, 29 Oct 2003 17:40:49 +0900 (JST) Date: Wed, 29 Oct 2003 17:40:49 +0900 (JST) Message-Id: <20031029.174049.41667937.yasuhiro@nttv6.jp> To: Mikael.Lind@teliasonera.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt From: SHIRASAKI Yasuhiro In-Reply-To: <7B64D9FB62EB42449683BA51E9AB2AE80185FCD8@TMS031MB.tcad.telia.se> References: <7B64D9FB62EB42449683BA51E9AB2AE80185FCD8@TMS031MB.tcad.telia.se> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 29 Oct 2003 09:30:51 +0100, wrote: > > In section 5.7, Figure 7 shows that all of network elements except > > "Exchange" are converted into "Dual", but the Exchange is still > > remained as "IPv4 + IPv6". Does it have any specific meaning? > > > > Some IXs seemed to be dual stack already. > > The intended meaning is that there can be separate exchange points for > IPv4 and IPv6 as well as dual stack exchange points. I got your point. thanks. -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Wed Oct 29 03:48:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28635 for ; Wed, 29 Oct 2003 03:48:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AElxD-0006hJ-Vq for v6ops-data@psg.com; Wed, 29 Oct 2003 08:45:23 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AElx9-0006gZ-7x for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:45:19 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 29-md50000000008.tmp for ; Wed, 29 Oct 2003 09:45:25 +0100 Message-ID: <131c01c39df8$fafc6100$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Date: Wed, 29 Oct 2003 09:45:16 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 29 Oct 2003 09:45:25 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt, We are working already with L3 IXs also ... (www.euro6ix.org). Regards, Jordi ----- Original Message ----- From: "Kurt Erik Lindqvist" To: "SHIRASAKI Yasuhiro" Cc: ; Sent: Wednesday, October 29, 2003 9:29 AM Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On onsdag, okt 29, 2003, at 07:25 Europe/Stockholm, SHIRASAKI Yasuhiro > wrote: > > > Hello Lind, > > > > In section 5.7, Figure 7 shows that all of network elements except > > "Exchange" are converted into "Dual", but the Exchange is still > > remained as "IPv4 + IPv6". Does it have any specific meaning? > > > > Some IXs seemed to be dual stack already. > > IXs in themselves should be completely agnostic to what you run over > them as they are L2 - no? > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 > > iQA/AwUBP596ZqarNKXTPFCVEQLywwCghDFQBnXbVW90JdZreU6XylL6wRsAoPGt > jUuk0RU6J9EJ36HHgVcJGtWT > =zvQ7 > -----END PGP SIGNATURE----- > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Oct 29 04:19:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29494 for ; Wed, 29 Oct 2003 04:19:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmRd-0009ot-J9 for v6ops-data@psg.com; Wed, 29 Oct 2003 09:16:49 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmRZ-0009oU-C8 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 09:16:45 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9GZPk001977; Wed, 29 Oct 2003 10:16:35 +0100 (CET) Date: Wed, 29 Oct 2003 10:16:30 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Mikael.Lind@teliasonera.com, v6ops@ops.ietf.org To: SHIRASAKI Yasuhiro From: Kurt Erik Lindqvist In-Reply-To: <20031029.173744.74716199.yasuhiro@nttv6.jp> Message-Id: <95035508-09F0-11D8-AB34-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> Hello Lind, >>> >>> In section 5.7, Figure 7 shows that all of network elements except >>> "Exchange" are converted into "Dual", but the Exchange is still >>> remained as "IPv4 + IPv6". Does it have any specific meaning? >>> >>> Some IXs seemed to be dual stack already. >> >> IXs in themselves should be completely agnostic to what you run over >> them as they are L2 - no? > > IX based address assignment, health monitoring, statistics services, > etc. > might be IP version aware. Address assignment I agree with. The rest I would classify as services that will fall under other migration scenarios. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+FcaarNKXTPFCVEQI/0ACg4SvomAe5Ay7STEMOHzSLatES95gAoLw+ BEuJYhw595U2/MsKKVrmIfNY =pi4L -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 04:20: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 EAA29517 for ; Wed, 29 Oct 2003 04:20:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmS5-0009sv-5U for v6ops-data@psg.com; Wed, 29 Oct 2003 09:17:17 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmS2-0009sZ-Vo for v6ops@ops.ietf.org; Wed, 29 Oct 2003 09:17:15 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9H4Pk001980; Wed, 29 Oct 2003 10:17:04 +0100 (CET) Date: Wed, 29 Oct 2003 10:17:01 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: , To: From: Kurt Erik Lindqvist In-Reply-To: <7B64D9FB62EB42449683BA51E9AB2AE80185FCD8@TMS031MB.tcad.telia.se> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 09:30 Europe/Stockholm, wrote: >> >> In section 5.7, Figure 7 shows that all of network elements except >> "Exchange" are converted into "Dual", but the Exchange is still >> remained as "IPv4 + IPv6". Does it have any specific meaning? >> >> Some IXs seemed to be dual stack already. > > The intended meaning is that there can be separate exchange points for > IPv4 and IPv6 as well as dual stack exchange points. Aha. Ok. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+Fj6arNKXTPFCVEQK/pQCgx8gLgbSGcOce7sj85ad1VHfoOaIAn1OJ /9qNJT6nMDKeYBnbJM/abwqe =l9qx -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 04:21:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29655 for ; Wed, 29 Oct 2003 04:21:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmUU-000A4m-9P for v6ops-data@psg.com; Wed, 29 Oct 2003 09:19:46 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmUS-000A4M-6N for v6ops@ops.ietf.org; Wed, 29 Oct 2003 09:19:44 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9JQPk001983; Wed, 29 Oct 2003 10:19:26 +0100 (CET) Date: Wed, 29 Oct 2003 10:19:22 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "JORDI PALET MARTINEZ" From: Kurt Erik Lindqvist In-Reply-To: <131c01c39df8$fafc6100$870a0a0a@consulintel.es> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 09:45 Europe/Stockholm, JORDI PALET MARTINEZ wrote: > > We are working already with L3 IXs also ... (www.euro6ix.org). Yes, BUT the vast majority of IXs out there are not L3. And IMHO I am not really sure if euro6ix is the right reference point for a transition scenario. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+GHKarNKXTPFCVEQKH0ACgu5EDi1E6w7ke99gHTOsI2bswxNQAoMSe eENOrT0Rqt3FlUn9zNm75R6+ =nEhe -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 07:08:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04480 for ; Wed, 29 Oct 2003 07:08:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEp3T-000Ng0-D3 for v6ops-data@psg.com; Wed, 29 Oct 2003 12:04:03 +0000 Received: from [136.206.1.5] (helo=hawk.dcu.ie) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEp3R-000Nfg-73 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 12:04:01 +0000 Received: from prodigy.redbrick.dcu.ie (136.206.15.2) by hawk.dcu.ie (7.0.016) id 3F6B7AE80024E62A for v6ops@ops.ietf.org; Wed, 29 Oct 2003 12:03:59 +0000 Received: from carbon.redbrick.dcu.ie ([136.206.15.1] ident=mail) by prodigy.redbrick.dcu.ie with esmtp (Exim 4.23) id 1AEp3Z-0006jy-KA for v6ops@ops.ietf.org; Wed, 29 Oct 2003 12:04:09 +0000 Received: from orly by carbon.redbrick.dcu.ie with local (Exim 3.35 #1 (Debian)) id 1AEp3O-000887-00 for ; Wed, 29 Oct 2003 12:03:58 +0000 Date: Wed, 29 Oct 2003 12:03:58 +0000 From: Hobbes tiger extraordinaire To: v6ops@ops.ietf.org Subject: Unicast Reverse Path Forwarding Message-ID: <20031029120358.GA23376@carbon.redbrick.dcu.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_20 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I was wondering if anyone can tell me if Unicast Reverse Path Forwarding is able to deal with IPv6 addresses on Cisco? JunOS appears to be able to manage both addresses. Thanks in advance Orla -- Happiness is a warm puppy From owner-v6ops@ops.ietf.org Wed Oct 29 10:09: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 KAA11271 for ; Wed, 29 Oct 2003 10:09:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AErsJ-000Bkm-PP for v6ops-data@psg.com; Wed, 29 Oct 2003 15:04:43 +0000 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AErsF-000BkO-Rr for v6ops@ops.ietf.org; Wed, 29 Oct 2003 15:04:39 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 10:04:39 -0500 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 09:56:06 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:53:24 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:53:24 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T8rNP09506 for ; Wed, 29 Oct 2003 03:53:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AElxD-0006hJ-Vq for v6ops-data@psg.com; Wed, 29 Oct 2003 08:45:23 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AElx9-0006gZ-7x for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:45:19 +0000 Received: from consulintel02 ([217.126.187.160]) (authenticated user jordi.palet@consulintel.es) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 29-md50000000008.tmp for ; Wed, 29 Oct 2003 09:45:25 +0100 Message-ID: <131c01c39df8$fafc6100$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Date: Wed, 29 Oct 2003 09:45:16 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Wed, 29 Oct 2003 09:45:25 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org X-OriginalArrivalTime: 29 Oct 2003 08:53:24.0304 (UTC) FILETIME=[1C8F3D00:01C39DFA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt, We are working already with L3 IXs also ... (www.euro6ix.org). Regards, Jordi ----- Original Message ----- From: "Kurt Erik Lindqvist" To: "SHIRASAKI Yasuhiro" Cc: ; Sent: Wednesday, October 29, 2003 9:29 AM Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On onsdag, okt 29, 2003, at 07:25 Europe/Stockholm, SHIRASAKI Yasuhiro > wrote: > > > Hello Lind, > > > > In section 5.7, Figure 7 shows that all of network elements except > > "Exchange" are converted into "Dual", but the Exchange is still > > remained as "IPv4 + IPv6". Does it have any specific meaning? > > > > Some IXs seemed to be dual stack already. > > IXs in themselves should be completely agnostic to what you run over > them as they are L2 - no? > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 > > iQA/AwUBP596ZqarNKXTPFCVEQLywwCghDFQBnXbVW90JdZreU6XylL6wRsAoPGt > jUuk0RU6J9EJ36HHgVcJGtWT > =zvQ7 > -----END PGP SIGNATURE----- > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Oct 29 10:27:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13673 for ; Wed, 29 Oct 2003 10:27:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEsCQ-000Dn3-67 for v6ops-data@psg.com; Wed, 29 Oct 2003 15:25:30 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEsCG-000DmK-LS for v6ops@ops.ietf.org; Wed, 29 Oct 2003 15:25:20 +0000 Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 10:25:19 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 10:25:19 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:16:13 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:16:13 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T6GDP01255 for ; Wed, 29 Oct 2003 01:16:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjVh-000IWD-If for v6ops-data@psg.com; Wed, 29 Oct 2003 06:08:49 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjVd-000IVc-0Y for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:08:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T68dp19104; Wed, 29 Oct 2003 08:08:39 +0200 Date: Wed, 29 Oct 2003 08:08:39 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org, Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 29 Oct 2003 06:16:13.0974 (UTC) FILETIME=[27A51360:01C39DE4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 28 Oct 2003, Tony Hain wrote: [...] > > So, I'll conclude by a few questions to give food for thought: > > > > - does this seem like a problem, that is, should getaddrinfo() + > > AI_ADDRCONFIG perform AAAA DNS queries etc. if > > the node only has v6 link-local/loopback addresses? > > It is not a problem if you follow addr selection rules and prefer > matching scopes. This will cause IPv4 to be used if there is only a LL, > trying to talk to a AAAA global. Uhh, I don't think Default Address Selection helps at all here. The question is NOT how you prefer the addresses after you've queried them, it's whether you query them *at all*. I.e., the point of the AI_ADDRCONFIG as it seems to me is to avoid an unnecessary query of IPv6 addresses in the first place. For example, the app wants to look up www.example.com. Prior to making that lookup, it must know which addresses are configured on the node if AI_ADDRCONFIG is used. It doesn't know about scopes of www.example.com at this point. If there are no IPv6 addresses (including link-locals) configured, it'll query only A records and then perform default address selection as you say, naturally ending up with IPv4 as there are no alternatives. If there are IPv6 addresses (including link-locals), it'll query both A and AAAA records and perform default address selection, probably also resulting in IPv4 if no global IPv6 addresses were configured. -- 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 Oct 29 10:27: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 KAA13697 for ; Wed, 29 Oct 2003 10:27:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEsCa-000Do2-8u for v6ops-data@psg.com; Wed, 29 Oct 2003 15:25:40 +0000 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEsCM-000Dmj-BE for v6ops@ops.ietf.org; Wed, 29 Oct 2003 15:25:26 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 10:25:25 -0500 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 10:24:30 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:39:13 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:39:14 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T8dDo21928 for ; Wed, 29 Oct 2003 03:39:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEliE-0004wJ-R9 for v6ops-data@psg.com; Wed, 29 Oct 2003 08:29:54 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEliA-0004vU-Qn for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:29:51 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T8TSPk001966; Wed, 29 Oct 2003 09:29:28 +0100 (CET) Date: Wed, 29 Oct 2003 09:29:24 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Mikael.Lind@teliasonera.com, v6ops@ops.ietf.org To: SHIRASAKI Yasuhiro From: Kurt Erik Lindqvist In-Reply-To: <20031029.152511.78736736.yasuhiro@nttv6.jp> Message-Id: <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 29 Oct 2003 08:39:14.0777 (UTC) FILETIME=[2233B490:01C39DF8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 07:25 Europe/Stockholm, SHIRASAKI Yasuhiro wrote: > Hello Lind, > > In section 5.7, Figure 7 shows that all of network elements except > "Exchange" are converted into "Dual", but the Exchange is still > remained as "IPv4 + IPv6". Does it have any specific meaning? > > Some IXs seemed to be dual stack already. IXs in themselves should be completely agnostic to what you run over them as they are L2 - no? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP596ZqarNKXTPFCVEQLywwCghDFQBnXbVW90JdZreU6XylL6wRsAoPGt jUuk0RU6J9EJ36HHgVcJGtWT =zvQ7 -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 10:56:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15609 for ; Wed, 29 Oct 2003 10:56:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEseo-000Gbn-Hs for v6ops-data@psg.com; Wed, 29 Oct 2003 15:54:50 +0000 Received: from [206.157.224.254] (helo=hatl0ms21.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEsea-000GaZ-9Z for v6ops@ops.ietf.org; Wed, 29 Oct 2003 15:54:36 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 10:53:36 -0500 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 10:35:49 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 07:14:22 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 07:14:21 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9TCELo28692 for ; Wed, 29 Oct 2003 07:14:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEp3T-000Ng0-D3 for v6ops-data@psg.com; Wed, 29 Oct 2003 12:04:03 +0000 Received: from [136.206.1.5] (helo=hawk.dcu.ie) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEp3R-000Nfg-73 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 12:04:01 +0000 Received: from prodigy.redbrick.dcu.ie (136.206.15.2) by hawk.dcu.ie (7.0.016) id 3F6B7AE80024E62A for v6ops@ops.ietf.org; Wed, 29 Oct 2003 12:03:59 +0000 Received: from carbon.redbrick.dcu.ie ([136.206.15.1] ident=mail) by prodigy.redbrick.dcu.ie with esmtp (Exim 4.23) id 1AEp3Z-0006jy-KA for v6ops@ops.ietf.org; Wed, 29 Oct 2003 12:04:09 +0000 Received: from orly by carbon.redbrick.dcu.ie with local (Exim 3.35 #1 (Debian)) id 1AEp3O-000887-00 for ; Wed, 29 Oct 2003 12:03:58 +0000 Date: Wed, 29 Oct 2003 12:03:58 +0000 From: Hobbes tiger extraordinaire To: v6ops@ops.ietf.org Subject: Unicast Reverse Path Forwarding Message-ID: <20031029120358.GA23376@carbon.redbrick.dcu.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OriginalArrivalTime: 29 Oct 2003 12:14:22.0103 (UTC) FILETIME=[2F915A70:01C39E16] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I was wondering if anyone can tell me if Unicast Reverse Path Forwarding is able to deal with IPv6 addresses on Cisco? JunOS appears to be able to manage both addresses. Thanks in advance Orla -- Happiness is a warm puppy From owner-v6ops@ops.ietf.org Wed Oct 29 11:18: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 LAA16859 for ; Wed, 29 Oct 2003 11:18:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEsyt-000IRX-25 for v6ops-data@psg.com; Wed, 29 Oct 2003 16:15:35 +0000 Received: from [206.157.224.254] (helo=hatl0ms21.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEsyo-000IQp-AE for v6ops@ops.ietf.org; Wed, 29 Oct 2003 16:15:30 +0000 Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 11:14:30 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 11:14:29 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:47:28 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:47:29 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T8lTP04589 for ; Wed, 29 Oct 2003 03:47:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AElsr-00069a-Rt for v6ops-data@psg.com; Wed, 29 Oct 2003 08:40:53 +0000 Received: from [2001:218:1:1040::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AElso-00068x-9K for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:40:51 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id AF3411FE47; Wed, 29 Oct 2003 17:40:49 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 760CA125FBD; Wed, 29 Oct 2003 17:40:49 +0900 (JST) Date: Wed, 29 Oct 2003 17:40:49 +0900 (JST) Message-Id: <20031029.174049.41667937.yasuhiro@nttv6.jp> To: Mikael.Lind@teliasonera.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt From: SHIRASAKI Yasuhiro In-Reply-To: <7B64D9FB62EB42449683BA51E9AB2AE80185FCD8@TMS031MB.tcad.telia.se> References: <7B64D9FB62EB42449683BA51E9AB2AE80185FCD8@TMS031MB.tcad.telia.se> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2003 08:47:29.0416 (UTC) FILETIME=[4907A080:01C39DF9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 29 Oct 2003 09:30:51 +0100, wrote: > > In section 5.7, Figure 7 shows that all of network elements except > > "Exchange" are converted into "Dual", but the Exchange is still > > remained as "IPv4 + IPv6". Does it have any specific meaning? > > > > Some IXs seemed to be dual stack already. > > The intended meaning is that there can be separate exchange points for > IPv4 and IPv6 as well as dual stack exchange points. I got your point. thanks. -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Wed Oct 29 11:19: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 LAA16909 for ; Wed, 29 Oct 2003 11:19:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEt0s-000IZn-H9 for v6ops-data@psg.com; Wed, 29 Oct 2003 16:17:38 +0000 Received: from [158.38.62.77] (helo=smistad.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEt0l-000IZ7-Qd for v6ops@ops.ietf.org; Wed, 29 Oct 2003 16:17:31 +0000 Received: from localhost (localhost [127.0.0.1]) by smistad.uninett.no (Postfix) with ESMTP id 36F1E29342; Wed, 29 Oct 2003 17:17:30 +0100 (CET) Date: Wed, 29 Oct 2003 17:17:29 +0100 (CET) Message-Id: <20031029.171729.57109093.he@uninett.no> To: jordi.palet@consulintel.es Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt From: Havard Eidnes In-Reply-To: <131c01c39df8$fafc6100$870a0a0a@consulintel.es> References: <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> <131c01c39df8$fafc6100$870a0a0a@consulintel.es> X-Mailer: Mew version 2.3 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > We are working already with L3 IXs also ... (www.euro6ix.org). According to a relatively common definition of what an IX is, the above is a contradiction in terms, and I tend to agree. When you say "L3" you implicitly drag along "will need to pick a routing policy", and it can therefore not serve as a policy-less interconnect between different ISPs, but rather becomes an ISP itself. Regards, - H=E5vard From owner-v6ops@ops.ietf.org Wed Oct 29 11:35:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17800 for ; Wed, 29 Oct 2003 11:35:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEtGB-000K5D-Rc for v6ops-data@psg.com; Wed, 29 Oct 2003 16:33:27 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEtG7-000K4n-HR for v6ops@ops.ietf.org; Wed, 29 Oct 2003 16:33:23 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 11:33:22 -0500 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 11:21:36 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 04:23:43 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 04:23:40 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T9Nco01633 for ; Wed, 29 Oct 2003 04:23:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmRd-0009ot-J9 for v6ops-data@psg.com; Wed, 29 Oct 2003 09:16:49 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmRZ-0009oU-C8 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 09:16:45 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9GZPk001977; Wed, 29 Oct 2003 10:16:35 +0100 (CET) Date: Wed, 29 Oct 2003 10:16:30 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Mikael.Lind@teliasonera.com, v6ops@ops.ietf.org To: SHIRASAKI Yasuhiro From: Kurt Erik Lindqvist In-Reply-To: <20031029.173744.74716199.yasuhiro@nttv6.jp> Message-Id: <95035508-09F0-11D8-AB34-000A9598A184@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 29 Oct 2003 09:23:40.0521 (UTC) FILETIME=[571BF590:01C39DFE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> Hello Lind, >>> >>> In section 5.7, Figure 7 shows that all of network elements except >>> "Exchange" are converted into "Dual", but the Exchange is still >>> remained as "IPv4 + IPv6". Does it have any specific meaning? >>> >>> Some IXs seemed to be dual stack already. >> >> IXs in themselves should be completely agnostic to what you run over >> them as they are L2 - no? > > IX based address assignment, health monitoring, statistics services, > etc. > might be IP version aware. Address assignment I agree with. The rest I would classify as services that will fall under other migration scenarios. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+FcaarNKXTPFCVEQI/0ACg4SvomAe5Ay7STEMOHzSLatES95gAoLw+ BEuJYhw595U2/MsKKVrmIfNY =pi4L -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 11:58:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19039 for ; Wed, 29 Oct 2003 11:58:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEtc5-000M0r-0K for v6ops-data@psg.com; Wed, 29 Oct 2003 16:56:05 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEtby-000M03-Aj for v6ops@ops.ietf.org; Wed, 29 Oct 2003 16:55:58 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 11:55:57 -0500 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 11:45:52 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 04:24:26 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 04:24:26 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T9OOo02296 for ; Wed, 29 Oct 2003 04:24:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmS5-0009sv-5U for v6ops-data@psg.com; Wed, 29 Oct 2003 09:17:17 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmS2-0009sZ-Vo for v6ops@ops.ietf.org; Wed, 29 Oct 2003 09:17:15 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9H4Pk001980; Wed, 29 Oct 2003 10:17:04 +0100 (CET) Date: Wed, 29 Oct 2003 10:17:01 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: , To: From: Kurt Erik Lindqvist In-Reply-To: <7B64D9FB62EB42449683BA51E9AB2AE80185FCD8@TMS031MB.tcad.telia.se> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 29 Oct 2003 09:24:26.0551 (UTC) FILETIME=[728B9470:01C39DFE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 09:30 Europe/Stockholm, wrote: >> >> In section 5.7, Figure 7 shows that all of network elements except >> "Exchange" are converted into "Dual", but the Exchange is still >> remained as "IPv4 + IPv6". Does it have any specific meaning? >> >> Some IXs seemed to be dual stack already. > > The intended meaning is that there can be separate exchange points for > IPv4 and IPv6 as well as dual stack exchange points. Aha. Ok. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+Fj6arNKXTPFCVEQK/pQCgx8gLgbSGcOce7sj85ad1VHfoOaIAn1OJ /9qNJT6nMDKeYBnbJM/abwqe =l9qx -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 11:59: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 LAA19078 for ; Wed, 29 Oct 2003 11:59:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEtda-000M7Y-64 for v6ops-data@psg.com; Wed, 29 Oct 2003 16:57:38 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEtdU-000M6z-50 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 16:57:32 +0000 Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 11:57:31 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 11:50:26 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:32:33 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:32:28 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T6WQo05908 for ; Wed, 29 Oct 2003 01:32:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjla-000JtA-LC for v6ops-data@psg.com; Wed, 29 Oct 2003 06:25:14 +0000 Received: from [2001:218:1:1040::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjlY-000Jsf-MY for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:25:12 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 12DB41FE47; Wed, 29 Oct 2003 15:25:12 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 6FD20125FBD; Wed, 29 Oct 2003 15:25:11 +0900 (JST) Date: Wed, 29 Oct 2003 15:25:11 +0900 (JST) Message-Id: <20031029.152511.78736736.yasuhiro@nttv6.jp> To: Mikael.Lind@teliasonera.com Cc: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt From: SHIRASAKI Yasuhiro In-Reply-To: <7B64D9FB62EB42449683BA51E9AB2AE80185FCC8@TMS031MB.tcad.telia.se> References: <7B64D9FB62EB42449683BA51E9AB2AE80185FCC8@TMS031MB.tcad.telia.se> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2003 06:32:33.0253 (UTC) FILETIME=[6F573150:01C39DE6] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Lind, In section 5.7, Figure 7 shows that all of network elements except "Exchange" are converted into "Dual", but the Exchange is still remained as "IPv4 + IPv6". Does it have any specific meaning? Some IXs seemed to be dual stack already. regards, -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Wed Oct 29 12:02: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 MAA19189 for ; Wed, 29 Oct 2003 12:02:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEtgG-000MJh-MI for v6ops-data@psg.com; Wed, 29 Oct 2003 17:00:24 +0000 Received: from [206.157.224.254] (helo=hatl0ms21.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEtgA-000MJ8-St for v6ops@ops.ietf.org; Wed, 29 Oct 2003 17:00:18 +0000 Received: from catl0ms23.corp.cox.com ([10.64.200.46]) by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 12:00:18 -0500 Received: from mail pickup service by catl0ms23.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 11:46:02 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 00:49:46 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 00:49:46 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T5nio29430 for ; Wed, 29 Oct 2003 00:49:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEj5P-000GRS-Js for v6ops-data@psg.com; Wed, 29 Oct 2003 05:41:39 +0000 Received: from [4.40.179.32] (helo=tndh.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEj5M-000GR2-47 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 05:41:36 +0000 Received: from eaglet (127.0.0.1:3318) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Tue, 28 Oct 2003 21:41:36 -0800 From: "Tony Hain" To: "Pekka Savola" , Cc: Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Tue, 28 Oct 2003 21:41:32 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 29 Oct 2003 05:49:46.0634 (UTC) FILETIME=[758436A0:01C39DE0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > ... > IMHO, using link-local addresses for anything except well-specified > purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really > counter-productive in your limited world this is undoubtedly true, but there is a wider world out there. > -- as you'll have to make those apps be able to > distinguish the zone identifiers as well, and that's probably > something we > DON'T want to do. But your mileage may vary. > > So, I'll conclude by a few questions to give food for thought: > > - does this seem like a problem, that is, should getaddrinfo() + > AI_ADDRCONFIG perform AAAA DNS queries etc. if > the node only has v6 link-local/loopback addresses? It is not a problem if you follow addr selection rules and prefer matching scopes. This will cause IPv4 to be used if there is only a LL, trying to talk to a AAAA global. > > - is getaddrinfo() + link-local addresses something we should support? Absolutely in the standard. In your specific network, you can turn this off if it causes you to loose sleep at night. > > - should this be fixed by e.g.: > a) recommending that the implementations filter out > link-locals as well > when doing AI_ADDRCONFIG (a BCP/Info document) > b) specifying additional semantics for AI_ADDRCONFIG > c) specifying a new hint which would perform this > > Note: if we go select any of these (especially the latter two), it might > make sense to bring this discussion up in the relevant API forums like > POSIX as well, because the IETF API documents are just Informational RFCs. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From owner-v6ops@ops.ietf.org Wed Oct 29 12:26:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21773 for ; Wed, 29 Oct 2003 12:26:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEu3L-000OaP-NF for v6ops-data@psg.com; Wed, 29 Oct 2003 17:24:15 +0000 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEu3I-000Oa6-Vs for v6ops@ops.ietf.org; Wed, 29 Oct 2003 17:24:13 +0000 Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 12:23:12 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 12:17:12 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:19:05 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 01:18:59 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T6Iwo25726 for ; Wed, 29 Oct 2003 01:18:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEjaZ-000Itr-DW for v6ops-data@psg.com; Wed, 29 Oct 2003 06:13:51 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEjaW-000ItX-Rn for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:13:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T6DdG19184; Wed, 29 Oct 2003 08:13:40 +0200 Date: Wed, 29 Oct 2003 08:13:38 +0200 (EET) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029015737.7F44589@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 29 Oct 2003 06:19:06.0008 (UTC) FILETIME=[8E2F6180:01C39DE4] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Jun-ichiro itojun Hagino wrote: > d) obsolete AI_ADDRCONFIG. AI_ADDRCONFIG semantics is too vague, and > way too difficult to specify (for instance, if you have IPv6 global > unicast address and no route, is it configured?). also, even without > AI_ADDRCONFIG programs work just fine (socket(2) or connect(2) will > issue the right error). Agreed, that might be one option. Without the on-link assumption, the default route case should be rather simple, though. You'd only have to look at the addresses. IMHO, without the on-link assumption, AI_ADDRCONFIG could help a lot in dual-stack deployments where IPv6 connectivity is not yet enabled. Of course, properly written apps would most probably also work there, but some apps are not properly written, but: - there are really misbehaving DNS servers out there, which jeopardize your IPv4 service if you query for AAAA's, and - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA queries - maybe other considerations we haven't figured out / thought out 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 Oct 29 12:54:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23146 for ; Wed, 29 Oct 2003 12:54:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEuUt-0001Pg-AI for v6ops-data@psg.com; Wed, 29 Oct 2003 17:52:43 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEuUq-0001PF-4f for v6ops@ops.ietf.org; Wed, 29 Oct 2003 17:52:40 +0000 Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 12:52:39 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 12:44:06 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:44:04 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 03:44:05 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T8i5P01315 for ; Wed, 29 Oct 2003 03:44:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AElpt-0005o9-77 for v6ops-data@psg.com; Wed, 29 Oct 2003 08:37:49 +0000 Received: from [2001:218:1:1040::2] (helo=gura.nttv6.jp) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AElpq-0005ne-SK for v6ops@ops.ietf.org; Wed, 29 Oct 2003 08:37:47 +0000 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by gura.nttv6.jp (NTTv6MTA) with ESMTP id 42FA71FE47; Wed, 29 Oct 2003 17:37:46 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (NTTv6MTA) with ESMTP id 17DE9126909; Wed, 29 Oct 2003 17:37:46 +0900 (JST) Date: Wed, 29 Oct 2003 17:37:44 +0900 (JST) Message-Id: <20031029.173744.74716199.yasuhiro@nttv6.jp> To: kurtis@kurtis.pp.se Cc: Mikael.Lind@teliasonera.com, v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt From: SHIRASAKI Yasuhiro In-Reply-To: <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> References: <20031029.152511.78736736.yasuhiro@nttv6.jp> <0059728F-09EA-11D8-AB34-000A9598A184@kurtis.pp.se> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2003 08:44:05.0417 (UTC) FILETIME=[CF6FD990:01C39DF8] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 29 Oct 2003 09:29:24 +0100, Kurt Erik Lindqvist wrote: > On onsdag, okt 29, 2003, at 07:25 Europe/Stockholm, SHIRASAKI Yasuhiro > wrote: > > > Hello Lind, > > > > In section 5.7, Figure 7 shows that all of network elements except > > "Exchange" are converted into "Dual", but the Exchange is still > > remained as "IPv4 + IPv6". Does it have any specific meaning? > > > > Some IXs seemed to be dual stack already. > > IXs in themselves should be completely agnostic to what you run over > them as they are L2 - no? IX based address assignment, health monitoring, statistics services, etc. might be IP version aware. -- SHIRASAKI Yasuhiro @ NTT Communications t: +81-3-6800-3262, f: +81-3-5365-2990 From owner-v6ops@ops.ietf.org Wed Oct 29 13:03: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 NAA23617 for ; Wed, 29 Oct 2003 13:03:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEudk-0002CE-SP for v6ops-data@psg.com; Wed, 29 Oct 2003 18:01:52 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEudh-0002Br-Cm for v6ops@ops.ietf.org; Wed, 29 Oct 2003 18:01:49 +0000 Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 13:01:48 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 13:01:48 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:02:32 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:02:32 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T72VP19384 for ; Wed, 29 Oct 2003 02:02:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkDZ-000MFv-GN for v6ops-data@psg.com; Wed, 29 Oct 2003 06:54:09 +0000 Received: from [2001:700:1:4:202:55ff:fe67:bc18] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkDW-000MFU-Ee for v6ops@ops.ietf.org; Wed, 29 Oct 2003 06:54:06 +0000 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id h9T6rPpI003059; Wed, 29 Oct 2003 07:53:25 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id h9T6rPR7031934; Wed, 29 Oct 2003 07:53:25 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id h9T6rOAk031933; Wed, 29 Oct 2003 07:53:24 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 29 Oct 2003 07:53:24 +0100 From: Stig Venaas To: Pekka Savola Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-ID: <20031029065324.GA31918@sverresborg.uninett.no> References: <20031029015737.7F44589@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OriginalArrivalTime: 29 Oct 2003 07:02:32.0628 (UTC) FILETIME=[9FDA0740:01C39DEA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Oct 29, 2003 at 08:13:38AM +0200, Pekka Savola wrote: > - there are really misbehaving DNS servers out there, which jeopardize > your IPv4 service if you query for AAAA's, and > - if you have no IPv6 address, you'll waste a roundtrip or two in AAAA > queries > - maybe other considerations we haven't figured out / thought out yet. And I've seen cases where you never get a reply to the AAAA query, which means that the application will wait for quite some time. Probably too clever firewalls or broken DNS server software. So I've seen people turn off IPv6 in apps using getaddrinfo() looping through the addresses the normal way, due to this. I don't like the idea of changing getaddrinfo() because of this, one should rather attack the real problem. However that is much harder... Stig From owner-v6ops@ops.ietf.org Wed Oct 29 13:34:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25347 for ; Wed, 29 Oct 2003 13:34:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEv6N-0004lm-Bx for v6ops-data@psg.com; Wed, 29 Oct 2003 18:31:27 +0000 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEv6K-0004lT-FQ for v6ops@ops.ietf.org; Wed, 29 Oct 2003 18:31:24 +0000 Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms20.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 13:31:23 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 13:26:39 -0500 Received: from hatl0ms23.corp.cox.com ([10.64.200.56]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 04:26:11 -0500 Received: from bastion2.cox.com ([10.225.2.51]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 04:26:07 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion2.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T9Q5o03768 for ; Wed, 29 Oct 2003 04:26:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEmUU-000A4m-9P for v6ops-data@psg.com; Wed, 29 Oct 2003 09:19:46 +0000 Received: from [192.71.80.74] (helo=dhcp4.se.kurtis.pp.se) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEmUS-000A4M-6N for v6ops@ops.ietf.org; Wed, 29 Oct 2003 09:19:44 +0000 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp4.se.kurtis.pp.se (8.12.9/8.10.2) with ESMTP id h9T9JQPk001983; Wed, 29 Oct 2003 10:19:26 +0100 (CET) Date: Wed, 29 Oct 2003 10:19:22 +0100 Subject: Re: I-D ACTION:draft-lind-v6ops-isp-scenarios-01.txt Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "JORDI PALET MARTINEZ" From: Kurt Erik Lindqvist In-Reply-To: <131c01c39df8$fafc6100$870a0a0a@consulintel.es> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) X-OriginalArrivalTime: 29 Oct 2003 09:26:11.0689 (UTC) FILETIME=[B1365D90:01C39DFE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00,UPPERCASE_25_50 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On onsdag, okt 29, 2003, at 09:45 Europe/Stockholm, JORDI PALET MARTINEZ wrote: > > We are working already with L3 IXs also ... (www.euro6ix.org). Yes, BUT the vast majority of IXs out there are not L3. And IMHO I am not really sure if euro6ix is the right reference point for a transition scenario. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBP5+GHKarNKXTPFCVEQKH0ACgu5EDi1E6w7ke99gHTOsI2bswxNQAoMSe eENOrT0Rqt3FlUn9zNm75R6+ =nEhe -----END PGP SIGNATURE----- From owner-v6ops@ops.ietf.org Wed Oct 29 14:00: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 OAA27204 for ; Wed, 29 Oct 2003 14:00:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEvVv-0006qL-Ao for v6ops-data@psg.com; Wed, 29 Oct 2003 18:57:51 +0000 Received: from [192.18.98.43] (helo=brmea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEvVs-0006q1-94 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 18:57:48 +0000 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TIAuPh017967 for ; Wed, 29 Oct 2003 11:10:56 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HNJ00HZJ6I7MK@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Wed, 29 Oct 2003 11:10:56 -0700 (MST) Received: from [192.168.1.100] ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HNJ005EB6I36R@mail.sun.net> for v6ops@ops.ietf.org; Wed, 29 Oct 2003 11:10:53 -0700 (MST) Date: Wed, 29 Oct 2003 10:13:35 -0800 From: Alain Durand Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-reply-to: To: Tony Hain Cc: Pekka Savola , ipv6@ietf.org, v6ops@ops.ietf.org Message-id: <9CC06662-0A3B-11D8-8D05-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.606) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Oct 28, 2003, at 9:41 PM, Tony Hain wrote: >> - does this seem like a problem, that is, should getaddrinfo() + >> AI_ADDRCONFIG perform AAAA DNS queries etc. if >> the node only has v6 link-local/loopback addresses? > > It is not a problem if you follow addr selection rules and prefer > matching > scopes. This will cause IPv4 to be used if there is only a LL, trying > to > talk to a AAAA global. Not always. read our 2 drafts, this is clearly explained. If you have a case where IPv6 src= LL, IPv6 dst = GL IPv4 src= SL (rfc1918), IPv4 DST = GL (This is a typical case of a host behind a NAT box) Default address selection will choose the impossible v6 path. - Alain. From owner-v6ops@ops.ietf.org Wed Oct 29 14:00:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27326 for ; Wed, 29 Oct 2003 14:00:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEvXH-0006xK-6B for v6ops-data@psg.com; Wed, 29 Oct 2003 18:59:15 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEvXA-0006wF-7f for v6ops@ops.ietf.org; Wed, 29 Oct 2003 18:59:08 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BD09B13A8A; Wed, 29 Oct 2003 13:59:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 13:59:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal : Common issues across Scenarios Design Team should be new work item Date: Wed, 29 Oct 2003 13:59:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B051222C5@tayexc13.americas.cpqcorp.net> Thread-Topic: Proposal : Common issues across Scenarios Design Team should be new work item Thread-Index: AcOd7rioTydZoZZxRNeyOpsdPuibOwAX0iMQ From: "Bound, Jim" To: "Kurt Erik Lindqvist" Cc: X-OriginalArrivalTime: 29 Oct 2003 18:59:07.0580 (UTC) FILETIME=[BAD70FC0:01C39E4E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Kurtis, > Jim, >=20 > > Proposal: Begin a new design team and effort to work on the common=20 > > IPv6 operational issues across any scenario that must be addressed=20 > > (e.g. DNS, Porting, Mail). There are also probably common security=20 > > issues for all scenarios in addition to the specific ones for each=20 > > scenario work effort > > in v6ops. >=20 > isn't what you are really saying that there might be issues=20 > identified=20 > by the DTs that really should go to other WGs? I think its another DT here in v6ops mostly. I could be other IETF WGs need to deal with specific operational issues of IPv6 in their space like multi6 WG but that I think is up to the ADs of Ops to determine if this issue has merit. Just a thought from working on one of the specs I saw that affects all DTs I think. Not clear what process would address it in v6ops or elsewhere. /jim >=20 > - - kurtis - >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 >=20 > iQA/AwUBP59syKarNKXTPFCVEQJIUgCeOm6AHZoOZO5VzyPibQ/jxisV0VcAoJaq > hVRvHgO8avlxmAteocW/3nqp > =3DnWfQ > -----END PGP SIGNATURE----- >=20 >=20 From owner-v6ops@ops.ietf.org Wed Oct 29 14:08:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27970 for ; Wed, 29 Oct 2003 14:08:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEvdz-0007hY-2S for v6ops-data@psg.com; Wed, 29 Oct 2003 19:06:11 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEvdV-0007d4-UM for v6ops@ops.ietf.org; Wed, 29 Oct 2003 19:05:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9TJ5X200634; Wed, 29 Oct 2003 21:05:33 +0200 Date: Wed, 29 Oct 2003 21:05:32 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: itojun@iijlab.net, , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310291410.32485.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > On the other hand, I think that applications which > query the DNS shouldn't be real-time applications, so I see this > feature is not very useful. How do you see people browsing the web get to the websites then, if not using DNS? That's enough realtime in my book -- the user waits while the request(s) is being processed. I really don't understand what you're trying to say.. > If I understood Stig well, he said that people was > turning off IPv6 because of delaying issues. Doing that is not an option if > you want to allow your app. to run over "IPv6 AND IPv4". If you can not cope > with such delays, maybe you shouldn't be using the DNS at all. Then what? Distributed hosts file? ;-) ? > The problem here is that most of the times this feature will fail back > to the worst case, which is the normal getaddrinfo behaviour, because > it's not as easy as checking for global IPv6 configured address, as Itojun > has already said. We might come up with a lot of scenarios where this > option might fail to improve the response time (e.g: only link-local > addresses, global addresses but no default route, proper link local IPv6 > configuration but some black-hole on outer routers.....). I fail to see the point here: - if only link local addresses: fixed AI_ADDRCONFIG would fix - if global but no default route: a) without the on-link assumption: automatic immediate no route message and fallback to the next address b) with (current) on-link assumption: problematic (which is why the assumption must be killed :-) - if global, default route, but blackhole somewhere: silently discarding packets is evil practice anyway and nothing can be done about that, whether in case of v4 or v6. - if global, default route, everything works, but some DNS server munges the AAAA queries: can't help with that, but because v6 would be used, that has to be fixed by fixing the servers anyway. .. so my perception is that this would fix all the problems related to partial IPv6 deployment I could think of w/ the elimination of the on-link assumption pretty well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Oct 29 14: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 OAA28350 for ; Wed, 29 Oct 2003 14:14:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEvjz-0008H4-4U for v6ops-data@psg.com; Wed, 29 Oct 2003 19:12:23 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEvjw-0008Gf-BW for v6ops@ops.ietf.org; Wed, 29 Oct 2003 19:12:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9TIIvQ32194; Wed, 29 Oct 2003 20:18:57 +0200 Date: Wed, 29 Oct 2003 20:18:57 +0200 (EET) From: Pekka Savola To: Hobbes tiger extraordinaire cc: v6ops@ops.ietf.org Subject: Re: Unicast Reverse Path Forwarding In-Reply-To: <20031029120358.GA23376@carbon.redbrick.dcu.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Hobbes tiger extraordinaire wrote: > I was wondering if anyone can tell me if Unicast Reverse Path Forwarding is > able to deal with IPv6 addresses on Cisco? JunOS appears to be able to manage > both addresses. This is off-topic for this list. I suggest using the NSP list or contacting the vendor directly. (Currently, it's not supported, FWIW.) -- 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 Oct 29 14:46: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 OAA01005 for ; Wed, 29 Oct 2003 14:46:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEwEC-000B3U-Ki for v6ops-data@psg.com; Wed, 29 Oct 2003 19:43:36 +0000 Received: from [160.36.56.50] (helo=klutz.cs.utk.edu) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEwE8-000B31-1E for v6ops@ops.ietf.org; Wed, 29 Oct 2003 19:43:32 +0000 Received: from localhost (klutz [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 77C0414261; Wed, 29 Oct 2003 14:43:31 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20552-03; Wed, 29 Oct 2003 14:43:30 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 60C2C14226; Wed, 29 Oct 2003 14:43:30 -0500 (EST) Date: Wed, 29 Oct 2003 14:41:31 -0500 From: Keith Moore To: "Tony Hain" Cc: moore@cs.utk.edu, pekkas@netcore.fi, v6ops@ops.ietf.org, ipv6@ietf.org Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Message-Id: <20031029144131.37110a1a.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Pekka Savola wrote: > > ... > > IMHO, using link-local addresses for anything except well-specified > > purposes (e.g. routing protocols, RFC2461/2, etc.) is really, really > > counter-productive > > in your limited world this is undoubtedly true, but there is a wider > world out there. Yes, there is a wider world out there. And in that wider world, what people do on their private networks - including inappropriate use of link-local addresses - really can harm the ability of the global Internet to support applications. Keith From owner-v6ops@ops.ietf.org Wed Oct 29 15:00: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 PAA01823 for ; Wed, 29 Oct 2003 15:00:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEwSc-000Car-MF for v6ops-data@psg.com; Wed, 29 Oct 2003 19:58:30 +0000 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEwSZ-000CaU-O5 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 19:58:27 +0000 Received: from catl0ms22.corp.cox.com ([10.62.200.101]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 14:58:27 -0500 Received: from mail pickup service by catl0ms22.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 14:53:02 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:33:31 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 02:33:30 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9T7XUP22108 for ; Wed, 29 Oct 2003 02:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEkjM-000PDz-8p for v6ops-data@psg.com; Wed, 29 Oct 2003 07:27:00 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEkjJ-000PDY-3y for v6ops@ops.ietf.org; Wed, 29 Oct 2003 07:26:57 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9T7Qo920283; Wed, 29 Oct 2003 09:26:50 +0200 Date: Wed, 29 Oct 2003 09:26:50 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <20031029071117.EA85D13@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 29 Oct 2003 07:33:30.0976 (UTC) FILETIME=[F3836E00:01C39DEE] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003 itojun@iijlab.net wrote: [...] > >Remember, the most important thing we should care about is that dual-stack > >deployments can get more common without causing problems for *IPv4* or > >services in general. AI_ADDRCONFIG is one step in that direction. > > for your story to be effective it has to be host-wide configuration > knob, not a parameter to library function. (we cannot change every > program we use to have AI_ADDRCONFIG) Yep, or the apps writing guidelines could recommend to turn it on. The basic API spec already defines "AI_DEFAULT" even though it doesn't (AFAIR) specify that it should be the default :-) > and we (*BSD groups) ship programs without AI_ADDRCONFIG, and they > work just fine... Yep, to the extent they're used. Stig already mentioned that some apps are moving to some custom address lookup hacks from getaddrinfo() due to these problems. The use of AI_ADDRCONFIG should help in the majority of cases, i.e., deploying v6-capable apps on nodes which don't have v6 connectivity 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 Oct 29 15:39: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 PAA04942 for ; Wed, 29 Oct 2003 15:39:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEx3h-000Fvu-8k for v6ops-data@psg.com; Wed, 29 Oct 2003 20:36:49 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEx3d-000FvR-1b for v6ops@ops.ietf.org; Wed, 29 Oct 2003 20:36:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9TKac302758; Wed, 29 Oct 2003 22:36:38 +0200 Date: Wed, 29 Oct 2003 22:36:38 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: itojun@iijlab.net, , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310292123.45458.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > I just say that this option is not *very* useful, having > into account the problems that it has with link-local > addresses and so on... if you fix these problems, it's > a matter of choice, if you want to use it, just do it. Which problems are you referring to? I still don't understand :-( > > > If I understood Stig well, he said that people was > > > turning off IPv6 because of delaying issues. Doing that is not an option > > > if you want to allow your app. to run over "IPv6 AND IPv4". If you can > > > not cope with such delays, maybe you shouldn't be using the DNS at all. > > > > Then what? Distributed hosts file? ;-) ? > > ^--^ ...(after a while)... pouting (grrrr). > > Then what ? it's not my problem, Sorry for my remark, I just could not resist. What you seemed to suggest was, "don't use DNS" without giving any reasonable alternative. That isn't really productive either :-) > I haven't switched to IPv4 because > the IPv6 resolver took a couple of extra roundtrip times. The extra roundtrip times are just the tip of the iceberg. Consider broken DNS servers, load balancers etc. out there -- which may eat your AAAA query for e.g. 10 seconds, causing a lot more delay than a couple of roundtrips. > I see another way of fixing: > > If this option is problematic, don't use it. This has been proved to work, > as a lot of applications don't use it already. As for AI_ADDRCONFIG, it's maybe not used because it hasn't really been implemented that much, maybe because it has been specified in a rather useless way (and it requires a proprietary interface between the glibc and kernel to get the addresses, such as the getaddrinfo destination address ordering as well; dst addr ordering hasn't been implemented that much either).. > You will have to give me other arguments to kill the on-link assuption. Let's keep that subject to a separate thread, (the next message). -- 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 Oct 29 16:02:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06066 for ; Wed, 29 Oct 2003 16:02:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AExQ4-000IKX-IQ for v6ops-data@psg.com; Wed, 29 Oct 2003 20:59:56 +0000 Received: from [206.157.230.254] (helo=hatl0ms22.CORP.COX.COM) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AExPy-000IJZ-V3 for v6ops@ops.ietf.org; Wed, 29 Oct 2003 20:59:51 +0000 Received: from CATL0MS81.corp.cox.com ([10.62.200.231]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 15:44:29 -0500 Received: from mail pickup service by CATL0MS81.corp.cox.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 15:36:22 -0500 Received: from hatl0ms22.CORP.COX.COM ([10.62.201.69]) by catl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 14:05:43 -0500 Received: from bastion.cox.com ([10.230.2.65]) by hatl0ms22.CORP.COX.COM with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 14:05:43 -0500 Received: from psg.com (psg.com [147.28.0.62]) by bastion.cox.com (8.11.7p1+Sun/8.11.6) with SMTP id h9TJ5gP05231 for ; Wed, 29 Oct 2003 14:05:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AEvXH-0006xK-6B for v6ops-data@psg.com; Wed, 29 Oct 2003 18:59:15 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AEvXA-0006wF-7f for v6ops@ops.ietf.org; Wed, 29 Oct 2003 18:59:08 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BD09B13A8A; Wed, 29 Oct 2003 13:59:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 13:59:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal : Common issues across Scenarios Design Team should be new work item Date: Wed, 29 Oct 2003 13:59:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B051222C5@tayexc13.americas.cpqcorp.net> Thread-Topic: Proposal : Common issues across Scenarios Design Team should be new work item Thread-Index: AcOd7rioTydZoZZxRNeyOpsdPuibOwAX0iMQ From: "Bound, Jim" To: "Kurt Erik Lindqvist" Cc: X-OriginalArrivalTime: 29 Oct 2003 18:59:07.0580 (UTC) FILETIME=[BAD70FC0:01C39E4E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Kurtis, > Jim, >=20 > > Proposal: Begin a new design team and effort to work on the common=20 > > IPv6 operational issues across any scenario that must be addressed=20 > > (e.g. DNS, Porting, Mail). There are also probably common security=20 > > issues for all scenarios in addition to the specific ones for each=20 > > scenario work effort > > in v6ops. >=20 > isn't what you are really saying that there might be issues=20 > identified=20 > by the DTs that really should go to other WGs? I think its another DT here in v6ops mostly. I could be other IETF WGs need to deal with specific operational issues of IPv6 in their space like multi6 WG but that I think is up to the ADs of Ops to determine if this issue has merit. Just a thought from working on one of the specs I saw that affects all DTs I think. Not clear what process would address it in v6ops or elsewhere. /jim >=20 > - - kurtis - >=20 > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.2 >=20 > iQA/AwUBP59syKarNKXTPFCVEQJIUgCeOm6AHZoOZO5VzyPibQ/jxisV0VcAoJaq > hVRvHgO8avlxmAteocW/3nqp > =3DnWfQ > -----END PGP SIGNATURE----- >=20 >=20 From owner-v6ops@ops.ietf.org Wed Oct 29 16:06:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06304 for ; Wed, 29 Oct 2003 16:06:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AExUS-000ImN-Pk for v6ops-data@psg.com; Wed, 29 Oct 2003 21:04:28 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AExUO-000IlQ-IF for v6ops@ops.ietf.org; Wed, 29 Oct 2003 21:04:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9TL3cZ03124; Wed, 29 Oct 2003 23:03:39 +0200 Date: Wed, 29 Oct 2003 23:03:38 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: Soliman Hesham , , , Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: <200310291747.12539.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=BAYES_00,REMOVE_IN_QUOTES, REMOVE_REMOVAL_NEAR autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Combining this, and the comment from the AI_ADDRCONFIG thread, and adding v6ops in the Cc:.. On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: [...] > You will have to give me other arguments to kill the on-link assuption. You seem to have some scenarios in mind where you think these are useful. Please elaborate. Remember that the removing the on-link assumption mostly helps in deployments where there is no IPv6 connectivity at all.. i.e., you're probably not experiencing these personally :-). But those are very probably nasty for folks who might have dual-stack on by default, but without connectivity. More inline.. On Wed, 29 Oct 2003, Juan Rodriguez Hervella wrote: > "The problems of this assumption are discussed in section 3 > of Alain's draft. The draft suggests that this assumption > should be removed from ND specs. Here is the suggestion: > [snipped but it's read as..."remove" and "remove"...] > This seems like a reasonable suggestion, any objections?" > > As I've already said, I think that on-link communications might > be a useful thing to have. You realize, of course, that the document does not try to restrict on-link communications at all? It just recommends that if you don't have a default route, don't assume everybody in the Internet is reachable on-link. This seems rather reasonable in almost all cases, because you generally *can't* expect anything like that. You expect that the prefixes you have the addresses from are on-link (which continue to work without any problems), and that's it :-) > > - impacts on address selection (section 3.1) > > So let's go to fix address selection instead of removing > a nice feature. Again, do you have scenarios in mind where this feature would be useful? The document doesn't (yet :-) tease out the different problems as well as it could, but this isn't just a thing that can be fixed by a simple default address selection modification. For example, if your first-hop router crashes *), but you still have a global IPv6 address, and you perform a DNS lookup over IPv4, and get A and AAAA responses back from the DNS, the on-link assumption would make you try to perform a TCP connect() using the IPv6 address. Obviously, this will cause long timeouts until the router comes back up and replaces the default route. *) here are actually two cases: the default route is removed (e.g. it times out), which is a clear case of an on-link assumption problem, and when default route persists but the next-hop is considered unreachable by NUD (which also triggers the on-link assumption, AFAIR -- but not sure; also not sure how fast NUD will work on the default router's nexthop..). The more obvious problem you may not be seeing is when an implementation has enabled dual-stack but does not have IPv6 connectivity at all (i.e., only the link-local addresses). However, due to the onlink assumption, it tries to reach every IPv6 destination directly on its interfaces. I fail to see any justification for this. Such addresses need not come through default address selection. The clearer issue with default address selection (really, destination address selection, which isn't really implemented that much yet!) is when the the scopes are mismatching. The fix should probably be applied in both, the default address selection (by clarifying what "avoid unusable destinations" should entail) and RFC2461bis, but the latter is more timely and more important. -- 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 Oct 30 01:22: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 BAA27563 for ; Thu, 30 Oct 2003 01:22:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF68K-000LqQ-Dr for v6ops-data@psg.com; Thu, 30 Oct 2003 06:18:12 +0000 Received: from [4.40.179.36] (helo=tndh.net) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF68I-000Lq2-3v for v6ops@ops.ietf.org; Thu, 30 Oct 2003 06:18:10 +0000 Received: from eaglet (127.0.0.1:3054) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id for from ; Wed, 29 Oct 2003 22:09:59 -0800 From: "Tony Hain" To: "Pekka Savola" Cc: , Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG Date: Wed, 29 Oct 2003 22:09:54 -0800 Message-ID: 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 IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK autolearn=no version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > It is not a problem if you follow addr selection rules and prefer > > matching scopes. This will cause IPv4 to be used if there is only a LL, > > trying to talk to a AAAA global. > > Uhh, I don't think Default Address Selection helps at all here. The > question is NOT how you prefer the addresses after you've queried them, > it's whether you query them *at all*. > > I.e., the point of the AI_ADDRCONFIG as it seems to me is to avoid an > unnecessary query of IPv6 addresses in the first place. > > For example, the app wants to look up www.example.com. Prior to making > that lookup, it must know which addresses are configured on the node if > AI_ADDRCONFIG is used. It doesn't know about scopes of www.example.com at > this point. > > If there are no IPv6 addresses (including link-locals) configured, it'll > query only A records and then perform default address selection as you > say, naturally ending up with IPv4 as there are no alternatives. > > If there are IPv6 addresses (including link-locals), it'll query both A > and AAAA records and perform default address selection, probably also > resulting in IPv4 if no global IPv6 addresses were configured. So you want to standardize an implementation & optimization issue ... This is an optimization that you may want to use in any implementation you do, but it is not an issue we need to standardize. In particular, it precludes use of IPv6 if a local network has a name service intelligent enough to provide LL information to the right place. Please stop assuming that the world will not evolve beyond where we are, and trying to prevent it from doing so. Yes we do not want LL addresses to show up in the global name space, and the current DNS is too lame to prevent that, but that is no reason to specify that nobody can ever use it. Tony From owner-v6ops@ops.ietf.org Thu Oct 30 01:26: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 BAA27824 for ; Thu, 30 Oct 2003 01:26:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AF6F4-000MCF-7f for v6ops-data@psg.com; Thu, 30 Oct 2003 06:25:10 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AF6F1-000MBe-7a for v6ops@ops.ietf.org; Thu, 30 Oct 2003 06:25:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9U6P2611169; Thu, 30 Oct 2003 08:25:02 +0200 Date: Thu, 30 Oct 2003 08:25:01 +0200 (EET) From: Pekka Savola To: Tony Hain cc: v6ops@ops.ietf.org, Subject: RE: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 29 Oct 2003, Tony Hain wrote: > So you want to standardize an implementation & optimization issue ... This > is an optimization that you may want to use in any implementation you do, > but it is not an issue we need to standardize. Did you notice that the APIs are Informational documents? :-) The key point here is raise the awareness of implementors by first discussiing, then writing a draft, and last publishing it. Whether it says "do this, ignore that" or "you might want to do this, but be aware of foo" is pretty irrelevant to me. > In particular, it precludes > use of IPv6 if a local network has a name service intelligent enough to > provide LL information to the right place. Right, there are tradeoffs here. Unless there is concensus about that this is a generally desirable thing, one way forward could be publishing a tradeoffs document which would just bring up both sides of the argument, why you would or would not want to do it, and let the implementor decide what they feel is more important for them. > Please stop assuming that the > world will not evolve beyond where we are, and trying to prevent it from > doing so. I'm not sure if I'd classify the widespread use of link-local addresses as "evolving".. > Yes we do not want LL addresses to show up in the global name > space, and the current DNS is too lame to prevent that, but that is no > reason to specify that nobody can ever use it. My personal point is that LL addresses are highly problematic for apps, because they'll have to then (at least) parse the zone identifier as well, because e.g. if you are a host and have one physical interface and one tunnel interface, you cannot use link local addresses without additional disambiguation. The only way to ensure that link-locals work seems to be restricting them to the special applications which know how to deal with them. But it's no use trying to debate this argument over here. If sufficiently many folks think link-locals are a good thing, then we'd probably need a tradeoffs document instead of a recommendation/specification document. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Oct 30 09: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 JAA23345 for ; Thu, 30 Oct 2003 09:28:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFDjO-000FaB-QO for v6ops-data@psg.com; Thu, 30 Oct 2003 14:24:58 +0000 Received: from [203.195.128.72] (helo=pmail.now-india.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFDjF-000FZs-3B for v6ops@ops.ietf.org; Thu, 30 Oct 2003 14:24:50 +0000 Received: from Amar ([203.195.216.55]) by pmail.now-india.com (Netscape Messaging Server 4.15) with SMTP id HNKQOF00.H5K for ; Thu, 30 Oct 2003 19:54:15 +0530 Message-ID: <020501c39ef1$499033c0$020aa8c0@Amar> From: "Amarnath Gutta" To: Subject: Implementation of Ipv6 in winxp Date: Thu, 30 Oct 2003 19:52:45 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello All, I have IPv6 enabled on my winxp professional computers. I have 2 of them. I am able to use ping6 with the IPv6 Address and get a reply from other computer , but only if I define the scope-id as 4. Without it does not ping. But as I understand that being on the same LAN the scope Id is necessary....is it ?? Other problem I am facing is with Web server. I have installed the native IIS of the winxp. I am able to access the site using the Ipv4 address of the website but as soon as I put the Ipv6 address in the IE6 (browser) I am getting error "Invalid Syntax". Why is this happening ?? Syntax is correct as http://[ipv6-address] but still I am getting this error. After some browing I found out that "wininet.dll" file is needed to access IPv6 Sites. So I got that files from the MSDN and copied it to my //windows/system directory and still the problem persists. I am able to Ping and tracert to the Ipv6 address. Please suggest. Any ideas are welcome. Regards Amar From owner-v6ops@ops.ietf.org Thu Oct 30 10:10: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 KAA25279 for ; Thu, 30 Oct 2003 10:10:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFENZ-000HP9-6n for v6ops-data@psg.com; Thu, 30 Oct 2003 15:06:29 +0000 Received: from [137.65.81.121] (helo=prv-mail25.provo.novell.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFENN-000HOY-Q5 for v6ops@ops.ietf.org; Thu, 30 Oct 2003 15:06:17 +0000 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 30 Oct 2003 08:06:17 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Thu, 30 Oct 2003 08:06:01 -0700 From: "Sukhdeep Johar" To: , Subject: Re: Implementation of Ipv6 in winxp Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 1. ARe you using the link-local addresses [fe80::xxxx] ? In that case, u need the scope , even on the same lan. 2. I understand that the default IE in xp cannot use literal ipv6 addresses. You need to map it in the hosts file. You can then access using the dns name in ur browser. HTH regards. >>> "Amarnath Gutta" 10/30/2003 7:52:45 PM >>> Hello All, I have IPv6 enabled on my winxp professional computers. I have 2 of them. I am able to use ping6 with the IPv6 Address and get a reply from other computer , but only if I define the scope-id as 4. Without it does not ping. But as I understand that being on the same LAN the scope Id is necessary....is it ?? Other problem I am facing is with Web server. I have installed the native IIS of the winxp. I am able to access the site using the Ipv4 address of the website but as soon as I put the Ipv6 address in the IE6 (browser) I am getting error "Invalid Syntax". Why is this happening ?? Syntax is correct as http://[ipv6-address] but still I am getting this error. After some browing I found out that "wininet.dll" file is needed to access IPv6 Sites. So I got that files from the MSDN and copied it to my //windows/system directory and still the problem persists. I am able to Ping and tracert to the Ipv6 address. Please suggest. Any ideas are welcome. Regards Amar From owner-v6ops@ops.ietf.org Thu Oct 30 11:22: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 LAA29220 for ; Thu, 30 Oct 2003 11:22:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFFW4-000Kiu-LV for v6ops-data@psg.com; Thu, 30 Oct 2003 16:19:20 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFFW0-000KiU-HQ for v6ops@ops.ietf.org; Thu, 30 Oct 2003 16:19:16 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CE563FD4C; Thu, 30 Oct 2003 11:19:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Oct 2003 11:19:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Implementation vs. the Standard Date: Thu, 30 Oct 2003 11:19:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1CD@tayexc13.americas.cpqcorp.net> Thread-Topic: Implementation vs. the Standard Thread-Index: AcOersiV4+nm+4lvQYeqFbI6EhJlwwAUNIlw From: "Bound, Jim" To: "Pekka Savola" , "Tony Hain" Cc: X-OriginalArrivalTime: 30 Oct 2003 16:19:15.0633 (UTC) FILETIME=[9001DA10:01C39F01] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable It is important for us to separate implementation choice vs. the standard. The onlink and v6bydefault discussions are mostly a focus on if you do this with IPv6 and don't think about this other aspect you can hurt yourself. A discussion of whether a standard is useful for networking is a different discussion. Then there is the importance that a standard does not create an interoperability problem. The API issues are not errors but could be operational issues. Also the Base API is Informational, and is standardized by the IEEE not the IETF as a note to all. At this point we don't even own that spec anymore. That spec is done and completed if we want additions it will have to go through IEEE process too not just IETF process. =20 There is nothing wrong with documenting issues for implementers in an RFC and that work should be encouraged. In that context I agree with Pekka S. But, for the IETF to tell vendors how they ship their products for customers is simply inappropriate and vendors will not listen to the IETF, hence this is not a good use of our precious mail time. In that sense I agree with Tony 100%. Discussion of operational issues with our standards and how they work with implementation is a good discussion. But should not be a priority over the standards work we need to deliver as a working group. So in addition to the recent and good request from Chairs and ADs to try to hold back on email and think about the response and hit reply for ones hot button (and at times it must be done for continuity and defense) I would also add that topics which are standards we are working on that are needed and on standards track receive priority mail discussion. The Standards Track discussions are the ones that may help improve time-to-market for the IETF to deliver their product/solutions which are networking standards and the point of this body and forum. This mail is not to tell anyone to do anything or stop doing anything but a note and my .50 cents. I also took IPv6 WG off this mail as I don't want to get mail twice again. I will send to IPv6 WG as courteous that I did this but I feel this is mostly a v6ops discussion at this point in time. Sincerely, /jim From owner-v6ops@ops.ietf.org Thu Oct 30 11:39:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29876 for ; Thu, 30 Oct 2003 11:39:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFFnI-000Lp8-JB for v6ops-data@psg.com; Thu, 30 Oct 2003 16:37:08 +0000 Received: from [216.69.64.150] (helo=mx1.nttmcl.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFFn7-000LoQ-3u for v6ops@ops.ietf.org; Thu, 30 Oct 2003 16:36:57 +0000 Received: from netmon.nttmcl.com (netmon.nttmcl.com [216.69.69.137]) by mx1.nttmcl.com (8.12.9/8.12.9) with ESMTP id h9UGao8P012080; Thu, 30 Oct 2003 08:36:51 -0800 (PST) Received: from netmon.nttmcl.com (localhost [127.0.0.1]) by netmon.nttmcl.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9UGasT4021533; Thu, 30 Oct 2003 08:36:54 -0800 Received: (from www-data@localhost) by netmon.nttmcl.com (8.12.9/8.12.9/Debian-3) id h9UGas1Y021532; Thu, 30 Oct 2003 08:36:54 -0800 X-Authentication-Warning: netmon.nttmcl.com: www-data set sender to jeremy@nttmcl.com using -f Received: from dhcp222.nttmcl.com (dhcp222.nttmcl.com [::ffff:216.69.69.222]) by netmon.nttmcl.com (IMP) with HTTP for ; Thu, 30 Oct 2003 08:36:54 -0800 Message-ID: <1067531814.3fa13e2695f8f@netmon.nttmcl.com> Date: Thu, 30 Oct 2003 08:36:54 -0800 From: "Jeremy T. Bouse" To: Sukhdeep Johar Cc: amarnathg@now-india.com, v6ops@ops.ietf.org Subject: Re: Implementation of Ipv6 in winxp References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I believe #2 is incorrect... IE 6 atleast can handle IPv6; however it does not accept IPv6 addresses or do AAAA queries by default. I believe I recalled having to find a Knowledge Base item on Microsoft's site to enable the AAAA queries and have been able to verify IPv6 connectivity through IE 6 using www.kame.net's mosaic turtle image which only properly displays for IPv6 connections... Regards, Jeremy T. Bouse Quoting Sukhdeep Johar : > 1. ARe you using the link-local addresses [fe80::xxxx] ? > In that case, u need the scope , even on the same lan. > > 2. I understand that the default IE in xp cannot use > literal ipv6 addresses. You need to map it in the hosts > file. You can then access using the dns name in ur browser. > > HTH > regards. > > >>> "Amarnath Gutta" 10/30/2003 7:52:45 PM > >>> > Hello All, > > I have IPv6 enabled on my winxp professional computers. I have 2 of > them. > > I am able to use ping6 with the IPv6 Address and get a reply from > other > computer , but only if I define the scope-id as 4. Without it does not > ping. > But as I understand that being on the same LAN the scope Id is > necessary....is it ?? > > Other problem I am facing is with Web server. I have installed the > native > IIS of the winxp. I am able to access the site using the Ipv4 address > of the > website but as soon as I put the Ipv6 address in the IE6 (browser) I > am > getting error "Invalid Syntax". Why is this happening ?? Syntax is > correct > as http://[ipv6-address] but still I am getting this error. After > some > browing I found out that "wininet.dll" file is needed to access IPv6 > Sites. > So I got that files from the MSDN and copied it to my //windows/system > directory and still the problem persists. > > I am able to Ping and tracert to the Ipv6 address. > > Please suggest. Any ideas are welcome. > > Regards > > Amar > > > From owner-v6ops@ops.ietf.org Thu Oct 30 11:41: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 LAA00013 for ; Thu, 30 Oct 2003 11:41:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFFpw-000Lxc-0m for v6ops-data@psg.com; Thu, 30 Oct 2003 16:39:52 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFFpj-000Lwi-Q8 for v6ops@ops.ietf.org; Thu, 30 Oct 2003 16:39:39 +0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9UGdM5u021191; Thu, 30 Oct 2003 09:39:23 -0700 (MST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9UGdLIr014829; Thu, 30 Oct 2003 11:39:21 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h9UGdLid020712; Thu, 30 Oct 2003 11:39:21 -0500 (EST) Message-Id: <200310301639.h9UGdLid020712@strat.East.Sun.COM> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Juan Rodriguez Hervella cc: Pekka Savola , Soliman Hesham , itojun@itojun.org, ipv6@ietf.org, v6ops@ops.ietf.org From: Sebastien Roy Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: Message from Juan Rodriguez Hervella of "Thu, 30 Oct 2003 12:04:14 +0100." <200310301204.15655.jrh@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Oct 2003 11:39:21 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk jrh@it.uc3m.es said: > For example, your fridge wants to talk with the scheduler to ask for > more food. The oven, which is sending RAs, is turned off. This will > cause no communication at all. I prefer 3 seconds of delay. I'm the > auto-communication kind of man. I don't see how you reached the conclusion that the removal of the on-link assumption would cause lack of communication in your example. If you're depending on a fall-back to IPv4 (and I assume you are since you mentioned a 3 second delay), then communication will occur more quickly without the on-link assumption... Can you explain your reasoning? Your example is not well defined. Are the fridge and the scheduler on the same link or not? Do they have manually configured IPv6 addresses or statelessly autoconfigured addresses? Do they have IPv4 addresses? Is the oven both the IPv6 and IPv4 router? > > I don't intend to make you laugh but I think I will have to get some > information about the zero-conf WG's jobs before going on this > discussion, because I thought that this feature was a GOOD THING. The zeroconf requirements don't include the on-link assumption. They also don't include nodes residing on the same link, but it's not clear if the example you gave depends on that or not. > > The more obvious problem you may not be seeing is when an implementation > > has enabled dual-stack but does not have IPv6 connectivity at all (i.e., > > only the link-local addresses). > > This is the common case nowadays. When I connect to Internet at home with > my dial up provider, I've got IPv4 and also a link-local address and I've > never experienced any problem at all. Your experience is anecdotal. There may be two reasons for your not experiencing problems. 1. In general, do you attempt to communicate with nodes whose names resolve to both IPv4 and IPv6 addresses? Maybe not. 2. Some OS's never implemented the on-link assumption to begin with, maybe yours is one of them. -Seb From owner-v6ops@ops.ietf.org Thu Oct 30 12:37:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02203 for ; Thu, 30 Oct 2003 12:37:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFGgM-000Ofm-GA for v6ops-data@psg.com; Thu, 30 Oct 2003 17:34:02 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFGgI-000OfL-4R for v6ops@ops.ietf.org; Thu, 30 Oct 2003 17:33:58 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UHXox21044; Thu, 30 Oct 2003 19:33:50 +0200 Date: Thu, 30 Oct 2003 19:33:49 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: itojun@iijlab.net, , Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310301119.34023.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: > > Which problems are you referring to? I still don't understand :-( > > I'm talking about the problems you've found out. I still don't understand what you're talking about, but I'll respond to two points below.. Perhaps it'd be useful to try to characterize these issues as problems without presupposing the solutions *). I'd encourage you to try if you want to find alternative solutions. *) for example: When a dual-stack node whose IPv6 stack has been enabled is deployed on a link where there is no IPv6 connectivity (no IPv6 router, no tunneling mechanism), trying to connect to a global IPv6 address, obtained either manually or from the DNS, results significant delays, due to the on-link assumption. How to fix this? When an application has been configured to try both IPv4 and IPv6 ("AF_UNSPEC") when performing a connection and DNS lookups, a number of useless lookups are made when an IPv4-only nodes query for IPv6 DNS records, or IPv6 nodes without connectivity (see above) similarly query for IPv6 records. How to best determine which records don't need to be queried? > 1. The problem that this option is not useful if we allow to > make AAAA queries using link-local addresses. Perhaps you miswrote, but that's very far from from the problem. The problem is that a node asks for AAAA and A records with an app configured "AF_UNSPEC" even if it has only IPv6 loopback and link-local addresses. The resulting AAAA records will be pretty much useless unless one assumes it's OK to return link-local addresses from the DNS (or similar other naming service), and the general purpose apps to use them. > 4. The problem that if we keep the option as a flag, already > deployed applications won't use it. So what? Applications are updated regularly. This would actually be a good reason to issue a minor update: a performance+ robustness enhancement for those which don't have full v6 connectivity. > That wasn't my purpose. I wanted to show that the process of > initiating a connection is not as fast as turning on the telly. We have to > have in mind that this flag only minimize the worst case of this process, > that's all in my opinion. I think the analogue is entirely different. The people expect the connections to form immediately, without waiting. On the other hand, turning on a telly takes a while (the screen is dark, but gets lighter, and is OK in 10-15 seconds; the same with monitors). We can do better than that. And as connections are established dozens, hundreds or thousands of times a day, the time savings are singificant. -- 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 Oct 30 12:58:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03033 for ; Thu, 30 Oct 2003 12:58:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFH23-000Pvs-Gn for v6ops-data@psg.com; Thu, 30 Oct 2003 17:56:27 +0000 Received: from [3ffe:8114:2000:240:290:27ff:fe24:c19f] (helo=purgatory.unfix.org) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFH20-000Pvc-Mk for v6ops@ops.ietf.org; Thu, 30 Oct 2003 17:56:24 +0000 Received: from limbo (limbo.unfix.org [3ffe:8114:2000:240:200:39ff:fe77:1f3f]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 0D39E7FDE; Thu, 30 Oct 2003 18:56:21 +0100 (CET) From: "Jeroen Massar" To: "'Jeremy T. Bouse'" , "'Sukhdeep Johar'" Cc: , Subject: RE: Implementation of Ipv6 in winxp Date: Thu, 30 Oct 2003 18:56:16 +0100 Organization: Unfix Message-ID: <000f01c39f0f$1e354800$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <1067531814.3fa13e2695f8f@netmon.nttmcl.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- [notez bien this is v6ops; not MS ipv6 list :) ] Jeremy T. Bouse wrote: > I believe #2 is incorrect... IE 6 atleast can handle IPv6; > however it does not accept IPv6 addresses or do AAAA queries by default. It does support IPv6 by default on XP and up. Windows 2000 doesn't though and one indeed need a correct wininet.dll to use that functionality. Check the several 'fixed' IPv6 patches available which include a wininet.dll with a upgradedversionnumber. Note that it can cause problems. > Quoting Sukhdeep Johar : > > > 1. ARe you using the link-local addresses [fe80::xxxx] ? > > In that case, u need the scope , even on the same lan. > > > > 2. I understand that the default IE in xp cannot use > > literal ipv6 addresses. You need to map it in the hosts > > file. You can then access using the dns name in ur browser. Microsoft decided, smartly imho, to disable the support for http://[; Thu, 30 Oct 2003 13:14:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFHHV-0000hs-6t for v6ops-data@psg.com; Thu, 30 Oct 2003 18:12:25 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFHHP-0000hF-Q2 for v6ops@ops.ietf.org; Thu, 30 Oct 2003 18:12:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UHFsq20758; Thu, 30 Oct 2003 19:15:54 +0200 Date: Thu, 30 Oct 2003 19:15:53 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: Soliman Hesham , , , Subject: Re: Issue 3: on link assumption considered harmful In-Reply-To: <200310301223.44112.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: [...] > Ooops, forget the oven :-), just think as if the fridge was shipped > with an Ipv6 address prefix and the scheduler was shipped with > another IPv6 prefix :) The whole point of IPv6 (and also IP) is that machines aren't shipped with invented addresses, and you're supposed to make them automatically communicate. Or, in the case of IPv6, the invented address is their link-local address and they can autoconfigure another address. All of these are from the same prefix between all the nodes on a link. This is just so incredibly bad idea it doesn't even bear thinking about. But if one want to enable it manually, you can always point a default route in your Ethernet interface. More on the related subject from: Embedding Globally Routable Internet Addresses Considered Harmful draft-plonka-embed-addr-00 Abstract Vendors of consumer electronics and network gear have produced and sold hundreds of thousands of Internet hosts with globally routable Internet Protocol addresses embedded within their products' firmware. These products are now in operation world-wide and primarily include, but are not necessarily limited to, low-cost routers and middleboxes for personal or residential use. This "hard-coding" of globally routable IP addresses within the host's firmware presents significant problems to the operation of the Internet and to the management of its address space. This document means to clarify best current practices in the Internet community. It denouces the practice of embedding references to unique, globally routable IP addresses in Internet hosts, describes some of the resulting problems, and considers selected alternatives. It is also intended to remind the Internet community of the ephemeral nature of unique, globally routable IP addresses and that the assignment and use of such addresses is temporary and therefore should not be used in fixed configurations. -- 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 Oct 30 14:43:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06951 for ; Thu, 30 Oct 2003 14:43:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFId4-0004uJ-Db for v6ops-data@psg.com; Thu, 30 Oct 2003 19:38:46 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFIcz-0004te-VB for v6ops@ops.ietf.org; Thu, 30 Oct 2003 19:38:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UJcO023416; Thu, 30 Oct 2003 21:38:30 +0200 Date: Thu, 30 Oct 2003 21:38:17 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: Tony Hain , Subject: Re: Implementation vs. the Standard In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B047CA1CD@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk A couple of comments inline. On Thu, 30 Oct 2003, Bound, Jim wrote: > It is important for us to separate implementation choice vs. the > standard. The onlink and v6bydefault discussions are mostly a focus on > if you do this with IPv6 and don't think about this other aspect you can > hurt yourself. I'm not sure how to read this. Are you implying that the specifications could (should) include harmful or dubious features, which clever implementers could then ignore or work around locally, as a means for product/vendor differentiation? Probably not, but that's a way to interpret some of the comments about why things like these are outside the scope of the specs. > There is nothing wrong with documenting issues for implementers in an > RFC and that work should be encouraged. In that context I agree with > Pekka S. But, for the IETF to tell vendors how they ship their products > for customers is simply inappropriate and vendors will not listen to the > IETF, hence this is not a good use of our precious mail time. In that > sense I agree with Tony 100%. > > Discussion of operational issues with our standards and how they work > with implementation is a good discussion. But should not be a priority > over the standards work we need to deliver as a working group. Personally, I disagree with the second paragraph. It is almost criminally negligent to just push out standards, one after another, without fixing or documenting issues in the existing ones. Our number one priority to ensure that the standards and the supporting advice we generate is accurate, has no known problems and is interoperable. From my point of view, broken standards are worse than no standards at all, hence the need to focus to addressing the issues in the existing standards. > I would also add that topics which are standards we are working > on that are needed and on standards track receive priority mail > discussion. The Standards Track discussions are the ones that may help > improve time-to-market for the IETF to deliver their product/solutions > which are networking standards and the point of this body and forum. Exactly the reason why I believe these issues are critical. I'm personally very worried about more than just time-to-market -- rather, what kind of technology ends up in the market, and if there are flaws in that technology, how to fix it quickly that the market won't reject it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Oct 30 15:06: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 PAA08262 for ; Thu, 30 Oct 2003 15:06:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFJ06-0006Ec-8k for v6ops-data@psg.com; Thu, 30 Oct 2003 20:02:34 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFJ00-0006EE-TC for v6ops@ops.ietf.org; Thu, 30 Oct 2003 20:02:29 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UK2P723973; Thu, 30 Oct 2003 22:02:26 +0200 Date: Thu, 30 Oct 2003 22:02:25 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310302031.48801.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Note: at the end of the message, there is also a description of an another problem, partially described in draft-ietf-v6ops-v6onbydefault-00.txt. On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: > On Thursday 30 October 2003 18:33, Pekka Savola wrote: > > When a dual-stack node whose IPv6 stack has been enabled is deployed on a > > link where there is no IPv6 connectivity (no IPv6 router, no tunneling > > mechanism), trying to connect to a global IPv6 address, obtained either > > manually or from the DNS, results significant delays, due to the on-link > > assumption. How to fix this? > > (I wonder why onlink assumption was included in the spec, but that's > another story....) > > Ok, so if we get rid of the onlink-assumption, there won't be such > delay, is this right ?. Yep, the delay is eliminated (as far as I can see). > > When an application has been configured to try both IPv4 and IPv6 > > ("AF_UNSPEC") when performing a connection and DNS lookups, a number of > > useless lookups are made when an IPv4-only nodes query for IPv6 DNS > > records, or IPv6 nodes without connectivity (see above) similarly query > > for IPv6 records. How to best determine which records don't need to be > > queried? > > if the host answers with "no route to destination" or something like that, > (we don't have onlink assuption any more, remember), > this is fixed, the penalty for those extra IPv6 connection attempts will be as > tiny as my wage. This is a separate problem. What I was worried in above is eliminating the unnecessary DNS lookups. Your problem may be something like: When an application has been configured to try both IPv4 and IPv6 ("AF_UNSPEC"), the results of the query are tried in some order, typically IPv6 first. When the destination is unreachable, an error should be returned. How to make falling back to the next address robust? .. straying to the solutions side, you may want to consider e.g.: a) avoiding such connection attempts in the first place, i.e., with minimal complexity there is only minimal chance of someone misbehaving and something getting broken! b) ensuring somehow that you always get the ICMP message and the connect() (or similar code) reacts to it, that is, you get a feedback signal back from the system when the attempt fails. This is actually a big potential problem. Consider firewalls which discard (instead of send ICMP unreachable) packets. This could trigger a TCP timeout.. (see more at the end) c) .... > This is my major concern now, so I would be glad to hear your opinion > about this. See above. This is also a major potential problem (it isn't now, because IPv6 is only deployed by mostly clueful folks, but if the masses do it and use e.g. firewalls w/ silent discard, we could end up in a loooooot of trouble..) [snip -- to a description of a different issue] > I've also experienced a problem which I think doesn't have a > solution (at least a solution the host could implement). For example: > > I'm using the latest web browser, which it's already using this flag > because the developers are really smart and they are use to > trying more than one destination address (this still doesn't happen > on my Konqueror 3.1.4). > > I try to connect to "www.6bone.net", I receive both AAAA and A. > > My network is IPv6/IPv4, so I have no connectivity problems, and > my web tries to connect to IPv6 in the first place. > > "www.6bone.net" has just moved to IPv6, and its provider is having > a lot of problems with that, so they don't have outer IPv6 connectivity. > > (www.6bone.net is just an example, haven't occured to me on this website) I'm not sure what you mean by "outer IPv6 connectivity". Do you mean that either: - the IPv6 connectivity doesn't exist (you get back ICMP destination unreachable), - the IPv6 connectivity exists, but the packets get blackholed somewhere (you get nothing back, results in TCP timeout) - something else? In the former case, have a look at draft-ietf-v6ops-v6onbydefault-00.txt section 2.3; this is discussed there. TCP connection should not abort from an ICMP soft error such as destination unreachable. However, some implementations do this, and it may make most sense for quick recovery. In the latter case, there is no real fix that I'm aware of. Could be worth thinking about a bit, or writing down as a potential problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Oct 30 16:15:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11867 for ; Thu, 30 Oct 2003 16:15:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFK5g-0009ep-I6 for v6ops-data@psg.com; Thu, 30 Oct 2003 21:12:24 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFK5d-0009eV-D4 for v6ops@ops.ietf.org; Thu, 30 Oct 2003 21:12:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UKEOt24301; Thu, 30 Oct 2003 22:14:24 +0200 Date: Thu, 30 Oct 2003 22:14:24 +0200 (EET) From: Pekka Savola To: tsvwg@ietf.org cc: v6ops@ops.ietf.org Subject: TCP and ICMP soft-errors in IPv4/6 environments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (Targeted at Transport area, v6ops is there just to keep v6ops in the loop, this has already been discussed there at some length..) With dual-stack IPv4/6 deployments, when a TCP connection is tried to both an IPv6 and IPv4 address, these are done in serial w/ a getaddrinfo loop (in the typical case). If the first destination is unreachable (e.g. resulting in a host unreachable ICMPv6 message). The old host requirements document states that TCP MUST NOT abort connections on such soft errors. However, this poses some problems in current deployments where multiple addresses are tried sequentially, as summarized above. This is discussed more in section 2.3 of: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6onbydefault-00.txt Has this been discussed in the transport area? Is there something to be done about this, e.g. a BCP document discussing this practice and suggesting ICMP DU's are OK when establishing connections -- or something else? Pekka Writing as v6ops co-chair -- 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 Oct 30 16: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 QAA12466 for ; Thu, 30 Oct 2003 16:25:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFKGe-000AUc-Nf for v6ops-data@psg.com; Thu, 30 Oct 2003 21:23:44 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFKGc-000AUH-Di for v6ops@ops.ietf.org; Thu, 30 Oct 2003 21:23:42 +0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9ULMjxA005141; Thu, 30 Oct 2003 13:22:45 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9ULMjbx022758; Thu, 30 Oct 2003 16:22:45 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9ULMiS4000324; Thu, 30 Oct 2003 16:22:44 -0500 (EST) Message-Id: <200310302122.h9ULMiS4000324@thunk.east.sun.com> From: Bill Sommerfeld To: Pekka Savola cc: tsvwg@ietf.org, v6ops@ops.ietf.org Subject: Re: TCP and ICMP soft-errors in IPv4/6 environments In-Reply-To: Your message of "Thu, 30 Oct 2003 22:14:24 +0200." Reply-to: sommerfeld@east.sun.com Date: Thu, 30 Oct 2003 16:22:44 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Has this been discussed in the transport area? Is there something to be > done about this, e.g. a BCP document discussing this practice and > suggesting ICMP DU's are OK when establishing connections -- or something > else? Maybe the right answer here is a "slewed parallel" connection establishment; start with one address, and if you get a soft error or a RTO-sized timeout, try a second, third, fourth, etc., connection, but leave the prior ones open in the event they complete successfully. Soft errors wouldn't kill the first connection -- they'd just be a a hint to try another connection in parallel. This should probably be buried in a library routine so that applications don't have to reinvent this wheel. - Bill From owner-v6ops@ops.ietf.org Thu Oct 30 17: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 RAA17037 for ; Thu, 30 Oct 2003 17:19:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFL4o-000EJB-Np for v6ops-data@psg.com; Thu, 30 Oct 2003 22:15:34 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFL4k-000EIw-KT for v6ops@ops.ietf.org; Thu, 30 Oct 2003 22:15:30 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9UMFRM26929; Fri, 31 Oct 2003 00:15:27 +0200 Date: Fri, 31 Oct 2003 00:15:27 +0200 (EET) From: Pekka Savola To: Juan Rodriguez Hervella cc: v6ops@ops.ietf.org, Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG In-Reply-To: <200310302139.50993.jrh@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 30 Oct 2003, Juan Rodriguez Hervella wrote: [snip] > > Sorry but I don't catch this point. Maybe we are talking either > about different things or the same things, I'm not sure. > I will try to set up an specific example, talking about the right > behaviour we should expect of this stuff. > > If you make a getaddrinfo() call with AF_UNSPEC and AI_ADDRCONFIG on a > machine with dual-stack support, full IPv4 connectivity and only IPv6 link > local addresses, this should run as follows: > > 1. Interacting with the DNS over IPv4, but it will ask only for A r.records. > 2. Connecting using IPv4, no problem. > > If you've got the same scenario, but you don't use AI_ADDRCONFIG: > > 1. Interacting with the DNS over IPv4, it will return AAAA and A records. > 2. Trying to connect with an IPv6 global address. This should fail > inmediately (we don't have the delay that onlink assuption causes...) > with "no-route-to-host". > 3. A well-programmed app. would try with the IPv4 address, end up with > a conexion. > > Where are the "unnecesary DNS lookups" you are talking about ? > I think that you receive both AAAA and A records on the same unique query, > don't you ? Look at the details of item "1." in each case. There are multiple when queries multiple records are asked/responded. (On the other hand, with properly augmented AI_ADDRCONFIG, you could omit everything relating to AAAA records, causing optimization.) For example, this roughly what happens when you do try look up "psg.com" with getaddrinfo using PF_UNSPEC: 23:48:31.909344 80.186.150.55.1836 > 193.229.0.40.53: [udp sum ok] 1651+ AAAA? psg.com. (25) (ttl 64, id 27243, len 53) 23:48:31.920410 193.229.0.40.53 > 80.186.150.55.1836: [udp sum ok] 1651 q: AAAA? psg.com. 1/0/0 psg.com. AAAA 2001:418:1::62 (53) (DF) (ttl 251, id 17061, len 81) 23:48:31.920892 80.186.150.55.1837 > 193.229.0.40.53: [udp sum ok] 1652+ A? psg.com. (25) (ttl 64, id 27244, len 53) 23:48:31.930985 193.229.0.40.53 > 80.186.150.55.1837: [udp sum ok] 1652 q: A? psg.com. 1/0/0 psg.com. A 147.28.0.62 (41) (DF) (ttl 251, id 46142, len 69) Two roundtrips. Three if you do A6 as well :-), and even more if you have to look up the delegation paths as well. Note: I'm using a forwarding nameserver here -- in practice, the roundtrips would take much longer if nothing would be cached (the DNS server I'm pointing my resolver to already has everything about psg.com cached.). I did a test: tried to do a TCP connect to www.6bone.net. From the first DNS query packet sent out, it took 1.528 _seconds_ for the fist TCP packet to go out! The first AAAA record arrived after 0.915 seconds (a lot in itself). That gives a measure of how much (at least) it would be faster with IPv4-only. Over 50% additional delay, and it could be worse if the delegation path DNS servers have AAAA records which are not cached. Only after all the responses have been received, the TCP connection is established. After all, you have to run the default address selection on all the results. This feature of DNS lookups certainly should be spelled out if/when we add AI_ADDRCONFIG considerations to the v6onbydefault document, as it clearly isn't apparent.. -- 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 Oct 31 07:16: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 HAA23016 for ; Fri, 31 Oct 2003 07:16:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFY8h-0007Tr-NO for v6ops-data@psg.com; Fri, 31 Oct 2003 12:12:27 +0000 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFY8d-0007T7-Tq for v6ops@ops.ietf.org; Fri, 31 Oct 2003 12:12:24 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h9VBTa604793; Fri, 31 Oct 2003 13:29:37 +0200 Date: Fri, 31 Oct 2003 13:29:36 +0200 (EET) From: Pekka Savola To: Bill Sommerfeld cc: tsvwg@ietf.org, Subject: Re: TCP and ICMP soft-errors in IPv4/6 environments In-Reply-To: <200310302122.h9ULMiS4000324@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 30 Oct 2003, Bill Sommerfeld wrote: > > Has this been discussed in the transport area? Is there something to be > > done about this, e.g. a BCP document discussing this practice and > > suggesting ICMP DU's are OK when establishing connections -- or something > > else? > > Maybe the right answer here is a "slewed parallel" connection > establishment; start with one address, and if you get a soft error or > a RTO-sized timeout, try a second, third, fourth, etc., connection, > but leave the prior ones open in the event they complete successfully. > > Soft errors wouldn't kill the first connection -- they'd just be a a > hint to try another connection in parallel. > > This should probably be buried in a library routine so that > applications don't have to reinvent this wheel. This is probably an obvious first thought, as what would be the desirable behaviour. But what would that imply in practice? That at least some parts of the basic API functions like connect() be augmented by a set of new functions for managing connectivity? That could be a forever-project, while what we'd like is to get a fix that'd be usable in this decade :-). I'm not saying that's not a probably relevant option to consider, but I think folks have been thinking about replacing APIs before and not much has come out of it.. so I'm a bit reluctant to start on that particular path... -- 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 Oct 31 21:30:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28853 for ; Fri, 31 Oct 2003 21:30:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.24; FreeBSD 4.9) id 1AFlRf-000M87-NF for v6ops-data@psg.com; Sat, 01 Nov 2003 02:24:55 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AFlRc-000M7p-KI for v6ops@ops.ietf.org; Sat, 01 Nov 2003 02:24:52 +0000 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 31 Oct 2003 18:24:52 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 31 Oct 2003 18:24:56 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 Oct 2003 18:24:51 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 31 Oct 2003 18:24:51 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 31 Oct 2003 18:24:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 31 Oct 2003 18:24:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Implementation of Ipv6 in winxp Date: Fri, 31 Oct 2003 18:24:55 -0800 Message-ID: Thread-Topic: Implementation of Ipv6 in winxp thread-index: AcOfEKaFynT0jWOQQAmy3DSvKGOkdgBDOXGw From: "Christian Huitema" To: "Jeroen Massar" , "Jeremy T. Bouse" , "Sukhdeep Johar" Cc: , X-OriginalArrivalTime: 01 Nov 2003 02:24:49.0789 (UTC) FILETIME=[5343D2D0:01C3A01F] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable There are several places that are more appropriate than an IETF list to obtain information on IPv6 support in Microsoft products. A good start is the web page http://www.microsoft.com/ipv6, which includes pointers to various white papers, product descriptions, etc., including a pointer to the Frequently Asked Questions for IPv6 support on Windows XP: http://www.microsoft.com/technet/treeview/default.asp?url=3D/technet/prod= t echnol/winxppro/Plan/FAQIPV6.asp. This FAQ actually addresses the questions debated in this thread. A good place for further debates may be the news group "microsoft.public.platformsdk.networking.ipv6". -- Christian Huitema