From owner-v6ops@ops.ietf.org Tue Sep 3 19:37:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17293 for ; Tue, 3 Sep 2002 19:37:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mNDg-000Aie-00 for v6ops-data@psg.com; Tue, 03 Sep 2002 16:36:28 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17mNDb-000Aho-00 for v6ops@ops.ietf.org; Tue, 03 Sep 2002 16:36:23 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA09845 for ; Tue, 3 Sep 2002 16:36:19 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g83NaJ919301 for ; Tue, 3 Sep 2002 16:36:19 -0700 X-mProtect: <200209032336> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhq5ykW; Tue, 03 Sep 2002 16:36:17 PDT Message-ID: <3D754A77.8030505@iprg.nokia.com> Date: Tue, 03 Sep 2002 16:49:11 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Comments on the new proposed charter follow: > * To: IETF-Announce: ; > * Subject: WG Review: IPv6 Operations (v6ops) > * From: Steve Coya > * Date: Tue, 27 Aug 2002 10:05:36 -0400 > * Cc: new-work@ietf.org > > A new IETF working group has been proposed in the Operations and > Management Area. The IESG has not made any determination as yet. > > The following Description was submitted, and is provided for > informational purposes only: > > > IPv6 Operations (v6ops) > ----------------------- > > Current Status: Proposed Working Group > > Description of Working Group: > > The global deployment of IPv6 is underway, creating an IPv4/IPv6 > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and > nodes. This deployment must be properly handled to avoid the division > of the Internet into separate IPv4 and IPv6 networks while ensuring > global addressing and connectivity for all IPv4 and IPv6 nodes. > > The IPv6 Operations Working Group (v6ops) develops guidelines for the > operation of a shared IPv4/IPv6 Internet and provides guidance for > network operators on how to deploy IPv6 into existing IPv4-only > networks, as well as into new network installations. > > The v6ops working group will: > > (1) Solicit input from network operators and users to identify > operational or security issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. This includes The term "operational" needs to be defined. The above could be interpreted as implying that sub-optimal solutions are satisfactory, as long as they work in some fashion. I would like to see the term "operational" defined in such a way that the best solution for the problem space is considered; not just a one-size-fits-all solution that may be sub-optimal. > (7) Identify open operational or security issues with the deployment > solutions documented in (5) and fully document those open > issues in Internet-Drafts or Informational RFCs. Work to find > workarounds or solutions to basic, IP-level deployment issues > that can be solved using widely-applicable transition mechanisms, > such as dual-stack, tunneling or translation. > > If the satisfactory resolution of a deployment issue requires > the standardization of a new, widely-applicable transition > mechanism that does not properly fit into any other IETF WG or > area, the v6ops WG will standardize a transition mechanism > to meet that need. I find the above wording biased, since "widely-applicable" seems to be the only selection criteria mandated for the standardization of new mechanisms. I would like to see the above changed to allow for standardization of the best mechanism for a particular scenario; not just a one-size-fits-all. By way of analogy, four-door sedans are "widely-applicable" vehicles. But: - minivans are a better choice for large families - pick-ups are a better choice for hauling large loads - 4wd's are a better choice for off-road driving - etc. Summary - the wording in sections (1) and (7) seems to mandate lowest-common-denominator solutions and ignore solutions that provide a better fit. Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Sep 4 06:59:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22272 for ; Wed, 4 Sep 2002 06:59:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mXtS-000Mkp-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 04:00:18 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17mXtN-000MkY-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 04:00:13 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17mXtL-00009s-00; Wed, 04 Sep 2002 12:00:11 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17mXtL-00009n-00; Wed, 04 Sep 2002 12:00:11 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA27916; Wed, 4 Sep 2002 12:00:09 +0100 Message-ID: <3D75E7C1.E334A50E@hursley.ibm.com> Date: Wed, 04 Sep 2002 13:00:17 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Fred L. Templin" CC: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) References: <3D754A77.8030505@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Fred L. Templin" wrote: ... > Summary - the wording in sections (1) and (7) seems to mandate > lowest-common-denominator solutions and ignore solutions that > provide a better fit. It's hard to avoid special pleading (since the transition solution with my name on it is in the list), but I do think that there is a strong argument for concentrating on LCD solutions for the first wave. We might contemplate a separate IETF activity for advanced transition solutions. Brian From owner-v6ops@ops.ietf.org Wed Sep 4 07:15:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22579 for ; Wed, 4 Sep 2002 07:15:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mY8n-000NMr-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 04:16:09 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17mY8j-000NMf-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 04:16:06 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g84BG0R13058; Wed, 4 Sep 2002 14:16:00 +0300 Date: Wed, 4 Sep 2002 14:15:59 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: "Fred L. Templin" , Subject: Re: WG Review: IPv6 Operations (v6ops) In-Reply-To: <3D75E7C1.E334A50E@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 4 Sep 2002, Brian E Carpenter wrote: > "Fred L. Templin" wrote: > ... > > Summary - the wording in sections (1) and (7) seems to mandate > > lowest-common-denominator solutions and ignore solutions that > > provide a better fit. > > It's hard to avoid special pleading (since the transition solution > with my name on it is in the list), but I do think that there is a strong > argument for concentrating on LCD solutions for the first wave. > > We might contemplate a separate IETF activity for advanced transition > solutions. I agree with Brian. People already have problems trying to choose which cars to buy. Guides and expert knowledge help a bit but it's still difficult. It's quite much simpler if you don't have all that many choices to make. People don't get stuck on details, and we can concentrate better on really pressing matters (if any). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 4 15:46:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18601 for ; Wed, 4 Sep 2002 15:46:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mg5f-000MXx-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 12:45:27 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17mg5c-000MXj-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 12:45:24 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA04097; Wed, 4 Sep 2002 12:45:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g84JjL412987; Wed, 4 Sep 2002 12:45:21 -0700 X-mProtect: <200209041945> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGTFoXU; Wed, 04 Sep 2002 12:45:19 PDT Message-ID: <3D7665D9.9050806@iprg.nokia.com> Date: Wed, 04 Sep 2002 12:58:17 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) References: <3D754A77.8030505@iprg.nokia.com> <3D75E7C1.E334A50E@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Brian E Carpenter wrote: > "Fred L. Templin" wrote: > ... > >>Summary - the wording in sections (1) and (7) seems to mandate >>lowest-common-denominator solutions and ignore solutions that >>provide a better fit. > > > It's hard to avoid special pleading (since the transition solution > with my name on it is in the list), but I do think that there is a strong > argument for concentrating on LCD solutions for the first wave. I'm sorry; the text of sections (1) and (7) I was commenting on refers to selection criteria for *new* mechanisms - I had no intention of labeling the set of solutions already accepted to the wg as "LCD". Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Sep 4 22:36:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28109 for ; Wed, 4 Sep 2002 22:36:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mmUc-000FUT-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 19:35:38 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17mmUZ-000FUH-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 19:35:35 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CB216691B; Wed, 4 Sep 2002 22:35:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 4 Sep 2002 22:35:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Wed, 4 Sep 2002 22:35:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE90EE@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJTo0CO5z1YJFVPTOSkPO1y64RmWAA4X26w From: "Bound, Jim" To: "Fred L. Templin" , X-OriginalArrivalTime: 05 Sep 2002 02:35:33.0962 (UTC) FILETIME=[E8E652A0:01C25484] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA28109 I believe Fred has made a valid point on input to the charter. The one-size-fits-all is not a good way to view a tool. This is a good catch in the wording of the charter. thanks /jim > -----Original Message----- > From: Fred L. Templin [mailto:ftemplin@IPRG.nokia.com] > Sent: Tuesday, September 03, 2002 7:49 PM > To: v6ops@ops.ietf.org > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > Comments on the new proposed charter follow: > > > > * To: IETF-Announce: ; > > * Subject: WG Review: IPv6 Operations (v6ops) > > * From: Steve Coya > > * Date: Tue, 27 Aug 2002 10:05:36 -0400 > > * Cc: new-work@ietf.org > > > > A new IETF working group has been proposed in the Operations and > > Management Area. The IESG has not made any determination as yet. > > > > The following Description was submitted, and is provided for > > informational purposes only: > > > > > > IPv6 Operations (v6ops) > > ----------------------- > > > > Current Status: Proposed Working Group > > > > Description of Working Group: > > > > The global deployment of IPv6 is underway, creating an IPv4/IPv6 > > Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 > networks and > > nodes. This deployment must be properly handled to avoid > the division > > of the Internet into separate IPv4 and IPv6 networks while ensuring > > global addressing and connectivity for all IPv4 and IPv6 nodes. > > > > The IPv6 Operations Working Group (v6ops) develops > guidelines for the > > operation of a shared IPv4/IPv6 Internet and provides guidance for > > network operators on how to deploy IPv6 into existing IPv4-only > > networks, as well as into new network installations. > > > > The v6ops working group will: > > > > (1) Solicit input from network operators and users to identify > > operational or security issues with the IPv4/IPv6 Internet, and > > determine solutions or workarounds to those issues. > This includes > > The term "operational" needs to be defined. The above could > be interpreted as implying that sub-optimal solutions are > satisfactory, as long as they work in some fashion. I would > like to see the term "operational" defined in such a way that > the best solution for the problem space is considered; not > just a one-size-fits-all solution that may be sub-optimal. > > > (7) Identify open operational or security issues with the deployment > > solutions documented in (5) and fully document those open > > issues in Internet-Drafts or Informational RFCs. Work to find > > workarounds or solutions to basic, IP-level deployment issues > > that can be solved using widely-applicable transition > mechanisms, > > such as dual-stack, tunneling or translation. > > > > If the satisfactory resolution of a deployment issue requires > > the standardization of a new, widely-applicable transition > > mechanism that does not properly fit into any other IETF WG or > > area, the v6ops WG will standardize a transition mechanism > > to meet that need. > > I find the above wording biased, since "widely-applicable" seems to > be the only selection criteria mandated for the standardization of > new mechanisms. I would like to see the above changed to allow for > standardization of the best mechanism for a particular scenario; > not just a one-size-fits-all. > > By way of analogy, four-door sedans are "widely-applicable" > vehicles. But: > > - minivans are a better choice for large families > - pick-ups are a better choice for hauling large loads > - 4wd's are a better choice for off-road driving > - etc. > > Summary - the wording in sections (1) and (7) seems to mandate > lowest-common-denominator solutions and ignore solutions that > provide a better fit. > > Fred Templin > ftemplin@iprg.nokia.com > > > > From owner-v6ops@ops.ietf.org Wed Sep 4 22:55:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28560 for ; Wed, 4 Sep 2002 22:55:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mmnp-000GTP-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 19:55:29 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17mmnj-000GSM-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 19:55:23 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CA3884038; Wed, 4 Sep 2002 22:55:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 4 Sep 2002 22:55:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Wed, 4 Sep 2002 22:55:22 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE90F2@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJUAqr5WKjkxhQ7S0SX0ZsfSYoAKQAg7Dkw From: "Bound, Jim" To: "Brian E Carpenter" , "Fred L. Templin" Cc: X-OriginalArrivalTime: 05 Sep 2002 02:55:22.0722 (UTC) FILETIME=[AD74B420:01C25487] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA28560 Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, September 04, 2002 7:00 AM > To: Fred L. Templin > Cc: v6ops@ops.ietf.org > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > "Fred L. Templin" wrote: > ... > > Summary - the wording in sections (1) and (7) seems to mandate > > lowest-common-denominator solutions and ignore solutions that > > provide a better fit. > > It's hard to avoid special pleading (since the transition solution > with my name on it is in the list), but I do think that there > is a strong > argument for concentrating on LCD solutions for the first wave. Then stated it please Brian. Your really not responding to Fred's wording. The market wants special solutions like ISATAP, Teredo, and DSTM and they are all being deployed by customers I know of and will not share so no one ask. Granted its trial networks but that is how it starts. An LCD solution is good but not for all cases. Fred's car to minivan to truck is a perfect analogy he sent out. In my case I require a truck to haul my guns and german shepherds around :--). That being said I am being silent on all of this because as far as I am concerned ISATAP, Teredo, and DSTM all got screwed by the IETF process after years of support and work by the working group. But that is OK because if we don't continue this work in the v6ops group under some valid assumption based on the charter definition I for one will go do the work in the market and not in the IETF. I don't know how Christian and Fred feel but I know DSTM is being deployed and we can create a defacto spec if necessary and move it into the market. I am not playing this game much longer. Its absurd. In fact its not just IPv6 transition. Its in many places of the IETF. If someone finds technical flaws or problems in design of specs thats cool and they have to debate and state and defend their position. But to just tell a working group and authors "we just don't like it and its not needed" is hardly the IETF process I have come to spend so much energy on because it is completely unfair. I won't put up with it and I think many vendors won't put up with it. We have enough momentum and forums and lots of coordinated efforts in the industry now it might be time to just by-pass the IETF and just go do it and maybe that will give our process a wake up call. Because one is needed. But I would really like to hear you technically defend or even from market perspective why you believe the LCD is a good idea. > > We might contemplate a separate IETF activity for advanced transition > solutions. I don't think so. We will just do it in the market thank you. regards, /jim > > Brian > > From owner-v6ops@ops.ietf.org Wed Sep 4 22:55:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28592 for ; Wed, 4 Sep 2002 22:55:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mmpk-000GZY-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 19:57:28 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17mmpe-000GYf-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 19:57:22 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 946168C42; Wed, 4 Sep 2002 22:57:21 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 4 Sep 2002 22:57:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Wed, 4 Sep 2002 22:57:20 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE90F3@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJUBLTRIqpq8ukFTkaWfq25MG9uxQAgwUKQ From: "Bound, Jim" To: "Pekka Savola" , "Brian E Carpenter" Cc: "Fred L. Templin" , X-OriginalArrivalTime: 05 Sep 2002 02:57:21.0720 (UTC) FILETIME=[F4625B80:01C25487] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA28592 Pekka, Your just plain wrong. Do you think users are stupid? Do you think they even care about what we say here in the IETF work? No they do not. What they want are IPv6 solutions. And they will all want different ones. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 04, 2002 7:16 AM > To: Brian E Carpenter > Cc: Fred L. Templin; v6ops@ops.ietf.org > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > On Wed, 4 Sep 2002, Brian E Carpenter wrote: > > "Fred L. Templin" wrote: > > ... > > > Summary - the wording in sections (1) and (7) seems to mandate > > > lowest-common-denominator solutions and ignore solutions that > > > provide a better fit. > > > > It's hard to avoid special pleading (since the transition solution > > with my name on it is in the list), but I do think that > there is a strong > > argument for concentrating on LCD solutions for the first wave. > > > > We might contemplate a separate IETF activity for advanced > transition > > solutions. > > I agree with Brian. > > People already have problems trying to choose which cars to > buy. Guides > and expert knowledge help a bit but it's still difficult. > It's quite much > simpler if you don't have all that many choices to make. > People don't get > stuck on details, and we can concentrate better on really > pressing matters > (if any). > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Wed Sep 4 23:17:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28973 for ; Wed, 4 Sep 2002 23:17:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mnA9-000HhT-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 20:18:33 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17mnA5-000HhH-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 20:18:29 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BD90F282A; Wed, 4 Sep 2002 23:18:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 4 Sep 2002 23:18:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Wed, 4 Sep 2002 23:18:28 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE90FA@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJUAqr5WKjkxhQ7S0SX0ZsfSYoAKQAg7DkwAAEaUoA= From: "Bound, Jim" To: "Bound, Jim" , "Brian E Carpenter" , "Fred L. Templin" Cc: X-OriginalArrivalTime: 05 Sep 2002 03:18:28.0666 (UTC) FILETIME=[E78AF9A0:01C2548A] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA28973 also I do not consider 6to4 an LCD. It is a custom solution for many users. And a method that can be used by other mechanisms to work with. /jim > -----Original Message----- > From: Bound, Jim > Sent: Wednesday, September 04, 2002 10:55 PM > To: Brian E Carpenter; Fred L. Templin > Cc: v6ops@ops.ietf.org > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > Brian, > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, September 04, 2002 7:00 AM > > To: Fred L. Templin > > Cc: v6ops@ops.ietf.org > > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > > > > "Fred L. Templin" wrote: > > ... > > > Summary - the wording in sections (1) and (7) seems to mandate > > > lowest-common-denominator solutions and ignore solutions that > > > provide a better fit. > > > > It's hard to avoid special pleading (since the transition solution > > with my name on it is in the list), but I do think that there > > is a strong > > argument for concentrating on LCD solutions for the first wave. > > Then stated it please Brian. Your really not responding to > Fred's wording. > The market wants special solutions like ISATAP, Teredo, and > DSTM and they are all being deployed by customers I know of > and will not share so no one ask. Granted its trial networks > but that is how it starts. An LCD solution is good but not > for all cases. Fred's car to minivan to truck is a perfect > analogy he sent out. In my case I require a truck to haul my > guns and german shepherds around :--). > > That being said I am being silent on all of this because as > far as I am concerned ISATAP, Teredo, and DSTM all got > screwed by the IETF process after years of support and work > by the working group. But that is OK because if we don't > continue this work in the v6ops group under some valid > assumption based on the charter definition I for one will go > do the work in the market and not in the IETF. I don't know > how Christian and Fred feel but I know DSTM is being deployed > and we can create a defacto spec if necessary and move it > into the market. I am not playing this game much longer. > Its absurd. In fact its not just IPv6 transition. Its in > many places of the IETF. > > If someone finds technical flaws or problems in design of > specs thats cool and they have to debate and state and defend > their position. But to just tell a working group and authors > "we just don't like it and its not needed" is hardly the IETF > process I have come to spend so much energy on because it is > completely unfair. I won't put up with it and I think many > vendors won't put up with it. We have enough momentum and > forums and lots of coordinated efforts in the industry now it > might be time to just by-pass the IETF and just go do it and > maybe that will give our process a wake up call. Because one > is needed. > > But I would really like to hear you technically defend or > even from market perspective why you believe the LCD is a good idea. > > > > > We might contemplate a separate IETF activity for advanced > transition > > solutions. > > I don't think so. We will just do it in the market thank you. > > regards, > /jim > > > > > Brian > > > > > > From owner-v6ops@ops.ietf.org Wed Sep 4 23:27:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29091 for ; Wed, 4 Sep 2002 23:27:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mnJv-000IFB-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 20:28:39 -0700 Received: from c143.apnic14.nic.ad.jp ([202.11.26.143] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17mnJp-000IEq-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 20:28:33 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17mnJo-0006NV-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 20:28:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-reply-to: Jim.Bound's message of Wed, 04 Sep 2002 22:57:20 -0400. <9C422444DE99BC46B3AD3C6EAFC9711B02BE90F3@tayexc13.americas.cpqcorp.net> Message-Id: <20020905032223.69DDF7BC@starfruit.itojun.org> To: "Bound, Jim" Cc: "Pekka Savola" , "Brian E Carpenter" , "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) From: Jun-ichiro itojun Hagino Date: Thu, 05 Sep 2002 12:22:23 +0900 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Your just plain wrong. Do you think users are stupid? Do you think >they even care about what we say here in the IETF work? No they do not. > What they want are IPv6 solutions. And they will all want different >ones. (chair hat off) the comments i get from the people most is that, they have big trouble picking which ngtrans mechanisms to pick (for instance, which one to implement on their router, which one to deploy to their network). so what we need to do is cut down number of deployment mechanisms, and help people deploy network in actual use. as i said in IETF54 plenary, there's no need to deploy fancy IPv6 network. keep it simple, stupid and robust. itojun From owner-v6ops@ops.ietf.org Wed Sep 4 23:30:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29150 for ; Wed, 4 Sep 2002 23:30:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mnMl-000IRx-00 for v6ops-data@psg.com; Wed, 04 Sep 2002 20:31:35 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17mnMg-000IQz-00 for v6ops@ops.ietf.org; Wed, 04 Sep 2002 20:31:30 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D3DFB414F; Wed, 4 Sep 2002 23:31:29 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 4 Sep 2002 23:31:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Wed, 4 Sep 2002 23:31:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE90FD@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJUi4IwQfEIRKh8Qsit5hT9z3VqEQAAEn3Q From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" Cc: "Pekka Savola" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 05 Sep 2002 03:31:30.0015 (UTC) FILETIME=[B9435EF0:01C2548C] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29150 I don't hear that from any user in that way. What I hear is there are several good mechanisms they like and want to apply for different reasons. Also the one we are missing in our thinking is the user who will deploy a dominant IPv6 backbone where the only access to IPv4 is simply to reach legacy systems. They are also the ones deploying trial Mobile IPv6 networks with Mobile IPv6 handhelds. For them Ipv4 is to be treated as-needed basis. They don't even want to use 6to4. They will use ISATAP to jump-start installed base. They will use DSTM to give out addresses in ad-hoc manner. These folks will also spend money which is the largest hammer for any mechanism. But the key missing point in our collective thinking is assuming this type of network for IPv6 will only happen later during IPv6 adoption. That is plain wrong. Many of the users of IPv6 are building new and emerging systems that will be IPv6 out of the box and the networks for first deployment. What we need to do is flush out our assumptions on this mail list and see where we all stand. /jim > -----Original Message----- > From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net] > Sent: Wednesday, September 04, 2002 11:22 PM > To: Bound, Jim > Cc: Pekka Savola; Brian E Carpenter; Fred L. Templin; > v6ops@ops.ietf.org > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > >Your just plain wrong. Do you think users are stupid? Do you think > >they even care about what we say here in the IETF work? No > they do not. > > What they want are IPv6 solutions. And they will all want different > >ones. > > (chair hat off) > > the comments i get from the people most is that, they > have big trouble > picking which ngtrans mechanisms to pick (for instance, > which one > to implement on their router, which one to deploy to > their network). > so what we need to do is cut down number of deployment > mechanisms, > and help people deploy network in actual use. > > as i said in IETF54 plenary, there's no need to deploy > fancy IPv6 > network. keep it simple, stupid and robust. > > itojun > From owner-v6ops@ops.ietf.org Thu Sep 5 07:06:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14720 for ; Thu, 5 Sep 2002 07:06:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17muTN-000BXg-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 04:06:53 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17muTJ-000BXR-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 04:06:50 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17muTH-0007cc-00; Thu, 05 Sep 2002 12:06:47 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17muTH-0007cW-00; Thu, 05 Sep 2002 12:06:47 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA36114; Thu, 5 Sep 2002 12:06:46 +0100 Message-ID: <3D772E3E.379E5BBF@hursley.ibm.com> Date: Thu, 05 Sep 2002 12:13:18 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Fred L. Templin" CC: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) References: <3D754A77.8030505@iprg.nokia.com> <3D75E7C1.E334A50E@hursley.ibm.com> <3D7665D9.9050806@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Fred L. Templin" wrote: > > Brian, > > Brian E Carpenter wrote: > > "Fred L. Templin" wrote: > > ... > > > >>Summary - the wording in sections (1) and (7) seems to mandate > >>lowest-common-denominator solutions and ignore solutions that > >>provide a better fit. > > > > > > It's hard to avoid special pleading (since the transition solution > > with my name on it is in the list), but I do think that there is a strong > > argument for concentrating on LCD solutions for the first wave. > > I'm sorry; the text of sections (1) and (7) I was commenting on refers > to selection criteria for *new* mechanisms - I had no intention of > labeling the set of solutions already accepted to the wg as "LCD". LCD may be a wrong characterisation of them, but one assumes they were chosen because they were believed to be relatively simple and universal. Brian From owner-v6ops@ops.ietf.org Thu Sep 5 07:06:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14736 for ; Thu, 5 Sep 2002 07:06:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17muTV-000BXr-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 04:07:01 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17muTJ-000BXP-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 04:06:50 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17muTE-0007cQ-00; Thu, 05 Sep 2002 12:06:44 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17muTE-0007cL-00; Thu, 05 Sep 2002 12:06:44 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA29208; Thu, 5 Sep 2002 12:06:42 +0100 Message-ID: <3D772DC4.F6B186D3@hursley.ibm.com> Date: Thu, 05 Sep 2002 12:11:16 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Bound, Jim" CC: "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE90FA@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Bound, Jim" wrote: > > also I do not consider 6to4 an LCD. It is a custom solution for many users. And a method that can be used by other mechanisms to work with. That's why I was concerned about special pleading, but 6to4 wasn't intended as a custom solution, but as a general technique to help bootstrap IPv6 adoption. Anyway look again at what I said (or meant to say). I think it's appropriate to limit an ops WG to simple, hopefully universal, solutions and it's also appropriate to work on advanced solutions *in their own WG*. I think that's a win-win. If you look at the amount of agenda time that DSTM, ISATAP or Teredo have been getting in NGTRANS meetings recently you can see why they would be better in a separate group. Just doing it in the market doesn't cut it for solutions that require host stacks to collaborate. Brian > > /jim > > > -----Original Message----- > > From: Bound, Jim > > Sent: Wednesday, September 04, 2002 10:55 PM > > To: Brian E Carpenter; Fred L. Templin > > Cc: v6ops@ops.ietf.org > > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > > > > Brian, > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday, September 04, 2002 7:00 AM > > > To: Fred L. Templin > > > Cc: v6ops@ops.ietf.org > > > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > > > > > > > "Fred L. Templin" wrote: > > > ... > > > > Summary - the wording in sections (1) and (7) seems to mandate > > > > lowest-common-denominator solutions and ignore solutions that > > > > provide a better fit. > > > > > > It's hard to avoid special pleading (since the transition solution > > > with my name on it is in the list), but I do think that there > > > is a strong > > > argument for concentrating on LCD solutions for the first wave. > > > > Then stated it please Brian. Your really not responding to > > Fred's wording. > > The market wants special solutions like ISATAP, Teredo, and > > DSTM and they are all being deployed by customers I know of > > and will not share so no one ask. Granted its trial networks > > but that is how it starts. An LCD solution is good but not > > for all cases. Fred's car to minivan to truck is a perfect > > analogy he sent out. In my case I require a truck to haul my > > guns and german shepherds around :--). > > > > That being said I am being silent on all of this because as > > far as I am concerned ISATAP, Teredo, and DSTM all got > > screwed by the IETF process after years of support and work > > by the working group. But that is OK because if we don't > > continue this work in the v6ops group under some valid > > assumption based on the charter definition I for one will go > > do the work in the market and not in the IETF. I don't know > > how Christian and Fred feel but I know DSTM is being deployed > > and we can create a defacto spec if necessary and move it > > into the market. I am not playing this game much longer. > > Its absurd. In fact its not just IPv6 transition. Its in > > many places of the IETF. > > > > If someone finds technical flaws or problems in design of > > specs thats cool and they have to debate and state and defend > > their position. But to just tell a working group and authors > > "we just don't like it and its not needed" is hardly the IETF > > process I have come to spend so much energy on because it is > > completely unfair. I won't put up with it and I think many > > vendors won't put up with it. We have enough momentum and > > forums and lots of coordinated efforts in the industry now it > > might be time to just by-pass the IETF and just go do it and > > maybe that will give our process a wake up call. Because one > > is needed. > > > > But I would really like to hear you technically defend or > > even from market perspective why you believe the LCD is a good idea. > > > > > > > > We might contemplate a separate IETF activity for advanced > > transition > > > solutions. > > > > I don't think so. We will just do it in the market thank you. > > > > regards, > > /jim > > > > > > > > Brian From owner-v6ops@ops.ietf.org Thu Sep 5 07:29:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15442 for ; Thu, 5 Sep 2002 07:29:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17muqz-000CPm-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 04:31:17 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17muqv-000CPW-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 04:31:13 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g85BUuK25987; Thu, 5 Sep 2002 14:30:56 +0300 Date: Thu, 5 Sep 2002 14:30:56 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Jun-ichiro itojun Hagino , Brian E Carpenter , "Fred L. Templin" , Subject: RE: WG Review: IPv6 Operations (v6ops) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE90FD@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.8 required=5.0 tests=IN_REP_TO,PORN_10 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 4 Sep 2002, Bound, Jim wrote: > I don't hear that from any user in that way. What I hear is there are > several good mechanisms they like and want to apply for different > reasons. For (over?) 95% of folks, they're just distraction. And what we want here is to get deployments going. There's little need for anything fancy if you don't require it. I don't think all of these non-basic, complex, fringe(?) mechanisms should be discarded -- quite the contrary. But this is probably(?) not the right place. Waiting for nice mechanism "X" is also a good excuse to delay transition btw. > Also the one we are missing in our thinking is the user who will deploy > a dominant IPv6 backbone where the only access to IPv4 is simply to > reach legacy systems. They are also the ones deploying trial Mobile > IPv6 networks with Mobile IPv6 handhelds. For them Ipv4 is to be > treated as-needed basis. They don't even want to use 6to4. They will ^^^^^^^^^^^^^^^ > use ISATAP to jump-start installed base. They will use DSTM to give out > addresses in ad-hoc manner. [...] ^^^^^^^^^^^^^ I could say probably over 99% of folks doing this are not living in today's world. IPv4 just isn't ready to be "as-needed" at the moment, or you're probably using it in very simple ways (e.g. www browsing only which works quite well with NAT too :-). It's IMO very questionable to approach IPv4 needs with an "ad-hoc" ways when clearly the requirements for IPv4 are not, in reality, ad-hoc. But this is one approach for enterprise transition. I've been asked about it myself a few times: organization which would want to start deploying IPv6 internally, perhaps do some translation or proxying to reach IPv4 sites and just wait for an usable IPv6 Internet to emerge in xxx years. The problem with this is, really, that unless you can convince (lie :-) very well that xxx is not much more than 1-2, IS managers discard this approach as it generates no added value in the short term. Most don't want to be the test-bunnies for fancy technology. > But the key missing point in our collective thinking is assuming this > type of network for IPv6 will only happen later during IPv6 adoption. > That is plain wrong. Many of the users of IPv6 are building new and > emerging systems that will be IPv6 out of the box and the networks for > first deployment. I'd like to see this on real world (and not on fancy .ppt). People always seem to forget that they do happen to need IPv4 for something (e.g. in the case of routers, SNMP monitoring, RADIUS authentication for logins etc.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 5 09:17:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18243 for ; Thu, 5 Sep 2002 09:17:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mwWh-000GdE-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 06:18:27 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17mwWd-000Gcu-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 06:18:23 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0869A64DD; Thu, 5 Sep 2002 09:18:12 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 5 Sep 2002 09:18:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Thu, 5 Sep 2002 09:18:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9108@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJUzFYQQBPRkFdmSL2yeL2ott+sPwAEVYgw From: "Bound, Jim" To: "Brian E Carpenter" Cc: "Fred L. Templin" , X-OriginalArrivalTime: 05 Sep 2002 13:18:12.0061 (UTC) FILETIME=[AF5150D0:01C254DE] X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA18243 Brian, I can agree with what you say below for sure. Except for host stacks. I think if there is enough money on the table vendors will collaborate quite well. Look at RDMA if the IETF moves to slow here trust me RDMA with copy avoidance et al will happen while we are still discussing it in the IETF. The IETF is too slow now and in the mission to find the perfect spec we have lost time-to-market in our processes. Not all host stacks have to be used to adopt a technology like RDMA but if just 3 or 4 major vendors agree it does cause an effect in the market. Don't get me wrong I would love to see the IETF move faster, better, and lately in a more fair process. And one thing that would really help is something I said to Scott Bradner (one of the area directors I keep voting for fyi and him an allison run one of the most efficient areas in the IETF and why I have hopes for RDMA in the IETF) at a plenary about 2 years ago is: "It is imperative that "consistency" be used across the IETF. For example lets take the silence vs no silence for consensus in a working group. One does one thing the other does the other. For processes of governing I think this should be consistent whether I am working on IPv6 transition or Routing or SCTP. It is not today. Also Area Directors need to be more like "managers" than "engineers". And leave technical work to us in the working group and the chairs. My view is the IESG is a management body more than a technical body. But if we want to start an advanced transition area I will support that but we need that started A.S.A.P. regards, /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, September 05, 2002 6:11 AM > To: Bound, Jim > Cc: Fred L. Templin; v6ops@ops.ietf.org > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > "Bound, Jim" wrote: > > > > also I do not consider 6to4 an LCD. It is a custom > solution for many users. And a method that can be used by > other mechanisms to work with. > > That's why I was concerned about special pleading, but 6to4 > wasn't intended > as a custom solution, but as a general technique to help > bootstrap IPv6 adoption. > > Anyway look again at what I said (or meant to say). I think it's > appropriate to limit an ops WG to simple, hopefully > universal, solutions > and it's also appropriate to work on advanced solutions *in their > own WG*. I think that's a win-win. If you look at the amount of > agenda time that DSTM, ISATAP or Teredo have been getting in NGTRANS > meetings recently you can see why they would be better in a separate > group. Just doing it in the market doesn't cut it for solutions that > require host stacks to collaborate. > > Brian > > > > > > /jim > > > > > -----Original Message----- > > > From: Bound, Jim > > > Sent: Wednesday, September 04, 2002 10:55 PM > > > To: Brian E Carpenter; Fred L. Templin > > > Cc: v6ops@ops.ietf.org > > > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > > > > > > > Brian, > > > > > > > -----Original Message----- > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: Wednesday, September 04, 2002 7:00 AM > > > > To: Fred L. Templin > > > > Cc: v6ops@ops.ietf.org > > > > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > > > > > > > > > > "Fred L. Templin" wrote: > > > > ... > > > > > Summary - the wording in sections (1) and (7) seems to mandate > > > > > lowest-common-denominator solutions and ignore solutions that > > > > > provide a better fit. > > > > > > > > It's hard to avoid special pleading (since the > transition solution > > > > with my name on it is in the list), but I do think that there > > > > is a strong > > > > argument for concentrating on LCD solutions for the first wave. > > > > > > Then stated it please Brian. Your really not responding to > > > Fred's wording. > > > The market wants special solutions like ISATAP, Teredo, and > > > DSTM and they are all being deployed by customers I know of > > > and will not share so no one ask. Granted its trial networks > > > but that is how it starts. An LCD solution is good but not > > > for all cases. Fred's car to minivan to truck is a perfect > > > analogy he sent out. In my case I require a truck to haul my > > > guns and german shepherds around :--). > > > > > > That being said I am being silent on all of this because as > > > far as I am concerned ISATAP, Teredo, and DSTM all got > > > screwed by the IETF process after years of support and work > > > by the working group. But that is OK because if we don't > > > continue this work in the v6ops group under some valid > > > assumption based on the charter definition I for one will go > > > do the work in the market and not in the IETF. I don't know > > > how Christian and Fred feel but I know DSTM is being deployed > > > and we can create a defacto spec if necessary and move it > > > into the market. I am not playing this game much longer. > > > Its absurd. In fact its not just IPv6 transition. Its in > > > many places of the IETF. > > > > > > If someone finds technical flaws or problems in design of > > > specs thats cool and they have to debate and state and defend > > > their position. But to just tell a working group and authors > > > "we just don't like it and its not needed" is hardly the IETF > > > process I have come to spend so much energy on because it is > > > completely unfair. I won't put up with it and I think many > > > vendors won't put up with it. We have enough momentum and > > > forums and lots of coordinated efforts in the industry now it > > > might be time to just by-pass the IETF and just go do it and > > > maybe that will give our process a wake up call. Because one > > > is needed. > > > > > > But I would really like to hear you technically defend or > > > even from market perspective why you believe the LCD is a > good idea. > > > > > > > > > > > We might contemplate a separate IETF activity for advanced > > > transition > > > > solutions. > > > > > > I don't think so. We will just do it in the market thank you. > > > > > > regards, > > > /jim > > > > > > > > > > > Brian > > > From owner-v6ops@ops.ietf.org Thu Sep 5 09:41:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19019 for ; Thu, 5 Sep 2002 09:41:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17mwts-000Hh3-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 06:42:24 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17mwtn-000Hgs-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 06:42:20 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2279A2848; Thu, 5 Sep 2002 09:42:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 5 Sep 2002 09:42:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Thu, 5 Sep 2002 09:42:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B577@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJUz7j38w6B+tXuQ9WjlBjJStBx4AADwGqQ From: "Bound, Jim" To: "Pekka Savola" Cc: "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 05 Sep 2002 13:42:19.0031 (UTC) FILETIME=[0DC76A70:01C254E2] X-Spam-Status: No, hits=1.0 required=5.0 tests=PORN_10,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA19019 Pekka, > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, September 05, 2002 7:31 AM > To: Bound, Jim > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin; > v6ops@ops.ietf.org > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > On Wed, 4 Sep 2002, Bound, Jim wrote: > > I don't hear that from any user in that way. What I hear > is there are > > several good mechanisms they like and want to apply for different > > reasons. > > For (over?) 95% of folks, they're just distraction. And what > we want here > is to get deployments going. There's little need for > anything fancy if > you don't require it. Deployment is going as best it can right now. See the NTT MSC announcment that came out yesterday in Malaysia that is native IPv6. I don't think ISATAP, DSTM, or Teredo are "fancy" but solid mechanisms that work and for those moving at very fast pace. The mechanisms I feel are imperative for wide deployment are as follows: Basic Tunnels 6to4 ISATAP Teredo DSTM BIA (in some cases but caution is needed) NAT-PT and SIIT should be last resort and not used unless there is no choice. So not including NAT-PT and SIIT above that is 6 mechanisms. That is not to much for any user I know to absorb and understand. They are all deployed and implemented and all will work and all together as package permit users to adopt IPv6 without the use of Network Address Translation. Teredo though there are many parts is very doable on the Intranet, Extranet, and Internet. It will work. DSTM+ISATAP+Teredo+6to4 have multiple combinations also where they can work together. I see two key areas of deployment where there is real money to be made for IPv6. One is where technology is being built for military operations with IPv6 and many of what is called the Intelligent War Fighter visions will not even use IPv4 for things like sensor devices and other things I won't get into. They are in the factory now being built for 4 years from now. Using anything with IPv4 as core is a non-starter. Sure there will be legacy IPv4 things to speak with but thats where ISATAP and DSTM come in but not 6to4 or Teredo. The other is Mobile IPv6. Mobile IPv4 simply will not work except on an Intranet because anywhere NAT exists it kills true roaming without a "reconnect". Mobile IPv6 handsets require IPv6 and if they need IPv4 it is temporary because like the NTT MSC case all the initial services for the user are hosted with IPv6 like Web, Database, etc. What is happening is that unless vendors, operators, and some other entities I won't mention begin to make money on IPv6 they are going to stop momentum. Fortuneately we are seeing real purchase orders for IPv6 and boxes and software be sold at significant levels to warrant continued engineering and market investments. But those returns are not from the large mass that will move with LCD mechanisms or the 80% that will do as you say and want universal solutions (as Brian suggested). So the catch-22 is that the 20% of custom users is where we will all make our money for the next 3 years. Then the masses will begin conversion. So my issue is that to stop work on what we are doing that will make money is crazy in the IETF. Maybe we need an advanced Ipv6 transition area as Brian suggested but if that don't happen fast the vendors and entities that want to deploy this 20% will not wait for the IETF and do it out of band and create a storm of defacto standards for IPv6 that will compete with the IETF in the market. They have no choice and will not loose the mony waiting on 2 and 3 year discussions of how to do transition or settle for universal compromised solutions. > > I don't think all of these non-basic, complex, fringe(?) > mechanisms should > be discarded -- quite the contrary. But this is probably(?) > not the right > place. I am not sure yet. Randy Bush has been saying IPv6 is here as operator and I agree. How IPv6 deploy is still TBD. Why should not this true 20% deployment sector recieve the work from v6ops effort? I think not doing it is not wise. > > Waiting for nice mechanism "X" is also a good excuse to delay > transition > btw. No one has to wait. They are defined and done. > > > Also the one we are missing in our thinking is the user who > will deploy > > a dominant IPv6 backbone where the only access to IPv4 is simply to > > reach legacy systems. They are also the ones deploying trial Mobile > > IPv6 networks with Mobile IPv6 handhelds. For them Ipv4 is to be > > treated as-needed basis. They don't even want to use 6to4. > They will > ^^^^^^^^^^^^^^^ > > use ISATAP to jump-start installed base. They will use > DSTM to give out > > addresses in ad-hoc manner. [...] > ^^^^^^^^^^^^^ > > I could say probably over 99% of folks doing this are not living in > today's world. This is simply not true I hope my above mail helps change your mind on this statement above as its as far as I can take to convince you and others. > > IPv4 just isn't ready to be "as-needed" at the moment, or > you're probably > using it in very simple ways (e.g. www browsing only which works quite > well with NAT too :-). It's IMO very questionable to approach IPv4 > needs with an "ad-hoc" ways when clearly the requirements for > IPv4 are > not, in reality, ad-hoc. Ad hoc means the use of IPv4 is dicouraged as a policy and used only when necessary. So maybe adhoc was wrong term on my part. Many users want to run at 1000 miles an hour away from IPv4 NAT it is hurting them bad to evolve their networks for true peer-to-peer computing, applications, and security. That is driving the 20% above strongly to native IPv6 and dominant IPv6 strategy. > > But this is one approach for enterprise transition. I've > been asked about > it myself a few times: organization which would want to start > deploying > IPv6 internally, perhaps do some translation or proxying to reach IPv4 > sites and just wait for an usable IPv6 Internet to emerge in > xxx years. > The problem with this is, really, that unless you can > convince (lie :-) > very well that xxx is not much more than 1-2, IS managers discard this > approach as it generates no added value in the short term. Most don't > want to be the test-bunnies for fancy technology. When there future business depends on IPv6 test bunnies are easy to be and that is exactly what is happening now. > > > But the key missing point in our collective thinking is > assuming this > > type of network for IPv6 will only happen later during IPv6 > adoption. > > That is plain wrong. Many of the users of IPv6 are building new and > > emerging systems that will be IPv6 out of the box and the > networks for > > first deployment. > > I'd like to see this on real world (and not on fancy .ppt). > People always > seem to forget that they do happen to need IPv4 for something > (e.g. in the > case of routers, SNMP monitoring, RADIUS authentication for > logins etc.) That is being done right now within the 20% and entire architectures are being reworked to do exactly what I say above at some pretty significant levels within the enties with Exec VP support. Ipv6 is necessary now Pekka not an option. Its is not a question of "if" but "when". regards, /jim > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Thu Sep 5 11:54:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23490 for ; Thu, 5 Sep 2002 11:54:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17myxc-000Njy-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 08:54:24 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17myxY-000Njn-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 08:54:21 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g85Fs4s28236; Thu, 5 Sep 2002 18:54:05 +0300 Date: Thu, 5 Sep 2002 18:54:04 +0300 (EEST) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: "Bound, Jim" , Brian E Carpenter , "Fred L. Templin" , Subject: Re: WG Review: IPv6 Operations (v6ops) In-Reply-To: <20020905032223.69DDF7BC@starfruit.itojun.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=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thinking back after discussions with Jim et al, I have one additional issue to highlight: On Thu, 5 Sep 2002, Jun-ichiro itojun Hagino wrote: > >Your just plain wrong. Do you think users are stupid? Do you think > >they even care about what we say here in the IETF work? No they do not. > > What they want are IPv6 solutions. And they will all want different > >ones. > > (chair hat off) > > the comments i get from the people most is that, they have big trouble > picking which ngtrans mechanisms to pick (for instance, which one > to implement on their router, which one to deploy to their network). > so what we need to do is cut down number of deployment mechanisms, > and help people deploy network in actual use. ... Most importantly: > as i said in IETF54 plenary, there's no need to deploy fancy IPv6 > network. keep it simple, stupid and robust. There are two cases, I think: 1) network (ISP/core) transition. Folks who feel stuff like IGP or BGP tunneling is really needed etc. Most probably agree that complexity in the core networks is highly undesirable. 2) site/home transition. Current "approved" toolbox offers no solutions to e.g. provide IPv6 access through NAT's (well, it's a double-edged sword..), and some other solutions like ISATAP may be useful especially in large networks e.g. where admins wouldn't want to bother to build proper dual-stack infrastructure. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 5 18:05:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09484 for ; Thu, 5 Sep 2002 18:05:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17n4l0-000Gag-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 15:05:46 -0700 Received: from smtp2.southeast.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #1) id 17n4kv-000GZc-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 15:05:42 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by smtp2.southeast.rr.com (8.12.5/8.12.2) with ESMTP id g85M6BuW024962 for ; Thu, 5 Sep 2002 18:06:15 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 5 Sep 2002 18:05:37 -0400 Message-ID: <3D77D48D.71ED1A15@nc.rr.com> Date: Thu, 05 Sep 2002 18:02:53 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > There are two cases, I think: > > 1) network (ISP/core) transition. Folks who feel stuff like IGP or BGP > tunneling is really needed etc. Is this really the case? The large operators I have talked to don't want any transition tools in their core. They see 6to4, ISATAP, NAT-PT, various tunneling mechanisms, etc. as a leaf network solution. Their core is native v6. > > Most probably agree that complexity in the core networks is highly > undesirable. Agreed. Brian From owner-v6ops@ops.ietf.org Fri Sep 6 00:55:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16389 for ; Fri, 6 Sep 2002 00:55:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nB9F-000EQY-00 for v6ops-data@psg.com; Thu, 05 Sep 2002 21:55:13 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17nB9C-000EQN-00 for v6ops@ops.ietf.org; Thu, 05 Sep 2002 21:55:10 -0700 Received: from kenawang.windriver.com ([192.168.1.60]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id VAA12456; Thu, 5 Sep 2002 21:54:28 -0700 (PDT) Message-Id: <5.1.0.14.2.20020906002645.03a92910@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Sep 2002 00:47:53 -0400 To: "Fred L. Templin" From: Margaret Wasserman Subject: Re: WG Review: IPv6 Operations (v6ops) Cc: v6ops@ops.ietf.org In-Reply-To: <3D754A77.8030505@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Fred, >Summary - the wording in sections (1) and (7) seems to mandate >lowest-common-denominator solutions and ignore solutions that >provide a better fit. It was our intention to write a charter that limits the v6ops WG to work on the minimal required set of IPv6 transition tools/mechanisms, and Itojun and I plan to be fairly conservative about enforcing the requirements of the charter in this area. It is our goal for v6ops to primarily focus on the operational and security issues that arise in the deployment of IPv6, not on anticipating transition issues and developing a transition toolkit. This does not mean that we won't standardize any new transition tools. However, we will only standardize a new tool if it solves a well-defined, general IPv6 deployment problem that cannot be satisfactorily addressed using other means (such as existing transition tools and/or operational practices). The IETF may also develop transition tools for IPv6 deployment problems related to specific application and/or transport protocols, but that work would be done in the proper WGs/areas, not within v6ops. Margaret From owner-v6ops@ops.ietf.org Fri Sep 6 07:27:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29785 for ; Fri, 6 Sep 2002 07:27:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nHHZ-0008SX-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 04:28:13 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17nHHV-0008SK-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 04:28:09 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g86BS5805007; Fri, 6 Sep 2002 14:28:05 +0300 Date: Fri, 6 Sep 2002 14:28:05 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) In-Reply-To: <3D77D48D.71ED1A15@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 5 Sep 2002, Brian Haberman wrote: > Pekka Savola wrote: > > > > There are two cases, I think: > > > > 1) network (ISP/core) transition. Folks who feel stuff like IGP or BGP > > tunneling is really needed etc. > > Is this really the case? Yes. Why else would they have been specified and (in the case of BGP tunneling) implemented by a few vendors (Cisco, Juniper a least) -- the customers are asking for them. > The large operators I have talked to don't > want any transition tools in their core. They see 6to4, ISATAP, NAT-PT, > various tunneling mechanisms, etc. as a leaf network solution. Their > core is native v6. That's my view too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Sep 6 08:08:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00794 for ; Fri, 6 Sep 2002 08:08:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nHvR-000ASC-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 05:09:25 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17nHvO-000AS1-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 05:09:22 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A8D1C4B22; Fri, 6 Sep 2002 21:09:15 +0900 (JST) To: Pekka Savola Cc: Brian Haberman , v6ops@ops.ietf.org In-reply-to: pekkas's message of Fri, 06 Sep 2002 14:28:05 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: WG Review: IPv6 Operations (v6ops) From: itojun@iijlab.net Date: Fri, 06 Sep 2002 21:09:15 +0900 Message-Id: <20020906120915.A8D1C4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> Is this really the case? >Yes. Why else would they have been specified and (in the case of BGP >tunneling) implemented by a few vendors (Cisco, Juniper a least) -- the >customers are asking for them. it really depends on what kind of network the ISP has already deployed. if they have already deployed MPLS-based network, they need some trick to reuse IPv4 virtual circuit (what was the name for it in MPLS?), hence the drafts. if they have a pure IP backbone, we need no tricks. itojun From owner-v6ops@ops.ietf.org Fri Sep 6 08:19:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01094 for ; Fri, 6 Sep 2002 08:19:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nI6i-000B28-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 05:21:04 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17nI6f-000B1x-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 05:21:01 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g86CKrrU017162; Fri, 6 Sep 2002 14:20:53 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Sep 2002 14:20:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0972@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'itojun@iijlab.net'" , Pekka Savola Cc: Brian Haberman , v6ops@ops.ietf.org Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Fri, 6 Sep 2002 14:20:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk it really depends on what kind of network the ISP has > already deployed. > if they have already deployed MPLS-based network, they need some > trick to reuse IPv4 virtual circuit (what was the name > for it in MPLS?), > hence the drafts. if they have a pure IP backbone, we > need no tricks. => Well, not everyone has to use 6-to-4 in a pure IP backbone. If they don't use 6-to-4 they need some other way of discovering the tunnel end point, I think the BGP extensions do that job well. How else would you do it, 6-to-4 for every site? Hesham From owner-v6ops@ops.ietf.org Fri Sep 6 09:31:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02892 for ; Fri, 6 Sep 2002 09:31:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nJDN-000EmI-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 06:32:01 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17nJDJ-000Em7-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 06:31:58 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C714B4B22; Fri, 6 Sep 2002 22:31:52 +0900 (JST) To: "Hesham Soliman (EAB)" Cc: Pekka Savola , Brian Haberman , v6ops@ops.ietf.org In-reply-to: hesham.soliman's message of Fri, 06 Sep 2002 14:20:49 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0972@Esealnt861.al.sw.ericsson.se> 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: WG Review: IPv6 Operations (v6ops) From: itojun@iijlab.net Date: Fri, 06 Sep 2002 22:31:52 +0900 Message-Id: <20020906133152.C714B4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >=> Well, not everyone has to use 6-to-4 in a pure IP >backbone. If they don't use 6-to-4 they need some other >way of discovering the tunnel end point, I think the >BGP extensions do that job well. How else would you >do it, 6-to-4 for every site? what do you mean by 6-to-4? assuming that you mean IPv6 over IPv4 tunnel, you can deal with it well enough with manual configuration. you don't need any automation. (you know, ISPs set up IBGP full mesh manually so we can deal with it too) itojun From owner-v6ops@ops.ietf.org Fri Sep 6 10:06:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04502 for ; Fri, 6 Sep 2002 10:06:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nJmA-000Gly-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 07:07:58 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17nJm4-000GlH-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 07:07:53 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g86E7mrV021425; Fri, 6 Sep 2002 16:07:48 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Sep 2002 16:07:48 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0977@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'itojun@iijlab.net'" , "Hesham Soliman (EAB)" Cc: Pekka Savola , Brian Haberman , v6ops@ops.ietf.org Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Fri, 6 Sep 2002 16:07:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >=> Well, not everyone has to use 6-to-4 in a pure IP > >backbone. If they don't use 6-to-4 they need some other > >way of discovering the tunnel end point, I think the > >BGP extensions do that job well. How else would you > >do it, 6-to-4 for every site? > > what do you mean by 6-to-4? assuming that you mean > IPv6 over IPv4 > tunnel, you can deal with it well enough with manual > configuration. > you don't need any automation. > (you know, ISPs set up IBGP full mesh manually so we > can deal with > it too) => Are ISPs also happy to setup there EGPs manually? I don't understand why we should drop something that makes it either to setup tunnels instead of relying on manual configuration. Just because people do it manually today is not enough to justify dropping it. If people did that a few years ago, DHCP would not have been developed :) Hesham From owner-v6ops@ops.ietf.org Fri Sep 6 10:34:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05338 for ; Fri, 6 Sep 2002 10:34:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nKCG-000IJA-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 07:34:56 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17nKCB-000IIa-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 07:34:52 -0700 Received: from kenawang.windriver.com ([192.168.1.56]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA09393; Fri, 6 Sep 2002 07:34:18 -0700 (PDT) Message-Id: <5.1.0.14.2.20020906101145.03aa6c70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Sep 2002 10:35:33 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: WG Review: IPv6 Operations (v6ops) Cc: v6ops@ops.ietf.org In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0977@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Hesham, Although I have been reading this thread closely, I'm not quite sure what we're talking about here... >=> Are ISPs also happy to setup there EGPs manually? >I don't understand why we should drop something that makes >it either to setup tunnels instead of relying on manual >configuration. Just because people do it manually >today is not enough to justify dropping it. If people >did that a few years ago, DHCP would not have been developed :) Are you talking about the BGP Tunneling specification? Even if it were absolutely necessary to have some sort of BGP extensions to make shared IPv4/IPv6 networks work (about which there is apparently some disagreement), why would we want to standardize BGP extensions in an OPS area WG, instead of doing it within the WG responsible for BGP (the idr WG). Based on the v6ops charter, the v6ops WG might identify a need in this area, but then we would work within the idr WG to devise an appropriate solution. Margaret From owner-v6ops@ops.ietf.org Fri Sep 6 10:47:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05785 for ; Fri, 6 Sep 2002 10:47:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nKPM-000J2t-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 07:48:28 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17nKPJ-000J2a-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 07:48:25 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g86EmNrU001816; Fri, 6 Sep 2002 16:48:23 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Sep 2002 16:48:23 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0978@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Hesham Soliman (EAB)" Cc: v6ops@ops.ietf.org Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Fri, 6 Sep 2002 16:48:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Are you talking about the BGP Tunneling specification? => Yes. > > Even if it were absolutely necessary to have some sort of BGP > extensions to make shared IPv4/IPv6 networks work (about which > there is apparently some disagreement), why would we want to > standardize BGP extensions in an OPS area WG, instead of doing > it within the WG responsible for BGP (the idr WG). => I don't care why or where it is done, why was it in the ops area to start with ?? I only care about seeing it done. > > Based on the v6ops charter, the v6ops WG might identify a need in > this area, but then we would work within the idr WG to devise > an appropriate solution. => Fine, as I said I don't care where it's done, I want to make sure it's not dropped, and it's very easy for a WG to drop a spec without trying to help its authors find the right place. Hesham From owner-v6ops@ops.ietf.org Fri Sep 6 11:32:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07431 for ; Fri, 6 Sep 2002 11:32:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nL74-000Lk8-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 08:33:38 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17nL71-000Ljx-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 08:33:35 -0700 Received: from kenawang.windriver.com ([192.168.1.56]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA20573; Fri, 6 Sep 2002 08:32:59 -0700 (PDT) Message-Id: <5.1.0.14.2.20020906111327.03aa7ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Sep 2002 11:31:15 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: WG Review: IPv6 Operations (v6ops) Cc: v6ops@ops.ietf.org, ngtrans@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0978@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Hesham, At 10:48 AM 9/6/02, Hesham Soliman (EAB) wrote: >=> Fine, as I said I don't care where it's done, I want >to make sure it's not dropped, and it's very easy for a WG >to drop a spec without trying to help its authors find >the right place. Before we officially disband the ngtrans WG, we will have to make a decision about what to do with all of its WG IDs. There are a number of choice, but the main options are: - The draft is reverted to an individual submission. This is the default choice for documents that don't find a new home. Most of the ngtrans drafts will probably fall into this category. There is a further choice here -- whether to change the name of the draft immediately, or leave it as draft-ietf-ngtrans-*... New revisions of these drafts would need to be done under the authors' names, as ngtrans would no longer exist. - The draft is moved to v6ops or to another WG. In order for this to happen, the document would need to fit within the charter of another WG, and there would need to be a consensus within the WG to accept the document as a work item . I expect that we will officially accept a few of the ngtrans work items (ones that clearly fit into the v6ops WG charter) as v6ops work items in Sunnyvale. - The draft is immediately expired. I don't think we will do this with any of the ngtrans work items, unless we have active documents whose authors would prefer to have them expired, rather than reverting them to an individual submission. I realize that these aren't great choices. The authors of ngtrans work items have worked very hard to produce good documents that have been accepted by the ngtrans WG and reflect WG consensus, and these choices will represent an official step backwards for many of those documents. In most cases, though, the actual status of this work won't really have changed. For the past several months, all ngtrans transition mechanism work has been on-hold pending the outcome of our efforts to define deployment scenarios and solutions, and none of this work could be advanced unless it met most of the same criteria that are listed in the v6ops charter. Margaret From owner-v6ops@ops.ietf.org Fri Sep 6 12:27:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11654 for ; Fri, 6 Sep 2002 12:27:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nLxz-000PHo-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 09:28:19 -0700 Received: from mrwint.cisco.com ([144.254.98.48] helo=cisco.com) by psg.com with esmtp (Exim 3.36 #1) id 17nLxt-000PGE-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 09:28:14 -0700 Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA17534; Fri, 6 Sep 2002 17:28:00 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Margaret Wasserman Cc: "Hesham Soliman (EAB)" , v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) References: <5.1.0.14.2.20020906101145.03aa6c70@mail.windriver.com> From: Ole Troan Date: Fri, 06 Sep 2002 17:28:00 +0100 In-Reply-To: <5.1.0.14.2.20020906101145.03aa6c70@mail.windriver.com> (Margaret Wasserman's message of "Fri, 06 Sep 2002 10:35:33 -0400") Message-ID: <7t5it1julpr.fsf@mrwint.cisco.com> Lines: 43 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Hi Hesham, > > Although I have been reading this thread closely, I'm not > quite sure what we're talking about here... > >>=> Are ISPs also happy to setup there EGPs manually? >>I don't understand why we should drop something that makes >>it either to setup tunnels instead of relying on manual >>configuration. Just because people do it manually >>today is not enough to justify dropping it. If people >>did that a few years ago, DHCP would not have been developed :) > > Are you talking about the BGP Tunneling specification? > > Even if it were absolutely necessary to have some sort of BGP > extensions to make shared IPv4/IPv6 networks work (about which > there is apparently some disagreement), why would we want to > standardize BGP extensions in an OPS area WG, instead of doing > it within the WG responsible for BGP (the idr WG). from my reading of the BGP tunnel specification, I cannot see any text suggesting new BGP extensions. the document suggests two ways of using BGP: 1. in combination with e.g 6to4, exchange native IPv6 prefixes, using 6to4 next-hops. this already works with all BGP/IPv6 implementations that I know of. the building blocks for this mechanism are already specified in 6to4 and MP-BGP RFC's. specifications. 2. routes are exchanged over BGP/IPv4, some special next-hop, like an IPv4 mapped address is used. IPv6 route resolution has to do lookup in IPv4 RIB, and/or MPLS LIB. which format the IPv6 next-hop should have needs to be standardised. > Based on the v6ops charter, the v6ops WG might identify a need in > this area, but then we would work within the idr WG to devise > an appropriate solution. I think it belongs in v6ops. /ot From owner-v6ops@ops.ietf.org Fri Sep 6 14:23:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16615 for ; Fri, 6 Sep 2002 14:23:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nNls-0006Ij-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 11:23:56 -0700 Received: from e31.co.us.ibm.com ([32.97.110.129]) by psg.com with esmtp (Exim 3.36 #1) id 17nNln-0006IF-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 11:23:51 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g86INmlj020124; Fri, 6 Sep 2002 14:23:48 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g86INl19119322; Fri, 6 Sep 2002 12:23:47 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g86IK9325975; Fri, 6 Sep 2002 14:20:09 -0400 Message-Id: <200209061820.g86IK9325975@rotala.raleigh.ibm.com> To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: WG management (was Re: WG Review: IPv6 Operations (v6ops) ) In-Reply-To: Message from "Thu, 05 Sep 2002 09:18:11 EDT." <9C422444DE99BC46B3AD3C6EAFC9711B02BE9108@tayexc13.americas.cpqcorp.net> Date: Fri, 06 Sep 2002 14:20:09 -0400 From: Thomas Narten X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a bit off topic, but I want to respond anyway. "Bound, Jim" writes: > Don't get me wrong I would love to see the IETF move faster, better, > and lately in a more fair process. And one thing that would really > help is something I said to Scott Bradner (one of the area directors > I keep voting for fyi and him an allison run one of the most > efficient areas in the IETF and why I have hopes for RDMA in the > IETF) at a plenary about 2 years ago is: "It is imperative that > "consistency" be used across the IETF. I am in support of consistency, where it make sense. > For example lets take the silence vs no silence for consensus in a > working group. One does one thing the other does the other. There are good reasons for this. In some WGs, the WG never says (hardly) anything, even when something seems like a bad or even dangerous idea. The WG chairs (and ADs) are supposed to ensure that specs are baked and won't cause problems when deployed. So, asking for explicit support is a useful tool to force people to come out and say "I have looked at this, and I think it is good stuff". One doesn't always need this. It depends on the WG and the specific document at hand. I (as an AD) have asked to see explicit WG support when I have concerns about a document and it seems like nobody is actually looking at the document and it seems like a document is moving forward only because nobody seems to be objecting. If no one is willing to speak up on behalf of a document (other than the authors) that is often cause for concern... > For processes of governing I think this should be consistent whether > I am working on IPv6 transition or Routing or SCTP. It is not > today. Also Area Directors need to be more like "managers" than > "engineers". And leave technical work to us in the working group > and the chairs. ADs are (and need to be) both. ADs certainly believe they are obligated to ensure that specs are baked and complete from a technical perspective. This is not just a managerial function, it requires being able to do technical assessments and reviews. The motivation comes straight out of RFC 2026. If the ADs don't intervene when there are technical problems with a document, who will? Thomas From owner-v6ops@ops.ietf.org Fri Sep 6 14:43:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17317 for ; Fri, 6 Sep 2002 14:43:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nO5n-0007Tv-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 11:44:31 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17nO5j-0007TZ-00 for v6ops@ops.ietf.org; Fri, 06 Sep 2002 11:44:27 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g86IiLRb011978; Fri, 6 Sep 2002 20:44:22 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 6 Sep 2002 20:44:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F097A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman '" , "Hesham Soliman (EAB)" Cc: "'v6ops@ops.ietf.org '" , "'ngtrans@sunroof.eng.sun.com '" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Fri, 6 Sep 2002 20:44:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA17317 Hi Margaret, Before we officially disband the ngtrans WG, we will have to make a decision about what to do with all of its WG IDs. There are a number of choice, but the main options are: - The draft is reverted to an individual submission. This is the default choice for documents that don't find a new home. Most of the ngtrans drafts will probably fall into this category. There is a further choice here -- whether to change the name of the draft immediately, or leave it as draft-ietf-ngtrans-*... New revisions of these drafts would need to be done under the authors' names, as ngtrans would no longer exist. - The draft is moved to v6ops or to another WG. In order for this to happen, the document would need to fit within the charter of another WG, and there would need to be a consensus within the WG to accept the document as a work item . I expect that we will officially accept a few of the ngtrans work items (ones that clearly fit into the v6ops WG charter) as v6ops work items in Sunnyvale. - The draft is immediately expired. I don't think we will do this with any of the ngtrans work items, unless we have active documents whose authors would prefer to have them expired, rather than reverting them to an individual submission. I realize that these aren't great choices. The authors of ngtrans work items have worked very hard to produce good documents that have been accepted by the ngtrans WG and reflect WG consensus, and these choices will represent an official step backwards for many of those documents. => Understood. In this particular thread I was trying to make the case for the EGP/IGP-based tunnelling because I think it's very useful/needed and supported by all the major router vendors. In this case, I think that the picture is not too grim because hopefully they can be moved to existing WGs in the routing area. I hope that some communication takes place between the chairs/ADs to see if this is feasible. I have some concerns about other drafts, like for example ISATAP, which is also a very useful tool and does have deployment cases. I'm just not sure how concrete one has to be to "prove" that deployment will need something, when the actual deplyment hasn't taken place on a large scale. To a large extent there will be some speculation, which is no different to the justifications that were behind these drafts when they were wrote in the first place. If we wait for people to deploy networks and then discover that they are missing pieces then we're too late. Let me give you an example, if 6to4 was written now, it would have suffered the same destiny as ISATAP or BGP-based tunnelling. But because it was written a long time ago, it is actually an RFC. I'm not sure that 6to4 is a better solution for inter-domain tunnelling than BGP-based tunnels. I could be completely wrong´, I hope so.... Hesham From owner-v6ops@ops.ietf.org Fri Sep 6 17:03:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21380 for ; Fri, 6 Sep 2002 17:03:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nQH1-000EKO-00 for v6ops-data@psg.com; Fri, 06 Sep 2002 14:04:15 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17nQGx-000EKB-00; Fri, 06 Sep 2002 14:04:11 -0700 Received: from classic.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g86LFqE60934; Fri, 6 Sep 2002 17:15:53 -0400 (EDT) Date: Thu, 05 Sep 2002 07:25:47 -0400 From: Marc Blanchet To: Jun-ichiro itojun Hagino , mrw@windriver.com, randy@psg.com cc: Pekka Savola , Brian E Carpenter , "Fred L. Templin" , v6ops@ops.ietf.org, "Bound, Jim" Subject: Re: WG Review: IPv6 Operations (v6ops) Message-ID: <495950000.1031225147@classic.viagenie.qc.ca> In-Reply-To: <20020905032223.69DDF7BC@starfruit.itojun.org> References: <20020905032223.69DDF7BC@starfruit.itojun.org> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_24_48 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA21380 - I think the idea behind having a small set of "core" transition mechanism handled by the "official" v6 ops IETF wg might make sense. - but I also think that we are still in very early stage of IPv6 deployment (compared to the full blown IPv6-only internet that might happen in a few years... ;-))) - which tells me that it is not the time to completly cut solutions/protocols/ that might fit in some environments. It is just too early for a so important technology for the future of the internet (i.e. ipv6). My suggestion is: - have a process in IETF (compared to Jim, I can't think of another organisation to do that, and would be not an overall good idea to do it) that would work on all non-core transition mechanism (i.e. mechanism not chosen by v6ops as wg items) and the goal, for now, would have them published, if agreeable by the process as either Informational or experimental. - this way, those people working on products/solutions/experimentation/.... will have a forum to discuss these mechanisms and have a spec that will produce interoperable implementations through a stable document mechanism (i.e. RFC publication) - based on feedback over time, implementations, "market acceptance: i.e. how successful this or that solution is used and deployed", ..., the v6ops and/or the IESG and/or the right instance in IETF could reconsider, later on, to "promote" one or many of those "experimental/informational specs to the standard track. - I'm enough convinced that I can commit to spend time on this to start/work on this proposed process with the ADs/v6ops chairs/... if this is an accepted idea within the community. To me, it is much highly prefereable to have interoperable implementations of non-core transition mechanisms that many specs that are floating around without any status and stability that will produce non-interoperable implementations. Marc. -- jeudi, septembre 05, 2002 12:22:23 +0900 Jun-ichiro itojun Hagino wrote/a écrit: >> Your just plain wrong. Do you think users are stupid? Do you think >> they even care about what we say here in the IETF work? No they do not. >> What they want are IPv6 solutions. And they will all want different >> ones. > > (chair hat off) > > the comments i get from the people most is that, they have big trouble > picking which ngtrans mechanisms to pick (for instance, which one > to implement on their router, which one to deploy to their network). > so what we need to do is cut down number of deployment mechanisms, > and help people deploy network in actual use. > > as i said in IETF54 plenary, there's no need to deploy fancy IPv6 > network. keep it simple, stupid and robust. > > itojun > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Sat Sep 7 21:07:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20874 for ; Sat, 7 Sep 2002 21:07:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17nqX7-000EEr-00 for v6ops-data@psg.com; Sat, 07 Sep 2002 18:06:37 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17nqWz-000EEd-00 for v6ops@ops.ietf.org; Sat, 07 Sep 2002 18:06:29 -0700 Received: from kenawang.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA17629 for ; Sat, 7 Sep 2002 18:05:58 -0700 (PDT) Message-Id: <5.1.0.14.2.20020907150723.01c3ee30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Sep 2002 15:10:44 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Interim Meeting Registration CLOSED Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.7 required=5.0 tests=DATE_IN_PAST_03_06 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Registration for our interim meeting official closed on Tuesday. We are now completely full, so we will not be able to accept any last-minute registrations. I will update the attendee list on the web either tonight or tomorrow. So, if you have registered for the event, please check on Monday to make sure that you are on the final registration list. If not, please let me know as soon as possible. If you have registered for this event, but do not plan to attend, please let me know. If you will not use your space, I can make it available for a last minute person who would like to attend. Thank you, Margaret From owner-v6ops@ops.ietf.org Sun Sep 8 09:37:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06464 for ; Sun, 8 Sep 2002 09:37:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17o2EM-000G3p-00 for v6ops-data@psg.com; Sun, 08 Sep 2002 06:36:02 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17o2EJ-000G3e-00 for v6ops@ops.ietf.org; Sun, 08 Sep 2002 06:36:00 -0700 Received: from kenawang.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA00843 for ; Sun, 8 Sep 2002 06:35:28 -0700 (PDT) Message-Id: <5.1.0.14.2.20020908093051.029cf7b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 08 Sep 2002 09:33:30 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Interim Meeting Document Deadline Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, All documents for the v6ops interim meeting should be submitted to the internet-drafts depository by Wednesday (September 11th) to allow time for people to read them before the meeting. If there is any problem with this deadline, please let me know. Thanks, Margaret From owner-v6ops@ops.ietf.org Sun Sep 8 10:27:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07201 for ; Sun, 8 Sep 2002 10:27:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17o328-000I4U-00 for v6ops-data@psg.com; Sun, 08 Sep 2002 07:27:28 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17o322-000I3j-00 for v6ops@ops.ietf.org; Sun, 08 Sep 2002 07:27:22 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17o320-0000Sv-00; Sun, 08 Sep 2002 15:27:20 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17o320-0000Sq-00; Sun, 08 Sep 2002 15:27:20 +0100 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA18920; Sun, 8 Sep 2002 15:27:17 +0100 Message-ID: <3D7B5E4A.B40BCC96@hursley.ibm.com> Date: Sun, 08 Sep 2002 16:27:22 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Margaret Wasserman '" , "'v6ops@ops.ietf.org '" , "'ngtrans@sunroof.eng.sun.com '" Subject: Re: WG Review: IPv6 Operations (v6ops) References: <4DA6EA82906FD511BE2F00508BCF0538044F097A@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Hesham Soliman (EAB)" wrote: ... > Let me give you an example, if > 6to4 was written now, it would have suffered the same > destiny as ISATAP or BGP-based tunnelling. But because > it was written a long time ago, it is actually an > RFC. I'm not sure that 6to4 is a better solution > for inter-domain tunnelling than BGP-based tunnels. I think the historical fact is that the BGP-based tunneling proposal emerged later than 6to4 *because* 6to4 talks quite a bit about using BGP to make 6to4 work properly in an IDR context. And of course BGP will work with other methods of prefix assignment too. If it isn't in the v6ops charter, just develop it as an individual submission to the routing area. Brian From owner-v6ops@ops.ietf.org Sun Sep 8 13:14:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08872 for ; Sun, 8 Sep 2002 13:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17o5e0-000OgY-00 for v6ops-data@psg.com; Sun, 08 Sep 2002 10:14:44 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17o5dt-000Og6-00 for v6ops@ops.ietf.org; Sun, 08 Sep 2002 10:14:37 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g88HENA02789; Sun, 8 Sep 2002 20:14:24 +0300 Date: Sun, 8 Sep 2002 20:14:23 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Jun-ichiro itojun Hagino , Brian E Carpenter , "Fred L. Templin" , Subject: RE: WG Review: IPv6 Operations (v6ops) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B577@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Getting back to a few points. On Thu, 5 Sep 2002, Bound, Jim wrote: > > On Wed, 4 Sep 2002, Bound, Jim wrote: > > > I don't hear that from any user in that way. What I hear > > is there are > > > several good mechanisms they like and want to apply for different > > > reasons. > > > > For (over?) 95% of folks, they're just distraction. And what > > we want here > > is to get deployments going. There's little need for > > anything fancy if > > you don't require it. > > Deployment is going as best it can right now. See the NTT MSC > announcment that came out yesterday in Malaysia that is native IPv6. Native IPv6 is the proper and easy way. The press release does not elaborate on the tunneling mechanisms used though. And there's nothing to suggest v6-only (which was one of my "not of this world" arguments) there. > I > don't think ISATAP, DSTM, or Teredo are "fancy" but solid mechanisms > that work and for those moving at very fast pace. Some are more useful than others. I suppose they work, more or less, in more or less restricted topologies. I have doubts about the stability in the long term or when more people would start to use them. > The mechanisms I feel are imperative for wide deployment are as follows: > > Basic Tunnels > 6to4 Sure. > ISATAP May be useful in some scenarios (IMO, especially large enterprises with slow and sparse deployment or a lot of internal traffic). > Teredo Have you read the latest versions of the draft? It's a patch over a patch over a patch against (mis)features of NAT (not a fault of the author of course). It's just too complex to work reliably. I would rephrase this as: "Some reliable and simple mechanism to provide v6 behind a NAT" (Yes, it's possible -- but there are some engineering tradeoffs!) > DSTM I'm not yet convinced of this. Especially I have huge doubts about temporary address management scalability and robustness. > BIA (in some cases but caution is needed) May be useful for legacy apps, yes. > NAT-PT and SIIT should be last resort and not used unless there is no choice. Agreed. > What is happening is that unless vendors, operators, and some other > entities I won't mention begin to make money on IPv6 they are going to > stop momentum. Fortuneately we are seeing real purchase orders for IPv6 > and boxes and software be sold at significant levels to warrant > continued engineering and market investments. But those returns are not > from the large mass that will move with LCD mechanisms or the 80% that > will do as you say and want universal solutions (as Brian suggested). > > So the catch-22 is that the 20% of custom users is where we will all > make our money for the next 3 years. Then the masses will begin > conversion. So my issue is that to stop work on what we are doing that > will make money is crazy in the IETF. Maybe we need an advanced Ipv6 > transition area as Brian suggested but if that don't happen fast the > vendors and entities that want to deploy this 20% will not wait for the > IETF and do it out of band and create a storm of defacto standards for > IPv6 that will compete with the IETF in the market. They have no choice > and will not loose the mony waiting on 2 and 3 year discussions of how > to do transition or settle for universal compromised solutions. But are those 20% of users such that they *need* a "custom" transition mechanism? Why not e.g. consulting them how to build their network using current mechanisms? > > I don't think all of these non-basic, complex, fringe(?) > > mechanisms should > > be discarded -- quite the contrary. But this is probably(?) > > not the right > > place. > > I am not sure yet. Randy Bush has been saying IPv6 is here as operator > and I agree. How IPv6 deploy is still TBD. Why should not this true 20% > deployment sector recieve the work from v6ops effort? I think not doing > it is not wise. Randy Bush has a network/ISP operator background AFAIK. Deploying IPv6 there is a much more simple task than deploying it properly in organizations. There's much more to 'IPv6 is here' than having it enabled on dual-stack routers. > > I could say probably over 99% of folks doing this are not living in > > today's world. > > This is simply not true I hope my above mail helps change your mind on > this statement above as its as far as I can take to convince you and > others. See comment above, I don't think v6-only is really here yet. > > > > > IPv4 just isn't ready to be "as-needed" at the moment, or > > you're probably > > using it in very simple ways (e.g. www browsing only which works quite > > well with NAT too :-). It's IMO very questionable to approach IPv4 > > needs with an "ad-hoc" ways when clearly the requirements for > > IPv4 are > > not, in reality, ad-hoc. > > Ad hoc means the use of IPv4 is dicouraged as a policy and used only > when necessary. So maybe adhoc was wrong term on my part. And if it's necessary for a node to use it, 10, 100, 1000 times a day? Is Ad-hoc really the best way to go? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sun Sep 8 15:11:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09909 for ; Sun, 8 Sep 2002 15:11:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17o7UI-0003Qa-00 for v6ops-data@psg.com; Sun, 08 Sep 2002 12:12:50 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17o7UF-0003QO-00 for v6ops@ops.ietf.org; Sun, 08 Sep 2002 12:12:47 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g88JCdU29583; Sun, 8 Sep 2002 21:12:39 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA10436; Sun, 8 Sep 2002 21:12:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g88JCY6o071965; Sun, 8 Sep 2002 21:12:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209081912.g88JCY6o071965@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haberman cc: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) In-reply-to: Your message of Thu, 05 Sep 2002 18:02:53 EDT. <3D77D48D.71ED1A15@nc.rr.com> Date: Sun, 08 Sep 2002 21:12:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > 1) network (ISP/core) transition. Folks who feel stuff like IGP or BGP > tunneling is really needed etc. Is this really the case? The large operators I have talked to don't want any transition tools in their core. They see 6to4, ISATAP, NAT-PT, various tunneling mechanisms, etc. as a leaf network solution. Their core is native v6. => this is not true for cores using MPLS where some hacks are used for IPv6 support (aka 6PE, etc): you can't say this is native v6... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sun Sep 8 18:04:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11107 for ; Sun, 8 Sep 2002 18:04:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oABL-000AjI-00 for v6ops-data@psg.com; Sun, 08 Sep 2002 15:05:27 -0700 Received: from smtp2.southeast.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #1) id 17oABF-000AhI-00 for v6ops@ops.ietf.org; Sun, 08 Sep 2002 15:05:22 -0700 Received: from mail7.nc.rr.com (fe7 [24.93.67.54]) by smtp2.southeast.rr.com (8.12.5/8.12.2) with ESMTP id g88M5mtw018184; Sun, 8 Sep 2002 18:05:50 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sun, 8 Sep 2002 18:05:10 -0400 Message-ID: <3D7BC8F3.5A092A90@nc.rr.com> Date: Sun, 08 Sep 2002 18:02:27 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) References: <200209081912.g88JCY6o071965@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=RCVD_IN_MULTIHOP_DSBL,X_RCVD_IN_UNCONFIRMED_DSBL, FUDGE_MULTIHOP_RELAY version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis, Francis Dupont wrote: > > In your previous mail you wrote: > > > 1) network (ISP/core) transition. Folks who feel stuff like IGP or BGP > > tunneling is really needed etc. > > Is this really the case? The large operators I have talked to don't > want any transition tools in their core. They see 6to4, ISATAP, NAT-PT, > various tunneling mechanisms, etc. as a leaf network solution. Their > core is native v6. > > => this is not true for cores using MPLS where some hacks are used > for IPv6 support (aka 6PE, etc): you can't say this is native v6... Agreed. And I never mentioned MPLS. The operators I am talking about are using BGP, IS-IS, and OSPF to route v6 natively. Some of these operators have MPLS in parts of their network. But, they are not utilizing the MPLS portion for v6 yet. Brian From owner-v6ops@ops.ietf.org Sun Sep 8 20:16:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11945 for ; Sun, 8 Sep 2002 20:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oCFW-000Gso-00 for v6ops-data@psg.com; Sun, 08 Sep 2002 17:17:54 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17oCFS-000Gsc-00 for v6ops@ops.ietf.org; Sun, 08 Sep 2002 17:17:50 -0700 Received: from kenawang.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA19655 for ; Sun, 8 Sep 2002 17:17:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20020908201339.06374620@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 08 Sep 2002 20:18:35 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: It's a WG! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=1.2 required=5.0 tests=PLING,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, Our WG was chartered by the IESG last Thursday. The official announcement will probably go to the ietf-announce list on Monday. So, we are now officially a working group. I have appended the approved charter below. Thanks to all who provided input during the charter process! Margaret IPv6 Operations (v6ops) Chair(s): Jun-Ichiro itojun Hagino Margaret Wasserman Operations and Management Area Director(s): Randy Bush Bert Wijnen Operations and Management Area Advisor: Randy Bush Mailing List: General Discussion: v6ops@ops.ietf.org To Subscribe: Send mail to majordomo@ops.ietf.org, with "subscribe v6ops" (no quotes) in the body of the message. Archive: http://ops.ietf.org/lists/v6ops/ ftp://ops.ietf.org/pub/lists/v6ops.* Description of Working Group: The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring global addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides guidance for network operators on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. The v6ops working group will: (1) Solicit input from network operators and users to identify operational or security issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. This includes identifying standards work that is needed in other IETF WGs or areas and working with those groups/areas to begin appropriate work. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. For example, important pieces of the Internet infrastructure such as DNS, SMTP and SIP have specific operational issues when they operate in a shared IPv4/IPv6 network. The v6ops WG will cooperate with the relevant areas and WGs to document those issues, and find protocol or operational solutions to those problems. (2) Provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. (3) Publish Informational RFCs that help application developers (within and outside the IETF) understand how to develop IP version-independent applications. Work with the Applications area, and other areas, to ensure that these documents answer the real-world concerns of application developers. This includes helping to identify IPv4 dependencies in existing IETF application protocols and working with other areas and/or groups within the IETF to resolve them. (4) Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. (5) Publish Informational or BCP RFCs that provide viable solutions for deploying IPv6 within common network environments, such as ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. (6) Assume responsibility for advancing the basic IPv6 transition mechanism RFCs along the standards track, if their applicability to common deployment solutions is demonstrated in (5) above: Transition Mechanisms (RFC 2893) SIIT (RFC 2765) NAT-PT (RFC 2766) 6to4 (RFC 3056 & 3068) This includes updating these mechanisms, as needed, to resolve problems. In some cases, these mechanisms may be deprecated (i.e. moved to Historic), if they are not found to be applicable to the deployment solutions described in (5) or if serious flaws are encountered that lead us to recommend against their use. (7) Identify open operational or security issues with the deployment solutions documented in (5) and fully document those open issues in Internet-Drafts or Informational RFCs. Work to find workarounds or solutions to basic, IP-level deployment issues that can be solved using widely-applicable transition mechanisms, such as dual-stack, tunneling or translation. If the satisfactory resolution of a deployment issue requires the standardization of a new, widely-applicable transition mechanism that does not properly fit into any other IETF WG or area, the v6ops WG will standardize a transition mechanism to meet that need. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops group will provide input to those areas/groups, as needed, and cooperate with those areas/groups in developing and reviewing solutions to IPv6 operational and deployment problems. Goals and Milestones: OCT 02 Publish Cellular Deployment Scenarios as a WG I-D OCT 02 Publish Unmanaged Network Deployment Scenarios as a WG I-D OCT 02 Publish ISP Deployment Scenarios as a WG I-D OCT 02 Publish Cellular Deployment Solutions as a WG I-D OCT 02 Publish Survey of IPv4 Addresses in IETF Standards as WG I-D DEC 02 Submit Transition Mechanisms to IESG for DS DEC 02 Publish Unmanaged Network Deployment Solutions as a WG I-D DEC 02 Publish Enterprise Deployment Scenarios as a WG I-D DEC 02 Publish ISP Deployment Solutions as a WG I-D DEC 02 Submit Cellular Deployment Scenarios to IESG for Info DEC 02 Submit Cellular Deployment Solutions to IESG for BCP FEB 03 Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info APR 03 Publish Enterprise Deployment Solutions as a WG I-D APR 03 Submit Unmanaged Network Deployment Scenarios to IESG for Info APR 03 Submit Unmanaged Network Deployment Solutions to IESG for BCP APR 03 Submit ISP Deployment Scenarios to IESG for Info APR 03 Submit ISP Deployment Solutions to IESG for BCP AUG 03 Submit Enterprise Deployment Scenarios to IESG for Info AUG 03 Submit Enterprise Deployment Solutions to IESG for BCP Internet-Drafts: Request For Comments: Network Address Translation-Protocol Translation (NAT-PT) (RFC 2766) (49836 bytes) Stateless IP/ICMP Translation Algorithm (SIIT) (RFC 2765) (59465 bytes) Transition Mechanisms for IPv6 Hosts and Routers (RFC 2893) (62731 bytes) Connection of IPv6 Domains via IPv4 Clouds (RFC 3056) (54902 bytes) An anycast prefix for 6to4 relay routers (RFC 3068) (20120 bytes) From owner-v6ops@ops.ietf.org Mon Sep 9 03:28:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26103 for ; Mon, 9 Sep 2002 03:28:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oIxp-000Bj5-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 00:28:05 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17oIxl-000Biu-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 00:28:02 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17oIxj-0002Ib-00; Mon, 09 Sep 2002 08:27:59 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17oIxj-0002IW-00; Mon, 09 Sep 2002 08:27:59 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA23250; Mon, 9 Sep 2002 08:27:56 +0100 Message-ID: <3D7C4D8F.C960C618@hursley.ibm.com> Date: Mon, 09 Sep 2002 09:28:15 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Margaret Wasserman CC: v6ops@ops.ietf.org Subject: Re: It's a WG! References: <5.1.0.14.2.20020908201339.06374620@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=PLING version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I noted earlier, some 6to4 related drafts need to be transferred over: > There's work in progress on 6to4 DNS, 6to4 multicast, > and 6to4 security that needs to be picked up... > draft-ietf-ngtrans-6to4-dns-01.txt (expired, but something's needed) > draft-ietf-ngtrans-6to4-multicast-01.txt > draft-savola-ngtrans-6to4-security-01.txt (no consensus yet, but needed) Brian From owner-v6ops@ops.ietf.org Mon Sep 9 08:45:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29659 for ; Mon, 9 Sep 2002 08:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oNvX-000NC2-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 05:46:03 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17oNvT-000NBY-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 05:45:59 -0700 Received: from kenawang.windriver.com ([147.11.233.14]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA13245; Mon, 9 Sep 2002 05:45:28 -0700 (PDT) Message-Id: <5.1.0.14.2.20020909083536.06cd2150@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Sep 2002 08:44:30 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: It's a WG! Cc: v6ops@ops.ietf.org In-Reply-To: <3D7C4D8F.C960C618@hursley.ibm.com> References: <5.1.0.14.2.20020908201339.06374620@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,PLING version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Brian, Thanks for the reminder. I must have forgotten to reply to this the first time... To accept any draft as a v6ops WG work item will be a two-step process. First, itojun and I need to decide whether the draft fits into the v6ops charter. If so, the WG will then need to decide whether or not to accept the draft as a work item. I am sure that several ngtrans drafts (possibly including the ones you've listed) will be accepted as v6ops WG items. But, it may take a week or two to go through the process. Margaret At 03:28 AM 9/9/02, Brian E Carpenter wrote: >As I noted earlier, some 6to4 related drafts need to be >transferred over: > >> There's work in progress on 6to4 DNS, 6to4 multicast, >> and 6to4 security that needs to be picked up... > >> draft-ietf-ngtrans-6to4-dns-01.txt (expired, but something's needed) >> draft-ietf-ngtrans-6to4-multicast-01.txt >> draft-savola-ngtrans-6to4-security-01.txt (no consensus yet, but needed) > > Brian From owner-v6ops@ops.ietf.org Mon Sep 9 09:05:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00214 for ; Mon, 9 Sep 2002 09:05:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oOG5-000Nz8-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 06:07:17 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17oOFt-000Nyk-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 06:07:05 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g89D6aU06697; Mon, 9 Sep 2002 15:06:36 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA04902; Mon, 9 Sep 2002 15:06:36 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g89D6X6o073935; Mon, 9 Sep 2002 15:06:34 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209091306.g89D6X6o073935@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: "Bound, Jim" , Jun-ichiro itojun Hagino , Brian E Carpenter , "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) In-reply-to: Your message of Sun, 08 Sep 2002 20:14:23 +0300. Date: Mon, 09 Sep 2002 15:06:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > Basic Tunnels > 6to4 Sure. => I am not convinced by 6to4. For instance by the 6to4-relay concept. > DSTM I'm not yet convinced of this. Especially I have huge doubts about temporary address management scalability and robustness. => this address management is exactly the current DHCPv4 address management (I agree this is not a real answer :-). Randy Bush has a network/ISP operator background AFAIK. Deploying IPv6 there is a much more simple task than deploying it properly in organizations. => the problem for an ISP is not the task, it is the business... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Mon Sep 9 16:44:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15852 for ; Mon, 9 Sep 2002 16:44:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oVOO-000HGQ-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 13:44:20 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17oVOG-000HG7-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 13:44:12 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g89Khjo15273; Mon, 9 Sep 2002 23:43:49 +0300 Date: Mon, 9 Sep 2002 23:43:45 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: "Bound, Jim" , Jun-ichiro itojun Hagino , Brian E Carpenter , "Fred L. Templin" , Subject: Re: WG Review: IPv6 Operations (v6ops) In-Reply-To: <200209091306.g89D6X6o073935@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 9 Sep 2002, Francis Dupont wrote: > In your previous mail you wrote: > > > Basic Tunnels > > 6to4 > > Sure. > > => I am not convinced by 6to4. For instance by the 6to4-relay concept. 6to4 relays cause some rather interesting problems, especially relating to quality of service (too few of them at the moment, leading to huge delays connecting to 6to4 nodes from some areas). > > DSTM > > I'm not yet convinced of this. Especially I have huge doubts about > temporary address management scalability and robustness. > > => this address management is exactly the current DHCPv4 address management > (I agree this is not a real answer :-). No it *definitely* isn't, or I've misunderstood the intent. What has been proposed is something like 'when application requests and address, get it from somewhere, after application exists, return it'. That's very far from DHCPv4. Add the ports option to the stew and you have a mess.. Running DHCPv4 over DSTM (with reasonable address lifetimes etc.) would sound much better than currently proposed. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Sep 9 17:14:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16897 for ; Mon, 9 Sep 2002 17:14:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oVsX-000Imi-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 14:15:29 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17oVsU-000Ikp-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 14:15:26 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8EB5818F9 for ; Mon, 9 Sep 2002 17:14:54 -0400 (EDT) Date: Mon, 09 Sep 2002 17:14:54 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) In-Reply-To: References: <200209091306.g89D6X6o073935@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020909211454.8EB5818F9@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Mon, 9 Sep 2002 23:43:45 +0300 (EEST), Pekka Savola wrote: > > 6to4 relays cause some rather interesting problems, especially relating to > quality of service (too few of them at the moment, leading to huge > delays connecting to 6to4 nodes from some areas). Once upon a time we used routing protocols to handle problems that were at least superficially similar to this. > Running DHCPv4 over DSTM (with reasonable address lifetimes etc.) would > sound much better than currently proposed. Damn, that's so simple even ordinary users might understand it :). From owner-v6ops@ops.ietf.org Mon Sep 9 17:58:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17675 for ; Mon, 9 Sep 2002 17:58:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oWXw-000KoJ-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 14:58:16 -0700 Received: from evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net ([4.65.28.11] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17oWXn-000KmR-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 14:58:07 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Sep 2002 14:58:05 -0700 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , "'Fred L. Templin'" Cc: Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Mon, 9 Sep 2002 14:56:44 -0700 Message-ID: <030d01c2584b$c9f4cb90$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D75E7C1.E334A50E@hursley.ibm.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17675 Brian E Carpenter wrote: > "Fred L. Templin" wrote: > ... > > Summary - the wording in sections (1) and (7) seems to mandate > > lowest-common-denominator solutions and ignore solutions > that provide > > a better fit. > > It's hard to avoid special pleading (since the transition > solution with my name on it is in the list), but I do think > that there is a strong argument for concentrating on LCD > solutions for the first wave. If you look at the sequence of work done in ngtrans you will see that it started with a strong focus on LCD approaches, but moved on to address the reality that one size does not fit all. Debates about what is useful or necessary will be useless until we complete the environment description documents. Once we get a set of problem statements in front of the whole group it will be easier to see from the diverse requirements that there is no LCD. It is a nice fantasy to believe that a core-out approach will be simple and easy, but when the deployment hits CPE that can't be replaced or upgraded (or in the case of cable modems there is not even a plan for upgrading the fundemental docsis standard to consider IPv6), whats next? The charter of the new WG will need to evolve once the current set of documents are written, as they will form the real problem statement. In their absence, the charter is limited to the viewpoint of core network providers and the operational challenges in getting that environment running. > > We might contemplate a separate IETF activity for advanced > transition solutions. That is unlikely since the group that would look at those is being shut down. Tony From owner-v6ops@ops.ietf.org Mon Sep 9 23:17:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23604 for ; Mon, 9 Sep 2002 23:17:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17obXx-000BJx-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 20:18:37 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17obXp-000BJg-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 20:18:29 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 323633498; Mon, 9 Sep 2002 23:18:28 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Sep 2002 23:18:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG management (was Re: WG Review: IPv6 Operations (v6ops) ) Date: Mon, 9 Sep 2002 23:18:27 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE916F@tayexc13.americas.cpqcorp.net> Thread-Topic: WG management (was Re: WG Review: IPv6 Operations (v6ops) ) Thread-Index: AcJV0o6aQje9DNG4TbOcfSgfvazZQwCpaDOw From: "Bound, Jim" To: "Thomas Narten" Cc: X-OriginalArrivalTime: 10 Sep 2002 03:18:28.0089 (UTC) FILETIME=[BB43AE90:01C25878] X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23604 The AD making sure the process works is fine and if thats the view of silence vs no-silence thats fine. But my fear is that whether a working group is on board or not on board could be a "subjective" call and that makes me nervous ok. I am fine when objectivity is used. I agree with you it is important to make sure things are baked. But driving for perfection is absurd and then the its not baked but overdone. Getting it baked but not overdone is a fine line. We will never ever produce a spec that cannot be made better or an architecture. The trick is to move it along so it can be implemented and then see if the market will use it. We do that often with PS. The bar at this point for PS is to high and wrong. /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Friday, September 06, 2002 2:20 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: WG management (was Re: WG Review: IPv6 Operations (v6ops) ) > > > This is a bit off topic, but I want to respond anyway. > > "Bound, Jim" writes: > > > Don't get me wrong I would love to see the IETF move faster, better, > > and lately in a more fair process. And one thing that would really > > help is something I said to Scott Bradner (one of the area directors > > I keep voting for fyi and him an allison run one of the most > > efficient areas in the IETF and why I have hopes for RDMA in the > > IETF) at a plenary about 2 years ago is: "It is imperative that > > "consistency" be used across the IETF. > > I am in support of consistency, where it make sense. > > > For example lets take the silence vs no silence for consensus in a > > working group. One does one thing the other does the other. > > There are good reasons for this. In some WGs, the WG never says > (hardly) anything, even when something seems like a bad or even > dangerous idea. The WG chairs (and ADs) are supposed to ensure that > specs are baked and won't cause problems when deployed. So, asking for > explicit support is a useful tool to force people to come out and say > "I have looked at this, and I think it is good stuff". One doesn't > always need this. It depends on the WG and the specific document at > hand. I (as an AD) have asked to see explicit WG support when I have > concerns about a document and it seems like nobody is actually looking > at the document and it seems like a document is moving forward only > because nobody seems to be objecting. If no one is willing to speak up > on behalf of a document (other than the authors) that is often cause > for concern... > > > For processes of governing I think this should be consistent whether > > I am working on IPv6 transition or Routing or SCTP. It is not > > today. Also Area Directors need to be more like "managers" than > > "engineers". And leave technical work to us in the working group > > and the chairs. > > ADs are (and need to be) both. ADs certainly believe they are > obligated to ensure that specs are baked and complete from a technical > perspective. This is not just a managerial function, it requires being > able to do technical assessments and reviews. The motivation comes > straight out of RFC 2026. > > If the ADs don't intervene when there are technical problems with a > document, who will? > > Thomas > From owner-v6ops@ops.ietf.org Mon Sep 9 23:59:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24247 for ; Mon, 9 Sep 2002 23:59:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ocCJ-000DfH-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 21:00:19 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17ocCF-000Df6-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 21:00:15 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 294EE8BBC; Tue, 10 Sep 2002 00:00:13 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 00:00:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Tue, 10 Sep 2002 00:00:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9178@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJXWzENeN1fZfFtTeiDgJaDB2n13ABIc6xQ From: "Bound, Jim" To: "Pekka Savola" Cc: "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 10 Sep 2002 04:00:12.0870 (UTC) FILETIME=[903AEE60:01C2587E] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA24247 Hi Pekka, > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Sunday, September 08, 2002 1:14 PM > To: Bound, Jim > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin; > v6ops@ops.ietf.org > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > Hello, > > Getting back to a few points. > > On Thu, 5 Sep 2002, Bound, Jim wrote: > > > On Wed, 4 Sep 2002, Bound, Jim wrote: > > > > I don't hear that from any user in that way. What I hear > > > is there are > > > > several good mechanisms they like and want to apply for > different > > > > reasons. > > > > > > For (over?) 95% of folks, they're just distraction. And what > > > we want here > > > is to get deployments going. There's little need for > > > anything fancy if > > > you don't require it. > > > > Deployment is going as best it can right now. See the NTT MSC > > announcment that came out yesterday in Malaysia that is > native IPv6. > > Native IPv6 is the proper and easy way. The press release does not > elaborate on the tunneling mechanisms used though. And > there's nothing to > suggest v6-only (which was one of my "not of this world" > arguments) there. Nothing to suggest it is not v6 only and my impression is that v6 only will be part of the solution. > > > I > > don't think ISATAP, DSTM, or Teredo are "fancy" but solid mechanisms > > that work and for those moving at very fast pace. > > Some are more useful than others. I suppose they work, more > or less, in > more or less restricted topologies. I have doubts about the > stability in > the long term or when more people would start to use them. > > > The mechanisms I feel are imperative for wide deployment > are as follows: > > > > Basic Tunnels > > 6to4 > > Sure. > > > ISATAP > > May be useful in some scenarios (IMO, especially large > enterprises with > slow and sparse deployment or a lot of internal traffic). I agree and to jump start IPv6. > > > Teredo > > Have you read the latest versions of the draft? It's a patch > over a patch > over a patch against (mis)features of NAT (not a fault of the > author of > course). It's just too complex to work reliably. > > I would rephrase this as: > > "Some reliable and simple mechanism to provide v6 behind a NAT" Yes I have read it and still state what I state. It is a solution to many customer problems who will adopt v6. > > (Yes, it's possible -- but there are some engineering tradeoffs!) > > > DSTM > > I'm not yet convinced of this. Especially I have huge doubts about > temporary address management scalability and robustness. There is not other mechanisms that treats IPv4 as DSTM does. Our job here is not to decide if temp addr mgmt is scalable the market will decide that. Our job here is to decide if the DSTM spec is functional. I could argue a lot of what we work on here is not scalable. That is not our job. The market and vendors won't use it if its not scalable. As far as robust? What does that mean? Why would you call 6to4 robust? And define robust. What is robust to you may not be robust to my customers? And what I call robust may not be robust to your customers? Robust is to subjective we cannot state specs are robust or not in the IETF. > > > BIA (in some cases but caution is needed) > > May be useful for legacy apps, yes. > > > NAT-PT and SIIT should be last resort and not used unless > there is no choice. > > Agreed. > > > What is happening is that unless vendors, operators, and some other > > entities I won't mention begin to make money on IPv6 they > are going to > > stop momentum. Fortuneately we are seeing real purchase > orders for IPv6 > > and boxes and software be sold at significant levels to warrant > > continued engineering and market investments. But those > returns are not > > from the large mass that will move with LCD mechanisms or > the 80% that > > will do as you say and want universal solutions (as Brian > suggested). > > > > So the catch-22 is that the 20% of custom users is where we will all > > make our money for the next 3 years. Then the masses will begin > > conversion. So my issue is that to stop work on what we > are doing that > > will make money is crazy in the IETF. Maybe we need an > advanced Ipv6 > > transition area as Brian suggested but if that don't happen fast the > > vendors and entities that want to deploy this 20% will not > wait for the > > IETF and do it out of band and create a storm of defacto > standards for > > IPv6 that will compete with the IETF in the market. They > have no choice > > and will not loose the mony waiting on 2 and 3 year > discussions of how > > to do transition or settle for universal compromised solutions. > > But are those 20% of users such that they *need* a "custom" > transition > mechanism? Why not e.g. consulting them how to build their > network using > current mechanisms? See we don't agree. DSTM is a current mechanism but now its been stopped by the IETF. It is being deployed and specifically for Mobile IPv6. See the market is not going to wait for the IETF anymore in several spaces or 3G for that matter. DSTM permits a Mobile IPv6 node that is doing mostly IPv6 to get an IPv4 address if it needs one. Users with IPv4 address space can use DSTM to leverage their IPv4 address space to deploy IPv6. > > > > I don't think all of these non-basic, complex, fringe(?) > > > mechanisms should > > > be discarded -- quite the contrary. But this is probably(?) > > > not the right > > > place. > > > > I am not sure yet. Randy Bush has been saying IPv6 is here > as operator > > and I agree. How IPv6 deploy is still TBD. Why should not > this true 20% > > deployment sector recieve the work from v6ops effort? I > think not doing > > it is not wise. > > Randy Bush has a network/ISP operator background AFAIK. > Deploying IPv6 > there is a much more simple task than deploying it properly in > organizations. > > There's much more to 'IPv6 is here' than having it enabled on > dual-stack > routers. > > > > I could say probably over 99% of folks doing this are not > living in > > > today's world. > > > > This is simply not true I hope my above mail helps change > your mind on > > this statement above as its as far as I can take to convince you and > > others. > > See comment above, I don't think v6-only is really here yet. We will have to agree to disagree. Thats ok it is two distinct views of the market I guess. As a product engineer I know its working for my work and making money. > > > > > > > > IPv4 just isn't ready to be "as-needed" at the moment, or > > > you're probably > > > using it in very simple ways (e.g. www browsing only > which works quite > > > well with NAT too :-). It's IMO very questionable to > approach IPv4 > > > needs with an "ad-hoc" ways when clearly the requirements for > > > IPv4 are > > > not, in reality, ad-hoc. > > > > Ad hoc means the use of IPv4 is dicouraged as a policy and used only > > when necessary. So maybe adhoc was wrong term on my part. > > And if it's necessary for a node to use it, 10, 100, 1000 > times a day? Is > Ad-hoc really the best way to go? OK. But you have not provided one technical argument against DSTM nor has anyone else since the last draft-08 because the working group did their job and the authors did their job with updates. All your arguments are a "gut" feeling against DSTM and "your OPINION" of how IPv6 will be deployed. Hardly an argument to not move forward with DSTM. This is not a club or social group it is the Internet Engineering Task Force and DSTM performed that process and is being used as all the mechanisms above. Just because you don't like it is not a fair way to stop it from being move forward. In fact if that happens it proves all I am beginning to dislike about the IETF processes of late. regards, /jim > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Tue Sep 10 00:07:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24514 for ; Tue, 10 Sep 2002 00:07:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ocKy-000EB2-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 21:09:16 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17ocKt-000EAm-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 21:09:12 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2C44E4213; Tue, 10 Sep 2002 00:09:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 00:09:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Tue, 10 Sep 2002 00:09:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B57D@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJYQaINdghEIcriTHGODpYoSbuTaAAPQRaQ From: "Bound, Jim" To: "Pekka Savola" , "Francis Dupont" Cc: "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 10 Sep 2002 04:09:11.0086 (UTC) FILETIME=[D1082CE0:01C2587F] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA24514 Hi Pekka (again), > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, September 09, 2002 4:44 PM > To: Francis Dupont > Cc: Bound, Jim; Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. > Templin; v6ops@ops.ietf.org > Subject: Re: WG Review: IPv6 Operations (v6ops) > > > On Mon, 9 Sep 2002, Francis Dupont wrote: > > In your previous mail you wrote: > > > > > Basic Tunnels > > > 6to4 > > > > Sure. > > > > => I am not convinced by 6to4. For instance by the > 6to4-relay concept. > > 6to4 relays cause some rather interesting problems, > especially relating to > quality of service (too few of them at the moment, leading to huge > delays connecting to 6to4 nodes from some areas). I am not going to bash 6to4. It has its place and there are places it should not be used. I believe 6to4 will do what it technically states it will do and worked very hard on that draft as working group reviewer and worker. And have deployed that too with customers. But for many of my customers it is a non-starter. It is not proper for me to even discuss that it is not the point. 6to4 went through a technical process not a philosophical process. This is NOT the Internet Philosophical Task Force. Though I think some would love it to be and really believe they control the Internet. Not Not Not the market and the almighty buck, dollar, euro, whatever controls the Internet. Not us here. We simply build the specs and a suggested architecture. But egoes seem to get the best of processes at time. > > > > DSTM > > > > I'm not yet convinced of this. Especially I have huge > doubts about > > temporary address management scalability and robustness. > > > > => this address management is exactly the current DHCPv4 > address management > > (I agree this is not a real answer :-). > > No it *definitely* isn't, or I've misunderstood the intent. > What has been > proposed is something like 'when application requests and > address, get it > from somewhere, after application exists, return it'. That's very far > from DHCPv4. Add the ports option to the stew and you have a mess.. > > Running DHCPv4 over DSTM (with reasonable address lifetimes > etc.) would > sound much better than currently proposed. Read the DSTM Assumptions in the Spec. This just frustrates me to no end. The DSTM assumption is as follows. "THE USER DOES NOT WANT ANYMORE IPv4 PROLIFERATION and forcing IPv6 deployment native". They do not want to begin their new IPv6 networks or update their networks with DHCPv4. And to answer Rob's question. Yes I know many customers who do understand the DSTM assumptions. But one DSTM deployment is using DHCPv4 this way but only because DHCPv6 was not done. The prime systems integrator just delivered a dhcpv6 solution to resolve that. Again this is a trial network but it will be the production network of tommorrow. Have you read the latest DSTM spec (like you asked me about Teredo)? regards, /jim > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From owner-v6ops@ops.ietf.org Tue Sep 10 00:09:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24547 for ; Tue, 10 Sep 2002 00:09:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ocMx-000EHw-00 for v6ops-data@psg.com; Mon, 09 Sep 2002 21:11:19 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17ocMo-000EHe-00 for v6ops@ops.ietf.org; Mon, 09 Sep 2002 21:11:10 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7FB2B42E2; Tue, 10 Sep 2002 00:11:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 00:11:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Tue, 10 Sep 2002 00:11:09 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE917A@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJXWzENeN1fZfFtTeiDgJaDB2n13ABIc6xQAADBb/A= From: "Bound, Jim" To: "Bound, Jim" , "Pekka Savola" Cc: "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 10 Sep 2002 04:11:09.0429 (UTC) FILETIME=[1791E250:01C25880] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA24547 also DSTM will not stop in the market that I gurantee. /jim > -----Original Message----- > From: Bound, Jim > Sent: Tuesday, September 10, 2002 12:00 AM > To: Pekka Savola > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin; > v6ops@ops.ietf.org > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > Hi Pekka, > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Sunday, September 08, 2002 1:14 PM > > To: Bound, Jim > > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin; > > v6ops@ops.ietf.org > > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > > > > Hello, > > > > Getting back to a few points. > > > > On Thu, 5 Sep 2002, Bound, Jim wrote: > > > > On Wed, 4 Sep 2002, Bound, Jim wrote: > > > > > I don't hear that from any user in that way. What I hear > > > > is there are > > > > > several good mechanisms they like and want to apply for > > different > > > > > reasons. > > > > > > > > For (over?) 95% of folks, they're just distraction. And what > > > > we want here > > > > is to get deployments going. There's little need for > > > > anything fancy if > > > > you don't require it. > > > > > > Deployment is going as best it can right now. See the NTT MSC > > > announcment that came out yesterday in Malaysia that is > > native IPv6. > > > > Native IPv6 is the proper and easy way. The press release does not > > elaborate on the tunneling mechanisms used though. And > > there's nothing to > > suggest v6-only (which was one of my "not of this world" > > arguments) there. > > Nothing to suggest it is not v6 only and my impression is > that v6 only will be part of the solution. > > > > > > I > > > don't think ISATAP, DSTM, or Teredo are "fancy" but solid > mechanisms > > > that work and for those moving at very fast pace. > > > > Some are more useful than others. I suppose they work, more > > or less, in > > more or less restricted topologies. I have doubts about the > > stability in > > the long term or when more people would start to use them. > > > > > The mechanisms I feel are imperative for wide deployment > > are as follows: > > > > > > Basic Tunnels > > > 6to4 > > > > Sure. > > > > > ISATAP > > > > May be useful in some scenarios (IMO, especially large > > enterprises with > > slow and sparse deployment or a lot of internal traffic). > > I agree and to jump start IPv6. > > > > > > Teredo > > > > Have you read the latest versions of the draft? It's a patch > > over a patch > > over a patch against (mis)features of NAT (not a fault of the > > author of > > course). It's just too complex to work reliably. > > > > I would rephrase this as: > > > > "Some reliable and simple mechanism to provide v6 behind a NAT" > > Yes I have read it and still state what I state. It is a > solution to many customer problems who will adopt v6. > > > > > (Yes, it's possible -- but there are some engineering tradeoffs!) > > > > > DSTM > > > > I'm not yet convinced of this. Especially I have huge doubts about > > temporary address management scalability and robustness. > > There is not other mechanisms that treats IPv4 as DSTM does. > Our job here is not to decide if temp addr mgmt is scalable > the market will decide that. Our job here is to decide if > the DSTM spec is functional. I could argue a lot of what we > work on here is not scalable. That is not our job. The > market and vendors won't use it if its not scalable. > > As far as robust? What does that mean? Why would you call > 6to4 robust? > And define robust. What is robust to you may not be robust > to my customers? > And what I call robust may not be robust to your customers? > > Robust is to subjective we cannot state specs are robust or > not in the IETF. > > > > > > BIA (in some cases but caution is needed) > > > > May be useful for legacy apps, yes. > > > > > NAT-PT and SIIT should be last resort and not used unless > > there is no choice. > > > > Agreed. > > > > > What is happening is that unless vendors, operators, and > some other > > > entities I won't mention begin to make money on IPv6 they > > are going to > > > stop momentum. Fortuneately we are seeing real purchase > > orders for IPv6 > > > and boxes and software be sold at significant levels to warrant > > > continued engineering and market investments. But those > > returns are not > > > from the large mass that will move with LCD mechanisms or > > the 80% that > > > will do as you say and want universal solutions (as Brian > > suggested). > > > > > > So the catch-22 is that the 20% of custom users is where > we will all > > > make our money for the next 3 years. Then the masses will begin > > > conversion. So my issue is that to stop work on what we > > are doing that > > > will make money is crazy in the IETF. Maybe we need an > > advanced Ipv6 > > > transition area as Brian suggested but if that don't > happen fast the > > > vendors and entities that want to deploy this 20% will not > > wait for the > > > IETF and do it out of band and create a storm of defacto > > standards for > > > IPv6 that will compete with the IETF in the market. They > > have no choice > > > and will not loose the mony waiting on 2 and 3 year > > discussions of how > > > to do transition or settle for universal compromised solutions. > > > > But are those 20% of users such that they *need* a "custom" > > transition > > mechanism? Why not e.g. consulting them how to build their > > network using > > current mechanisms? > > See we don't agree. DSTM is a current mechanism but now its > been stopped by the IETF. It is being deployed and > specifically for Mobile IPv6. See the market is not going to > wait for the IETF anymore in several spaces or 3G for that matter. > > DSTM permits a Mobile IPv6 node that is doing mostly IPv6 to > get an IPv4 address if it needs one. > > Users with IPv4 address space can use DSTM to leverage their > IPv4 address space to deploy IPv6. > > > > > > > I don't think all of these non-basic, complex, fringe(?) > > > > mechanisms should > > > > be discarded -- quite the contrary. But this is probably(?) > > > > not the right > > > > place. > > > > > > I am not sure yet. Randy Bush has been saying IPv6 is here > > as operator > > > and I agree. How IPv6 deploy is still TBD. Why should not > > this true 20% > > > deployment sector recieve the work from v6ops effort? I > > think not doing > > > it is not wise. > > > > Randy Bush has a network/ISP operator background AFAIK. > > Deploying IPv6 > > there is a much more simple task than deploying it properly in > > organizations. > > > > There's much more to 'IPv6 is here' than having it enabled on > > dual-stack > > routers. > > > > > > I could say probably over 99% of folks doing this are not > > living in > > > > today's world. > > > > > > This is simply not true I hope my above mail helps change > > your mind on > > > this statement above as its as far as I can take to > convince you and > > > others. > > > > See comment above, I don't think v6-only is really here yet. > > We will have to agree to disagree. Thats ok it is two > distinct views of the market I guess. As a product engineer > I know its working for my work and making money. > > > > > > > > > > > > IPv4 just isn't ready to be "as-needed" at the moment, or > > > > you're probably > > > > using it in very simple ways (e.g. www browsing only > > which works quite > > > > well with NAT too :-). It's IMO very questionable to > > approach IPv4 > > > > needs with an "ad-hoc" ways when clearly the requirements for > > > > IPv4 are > > > > not, in reality, ad-hoc. > > > > > > Ad hoc means the use of IPv4 is dicouraged as a policy > and used only > > > when necessary. So maybe adhoc was wrong term on my part. > > > > And if it's necessary for a node to use it, 10, 100, 1000 > > times a day? Is > > Ad-hoc really the best way to go? > > OK. But you have not provided one technical argument against > DSTM nor has anyone else since the last draft-08 because the > working group did their job and the authors did their job > with updates. > > All your arguments are a "gut" feeling against DSTM and "your > OPINION" of how IPv6 will be deployed. > > Hardly an argument to not move forward with DSTM. This is > not a club or social group it is the Internet Engineering > Task Force and DSTM performed that process and is being used > as all the mechanisms above. Just because you don't like it > is not a fair way to stop it from being move forward. In > fact if that happens it proves all I am beginning to dislike > about the IETF processes of late. > > regards, > /jim > > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > From owner-v6ops@ops.ietf.org Tue Sep 10 04:18:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07115 for ; Tue, 10 Sep 2002 04:18:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ogED-0001VE-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 01:18:33 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17ogEA-0001V0-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 01:18:30 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8A8I7820724; Tue, 10 Sep 2002 11:18:07 +0300 Date: Tue, 10 Sep 2002 11:18:07 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Francis Dupont , Jun-ichiro itojun Hagino , Brian E Carpenter , "Fred L. Templin" , Subject: RE: WG Review: IPv6 Operations (v6ops) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B57D@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 10 Sep 2002, Bound, Jim wrote: > > No it *definitely* isn't, or I've misunderstood the intent. What has > > been proposed is something like 'when application requests and > > address, get it from somewhere, after application exists, return it'. > > That's very far from DHCPv4. Add the ports option to the stew and you > > have a mess.. > > > > Running DHCPv4 over DSTM (with reasonable address lifetimes etc.) > > would sound much better than currently proposed. > > Read the DSTM Assumptions in the Spec. This just frustrates me to no > end. The DSTM assumption is as follows. "THE USER DOES NOT WANT > ANYMORE IPv4 PROLIFERATION and forcing IPv6 deployment native". They do > not want to begin their new IPv6 networks or update their networks with > DHCPv4. Perhaps I failed to convey my intent or you misunderstood it. What I meant was v6-only network + DSTM _without_ temporary address management. IPv4 addresses would be handled over IPv6 tunnels by DHCPv4 server, not the temporary address management system. The only difference would be using existing protocol DHCPv4 for the task; temporary address management would indeed also be possible, and perhaps even useful in the cases that addresses are used by a very small number of applications for short periods of time only. But otherwise, it seems like a complication right now. > And to answer Rob's question. Yes I know many customers who do > understand the DSTM assumptions. > > But one DSTM deployment is using DHCPv4 this way but only because DHCPv6 > was not done. The prime systems integrator just delivered a dhcpv6 > solution to resolve that. Again this is a trial network but it will be > the production network of tommorrow. > > Have you read the latest DSTM spec (like you asked me about Teredo)? Indeed, I have read the latest spec (but only cursorily, the only major thing that has changed is the applicability statement). I also commented on -07 (and DSTM-* technologies) on the ngtrans list (17 Mar 2002). Have you read my comments (I have received zero direct feedback)? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 10 05:50:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08494 for ; Tue, 10 Sep 2002 05:50:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ohgR-000621-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 02:51:47 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17ohgF-000613-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 02:51:35 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8A9pMW21434; Tue, 10 Sep 2002 12:51:22 +0300 Date: Tue, 10 Sep 2002 12:51:22 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Jun-ichiro itojun Hagino , Brian E Carpenter , "Fred L. Templin" , Subject: RE: WG Review: IPv6 Operations (v6ops) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9178@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 10 Sep 2002, Bound, Jim wrote: > > (Yes, it's possible -- but there are some engineering tradeoffs!) > > > > > DSTM > > > > I'm not yet convinced of this. Especially I have huge doubts about > > temporary address management scalability and robustness. > > There is not other mechanisms that treats IPv4 as DSTM does. Well, but there could be. Personally I've toyed with an idea of writing Dual Stack Tunneling Mechanism (DSTM) draft. > Our job > here is not to decide if temp addr mgmt is scalable the market will > decide that. Our job here is to decide if the DSTM spec is functional. > I could argue a lot of what we work on here is not scalable. That is > not our job. The market and vendors won't use it if its not scalable. I think our job is to provide properly engineered, technically sound specifications. Specifications that don't have any known technical issues, or at least ones that aren't clearly identified. > As far as robust? What does that mean? Why would you call 6to4 robust? > And define robust. What is robust to you may not be robust to my > customers? And what I call robust may not be robust to your customers? > > Robust is to subjective we cannot state specs are robust or not in the > IETF. Sure, one cannot really define robust in general terms. For some it's one thing, for others something else. But mechanisms that should be widely deployed would use even more (and perhaps a tighter interpretation for analyzing robustness) scrutiny. [...] > > And if it's necessary for a node to use it, 10, 100, 1000 > > times a day? Is > > Ad-hoc really the best way to go? > > OK. But you have not provided one technical argument against DSTM nor > has anyone else since the last draft-08 because the working group did > their job and the authors did their job with updates. Read my comments from 6 months back. > All your arguments are a "gut" feeling against DSTM and There are more, but gut feelings are part of it, yes. Is that a bad thing. Did people have "technical arguments" against NAT? Gut feelings, at least surely (I'm not saying DSTM == NAT, but to make a point: gut feelings, intuition etc. do play a valid role). > "your OPINION" > of how IPv6 will be deployed. Can anyone say anything else? It's all opinions, hopefully informed ones of course. > Hardly an argument to not move forward with DSTM. This is not a club or > social group it is the Internet Engineering Task Force and DSTM > performed that process and is being used as all the mechanisms above. ... > Just because you don't like it is not a fair way to stop it from being > move forward. There are reasons I don't like it, and I'd like to see it changed so that both operational procedures would be possible (with "core" procedure being the simplest one). > In fact if that happens it proves all I am beginning to > dislike about the IETF processes of late. You'd like the IETF take out the rubber stamp? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 10 07:06:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09407 for ; Tue, 10 Sep 2002 07:06:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oirj-0009JS-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 04:07:31 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17oirg-0009JG-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 04:07:28 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g8AB65V29873; Tue, 10 Sep 2002 13:06:05 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA25359; Tue, 10 Sep 2002 13:06:05 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g8AB636o077016; Tue, 10 Sep 2002 13:06:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209101106.g8AB636o077016@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: "Bound, Jim" , Jun-ichiro itojun Hagino , Brian E Carpenter , "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: WG Review: IPv6 Operations (v6ops) In-reply-to: Your message of Mon, 09 Sep 2002 23:43:45 +0300. Date: Tue, 10 Sep 2002 13:06:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => I am not convinced by 6to4. For instance by the 6to4-relay concept. 6to4 relays cause some rather interesting problems, especially relating to quality of service (too few of them at the moment, leading to huge delays connecting to 6to4 nodes from some areas). => I had more security issues in mind... > I'm not yet convinced of this. Especially I have huge doubts about > temporary address management scalability and robustness. > > => this address management is exactly the current DHCPv4 address management > (I agree this is not a real answer :-). No it *definitely* isn't, or I've misunderstood the intent. => IMHO the second (:-). What has been proposed is something like 'when application requests and address, get it from somewhere, after application exists, return it'. => no, the address is renew if it is still in used and it is returned after a delay (i.e., one checks from time to time if it is used and returns it if not. Of course the initial delay is greater). Add the ports option to the stew and you have a mess.. => I don't like the ports option (too close to NAT). Running DHCPv4 over DSTM (with reasonable address lifetimes etc.) would sound much better than currently proposed. => I believe you have misunderstood the proposal: it works exactly like DHCPv4, the only difference is the allocation (request) is done only when needed, not a priori. And in our implementation the allocation control is performed by a reused DHCPv4 code... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Tue Sep 10 10:10:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14913 for ; Tue, 10 Sep 2002 10:10:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17olhG-000Itz-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:08:54 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17olh6-000IsT-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:08:44 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D0A6D6A6E; Tue, 10 Sep 2002 10:08:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 10:08:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Tue, 10 Sep 2002 10:08:42 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9191@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJYoqSStjcPNa7KSm+u0eB6Y3U45gAMGK7g From: "Bound, Jim" To: "Pekka Savola" Cc: "Francis Dupont" , "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 10 Sep 2002 14:08:43.0734 (UTC) FILETIME=[9266A760:01C258D3] X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA14913 Hi Pekka, > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, September 10, 2002 4:18 AM > To: Bound, Jim > Cc: Francis Dupont; Jun-ichiro itojun Hagino; Brian E > Carpenter; Fred L. > Templin; v6ops@ops.ietf.org > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > On Tue, 10 Sep 2002, Bound, Jim wrote: > > > No it *definitely* isn't, or I've misunderstood the > intent. What has > > > been proposed is something like 'when application requests and > > > address, get it from somewhere, after application exists, > return it'. > > > That's very far from DHCPv4. Add the ports option to the > stew and you > > > have a mess.. > > > > > > Running DHCPv4 over DSTM (with reasonable address lifetimes etc.) > > > would sound much better than currently proposed. > > > > Read the DSTM Assumptions in the Spec. This just > frustrates me to no > > end. The DSTM assumption is as follows. "THE USER DOES NOT WANT > > ANYMORE IPv4 PROLIFERATION and forcing IPv6 deployment > native". They do > > not want to begin their new IPv6 networks or update their > networks with > > DHCPv4. > > Perhaps I failed to convey my intent or you misunderstood it. > > What I meant was v6-only network + DSTM _without_ temporary address > management. IPv4 addresses would be handled over IPv6 > tunnels by DHCPv4 > server, not the temporary address management system. The > only difference > would be using existing protocol DHCPv4 for the task; > temporary address > management would indeed also be possible, and perhaps even > useful in the > cases that addresses are used by a very small number of > applications for > short periods of time only. But otherwise, it seems like a > complication > right now. I responded why not DHCPv4 for the main DSTM spec in other mail last night. But clearly there can be spec with DHCPv4 but that complicates DSTM and DHCPv6 fits exactly within the architecture of DSTM. But as I said one user has chosen this path but more because there was no dhcpv6 implementation 6 months ago. > > > And to answer Rob's question. Yes I know many customers who do > > understand the DSTM assumptions. > > > > But one DSTM deployment is using DHCPv4 this way but only > because DHCPv6 > > was not done. The prime systems integrator just delivered a dhcpv6 > > solution to resolve that. Again this is a trial network > but it will be > > the production network of tommorrow. > > > > Have you read the latest DSTM spec (like you asked me about Teredo)? > > Indeed, I have read the latest spec (but only cursorily, the > only major > thing that has changed is the applicability statement). I > also commented > on -07 (and DSTM-* technologies) on the ngtrans list (17 Mar > 2002). Have > you read my comments (I have received zero direct feedback)? Hmmm. I recall Octavio responding to you? Can you repost I don't store IETF mail normally and for DSTM I just scanned and cannot find your input? The update to draft 7 was just applicability per Alain Durand as chair and author too.\ Was it technical issue or deployment issue? thanks /jim > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Tue Sep 10 10:21:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15265 for ; Tue, 10 Sep 2002 10:21:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oltj-000JDA-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:21:47 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17oltf-000JCx-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:21:43 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2C6A44253; Tue, 10 Sep 2002 10:21:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 10:21:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WG Review: IPv6 Operations (v6ops) Date: Tue, 10 Sep 2002 10:21:42 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9192@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJYr6txN3hh5VJGQOunRf/V06pu3QAI/LnA From: "Bound, Jim" To: "Pekka Savola" Cc: "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 10 Sep 2002 14:21:43.0089 (UTC) FILETIME=[62EECA10:01C258D5] X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15265 Hi Pekka, > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Tuesday, September 10, 2002 5:51 AM > To: Bound, Jim > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin; > v6ops@ops.ietf.org > Subject: RE: WG Review: IPv6 Operations (v6ops) > > > On Tue, 10 Sep 2002, Bound, Jim wrote: > > > (Yes, it's possible -- but there are some engineering tradeoffs!) > > > > > > > DSTM > > > > > > I'm not yet convinced of this. Especially I have huge > doubts about > > > temporary address management scalability and robustness. > > > > There is not other mechanisms that treats IPv4 as DSTM does. > > Well, but there could be. Personally I've toyed with an idea > of writing > Dual Stack Tunneling Mechanism (DSTM) draft. I think it would be more productive if you would state what DSTM is missing now? Other than the DHCPv4 issue and I have commented on that already. > > > Our job > > here is not to decide if temp addr mgmt is scalable the market will > > decide that. Our job here is to decide if the DSTM spec is > functional. > > I could argue a lot of what we work on here is not > scalable. That is > > not our job. The market and vendors won't use it if its > not scalable. > > I think our job is to provide properly engineered, technically sound > specifications. Specifications that don't have any known technical > issues, or at least ones that aren't clearly identified. That is the case we feel with DSTM and it is totally technically sound. > > > As far as robust? What does that mean? Why would you call > 6to4 robust? > > And define robust. What is robust to you may not be robust to my > > customers? And what I call robust may not be robust to your > customers? > > > > Robust is to subjective we cannot state specs are robust or > not in the > > IETF. > > Sure, one cannot really define robust in general terms. For > some it's one > thing, for others something else. But mechanisms that should > be widely > deployed would use even more (and perhaps a tighter interpretation for > analyzing robustness) scrutiny. Bottom line this cannot be a bar for a draft to jump over if we cannot clearly define it and hence should not be a bar. > > [...] > > > > And if it's necessary for a node to use it, 10, 100, 1000 > > > times a day? Is > > > Ad-hoc really the best way to go? > > > > OK. But you have not provided one technical argument > against DSTM nor > > has anyone else since the last draft-08 because the working > group did > > their job and the authors did their job with updates. > > Read my comments from 6 months back. Please resend them. I don't recall them other than being you did not like DSTM? The one area I would like to improve is the use the gethostent struct time field. But we have been forced to only product architecture doc. > > > All your arguments are a "gut" feeling against DSTM and > > There are more, but gut feelings are part of it, yes. Is that a bad > thing. Did people have "technical arguments" against NAT? > Gut feelings, > at least surely (I'm not saying DSTM == NAT, but to make a point: gut > feelings, intuition etc. do play a valid role). And that is why we have NAT specs mine and others gut feelings were not used to prevent that work from reaching an RFC number. And that was the right decision. But they should not hold up or prevent work. If a spec is technically correct and the working group has worked it on its scope of merit it should move forward. The place to put our gut feelings is in the applicability section of documents as a note. > > > "your OPINION" > > of how IPv6 will be deployed. > > Can anyone say anything else? It's all opinions, hopefully > informed ones > of course. Yes they can. I for example objected to entire notion of 6to4 relays I don't think they are technically required or technically defined well in the spec. I lost that discussion and now accept and make the spec work as best I can in the industry. You know how I feel about site-locals and my technical arguments against them. But in all my counter non consensus input it was based on technical input not gut input. My gut is 6to4 is to general and I don't like general except for general cases. IPv6 as I said in other mail for initial deployment requires non-general mechanisms and that is the crux of where you and I and others disagree. It like so many of our specs are a design by committee and that just waters it down. SCTP on the hand is an excellent example of a design by an engineering team and then worked on by the IETF processes. That is how I want DSTM to be done. DHCPv6 is now suffering from design by committee and we are trying to make sure it is not watered down. > > > Hardly an argument to not move forward with DSTM. This is > not a club or > > social group it is the Internet Engineering Task Force and DSTM > > performed that process and is being used as all the > mechanisms above. > > ... > > > Just because you don't like it is not a fair way to stop it > from being > > move forward. > > There are reasons I don't like it, and I'd like to see it > changed so that > both operational procedures would be possible (with "core" > procedure being > the simplest one). Then suggest your changes but I don't buy the DHCPv4 idea at all. > > > In fact if that happens it proves all I am beginning to > > dislike about the IETF processes of late. > > You'd like the IETF take out the rubber stamp? Not what I am saying. What I am saying is the IETF needs to just do technical work and not pretend they can do all things for all people. When that technical work is done then a stamp is important for sure. But stopping work because of gut feelings and power plays by authority don't sit well with me. It is simply not fair. Also DSTM discussions have existed and have been discussed this is not new. /jim > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From owner-v6ops@ops.ietf.org Tue Sep 10 10:25:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15439 for ; Tue, 10 Sep 2002 10:25:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17olyo-000JWi-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:27:02 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17olyl-000JWW-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:26:59 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17olyi-0006Wz-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:26:56 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17olyi-0006Wt-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:26:56 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA61826 for ; Tue, 10 Sep 2002 15:26:55 +0100 Message-ID: <3D7E0140.64CAAB08@hursley.ibm.com> Date: Tue, 10 Sep 2002 16:27:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: <200209101106.g8AB636o077016@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > > => I am not convinced by 6to4. For instance by the 6to4-relay concept. > > 6to4 relays cause some rather interesting problems, especially relating to > quality of service (too few of them at the moment, leading to huge > delays connecting to 6to4 nodes from some areas). If the worst problem with 6to4 is already a purely operational one, I'm not at all distressed, and I wonder whether we can encourage all XPs to operate a 6to4 relay? Brian From owner-v6ops@ops.ietf.org Tue Sep 10 10:29:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15649 for ; Tue, 10 Sep 2002 10:29:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17om1s-000JjH-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:30:12 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17om1o-000Jj0-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:30:08 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4FDA4665F; Tue, 10 Sep 2002 10:30:06 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 10:30:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: access to temp addrs in DSTM Date: Tue, 10 Sep 2002 10:30:03 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9197@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJYr6txN3hh5VJGQOunRf/V06pu3QAJqMUw From: "Bound, Jim" To: "Pekka Savola" Cc: "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 10 Sep 2002 14:30:04.0101 (UTC) FILETIME=[8D8F2750:01C258D6] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15649 Pekka, As a note we made it clear in dstm that at this point one can use any addr mgmt they choose to and will be specific specs to be done for DSTM. So if one want to use dhcpv4, or a version of it, or RPC or DHCPv6 its pretty open. /jim From owner-v6ops@ops.ietf.org Tue Sep 10 10:30:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15681 for ; Tue, 10 Sep 2002 10:30:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17om1o-000Jiy-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:30:08 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17om1g-000Ji9-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:30:00 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17om1f-00072f-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:29:59 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17om1f-00072a-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:29:59 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA47630 for ; Tue, 10 Sep 2002 15:29:58 +0100 Message-ID: <3D7E01F7.A0049F66@hursley.ibm.com> Date: Tue, 10 Sep 2002 16:30:15 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations Subject: 6to4 security [Re: WG Review: IPv6 Operations (v6ops)] References: <200209101106.g8AB636o077016@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: ... > => I had more security issues in mind... I would like this WG to consider draft-savola-ngtrans-6to4-security-01.txt as the basis for a possible work item. Brian From owner-v6ops@ops.ietf.org Tue Sep 10 10:30:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15726 for ; Tue, 10 Sep 2002 10:30:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17om3d-000Jog-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:32:01 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17om3V-000Jnb-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:31:53 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17om3U-00076M-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:31:52 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17om3U-00076H-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:31:52 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA61784 for ; Tue, 10 Sep 2002 15:31:52 +0100 Message-ID: <3D7E0269.4D9436FF@hursley.ibm.com> Date: Tue, 10 Sep 2002 16:32:09 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations Subject: 6to4 DNS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like this WG to consider draft-ietf-ngtrans-6to4-dns-01.txt (expired) as the basis for a WG effort, or whether it should be referred to a DNS-related WG. Brian From owner-v6ops@ops.ietf.org Tue Sep 10 10:32:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15782 for ; Tue, 10 Sep 2002 10:32:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17om5T-000Jxq-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:33:55 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17om5P-000Jwt-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:33:51 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17om5O-00077d-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:33:50 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17om5O-00077Y-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 15:33:50 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA67754 for ; Tue, 10 Sep 2002 15:33:49 +0100 Message-ID: <3D7E02DF.EC6FDAB@hursley.ibm.com> Date: Tue, 10 Sep 2002 16:34:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: IPv6 Operations Subject: 6to4 multicast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like this WG to consider draft-ietf-ngtrans-6to4-multicast-01.txt as the basis for a WG effort, or whether it should be referred to a multicast-related WG. Brian From owner-v6ops@ops.ietf.org Tue Sep 10 10:43:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16113 for ; Tue, 10 Sep 2002 10:43:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17omFs-000KZd-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:44:40 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17omFj-000KZM-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:44:31 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D150F47C8; Tue, 10 Sep 2002 10:44:30 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 10:44:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: access to temp addrs in DSTM Date: Tue, 10 Sep 2002 10:44:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B580@tayexc13.americas.cpqcorp.net> Thread-Topic: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJYr6txN3hh5VJGQOunRf/V06pu3QAJqMUwAAAjXlA= From: "Bound, Jim" To: "Pekka Savola" Cc: "Jun-ichiro itojun Hagino" , "Brian E Carpenter" , "Fred L. Templin" , X-OriginalArrivalTime: 10 Sep 2002 14:44:30.0658 (UTC) FILETIME=[92114220:01C258D8] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16113 Pekka, A bit of history. DSTM was orginially called "Avoidance of Network Address Translation" (AATN) and a very specific solution. We were asked to change the name to prevent negative connotation. OK I did that. We then combined forces with a Tunneling methodology from Laurent Toutain and company in the spring of 1999. We had an AATN BOF in 98 and it was highly attended and spawned various activities like RSIP and a few others. We then were asked to just build an architecture template and permit DSTM specific mechanisms as extensions to that main architecture. There are extensions for Mobile IPv6, Use with SIIT, Port Ranges, and even 6to4 and all good engineering work. So I feel I am very correct in arguing to the IETF DSTM is an architecture and method that folks do want in the IETF or there would not be so many adjunct extensions for DSTM. In addition the NGTRANS Chairs supported this work and still do. In addition there are three implementations currently of DSTM Francis spoke of ENST's, i2Soft, and the other is not annoucing yet but it is in Asia and for large Telecom doing Mobile IPv6. i2Soft and the Asian Telecom are using DHCPv6 as a note. So if anyone tells me that DSTM is not a needed and useful mechanism I simply cannot parse that at all. Of if they try to second guess IPv6 deployment. I think Tony Hain summed it up really well when he stated we need to complete the work on the Enterprise, UnManaged, and ISP ops design teams and see what we learn from those deployment works. But to tell me and my authors and the NGTRANS working group after 3 years of hard work, support from the NGTRANS working group, trial deployment and some products in the market, that my colleagues who are very bright engineers are using DSTM to assist with things like SIIT, Mobile IPv6, and even the extensions to work with 6to4 that we have to go back to individual ID submissions is simply wrong and demonstrates that the IETF is being unfair, dicatorial without valid discussion in the community, and very well could justify the work to an appeal to the IAB and if necessary to the Internet Society. This simply sounds like foul play and political efforts to kill DSTM and other mechanisms where motives are very unclear and they have not been able to kill it or prove it is wrong technically. Thats what has me sketchy with the IETF OK. Big time. Lastly I don't agree with Francis at all and I believe the Port Range extensions draft for DSTM in fact is a very good piece of work and in fact will work and assist customers transitioning with DSTM. regards, /jim > -----Original Message----- > From: Bound, Jim > Sent: Tuesday, September 10, 2002 10:30 AM > To: 'Pekka Savola' > Cc: Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L. Templin; > v6ops@ops.ietf.org > Subject: access to temp addrs in DSTM > > > Pekka, > > As a note we made it clear in dstm that at this point one can > use any addr mgmt they choose to and will be specific specs > to be done for DSTM. So if one want to use dhcpv4, or a > version of it, or RPC or DHCPv6 its pretty open. > > /jim > From owner-v6ops@ops.ietf.org Tue Sep 10 10:45:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16195 for ; Tue, 10 Sep 2002 10:45:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17omHr-000KjC-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:46:43 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17omHo-000Kj0-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:46:40 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A736A6398; Tue, 10 Sep 2002 10:46:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 10:46:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Date: Tue, 10 Sep 2002 10:46:39 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9199@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Thread-Index: AcJY1uZZEANNfXeUSKeSQwOKmiA8lQAAcEUw From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 10 Sep 2002 14:46:39.0610 (UTC) FILETIME=[DEEDC5A0:01C258D8] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16195 We cannot encourage XPs to do anything Brian. What will do that is not here in the IETF. This is the ego I was talking about. The market just wants our specs not our wisdom in the IETF. I am having discussions with XPs in other fora and be glad to discuss this with you offline. But this body is to build standards. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, September 10, 2002 10:27 AM > To: v6ops@ops.ietf.org > Subject: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] > > > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > > > => I am not convinced by 6to4. For instance by the > 6to4-relay concept. > > > > 6to4 relays cause some rather interesting problems, > especially relating to > > quality of service (too few of them at the moment, > leading to huge > > delays connecting to 6to4 nodes from some areas). > > If the worst problem with 6to4 is already a purely operational one, > I'm not at all distressed, and I wonder whether we can encourage > all XPs to operate a 6to4 relay? > > Brian > > From owner-v6ops@ops.ietf.org Tue Sep 10 10:45:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16231 for ; Tue, 10 Sep 2002 10:45:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17omID-000KmF-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:47:05 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17omIA-000Km2-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:47:02 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1EAA13BB0; Tue, 10 Sep 2002 10:47:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 10 Sep 2002 10:47:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Date: Tue, 10 Sep 2002 10:47:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE919A@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Thread-Index: AcJY1uZZEANNfXeUSKeSQwOKmiA8lQAAfoVg From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 10 Sep 2002 14:47:01.0048 (UTC) FILETIME=[EBB4F380:01C258D8] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA16231 I also have major problems with the relay as it is currently defined. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, September 10, 2002 10:27 AM > To: v6ops@ops.ietf.org > Subject: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] > > > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > > > => I am not convinced by 6to4. For instance by the > 6to4-relay concept. > > > > 6to4 relays cause some rather interesting problems, > especially relating to > > quality of service (too few of them at the moment, > leading to huge > > delays connecting to 6to4 nodes from some areas). > > If the worst problem with 6to4 is already a purely operational one, > I'm not at all distressed, and I wonder whether we can encourage > all XPs to operate a 6to4 relay? > > Brian > > From owner-v6ops@ops.ietf.org Tue Sep 10 10:46:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16268 for ; Tue, 10 Sep 2002 10:46:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17omJP-000Kpv-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:48:19 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17omJM-000Kpg-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:48:16 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g8AEmDV06094; Tue, 10 Sep 2002 16:48:13 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA00847; Tue, 10 Sep 2002 16:48:13 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g8AEmD6o077729; Tue, 10 Sep 2002 16:48:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209101448.g8AEmD6o077729@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-reply-to: Your message of Tue, 10 Sep 2002 16:27:12 +0200. <3D7E0140.64CAAB08@hursley.ibm.com> Date: Tue, 10 Sep 2002 16:48:13 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: => some clarifications: Francis Dupont wrote: > > In your previous mail you wrote: > > > => I am not convinced by 6to4. For instance by the 6to4-relay concept. => my comment. > > 6to4 relays cause some rather interesting problems, especially relating to > quality of service (too few of them at the moment, leading to huge > delays connecting to 6to4 nodes from some areas). => Pekka's comment (the answer to mine). If the worst problem with 6to4 is already a purely operational one, I'm not at all distressed, and I wonder whether we can encourage all XPs to operate a 6to4 relay? Brian Thanks Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Tue Sep 10 10:49:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16408 for ; Tue, 10 Sep 2002 10:49:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17omLo-000Kxl-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:50:48 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17omLd-000KxG-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:50:38 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17omLc-0007Yc-00; Tue, 10 Sep 2002 15:50:36 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17omLc-0007YX-00; Tue, 10 Sep 2002 15:50:36 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA27120; Tue, 10 Sep 2002 15:50:32 +0100 Message-ID: <3D7E06C9.BA565C79@hursley.ibm.com> Date: Tue, 10 Sep 2002 16:50:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Tony Hain CC: "'Jun-ichiro itojun Hagino'" , IPv6 Operations Subject: 6to4 MRU - still need WG consensus References: <032001c2585f$44e91aa0$011aa8c0@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony, People refuse to stay on a single topic however many times I twiddle the subject field, but yes the issue is in fact the 6to4 MRU. I think your formulation is the best yet. Brian (conversation switched to v6ops list) Tony Hain wrote: > > itojun wrote: > > >How about this as a compromise: > > >All nodes SHOULD configure a 6to4 MRU at least as large as their > > >interface MTU, but that value MUST NOT be smaller than 1480.=20 > > > > > >This would allow for the future case where both ends were GigE, but > > >would also allow for IPv6 PMTU discovery to figure out that > > one end was > > >limited to < 1500. > > > > we are talking about 6to4, correct? if so, even if you > > have GigE and > > I have GigE, you are not sure where 6to4 packet will > > travel to. it can > > go to anywhere (based on value on 3rd to 6th octet in ip6_dst). > > this is why i have been proposing to have fixed MTU > > value for 6to4 > > interface. > > Yes the packet might go through a router without a 100bT interface, so > the router upstream from it would have to fragment. As long as the > receiving 6to4 router is able to reassemble the fragments, there is no > problem. > > Are we talking about MTU or MRU??? There is no need for a fixed IPv6 MTU > since that is already defined as something between 1280 and the physical > link. Also there is no need for a defined IPv4 MTU since that is > something between 68 and the physical link. What I thought the point of > the thread was about is finding a minimum IPv4 MRU that would support > reassembly of IPv4 fragments into IPv6 packets. If any specific receiver > can't support an IPv4 MRU larger than 1280, the IPv6 PMTU discovery will > fail until it gets down to an acceptable value. The only real > interoperability problem will be when the IPv4 MRU is less than 1280. > Everything else is simply an optimization. > > We shouldn't need to specify that a node should implement an MRU that is > at least as large as the physical interface MTU, but if that is > confusing then I don't think it hurts. I also don't believe we need to > specify that a 6to4 MRU needs to be at least 1280 since that is already > specified, but if there were problems getting that to work between > implementations, then again it doesn't hurt to pick a value. If we are > going to do that we should pick one that is large enough to accommodate > the common option headers. > > I personally don't see why anything smaller than 4k for an MRU makes any > sense, but I also don't see that there is anything here worth arguing > over. If all nodes can receive as much as they can transmit, with a > minimum greater than 1280, then the overall system will self correct. I > don't see why a fixed value is needed. > > Tony -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Tue Sep 10 10:57:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16579 for ; Tue, 10 Sep 2002 10:57:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17omTR-000LPI-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 07:58:41 -0700 Received: from roam.psg.c ([193.0.9.125] helo=roam) by psg.com with esmtp (Exim 3.36 #1) id 17omTO-000LP6-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 07:58:38 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17omTN-000AXZ-00; Tue, 10 Sep 2002 07:58:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brian E Carpenter Cc: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: <200209101106.g8AB636o077016@givry.rennes.enst-bretagne.fr> <3D7E0140.64CAAB08@hursley.ibm.com> Message-Id: Date: Tue, 10 Sep 2002 07:58:37 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If the worst problem with 6to4 is already a purely operational one, > I'm not at all distressed aaaaiiiiiiiiiiiiiiiiii! From owner-v6ops@ops.ietf.org Tue Sep 10 14:14:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22276 for ; Tue, 10 Sep 2002 14:14:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17opY2-00063g-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 11:15:38 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17opXv-00063I-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 11:15:32 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8AIFSi26216; Tue, 10 Sep 2002 21:15:29 +0300 Date: Tue, 10 Sep 2002 21:15:28 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-Reply-To: <3D7E0140.64CAAB08@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 10 Sep 2002, Brian E Carpenter wrote: > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > > > => I am not convinced by 6to4. For instance by the 6to4-relay concept. > > > > 6to4 relays cause some rather interesting problems, especially relating to > > quality of service (too few of them at the moment, leading to huge > > delays connecting to 6to4 nodes from some areas). > > If the worst problem with 6to4 is already a purely operational one, > I'm not at all distressed, and I wonder whether we can encourage > all XPs to operate a 6to4 relay? I wonder if we can encourage Microsoft implementations not to assume bogus things about 6to4 relays. Like it having the address '2002:::'. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 11 00:20:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04476 for ; Wed, 11 Sep 2002 00:20:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17oyxp-000DXb-00 for v6ops-data@psg.com; Tue, 10 Sep 2002 21:18:53 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17oyxj-000DXJ-00 for v6ops@ops.ietf.org; Tue, 10 Sep 2002 21:18:47 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A912E38B5; Wed, 11 Sep 2002 00:18:46 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 11 Sep 2002 00:18:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) Date: Wed, 11 Sep 2002 00:18:46 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91AF@tayexc13.americas.cpqcorp.net> Thread-Topic: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJXRBp7dXa5RqqKTT+xauRm17+oGACBbRrQ From: "Bound, Jim" To: "Brian E Carpenter" , "Hesham Soliman (EAB)" Cc: "Margaret Wasserman " , , X-OriginalArrivalTime: 11 Sep 2002 04:18:46.0429 (UTC) FILETIME=[52604CD0:01C2594A] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA04476 Brian, That is not what should happen. And we may need this within V6ops per Hesham's many explanations. Also 6to4 punts on BGP and it could be we need this as adjunct for 6to4 and we should at least look at this in V6ops. I also came to the same conclusion of the serendipity of 6to4 in these times. 6to4 would potentially be dead in V6ops too if it did not have and RFC number. And lastly I think all transition work that does not fit with V6ops requires its own focus not within the routing area. What Hesham asks for is required TODAY not tomorrow. We need possibly the "advanced transition working group" but I have not given up on V6ops either and we will see at the Interim meeting. regards, /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, September 08, 2002 10:27 AM > To: Hesham Soliman (EAB) > Cc: 'Margaret Wasserman '; 'v6ops@ops.ietf.org '; > 'ngtrans@sunroof.eng.sun.com ' > Subject: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > "Hesham Soliman (EAB)" wrote: > ... > > Let me give you an example, if > > 6to4 was written now, it would have suffered the same > > destiny as ISATAP or BGP-based tunnelling. But because > > it was written a long time ago, it is actually an > > RFC. I'm not sure that 6to4 is a better solution > > for inter-domain tunnelling than BGP-based tunnels. > > I think the historical fact is that the BGP-based tunneling > proposal emerged later than 6to4 *because* 6to4 talks quite a > bit about using BGP to make 6to4 work properly in an IDR > context. And of course BGP will work with other methods of > prefix assignment too. > > If it isn't in the v6ops charter, just develop it as an > individual submission to the routing area. > > Brian > From owner-v6ops@ops.ietf.org Wed Sep 11 04:42:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01555 for ; Wed, 11 Sep 2002 04:42:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p35B-0003Ue-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 01:42:45 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17p354-0003UJ-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 01:42:38 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p351-0007eq-00; Wed, 11 Sep 2002 09:42:35 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p351-0007el-00; Wed, 11 Sep 2002 09:42:35 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA72130; Wed, 11 Sep 2002 09:42:32 +0100 Message-ID: <3D7F0209.29B2FEFB@hursley.ibm.com> Date: Wed, 11 Sep 2002 10:42:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Tony Hain CC: "'Robert Elz'" , IPv6 Operations Subject: Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus] References: <036601c258e0$e83dd480$011aa8c0@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: > > kre wrote: > > Actually, no it isn't, and this is the point. Packets > > exceeding the MRU > > generally just get dropped (unless something implements the > > idea that Christian suggested, which currently, I know of > > nothing that does). No ICMP gets sent back. > > > > That is, PMTUD doesn't find this problem, what happens is a > > black hole. > > An apparently false assumption on my part was that implementations had a > black-hole detector tied to their PMTU discovery process. At least for > TCP the stack should know that the small packets through SYN-ACK worked, > so if large ones are failing, it would seem logical to shrink them > before trying again, then try to grow them over time. > > Short of that, I agree it makes the most sense to require a 6to4 > receiver to send an IPv6 MTU exceeded message when reassembly fails due > to size. It will have the necessary information, and as a router its job > is to inform the upstream node when a link capacity is being exceded. > The unusual aspect of this case is that the link is a logical one inside > the router between IPv4 and IPv6, and the failure notice is coming from > the inbound IPv6 interface rather than an outbound one. The more I think > about it, this would be a reasonable requirement for all inbound IPv6 > interfaces, because we may end up with the same kinds of MTU/MRU > mismatch issues we found with FDDI-Ethernet bridges as we move into gigE > ... Exactly. There is nothing special about a 6to4 interface in this respect. Brian From owner-v6ops@ops.ietf.org Wed Sep 11 04:50:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01819 for ; Wed, 11 Sep 2002 04:50:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p3DF-0003za-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 01:51:05 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17p3D7-0003yT-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 01:50:57 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8B8oZt07996; Wed, 11 Sep 2002 15:50:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8B8oR811233; Wed, 11 Sep 2002 15:50:30 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Sep 2002 15:50:27 +0700 Message-ID: <11231.1031734227@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Tue, 10 Sep 2002 21:15:28 +0300 (EEST) From: Pekka Savola Message-ID: | I wonder if we can encourage Microsoft implementations not to assume bogus | things about 6to4 relays. Like it having the address | '2002:::'. I haven't seen the implementation, so this is a real question ... which way is it assuming that? If when it is acting as a 6to4, that's the address it assigns itself, that is, RELAY_IPv4 is its own IPv4 address, then that sounds OK to me, it has to have something, as a v6 addr by default, right? If it is assuming that some other node will have that address, then why? Why would anyone ever want to directly address a 6to4 relay node? That would be much like having nodes attempt to guess the IP(4 or 6) address of some router along the path to a destination (including the local egress and remote ingress routers). It just makes no sense to assume anything about any of those addresses (I mean, how would you even tell it was making the assumption). So, what is the actual encouragement that is needed? kre From owner-v6ops@ops.ietf.org Wed Sep 11 04:50:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01847 for ; Wed, 11 Sep 2002 04:50:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p3Dw-00041p-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 01:51:48 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17p3Dt-00041c-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 01:51:45 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p3Ds-0007pz-00; Wed, 11 Sep 2002 09:51:44 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p3Ds-0007pu-00; Wed, 11 Sep 2002 09:51:44 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA72174; Wed, 11 Sep 2002 09:51:41 +0100 Message-ID: <3D7F042E.A7CFB6CE@hursley.ibm.com> Date: Wed, 11 Sep 2002 10:51:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Tue, 10 Sep 2002, Brian E Carpenter wrote: > > Francis Dupont wrote: > > > > > > In your previous mail you wrote: > > > > > > > => I am not convinced by 6to4. For instance by the 6to4-relay concept. > > > > > > 6to4 relays cause some rather interesting problems, especially relating to > > > quality of service (too few of them at the moment, leading to huge > > > delays connecting to 6to4 nodes from some areas). > > > > If the worst problem with 6to4 is already a purely operational one, > > I'm not at all distressed, and I wonder whether we can encourage > > all XPs to operate a 6to4 relay? > > I wonder if we can encourage Microsoft implementations not to assume bogus > things about 6to4 relays. Like it having the address > '2002:::'. The specification that the IETF actually approved was for router-based 6to4, not host-based, and it was assumed that router operators would club together to configure and share relays. Clearly, a client-host based implementation such as the one you mention leads to quite different issues around relay deployment, which were not considered in the original scenario. We are still missing an RFC really analysing host-based 6to4, and until that work has been done we don't know what is bogus. Brian From owner-v6ops@ops.ietf.org Wed Sep 11 04:56:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01926 for ; Wed, 11 Sep 2002 04:56:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p3K3-0004OT-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 01:58:07 -0700 Received: from laposte.enst-bretagne.fr ([192.108.115.3]) by psg.com with esmtp (Exim 3.36 #1) id 17p3Jy-0004NT-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 01:58:02 -0700 Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g8B8vpE20695; Wed, 11 Sep 2002 10:57:51 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA17630; Wed, 11 Sep 2002 10:57:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g8B8vp6o079986; Wed, 11 Sep 2002 10:57:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200209110857.g8B8vp6o079986@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-reply-to: Your message of Wed, 11 Sep 2002 10:51:58 +0200. <3D7F042E.A7CFB6CE@hursley.ibm.com> Date: Wed, 11 Sep 2002 10:57:51 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: We are still missing an RFC really analysing host-based 6to4, and until that work has been done we don't know what is bogus. => a new work item for the v6ops WG? Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Sep 11 05:01:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02001 for ; Wed, 11 Sep 2002 05:01:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p3P6-0004jj-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 02:03:20 -0700 Received: from proxy-sat-camp.camp.wide.ad.jp ([203.178.141.126] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17p3P2-0004jX-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 02:03:17 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B5F987B9; Wed, 11 Sep 2002 18:03:10 +0900 (JST) To: Brian E Carpenter Cc: Pekka Savola , v6ops@ops.ietf.org In-reply-to: brian's message of Wed, 11 Sep 2002 10:51:58 +0200. <3D7F042E.A7CFB6CE@hursley.ibm.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] From: Jun-ichiro itojun Hagino Date: Wed, 11 Sep 2002 18:03:10 +0900 Message-Id: <20020911090310.B5F987B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >The specification that the IETF actually approved was for router-based >6to4, not host-based, and it was assumed that router operators would >club together to configure and share relays. Clearly, a client-host WinXP node can become a router, so there's nothing prohibiting WinXP from running 6to4. in fact, i don't see any distinction between "router-based 6to4" and "host-based 6to4" in the RFC. am i mistaken? itojun From owner-v6ops@ops.ietf.org Wed Sep 11 05:14:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02138 for ; Wed, 11 Sep 2002 05:14:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p3bj-0005UN-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 02:16:23 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17p3bd-0005U1-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 02:16:17 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p3bY-0000Bz-00; Wed, 11 Sep 2002 10:16:12 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p3bY-0000Bu-00; Wed, 11 Sep 2002 10:16:12 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA25214; Wed, 11 Sep 2002 10:16:07 +0100 Message-ID: <3D7F09E8.446CFD7A@hursley.ibm.com> Date: Wed, 11 Sep 2002 11:16:24 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Bound, Jim" CC: "Hesham Soliman (EAB)" , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91AF@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't agree that RFC 3056 punts on BGP. It's quite explicit about how relays should use BGP4+. Brian "Bound, Jim" wrote: > > Brian, > > That is not what should happen. And we may need this within V6ops per Hesham's many explanations. Also 6to4 punts on BGP and it could be we need this as adjunct for 6to4 and we should at least look at this in V6ops. > > I also came to the same conclusion of the serendipity of 6to4 in these times. 6to4 would potentially be dead in V6ops too if it did not have and RFC number. > > And lastly I think all transition work that does not fit with V6ops requires its own focus not within the routing area. What Hesham asks for is required TODAY not tomorrow. We need possibly the "advanced transition working group" but I have not given up on V6ops either and we will see at the Interim meeting. > > regards, > /jim > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Sunday, September 08, 2002 10:27 AM > > To: Hesham Soliman (EAB) > > Cc: 'Margaret Wasserman '; 'v6ops@ops.ietf.org '; > > 'ngtrans@sunroof.eng.sun.com ' > > Subject: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > > > > "Hesham Soliman (EAB)" wrote: > > ... > > > Let me give you an example, if > > > 6to4 was written now, it would have suffered the same > > > destiny as ISATAP or BGP-based tunnelling. But because > > > it was written a long time ago, it is actually an > > > RFC. I'm not sure that 6to4 is a better solution > > > for inter-domain tunnelling than BGP-based tunnels. > > > > I think the historical fact is that the BGP-based tunneling > > proposal emerged later than 6to4 *because* 6to4 talks quite a > > bit about using BGP to make 6to4 work properly in an IDR > > context. And of course BGP will work with other methods of > > prefix assignment too. > > > > If it isn't in the v6ops charter, just develop it as an > > individual submission to the routing area. > > > > Brian > > From owner-v6ops@ops.ietf.org Wed Sep 11 05:34:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02431 for ; Wed, 11 Sep 2002 05:34:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p3uF-0006UP-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 02:35:31 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17p3uC-0006UE-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 02:35:28 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8B9Z1D01207; Wed, 11 Sep 2002 12:35:01 +0300 Date: Wed, 11 Sep 2002 12:35:01 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-Reply-To: <11231.1031734227@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Perhaps I should have been more clear, sorry. On Wed, 11 Sep 2002, Robert Elz wrote: > Date: Tue, 10 Sep 2002 21:15:28 +0300 (EEST) > From: Pekka Savola > Message-ID: > > | I wonder if we can encourage Microsoft implementations not to assume bogus > | things about 6to4 relays. Like it having the address > | '2002:::'. > > I haven't seen the implementation, so this is a real question ... which > way is it assuming that? > > If when it is acting as a 6to4, that's the address it assigns itself, > that is, RELAY_IPv4 is its own IPv4 address, then that sounds OK to me, > it has to have something, as a v6 addr by default, right? What I meant is that 6to4 routers, in MS implementations that I'm aware of, can be configured with the relay's IPv4 address. Additionally it's looked up from DNS. No problem. For MS implementation to be able to use that specified relay, the relay must have 2002::: address. (I assume it's trying to ping the relay before using it or something, I really don't care that much). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 11 06:17:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03114 for ; Wed, 11 Sep 2002 06:17:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p4ZX-000918-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 03:18:11 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17p4ZR-0008zc-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 03:18:05 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8BAI1H01543; Wed, 11 Sep 2002 13:18:01 +0300 Date: Wed, 11 Sep 2002 13:18:01 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: RE: access to temp addrs in DSTM In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B580@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Trimmed Cc: list a bit. On Tue, 10 Sep 2002, Bound, Jim wrote: [...] > So I feel I am very correct in arguing to the IETF DSTM is an > architecture and method that folks do want in the IETF or there would > not be so many adjunct extensions for DSTM. [...] Why not make the IPv4 address management (a bit more clearly perhaps) a bit more clearly a replaceable part of the architecture? Mainly my objection is that the DSTM model as I see it is using v6-only network and tunneling IPv4 over that (when necessary). "When necessary" varies greatly between people deploying DSTM. For example, one company here with an IPv4 assignment of /16 with 4000 nodes may be interested in something similar; it is possible that some folks do not see the IPv4 shortage as direly as others, and may want to use some other mechanism for handling IPv4 addresses (static assignment, DHCPv4, whatever). That's IMHO the simplest and the most "robust" and "stable" case (== requires no code at all I think). More complex mechanisms (like using RPC, or whatever) may be warranted, but these should be an extension. Perhaps this clarifies how I feel about the architecture or DSTM framework if I may. [...] > I think Tony Hain summed it up really well when he stated we need to > complete the work on the Enterprise, UnManaged, and ISP ops design teams > and see what we learn from those deployment works. Indeed. [...] > Lastly I don't agree with Francis at all and I believe the Port Range > extensions draft for DSTM in fact is a very good piece of work and in > fact will work and assist customers transitioning with DSTM. Port Range extension is an interesting idea, but I have great doubts on the robustness. In particular, I don't see any way the node could reliably control that an application doesn't just use any port it wishes to use regardless of the assigned ports. It may be useful in some very restricted cases, but probably not so in general. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 11 06:58:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03745 for ; Wed, 11 Sep 2002 06:58:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p5Dp-000BQ4-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 03:59:49 -0700 Received: from roam.psg.c ([193.0.9.125] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17p5Dm-000BPs-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 03:59:46 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17p5Dg-000B21-00; Wed, 11 Sep 2002 03:59:41 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Francis Dupont Cc: Brian E Carpenter , Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: <3D7F042E.A7CFB6CE@hursley.ibm.com> <200209110857.g8B8vp6o079986@givry.rennes.enst-bretagne.fr> Message-Id: Date: Wed, 11 Sep 2002 03:59:41 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> We are still missing an RFC really analysing host-based 6to4, >> and until that work has been done we don't know what is bogus. > a new work item for the v6ops WG? how is this different from what shipworm is trying to solve? randy From owner-v6ops@ops.ietf.org Wed Sep 11 07:51:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04891 for ; Wed, 11 Sep 2002 07:51:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p62X-000Dp4-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 04:52:13 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17p62P-000Do6-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 04:52:05 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 15DCD6611; Wed, 11 Sep 2002 07:52:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 11 Sep 2002 07:52:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: access to temp addrs in DSTM Date: Wed, 11 Sep 2002 07:52:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B585@tayexc13.americas.cpqcorp.net> Thread-Topic: access to temp addrs in DSTM Thread-Index: AcJZfIT+rZGB/QcsTciwd6qjUArctAACy03g From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 11 Sep 2002 11:52:04.0934 (UTC) FILETIME=[A5F2CE60:01C25989] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA04891 Hi Pekka, The DSTM draft-ietf-ngtrans-dstm-08.txt permits the use of the address mgmt that you want and I suppose doing a draft with dhcpv4 to obtain the addreses is fair. I would support it as engineer even though I don't like the idea. > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 11, 2002 6:18 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: access to temp addrs in DSTM > > > Trimmed Cc: list a bit. > > On Tue, 10 Sep 2002, Bound, Jim wrote: > [...] > > So I feel I am very correct in arguing to the IETF DSTM is an > > architecture and method that folks do want in the IETF or > there would > > not be so many adjunct extensions for DSTM. [...] > > Why not make the IPv4 address management (a bit more clearly > perhaps) a > bit more clearly a replaceable part of the architecture? We took address mgmt out of the architecture I think that was wise. > > Mainly my objection is that the DSTM model as I see it is > using v6-only > network and tunneling IPv4 over that (when necessary). "When > necessary" > varies greatly between people deploying DSTM. For example, > one company > here with an IPv4 assignment of /16 with 4000 nodes may be > interested in > something similar; it is possible that some folks do not see the IPv4 > shortage as direly as others, and may want to use some other > mechanism for > handling IPv4 addresses (static assignment, DHCPv4, whatever). Then what you are debating is our assumptions not our technical work. I believe that to be as important discussion as the technical giblets suggested. We built DSTM for dominant IPv6 backbones that is what it is for not for IPv4 backbones. For the scenario above the user may have enough address space (globally routable I will assume) that to connect with IPv4 apps they do not have to manage IPv4 as scarce resource. THen I would argue for that case DSTM is not needed. Our work was for users who do have to treat their IPv4 global routable address space as a scarce resource. It also assumed many of the users were having to use NAT with private address space. Hmmmm. This we could state much clearer in our DSTM assumptions section. So this conversation to me just found a hole we need to state. > > That's IMHO the simplest and the most "robust" and "stable" case (== > requires no code at all I think). More complex mechanisms > (like using > RPC, or whatever) may be warranted, but these should be an extension. > > Perhaps this clarifies how I feel about the architecture or > DSTM framework > if I may. > > [...] > > I think Tony Hain summed it up really well when he stated we need to > > complete the work on the Enterprise, UnManaged, and ISP ops > design teams > > and see what we learn from those deployment works. > > Indeed. > > [...] > > Lastly I don't agree with Francis at all and I believe the > Port Range > > extensions draft for DSTM in fact is a very good piece of > work and in > > fact will work and assist customers transitioning with DSTM. > > Port Range extension is an interesting idea, but I have great > doubts on > the robustness. In particular, I don't see any way the node could > reliably control that an application doesn't just use any > port it wishes > to use regardless of the assigned ports. It may be useful in > some very > restricted cases, but probably not so in general. Hmmm. I will have to go read the draft but controlling evil apps is something we could do in that extension. But I believe it to be useful because for a user that only has lets say 10,000 IPv4 global address spaces distributed across a multi-sited Intranet the port ranges can help with conservation. I do agree with restricted cases but maybe not on the word "restricted". I believe in Caveat Emptor and survival of the fittest. Clearly a minority view in this community. But on the other hand we cannot protect every case from happening or we won't ship specs. We have to assume that the majority of implementors, operators, and users are intelligent beings educated about doing networking. I am fine with that assumption. thanks /jim > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From owner-v6ops@ops.ietf.org Wed Sep 11 07:53:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04932 for ; Wed, 11 Sep 2002 07:53:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p65b-000E30-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 04:55:23 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17p65Y-000E2m-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 04:55:20 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 84EC2454B; Wed, 11 Sep 2002 07:55:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 11 Sep 2002 07:55:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Date: Wed, 11 Sep 2002 07:55:19 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91B4@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Thread-Index: AcJZgpKxGoKNZH02TKy/G/R6SLAAPQAByuSQ From: "Bound, Jim" To: "Randy Bush" , "Francis Dupont" Cc: "Brian E Carpenter" , "Pekka Savola" , X-OriginalArrivalTime: 11 Sep 2002 11:55:19.0402 (UTC) FILETIME=[19DC44A0:01C2598A] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA04932 6to4 assumes a NAT is not in the way of the relay. Teredo addresses the case where there is a NAT in the way. And why I think Teredo is very important to work on from v6 operations perspective. I have NAT in my home (I know I know) and can see Teredo or daughter of Teredo (that not being defined) helping me in my home. 6to4 won't work my ISP don't have the address space to give each of us the v4 addr space. DSTM has the same problem and ISATAP would only have private address to help me out. Teredo gives me some chance without completely blowing my network away. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, September 11, 2002 7:00 AM > To: Francis Dupont > Cc: Brian E Carpenter; Pekka Savola; v6ops@ops.ietf.org > Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] > > > >> We are still missing an RFC really analysing host-based 6to4, > >> and until that work has been done we don't know what is bogus. > > a new work item for the v6ops WG? > > how is this different from what shipworm is trying to solve? > > randy > > > From owner-v6ops@ops.ietf.org Wed Sep 11 08:04:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05376 for ; Wed, 11 Sep 2002 08:04:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p6Fo-000EcB-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 05:05:56 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17p6Fk-000Ebu-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 05:05:52 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8D2E55BBB; Wed, 11 Sep 2002 08:05:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 11 Sep 2002 08:05:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) Date: Wed, 11 Sep 2002 08:05:51 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91B6@tayexc13.americas.cpqcorp.net> Thread-Topic: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJZc+XVz6Z51txzRFCNrJbc92PmXAAF0VWA From: "Bound, Jim" To: "Brian E Carpenter" Cc: "Hesham Soliman (EAB)" , "Margaret Wasserman" , X-OriginalArrivalTime: 11 Sep 2002 12:05:51.0383 (UTC) FILETIME=[928CEA70:01C2598B] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA05376 Brian, from rfc 3056: The below is punting. It did not give examples, it does not discuss ramifications of policy, it does not have applicability statement it just says BGP+ is being used as standard. Based on what we have to do today to get through the IESG loop with new specs this is punting. Also Sowmini and I beat on this and wanted diagrams but we gave up. It also affects the relay routers too if they happen to be egress routers. So it did punt. /jim 5.2.2.1. BGP4+ not used If BGP4+ is not deployed in the 6to4 exterior routing domain (option 2.1 of Section 5.2), the relay router will be configured to accept and relay all IPv6 traffic only from its client 6to4 sites. Each 6to4 router served by the relay router will be configured with a default IPv6 route to the relay router (for example, Site A's default IPv6 route ::/0 would point to the relay router's address under prefix 2002:09fe:fdfc::/48). 5.2.2.2. BGP4+ used If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2 of Section 5.2), the relay router advertises IPv6 native routing prefixes on its 6to4 pseudo-interface, peering only with the 6to4 routers that it serves. (An alternative is that these routes could be advertised along with IPv4 routes using BGP4 over IPv4, rather than by running a separate BGP4+ session.) The specific routes advertised depend on applicable routing policy, but they must be chosen from among those reachable through the relay router's native IPv6 interface. In the simplest case, a default route to the whole IPv6 address space could be advertised. When multiple relay routers are in use, more specific routing prefixes would be advertised according to the desired routing policy. The usage of BGP4+ is completely standard so is not discussed further in this document. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, September 11, 2002 5:16 AM > To: Bound, Jim > Cc: Hesham Soliman (EAB); Margaret Wasserman; v6ops@ops.ietf.org > Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > I don't agree that RFC 3056 punts on BGP. It's quite explicit about > how relays should use BGP4+. > > Brian > > "Bound, Jim" wrote: > > > > Brian, > > > > That is not what should happen. And we may need this > within V6ops per Hesham's many explanations. Also 6to4 punts > on BGP and it could be we need this as adjunct for 6to4 and > we should at least look at this in V6ops. > > > > I also came to the same conclusion of the serendipity of > 6to4 in these times. 6to4 would potentially be dead in V6ops > too if it did not have and RFC number. > > > > And lastly I think all transition work that does not fit > with V6ops requires its own focus not within the routing > area. What Hesham asks for is required TODAY not tomorrow. > We need possibly the "advanced transition working group" but > I have not given up on V6ops either and we will see at the > Interim meeting. > > > > regards, > > /jim > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Sunday, September 08, 2002 10:27 AM > > > To: Hesham Soliman (EAB) > > > Cc: 'Margaret Wasserman '; 'v6ops@ops.ietf.org '; > > > 'ngtrans@sunroof.eng.sun.com ' > > > Subject: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > > > > > > > "Hesham Soliman (EAB)" wrote: > > > ... > > > > Let me give you an example, if > > > > 6to4 was written now, it would have suffered the same > > > > destiny as ISATAP or BGP-based tunnelling. But because > > > > it was written a long time ago, it is actually an > > > > RFC. I'm not sure that 6to4 is a better solution > > > > for inter-domain tunnelling than BGP-based tunnels. > > > > > > I think the historical fact is that the BGP-based tunneling > > > proposal emerged later than 6to4 *because* 6to4 talks quite a > > > bit about using BGP to make 6to4 work properly in an IDR > > > context. And of course BGP will work with other methods of > > > prefix assignment too. > > > > > > If it isn't in the v6ops charter, just develop it as an > > > individual submission to the routing area. > > > > > > Brian > > > > From owner-v6ops@ops.ietf.org Wed Sep 11 11:01:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11918 for ; Wed, 11 Sep 2002 11:01:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p8yw-000OkW-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 08:00:42 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17p8ys-000OkL-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 08:00:38 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p8yq-0005i7-00; Wed, 11 Sep 2002 16:00:36 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17p8yq-0005i2-00; Wed, 11 Sep 2002 16:00:36 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA42148; Wed, 11 Sep 2002 16:00:34 +0100 Message-ID: <3D7F5AA2.EF179C73@hursley.ibm.com> Date: Wed, 11 Sep 2002 17:00:50 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Bound, Jim" CC: "Hesham Soliman (EAB)" , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91B6@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We'll have to agree to disagree. I think that text is necessary and sufficient for a standard; but undoubtedly a BCP is needed as well, to cover the scenarios and examples. Such a BCP would be a fine work product of an operations WG, I think. Brian "Bound, Jim" wrote: > > Brian, > > from rfc 3056: The below is punting. It did not give examples, it does not discuss ramifications of policy, it does not have applicability statement it just says BGP+ is being used as standard. Based on what we have to do today to get through the IESG loop with new specs this is punting. Also Sowmini and I beat on this and wanted diagrams but we gave up. It also affects the relay routers too if they happen to be egress routers. > > So it did punt. > > /jim > > 5.2.2.1. BGP4+ not used > > If BGP4+ is not deployed in the 6to4 exterior routing domain (option > 2.1 of Section 5.2), the relay router will be configured to accept > and relay all IPv6 traffic only from its client 6to4 sites. Each > 6to4 router served by the relay router will be configured with a > default IPv6 route to the relay router (for example, Site A's default > IPv6 route ::/0 would point to the relay router's address under > prefix 2002:09fe:fdfc::/48). > > 5.2.2.2. BGP4+ used > > If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2 > of Section 5.2), the relay router advertises IPv6 native routing > prefixes on its 6to4 pseudo-interface, peering only with the 6to4 > routers that it serves. (An alternative is that these routes could > be advertised along with IPv4 routes using BGP4 over IPv4, rather > than by running a separate BGP4+ session.) The specific routes > advertised depend on applicable routing policy, but they must be > chosen from among those reachable through the relay router's native > IPv6 interface. In the simplest case, a default route to the whole > IPv6 address space could be advertised. When multiple relay routers > are in use, more specific routing prefixes would be advertised > according to the desired routing policy. The usage of BGP4+ is > completely standard so is not discussed further in this document. > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Wednesday, September 11, 2002 5:16 AM > > To: Bound, Jim > > Cc: Hesham Soliman (EAB); Margaret Wasserman; v6ops@ops.ietf.org > > Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > > > > I don't agree that RFC 3056 punts on BGP. It's quite explicit about > > how relays should use BGP4+. > > > > Brian > > > > "Bound, Jim" wrote: > > > > > > Brian, > > > > > > That is not what should happen. And we may need this > > within V6ops per Hesham's many explanations. Also 6to4 punts > > on BGP and it could be we need this as adjunct for 6to4 and > > we should at least look at this in V6ops. > > > > > > I also came to the same conclusion of the serendipity of > > 6to4 in these times. 6to4 would potentially be dead in V6ops > > too if it did not have and RFC number. > > > > > > And lastly I think all transition work that does not fit > > with V6ops requires its own focus not within the routing > > area. What Hesham asks for is required TODAY not tomorrow. > > We need possibly the "advanced transition working group" but > > I have not given up on V6ops either and we will see at the > > Interim meeting. > > > > > > regards, > > > /jim > > > > > > > -----Original Message----- > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: Sunday, September 08, 2002 10:27 AM > > > > To: Hesham Soliman (EAB) > > > > Cc: 'Margaret Wasserman '; 'v6ops@ops.ietf.org '; > > > > 'ngtrans@sunroof.eng.sun.com ' > > > > Subject: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > > > > > > > > > > "Hesham Soliman (EAB)" wrote: > > > > ... > > > > > Let me give you an example, if > > > > > 6to4 was written now, it would have suffered the same > > > > > destiny as ISATAP or BGP-based tunnelling. But because > > > > > it was written a long time ago, it is actually an > > > > > RFC. I'm not sure that 6to4 is a better solution > > > > > for inter-domain tunnelling than BGP-based tunnels. > > > > > > > > I think the historical fact is that the BGP-based tunneling > > > > proposal emerged later than 6to4 *because* 6to4 talks quite a > > > > bit about using BGP to make 6to4 work properly in an IDR > > > > context. And of course BGP will work with other methods of > > > > prefix assignment too. > > > > > > > > If it isn't in the v6ops charter, just develop it as an > > > > individual submission to the routing area. > > > > > > > > Brian > > > > > > From owner-v6ops@ops.ietf.org Wed Sep 11 11:14:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12468 for ; Wed, 11 Sep 2002 11:14:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17p9Di-000PlV-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 08:15:58 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17p9De-000PlI-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 08:15:54 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 43CF44575; Wed, 11 Sep 2002 11:15:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 11 Sep 2002 11:15:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) Date: Wed, 11 Sep 2002 11:15:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91C6@tayexc13.americas.cpqcorp.net> Thread-Topic: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) Thread-Index: AcJZpAeN7HieUQ1bQ/e0pkznQT3v3AAAdcnQ From: "Bound, Jim" To: "Brian E Carpenter" Cc: "Hesham Soliman (EAB)" , "Margaret Wasserman" , X-OriginalArrivalTime: 11 Sep 2002 15:15:52.0879 (UTC) FILETIME=[1E5F23F0:01C259A6] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12468 I think it is good to agree to disagree and move on 1000% agree. In fact we would all get more done and move on if we could all do this and simply admit it. I agree completely this is a real good work item for new v6ops and could even suggest tools for use within 6to4 as BCP. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Wednesday, September 11, 2002 11:01 AM > To: Bound, Jim > Cc: Hesham Soliman (EAB); Margaret Wasserman; v6ops@ops.ietf.org > Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > We'll have to agree to disagree. I think that text is necessary and > sufficient for a standard; but undoubtedly a BCP is needed as > well, to > cover the scenarios and examples. Such a BCP would be a fine work > product of an operations WG, I think. > > Brian > > "Bound, Jim" wrote: > > > > Brian, > > > > from rfc 3056: The below is punting. It did not give > examples, it does not discuss ramifications of policy, it > does not have applicability statement it just says BGP+ is > being used as standard. Based on what we have to do today to > get through the IESG loop with new specs this is punting. > Also Sowmini and I beat on this and wanted diagrams but we > gave up. It also affects the relay routers too if they > happen to be egress routers. > > > > So it did punt. > > > > /jim > > > > 5.2.2.1. BGP4+ not used > > > > If BGP4+ is not deployed in the 6to4 exterior routing > domain (option > > 2.1 of Section 5.2), the relay router will be configured > to accept > > and relay all IPv6 traffic only from its client 6to4 sites. Each > > 6to4 router served by the relay router will be configured with a > > default IPv6 route to the relay router (for example, > Site A's default > > IPv6 route ::/0 would point to the relay router's address under > > prefix 2002:09fe:fdfc::/48). > > > > 5.2.2.2. BGP4+ used > > > > If BGP4+ is deployed in the 6to4 exterior routing domain > (option 2.2 > > of Section 5.2), the relay router advertises IPv6 native routing > > prefixes on its 6to4 pseudo-interface, peering only with the 6to4 > > routers that it serves. (An alternative is that these > routes could > > be advertised along with IPv4 routes using BGP4 over IPv4, rather > > than by running a separate BGP4+ session.) The specific routes > > advertised depend on applicable routing policy, but they must be > > chosen from among those reachable through the relay > router's native > > IPv6 interface. In the simplest case, a default route > to the whole > > IPv6 address space could be advertised. When multiple > relay routers > > are in use, more specific routing prefixes would be advertised > > according to the desired routing policy. The usage of BGP4+ is > > completely standard so is not discussed further in this document. > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Wednesday, September 11, 2002 5:16 AM > > > To: Bound, Jim > > > Cc: Hesham Soliman (EAB); Margaret Wasserman; v6ops@ops.ietf.org > > > Subject: Re: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > > > > > > > I don't agree that RFC 3056 punts on BGP. It's quite > explicit about > > > how relays should use BGP4+. > > > > > > Brian > > > > > > "Bound, Jim" wrote: > > > > > > > > Brian, > > > > > > > > That is not what should happen. And we may need this > > > within V6ops per Hesham's many explanations. Also 6to4 punts > > > on BGP and it could be we need this as adjunct for 6to4 and > > > we should at least look at this in V6ops. > > > > > > > > I also came to the same conclusion of the serendipity of > > > 6to4 in these times. 6to4 would potentially be dead in V6ops > > > too if it did not have and RFC number. > > > > > > > > And lastly I think all transition work that does not fit > > > with V6ops requires its own focus not within the routing > > > area. What Hesham asks for is required TODAY not tomorrow. > > > We need possibly the "advanced transition working group" but > > > I have not given up on V6ops either and we will see at the > > > Interim meeting. > > > > > > > > regards, > > > > /jim > > > > > > > > > -----Original Message----- > > > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > > Sent: Sunday, September 08, 2002 10:27 AM > > > > > To: Hesham Soliman (EAB) > > > > > Cc: 'Margaret Wasserman '; 'v6ops@ops.ietf.org '; > > > > > 'ngtrans@sunroof.eng.sun.com ' > > > > > Subject: (ngtrans) Re: WG Review: IPv6 Operations (v6ops) > > > > > > > > > > > > > > > "Hesham Soliman (EAB)" wrote: > > > > > ... > > > > > > Let me give you an example, if > > > > > > 6to4 was written now, it would have suffered the same > > > > > > destiny as ISATAP or BGP-based tunnelling. But because > > > > > > it was written a long time ago, it is actually an > > > > > > RFC. I'm not sure that 6to4 is a better solution > > > > > > for inter-domain tunnelling than BGP-based tunnels. > > > > > > > > > > I think the historical fact is that the BGP-based tunneling > > > > > proposal emerged later than 6to4 *because* 6to4 talks quite a > > > > > bit about using BGP to make 6to4 work properly in an IDR > > > > > context. And of course BGP will work with other methods of > > > > > prefix assignment too. > > > > > > > > > > If it isn't in the v6ops charter, just develop it as an > > > > > individual submission to the routing area. > > > > > > > > > > Brian > > > > > > > > > From owner-v6ops@ops.ietf.org Wed Sep 11 13:00:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16486 for ; Wed, 11 Sep 2002 13:00:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pArI-0006uo-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 10:00:56 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17pArF-0006ud-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 10:00:53 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA22658 for ; Wed, 11 Sep 2002 10:00:51 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8BH0kc11579 for ; Wed, 11 Sep 2002 10:00:46 -0700 X-mProtect: <200209111700> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQvjtaw; Wed, 11 Sep 2002 10:00:44 PDT Message-ID: <3D7F79EE.6000608@iprg.nokia.com> Date: Wed, 11 Sep 2002 10:14:22 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: 6to4 MRU - still need WG consensus Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, Since you are clearly trying to keep this thread brief and on-topic, it seems to me that the fundamental assumptions need to be outlined so that the community can make an informed decision. Let me list a few below; please correct any mistakes or add any additional assumptions I may be missing: 1) 6to4 interfaces will send IPv6-in-IPv4 packets with the "do not fragment" bit NOT set in the IPv4 header 2) 6to4 interfaces will set a fixed-value MTU and MRU such that MTU <= MRU 3) the 6to4 encapsulator need not implement any mechanism to dynamically discover the MRU of the decapsulator (perhaps this is self-evident from 2)? ) 4) IPv6 path MTU discovery is disabled for 6to4 interfaces Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Sep 11 13:50:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18834 for ; Wed, 11 Sep 2002 13:50:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pBf0-000AkA-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 10:52:18 -0700 Received: from [2002:425c:4242:0:250:baff:fed6:3875] (helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17pBew-000Afx-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 10:52:14 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1F607198A for ; Wed, 11 Sep 2002 13:51:43 -0400 (EDT) Date: Wed, 11 Sep 2002 13:51:43 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-Reply-To: References: <3D7F042E.A7CFB6CE@hursley.ibm.com> <200209110857.g8B8vp6o079986@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020911175143.1F607198A@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Wed, 11 Sep 2002 03:59:41 -0700, Randy Bush wrote: > > >> We are still missing an RFC really analysing host-based 6to4, > >> and until that work has been done we don't know what is bogus. > > a new work item for the v6ops WG? > > how is this different from what shipworm is trying to solve? Shipworm has a lower required density of global IPv4 addresses; host-based-6to4 has less reliance on middleboxes. From owner-v6ops@ops.ietf.org Thu Sep 12 02:46:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14523 for ; Thu, 12 Sep 2002 02:46:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pNjv-000Fli-00 for v6ops-data@psg.com; Wed, 11 Sep 2002 23:46:11 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17pNjr-000FlX-00 for v6ops@ops.ietf.org; Wed, 11 Sep 2002 23:46:07 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8C6jx212424; Thu, 12 Sep 2002 09:46:00 +0300 Date: Thu, 12 Sep 2002 09:45:59 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: Re: access to temp addrs in DSTM In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9197@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (To this and your previous/next comments on technical details.) I'll re-review the spec (and revisit my comments) on the flight to v6ops next week. On Tue, 10 Sep 2002, Bound, Jim wrote: > Pekka, > > As a note we made it clear in dstm that at this point one can use any > addr mgmt they choose to and will be specific specs to be done for DSTM. > So if one want to use dhcpv4, or a version of it, or RPC or DHCPv6 its > pretty open. > > /jim > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 12 07:26:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19292 for ; Thu, 12 Sep 2002 07:26:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pS77-0003me-00 for v6ops-data@psg.com; Thu, 12 Sep 2002 04:26:25 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17pS74-0003mT-00 for v6ops@ops.ietf.org; Thu, 12 Sep 2002 04:26:22 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 83F7B470D; Thu, 12 Sep 2002 07:26:21 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Sep 2002 07:26:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: access to temp addrs in DSTM Date: Thu, 12 Sep 2002 07:26:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91EC@tayexc13.americas.cpqcorp.net> Thread-Topic: access to temp addrs in DSTM Thread-Index: AcJaKBO2pyX+bcybQ9mvAnxTYPqRMQAJwvfA From: "Bound, Jim" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 12 Sep 2002 11:26:21.0546 (UTC) FILETIME=[386E3CA0:01C25A4F] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA19292 Hi, Thats very nice of you all of us coauthors will look forward to it. thanks /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, September 12, 2002 2:46 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: access to temp addrs in DSTM > > > Hi, > > (To this and your previous/next comments on technical details.) > > I'll re-review the spec (and revisit my comments) on the > flight to v6ops > next week. > > On Tue, 10 Sep 2002, Bound, Jim wrote: > > Pekka, > > > > As a note we made it clear in dstm that at this point one > can use any > > addr mgmt they choose to and will be specific specs to be > done for DSTM. > > So if one want to use dhcpv4, or a version of it, or RPC or > DHCPv6 its > > pretty open. > > > > /jim > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > From owner-v6ops@ops.ietf.org Thu Sep 12 09:01:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21944 for ; Thu, 12 Sep 2002 09:01:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pTb3-0009N0-00 for v6ops-data@psg.com; Thu, 12 Sep 2002 06:01:25 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17pTax-0009M0-00 for v6ops@ops.ietf.org; Thu, 12 Sep 2002 06:01:19 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTaw-0002yX-00; Thu, 12 Sep 2002 14:01:18 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTaw-0002yS-00; Thu, 12 Sep 2002 14:01:18 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA18868; Thu, 12 Sep 2002 14:01:16 +0100 Message-ID: <3D80902D.77C69F5F@hursley.ibm.com> Date: Thu, 12 Sep 2002 15:01:33 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Fred L. Templin" CC: v6ops@ops.ietf.org Subject: Re: 6to4 MRU - still need WG consensus References: <3D7F79EE.6000608@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Fred L. Templin" wrote: > > Brian, > > Since you are clearly trying to keep this thread brief and on-topic, > it seems to me that the fundamental assumptions need to be outlined > so that the community can make an informed decision. Let me list a > few below; please correct any mistakes or add any additional > assumptions I may be missing: > > 1) 6to4 interfaces will send IPv6-in-IPv4 packets with the > "do not fragment" bit NOT set in the IPv4 header This is a SHOULD NOT in RFC 3056, in case there are any corner cases where it would be useful to set the bit. > > 2) 6to4 interfaces will set a fixed-value MTU and MRU such > that MTU <= MRU MTU <= MRU by definition. I would expect link MTU = 1480 to be normal, but there is no need to specify it separately for 6to4. > > 3) the 6to4 encapsulator need not implement any mechanism to > dynamically discover the MRU of the decapsulator (perhaps > this is self-evident from 2)? ) There's no MRU discovery mechanism except telephoning or smoke signals anyway. > > 4) IPv6 path MTU discovery is disabled for 6to4 interfaces Why would you do that? There is nothing very special about a 6to4 pseudo-interface; it inherits everything from RFC 2460 and RFC 2893 that isn't specifically called out in RFC 3056. Brian From owner-v6ops@ops.ietf.org Thu Sep 12 09:05:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22122 for ; Thu, 12 Sep 2002 09:05:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pTfe-0009jB-00 for v6ops-data@psg.com; Thu, 12 Sep 2002 06:06:10 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17pTfb-0009ix-00 for v6ops@ops.ietf.org; Thu, 12 Sep 2002 06:06:07 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTfa-00034E-00; Thu, 12 Sep 2002 14:06:06 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTfa-000347-00; Thu, 12 Sep 2002 14:06:06 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA39674; Thu, 12 Sep 2002 14:05:55 +0100 Message-ID: <3D809144.2D8357FC@hursley.ibm.com> Date: Thu, 12 Sep 2002 15:06:12 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: <20020911090310.B5F987B9@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: > > >The specification that the IETF actually approved was for router-based > >6to4, not host-based, and it was assumed that router operators would > >club together to configure and share relays. Clearly, a client-host > > WinXP node can become a router, so there's nothing prohibiting WinXP > from running 6to4. in fact, i don't see any distinction between > "router-based 6to4" and "host-based 6to4" in the RFC. am i mistaken? From the Introduction to RFC 3056: > The basic mechanism described in the present document, which applies > to sites rather than individual hosts, will scale indefinitely by > limiting the number of sites served by a given relay router (see > Section 5.2). It will introduce no new entries in the IPv4 routing > table, and exactly one new entry in the native IPv6 routing table > (see Section 5.10). > > Although the mechanism is specified for an IPv6 site, it can equally > be applied to an individual IPv6 host or very small site, as long as > it has at least one globally unique IPv4 address. However, the > latter case raises serious scaling issues which are the subject of > further study [SCALE]. Brian From owner-v6ops@ops.ietf.org Thu Sep 12 09:12:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22422 for ; Thu, 12 Sep 2002 09:12:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pTnc-000ACZ-00 for v6ops-data@psg.com; Thu, 12 Sep 2002 06:14:24 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17pTnV-000ABz-00 for v6ops@ops.ietf.org; Thu, 12 Sep 2002 06:14:17 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTnU-0003E1-00; Thu, 12 Sep 2002 14:14:16 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pTnU-0003Dw-00; Thu, 12 Sep 2002 14:14:16 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA39526; Thu, 12 Sep 2002 14:14:15 +0100 Message-ID: <3D809338.3C388A9A@hursley.ibm.com> Date: Thu, 12 Sep 2002 15:14:32 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Rob Austein CC: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: <3D7F042E.A7CFB6CE@hursley.ibm.com> <200209110857.g8B8vp6o079986@givry.rennes.enst-bretagne.fr> <20020911175143.1F607198A@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > > At Wed, 11 Sep 2002 03:59:41 -0700, Randy Bush wrote: > > > > >> We are still missing an RFC really analysing host-based 6to4, > > >> and until that work has been done we don't know what is bogus. > > > a new work item for the v6ops WG? > > > > how is this different from what shipworm is trying to solve? > > Shipworm has a lower required density of global IPv4 addresses; > host-based-6to4 has less reliance on middleboxes. Also (this is what Jim's reply was getting at too), 6to4 assumes that it is implemented *in* a router (or NAT/router) whereas Teredo assumes it has to traverse an uncooperative NAT. 6to4 simply fails if it is *behind* a NAT. It wasn't aimed at that scenario. It wasn't designed as a host solution, so NAT traversal was not a requirement. So when you hammer 6to4 into a host, there are cases where it simply cannot work. Brian Brian From owner-v6ops@ops.ietf.org Thu Sep 12 09:49:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23492 for ; Thu, 12 Sep 2002 09:49:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pUN0-000Chv-00 for v6ops-data@psg.com; Thu, 12 Sep 2002 06:50:58 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17pUMx-000Chk-00 for v6ops@ops.ietf.org; Thu, 12 Sep 2002 06:50:55 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8CDna012384; Thu, 12 Sep 2002 09:49:36 -0400 (EDT) Message-Id: <200209121349.g8CDna012384@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Rob Austein , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-reply-to: (Your message of "Thu, 12 Sep 2002 15:14:32 +0200.") <3D809338.3C388A9A@hursley.ibm.com> Date: Thu, 12 Sep 2002 09:49:36 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > So when you hammer 6to4 > into a host, there are cases where it simply cannot work. I use 6to4 on hosts every day, so I don't consider it hammering. But 6to4 was primariliy intended for routers. That it happens to work on some hosts is a happy side-benefit, not the design goal. Keith From owner-v6ops@ops.ietf.org Thu Sep 12 10:28:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24643 for ; Thu, 12 Sep 2002 10:28:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pUxl-000FBY-00 for v6ops-data@psg.com; Thu, 12 Sep 2002 07:28:57 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17pUxi-000FBN-00 for v6ops@ops.ietf.org; Thu, 12 Sep 2002 07:28:54 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3F81D2896; Thu, 12 Sep 2002 10:28:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Sep 2002 10:28:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Date: Thu, 12 Sep 2002 10:28:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91FA@tayexc13.americas.cpqcorp.net> Thread-Topic: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Thread-Index: AcJaXWrcF37LcHASQLiN3QGbIWf12wACw9jw From: "Bound, Jim" To: "Brian E Carpenter" , "Jun-ichiro itojun Hagino" Cc: "Pekka Savola" , X-OriginalArrivalTime: 12 Sep 2002 14:28:53.0169 (UTC) FILETIME=[B81B4A10:01C25A68] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA24643 note T64 can do the routing too and the relay as a host and we have customers using it. that will be done on hp-ux too. but we turn on interface as router according to ND rules. we use this to assist our routing partners for v6 deployment. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Thursday, September 12, 2002 9:06 AM > To: Jun-ichiro itojun Hagino > Cc: Pekka Savola; v6ops@ops.ietf.org > Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] > > > Jun-ichiro itojun Hagino wrote: > > > > >The specification that the IETF actually approved was for > router-based > > >6to4, not host-based, and it was assumed that router > operators would > > >club together to configure and share relays. Clearly, a client-host > > > > WinXP node can become a router, so there's nothing > prohibiting WinXP > > from running 6to4. in fact, i don't see any > distinction between > > "router-based 6to4" and "host-based 6to4" in the > RFC. am i mistaken? > > From the Introduction to RFC 3056: > > > The basic mechanism described in the present document, > which applies > > to sites rather than individual hosts, will scale indefinitely by > > limiting the number of sites served by a given relay router (see > > Section 5.2). It will introduce no new entries in the > IPv4 routing > > table, and exactly one new entry in the native IPv6 routing table > > (see Section 5.10). > > > > Although the mechanism is specified for an IPv6 site, it > can equally > > be applied to an individual IPv6 host or very small > site, as long as > > it has at least one globally unique IPv4 address. However, the > > latter case raises serious scaling issues which are the > subject of > > further study [SCALE]. > > Brian > > From owner-v6ops@ops.ietf.org Thu Sep 12 11:18:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26443 for ; Thu, 12 Sep 2002 11:18:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pVl5-000Ir9-00 for v6ops-data@psg.com; Thu, 12 Sep 2002 08:19:55 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17pVkx-000Iqw-00 for v6ops@ops.ietf.org; Thu, 12 Sep 2002 08:19:47 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pVkr-0006ey-00; Thu, 12 Sep 2002 16:19:41 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pVkq-0006et-00; Thu, 12 Sep 2002 16:19:40 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA56134; Thu, 12 Sep 2002 16:19:39 +0100 Message-ID: <3D80B09C.99B05F66@hursley.ibm.com> Date: Thu, 12 Sep 2002 17:19:56 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Keith Moore CC: Rob Austein , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: <200209121349.g8CDna012384@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > > > So when you hammer 6to4 > > into a host, there are cases where it simply cannot work. > > I use 6to4 on hosts every day, so I don't consider it hammering. > > But 6to4 was primariliy intended for routers. That it happens > to work on some hosts is a happy side-benefit, not the design goal. Indeed. Brian From owner-v6ops@ops.ietf.org Fri Sep 13 03:10:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27120 for ; Fri, 13 Sep 2002 03:10:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pkaw-0008ND-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 00:10:26 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17pkas-0008MZ-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 00:10:22 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pkaq-0007WW-00; Fri, 13 Sep 2002 08:10:20 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17pkaq-0007WR-00; Fri, 13 Sep 2002 08:10:20 +0100 Received: from hursley.ibm.com (dhcp23-199.zurich.ibm.com [9.4.23.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA26806; Fri, 13 Sep 2002 08:10:18 +0100 Message-ID: <3D818F6A.67F63BB4@hursley.ibm.com> Date: Fri, 13 Sep 2002 09:10:34 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Tony Hain CC: IPv6 Operations Subject: Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus] References: <01ae01c25a89$7f65c2b0$011aa8c0@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Having read the subsequent discussion, I'm of the view that this (and not a larger MRU) is the appropriate thing to specify. I suspect we are begining to need a 6to4 operational BCP, where this could fit. But we'd need someone with cycles to work on it. And I've switched this to v6ops. Brian Tony Hain wrote: > > Am I detecting convergence??? > > All 6to4 implementations SHOULD send IPv6 PMTU exceeded messages > whenever the wrapping IPv4 packet is discarded due to excessive size. In > addition, all 6to4 implementations MUST configure a 6to4 MRU of at least > 1480, but SHOULD have an MRU at least as large as the IPv4 physical > interface MTU. > > If that text is acceptable, which document does it belong in? Logically > it would belong in a rev to 3056, but if we open that document is this > the only pending change? I assume we want to get this out in RFC form > quickly, so I wouldn't want it to get stuck because it was part of a > lengthy document. > > Tony > > > -----Original Message----- > > From: owner-ngtrans@sunroof.eng.sun.com > > [mailto:owner-ngtrans@sunroof.eng.sun.com] On Behalf Of Robert Elz > > Sent: Thursday, September 12, 2002 12:08 AM > > To: Fred L. Templin > > Cc: ngtrans@sunroof.eng.sun.com > > Subject: Re: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - > > need WG consensus] > > > > > > Date: Wed, 11 Sep 2002 09:35:49 -0700 > > From: "Fred L. Templin" > > Message-ID: <3D7F70E5.2080604@iprg.nokia.com> > > > > | Don't most modern systems support a socket > > | abstraction similar to the Berkeley Packet Filter (bpf)? If so, > > | an application can write a simple filter to receive IPv4 > > fragments [...] > > > > Yes, other than for embedded systems, where nothing new is > > ever going get added (but where a 6to4 implementation could > > probably get slotted into the frag code with no issues), > > you're probably right. > > > > If everyone could implement Christian's idea, that's great. > > My point was > > more that we don't have to prove that they can, as long as we > > don't set the required MTU too high. > > > > And that's OK, we don't need the 64K that was suggested (by > > you?) - packets to be transmitted by 6to4 can't be bigger > > than the PMTU anyway (or at least the PMTU up to the 6to4 > > box), and that's truly unlikely to get huge anytime soon (and > > even if it did, because the 6to4 box is very close to the > > source, the packets would only get blocked soon after > > emerging). I certainly don't think we should be promoting > > 6to4 as an end to end protocol that sources can use to > > transmit directly to recipients, just so they can get an IPv6 > > MTU that's huge, that they wouldn't be able to use on any > > real links they have available. > > > > All we need is an MRU big enough to cope with paths that > > might reasonably > > be achieved in the reasonable lifetime of the IPv4 net. In > > the past 15 > > years, the achievable MTU over typical paths has about > > tripled (not in small > > increments of course, but in big jumps). So, assuming that over the > > next 15 years it might triple again seems reasonable to me > > (if we're off by a bit, who cares - if it doesn't get that > > big, the harm is almost irrelevant, if it gets bigger then we > > won't be able to use all that is available, but at least we > > shouldn't still be sending tinygrams, which 1280 would be). > > > > So, I think 4664 is big enough, while also being small enough > > that we don't have to care whether or not there's some > > implementation that can't implement Christian's idea (or > > can't do it reasonably) and for which the specified MRU is > > too big to handle. > > > > kre > > From owner-v6ops@ops.ietf.org Fri Sep 13 07:53:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01697 for ; Fri, 13 Sep 2002 07:53:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pp23-000GQa-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 04:54:43 -0700 Received: from roam.psg.com ([193.0.9.125]) by psg.com with esmtp (Exim 3.36 #1) id 17pp1v-000GQI-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 04:54:37 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17pp1u-0001pR-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 14:54:34 +0300 Message-Id: <200209131144.HAA01400@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 Subject: I-D ACTION:draft-mickles-v6ops-isp-cases-01.txt Date: Fri, 13 Sep 2002 07:44:32 -0400 X-Spam-Status: No, hits=4.9 required=5.0 tests=TO_MALFORMED,NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transition Scenarios for ISP Networks Author(s) : C. Mickles Filename : draft-mickles-v6ops-isp-cases-01.txt Pages : 20 Date : 2002-9-12 This document describes the different types of Internet Service Provider (ISP) networks in existence today. It will provide design and operational considerations in delivering network services to customers for five specific areas in an effort to better identify specific issues which may arise during a transition to IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-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-mickles-v6ops-isp-cases-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-mickles-v6ops-isp-cases-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: <2002-9-12143605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mickles-v6ops-isp-cases-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-mickles-v6ops-isp-cases-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-12143605.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Fri Sep 13 10:45:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07774 for ; Fri, 13 Sep 2002 10:45:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17prhF-000MLv-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 07:45:25 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17prhC-000MLk-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 07:45:22 -0700 Received: from kenawang.windriver.com ([147.11.233.34]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA14081 for ; Fri, 13 Sep 2002 07:44:49 -0700 (PDT) Message-Id: <5.1.0.14.2.20020913104036.01c432c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 13 Sep 2002 10:45:13 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Updated Interim Meeting Info Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi All, I have updated the interim meeting information to include the approved WG charter, the final agenda and the final attendee list. The updated information can be found at: http://home.attbi.com/~margaretw/v6ops-Interim-Sep02.html The new agenda includes URLs for all of the documents that we expect to discuss. Please try to read the documents before the meeting, so we can use our meeting time as effectively as possible. Thanks, Margaret From owner-v6ops@ops.ietf.org Fri Sep 13 14:55:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15671 for ; Fri, 13 Sep 2002 14:55:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pvax-0004UG-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 11:55:11 -0700 Received: from x98a3a513.pix.aol.com ([152.163.165.19] helo=mailbox.office.aol.com) by psg.com with esmtp (Exim 3.36 #1) id 17pvat-0004U3-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 11:55:07 -0700 Received: from pcsn630877 ([10.0.198.12]) by mailbox.office.aol.com (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id OAA24630; Fri, 13 Sep 2002 14:54:53 -0400 (EDT) Reply-To: From: "Cleve Mickles" To: Subject: RE: I-D ACTION:draft-mickles-v6ops-isp-cases-01.txt Date: Fri, 13 Sep 2002 14:54:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200209131144.HAA01400@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-0.1 required=5.0 tests=IN_REP_TO,EXCUSE_6,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Only one section of the draft has been updated. If any of you have experience with DSL deployments please take a look and send comments to the list or myself. Thanks, Cleve... > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Internet-Drafts@ietf.org > Sent: Friday, September 13, 2002 7:45 AM > To: IETF-Announce: > Cc: v6ops@ops.ietf.org > Subject: I-D ACTION:draft-mickles-v6ops-isp-cases-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Transition Scenarios for ISP Networks > Author(s) : C. Mickles > Filename : draft-mickles-v6ops-isp-cases-01.txt > Pages : 20 > Date : 2002-9-12 > > This document describes the different types of Internet Service > Provider (ISP) networks in existence today. It will provide design > and operational considerations in delivering network services to > customers for five specific areas in an effort to better identify > specific issues which may arise during a transition to IPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-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-mickles-v6ops-isp-cases-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-mickles-v6ops-isp-cases-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. > From owner-v6ops@ops.ietf.org Fri Sep 13 17:05:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18982 for ; Fri, 13 Sep 2002 17:05:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pxcF-0008o0-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 14:04:39 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17pxcB-0008np-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 14:04:36 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA23885; Fri, 13 Sep 2002 14:04:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8DL4WA27313; Fri, 13 Sep 2002 14:04:32 -0700 X-mProtect: <200209132104> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6LmFbg; Fri, 13 Sep 2002 14:04:30 PDT Message-ID: <3D82561D.1050708@iprg.nokia.com> Date: Fri, 13 Sep 2002 14:18:21 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: Keith Moore Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I use 6to4 on hosts every day, so I don't consider it hammering. > > But 6to4 was primariliy intended for routers. That it happens > to work on some hosts is a happy side-benefit, not the design goal. > > Keith If you want to run 6to4 on a host that happens to have a global IPv4 address and can accept 'ip-proto-41' w/o creating a security risk, then that is fine. But (and you seem to recognize this), if one wants to postulate a "generalized host-based 6to4" mechanism, that is a different matter and one that is not covered by any existing RFCs. To realize a "generalized host-based 6to4", one would need to incorporate the NAT traversal mechanisms first pioneered by TEREDO and the two-stage (end-to-edge; edge-to-internet) tunneling mechanism first pioneered by ISATAP. But, then this becomes more than just vanilla 6to4 and represents a unified transition mechanism that incorporates elements proven by earlier works in various degrees. Finally, a truly generalized mechanism would work behind a corporate firewall w/o requiring any per-host firewall filter configurations and w/o exposing the site to outside attackers. It's not clear to me whether a solution for this exists - but, it would be pretty interesting if one could be identified! Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Sep 13 17:55:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19940 for ; Fri, 13 Sep 2002 17:55:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pyPx-000AZK-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 14:56:01 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17pyPp-000AYf-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 14:55:53 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8DLsS018628; Fri, 13 Sep 2002 17:54:28 -0400 (EDT) Message-Id: <200209132154.g8DLsS018628@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fred L. Templin" cc: v6ops@ops.ietf.org, Keith Moore Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-reply-to: (Your message of "Fri, 13 Sep 2002 14:18:21 PDT.") <3D82561D.1050708@iprg.nokia.com> Date: Fri, 13 Sep 2002 17:54:28 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > I use 6to4 on hosts every day, so I don't consider it hammering. > > > > But 6to4 was primariliy intended for routers. That it happens > > to work on some hosts is a happy side-benefit, not the design goal. > > > > Keith > > If you want to run 6to4 on a host that happens to have a global IPv4 address > and can accept 'ip-proto-41' w/o creating a security risk, then that is fine. > But (and you seem to recognize this), if one wants to postulate a "generalized > host-based 6to4" mechanism, that is a different matter and one that is not > covered by any existing RFCs. > > To realize a "generalized host-based 6to4", one would need to incorporate the > NAT traversal mechanisms first pioneered by TEREDO and the two-stage (end-to-edge; > edge-to-internet) tunneling mechanism first pioneered by ISATAP. No, that's not "generalized host-based 6to4", that's "6to4 trying to accomodate NAT brain-damage". A solution which works well (okay, as well as possible) in the presence of NATs will be very sub-optimal between hosts whose communications is not hampered by NAT. Which is why something like 6to4 and something like Teredo are both needed. Keith From owner-v6ops@ops.ietf.org Fri Sep 13 19:25:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22042 for ; Fri, 13 Sep 2002 19:25:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pzo5-000Dca-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 16:25:01 -0700 Received: from [2002:4051:3012:1fff::dead:beef] (helo=pianosa.catch22.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 17pzo1-000Dc1-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 16:24:57 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id B124617; Fri, 13 Sep 2002 16:24:52 -0700 (PDT) Date: Fri, 13 Sep 2002 16:24:52 -0700 From: David Terrell To: Keith Moore Cc: "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Message-ID: <20020913232452.GB25262@pianosa.catch22.org> Reply-To: David Terrell References: <3D82561D.1050708@iprg.nokia.com> <200209132154.g8DLsS018628@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209132154.g8DLsS018628@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 4:01PM up 4 days, 4:02, 34 users, load averages: 0.78, 0.72, 0.60 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Sep 13, 2002 at 05:54:28PM -0400, Keith Moore wrote: >>To realize a "generalized host-based 6to4", one would need to >>incorporate the NAT traversal mechanisms first pioneered by TEREDO >>and the two-stage (end-to-edge; edge-to-internet) tunneling mechanism >>first pioneered by ISATAP. > >No, that's not "generalized host-based 6to4", that's "6to4 trying >to accomodate NAT brain-damage". A solution which works well (okay, >as well as possible) in the presence of NATs will be very sub-optimal >between hosts whose communications is not hampered by NAT. Which >is why something like 6to4 and something like Teredo are both needed. to diverge slightly on this topic, it would be kind of nice if 6to4 could turn into a more general transition mechanism for non-NAT servers; i.e. if many 6to4 aware machines could implicitly bind to 2002:ipv4::something[*], v6only servers could try to connect to that as an alternative to something like the site-local faith -- that could of course be a fallback for things that don't understand this mechanism ("implicit host-based 6to4"). I was hoping to zip out a draft on this behavior before the deadline but obviously I didn't make it. * - Someone mentioned that Win XP is listening on 2002:ipv4::ipv4? -- David Terrell | "War is peace, Prime Minister, Nebcorp | freedom is slavery, dbt@meat.net | ignorance is strength http://wwn.nebcorp.com/ | Dishes are clean." - Chris Fester From owner-v6ops@ops.ietf.org Fri Sep 13 19:26:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22063 for ; Fri, 13 Sep 2002 19:26:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pzr5-000Dhf-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 16:28:07 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17pzqx-000DhE-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 16:27:59 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8DNQV019106; Fri, 13 Sep 2002 19:26:31 -0400 (EDT) Message-Id: <200209132326.g8DNQV019106@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: David Terrell cc: Keith Moore , "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-reply-to: (Your message of "Fri, 13 Sep 2002 16:24:52 PDT.") <20020913232452.GB25262@pianosa.catch22.org> Date: Fri, 13 Sep 2002 19:26:31 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > if many 6to4 aware machines could implicitly bind to > 2002:ipv4::something[*], v6only servers could try to connect to > that as an alternative to something like the site-local faith -- unfortunately that constrains how sites organize their networks, which doesn't seem desirable. Keith From owner-v6ops@ops.ietf.org Fri Sep 13 19:28:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22087 for ; Fri, 13 Sep 2002 19:28:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pzt5-000Do2-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 16:30:11 -0700 Received: from [2002:4051:3012:1fff::dead:beef] (helo=pianosa.catch22.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 17pzt2-000Dnp-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 16:30:08 -0700 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 6031A37; Fri, 13 Sep 2002 16:30:06 -0700 (PDT) Date: Fri, 13 Sep 2002 16:30:06 -0700 From: David Terrell To: Keith Moore Cc: "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Message-ID: <20020913233005.GC25262@pianosa.catch22.org> Reply-To: David Terrell References: <20020913232452.GB25262@pianosa.catch22.org> <200209132326.g8DNQV019106@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209132326.g8DNQV019106@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 4:29PM up 4 days, 4:30, 29 users, load averages: 0.37, 0.66, 0.70 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Sep 13, 2002 at 07:26:31PM -0400, Keith Moore wrote: > > if many 6to4 aware machines could implicitly bind to > > 2002:ipv4::something[*], v6only servers could try to connect to > > that as an alternative to something like the site-local faith -- > > unfortunately that constrains how sites organize their networks, > which doesn't seem desirable. This would only be a potential method for IPv6-only sites to connect to a remote end for which you only have an IPv4 address -- if you don't want it, include an AAAA record. -- David Terrell | "Consumerism is neat." dbt@meat.net | - Brian Swetland http://wwn.nebcorp.com/ | From owner-v6ops@ops.ietf.org Fri Sep 13 19:35:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22187 for ; Fri, 13 Sep 2002 19:35:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17pzyu-000E3Y-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 16:36:12 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17pzyl-000E3K-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 16:36:03 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8DNYa019144; Fri, 13 Sep 2002 19:34:36 -0400 (EDT) Message-Id: <200209132334.g8DNYa019144@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: David Terrell cc: Keith Moore , "Fred L. Templin" , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-reply-to: (Your message of "Fri, 13 Sep 2002 16:30:06 PDT.") <20020913233005.GC25262@pianosa.catch22.org> Date: Fri, 13 Sep 2002 19:34:36 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > if many 6to4 aware machines could implicitly bind to > > > 2002:ipv4::something[*], v6only servers could try to connect to > > > that as an alternative to something like the site-local faith -- > > > > unfortunately that constrains how sites organize their networks, > > which doesn't seem desirable. > > This would only be a potential method for IPv6-only sites to connect > to a remote end for which you only have an IPv4 address -- if you > don't want it, include an AAAA record. okay, why is it better to impose such assumptions on hosts and nets (not to mention firewalls) "by default" (i.e. in the absence of an AAAA record) than to require them to declare their willingness to accept such traffic (by advertising an AAAA record)? Keith From owner-v6ops@ops.ietf.org Fri Sep 13 21:59:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23785 for ; Fri, 13 Sep 2002 21:59:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17q2DM-000IsN-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 18:59:16 -0700 Received: from roam.psg.com ([193.0.9.125]) by psg.com with esmtp (Exim 3.36 #1) id 17q2DJ-000IsB-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 18:59:13 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17q2DD-0002BQ-00 for v6ops@ops.ietf.org; Sat, 14 Sep 2002 04:59:07 +0300 Message-id: <3D8228AC.5090708@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Date: Fri, 13 Sep 2002 11:04:28 -0700 From: Alain Durand Subject: reading material for interim meeting To: v6ops@ops.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi, I'm trying to gather the reading material from the agenda published on http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt I couldn't find: http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt Is there a typo in the name or has it not been submited yet? - Alain. From owner-v6ops@ops.ietf.org Fri Sep 13 22:21:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24025 for ; Fri, 13 Sep 2002 22:21:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17q2ZS-000JiJ-00 for v6ops-data@psg.com; Fri, 13 Sep 2002 19:22:06 -0700 Received: from roam.psg.com ([193.0.9.125]) by psg.com with esmtp (Exim 3.36 #1) id 17q2ZP-000JhM-00 for v6ops@ops.ietf.org; Fri, 13 Sep 2002 19:22:03 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17q2ZO-0002EZ-00 for v6ops@ops.ietf.org; Sat, 14 Sep 2002 05:22:02 +0300 Message-id: <3D827F8A.1090902@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Date: Fri, 13 Sep 2002 17:15:06 -0700 From: Alain Durand Subject: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: itojun@iijlab.net, v6ops@ops.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT > o By transmitting IPv6 packet with ::ffff:127.0.0.1 in IPv6 source > address field, applications that assume basic API behavior will be > tricked to believe that the packet is from the node itself (IPv4 > loopback address, 127.0.0.1). How is that different from the case of an IPv4 application receiving a packet with src address = 127.0.0.1? The kernel should have dropped it before passing it to the application.(see my last comment in this mail) > o By transmitting IPv6 packet to firewall device, with IPv4 mapped > address corresponds to address inside the firewall (like > ::ffff:10.1.1.1) as the IPv6 source address, malicious party could > bypass IPv4 filtering rules and inject traffic inside the firewall. This only means that ingress filtering should be smarter... And anyway, with all the security issues concerning tunneling and open relays, firewalls needs to be smarter. > o Assume that the victim node is an IPv4/v6 dual stack node. By > transmitting IPv6 packet with IPv4 mapped address corresponds to IPv4 > broadcast address (::ffff:10.255.255.255) in IPv6 source address > field, to TCP/UDP port that swaps IPv6 source and destination address > (e.g. UDP port 53, DNS), malicious node can trick the victim node to > generate improper IPv4 broadcast traffic; This is because basic API on > the victim node will emit transmission requests to destination IPv4 > mapped address, ::ffff:10.255.255.255, into IPv4 traffic. If a kernel implements 'basic API' semantic, it would/should drop any packet which src/dst address is v4-mapped. However, it the kernel implements 'SIIT' semantic, and passes v6 packets to applications with IPv4-mapped src addresses, the reserver is also ture, that is, when those applications will answer, the kernel will output a v6 packet, not a v4 packet... Then up to the SIIT box to drop directed broadcast. - Alain. From owner-v6ops@ops.ietf.org Sat Sep 14 08:23:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10007 for ; Sat, 14 Sep 2002 08:23:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qBxE-0008rn-00 for v6ops-data@psg.com; Sat, 14 Sep 2002 05:23:16 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17qBxA-0008rc-00 for v6ops@ops.ietf.org; Sat, 14 Sep 2002 05:23:12 -0700 Received: from kenawang.windriver.com ([192.168.1.76]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA05002; Sat, 14 Sep 2002 05:22:34 -0700 (PDT) Message-Id: <5.1.0.14.2.20020914081958.026c5120@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 14 Sep 2002 08:20:33 -0400 To: Alain Durand From: Margaret Wasserman Subject: Re: reading material for interim meeting Cc: v6ops@ops.ietf.org In-Reply-To: <3D8228AC.5090708@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk It has been submitted, but it may not have been posted to the I-D directory yet. Yanick, let me know if I made a mistake on the name. Margaret At 02:04 PM 9/13/02, Alain Durand wrote: >Hi, > >I'm trying to gather the reading material from the agenda >published on http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt > >I couldn't find: > >http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt > > >Is there a typo in the name or has it not been submited yet? > > - Alain. > > > From owner-v6ops@ops.ietf.org Sat Sep 14 20:22:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16942 for ; Sat, 14 Sep 2002 20:22:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qN7B-000Own-00 for v6ops-data@psg.com; Sat, 14 Sep 2002 17:18:17 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17qN77-000Ovw-00 for v6ops@ops.ietf.org; Sat, 14 Sep 2002 17:18:13 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 57A034B23; Sun, 15 Sep 2002 09:18:10 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Fri, 13 Sep 2002 17:15:06 MST. <3D827F8A.1090902@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt From: itojun@iijlab.net Date: Sun, 15 Sep 2002 09:18:09 +0900 Message-Id: <20020915001810.57A034B23@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> o By transmitting IPv6 packet with ::ffff:127.0.0.1 in IPv6 source >> address field, applications that assume basic API behavior will be >> tricked to believe that the packet is from the node itself (IPv4 >> loopback address, 127.0.0.1). >How is that different from the case of an IPv4 application receiving >a packet with src address = 127.0.0.1? >The kernel should have dropped it before passing it to >the application.(see my last comment in this mail) not really different, but this is not obvious, from piles of IPv6 documents, what kind of traffic people needs to filter it. >> o By transmitting IPv6 packet to firewall device, with IPv4 mapped >> address corresponds to address inside the firewall (like >> ::ffff:10.1.1.1) as the IPv6 source address, malicious party could >> bypass IPv4 filtering rules and inject traffic inside the firewall. >This only means that ingress filtering should be smarter... >And anyway, with all the security issues concerning tunneling >and open relays, firewalls needs to be smarter. no, it is not just about firewalls. >> o Assume that the victim node is an IPv4/v6 dual stack node. By >> transmitting IPv6 packet with IPv4 mapped address corresponds to IPv4 >> broadcast address (::ffff:10.255.255.255) in IPv6 source address >> field, to TCP/UDP port that swaps IPv6 source and destination address >> (e.g. UDP port 53, DNS), malicious node can trick the victim node to >> generate improper IPv4 broadcast traffic; This is because basic API on >> the victim node will emit transmission requests to destination IPv4 >> mapped address, ::ffff:10.255.255.255, into IPv4 traffic. >If a kernel implements 'basic API' semantic, it would/should >drop any packet which src/dst address is v4-mapped. where this recommendation is documented? i believe nowhere. >However, it the kernel implements 'SIIT' semantic, >and passes v6 packets to applications with IPv4-mapped src addresses, >the reserver is also ture, that is, when those applications will answer, >the kernel will output a v6 packet, not a v4 packet... >Then up to the SIIT box to drop directed broadcast. From owner-v6ops@ops.ietf.org Sun Sep 15 04:03:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00689 for ; Sun, 15 Sep 2002 04:03:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qUMD-000De8-00 for v6ops-data@psg.com; Sun, 15 Sep 2002 01:02:17 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17qUM7-000Ddx-00 for v6ops@ops.ietf.org; Sun, 15 Sep 2002 01:02:11 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17qUM5-0004qK-00; Sun, 15 Sep 2002 09:02:09 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17qUM5-0004qF-00; Sun, 15 Sep 2002 09:02:09 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA66756; Sun, 15 Sep 2002 09:02:06 +0100 Message-ID: <3D843E86.E86DE542@hursley.ibm.com> Date: Sun, 15 Sep 2002 10:02:14 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Fred L. Templin" CC: v6ops@ops.ietf.org, Keith Moore Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] References: <3D82561D.1050708@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Fred L. Templin" wrote: > > > I use 6to4 on hosts every day, so I don't consider it hammering. > > > > But 6to4 was primariliy intended for routers. That it happens > > to work on some hosts is a happy side-benefit, not the design goal. > > > > Keith > > If you want to run 6to4 on a host that happens to have a global IPv4 address > and can accept 'ip-proto-41' w/o creating a security risk, then that is fine. > But (and you seem to recognize this), if one wants to postulate a "generalized > host-based 6to4" mechanism, that is a different matter and one that is not > covered by any existing RFCs. > > To realize a "generalized host-based 6to4", one would need to incorporate the > NAT traversal mechanisms first pioneered by TEREDO and the two-stage (end-to-edge; > edge-to-internet) tunneling mechanism first pioneered by ISATAP. But, then this > becomes more than just vanilla 6to4 and represents a unified transition mechanism > that incorporates elements proven by earlier works in various degrees. Finally, > a truly generalized mechanism would work behind a corporate firewall w/o requiring > any per-host firewall filter configurations and w/o exposing the site to outside > attackers. It's not clear to me whether a solution for this exists - but, it > would be pretty interesting if one could be identified! If you are really stuck behind a NAT you have no choice but to try some Teredo-like trick, and one Teredo in the world is enough. But trying to support enterprise scenarios where neither the ISP, nor the corporate IS people, are willing to support IPv6, *and* there is a NAT in the way, is just not worth considering IMHO. Too complicated, too many failure modes. Brian From owner-v6ops@ops.ietf.org Sun Sep 15 04:15:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00775 for ; Sun, 15 Sep 2002 04:15:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qUZE-000Dus-00 for v6ops-data@psg.com; Sun, 15 Sep 2002 01:15:44 -0700 Received: from pc25.nmrg.uni-osnabrueck.de ([131.173.144.163] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17qUZ9-000Duh-00 for v6ops@ops.ietf.org; Sun, 15 Sep 2002 01:15:39 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17qUZ6-0002d3-00 for v6ops@ops.ietf.org; Sun, 15 Sep 2002 11:15:36 +0300 In-reply-to: <20020915001810.57A034B23@coconut.itojun.org> Message-id: <6B108F62-C85A-11D6-814C-00039376A6AA@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Date: Sat, 14 Sep 2002 20:22:52 -0700 From: Alain Durand Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: itojun@iijlab.net Cc: v6ops@ops.ietf.org X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Saturday, September 14, 2002, at 05:18 PM, itojun@iijlab.net wrote: > >>> o Assume that the victim node is an IPv4/v6 dual stack node. By >>> transmitting IPv6 packet with IPv4 mapped address corresponds to >>> IPv4 >>> broadcast address (::ffff:10.255.255.255) in IPv6 source address >>> field, to TCP/UDP port that swaps IPv6 source and destination >>> address >>> (e.g. UDP port 53, DNS), malicious node can trick the victim node to >>> generate improper IPv4 broadcast traffic; This is because basic API >>> on >>> the victim node will emit transmission requests to destination IPv4 >>> mapped address, ::ffff:10.255.255.255, into IPv4 traffic. >> If a kernel implements 'basic API' semantic, it would/should >> drop any packet which src/dst address is v4-mapped. > > where this recommendation is documented? i believe nowhere. I think this is the core of the discussion. My take is that it should be documented somewhere that if one one implements basic API semantic, the kernel should drop incoming packets with IPv4-mapped src address, but if one decides to accept them, then when the same kernel is asked to send an IPv4-mapped address, it should sent it on the wire as an IPv6 address. The fist behavior is fine for dual stack host, the second for IPv6-only hosts. - Alain. From owner-v6ops@ops.ietf.org Sun Sep 15 14:20:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08282 for ; Sun, 15 Sep 2002 14:20:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qdyF-0000uP-00 for v6ops-data@psg.com; Sun, 15 Sep 2002 11:18:11 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17qdyB-0000uC-00 for v6ops@ops.ietf.org; Sun, 15 Sep 2002 11:18:08 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 58C387B9; Mon, 16 Sep 2002 03:17:56 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Sat, 14 Sep 2002 20:22:52 MST. <6B108F62-C85A-11D6-814C-00039376A6AA@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt From: Jun-ichiro itojun Hagino Date: Mon, 16 Sep 2002 03:17:56 +0900 Message-Id: <20020915181756.58C387B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> where this recommendation is documented? i believe nowhere. > >I think this is the core of the discussion. My take is that >it should be documented somewhere that if one one implements >basic API semantic, the kernel should drop incoming packets with >IPv4-mapped src address, but if one decides to accept them, >then when the same kernel is asked to send an IPv4-mapped >address, it should sent it on the wire as an IPv6 address. > >The fist behavior is fine for dual stack host, the second >for IPv6-only hosts. for each host, the above story may make sense. however, for a operator of a given site (like sun.com) there will be IPv4-only nodes, IPv6-only nodes (with SIIT support) and IPv4/v6 dual stack nodes. if we are to add the above sentences somewhere and leave IPv4 mapped address on wire be legal, it will be unmanageable. itojun From owner-v6ops@ops.ietf.org Mon Sep 16 04:09:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28198 for ; Mon, 16 Sep 2002 04:09:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qqvc-00013E-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 01:08:20 -0700 Received: from pc25.nmrg.uni-osnabrueck.de ([131.173.144.163] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17qqvV-000133-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 01:08:13 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17qqvU-0003Kw-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 11:08:12 +0300 In-reply-to: <20020915181756.58C387B9@starfruit.itojun.org> Message-id: <093D58A3-C939-11D6-B85C-00039376A6AA@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Date: Sun, 15 Sep 2002 22:56:25 -0700 From: Alain Durand Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Sunday, September 15, 2002, at 11:17 AM, Jun-ichiro itojun Hagino wrote: >>> where this recommendation is documented? i believe nowhere. >> >> I think this is the core of the discussion. My take is that >> it should be documented somewhere that if one one implements >> basic API semantic, the kernel should drop incoming packets with >> IPv4-mapped src address, but if one decides to accept them, >> then when the same kernel is asked to send an IPv4-mapped >> address, it should sent it on the wire as an IPv6 address. >> >> The fist behavior is fine for dual stack host, the second >> for IPv6-only hosts. > > for each host, the above story may make sense. however, for a > operator > of a given site (like sun.com) there will be IPv4-only nodes, > IPv6-only > nodes (with SIIT support) and IPv4/v6 dual stack nodes. if we are > to add the above sentences somewhere and leave IPv4 mapped address > on wire be legal, it will be unmanageable. I do not see why it would add any extra unmanageable complexity. The only place where extra caution would be needed would be the firewalls, and those one anyway need to be rethink to understand Ipv6 in Ipv4 tunnels better. Actually, I think that a solution like this one (SIIT+NAT64) would enable me to deploy an Ipv6 only island in my network with reasonable chances to make it work (that is, no worse than today's NAT) - Alain. From owner-v6ops@ops.ietf.org Mon Sep 16 09:52:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05260 for ; Mon, 16 Sep 2002 09:52:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwJI-000AkO-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 06:53:08 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17qwJF-000AkC-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 06:53:06 -0700 Received: from kenawang.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA20974 for ; Mon, 16 Sep 2002 06:52:29 -0700 (PDT) Message-Id: <5.1.0.14.2.20020916095237.03fd15f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 16 Sep 2002 09:53:12 -0400 To: v6ops@ops.ietf.org From: Margaret Wasserman Subject: Fwd: I-D ACTION:draft-soininen-v6ops-3gpp-cases-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Note: A new version of the 3gpp scenarios document is now available. Margaret >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Transition Scenarios for 3GPP Networks > Author(s) : J. Soininen > Filename : draft-soininen-v6ops-3gpp-cases-00.txt > Pages : 11 > Date : 2002-9-13 From owner-v6ops@ops.ietf.org Mon Sep 16 10:18:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06065 for ; Mon, 16 Sep 2002 10:18:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qwjN-000Blr-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 07:20:05 -0700 Received: from [66.81.111.138] (helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17qwjF-000Bl6-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 07:19:57 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 988537B9; Mon, 16 Sep 2002 23:19:48 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Sun, 15 Sep 2002 22:56:25 MST. <093D58A3-C939-11D6-B85C-00039376A6AA@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt From: Jun-ichiro itojun Hagino Date: Mon, 16 Sep 2002 23:19:48 +0900 Message-Id: <20020916141948.988537B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> for each host, the above story may make sense. however, for a operator >> of a given site (like sun.com) there will be IPv4-only nodes, IPv6-only >> nodes (with SIIT support) and IPv4/v6 dual stack nodes. if we are >> to add the above sentences somewhere and leave IPv4 mapped address >> on wire be legal, it will be unmanageable. >I do not see why it would add any extra unmanageable complexity. >The only place where extra caution would be needed would be >the firewalls, and those one anyway need to be rethink >to understand Ipv6 in Ipv4 tunnels better. so tell me - assuming that there are mixture of IPv4/v6 dual stack nodes and IPv6-only nodes in your site. when IPv4 traffic comes in to your firewall box, how a firewall can decide if it should let the traffic go through as is, or to translate it in SIIT way? >Actually, I think that a solution like this one (SIIT+NAT64) >would enable me to deploy an Ipv6 only island in my network >with reasonable chances to make it work >(that is, no worse than today's NAT) SIIT/NAT64 are RSIP for IPv4 and IPv6 - end node knows what needs to be done at NAT box, and end node must act like IPv4 box (see RFC2765 page 6 for very strange description - it asks IPv6-only node to compute IPv4 AH checksum). i don't think they are workable even in IPv6-only cloud. itojun From owner-v6ops@ops.ietf.org Mon Sep 16 11:21:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08476 for ; Mon, 16 Sep 2002 11:21:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxhX-000EUF-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 08:22:15 -0700 Received: from [131.173.13.103] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17qxhT-000EU0-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 08:22:11 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17qxhR-0003jk-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 18:22:10 +0300 In-reply-to: <20020916141948.988537B9@starfruit.itojun.org> Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Date: Mon, 16 Sep 2002 07:57:39 -0700 From: Alain Durand Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Monday, September 16, 2002, at 07:19 AM, Jun-ichiro itojun Hagino wrote: >>> for each host, the above story may make sense. however, for a >>> operator >>> of a given site (like sun.com) there will be IPv4-only nodes, >>> IPv6-only >>> nodes (with SIIT support) and IPv4/v6 dual stack nodes. if we are >>> to add the above sentences somewhere and leave IPv4 mapped address >>> on wire be legal, it will be unmanageable. >> I do not see why it would add any extra unmanageable complexity. >> The only place where extra caution would be needed would be >> the firewalls, and those one anyway need to be rethink >> to understand Ipv6 in Ipv4 tunnels better. > > so tell me - assuming that there are mixture of IPv4/v6 dual stack > nodes and IPv6-only nodes in your site. when IPv4 traffic comes in to > your firewall box, how a firewall can decide if it should let the > traffic go through as is, or to translate it in SIIT way? If it is v4 traffic, the firewall applies v4 sanity checks. The SIIT box does not need to be collocated with the firewall. Inbound packets that need translation (at least in NAT64) have an IPv4 dst address of one of the NAT64/SIIT gateways. They are easily identifiable by the firewalls if necessary. \What is the problem? > >> Actually, I think that a solution like this one (SIIT+NAT64) >> would enable me to deploy an Ipv6 only island in my network >> with reasonable chances to make it work >> (that is, no worse than today's NAT) > > SIIT/NAT64 are RSIP for IPv4 and IPv6 - end node knows what needs to > be done at NAT box, and end node must act like IPv4 box (see RFC2765 > page 6 for very strange description - it asks IPv6-only node to > compute > IPv4 AH checksum). i don't think they are workable even in IPv6-only > cloud. SIIT/NAT64 is not RSIP. It does not negotiate anything with the NAT box It is much more like plain IPv4 NAT. Same model. Things that work today with IPv4 NAT still work with NAT64. Things that do not work with IPv4 NAT (like IPsec) still do not work with NAT64. NAT is not a perfect solution, but a solution that, like it or not, the Internet is now very familiar with. We know the limits, and where it works, it works rather well. This is because this model is well understood today that I think SIIT/NAT64 is workable. Also remember, SIIT/NAT64 are designed as transition mechanisms, that is don't expect them to solve all problems. What makes a transition mechanism interesting is if it solves a large enough problem, is deployable and is simple enough to understand. - Alain. From owner-v6ops@ops.ietf.org Mon Sep 16 11:32:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08681 for ; Mon, 16 Sep 2002 11:32:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qxsz-000F4k-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 08:34:05 -0700 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by psg.com with esmtp (Exim 3.36 #1) id 17qxsw-000F4S-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 08:34:02 -0700 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8GFY1d26193 for ; Mon, 16 Sep 2002 10:34:01 -0500 (CDT) Message-ID: <3D85FA1D.7080404@alcatel.com> Date: Mon, 16 Sep 2002 10:34:54 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: v6ops in the subject line Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I just joined this list and started to receive the mails. One thing that I observed is there is no v6ops in the subject line so not so easy to get message filters to separate v6ops emails from others. Can we have this set up please? Regards, -- Behcet From owner-v6ops@ops.ietf.org Mon Sep 16 12:04:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09677 for ; Mon, 16 Sep 2002 12:04:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qyNL-000Glc-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 09:05:27 -0700 Received: from [66.81.111.138] (helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17qyNB-000Gku-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 09:05:17 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id EA2467B9; Tue, 17 Sep 2002 01:05:10 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 07:57:39 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 01:05:10 +0900 Message-Id: <20020916160510.EA2467B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> so tell me - assuming that there are mixture of IPv4/v6 dual stack >> nodes and IPv6-only nodes in your site. when IPv4 traffic comes in to >> your firewall box, how a firewall can decide if it should let the >> traffic go through as is, or to translate it in SIIT way? > >If it is v4 traffic, the firewall applies v4 sanity checks. >The SIIT box does not need to be collocated with the >firewall. >Inbound packets that need translation (at least in NAT64) >have an IPv4 dst address of one of the NAT64/SIIT gateways. >They are easily identifiable by the firewalls if necessary. > >What is the problem? so you assume every IPv6 site to have two IPv4 addresses, instead of 1? people wants to collocate their firewall and SIIT, to reduce IPv4 address requirements. >>> Actually, I think that a solution like this one (SIIT+NAT64) >>> would enable me to deploy an Ipv6 only island in my network >>> with reasonable chances to make it work >>> (that is, no worse than today's NAT) >> >> SIIT/NAT64 are RSIP for IPv4 and IPv6 - end node knows what needs to >> be done at NAT box, and end node must act like IPv4 box (see RFC2765 >> page 6 for very strange description - it asks IPv6-only node to compute >> IPv4 AH checksum). i don't think they are workable even in IPv6-only >> cloud. >SIIT/NAT64 is not RSIP. It does not negotiate anything with the NAT box >It is much more like plain IPv4 NAT. Same model. Things that work >today with IPv4 NAT still work with NAT64. Things that do not work >with IPv4 NAT (like IPsec) still do not work with NAT64. SIIT/NAT64 is RSIP. a proof - SIIT/NAT64 FTP client has to know about how to deal with PORT/PASV command, even though they run on IPv6-only stack. If the IPv6-only node only implements EPSV/EPRT (with IPv6 address support only), it won't be able to use FTP over SIIT/NAT64. SIIT/NAT64 imposes very strange requirement to the end devices. normal NAT box, and good translators, does not impose any new requrirement to end clients. NAT-PT and TRT requires no modification at all to IPv6-only (or IPv4/v6 dual stack) nodes in the cloud. itojun From owner-v6ops@ops.ietf.org Mon Sep 16 13:33:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11908 for ; Mon, 16 Sep 2002 13:33:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qzlI-000Kt8-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 10:34:16 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17qzlF-000Ksx-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 10:34:13 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8GHWt022400; Mon, 16 Sep 2002 13:32:56 -0400 (EDT) Message-Id: <200209161732.g8GHWt022400@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Behcet Sarikaya cc: v6ops@ops.ietf.org Subject: Re: v6ops in the subject line In-reply-to: (Your message of "Mon, 16 Sep 2002 10:34:54 CDT.") <3D85FA1D.7080404@alcatel.com> Date: Mon, 16 Sep 2002 13:32:55 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > that I observed is there is no v6ops in the subject line so not so easy > to get message filters to separate v6ops emails from others. > Can we have this set up please? please don't. it's really annoying to have this cluttering up the subject lines. and filtering on the return-path address is more reliable anyway. Keith From owner-v6ops@ops.ietf.org Mon Sep 16 13:37:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11996 for ; Mon, 16 Sep 2002 13:37:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qzpn-000L8f-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 10:38:55 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17qzpe-000L7C-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 10:38:46 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8GHaB025618; Mon, 16 Sep 2002 13:36:11 -0400 (EDT) Message-Id: <200209161736.g8GHaB025618@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alain Durand cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt In-reply-to: (Your message of "Mon, 16 Sep 2002 07:57:39 PDT.") Date: Mon, 16 Sep 2002 13:36:11 -0400 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > NAT is not a perfect solution, but a solution that, like it or not, > the Internet is now very familiar with. We know the limits, and > where it works, it works rather well. I strongly disagree. Most network admins are still not familiar with the problems NAT causes. Most network admins still do not understand the limits of NAT. No general workarounds for NAT have been identified. NAT "works" only by drastically decreasing the flexibility of the Internet to support new applications, so claims that it "works rather well" need to be taken with a large dose of salt. Keith From owner-v6ops@ops.ietf.org Mon Sep 16 13:37:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12015 for ; Mon, 16 Sep 2002 13:37:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17qzqU-000L9d-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 10:39:38 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17qzqM-000L9Q-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 10:39:30 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8GHau025637; Mon, 16 Sep 2002 13:36:56 -0400 (EDT) Message-Id: <200209161736.g8GHau025637@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jun-ichiro itojun Hagino cc: Alain Durand , v6ops@ops.ietf.org Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt In-reply-to: (Your message of "Tue, 17 Sep 2002 01:05:10 +0900.") <20020916160510.EA2467B9@starfruit.itojun.org> Date: Mon, 16 Sep 2002 13:36:56 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk normal NAT box, and good translators, does not impose any new requrirement to end clients. that's completely false. how can we make progress if people are still in this level of denial? From owner-v6ops@ops.ietf.org Mon Sep 16 14:00:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12676 for ; Mon, 16 Sep 2002 14:00:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r0Bs-000MJD-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 11:01:44 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17r0Bp-000MIv-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 11:01:41 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8GHwr009327; Mon, 16 Sep 2002 13:58:53 -0400 (EDT) Message-Id: <200209161758.g8GHwr009327@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Keith Moore cc: Jun-ichiro itojun Hagino , Alain Durand , v6ops@ops.ietf.org Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt In-reply-to: (Your message of "Mon, 16 Sep 2002 13:36:56 EDT.") <200209161736.g8GHau025637@astro.cs.utk.edu> Date: Mon, 16 Sep 2002 13:58:53 -0400 X-Spam-Status: No, hits=-5.5 required=5.0 tests=IN_REP_TO,FROM_AND_TO_SAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk yeah, I know. I shouldn't send such messages. I offer my apologies. for what it's worth, I interpreted "clients" as applications, not hosts. hosts may not be impacted by NATs. apps certainly are, and I doubt that itojun would claim otherwise. Keith > > normal NAT box, and good translators, does not impose any new > requrirement to end clients. > > that's completely false. > > how can we make progress if people are still in this level of denial? > From owner-v6ops@ops.ietf.org Mon Sep 16 14:33:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13493 for ; Mon, 16 Sep 2002 14:33:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r0h1-000Now-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 11:33:55 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17r0gy-000Nok-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 11:33:52 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA12176 for ; Mon, 16 Sep 2002 11:33:51 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8GIXp404109 for ; Mon, 16 Sep 2002 11:33:51 -0700 X-mProtect: <200209161833> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdROZukJ; Mon, 16 Sep 2002 11:33:49 PDT Message-ID: <3D86275C.30509@iprg.nokia.com> Date: Mon, 16 Sep 2002 11:47:56 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian and Keith, Please don't get me wrong; I'm not suggesting the reinvention of any wheels here (and I'm *certainly* not arguing in favor of sub-optimality). I guess what I'm doing is speculating as to whether a truly general-purpose transition mechanism is possible that would unite the functions of several existing mechanisms. Ideally, this could entail near-100% code reuse and would only require building simple links between existing modules so that the correct functionality is activated under the proper circumstances. By way of example, my laptop normally connects to my company's network which accesses the global IPv4 Internet via firewalls, proxies, etc. as for any corporate Intranet. If I were to enable a transition mechanism on my laptop while at work, I would probably choose isatap - and hope that the site has configured a 6to4/isatap router. But, suppose I wanted to take my laptop home and connect it to the NAT hub behind my DSL modem. In that case, I would clearly need to use teredo. Suppose I then wanted to take the laptop to an academic campus with open Internet access; i.e., no proxies, firewalls or NATs to traverse. In that case, host-based 6to4 would provide the optimal solution. (Example scenarios requiring other useful mechanisms, e.g., DSTM, configured tunnels, etc., could also be given.) I would think it highly unlikely that the average user would understand or even care about the subtleties of the various scenarios, which suggests to me that the decision point needs to be automated. I think this might be possible - especially if a unified addressing scheme were used that places local IPv4 unicast routing information in the interface identifier portion of the IPv6 address and global routing information (to possibly include global IPv4 routing information) in the routing prefix. Does the above give you a better idea of where I'm coming from? Fred ftemplin@iprg.nokia.com Brian E Carpenter wrote: > "Fred L. Templin" wrote: > >>>I use 6to4 on hosts every day, so I don't consider it hammering. >>> >>>But 6to4 was primariliy intended for routers. That it happens >>>to work on some hosts is a happy side-benefit, not the design goal. >>> >>>Keith >> >>If you want to run 6to4 on a host that happens to have a global IPv4 address >>and can accept 'ip-proto-41' w/o creating a security risk, then that is fine. >>But (and you seem to recognize this), if one wants to postulate a "generalized >>host-based 6to4" mechanism, that is a different matter and one that is not >>covered by any existing RFCs. >> >>To realize a "generalized host-based 6to4", one would need to incorporate the >>NAT traversal mechanisms first pioneered by TEREDO and the two-stage (end-to-edge; >>edge-to-internet) tunneling mechanism first pioneered by ISATAP. But, then this >>becomes more than just vanilla 6to4 and represents a unified transition mechanism >>that incorporates elements proven by earlier works in various degrees. Finally, >>a truly generalized mechanism would work behind a corporate firewall w/o requiring >>any per-host firewall filter configurations and w/o exposing the site to outside >>attackers. It's not clear to me whether a solution for this exists - but, it >>would be pretty interesting if one could be identified! > > > If you are really stuck behind a NAT you have no choice but to try some > Teredo-like trick, and one Teredo in the world is enough. But trying to > support enterprise scenarios where neither the ISP, nor the corporate IS > people, are willing to support IPv6, *and* there is a NAT in the way, is > just not worth considering IMHO. Too complicated, too many failure modes. > > Brian From owner-v6ops@ops.ietf.org Mon Sep 16 14:46:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13993 for ; Mon, 16 Sep 2002 14:46:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r0uh-000Oa3-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 11:48:03 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17r0uX-000OXT-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 11:47:53 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8GIjF009545; Mon, 16 Sep 2002 14:45:15 -0400 (EDT) Message-Id: <200209161845.g8GIjF009545@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alain Durand cc: Keith Moore , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: Bridging IPv6 only networks In-reply-to: (Your message of "Mon, 16 Sep 2002 11:29:27 PDT.") <3D862307.6060705@sun.com> Date: Mon, 16 Sep 2002 14:45:15 -0400 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Don't take me wrong, I'm not saying NAT is a perfect solution, far from > that. I'm saying the model is well understood, partly thanks to you Keith. > We know where it works and where it does not. That knowledge > may or may not have percolated to all network admin, but its > a different issue. well, given that I don't think I can come up with a concise statement of where NAT works and where it does not, at least, not without lots of wiggle room - I seriously doubt that "we" (for any larger set of people) understand NATs well. The midcom people have made progress, but the ugliness of their partial solution should tell us something. > I'm not advocating NAT instead of IPv6, I'm saying that NAT-like > (NAT64/SIIT) technology would enable to deploy IPv6-only > networks. Such hosts will work exactly the same as IPv4 hosts > that are today behind a NAT when talking to the IPv4 world > and benefit from end-to-end connectivity when talking to the IPv6 only > world. It's clear that some form of NAT is required to allow most apps on IPv4-only hosts to exchange information with apps on IPv6-only hosts - if only because it's impractical to build an ALG for each app. > The success (or failure) of IPv6 will not be measured by how well > early deployment using dual-stack technique will work, but > by how well large to very large IPv6-only networks will operate. and by whether those networks are more functional than NATted v4 networks. the real challenge is for the transition mechanisms to avoid imposing NAT-like restrictions on communications between application components on v6-capable hosts. otherwise, there's little point to IPv6. actually, let me back up - the real challenge is for IPv6 (with or without transition mechanisms) to avoid imposing NAT-like restrictions on communications between application components on v6-capable hosts. Because current ideas about address selection, multihoming, renumbering, and limited-scope addressing, actually impose many of those restrictions even without considering transition mechanisms. > One think that we learned in the last 2 years by studying DNS, SMTP, > SIP & friends is that, in order to keep the Internet from fragmenting > and being balkanized, nodes needs to access basic services regardless > of the IP version they are using. actually I suspect we will end up with a network which supports both heavily NATted v4 and v6 - some apps using v4, some apps using v6, and some able to tolerate either. the apps in the latter category will consist of those that tolerate NAT and don't care how big their addresses are (e.g. the web), and those apps that have built-in support for intermediaries (that can serve as v4<>v6 translators) and a transparent way of locating them (e.g. email). IF we are successful, v6-only apps will be those that cannot tolerate NAT. v4-only apps will be limited to legacy, probably local-only apps that cannot tolerate NAT and/or have wired-in assumptions about address size. > I think bridging both world at the IP layer makes more sense than > bridging them at upper layers, and NAT-like technology is a natural > candidate for that purpose. again, I see two risks with this: - one is that we pretend that it's a general solution. - the other is that such mechanisms interfere with interoperation between v6-only hosts. Keith From owner-v6ops@ops.ietf.org Mon Sep 16 14:52:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14205 for ; Mon, 16 Sep 2002 14:52:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r10f-000Ouc-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 11:54:13 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17r10X-000OuI-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 11:54:05 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA13623; Mon, 16 Sep 2002 11:54:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8GIs3600983; Mon, 16 Sep 2002 11:54:03 -0700 X-mProtect: <200209161854> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz3FQHo; Mon, 16 Sep 2002 11:54:02 PDT Message-ID: <3D862C19.4080309@iprg.nokia.com> Date: Mon, 16 Sep 2002 12:08:09 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Alain Durand , v6ops@ops.ietf.org Subject: Re: reading material for interim meeting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am also curious as to whether we'll be seeing this document in time for the meeting - any idea as to the status? Fred ftemplin@iprg.nokia.com Margaret Wasserman wrote: > > It has been submitted, but it may not have been posted to the I-D > directory yet. > > Yanick, let me know if I made a mistake on the name. > > Margaret > > > > At 02:04 PM 9/13/02, Alain Durand wrote: > >> Hi, >> >> I'm trying to gather the reading material from the agenda >> published on http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt >> >> I couldn't find: >> >> http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt >> >> >> Is there a typo in the name or has it not been submited yet? >> >> - Alain. From owner-v6ops@ops.ietf.org Mon Sep 16 15:10:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14577 for ; Mon, 16 Sep 2002 15:10:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r1Hm-000PjI-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 12:11:54 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17r1Hd-000PhH-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 12:11:45 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 16 Sep 2002 12:11:45 -0700 Reply-To: From: "Tony Hain" To: "'Fred L. Templin'" , Subject: RE: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Date: Mon, 16 Sep 2002 12:11:14 -0700 Message-ID: <036201c25db4$d3d40860$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3D86275C.30509@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred, There is nothing here that a well implemented stack that included isatap, 6to4, & teredo wouldn't provide. If the sending rules are followed, your nomad node would in fact work fine without further effort. If that node wanted to be called, it would need to use mipv6 anyway, because its ipv4 address would be changing as it moved. So putting that in the iid doesn't help the dns update problem. Finding a provider for a home agent of a node that is only using transition technologies would be a bit of a challenge, but there is no technical reason for that to be a problem as long as the HA was accessable to it over each of the technologies. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred L. Templin > Sent: Monday, September 16, 2002 11:48 AM > To: v6ops@ops.ietf.org > Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] > > > Brian and Keith, > > Please don't get me wrong; I'm not suggesting the reinvention > of any wheels here (and I'm *certainly* not arguing in favor > of sub-optimality). I guess what I'm doing is speculating as > to whether a truly general-purpose transition mechanism is > possible that would unite the functions of several existing > mechanisms. Ideally, this could entail near-100% code reuse > and would only require building simple links between existing > modules so that the correct functionality is activated under > the proper circumstances. > > By way of example, my laptop normally connects to my > company's network which accesses the global IPv4 Internet via > firewalls, proxies, etc. as for any corporate Intranet. If I > were to enable a transition mechanism on my laptop while at > work, I would probably choose isatap - and hope that the site > has configured a 6to4/isatap router. But, suppose I wanted to > take my laptop home and connect it to the NAT hub behind my > DSL modem. In that case, I would clearly need to use teredo. > Suppose I then wanted to take the laptop to an academic > campus with open Internet access; i.e., no proxies, firewalls > or NATs to traverse. In that case, host-based 6to4 would > provide the optimal solution. (Example scenarios requiring > other useful mechanisms, e.g., DSTM, configured tunnels, > etc., could also be > given.) > > I would think it highly unlikely that the average user would > understand or even care about the subtleties of the various > scenarios, which suggests to me that the decision point needs > to be automated. I think this might be possible - especially > if a unified addressing scheme were used that places local > IPv4 unicast routing information in the interface identifier > portion of the IPv6 address and global routing information > (to possibly include global IPv4 routing information) in the > routing prefix. > > Does the above give you a better idea of where I'm coming from? > > Fred > ftemplin@iprg.nokia.com > > Brian E Carpenter wrote: > > "Fred L. Templin" wrote: > > > >>>I use 6to4 on hosts every day, so I don't consider it > hammering. >>> >>>But 6to4 was primariliy intended for > routers. That it happens >>>to work on some hosts is a > happy side-benefit, not the design goal. >>> >>>Keith >> > >>If you want to run 6to4 on a host that happens to have a > global IPv4 address >>and can accept 'ip-proto-41' w/o > creating a security risk, then that is fine. >>But (and you > seem to recognize this), if one wants to postulate a > "generalized >>host-based 6to4" mechanism, that is a > different matter and one that is not >>covered by any > existing RFCs. >> >>To realize a "generalized host-based > 6to4", one would need to incorporate the >>NAT traversal > mechanisms first pioneered by TEREDO and the two-stage (end-to-edge; > >>edge-to-internet) tunneling mechanism first pioneered by > ISATAP. But, then this >>becomes more than just vanilla 6to4 > and represents a unified transition mechanism >>that > incorporates elements proven by earlier works in various > degrees. Finally, >>a truly generalized mechanism would work > behind a corporate firewall w/o requiring >>any per-host > firewall filter configurations and w/o exposing the site to > outside >>attackers. It's not clear to me whether a solution > for this exists - but, it >>would be pretty interesting if > one could be identified! > > > If you are really stuck > behind a NAT you have no choice but to try some > > Teredo-like trick, and one Teredo in the world is enough. But > trying to > support enterprise scenarios where neither the > ISP, nor the corporate IS > people, are willing to support > IPv6, *and* there is a NAT in the way, is > just not worth > considering IMHO. Too complicated, too many failure modes. > > > Brian > > > > From owner-v6ops@ops.ietf.org Mon Sep 16 16:42:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16651 for ; Mon, 16 Sep 2002 16:42:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r2id-0004LB-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 13:43:43 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17r2iZ-0004Ky-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 13:43:39 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8GKhNs04367; Mon, 16 Sep 2002 23:43:24 +0300 Date: Mon, 16 Sep 2002 23:43:23 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Alain Durand , Subject: Re: reading material for interim meeting In-Reply-To: <5.1.0.14.2.20020914081958.026c5120@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 14 Sep 2002, Margaret Wasserman wrote: > It has been submitted, but it may not have been posted to the I-D > directory yet. > > Yanick, let me know if I made a mistake on the name. Guys.. are you kidding? There is zero point in just posting drafts to the I-D directory this near to the meeting. At least, it should have been published on a web page somewhere and a URL posted here. > At 02:04 PM 9/13/02, Alain Durand wrote: > >Hi, > > > >I'm trying to gather the reading material from the agenda > >published on http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt > > > >I couldn't find: > > > >http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt > > > > > >Is there a typo in the name or has it not been submited yet? > > > > - Alain. > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Sep 16 17:16:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17596 for ; Mon, 16 Sep 2002 17:16:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r3Ft-00062x-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 14:18:05 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17r3Fn-00062m-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 14:17:59 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id AB5053A1B; Mon, 16 Sep 2002 17:17:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 16 Sep 2002 17:17:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: reading material for interim meeting Date: Mon, 16 Sep 2002 17:17:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE923C@tayexc13.americas.cpqcorp.net> Thread-Topic: reading material for interim meeting Thread-Index: AcJdwfyQWrB9Iin0QoW1BDhW29ZHXAABFw0A From: "Bound, Jim" To: "Pekka Savola" Cc: "Alain Durand" , X-OriginalArrivalTime: 16 Sep 2002 21:17:58.0365 (UTC) FILETIME=[87D5F8D0:01C25DC6] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17596 Pekka, We are all volunteers and most of us have day jobs that pay for us to come to an interim meeting. We also just formed our team late August. So please bare with us on the Enterprise Network Team. thanks /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, September 16, 2002 4:43 PM > To: Margaret Wasserman > Cc: Alain Durand; v6ops@ops.ietf.org > Subject: Re: reading material for interim meeting > > > On Sat, 14 Sep 2002, Margaret Wasserman wrote: > > It has been submitted, but it may not have been posted to the I-D > > directory yet. > > > > Yanick, let me know if I made a mistake on the name. > > > Guys.. are you kidding? > > There is zero point in just posting drafts to the I-D > directory this near > to the meeting. > > At least, it should have been published on a web page > somewhere and a URL > posted here. > > > At 02:04 PM 9/13/02, Alain Durand wrote: > > >Hi, > > > > > >I'm trying to gather the reading material from the agenda > > >published on http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt > > > >I couldn't find: > > > >http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt > > > > > >Is there a typo in the name or has it not been submited yet? > > > > - Alain. > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Sep 16 17:19:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17621 for ; Mon, 16 Sep 2002 17:19:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r3Ib-0006GA-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 14:20:53 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17r3IW-0006FF-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 14:20:49 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8GLKgk04707; Tue, 17 Sep 2002 00:20:42 +0300 Date: Tue, 17 Sep 2002 00:20:41 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Alain Durand , Subject: RE: reading material for interim meeting In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE923C@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 16 Sep 2002, Bound, Jim wrote: > We are all volunteers and most of us have day jobs that pay for us to > come to an interim meeting. We also just formed our team late August. > So please bare with us on the Enterprise Network Team. So there will be misunderstanding, I was not criticizing the progress but the process: if a draft has been submitted (== deemed ready at this point), it should have been made otherwise available, rather than to wait for the I-D queue (a few days). > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Monday, September 16, 2002 4:43 PM > > To: Margaret Wasserman > > Cc: Alain Durand; v6ops@ops.ietf.org > > Subject: Re: reading material for interim meeting > > > > > > On Sat, 14 Sep 2002, Margaret Wasserman wrote: > > > It has been submitted, but it may not have been posted to the I-D > > > directory yet. > > > > > > Yanick, let me know if I made a mistake on the name. > > > > > > Guys.. are you kidding? > > > > There is zero point in just posting drafts to the I-D > > directory this near > > to the meeting. > > > > At least, it should have been published on a web page > > somewhere and a URL > > posted here. > > > > > At 02:04 PM 9/13/02, Alain Durand wrote: > > > >Hi, > > > > > > > >I'm trying to gather the reading material from the agenda > > > >published on > http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt > > > > > >I couldn't find: > > > > > >http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt > > > > > > > > >Is there a typo in the name or has it not been submited yet? > > > > > > - Alain. > > > > > > > > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Sep 16 17:20:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17643 for ; Mon, 16 Sep 2002 17:20:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r3KK-0006Ll-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 14:22:40 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17r3KH-0006LZ-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 14:22:37 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6F3C365D7; Mon, 16 Sep 2002 17:22:36 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 16 Sep 2002 17:22:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: reading material for interim meeting Date: Mon, 16 Sep 2002 17:22:35 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE923D@tayexc13.americas.cpqcorp.net> Thread-Topic: reading material for interim meeting Thread-Index: AcJdxvDcuoQWrnf1QAyAybmyLcklnAAAC1JA From: "Bound, Jim" To: "Pekka Savola" Cc: "Alain Durand" , X-OriginalArrivalTime: 16 Sep 2002 21:22:36.0191 (UTC) FILETIME=[2D6EDAF0:01C25DC7] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA17643 OK. Then I am sorry I responded. No comment from me on this. thanks /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, September 16, 2002 5:21 PM > To: Bound, Jim > Cc: Alain Durand; v6ops@ops.ietf.org > Subject: RE: reading material for interim meeting > > > On Mon, 16 Sep 2002, Bound, Jim wrote: > > We are all volunteers and most of us have day jobs that pay > for us to > > come to an interim meeting. We also just formed our team > late August. > > So please bare with us on the Enterprise Network Team. > > So there will be misunderstanding, I was not criticizing the > progress but > the process: if a draft has been submitted (== deemed ready at this > point), it should have been made otherwise available, rather > than to wait > for the I-D queue (a few days). > > > > -----Original Message----- > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > Sent: Monday, September 16, 2002 4:43 PM > > > To: Margaret Wasserman > > > Cc: Alain Durand; v6ops@ops.ietf.org > > > Subject: Re: reading material for interim meeting > > > > > > > > > On Sat, 14 Sep 2002, Margaret Wasserman wrote: > > > > It has been submitted, but it may not have been posted > to the I-D > > > > directory yet. > > > > > > > > Yanick, let me know if I made a mistake on the name. > > > > > > > > > Guys.. are you kidding? > > > > > > There is zero point in just posting drafts to the I-D > > > directory this near > > > to the meeting. > > > > > > At least, it should have been published on a web page > > > somewhere and a URL > > > posted here. > > > > > > > At 02:04 PM 9/13/02, Alain Durand wrote: > > > > >Hi, > > > > > > > > > >I'm trying to gather the reading material from the agenda > > > > >published on > > http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt > > > > > > > >I couldn't find: > > > > > > > >http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt > > > > > > > > >Is there a typo in the name or has it not been submited yet? > > > > > > - Alain. > > > > > > > > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Sep 16 18:04:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18546 for ; Mon, 16 Sep 2002 18:04:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r3zt-0008fx-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 15:05:37 -0700 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by psg.com with esmtp (Exim 3.36 #1) id 17r3zY-0008fA-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 15:05:16 -0700 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8GM5px16083 for ; Mon, 16 Sep 2002 17:05:51 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Sep 2002 17:05:12 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Sep 2002 17:03:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C25DCC.F029E9BE" Subject: FW: I-D ACTION:draft-soininen-v6ops-3gpp-cases-00.txt Date: Mon, 16 Sep 2002 15:03:50 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE0175D531@mvebe001.americas.nokia.com> X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-soininen-v6ops-3gpp-cases-00.txt Thread-Index: AcJdgHOcswutnZ+nS62Vvg1Bsjo8sAAQRXlA From: To: X-OriginalArrivalTime: 16 Sep 2002 22:03:51.0084 (UTC) FILETIME=[F0958EC0:01C25DCC] X-Spam-Status: No, hits=4.2 required=5.0 tests=NO_REAL_NAME,EXCUSE_6,DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C25DCC.F029E9BE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, here is a new version of the scenarios document. Sorry it is so late for = the meeting. (I had some trouble of getting it out.) For those that are = already prepared to kill me because of the late submission, I can assure = it has changed very little from the original version of the draft = (http://www.ietf.org/internet-drafts/draft-soininen-ngtrans-3gpp-cases-00= .txt). The biggest change has been the addition of the ASCII-graphics to = the scenarios, and some clarifying text about GPRS, and IMS. Thus, the actual substance has not changed really at all. Cheers, Jonne. -----Original Message----- From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, September 16, 2002 4:47 AM Subject: I-D ACTION:draft-soininen-v6ops-3gpp-cases-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Transition Scenarios for 3GPP Networks Author(s) : J. Soininen Filename : draft-soininen-v6ops-3gpp-cases-00.txt Pages : 11 Date : 2002-9-13 =09 This document describes different scenarios in Third Generation=20 Partnership Project (3GPP) defined packet network, i.e. General=20 Packet Radio Service (GPRS) that would need IP version 6 and IP=20 version 4 transition. The focus of this document is on the scenarios=20 where the User Equipment (UE) connects to nodes in other networks,=20 e.g. in the Internet. GPRS network internal transition scenarios,=20 i.e. between different GPRS elements in the network, are out of scope=20 of this document. =20 The purpose of the document is to list the scenarios for further=20 discussion and study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-soininen-v6ops-3gpp-cases-00.tx= t 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-soininen-v6ops-3gpp-cases-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-soininen-v6ops-3gpp-cases-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. ------_=_NextPart_001_01C25DCC.F029E9BE Content-Type: application/octet-stream; name="ATT520381.TXT" Content-Description: ATT520381.TXT Content-Disposition: attachment; filename="ATT520381.TXT" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTktMTMxNDM3MzMuSS1EQGlldGYub3JnPg0KDQpF TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc29pbmluZW4tdjZvcHMt M2dwcC1jYXNlcy0wMC50eHQNCg== ------_=_NextPart_001_01C25DCC.F029E9BE Content-Type: application/octet-stream; name="draft-soininen-v6ops-3gpp-cases-00.URL" Content-Description: draft-soininen-v6ops-3gpp-cases-00.URL Content-Disposition: attachment; filename="draft-soininen-v6ops-3gpp-cases-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1zb2luaW5lbi12Nm9wcy0zZ3BwLWNhc2VzLTAwLnR4dA0K ------_=_NextPart_001_01C25DCC.F029E9BE-- From owner-v6ops@ops.ietf.org Mon Sep 16 18:22:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18776 for ; Mon, 16 Sep 2002 18:22:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r4Ha-0009ii-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 15:23:54 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17r4HX-0009iX-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 15:23:51 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 16 Sep 2002 15:23:48 -0700 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , "'Pekka Savola'" Cc: "'Alain Durand'" , Subject: RE: reading material for interim meeting Date: Mon, 16 Sep 2002 15:23:05 -0700 Message-ID: <037d01c25dcf$a0c873a0$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE923D@tayexc13.americas.cpqcorp.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA18776 If the unmanaged & isp documents are any indication of the current lag, I would expect the enterprise doc to show up tomorrow. In the mean time, I put a copy of the document Yanick sent to the ID editor at: http://www.tndh.net/~tony/ietf/draft-pouffary-v6ops-ent-v6net-00.txt Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bound, Jim > Sent: Monday, September 16, 2002 2:23 PM > To: Pekka Savola > Cc: Alain Durand; v6ops@ops.ietf.org > Subject: RE: reading material for interim meeting > > > OK. Then I am sorry I responded. No comment from me on this. > thanks /jim > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Monday, September 16, 2002 5:21 PM > > To: Bound, Jim > > Cc: Alain Durand; v6ops@ops.ietf.org > > Subject: RE: reading material for interim meeting > > > > > > On Mon, 16 Sep 2002, Bound, Jim wrote: > > > We are all volunteers and most of us have day jobs that pay > > for us to > > > come to an interim meeting. We also just formed our team > > late August. > > > So please bare with us on the Enterprise Network Team. > > > > So there will be misunderstanding, I was not criticizing the > > progress but > > the process: if a draft has been submitted (== deemed ready at this > > point), it should have been made otherwise available, rather > > than to wait > > for the I-D queue (a few days). > > > > > > -----Original Message----- > > > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > > > Sent: Monday, September 16, 2002 4:43 PM > > > > To: Margaret Wasserman > > > > Cc: Alain Durand; v6ops@ops.ietf.org > > > > Subject: Re: reading material for interim meeting > > > > > > > > > > > > On Sat, 14 Sep 2002, Margaret Wasserman wrote: > > > > > It has been submitted, but it may not have been posted > > to the I-D > > > > > directory yet. > > > > > > > > > > Yanick, let me know if I made a mistake on the name. > > > > > > > > > > > > Guys.. are you kidding? > > > > > > > > There is zero point in just posting drafts to the I-D > > > > directory this near > > > > to the meeting. > > > > > > > > At least, it should have been published on a web page > > > > somewhere and a URL > > > > posted here. > > > > > > > > > At 02:04 PM 9/13/02, Alain Durand wrote: > > > > > >Hi, > > > > > > > > > > > >I'm trying to gather the reading material from the agenda > > > > > >published on > > > http://home.attbi.com/~margaretw/Interim-Agenda-Sep02.txt > > > > > > > > > >I couldn't find: > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent- v6net-00.t >xt > > > > > > > > >Is there a typo in the name or has it not been submited yet? > > > > > > - Alain. > > > > > > > > > > > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Sep 16 20:32:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20722 for ; Mon, 16 Sep 2002 20:32:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r6I6-000H85-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 17:32:34 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17r6I2-000H7u-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 17:32:30 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA03544; Mon, 16 Sep 2002 17:32:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8H0WTs29709; Mon, 16 Sep 2002 17:32:29 -0700 X-mProtect: <200209170032> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFftT0b; Mon, 16 Sep 2002 17:32:27 PDT Message-ID: <3D867B6C.90807@iprg.nokia.com> Date: Mon, 16 Sep 2002 17:46:36 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tony Hain" CC: v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony, Tony Hain wrote: > Fred, > > There is nothing here that a well implemented stack that included > isatap, 6to4, & teredo wouldn't provide. If the sending rules are > followed, your nomad node would in fact work fine without further > effort. If that node wanted to be called, it would need to use mipv6 > anyway, because its ipv4 address would be changing as it moved. So > putting that in the iid doesn't help the dns update problem. Finding a > provider for a home agent of a node that is only using transition > technologies would be a bit of a challenge, but there is no technical > reason for that to be a problem as long as the HA was accessable to it > over each of the technologies. > > Tony Somehow, I was inferring a "glue" layer was needed to bind everything together. But, your message makes me believe that won't be necessary in well implemented stacks. Thanks for the comments, Fred ftemplin@iprg.nokia.com >>-----Original Message----- >>From: owner-v6ops@ops.ietf.org >>[mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred L. Templin >>Sent: Monday, September 16, 2002 11:48 AM >>To: v6ops@ops.ietf.org >>Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] >> >> >>Brian and Keith, >> >>Please don't get me wrong; I'm not suggesting the reinvention >>of any wheels here (and I'm *certainly* not arguing in favor >>of sub-optimality). I guess what I'm doing is speculating as >>to whether a truly general-purpose transition mechanism is >>possible that would unite the functions of several existing >>mechanisms. Ideally, this could entail near-100% code reuse >>and would only require building simple links between existing >>modules so that the correct functionality is activated under >>the proper circumstances. >> >>By way of example, my laptop normally connects to my >>company's network which accesses the global IPv4 Internet via >>firewalls, proxies, etc. as for any corporate Intranet. If I >>were to enable a transition mechanism on my laptop while at >>work, I would probably choose isatap - and hope that the site >>has configured a 6to4/isatap router. But, suppose I wanted to >>take my laptop home and connect it to the NAT hub behind my >>DSL modem. In that case, I would clearly need to use teredo. >>Suppose I then wanted to take the laptop to an academic >>campus with open Internet access; i.e., no proxies, firewalls >>or NATs to traverse. In that case, host-based 6to4 would >>provide the optimal solution. (Example scenarios requiring >>other useful mechanisms, e.g., DSTM, configured tunnels, >>etc., could also be >>given.) >> >>I would think it highly unlikely that the average user would >>understand or even care about the subtleties of the various >>scenarios, which suggests to me that the decision point needs >>to be automated. I think this might be possible - especially >>if a unified addressing scheme were used that places local >>IPv4 unicast routing information in the interface identifier >>portion of the IPv6 address and global routing information >>(to possibly include global IPv4 routing information) in the >>routing prefix. >> >>Does the above give you a better idea of where I'm coming from? >> >>Fred >>ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Mon Sep 16 21:43:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22325 for ; Mon, 16 Sep 2002 21:43:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r7Pg-000LJG-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 18:44:28 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17r7PX-000LIy-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 18:44:20 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8H1gr020211; Mon, 16 Sep 2002 21:42:53 -0400 (EDT) Message-Id: <200209170142.g8H1gr020211@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Fred L. Templin" cc: "Tony Hain" , v6ops@ops.ietf.org Subject: Re: 6to4 relays [Re: WG Review: IPv6 Operations (v6ops)] In-reply-to: (Your message of "Mon, 16 Sep 2002 17:46:36 PDT.") <3D867B6C.90807@iprg.nokia.com> Date: Mon, 16 Sep 2002 21:42:53 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > There is nothing here that a well implemented stack that included > isatap, 6to4, & teredo wouldn't provide. If the sending rules are > followed, your nomad node would in fact work fine without further > effort. I don't believe for a millisecond that the sending rules will allow apps to cope with an arbitrary number of addresses or interfaces. Address selection is the v6 way of saying "it's somebody else's problem". that "somebody" is the application writer. Keith From owner-v6ops@ops.ietf.org Mon Sep 16 21:58:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22559 for ; Mon, 16 Sep 2002 21:58:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r7eR-000MCc-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 18:59:43 -0700 Received: from ny-ppp012.iij-us.net ([216.98.99.12] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17r7eK-000MCQ-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 18:59:37 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C48267B9; Tue, 17 Sep 2002 10:59:22 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 09:42:20 MST. <3D8609EC.5020707@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 10:59:22 +0900 Message-Id: <20020917015922.C48267B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I'm not assuming that. >Please read more carefully what I wrote. >--> 'The SIIT box does not need to be collocated with the firewall.' >It does not mean it can not. ok, then how do you make SIIT and firewall collocate on the same box? >> SIIT/NAT64 is RSIP. a proof - SIIT/NAT64 FTP client has to know >> about how to deal with PORT/PASV command, even though they run on >> IPv6-only stack. >> >> If the IPv6-only node only implements EPSV/EPRT >> (with IPv6 address support only), it won't be able to use FTP over >> SIIT/NAT64. SIIT/NAT64 imposes very strange requirement to the end >> devices. >> >> normal NAT box, and good translators, does not impose any new >> requrirement to end clients. NAT-PT and TRT requires no modification >> at all to IPv6-only (or IPv4/v6 dual stack) nodes in the cloud >I may be ignorant, then please educate me with a clear example >how NAT64 is different from NAT-PT in that regard. > >An IPv6-only end node working in an NAT64 environement >will have to inplement what you call SIIT kernel behavior, >that's all. the 'peer' address will be an IPv6 address, the same way >as NAT-PT. It just happend that this address is a v4-mapped address, >but as it would be sent over the wire, I still see no difference with NAT-PT >in that regard. no, the above description is incorrect. SIIT/NAT64 environment: For an FTP client on IPv6 only kernel (on the lefthand side of the diagram) to be able to contact and transfer files across SIIT box, the FTP client has to implement and understand IPv4 FTP commands, such as PORT and PASV. this is not a normal requirement to IPv6-only FTP client. IPv6-only FTP client normally implement EPSV/EPRT, for protocol #2 (IPv6) only, and that's all. remember SIIT/NAT64 box will not rewrite the payload of packets. so, the FTP client knows about IPv4 (= outside world from the SIIT box). this is why i call SIIT/NAT64 similar to RSIP. NAT-PT environment: FTP client on IPv6 only kernel (or IPv6/v4 dual stack kernel) talks EPSV/EPRT, with protocol #2 (IPv6). NAT-PT box will translate the content of the FTP control traffic into IPv4 ones (PORT/PASV). therefore, FTP client is seeing IPv6 peer from FTP protocol point of view. itojun SIIT/NAT64 environment FTP client ========== AF_INET6 API IPv6 only kernel SIIT box IPv4 FTP server | | | |a.b.c.d ==+==============================+= =+============+== IPv6 traffic IPv4 traffic (::ffff:a.b.c.d) SIIT/NAT64 environment FTP client ========== AF_INET6 API IPv6 only/dualstack NAT-PT box IPv4 FTP server | | | |a.b.c.d ==+==============================+= =+============+== IPv6 traffic IPv4 traffic (to some fake address) From owner-v6ops@ops.ietf.org Mon Sep 16 22:11:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22710 for ; Mon, 16 Sep 2002 22:11:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r7rm-000N1K-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 19:13:30 -0700 Received: from ny-ppp012.iij-us.net ([216.98.99.12] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17r7rh-000N0D-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 19:13:26 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A666C7B9; Tue, 17 Sep 2002 11:13:18 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: itojun's message of Tue, 17 Sep 2002 10:59:22 +0900. <20020917015922.C48267B9@starfruit.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 11:13:18 +0900 Message-Id: <20020917021318.A666C7B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>An IPv6-only end node working in an NAT64 environement >>will have to inplement what you call SIIT kernel behavior, >>that's all. the 'peer' address will be an IPv6 address, the same way >>as NAT-PT. It just happend that this address is a v4-mapped address, >>but as it would be sent over the wire, I still see no difference with NAT-PT >>in that regard. > no, the above description is incorrect. 2nd diagram is for NAT-PT, of course. itojun From owner-v6ops@ops.ietf.org Mon Sep 16 22:32:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23146 for ; Mon, 16 Sep 2002 22:32:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r8B5-000ODa-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 19:33:27 -0700 Received: from ny-ppp012.iij-us.net ([216.98.99.12] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17r8B2-000ODK-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 19:33:25 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 1A85B7B9; Tue, 17 Sep 2002 11:33:17 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 19:23:07 MST. <3D86920B.1060801@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 11:33:17 +0900 Message-Id: <20020917023317.1A85B7B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>SIIT/NAT64 environment >> >>FTP client >>========== AF_INET6 API >>IPv6 only kernel SIIT box IPv4 FTP server >> | | | |a.b.c.d >>==+==============================+= =+============+== >> IPv6 traffic IPv4 traffic >> (::ffff:a.b.c.d) >I think I now understand your problem. >What you say is true if and only if the ftp client has internal >knowledge that ::ffff:a.b.c.d is a special address that is in fact an >IPv4 address. >That is, FTP looks at it in a sockaddr_in/AF_INET and not a >sockaddr_in6/ AF_INET6 >structure. the internal knowledge is vital for SIIT/NAT64 to work. it is not avoidable. >This does not have to be the case. Remove that knowledge from the >application/kernel >and then you do not need anymore PORT/PASV. if you remove the knowledge, FTP client on IPv6-only machine cannot transfer files from/to IPv4 FTP server (since IPv4 FTP server does not understand EPSV/EPRT, with protocol #2). itojun From owner-v6ops@ops.ietf.org Mon Sep 16 22:52:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23481 for ; Mon, 16 Sep 2002 22:52:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17r8UD-000PG4-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 19:53:13 -0700 Received: from ny-ppp022.iij-us.net ([216.98.99.22] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17r8U7-000PFn-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 19:53:08 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 302CD7B9; Tue, 17 Sep 2002 11:53:02 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: itojun's message of Tue, 17 Sep 2002 11:33:17 +0900. <20020917023317.1A85B7B9@starfruit.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 11:53:02 +0900 Message-Id: <20020917025302.302CD7B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>I think I now understand your problem. >>What you say is true if and only if the ftp client has internal >>knowledge that ::ffff:a.b.c.d is a special address that is in fact an >>IPv4 address. >>That is, FTP looks at it in a sockaddr_in/AF_INET and not a >>sockaddr_in6/ AF_INET6 >>structure. > the internal knowledge is vital for SIIT/NAT64 to work. it is > not avoidable. and it does not matter if you are using sockaddr_in/AF_INET, or sockaddr_in6/AF_INET6. (normally I assume AF_INET socket is not available on IPv6-only systems, btw) itojun From owner-v6ops@ops.ietf.org Tue Sep 17 01:21:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25765 for ; Tue, 17 Sep 2002 01:21:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rAo6-0008ag-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 22:21:54 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rAo2-0008Zh-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 22:21:50 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 1D2E17B9; Tue, 17 Sep 2002 14:21:45 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 22:16:45 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 14:21:45 +0900 Message-Id: <20020917052145.1D2E17B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>> This does not have to be the case. Remove that knowledge from the >>> application/kernel >>> and then you do not need anymore PORT/PASV. >> if you remove the knowledge, FTP client on IPv6-only machine cannot >> transfer files from/to IPv4 FTP server (since IPv4 FTP server does not >> understand EPSV/EPRT, with protocol #2). >Not if your FTP client is IPv6-only!!! bzzzt. wrong. if your FTP client is IPv6-only, it will issue EPSV/EPRT with protocol #2. FTP server on the other end is IPv4-only, which does not understand it. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 01:38:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26015 for ; Tue, 17 Sep 2002 01:38:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rB5u-0009ku-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 22:40:18 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rB5N-0009jw-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 22:39:45 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 3B0867B9; Tue, 17 Sep 2002 14:39:38 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 22:26:34 MST. <0807F110-C9FE-11D6-8198-00039376A6AA@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 14:39:38 +0900 Message-Id: <20020917053938.3B0867B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> bzzzt. wrong. >> if your FTP client is IPv6-only, it will issue EPSV/EPRT with protocol >> #2. FTP server on the other end is IPv4-only, which does not >> understand it. >BZZZZ.. Wrong. :-) >This goes to the NAT64 box which does the translation the same way >NAT-PT would do! hmm, then that's the fundamental difference between NAT64 and SIIT. NAT64 does rewrite the content of the packet, which means, - support nightmare just like we had in IPv4-to-IPv4 NAT, just like NAT-PT, - you can't put multiple NAT64 boxes in your site border (= scalability problem) just like NAT-PT. - NAT64 box has to deal with fragmentation issue just like NAT-PT. - NAT64 translator box is stateful, and single point of failure, just like NAT-PT. draft-durand-ngtrans-nat64-nat46-00.txt is not clear enough about it (or i wasn't careful when reading it), and i'm not happy with "scalable NAT mechanism" written in the abstract of the draft. it doesn't scale. anyways, you didn't answer my first question - how do you collocate IPv4 firewall and NAT64 into the same box? itojun From owner-v6ops@ops.ietf.org Tue Sep 17 02:29:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05648 for ; Tue, 17 Sep 2002 02:29:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rBsB-000Cs8-00 for v6ops-data@psg.com; Mon, 16 Sep 2002 23:30:11 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rBre-000CrG-00 for v6ops@ops.ietf.org; Mon, 16 Sep 2002 23:29:39 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 5519A7BC; Tue, 17 Sep 2002 15:29:30 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 09:42:20 MST. <3D8609EC.5020707@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 15:29:30 +0900 Message-Id: <20020917062930.5519A7BC@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk back to the original topic - the fundamental issue i'm raising is that it is evil to make dual use of IPv4 mapped address. we need to make it to have single meaning (RFC2553 one due to the deployed codebase), otherwise we get a lot of security issues like i have listed and alike. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 03:00:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06091 for ; Tue, 17 Sep 2002 03:00:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rCNF-000F26-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 00:02:17 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rCMg-000Ewu-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 00:01:43 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A05457C7; Tue, 17 Sep 2002 16:01:37 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 23:14:15 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 16:01:37 +0900 Message-Id: <20020917070137.A05457C7@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >But it has serious advantages over NAT-PT. >It scales much better and does not break DNSsec. i do not really think it a major advantage. if you can use "AD is secure" proposal and let NAT-PT box to validate DNSsec signature, we can get the same effect with NAT-PT. one big disadbantage: abuses IPv4 mapped address. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 03:01:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06121 for ; Tue, 17 Sep 2002 03:01:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rCNq-000F3B-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 00:02:54 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rCNH-000F28-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 00:02:20 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 5B60A7C7; Tue, 17 Sep 2002 16:02:13 +0900 (JST) To: Alain Durand , v6ops@ops.ietf.org In-reply-to: itojun's message of Tue, 17 Sep 2002 16:01:37 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 16:02:13 +0900 Message-Id: <20020917070214.5B60A7C7@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>But it has serious advantages over NAT-PT. >>It scales much better and does not break DNSsec. > i do not really think it a major advantage. > if you can use "AD is secure" proposal and let NAT-PT box to validate > DNSsec signature, we can get the same effect with NAT-PT. s/NAT-PT box/DNS ALG/ itojun From owner-v6ops@ops.ietf.org Tue Sep 17 03:41:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06719 for ; Tue, 17 Sep 2002 03:41:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rCzr-000HRv-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 00:42:11 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rCzB-000HNy-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 00:41:30 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 75BEB7B9; Tue, 17 Sep 2002 16:41:24 +0900 (JST) To: Alain Durand Cc: v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Tue, 17 Sep 2002 00:30:16 MST. <4F7663DF-CA0F-11D6-8198-00039376A6AA@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 16:41:24 +0900 Message-Id: <20020917074124.75BEB7B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> i do not really think it a major advantage. >> if you can use "AD is secure" proposal and let NAT-PT box to validate >> DNSsec signature, we can get the same effect with NAT-PT. >Using "AD is secure" add extra complexity. then why is "AD is secure" proposed? it is to avoid implementing complex crypto operations in every resolver implementation. >Another big issue with NAT-PT: you can not use it >to enable an Ipv6-only resolver to query data from >an Ipv4 only DNS server... (in the general issue to make >DNS interoperate smoothly between IPv4 & IPv6 only worlds) as long as DNS-ALG is IPv4/v6 dual stack, it should be okay. >Also, as i explain earlier, NAT64 scales better. with NAT-PT you can do the same, with multiple DNS-ALG returning different address prefixes. (it is documented in TRT RFC) >> one big disadbantage: abuses IPv4 mapped address. >you still haven't convince me about the severity of those problems. >I think I made clear today that those issues can be addressed. i disagree, this is not just a firewall issue. it affects end nodes and applications. and it is impractical to ask every applications to implement IN6_IS_ADDR_V4MAPPED() goofs. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 04:01:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07045 for ; Tue, 17 Sep 2002 04:01:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rDJy-000IcQ-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 01:02:58 -0700 Received: from ny-ppp023.iij-us.net ([216.98.99.23] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rDJR-000IaD-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 01:02:26 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id CCE317B9; Tue, 17 Sep 2002 17:02:20 +0900 (JST) To: v6ops@ops.ietf.org In-reply-to: itojun's message of Tue, 17 Sep 2002 16:41:24 +0900. <20020917074124.75BEB7B9@starfruit.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIIT/NAT64 is similar to RSIP From: Jun-ichiro itojun Hagino Date: Tue, 17 Sep 2002 17:02:20 +0900 Message-Id: <20020917080220.CCE317B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk NAT64 is still not in v6ops charter, btw. we should go back to ngtrans. >>Also, as i explain earlier, NAT64 scales better. > with NAT-PT you can do the same, with multiple DNS-ALG returning > different address prefixes. (it is documented in TRT RFC) or single DNS-ALG returning different addreess prefix at random/round robin. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 04:04:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07091 for ; Tue, 17 Sep 2002 04:04:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rDMi-000Ilo-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 01:05:48 -0700 Received: from dhcp11.freenet.ams.attingo.nl ([212.123.202.101] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rDMC-000IlJ-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 01:05:16 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rDMA-0003p1-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 11:05:14 +0300 Message-id: <3D8609EC.5020707@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <20020916160510.EA2467B9@starfruit.itojun.org> Date: Mon, 16 Sep 2002 09:42:20 -0700 From: Alain Durand Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Jun-ichiro itojun Hagino wrote: >>> so tell me - assuming that there are mixture of IPv4/v6 dual stack >>> nodes and IPv6-only nodes in your site. when IPv4 traffic comes in to >>> your firewall box, how a firewall can decide if it should let the >>> traffic go through as is, or to translate it in SIIT way? >>> >>> >>If it is v4 traffic, the firewall applies v4 sanity checks. >>The SIIT box does not need to be collocated with the >>firewall. >>Inbound packets that need translation (at least in NAT64) >>have an IPv4 dst address of one of the NAT64/SIIT gateways. >>They are easily identifiable by the firewalls if necessary. >> >>What is the problem? >> >> > > so you assume every IPv6 site to have two IPv4 addresses, instead of 1? > people wants to collocate their firewall and SIIT, to reduce IPv4 > address requirements. > I'm not assuming that. Please read more carefully what I wrote. --> 'The SIIT box does not need to be collocated with the firewall.' It does not mean it can not. >>>>Actually, I think that a solution like this one (SIIT+NAT64) >>>>would enable me to deploy an Ipv6 only island in my network >>>>with reasonable chances to make it work >>>>(that is, no worse than today's NAT) >>>> >>>> >>> SIIT/NAT64 are RSIP for IPv4 and IPv6 - end node knows what needs to >>> be done at NAT box, and end node must act like IPv4 box (see RFC2765 >>> page 6 for very strange description - it asks IPv6-only node to compute >>> IPv4 AH checksum). i don't think they are workable even in IPv6-only >>> cloud. >>> >>> >>SIIT/NAT64 is not RSIP. It does not negotiate anything with the NAT box >>It is much more like plain IPv4 NAT. Same model. Things that work >>today with IPv4 NAT still work with NAT64. Things that do not work >>with IPv4 NAT (like IPsec) still do not work with NAT64. >> >> > > SIIT/NAT64 is RSIP. a proof - SIIT/NAT64 FTP client has to know > about how to deal with PORT/PASV command, even though they run on > IPv6-only stack. > > If the IPv6-only node only implements EPSV/EPRT > (with IPv6 address support only), it won't be able to use FTP over > SIIT/NAT64. SIIT/NAT64 imposes very strange requirement to the end > devices. > > normal NAT box, and good translators, does not impose any new > requrirement to end clients. NAT-PT and TRT requires no modification > at all to IPv6-only (or IPv4/v6 dual stack) nodes in the cloud > I may be ignorant, then please educate me with a clear example how NAT64 is different from NAT-PT in that regard. An IPv6-only end node working in an NAT64 environement will have to inplement what you call SIIT kernel behavior, that's all. the 'peer' address will be an IPv6 address, the same way as NAT-PT. It just happend that this address is a v4-mapped address, but as it would be sent over the wire, I still see no difference with NAT-PT in that regard. - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 04:12:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07211 for ; Tue, 17 Sep 2002 04:12:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rDUR-000JEA-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 01:13:47 -0700 Received: from dhcp11.freenet.ams.attingo.nl ([212.123.202.101] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rDTv-000JDj-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 01:13:15 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rDTu-0003pc-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 11:13:14 +0300 Message-id: <3D862307.6060705@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <200209161736.g8GHaB025618@astro.cs.utk.edu> Date: Mon, 16 Sep 2002 11:29:27 -0700 From: Alain Durand Subject: Bridging IPv6 only networks To: Keith Moore Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Keith Moore wrote: >>NAT is not a perfect solution, but a solution that, like it or not, >>the Internet is now very familiar with. We know the limits, and >>where it works, it works rather well. >> >> > >I strongly disagree. Most network admins are still not familiar >with the problems NAT causes. Most network admins still do not understand >the limits of NAT. No general workarounds for NAT have been identified. >NAT "works" only by drastically decreasing the flexibility of the Internet >to support new applications, so claims that it "works rather well" need >to be taken with a large dose of salt. > >Keith > > [I've changed the title of this thread, as the discussion is no longer on Ipv4-mapped addresses] Don't take me wrong, I'm not saying NAT is a perfect solution, far from that. I'm saying the model is well understood, partly thanks to you Keith. We know where it works and where it does not. That knowledge may or may not have percolated to all network admin, but its a different issue. I'm not advocating NAT instead of IPv6, I'm saying that NAT-like (NAT64/SIIT) technology would enable to deploy IPv6-only networks. Such hosts will work exactly the same as IPv4 hosts that are today behind a NAT when talking to the IPv4 world and benefit from end-to-end connectivity when talking to the IPv6 only world. The success (or failure) of IPv6 will not be measured by how well early deployment using dual-stack technique will work, but by how well large to very large IPv6-only networks will operate. One think that we learned in the last 2 years by studying DNS, SMTP, SIP & friends is that, in order to keep the Internet from fragmenting and being balkanized, nodes needs to access basic services regardless of the IP version they are using. The current operational approach is to mandate dual stack in the core infrastructure pieces of the Internet: SMTP relays, DNS resolvers/servers,... This approach works well in the early days, when the 'penetration rate' of IPv6 is low (say < 10%) and will not be an issue when this rate will be 80% or more (access to v4 services will not be critical anymore) but I'm concerned that this will not work very well when IPv6 penetration rate will be something like 50% and large to very large IPv6-only network will be a reality. I think bridging both world at the IP layer makes more sense than bridging them at upper layers, and NAT-like technology is a natural candidate for that purpose. - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 04:40:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07693 for ; Tue, 17 Sep 2002 04:40:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rDvt-000Kz5-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 01:42:09 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17rDvN-000Kvj-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 01:41:37 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17rDvM-0002gT-00; Tue, 17 Sep 2002 09:41:36 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17rDvL-0002gO-00; Tue, 17 Sep 2002 09:41:35 +0100 Received: from hursley.ibm.com (dhcp222-1.zurich.ibm.com [9.4.222.1]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA25102; Tue, 17 Sep 2002 09:41:34 +0100 Message-ID: <3D86EACB.FA58A6A6@hursley.ibm.com> Date: Tue, 17 Sep 2002 10:41:47 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Alain Durand CC: Keith Moore , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: Bridging IPv6 only networks References: <200209161736.g8GHaB025618@astro.cs.utk.edu> <3D862307.6060705@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alain Durand wrote: ... > I think bridging both world at the IP layer makes more sense than > bridging them at upper layers, I disagree with this generalisation. There are scenarios where this may be true, but there are others where application level proxies or edge servers may make more sense. The 6net project is exploring both of these approaches. It's too soon to draw conclusions, but I hope we will get enough experience with both to learn which scenarios make sense. Brian From owner-v6ops@ops.ietf.org Tue Sep 17 10:03:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15311 for ; Tue, 17 Sep 2002 10:03:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rIxA-000FfU-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 07:03:48 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17rIwz-000Ff3-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 07:03:37 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25882; Tue, 17 Sep 2002 08:03:35 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8HE3XA07611; Tue, 17 Sep 2002 16:03:33 +0200 (MEST) Date: Tue, 17 Sep 2002 15:06:50 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: Jun-ichiro itojun Hagino Cc: Alain Durand , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20020916160510.EA2467B9@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I suspect the root of this argument is whether NAT as we know it in IPv4 (with DNS-ALG, FTP-ALG, etc) is "good enough". If so NAT-PT is what we need. Or do we want to improve on that? For instance, do we want improvements that allows one to take advantage DNSSEC through the NAT? Until we agree of the right approach or approaches at that level I think the detail discussion is rather pointless. > SIIT/NAT64 is RSIP. a proof - SIIT/NAT64 FTP client has to know > about how to deal with PORT/PASV command, even though they run on > IPv6-only stack. If the IPv6-only node only implements EPSV/EPRT > (with IPv6 address support only), it won't be able to use FTP over > SIIT/NAT64. SIIT/NAT64 imposes very strange requirement to the end > devices. FWIW RSIP has a lot of other implications as it comes to port number allocation and SPI allocation in the stacks. The assumptions behind SIIT is that the node is dual stack (the protocols as well as the applications) but the node doesn't have a permanent IPv4 address and the local network infrastructure does not support IPv4. With those assumptions there aren't any strange requirements on the devices (ignoring the AH suggestion in the RFC:-); the ftp implementation on a dual stack node already needs to support old stuff when communicating with IPv4 addresses. Erik From owner-v6ops@ops.ietf.org Tue Sep 17 10:40:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17150 for ; Tue, 17 Sep 2002 10:40:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rJYB-000IKn-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 07:42:03 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17rJY2-000IKY-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 07:41:55 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8HEdK017461; Tue, 17 Sep 2002 10:39:20 -0400 (EDT) Message-Id: <200209171439.g8HEdK017461@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Jun-ichiro itojun Hagino , Alain Durand , v6ops@ops.ietf.org Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt In-reply-to: (Your message of "Tue, 17 Sep 2002 15:06:50 +0200.") Date: Tue, 17 Sep 2002 10:39:19 -0400 X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I suspect the root of this argument is whether NAT as we know it > in IPv4 (with DNS-ALG, FTP-ALG, etc) is "good enough". > If so NAT-PT is what we need. that begs the question "good enough for what?" > Or do we want to improve on that? > For instance, do we want improvements that allows one to take advantage > DNSSEC through the NAT? I propose three guidelines: 1. communication between v6-capable nodes MUST NOT use NAT, so applications that do not tolerate NAT can use v6. 2. views of DNS MUST be kept consistent between v4 and v6, except possibly for limited portions of the net for which some DNS ALG is necessary, and even then we need to discourage it. in other words, don't use NAT as an excuse to pollute DNS. 3. if it is necessary/desirable to extend the flexibility of communication between v4 and v6 hosts (v4-v6 NAT) this should patterned after mechanisms developed for v4-v4 NAT. this will minimize impact on software written to take advantage of v4-v4 NAT workarounds. in other words, NAT is a disaster, and attempts to solve the problem (DNSALG, RSIP, MIDCOM) should be sufficient evidence that there are no good solutions. let's keep v6ops out of the business of generating more bad solutions. From owner-v6ops@ops.ietf.org Tue Sep 17 11:26:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18810 for ; Tue, 17 Sep 2002 11:26:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rKFg-000Kpp-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 08:27:00 -0700 Received: from ny-ppp022.iij-us.net ([216.98.99.22] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rKFa-000KpK-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 08:26:55 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 1DE8F7B9; Wed, 18 Sep 2002 00:26:46 +0900 (JST) To: Erik Nordmark Cc: v6ops@ops.ietf.org Cc: ngtrans@sunroof.eng.sun.com Reply-To: ngtrans@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Tue, 17 Sep 2002 15:06:50 +0200. X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt From: Jun-ichiro itojun Hagino Date: Wed, 18 Sep 2002 00:26:46 +0900 Message-Id: <20020917152646.1DE8F7B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (since this is transition tool discussion replies to ngtrans please) >The assumptions behind SIIT is that the node is dual stack (the protocols >as well as the applications) but the node doesn't have a permanent IPv4 >address and the local network infrastructure does not support IPv4. >With those assumptions there aren't any strange requirements on the devices >(ignoring the AH suggestion in the RFC:-); the ftp implementation on a >dual stack node already needs to support old stuff when communicating with >IPv4 addresses. if the above assumption is true, what do you intend to do about the dual use of IPv4 mapped address? telnet client on dual stack machine would make a send(2) request to ::ffff:a.b.c.d, which will be captured by an AF_INET6 socket, and goes out of the node as IPv4 packet. there's no documented way in which ::ffff:a.b.c.d would go out as IPv6 packet. either RFC2553 API does not work, or SIIT dose not work. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 13:56:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23757 for ; Tue, 17 Sep 2002 13:56:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rMbI-0003f5-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 10:57:28 -0700 Received: from dhcp4.kurtis.pp.se ([195.43.225.73] helo=laptop.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 17rMbD-0003cj-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 10:57:23 -0700 Received: from laptop.kurtis.pp.se (localhost [127.0.0.1]) by laptop.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id g8HHuUbu003576; Tue, 17 Sep 2002 19:56:46 +0200 (CEST) Date: Tue, 17 Sep 2002 17:02:13 +0200 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org To: Alain Durand From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <72AA3B4C-CA4E-11D6-B19C-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > NAT is not a perfect solution, but a solution that, like it or not, > the Internet is now > very familiar with. We know the limits, and where it works, it works > rather well. > This is because this model is well understood today that I think > SIIT/NAT64 > is workable. > If NAT works so well in the first place, why do we then need IPv6 at all? - kurtis - From owner-v6ops@ops.ietf.org Tue Sep 17 14:00:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24002 for ; Tue, 17 Sep 2002 14:00:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rMfr-00041i-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 11:02:11 -0700 Received: from ny-ppp020.iij-us.net ([216.98.99.20] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rMfn-00041R-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 11:02:08 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 6DB7B7B9; Wed, 18 Sep 2002 03:02:02 +0900 (JST) To: v6ops@ops.ietf.org Subject: venue network setup X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Wed, 18 Sep 2002 03:02:02 +0900 Message-Id: <20020917180202.6DB7B7B9@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk here's some details about venue network setup. itojun 802.11b wireless - ESSID is "v6ops" (shouldn't matter if you set your laptop to accept "ANY") IPv4 - use DHCP. IPv6 - use stateleses autoconf. IPv6 transport-ready nameserver is at 2001:240:5ff::53. From owner-v6ops@ops.ietf.org Tue Sep 17 14:50:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25926 for ; Tue, 17 Sep 2002 14:50:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNR8-0007QI-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 11:51:02 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17rNR4-0007Po-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 11:50:58 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 53B2B28B02 for ; Tue, 17 Sep 2002 18:50:58 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt In-Reply-To: Message from Kurt Erik Lindqvist of "Tue, 17 Sep 2002 17:02:13 +0200." <72AA3B4C-CA4E-11D6-B19C-000393AB1404@kurtis.pp.se> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 17 Sep 2002 18:50:58 +0000 Message-Id: <20020917185058.53B2B28B02@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > If NAT works so well in the first place, why do we then need IPv6 at all? i expect that question to come up quite a lot, as part of the business case analysis. "i've got 20,000 ip-speaking devices, but only 7 of them have universally unique addresses, the rest are in private address space because i was not able to get a class B. if i move to ipv6 i can get my own /48 but it will be in my isp's address space, which will make multihoming hard and make switching providers even harder. do i really want to have to renumber, even with ipv6's extensive automated assistance for this, whenever there's a rate war at my local transit exchange?" and then will come the question you gave above. (i'm done grousing about A6 -- that's a dead issue as far as i'm concerned. but the problems A6 was supposed to solve or avoid didn't die with it, and we're going to have to grapple with the business case analysis every step of the way to full ipv6 deployment. unfortunately, the early adopters are all organizations of the kind who get their address space from RIR's rather than from their upstream ISP's, so this issue hasn't yet seemed real here.) From owner-v6ops@ops.ietf.org Tue Sep 17 15:08:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26437 for ; Tue, 17 Sep 2002 15:08:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNje-0008nX-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 12:10:10 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNjU-0008l2-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 12:10:02 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNjO-0003wo-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 22:09:54 +0300 Message-id: <3D868E3E.60107@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Date: Mon, 16 Sep 2002 19:06:54 -0700 From: Alain Durand Subject: comments on draft-ietf-ngtrans-mech-v2-00.txt To: erik.nordmark@Sun.COM, v6ops@ops.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] In the intoduction: The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. We expect that most nodes in the Internet will need such compatibility for a long time to come, and perhaps even indefinitely. However, IPv6 may be used in some environments where interoperability with IPv4 is not required. IPv6 nodes that are designed to be used in such environments need not use or even implement these mechanisms => This last paragraph could be read as a hint that IPv6 nodes do not have to implement dual stack if and only they it will never have to interoperate in any way with any IPv4 node. I think that in its introduction, this document should not close the door to Ipv6-only devices interoperating with IPv4 devices via some sort of relays. 1.1 terminology IPv6-native address: The remainder of the IPv6 address space. An IPv6 address that bears a prefix other than 0:0:0:0:0:0. => It will be good to have a terminology to distinguish IPv6 addresses that embed IPv4 addresses for automatic tunneling purposes (6to4, Isatap) from other 'regular' types of Ipv6 addresses. Modes of operation of IPv6/IPv4 nodes IPv6-only operation: An IPv6/IPv4 node with its IPv6 stack enabled and its IPv4 stack disabled. IPv4-only operation: An IPv6/IPv4 node with its IPv4 stack enabled and its IPv6 stack disabled. IPv6/IPv4 operation: An IPv6/IPv4 node with both stacks enabled. => the word 'stack' is confusing here. Does it covers the kernel only or does it cover the libraries and applications as well? How to differenciate a node with an IPv6 kernel but no IPv6 application? Example: a v6 dual stack node with a popd listening only on Ipv4 sockets? => And even from a kernel perspective, the work 'stack enabled' is confusing. Does it mean that the kernel has code to process IPv6 packets? Does it mean that an IPv6 address has been configured on an interface? Is a node with only link local address configured operating in IPv6/IPv4 mode? What about loopback only? What about a node listening to RA on an IPv4-only network where a rogue IPv6 router is sending a bogus prefix? 2. Dual IP Layer Operation The most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes is by providing a complete IPv4 implementation. IPv6 nodes that provide a complete IPv4 and IPv6 implementations are called "IPv6/IPv4 nodes." => Same comment as above. 2.2. DNS => This section should say that the actual DNS query can be done using either IPv4 or Ipv6 as transport. => On an IPv6-only node, would it be correct for a resolver library recieving only A answers for a name to address question to pass the application an IPv6 address using the IPv4-mapped format? [This is an asumption made in NAT64] 2.3. Advertising Addresses in the DNS The recommendation is that AAAA records for a node should not be added to the DNS until all of these are true: 1) The address is assigned to the interface on the node. 2) The address is configured on the interface. 3) The interface is on a link which is connected to the IPv6 infrastructure. => I think a extra rule is needed: The applications have to be IPv6 ready. (see my comment on IPv4/IPv6 operation). However, what to do when some services are IPv6 ready and some are not? Example, there is a telnetd listening on v4 and v6, but popd only listen on v4? 4.1. Ingress Filtering The decapsulating node MUST verify that the tunnel source address is acceptable before forwarding decapsulated packets to avoid circumventing ingress filtering [13]. Note that packets which are delivered to transport protocols on the decapsulating node SHOULD NOT be subject to these checks. For bidirectional configured tunnels this is done by verifying that the source address is the IPv4 address of the other end of the tunnel. For unidirectional configured tunnels the decapsulating node MUST be configured with a list of source IPv4 address prefixes that are acceptable. Such a list MUST default to not having any entries i.e. the node has to be explicitly configured to forward decapsulated packets received over unidirectional configured tunnels. => This only applies to configured tunnels, and CAN NOT be implemented for automatic tunnels like 6to4 using relay routers. I understand this is a sub-section of '4 Configured Tunneling' but this somehow contradic the text in the security considerations. 6. Security Considerations Tunneling is not known to introduce any security holes except for the possibility to circumvent ingress filtering [13]. This is prevented by requiring that decapsulating routers only forward packets if they have been configured to accept encapsulated packets from the IPv4 source address in the receive packet. => This is not true for automatic tunneling (see above comment) I think that any kind of automatic tunneling mechanism using open relays such a 6to4 creates serious risks in the Internet. - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 15:09:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26458 for ; Tue, 17 Sep 2002 15:09:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNkL-0008qu-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 12:10:53 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNkG-0008qg-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 12:10:50 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNkB-0003x6-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 22:10:43 +0300 In-reply-to: <20020917070137.A05457C7@starfruit.itojun.org> Message-id: <4F7663DF-CA0F-11D6-8198-00039376A6AA@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Date: Tue, 17 Sep 2002 00:30:16 -0700 From: Alain Durand Subject: Re: SIIT/NAT64 is similar to RSIP To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Tuesday, September 17, 2002, at 12:01 AM, Jun-ichiro itojun Hagino wrote: >> But it has serious advantages over NAT-PT. >> It scales much better and does not break DNSsec. > > i do not really think it a major advantage. > if you can use "AD is secure" proposal and let NAT-PT box to validate > DNSsec signature, we can get the same effect with NAT-PT. Using "AD is secure" add extra complexity. Another big issue with NAT-PT: you can not use it to enable an Ipv6-only resolver to query data from an Ipv4 only DNS server... (in the general issue to make DNS interoperate smoothly between IPv4 & IPv6 only worlds) Also, as i explain earlier, NAT64 scales better. > one big disadbantage: abuses IPv4 mapped address. you still haven't convince me about the severity of those problems. I think I made clear today that those issues can be addressed. - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 15:09:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26522 for ; Tue, 17 Sep 2002 15:09:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNjt-0008q1-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 12:10:25 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNjm-0008nE-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 12:10:20 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNjb-0003wu-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 22:10:07 +0300 Message-id: <3D86920B.1060801@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <20020917015922.C48267B9@starfruit.itojun.org> Date: Mon, 16 Sep 2002 19:23:07 -0700 From: Alain Durand Subject: Re: SIIT/NAT64 is similar to RSIP To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Jun-ichiro itojun Hagino wrote: > no, the above description is incorrect. > > SIIT/NAT64 environment: > For an FTP client on IPv6 only kernel (on the lefthand side of the > diagram) to be able to contact and transfer files across SIIT box, > the FTP client has to implement and understand IPv4 FTP commands, > such as PORT and PASV. this is not a normal requirement to IPv6-only > FTP client. IPv6-only FTP client normally implement EPSV/EPRT, for > protocol #2 (IPv6) only, and that's all. remember SIIT/NAT64 box will > not rewrite the payload of packets. > so, the FTP client knows about IPv4 (= outside world from the SIIT box). > this is why i call SIIT/NAT64 similar to RSIP. > > NAT-PT environment: > FTP client on IPv6 only kernel (or IPv6/v4 dual stack kernel) talks > EPSV/EPRT, with protocol #2 (IPv6). NAT-PT box will translate the > content of the FTP control traffic into IPv4 ones (PORT/PASV). > therefore, FTP client is seeing IPv6 peer from FTP protocol point > of view. > >itojun > > >SIIT/NAT64 environment > >FTP client >========== AF_INET6 API >IPv6 only kernel SIIT box IPv4 FTP server > | | | |a.b.c.d >==+==============================+= =+============+== > IPv6 traffic IPv4 traffic > (::ffff:a.b.c.d) > >SIIT/NAT64 environment > >FTP client >========== AF_INET6 API >IPv6 only/dualstack NAT-PT box IPv4 FTP server > | | | |a.b.c.d >==+==============================+= =+============+== > IPv6 traffic IPv4 traffic > (to some fake address) > > I think I now understand your problem. What you say is true if and only if the ftp client has internal knowledge that ::ffff:a.b.c.d is a special address that is in fact an IPv4 address. That is, FTP looks at it in a sockaddr_in/AF_INET and not a sockaddr_in6/ AF_INET6 structure. This does not have to be the case. Remove that knowledge from the application/kernel and then you do not need anymore PORT/PASV. - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 15:10:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26545 for ; Tue, 17 Sep 2002 15:09:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNk0-0008qJ-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 12:10:32 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNjv-0008q0-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 12:10:29 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNjo-0003wz-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 22:10:20 +0300 In-reply-to: <20020917023317.1A85B7B9@starfruit.itojun.org> Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Date: Mon, 16 Sep 2002 22:16:45 -0700 From: Alain Durand Subject: Re: SIIT/NAT64 is similar to RSIP To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] On Monday, September 16, 2002, at 07:33 PM, Jun-ichiro itojun Hagino wrote: > >> This does not have to be the case. Remove that knowledge from the >> application/kernel >> and then you do not need anymore PORT/PASV. > > if you remove the knowledge, FTP client on IPv6-only machine cannot > transfer files from/to IPv4 FTP server (since IPv4 FTP server does not > understand EPSV/EPRT, with protocol #2). Not if your FTP client is IPv6-only!!! - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 15:23:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27079 for ; Tue, 17 Sep 2002 15:23:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNy7-000A0M-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 12:25:07 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNy0-0009yy-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 12:25:02 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNxw-000408-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 22:24:56 +0300 Message-id: <3D877034.5000005@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Date: Tue, 17 Sep 2002 11:11:00 -0700 From: Alain Durand Subject: Part of the charter? (was Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt) To: Erik Nordmark Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=SUBJ_HAS_Q_MARK,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Erik Nordmark wrote: >I suspect the root of this argument is whether NAT as we know it >in IPv4 (with DNS-ALG, FTP-ALG, etc) is "good enough". >If so NAT-PT is what we need. > >Or do we want to improve on that? >For instance, do we want improvements that allows one to take advantage >DNSSEC through the NAT? > >Until we agree of the right approach or approaches at that level >I think the detail discussion is rather pointless. > I agree Itojun & I went a bit too far in the details of NAT64. This was just to illustrate the point that IPv4-mapped addresses can be used on the wire. Now, to up-level the NAT discussion, the question IMHO is not so much to ask if NAT as we know it in v4 is good enough or not, but to really understand how v4 and v6 interoperate, not in the early days of transition where IPv6 only exists is some leaf sites, but when both IPv4 and IPv6 represent a large portion of the entire Internet. A few points: a) The Internet is one. (RFC2826). In particular, the DNS name space is the same for both v4 and v6. b) There will be a point where IPv6-only devices will show up. c) There will be a point where IPv6-only networks will show up. The current thinking for a) and b) is to heavily use dual-stack in the infrastructure. (DNS resolver/server, SMTP relays,...) Does this approach still makes sense for c) ? Or another way to put it, when IPv6 penetration is < 10%, inter-operability with IPv4 is critical, dual-stack on the infrastructure is an acceptable price. When IPv6 penetration is > 80%, such inter-operability may not be as important any more But what should happen in the 20-70% range? There are several approaches: 1) keep dual-stacking the infrastructure until the end of the times. 2) put ALGs at the boundaries of v4 and v6. Btw, who remember the days in Sendmail where there were 'well known' Bitnet and UUCP relays? Personal opinion, not sure I want to go there... 3) explore IP layer bridging. If we go that route, we can argue to see if IPv4 NAT is a good enough model or not, revisit NAT-PT, explore NAT64 or invent something different. So maybe the first question to ask is whether ot not looking at the coexistence of IPv4 and IPv6 in this middle phase of transition (20-70%) is part of the v6Ops charter or not. - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 15:23:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27098 for ; Tue, 17 Sep 2002 15:23:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rNyb-000A29-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 12:25:37 -0700 Received: from [216.155.166.225] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rNyU-000A10-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 12:25:33 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rNyQ-00040E-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 22:25:26 +0300 Message-id: <3D877181.2060107@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <72AA3B4C-CA4E-11D6-B19C-000393AB1404@kurtis.pp.se> Date: Tue, 17 Sep 2002 11:16:33 -0700 From: Alain Durand Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: Kurt Erik Lindqvist Cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] >> >> NAT is not a perfect solution, but a solution that, like it or not, >> the Internet is now >> very familiar with. We know the limits, and where it works, it works >> rather well. >> This is because this model is well understood today that I think >> SIIT/NAT64 >> is workable. >> > > If NAT works so well in the first place, why do we then need IPv6 at all? Don't ge me wrong, NAT does not work very well. We still need v6. Bridging IPv4 and IPv6 is a temporary/transition solution. So the idea is: - use v6, you'll have end to end connectivity between v6 nodes. - but you still want to maintain some level of interoperability with v4, but don't expect miracles there. NAT is not a very good answer, but it is the best we have so far. - Alain. From owner-v6ops@ops.ietf.org Tue Sep 17 16:32:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29054 for ; Tue, 17 Sep 2002 16:32:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rP29-000FDg-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 13:33:21 -0700 Received: from adsl-63-201-129-42.dsl.snfc21.pacbell.net ([63.201.129.42] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rP25-000FDU-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 13:33:17 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 99C317BA; Wed, 18 Sep 2002 05:33:13 +0900 (JST) To: Paul Vixie Cc: v6ops@ops.ietf.org In-reply-to: paul's message of Tue, 17 Sep 2002 18:50:58 GMT. <20020917185058.53B2B28B02@as.vix.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: renumbering From: Jun-ichiro itojun Hagino Date: Wed, 18 Sep 2002 05:33:13 +0900 Message-Id: <20020917203313.99C317BA@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> If NAT works so well in the first place, why do we then need IPv6 at all? > >i expect that question to come up quite a lot, as part of the business case >analysis. "i've got 20,000 ip-speaking devices, but only 7 of them have >universally unique addresses, the rest are in private address space because >i was not able to get a class B. if i move to ipv6 i can get my own /48 but >it will be in my isp's address space, which will make multihoming hard and >make switching providers even harder. do i really want to have to renumber, >even with ipv6's extensive automated assistance for this, whenever there's >a rate war at my local transit exchange?" and then will come the question >you gave above. > >(i'm done grousing about A6 -- that's a dead issue as far as i'm concerned. >but the problems A6 was supposed to solve or avoid didn't die with it, and >we're going to have to grapple with the business case analysis every step >of the way to full ipv6 deployment. unfortunately, the early adopters are >all organizations of the kind who get their address space from RIR's rather >than from their upstream ISP's, so this issue hasn't yet seemed real here.) i have renumbered my home (/48) more than a couple of times without any problem. yes, it may not extend naturally to enterprise network where # of nodes are 10^4, but anyway, - IPv6 address autoconfiguration - multiple IPv6 address per interface - source/destination address selection makes renumbering so much easier than IPv4 case. you just need to be careful about DNS TTL and RA address/prefix lifetime. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 16:40:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29382 for ; Tue, 17 Sep 2002 16:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPAi-000FuZ-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 13:42:12 -0700 Received: from adsl-63-201-129-42.dsl.snfc21.pacbell.net ([63.201.129.42] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rPAc-000Ftl-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 13:42:07 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id DC20F7BA; Wed, 18 Sep 2002 05:42:03 +0900 (JST) To: Alain Durand Cc: erik.nordmark@Sun.COM, v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Mon, 16 Sep 2002 19:06:54 MST. <3D868E3E.60107@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-ietf-ngtrans-mech-v2-00.txt From: Jun-ichiro itojun Hagino Date: Wed, 18 Sep 2002 05:42:03 +0900 Message-Id: <20020917204203.DC20F7BA@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >=> On an IPv6-only node, would it be correct for a resolver library > recieving only A answers for a name to address question to > pass the application an IPv6 address using the IPv4-mapped format? > [This is an asumption made in NAT64] really depends on the API you are using. by default, getaddrinfo should not return them. with ai_flags = AI_V4MAPPED, you may get them. >>2.3. Advertising Addresses in the DNS >> >> The recommendation is that AAAA records for a node should not be >> added to the DNS until all of these are true: >> >> 1) The address is assigned to the interface on the node. >> >> 2) The address is configured on the interface. >> >> 3) The interface is on a link which is connected to the IPv6 >> infrastructure. >=> I think a extra rule is needed: The applications have to be IPv6 ready. > (see my comment on IPv4/IPv6 operation). > However, what to do when some services are IPv6 ready and some are not? > Example, there is a telnetd listening on v4 and v6, but popd only > listen on v4? i don't think extra rule is needed. when multiple address (mixture of AAAA and A) are returned, client (like SMTP sender) should try to connect to all of them, just like when multiple A records are returned. so it is okay to have IPv4-only SMTP server running on top of IPv4/v6 dual stack node, and advertise both AAAA and A records. the client will try IPv6 connection, fails, and then try IPv4 connection. >>4.1. Ingress Filtering >=> This only applies to configured tunnels, and CAN NOT be implemented > for automatic tunnels like 6to4 using relay routers. > I understand this is a sub-section of '4 Configured Tunneling' > but this somehow contradic the text in the security considerations. why not? tunnel ingress box (= 6to4 relay router) should be located at topologically-correct location. >>6. Security Considerations >> >> Tunneling is not known to introduce any security holes except for the >> possibility to circumvent ingress filtering [13]. This is prevented >> by requiring that decapsulating routers only forward packets if they >> have been configured to accept encapsulated packets from the IPv4 >> source address in the receive packet. >=> This is not true for automatic tunneling (see above comment) > I think that any kind of automatic tunneling mechanism > using open relays such a 6to4 creates serious risks in the Internet. there also is another problem which applies to with configured tunnel as well. malicious party can inject IPv6-over-IPv4 packet to tunnel endpoint, to inject any IPv6 traffic to the Internet anonymously. itojun From owner-v6ops@ops.ietf.org Tue Sep 17 16:43:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29794 for ; Tue, 17 Sep 2002 16:43:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPDe-000G6p-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 13:45:14 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17rPDb-000G6S-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 13:45:11 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id F28FB28B01 for ; Tue, 17 Sep 2002 20:45:10 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: renumbering In-Reply-To: Message from Jun-ichiro itojun Hagino of "Wed, 18 Sep 2002 05:33:13 +0900." <20020917203313.99C317BA@starfruit.itojun.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 17 Sep 2002 20:45:10 +0000 Message-Id: <20020917204510.F28FB28B01@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > i have renumbered my home (/48) more than a couple of times without > any problem. yes, it may not extend naturally to enterprise network > where # of nodes are 10^4, but anyway, > - IPv6 address autoconfiguration > - multiple IPv6 address per interface > - source/destination address selection > makes renumbering so much easier than IPv4 case. you just need to be > careful about DNS TTL and RA address/prefix lifetime. there's no question that it's easier than the ipv4 case. congrats are in order on that point. however, at size 10**4 and above, renumbering of this kind will be expensive. and at size 10**5 and above, it will be constant/overlapping. my point was, that's a big reason why folks will ask "why not just use NAT?" now i'm thinking, please don't make NAT any harder than it already is. From owner-v6ops@ops.ietf.org Tue Sep 17 17:07:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00652 for ; Tue, 17 Sep 2002 17:07:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPaX-000IBD-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 14:08:53 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17rPaS-000IAr-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 14:08:48 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9448F57A3; Tue, 17 Sep 2002 17:08:47 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Sep 2002 17:08:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Date: Tue, 17 Sep 2002 17:08:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE925F@tayexc13.americas.cpqcorp.net> Thread-Topic: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Thread-Index: AcJeWJTnmnaQ8wQaQg+GkUHN/0TdzgANcYzw From: "Bound, Jim" To: "Keith Moore" , "Erik Nordmark" Cc: "Jun-ichiro itojun Hagino" , "Alain Durand" , X-OriginalArrivalTime: 17 Sep 2002 21:08:44.0131 (UTC) FILETIME=[67E65330:01C25E8E] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA00652 I really like Keiths bullets. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, September 17, 2002 10:39 AM > To: Erik Nordmark > Cc: Jun-ichiro itojun Hagino; Alain Durand; v6ops@ops.ietf.org > Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt > > > > I suspect the root of this argument is whether NAT as we know it > > in IPv4 (with DNS-ALG, FTP-ALG, etc) is "good enough". > > If so NAT-PT is what we need. > > that begs the question "good enough for what?" > > > Or do we want to improve on that? > > For instance, do we want improvements that allows one to > take advantage > > DNSSEC through the NAT? > > > I propose three guidelines: > > 1. communication between v6-capable nodes MUST NOT use NAT, so > applications that do not tolerate NAT can use v6. > > 2. views of DNS MUST be kept consistent between v4 and v6, except > possibly for limited portions of the net for which some DNS ALG > is necessary, and even then we need to discourage it. > > in other words, don't use NAT as an excuse to pollute DNS. > > 3. if it is necessary/desirable to extend the flexibility of > communication between v4 and v6 hosts (v4-v6 NAT) this should > patterned after mechanisms developed for v4-v4 NAT. this will > minimize impact on software written to take advantage of > v4-v4 NAT workarounds. > > in other words, NAT is a disaster, and attempts to solve the > problem (DNSALG, RSIP, MIDCOM) should be sufficient evidence > that there are no good solutions. let's keep v6ops out of the > business of generating more bad solutions. > > From owner-v6ops@ops.ietf.org Tue Sep 17 17:07:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00667 for ; Tue, 17 Sep 2002 17:07:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPai-000IBy-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 14:09:04 -0700 Received: from adsl-63-201-129-42.dsl.snfc21.pacbell.net ([63.201.129.42] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rPaU-000IB0-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 14:08:50 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D5E157B9; Wed, 18 Sep 2002 06:08:46 +0900 (JST) To: Alain Durand Cc: erik.nordmark@Sun.COM, v6ops@ops.ietf.org In-reply-to: Alain.Durand's message of Tue, 17 Sep 2002 13:59:37 MST. <3D8797B9.9040301@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on draft-ietf-ngtrans-mech-v2-00.txt From: Jun-ichiro itojun Hagino Date: Wed, 18 Sep 2002 06:08:46 +0900 Message-Id: <20020917210846.D5E157B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> i don't think extra rule is needed. when multiple address (mixture of >> AAAA and A) are returned, client (like SMTP sender) should try to >> connect to all of them, just like when multiple A records are returned. >> so it is okay to have IPv4-only SMTP server running on top of >> IPv4/v6 dual stack node, and advertise both AAAA and A records. >> the client will try IPv6 connection, fails, and then try IPv4 >> connection. >I have seens instances where this is a problem. >Some applications, like Netscape, only do name to address resolution once, >by fear of ssl connection theft (don't ask me wy they do that). >So if you contact a web site that is v6 aware, you'll get the v6 addresss. >Then, if you contact a pop server that is v4 only on the host, the >connection >will fail. then netscape won't work when some of the servers (like 66.218.71.83) are down when looking at www.yahoo.com. i don't think this is IPv6 problem, but problem in general with multiple address (A/AAAA) records. i'm not sure where is the best forum to discuss this. >>>=> This only applies to configured tunnels, and CAN NOT be implemented >>> for automatic tunnels like 6to4 using relay routers. >>> I understand this is a sub-section of '4 Configured Tunneling' >>> but this somehow contradic the text in the security considerations. >> why not? tunnel ingress box (= 6to4 relay router) should be located >> at topologically-correct location. >How do you reconcile this with RFC3068 An Anycast Prefix for 6to4 Relay >Routers ? IPv4 (outer) source address of the packet can be different from the 6to4 anycast prefix (192.88.99.x). RFC3068 doesn't specify what address should be used as IPv4 source. maybe RFC3068 should say something about it ("don't use 192.88.99.x as IPv4 source"). RFC3068 section 4.2: > The 6to4 relay routers that advertise the 6to4 anycast prefix will > receive packets bound to the 6to4 anycast address. They will relay > these packets to the IPv6 Internet, as specified in [RFC3056]. > > Each 6to4 relay router that advertise the 6to4 anycast prefix MUST > also provide an equivalent IPv4 unicast address. Packets sent to > that unicast address will follow the same processing path as packets > sent to the anycast address, i.e., be relayed to the IPv6 Internet. itojun ; <<>> DiG 9.3.0s20020722 <<>> www.yahoo.com. a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14538 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 10, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 1790 IN CNAME www.yahoo.akadns.net. www.yahoo.akadns.net. 290 IN A 66.218.71.83 www.yahoo.akadns.net. 290 IN A 66.218.71.84 www.yahoo.akadns.net. 290 IN A 66.218.71.86 www.yahoo.akadns.net. 290 IN A 66.218.71.87 www.yahoo.akadns.net. 290 IN A 66.218.71.89 www.yahoo.akadns.net. 290 IN A 66.218.71.80 www.yahoo.akadns.net. 290 IN A 66.218.71.81 ;; AUTHORITY SECTION: akadns.net. 161825 IN NS ZC.akadns.net. akadns.net. 161825 IN NS ZD.akadns.net. akadns.net. 161825 IN NS ZE.akadns.net. akadns.net. 161825 IN NS ZF.akadns.net. akadns.net. 161825 IN NS ZG.akadns.net. akadns.net. 161825 IN NS ZH.akadns.net. akadns.net. 161825 IN NS USE2.AKAM.net. akadns.net. 161825 IN NS NS1-93.AKAM.net. akadns.net. 161825 IN NS NS1-159.AKAM.net. akadns.net. 161825 IN NS ZA.akadns.net. ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(0.0.0.0) ;; WHEN: Wed Sep 18 06:03:18 2002 ;; MSG SIZE rcvd: 363 From owner-v6ops@ops.ietf.org Tue Sep 17 17:16:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01201 for ; Tue, 17 Sep 2002 17:16:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rPjK-000J0n-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 14:17:58 -0700 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17rPjH-000J0Y-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 14:17:55 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BBF72BEB; Tue, 17 Sep 2002 17:17:54 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Sep 2002 17:17:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Date: Tue, 17 Sep 2002 17:17:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9261@tayexc13.americas.cpqcorp.net> Thread-Topic: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Thread-Index: AcJeXvm7VhSsO/KsQsqyiznl65Cd3AAMFrxA From: "Bound, Jim" To: "Jun-ichiro itojun Hagino" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 17 Sep 2002 21:17:43.0568 (UTC) FILETIME=[A96DE100:01C25E8F] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01201 I believe if a packet comes in with v4mapped then a flag must be set that SIIT is in process. This was my recommendation on APIFOLKS a year ago. If an app gets back a v4mapped and asked for it then that would be known too. what we should do is document the cases that are not clear above. But we cannot break the API. I also believe of any NAT proposal I like and support SIIT since inception. For what it is worth. /jim > -----Original Message----- > From: Jun-ichiro itojun Hagino [mailto:itojun@iijlab.net] > Sent: Tuesday, September 17, 2002 11:27 AM > To: Erik Nordmark > Cc: v6ops@ops.ietf.org; ngtrans@sunroof.eng.sun.com > Subject: (ngtrans) Re: comments on > draft-itojun-v6ops-v4mapped-harmful-00.txt > > > (since this is transition tool discussion replies to > ngtrans please) > > >The assumptions behind SIIT is that the node is dual stack > (the protocols > >as well as the applications) but the node doesn't have a > permanent IPv4 > >address and the local network infrastructure does not support IPv4. > >With those assumptions there aren't any strange requirements > on the devices > >(ignoring the AH suggestion in the RFC:-); the ftp > implementation on a > >dual stack node already needs to support old stuff when > communicating with > >IPv4 addresses. > > if the above assumption is true, what do you intend to > do about the > dual use of IPv4 mapped address? telnet client on dual > stack machine > would make a send(2) request to ::ffff:a.b.c.d, which > will be captured > by an AF_INET6 socket, and goes out of the node as IPv4 packet. > there's no documented way in which ::ffff:a.b.c.d would > go out as IPv6 > packet. either RFC2553 API does not work, or SIIT dose > not work. > > itojun > From owner-v6ops@ops.ietf.org Tue Sep 17 17:48:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01715 for ; Tue, 17 Sep 2002 17:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rQDc-000Lt6-00 for v6ops-data@psg.com; Tue, 17 Sep 2002 14:49:16 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17rQDX-000Lrw-00 for v6ops@ops.ietf.org; Tue, 17 Sep 2002 14:49:11 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 76CA75462; Tue, 17 Sep 2002 17:49:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Sep 2002 17:49:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Date: Tue, 17 Sep 2002 17:49:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9269@tayexc13.americas.cpqcorp.net> Thread-Topic: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Thread-Index: AcJec+8RAJUgAlk3QH+xzS4qRvpZvwAIA/1A From: "Bound, Jim" To: "Kurt Erik Lindqvist" , "Alain Durand" Cc: "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 17 Sep 2002 21:49:09.0428 (UTC) FILETIME=[0D7D4740:01C25E94] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01715 Excellent question but what we don't need is more NAT and we do need IPv6. /jim > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Tuesday, September 17, 2002 11:02 AM > To: Alain Durand > Cc: Jun-ichiro itojun Hagino; v6ops@ops.ietf.org > Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt > > > > > > NAT is not a perfect solution, but a solution that, like it > or not, > > the Internet is now > > very familiar with. We know the limits, and where it works, > it works > > rather well. > > This is because this model is well understood today that I think > > SIIT/NAT64 > > is workable. > > > > If NAT works so well in the first place, why do we then need IPv6 at > all? > > - kurtis - > > > From owner-v6ops@ops.ietf.org Wed Sep 18 05:56:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07163 for ; Wed, 18 Sep 2002 05:56:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rbZk-0007fb-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 02:56:52 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17rbZa-0007eU-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 02:56:43 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8I9uV312641; Wed, 18 Sep 2002 16:56:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8I9spK19292; Wed, 18 Sep 2002 16:54:52 +0700 (ICT) From: Robert Elz To: Paul Vixie cc: v6ops@ops.ietf.org Subject: Re: renumbering In-Reply-To: <20020917204510.F28FB28B01@as.vix.com> References: <20020917204510.F28FB28B01@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Sep 2002 16:54:51 +0700 Message-ID: <19290.1032342891@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Tue, 17 Sep 2002 20:45:10 +0000 From: Paul Vixie Message-ID: <20020917204510.F28FB28B01@as.vix.com> | however, at size 10**4 and above, renumbering of this kind will be | expensive. The actual renumbering need not be expensive. At the minute it would be, but more tools/protocols can be developed to make the kind of renumbering we're talking about more or less invisible as far as the site is concerned (and yes, A6 would certainly have helped). We're nowhere near there yet, but we can get there - that is, make all of this possible. That isn't to require anyone to actually use this stuff if they don't trust it (the "I won't let anything reconfigure my router except for me" attitude). The other kind of renumbering (changing the internal structure of a net) will perhaps still be hard (though not as hard as for v4) - but running NAT doesn't help with this at all. Actually producing something that uses site local addressing where possible, to isolate local communications from the effects of a global prefix change is another thing that will assist with all of this, just as external renumbering is hidden by the use of 1918 addresses hidden behind a NAT. I have some students working on this now - they seem to have it all working in a prototype environment (to the stage where if you say telnet 3ffe:... it actually makes a connection (where possible) to fec0:... instead) That is, of course, going too far - if someone gives a numeric address, that's what should be used, but this makes it easier for their testing, as they don't get to own the DNS zone files, and so can't get their systems included easily, so they're currently just using numbers. The current implementation isn't suitable for use in the wild, but it does demonstrate that the method works, and site local addresses can be used without anyone needing to know a lot about it (the application obviously knows, and should be able to say "no", but most simply don't care). | and at size 10**5 and above, it will be constant/overlapping. Huh? What does the size of the net have to do with the frequency of renumbering - if anything, smaller nets are the ones that tend to shift around more frequently (they don't have the clout to get good deals from providers initially, nor do they usually engage in longer term agreements to achieve that - bigger places do). If implemented rationally, there's no reason that renumbering a large net should take a lot longer than a small one - that would only be the case if we started needing a lot of human intervention everywhere. That's something that we need to get away from (and that includes getting literal addresses out of filters and such, and instead using "my prefix" and then the rest of the address, where that's what we mean). | my point was, that's a big reason why folks will ask "why not just use NAT?" And the answer will be, that NAT achieves nothing, but does limit applications, some things just don't work. And once we get into an environment where the default isn't "everyone uses NAT", more of the kinds of applications that just don't work with NAT are likely to appear (there will be no reason for them not to). kre From owner-v6ops@ops.ietf.org Wed Sep 18 06:56:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08039 for ; Wed, 18 Sep 2002 06:56:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rcWY-000Cen-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 03:57:38 -0700 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 17rcWT-000CeH-01 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 03:57:34 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rcSf-0004Hl-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 13:53:37 +0300 Message-id: <3D8797B9.9040301@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <20020917204203.DC20F7BA@starfruit.itojun.org> Date: Tue, 17 Sep 2002 13:59:37 -0700 From: Alain Durand Subject: Re: comments on draft-ietf-ngtrans-mech-v2-00.txt To: Jun-ichiro itojun Hagino Cc: erik.nordmark@Sun.COM, v6ops@ops.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Jun-ichiro itojun Hagino wrote: >> >> >>=> I think a extra rule is needed: The applications have to be IPv6 ready. >> (see my comment on IPv4/IPv6 operation). >> However, what to do when some services are IPv6 ready and some are not? >> Example, there is a telnetd listening on v4 and v6, but popd only >> listen on v4? >> >> > > i don't think extra rule is needed. when multiple address (mixture of > AAAA and A) are returned, client (like SMTP sender) should try to > connect to all of them, just like when multiple A records are returned. > so it is okay to have IPv4-only SMTP server running on top of > IPv4/v6 dual stack node, and advertise both AAAA and A records. > the client will try IPv6 connection, fails, and then try IPv4 > connection. > I have seens instances where this is a problem. Some applications, like Netscape, only do name to address resolution once, by fear of ssl connection theft (don't ask me wy they do that). So if you contact a web site that is v6 aware, you'll get the v6 addresss. Then, if you contact a pop server that is v4 only on the host, the connection will fail. Sure can try to make Netscape to change (I did), but I'm affraid that there are many other applications that do not walk through the list of addresses returned by the DNS. >>>4.1. Ingress Filtering >>> >>> >>=> This only applies to configured tunnels, and CAN NOT be implemented >> for automatic tunnels like 6to4 using relay routers. >> I understand this is a sub-section of '4 Configured Tunneling' >> but this somehow contradic the text in the security considerations. >> >> > > why not? tunnel ingress box (= 6to4 relay router) should be located > at topologically-correct location. > > How do you reconcile this with RFC3068 An Anycast Prefix for 6to4 Relay Routers ? >>>6. Security Considerations >>> >>> Tunneling is not known to introduce any security holes except for the >>> possibility to circumvent ingress filtering [13]. This is prevented >>> by requiring that decapsulating routers only forward packets if they >>> have been configured to accept encapsulated packets from the IPv4 >>> source address in the receive packet. >>> >>> >>=> This is not true for automatic tunneling (see above comment) >> I think that any kind of automatic tunneling mechanism >> using open relays such a 6to4 creates serious risks in the Internet. >> >> > > there also is another problem which applies to with configured tunnel > as well. malicious party can inject IPv6-over-IPv4 packet to tunnel > endpoint, to inject any IPv6 traffic to the Internet anonymously. > I agree, this is a general problem. Tunnel decapsulators are basically acting as packet anomymiser... and defeat iTrace messages. - Alain. From owner-v6ops@ops.ietf.org Wed Sep 18 11:25:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17690 for ; Wed, 18 Sep 2002 11:25:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rgiV-0007tW-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 08:26:15 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rgiL-0007sT-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 08:26:06 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8IFPwo25132; Wed, 18 Sep 2002 18:25:59 +0300 Date: Wed, 18 Sep 2002 18:25:58 +0300 (EEST) From: Pekka Savola To: Cleve Mickles cc: v6ops@ops.ietf.org Subject: ISP scenarios comments In-Reply-To: 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,DOUBLE_CAPSWORD,EXCUSE_6 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, Some comments (and additional thoughts on missing sections). - DSL etc. scenarios need to consider (with coordination of unmanaged networks scenarios) at least still: * should dynamic/static prefixes be used? o static make many things (e.g. service registration, less need for DNS updates, reverse/forward DNS) easier o privacy considerations with static /48 prefixes: RFC3041 is pretty much useless - currently there is little text except for the DSL case, some issues to consider (something I quickly write down on the plane) in Core/Backbone networks: * routing protocol issues - same protocol (where applicable) for IPv6 and IPv4 or keep them separate? o same link state database for IS-IS? o problem: multi-topology IS-IS would often be needed (if v4/v6 topologies are slightly different, seems probable) o IMO: pick a different protocol for IPv6. We have OSPFv2 for v4 and IS-IS for v6-only. - Which one to pick: OSPFv3, IS-IS or RIPng (ugh..) * multicast issues - support is yet a bit .. raw or non-existant. - there is no MSDP, so there can be only one PIM domain currently - should we focus on SSM only * transition: how to enable v6 - v4/v6 dual stack everywhere? - tunneling (which kind: configured IP-in-IP, L2 tunneling (hardware restrictions on e.g. Cisco GSR, ...) - existing MPLS networks * addressing - which kind of addresses to use, prefix lengths? - avoid using site-locals * long-term plans/transition overview (this could possibly be a more generic document too) - what services could become v6-only soon (or sooner than others) -- and what would have to be done to make it so? - what must have v4 support for a long time yet (e.g. backup MX's, DNS servers, ...) o no need to think of the "exit plan for v4" for these yet, IMO. - what should be v6-enabled soon (or sooner than other services .. e.g. separate v4/v6 www cache service, recursive v4/v6 DNS cache server, ...) - what additional services would be nice to have in the ISP network (e.g. 6to4 relay) - section 2, scope: * I don't see why Ethernet _to the home_ is special, generalize? - section 3.1 * "Most networks employ some type of traffic engineering.." ==> s/Most/Many/ ? * s/over provisioning/overprovisioning/? * s/authentication( radius or tacacs)/authentication (e.g. radius or tacacs/ - section 3.2 * spell out "HFC". - section 3.3.1 * possibly delete the third paragraph ("The POTS..") -- irrelevant * definitely delete everything from there until the "Several models are used" -- completely irrelevant * s/through ATM, Ethernet/through e.g. Ethernet/ -- ATM is IMO a minor corner case here. - section 3.3.2.1 * one should discuss the difference of bridged/routed ATM encapsulation. This has significant impact on v6 deployment: with bridged, the xDSL box does not need to know about v6 at all (cost of v6 deployment is very small) * "The NSP edge router sees all subscribers as attached to the same Ethernet link.." -- really? I don't think this was the case; I thought everyone would have its own sub-interface and would have its own ACL's etc. - section 3.3.2.2.1 * spell out IPCP. - section 3.3.2.2.2 & 3.3.2.3.2 * extend "customer premises" in the figure a bit more to the right so "Modem" will fit in there. - section 3.3.3 * s/operates/operate/ - section 3.3.6 * "edge routers"; do you mean CPE or ISP-located edge routers (just to be clear)? - section 5 * one operational issue is being able to monitor respective v4/v6 traffic levels in dual-stack interfaces * another is that some SNMP tools barf on interfaces that don't have even a dummy IPv4 address On Fri, 13 Sep 2002, Cleve Mickles wrote: > Only one section of the draft has been updated. If > any of you have experience with DSL deployments please > take a look and send comments to the list or myself. > > Thanks, > > Cleve... > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Friday, September 13, 2002 7:45 AM > > To: IETF-Announce: > > Cc: v6ops@ops.ietf.org > > Subject: I-D ACTION:draft-mickles-v6ops-isp-cases-01.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Transition Scenarios for ISP Networks > > Author(s) : C. Mickles > > Filename : draft-mickles-v6ops-isp-cases-01.txt > > Pages : 20 > > Date : 2002-9-12 > > > > This document describes the different types of Internet Service > > Provider (ISP) networks in existence today. It will provide design > > and operational considerations in delivering network services to > > customers for five specific areas in an effort to better identify > > specific issues which may arise during a transition to IPv6. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-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-mickles-v6ops-isp-cases-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-mickles-v6ops-isp-cases-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 "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 14:00:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23719 for ; Wed, 18 Sep 2002 13:59:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rj6b-000Jp4-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 10:59:17 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rj6W-000JoJ-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 10:59:12 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 5AA327B9; Thu, 19 Sep 2002 02:58:57 +0900 (JST) To: v6ops@ops.ietf.org Subject: memo, 1st day AM X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 02:58:57 +0900 Message-Id: <20020918175857.5AA327B9@starfruit.itojun.org> X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk [not a official minutes] homework (mar) charter - swap 6 and 7? introduction charter/priorities toplevel goals - no comment task 1 - solicit input from operators ralph: IETF only, or outside IETF? mar: suppose we could do outside IETF too hinden: seems IETF only mar: will see what operators will bring in ?: who are network operators? mar: people deploying IPv6 in their networks - operators, not implementers, basically. try to outreach operators bound: transition tools? mar: see later slides templin: "operational" - "functional" or "efficiency" mar: "securely" "functional enough" "efficiently enough" - is it enough? bound: enterprise user/operator/..., we don't know plans for task 1 bound: DoD is deploying serious network. randy: nobody should speak for others - like vendors should not speak for enterprise. thomas: avoid having second party comment randy: speak in the first person huitema: comments from support guys? thomas: hard to draw a strict line mar: authoritatively on behalf of that party bound: example: tunnel performance issues <-> NAT hinden: vendors have contacts to customers. we need to be careful not alianating vendors. need to be clear about where the problem came from DNS - dnsop SMTP - apps area SIP - wrote allison about it, no response thomas: working with sip wg itojun: parser has ipv6 alain: not optimistic, based on attending sip huitema: v4-v4, v6-v6 is okay, v4-v6 may not be okay so there could be transition issues task 2 - input to ipv6 wg plans for task 2 - identify open issues bound: network management, snmp itojun: i have slide alain: topology discovery with snmp task 3 - ip version independent apps hesham: more of educational issue, not operational hain: it belongs to ipv6 working group huitema: task 1 - look at technology, how to use (operation concern). task 2 - how do i develop stuff (developer concern). plans for task 3 - phil nesser's document, blanchet: no update even though sent comment itojun: there are books. itojun: traps in scoped address task 4 - potential security risks for ipv4/v6 networks huitema: top-down, bottom-up itojun: i have some top-down as well as bottom-up slide ?: send bof thomas: yes, send has charter, ipv4 arp is not in charter, it was a bootstrap to key material. task 5 - viable solutions in common network types, into existing ipv4 net or new net huitema: remaining work from ngtrans, what to do? mar: ngtrans shuts down in a couple of weeks randy: shut down working group, mailing list kept open. alain: what should be move to ngtrans? mar: some transition tools are in v6ops charter. scenario work might identify some tool is needed. hain: can we refresh ngtrans document? - yes (randy) templin: combine mailing list? - too hard (randy) bound: it's not fair to shut it down and put existing work dangling state mar: on hold until deployment scenario documents. harold: (1) re-charter or start a new group? giving reason is good. in order to get this meeting focused, start a new group. bound: need some ruleset randy: read the original message on v6ops opening hinden: (1) plan is good (2) share concerns in ngtrans - concerns with closing wg. they will sent to somewhere else. issue of fairness? thomas: agree with harold alain: move ngtrans to sleeping mode? mar: ngtrans chair and ad will discuss. task 6 - advance standard-track RFCs, or move it historic transition mech, siit, natpt, 6to4 plan for task 6 transition mech update underway dependent on task 5 huitema: the way charter is written in a way that could piss off bound mar: no intention to make these 4 special, pls read task 7 bound: how you differentiate mechanisms listed here, and others? task 7 - identify and document open operational or security issues found in 5, work to resolve it cooperatively with other wg as a last resort, standardize additional transition mechanisms to resolve issues bound: ok, looks fine. list on task 6 are not special in technical sense huitema: reverse order of 7 and 6? alain: chater discussion, if we need to go to iesg, we need to do it alain: by naming 4 items, making them special alain: 6over4? - ipv6wg deering: move 6over4 to historic randy: to move forward, maybe good not dig into too much details. use ngtrans mailing list to discuss new transition techs. bound: scenario is important. outsiders are watching. be careful. droms: open security issues - resolve in ipv6wg, or v6ops? - droms: scenarios first - mar: we won't hold everything, based on deployment base bound: how do you determine? ?: difficult to decide which scenario makes sense, and which mechanism makes sense mar: iesg trusts us on judgement... templin: wording nit in charter. bound: why this time? what's the rush? hain: if need to recharter, recharter. randy: charter has been there, why you didn't comment that time bound: (can't take note) huitema: keep work on technical tasks behind the scene... limits on v6ops scope work will be pushed to the right groups/areas must get the full ietf involved in ipv6 we will cooperate with other groups, as needed it is NOT a primary purpose of v6ops to do any standardization work. other wg should work on ipv6. v6ops is last resort in terms of standardization work. priorities? scenario/solution for now, think about it for these 2 days moving from "what" to "how" open process fairness separate process discussion and technical discussion submission (email, i-d) author refinement wg acceptance wg charter interest from wg accepted as a work item by rough consensus have correspondeing goals/milestons in the charter editor selection wg last call - silence is not a consent thomas: mobile-ip - no presentation without mailing list discussion harold: will send to wg chairs list bound: works for me structured discussions slides "sense of room slide" helps tools mailing list archives webpage alain: delivery delays From owner-v6ops@ops.ietf.org Wed Sep 18 14:20:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24526 for ; Wed, 18 Sep 2002 14:20:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rjRV-000LY5-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 11:20:53 -0700 Received: from [149.99.32.11] (helo=mail2) by psg.com with esmtp (Exim 3.36 #1) id 17rjRS-000LXW-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 11:20:50 -0700 Received: from atp (unverified [149.99.32.50]) by mail2 (Rockliffe SMTPRA 4.2.2) with ESMTP id ; Wed, 18 Sep 2002 11:51:26 -0700 Message-ID: <1618173.1032373552640.JavaMail.Administrator@atp> Date: Wed, 18 Sep 2002 11:25:52 -0700 (PDT) From: bkhabs Reply-To: bkhabs@nc.rr.com To: pekkas@netcore.fi Subject: Re: ISP scenarios comments Cc: v6ops@ops.ietf.org, micklesc@aol.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: E-mailanywhere V2.0 (Windows) X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_NAME_NO_SPACES,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, >On Wed, 18 Sep 2002 18:25:58 0300 (EEST) Pekka Savola wrote. > * multicast issues > - support is yet a bit .. raw or non-existant. Are you talking standards or implementations? > - there is no MSDP, so there can be only one PIM domain currently Dave Meyer (MSDP chair) and I have gone around and around on this issue. The last time we discussed it the consensus was that SSM was going to be the dominant multicast environment. If people really needed inter-domain ASM support, BGMP would fill that role. Now, I am not so sure if BGMP is really worth considering or not given its complexity. > - should we focus on SSM only For the short term definitely. The key is going to be getting vendors to support MLDv2 and PIM-SM with SSM support ASAP. The nice thing about the MSDP spec is that in order to make it IPv6 capable, three new IPv6 TLVs and the rest of the machinery should stay the same. Regards, Brian From owner-v6ops@ops.ietf.org Wed Sep 18 14:34:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25082 for ; Wed, 18 Sep 2002 14:34:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rjfA-000MeW-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 11:35:00 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rjf4-000MeB-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 11:34:54 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8IIYMY27083; Wed, 18 Sep 2002 21:34:22 +0300 Date: Wed, 18 Sep 2002 21:34:22 +0300 (EEST) From: Pekka Savola To: bkhabs cc: v6ops@ops.ietf.org, Subject: Re: ISP scenarios comments (multicast) In-Reply-To: <1618173.1032373552640.JavaMail.Administrator@atp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, bkhabs wrote: > Pekka, > > >On Wed, 18 Sep 2002 18:25:58 0300 (EEST) Pekka Savola > wrote. > > * multicast issues > > - support is yet a bit .. raw or non-existant. > > Are you talking standards or implementations? Both. As for standards, there is the problem with MSDP. Another partially related one is related to site-local group scoping. There needs to be some feature like 'bsr-border' to site-local scopes to work properly inside only one PIM domain, I think. I had some intention to write a short draft on these open issues, but the idea is still waiting at wg chairs'/AD's inbox (or /dev/null, possibly). > > - there is no MSDP, so there can be only one PIM domain currently > > Dave Meyer (MSDP chair) and I have gone around and around on this > issue. The last time we discussed it the consensus was that SSM was > going to be the dominant multicast environment. If people really > needed inter-domain ASM support, BGMP would fill that role. Now, > I am not so sure if BGMP is really worth considering or not given > its complexity. I agree. Main use of ASM is videoconferencing, and I believe this could be done adequately by one SSM "hub". I believe BGMP hasn't been implemented by anyone. > > - should we focus on SSM only > > For the short term definitely. I believe most don't realize that's the only option at the moment. > The key is going to be getting > vendors to support MLDv2 and PIM-SM with SSM support ASAP. Yes. > The nice thing about the MSDP spec is that in order to make it > IPv6 capable, three new IPv6 TLVs and the rest of the machinery > should stay the same. It's good to hear that. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 14:47:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25694 for ; Wed, 18 Sep 2002 14:47:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rjs4-000NkR-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 11:48:20 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rjrw-000Njd-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 11:48:14 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 4D2557B9; Thu, 19 Sep 2002 03:48:02 +0900 (JST) To: v6ops@ops.ietf.org X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: memo, 1st day AM 2 From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 03:48:02 +0900 Message-Id: <20020918184802.4D2557B9@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [not a official minutes] homework move "sense of room" to mailing list continue discussion on mailing list mech-v2 sense of room - yes to both bound: is goal to move to DS? - yes. survey of ipv4 addrs in ietf standards repeatedly asked feedback blanchet: feedback not imported - need to retransmit? spend time - yes (17) accept - yes itojun: need to request ietf@ietf mar: need some management ?: split document into parts, like 7-layers? ietf area? mar: need to talk to author From owner-v6ops@ops.ietf.org Wed Sep 18 15:06:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26591 for ; Wed, 18 Sep 2002 15:06:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rk9y-000P8f-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 12:06:50 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17rk9v-000P8T-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 12:06:47 -0700 Received: from dhcp64-134-140-111.wgs.sjc.wayport.net (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8IJKGE14375; Wed, 18 Sep 2002 15:20:16 -0400 (EDT) Date: Wed, 18 Sep 2002 15:04:14 -0400 From: Marc Blanchet To: v6ops@ops.ietf.org, phil@nesser.com cc: ntp@viagenie.qc.ca, jean-francois.boudreault@viagenie.qc.ca Subject: draft-ietf-ngtrans-ipv4survey-02.txt Message-ID: <214350000.1032375854@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA26591 proposed modification to draft-ietf-ngtrans-ipv4survey-02.txt 3.12 RFC 1305 Network Time Protocol (Version 3) ... There are numerous places in sample code and algorithms use the above mentioned variables. It seems that there is no reason to modify the actual protocol. A small number of text changes and an update to implementations to understand both IPv4 and IPv6 addresses can achieve an NTP that works on both network layer protocols. my colleague Jean-Francois did the port. There is a problem which is the refid. Without changes, NTPv6 does not scale well without a fix. Here is a suggested text to replace the quoted text to this draft section: The refid field identifies uniquely the reference clock a ntp is based on. This refid is a 32-bit field in the NTP packet. So it cannot carry an IPv6 address without a protocol change. The discussions in the ntp dev team and ntp author around how to resolve this issue went to put a "compressed" ipv6 address in this refid field. This in fact changes the current protocol. Other than the refid change, there is no other changes needed to support IPv6 in NTP. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Sep 18 15:39:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27541 for ; Wed, 18 Sep 2002 15:39:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rkgm-0001xp-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 12:40:44 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rkgi-0001xb-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 12:40:41 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8IJeYw32000; Wed, 18 Sep 2002 22:40:34 +0300 Date: Wed, 18 Sep 2002 22:40:34 +0300 (EEST) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org, , , Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt In-Reply-To: <214350000.1032375854@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Marc Blanchet wrote: > > The refid field identifies uniquely the reference clock a ntp is based on. > This refid is a 32-bit field in the NTP packet. So it cannot carry an IPv6 > address without a protocol change. The discussions in the ntp dev team and > ntp author around how to resolve this issue went to put a "compressed" ipv6 > address in this refid field. This in fact changes the current protocol. > > Other than the refid change, there is no other changes needed to support > IPv6 in NTP. > Some reference to that change (to use a hash of a part of the address, I recall) should be there too. Is there other than the expired I-D? Has the change in the protocol been ratified or in the process of being done so? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 16:18:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28741 for ; Wed, 18 Sep 2002 16:18:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rlID-000517-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 13:19:25 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17rlIA-00050v-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 13:19:22 -0700 Received: from dhcp64-134-140-111.wgs.sjc.wayport.net (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8IKWiE15558; Wed, 18 Sep 2002 16:32:46 -0400 (EDT) Date: Wed, 18 Sep 2002 16:16:42 -0400 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org, phil@nesser.com, ntp@viagenie.qc.ca, jean-francois.boudreault@viagenie.qc.ca Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Message-ID: <259130000.1032380202@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA28741 -- mercredi, septembre 18, 2002 22:40:34 +0300 Pekka Savola wrote/a écrit: > On Wed, 18 Sep 2002, Marc Blanchet wrote: >> >> The refid field identifies uniquely the reference clock a ntp is based >> on. This refid is a 32-bit field in the NTP packet. So it cannot carry >> an IPv6 address without a protocol change. The discussions in the ntp >> dev team and ntp author around how to resolve this issue went to put a >> "compressed" ipv6 address in this refid field. This in fact changes the >> current protocol. >> >> Other than the refid change, there is no other changes needed to support >> IPv6 in NTP. >> > > Some reference to that change (to use a hash of a part of the address, I > recall) should be there too. not sure we need to go deep in this document. I agree that it would be nice to put a reference to a draft on what is chosen to resolve the issue. > Is there other than the expired I-D? none that I'm aware. > Has > the change in the protocol been ratified or in the process of being done > so? - process was done within the ntp dev team and the small group of interested people. there is no ntp wg I know of. I let the ntp author decide how to do this. I think he had in mind a important rev of the ntp documents. IPv6 refid would be a very small part of it. Marc. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Sep 18 16:41:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29402 for ; Wed, 18 Sep 2002 16:41:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rlex-0006sL-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 13:42:55 -0700 Received: from pixsv79.isi.com ([192.73.222.230] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rlet-0006rY-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 13:42:51 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rleq-0004cH-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 23:42:48 +0300 Content-Type: text/plain; charset="iso-8859-1" References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209181630.20435.Jean-Francois.Boudreault@viagenie.qc.ca> From: =?iso-8859-1?q?Jean-Fran=E7ois=20Boudreault?= To: Pekka Savola Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Date: Wed, 18 Sep 2002 16:30:20 -0400 Cc: v6ops@ops.ietf.org, , , Marc Blanchet X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM,WEIRD_PORT version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit >Some reference to that change (to use a hash of a part of the address, I >recall) should be there too. Is there other than the expired I-D? Has >the change in the protocol been ratified or in the process of being done >so? The change has been implemented by ntp dev team and should be ratified in the protocol. From a conversation with Dave Mills : "John Hay implemented the latest, which amounts to the first 32 bits of an MD5 hash of the IPv6 address." And you can see in NTP cvs ChangeLog that it as been implemented on 2002-07-29 : http://ntp.bkbits.net:8080/ntp-dev/cset@1.884?nav=index.html|ChangeSet@-9M -- ------------------------------- Jean-Francois Boudreault http://www.viagenie.qc.ca tel: +1-418-656-9254x228 ------------------------------- ------------------------------- Free IPv6 Connectivity http://www.freenet6.net ------------------------------- From owner-v6ops@ops.ietf.org Wed Sep 18 16:41:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29434 for ; Wed, 18 Sep 2002 16:41:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rlfX-0006uo-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 13:43:31 -0700 Received: from pixsv79.isi.com ([192.73.222.230] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17rlfR-0006uU-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 13:43:25 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rlfQ-0004cj-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 23:43:25 +0300 In-Reply-To: <200209181630.20435.Jean-Francois.Boudreault@viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Date: Wed, 18 Sep 2002 23:32:17 +0300 (EEST) From: Pekka Savola To: =?iso-8859-1?q?Jean-Fran=E7ois=20Boudreault?= cc: v6ops@ops.ietf.org, , , Marc Blanchet Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,WEIRD_PORT version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT Implemented != ratified in the protocol (specification). There are probably code bases which have nothing to do with Dave Mills'. On Wed, 18 Sep 2002, Jean-Franįois Boudreault wrote: > >Some reference to that change (to use a hash of a part of the address, I > >recall) should be there too. Is there other than the expired I-D? Has > >the change in the protocol been ratified or in the process of being done > >so? > > The change has been implemented by ntp dev team and should be ratified in the > protocol. From a conversation with Dave Mills : > > "John Hay implemented the latest, which amounts to the first 32 bits of > an MD5 hash of the IPv6 address." > > And you can see in NTP cvs ChangeLog that it as been implemented on 2002-07-29 > : > > http://ntp.bkbits.net:8080/ntp-dev/cset@1.884?nav=index.html|ChangeSet@-9M > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 17:01:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29942 for ; Wed, 18 Sep 2002 17:01:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rly4-0008U7-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:02:40 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17rly0-0008TS-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:02:36 -0700 Received: from metal.viagenie.qc.ca (vg171.viagenie.qc.ca [206.123.31.171]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8ILG5u16560; Wed, 18 Sep 2002 17:16:05 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?q?Jean-Fran=E7ois=20Boudreault?= Reply-To: Jean-Francois.Boudreault@viagenie.qc.ca To: Pekka Savola Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Date: Wed, 18 Sep 2002 17:03:26 -0400 X-Mailer: KMail [version 1.4] Cc: v6ops@ops.ietf.org, , , Marc Blanchet References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209181703.26475.Jean-Francois.Boudreault@viagenie.qc.ca> X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM,WEIRD_PORT version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit That's why I said 'should', it isn't ratified yet, last time I talked with Dave Mills about ntp it there wasn't any plan. He told me it will take a while to do so. From there, we should add this ntp refid case to ipv4survey draft as IPv4 protocol dependance. >Implemented != ratified in the protocol (specification). > >There are probably code bases which have nothing to do with Dave Mills'. > >On Wed, 18 Sep 2002, Jean-Franįois Boudreault wrote: >> >Some reference to that change (to use a hash of a part of the address, I >> >recall) should be there too. Is there other than the expired I-D? Has >> >the change in the protocol been ratified or in the process of being done >> >so? >> >> The change has been implemented by ntp dev team and should be ratified in >> the protocol. From a conversation with Dave Mills : >> >> "John Hay implemented the latest, which amounts to the first 32 bits of >> an MD5 hash of the IPv6 address." >> >> And you can see in NTP cvs ChangeLog that it as been implemented on >> 2002-07-29 >> >> >> http://ntp.bkbits.net:8080/ntp-dev/cset@1.884?nav=index.html|ChangeSet@-9M -- ------------------------------- Jean-Francois Boudreault http://www.viagenie.qc.ca tel: +1-418-656-9254x228 ------------------------------- ------------------------------- Free IPv6 Connectivity http://www.freenet6.net ------------------------------- From owner-v6ops@ops.ietf.org Wed Sep 18 17:04:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00046 for ; Wed, 18 Sep 2002 17:04:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rm1J-0008mU-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:06:01 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17rm1F-0008mJ-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:05:58 -0700 Received: from dhcp64-134-140-111.wgs.sjc.wayport.net (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8ILJQE16616; Wed, 18 Sep 2002 17:19:26 -0400 (EDT) Date: Wed, 18 Sep 2002 17:03:22 -0400 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org, phil@nesser.com, ntp@viagenie.qc.ca, =?ISO-8859-1?Q?Jean-Fran=E7ois_Boudreault?= Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Message-ID: <302330000.1032383002@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,WEIRD_PORT version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA00046 -- mercredi, septembre 18, 2002 23:32:17 +0300 Pekka Savola wrote/a écrit: > Implemented != ratified in the protocol (specification). > > There are probably code bases which have nothing to do with Dave Mills'. you are right. You are suggesting which process? Marc. > > On Wed, 18 Sep 2002, Jean-Franįois Boudreault wrote: >> > Some reference to that change (to use a hash of a part of the address, >> > I recall) should be there too. Is there other than the expired I-D? >> > Has the change in the protocol been ratified or in the process of >> > being done so? >> >> The change has been implemented by ntp dev team and should be ratified >> in the protocol. From a conversation with Dave Mills : >> >> "John Hay implemented the latest, which amounts to the first 32 bits of >> an MD5 hash of the IPv6 address." >> >> And you can see in NTP cvs ChangeLog that it as been implemented on >> 2002-07-29 : >> >> http://ntp.bkbits.net:8080/ntp-dev/cset@1.884?nav=index.html|ChangeSet@- >> 9M >> >> > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Sep 18 17:12:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00236 for ; Wed, 18 Sep 2002 17:12:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rm8m-0009OI-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:13:44 -0700 Received: from [2001:670:87:1:2d0:59ff:fe12:20fe] (helo=laptop.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 17rm8V-0009Kp-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:13:37 -0700 Received: from localhost (localhost [127.0.0.1]) by laptop.kurtis.pp.se (8.12.5/8.12.5) with ESMTP id g8IKRW6C043392; Wed, 18 Sep 2002 22:27:52 +0200 (CEST) (envelope-from kurtis@kurtis.pp.se) Date: Wed, 18 Sep 2002 22:27:32 +0200 (CEST) From: Kurtis Lindqvist To: "Bound, Jim" cc: Alain Durand , Jun-ichiro itojun Hagino , "v6ops@ops.ietf.org" Subject: RE: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9269@tayexc13.americas.cpqcorp.net> Message-ID: <20020918222649.M42806-100000@laptop.kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ...and I will be the first to back you up on the questions of NAT... - kurtis - On Tue, 17 Sep 2002, Bound, Jim wrote: > Excellent question but what we don't need is more NAT and we do need IPv6. > /jim > > > -----Original Message----- > > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > > Sent: Tuesday, September 17, 2002 11:02 AM > > To: Alain Durand > > Cc: Jun-ichiro itojun Hagino; v6ops@ops.ietf.org > > Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt > > > > > > > > > > NAT is not a perfect solution, but a solution that, like it > > or not, > > > the Internet is now > > > very familiar with. We know the limits, and where it works, > > it works > > > rather well. > > > This is because this model is well understood today that I think > > > SIIT/NAT64 > > > is workable. > > > > > > > If NAT works so well in the first place, why do we then need IPv6 at > > all? > > > > - kurtis - > > > > > > > From owner-v6ops@ops.ietf.org Wed Sep 18 17:14:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00275 for ; Wed, 18 Sep 2002 17:14:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rmAo-0009ZY-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:15:50 -0700 Received: from ncsmtp02.ogw.rr.com ([24.93.67.83]) by psg.com with esmtp (Exim 3.36 #1) id 17rmAi-0009Yf-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:15:45 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g8ILG6up013990; Wed, 18 Sep 2002 17:16:06 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 18 Sep 2002 17:15:38 -0400 Message-ID: <3D88EC5A.1B69FB82@nc.rr.com> Date: Wed, 18 Sep 2002 17:12:58 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, micklesc@aol.net Subject: Re: ISP scenarios comments (multicast) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.1 required=5.0 tests=DOUBLE_CAPSWORD,RCVD_IN_MULTIHOP_DSBL, X_RCVD_IN_UNCONFIRMED_DSBL,FUDGE_MULTIHOP_RELAY version=2.31 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: > > On Wed, 18 Sep 2002, bkhabs wrote: > > > Pekka, > > > > >On Wed, 18 Sep 2002 18:25:58 0300 (EEST) Pekka Savola > > wrote. > > > * multicast issues > > > - support is yet a bit .. raw or non-existant. > > > > Are you talking standards or implementations? > > Both. > > As for standards, there is the problem with MSDP. Another partially > related one is related to site-local group scoping. There needs to be > some feature like 'bsr-border' to site-local scopes to work properly > inside only one PIM domain, I think. I brought up the issue of site-locals and PIM in a PIM for v6 draft a few years ago. The PIM group came to consensus that in order to use site-locals in certain PIM messages (e.g. C-RP or Bootstrap) then a PIM domain border MUST be the same as the site-local border. That draft was eventually merged into the new pim draft. > > I had some intention to write a short draft on these open issues, but the > idea is still waiting at wg chairs'/AD's inbox (or /dev/null, possibly). > > > > - there is no MSDP, so there can be only one PIM domain currently > > > > Dave Meyer (MSDP chair) and I have gone around and around on this > > issue. The last time we discussed it the consensus was that SSM was > > going to be the dominant multicast environment. If people really > > needed inter-domain ASM support, BGMP would fill that role. Now, > > I am not so sure if BGMP is really worth considering or not given > > its complexity. > > I agree. Main use of ASM is videoconferencing, and I believe this could > be done adequately by one SSM "hub". > > I believe BGMP hasn't been implemented by anyone. And I don't expect anyone to anytime soon. > > > > - should we focus on SSM only > > > > For the short term definitely. > > I believe most don't realize that's the only option at the moment. Agreed. The interesting thing is that, just like in v4, multicast in v6 is lagging in development effort. > > > The key is going to be getting > > vendors to support MLDv2 and PIM-SM with SSM support ASAP. > > Yes. > > > The nice thing about the MSDP spec is that in order to make it > > IPv6 capable, three new IPv6 TLVs and the rest of the machinery > > should stay the same. > > It's good to hear that. Another possibility is whether or not RFC 3306 can be exploited to help with the issue of RP location and such. Haven't had much time to look into that though. Brian From owner-v6ops@ops.ietf.org Wed Sep 18 17:20:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00505 for ; Wed, 18 Sep 2002 17:20:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rmGG-0009yf-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:21:28 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17rmGB-0009y1-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:21:23 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 9385628B01 for ; Wed, 18 Sep 2002 21:21:22 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: renumbering In-Reply-To: Message from Robert Elz of "Wed, 18 Sep 2002 16:54:51 +0700." <19290.1032342891@munnari.OZ.AU> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 18 Sep 2002 21:21:22 +0000 Message-Id: <20020918212122.9385628B01@as.vix.com> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > | however, at size 10**4 and above, renumbering of this kind will be > | expensive. > > The actual renumbering need not be expensive. At the minute it would be, > but more tools/protocols can be developed to make the kind of renumbering > we're talking about more or less invisible as far as the site is > concerned (and yes, A6 would certainly have helped). A6 was a concrete solution, with plusses and minuses, and is dead now. Alternatives which would also make renumbering less expensive are just vaporware at the moment, and since I can't evaluate them I can't accept your assertion that actual renumbering need not be expensive. > | and at size 10**5 and above, it will be constant/overlapping. > > Huh? What does the size of the net have to do with the frequency of > renumbering - if anything, smaller nets are the ones that tend to shift > around more frequently (they don't have the clout to get good deals from > providers initially, nor do they usually engage in longer term agreements > to achieve that - bigger places do). Larger networks are less mobile only when renumbering makes it so. If you take away the renumbering penality (for example, if you use NAT) then I'd expect any network who attends a transit exchange such as PAIX or Equinix to change their provider at least once a month during fee wars. > | ..., that's a big reason why folks will ask "why not just use NAT?" > > And the answer will be, that NAT achieves nothing, but does limit > applications, some things just don't work. And once we get into an > environment where the default isn't "everyone uses NAT", more of the > kinds of applications that just don't work with NAT are likely to appear > (there will be no reason for them not to). What odds are you giving and how much are you putting up? Please don't misunderstand my intent here. I'm not using NAT and ISC is 99% done rolling out IPv6 internally and I'm not trying to get anybody to feel bad or act different concerning renumbering technologies, A6 or otherwise. However, at the moment my take on all this is that folks are likely to use more NAT rather than less. Any application author who wants to make their work NAT-unfriendly can't be -- and shouldn't be -- stopped. But as far as the core protocols go, I think we should do a better job avoiding moralism tham IPsec did. ("L4 routing/switching/firewalling is evil, so let's cover the port numbers under the encryption envelope.") From owner-v6ops@ops.ietf.org Wed Sep 18 17:32:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00822 for ; Wed, 18 Sep 2002 17:32:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rmSK-000Am5-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:33:56 -0700 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #1) id 17rmSH-000Alp-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:33:53 -0700 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8ILYHM15911 for ; Wed, 18 Sep 2002 16:34:17 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 18 Sep 2002 16:33:50 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 16:32:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Securing OSPFv3 Date: Wed, 18 Sep 2002 14:32:43 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE01771C4E@mvebe001.americas.nokia.com> Thread-Topic: memo, 1st day AM 2 Thread-Index: AcJfRIKnfKNNfw5KT2Cic97DVY4QGgAFY4eA From: To: , X-OriginalArrivalTime: 18 Sep 2002 21:32:44.0194 (UTC) FILETIME=[ECA84020:01C25F5A] X-Spam-Status: No, hits=0.5 required=5.0 tests=NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA00822 If you haven't seen it, draft-gupta-ospf-ospfv3-auth-01.txt clarifies how to really make IPSec for OSPFv3 work. The keying is static, and the peculiarities of multicast and IPSec mean for example that replay protection must be turned off. It's all the details needed to make "use IPSec" reality. As noted in the discussion, doesn't solve any of the managerial problems of keying a large number of routers and managing them, and everybody on the same link has to share the same key. But, no worse than IPv4. I believe this was presented as an individual submission in the routing area at Yokohama. --Rod From owner-v6ops@ops.ietf.org Wed Sep 18 17:50:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01287 for ; Wed, 18 Sep 2002 17:50:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rmk5-000BtT-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:52:17 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rmk2-000BtB-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:52:14 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8ILqAx05165 for ; Thu, 19 Sep 2002 00:52:10 +0300 Date: Thu, 19 Sep 2002 00:52:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: raw thoughts on v6 firewalls Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Regarding v6ops meeting discussion.. I don't think v6 firewalls can be killed. They're a mechanism to ensure some form of security policy; trusting end nodes to do the right thing is not enough. But there are problems with v6 firewalling. I've been trying to get around to writing a draft for a year or so now but never did it (further than the baseline summary of the content): perhaps now it's a better time. One potentially major deployment issue is how the firewall is supposed to handle packets where extension header contains a header it does not not recognize and thus cannot parse e.g. UDP/TCP headers. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 17:58:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01388 for ; Wed, 18 Sep 2002 17:58:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rmrK-000COJ-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 14:59:46 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17rmrB-000CMV-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 14:59:37 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8ILwK020251; Wed, 18 Sep 2002 17:58:20 -0400 (EDT) Message-Id: <200209182158.g8ILwK020251@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Vixie cc: v6ops@ops.ietf.org Subject: Re: renumbering In-reply-to: (Your message of "Wed, 18 Sep 2002 21:21:22 -0000.") <20020918212122.9385628B01@as.vix.com> Date: Wed, 18 Sep 2002 17:58:20 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Any application author who wants to make their > work NAT-unfriendly can't be -- and shouldn't be -- stopped. But as far as > the core protocols go, I think we should do a better job avoiding moralism > tham IPsec did. well, let's be clear here. the argument about NAT isn't a moral argument. it's about the flexibility of the network to support a variety of applications, reliability, network management, and user support issues. if it looks like a moral argument to some people it's just because the deeper technical and economic issues are not immediately obvious to everyone. it's hard to imagine that any authors "want" to make their work NAT-unfriendly. however for some applications there are not good, or even feasible, alternatives within the current internet architecture, and it's very difficult to retro-fit the current architecture to provide such alternatives. (see draft-moore-nat-tolerance-recommendations-00.txt) just because NAT shifts some burdens from network operators to applications implementors, doesn't mean that it actually solves any problems - it just moves the problems to a group of people who are fundamentally less able to solve them. btw, I'm fully in agreement that people will use NATv6 or simply avoid v6 if we don't make renumbering fairly painless. and we really need *some* WG to seriously tackle that problem. perhaps this is the one? Keith From owner-v6ops@ops.ietf.org Wed Sep 18 18:17:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02024 for ; Wed, 18 Sep 2002 18:17:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rnAC-000DPV-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 15:19:16 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rnA7-000DP6-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 15:19:11 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A1E2D7B9; Thu, 19 Sep 2002 07:18:54 +0900 (JST) To: Rod.VanMeter@nokia.com Cc: v6ops@ops.ietf.org In-reply-to: Rod.VanMeter's message of Wed, 18 Sep 2002 14:32:43 MST. <4D7B558499107545BB45044C63822DDE01771C4E@mvebe001.americas.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Securing OSPFv3 From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 07:18:54 +0900 Message-Id: <20020918221854.A1E2D7B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >If you haven't seen it, draft-gupta-ospf-ospfv3-auth-01.txt >clarifies how to really make IPSec for OSPFv3 work. The >keying is static, and the peculiarities of multicast and >IPSec mean for example that replay protection must be turned >off. It's all the details needed to make "use IPSec" reality. > >As noted in the discussion, doesn't solve any of the >managerial problems of keying a large number of routers >and managing them, and everybody on the same link has to >share the same key. But, no worse than IPv4. > >I believe this was presented as an individual submission >in the routing area at Yokohama. thank you for info, and PIM-SM work is already there, i guess only remaining major one is RIPng. BGP is unicast so it's easy. (not sure about IS-IS) draft-irtf-gsec-pim-sm-security-issues-01.txt itojun From owner-v6ops@ops.ietf.org Wed Sep 18 18:40:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02553 for ; Wed, 18 Sep 2002 18:40:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rnVO-000EfT-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 15:41:10 -0700 Received: from [2001:218:1:10c2::2] (helo=guri.nttv6.jp) by psg.com with esmtp (Exim 3.36 #1) id 17rnVG-000Ef1-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 15:41:02 -0700 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1:10c1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id E3548B16AA for ; Thu, 19 Sep 2002 07:40:31 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id 8A465125CD6 for ; Thu, 19 Sep 2002 07:40:29 +0900 (JST) Date: Thu, 19 Sep 2002 07:40:05 +0900 (JST) Message-Id: <20020919.074005.78736511.miyakawa@nttv6.jp> To: v6ops@ops.ietf.org Subject: My slides From: Shin Miyakawa Organizaton: NTT Communications X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Sep_19_07:40:05_2002_726)--" Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----Next_Part(Thu_Sep_19_07:40:05_2002_726)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, This is the PPT which I used at my presentation. Thanks, Shin Miyakawa, Ph.D Sr.Research Manager, IPv6 Group, Innovative IP Architecture Center NTT Communications Corporation ----Next_Part(Thu_Sep_19_07:40:05_2002_726)-- Content-Type: Application/Vnd.ms-Powerpoint Content-Disposition: attachment; filename="ADSL-Spec-v6OPS.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAA9gEAAAAAAAAA EAAA/v///wAAAAD+////AAAAAPIBAADzAQAA9AEAAPUBAAD///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A bh7w/AMAADwgDsnOVVsOCNMt7QKaRpr/iVBORw0KGgoAAAANSUhEUgAAAH0AAABCCAMAAABNcilv AAAAA3NCSVQFBQUYJt5DAAAAYFBMVEUAAMwzM8xmZv9mZsyZmf+ZmczMzP8AM/8AM8wzZv8zZsxm mf9mmcyZzP+ZzMzM///////MzMyZmZlmZmYzMzMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACkqgCRAAAAAWJLR0T/pQfyxQAAAx1JREFUeJztmNmWgyAMhrUqIm4s+v6vOpCwKdieOWrn YkxPK6WUj59Aghb8L6146A/9oT/0h/7Q/yd9nojAEpkI+Sp9ZJS2lNJuGJm56lLzLfoAvILS7bW6 cgaO6IQeWVffTh8P4dqqm+kj+PvwfRk+Sx/Rz0U5EOdz825qZsvDnXQ7w9rBDAplDxemx1XiTxct vRydecKEcLcBRr0aSzeQm+gw2y2ddfEFfjaVnR0GJ8zNizWxKHjpolS2rLhc1O4l5L5GyQwdui9M 9zP4G0A4C40vUd9crmgqFNeVL+vepEyrUvoMnb9MsYk4pVdc+YGgdteX4CrQVYISaZVK6dj5ZIp1 5OLel6PhxdrX5QrtnfE1cz5onYcHU375gbRh6pXrVmjXwjCUBO1KoVysRe1YXpVc8tqDrw29cJGt NmUcVAN7fgp/8eLRDWYBQud2/rEBaF+sowTP00m0n2GfddyNxE+32347uu4T+lZmQgzPugIbgPZP 9DpaaRjte6fXR3gYSRTvgud/pz31ex/p5RjXXzWpML/Pnt6GZRfoq/TauRCCe+3CfBP46WbJWF67 C2XVNr+z0KaIw11YxV47mtMemaODJfRhs53KKLHSkmTbWLoKH/4H+Vt67UIq2OaQ4VNLtwv1QfZ6 UnsNvg7fmcvrHdnWRUccZPhYdkI7AR9HGXQy65CxaINxusvx0co+qX3eRvGcka0fPF2d184/5+9q m+Q8XSyntdtw8+7wYhZddLazcV664OK066jv4rwMbV2cV3m6oJtVn1rv8z9YSF2Sb7THOS1pa1pn zzYspNiczbvRhZ0mbO9Wu0rpIqoSeTouqlIc0DEAhRUfa0fPn9KuT3Owv/Nwu/9DhfDnNG5PdtbL 8TkuaavPeQd0gXGd5dTbmH/jidqmU1omu362cf+qW7n8nZQ90VM2x7Wkd9UXwY/uIm0+N7ndsyHI tFH2v43u1Rv/G6PR9+vu4A+fHjQdzduFt+9vnl0IloVf+vDm3XMbwvb37lc+t/hE1/p762t4b3L8 F+jaCBlq85rmTy3voN9qD/2hP/SH/h/oP7Sz9Tkfiy0eAAAAAXRFWHQAT0ba5wAAAABJRU5ErkJg ggBuHvAsBAAAGoiJrOuonVjD7kWnYXCpa/+JUE5HDQoaCgAAAA1JSERSAAAAngAAAB4IAwAAAOrr V5EAAABgUExURQAAM4+PpTAwWf///87O2F9ff7+/zBAQQH9/me7u8UBAZq+vv1BQcyAgTd/f5Z+f sm9vjICAmXBwjZSUpWBggDs7Yu/v9/4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGYGnKIAAAAY dFJOU///////////////////////////////AM0TLuoAAAABYktHRACIBR1IAAAABGdJRmcBAAAU Puq3VQAAAAxjbVBQSkNtcDA3MTIAAAADSABzvAAAAx1JREFUWEftV9uum0AMXCDhFi5JdPr/v1rP jA0LJVUanUipdPySXVjbY3vsJSn9yCdkYLx9fQKMRxiu1eWT4V2q6yfD66rym+A1fd83j23VEnmb bVUkf/TwJ6Wy6ux0mWmmdMdu+NpopdxW0dMHTzhzh8tUQabbeIyw5OuqKvC6wart/VH8nHb7OqUz qTfyxSDDNHRKdX540tNFaqTpgi2R9pnl7rgaV9c94fxAzXYPZ7dvLcuiHl/YFkJcpR6FzCnM+5PZ DnZYA+d9c7Y7zB9jgeBtgUUqjQ39jGWNVf9rtzfTk6hHSIJHHG1i5qVmMipVhS3lxxLvWXZnXTum RvkA9D8EtSeUs7szCxCaY4oO9iOp54eoMCInVgF6ytSYKobCQhoExmFUYqW8pAQgk1shfc7AAvDY eK1Wu1LY7EU9B0N4jMZgeInDCc3TbxMGeHLw/V0HCbU6gHfG8xERmRFWRu3FEmTxbPezB0FtmKV9 BEYQN4n55gELpRyQvA4VcurxzeSI1IwH8JBW769SldEhliC7GLb7yYMIsw0ogubaNKqps2ohF9A7 qMc0c1yY0M5RcUk9hdSyMs9RLyKl514tBYZtGvWKFtqhW6jnmoLHHj64JckNMwNC1P9APQ9CleoZ PDlLYs2tZPTBGAg5Opx6SrOI5IxF5XdCBljY/NXU44nnqBeTBbzi3BTc1UdQz7MK2049TXSHp9oe 3GzgBmrO02x92X6OejG7PEaPKjJrZkg9K44PcEOzTD3C09XW0LFPjE3+wA3WPEiiJKgEmcJmb1df GFkuGGKI2by4oFVwUsmy/DCfmGG0OCFjJdFlQS3qQb21xbyXxKk1ks1+WG3F9Zw3FJGwEAIFK8vk WG4APekus+7d09FHS1DPo7Jjut9Xu0K43RdrXn2QxH3JKEJqpYrI1dFRJd6umpkuxeEnFQaCxo0A 6Kp21Szdqx+8PWV5lZZKu2vUVtQjRQIe3fgwLuPjppu/69sRrjLqrdV/aTUONn6G78RmMDLqvQTq zUoZ9d7s6SXzp/g+fkn77Upt+5d/Lm/3/uPgP83Ab/LNHjLHISQpAAAAAElFTkSuQmCCAG4e8JkD AABnViI1jqJOHy/BdYRyWY21/4lQTkcNChoKAAAADUlIRFIAAAC9AAAAvQgCAAAAabXrZwAAAAFz UkdCAK7OHOkAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAMtSURBVHhe7dKxDQAgDAQxYP+dgxiBq506 35y8Z2Y5BT4LnM9/7wq8AtxwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZ cMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRq NtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADel mg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBN qWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApw U6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC 3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOl ADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNA KcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtww UApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03 DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbD DQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZ cMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRq NtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKXABrvIEd1LKdAcA AAAASUVORK5CYIIAbh7wMwkAAGFboKUia4mVu1MMQGXdsfn/iVBORw0KGgoAAAANSUhEUgAAAEIA AABCCAMAAADUivDaAAADAFBMVEXvnKVKQkqUjJS9tb3e1t7Oxs7v5+9za3ucnKWMjJTe3ufOztb3 9//v7/cACAhjY1q9vbXn597Ozsb///fGvbX/7+e1UkrWY1rOY1q9IRi9KSG9Qjm9GBi1GBi9ISGt ISGcISG9KSm1KSmtKSm9MTGUKSnGOTm9OTmcMTGtOTnGQkK9QkKMMTG1QkKEMTG9SkrOUlJ7MTGl QkK9UlK9WlqcSkrOY2O1WlqlUlLGY2OUSkqEQkIQCAjOa2u9Y2OMSkree3uESkrWe3ucWlpjOTm1 a2vOe3u9c3Ota2vGe3uEUlKcY2PnlJTelJStc3N7UlIYEBDnnJwxISHWlJS9hISMY2O1hIR7Wlpa QkKcc3PepaXnra1jSkqthITWra0pISGEa2vnvb21lJRaSkq9nJzvxsaUe3vOra0xKSlrWlrWtbWc hITevb2ljIznxsatlJTvzs5zY2M5MTH31tZCOTnGra29paWEc3POtbWMe3vWvb3nzs5KQkLv1tb3 3t5SSkrOvb3WxsZrY2Pv3t7n1tbezs5za2v35+eMhISlnJyclJS1ra3e1tbWzs7v5+fAwMD39/fv 7+/n5+fe3t7W1tbOzs7Gxsa9vb21tbWtra2lpaWcnJyUlJSMjIyEhIR7e3tzc3Nra2tjY2NaWlpS UlJKSkpCQkI5OTkxMTEpKSkhISEYGBgQEBAICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8iYF8AAAAkHRS TlP///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////wADZeeHAAAAAWJLR0T/pQfyxQAABTRJREFU eJztlvl7E0UYx1ErIkfBxqLFbWJpqVjQIsilAoKoCIJVwROhCOHyoCAWBXpjkUK7O3vO3neaNt38 jb6TTRq6STYFHn/S99ln353Zmc9+33euXUI/sS35H/F4iMQeitryZIjPKYpqQwzz+AjURRAsixYy HgXRt46iWjoEPsJ4FEQ6CSq2YXEFix4TsbKvjaI6flLkJm4xiOa7g3fvJhbWMeijTTt1XVPE+ojf jr7U1QnWteNouth48NOjfQziJWVRiOYDoLdkLZ0H0lB3poOi1n3HAkLTVFmokwv0cti3cBFL7hgY 6yQPnZOCJCuKLPJs/Ii8XwRQJVKy69SBsOJckyitkcRJdlUs4vtkEVCUkdx2Tmx6Law4LonPCjxX b2rNhxFC2nsh9v51oaRjWBK45VOozgTvLvcH23hp3NTVrwrKWlq/VSTIZHSJRBFkLRYBLVRru+fa lqEeAwRcqRsaXsFGARUI5nJbUQDcUwcBYWrLriTDmvYjMJ51EeiFPeUB2eB7jqkrGHeXcvtDZFZV VbH89/VhFHB/6+RnvboiNYlr1iZTKVLzhsRFkxlFMAwnfDivArqltvULDbx4//yJ/SlC/rFKJFEV rIB3LZidr4xwHP+MahwuVB4S+QoZUQRZSh+k5ucmYHYDQpS17QXkLhxZIJUIGoEM7UR7eYlQbcM8 L0hX1hdqtipShYwogkEcfPLw/AqB67gAjL1hzTsarouAbPDSva0PrVTqkCTwN9vCsK7qssDVRSB2 RX9yfobCtUsRJ7tD2uZxQxGjyajccoDxSXm1g21X8duhqI2r7UUhgLF7Pg9E/L6/1xLS+tf3u661 mEDApkrLtXBPfd3bsal777HzluPYpor56OSqhkBbypsGIEbNCRnLqm7Ztvk02XsXgWB2tzyUzc2j pibLiqobpqHJUoWI6ir2PKQidRLUK8DQNE3BUvQ0rIX4srUs403XNlRMTIZ9j6+Y3jUQI+WTZMPQ 6udAvkCMb4A8VOx71RArEfdxuMJaqNQ3HoiAr3McR/4KKgE1VHDiTrJXtKZePTjkWDqGUUCIqQ6o MSKsIOuW6/k+7HyWrpA9gqGrdq+N4CXVsBzXdR2LhMFW/3wcAnECVg3Tsiw4RbBQZb+MRTBcOp2+ LIhYUWEmqPcm0mf6JBSKQwUPeYk92R9k8sRyzrAoYTysZwtF72cgePAwAYSZfD6IQQxeyxft7BjP 8+NzxdJ7N2naBd8j0AioczGI26S9X1ByCSGZ+KxHOBd5hiDymQR9MRbxKzQKNIYZBz/HMFfBTbMM ngX/oKAinz9HAsnVRtjQZobEEwBqzVISlQBFPZPJ/IG8MEtCfCAkAps8QLNGVchBY7H0LhGqyE/n YhE+NDHAk5TldQECmBVK70gugnC84gKxyACSL4JvfDFBArkFxQnfz5xCBKGHjBgVS8j49aOpX0ha mxND4N5toMe+AH9hFUFIk3N1EPRMYThJ13wvTd8sxH6DEK4naEhn4/3En3UCocWZ0tTqJb/PR0ql YCTMhUajuToq6Dtne4J8EAS9S0kpcSE3F+Qbe07/BekczfXMKvAnnMv1nI5D0PSIqitNd0qlqeFl uhaWmIEBklv61sDgQDzikW0BwrPcbMYzHYZ2PNfzMk/5WVXz/evWtENrvmc7VoY0mLnmZnAthJKZ dVycu0+LcHhNB9msZxiW7ZuzLmcH/vOaYAVZ2wxyTlaqgTAddhltW5AzD2MXWQaiMYahyFjw0rJv czRjcbojYZ0z/r1c/McR/wDV+JbgJ8/hfwAAAABJRU5ErkJgggBuHvCCCgAAqFlgZsZin5fKFicO aELhYv+JUE5HDQoaCgAAAA1JSERSAAAAowAAAEoIAwAAAOD5FPgAAAGAUExURdnV5vLw9t3a6FJG jqqixn1yqMXA2NHN4XVpo1lMkmldnHFmodXR4+zq8k5Bi+Hd6ks9ifr6/JWMuT4vgMC71ero8YV5 rnltpvDu9enm8P7+/l5RlP38/fn4+2VZms3J3jopfbexz8nB2Yl+sOjl76CYwD0tf0U2hb220rq1 0q2lyJGFtZ2VvpKIt5qSvcK81m1gnq+pylZKkPb1+UY5htvY50AygoJ4rWBUlubk74B1qqSZweLg 7I2BsrWvzpiOuu7s9L651MS/2Ek7h8jE2/Tz+MrG3NTP4vf3+riy0K6oyouBs7Gqy6Wcw25joMS9 1o6Ds+bj7o6Etaidw9DJ3u3s87iuzqGVvmNWmM3G3Ih7r/j3+p2TvdjT5EM2hODb6fPy90I0g4Z8 r8C307OszbCmyaOcwuXg7MvE26igxZyQu56XvzkofP39/uXj7vX0+OPh7ff2+f79/sO71eLf7Pv7 /L2306KXwDsrfqWdw+Xh7OTf6ryz0LaszDoqff///8zJ0A4AAAABYktHRACIBR1IAAAADGNtUFBK Q21wMDcxMgAAAANIAHO8AAAIh0lEQVRoQ9Wa60MSSxTAEeSxIAu4yFs00SU1lAyBtJJclUwkLTPT NLDHzUzBTKN7u2f/9XtmdhEQq90FH3c+LcvszO885syZh068prLl2LPolPWtsJqyxpTXst/2QmVb Yf1rYbSPbQAUTxUiitfA6Ng1AEAlpxTxyhld20YOCQHuKEa8asa+FAUEmFKOeLWMc0ZeRgyXbibj tjcqE4JT1TBQVVmF7E1V/buSH5JSeaSqpStiLM+c6RAZI6oQr8Yfez9OnOkQH9IdN48xF6wnBH5S HeLl6zGgy1cHs0w6ohLx0hkPY5UGJQJY7t0sxoO9BkcktE6HWsTL1aMpfE6HAPxT1YiXyeiLJZsQ IXxwgxhDw2wzIeyoHdNEosuK4ZOpJN/fDPlDvRYvi/HkI5NIctAEme+9MYx6I8sK0STXfw4yOacF 8TJs3XFrgzGwzsROkv/SaG2V83RVoPb7oy4STgcpZPGcS7J+TWpsux5Pct64dSPNTBhY4bxL3tWG 2G7GbzGvJW+1oiIJJHXJs7kw77oJjK7XD6eMBLJq7Z2kweuVUwouqxGxrXrM5FY2PUajxRaXIQ2p XFnclceNR1PcaXMM334xM0ogvQQSXdL2lAzIQUYKQKz6XKLt43prYPrV5+7Rh5spAmmNR7IF2oc5 KYXybq2Wbt888/L2yIvpN59jK5FNdEnP0Lcq0h4GIIRk7dfNGHD8/PdD5/L3z9TaD3O1QNg7VeQq yKh856RZlrbEcJfu+Pb6vx/2pgnkqLs+VBfIxF3pn3iiXY1tGdfzXZ9mj3+u50b2pl+9MfkaaPQ0 lPcvtoDYBsZAx3Z27dOzdz/XP4yMDEgDpVaG6cSdn79WxgOf421X9vXA8bv19U/NA6ObzImJ4VYQ W9bjQaFn1TGZNSPk654LSCxkTswfXSujaz7T85dDl11bG7xoOr4XZiZYtjU1tqbHgCgGjgp2/z9v dX+fXKiqyTCmafmWtNhaDD/whUTxoNTRM+j/1br+cRjTtMfXx3ikf/sSe3eVOkpff0XxFCfuvOqN iXOtaY/hPcfHWQcJNa7fLJlnMANyt6hG7f6oX37xc1b39+/z1kAsbrVcNNxVYWvV48LmyvfOdwOT jbPK+a4LEVtc9TZZE79GxkdWiyc2/WHg94jiasRidKjS2UWVNTG69g3puHdz5lnpD/3rPd43GKBa LFoYQ88rTkM4/3D7j91np4zmFgHxcw2MrhX4wrGGO5k/997nea5hn+x8u+oZM0bM/L8YxpsIvx70 4qRz3zFYy33GN1sOPFr02JEnqxNvWUY8ycxnCiRIu+757Kv/6B1+33wtHpkiCpT9R3Oo1WPJQs6A ptwDe0Njo92x0WkMQDRKBu4VMh2lk8YZ53QZZ8uWi0rGAkGkBV1ywmrzrLxCSL0fve6g2fMCubWW AVXbOlA9NiWQRZaRouTxJEkuLignz1qeY0irqvQY6q4/yPiSYNNxY/f46vyvDLr1TfPeRL3EqhjH GrYT+7kJ72J56zdBMqR1F6rRJmoYH9UjJjYiwyrP/bT6pgpGd+1MjdntNLdjxCqjVs5olk93K/kf 5kFljbeplmLGHgYtXTR4TjNtGQdq8JUyztsqBuuQuQ2zrxo6qa5Sxqxn+GoNXCeKUsbWVvHqdac5 PrbWleavlepRcwdt+PB/w1go99Qi8ttx92w16/Ob3OP3q5qwl3sah3XvYbmESZldShxc/sPV1UOy KyC6BvERC8krAy/L5Zfik/sPCmKBVCflyYLbfaac+VXyXTWglcqrh+LJ4AN5Meeac8/6SNVQWmCr JJPWBJfkLHTbNWN04nNQ/ssRFDYal4GzguAJib7wqBQhGMHpdKbIo96QEAQhwdITmRVBmBKnBaFT jDB68iK0zyajyahNVsRjJ34nMDLznCAExVwiLPVkMhSLHEv+ymF0lpdGfTtQSb23GIlae/AKYP7u UlzeOsaEYmehwbvu4HezYtfOGH2LU6WzM0e7ur+CyXoiFaMU3XjNI4QTwHJox0IrxgDCa1MAS1I2 0glgtQFQ4ShLfjvJSQe0kywEF1JL2OYRmUGkw28Xtm1Bg1LrLQEwKI48r/idmH+/b2Akp0MGlwmk BklfZ38v8hCX3QdlSy3gPa79HGeiHUeh2CfOAkSlPXLsZn//jDECsJuGMQl/GglMYi8yPgUUw0vf bjshWd3l8uHNof0a0xjLAkgaqxYiG+zdAmltswIwsbcv782jrlJy0oaasWHPkAoyNFVD5vCW+Bjf lMjPgBH4qQ3g5aNtVJIA6VorKLhDJ3akmfeoDzocbuNDdb+4S4BozbYZLjaEktQnO0eCNYz1406a ogXQejzHyR6LUlfluQXAcQYOWI7uqoS82IwoYp7H0HFiD0IFtXxXlogmLkE68kRxgF4amdKJi5BE x6tQ3xnBPqtJoakC0doCfgacAn5cv+Gtjw4Nk7x8g+rDngZuOJCRhUD4ql/M7aBZY0VMSGjPIVwR DYkiLjp2qVocBqhgK/KiooMDzADP7guYbcgc1j0JshYrvp8lH6DMyBXoIz2Zi8DhZZxt2rLdOWGx chCtv4rsLo6fxJFxl3J9Y6HokMQXRf8EJKnzYcmiIxtPUSNLEj/SxUQfCtxHf/bxsJMGkHeuFngI ok91U63OD5+QE9F93Sm8D9nxmvEMeZtBH2RiNoa01otGYWPe4APyRwyygVXsrP5CxHKySzSjmT7S vsw8cMZdGawvCoYqMA5O7tSPjLJRTGj2ZXS7mLSQwMHD4tC3SQKhIW3einyzz8zH8Xqx069zho/E XgvPx2kdPTltrqAtsPh20UAQISLpBNKGgefrB00qib14eJ5aQBzmefxUPurPcXyw6jM+Bp8Po7xV fhE4ZdC41kV5rfOR570/eF4+T3zO87ERjpfOuvXkvp9NL/4Hh22bhBmdjJgAAAAASUVORK5CYIJg IRvwBwcAAFXbHQYsP2GcgDvz3Oaxnq9UBQAAAAAAAAAAAAAoBQAACAMAAGD4HwDIyhIA1gEAAAD+ eJyVlC9s20AUxr/v3bl19zdSq8nSpM2aos1kU2ChYWBh0BQYGBhoGGgY2LEqqGAgcDAwcDBoMgys tkm3d+fYaqUsrU86vzt/v3v37j37iDPALAWwuIBvkfbn0oxeSGyyyOrI8iW8/cIkWCEDcdayFOcc jI7e4Zk+P568Vuv8y9BOtf/19Gzp/Wn/TPj98VtOEKtd/nL4sFcY+MT6/fOWi4In77LhJNid8q/U 9o0nKu2ZpJHvVZgf09q4vrs2Lu69/j8+7ONbMwtBHTrx0SyEVvsy7RkengmhJn0T41putU4bVGaK K1vqvjlik2NmRkHrys0kZiIVLjnkGhnBQucFrzmm17pyW4yQ81IzW6KUGUayhl+x4m3QunK5nXBr 5oTJWIoScoetucPE9Oi1p3IPK8BHq1K/aCrc7HIjK83iT+yMRmwXSO0QPTNEYcZB68oV0mMqO83E FTcYMOZc53PecEKvdeUqjDWLOQaywEIKjGUDv+IHV0Hryg3tlJUpGZsBF6KEQOfg1CT02lO5x7PP NvtvbCr++zh2I9R3S02/F6v0H+d/vgv55uo76Fy+mrp+n+hcY++vSyWLtkiiwz77qr2NGp9p1PhM o8bXofjv7wP8A17q3C5DBbABWJmr32WfiFHJqfWQaVVOCAAAAAAAAAAAAAApBQAACQMAAGD4HwDI yhIAywQAAAD+eJyV1V9I1FkUB/DvOfdedty0NCQGtc0o090IBiLK6mGWehhJVqckzAdRIY1AKvJh hCIhgqLQCSYyY6MMKnwoH4Y1qbCgUqJSImuhHvpH+RRGD05lO/v9/dzcl2VjfvLjzrnn3J/cM5/f ncBv4GWy3M/I03Q20n8BGp65ZzPe9RMKgFisrw+CH2czAWQhKqw1AVeGc/gDlnlBQV/f27fpNPMB 7NH53yokogmp0CdSaRZI1NRIremURnNXWs1XabchOWIb5ZTtlD6blBt2XEbtB3ntnHxy+TrXLdSl rljXcqxivN05bbcf9Kgd1zM2qVdspw7ZRh21IX1mvuo7c1cnTadOmRqdNgs0rU8MNMFxs07rfJ2S xzopPfpOmvSZLNdRpHQIw3oFPXoGbXoUW7Qdq3U7lmgV8nUt5uhSBHQu5sgn5MtrLJFRrJYb2CJ9 aJNT6JEjGJZ2pKRVlkujNEmt9EhUHksle1Chm/39h3n/qk9lowlKhdnKPhyXOnNPmq3IXrtKDtoW SdiEXLDXZNA+l/s2JS9djky5Is1xJexBma7jGGXc4nJ0n01pl32uvfaaJm1C79gWHber9JUVfW/u cf/HNW22GmuC5gd9agKa4Bg1VnM1LY/Yh5P6Xur1lZTqOD7qHdzSJBLai1btQqXuQ0hbUKhRZOs6 GPYAmgMjU8iWlyiU+wjJICrlAlolgYQcxC3Zi4/SLKVSJ/Xc/0mpkEeyUXO576i3/1lLnp89tDXB Z5a54pnx2+eZ+Lt5PiuZpLWop1JG/s/hbAV7gCx9gmyzAHmmBkHTicXmLlaYryi3IVTYRmyzndhp k9hvx9FlP+C8cxh0+XjoFuIN//dnt1DmuXwpoc9yOt1Er/V0u4t+D9BxFz2fpuuL9N1P5wP0fp3u h+j/Jg0M0cN1uhigj346uUgvp+mmi34O0NEueqqnq030VU5nJfQ2D/n4jDl4w/085DjI+DyWoAur sR9bsBNt2IYeVGAY5UhhhSzHYmlCUHqQJ4/5Dc7nvjf7++e7ANGnoAtkma3sw3EUmHtYZgUr7Sps sC2osQk022tot89xzKZwzuVgwBXhgSthD8rwxZVIniuSUvpcT6dV9NpEt230e4iOT9BzL11fpu8B Oh+i99t0P0z/I+zBMD3cposh+higk8v00ks3J+jnEB210VMTXVXR13o6K6W3PGTjCwx7ADzgOMD4 HApxDCG0oxLNaEUNEtiAW1iJj1jGVQXsZJ6cRJY8At1z31F//wUzp9w/Dn9BWM9izFaj3xsNsNtM IM44bIMImwBqTczPZVo7gRHp0JgENIYJDUpE1kiZN0ekHYwb5Kyfy7R2DV5gROOo5biGp2ycb0eM 8YjWckUE/XLVz2Vam9K4HLZh2cH7sHkhZQY8u+KcH0GKca7Z4eUyqi1I+5e/JqKX8KetxVVvZK9i ZhLdjCO2GBGTiwbT4ecyrZ3EmBzWDsnVDkxqsVRLWELenAQ4Xyw75JKfy7Q2zG9lTLvRwDHMXnVr CB2Mx7SBK6pxVW76uQxrBdotcRuR3bzjZkJCJiDVnIOOCRgHzW4vl1Htv6fff336diJ6v+Iv+A4s 4vwP/vno/RWnf09Pm7r09Hee4q92hbrILfXWuCJTx1Mh/Tdb+dt6AG4e8EEPAACR9rbal2ZUL0Ke rPcuPiOZ/4lQTkcNChoKAAAADUlIRFIAAANjAAAAlwgDAAAArwRzqQAAAARnQU1BAACxiJWY9KYA AAMAUExURQAAABNRkv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYHn4MAAAAJcEhZcwAADsQAAA7EAZUr DhsAAAvGSURBVHic7Z3bshvEDkS3+f+PPgUHNk6wZ6S+SPIurQdeiKeXJDdQqYR8/bEsP5LHgVKR r9K0ZangVK/6pm3Hlh9FsF6VPduOLT+HbMFqarYdW34IWMEKavbliywbhllu5a6zrnYZpWyzM6Ba Zv66Y5LAskn4/RYsmnG1W+lkP0aUdn/63PeHX7/i61jdCTQb9vlJXO1mGtkP0RToP33o+5Ovn9iO +f1UrnY5gWy5o/L6qQGePvLPB9888PXG0TQ7/2w0ybvgJle/HytbbKhuWG6Ex9O/vjo6VniBjvV2 ufoNOdlSP0fDMjM8njv22I5pt9vo6ndkZAvtTA1LTPH4tWPvPvv1TtWyAPbRRJRzt82ufktctszN WbHoHI/ejjneTGX5Ntvv6teEZavUvA0LDvL4t2N//3fiyw9uxwoE5a5+T1S2yMxesdAoj3DHLCUz PJnL8mx1imuBKSY7Vswxy6O1Y/oXs2GWpc5xLVCd2zHVEtlhHk8de/rL72zHCgQ/1HVqx2Q7ZKd5 xDtmKJn8wXSYYaWjXIfKzrTCUQh7OmbTjad1LbTKdehP0IyUYhAYb8cqDA2uFbo/xImDV/46iIsX wctm0lq2Weda4jvQSbm/qpEsHfOopuJ8aRxx14rrA7K9SoARDyu9Hasl5+q+PiDbagQIKSCtv07y 0lWQosk4XxpH2tV5fET2wjQfDZy2o2MGzXSeMY4CcbUdnwjuEAJ0VFDe27FaIFfT7YncDiHARgYl /s//+035tN4yn2eMo8BcTcfHYxt8ABkhjLmhY3JHJNCZx4C6Om4Phx6Y5CKFUN+O1QK7Gm4PZx6Y 5KIFV//+/wTrHhYbYoHOPAbYVX96PPPAIBU1sLu+Y1o/NNEaSIC7qi+PR56YYyIHlt+O1UK4qk8P J54YI2IAtf/3z5RQPSvVgxOtgQSEq/jyeOKJMSIOQPtLx/LPKuWISG8iDuMqPTweeGSKhwVQfztW C+MqPTweeGSKhwdM/+nPH9O8qlObHAlDuQrvjuedGaJhAvO/dSz7rFCNyjRHwlCuysPjeUdmWNiA BtiO1UK5Cu9O5B2ZYWEDGuD5z6pVvCoTG56Jwrnq7o7HnRkhYQSZ4Nqx3KsyLzbUnYnCuRavN/Kl s8sAEkaQCbZjtXCuxeuNfOncMoCDFWCE544JTiiyytESCsK5qq7OxJ2Z4GAFGOHescyrKqscLaEg nGvxfiPfObcM4OAlP8J2rBbOtXi/ka+cWQZQMJOf4ZeO0TfUOGXpScXgXEVHp+LODFB4a6V5Kz9i oGNzfx3CIdafisG5Fi848o3zygAGFyH9i1e2Y7VwrsULjnzjvDKAwdWGfJPtGHlEiVGeplgIzlVz cy7uTL9BwIV6NT9jpGPUb3DKCgE0xUJQrpqTc7IX2gViKraHX7Edq4Vy1Zyck73QLhAUIV5mO0b1 ROGD0JWLQLlKLk7KXmgXCHvgb2eHDHUs9qhCB6IrF4Fyrd5w5PvmtAHyExre15/YjtXCuEoOzspe 6M7PWJif/+b3jhFNEdhgtAUDMK6Sg7OyF7rzBQuVDxnrWORVhQ1GWzAA4yo5OCt7oTs/5QC+n51y O1YL4ao4Ny97oTk+6eBP+JP/dAzuCu+C0pech3BVnJuXvdAcn1UoiBB2TOCC0pecB3eVnJuXvdAc n1UoiAh37P6qwAWlLzkP7Cq5tkD2QnN82qAi478dA9vCq8A0RqeBXSXXFsheaI5PG2AZuRBVxwTj wjRGp0FdJcdWyF5ojs8LQCGejkG//itlgoOtqVzzrSv4Mb967y6BdECgIOVFx6C+KMZFwdZU7/nO FfpQhXrvLoF0IB9K2Y5ZF2ZwRT5TYt67SyAdyffHhDt2flY0Lwa0pQbPd675TxSJ9+4SSP+cjgGN 0YwLAm2pQ/SNa/KH14n37hJI3465gLbUIfrGFR2rRbbOCUhH4pEYV8fS/7hNeTBAW+oQFbiWavdK Fe0EiRF0LN0Z0bgg0JZaTLdj3vTtmAtoSy2myo7NlO1Nh+LtOYmOvX9YNi4GsqQeU2HHhsr2pn9S x5KtUU0LgiypSVXWsamyvenbMRfIkppUVR0bK9ub/vkdS/0kc25OCmRJTaqijs2V7U3/qI6leqMa FgVZ0qe6lvr2uhWtBonZjlkX1uxaqtsrV7QbJMbYsddPq4aFgbb0oa7TZXvTP+jXUr2NDv/I3Jgk 0JaaZD9IdTsmivmpHSsVSABdtGuoXsWiFfljch179bZoVIJ2gQTQRbsG6tWsWROUIupYuDuSSSn6 DeKYz9kt296xtEBBynaslteuqmsWyF7oTQcEClLojkkG5eg3iPPWVXNOv+yF5vi0AJQh61iwPYI5 WQYohDm4Su5pl73QHJ82wDK2Yw0KYU6ukoO6ZS80x2cNsIjijvEGPAMUwhxdJRc1y15ojs8qFEQc OxbqD2/AM8EhytlVc1Or7IXm+KQCmLAda3GIcnHVHNUpe6E5PungT/gTsmMCA54JDlFurpqrGmUv NMfnJOwB/+fUsUCDeAEBIySCQBvtmifydXN6AvkZC/j57ViPRJC7q+SsPtkL3fkJDe/rT3AdUxjw jJAIEnDVHNYle6E7P+5hffwXjh27dkggIGCGRYyAq+iyJtkL3flhEefbv7EdqyXiqrmsSfZCu0DM hHm4tmOCfAVDNEKEXDWn9cheaBcIubjefc25Y5eSKQQEDNEIEXMVHdche6FdIGDjefU927Fagq6i 6xpkL/QbXIT4F9s7ls1XoNhDFUFX0XUNshf6Dd5bSR9LcOlY+teJpwUETPGIEHVV3Vcue6HfwE56 CKRjp9/wlBYQMMUjQthVdWC17IUBCm7SM4g7ls5XIFlEEWFX1YHVshcGKJjJz3Dr2OFLoREQMEYk QNxVdmKt7IUJDl7yI2zHakm4ym4slb0wwcEKMALUsce7vwMICBCtooSEq+7IStkLExysACNcO/b+ W6ERECBaRQkZV92VhbIXRkgYQSbAO6Yy4JljciflKryzTPbCCAkjyATSjiECAlS7qCDlKryzTPbC DAsb0AD3jr37WqgMeGTLKCDnqry0SPbCDAsb0ABwx2QGPINUriRdlafWyF4YomEC81d2DDPg0W3D T9JVemuJ7IUpHh4w/UDHXtdJZsCj24afrKv02ArZC1M8LID627Fasq7ic/OyF8aIOADtwY4JDXhG yVxIu3YuO3h4vxcgYgC1j3QsOCKqQDNK5kLetXHbsbtXaAEmcmD57VgtedfGbcfuXqIFqKiB3XUd gxVoZtmcAVz79h377tVYAS5acPVQx0ID4g4ss2zOAK59C499+WqkABcphPp2rBbEtW3hwa9fjRQg I4Qxl3WMkSAZpnMEcu1aefQLWOME2MigxGMdC8xHWXAM0zkCuXbtPPoNLFICdERw3tuxWjDXpp2H v4NFSoCPBk5b1THOgmOazwnQtWfr8S9hkREgpIC0DnbsOh2pQTHN5wTo2rP2+Lewau+AEQ8rvR2r BXVtWXvie1i1d0CJhXYWdYz2YJi10bwrM2O5bO/6GkrGK0c7dpmNFyEYttK0KzNkuWzv+jApAoXx dqx2Ejiyw3fe+kArGImwpmMSFZh5W8254p80C89bH6oFovENd+w4mcYFZeBaU67ER73C89aHiyGI bLdjtaMQkfXG89ZHmPWNIumYzAZj5mbjrsxnrcrz1seotU0S79hhLJ0OxNDVhl2Zz1qV562Pk2ua YztWOwsVWe08b32kXc8Yio5JhQDmbjfmSn3Y6TxvfbRfxxCJjjX+hlzMa8J+I67cp43S89YnMKwf YTtWOwwZWWs9b30Sx+oJBB3TSyUZvuKrK/lxn/W89Yksa/UzHXszjcWL15q05bMr+3mb9rz1yTwr 5bdjtdOwkaXe89anVC1T5zvmMiO1xm36vSv9gMt73vq0skXeqY4N/d2Q3HZrx6EjK8XnrU/uWyH9 Ezq2LN9MK9gf2Y4tywcwp15/sR1bfigT6vUX27Fl8bIdWxYv27Fl8bIdWxYv27Fl8bIdWxYv/wN4 WV/UyuqELwAAAABJRU5ErkJggqBGHfA9GQAAxH+YSkwRufLHq3g/np/Mfwv/2P/gABBKRklGAAEB AQBLAEsAAP/jAw5NU08gUGFsZXR0ZSBvcXJ4ent/gYKFhoiKjI2PkJKTlJeYmJqbnZ+fn6KipKem pqioqa2srK+ur7OysbS0tbm3t7q5ur69vcC/wMTDwsbFxcrIyM3Ly9DPztPS0tfW1tvb2+Dj4+hH SUtiZGZmZ2hmaWtpamtpbG5rb3Ftbm9vcHJvcnNwc3Zzc3RzdXZzdnh1eHp2d3h2en15eXl6e3x6 fH56foB8fH19foB9gIJ+gYSAgICAgoKBg4SBhIeDhomEhYaEh4mGiYqHh4eHioyIiYmJioyJi46J jI+Li4uLjI6MjY+Mj5GNjpGNkJOOkJOPkJGQkpSQk5aRkJCRk5WSkpKSlZiTk5STk5aTlpmUlZeU l5uWlZaWl5iWmJuXmZuYmJmYmp2Ym5+ZnJ+ampubm52bnJ6bnZ6bnaKcnqCcoKSdn6KenZ2enqCe oaSfn6GfoqagoaOhoaKho6ahpKiioqSjo6WjpKejpamkpqilo6Wlpaalp6mlp6umqKynp6mnqayo p6ioqKyoqq6oq66pqKmpqq2prLCqrK+rqqurq62rrbKrrrOsrK6srbCtrrKura+urrGusLKusLWv r7KvsbWxr7GxsLOxsbSxsbaxsrWxtLiys7aytLeztLmztbm0srW0tLa0trq1tbm1uLy2tLa2trm3 uLq3uL23ub24t7q4ur65uLu5ur25u8C6u8C7u7+7vMC8ur28vL+8vcC8vcK9vL+9vsK9v8S+v8O/ vsG/wMXAv8PAwcTAwsfCwMPCwcXCwsbDw8fDxMnEw8fExcvFxMnFxsrGxcnGxsvGx8zHxsrHyM3I x8zIyc7Iys/JyMzKyMzKyc7Ky9DLys7Ly8/LzNHMzNDMzdLOzNDOzdHOztPPz9PPz9XQ0dbRz9TR 0tfS0dXT0tbU09jU1NrV1NrV1tzW1drX19zY19zY2d/Z2NzZ2d7a2uDc2t/c3OHd3eLe3uTf3+Tg 4OXi4efk4+np6e8kJSg7PD9CRUdKTE5PUVNSVVVVWFlZW1xbXl9dYGJgYWJiZGVjZmj/2wBDAAsI CAoIBwsKCQoNDAsNERwSEQ8PESIZGhQcKSQrKigkJyctMkA3LTA9MCcnOEw5PUNFSElIKzZPVU5G VEBHSEX/2wBDAQwNDREPESESEiFFLicuRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVF RUVFRUVFRUVFRUVFRUVFRUX/wAARCACAAIADASIAAhEBAxEB/8QAGgAAAwEBAQEAAAAAAAAAAAAA AgMEAQUABv/EADMQAAICAQMDAgUDAwQDAQAAAAECAxEEABIhEzFBUWEFFCJxgSMykaGxwUJS0fAV JHLh/8QAFQEBAQAAAAAAAAAAAAAAAAAAAAH/xAAUEQEAAAAAAAAAAAAAAAAAAAAA/9oADAMBAAIR AxEAPwD6MOyY0GTDG3VlW5w6gM4rkkfxqd2xpsjHmSZiqRl4kaQrVkbvq88f217IhM0bQw2qzxhn lZ/3ntt3dx6++vR47QxzN8RC7YlJTaoIWM1YJHHi/XxqoVHPLnfFWZKaJ2sRyUCB2J9/PbxpuXgR R4zY2LKjfrOws/Uhrcx9u549Ne/XEeRJ8qkjQfVE++qUcc+4BY8arycqQYAkx4Wm3kBSQSXQii3H bvoIcGaLHz5EhczbVPU2lQXIAsgA+hv2vTBJBFlsd3y8e7dHHM5IazZIHj007Bhmx8t4ZYoPlXQq rhTvJ87j5+mtRzLiTYXTx1QpjOWMFAla7VzwCefQ6Bs2ZFlMEwZ/12cfpDjaB3bb5F1zopHnjwTF G4cHcd/Z4kPN0RR7Ec6yCBoJHyZsdZp2+rqo20qncKvsPOlxxQ/EJYgMf6thdiZLALeSAef21oGf DJMURsYjNC8ikh3NgsSCRXYXXHto3ykXLZllZg4HLftjo9qPqfNaTJLAmCYZmYpJJvURttICnkDb fatPxsjBeIZHw1FnBJZ6K2hHJJvk2ONAGc2OvRbJuWKS4tsZ+kjb5J83/wB41H8OyEyykKMcjGB3 W0g3OvYWoFMPHPIrXQ6cJylx9zJO5MixvLYF2C3A9DQ1KBjoMhMOKOOSOILG5BU7AD9J/Pkgd9BZ PCIsnIfdEkckKxF1QM5JPcV48axGWMyQfNqRFEpXdGqjvxdaidIZ8JMg47rOIy4x2lbaHJok2aIH GiwncYTnLWIfV1GKivHbm+/HfQMg+Y4Qus0Ub8/p95L4Nk9uar20uJosGQGGKS3ILAuCYALPr9R5 7eNUQZDHIdROs6s60Nt7yRZI/wCO3pWl42IYMsLLETC26SORxt20LAIr17Dnv7aKjxBjQwopzYPl 0cGC2oWpskE1xzfnzrslJcQ9KTZ05G3ixtUcDge+pYcJVeSXIQyKsgKRHaey0SvmvvpM8TT9KTLq JhJ+ghc7SfB3dh30RRK5XGI2zTQshTe78iu1cXZN2fbSJsNMrEjjjyHdVAnjkUUXo3tbwQe3j11W 8EOJgELIZ3Xe9oLJY23IPe/86fg5HzMLsrwkFA1O1KPF3+PXRUj5GLJCHSVpnbbbGX9vFmweK7du 96CSDHeKYiF5nsAwpQ3BqHtY88+mhmzI2hkBEqKV2SbV/cDwHo9hxXP30wY0sDxNLhKzs25mU7VC 1Y7+bH476IUI44siVomKoMcoqENs7/uN8evjWw/JfBoVWGURblBSNUJbb54HiyD+TqqTJU4sj5Mi xmRnKN1LoV6dtehy4yh4uSwFKr+1RzYJNUf86CCVhI8PUkhY7i4Cw0rCqF32PFemvYOPknJkhdYE WSzHjRfSQK7k+Oa/jSsz4hgr8RRXRRBFQeeYEAljwAa7C+OfOuiBhxzL8pII0xkZuFslTwe/Pj/A 0EuJgY3wvLjmjMkrkN1siZuYK/atdq8axMXKgnx4pzIizMH6qSAGQjnbx3U+h1ZM2RH8OKwujIR9 PUIAF+vqAL799LlmiyYIFE170TbGBuLKRVjyB350B5YjyVaaNes3MamwyK98X4JGlzYRSboszA5K qJZOGJI7cHye96DKy8mLF6fSnilQAERCwQSPq9TQOsnbIaGNYD8xKoEjEEJJ7X+KHHroKZ1w3x1S YY6zILQgcihzXkX6jSwpysOGWdFEbfucmqJav5HroEf/AMgVBLKKIOOUokXRs+K7/nVCwCKeFei8 jDdtFfsXg2faxfroooWnz4kkx3jMUid2sFh34AF83zpMWOsMPysbFQfqZiv7R3LV/p7V+dTzZEdr BkMX+p1DxpsUGq444JDarx8MN1FVemywosa7hyt8/g15541UBlSDLD5bJPjx4ZKiiVWSgOQovcPT 7aVBJJkxlMiCPFxqtZdwUPyDZF8AnjnTJ5YstoxhTdCSOo5ADuDccLfkcn+NAsuHvjiyaM0eMxLS cMfqAqh9PkfyNQPwoYXiyNk0EqGQkC9pDbjQJPe+fbSIZ4VgbEjebJdXKSqzGv69+PGmSZoimx8T GgWWJ1L7pVJKHcO57eum5whjWMrslmJKRszV3FsQfXj30UpYsTrKMqFwIntRGgsN5agexr7aYZgz ZMmCY2KIXjhf912bNjtfp40wiKbE6E7KJQ20gSi+Bf7r7d9c74diywQjH6oVHWRlKPTBT5DXzz2v j76Iq3R5OHjdSHro628O0PvIFqTfYg64+PiSZXxGWJJxjl0Us0bUUA488ePN99XZM8yNGpT6CwDy KTQBAs8dySO/bRwTRS/EujJEyxPcsTkWxckAg+D2u9B0YU6wEUvTljZCJNren/7fOufnRtI8b4kK fMB1WTpyKoKHyb7fah41S7qJ2ADUAdrKSt8dgSORxpOO0r5BXp9Cdk6YJAZEHJDUft76DZycnr/K yCzQNWQfYgc3YH86h+KSRYWXFOclWy5pF2LEoAkagNp9L4s+g108qRMLozFpkQxNtCRWGb0YjvyQ QDoVXEhikfJMRySpapLLEXRN3wL0Uh+vHE2z97ttIkYuVJNbQRyB/wDmnNmLF8PmWWUmRI2LliQy UP3Hwfb7aCLHnmwJJsYsrtuEwcFTKaoAHwAdtfbQHLzJrinjjTLVGZY2W9tdyTzfkUNEHmf+wohw phCVkXqncCDZAJN/6q8e+mZfSxcgx9dcZybEhqtouuSK450j5d5F6SJIylyvUdQRuI5BArz3/wDn WTMsYWKeJcrIgUBmZDTWeAo8ngcaKBkSLHWIQq/TkUrJHGNjncCSB7dv51VPG0/xAIxjSQRXOw3K Hog1fpxpHSZ4njIXHV2EY3twas9rBPHj11VNMDPIEMrjJVYjzRSrsqKrnvoMjmHzbRyVIUdUhCKK Hmw32NXpvTjC/OtBK7QvXRZACncWK7mmPOp7m+ILFHPEYYVUo0kThWDDm+3AqtKyJcnGRDJFO0c+ 63dvqXaw2sNvc8X9tAWY8GXkYoxHjeNjvdWtekTyCSK8+POn4xikkJdMYRSbVchCpJ5snxRNVffX PfNwY/hcKZF5AaQoJSKIJDNbV54r76bhri/E/h1Ys8mOuWu6lUWu0AE2RVe/uK0G5hjkabEghZAs aP8ASnJ5JojtVDx3rTSi5s5kxgwfoKLqhtu+R4Js0Doy7TJHF8Q+hUciN1O1WP8AprnvV869FHPH HMMwb4FB6fUoOa48dx4F+ugTCVzGlOHA7hAm2pACrA8qPA9+3jWHHeafJrKlKBhujVNpj5s7WJ83 X4OslyYp1EEbSx5LxtRjtRYANH/n/nVsGLh40EEzbl2gxghaUKSeWr/t6DnZmJmoomOayNvajEpA IugxHnj17HRZPw+L4ziIW3TZWzb1HbbY3BiGA+w/nR5uXAidQkzGCgwlQqrGwAv357+uqmyBFEkh lp1bpsFqqPgeCaPH20Ch1l+JPC86kkb46UbYyP8ARvuyeRzoovqgyfmZBK6imlRCB0u9qfIokfzr JMWDervIyYqbmkldxQPFc8/00jJnbGkf5Q5LvGCzI20HtwAB7A8aCqQ5e3p5JSfHCjpkErW0fU19 yfb+NB8MkilnIjBUwkhY3SqbuLB5Jrz6accqabGQssscUY3Sspr6geeDyR/HGpWzo4Fmy4wUVACY xByWHcrV3usUNBZHEJviEWWwkmR0KhWWwKIrjweTz/bQ5GTBHlYyzKyyr9KxxpakG9oJriiB29Od c9fmMuF+jkssOYwb6WP6Kjtzf0ntx766PxDImGMyiGRskqCrKV4b/dt8V/fQc/MyBH1BPLNHNkVU asCF2j9wB9DzV86qSd5skRR9aUom4PMtCwO/jkg/bSsqLD3Qt02aUbdjyM24MxB5HazXbt207LjM E8zPAZOrtd+SCtH9vHINcj7aAWxo5lffEnVdOUc0S1djRAB/wNSfPKZ5MAwk48SV+owKs4PA4oev /Gqc2eIZmB83EoXcE6kjV9TcC188evbWTRrtyIJ3BxWcSPsNVZ8kckUKFd60Gww5i5jTq4CBdzxx c2tgEIP63ocj5edZVgeSFg4WRtpNC7oXwb5N+g1SqQHGhljSeLe5KbWJCKRf4v08XosZcV4j8vvd ch97Sq21Sw44v8/xoA+GSxO8i4sbKh3VnBRRa+QPbg8/86XjfMJmpi/MSNCFYuOKjFmya/1G+B6a VkNDDmSY8aoIQQRSM1SWT9Qv8aDMRPiU0G/HhZqHzMNlAq3W4+CPOg9iCXLmaZk2YqApFtA3MfPF ccjxpJkSH4djRilKgxllYkEILPilPfVR+HwYOSk5laaOcCPZI24KCRt57AVZr21TKuNkYbHOO6MB t5cbiAfDEVwRXbnQRmQJmdbF3Jjhxe9unG1g7SB5Jsc9r1YFEhe8jiMFKXglrsf/AF4/n10UCZGN SRRQfLRqQkS1QUftHuL5vx20jKx4WwI4yyO8W10eL62C2LKjt5GgZjxSbYTK24RyO0YEpY8AAI3q dY0z4zvFAGkuQNIAB9K14vxfF+t6XkSSumXCqJsWUGIyHYpB7k14F/mtFiiHotjpOsi9PqAhyWIB qq71oIQ8GXljDkDxQS/qR7FAUgnljfvQ5v8Atqj4i6nHkitsiYsUBV1uJq81579tPhmX5SYDHHXh UpEDZKg0avvyTpD5QxdkqYMbSvZlogDgckMbN8fmtBTFGEiOQIZN6wkSeOoa4H3GggnyxkQoJVZY lAckmmBAJ5rn2+3vpuPkw5tRRbiGh2yRvyBxYJriz99QRZGZlPKmdjzIuPkKYjGyjqKOCFJ8Dm/O gL4thTLsxlkilacuerIVsduF47kcVp+EmCnw8wYsbptTlJgXMJ/21fr4B0rNgnORMJMiJDW2HYBY B7qWPb2rnSRjtBOXZVyMyUjcFariNE1ffgf00HR6a5LO0xEcZiqSFhwijuCb4POo8GbHiw4ocEHI jViyBCFLKbHA9AOSftpkx68roCOjIyM8b8n04739uONOxhFFlyRqblssgYfQRto7QPQCiPXQLiMW Mz5WWiwcLGdtufa/bn37jTXzVTMmm+XdI2UdOiKY8Dcee3I0GfHFlGFMroFLJSRkscDiueP6cjUw EsLStLILWVVAn5jjShuoX2rt+dAU7TyQySsBlSGKliVfpLDglmPbmx7aOWCaeCO+qA+0tAg4rnvx 9v415JVx45FEMaiaQJuVySxLWGv1Io/nTJo5I/icEEUVJKS7ZAYlQFNkV45P9dB7FhZUmMuXkBg/ 1h1sbQf2gDgd/Gpzg4omZMfLnjeQ/WyEruPJ+njjtdaYc3IyoWkhjMc6WoD9m54LcGl9+Tqgrj4k Cc3UhkcIbaRvtXI5/GgU0Qkix55CYwoO1JBurbdnj++k4q5EUUifpEhuoHRK3ITxtNdjwfxWvSGG CQLJOy2V3Ag/RvB3fUOxPH8DTMmA4EXROU0TPXRWUioz6jyV9vHGgqiXHDIk0v8A7A7ovcceg8V6 6SYUygJZZfmohZaiuwMP83/FaQMqLH+JyzBQxQKsjldterX27Vqj9d4Qk0q9Ka26YpGYdzQ9KPjQ SmYYONLkXt6hKCOibocUK/7/ABpXzMk0uPK8vSaSRukkyEg+PB4sevmtPnhEZxY0lMuIkdSCi8ln swbxXk+mqMZEfpRiNZDGvVVyosKSefYEaBDtjSGSL4fhtkzxv+ozE7DfcknvXv8AjU2eMyaIRw3M 24xvIF4CAWAa4HegNdKNpMWaaYxCdJArOIbAHHLC/wDHfS4M9ckxyIiRLOSJFaO3NcDkdidBjQQt ihosh4Wc7o1RuKIqrBquDXNa5+WZMXDi2Bw4kVEfHO5mHcgr6ci6vvqiCDKTq4kJHT27Fctaqlml r1H/AH00jqY/xLKkQPFHkI6mBgSBv8MQe5AF17aIrx5YcJpoMoJGNzdNZgAXA72fbv8AbXNZDDPl SxZayzZTjpu0Z6ca1wBZ7+R666Esk73DNjFmjJ25TRW5okbjxQuh9/bXo1AzJ8mfrTM8QRYVAoEE k8Dsfua0Vr5bU+NMHkdSpjZEIBQ0AxaqJ9fTVGYmQmICHMrFlGwcKRfOhxM7/wAg4ORui2G1V/oZ L4rg/bnSpJ9i9NnMs25yjRoQFrigBwaP+DoE9Y4cRORNIiREArIQWQ1xfe7sj05GrJspZZ3foSPI kG9CajD7qFA+v3/xqWH5nGneaUFdu0P1IQTK4B+oePI83xWmpOskbwyQCL9MSPNKtj/4Nex9fOgL Iw5cnAoRxMpUSMrISzMOQD6/n01uRGmZkPBkYxiVFWSRnAYP4BDfzx7amjlnhnkXFxlEZj/U4AcM Tt5J9L73pZiy4pzk9UvizOAyS/SUAq7J9/x40Gri5Zk6khikLIxKIm3cvZb9CFvtQPGmQ5WQjGWB CY1VWUyUjDgcc9ztPH+dVPLjxTRSrLulI2bUpjVGr/n8DXsZoZNysn6ijiR1JCtzQI9R7eugkHy8 eXXQnJ2MixWQoBo7uOPHrxZ0WEyfB+ni9VhFW0gEyiQgGzu8Hg2OdBniVYiajnRdq9EfX0zftzR8 8+mh+KY82HA8OLGYhK+5nCARoe7Nz447e/50FP1fJvLi/WsgB3ba6YN9h3PjjUWecvFwjAX6pkFt JAnKqaPP+3ue2qFyJZ8WPKkmiMatuSZUK9Tx2r93j059dUpK2RNAv6kcisWIQBfpHHI9O/voiLDk XbDDG0iI8Py5iRh9NH99sSTfazzpsvwwTmKLFiSNBKLYMHZaNggnz59ffWsceaWVogoPIlkC2NoI oHiweRqiTJjvoiSVCx2Bo03EsRzZ/jn3GgKIvGsyzyB40G1ygIZQO/A9a/vrmwT42LmCTIZ48WW4 BG610l8fyT59TqvFcB8gFVmxzIUMjsULAeB6CwfvrMxUM02XFu2uwRxI1p9IFEAd/XQbP8MyIkWS R4Ztrll6h+rbV3x3OmvPjZEJkiVgF2shKfTu9AL4N0f40Pw7NEp6OUxlyFUuZDX0r43DxwQPzpkT xYuFNPBuCmTaUb6i44Ue3Pf86Kmw/iUmSqLJDMoYNboSoLXZABonv/TTp988TpPAyxsN7oSCarsR zfbUnzDfNZU69aKCArEkoXabvyT48ayDLVoUyOtJJKTcjiisnJ+kdqHb05Gg/9kAbh7w4AQAANg7 tcVrSQNJ+MyUCQhGTon/iVBORw0KGgoAAAANSUhEUgAAAHAAAAAbCAMAAACTDfvgAAAAA3NCSVQI CAjb4U/gAAAAwFBMVEXAwMD9/P3w7vT5+Pv49/rs6vH29fnd2uc5KnU9LnhHOX9PQYRXSopkWJNw ZZt6cKKPhrGakrmjnL+rpMSzrcrCvdXl4+3z8vc7LXdBM3uDeqm6tc/U0eHLyNv6+vz///7zzwH3 1xzz0jvlvAH42VPXqAD43HD745HarR3+9djHkgL75ab+7Lb+8Mn+9+T+/frbtVfkyoz+/PfSpj7h wXbq16vs3b39+O2zeQW9iSDFlDH17Nn9+vT//v3+/v4AAAAgsfSTAAAAAXRSTlMAQObYZgAAAAFi S0dE/6UH8sUAAAOhSURBVHicvZaLcqIwFECjFQiEQCAhlJdtfUARpSCoRdv9/8/aANa2s1vrtp09 cUIGYk4eN5kA8Ak3zw9PuzxP03T1lnSVpnme79YPz5+1cDE3611rWb4je494s2rVu/XN92TrPF0d G1+KlCVJWddFUe33TdM8vtA0+31VFHVdJtlSaJ++Ntp13rqSLglT63l1HEVN62rlL1+avRAn2Srd /aP0IV0mJ+J3qmZf1eVmq0hui9xnw6G03W7Kuti3NZuqiLNlfrkz72xxm97KmqrebA9D+ex/B08H Ia6aVrpMHy7RpVnckcSzYr9YPHY/4To8XdxjAFptta/iZf5ZzTyJj0yqXva4qMrtv8hO7DZ1VSTp uSo3y3jWM7lf9FT1p508w3Na1snHDTwkf+g2XxrbO+eqXH20lsmk5+6ou99819aTf9Dr1V3PdLGY L+bzeZG7juNEg8hRFKcjkvqnI/1IR2a3PfOeGgALQqhLCFITdmC7f8IIjCKHn20tcF7LA9f+Wxfv 3vkKcS62HhRBGGBPhdDzCNE8CFUPyRwj3T8rtNhLaUhGkjn8UDidzrskwllGEKnIgip3XQNq3L2S XTFG6soDbHB3yAnhI2pbIWFXjJLQssdMAZQzm3DZHrWfbeJwEwZhAAKfgZASOgiJdRTGxxFOWybi hXINfU8zoD4GAwRxV4nAawWASBXzyZFvYgcSpBMvgD5GRA1QJHmO6mMzQiHybU5t5OjYIaaNLI35 muUFiLyMfXU7vZ2+ELfLADWmqhoUc6eosJvBAYaamB0b/RKZDhREdIBtGVkI+CYQD9nRGQK2QQ1L 9FCxLU0xKMAEMWCamAIUYPN0OmbTV+6u2pjRQ7F2kALAILTbKlyFhnAF1yEYEwyobhCAwkAnBtCZ olNdeEXZJAIMZN2iiOvRCDEvGovOhVzjQ0ROq5i10TLtlzIBwIAm97qYFDPZ5mIuIWxXYGxohhVp hkYx45pLTJ+4Gqc48gyVmhbADFNRZrqJDRkZDnJNHeMIjZhu+ch+jZvD5KS8WwKxAcftrnMBCB1n 1I3Q6XfDVUBDEQMhiCTJAaESctkBSggcFvFQEm8jkVFFYZECQsYjIDPmSpGoElJn/CZS1+X9yZid DfsfY1dW4qSZ3oojJz570v8cT5uiPUgnk9ks2f0fJThsimZxfz+L4yz95k3sYvJtXYibwizOVv9r mGI9l2VRVUWdpbuLric/g3zYluKidvjiffOv/AZ7DpZk1+g6NgAAAABJRU5ErkJgggBuHvA/XQAA 0gykEotd2DcKt7VRgttVS/+JUE5HDQoaCgAAAA1JSERSAAADGAAAAMAIAwAAALAmNYkAAAMAUExU RaxiBNubBH+ds/zRiAQ2cdCbR8TP1E1qg/zCRrVqBMmEBHqdvfy8BPzrydKbKHSCkMaFLtekZCpQ cqO3w+q/Z+HRqLrQ5cGEIOqxR9/q7PSsBNy3hD1pnNKQBPrTaeWsKQpDc8J4BJ241l6Frfz46iJR hfviqY+rwdTKZPTgx8/f6uXIntecGPy+JuC0Z9ynSfvgi+SwWVB4oNGcOG6QrzBdib55HfvLSfzb qd7DiM6VRa7E19SFBAdDfeC/elZ2kvvSlsmQL93s9+isGdyQBMx5BOC2d8qSIeWcBOGyhJSns4Wd vAQ2fEFqk/r6+q/DzN2qOpGvzN/g122VvfTHiNadWOraxcTS5cTg9/zMJL/K2PnBV7RuBMeFFPvt 1zFglI+dp758FEZ4rISOlN2cN/zetU1ukd+3Wc6UPPzGCOq4STxde86RFB5GcfzvuaGww/u+Ntuo WH2VsfTCeMfX2+CdJ7m7wUJvnMJ+BD1fh+3x9/////m0BPziufrmx+64aPzXmAY1ZGGEouzVtdyu ePzNeOyrNvvTefvem/fl1dfZ2/y/F/vLWvnNOPzIGiNRfN++lHuiwPKzKOOjGfS0F4mlvsrZ5/vW pvrx5tnm9W6HoezKrLhwFCRSlHKPpPzWi92tZ/zKaN2hScSKPJ63zPvEacyHIO++hK2+1d3l6158 nuLFlLDI5NSHFGh6kNaTMNyVFMx+FO24d9aTIMDHyp2yzfDKlI+ftLG8zNmkBwQ7c9SjJrzX6NSj N+ykBEJuk/vz2eKkNuClKPS0Ob/Q3PzCKgQ8fPzCOPzbePzonCxSfAo7ZHmezPjKnOieGL7K5L1x BPC4WfW5SE5xnYimzNDa9MqKBdOWBWOKrvv+6yVWhcR+HxZKfZyutOSyNNaiWPzGWFF+rfzqt3Si zH+WpH+is9OiR09uhPzGSvvyycaKMuTGZuTWpMSKIuTy7OC+hxRKdKS+1JSyxNTm7N+6Z1R+onCW szFijLHK2NWKBODGeMuWMuPy+d6WBMx+BN+6ef3S/VcAAAB8dFJOU/////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wABatoxAAAA AWJLR0QAiAUdSAAAIABJREFUeJzsXU9o3MiaDwgfLOiQgQQHTLIImoYmg40xDEpognyQw7uI5dHx Je2GQMSYZVgwTUBkUEfgp2kH3uHBO8jwDO32o51DGDyxIZdlwdl3nkWZg5eQg5ccAm+YkMtcvIH2 1vd9VaVSd/tfEqfbTn9SS6WqUkmq+v2+31fqjnPu+4Ep5igJx3EesGWJWXmpXM6Uy9VH1XK1Ws37 eZ8Z7PIHrj6u+Wo1U2WnPmItMIP2lh4ssdZ7+aADO8TO9foG+sWyzJbKW4wB5cyjah7R77q+ixwA GuSJD7R1fX+GbQ5ZWAt5F08llsCetYmtuC5lPXpUfsTYUn7w4IGTJsuAOL20L5YYDISoBUiDPLl/ QDtHvMv5gBRw4dB1ZT5Dez6pcZBBrbzvipagiRnJNVfsoBI2zw6YshBRsgNN6aV9WcRgZNiCcAbC IQFU1+X+nXl3FzfADnT1LscucGZGHgnAt+lDV9HAqlSK8qOwCa4DCz+VlyDhXM5CuDLqyVI2qwZ5 Azt5+wKI4WRBGogLLvh62JngtmdclAiOSD/BuusmrBHG0U1pP8WLfUIpkgDZDCeHPOKscf0k6bqu mgXq4nKCsE81w2YpWSc7oMZnsLNLjGx2ayuTqfKYxRShi4B+zvRzErOmhL7w3onD5wkpLRLdapYv ZSdRIcEhkZHzYRX8SBpOmOemr+Yql5E3aObgrqrVsqoiA/vkdtaI4TB92CozPpgcciKUgQzIY3TI MYDmEjwSZ3JQzBYZ90A9ky85xaGrqHflNXz1WF41fUwtwUdcjC4It0WsgRI4y/R55VxOEikH2awe VxQhLExEtrIwGxmw5JPa2SEGCERVxDg5l+sBwYvtCJ4AN0EKnxjiEwgBdckJCqs4omXsQz49p85P VM/OgyhJCRQJU0wkXBQv6f351MI1VV4hXUwRufnIUYV0SGKTNyP48dqvIkF6PQhnx047MUAhQCAI +QcYVEjXMVN7UazsUyfkTGZqXVPA1kTQyzIOa+npTdEU16yO1SUtENej83z+RKZLLZjJfSZXz8Fq +kKg0Ng8BAniDCTko+z0EsPJspCJ3HhOYvWgRa5KRnrXvhdlhEOcsyuxkSSKKQuU6XXOBI5IaqnT +P2oS/GWKS7JHst0FVVSeKq+CHDbnoezEviR7XzhO2DLEe0UEgMZkRHwM4Un784E8WlnRJoQ7XyQ TlnRCKkGClcgz+QUQUyygwhKIiqN2oG778o+ETvJjNwFCfgFbIEaN+lC8jKm+uBtD0Ptsa6BMLFc zmZf9nrITqGdFmKgp3Oy5TLNOwkWMgLxCalti6mCymwrkBmpGmoV11S3si1RKVXLNzkLEkpFJkN6 pPDIPGilGguQjCJTXlMlNyeHKy8jiJl6FqyZM+XLBdS6fCaztDQQi+PYKSGG47CZtZuA1JfQ9FPg PUAxDlqUVYGXgKPqpvET0SUj+kS4IKTZ6nJvzmmSnHWIgWTItplamNS4SzSBtCvbTtimPrjokVSj qrH46p9bA3oczfqeGGxyncn7yTC7Xcc8OgL00oARuOqEksyIRLFQChb2d1zSJcACfqPiu8fvKpXp r27f3tmZX71xgezVhVffDJ87d/i6/A1UZvbrjdX5ndu3VzY2KhvvipF6O/s/kJJ2haa2uQSq51fL XSYfA0tbnxLjpYOUKFf9Njj4QReQRO4xiXGIpYKr5Crsg1dHmj57XNnY+Or2V0OI/2+Wh8nOid05 Ojgncg63c3J7jk47lxQsv/r7hb8Pre7sjD2++dhS7tQ9QI5cftdRN1LB7Hzwa6z9rU+J4WQz8Hq/ w6JApFIEWWTLCVv07HGREWFn7sKFteV9wX1CVmrPWGayMrSzs7JR+VlMSri1U1mmAzNlRHE/szT4 8qOr9R8xsuWMawYw2AGskVxYZjqsp8JAlmOGKQsi0UAgaKRghUsMzpDxtIg3w9QnivjEOXi8UdnZ Wb1wYeSzU+E4dpfFXrd3NjaK0GkW8STiTxGJ3jjA/Hx5MDNvt74iBuMEhimL3KVFCarxiG2DCD5J IZXhPkIS4JZnCcJIWATQNJQsLkJFURPxs8gBZRUrY/O3h9ZGYu6nS8OluM1nK0fxPmjdL/+o5Uc2 dm8l0WDp1ciN2/NjSJFISAm6jCCKUvSIUEJgXeROw89sHfBe94t749s3xOCciBhgFyXgFVqobt80 leMgyWjPggSjgMlbDExTxtzRIssLEDoAmEWzWNmYX526MMJQhjhjZGCIiwlvuAI78FNCGGIRJkuY hi0keE2AKxxBc2wplaheic7CFlnhkWxYLqKZkrgo0YsahjuOOUfi4ZH1ufmxyrMoEJJIPRaARUln Yu8uIjuiQWilWB8Qw8mWfROAimMkR0uyIUrCoUBZ1PKAh0xqViQOpZ/EXEBKkLDJ2piefzM1YsQc pcPxMtsuM5DBXmrDMifHsHDOhGzOgeFhpZBKFUEoJQJD+I6PKxiCGF3LSoKEjBnEFXbnSE94nvju 2tzqykYRu5TCKwwYA5PEU8oyT8POr25lew2KnluPiZF14EdB4NMjgKxw+MyrqdAPUrv2ki61FMWJ kAfoJzFkWsQQKvp5Y2Vn6oIXkyigOgCcCEwxd9Sx8NIlToGY3LwUDw507smFBvAiKQjDHc5fNHxU k3rRabGsQuSAu4/pIXiKSr9ZW59fualhH0BECboRQJcHAXca3KHwY4iseouN3loPiZEtV32CrKm4 cM4JHCKxmqlde0mXWjKZFEaBxfaWxSYQ70fuImSWYwJWXFoWtEBOIEviBHdCTeIEm5iMeTTTDa7d s0/GMF6Du8TYr0RRleBejAyJY/5E8cjU0ESlaIGioqcwF2kIaAK2KMR6kSKr8lbv8NFb6w0xXma3 UNoDnBSisAfcIp4REDWiBOZRCvgRpSNl24Ub2DKECpZ2c+zN3IgxTFiRJECGSOygnxd+Vm4lqj4c uPueT2jtsuxfu2s+6VUsyMDzMbIT1x8u8edm2ctPb7wZq2jCLUW8+0lBeC7xJWDTDph1fGkzj89O DIdNKfImqbmYDNKYcHHHmSAfpEjsOC0iccSZkqpDu4gnAxFBBZWJN1NvY6PEljg2JE4kXGMFX3wb J6ThmiEcb8pK3bP3z22vUTpCvcOaEfcb4xSDUsRlMEMwTbkrI8auYFXuvp3c2dCIB9TBtMFehE3A p2qZzIAYJ2fwbfZWjqLbhA7ptW3DVyUlT7YgafH5tDjBAgtgYWXFh/NDvxpHQmk31ArgUXo4lmBT AT0sckuxRGBJQlG5sDjXUFax625YUjIElrveZElpOZkixYkK8p0h7mG425O+ndt5+Jh1Gus1S8Ou tVK6QdqRy3xJcdVnIIbwNS+3MqZUayugzrdkSuZZfEnVkZm8ohCbZOTQQGwsEyixvmYo6OgA9D62 T4USAFSE68PqtDbudpH0nptgqAiVDr4RcQZpnGhN4SuVCzErJe2Rfhg454gFYTGiUu9KvT4+W8lY m5t/qFlRZKFSmKLfI4v0BN9Z+FXnC5mSnzQxKDx1XmarfhDUEwRbwT62b4FawUL3hkf1hFlW3bLq Dycm3xoCAh2g/RBDfMFcOubvhhLvTyEJfsXWRg5Dgax06aW7a+s35mj56k97e9Ngo6PT3ZY/jI6u 3L4xxwxqX/gmJm/PNQlJgZA2uCIYgnYxdwiYPyyJOExPkMReCo/4itlTQ/MXtUD2bzIeMuF/Ecrx OUKpl1t+LuGEpUqC0AVVEpTCpI4iIXyE6kgQCxwahE+BVRlbnbLZ2NoxfgzDiAVuPsoMyQJo0+Cu 3+B4NPBKBpbKaxkjc+8nh1YY6v9wbSGfn5l5RH42HagfJWxvq1P+48yMv3Dpyejo6J9u37hxY+qV IYUDbyHmD80TnDN4n4aUoDjtL+SjUCXG9pGp8UrRSiKqpNfRIjP3+qwrx4kTI5txg0CrJz2M23qa DSpV2umgZllyr5qmNccnn9o48AZiwaZ9HEtgJOm446Nujbbw3+BRvsHRU0L00FWMZcooGcuv1m8M rexN/+WSO5PnvzvqhP3x5q/0y9euf7NT/C1Pvlmqzvjuu+nplaHJqbexvFtgqkh0zmbUx1Q7KCbP wp7L+3X1YZH3/s/Yz9D9Gvkjq2764hdWZ/I3uidKDGfLXwTXrgXRz6xLxcxYS3x/HWKhugiyNNxD fbEJMFKialRJ46qDA8UOH46vv+Ju3AadoGFVPL10nqoDjZW05ENSou6EP2XtM09sD8ecfywmH1p5 Nzozky/jHx7g6BAgIdAeApkjI2pfBMrLKEX5Bffa6E0WiEFMaXgkBHZJ6EZCf2VKbxjcldh8a2NP 2vHavYmKpnGXFWj8EwBV6oHpn9m3VSdFDOf7bDkX1DXmzgHWDMUoEpoGrz1YlkUU4IxAT6TxCEkV bSuVxYiEXNKQNlplfF03OBXsNBliHju0O0pxoJyigEFUsVPUKNmlZTpv2DBmh4am957MzJSTB+2h dSeK+rVDdmbhb3+Z/mrohsEjqGXqlpLaLXa6X9KdxqrfnRp/EbJOr1so/mwBIx9XNzNnMqg6IWJk yyYDNKEewAzdCAxBedAsTgUMi0gNuGJYXDGQJigmGtFH41oBp7Dsytj6Gjo5G0bVsA0aT/RxItYR +mGLjVjIVVJd7kRtYoHNaSGExxAEW5+bHn2ykE+77P7+K2cOBlyKji3lZ56N3pxcX1PchpgzyZhK 0EOpYJAUM3Y81DR87UGjRAxhw1EP/LP3L2ZPghjwWhbci7JwrINUEMaT41Qpc0h1i3qeJVG+63Iu AfpjacUXq2uGdGuGcPViityuC8qwJx7SSLtEGYNLptGU+u7a0Pzek4XyWRv1bH7h3cb80BQ+Jn9g Zjb3KlIpyLcYQoHtuLR2fuWiBgaRAFs0HCUYUDN/tt5VfXJigFYAuDWG44B6DxEtEhRdUY/KCpBm K1Srg6DwCKyOSdYcowsORnP+3qxH0bCNwwmxsCE+qByUtukVC5WrNUQsbVPwLWsIo4PZyYnr1/yz +693uJI4S3l/dO/N3Kwn+pOe30OO2AbXUIO/r6LONp7eWq0UwYtp9EIQeAK6oUX+Gfrd4aclRjZj asgHTbABCQIswCNODc6HgOpihuQOcEKra2R1dE3QmqVdHJ/SPUO4NxgvCovsWAyg+sEtd4A8uort 5GQeIdiIAmlsQv3+9+u/lZ1+D5M+wpKncmSYBb/SeTc6/97D3lI9hNglboR6zyussjk5HyYiRwCD FZnlpbPxkuoTEuNlJhdgX6Eo1Anv9TrHO7KgzslQJ+GwRD6GUVQf+QMzPFQdDQMp7eHzTY7dlhyr di9vd+R0LWTsAEFhGbaHBTb4Svvp0Ng795HDX4U6Z/QdpGLinbKjztdZjLU3NrdGimtjb0N3sT4y VGFl2R47HFl/UdFIMch9ga6zGceZmI1/NDGE29nyA012UZ331NGsS11Le8ZT4cV//ZEj2LDbSWGn gG/zat3S4gDCAc9TAiv71tD0pbwjISLsi/i3nPyBX6YPv/++/Nv1saEL2D86EaEFkuHJfvREr+qT lxvqwAUw+HWzeurnZZ9GMbKv6xLRiGYZDH2ABXguCHMISmHDuEhJ51DHcDdRe1uhRsdWrSmJBcN8 a37vUrX9Udq+jjir5nQk5deSSVF54frK+xGl36U/omM+MLPn4asOcoc1BoAaDGCQ23r5/Snux09B jMwiMqEoXD8oalHAvKikZSrJUY7UU1iDzcubs6DhEOgQllEFYqRFgvADA6su82psYmTo97/Jr6ZO 7didmKXDyOzMk4tDb2FOZ9tKL3IHE9NETb830ZRjWNRq4NgCf+v0Ku9HE2PLt6A76iGAmW1q1D21 NCP2JUVHJqbCF5OFp8wjeTrEPZ7q60HTPc/zjJROKJGTZ7TLR3LEyt7Pv3MffIqeO/uWVpX8tb3J WdCIltcSsRROQzzbY1me11p7/gJRICwE3Titf1vh44jhvG6fH4RJx4TtmUqviWq1NDsgM7z4w5qH vW202ArjoC6GXGw6xI/t2TYQBpyapzPaAEtaHgyb3oKk3TJmJy9ey3+ibvti7Y/WzaFZ1pvMPPZh Cdb30NseTtFb343D9xwh94rwsfxT+QXHxxAj6wv8h3xJUB9qbdlJoSZpwsWlhmnkSOXF+VkQCexv ALbKhLbFs8WG2APWAmqg5OtQAoNntHRvdvLbS2fiXUnPDf52Khv4dyvfgZgzSbeJJDrrZnrF12pt wpQjcYtaUXlPdWr041jESP3UsxzUQgXnEvZdFENLKUZCFHAsbF+EgloxbI5vzrIetpkfslEw7C6K 4bXEhvaUYPVs8F9IDTZiug7DVWCqYmxOXM+LcTnr72A/g/HXu2xX/nns3lPocnBhOG4680EeCLa3 +R93QvR3Ya2G4x2U5Rj08u6Pbh+oGNl/D9rEQmiDkg7VNKdFuhh6LaTkw/FNHcXZ1pn/Ye5IEoCF SRg42RRbeZ7KDDXGAolgQ0Ok8Aq2PfvmurtENzz4n7dOxpZ+e/dmtsUNhkHHMWAkmb0/UWG0oIA5 ZCPsLp2mb02PTwz4HihXL4ZhDYBfS6M9zYWEE6JMYUURnAk2UgxfPN9G7894wYCNDkgVhtTaanUe 0F5nZ9otEg59auXSI/WfMHzSXhtYypYWfl+dBYekF2wYNnBNLKjy9M3xZi0EqBA5Av/0hLMfoBhZ UyN3rwGua0QQda3hp4Z7MC0MU5ShvBonSPjivA59yhcGcx0DV6/VjRaeGkApoRWxQ4eTdf38dNTl Z+EDbnxK63jZXb60N6nrhacwfC1vloZDb/147w6MeK2IslEPtpZ6dMPHtOMS42XZFFQIweuT1fiK RaqlCvgGaMFbqDUn7l+h2AfiKB3eIcG8u0XvPXTRu+oiREIIhdALzPP0uTFzacCB3pjzIH99/JZn 6Kj3NFRsIPX7vzTCqxwNjfrrU/GW6njEcDI5wHWjgdvwWFaTW01kXDz/I02SdZwpM09TsJEJSABd UCNtOl85TeQhW9f3FrIDZeixOVl3bBICYgoDdBya2fsvaNCLAAAz0+ubPNyORgyOtbJ5PC608aKY yrhzb7tDENrVodvSknuklI7hU0GfmjBPTwB75s0pF8fXdBwejAdYJKDfv9wMQ7ZWwquNeq7fB+vo iuEswfvZNpmoHHCUWIPKSGdQOe5c/nFWLxQKCPGC6v/FUmhRCRUnH6Yu7Dzdhj5ndWw4uPLmWvnw BxjYZ7Qs/Nr62sp6AYYMBhpigcLXl1kshVgohrlyX78ZOTIxsiZ7pEZDxboaTDVETiNUS9p41MCl eXmzwFhBMRQCvNuKH1mu5MDLJx0bwOPze/5JdtDAPsDke9ns1rOx87pwZ2y3e//fkBhXGQ6CTOqM /rIjEcNxsubVWq0BvGiEKvYbybHcy+JGsm+AiOJx5cXzXfD1fCnox17QBbHdbEHfHreUf2Y3+Pqu L81ZujS/2YLhKpD91x1GDQSD1r8+7WjEeM1iqAYGSk2CeUPswuRYSTQkHxJeYN3m5Z/A84PvQIjr h/KggxacF63CrW9N/ncOT7iPBvahJkcmy+Ycs/ruto6+UL/y/E6Fwo9ark/fUR2FGK/r7CFgatBo hGEa+h2EUBihlLD1ai1s3rlf4OBOYC5Cp86Qqo0cIr3LztJ3128Ofg94WkzQo/r75i6OYKGwq//0 QxNCkEal1p8vTQ4nxlYQNsiQGY0mgZ1SDbGGSTbP4IeyWvMfm9skpQDwXQl0DIsEXdRVUQk9yYFq //l/fepmBtbdpHJsLUzcwuklG8Xt/77McHE1bF5d7MPhPJQYpiZVoCEVgN67ibkDZDRoQyUKOxq4 C5vN598BpsFj7O5uFzjC0fsrc+vOCCoRDFFw/gm8ger4+5UD63/DObnz6PH5KzrNN7774SKBZfGf vb63djuEGJlQyMUhFvKPOAjFIdLkl78iJygKUje7hW32kYsuF9IPfgZSim23tyeLfam7AzuWOWXr 210c1cLu1780m81Gsxn0mWocSAxnsXFEXuxPmGbjfy9/vasTujusPYBKbJv1HPJnG/KBQIX7xT7r vIF9sDnOwrf/w5zi9u72lX+5UwE3uog+r1+igAOI4WRqH8kKVIzLP4G7hwnXkZcCaQTKBK6MJVc2 Hn2+XhnYZ7H83n2Sjb/+gljpp2l4BzFk8M7k4s8NWPe1P++TVuzOP65c0SkSOjoviA4FvmHaUfhx YoH/47F+cSgD+3/2rjU0riu/T9SLOlTOLsSLiIWUDNYoKmK1FCHhgDIEnPkg6pmbbFPI1qJ2P3S1 uMGNcA0iuspjBI53V9oKxysR90OMwGKrZT8ENtmkB2O58ehMmykpiU1qGbUo3ppO2LI4cS1bywh6 /o9z7kP3jkbyQ1pn/vfOfZx7zrnnnvP/nf/jnHvnrlDyR9/6xmcrLZ+trH46A/rFE9vmyyKREuPA 8SXk9/HpGWT8mXGlCU4v0RnhAALGZ+gMdksuRpbG4az/jRZCBMNiZb2fXhEOiv4SNum//tU26klq dOfkn7L+6rd+Ca3f8kb/+PjMsb/dJm0dAgx8q/cJxdfjBAq11eyP6xKeK6TwOZ4RLJbwMqJFgejx 9FNp4OyWlZUqBIaGBcVdaUk/taJSt7zzf69uix6kRveQfvTaQ9ADfvzJzPTfnd4eDqpwiXH+9fEZ xeTQ6SMCcJnhlUQC/QgUBAuMiIhRB0tLb6RX0oiLNKzA5ZUXjrhCSRQsVtJ/1PLcr35P3mup0WbI iA7befI7LU+lW779qVI2wEG15Z1hqI1x4Hg/sLZi8iXmdEDAuFlZMtAPgUBheq9kyqcMinSaGX7d pYV2BifplZYfvLLl9VOje0MhDZt8/Z9Vw69emJk+dnXr2z0IDCjR1em4Ym4lMpaW8Kekxzht9er9 YTwQMHAwPt4/rUIuVIcF74Iio4UAAduWb/9sm2ibNbpvdOB332hpeejC+PjxLX+NwAMMRmnyCdCM gMmXZhQeZsbD12mIofYqCsYDBIH1obYXPk6n0xvExQpv0oiRlpaT/7utvNo1ul/05KMtK+9cGJ+5 6v2E4RawQUBi2M7500tL/cTmGyQEyUx//EPg7tWNSgyFhxaChfo9+v37XxM12ib0xc8+Xul7o/84 GOFb9+VbFxiEyvN/MF5SwFgqbRQW/bx7/B1g8tX05gjFxScPR/0hcI0edKI2//5z6dVPp7fUwgxI jAPH+meWSspSACYncJTooORu9VryxgErpL90YTXNBvcmIAHU8lk/zvuogeJrRvrPCLhPTH7y0EOD x5PV/Sv0vSA/MA48VlqKKx4Hvu9fWiM3vKcInbjaaWjE+0mL8vH5RrHR8lrSP/pTo68nLTj2n398 Mv7qlrGBDxgHpuOK12fi/SQPFDbiZukv4WLO4TKLDLq8tEeJC1ChNqdGgYHR8h3XGVHDxdeQbP/x 6x8+fnqr/ijZAMMGXJSUgVEq7VmKI6eXPEpTiQ9NCIIHIAErBHx6crOY0ND4wfYY86zRtiH7yUd/ c35rvnirgaHUuORjceT8EiOA8eANMTuFiVKJsAPQiJf63+xTsFgFmVHdAnFhY44f3b4vxtdo6+iV P37Y3orX+jUwFpzkccX18X7F6PFSHLk/jsc6hPc6BLER70eNSp2eXGVOrwIRaVa5MAGCaXX1w9+j 7/3W6D6SbV+1t8Jry8BQiDxd6F/a06/VJ2J9433yr7xg5DjEu9DXt8ocvi4y9I5gQQd9v6tNKa9R KNlbNJhhbIwnSnFFuAHqN0cRVMJfCczx0puECf2rSCYCYkLhqW919TU9U7AGjRptE9LAeHhPCZWn 6imOP7UUTqY1n6fXw4V7PU1iI/1Q+uQTujA1XNRouxAD463pwhKzOy0Fc+RZ1gapBIMfr2LX3xdk /UhoaKULkqRXj8P9a5CoUTht7ThG8nShNLinoNAQLyAqGBoF3vLqHqnAeEEBpTQ4aCCxqpm9IvXp FTf/8dyWT6OsUY1CiIBxtVBQTF6ID8YLCIYC70ruqYKMXuhcxVcJLvT5sNBHsmOdBbHU15de7Tvm 1KRFjbYjxfArWKX4T5DnDfPrI/+ugAIFrypUwNmbVcDAv6QREICL1dX/Cv6BiG0nbSd8WXDcecg2 /IM9X0jatu3+lWhE4gqLTo2JTWbVL86WeNlrdK8JJcbriueB1V2hEISFWUlgkGCJDz6znuK0VpPq A2iQ3Jge9hRk/YliduSJcycuPbvK29foa0UAjGRJg8Gzp5/euuRGQlz0bZBWKYnanHsyUJTbA9m5 oWw2O5ed8668ZOduGCbONg95rqhlYBbD59SFLIVUvTZfVGkw29GB7JBaQuO5m5ALs/ezwWp0fwiA 8SedhQ3SIG5ObhQVGht951b7Hker2/ufqicsKYUUEZSyGnXUqZQnmjpKCYHhHSIVmTySUpYUAIyk kxBSSmvD6UXq/rZYje4LKWCcV7rRfIF+sJlfFxcQY3Dwp5vDRd/qObX5Dc8A8fzdVFaxWVHIjDQr LPpMinr+EJxzRkXMSb4mhOLsZrwyqY6LnqTBJSxAiqIU3ZDtC8DmAA73WkZ6U4Zlq9KLOac2m+XB oxgJjE6QAoNqN6j382qBLYbNG8jMFzhg07joA1wcC5kyCT2/kQIiKDukyFM022lVLGrCVRefSi1j +OVMKiPCSOqt9J3xUUr0EqxSwSRuHH9pfGGyoWaePIAUc5J7BucL82oNLAW99wS5h4CLc5sExurJ 19fCwp4CLcbKWBEkrdtkIdtOj0hIocPVgRAv2eBO6gFOjUofna8Uu1S2yS5MHHn/yPTyy5rp/gBS zLk62KkYvTOABg0VPyDMQWen7vs3IS9OXg0piN0OFoZldHzL7HQPP6lVKXMVtqBMiVnAhaPOwyWG L0d/ANwwhX7XRbi9sCzPtXXSM/3Z/W6zGt0HijnjSjdSKOiEZb5TaVC0x3N1oRNA06kvU2BhvlMx eJVaNRkPAAAgAElEQVSL2fXx+kzo358nnydzwQLuhANgRDjHBRi+jnHRqFAiIYiuWsr8hfEIpzcB KQRdwcSYF+dHnE4XIIa+hdrMQb57lbCAs4zQkfne0hPd5KezVUVpCx3GwBESGudQy/CDL1OSl7Jz c3PN2aG76KQL+OChDndnh25lm7PZ7I/v2l3CKZbcA8KCqcCbwrwOK3iOea+w0dlUNS76zI4DFC5C maSHO2nmZ2Zv80sJ0uXtZDuxP27UFcWwzVhr74NYsYReNcCAeT35GdAwPlTyBsdecOqR83OcaYZz Z/b3lYivS4KM7NJOZG/7uaSH/+yFhQd7JPAguE5U1V6/d3MZVL5dqCyrJrjXVRn7ohPkwxiIBr24 h4Pq17k2uPOnHlFQpcRANUqdAC5Cu1hkTM3XhiM9UuME/0NBFwFAA0ggZ1M45IDsipztYX8XE4Eg yCoPNd5goRYlXYkgze2lt0TSoJIKOxl4Gmb/cu+RrrnmK6InOzfw9vu3T/G1B5ewLtFJd/eeMsAp 6uwweluEOHivKzP2QwWKzjG1GevkTadaxjrhN2Z+EIwhdOAVBVVKjHPnECKoR4UNUzfmhFaliH0l 9dgsMYRMPM+V00bGgFFzhOil8AyaI5prMakHAkaJctUsiiKGoYoHUq62pdWkjNDw1FIGb+cmhvsf 9TSb3s2293j8VribaL19Txtyq6kjx73Kr+8Sw4Z+LWYXW3u50btzk2iKPTZGAgNXvZmf560hHYww IiavfnUh8swrUdr2JHbXQhheNH0ysz+ZAo5d1pYw2wuKbsCF35JPilnbAMcF2xr7gE4SE1ikBDKx zjNjDAoNThPEcNHGT6Lsazo4zg/AUCV7fGHMURJAEnsfYInxpxaKayF7715XDu3imzbkPCtJiZUv 3a17RFGs8PedY50sJcbGxvQ2SN7QkXObo6a+ptPuMwaoFZnN0h2yV1iQyiNp4oadt6RWmQgCog2n 8/UK1sUy2lx3sWB5+nltH/AdpLgIpdnFmHTlhTRqnQGWa/NILaysHp/AV0enLloJ9ldJLJFEO0ck MlceZF3qJvZGqv5P3YWH1H/rNdXdttP3CdsTPIKVm7rje6xDsfkKaIigDQMC13Pn/qnpWHRBYBAi Y7pz4ena2WJQwMA6qkMAZLSqo7Zd+C9kR5Tqqbtzo0W5ahNf8MsjvMs+yLYXs5ImijRwkBqcXleA 0DgSrYHnuHSYRAVlQyMt7Ou9/CAD4xZL3Ct4djees6NbKc3CaKpovM1JMPEFzwG6lxQbO6RY/dBG cNHUtFFY6N3fuM8YpOEcqByWVmRc7tM4URKDzNqsIK+qKw8aMHwAGdIMZFgaBwZoUfOgGqHHv7Y2 3AWo0bBCcmj3jeGXnyYTFAEEyXjABeSG1fsg+2wtHhW6eXd8bz/uvmKhHmpCbBrCIq9K8z2vydjY jkOHdqjNDlzHYMcHsB/TWw6GTRPxebWLByLJiDpToY2uGs+YKGYYFVprOUipidNQ1wROTQmYRKUo hT4RCdOXcJUiYfgZdSiCnhuB1oTAbOckMbQUKYlRLG3Ia2ljSeZ5b2op9+tnsBeU/XOQRwgtK6Fa leZEQqyUKmfCqeY7MOu1+D3hiNAv7q/xCFVK/O9KV4QqF/99p2VJ4jsy17mXbPbduwNqH2buLN/p XdalGLD6DsP0eMQ/xopeOXzHyLmNSQyMDtpUU+TXq7HHdocXSPVftLwmg5USRYw5a7nygOwwsRfy uBHoyXM5AwwyNzKCtZoAHcS28Iy482HOIzOg60fXWNGVJ9RF+mR6uSenxUMCI2RbGxpas22YIBVU uu6UIr7QFxhVqZj+bpSh6nxDwyN6ig4auhLi7Y1kthmKyii2g0FwyD3Qp35k6KWJ5cXGVvWbjn4a 2+nyeZFgyWrVxdIKEqZ/1jKDGGw89+DT7Vquq2s4UbevTu1gOVI3ZJnRam2KC9FDV92l4T24v92g A+r2HdlX93xd3efG9JYICwRpW90Rk3CfuteRyfc8DzXcw9IMLRw5+iy2u5Ikb/XeVIi67VEyNse3 xoMZgYlg1NA4INkq3gXJy7DVMaEe549IUCUnc7QzZHBK8YH3kroIr3GGPf4GXlSz/TUQUYKYkQSM DUNrBAZdVgJj47BQKZpG3qpUO22CmVfbu9YJaSU8biUJwEg6TjcNyhmdXwrj0g6MON/kOR8aaQiT MBm8RvWH8waQERan1dZFV7D+fCm7qJgAi5yoK9s6c8i/XCeG/X5du9JbsbYpl615bSFwPZr1/UXU h0lPsjV3qpDUPU36L3kygz29FhxSLXbEiG60xLOdboEOFmnRLDh+dZln2oQUuFJPEfSmR5K3NezY IcPyRlsKBPmvNBnVaCOLWn9YqUCzWofiMQu1finMmAY6ZaWFJc+SwPDYHpPeuvY02yPGm0QyB2wM K19F3SHLduWo43fvI2C6VjIilaL3aWI72vjZWds0Jm/Lfp6xzevlQbZZq9vbnp2te7zKnR7zj1sd toZi8A7BrELOHfMwVGY7tMY0Lrx4tD2rflJdBp1sTQ0oqXCLJpRmEraJ6ZjOJAQWJjTcv8GBSYd7 o5BYw5Sa5ripXWzMoyv5YHEosDBWmpqIzzeECwWjN4MN4qNn9WQN42taPKq7au2AEqcgPQW67iYp 6m1v9Rjam5PaZtAuLkvmyqGVFtJjTmgtjOGFtz1rR7+TtGuRxZOWS6YF6Q5JfZ+1tRCUJI7uvZKc ydqGtFkKePq4QJPbBkn+nt2XRBcsEOjyoHtqU98d1mN7ztbKNdsXS3OvtyTBjkFdJTNSFMETiVna SW8Sf4UZoIXWrcGyM+yph5DOSMtwuhT7Sbh8CKdDO0YAEwyN6klFDr7h7S9VQ0pbDrqD7nKAyXKu a0ha+1VEfGsj43UZiXC42fuF8Mx0IgyJjyqUwUe/ZdtasIVCWlIlf+vLUmoAfddJrokYCMg//3l2 sSh6ht7+shyIN1z/QmNj/mjjFKTZ2z6gLJeh0S/19aQzvHs0e0UkLrb7prHmiRqh5yvvbs0qg6jr u2X33o0NQz1FkR1t9BblqLrRWXWr/d6chutVaGNj4350ajiz6qy+8YXGPLBMx7WhNrHYPHom0MF0 NL6wX9288d3A03a0tw6pLub6raHu9qOe+PYLl7rnsteFWMzOHTnruTALt77dzi2W+DyvaiKvyocZ 7srX59VpPu8ZDocLvQ3ZIcUJPXPdveVgTXdwxXTAyS+WsymRyC73Omuo/EHd3JAy968MzTWcmYIp IR5ghAmJgDwZ2QgePDSytiieh7MHzHxzZkZr0rG07U29thQAjDN43cqY8btUc4QkakC/ntHQUMOR n1cqhpfe5TmNlrHeLTDzo4HxCxzoRqukPVRW05Pi9lTrIvpxwaGrCvn0C74e7BLmJIsDjnN2AL3D MiESj7ASuHdUWORRlqLBTTSsvWVvOeUTh1UhwF0sDmvn6eRHIoHvp0sxt9eUw3nZoskq171l3A3u AxU9txtPR8lBKlWf0tijglPwArBY9Ltls5hPQua8geXJCSq+lCkLStPN4bsvJrQfG17Zl4sNBmd/ hQ+fo4lrqtVymC/3Z13sIy96a7d+dBHf9YcHVgX75il/jQ/xnf7QsV96BJ9L1Z710W5/k+Sfhpff UlBFNH/n89i/7nBBsY602OEBxsYAMtJU6c8vVNGYhxEANBJQ72BXnzHTXBNKZ7KTz/MIjzEeRHcE D17U/t+MjqsY7P0KXb6vQP+mh1SMR8Br5oekyHK8hJmHHpYtdAIdl3PujDBCX2t5QTNr0r5Mos6q s9uLlhlWtMQZgFt7ihzFJJt6yrrvbNSlTJ6d4Pky6DsYhURn21L4AIT11JTR80kSSjHgFnnBXpas EqJESjbzQP6t8tOWO24qxa2yqxHZVsLCMaUsnuLDlBtS4LdWJclpP3k7VQI/NPn6qCoSvXgvx5lD PdkdkyX/RyskW3Da4Jkk+iF1fU5l3UIlSMdeHnYWXIkt2avzD98bMPMVYNOqzTAVdW8zzWbBCzmc /zARO+8BRFBi+L23uNmkwGiq8L0AUJB40JqnUcBZ2QFHNpsG1NB59SQHhZmXQZ5UcSaCDyc0xlwb Q0bY3mtKZDvNvncwyMbBUe4ImtIOsNThvZWe1HGuJdCsZw+CQA3PeuSsq/72kNut+NVNS09SQYUw pxSK1qKFDM+jPrn/0fnW8SDM0NlFmlhDpzL3tmN/dRjb24zRHD7LqfI8N807XoYfpZDYi9C55qau CSsj2W0trJywXiwbO3qKTAIp3mZFX4HxsB4asszuKGrw7yZkxvAnIyBn7STzZVHoztGisSSE8yRW XRmrQ1XeqENAsZ2GHNZOUaXI6MEt0TPs2iJl7aa5nLL0ZGeK9k3zyB1Ftzg0F0taN2POmJYHVRka XikQIThG1hyNNI1XYkMl5NzXJNgY6IE3X6jr0lwtr9kwJ0A7rngKrdURDowOao+M+/IFCJ2qBAZk uOhqUW7JImauQcc5ahy7UUDlxmLNxLQQMaGV+B7HsG1BHl+r2aJRdq4E+MrPZak/0sASIKe1qVEL C2k1w6hmSpK6CcOR1q6OFEzaB2bWU1R62FCd1BPje72FFOzmpkmbN3TnIlSPjLFTulNaNklekqT4 WDu1hfwejz6hRoTPkRJt9IA7OTAl2IlHj4NGwC5CiqXFIj5twqrHOs5bCdSfpfZDDmcFzoFw64QU sB7X+bZf6O8CeGBI8n+Sm64jQW2dsXgWNFzfHXP+5VBVoGBNagTY3KdPjfDCFzxhnigVTG+gZc0M ZsbeqA1SlUUu6zR1tp3XT2eGyBc9TOelfzT6BnevluGIdcmGcXTd/PzuEjBGdIrh61o0TVT2GP5c I0K6/Rc+zotsNtqAaFlU7ZQS9KEtQhx01WeEmcJO02EkvNWLdNAomEqJtsAKYKGR+PUEGBzo8WbO tsR7lGiU+mYcLTDlnCI5JfmNyQ80DIkSzDpYsl061WX9mvAsS4yvihSZ5tEABiz6SpGiEwq4Kf0Y koGjTGJI2ZvQ79RACiq1pCmDtrOPX9HEOUA2TDSQWB4qTIKLB2V323kf3DjDotnCuRCSHf6Hy5Tt hMIs6MCMVCrVcMz+wsv7gTkgwbMdBhQja0TGiH/jCxtZ58tLt9z3J1g+tMNsQWmsbzw4kbQnU240 gkt2re8Nqc7Iaj30rajKWRk22vhaJhmB0xwdv5f64gwIjMhI6jcqdN9lpIae9tjNCvtXqBXDNx5y CdYmOCZ0+6r/LEIDpiy2JHaSm9FMUZFFkbBI/cL7FPnVEIvRZAELXCT+7SFBLQ97i3mGccFipIG9 c5KBliPuRIbu1k+GEztVkRe5A+hlDpZkjmRIDaAMnTn8LF5R9GSHmie4kwe1UIkMezLHqKdKRx0n k6AZu/jqJtYcnZZf5IkNVBsgI0lwKcau0yXrco05iJ3IEY5QO6Wmuiakvmnxo1tDQ3j0sh1znL9Q /B4hIw4FQ7TEGGFoBE59QZ7DzkodNZpjnq8goHI5BRJDuhaGRInhjCphqt+3Rr7P7AuDhQpqdmFG sSHb/6xWYixLv0MLuSLKzAdNKoXckxGJECe5G+2a+dRhRtw8s3+48dKVou7FYcoXJFw2r/hKcf1S fra3hz7+gL270htGe6f2Hzls3m4Hh4CN3TzrHnLxcn3H/ssip2cmA028lL9xBt+qz1ipIs+uGWbz Qc55C9mtkTuLkeYsnmig4NbWnr+Rb+BvTijRdEWPHSQYhVmasrErgV/+ksomsa5399a/le9dfgTm umH/+JEQ13++k33Ns//f3rcHR3WdeUata0xJIn+EjRJY8LRNYwr8yESWyni1bQh2xZRRHzIxlZkB B4dsgQvbGmwPNRK6DUUrpRIxciiSSBhPlRmqoMpyUvvPDCE6sRGVFZcMmqpk1rUSorRjwoaMvMaJ XyAKi8qe73Eet/t208LiNXu/7r59+/Z9nHvu+Z3veb6TaOa+L1ACgf8X3YkXE2dHm1iiTvwuoejs XXSZUYZnA2kx7dhZ4KPJta+s7R1YMJ9GJKg719zAPyW1C0B64wumLao9OajZh1yC59nCPFsmE2Qb W9ZdJ6sx4ZqVlK5I2bymP9tZZgsBAQt431G6Ib5JorZndTtQBtoHAz0eiZ7UE744FWg5UQf2NRY5 J/dDBh1YG4tKl8NSJs3jQIxWJktpD6r+ScLwSgy5FP5mFozUng09HOrQnqNWkNY2r3ErK7UDN2iD gPpAy4TNqxF4Pc2ak7bAmcWCNEuLSozAM/sLpDSidfJV8Ja3tTWAII1ZHDHlz2oCXAAyqi1lA/MX zn6SNA/Aq4ZmL8TeZqPpcIVs1gpWgnx3GdAL8Inmzi6jVuz7tcxflsm6lb6wbvieJN2/l6ENIxgf hCXf5dSdL/Zq3vUq4uR1uAi2gSADQzjVHU60D8LNKcnR66ajJgI9JMYDKzpZBfTzTOMIQcNaa200 QltbCnLXlocJ1jGwoeOHFs6SP/o//oa1HSV6avXPdwLmgZJHIAVzVAmrdSNCbVvdYUbMglSzxlSE N7Q32o3xktRsVo/ODpAHl6l9S8sxkC9hv1R0bJr4WF8t11jqtOMeRd2CRkGwUMsl9NiMFSjHjsIm xAU8qkU54ni5tOdt5qPqtZxIGVLajXiW5KAGyLqCfaViSa/ypp5B7D9Vd46R+jTkSy1WuvUC/Aku iFZn0SsZYIE8JDhaYpMqYg7UjEFCKerecKr0h/j7kMdja7zkgGGgxur2yl7f9fOk/I8wRCFIZjiw IzXhkawVvC2EE2C2UlURlgQTjE00g0iEh57X8Sjqpqn5BN44XlJMM4PGgloqfEq1K2JHmHXJv+g1 oRmb9BLYg5z3AIxf5TV+/XbW9B81pvUzM5htMGBhMTvvO5stPYW3OBmy/0Chf6dKmKCW32RUv4x/ kTVRZgLqhpojT6gkZceDIdmq5WVKFsM5fIClV8PGoEzJ4pLUAerTlQJUGHKiKQWeM3omwbPWdSv2 DmoN4CV4NG/mgkEcDpLcNaE9G6NkeFb7fYdvT/X2knhEP/a8T6VRmFdF/Tt94guBjlA1Ha9gIUkG PXBqI7P3OrhY7ZGAkqY0Xo1ai4cAcG0DNZbmAYE3Ng+flGJasxAF8zH6U+kc5VjHheilcGTkfXiN AXruQfJwaL/qNOk6cjMA6F8GUbwIgvQG57kMaJ1Soi1DnOX2EsjHzT7fpMx+pNOLaaDjD6r++Fnf mk0EAePoD6j9Z4soG2GOQVKS4Qr5r3xw4K6RKdbMLfvjUmcsIAN2WqmUqkPTQeNslFLASMjAdS2o G15S5Jyse+tUIYSi+jJHl4kFXtravTy2lhbTvdmLgFd4quj51aVPGKV7kbt9nFsZRUPOhCFaWPgD uh3isF/CpsadGPC4J9/AsUXcUWTMsz0rtTH2p+ZSpKio+sUe9hTL7CHEd7PXLfhLPOICa/Wy2UTy 4agu1KqTq6kpjZMaGDRjj9+odX15Nq+aCiuONUxgD1x0dcYEJa0P4yqFV0X+j7+TLCkGzctMwVCn YBFhAH/XaQV1l3NNrUSlgR1NY3EzFOGu9vsc7LsjWsPI2u+s/r46Km2UElI6/mzsoT4GuVlKrY0T Elr8fpIzWGmEJp+IOp/va0egyzJkUX2k4PDzJKcFLMmRJF4ieXM/OIZg57qiuwjwrKD1RbqhHNj2 uN0noJpOsgElGLV78IP0goRpTI2MBHAmAP9I0x165hbb6vUDP2UvJjVB+OEEOcexq7a3Nk+7qQW6 yeZ4ZFjyXCNHhozF0hug4mhGRBx5gzZEOxeOqA4tYolZOXJmbND/vc3aeMjrJPxmvqF+iISdye3Z Cw6EOvo6HRu3AmXOUV00O25G+FpXQYT1yGSOfo1exNwBfKLP4erLWd30tfTkbnAEqatDRk2JGlKF qMV7MXlq1PIDuKvVksOVtHHllJ80Kgf3vV5ksibohUwGBLprlIL3Ru0cRU9pkJrMUkEJWKlOn/sv 74kSXcBracks/A/CPfiwloIxMCMTkAEiOGnNWyg0wR0vM20gwb6NAPXdBfys5S7rj9hANaQdWUBt ugAoztfmkiRK1bvAYO7kzfcxeDfJPZC0WYLa/CTrN2w3HaAOKA1mQ1/8IamtqB9FVxZ8UJTc/E/T IOxxQY7cGef1/808XjLsdaIhml46QONgHdsEVKMIVXm17kah8xGzdB7W+bZeDI45sEundFFyZ8Kp CJqc8t18DhHJMrJa/bb4qNE/atwfzj60LAw2dSkhTQAsfprI7DdA4gn/A9E4vcY3ISnE1ovM1Ki2 TdPhAVbVKKKPRBzOzmebJKRQEg9dTYBREB+a6qeKntXfFbAN4LchuUJcxAHq6oqgMPr69uQiBsGI qNW8v8Ee1q47DFRvzxPTSboW5Q+ShAtvFiNMwInoXjCCKqEdEofcYkoW0eqwzIsYs3JJWD8nyc6j 8y7QQTeN8KvRY+/FqB9ZYerSbSur+3eRR9rL5XA8PtjGeHdqzUGe10l8qAW0AylV+EFi6YGXZ0Pf rQOGUEP/UHPS1ywwRA97YgKSjdu1jU1dMrOXHpWvgSF+FeIU2YiV8N/u72zWWbE7ZLOGw9QcLdpe gOq0vGJYQYI4hhZk9ODS19GCqhkL1N2uIohbEEgTf2t4Tpm6N5iPGX9GmWni7FXRJAymXy/eA7Sx A7hJhrKFqOY6yEFdcyDCkN0GnpMr+hB1HGmyhuJBfgsrxV4b9L4Nkn6ybIP2FZ3ydJc1AS0IOE45 AdwgIzmarMcRM/6SdJfAw4A/cUCyB8X2/igTkp2O87ac1H0ucsJEQBa94LfaUGuPRJpZR6WFGGGM E25yZXxHR1kQquMLHlspobikn6vSN/WEOhk0OeFDqwbrUoL2SstaZ2bTWtZOvHasmGWj3A1KrykY PKCL+TmfzIYvF1iiCt4kVoU5Bv8yW2ssu3C4Sk1U3n97N/PZkqx9FjKYph5m6k3tWpJaV6g2uoXH BpX2yIaY8ucFJqaWYaGuUbw7zytQN4YNBJ5rsw3qitl6BYRwYtGTwYLIPZBW635fhnMX+okkxq7R jGeHqNF47oDdejYeyQG30yYh+xSqq0k9YsRCbrVO+1Zvr3Y+YHaAmukH7B4JifLdutXQ/FX1Ov7V Hfvxc4hWgZ0uEDAaWGg75ZNWkqSyzIyMjan9AoaAGQGGDoWqXsT60wVyZOd5nUSGjcuDKDtyqygI 09mtmwjyn4zOwuoOZVxBulXAQz9Hfj1o2pm6gq73z/ERR0tiIoSarPuu0ZKUwzGy4bfaUnxYq6K2 QXxAzAPxeVPafHDUMBvhLt8kA2xi23p+RmWqWoox4UTngacTVV0szyalWBg7fbSTD1f/T7HRewAM toAFieJWqW7d4zX4LsSEMM+yXgAICAPeTLvHOErA0uRYUs1xEYe7DcIAEzGNH6rOSQf0eBONDg1W Wt10XPsX4UcvtUjQvZ1Ct3uU6ISvxd5GR0ZXO7/IgU5aieAQpoAsD/N1p9UTVd3/TceIUf9Gjxtz zEs9Bq+fRR0vzKJ19bWAloMhBCErHD+J8wxseRh+pklCCkJxQ0sAeNjPMEtrTHuDHLWiOqgtlmMg bQ1xhhKvsHgVkrlcq2/oXcLzLURjOif5PsnTpcfZoe9Be+lMchCjZEANr44+5wRrLU1mSXAri1IY 9x8Y7x6nlJpWwtY7x+OI2ZPFgUFuGbSqhB/mHJgGEC5xQUCroNhPr9caSNh24PXrJp6CHpNGKjwO OxygikERSRO1EA8UdmsX9SA6kSfjbKT2mXYcFGDu9Ki7R/QKkcbYKlQxTHn9For7C2QPNqyLSTJt eGexYfPjgnxd4dQdcPp5AY8qCNKYhyqANEckJYzrG5aswdweYtHav5N+DYAxT0IgVQASk1uVvr+L jWoeeNdnseLq1ouA6Ak8v+WUPVswgJAF6DosqQEGRIZks7MdjaEYLmrywRHaIXL/Y8WaC9xNwnYh GE5OhjtVtpxt3joQkL5oxbMxCfnnnCYDN9E5qijB/KKNNq9Ay3SACh7o8WKiOC7IxC49M4Qm6rQJ eBjQHVeHRAwyKUqwfr6OMec4f403ann/APXsgXzCHKIaGAZmqbaJslaan+qALeN8ttuRfIOLaTTa IEAVXVxgC1Wwydg71a17xIo5BGuAQlFDpmqhZDDq6pP0s1v38NPwRDnJw2gi6qs7p0Unb3C8fsHF NwdW1z5BtZ3WUvFLWnkPp5Q6QP4dGeB4rf4kd3Yhc73w92pxFaPYN+nYx0an+G2kWYWeFQWI6eCy buh6LDBEV7nG15DglM2DUiGWakpq3xiaic1cB9xwx0f5GG3TNumktJ1KPZli7TARaIOieUtZdGRd Pg1IHb4o6SHBxcb9IvHkQCfTLBsMFkRjGTkmwWc11hfe/qHUD7MXLCYsVBpDgRAL2HhkfRQo1tME UHiqLVhKpWjYFj6h66iOCyEooTxuhBOJjI4xtG40QbwHGggpS910W2FXWy93AjQThhB13OWz7kRJ rL20V1jdE6xZeE3J6r363zqSj9M8CkxskqjBpJWg5lY4+3c8Cf480R/Q+GYv4SIWJ/RlIcPH5s5D 1VwN6SLbEyCVsL5t4dfuMoIJ+DJdjoHIKM9PofVwl2MUiFFmAbv+eX4dOZcdlVpaso9KkEk/TYzd c/6lnywd1Ue1dbVpQ2DDdQ2Oisv/ecRx/8aDgWbFecVtUr4/06TMdU3h4X1eTKex1Enb++IKpXmX 6WCXUmJmBhxz7Yypa+fm7O01R02w3yTYghuSkvqQ+fbEAxpt1bY8OLMO7Idi2q40mXi9ZbYsog4h Ngi9P16alYngD86dNLJuomMP53OZ+ep8kcI5j8QIGDWQSZ1YprPUCDHIg3XfZBi8qLnvx6GjtX9n FF2D85ArqXeegzdDY1QDyC/p81hEmGTRVoLqoFi3P2Afgvq0LTGDwqQSwyww1H+pY9TuZ5d8Z665 yEAAABk8SURBVLN5OoUBQZ4kpcEDdKx4o+zlgDNrPdLCXybQNiX9ke6qLDL4QeCz0pYs64eoLVqE PBpP6iApkqKwiZWwN6l78NLMWZIFaSp0qRLMVOTb+ln41LVzdxC8BtZGvjXLHXioq2pq1i+Ac5Lj CFYUijDmHI6qGzEHVbNG4/T1Yj6bEj7A82hB1XNY4cce2/35EbAZ2Bn4AzFLZLPjMoo/sCYWvOEz x+Ced6AAGXMCTKnqJZeNCH3VlSwU63x0Yg7fTDpcj1qz3KBvz8MaCCXQExe1/c77C5/HQkK8vGun F0t0P9MT6qBgEKYchEElQW53SMdQNHK8XGmqpiay/ddknYUjW9Vk/yaqsWChDlDxTVgUmW2QX0pj nPW03cczFlRY7YnG24Q0MfhSwynIt5IWp2bdVjV/IvG91OFbuLYD7w2/CM9YrUOX3FaGQ/rY6LAI ZWcenWm6aCG0APS2PRfPspP0UHg+wFxGz2sLVMdCi5xwTuQlUczAE+kRtIF0ckFVa4htwcIJDiBM hthli8ey0iwUpaZxgELAzJKG0qm/u8MVIdh8NajgDLEXnCdzDg6hQF2I9h4NsF8KW5J8499Bj7aR Cr1wbsgN2gWCo54W8SOUL7olmU+RwEEyLBmrX1+QGPlIDq8QMPzUfT8uHFtRONKCGnteUFU2DAvn T/jnwaLJRV+VaU7RwK05aOfb6Df+Z9S2dQpPjnols2NhGxSU39YExurIkPGSLds5fi9Z+wNHepPh 5M35Rwh/U9rg6GT0Tqll3FQhMsVWRq3krl09jTbf/4B3MkIR6N6owATBCnvYGwFnPEShqJ49udLR vU+xJGXmqgPpikeudUOTgLh8CB5PG+MMeO44sJvUc5/m6AkgC4Qjyjczx/iArHwrSGswXpYMi1Ky paC6udl6tTbv1jTmBN55jQMciio9PZcf7/gRaZ8eijlgR+D7a3bDmT80DglMl3CIBUG52nnybSxe BfnuXoxHh5aYxHBRFxgQi35ci1J6iB7H0poVWnNZQoSWkS1kKEeLIEP0Sx01yXVkxrrX83gMzTIc PzQ5KVqKNPULer5jl+Gc9Ms0167Una2eawaWLSUOUE+qLa3d5Gn5Rv51Nr2EO83HQfdKmfjvFqIw qoB9mI2+SH2sxao66zP5neYHq+31tgR4PSVwp6gGAxQsjP0JHj+d1Rk4ldCsB+PL2lhsDUCkYOw8 GzRRugH5EWxJ6VgdF3Eo+mLH8V26HDp9YFQpyUapf2E+T3nAXHqJKjbt1fIfqvDPsujm7dY7B5xG LOy7hWQPOAqYxzkyLgLPhpP7m2kgIRTnf0G9tOsYvGVO8VezPC6fEOEoKwIGnuBCvigF1KWzGRAe 3CHcZrg3MY0ofTsPIw46Hsy/kCaPrOuGGQTyJX68h8lFxX2+8XToXhyCvqKB0RJoTkvBJHje/12m INVGAxloXJ3JQFGEDxh6HEUO6pF3HVJtHHyUAqS3TackZRd5DQdyS+wxcebvlN/ToM363ga44w+p ZwiA+TOlvksye9oI4ZRdDTvQfhJ4qGNRPJF3wBPhpsAMaYAQbPI/8Im8NFvJlkBuJShNO/WYsEsv cozvUn2H5i8SH9JhGDII5xml5hSMk3AEoUjUKTcpFdtvE+qtNveyoTRQqk1uE818rra/oV2wrO37 yDGSCuTBLkoTjXWg9D5u8jrebQkPQfea/wqzd6ZSkLDHk5Tpox19KE+hIhaE009WwziOQU+mf64K tnk3PCG4DsQSbyAhIciddZVvc+OdehgSgqBPK9yWYWhcZPO0CRuNa3/X2B12RIsym4lFms490C5Q O3mYZhUWPMgLA29lkVbabEdyaFUBRPgie+fdv5YFGIBN5EgtOhmiPiuoyDmakUPmBusbZ8HGZT9/ FWQTGnS3V90O5dPNkfg9UZ1UongO7zmJPeFuMg+nXcUV7YiqNKeccA+tHlTDiXu4ZXJ4KpYpwVKp 1b0FjLVG4O4iZfMUqwY6j1xtg+aUUpJmIuYzvJ5y75eMCJ4e5tHLLD0wvGk+WbbUcc2cYc1feT4H AgmLBvILE2Rc3duiDRKeZ9isB3HgqkEPdhPOfFZPaM9x3qvR0yJo8iOUdSZe9PTwqYDlK7qfpnBY fR09T4mh1vXyxGGdHcvfreUTCYNcC4Dhi392mYSTOCqcQ8qxTbnKRDg4191hY/R8So9rCapJmrn2 uCCHbdRtqJHztkDOijifj14ezzRs/PK8kkpC+HDJ4xQYhHgu74qjxWGyH4lPFGKFQOXIYT0HOEea r6P2mBM1b0icbWnWrLvJy92FMwn1sz/Nie1ZRrGmnpvgsFpzDBRxZlILCWhQM1GGww6td1csIvQk ddAqGmHIG3DijUT7/BybkzzkRHDcxCDbeEID2TMsELFazy3Umu3EXXqL+pxYklgxTzV/VDiEHsst k9UDP62d2S5pVCk8eDv6BBKbEGDHLyQyo5RSboAcegGPv1Ena2A7gbrHXW90V2c84hXY4/8aueYA qzRBaLxUA1t6RuEk46oEo7+9a2Bg2rRunvRHHYHO1UJg+P67Pz7iZIaKJOApocaftdzDilguPmpq uvyoqbbaZdhrEJg8MhhQJ3luSjPCz4zg9vINer6us49kYCxKWhYLMiX8c6HjF3FfZIxaaDu88rGv 55rQNii5A6dY8mRykFuiAuwHQaD1ZGxaWk4zyT9ZwncNVzRUT6Gt22wTdbrlYUxZPYtEJjhJkHwD 2xwPqGnB3fbEZn4DyXmZeA4Gcn4M6C44lIExzSxiF10p4XHmK5uN7kSADudBMyNikuKoRuZhtCQK j7kkBkglA46XsqpwRsc2UiW9hkV5PCANw3LANyGfI8//Bvvp+C110plUsm6GIYzZsf2D7lYB+20y RGSqDsgXFQUMP3UcW3+fzWneh29ew6X6rsknwzGyYUgw/bkfIU01BDYIFtpz0uPhAcK/GDhWIQ0c w0Ckl4lkQTjriBWFWKSQF8o01opDoCrYWWwoOm/8ygf6B5JNgTTeSNJssWWZqN4DHseEab+Zh/jx BhEXENvDxqZ2W9gEcT+Ze9N4MTigSQbzfS36oWRlzUu9NH+hTL9q76uaH7xpW3MgxNUCgxoV4Xom H6GHdjt3uYgNEmnmYJgMEHYzz3akh7KPeAFFkA3C9274+03Jsxty3SjAPDVH4jyKxlEHw4oDLhf0 4eiqEu3YSpLumPqEh7MpeoFmdJKzDFHhMecjKSKu4WpA3yqE8F80+CNWQ8WiziQCGNCz3vEIQSJr EWHQoX/3ZbMF0ChNEc4MY6XX4VCB1Dk3MUjIpDUnfzfJXOyxi/Yym0HUmrPQkyx3xnRx0h5rZDhH GS5Bi0541ON7trZB4a41YXzUuescalraBSkEE2R8yE3c7aLrtL3O3mwbP010qZGfA1rbuK2NRl2r m+yJMvz4pc4428M7YSk44FSppbDS4wtGHOLYreVGzUaYg/GAU0/zJnKsMKv19Ol5PEc9pBehtkwp phsmSFK1Opxo4+AMSRmhl2HdNCQJtM5YM9GOIy10x0ldvupYD+nKRn0ddSpOPwK0QBt0ITNKPUcb k4WBumevmRhvJMdQ/9z94z7FLhRjwKkw+ohFHJmtoXGEfk4SGTuPFjRkZOie7dudlPRiQLOKIH/J HVkR4UgaTuOxsuFJWTzVct6tN7DDSqsp2AYbr8RuaGaSdoygphzt3CxUPzdhhhf5Hw2a1kJxMJ6X a+jRlZ6Q+s7seTHgQh3iKMCrtRUVxfoebtKBEx/zYppP5Hh3k3hUE1my8HKHBm3dw5XbT2qw4i4Q q6PKnwuzy2rJbh4y4e6FA2Aw5atW0vP9Q5x4HBUocJp5q9FaNvEsq0MU0JJrmPgm7KRavbVFiwM8 wyeWKk1nZFXEGVOvrlI/mCO9v4lk5yaZy2XMJAfLdO9U5w4Kb6cH64F3UjRonk6gGITtW9i2Gw0M RWun98FMqzBtfR/PigQwYbD0EViORCJjY963/flywWUOk25shaVgjhmmtkhKt4WHX7JgwI+++c1S j6aw2JBBtE0sgpi7Otfx0t7HVzhYT8SzbB7zNBan4PhR48GFHFEZ6gg5BtDz5t/F//g8EiGQDncQ vbpDO+lKV5zyFVqT2JSmKKLgIwuCDDsFnb6+VzORJ+wwwLtGqe00QdNOrhRLKMkl+0J7MSt7AENM nbvP5FjHpUKv5HYm7YQTeKyxmHOP3Et/tJ23go9qsm3iIlexe/CBtORcQBxMKaZRqEoAQ6OcPWtP hawxqjIP0bPAYyQ7NKvdR9/AA3kwwXR/UhcFDQAgTe2mg0sAw/c7cbI9jYojfVHTd8/uiwBEFEiY Xj6a10C/05JHtzvxTxvmvJ3J/9/QhiKZc/zGDZmWOXa//v6W/kzLE0V2LqC/+vcMHNNvD5/TMuf2 co+GKZD6eToU0ge3tDeGdxiAiU5QOU/LE/NCfy6hK2Ycwe0lXY6/s9sSG1TxVKkorcaBDZl+vEcn F/vtmRZV7P4N9YX3dTtfEZ/CRPcJSTNnNzzeprpgqCxz/UVwmf6WzIaQVXyeeiSqPvs5i/4mXb6X 8urh1+0feCS1p+XoPMsCGzODKM2n5RLYOLMFrxGu4L3tozjsNZ374C6+x354ov3/np9vvnFJM03M rnY+0R6KhouoF3XPt1N76Kf2sHdBhswkaZjbprluplVHSgDD3/YMzrSnELG8yNzeIGhlQ3OVmamY nBmR8cWZcF8euXJupzK79jJ3myxNwWk3D3QnqhMrEodW90b9LT5+fXf14cThn5Yr3pWkQnlSRK4X ua+emYcTiQN7fd3TOjtPqiYidn5zZkLVQ/fFvNucaFyROJsYmCh5hYGPDr+44lBv3g5RbWfRzxOJ xOHugd68UkTVS9T1pg0kVqxIJFas/jh0glLA8Ec6H1HC03LV/uGtPvqlv4hrFE18WzA/MiAjJXxb 8YKK675Cdxbxv91PFK1Z4fuF+5ZHIq9YkyXWbHn0mvCjnpBvM7e622w5HXE9shxWNNMHCT29UbhW 3LWIa4JPWZij7ZEiYuEWPVSUIlWsNxUeYMpOK3mTY7pldmfOFPaQgmv4hQUoqBe9Nb+w4VsuAxi4 y7vTgWEcOWJQUEDLjzg6eKF2Ydey/OOvU+HCTD2JIvVc9tHuUaKgyss8i8grR/gKIvQUipViMn8U XCESTFHsReS1q6u74yIFEYUNUePZKVfUz1AulSt0UpPo9/I3CAcszr+lOAbsltoOTKNi9pEK9Voe Wi7vU6/lJFBlC6CQN3e4RcbGvy6dTOcq7vYa06TLUcYBV9jlSmcom5dNjlNOmkoec4WWXJ7DdWqp aEdV8E9JUYqgsR/EqT7LNtyl+qoAmCimsdHhF3rKPr2N9AxEBuz47pTc5E1L1+6Bl81ibpY+5WpJ 5H1/9jNNlkoDg2jbM5ZP0EJ9LV/O6yBOqT+z2RAU7LQzBhzOH/98xQ6qbImhrM2TrJ0b3qyu1BGX U8CIfSYlcNyoSoi6bpTS9BmvcaUTXREYWEdn/kyBAegIfAFIACfL9Td+jhRoGvk6hzNt2RVmkonp KumGQ/oa0me5t8kfWw7HUDSy9Uif4g3IKfoqkFmYj9I0Kpbjtqxu+HYO5I15gpX+2mnDCf8jP8yY blUqExh+SnQ8UlHRh2xDKRwAiT6w41aYD7yOhISosHcjzD42brzbnLvoqNeYYrpRVC4wFL2ioKH4 AqJCoQCWFcvNixYuNDbmI8JuxcUdYKO+EaaJmGK6Ik0CGIptdPT1IRwMFizxporlsx3GsDEME5c2 7qw5/jdw0jJ1yZhiup40KWAIP7XqXtX4L6vPsFo6r8sED1ivOLJz586anZZq4F2zc+NOeCPh9w9q du5TTGNkJAZGTDcdTQoYQCOXfmTZxGUCyeUKly5XHJn942M777tPvdXXMX4R7bxvJ/51bOdOtXHn gzOKOGRjiumG0qSBAQLVL+dW9F0eHr6sX5fVp+Ly8FzcBGuXl/cpUByDtyENkGPHjhmkHDt+369K z88XU0w3hCYNDPRrLP7GoyhNEeH3sGEbw8RDHtl533GCQSTdd+wHaqnYxljJyTNiiumG0FVwDKDU 2mdU+38UNI3hYQWKRx+9DF/qB/IQ9a6Ye7nvh/cdf/7Y8ePqffz4888fd+mYXpl+/PgdodmOY6kq ppuArhIYqv2ufa+v4tFHldoNkpTCQYUCxdzLFVq8mgtrfT8ERExHBLx8PJoURF7e98pU3lNMMX1m unpgKLax9Bdz5wIc5oKCMXfu5cuPKj1j7mV8ITzUP3/2PCBizPIHojGDizFYfXBH7OaL6WaiqwYG OSDOrFHQUIAAfAzPfVQBYe4wvS7PBYwA5/jRD6ePTVc0hkui4+4a/HH89N1XvmJMMV0v+gzAIBKr FNtAXChMVDwKmCBozOUVtdb3b6r5n1ZvhYAxwAG8+fUgYmaN+uyHuV1jDSOmm4I+MzAUbfvkXgQC LWhl2K4ANIYfeR7ZxumxNaenrxlbo5b8UmBZoz5dgJr926agNDHFNAX0mYBhwvZTS7+sITGs8YHC FcNFoWMIJKquB9eMjY2dHhvDJb6mT+8am366a/oawMdY55nYrRHTzUBTwTEQHEdRpMqnYXdt+Jf/ 47RDY7hcA9+KjzzYpVbUj84zcVxhTDeepgQYTDPeuxf0b0ND+BkaUuyCfymRas3p010HT+9XkIBl Vxe+CSkH8a+u/THXiOmG01QCQ7GOuz9hHjFEYBiaOzzsIEVtG/rRv/1PhEFX15gCwZqu0wcVLvYr jKiXwsua/V1r9t9t/Box94jphtDUAkOR2PpVxMQwMYnhIcM3aG1YvR95RiEB6GBX18H9uN4Fr4Pq c8fBgx1dXZ078mJuY4DEdF1pyoEBaQ7WP/0YAAFZBABiaIiRYT7Dv3hmDUFjfx516a/t705dqoiY YpokTT3HwGVq678+MISSEzOKEOHP4V/+63v5qDBA6VDfXb86U+Z0kjHFNNU09RyDSAh/xqXPVykA /NehYjR3+BvP3PHeQYWCgwCIDkQEfg6eVt8H/3b/HXfHenhMN4SmDBgFSR6Bjla+NTRUNVQVBgRu qKKNw798pkshoaNjP70YGopjdHR03KE275gRS1IxXX+6VhzDgCN17v7HCA1DDkCqeAHweO4XT++/ g3DhEANFrVXGbCOm607XDhgObXvo85pRKChUDbVqjlEFX7DlF1/uuNTR0XmpI0Sd+O74287FMduI 6frSdQGGopE999+LEGDBqrUVIYEQUb/Uj3u//J8IC/ipJGisol/7O/edKTcVdEwxTQFdL2AoEt// yVeeQ2RUVWneAbBorSJqHXruG093dlZ2rKqs7Ois7Kxc1aFW1KuzsrJy1arOPG0j5iExXUO6bsBg M+62S2+1Vmn1WzGM1qoqq4/D64EvX1J46OwERChcMDZguapj3+KjNzTfcEz//9D1A4Yw0xBse/it IeYSVbwy1IpyVRWCRjGOVUsrNa2Cxb5OvWHb2hgWMV17us4cw8wYuvDhrxjVmxgH6R/EQaqeu/eF 9wgI+/Z1Vu6Db1gCOrbvOBOPEI/pWtN11DEcoqmwtj30++da1yk1vJU+rcgwkHGoz7eH3nq6c1/l 0u3bFRyWLt23b+nS7ZX7tgM69t09IxXzjZiuJd0YYBDBoPHvV97/KSLChUcrsZDWqnWPvfX0vu1L dyhQ/EyhonK7egNKFDa2zoi9GzFdO7qRwNCUWvjwA89pbORTVetjX/kEoKCAoRaKgRAt3b508YxU rIjHdG3oZgAG0sIv3v/At5FPoA5OoMAVeD/3jUuVCgznlGSlQMKf7dv3rF8bzyQQ07WgmwYYQKlt D331H11mEVr99J1LCgqV5xRAlu7Zs1299gD/WBybqWKaerqpgAEkxNY/fvVrBhUWHHfC4v23gHOA ILUHvhaTWLXY6uIxSGKaErppgMFmXB16+M17/vQAIGGdRUUVr73/wCeV288pfvFF4BqL9+xZvH3x 4sVrj47gSeKEhjFNBd00wGAKObZf+d5/fucxAMWdhIk76dN657pvf17JVTv2ACz2EDK2L16/MA6n immq6OYBhnDn/namk2lbeM+fblPQeNJA4076bn3/9588tGPHYqTv7VGLPeu3rY1V8Zimgm4eYJQm 8b2f/Om2L7X+5s4nLTLUV+u6T79y6dw5Asd6XG5dGzs4YvrMdKsAg2hk4RcffuFrAI3ftP6mFfGh 1u98/9MXLp1DjrH4nILH+q0LX8EZYW90cWO6denWAgbo1qq5r13/0P2fvt/6JPKMJxUbAQbypU+f VuhYv554x/cU44iBEdNV060GDCbU0dcufuiF2x5bBzxDgUQh5Ml1X/r0Hx66e/36rYrWL9464yjE 9KZiH2BMk6ZbERjhZi7WfuueP73zwDqUrBTnePLOdZ++8PDPCB1bz7DGESMjpknRrQgMJCE4Rtds WKv083du+/Y6JWEB8/ja7z95aP3ChWe2Lvx+rI7HNFm6VYFRwAHshrULv/jHr/+XT7/05J2Kebz/ D1//2ZkzM7bOiMdwxDQZulWBEUEFg15T3zr30MPv3Pa1J9f933e+fs/6bfEgjpjKpv9AwCASgoUs 8hjyUPNvbf3JH3/yx3v2/P3WWA+PqRz6f3H02g7T90p1AAAAAElFTkSuQmCCoEYd8H4NAACS2Qan 2jNmhxJZiQHycfw7///Y/+AAEEpGSUYAAQEBASwBLAAA/9sAQwAFAwQEBAMFBAQEBQUFBgcMCAcH BwcPCwsJDBEPEhIRDxERExYcFxMUGhURERghGBodHR8fHxMXIiQiHiQcHh8e/9sAQwEFBQUHBgcO CAgOHhQRFB4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e /8AAEQgAOgCUAwEiAAIRAQMRAf/EABwAAAMAAgMBAAAAAAAAAAAAAAAHCAYJAwQFAv/EAEgQAAED AwIDBAQJCAcJAAAAAAECAwQABREGBwgSITFBUWETInGBFBUWN1JydLKzMjU4QnWRobEYNlSSlLTT IzRDU4LB0eHw/8QAHAEAAQUBAQEAAAAAAAAAAAAAAAEDBAUGAgcI/8QANBEAAQQBAgMFBQcFAAAA AAAAAQACAxEEBSESMVEGE0FxsRQiMmGhB0JSgZHB0WKi4eLx/9oADAMBAAIRAxEAPwCyqKTequI/ b/TepLhYLhHvipdvkLjvFqKhSCpJwcErGR7qb8V5EiM1IbyEOoC057cEZrt8b2AFwq1yHA8ly0Uv d1t3tK7az4MLULVzW5NaU618FYSsYScHOVDFfGmN4tKah0Deta29m6C2WYqElLjCUunlSFHlTzYP RQ7SKXuX8PFWyONt1aYtFJ/Q/EPoTWGq4Gm7XEviJk5ZQ0p+M2lAISVdSHCR0B7qat4uUGz2uTdL nKaiQ4zZceecVhKEjtJpHxPYacN0BwO4XbopDucVW2iVqSIeolgEgKTDbwfMZczWezN0LLC2vVuH PtV7iWkchS09HQmQtK1pQlYRz45SVDtI6dfDPbseRtWOaQPaeRWd0UlNP8TW294vcK1Nt3qI5LeS yh6TGbS0hSjgFRDhwM9+KddcyRPj2cKShwdyRSx3Q3o0tol1yAgqu12R0VFjqAS2fBxfYn2DJ8qX vEHxAxbMu56N023Pj3hh4x5cxTaQlpOOvoiFEknOMkDHtqbQpchYXlbi3Dnr1Uon/vUXKMkIG1X4 redjOzWJq7nS5Elhv3Qd/M9B9T8vFwX/AIi9fz3lG3fF1paz6qWo4cUB5lzIJ9wry4m/O6DDoWvU DchP0HYLOD/dQD/GvZ0Jw8aqv0JufeJbNiYdAUht1suPkeJQCAn3nPlWSXXhflojFVr1Yy88B0RI iFCVH6wUcfuNROGd2+62r8vshiu9nLY7G3w8X91H1XPofiYUp5uNrCzNpQTgy4GfV8y2onPuPuqg tP3q1X+1M3SzTmZsN4ZQ60rI9h7wR3g9RUEa20lftHXhVrv8JUZ7HM2oHmQ6n6SVdhH/AMa7e027 UvbvU3pmjIftziwidEH5LiQccyevRY7j7j0qRjGaR3CBdKj7U9m9HjxRmYsrYy7kL913l0P08uav yikN/Ss20/sOpP8ACN/6lH9KzbT+w6k/wbf+pVj7JN+ErynvWdU+aKxXbDXdl3D02q/2JqY3ETIV HIlNpQvmSEk9AojHrDvophzS00V0De4UE77/ADz6v/a8j75rYpZPzLB+zt/dFa699/nn1f8AteR9 819tHdv0SfRfLj0eBy8olYx3Y8qvJ8fvo2b1Q/hQ2ScDjsm/x8/1q0x9he++K4djf0TtyvrvfgN0 h9VfKr4Qx8qfjr03IfQ/GXpeblz15fSd2fCnxsb+iduV9d78Buh8fdwNbd0R6oDuJ5KWPDbIjw97 tNSpTzbDDLzi3HHFBKUJDKySSewAVlHExvO/r+6KsNiecZ0zEc9XGQZqx/xFD6I/VT7z17EoCQcg kdMdK9bR1zhWbVVsutxtjN0iRZKHXojv5LqQeoP/AL6Z7cipLoWmTvDuQE2HGuFUFwu7EG6qja21 pExbwQ5b4Dqf948HHAf1PAfrdp6dri4ugE7AX5KQAAuKAB9obpj6Uvdr1Hp2De7K+h+BLZDjKk9w 8CO4g9CO4ilzxefMDf8A68X/ADDdU3fPlyGl3Ueql8AbGaUCVefDNua1q/bBSrtJButha9FPUo+s ttKSUO+9IIPmk1KmwuhGdw7rqGwkhExNkckQXCeiH0utcufIglJ8lGvA0hqO9aDvt0YQlxhyRFkW yfHXkHC0lBBHilWCPMedWWZGJmOaPiG6bxAO9aHmmkgE9P8Ai6e4V5e1Dri83yQMOTpa3in6IJ6D 3DAp+cImj41+1U9fp7KXY9nabU0hQyC+vPKfPlCVH24qbrmQZ7xByCroatLgpbQNv7s6Mc6rgEn2 BpGP5mqzPbxRwX0/YLa4OQcGLVBBtuGiuhe4emy5uIDeidpG8/JnTLbBuDbaVypLqecM8wylKU9h VjBJPTqKV+nuIbX8C4Idub8S6xeb/aMuR0tkjv5VIAwfbmqL1DA2pdvMly/NaVVciofCDLUz6XOB jm5uvZjtrofFmyX/ACNE/wB6P/5qpex5dYcrbTtR0iDDbDJgOea3dW5PUHmB0pdHdG22rdPZU3u3 tczyYpnwFEeuhaQSts+3CkkdmceFQ8/Z0uvLd9ORzqKscvZmthcDUG31stHxXbb5p2JDQlQQwzLa ShPNknAB7ySffUFLACyB1ANK7Ikx3B0bqJ5q17JaXjarDNi5kRMbHcTA6wRxX0I6D81ic+OI0lTI VzYA64qiNsOGiHrLQVp1O5qx+Gq4Ml0sphhYR6xGM8wz2VPt8/OTnsH8q2B8NPzF6U+xn8RVaGTI kbixvB3NX+i8w1XFig1PIgjFNa9wA6AGgu7stt81tro9enWbmu4pVLXJ9MtoNn1gkYwCfo/xorOK KqXOLyXHmo4AAoLW/vv88+r/ANryPvmtilk/MsH7O390VJ+53Djr/Ue4d/v1vfswiXCe7IZDslQU EqUSMjkODVaW1lce3Ro7mOdplCFY7MgAVOzZWPYwNN1/hMxNIcbUk8fP9atMfYXvviuHY39E7cr6 734DdMjii2i1VuVe7LM087bkNwozjTvwl4oOVKBGMJNce2mz+q9O7Gax0XPdtxuV4U4Yym3lFscz SEjmPLkdUnuNOtmZ7O1t72PVcljuMmlMewNnt1+3i03artGRKhPyiXWV/kr5UKUAfEZSOnfTT4w9 qE2C6fLqwRAi1zVhM9ltOEx3j2LAHYlf8FfWFe1szw9a70hudZNSXR+zqhwXlLdDMhSlkFCk9AUj vIqob9aoF8s0uz3SMiTCmNKaeaWOikkYPv8APupcjLDZmuYbFJGRWwgqMuEndj5IagGk75J5bFc3 R6FxZ9WLIPQHySroD4HB8aoHi767A38j6cX/ADDdIe+cKmuG7xLRZ7haH7cHVfBlvvqQ4W8+rzAI IBx24pw3LQW5F/4d5mgdQP2t69oUw3FlCSpSHWW3ULHpDy5CgEkZwc4HfmknMJlbKx3iLSs4w0tI Sb4E/nZun7Ed/GZr1uNbbf4uuzW4Nqj4izlBm5JQOiHseq57FAYPmB9Ks04ZdltXbc66m3q/vWxc Z+3LjJEZ9S1c5cbUMgpHTCDT31ZYrdqbTc+wXVkOw5zKmnU94z2EeBBwQfECuJckMyeNpsJWxkx0 Vq+queCm/sNO3jTTzgS6+huXHST+VyjlWB54KD7jSc3N2H1noWEq5zDDmWz05aD8daiUjPqqWMer n39enhXjadulxsNziXS1ylxpsVQU06juI/mD2Ed4qPq+VGSzgN1a9A7F6BNqODlxvFB4bwu8OJpJ /i/kU8OJ7bW/nWUnVtnt78+BNQhUgMIK1MuJSEnKR15SEg58c0lrVp++3WaiFbrROlSFq5QhthRO fPp099UtoPiQsMuG2xq+I/bpiQAuRHbLjK/PA9ZPswfbWUXHfzbOJHLrN3kTFgZDTENzmPvUAP3m qZ0cTzxB1LT4etdoNLgbhSYReWig4XVDldAg/qPmlhO4frXY9Avah1JqORFlRoan5DLTaChK8ZDY J7TnCfM9lT7TP3q3due4DiYEZhdvsjK+dEfmyt5Q7FOEdOncB0HnWAaes9xv96i2e1RlSJkpwIbQ nx8T4ADqT3AUzJwk0wLW6C3UYcV0+qye8d62po/L686WF3z85OewfyrYHw0/MXpT7GfxFUgda8Lu r5F757BLtKoQjspK5EhSVrcCB6RWAk4BXzY69mKpbZ7Ts/SW2lj05c1MqmQY5bdLKipBPMo9CQPH wrSSyNOLGwHcV6L581OZuTqWROz4XOcR5E2FltFFFQFGRmjNFFCEZozRRQhGaM0UUIRmjNFFCEZo zRRQhcFxhxbjCegzo7ciM+godacTlK0ntBFTHupw73GJIeuWh1CZEUSo291YDrfkhR6KHkSD7aqO im5ImyDdXOja9maPIX4ztjzB3B8x+43Wuq82a7WaSY12tkyA8DjkkMqbP8RXRAKiAAST2AVsffZa ebLbzSHEHtStIIP7668a2W2M56SPb4jK/pNspSf3gVFOLvVr0OD7R3OiLnY+4/q/1KiHQ+0+uNWv o+BWZ6JEURmXMSWmgPEZGVf9INVVtDtZY9vYRWwfht2eTyyJricHH0UD9VP8T3nswwKKfjgazfxW P13thnau3ujTI/wjx8z4/QfJFFFFPrJoooooQv/ZoEYd8NwoAACV0HfBNcnzrfYUiYU16TQ////Y /+AAEEpGSUYAAQEAAAEAAQAA/9sAQwABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sAQwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/8AAEQgAawB+AwEiAAIR AQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAAB fQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMB AQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A/v4ooooA KKKKACiiigAooooAKKKKACiiv4U/+Di//g5X8a/Afx742/YF/wCCePi6z0X4jeFxeeGP2if2ltHe DUNT8B+IZoJrbV/hR8IbgpLY6d430BJRbeNfiDG11qHgzXTc+GfDSaT400PUdY0UA/pI/wCCi3/B a/8A4J8/8ExtOvLD9ob4w2+s/FwacuoaN+zx8K4rTxz8atXS4haewe+8OQX9lpXgXTtSjSR9P134 k674O0PUVimTTL++ukFs/wDPb+25/wAHD/8AwWq+Dn7P/hf9s/4b/wDBJLwV8Af2O/F2o6LbeHPi b+1BrviH4reKNS03xLuTwprvifwB8M/iH8GfF/wr0zxg9xpZ8Pal4u8PXXhzUJ76y0/SPEmuT6zp c8v5F/8ABrr/AMEjtI/4KL/Hv4kft9ftjWGu/FH4PfAn4g6ePDum+N9Svtbtfjx+0ndCHxjqV54/ v9Ta9v8AxjoHw5sb7QPFXizSNUvkg8X+JPFnhOy159f8Nx+LvD+pf3w/8FXf2TfEf7cv/BOn9rf9 lfwX/Zh8dfFf4UX9t8P4danis9Ju/iF4T1XSvHngLT9Rv5yIdLtNR8YeFtFsJtXlDx6QlwdSeORb UxsAfx9fsJ/8HpvjXX/ip4f8G/8ABQ39nj4V+Gfhp4m1a30u7+MP7Nlv490iT4cRXkscEOt+I/hr 468XfEvUPF2g2cj+drk3h3xbpetWGnJPeaToHiK9hi0i7/0BLG+stTsrPUtNvLXUNO1C1t76wv7G 4iu7K+sruJJ7W8s7qB5ILm1uYJI5re4hkeKaJ0kjdkZWP+L/APC//ghN/wAFbfif8bNH+B0X7BP7 S/gjVr/xOvhzVPHvxG+E/i/wV8HPDkEOoR2Wq+I9Q+L+u6XZ/DnUPD+mQtNqKXnh7xLrEmvWVu3/ AAi8Ot3E1rBP/slfCbwInwt+Ffwz+GUWoPq0Xw6+H/gzwJHqskAtn1NPCPhzTfD6ag9uryLbverp 4uWgWRxEZDGHYLuIB6BXjvhT4neIvEfxe+K3wz1D4U+NvDPh74dWngy50D4p6vbqngr4mP4o0OHV tTtvCNwIkaWfwldSnR9bVpZdt/FIBsC7a9ir+Yv9vb4s/FTw58Qf+CsNv4e+JnxA0G38F/8ADCf/ AAh0GjeM/Eelw+E/+Ej0Twc/iH/hGYrHUoE0H+3nnnfWf7KW1/tRppWvvPMjkgH9OlcJ8Ofid4C+ LnhpfGXw18T6b4w8LPqutaJFrmkmZ9Pn1Pw7qdzo2s29vNNDCLhbLU7O5tGuIBJazPCz2800RVz+ Nv7Q/wCzjP8AA/45/skeH/CPx7/aTmtf2nPH/iX4S/H241X4z+Mb278e2lz4XTU4fFFq0moG38Ie JNNvLedtJuPC9tp1vpcE0Npp8FtaQzwXn5n/AARsvFPhnwh+yD8PPBep/tM+JdI/aV+IX7UyfFXw F8Lfi3ceHtY8Z6B8EfFGrXmi+FvBFx4h8S+GtB8KNq7S3Wq/Ey/s9b0rVfEWmIwjuZ7+5jtLwA/r 9or+W341ax+078IPhf8AtR+D/C0Px7+Cvwikf9nbWfhTpnxZ+M/h3xv8S/hZ4wvPip4W0HXdG0i/ 8L+PvF3ii08FeLdP1m61BrPXb+e0ubfS1sw7rc3Ud39cfGj9mzxH8PP2mv8Agn7+z9pP7Tv7UOpa Z8bdd/ar1z4ueLtX+MPiX/hKPFbeGPhN4B1fUrCzu9Onsk0LS9Uh03VbXTLK0WU+F5fEGo3+h3Ft qDm7YA/dqsTxN4k0Hwb4b8QeL/FOqWmh+GPCmiat4k8R63fyeVYaPoOhWFxqmr6pey4byrTT9Ptb i7uZMHZDC7YOMV/Mj+0z49+L37Hfxb+Nn7LfwK+Jvxxufhz8QvEH7L2i6BZS+N7jxZ46+HA+Jlz4 jk8WR/DXxf41vml8O3fiKPw2nh6xn1TWbaxjvdet3vL+G4httQt6nx8+D/xT0m28Z+GvDPgf9rj4 JfAS+/Zv/aN8ZfEnwf8AGH9pTwz4iOreNfhz8FfHnijwT4m0TStL+KfjPxLq2la1rljb+HviHoVr bx6Jq+nalEmpWw02ArZgH9OvhPxT4f8AHPhbw1428J6nBrfhXxhoGjeKfDWs2qyrbav4f8Qadbat o2p263EcM6wX+nXdtdQrNDFKI5VEkaOGUb9fDf8AwTn+FuifDX9kL4EXuj63401iT4i/B/4P+P8A Vo/F/i7WPFVvpGqa58LvCL3Wk+E4dWnnXwz4VtnQtpnhvTPK0zTRJIlpDHEVRfuSgD8VP+C+n/BS iX/gmR/wTx+JHxT8HalFZfHv4qT/APCk/wBnkYt5p9K+Ifi/StTlu/HwtLguksPw08L2Gt+MLU3F pe6bceJbDw1o2qW0lnrLqf8AG+nn1DWNQmurqa81TVdUvJJ7i4nknvdQ1HUL2dpJZppZGlubu8u7 mVnkkdpJ7ieRmZnkck/1Zf8AB3z+2zP+0T/wUmsP2afD2rSXXw4/Yq8B2Hgp7WG7hutLu/jJ8TLL R/HnxP1m0e3kZFmsdEl+HXw/1K0uEF1p2veA9chYgTGNPg7/AINzP2K3/bb/AOCsH7OXhnWNIGq/ DX4G6pL+0z8VVlhmmsx4c+EF5pup+FtOvokie3uLLxL8VL74feGNRs7yW3t7nSNY1LJuGjFncgH+ op/wSX/Y2sv2CP8Agnf+yx+zIdMh03xZ4N+GGi618VPLSPzLv4xeOUbxn8UpZZ0jje8is/Geuato +lz3ANwuhaXpVq5C2yIv6L0UUAFFFFABX8+//BVr4of8Elf2OoPjr4v/AG4vj54q8HeNP2ubX4S3 us/CXwBq9t4n+LHiiz+DUNtpvg3UfAvw+0jw5q2r+HvD8zeG5LXWPF/i+Wx8G3ep21zpi+IbHUpr axf17/gsj/wVu0v/AIJxeA/h98LPg94QPxz/AG9/2pNYt/AP7KH7PWmW95qNzq/iLW9Tt/DNj468 X21gY5Y/CWm+JNS03SdK0Vb2w1fx94luE0HQ5YNO07xd4i8K/wAR3/Ban/gkNrf7Hf7EVh+3l/wU S/ae+Ifxu/4KkftZ/Hzwzp0/hXw7rPhqX4T+EbC98O654l8ZaHqrXfh+51zxdH4G8PaJp/h6DVfB mreDvBHhfVdT8LeFPC3h3UvCunxa1q4B/S18Cf8Ag4u/4JJ/8FMP2wv2UfgzDov7Xnwl+KWifFpb j4Ea98UPBPwx8OfDjxP8TvEFm/h/QPCmtX3gj4ofFLXUl8UzyQ6R4fjvtG0Gyl1jULK2vdWspJ4w v6e/Fj9hP9iz9mX4TeL/AIo/F79pj4wfA/4TfDPxVcfFTwl4/wDFXxw0Hwhon7NfiHWNX1CbUp/h Lrd74ZgbS7jxvqWu2+jXega9J40vPGmqR+HrG3sdR8Riyef/ADX/APg3a+CHhv4gf8FJ/h78f/ir rNh4N/Z3/YM8MeKP21fjz8QtaZrfRfCPh74NWYvPBMkt20EsMup3vxQvvBslro8ROralpOn6/Po9 tdXWmtGP7If2bv2dPib/AMHHHxmj/b0/bq0jxr4K/wCCV/gDxNqlj+wz+w7qGr6v4Zj+OD6HI2l3 X7QnxvHhvVLN9Us73Uk1G20q1hv3N7Jb3nhjSbpPAen6vqXxVAPkL4of8F+P+CC/g2T4wfDm4b/g o1+1ZqHxM8X+Ddc8d/tJ6P4T+Gl1r/jg/DPWdO1fwlp2lap8VfH3wc1nTvCNneaZCLbTIvhdoHmW X7jEMMGmi1/qN/ZK+Pf7Gn/BV3Qf2dP+CgX7PPjTxV4ls/gZrHxf8MeGtMvbceFtU8IeMfH3hLR/ DHxA8HfFDwle2l9cprul6BLo9/pX9mawdKmg1Ky1vTNU1zSNQtJ5P82f/g6L+BH7JH7Nn/BUnUfh F+yF8L/B/wAHfDfh/wCAHwhvPip4D8BWaaR4T034t663ijWnutK8O223TfDv9p/Cy++Fl9fafpUF taXupT3mvzxPqes6hcz/ALXf8EEP2wPBf/BHb/ghX+0N+3N8crTVtcvf2g/2p/EWgfss/Be21aC2 v/jZ4n8IeCvDHgeyl8MwSSynTtMbxtp3jiy+IniOOxuLnSPDXw5luILHWdUHh3RNUAP6k/8Ago/P /wAExf2bdL+KP7QP7ffxmsvhjZ/G3wd4b8FQabqXiab/AISrWLj4W3tvrmgal8FPBPhXR7/4i6v4 28PahcWdzeXvh611uztIr6KLXraDRr6aOb+bXRv+Djb/AIIkaN4x8Zv4+0v/AIKsftJax4m+H/ib 4CwfFv4y6J8C/FEegfC7xjp1z4b8THwZBb/GXwTrWlWWtaZfXl5qGqaj4Hn8bXa3N21xby3V1PZz fXX/AAT4/wCCHvxM/wCCgvxCk/4Kkf8ABd2O/wDi18Y/i1DBrfwa/Y51t7zRvh78FfhXcpdXvgvR vHvhrTrm1Nq9tZ6mt3onwg8xU8PQhNX+Lt74q+JXiTxdonhr8mL7/gl3+xd/wUJ/4OYPiF+zV+zN 8HfBvw6/Yn/ZA8P+F/EH7Vfhz4f203h/wJ4u8VfC+30nTfGPgrw5pVhfW8OjyeLfiZr3h74TeLLL QDoEn2Pwr8R/F+lQ3F/A+p6oAfUf7ZH/AAcq/CD/AIJ6fAnwZ+z/AP8ABMy8+PP7RPi74k/Dvwp8 Q/CXxc/bN0fxJpHhD4C/D7xJ4fsbLwX4a+G/gHXPBHw317x3Da6RYSXujfuYfhlpryafqOk+JPiR pVzdaLYfxpftPf8ABTr/AIKBftlazqerftH/ALXPxx+I1pqssskng+bxzq/h34aWSzOzvDo/wu8K T6H8PdGiIYRuNM8NWrzRxwrcPN5UZX93v+Dxb4g/C3XP+Cmfwr+Evw20fQNMuv2eP2Rfhj8N/F8e g2GnaZa6Jf6n4q8f+O/C/gW3sNOtIIrTSvC/gHxT4V1HSbWOUWllD4nmsbPT7FLV5Lz+TSgAr+27 /gkZ4p8cf8EVPCXw48ZWvgbwb4w+M37UXwq8FfF39ofwv4rhktPEfhL4eeM5bvxJ8EvhDp2swW76 z4E1+L4bXPh/4veI5Zra4W81f4q6b4f8UeFdQ/4V7od7N/JT+xh8KfD/AMcv2uf2ZfhB4wnSz8E/ ET46/C3wt491CVwkel/D/U/GWkRePNXk/ewySJpHhD+2tTeC2k+2XK2pt7GOa8lgif8Aq0+PfxTu fjd8aPid8WJ7IaVD468Z63ruk6Giwpb+GvDc15JF4V8KWUduqwQ6b4U8Nw6V4c0yCBRDb6fpdtDH 8kYNfl3ijxPi8gy3AYfLMVPC5jjsX7WNWnyucMLg+WdXSUZRtVrVMPBxmnCrTVanKMouaP8ARL9n Z9H3hnxo4+41zrj/AIfw3EXBHCHDDwFXLcfGssJi+IuKpVsHgGqlGrRqKrgMqwedYunVw1SOJwGO llmNo1cPiIYaq/8AQA/ZA/bE+D/7afwrtviZ8KdSliuLOWLTfGvgjV5LaPxX4D1943kGma5aW8sq SWl6kUt1oWt2jSabrdkkj28kV9Z6pp2nfVlf56X/AAT/AP2wfEn7F37RnhH4mWt7qkvw/wBTuoPD fxc8LWMoMHiXwJqEpivJjZvHKlxrHheaVPE3h1o/s10+o6cNL+322m6vqkdx/oRWF/ZarY2Wp6bd W9/p2o2ltf2F9aSpPa3lleQpcWt1bTxlo5re4gkjmhlRmSSN1dSVINevwFxcuK8rnLERhTzTAShR x8Ka5YVFUjJ0MXTjryQrqFSMoX9yrSqJJU3Tv+Z/TP8AoxS+jb4iYShklXFY3w84zoYzM+DsXjJ+ 1xeAngqtGGb8N46vaLxGJyeWLwVWhi3BfW8tx+BlUnUxtPHcluiiivuj+OT8cf2Z/wDgkhoHwz/4 KK/tQ/8ABTb9oj4qy/tJ/tE/FfxXrGj/ALOz6t4WGheHf2VfgH9luNF8OfDzwRYXeteIDc+MIfCc /wDwi/iLxzYnQoNUsW1q5sPD+lXvjPxhNrH8H3/B3J+3SP2nv+Ckifs7eE9bk1D4YfsTeFG+Gggg uJ5NMuvjV4vax8S/GHVbeJzHHHdaWsPg34caivkb49V+H2pNHcT208JX/Sb/AG7/ANqzwv8AsPfs c/tGftY+LhaTab8D/hb4j8Yadpl87x23iPxj5C6T8PvB7PHLA6SeM/Hmp+G/CduyzwbbjWYiZ4QD Iv8Ah5eNfF/jb4x/Ejxb4+8WX2peL/iP8VPG+veL/EupGKW81jxR428ca9d61rN8YYEea61LW9d1 S5nMUKPLPdXOyNGdgCAf05f8EbP2HPF/7Zlj8N/+Ccfgu+1TQPh18cdY8Bftr/8ABU34iaE93pl3 Yfs2eDZ3P7Kf7KUWr27Wc8ms/EVtU1X4yXEEN1e2T/8AC0vh14pt7R7/AOC3ieym/wBN/wAYeJvg 3+x7+zn4j8W39no3w1+Av7NPwg1LWptM0O0s9N0TwZ8MfhT4Sluk0nQtO82zs4LbSfDuiJp+jaak sCO0VrZxMrOtfl9/wQW/4Jrzf8E4f2G/DmkfETTBH+1H+0Jd2nxt/ae1S5uX1DUrLxtr1ireHvhm 2oTh7g6f8KPDdxB4blslvNR08eMZvG2s6Zf3Nrromf8AJ3/g8b/byf4GfsS/D39ivwZrJtPHn7YX io6n46SyuWS90/4E/CXUdI17VrWc27x3Vh/wm/xDn8F6VaySOLTWvD/h/wAeaLNDdW8l2kQB/nrf H34u/FH/AIKIftt/Ef4va49ofib+1Z8eL/VbK11jV4bLRPDsvjzxOmn+FPDlxrmoNHa6V4T8D6JP o/h2DUr+SO00fw1ocVxeTJb2kso/ux/4IqfsKeGv+Chfxt+EP7Vfi7Rb24/4Jnf8Ew9Lg/Z6/wCC afw11rR7rRdA+O/xZ8D6oL/4qftkeIvDV5bQw3EnjD4pR6l8Sr1HF5cXHxFvdH8Jatqk/wDwp7W9 N1v+KD/glj+xJ8VP+Chv7bfwj/ZX+Fl7q/h5PiDPq8fxS8eaTZJdt8OfgfBp0sPxZ8W3Ms6fZbUN 4Su73w1pcF5cWdv4i8ReItE8GtcF/Esdtcf7SfwK+CPwz/Zs+Dfw0+Afwb8M2vg/4XfCPwbofgXw P4dtGeVdP0HQLKOztTdXUpa51HU7xkkv9Y1e9km1DWNWur3VNQnnvby4mkAPzj/4Ld/8FHtI/wCC Yv8AwT8+Lfx2stRtIvjL4rtJfhN+zlo8ywXEuo/GbxnpmpR6Frb2E7BLzSPh9plpq3xD12GXZBe2 Hhk6KJo73WLBJf5L/wDg1q/aN+Fv7HH7CP8AwWC/4KMfG+7bV9a8Ha/8N7nxHq+q3jP4h8a6npnh /wAea/4Y8G6dqlwl3NHrvxM+JHj2DSJp1hK32rX2k3urmeDSoJLT8pf+Dof/AIKcv+3r+37rHwj+ HPiU6p+zb+xzLrnwn8Arp9zFLovi/wCJ5u4I/jN8Sont2livo7zxBpln4E8O3iXd3p1z4W8C6dr+ krZyeKNWS4/PbVfgT+2t8Lv+CPOh/G+9nv8AQf2Iv2nv21rPSl8PSWN/Z3viX4j/AAY+GXi6y8G+ Oft6Tra3vgTXJNe+K3hi3tJbcw3PjP4UNeSlptI0eUAHw3+0p+0F8R/2rfj98YP2kfi7qv8AbHxI +NfxA8SfEPxZdRmYWdvqHiLUZryPR9Hgnlmex8PeH7JrXQfDmlrI0Gk6DpunaZbBbe0iVfEa9X8d fAz4u/DHwN8JviT8QfAHiDwf4J+Ouia94m+EOua9bx2Efj7w14Z1k+HtX8R6DZSyjUpvD8WtrLpt nrc1lBpmrXNrerpF1fLY3jQeUUAf0Hf8ECf2K5fj74i/bg/aj1mBl8I/sX/smePNc0q6MUssU3xa +MGheIvBPhOwlj86C2lhHgCy+LV+ZJftTafqlnol7FafaBb3Nt9xV+wP7CPwEtf+CeX/AAbQpq3i OytdH+Mv/BQfxHonxIv4r6Em9l0D4maho0vgTS0W9FrdyWqfs7+CF8VW8EUPk6T4h8Xancwi5jkk u7v8fq/m3xkr06nEGXUISvPD5VB1UndRdbFYiUItdJckVN6XcZw1elv98P2VOT47B+CXHGcYil7L B5z4kYqnl8pU1GeIhlnD2R0cTiITsnUw/wBZrzw0PecYV8NiopRlzuRX+iH/AME9/Et54t/Ye/ZU 1vUJ57q9b4HeANLuLm6Ja5uZPD2hWvh77RPIZJXnlmGliSS5lkM1yzG4nCzSOi/549hYX2q31lpe l2V3qWp6ld21hp2nWFtNeX1/fXkyW9pZWVpbpJcXV3dXEkcFtbQRyTTzSJFEjOyqf9Jv9nr4XRfB L4EfBz4QRyee3w1+GngvwXdXXmtP9s1Dw/4fsNO1O+8xsA/btRgurzbGkUCef5dvDBAscKdvgtRr PMs7xCv9XhgsNRqPo61WvKdHybUKNf0T89flP2smaZXT4E8I8lqODzvGcW59mmDj7rqRyvLcnoYT M2/tRhUxea5SltGpKm93TfL7FRRRX9Cn+HR/CP8A8HqX7c6eHvhz+zn/AME8vCGqGPV/iDqY/aR+ M0FvLGskfgnwvc6x4S+E2g3apK7y2XiPxivjPxJd280EDQXvw98OXMM0yXEsafjp/wAGn/8AwTBj /bK/bZm/as+KXho6n+z/APsXXmjeK7SHU7K2uNC8b/tBaiJrn4Y+GnivB/p9v4GS2ufihq/2FZxp uraL4EsdYRLDxRDFd/01/wDBVD/g1f0z/gpj+2V8Qv2wJ/29fGXwp1L4iReDLK88Ba58BtI+Kmme G9I8HeD9C8JWui+EtZs/ix8L5dO0yb+x59Wjiv8AS9VlgvtUvHuJr+V5Lib98f8AgnH+wJ8Hv+Ca H7Jnw7/ZO+C8t/q2h+EDqet+KfGutW9vbeIviP8AEDxJcLeeKfHGvw2jPb291qUyW2n6bp0Ms8Wh +HNK0PQIbm5g0qO4kAPuev8AGa/4L2/t5v8A8FC/+CnP7Qfxb0HxBPrvwg+H+sj4E/AQi5iutJT4 XfCy5vdHj13QJISQ2j/EXxnL4v8AijZtNm6WLxslvOIhbR20H+wt8bvhzd/GH4L/ABd+Elh4y1/4 c33xS+GHj74c2XxC8KC2bxR4Eu/G/hTVvDNv4y8Nreq9m2v+F5tTTW9HF2j2x1GxthOrRbwf41f2 ev8Agyl+BXww+PHgX4kfGT9tLxF8efhN4N8YaN4o1H4JH9nvSvAQ8c2OiXseox+EfF3jaT4xeNor jw5rE9vBZeJYdN8G6bd6losl/p9nd6VcXcWoWgB9tf8ABqf/AMEvV/Yp/Ygj/ae+JuhRWv7Qv7aW m+H/AB0VvbJI9V8CfANLYah8LfB6tc2cd/YX3iyO+n+I/imGK5S3u49Y8G6Vf2Ueo+EDNL9+/wDB fz9v6+/4J0/8Ey/jb8XPCOqnSfjF8RzYfAL4F3kUjQ3Nh8SPiZZ6rHN4kspo7m3ng1HwL4D0jxt4 80iaITr/AG14Z0yC4ga2uJXT9noooreKKCCKOGCGNIoYYkWOKKKNQkcUUaBUjjjRQiIgCqoCqAAB X5Ff8Fm/+CSfhH/gsJ+zT4R+AniD4ya78CNe+HvxS0z4q+DPH+keD7L4g2EGqWvh3xF4U1HSPEfg u78Q+EJNb0nUdG8TXkkJ0/xb4ev7DVrPTbwXl1Yx32lagAf4zmgxaVqniXRofFWr3elaHqOuadF4 k1+K1l1a+03Sru/hTWNXisQ6zand2dnJcXqWokWW9mjEIcPJur/RO1b9rMf8FUfAHwR/4JGf8EV/ 2RPCHxV/YL/Z+1P4CWfx0/ay/a5+F/iSy/Z8h8J/BfxT4X8ZWng+Hwncad4Z1+68QeOZtBs9Q8VT 38ugfFf4gW+reNrPRPB/h3T7u/8AiPa/QH7K/wDwZkfsAfCTxFYeJ/2l/jL8Zv2sX014pF8EiOy+ Bvw01Vgn73+39O8GarrnxGukEwSW1i0j4qaDEih4b9NTjfC/uv8Atw/HH4G/8EhP+Cafxz+L3wt+ H/w++FPgv4DfDDUbP4N/DLwX4c0Xwn4Su/ij4nkh8LfC7w5aaBo1lBatFrfxA1rQ5PEl5DY3l4ul f214g1CO7W0vJCAf5OP/AAWB+JH7RXjv/gob+0r4d/aY8d+AvGnjf4KfETxB8CdDsPg9avo3wN+H vgX4W6lc+GPCfw4+CnhHCJ4L+HvhLTLSPTrDw7Kj6zb6gmpXPiq+1fxZda5rF/4z/wAE8f2Stc/b p/bZ/Zs/ZS0UXsUHxh+KPh/Q/FuqaeP9K8OfDjT5m1/4neK4naGeKOTwv8PtJ8Sa7C1xH5Dz2EUU rKsm4fJPiDxBrnizXtb8U+JtW1DX/EniXV9S8QeIdd1e7mv9V1rXNZvZtR1bVtTvrl5Li91DUr+5 uLy9u55HmuLmaWaV2d2Y/wBcv/Br5/wS0+Nn7U+gftY/tWeBPiZYfBW20XQj+y/4H8X6t4N1LxC3 iC78eadbeIvjTZeHdWs9c0VvC+paZ4NXwX4W1HWLa2165n8OfE3xBp0Ntp1y0V6efF1qtDDV61DD VMZWpUpzpYWlOlTqYipGLcaUZ1pwpQc5WXNOSUVd6tWft8NZZl2c8QZNlOb59guFsrzDMcLhMx4j zLDY/GYHJcHWqxjiMxxGEyvDYvMMVDC0nKosPhaE6taSjT5qcZSqw/V//grr+1t4Z+P3xu0H4P8A whktrb9n79mLSZ/hp4BsdKiW30TUNc08WmkeJta0pYpZI7rQ7WLQ9J8MeFpxm3fRtC/tPT9sGtyt L+Slf0baP/wbm/GafUJYtf8A2j/hjpmlLPtgvdH8JeKtc1CS1zN++l0y9n8PW0M+1bc/Zk1eePMs w+1YgRrj9Mv2WP8Agh5+yp8ANW0fxn8RLzW/2iPHujT217Yz+NbKz0T4d6fqVm8jw6hYfDiwn1CO 9kJkBktPGfiPxlpiyQW1xa2NrdQmd/5sr8B8ccUZzicxzPB08veNrupWxGLxNB06FNWhCjSo0atf EzjRoxjSox9mouMIqdWN3M/30yf6Zf0QPo8eFXD/AAN4f8V47jenwpk1PA5XknDeQ5tDH5vjantM Ti8yzHNM1y/KcjwtfNMzxFfMM1qvGyr0q2KxEsPgK7pxw7/M3/gix/wTW1/xd4y8N/tg/HLwxNpv w/8ACktprvwR8M67ZSwXXjbxVE8V3o/xHa1maKSPwr4YdI9R8LXEtu0fiLXmsdYsZRpmiK2r/wBa VMjjjhjjiijSKKJFjiijVUjjjRQqRxooCoiKAqqoCqoAAAAFPr954Y4bwXC+V08uwbdSTk62LxU4 qNXFYmSSlVlFNqEIxioUqSlJU6cUnKc3OpP/ABi+kJ498W/SJ8Q8Zx1xRGngMPChHLOHOHcLWqVs Bw5kdCpUqUMBQq1I05YrE1atWri8yzCdKlPHY2tUnCjhsJDCYLClFFFfRH4aFFFFABRRRQAUV5L8 cvjv8HP2aPhd4r+NXx9+JHhT4T/CrwRZJfeJ/HHjPVIdJ0XTIppo7W0txJJunvdS1K8mgsNJ0fTo LvVtX1G4t9O0uyu724hgk+IP2Ov+Cy3/AATN/b8+I+qfCH9k79q3wn8T/idpWl3mtN4HvvCHxQ+G niHVtK03Lane+FbD4s+BvAsnjOLTIQbzU/8AhEf7bfTtPVtRvVgsFa4AB+nNfwSf8Ht/7Veoaf4b /Yz/AGKNA1uKKz8SX/jT9pP4oaJFMUvpoPD6p8Ofg7NOkNyrPpF1e6p8Y5Zbe8tnt7nU9E0y5tpD caVJ5f8Ae3X+RZ/wdN/tFx/tB/8ABZP4/wCnadqj6t4c/Z68MfDn9nTw9KWRo7OTwZoLeKfHGlwB HcImmfFXx14/tJVJVzdRXDsiM5UAH88dnZ3eo3lrp+n2tzfX99cwWdlY2cEt1eXl3dSrBbWtrbQK 81xc3EzpDBBCjyyyuscas7AH/a7/AOCPP7DFr/wTq/4J2/s4fsxXNvAnjvQvCTeM/jFfRrbNLqPx i+Il1L4u8fRy3VqkaahbeG9T1NfBGg3rhpn8L+FtCilkkeEyN/nQ/wDBrP8A8E2L39t7/gof4a+N vjbQJ7v9n39iq80D4zeLr25gb+yvEXxctb97j4H+AVmOUnnPinTJviLrFpJBdWFz4c8Aahoeqi3/ AOEk077R/rJUAFFFFABRRRQAUUUUAFFFFABRRRQB/Ix/weT/AAT+NvxP/wCCbXwx8d/DaHWdb+HX wM/aG0jx18bvDOj20919k8O6v4M8VeDvDfxG1RIAzf2N4L17XP7DvmKuloPHkeqXCx2Wm3d1bfwL f8EbfFWv+Df+CsX/AATh1nw3rr+Hb+4/bS/Z08N3mopey6f5vhrxp8UfDfg3xjo8lxC8bGDxH4R1 7W/D1xau3kX8GqSWNyr29zKjf7Y19Y2Wp2V5pupWdrqGnaha3Fjf2F9bxXdlfWV3E8F1Z3lrOkkF za3MEkkNxbzRvFNE7xyIyMyn+Lf/AILP/wDBGH/gmP8ADXxl4B+I3w2/ZP8ACfw58T/EPVNa1LxS Ph94w+KXgjw1Ne2gSS3l0bwL4X8daV4G8JrHKPN8nwn4c0OBpiZniaVmcgH9I3/BTP8A4KQfAL/g mJ+y/wCN/wBoL40eJtHj1230fVbD4QfDFr+FfFnxg+JTWMp8O+D/AA3pKTLqNxZSai1rP4q12GJr Dwp4dW+1vUpo47eKOf8AyKP2Uf2Mv22P+CwP7W3iLQ/hD4T1f4lfFL4t/EHXPiL8avi3rVrcaZ8P PA13488TXev+M/iX8UvFVpYy6d4d0t9T1XUtVNhZ291r2vXTf2L4P8P65rlzYaTcf2B/8E9v+CUP 7B37XH7U+j6R+0v8HvE3xrsNN8M6rfWcXj74+ftGa1LHJpFtdajYW8l3J8WkvLjTY7yNZZdIuZ5t Ku1aWG8sriCaaN/7g/gj8Afgh+zV4B0z4Wfs+/Cb4ffBn4d6QTJY+Dvhv4U0fwloa3LRRQzahc2e j2lqt/qt2kEP27V783Wp37xrLe3c8uXIB82f8E3P+CfnwY/4JmfsmfDv9lf4LwG9svDcMmueP/Hd 7ZQWfiD4qfFDWoLU+MPiF4hSF5jFcarcWtvYaLpbXV6nhvwnpfh/wvbXl1aaLBPJ94UUUAFFFFAB RRRQAUUUUAf/2QBuHvAwEQAAK9gS7wUbD+3pLrJxxgMnl/+JUE5HDQoaCgAAAA1JSERSAAAAgAAA AIAIAwAAAPTgkfkAAAAEZ0FNQQAAsYiVmPSmAAADAFBMVEUAAAAAAAgAABAACAAACCEACCkAEAgA EBAAECkAEDEAEEIAGBAAGEoAGFIAGFoAIRAAIRgAISEAIWsAIXsAKYwAMSEAMTEAMZQAMZwAMaUA Oa0AObUAOb0AQikAQkIAQr0ASikAUlIAWjEAWjkAY2MAa0IAc0IAc3MAe3sAhFIAhIQAjFIAlFoA pWMArWsAtWsAvXMAznsAzoQA1oQA3oQA54wA75QA95wA/5wIAAAIAAgIABgICAAICAgICBAIEAAI GBAIISEIMSEIMTkQAAAQCAAQCBAQEBAQGAAQGBAQIQAYAAAYCAAYEBAYGAgYGBgYGCEYITEYKQAY OTkhAAAhCAghGAAhGBAhGBghIQAhISEhMTEhQmMpECkpGAgpIQgpKSkpKTEpSmsxAAAxGAAxGBgx IRAxISExISkxKSkxMRAxMTExMTkxMUIxQjkxQkIxQlIxUgAxY4w5AAA5IRg5MQA5MSE5OTE5OUI5 Sko5a5xCAABCAABCKRBCKSlCMQBCMTFCQhhCQilCQkJCQlJCe7VKKUpKShhKSjFKSkpSAABSKVJS MRhSOTlSSmNSUlJSUlpSUmtaAABaMQBaMVpaOTlaQiFaWiFaWlpaWmtjQiFjQkJjY0JjY2NjY3tr AAhrOQBrOWtrQgBrQiFrSkprayFraylra2tra4RzAAhzSkpzc0pzc4x7ABB7Qnt7SgB7Uil7UlJ7 Wlp7eyl7e1p7e3t7e5R7e5yEUgCEUimEWlqEhFqEhJyE1gCMABCMUgCMY2OMjDGMjIyMjK2UABCU UpSUYzGUY2OUlJSUlLWcYzGca2ucnDmcnJycnL2lABClazGlc3OlpTmlpXOlpcatABitY62tra2t rda1ezm1e3u1tUK1tee9ABi9a729hEK9hIS9vYS9vb29ve/GABjGa8bGjIzGxkLGxsbOzkrOzozO zs7OzvfWABjWlJTW1krW1tbee97nnJzn51Ln55zn5+fvhO/vpaX391r396X3963/////jP//ra3/ tbX///+ZKCtDAAAACXBIWXMAAA7DAAAOwwHHb6hkAAANtUlEQVR4nM2bD3xTVxXHL5HShf5Z05T0 LwlZQ+higWJLaZTopu3qTFkmZmvWuS5bHVTi1Nlp0LSKdhukFqJxjDBs42SSgWQCLmyMWbcSt2zY ZVXiA7ZsWDLt1gQjUjup5Hnfe2ma5CXv3awh8wfty6efNuf7zj3n3HPvuwE4uibHsPHgZAp/gCKA bN2lkyuVjXLQrHeMfQQAIwqlwUzJ0KFsdaTNEWgAwV5lnzlaXUrLRAYBgs0d5ngZGk1p8QISgJ5u H0rdbAxmBmBCnsg+4QV5ZgBsCR1ACDmH5gagNxgSGO+Gg2DLCEBQ3ZXIBXJ1o2Pu9lEA9AalMgFA 45Y0DAAKAKbu6AbdXfQkOLcxDUmAANBmUBvk6niAbnPXkVfSUYtYAYLA3GFQqmn3b+g6MpqRGMDU 5r5EAN3qI6M67fTVB4BFoK9P3dcdD9AhP3d4xObKAAA9/Mx98tvkjWAUjNjmPggfCkD5ylQr0GgU A0bt1Qdw0QEMmpNTmp2h0BFsIAMecNHiz6w8+3zo4hUIYFHMvRKwAozTAcDZkyFCR5pH5myfHWAa 0AEOP08CbM9MJdTTpsIZAEUa7KPMBfEzkQE8OUXYP6fPDMC0ti/OPthOOuDw3KsQEgBRjKPU3QjA xlcIF2zMWFOqN8zWgq4OJeg8p7kAR2AgHfaRACZb1dAJBnOHWW3uVoPWi6FO6ICd6cgBxLZ8UquU dzV2yc1wBmjqJO4+FJpKSwiirowm9XJASt5y4CIZgaHn0xKC6GtDTEUCtF4gjBMh2Dn3ViAlAFiT B1pHqbu/uCc0tTMNHXmKAPjEHsr5oRebNOvSZT8VgJHDU+HhT+c2BTLAsPGz1+YoNh44dyU0iqXN PDrAQPWaBqja6iU3P7glDbNwqgCuBdLKxQVLllRKq5dXgjQ0wykCYAsqV6ysra1duVwqXbKoAOjS R4AEgBXUNUSr/vqc9EwEiAATBfUNcVqz2JJBAMtK0uj1q6MJFg1nDCC4iLJ5fewwFNB2C4PRmsAw bCIYZA0WBADjCtLiqk/EjkKNKroauXiCGQlJCYRiMXERCG5mLBsILRmgIqA6Pg6kpmhKiUwiEZM2 SfGgfVLLJICnZdhaRWhKF1P2ltfVxALUg6iW5EZZzq2bdwwOvnCC0tHBQeNDUG3QCTIxwwqOHcAh pcytlMbngnR2RhoXSBTn/YRO7TAODu4+4Q9rUCKQyKoYmhd2gHAI1KyWxo9B/Q2REHNIhLvDFo3D LpfjhRmAb1blyGRChoxhB1DVUiFQszweoKEy8sa6qpzTlMXTJw4e3Wx8agbgc2KBTJbDMHmyA4Da 8BCspgGsagv/ziSv6h7/rE7pNp84cYp49bqQGIHvMr09OwBVhtesoNlvaFgUzrARofipWfunb3r0 aahHb3rIv3tZtkwmZlrEI3uAnoZQq79O/Y5FwnsrCuCu/5J6d9D/pWU8mYzHtJvGDqClAOKTMOwC 6r0VMi1p+tUTr5+fBXji9CmhWCiT3ch4f6wAvZTlmvpEBNXknDSeIx70+0/85Od/Pv5rveqnu5+g ADqpJJSYmN6eHcBC+b6mblUk9iojAPULiEx0CHmn/c8ev3z5/UuX3v/r+9uepgB2+O8kk5BxBcEO MEzl/4qoIJReF3m5lGjPesX3+9+65dJlSHD5P5cvX/rRPwn7bx89LSCTkHENxw4wNlOKo9JwSaQm 1BD+vUF80H8UfGY90Gzb9gzULe+SIXDqoFAglklUjG/PDjC5IGxrZVT0L4jQ3AmnYYHglL/58w88 8MDvSAFqCDrPb5bwqmRC5uYJYTrWhY1Ft2Ufj4TB0iA+LL7R798Nfvn723/w7TvWr1//BRLg7c3+ G2REEjI38QgAw7GdCKWCmZC8DsM3izcTAPK1TV/52S9+89xzLW8TAD9+9VWeRChbBpgXMQwAkwMD ZJZP5iQAWLV4JhyM0zzBQf/5r+lcDofNZNSqwCP/JgDu8u8QwxAQsyzjGQAGrEMdbXqHC9NVr6iB PXkswWIyK9asAAqbMOce7f2a49v0ehNUr4oKgVv9bcuyq2QClmU8A4DcPhQIOK0Gg6FLrVaHNwgA +FhBweIlldU1oKZ2ZWUOOPAiEKx97yUAmvTb9Jptx5/ZpnnkD9D+X+55NrsKhkA2yzIyOUBQHXCb rXan0+sLhOUl5XEO2c1qaSUAnQdOXghd+f66W/70wb57HxY9/L1v3Qv1ZcUdd3zn7l0v7RKIYRL2 MttnAJhuJI36nFar1W7ostoDHivx0gnlDQwVNNRoroTX66PrNr330m8J7du69W7wxw9I/VAM6zBz GWQEwNsid06TzxpQ1zUsPRsGCE3tBPs+mNG/wte15EzItpXFAGAbSgoQsAfM1Q2rDoQiOrtu0z+g 0Td3bd20rmkr8fLv2RCg6k4W+0wAWEdyALfbvrShvnVqlmDqSfCrf+3aODp14cL27ffBUdgHFwgy MesakqkQNTONgROulyr3hKJ0TgM0YaIpxZsfbJLwJDIB61YCE4CJYQz2+wCcjK/dcyUaYYqyf7Zz anTtJkUV7MZYyiALgMuQHMAZkMMpYjnYOBqDQOYEAHsuZEvEEp5MomOzzwgwKWcIgoAazo6L6hYA sOXk36JiIfQkUa06gVDCE7KWQRYAXOdmiEIDrMW1DQXh+rhOs2V7685zF17UgIiyBewjwAzgsCaP QruZnCSlPLgSBeQyVCIR8gDI4Ql5PHKFDEZcCA/VGAHGGRLRbidbtTrYc8lgtCUQQNpIYgSYBMkB hpxLSIAcAkBCmVwmWRYNgGKfpSFRzQZBfDgMea+FjdHKOgAdDrIJzY49qW+gPdRkBjDZIwbjw8EZ APXS6oY6kMUnVVQCVSYSEZcSfj6X05sOgKhKEF8VnYHGRTAPVgCOKKEqijlI5xuYAcaVSWPAE+hY CjuiAsApS0wg4iJtKTMDTINk04HbEzBIG9YszuJwSsorrhoArncmA/AGrNKaHG4hH4iKSuJtl6cN wGZOBgDDEnCLy+aXzRcVx3ugOJf4npWGGMAxdRIAb8Br54gquMX5+XTn5xYTXmhGsc8GkLQUQQAn p3whv5xDDwA+l/hehLafzVautB7SHi0WPQRAcbmITxt/UQmnPB8GQR7aYw02AFs4Cn0xpdAHO3SP G1aAcj7NfjG3mEv8FK0MsAKM9c3ccSwAnI+9IFHyFeWWcAoJPzCvypEBpm+bGXN39DB4A84+Nw2g ophfmFc0v4h4nY/4YI91ytL5wmnniy4JnoDTHOOB8qK8+RygVCvnZZFFQJSF+GiNFcBhJy06yf/R HrAGQGnYOD+XozZY4XoJyv4pEqBMgfhYif0sGdmUeL3ugCcKwB2wUwDFhfzceYahyI8DHjk5N+Qb 0eyzA1CVwO2zx2ShnQBQk7O/2hoODp/d7oaLyPnUCKA+XEfYJyTv3BkLYA4MQQCnVW0O+8U3ZHfC MPHa3WQVqkBoR1EBMLPX7nSbnTEtkR0umgPqrjAVHCA3ERcer8f+SbIyFLEvCJABiKbE47Rb7dEE Tq9nf6Q8+qgvT8CuVA1Q/Uk+8iEzhCcmTh9pyeeGXvZRryFAXJPoCXjMjdx5k9NUbmaNpxFgPxV1 kZsfcjqdBmdUUkAoZ5+cm8Unyq+WyM1SxDKIBOC6rctKVkGvOwZkPzX8MAOHDIDDr6jgFIsWYriR qIN89PMNCM37mEqvAMqOPruHGmuflfD4TF3yGkBWYYmoNG/+PJGo0IUPwImgKA/9hAECwIQRNw1j DoexDTR29FnJkHATvhiCcW8AeaWwKeFy+UQXAO/ckScqL8xCP2GBAmDDTeE7CmIOixY0dlmHiN0y u+G+gRFotqyoqKIcrgXgFGiBABW55V9Eto8CMO7CdTEuDWLDNgWA/4ZhlbgmNz8/P5ebV1qYLyot 68VHuNyiMsZHFCkDjGC4lrbXZQrioBe2HA5+GbEUgm4g1wdt+Bjgi/gpHDVFAHCM4220qY0EwOBM MdMSZRGdcBkHn4aVqDCFUy4oAEGcfnaSANDDaqNv//RCfmlpaRGnOL+Qz58/gbdViND6YWQASxCn P3w2YUGgCuLTLe+cOdbf0tLSlCsiFkgLR/DeklK27dkUAUzTSQCagzjW/w6l167hh+cAS3FRCjGI AgDvh77nTwJguO1QGODlte3zrsnn51twW14WMJqQPwmFAABvn35LDgigxXD9y2GAvXvfeePY4/09 etzVtPfMMQCa2lsASjIgAQQTAwAMV/S8RgFseIO8vKHCsR54PdS/F/qmH+GoDQIAwIP0WyEBYCa0 y1s2PAa1NuwJgI+3E9djJA7C2XcEgGZ8PBEATnRdJvmGnp4NPY/1gPZDZwibTcEgoFDO7O25vWmO +4SkJrU4lhiAuAbHXDaj0WJqP9TTBFpu71k7FgT9UBta2vt77rOx9+bsAEFGgJlfaidi4Myx13pG psHeQ4ce69+74atImcAOAGfj4YQAMfUO04GW9g09jz/owBUtrVqTzYV46hehKzbhDvohFAhAj7AJ LIhZcG1K5x0RAAYIazSAkQQAUEGVUZHSxy4QAByRfiQawJUYAG+26a4CAP0oVlIAhxYh9FMCcFkm dPSASgqQqhDWBc0q8JECTNtMFrpTMwiQWP8PAB/2T9MHkJazvR8WwKhqSxCaGQRw6W2qjH3IJZGm HaZ0fN4Sx/8H1sE8qeWajHQAAAAASUVORK5CYIIAbh7wqgoAAAXKxw/JlbzoOQLAAF9tmIP/iVBO Rw0KGgoAAAANSUhEUgAAAIAAAACACAMAAAD04JH5AAAABGdBTUEAALGIlZj0pgAAAwBQTFRFAAAA CAgIECk5GBgYGDkhIVp7KSkpMYy9OTEpOTk5OXtKQr3/Ur1rWlpac/+Ue2Nae3t7tZyEvb299861 ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdzDz0QAAAAlwSFlzAAAOwwAADsMBx2+oZAAABy9JREFU eJzFm4uWoyAMhqlKLfSCne77P+vKTQIhXNTO5Jzd7Xjq5CP5CRFZ9m+vLcsi2GrLsvtXaGN774vs twHs0KGJ3WHYA7Ck7o3tROgH+Mn730vQD0C430vQC/BD+9+nxd6bSv53EfTdQ6X/QBLOBdgRgr5b av6/DUD6/ahfAYAzQG1/rfb+fHaHoOcOqICPsfD5VwCQ/8/nrZR66w+7c3AQINgvALA/BoASvKXu 378AACWo9JDh2LcIdNfCdgCRAKgbU8oQmH++DwAlADSgYg38AQD7JQBGAqi/BfjEAGJxdhYAyxuc /xEAsGMAehCEc21qA0hKMWOT9J+aopAFKHjO5CAKwMtbKwEGCG23lPIBf18B4J36X21qIkAAm4tX ZAQAc39U7ibWooPkK4vN4uOVGgFws3rw/qfDADrwyHk9BVvS0nvqOYgBFhT6IwCvboCFDEAZQJ0F QPsvA7C/BQg1iCXinToBChlIATKjZ1g/8jwASQHAi1Pmrq8DQAJ0by9AQQOSyQm4urUowBTjswDS IOQA8C3sPIBHmgMFADj3OZDSf9187Ab4lx0HmgJ3GIMV4H6/ewQ7APDd4wBh6HxePc3m78E8EQMA zcBtJOSqllGIswDCsKHxkIMVLLpuDHRTxwDc8Ad+vzcB3E12xuXJ2FWIcTQwP/sBrP/Uu/VDAOgY CL2VK6zZgDQDLPE0mFziywDRN2aTgNH7F+I6XgwTFYhiP5AffQqQJsf00wLaWJBDCSCVXpxqCkAg /x4hm4kCgAS/e17nWBMAY89VAZcUYFMkgsA9YTYBPJmJFICbgtg/qUgM8AgJCPKaEwCeB+DrFFz9 jwTAGodLGoVUGds0kCi26VAzAHYK0v69HJYGgIkNicN4RrhirCAAtwm4FgH0zARTggSIHXI0I8Ha lPinFBCJYaEAFgeAI14HGNYEPNv8sx8agPk1CLrjqCb4n8N1MwNqCvAqIDVgAR64BtEAbq7MtgbW /YsLLIp5AImLME4Bj/6lamA2AYVZYJcjliwxGYAhAeC6Bj57E5AFYEgBcKDe+ObYg+BFiArAvwqA zKxC6EoCoNuQJgWmxTgHkPHPKwDcLPn9CSC3aDAAvgIB9k1BGmDL98wHewF1Jj4msy7Ztg0Z+xVA AWyJ94Y7Iw4qUbYNalIAAcC3sd/0O6F1wRkQwAwABq3AJdeG1BJAiNAPPnoCTgkCgBHAqoAdCcgD cNt/pI/ASYPsc2AbcdCJF/2LFoB79PAHn4GTvtCXINGmgBErIA9gxv/+xKZuTo8Ddza4j6tWxLPe hphFCDfG2RTkXssFMRC2SwEYwL6cUwSAjoQ273T9eAsI5TJ0zSWArIQ0QD4owvXcFQVg/5nterEN rhAHbzczBZxj++wxEoHIKiAHUMpzkh7F0Awgk5FPQF4Dk0x3hBCEflGjK+Qo7JGyMYzbxoFdxmuL f6opjTZH9Ee0OhhboldLSRjgFUIACEC/rol2+yb7nAAL8bxtiomnO1E3mj0AZgNxHWPI9dpVCwDV wBzAktsjkjGAL79h+GGQJcv7R1s0wPGWBwQQh3/EoYcBKPtPNyol3JsyP+kd2hjA1F7zhnRkieB1 sdGL1uCWMjNNVlnSEkgBNv9+7DYWEMAEffHnKXGxucO1TLlvtAH8OIDJClE/Hj0MAXhU5979U+ip FrnX8tOdy8CiVqIdwEcgEYIMAEF8Cx6+sMOP13L3tS6AoMSHkYFRhI/+uEV/TNbfq+sP9GL+jgCs ZpsBJNgqNCGAAEtG+9vwt2e03PsMwj/artdewV6lVkEK4JM/jqEAX8J+LotPF7gyRW6WZt4XxAAy TgH5Uh/MEhUD0OsAAnCFgMUA4VmVE85h287ibm798cJK29VZAEYAhMUoLopJmUj7lYL7FEAYgAc8 NmAB3Ahnlj6jaAewX59j/7oU9mzXo8XIA2y7IHinBm1WJwBF900AMpph97Lx+JzZ7VQAzuj9+xCR qJOsKaAfoOL/KICgAFoDcBSAlQBYQwCOA6AjCBvA3BaA7wG0KODbAFX/M0OHO4hmeAdASwA4BqiF oAHg5QHwRlETQDkGPQBVCSKASjOSA3ilAA+3dc3w/nUTgKosB5mOKAZ4ucWoRQJZgE/Hu2MaYGgG gP6V6U6OAxgR7AX4HAOYtjdILXXwCwDS9WgmBN0AVhE95wfQNJTbAyoDByk4sAKAOg2gvGNDArDT ANBZOoogAlBuZToE8HAXpqznyZ3v2hKBAN6dALktmlfZJIwCAvhUV+TiIRYzdvp0WYww2H3rdA50 A+ARVwkijaQAqhsAnylusMe2twkBbp/6owk+wtEw4GIgooWoJsEcQE11JZMBQG0ZKPrPnKA4QhAD NEjwbIBXALAKuFWPFmdfXp8DoFoCkH9jsp/AA4Qi1A1gX1gcBFChCNWONpOvbE6y6tHq3Iu0M63m P/ufXE70Xz9b/h+34EGt5rDVyQAAAABJRU5ErkJgggBuHvAYAQAASGM3rl515M6DXOsjAzNt3f+J UE5HDQoaCgAAAA1JSERSAAAAHgAAABAEAwAAAPMU0uEAAAAYUExURf/MABAAAP8AAJiYmP/NAP7L AP7+AP///yu9SYQAAAAIdFJOU/////////8A3oO9WQAAAAFiS0dEBxZhiOsAAAAMY21QUEpDbXAw NzEyAAAAB09tt6UAAABxSURBVBjTYygXhAHxciBgKGQNhYJEMF+AAQbYxMF8JgYmKF8YwlfA5Csx KDAwqEH5QMCggMpXUgASMPUMSkAD0PgKQB1siUALGUScGEDmgfhpQAFk94DcjMwXNjYGut8FBhzN QeYh/CcM4RcbwwDIfwCAqCZWOXu7ywAAAABJRU5ErkJggqBGHfDKFgAAMqKiwjSyMQY57tpNP6EI kv//2P/gABBKRklGAAEBAQBgAGAAAP/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8e HRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/AABEIADgBSAMB IgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUE BAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1 Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOk paanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAf AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQF ITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdI SUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1 tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APf6 KztD1m31/TBf2qSpEZZYsSgA5jkaM9CeMqce1R6Jr9rrx1L7LHKn9n30ljL5gAy6YyRgnjmq5Xr5 AN8V3txpvg7W760k8u5trCeaJ8A7XWNiDg8HkDrXzN/wtzx7/wBDDJ/4Cwf/ABFe/eKtcttR8L+O NMiSVZtN02ZJmYDaxeBmG3n09cV8vXuiXNjoelatK8Rg1PzvJVSdy+W+xt3GOvTGa9LA04NPnX9W uZzb6HRN8XfHoUn/AISF+n/PrB/8RX1Rp0rz6ZaSytukeFGY4xklQTXxnLotynhZNeLxfZZLtrMJ k794TfnGMYx719k6T/yBrH/r3j/9BFTj4wio8ituOF+p8x33xZ8dRajdRx+IHVEndVH2WDgBiB/B 7VX/AOFuePf+hhk/8BYP/iKxG0ifUrnxDdwvGsenF7iUOTllMuzC4HXLDriqdhpU2o22pTxPGq2F t9plDk5Zd6pgcdcuP1rvVKjb4V9xF2fXXgzULrVPBWj6hfTebcz2iSSyEBdzEcnAAA/CqOr+LWjZ odLjWVhwZ3zt/Ad/r/Oue0C+lufAnh/RrWRUb+y0nuCT/CFBCj6/4etWLK0+0zRW8ewM/ALdOma8 f2aUm2aXMLUtZ1+Yln1S5X2jbyx+S4rnpPF3ifTJN9vrNycfwy4lU/gwP6c1193afaJooE2h5XEa k9AScCuJ161Ntd3Fu+0tFI0bY6ZBI/pXVT5Xo0Szu/Bfxbg1jUE0nXY4LK8k+WCdWIimb+7g/db0 ycHp1wD5745+JnjLSfHGs6fY628Npb3BSKMW8LbVwOMlCe9cj4x0mXRtUutNuXjeWBgrGPO05APG fqKwZp77WL6W4mM93dPhpH2l2bAAycfQc10U8NSUudLRicnsdZ/wtzx7/wBDFJ/4Cwf/ABFH/C3P Hv8A0MMn/gLB/wDEVyLWN4iF3s7lVUZLNCwAH1xUFdHsaX8q+4m7O1/4W549/wChhf8A8BYP/iKP +FuePf8AoYZP/AWD/wCIriqsf2fff8+N1/35b/Cj2NL+VfcF2ex/Cn4geKvEXjqHTtW1drm0a3lc xmCJckAY5VQf1r2zV9XsNB0ufUtTuFt7SBdzu36ADqSegA5NfOnwTs7qH4kwPLazxp9lmG542UdB 3IrY/aC1ueXXNN0JXxawwC7dQfvSMWUZ+gU4/wB8151ahGeIUI6Kxado3G+JPj7qlzNJD4dsYrO3 HC3FyPMlb3C/dX6HdXDXXxK8a3km+XxLfA/9MSsQ/JABXLVseGPDOo+Ltbj0rTFj85lLs8rbUjQd WJ5PcDgHrXeqFGnG9kTdsmXxv4rRty+JNVB9ftb/AONX7T4oeN7I/uvEd23/AF2VJf8A0NTXar+z 1rJQF9esFbHIELkD8eKzL/4D+LrWMvbS6de/7EcxRv8Ax4AfrWftcLLTT7gtI6HUPiL4of4NWGvx 6gsGpyaobZ5o4E+aMK/G1gR2HIA6Vwn/AAtzx7/0MMn/AICwf/EV0PiPRtS0D4EWGn6raPa3Sa4S Y3IPBWTBBBII+leU0UKVKSb5U9WDbO1/4W549/6GGT/wFg/+Io/4W749/wChhf8A8BYP/iK5/wAN 6Dc+KPENpotnLDFcXRcI8xIQbUZznAJ6Ke1dJ4p+E3ibwppr6jcra3VlFjzZbWQnywTjJDAHHuM1 co4eMuVpX9AvIt6Z8bfGljMGuru31GPvHcW6Jx7GML+ua9x8CfEXSvHVo4t1a11CFd09nI2So/vK 2BuXPGeD6gZGfkqtPw/r194Z1y21bTnC3MBOAwyrAjBUjuCDWdfB05x91WYKTR9JfEL4p6d4KzY2 8a32sMuRbhsLCD0aQ9vUKOT7A5r5/wBc+IHirxDKzX2tXKxnpBbt5MYHphcZ/HJrn7m5nvbua6up nmuJnMksrnLOx6k0yOOSaVIoo3kkc7VRFJZj6ADrV0cLCktrvuDk2KssiSiVJHWQHIdWIYH1z1rs fDnxU8WeHJk26jJf2o+9bXrGQEezH5l/A49jWZN4D8W29k15N4c1JIFXczGE5A9SvUflXPVq1TqK zsxao+orX4lWfif4fa1qmjytZ6rZWUkj274Z4HCkhhkYZcjg4+oHSvEv+Fu+Pf8AoYZP/AWD/wCI rkrS9ubCWSS1maJpInhfb/Ejjayn1BBpI7K7ljDx2lw6HoyxMQfxArGnhadNu6uvMbk2dd/wtzx7 /wBDDJ/4Cwf/ABFH/C3PHv8A0MUn/gLB/wDEVx0tvPb486CWLd08xCufpmo619jS/lX3Cuztf+Fu ePf+hhk/8BYP/iKP+FuePf8AoYpP/AWD/wCIrjYoZp2KwxSSsBkiNCxA9eKm/s++/wCfG6/78N/h R7Gl/KvuC7PsbwveXGoeEdFvbuTzLm4sIJZXwBudo1JOBwMknpRUPgxWTwL4fVlKsNNtgQRgg+Ut FfPT+Jm6M74a/wDImJ/1+3v/AKUy1V+G/Xxd/wBjJef+yVa+Gv8AyJkf/X7e/wDpTLVX4b9fF3/Y yXn/ALJW0vt+v6i7GLqH3fi1/wBeQ/8ASM1434i/5Jt4H+l//wClFey6j934tf8AXkP/AEjNeNeI v+SbeB/pf/8ApRXdht16r/0kiWwk4z8G7Qf9R+T/ANECuk0n4jeLP+Ff63ef2u3n2VxZQ27+TH8i NvDDG3nO0dfSubm/5I5Z/wDYfk/9ECodJZf+FZeKOR/x+2Hf3lrolCMou66/qTcf4YkebQfG0sh3 O+mqzH1JuEJqv4X/AOQP4u/7Ax/9KIam8Kf8i34z/wCwWn/o+OofC/8AyB/F3/YGP/pRDVv7Xqv0 A9U+H0xSNYncsY9McEk+kYH+fpXTeG74SaxZpnksf5GuB8AXwku7nn/mF3Df+Q61vBeoCTxVpse7 70h7/wCya4KsNZFJmrBfCTW7Bc9buIf+PiuQ8WTj+3tSGel5KP8Ax81PpeoB/EelrnrfQDk/9NFr nvF14B4m1cZ6X84/8iNWlOFpg3oQfFhx/wAJ7rC/9Nl/9AWovg9qkmm/E/S1VysV2JLaUf3gVJUf 99KtQ/FaTPxJ1tfSZf8A0BarfC63e6+J+gInJFyZD9FRmP6CtZ2+rpeX6CW59M/EL/knfiH/ALB8 3/oJr4/HSvsD4hf8k78Q/wDXhN/6Ca+P+1Z5d8D9QnuNk/1bfQ19xWv/AB6Q/wDXNf5V8Oyf6tvo a+4bX/jzh/65r/KozL7Pz/QdMmr56/aB0ieHxJpusBP9GuLX7MWA6SIzNz9Q3H+6a+hayPE3hyw8 V6DcaRqCnyZgCHXG6Nh0ZSehH+I71xYer7KopMuSuj4xq3pmqX+jahHf6bdy2t1HnbLGcEZ6j3Hs a7nxF8F/FeiyyNZW66taDlZLY/vMe8Z5z/u5rhL3Tr7TZDHf2N1aOOq3ELRkfgwFe7GpCovddzGz R6Ppnx48WWe1b6Gw1BO5eIxOfxU4/wDHa77w/wDHnw/qUqQavaz6VIxx5pIlh/Fhgj8Rj3r5xorG eDoy6W9BqTPoz48Tw3Xw60+e3ljlhk1CJkkjYMrAxyYII4Ir5zrfXxLLJ4Bk8Mzszxx38d5bEknY Njq6c9BkqwA7lvWsCrw1J0ocj7hJ3dztfhF/yVXQv96b/wBESV7p8W9a02x+H+rWdxeQJdXUPlQQ FwXdiR0Xrx69BXyuCVOVJBHcHFISWbcxJb1JyairhlUqqo3sClZWCiilwdobBwTgHHFdRIlfSPwU 8GWmleGYPENxCr6lqCl0dxkxQ5woX03D5ie+QO1fN1fW/wAMNTg1T4caJLCwJht1t5FB5V4/lIPp 0z9CK4cwlJU0l1LhuddXgvx28GWll5HiiwhSEzzeTeogwGcglZMepwQT3yPeveq8q+PepQW3geDT 2ZTcXl2mxO+1MszfQHaP+BV52ElJVlYuWx8319IfAPUnuvA9zZOxIsrx1QE9FcB//Qi1fN9fQn7P ULr4Z1eYjCSXoVT64Rc/zr08el7FkQ3Mz9or73hz/t5/9p14dXuP7RX3vDn/AG8f+068OqsF/Aj/ AF1FPc9Y/Z+/5HjUP+wa3/oyOvo2vnL9n7/keNQ/7Brf+jI6+ja83H/xmaQ2CiiiuMo5zwNpt3pP hhLS+hMM4urqQoSD8rzyMp49VIP41B4I0m+0k+I/tsHlfa9cubqD5gd8TbdrcdM4NdVRVuo3fzFY 861rS7yz074m3txCUt72wLW77gd4W1ZW47YPrXgetapZ3Xgfwpp8Mwe6sRefaI8EbN825eehyOeK +ovHP/JP/En/AGC7r/0U1fHNengffTb6W/KxE9Dop9Ts2+GNvpImH25NXkuWiweIzCFDZ6deK+rN J0rTv7DtE+wWuySGNnXyVwxC8EjHPU18YP8AcP0r7a0n/kDWP/XvH/6CKnMFyqNu7CB8n6fqFnYw +NLaeURyXcDQ26YPzsLhWwMdOAfyqloF/bWem+I4riUI93pnkQDB+d/OibH5KT+FZupf8ha+/wCv iT/0I1V7V6CgrepFz1Wwgg8IjTtVupPJ0/V/D8gifaSBcGIApwOCTgj/AHj6VleCvEVppvi3TLu/ n8m1ikJkcgnaNpHQZr2jQ/DWneLPg/oulakhaKSxiZHTh4nA4ZT2I/XkdDXz74x8B674Iu2W/gaW xLYivoVJicds/wBxvY++MjmuKlUhUcoSeuxTTWpY0nXYbXxHpd1cS7IIb6GWRzztQSKWPHPQVleJ tVjv/E2rXNtJvt5r6eSN8EbkaRipx9CKwvMzTC3rwK6vdTuhHS/EDVLPWvHer6hp8wmtJ5Q0cgBG 4bVHQ89Qa9H/AGf/AAtJLqN54nuIiIYUNtakj7zn77D6DAz/ALR9K4r4f/DTU/HF6sjLLZ6OnMt4 yEb/APZjyMM3v0H6H6p0vS7LRdLt9N063W3tLdNkca9AP6knJJ7k152JqqMfZouK6mN8Qv8Aknfi H/rwm/8AQTXx+K+wPiF/yTvxD/14Tf8AoJr4/rfLvgfqTPcbJ/q2+hr7itf+POH/AK5r/Kvh2T/V t9DX3Da/8ecH/XNf5VGZfZ+f6Dpk1ef+NvilbeB/Etrpt7ps1xbT2wnM0Djep3spG04B6eor0Cvn P9oMgeNNNJ4/4l4/9GPXJhKcalTllsVJ2R6fYfGTwPfIC2rNauRylzA6Efjgj8jV+f4i+BZoSs+v 6bJGRyrNuB/DFfJFFeg8up30bI52dr8TdR8I6l4hil8JWqwxLGRcyRReVFI+RgomBjAzk4Gf1PFU VoaNoeqeIb5bLSLGa8nOMiNeFHTLN0Ue5NdkYqnC19F3J3ZRCMyM4UlVxuOOBnpTa9Z8Z+AU8DfC a3SeRJtTu9The6lT7q4jkwi+oGTz3JPsB5NSp1FUV47A1Y0/DmkDXvEmnaQZjALydYjKF3bM98ZG a9i/4Z1j/wChnk/8Ah/8XXl/w7/5KN4e/wCv1K+wK4cbXqU5pQdi4JNankOl/s/aFbTCTUtUvr4A 58tAsKn2OMn8iKd8X/A1ovw/tptEsY7dNFcyeTCmB5LACQ+5GFYk+hJr1ymuiSRtHIqujAhlYZBB 7EVwrFVOdSk72K5VY+HK6zwP8QNW8DXkjWYS4spyDPaSkhWI/iU/wtjjPfuDgY6H4l/Cm88M3U+q 6NA9xojkuUTLPaexHUp6N26H1PmQORkV7cZU68O6Zlqme/zftDaYLItBoN6bvHCSSII8+7DJx+Fe M+KPFGqeLtZfU9VlVpMbY40GEiT+6o9P1NY1HUgDkk4AHeppYenSd4oHJsOTwAST0A6mvrr4ceG3 8K+BtP06dAt2yme5x/z0c5IP0GF/4DXm/wAKPhPcQ3cHiPxHbmIxESWdlIPm3dpJB2x2Xrnk4xXu defjsQp/u47I0hG2p4X+0V97w5/28f8AtOvDq9x/aK+94c/7eP8A2nXh1duC/gR/rqRPc9Y/Z+/5 HjUP+wa3/oyOvo2vnL9n7/keNQ/7Brf+jI6+ja83H/xmaQ2CiiiuMoKKKKAIrm3hvLWW2uYklgmQ xyRuMq6kYII7gisD/hX/AIO/6FfSP/ARP8KKKpSktmAf8K+8Hf8AQr6R/wCAif4V0UaJFGscahUU BVUDAAHaiihyk92Bz7+AvCEkjO/hnSWdiSzG0Qkk9+lN/wCFf+Dv+hX0j/wET/Ciin7SfdhY3rW0 t7G0itbSGOC3iUJHFGoVUUdAAOgqSSOOaJopUV43BVlYZDD0IooqAOQ1D4U+B9SmM0/h62Vz1Nu7 wg/gjAU7Tfhb4J0mcTWvh62Mg5DTs0+D7bycUUVftJ2tdisjrlVUUKqhVUYAAwAKWiioGQ3Vrb31 rLa3UMc1vKpSSKRdyup6gg9RWD/wr/wd/wBCvpH/AICJ/hRRVKUlswD/AIV94O/6FfSP/ARP8K6N VCqFUAADAA7UUUnJvdgLUNzaW17F5V1bxTx/3JUDD8jRRSA529+HHg2/JM/hzTwxOS0UXlk/iuKz D8G/AR/5gRH0vJ//AIuiitFWqLaT+8VkWLT4T+BrKUSR+Hrd2HaeSSYfk7EfpXWWlna2EAgs7aG3 hHSOJAij8BRRSlOUvidx2IdU0fTdbtVttUsLe9gVxIsdxGHUMAQDg98E/nWR/wAK/wDB3/Qr6R/4 CJ/hRRSU5LRMCa08E+FrG7iurTw9pkFxEwaOWO2RWUjuCBxW9RRScm92AUUUUgCuH134SeD9emad 9NNncN1ksn8rP1X7v6UUVUJyg7xdgauc4v7PvhsShm1TVmTP3N8Y/XZXZeHPh14X8LSCfTtMQ3Q/ 5eZ2Mkg+hP3fwxRRWksRVmrSkKyOpooorEZm6r4e0bXfK/tbS7O+8nPl/aIVfZnGcZHGcD8qzf8A hX/g7/oV9I/8BE/wooqlOSVkwsXtL8L6Doly1xpWj2NlM6bGkt4FRiuQcEgdMgflWtRRSbb1YBRR RSA//9kAbh7wEgsAADdsb01sucA69ump+e0VAC//iVBORw0KGgoAAAANSUhEUgAAAIoAAAAwCAMA AAD5CBJFAAADAFBMVEX/1BbZpjaoUwH//PP/4U64czbDegFGSIzU1OT/1Tj/1QHdpgDsswD/zADR jQLit2Xi4u3jrQGTlb17fK7cq1TxvQDluDjx8fbSmDf+5JLktEejSQDz8/j+5oL/+7W0tdHYo1DE xNv+7b3/+uvMkDzXt4rHhSXTm0Xr1rqbnMGDhbLz1oSho8WXOgD/+uT+9uPkyqndnQD/0iL/9b// 9dr/85X//v2rrMv//fnd3uvt1afTlBn+3WS9dQK6u9X+89Lu7vT+4X1rbKPSlSr/8rz/+dO0fhr/ 66I+QYj/5WD+44n/8s3/8qvIl1fo6fH5xQApLHz/8qD+3XH/7pHNnGb/20Xrv0T/1StiZJ7ryXbI lyu5bAE6PYbu2rhzdan/7sL/+tvLzN+Ki7dSVJTkt1Z0dL7y5dTZuWzpwmjkmAf/+77/64v/7bXJ ggDGiDD2ymrRqGGyYAAOEWr+21sTFm3DjhbKoHT/3zatrdr/1UMYGnD52mzw4My8hkbruh737tTD fBXMlAD/6pm8iyr/6nry2ZP79e3v5dn7+/3+43fFjAH879S7ggIzNYH10lz+6JicQADEi1W2axvV ngDixJr/6oW1ZwHWrXD37uPPz+FbXZnjpgDVrH7+667/5qAhJHbsw1bVq4XwtwD4+futcgD/6W02 OIOyZA3Dh0dOUZLevZstMH0dIHR3eavOiABWWJZfYZyyss9xc6ePkLr/2E6sWxR+gLD+3n2/wNf7 1lauXAL/104IDGwnKXrWlQD/zwokJ3iGiLXr6/Ntb6Woqcmur82mp8hKTY/Y2ef7yxT/+MX//M/2 vQD1zz8vMn7aw6T8+veoawW1aAv01mL00mn29vn/7Gbv4bznrADPkj7+56vct08AAnL/7HDcphWO j7n/96T41HH22nzy0XP16dm2t9P1vwDlz7X62FTasXr06tDW1+bSpnTTp3j/8Me5cBDAfSwjK4Fl Z6Dzxy7sqi7tvSzn6PDl5e/cngrfvYD/5mvs2MFkZ6P/9q9iYq7///8nIhTHAAABAHRSTlP///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////8AU/cHJQAAAAFiS0dE/6UH8sUAAAAMY21QUEpDbXAwNzEy AAAAA0gAc7wAAAaLSURBVFhH7Zd/XMx3HMdPpWvpVFeEainROqcfNJVJ50LXD5yKju6RfliMZbyL 5jDJrzRHDOn8OFM7S79rThKVo5hYM/kxW7NZzTQ/Nr+G2Xuf712IftzXPHj4o9f37vv5fO7e3+/7 +Xm/35/7fo6Bb4wYbwwJdqK0lYvOqHRGhe4apV0rHh61zs5u3gHXp061e6ypo64HeHu7OfXT1R1K 12H7dlpRhnr0cwuYavf9jh07fH0DAx89ertNzZw580SEk67HSxB1gOLh7BYwavuO3pTW+QZeunRp QlLvgZeNjY3Nzfs6OFxwuGBvT172Fxwc+vY1Nzc2njxwRVIgISJI/4eoPRTn6769/dWaNSs4+N1g 68szzH0GbCjVsUwlGvS8UgeRI9Wy9MbNXuYzfvEPfjQk4oVx2kIZGrHdfx/RSOtNwZs2WY8806fX ht06qZaDUi0tdXR0SnVKS3dv6Gq/PiTkj20aXQsJWf/l4g171ZyWpacTu0z72TppiNML5asVivMo 331BC4OCglYvX7584c4uPgPCSCQIQ+nc0zdmj03rv9HlnUVb2knAypiHw1z2fD5/fde9cxN9evU5 kzQkgnZBP4sy1G3dcKK4Bw+++PHB/j4+p3XUDJvDwhLt52w8t5J+CdTGuFxbT/HsXBhIk6Ylisdo /7i4/XFXhvudHb6/Z5cbJBObw7y8vBJnp7n8Sp/iqWVtzJ6Qm4k+J1eP6kfj8hYodkFfER04oOen d+e9xLDSuWFe+vr6ve6f2/JCKX/e6ZaHv9v7TLIerRXmCYpH7wMLKE08S0DCNm8O09fPy+tuPEzr HegYLErzmbTOSYvlYxSnuLfUSki4Ve9FYcTmfXD7o0/p+KFnM2zaQO+Oo9uMorsglOhWaEJofax+ bGxeXkqezwp6PmhbLbHruGKaUfwGUwplDHbVj+2u1jRn4sOKh8gzIW8LKysrCx4P6yys6kjvrgVt APqGGpQPGcePD2YwGMf/zut+SK3JiB//KRYLCj3lp2zchQoBUXaWY7W6oxBWUpyHtbu5V/WsUWGJ tsfhxPLycla5YXl93iFX9UElR1AG8cDhAnAFoFF8fnMHOHiX9Ku1wuRC0xPfybaIEK0NZTCLyJDF IhSuW11dXddSF+SUEcdKM8g24P7DJF2RjGsjUkkAmCp+Bh4k41wSmse3Tm7Th0EVYh2xGUe+zVXw 8MgxRE1yKftn46pJ0JXG8ZR2bXXdSsl0CfnMhPiUQj4TmGQQRQYaZ9kAnqQJBzJHHJEdL7awYEqz +VkVxSiTKwqi4ysP59tiVnGhQlHBRlkVikFkUFShOMoGKD4cjUcl8mg0UeTIi5M5EmFLfg3K1R6U Gk3Pa3Sbem64A/xUDdlC+IsMSDbMNJMBkJDmnkREnUGWDrk2UKUCtiw+EkRKKKo+yJUYJAM7HEZI IQM4bOCOQ890scgWqtFRHgkqW4gqAUdlTi5EkVXxVM0raK2RUQ9To11Gap2/Q30fDpLIaKo2SBp4 pwDc1ReNAKCmEglsci4CHgoEIjFWSpAjdJdgIWkVuQL0hHRmOOE/fJArJRXepFJBpSe5QzSfTyaS JY5iYonQViwki7MVCk4yJSEx3VWzi5IR9QMgLBMiVSKUU1vSaOovlxSrOipScpblIEpU8mIUipCZ X8xEfjTKRLJoZOeMg0isKIiUewIX78Urj4GjI0lsTlV+BaldZZYS+QJyLRm0RtHt2Y3ItIbVWFPT 2OiPeOyHMgVWUCgNiGYApzTBzAEoolpHADk7PV4IwkhSNcQfmIn5GM9HSSUXpMBsgDoEtlJCZlPA kRyshoajUJAOTSUgAKEBmZ5QWlkN4rZQECd/RtSthsUaP76xZgLWvv9vAxb/Y1YURRaADb9Akx/k qFTp6s4RhXQElkiZvDplXUY4D5VN7HTkpGPlMVTlh9tGRmGG2b3CKjRhCgxKqs1IWcjMDJRWyM0u sLLim6BjA0de1FatUDdfeXHpoaUppixDQ9Z4w+9a8r6e/jNbp6tdUlLWrDE9nmDIMJx44vUAtK6V 5k/OTZ+yJnNe/SehCQkM64jXC9N6mx0zfUxm5pr6k3p6eqtfK0ybO/5zc8Z8mzmv51o/v1lf094l v3QI2/sfFOPSf+yyeVP67AyaMKTfS20oaSN29Ec1edU38xePWXZxxgq7CN3aVx6ejlDU86lb9du2 tPvDlrz60GhFoR3flzbsRGkrhJ1R6YwK3aXVWStveK38B1pihgx2orCVAAAAAElFTkSuQmCCAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A6ANzNwAAAQDpAygAAABgGAAA4BAAAOAQAABvFgAABQAA AAoAAAADAAAABAAAAAEAAgAAAAAADwAJBGwBAAAAAAoEBAAAAOwEAAAPAMwPjgAAAAAAzQ8IAAAA AAAAAAEAAAABAMMPGAAAAAEAAAAAAAAAjgAAAAAAAAAeAAAAAA8AABAAug8WAAAA0zDDMMgw3jDD MNcwIACkMOEw/DC4MCAAug8aAAAAUABhAGkAbgB0AC4AUABpAGMAdAB1AHIAZQAwALoPFgAAANMw wzDIMN4wwzDXMCAApDDhMPwwuDAPAMwPwgAAAAAAzQ8IAAAAAAAAAAEBAAABAMMPGAAAAAEAAAAA AAAA6AQAAAAAAABPAQAAAA8AABAAug8kAAAAUABoAG8AdABvACAARQBkAGkAdABvAHIAIABQAGgA bwB0AG8AIAC6DxYAAABNAFMAUABoAG8AdABvAEUAZAAuADMAMAC6D0AAAABNAGkAYwByAG8AcwBv AGYAdAAgAFAAaABvAHQAbwAgAEUAZABpAHQAbwByACAAMwAuADAAIABQAGgAbwB0AG8ADwDyA9wC AAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QcUAgAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAg AFIAbwBtAGEAbgAAAAi4EwDwtxMAFucHMAgAAAAAAAAACLgTAHpbCTAAuBMAAAAEEhAAtw9EAAAA Lf8z/yAAMP+0MLcwwzCvMAAAIABSAG8AbQBhAG4AAAAIuBMA8LcTABbnBzAIAAAAAAAAAAi4EwB6 WwkwALgTAIAABDIgALcPRAAAAC3/M/8gADD/DmYdZwAArzAAACAAUgBvAG0AYQBuAAAACLgTAPC3 EwAW5wcwCAAAAAAAAAAIuBMAelsJMAC4EwCAAAQSMAC3D0QAAABBAHIAaQBhAGwAIABCAGwAYQBj AGsAAABtAGEAbgAAAAi4EwDwtxMAFucHMAgAAAAAAAAACLgTAHpbCTAAuBMAAAAEIkAAtw9EAAAA VABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBhAG4AAAAIuBMA8LcTABbnBzAIAAAAAAAAAAi4EwB6 WwkwALgTAAAABCJQALcPRAAAAEEAcgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAATAPC3 EwAW5wcwCAAAAAAAAAAIuBMAelsJMAC4EwABAAAAYAC3D0QAAAAt/zP/IAAOZh1nAABVAG4AaQBj AG8AZABlACAATQBTAAAAEwDwtxMAFucHMAgAAAAAAAAACLgTAHpbCTAAuBMAgAAEEQAApA8IAAAA gABAAIAAAAAAAKUPDAAAAAAAAAguAAAAAgAAAAAAqQ8KAAAABwAAAAIAEQQJBEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wCAAAAAAQAAAP//GAAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABfAOQHPgcA AAAA5QcEAAAAAQAAAA8A5gcqBwAAAAC6DxQAAAB3AGgAbwBvAHMAaAAuAHcAYQB2ABAAug8IAAAA LgBXAEEAVgAgALoPAgAAADEAMAC6DwYAAAAxADAAMwAAAOcH3gYAAFJJRkbWBgAAV0FWRWZtdCAQ AAAAAQABABErAAARKwAAAQAIAGRhdGGyBgAAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA foCAgICAgICAgICAfn6AfoCAgIB+gH6AgICAgH5+fn5+fn5+gH6AgICAgH5+gICAgICAgICAgICA gICAgICAgH6AgICAgICAgICAgH5+gIB+fn6AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgH5+foCAgICAgICCgoB+fHx8fn5+foCChoiGgn56dnR2eHp8foKIjI6QjIJ6dnJu bHJ2fISIkJSUjoiAfHZ0cnBwdHp+gIiQkIqEgHx4dnR2fH5+goaGhIKChoiGgHp4dnZ2enx+goSG jJKOioJ4cmxobnR6goqSkpCIgHp2cnJwcHJyeH6IkJKYnJCOfGpbUVVffJy1u6uljmJJQ0NZhKOx t6uIbltJQ1l+lqu7sZJ6bG5oXV9ygJKep6OYmJR8XVNVU1NqiIaWlHp8kJqIhoSChHhfX2x+mKmv mHZfXWRyipKGjIpuVWJ8gparsY5uZmRfXYSrs6GlgmRdNT1ycpi7q4xual1qeoycoYh+lGxNbIya nJCCZHKUnpiKeFtbX2Z8paWcgllRZldLX5K7p5qhiHhoW3qhvZ6OlnhbQ0lqiJSUpaeYenh4hGRT UXqxxXxfZkk5V6/TuYhNO1FumsHV5r92SztPVXiGfpS9p3hqXV1ZU36tybWnlGxNP3CvtaVsTTtD R3C15tm1jFspEktopbnV33wlDCU7eLvZ5L10S1FTXZ7f5smWYkdyfIpsU252eo6voX5uZlNbboie w6t4OxpBeqGvv449K0FZksndu3w9Lxgxcsf88rlfEgAKP3yl1ea9hFc1L0N6rdPVw6NmKRQvcI6h v7WedmJNUXKInqmhmJiOinxPPU+Ws5Z0amRoapyvq7e1lmxHP0dfjLnD0cmKSxQIM4TT8tecZFFD TXCMp7O3t6uGcFc7MVOa0dnFt5BBDg5NmrfV6tF6LyM/Ynilx82WU0FNW2h2kqWzq6GciGhZcH5+ eoieinJ2gIB0W11wjJirt550V09VdIyamJSCeHhkXXaIfnZ2eJ6nioB6ZF94jox6aF9uhpaemIiC clNRbJCaoZyOdGJkcIZ+X2yEiIicmnJRX2xdW4q1s450Zl1XXX6rt6eCaFdmcHyhmpCEZldobmiA ioiIoaOYgGJVW2h6jKOhlohsU0NXjq+ro56AYllibniUpZRwZGhqdoyprZ6Gak05T3SElKu7tZqA XUdRW2RwcH6cra+pmoJoaGhkcHh+hpacmpSMeGhdWW6CkJicjoyGgHRucoqajnBdZGx2lq+rp4Zq UU1ifIyQmpiWkop2ZGpwgIqIioR6eHp6goqIkpaKdGxqcnyImp6YfF9bcn6CkJyYmJJ+amJfanyM mKOUenx4cHB+foCSnpSUjHZdV2h8io6Sjnx6eIKChI6GfHh8gIR6gIiEem5kaHB4iIyaraeOcl1Z Zm50ipiWhIB6amx8gHqCjIqEfHx+hIiGgnZwcG5yeoaMjpSShHBocnh6fISGgICAfoKGhoaEfHh0 cmpqdHZ+io6OlI5+dnp8enyAgHx4cnJ2foiEhoyKgHhycHJ0eoSMjIaCgIB8fHx2eoKAeHZ4fICG iIiGiIR4dHh+fn5+fn5+gISEgoCAenh4eHiAhoqKhIB8enh6fn6Ciop+cnJ6gH6AhIJ8eHp+foCG hoSAfHZ0eHyAhISCgoB6eHp8fn5+gISGhIB8gIB8enh8fHx+gICAgIKAgIKAgH56enx6en6ChoaE gH5+fnx+gIB+fHx+gICCiIZ+fHx6enyAgoKAfnx8en5+foSIioqEfnp4enp8foCAgoKCgoKCgoKA fn5+fH5+gISEgoB+fH6AgoKAgoSCgHx8fn6AgoKCgoB+gIKEgn5+foCAgICAgICCgoKCgIB+fn5+ gICEgoKCgoJ+foCCfoCAfHx8gIKCgoCAgH6AgIB+gICAgICAfn6Afn5+foCAfoCAgICAgICAgH5+ fn58fH6AgoKCgH58fH58fH6AgoKCgH5+fnx8fH5+foCAgICAgIB+fHx8fH6AgIB+gICAfn6AgH5+ fHx8fH5+fn5+gIB+fn5+fn58fn5+gICAgoKAfnx6en6AgICCgH5+fn5+gH58fHx8foCCgIB+fHx+ foCAgoCAfn5+fHx8fn5+foCAgoKAfnx8fH58foCCgoB8fn5+gH58enx+fn5+gICAgIB+fn58fHx+ foCAgICAfn5+fn5+gIKEgHx8fn5+fn6AfoCAgH5+gA8ACwTMDwAADwAA8MQPAAAAAAbwoAsAAATI BQBzAQAA6wIAAAoAAAABAAAAFwAAAAEAAAAGAAAAFQAAAAgAAAAMAAAACAAAAAAAAAACAAAADAAA AAgAAAAAAAAABAAAAAAAAAACAAAAAAAAAFsAAAAAAAAACwAAAAAAAAALAAAAAAAAACoAAAAAAAAA DAAAAAAAAAAKAAAAAAAAAAcAAAAAAAAA3gAAAAAAAAAEAAAAAAAAANcAAAAAAAAA2AAAAAAAAADZ AAAAAAAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAABQAAAAAAAAAKAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAA AAAAAAAvAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAKgAAAAAAAAAEAAAA AAAAAE4BAAAAAAAABQAAAAAAAAAFAAAAAAAAAAcAAAAAAAAAVQAAAAAAAAAEAAAAAAAAAAoAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAHkAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAkAAAAAAAAANQAAAAAAAAAABAAAAAAAANQAAAAAAAAA CwAAAAAAAAAFAAAAAAAAAAoAAAAAAAAABAAAAAAAAAALAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAE AAAAAAAAAAUAAAAAAAAABQAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAMA AAAAAAAAAwAAAAAAAAAJAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABwAA AAAAAADYAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAUAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAA AAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABQAAAAAA AAAFAAAAAAAAAAoAAAAAAAAABwAAAAAAAAASAAAAAAAAAA0AAAAAAAAABgAAAAAAAAAKAAAAAAAA AAUAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAMAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAW AAAAAAAAAAUAAAAAAAAADgAAAAAAAAAEAAAAAAAAAAgAAAAAAAAAAwAAAAAAAAAbAAAAAAAAADEA AAAAAAAABQAAAAAAAAAFAAAAAAAAABQAAAAAAAAABgAAAAAAAAAPAAAAAAAAABQAAAAAAAAABQAA AAAAAAAFAAAAAAAAAAUAAAAAAAAAHwAAAAAAAAAhAAAAAAAAAAUAAAAAAAAABAAAAAAAAAARAAAA AAAAAAUAAAAAAAAARgEAAAAAAAARAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAD AAAABwAAAAAAAAAEAAAAAwAAAAQAAAAAAAAABAAAAAYAAAAFAAAAAAAAAAQAAAAAAAAAIQAAAAAA AAAEAAAAAAAAABYAAAAAAAAABQAAAAAAAAALAAAAAAAAAAQAAAAAAAAABAAAAAAAAABGAQAAAAAA ACMAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAIAAAAAAAAABAAAAAAAAAACAAAAAAAAAG4BAAAAAAAA CgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAABzAAAAAAAAACYAAAAGAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQA AAAAAAAABgAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACoAAAAAAAAABAAA AAAAAABqAAAAAAAAAAQAAAAAAAAAagAAAAAAAAAEAAAAAAAAAGoAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAQAAAAAAAAAAwAAAAAAAAAGAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAABUAAAAAAAAABAAAAAAAAACNAAAAAAAA AAQAAAAAAAAAhQAAAAAAAAAEAAAAAAAAADsCAAAAAAAAAwAAAAAAAAAEAAAAAAAAABcAAAAAAAAA EQAAAAAAAACbAgAAAAAAAD0AAAAAAAAABwAAAAAAAAAJAAAAAAAAAAMAAAAAAAAAFAAAAAAAAAAJ AAAAAAAAAAMAAAAAAAAABAAAAAAAAAAEAAAAAAAAAD8AAAAAAAAABAAAAAAAAAAGAAAAAAAAAAsA AAAAAAAABQAAAAAAAAAEAAAAAAAAAAYAAAAAAAAAxQEAAAAAAAD+AAAAAAAAAAAEAAAAAAAAagEA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA9AAAAAAAAAPUAAAAAAAAABQAAAAAAAAAFAAAA AAAAAAoAAAAAAAAABwAAAAAAAAAFAAAAAAAAADsAAAAAAAAABAAAAAAAAAAbAAAAAAAAAAQAAAAA AAAABwAAAAAAAAAQAAAAAAAAABEAAAAAAAAAOgAAAAAAAAAVAAAAAAAAAAkAAAAAAAAABgAAAAAA AAAEAAAAAAAAAAQAAAAAAAAAHAAAAAAAAAAEAAAAAAAAAA8AAAAAAAAAFAAAAAAAAAAKAAAAAAAA AAQAAAAAAAAADwAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAA CAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAsAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAUA AAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACMAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAFAAAAAAAAAGsAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAUAAAAA AAAABAAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAYAAAAAAAAAxQEAAAAA AAD+AAAAAAAAAAAEAAAAAAAAagEAAAAAAAByAAAAAAAAACcAAAAAAAAABQAAAAAAAAAEAAAAAAAA AAUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAA CgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAC/AAAABAAAAMAAAABqAQAAwQAAAEQBAAAAAAAABAAAAMMAAAAEAAAAAAAAAAQA AADFAAAABAAAAF8BAfCcAwAAYgAH8CQAAAAGBjwgDsnOVVsOCNMt7QKaRpr/AAQEAAABAAAAAAAA AAAAAABiAAfwJAAAAAYGGoiJrOuonVjD7kWnYXCpa/8ANAQAAAEAAAAEBAAAAAAAAGIAB/AkAAAA BgZnViI1jqJOHy/BdYRyWY21/wChAwAAAQAAADgIAAAAAAAAYgAH8CQAAAAGBmFboKUia4mVu1MM QGXdsfn/ADsJAAACAAAA2QsAAAAAAABiAAfwJAAAAAYGqFlgZsZin5fKFicOaELhYv8AigoAAAIA AAAUFQAAAAAAADIAB/AkAAAAAwRV2x0GLD9hnIA789zmsZ6v/wAPBwAAAgAAAJ4fAAAAAAAAYgAH 8CQAAAAGBpH2ttqXZlQvQp6s9y4+I5n/AEkPAAABAAAArSYAAAAAAABSAAfwJAAAAAUFxH+YSkwR ufLHq3g/np/Mf/8ARRkAAAEAAAD2NQAAAAAAAGIAB/AkAAAABgbYO7XFa0kDSfjMlAkIRk6J/wDo BAAAAgAAADtPAAAAAAAAYgAH8CQAAAAGBtIMpBKLXdg3Cre1UYLbVUv/AEddAAABAAAAI1QAAAAA AABSAAfwJAAAAAUFktkGp9ozZocSWYkB8nH8O/8Ahg0AAAEAAABqsQAAAAAAAFIAB/AkAAAABQWV 0HfBNcnzrfYUiYU16TQ//wDkKAAAAQAAAPC+AAAAAAAAYgAH8CQAAAAGBivYEu8FGw/t6S6yccYD J5f/ADgRAAABAAAA1OcAAAAAAABiAAfwJAAAAAYGBcrHD8mVvOg5AsAAX22Yg/8AsgoAAAEAAAAM +QAAAAAAAGIAB/AkAAAABgZIYzeuXnXkzoNc6yMDM23d/wAgAQAAAgAAAL4DAQAAAAAAUgAH8CQA AAAFBTKiosI0sjEGOe7aTT+hCJL/ANIWAAABAAAA3gQBAAAAAAACAAfwJAAAAAAAAAAAAAAAAAAA AAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAA AAAAAAAAAAAAAAAAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAAC AAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAGIAB/AkAAAABgY3bG9N bLnAOvbpqfntFQAv/wAaCwAAAQAAALAbAQAAAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ ARAAEADAAQEAAAjFQQAAAAD/AQgACAABAgIAAAiAABrxIAAAAP/MzAD/MwAAmf9mAP9mmQCZzP8A /wAAAADMmQD//2YAQAAe8RAAAAAAAAAI/zMAAP/////3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAE AAAAAAAAAAAAAIAAAAAADwDQB1wCAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAABAAAADwD6A2cA AAAAAP4DAwAAAAABAAAA/QM0AAAATAAAAGQAAABMAAAAZAAAAAgAAAAAAAAAILgTAHpbCTAAAAAA AAAAAGT///+a////AQATAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAAAwDAAAHwAIBDwAAAAA AP0DNAAAAEIAAABkAAAAQgAAAGQAAABMuBMA3x0JMIi5EwCwLJ0AAAAAAAAAAAAAAAAAag4AAAAA EwAfAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAACAAAAAAAAAAguBMA elsJMAAAAAAAAAAArPn//8T///8AABMAcAD7AwgAAAAAAAAAOAsAAHAA+wMIAAAAAQAAAHAIAAAf AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAEy4EwDfHQkwiLkTALAsnQAAAAAAAAAAAAAA AAAAAAAAAAETAB8AFAQcAAAAAAAVBBQAAABGbE8JAMqaO60HlMcAypo7AQEAAB8AEwQ8AAAAAAD9 AzQAAABkAAAAZAAAAGQAAABkAAAATLgTAHwtCTA4uBMAFAAAAAAAAAAAAAAAAAAAAAAAAAAAARMA DwCIE2oAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAABw tQAAcLUAAA8AihMqAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMMAAAAAAB6FwQAAAAABAAA PwDZDzgAAAAAANoPBAAAAAAALAAgALoPJAAAAE4AVABUACAARQB1AHIAbwBwAGUAIABMAGkAbQBp AHQAZQBkAE8A2Q8MAAAAAADaDwQAAAAAAD0ADwDwD+UYAAAAAPMDFAAAALcAAAAAAAAAAgAAAAAB AAAAAAAAAACfDwQAAAAGAAAAAACoD2sAAABJUHY2L3Y0IGR1YWwgc3RhY2sgY29tbWVyY2lhbCBB RFNMIHNlcnZpY2Ugc3BlY2lmaWNhdGlvbiALLSBJRVRGIHY2T1BTIFdHIEludGVyaW0gTWVldGlu ZyBvbiBTZXB0LjE4LDIwMDIgLQAAoQ84AAAAbAAAAAAAAAAAADgAAACAAAIAAAAcAAIAAACAAAIA AAAYADEAAACAAAIAAAASAAEAAAAAAAIAEgAQAJ8PBAAAAAUAAAAAAKAPBAEAAFMAaABpAG4AIABN AGkAeQBhAGsAYQB3AGEALAAgAFAAaAAuAEQAIAAI/65b3V0AMEtmCf8NAFMAcgAuACAAUgBlAHMA ZQBhAHIAYwBoACAATQBhAG4AYQBnAGUAcgAsACAASQBQAHYANgAgAEcAcgBvAHUAcAANAEkAbgBu AG8AdgBhAHQAaQB2AGUAIABJAFAAIABBAHIAYwBoAGkAdABlAGMAdAB1AHIAZQAgAEMAZQBuAHQA ZQByAA0ATgBUAFQAIABDAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBuAHMADQBtAGkAeQBhAGsAYQB3 AGEAQABuAHQAdAB2ADYALgBqAHAAAAChDxwAAACDAAAAAAAAAAAAGwAAAAAAAABoAAAAAAACABgA AACqD2AAAAAFAAAABgAAAAkEAAAIAAAABwAAAAMACQQAAAIAAAAGAAAACQQAAAQAAAAHAAAAAwAJ BAAAAQAAAAYAAAAJBAAABwAAAAAAAABWAAAAAAAAABEAAAAAAAAAAQAAAAAAAAAPAPIPGAAAAAAA 8w8QAAAAAAAAAAAAAAAAAAAACFUKMAAA3w8IAAAAcQAAAIIAAAAAAPMDFAAAAE4BAAAAAAAAAgAA AAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDwYAAAB0b3BpY3MQAJ8PBAAAAAEAAAAAAKAPTgYAAFcA ZQAgAE4AVABUACAAQwBvAG0AbQB1AG4AaQBjAGEAdABpAG8AbgBzACAAZwByAG8AdQBwACAAaABh AHMAIABhAGwAcgBlAGEAZAB5ACAAcwB0AGEAcgB0AGUAZAAgAGMAbwBtAG0AZQByAGMAaQBhAGwA IABJAFAAdgA2AC8AdgA0ACAAZAB1AGEAbAAgAHMAdABhAGMAawAgAGMAbwBtAG0AZQByAGMAaQBh AGwAIABzAGUAcgB2AGkAYwBlACAAaQBuACAASgBhAHAAYQBuACwAIABpAG4AaQB0AGkAYQBsAGwA eQAgAGYAcgBvAG0AIABkAG8AdwBuACAAdABvAHcAbgAgAFQAbwBrAHkAbwAgAHMAaQBuAGMAZQAg AHQAaABpAHMAIABzAHUAbQBtAGUAcgANAFcAZQAgAGgAYQB2AGUAIAB0AGEAbABrAGUAZAAgAHcA aQB0AGgAIAB0AGgAZQAgAG8AdABoAGUAcgAgAEkAUwBQAHMAIABhAG4AZAAgAGEAbABzAG8AIAAo AG0AbwBzAHQAbAB5ACAASgBhAHAAYQBuAGUAcwBlACAAYgBhAHMAZQBkACAAYgB1AHQAIABuAG8A dAAgAGwAaQBtAGkAdABlAGQAIAB0AG8AKQAgAHYAZQBuAGQAbwByAHMAIAB3AGgAbwAgAHMAdQBw AHAAbAB5AGkAbgBnACAAZQBxAHUAaQBwAG0AZQBuAHQAcwAgAGEAbgBkACAAcwBvAGYAdAB3AGEA cgBlAHMAIABhAGwAcgBlAGEAZAB5ACAAYQBiAG8AdQB0ACAAdABoAGUAIABzAHAAZQBjAGkAZgBp AGMAYQB0AGkAbwBuACAAdwBoAGkAYwBoACAAaQBzACAAbwBwAGUAbgBlAGQAIAB0AG8AIAB0AGgA ZQAgAHAAdQBiAGwAaQBjACAAYgB1AHQAIAB3AHIAaQB0AHQAZQBuACAAaQBuACAASgBhAHAAYQBu AGUAcwBlAA0AaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHYANgAuAG4AdAB0AC4AbgBlAHQALwB3AGgA YQB0AC8AMgAwADAAMgAwADcAMwAxAC4AaAB0AG0AbAANAFMAbwBtAGUAIABuAG8AbgAgAEoAYQBw AGEAbgBlAHMAZQAgAGIAYQBzAGUAZAAgAG4AZQB0AHcAbwByAGsAIABvAHAAZQByAGEAdABvAHIA cwAgAGEAbgBkACAAcwBvAG0AZQAgAG8AdABoAGUAcgAgAHYAZQBuAGQAbwByAHMALwBzAG8AZgB0 AHcAYQByAGUAIABkAGUAdgBlAGwAbwBwAGUAcgBzACAAYQByAGUAIABpAG4AdABlAHIAZQBzAHQA ZQBkACAAYgB5ACAAdABoAGUAIABzAHAAZQBjAGkAZgBpAGMAYQB0AGkAbwBuACwAIABiAGUAYwBh AHUAcwBlACAAdABoAGUAeQAgAGMAbwB1AGwAZAAgAGMAdQB0AC0AbwBmAGYAIAB0AGgAZQAgAGMA bwBzAHQAIABvAGYAIABkAGUAcwBpAGcAbgAgAHcAbwByAGsAIABhAG4AZAAgAGkAbQBwAGwAZQBt AGUAbgB0AGEAdABpAG8AbgANAFMAbwAsACAAcwBpAG0AcABsAHkAIAB3AGUAGSBkACAAbABpAGsA ZQAgAHQAbwAgAHQAcgBhAG4AcwBsAGEAdABlACAAbwB1AHIAIABzAHAAZQBjAGkAZgBpAGMAYQB0 AGkAbwBuACAAaQBuAHQAbwAgAEUAbgBnAGwAaQBzAGgAIABhAG4AZAAgAHAAdQBiAGwAaQBzAGgA IABhAHMAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AYQBsACAAZAByAGEAZgB0ACAAdQBuAGQAZQBy ACAAdABoAGUAIABuAGEAbQBlACAAbwBmACAAdgA2AG8AcABzACAAdwBvAHIAawBpAG4AZwAgAGcA cgBvAHUAcAAgAGEAcwAgAGEAbgAgAHIAdQBuAG4AaQBuAGcAIABlAHgAYQBtAHAAbABlACAAZgBv AHIAIABBAEQAUwBMACAASQBQAHYANgAvAEkAUAB2ADQAIABkAHUAYQBsACAAcwB0AGEAYwBrACAA cwBlAHIAdgBpAGMAZQAuAAAAoQ9CAAAAeAEAAAAAABAAAFAAKQAAAAEAABAAAFAAhwEAAAAAABAA AFAAeAEAAAAAAgAUACkAAAAAAAIAEgCHAQAAAAACABQAAACqDxoAAAAYAQAAAAAAAAkAAAABAAAA AwAHAgAAAAAAAAAA8wMUAAAAuQAAAAQAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAA AFRoZSBDb21wYW55IE5UVBAAnw8EAAAAAQAAAAAAoA+MBQAATgBpAHAAcABvAG4AIABUAGUAbABl AGcAcgBhAHAAaAAgAGEAbgBkACAAVABlAGwAZQBwAGgAbwBuAGUAIAANAGgAaQBzAHQAbwByAHkA IABzAHQAYQByAHQAZQBkACAAaQBuACAAMQA4ADYAOQANAHQAaABlACAAbQBpAG4AaQBzAHQAcgB5 ACAAbwBmACAAdABlAGwAZQBjAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBuACAAbwBmACAASgBhAHAA YQBuAGUAcwBlACAAZwBvAHYAZQByAG4AbQBlAG4AdAANAGIAZQBjAGEAbQBlACAAYQAgABwgcAB1 AGIAbABpAGMAIABjAG8AcgBwAG8AcgBhAHQAaQBvAG4AHSAgAGkAbgAgADEAOQA1ADIADQBpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgACgAbwByACAAHCBwAHIAaQB2AGEAdABpAHoAZQBkAB0gKQAg AGkAbgAgADEAOQA4ADQADQByAGUALQBvAHIAZwBhAG4AaQB6AGUAZAAgAG8AbgAgADcALwAxACwA MQA5ADkAOQANAFQAaABlACAAYwBvAG0AcABhAG4AeQAgAE4AVABUACAAYgBlAGMAYQBtAGUAIAB0 AGgAZQAgAHMAaABhAHIAZQAtAGgAbwBsAGQAaQBuAGcAIABhAG4AZAAgAFIAJgBEACAAYwBvAG0A cABhAG4AeQAgAHcAaABpAGMAaAAgAGgAYQBzAA0ATgBUAFQAIABFAGEAcwB0ACAAYQBuAGQAIABO AFQAVAAgAFcAZQBzAHQAIABhAHMAIAB0AHcAbwAgAGwAbwBjAGEAbAAgAHMAZQByAHYAaQBjAGUA IABjAG8AbQBwAGEAbgBpAGUAcwAsAA0ATgBUAFQAIABDAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBu AHMAIABhAHMAIABsAG8AbgBnAC0AZABpAHMAdABhAG4AYwBlACwAIABpAG4AdABlAHIAbgBhAHQA aQBvAG4AYQBsACwAIABGAFIALAAgAEEAVABNACAAYQBuAGQAIABJAG4AdABlAHIAbgBlAHQAIABz AGUAcgB2AGkAYwBlACwADQBOAFQAVAAgAEQAbwBDAG8ATQBvACAAZABvAGkAbgBnACAAYwBlAGwA bAB1AGwAYQByACAAcABoAG8AbgBlACAAYgB1AHMAaQBuAGUAcwBzACwADQBOAFQAVAAgAEQAYQB0 AGEAIABhAHMAIABhACAAcwB5AHMAdABlAG0AIABzAG8AbAB1AHQAaQBvAG4AIABzAGUAcgB2AGkA YwBlACAAYwBvAG0AcABhAG4AeQAsAA0AYQBuAGQAIABhACAAbABvAHQAIABvAGYAIABnAHIAbwB1 AHAAIABzAHUAYgBzAGkAZABpAGEAcgBpAGUAcwAuAA0AVQBSAEwAOgAgAGgAdAB0AHAAOgAvAC8A dwB3AHcALgBuAHQAdAAuAGMAbwAuAGoAcAAvAA0ATgBUAFQALQBDAG8AbQBtAHUAbgBpAGMAYQB0 AGkAbwBuAHMAIABoAHQAdABwADoALwAvAHcAdwB3AC4AbgB0AHQALgBjAG8AbQAvAA0AVwBvAHIA bABkACAAbwBwAGUAcgBhAHQAaQBvAG4AIAAgAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBuAHQAdAB2 AGUAcgBpAG8ALgBjAG8AbQAvAA0ASQBQAHYANgAgAHIAZQBsAGEAdABlAGQAIABoAHQAdABwADoA LwAvAHcAdwB3AC4AdgA2AC4AbgB0AHQALgBuAGUAdAAvACAAKABtAG8AcwB0AGwAeQAgAEoAYQBw AGEAbgBlAHMAZQAsACAAcwBvAHIAcgB5ACkADQANAAAAoQ++AAAAIAAAAAEAABAAAFAAGAAAAAIA ABAAAFAAOQAAAAMAABAAAFAAZgAAAAIAABAAAFAARQEAAAMAABAAAFAAQgAAAAIAABAAAFAAZwAA AAMAABAAAFAAAgAAAAEAABAAAFAAIAAAAAAAAgAYABgAAAAABAIAgAQUADkAAAAABAIAgAQSAGYA AAAACAIAgAgUAEUBAAAACAIAgAgSAEIAAAAADAIAgAwUAGcAAAAAEAIAgBASAAIAAAAAFAIAgBQY AAAAqg9YAAAApgEAAAAAAAAGAAAAAQAAAAMAfAAAAAAAAAANAAAAAQAAAAMAHAAAAAAAAAALAAAA AQAAAAMAGgAAAAAAAAAQAAAAAQAAAAMAQAAAAAAAAAABAAAAAAAAAAAA8wMUAAAAUAEAAAQAAAAB AAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPKgAAAE5UVC9WRVJJTyBHbG9iYWwgSVB2NiBCYWNr Ym9uZSAmIFNvbHV0aW9ucwAAoQ8UAAAAKwAAAAAAAAAAACsAAAAAAAIAHAAAAKoPFAAAACoAAAAA AAAAAQAAAAYAAAAJBAAAAADzAxQAAABRAQAABAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8VAAAAU3BlY2lmaWNhdGlvbiBzdW1tYXJ5EACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAA AADzAxQAAABSAQAAAAAAAAIAAAAHAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8WAAAAU3BlY2lmaWNh dGlvbiBoaS1saWdodBAAnw8EAAAAAQAAAAAAoA9mBAAAMQAgAEkAUAB2ADQAIABhAGQAZAByAGUA cwBzACAAKwAgADEAIABJAFAAdgA2ACAAcAByAGUAZgBpAHgAIAAoAHUAcwB1AGEAbABsAHkAIAAv ADQAOAApAA0AVQBzAGkAbgBnACAAIABEAEgAQwBQAHYANgAgACgAZQBzAHAAZQBjAGkAYQBsAGwA eQAgAFAARAAgAG8AcAB0AGkAbwBuACkAIABhAHMAIAAoAEQAeQBuAGEAbQBpAGMAKQAgAFMAaQB0 AGUAIABDAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuACAAUAByAG8AdABvAGMAbwBsAC4AIABQAGwA ZQBhAHMAZQAgAGQAbwAgAG4AbwB0ACAAYgBlACAAYwBvAG4AZgB1AHMAZQBkAC4ADQBJAFAAdgA2 ACAAcAByAGUAZgBpAHgAIABkAGUAbABlAGcAYQB0AGkAbwBuACAAcwB0AGEAdABpAGMAYQBsAGwA eQANAFMAdQBiAHMAYwByAGkAYgBlAHIAIABnAGUAdABzACAAcwBhAG0AZQAgAHAAcgBlAGYAaQB4 AA0ASQBQAHYANAAgAGEAZABkAHIAZQBzAHMAIABhAHMAcwBpAGcAbgBtAGUAbgB0ACAAZAB5AG4A YQBtAGkAYwBhAGwAbAB5AA0ASQBQAHYANAAgAGEAZABkAHIAZQBzAHMAIABtAGEAeQAgAGMAaABh AG4AZwBlACAADQBJAFAAdgA2ACAAZgByAGkAZQBuAGQAbAB5ACAARABOAFMAIABvAHAAZQByAGEA dABpAG8AbgANAE8AdQByACAARABOAFMAIABzAGUAcgB2AGUAcgBzACAAaABhAHYAZQAgAEkAUAB2 ADYAIAB0AHIAYQBuAHMAcABvAHIAdAAgAGEAbgBkACAAYQBjAGMAZQBwAHQAaQBuAGcAIABEAE4A UwAgAHQAcgBhAG4AcwBmAGUAcgAgAGIAeQAgAHQAaABhAHQADQBDAGEAbgAgAGIAZQAgAGMAdQBz AHQAbwBtAGUAcgAZIHMAIABzAGUAYwBvAG4AZABhAHIAeQAgAHMAZQByAHYAZQByAA0AQQBzAHMA dQBtAGkAbgBnACAAWwBhAHMAcwBpAGcAbgBlAGQAIABwAHIAZQBmAGkAeABdADoAOgA1ADMAIABh AHMAIABjAHUAcwB0AG8AbQBlAHIAGSBzACAARABOAFMAIABwAHIAaQBtAGEAcgB5ACAAcwBlAHIA dgBlAHIAIABsAG8AYwBhAHQAaQBvAG4ADQBTAG8AIAB0AGgAYQB0ACAAYwB1AHMAdABvAG0AZQBy ACAAYwBhAG4AIAByAHUAbgAgAA0ARAB1AGEAbAAgAFMAdABhAGMAawAgAE0AYQBpAGwAIABTAGUA cgB2AGUAcgAgAA0ARAB1AGEAbAAgAFMAdABhAGMAawAgAFcAVwBXACAAUwBlAHIAdgBlAHIADQBh AG4AZAAgAG0AbwByAGUAIAANAAAAoQ+8AAAAuQAAAAAAABAAAFAAHAAAAAEAABAAAFAAJAAAAAAA ABAAAFAAGQAAAAEAABAAAFAAHAAAAAAAABAAAFAAzQAAAAEAABAAAFAAOAAAAAIAABAAAFAAAQAA AAEAABAAAFAAuQAAAAAAAgASABwAAAAAAAIAEAAkAAAAAAQCAIAEEgAZAAAAAAQCAIAEEAAcAAAA AAgCAIAIEgDNAAAAAAwCAIAMEAA4AAAAAAwCAIAMDgABAAAAAAwCAIAMEAAAAPMDFAAAAFMBAAAA AAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABBdCB0aGUgZW5kEACfDwQAAAABAAAA AACoD0ABAABXZSBob3BlIHRoYXQgd2UgY291bGQgcHVibGlzaCBhIGRldGFpbGVkIHNwZWNpZmlj YXRpb24gYXMgSW5mb3JtYXRpb25hbCBSRkMgYXMgc28gdGhhdCBhbnlib2R5IHdobyBpbnRlcmVz dGVkIGJ5IHNhbWUga2luZCBvZiBzZXJ2aWNlIGNhbiB1c2UgaXQgdG8gc2F2ZSB0aW1lIGFuZCBl ZmZvcnRzIA1BbHNvIGZyb20gdmVuZG9ycyBwb2ludCBvZiB2aWV3LCBpZiB0aGlzIG1ldGhvZCB3 b3VsZCBiZSB3aWRlbHkgdXNlZCBpbiB0aGUgd29ybGQgd2lkZSwgdGhhdCBtZWFucyB0aGV5IGFs c28gY2FuIHNhdmUgdGltZSBhbmQgY29zdHMgZm9yIGRldmVsb3BtZW50DQAAoQ8eAAAAQAEAAAAA AAAAAAEAAAAAAAEAAAAAAEEBAAAAAAAAAADqAwAAAAAPAPgDigkAAAIA7wMYAAAAAQAAAAECBwkI AAAAAAAAAAAAAAAAABMAYADwByAAAAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAGAA 8AcgAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA//8A/wAzAJaWlgBgAPAHIAAAAP//zAAAAAAAgIAA AJmZMwAzmTMAgAAAAAAzzAD/zGYAYADwByAAAAD///8AAAAAADk5OQAAAAAAy8vLAIaGhgBNTU0A 6urqAGAA8AcgAAAA////AAAAAACfn58AAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAA AAAAhoaGAAAAAADLy8sAAGb/AP8AMwAAmQAAYADwByAAAAD///8AAAAAAJaWlgAAAAAAM5n/AJn/ zADMAMwAsrKyAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAABwAA AP//7wCAAAAAAQAAAP//LAAAAAADAAAQAKMPfAAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA 2AAAAEACAAAAAAcAAAD//+8AgAAAAAEAAAD//yAAAAAAAQAAgAUAABMg1AEgAQAAAgAcAIAFAAAi INACQAIAAAIAGACABQAAEyDwA2ADAAACABQAgAUAALsAEAWABAAAAAAgAKMPbgAAAAUA//0/AAAA IiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAcAAAD//+8AgAAAAAIAAAD//wwAAAAAAQAAAAUA ACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAA AQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBg AwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAA AAACABwAAQAAAAAAAAACABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACj Dz4AAAAFAAAAAAAAAAAAAgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQA AAAAAAAAAgAQAA8ADATEBQAADwAC8LwFAAAQAAjwCAAAAAgAAAAWBAAADwAD8EIFAAAPAATwKAAA AAEACfAQAAAA9fX19fX19fX19fX19fX19QIACvAIAAAAAAQAAAUAAAAPAATwwAAAABIACvAIAAAA AgQAAAAKAABzAAvwKgAAAH8AAQABAIAAyBX7A4cAAQAAAIEBBAAACL8BAQARAMABAQAACP8BAQAJ AAAAEPAIAAAAYADUAYwWMAMPABHwEAAAAAAAwwsIAAAAAAAAAAEA+wMPAA3wTgAAAAAAnw8EAAAA AAAAAAAAoA8aAAAA3jC5ML8w/DC/MKQwyDDrMG4w+GYPXy2KmlsAAKIPBgAAAA4AAAAAAAAAqg8K AAAADgAAAAEAAAAAAA8ABPBiAQAAEgAK8AgAAAADBAAAAAoAAGMAC/AkAAAAfwABAAEAgAB0GPsD gQEEAAAIvwEBABEAwAGAAIAA/wEBAAkAAAAQ8AgAAADwA9QBjBYQDg8AEfAQAAAAAADDCwgAAAAB AAAAAgD7Aw8ADfD2AAAAAACfDwQAAAABAAAAAACgD1oAAADeMLkwvzD8MMYwrTC5MMgwbjD4Zg9f LYqaWw0ALHsgADIAIADsMNkw6zANACx7IAAzACAA7DDZMOswDQAseyAANAAgAOww2TDrMA0ALHsg ADUAIADsMNkw6zAAAKIPHgAAAA4AAAAAAAgAAAABAAgAAAACAAgAAAADAAgAAAAEAAAAqg9aAAAA EAAAAAEAAAAAAAIAAAABAAAAAAAGAAAAAQAAAAAAAgAAAAEAAAAAAAYAAAABAAAAAAACAAAAAQAA AAAABgAAAAEAAAAAAAIAAAABAAAAAAAEAAAAAQAAAAAADwAE8LAAAAASAArwCAAAAAYEAAAACgAA YwAL8CQAAAB/AAEAAQCAAIgg+wOBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAMAPTBNg GOAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAvsDDwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA AAChDxoAAAACAAAAAAAAKAoAAgAyAAcAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBuAAAAsgQK 8AgAAAAJBAAAEAoAAGMAC/AkAAAABEEDAAAACwGOAAAAPwEAAAEAvwEAABAA/wEAAAgAPwIAAAIA EwAi8QYAAAC/AwAEAAQAABDwCAAAADgG+QlnDqYKDwAR8AwAAAAAAMELBAAAAI4AAAAPAATw1AAA AAIACvAIAAAACwQAAAAKAAAzAQvwrAAAAIUAAgAAAIcAAQAAAEIBkAkAAEMB8AAAAEQBBAAAAEXB EAAAAEbBGgAAAH8BAQABAIABAgAAAIEB3d3dAIZBCAAAAIfBCgAAAJUBAAAAAL8BFAAUAMABAQAA CMQBAAAAAP8BEAAYAAECAgAACIgDAAAAAAQABADw/wAAkACQCQAAoAjwAAAAkAAKAAwAAgAAQACs AQAArAEAAKwBAACsAWAAgH8wSzBSMPN3AAAAABDwCAAAAKACIAewEJADDwAE8GIAAACyBArwCAAA AA0EAAAACgAAQwAL8CwAAAB/AIAAgAAEQRUAAAAFwRQAAAAGAQEAAABuAGMAbwBtAF8AcgBvAGcA bwAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAAAAAA4gNaAQ8ABPBkAAAAsgQK8AgAAAAWBAAAAAoA AEMAC/AuAAAAfwCAAIAABEECAAAABcEWAAAABgEBAAAAbABvAGcAbwBiAG8AdAB0AG8AbQAAABMA IvEGAAAAvwMABAAEAAAQ8AgAAABJAFcUCxj9AA8ABPBaAAAAEgAK8AgAAAABBAAAAAwAALMAC/BC AAAAgQEAAAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgAAQIAAAACBQKoKQEABgKoKQEAPwIDAAMA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyACAAug8c AAAAsGVXMEQwjP+f/5r/fv+e/53/g/9w/3z/bv+d/w8A8ANWBwAAAQDxAwgAAAAAAACAAAAKMA8A DATWBgAADwAC8M4GAADAAAjwCAAAAAcAAAAHEAAADwAD8GwGAAAPAATwKAAAAAEACfAQAAAA9fX1 9fX19fX19fX19fX19QIACvAIAAAAABAAAAUAAAAPAATwBgEAABIACvAIAAAAAhAAAAAKAACzAAvw QgAAAH8AAQABAIAAzELxBIEA2V8BAIIA7K8AAIMA2V8BAIQA7K8AAL8AEAAfAIEBBAAACL8BAQAR AMABAQAACP8BAQAJAAAAEPAIAAAAAAAAAFEHHwEPABHwEAAAAAAAwwsIAAAAAAAAAAoC8QQPAA3w fAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGAAAAAIAAAAAAAAgCgAyAAcAAgAAAAAAAgAM AAAA+Q8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAAAKYPFgAAAPEeAAA4AhwB HAE4AjgCUwNTA28EbwQPAATwCAEAABIACvAIAAAAAxAAAAAKAACzAAvwQgAAAH8AAQABAIAADE7x BIEA2V8BAIIA7K8AAIMA2V8BAIQA7K8AAL8AEAAfAIEBBAAACL8BAQARAMABAQAACP8BAQAJAAAA EPAIAAAAAACPCeAQHwEPABHwEAAAAAAAwwsIAAAAAQAAAAcA8QQPAA3wfgAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAoCgACADIABwACAAAAAAACAAwAAAD4DwQAAAAAAAAA AACqDxQAAAABAAAAAQAAAAAAAQAAAAEAAAAAAAAApg8WAAAA8R4AADgCHAEcATgCOAJTA1MDbwRv BA8ABPBkAAAAEgAK8AgAAAAEEAAAAAoAAGMAC/AkAAAAhwABAAAAfwEAAAEAgQEEAAAIvwERABEA wAEBAAAI/wEIAAkAAAAQ8AgAAACuAV0ChA4YCg8AEfAQAAAAAADDCwgAAAACAAAABQDxBA8ABPCA AQAAEgAK8AgAAAAFEAAAAAoAALMAC/BCAAAAfwABAAEAgAC4V/EEgQDZXwEAggDsrwAAgwDZXwEA hADsrwAAvwAQAB8AgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACnCkACoA7BFA8AEfAQ AAAAAADDCwgAAAADAAAABgLxBA8ADfD2AAAAAACfDwQAAAACAAAAAACgD1oAAADeMLkwvzD8MMYw rTC5MMgwbjD4Zg9fLYqaWw0ALHsgADIAIADsMNkw6zANACx7IAAzACAA7DDZMOswDQAseyAANAAg AOww2TDrMA0ALHsgADUAIADsMNkw6zAAAKIPHgAAAA4AAAAAAAgAAAABAAgAAAACAAgAAAADAAgA AAAEAAAAqg9aAAAAEAAAAAEAAAAAAAIAAAABAAAAAAAGAAAAAQAAAAAAAgAAAAEAAAAAAAYAAAAB AAAAAAACAAAAAQAAAAAABgAAAAEAAAAAAAIAAAABAAAAAAAEAAAAAQAAAAAADwAE8AwBAAASAArw CAAAAAYQAAAACgAAwwAL8EgAAAB/AAEAAQCAAHwG8QSBANlfAQCCAOyvAACDANlfAQCEAOyvAACH AAIAAAC/ABAAHwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAFAVAABRB28WDwAR8BAA AAAAAMMLCAAAAAQAAAAJAvEEDwAN8HwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxgAAAAC AAAAAAAAIAoAMgAHAAIAAAAAAAIADAAAAPoPBAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAA AQAAAAAAAACmDxYAAADxHgAAOAIcARwBOAI4AlMDUwNvBG8EDwAE8A4BAAASAArwCAAAAAcQAAAA CgAAwwAL8EgAAAB/AAEAAQCAAJhm8QSBANlfAQCCAOyvAACDANlfAQCEAOyvAACHAAIAAAC/ABAA HwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAFAVjwngEG8WDwAR8BAAAAAAAMMLCAAA AAUAAAAIAvEEDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxoAAAACAAAAAAAAKAoA AgAyAAcAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAA AKYPFgAAAPEeAAA4AhwBHAE4AjgCUwNTA28EbwQPAATwQgAAABIACvAIAAAAARAAAAAMAABzAAvw KgAAAIEBAAAACJMB3r1oAJQBIzaLAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAIFUwgHwPTZNDwDJD+IEAAAPAAwEcgQAAA8AAvBq BAAAUAEI8AgAAAAFAAAABQgAAA8AA/AIBAAADwAE8CgAAAABAAnwEAAAAPX19fX19fX19fX19fX1 9fUCAArwCAAAAAAIAAAFAAAADwAE8OoAAAASAArwCAAAAAIIAAAACgAAswAL8EIAAAB/AAEAAQCA AKyF8QSBANlfAQCCAOyvAACDANlfAQCEAOyvAAC/ABAAHwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEA CQAAABDwCAAAAAAAAABRBx8BDwAR8BAAAAAAAMMLCAAAAAAAAAAKAvEEDwAN8GAAAAAAAJ8PBAAA AAQAAAAAAKAPAgAAACoAAAChDxgAAAACAAAAAAAAIAoAMgAHAAIAAAAAAAIADAAAAPkPBAAAAAAA AAAAAKYPFgAAAPEeAAA4AhwBHAE4AjgCUwNTA28EbwQPAATw7AAAABIACvAIAAAAAwgAAAAKAACz AAvwQgAAAH8AAQABAIAA/JXxBIEA2V8BAIIA7K8AAIMA2V8BAIQA7K8AAL8AEAAfAIEBBAAACL8B AQARAMABAQAACP8BAQAJAAAAEPAIAAAAAACPCeAQHwEPABHwEAAAAAAAwwsIAAAAAQAAAAcC8QQP AA3wYgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAoCgACADIABwACAAAA AAACAAwAAAD4DwQAAAAAAAAAAACmDxYAAADxHgAAOAIcARwBOAI4AlMDUwNvBG8EDwAE8PAAAAAS AArwCAAAAAQIAAAACgAAwwAL8EgAAAB/AAEAAQCAANCN8QSBANlfAQCCAOyvAACDANlfAQCEAOyv AACHAAIAAAC/ABAAHwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAFAVAABRB28WDwAR 8BAAAAAAAMMLCAAAAAIAAAAJAvEEDwAN8GAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxgA AAACAAAAAAAAIAoAMgAHAAIAAAAAAAIADAAAAPoPBAAAAAAAAAAAAKYPFgAAAPEeAAA4AhwBHAE4 AjgCUwNTA28EbwQPAATw8gAAABIACvAIAAAABQgAAAAKAADDAAvwSAAAAH8AAQABAIAAIKrxBIEA 2V8BAIIA7K8AAIMA2V8BAIQA7K8AAIcAAgAAAL8AEAAfAIEBBAAACL8BAQARAMABAQAACP8BAQAJ AAAAEPAIAAAAUBWPCeAQbxYPABHwEAAAAAAAwwsIAAAAAwAAAAgC8QQPAA3wYgAAAAAAnw8EAAAA BAAAAAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAoCgACADIABwACAAAAAAACAAwAAADYDwQAAAAA AAAAAACmDxYAAADxHgAAOAIcARwBOAI4AlMDUwNvBG8EDwAE8EIAAAASAArwCAAAAAEIAAAADAAA cwAL8CoAAACBAQAAAAiTAd69aACUASM2iwC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAA AP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAA XwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACBVMIBcMhNTg8A7gOnAgAAAgDvAxgAAAAA AAAADxAAAAAAAAAAAACAAAAAAAcAEwAPAAwEzgEAAA8AAvDGAQAAMAAI8AgAAAADAAAABowCAA8A A/BWAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACMAgAFAAAADwAE 8HIAAAASAArwCAAAAAOMAgAgAgAAUwAL8B4AAAB/AAAABACAAJTH+wO/AQAAAQD/AQAAAQABAwME AAAAABDwCAAAAOAKwAPQFDAPDwAR8BAAAAAAAMMLCAAAAAEAAAAQAPsDDwAN8AwAAAAAAJ4PBAAA AAEAAAAPAATwpAAAABIACvAIAAAAAowCACACAABzAAvwKgAAAH8AAAAEAIAAlM77A4ABAAAAAIEB AAAACL8BEAARAP8BAAABAAEDAgQAAFMAIvEeAAAAngH/////nwH/////oAEAAAAgocEAAAAApgH/ ////AAAQ8AgAAACgBQYBWhdwCA8AEfAQAAAAAADDCwgAAAAAAAAADwD7Aw8ADfAMAAAAAACeDwQA AAAAAAAADwAE8EgAAAASAArwCAAAAAGMAgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAR5AlwCU Ad69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAPAAXwAAAAABAA8AcgAAAA////AAAAAACWlpYA AAAAAADMmQAzM8wAzMz/ALKysgAPAIgTgQAAAA8AihN5AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLE1kAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAAAuRMA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gN9AgAAAgDvAxgA AAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwElAEAAA8AAvCMAQAA8AsI8AgAAAADAAAAA7AF AA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACwBQAFAAAA DwAE8HIAAAASAArwCAAAAAKwBQAgAgAAUwAL8B4AAAB/AAAABACAAGgAnQC/AQAAAQD/AQAAAQAB AwIEAAAAABDwCAAAAGAA1AGMFjADDwAR8BAAAAAAAMMLCAAAAAAAAAANAAQEDwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATwcgAAABIACvAIAAAAA7AFACACAABTAAvwHgAAAH8AAAAEAIAAHCmdAL8BAAAB AP8BAAABAAEDAwQAAAAAEPAIAAAA8APUAYwWEA4PABHwEAAAAAAAwwsIAAAAAQAAAA4AnQAPAA3w DAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABsAUAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJaW lgAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABU ADEAMAAAAIsTaQAAAAAA6y4IAAAAOl/CAaDdrEoAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAA AAAAAAMAAAAAAAAAAAAAAAAAAAAAuRMA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIr AAAAAA8A7gPTAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwE+gEAAA8AAvDy AQAAYAAI8AgAAAAEAAAABJwCAA8AA/CKAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAACcAgAFAAAADwAE8HgAAAASAArwCAAAAAKcAgAgAgAAYwAL8CQAAAB/AAAABACA AIApBAS/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAGAA1AGMFjADDwAR8BAAAAAAAMML CAAAAAAAAAANAAQEDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATweAAAABIACvAIAAAAA5wCACACAABj AAvwJAAAAH8AAAAEAIAAVCoEBL8BAAABAP8BAAABAAEDAwQAAIgDAAAAAAAAEPAIAAAAkANgAGAY wA8PABHwEAAAAAAAwwsIAAAAAQAAAA4ABAQPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBSAAAAsgQK 8AgAAAAEnAIAAAoAAEMAC/AqAAAAfwCAAIAABEEBAAAABcESAAAABgEBAAAAbgB0AHQAXwBsAG8A ZwBvAAAAAAAQ8AgAAAAsAQAA7gK4Ag8ABPBIAAAAEgAK8AgAAAABnAIAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBOBAAAADwCKE3kAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTWQAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAA AAAAAAAAAAAAAAC5EwD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuAws9 AQACAO8DGAAAAAEAAAANEwAAAAAAAAAAAIAAAAAABwATAA8ADAQyPAEADwAC8Co8AQAQDAjwCAAA AEMBAABDuQUADwAD8MI7AQAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA ALgFAAUAAAAPAATwfgAAABIACvAIAAAAArgFACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAAED8E BL8BAAABAP8BAAABAAEDAgQAAIgDAAAAAAAAEPAIAAAAAADpAaEW0AIPABHwEAAAAAAAwwsIAAAA AAAAAA0ABAQPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCfAAAAogwK8AgAAAADuAUAAAoAAJMAC/A2 AAAAgAAAQAQEhQACAAAAhwAGAAAAvwACAAIAgQH/zMwAvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAQ8AgAAAAjD+kHUwpDEA8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwUAAABKYXBhbgAAoQ8YAAAA BgAAAAAAAAgKAAEABwAGAAAAEQAAAJEADwAE8J4AAACiDArwCAAAAAS4BQAACgAAkwAL8DYAAACA AFxDBASFAAIAAACHAAYAAAC/AAIAAgCBAf/MzAC/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDw CAAAAMAJwAxFD+AKDwAN8DgAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAFUuUy5BLgAAoQ8WAAAABwAA AAAAAAAKAAcABwAAABEAAACRAA8AA/DaQwAADwAE8EwAAAABAAnwEAAAADAPAAAsBQAA6RQAAHwL AAACAArwCAAAAAW4BQABAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAPICfRKgF7EIDwAE 8NgCAAACAArwCAAAAAa4BQACCgAAAwEL8KgCAAAEAAAAAABCAegAAABDAUsBAABEAQQAAABFwRwB AABGwSYBAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ ARAAGACIAwAAAABHAEcA8P91AAMAhgAAAJEADQCTABwAlwAgAKAAHQC6ACgAwgAjAMwAIgDTACsA 2QA6AOIARADoAEkA5QBOANIAVAC8AGAAvQB0ALAAfwClAIgApACcAKQAqQCbALIAlACpAIgArACH ALMAhQDDAIkAyQCHANoAfwDhAHUA7gBxAPkAcwANAXsAGAF2AB8BYAAmAVgALgFXADcBVwBIAT4A SAEtAEsBGQA0AQ4ANAEFADQBAAAsAQUAIwERABMBFwACASQA7gAnAOMAIQDbABkA0wAXAM4AIQDL ACcAvwAcALwAEQDCABEAtAAXAKwAHACjAB8AmAAhAJAAJwCNADAAkwA+AH8ARgBxAFwAWABcAE0A aAA8AGsAKABwAB0AdQADAJAAlAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAMA8AABMJAAAYEAAAXgoAAA8AA/BkBwAA DwAE8FQAAAABAAnwEAAAAHcNAAC6CQAA9A8AANoLAAACAArwCAAAAAe4BQADAgAAIwAL8AwAAAAE AAAAAACIAwAAAAAAAA/wEAAAAIcPAACsCAAABBIAAMwKAAAPAATwagQAAAIACvAIAAAACLgFAAIK AADzAAvwOgQAAEIBZgIAAEMBIAIAAEQBBAAAAEXB6AEAAEbB8gEAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAHoAegDw/x8AagAcAGIA HwBXADAAOwAnADUAKwAsACEAKgAhAB8AJwAWAEQADgBaABAAXAAIAG0AAAB2AAMAiQAcAKgAKgDE ACoAzAAsABgBVwAuAVoAPwFqAFgBZABmAW0AdQF7AIUBewCRAX4AlgGDAJEBjACRAZcAvQG2ANYB ygDiAccA7wHEABoC2AAfAuYAJQLrADMC7gA7AvQARwL0AFIC9ABdAvcAYAL0AGYC/wBmAg0BXQIW ATECNwEdAjcB5QFFAdEBSAHRAVgBxgFYAboBYQGvAW8BpAF6AZYBfQGLAYsBiwGfAZMBqQGWAbIB lgHAAZMBxgGIAckBdwHXAWEB6wFYAfMBUwH4AVMBAQI6AQECKwEEAiABBwIbAQwCEgEXAgQBHQL8 AB0C6wAaAs8AFwKdAAQCiQABAnYABwJoAA8CVwARAkkAGgJAACACIQD+ASEAzwEUAL0BAwCwAQAA pwEAAJYBCACNAR8AhQEkAIABHAB0ARkAYQEhAFABMwA/ATMAMgEtACYBMwATATUAEAE9ABABRAAZ AUwADQFPAO4AZQDbAGUAzwBlAMcAfAC5AIwAtgCSALAAhACjAHkAjABzAIcAYwCPAFcAigBHAIMA QACHADsAgAA7AHYAMwBqAC0AZwAfAGoA9gD4AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBYACAAAAP8BAAAAB3DQAAugkAAN0PAADaCwAADwAE8MoAAAACAArwCAAAAAm4BQACCgAA 8wAL8JoAAABCARgAAABDAREAAABEAQQAAABFwRgAAABGwSIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAGAAYA8P8YAAAADQAAAAAA DAAGABEAEgARABgAAAAOABAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABK DwAAfQsAAGIPAACOCwAADwAE8PIAAAACAArwCAAAAAq4BQACCgAA8wAL8MIAAABCATUAAABDASoA AABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAALAAsA8P8nAAAAIgAFAAsACAAAABcAEAAiABkAKgAqACcA NQAiADIAFwAqAA4AJwAAABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAjw8AAFMLAADEDwAAfQsAAA8ABPDCAAAAAgAK8AgAAAALuAUA AgoAAPMAC/CSAAAAQgERAAAAQwEWAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQEG AAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAABQAFAPD/CwAAAAAA BQAJAA0AEQAWAAsAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAOMPAABW CwAA9A8AAGwLAAAPAAPwQggAAA8ABPBUAAAAAQAJ8BAAAACsEAAAygkAANkSAACKDAAAAgAK8AgA AAAMuAUAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAAC8EgAAvAgAAOkUAAB8CwAADwAE 8GIBAAACAArwCAAAAA24BQACCgAA8wAL8DIBAABCAVkAAABDAZIAAABEAQQAAABFwWQAAABGwW4A AAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACI AwAAAAAZABkA8P81AAAAJwAIABwAEQAQABQAAAARAAMAIgALAC0ACABKAAgAVwALAGMAAwB5AAUA igAQAJIAIQCHACcAhAA4AIcAQwB8AEMAcABRAFoAVgBMAFEAPgBZAC0AVAAUAFEABQA1AAAANAA4 AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAA AMAQAAA/CwAAGREAANELAAAPAATwggEAAAIACvAIAAAADrgFAAIKAADzAAvwUgEAAEIBpAAAAEMB ZwAAAEQBBAAAAEXBdAAAAEbBfgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAA AMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAB0AHQDw/5wAAACkAAkAnwARAJkAHgCQACcAkwBBAJkA VACKAFwAiABkAHwAZwBsAFcAYABXAFcASQBHAEEAOwA+ADAAOAAlAC8AEQAiAAkAHgAAABYAAAAM AAMAAwAUAAUALgAFADMADgBPAA4AYwAOAHwACQCcAAAAPABAAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAACPEQAA IwwAADMSAACKDAAADwAE8OoEAAACAArwCAAAAA+4BQACCgAA8wAL8LoEAABCAS0CAABDAXUCAABE AQQAAABFwSgCAABGwTICAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwx AADOAQAAAAD/ARAAGACIAwAAAACKAIoA8P+UAW0CnAF1AqoBbQK7AVYCwwE1AswBMgLSATcC3QEs AtoBHgLfARMC3QENAs8BAgLKAQICzAH8AcEB/wG7AfoBuwH0AcwB6QHUAd4B1AHMAd0BygH5AdgB BALbARIC7gEYAvoBIAL6ASkC7gEtAuMBIwLPARgCxAENAsQBDQLCAQcCwgHrAaUB3QGoAcwBkgHB AY8BsAF+AacBeAGtAXMBtgFwAaoBZwGcAW0BkQFnAXIBTgFvAUMBZAFAAVkBOAE9AfoANAHyAB4B 3gAFAbcABQGgABMBmAATAYwACAGCAAIBfAAFAXMAEAFuADIBZgBAAV0ASwFSAEgBNQBLASsAOgEo ABYBHwAQARcADgEUAA4BDAALAQMA9wAAAMcAAwDCAA8AsQARAKYAKACmADAAmwAoAIkAJQB/ACsA dgA7AGUAMABoAB8AYwAUAFcAFwBUACUATAAtAEMALQAcACgADgAzABEAQQAUAEwAAABdAAUAaAAL AG4AAAB8AAAAkAAFAJgAEQCYABcAngAcAKwAHAC6ACcAvQAwALoATwCbAFwAoAB4AK8AjAC9AI8A zgCbANkAoADtAKYACwGuABkBuQAlAc0ALQHeAEgB7wBfAf8AagEeAY8BNAGPAU4BpQFOAbwBVgHC AWcBtgFqAcIBagHPAXsB3gGAAeYBlwHgAZoB6QGXAfwBogENAqUBGwKqASkCpwE1ApwBQAKaAU4C kQFeApQBbQIWARgBAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACA AAAP8BAAAACsEAAAygkAANkSAAA/DAAADwAE8IACAAACAArwCAAAABC4BQACCgAAAwEL8FACAAAE AAAAAABCAeEAAABDAZMAAABEAQQAAABFwfAAAABGwfoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAA8ADwA8P92ABwAawASAGwADgBl AAgAXwAAAFgACABUAAUATAANAEwAEABCABUAKQApACIAMQAiADsAGQA+AAcAUQAHAFgAAABhAAMA agALAGUAEwBcACAAWgApAFwALABqACoAdAAwAHsANgCAAEUAgQBkAIUAawCBAG8AewByAG4AfgBu AIEAdgCBAIkAkACTAJoAggCmAH0AswB+ALwAgwDAAIgAwwB6AMsAaQDbAGYA4QBbANsAUgDUAE4A vwBLAL4AQAC+ADUAvgAsALEAJgCqACkAnwAgAJ0AGgCZABMAmQAQAI0ADQCIABIAgAAYAHYAHAB6 AHwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAChEgAAZAgAAIITAAD3CAAADwAE8KACAAACAArw CAAAABG4BQACCgAAAwEL8HACAAAEAAAAAABCAVYBAABDAZwAAABEAQQAAABFwQABAABGwQoBAAB/ AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAA AABAAEAA8P8AADgADgA3ABQANQAbAD4AJAA7ADAAPQA3AEIAQwA7AFMAPABZAEMAYwBFAGkAQAB6 AD0AggA9AI8AQgCeAEwAqgBHAKwAPQCkADAAoQAeAMcABADQAAQA0QANANwADwD1AAwA/wABAB0B AAAkAQ0AMAENADsBBgBOARIATgEnAFYBMABUAT4ATgFMAEQBTABAAVAARgFbAEYBZgBAAXAAMAF4 AC8BggAvAYwAIAGPAAYBjgD6AJEA5ACRANsAnAC4AJEApwCRAHsAiAB1AH0AdQByAHIAawBsAGgA UQBpACsAbQAnAGQAIQBhABUAXQAKAFoACgBQAAoAQAAAADgAggCEAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAFUTAABTCAAAqxQAAO8IAAAPAATwgAEAAAIACvAIAAAA ErgFAAIKAAADAQvwUAEAAAQAAAAAAEIBlgAAAEMBVwAAAEQBBAAAAEXBcAAAAEbBegAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAABwA HADw/w0AMAAcAD8AGABGABEATAAJAE0AAABPABAAVgAWAFcAKQBMAFIAVgBtADgAcwArAHgAJwCH ACkAlgAXAJUACwCKAAAAgwABAHwABABuAAEAYQABAFMABQBAAAQAOAAPABgABQAMAAUADAAYAA0A MAA6ADwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAA+RMAAOAIAACPFAAANwkAAA8ABPDgAQAAAgAK8AgAAAATuAUAAgoA AAMBC/CwAQAABAAAAAAAQgGeAAAAQwGMAAAARAEEAAAARcGgAAAARsGqAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAKAAoAPD/AAAZ AAQAFAACAA0AGgAAAB0ABAAuAAEAPAACADYACQA5ABIARQAWAE8AFQBYAA4AaAANAGwAEwB1ABgA ggAZAIAAIwCBADkAgwBGAJEARACWAE0AlwBVAJ4AXwCVAGcAjQBtAIQAbQB5AHAAeQB7AHQAgwBp AIwAVgB+AFEAcQBAAG0AOgBcAC4AUgApAEYAIAA6ABkALgAMACUAAAAZAFIAVAACAABAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABWEgAAVgcA APQSAADiBwAADwAE8CgBAAACAArwCAAAABS4BQACCgAAAwEL8PgAAAAEAAAAAABCASwAAABDATYA AABEAQQAAABFwUQAAABGwU4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAARABEA8P8fADYAIgAkACwAHgAsABUAJgAPACEABwAeAAAA FAAAAA0AAwANAA4ABwAYAAAAGwADACQADAAmABYAKAAbAC0AHwA2ACQAKAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAwRIAAMMHAADtEgAA+QcAAA8ABPBgAgAAAgAK8AgAAAAVuAUAAgoAAAMBC/Aw AgAABAAAAAAAQgGhAAAAQwGsAAAARAEEAAAARcHgAAAARsHqAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAOAA4APD/QwAEADIAGQAy AB8AKAApACoAKwAnADIAHQA7ABMARwAPAE0AEwBSABAAWwALAGEABwBkAAAAbQABAHUACAB6ABoA egAkAHQALwByADcAegBAAH0ASwB/AEgAjABMAKwAVgCrAFwAqgBeAKEAYACOAGcAhABnAHQAbQBq AHkAZACRAEoAlAA+AJAALACfACAAoQAMAJcAAwCQAAEAgwAAAGcAAABfAAYAWAAPAFkAFgBjAB0A agAlAGoAMQBfADkAUwA7AEsAPQBHADYARAAsAEoAJABIABoARwAQAEMABAByAHQAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAA AI0SAADwBgAALhMAAJwHAAAPAATw6AIAAAIACvAIAAAAFrgFAAIKAAADAQvwuAIAAAQAAAAAAEIB 5QAAAEMB0gAAAEQBBAAAAEXBJAEAAEbBLgEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAA CMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAEkASQDw/1UATwBSAFcAVQBjAFAAaQBJAGUA QQBmAEEAbwAwAH8AJgCCABkAkQARAJUACgCUAAcAlgAFAJkACACeAAgAqAAAALEAAwC6AAMAugAN ALoAEQCzABcAuQAPAL4AEgDHABcAyAApAMsALADNAD0A0gBDAM8AUgDHAGcAywCNAMsAogDHAKwA twC5ALEAvQCoAMEAmwDLAJQA0wB/ANIAZgDlAFsA2gBRANYAQADPADoAxgA6AL4ANQCvACMAtgAf ANAABwDNAAAAxQACAKkAAwCfAAoAmAAOAI4ADQCIABEAjQAYAJsAIQCRACMAeAAmAGcAHwBWABgA UAAcAEwAKQBNADAASwAzAEEANwBCAEQAQQBHADcAVABAAGEAQwBgAFUATwCUAJgAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAZRAAAOEFAABKEQAAswYAAA8AA/CwBwAADwAE8FQAAAABAAnwEAAAAGARAAD+ BgAAaBIAAMwHAAACAArwCAAAABe4BQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAHAT AADwBQAAeBQAAL4GAAAPAATwQgIAAAIACvAIAAAAGLgFAAIKAADzAAvwEgIAAEIBbQAAAEMBiAAA AEQBBAAAAEXB1AAAAEbB3gAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAADUANQDw/wgAdAAOAH4AGgB+ACUAgQAuAIgANwCIADEAfwA1 AHQAOwBnAD4AWQBLAFAAVQBKAFQAQgBUADQAVwAuAGEALQBlADAAbQAmAGoAHQBlABwAWwAcAFcA HABUAA8AVQADAE4AAABLAAQAOwABADcABQA7ABEAOQAcADIAFAAvAA0AJQAOACIAFQAfABgAHwAi AB0AIAAVABQAEAAPAAsAEgAMABkADAAdAAUAIAAFACoACwA0AAsAOwAIAEIAAABJAAEAUAAJAFcA DABeAAsAbAAIAHQAbABwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAABgEQAAKAcAAM0RAACwBwAADwAE8BoBAAACAArwCAAAABm4BQACCgAA8wAL 8OoAAABCAVMAAABDATQAAABEAQQAAABFwUAAAABGwUoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAQABAA8P8AADIABwA0AA8ALgAY ACQALgAkAEIAIABOABcAUQAMAFMAAABEAAcAKAAUACAAFQAYABwABwAfAAAAIgAAADIAIgAkAAIA AEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAAHYRAAD+BgAAyREAADIHAAAPAATw8gAAAAIACvAIAAAAGrgFAAIK AADzAAvwwgAAAEIBIwAAAEMBKwAAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/wsAAAAiAA8A IwAWABsAHgATACQAFQArAAsAKQABAB4AAAAWAAQADQALAAAAGAAcAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAChEQAAfQcAAMQRAACoBwAA DwAE8DIBAAACAArwCAAAABu4BQACCgAA8wAL8AIBAABCATUAAABDAT8AAABEAQQAAABFwUwAAABG wVYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAATABMA8P8yAAAANQADADIABgA1AA0AMQAWACkAHAAsACMAKQApACwALwAiAD8ADAAv AAAAJwAHACMABwAZABUAEAAcABMAIgAQAC4ACAAyAAAAKAAsAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAAM0RAABxBwAAAhIAALAHAAAPAATw2gAAAAIACvAIAAAAHLgFAAIKAADzAAvw qgAAAEIBFQAAAEMBGgAAAEQBBAAAAEXBIAAAAEbBKgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQ AMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAgACADw/wAAAAAOAAQAEwALABUA FQAOABoAAwAWAAEADwAAAAAAEgAUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB YACAAAAP8BAAAADHEQAAsgcAANwRAADMBwAADwAE8MoAAAACAArwCAAAAB24BQACCgAA8wAL8JoA AABCARAAAABDARYAAABEAQQAAABFwRgAAABGwSIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADA AQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAGAAYA8P8FAAAAAAAEAAAADwALABYA EAAMAAUAAAAOABAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABYEgAAqwcA AGgSAADBBwAADwAD8NAGAAAPAATwVAAAAAEACfAQAAAAzxAAAKUHAABSEgAAqwkAAAIACvAIAAAA HrgFAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAA3xIAAJcGAABiFAAAnQgAAA8ABPDK AAAAAgAK8AgAAAAfuAUAAgoAAPMAC/CaAAAAQgESAAAAQwERAAAARAEEAAAARcEYAAAARsEiAAAA fwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMA AAAABgAGAPD/AQAAAAAAAwABAAwACwARABIACgABAAAADgAQAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAFxIAANYHAAApEgAA5wcAAA8ABPCaBQAAAgAK8AgAAAAguAUAAgoA APMAC/BqBQAAQgGDAQAAQwEGAgAARAEEAAAARcGAAgAARsGKAgAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAoACgAPD/oAAAAJcABQCX AAsAmQARAJoAGQCcACQAlwApAJcAMACZADYApABAAKsAQgCuAFEAngBNAJYARQCPAEkAggBZAH0A XgB3AFwAdgBWAHIAUABmAEwAVQBMAFAAUwBHAFwATwBjAE8AcABNAHcASgB9AEAAhAA9AIUAPwCP AEMAlgBAAJ4AOQCoADEAsgArALkAIQDAABoAwwAVAM4AFADfAA4A6QAOAPcACAD+AAcAAgELAAkB DgAVARUAHgEBAC8BBQA5AQ0AQAEOAEEBDgBIAQQATwEAAFkBBABmAQoAbgEVAHIBIwB1ATEAdgE8 AHgBRQB+AU0AhQFDAIoBOwCSATMAmgExAKMBLQC3ASYAxAEhAM0BLQDcATAA4AE2AOYBPQDlAUYA 4AFKANwBTADaAVkA3AFeAOMBYgDsAWgA8wFwAPQBgQDzAYkA8QGUAPkBnQD2AaUA+AGtAP4BugD4 AccA+AHRAP4B2AABAuAA+wHoAPsB9wD4AQEB/gECAfsBDQECAhYBBgIgAQICIgH7ARsB8QEaAewB FgHbATwBwQFGAcEBSAG9AToBuAEwAa4BFwGYARQBhgEGAYMBBAFyAQEBZAH7AF0B/wBWAQIBUwEK AVQBIQFNAVMBNAFeAS8BaAEoAXEBMQF8AS0BfwEhAX4BGwGDARMBfQEKAXYB+gB7AeMAcwHYAHAB zQB0AcIAcQG5AGIBpwBqAZ0AagGLAGsBdQBaAWIAUgFXAEgBTQA5AUAALwE6ACgBOAAeAT8AFwFD AAEBVADxAFAA6gBQAOoASgDtAEIA8QA7ANwALgDWAC0AzAAkAMkAFQDEAAsAvQANALUAAwCqAAEA oAAAAEIBRAECAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAADPEAAApQcAAFISAACrCQAADwAD8FgI AAAPAATwVAAAAAEACfAQAAAA3A4AAHsIAAAcEQAAKQsAAAIACvAIAAAAIbgFAAMCAAAjAAvwDAAA AAQAAAAAAIgDAAAAAAAAD/AQAAAA7BAAAG0HAAAsEwAAGwoAAA8ABPD6AAAAAgAK8AgAAAAiuAUA AgoAAPMAC/DKAAAAQgEzAAAAQwFcAAAARAEEAAAARcEwAAAARsE6AAAAfwEBAAEAgAEAAAAAgQEG AAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAADAAMAPD/MwAAACIA EwAPABMAAAAfAAMALwADAEgADwBcABwAVwAfAEsALgAyAC4AJAAzAAAAGgAcAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA6RAAAM0K AAAcEQAAKQsAAA8ABPDyBgAAAgAK8AgAAAAjuAUAAgoAAPMAC/DCBgAAQgFAAgAAQwE1AgAARAEE AAAARcEsAwAARsE2AwAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAA zgEAAAAA/wEQABgAiAMAAAAAywDLAPD/CgBQAA8AXgAKAGkACABtAAAAagADAHEAAwB4AAoAgwAX AIAAJwCSAC4AngA4AKcARQCnAEoAsgBVALwAXAC9AF4AwgBaAMsAWgDTAFgA2wBVAOoAYQD3AG4A AQFuAAgBbAAgAWkANAFsADwBdwBFAXcAVQF3AGEBawBQAWQARQFfAEgBYgBQAV4AWgFXAGQBUgBr AVgAcQFUAHkBSgCDAUkAiwFDAJUBNACnASsAuQErALwBMADCASoAygEsANQBNQDhAVgA9AFxAAoC egAHAocAAgKyABQCuAAaArwAJgLDACoCzQArAtwAMwL1ADUC/QArAv8AIAL/ABQCCgEKAiAB/gEp Af0BNQH3AT8B9wFKAf4BUgEIAlwBCAJlAQoCdQEMAoEBGgKKASECmQEmAqUBLQKsAS4CvAEdAsgB GgLQARQC3AEKAuwBCgLrAfYB6AHwAeEB5gHbAegB1QHmAdAB3gHPAcoB2gG9AdIBswHSAa4B4gGd AeIBlwHfAYMB6QF5AeEBbgHhAWUB3wFXAdsBUwHSAVMByAFVAcYBWAHAAV4BuAFhAbUBWAG7AVIB vgFMAb4BRQHNATYB1QEzAdcBJwHfAR0B9wELAf4BCwEBAgQBCgL8ABAC/AATAvcAFwL0AB0C6wAj AtsAJALSACQCyQAsAr8AOQK4AEACsQBAAq4ANQKmAC8CowAfAqEADAKeAAUCnQD+AZoA9wGTAPEB iADsAYEA5QF+ANwBewDYAXoAzQFwAL8BZAC2AVoArQFXAKgBUgCjAUgAlwE5AJQBLwCKASYAhgEd AIEBFgB3AQ8AbQEEAGUBAABPAQEARwEBADwBCQBCARAAOgEaACUBNQAaATsA/QA+APAAQgDpAEgA 5gBOANsASwDJAE4AvQBNALMARgCsAD4ApgA7AKsANACjACwAnAArAJYAKgCVACwAmgAyAJcANgCa AD8AnABIAJwAUACaAFEAlQBVAJMAXACTAGQAkgBpAIoAZwCAAGIAegBnAHAAYQBrAF8AZABkAF4A ZABeAF8ARgBIAEAASAA8AEsAMwBQACwAUQAmAEoAFQBKAAoAUACYAZwBAgAAQACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAANwOAAB7CAAAHBEAALAKAAAPAAPw0AoAAA8ABPBUAAAAAQAJ8BAAAADiDgAA OgYAADcQAAB1CAAAAgAK8AgAAAAkuAUAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADy EAAALAUAAEcSAABnBwAADwAE8NIFAAACAArwCAAAACW4BQACCgAA8wAL8KIFAABCAVUBAABDATQC AABEAQQAAABFwZwCAABGwaYCAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAACnAKcA8P9mAGoBdgB4AW8AhgFlAJEBVQCZAUkAoAE8AKEB NgCnAT8AtwFPALcBVQC5AVUAxAFeAMQBZADBAWgAzQFwANYBfgDWAYgA0wGRANYBewDpAXMA7QFo AOkBTwDfAUIA3wE2AOkBJwD1AR8A/AEVAP8BCgAFAgEACwIAABACCgARAhEAGAIaAB0CJAAYAi0A FAI2ABUCRQAeAlMAJAJcAB4CYQATAnAACgJ6AAoCgwAUAooAGgKVABoCpAAbAq4AHwK4ABgCwAAY AskAHQLSACcC3wApAu4ALAL4ADECBAE0Ag0BLwIaAScCIwEmAi0BJAI2ARsCMAETAiABCgIaAQUC GgH/ASEB+QEtAfgBOAHyAUoB3wFSAdUBVQHEAVUBugFNAbMBQgGrATgBpwEtAagBJgGsASMBpQEp AZoBKwGRASoBggEpAW0BLQFcASoBUwEjAUYBEgEpAQsBGwEIAQsBBwEBAQsB8AALAeMACAHVAAEB zgD0AMEA6wC9AOEAvADaALoA2gCzAN4ArgDpAK0A8wCwAPoAsgD+AKsA/QCjACYBfQAtAXQALQFj ACMBWwAXAVkADQFKAPoASgD6AEoA6ABNAOQATADfAEUA6AA/APAANgABAScADwEmABwBHAApARIA DAELAAABCgDxAAgA4QAAANIAEADSABkAygAcALwAJACwACkAsAA1AK4APwCjAE8AkQBiAIoAbACN AHMAoABxAKEAdQChAH0AiACdAIAArgB6AL0AgADEAIsAtgCXAKYAnwCrAKAAwwChANIAkgDbAIgA 5QCFAO0AmQD+AKoA+wCuAAQBwAD5AL8AAgGwABQBtgAoAbgAMwHIADQByQA+AbYAVAGwAFEBqQBY AacAYwGVAFkBZgBqAVABVAECAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAWAAgAAAD/AQAAAA4g4AAEEGAAA3EAAAdQgAAA8ABPDSAAAAAgAK8AgAAAAmuAUAAgoAAPMA C/CiAAAAQgEcAAAAQwEVAAAARAEEAAAARcEcAAAARsEmAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQ ABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAABwAHAPD/DwAAABsAAgAcAAkA DwASAAIAFQAAAAwADwAAABAAFAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAABdDwAAUgcAAHkPAABnBwAADwAE8NIAAAACAArwCAAAACe4BQACCgAA8wAL8KIAAABCARwA AABDARQAAABEAQQAAABFwRwAAABGwSYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjE AQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAHAAcA8P8XAAAAHAAKAA4AEQADABQAAAAKAAUA BAAXAAAAEAAUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAEoPAADO BgAAZg8AAOIGAAAPAATw2gAAAAIACvAIAAAAKLgFAAIKAADzAAvwqgAAAEIBEAAAAEMBJwAAAEQB BAAAAEXBIAAAAEbBKgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEA AM4BAAAAAP8BEAAYAIgDAAAAAAgACADw/wYAJwAQAB0ADAAQAAkACgAGAAAAAAAEAAMAEgAGACcA EgAUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB0DwAAZwYA AIQPAACOBgAADwAE8BIBAAACAArwCAAAACm4BQACCgAA8wAL8OIAAABCAUoAAABDAUsAAABEAQQA AABFwTwAAABGwUYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADO AQAAAAD/ARAAGACIAwAAAAAPAA8A8P8aAAAAKwAAADcAAwBAAA8ASAAiAEoAMwBBADsAPgBHADYA SwAuAEEAJgAuACEAKAASACYAAAATABoAAAAgACQAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAADDwAAAQcAAE0P AABMBwAADwAE8OIAAAACAArwCAAAACq4BQACCgAA8wAL8LIAAABCASYAAABDARwAAABEAQQAAABF wSQAAABGwS4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAA AAD/ARAAGACIAwAAAAAJAAkA8P8iAAAAJgAHABgADwAKABwAAgAZAAAACgAAAAUAFwAAACIAAAAU ABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABvDwAA OgYAAJUPAABWBgAADwAE8PAQAAACAArwCAAAACu4BQAACgAAAwEL8MgQAAAEAAAAAABCAc8JAABD AfEFAABEAQQAAABFwSwIAABGwTYIAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAA AADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAALAgsC8P90CQkAZwkAAFkJAABQCQEASgkMAD8JCQA3 CQwAMQkbAB8JPQAoCVIAIQlrACcJdgAmCYoAIwmcABgJnwAPCZUA/gi9AN0IxQCyCNIAkwjaAHsI 7wBqCAYBXAgHAUwIIAFTCCkBVwg9AU8IRAFECFMBOAhXATQIYQEfCGQBAghlAesHcwHuB4kB5wec AdQHtQG8B8wBpAfVAZ0H5wFsB/sBUQf1AUwH7wFYB+MBWQfTAVAHxQFaB74BaAfBAWYHowFjB4sB Wwd1AU4HagE8B2UBLgdvASEHgQETB30BGAd0AR8HbwEoB2kBNQdZASsHOgEoByEBEwcdAe0GBgHX BhAB0wYbAdgGJAHNBikBzAY7AcIGOwGyBkoBrAZVAacGYQGmBn4BowaeAasGsAG2Bs4BtgbzAawG HAKaBh8CjgYYAoQGCQJ5BvMBewbWAXsGwwFyBrEBdAaNAXgGcAF6BmEBjAZIAYIGPQF5BkIBcwZQ AV4GZgFqBlQBawZHAWcGOAFqBioBcwYdAXUGCgF5BgABfQYRAY8GEgGaBgcBrAb/AMAG/QDIBgQB 1wYBAe4G/AD6BvsA/AbxAP4G8QD0BuYA5wbgANEG2QC+BtkAsgbXAKwGzwCWBswAggbQAHQG0gBk BuAAUAbXAEAG0AAtBtkAIAbTAC4GvwAqBrgAIga7AA8G0gAABuQA8QX4ANwF9gDTBd8AywXgAMQF 8QCrBfIAxgXQAAUGqQAJBp8A5gWhAMIFlAC1BaUAmQWbAIcFogB7BY4AXAWPAFMFmAAwBYIAKwVt AAMFZQAVBYIAxQJvAKECZgBiAl4AEgJSAK4BSQCIAUIAUgE5ACsBMADDABIAvAAVAL8AIwDFADMA wAA6ALkAQQC9AEwAzABlAMAAdgC5AIsAqACLALYAgQC7AHYAuABrAK8AaACzAGAAvwBjAL8AXQC3 AEoArgBJAJsARgCMADgAggAxAHYALABuADkAcwBOAHYAXwB0AHQAcwCHAHYAjgB9AJwAdgCmAHcA rwB4AL4AbQDDAGUA5QBdAAMBUQAiAUIAOgE0AFkBJgBsASYAmwEmAMUBIADVARIA8AEAAA0CEgAy Ag0AUAIIAGUCFwCKAiIAogIyAKwCQQCbAkYApgJKAK8COwCxAjwAvAIuALUCMADMAjYA4AI5AO8C TADsAkkA8wI5AP4COQAWA08ALgNYADYDUgBAA1kATgNdAF8DYwBqA2YAdwNnAIQDYwCNA3IAkQOA AJIDjACPA5sAkQOfAJ0DogCnA7EAtwO4AL4DvwDLA8AA0wPOANsD2gDmA+cA+gPpABIE6AAfBPUA IQQDAR4EEQEdBCYBHgQ6AR8EVQEfBGcBIQRqASwEZgE3BHwBRQSSAVAEvAFmBNsBdwT9AYQEIAKQ BDcCkgRLAo8EagKTBH4ClgSUApQEqQKZBLsCmAS9An8E3QKDBAMDhAQhA6cERQPFBFoD3ARbA/AE YgMGBXADFQV/AyMFqwM+BboDOgXDAzIFyAMiBcwDFQXdAxQF8AMVBQgEGgUWBCQFKAQsBS4EOQU3 BE4FQARiBUoEcgVcBH0FawSNBXEEpAV3BLcFgwTWBZQE2QWnBOEFugTmBdME5wXhBPEFAwXvBQUF 1wXyBMYF7wSsBfwEmgX7BIcFAAWCBQIFdAUOBWwFJAVdBTAFXQVLBUwFXAU8BXcFLAVwBRcFdgUS BX4FKAWjBQgFwQUJBeoFEgUKBg0FGQYLBREG/QQfBv8EKAYKBSgGFAVGBhYFVQYXBVsGEQVoBhwF cgYfBX4GHAV1BgsFgwYKBYwGDwWZBhkFogYWBasGDAWlBv8EmAb6BJAG8wSWBuUElQbYBIgG2AR8 BuUEegbTBGoG3QRbBuIEVgbZBGIGygSMBtIElQbCBKoGvATCBsIEywa8BMsGqATXBsEE2wbKBO0G wAT7BrAEAge6BA4HvgQhB7YESQevBFEHuARbB8MEawfGBHsHyASOB8EEmge1BKUHsQSsB7YEtgfB BMUHzgTTB9IE3wfUBOwH4QT0B/AE/gf6BPoHDwX7ByAF+wcsBf8HNQUFCDcFCQglBRIILwULCD0F CQhJBREITwUhCF8FLghiBTUIdgU9CHoFSQiQBVkImAVoCJ4FcwiwBYkIrAWnCKUFrwiEBaoIbwWq CEoFogg/BZMILQWGCBkFeggABW4I4wRcCMgETQi1BDsImgQuCIMEKQhvBCcIYAQqCFMELQhOBC4I LgQ/CBEEOwj/A1UI+AN2CNgDhwikA7EIkgPKCGID8whTAwcJLgMHCRQDCAn9Av4I/gL+CCQD5QhA A8MIRwPkCDYD0QguA+QIKgPwCCsD9ggVA/QIAQPiCAEDxwgLA8gI+ALXCAAD7gj1AvEI6wLhCOUC 4wjOAtEIxQLLCM0CxQi9AscIqwLKCJkCqgiMArMIiAKrCGECqghKArAIRAKxCGQCvQh6As8IjwLP CLcC4wi6AvMIkgLyCFgC3QhIAt8IPAL4CEkCBQkrAgYJEgIGCecB+gjZAQAJzgEJCdoBPQm/AWEJ ogFGCZ8BHwm2AQYJwAEYCaoBKQmfATMJowFPCZQBVQmGAV0JhgFoCX8BdAlxAYkJeQGUCW8BnQlh AZQJTwGHCUQBfwlDAXUJSAF/CVcBhAlgAXgJXwFrCU4BXglRAWEJRAFnCTYBXAk0AWUJGQFiCQkB bwn9AGgJ7AB0CeQAggnaAI8J1QCUCboAogm6ALUJrQC/CZ8AzwmSAM0JgAC3CXcAqgllAJIJZQCI CVAAhQk5AH4JJAB0CQkAGAQcBAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAFgAIAAABDwCAAAADYDcQtaEVoHDwAD8GSEAAAPAATwTAAAAAEACfAQAAAAiAAAAN8CAAD5 CQAAqwwAAAIACvAIAAAALLgFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAAigPwACsL Vg0PAAPwjgsAAA8ABPBUAAAAAQAJ8BAAAABiCwAAdwgAAC0MAACRCQAAAgAK8AgAAAAtuAUAAwIA ACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADfBgAAyggAAOoHAABhCgAADwAE8AIBAAACAArw CAAAAC64BQACCgAA8wAL8NIAAABCATsAAABDAVQAAABEAQQAAABFwTQAAABGwT4AAAB/AQEAAQCA AQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAANAA0A 8P8tAAAAOwAEAC0ALAAgADAAGgA6AA4ARQAKAFQAAABLAB4AJwAfABsAIwAbACUACgAtAAAAHAAg AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAGILAAAOCQAAnQsAAGIJAAAPAATw+gAAAAIACvAIAAAAL7gFAAIKAADzAAvwygAA AEIBGQAAAEMBHAAAAEQBBAAAAEXBMAAAAEbBOgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMAB BwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAwADADw/w4AAAABAAAAAAAGAAAACwAQ AAwACgATAAkAGQAPABwAFwAYABkADgAVAAYADgAAABoAHAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAKALAADwCAAAuQsAAAwJAAAP AATwwgAAAAIACvAIAAAAMLgFAAIKAADzAAvwkgAAAEIBDQAAAEMBEQAAAEQBBAAAAEXBFAAAAEbB HgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAY AIgDAAAAAAUABQDw/wEAAAANAAQACAARAAAADQABAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAADwCwAA1AgAAP0LAADlCAAADwAE8EoBAAACAArwCAAAADG4BQACCgAA8wAL 8BoBAABCASYAAABDAT0AAABEAQQAAABFwVgAAABGwWIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAWABYA8P8KAAAAFwAGAB8ABwAf ABgAJgAjABUAIwAUACwAGwAxABoANAAMAD0ADAAwAAkAMAAIACgAAAAhAAEAIAAHABsADAAcAAcA FwAIABIAAQARAAMABwAKAAAALgAwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAPULAAD1CAAAGwwAADIJAAAPAATwAgEAAAIACvAIAAAAMrgFAAIKAADzAAvw0gAA AEIBMgAAAEMBOwAAAEQBBAAAAEXBNAAAAEbBPgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMAB BwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAA0ADQDw/yAAAAAnAAUAMgAKADEAEwAg ABMAJgAcABwAIgAVAC0AAAA7AAgAEQAaABEAGgAGACAAAAAcACAAAgAAQACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAvwsAAPwIAADx CwAANwkAAA8ABPBSAgAAAgAK8AgAAAAzuAUAAgoAAPMAC/AiAgAAQgFmAAAAQwF+AAAARAEEAAAA RcHcAAAARsHmAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAANwA3APD/FAAIACAABgAvAA0ANAAJADQAAAA7AAwAQgATAD0AGQA9ACAA QwAsADwAMwA8AEIAMABCADAASQA0AE8APQBPAD0AVQA1AFsAMABaADUAYABBAGEATwBaAFgAZQBg AGsAYgB3AGYAeABmAH0AWwB+AFYAeQBPAHgASQBzAEcAegA8AH4APAB3AEIAcwA9AGsAGQByABcA aAAfAGMAHgBaABkAWwAFAE4ABwBGAAAAQgABADYACAA2AAUAPwAKAEMAEgBCABEAMAALAC4ACgAl AAcAHwARAAAAFAAIAHAAdAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBYACAAAAP8BAAAACKCwAAdwgAAPALAAD1CAAADwAE8LoAAAACAArwCAAAADS4 BQACCgAA8wAL8IoAAABCAQwAAABDARIAAABEAQQAAABFwRAAAABGwRoAAAB/AQEAAQCAAQAAAACB AQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAEAAQA8P8AAAAA DAAJAAQAEgAAAAAACgAMAAIAAEAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAABQMAAAeCQAAIAwA ADAJAAAPAATwygAAAAIACvAIAAAANbgFAAIKAADzAAvwmgAAAEIBCQAAAEMBFwAAAEQBBAAAAEXB GAAAAEbBIgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAA AP8BEAAYAIgDAAAAAAYABgDw/wMAAAAJAAoACQAXAAMAEQAAAAsAAwAAAA4AEAACAABAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACIMAAApCQAAKwwAAEAJAAAPAATwCgIAAAIACvAI AAAANrgFAAIKAADzAAvw2gEAAEIBZgAAAEMBWgAAAEQBBAAAAEXBuAAAAEbBwgAAAH8BAQABAIAB AAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAC4ALgDw /0gAAABTAAAAUwAGAFkABgBgAA0AYQAUAGYAHQBmADUAXwA+AF8ARwBYAEcAWQA7AEwAPABMAD8A UwBBAFMATQBMAFIASQBaAEIAUgA5AFIAMQBJACkAQAApAD4AMQA1ACkANgAmADAAIwA1ABMANwAS ACwACwA2AAwAPwAFAEcAAABBAAAALgAHACkADwAoABIAJAAXACIAHQAdACkAHQAuACIALwAdADoA HgA6ABEASAAMAEgAAABeAGAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAxwsAADcJAAAtDAAA kQkAAA8AA/BiDgAADwAE8FQAAAABAAnwEAAAAPUKAACrBAAAxwsAAEAHAAACAArwCAAAADe4BQAD AgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAIgGAABTAwAAmwcAAAwHAAAPAATwCgEAAAIA CvAIAAAAOLgFAAIKAADzAAvw2gAAAEIBDQAAAEMBFgAAAEQBBAAAAEXBOAAAAEbBQgAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAA4A DgDw/wIADgAEAAoABQAEAAYAAQALAAAADQAFAAsADgAJABIACAAVAAUAFgACABYAAgAUAAAAEgAC AA4AHgAgAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAAB0CwAAogYAAIELAAC4BgAADwAD8OwMAAAPAATwTgAAAAEACfAQ AAAA9QoAAKsEAADHCwAAQAcAAAIACvAIAAAAObgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA 9QoAAKsEAADHCwAAQAcAAA8ABPByAgAAAgAK8AgAAAA6uAUAAgoAAPMAC/BCAgAAQgFnAAAAQwGP AAAARAEEAAAARcHsAAAARsH2AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAA ywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAOwA7APD/RgAAAEsADgBGABYAPwAWADsAHAAqACMAFwAg AAUAIQAAAB8AAAAnAAQALQAJADUAEAAzABMANwAXADcAGwBBACIARgAfAEwAJwBUACUAXgAZAGMA HABoACIAbgAlAHMAJwB9AC8AhgA1AIIAOwCLAEEAjwBDAI4ARACGAEMAfgBHAHsASQBzAEAAcQA2 AHYALQB2ADEAbQA4AG0APwBnAEEAXABKAFkATgBWAFoAVwBbAFQAYwBRAFoARgBWAEAAWQA3AFkA LwBhACYAXwAhAGMAIABjABgAZwAUAGIAEABfABAAUgAHAEYAAAB4AHwAAgAAQACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAA AA/wEAAAAPUKAACrBAAAXAsAADoFAAAPAATwKgQAAAIACvAIAAAAO7gFAAIKAADzAAvw+gMAAEIB jwAAAEMBQwEAAEQBBAAAAEXByAEAAEbB0gEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAA CMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAHIAcgDw/yMADAAtAAoANQAOADwADgBFABMA SgAcAFAAIABRACoAVAAyAF4AOgBTAD4AWABCAFsASABwAFgAcQBgAHYAawB9AHIAigB3AIcAggCP AJEAjgCWAHoAlgB6AJ4AdgCkAHYAqQB4ALMAdgC8AHMAwwBuAMkAZwDSAGsA2wBjAOEAaADpAGkA 8ABrAPwAaAACAWAA/wBaAAEBVAD8AFAA9gBPAO8ASgDrAEQA8QA9APYANgD8ADYABQExAA8BLQAV AS0AGwElACABHAAmASQAMgEfADgBFwA3AQ0AQwEJAEMBAABAAQwAIwEJABIBDgAHAQ4A/wAUAPoA FwD9ACEA8wAlAOUALQDfADAA1gA1ANoAPQDRADsAyQA2AMYAMgCqACsApAAoAJ0AKQCWAC0AkAAw AJIAMACeADYAoQA5AKMAPQCgAD4AmQA+AJIAQwCNAEIAfwA9AG0AQABjADwAWwA2AFUANgBPAC8A RgArAEAAKgA5ACQANgAdADsAGgA3ABYALwAUACoADgAtAA0AJgANAB8ABwAXAAkAEgARABIAFgAV ABcAEAAbAAsAFAAGAA8ACwALAAoADQACABMAAAAaAAUAIwAMAOYA6AACAABAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAADgL AAAkBQAAxwsAAGcGAAAPAATwggEAAAIACvAIAAAAPLgFAAIKAADzAAvwUgEAAEIBJAAAAEMBPwAA AEQBBAAAAEXBdAAAAEbBfgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAAB0AHQDw/yIABQAYAAAAFAADAA8ABAAMAA0ACQAQAAgAGQAG AB8AAAAiAAIAKQADAC8AAAA3AAMAPAAHADcACgA8AA4APwASAD4AGAA+ABsANgAXADMAFwAoABQA IgAZAB0AHAAbACEAGgAkABgAJAATAB8AEAAiAAUAPABAAAIAAEAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABoCwAAKQYA AIwLAABoBgAADwAE8IIBAAACAArwCAAAAD24BQACCgAA8wAL8FIBAABCAUIAAABDAToAAABEAQQA AABFwXQAAABGwX4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADO AQAAAAD/ARAAGACIAwAAAAAdAB0A8P8cAAAAEQAFAAwABQAJAAwABwAUAAUAFwAHABwAAAAiAAYA KAAOACsAFAAlAA4AFwAZABgAIgAaACUAIAAmADMALAA4ADEAOgA3ADYAOQAyAEIALABBACUAPAAi ADgAFwA1ABEAMwAHADEAAAApAAMAHAAAADwAQAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAOAsAAG0GAAB6CwAA pwYAAA8ABPDaAAAAAgAK8AgAAAA+uAUAAgoAAPMAC/CqAAAAQgENAAAAQwELAAAARAEEAAAARcEg AAAARsEqAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA /wEQABgAiAMAAAAACAAIAPD/BwAAAAEAAQAAAAgAAwAKAAkACwANAAcADAACAAcAAAASABQAAgAA QACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGILAAC1BgAAbwsAAMAG AAAPAATwCgEAAAIACvAIAAAAP7gFAAIKAADzAAvw2gAAAEIBNAAAAEMBOgAAAEQBBAAAAEXBOAAA AEbBQgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8B EAAYAIgDAAAAAA4ADgDw/wUAJQAOABkAFQALABcAAwApAAAANAANACwAJQAjAC4AHgA2ABEAOgAF ADoABQA1AAAAMAAFACUAHgAgAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABhCwAA1gYAAJULAAAQBwAADwAE8NoAAAAC AArwCAAAAEC4BQACCgAA8wAL8KoAAABCARoAAABDARgAAABEAQQAAABFwSAAAABGwSoAAAB/AQEA AQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAI AAgA8P8OAAAAAwACAAAAEgAFABcAEwAYABoADgAZAAMADgAAABIAFAACAABAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAXQsAACgHAAB3CwAAQAcAAA8ABPBABgAAAgAK 8AgAAABBuAUAAgoAAAMBC/AQBgAABAAAAAAAQgF1AwAAQwEsAwAARAEEAAAARcHQAgAARsHaAgAA fwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMA AAAAtAC0APD/dQIAAEcCKgBYAjAAVwJXAF0CbAA/AoIATAKsAGoCnQB6Ap0AcwKyAGgCyABhAt4A WwLwAE4C+wA6AvoAOQIQAUQCGQE8AjoBMAJBARcCWgECAmsB3AFwAZwBcAGOAXgBewGDAWsBdAFY AWsBSgFkATgBXwEKAV8BCgFOAQEBNQHuAC4B0QAoAcgAHgGzACwBrQBJAYoATgFnAMABbADGAVIA zwFBANkBMgDiAR8A4gEQAO0BAAD7AQsAEwIZACMCHwArAhIALgIlAFACXgBQAngAZgJrAHICYAB4 Al8AhgJaAJkCYACoAm4AvwIgAeMCLwHhAjYB4wI8AdsCPwHSAkkBzAJjAdgChAG8ApkBoQKuAbMC uAGyAsMBuQLbAa4C5wG6Au4BygLuAeYC6wH8AusBDgP7AQYD/QEAAygCLANBAgsDTgIGA2UC/QJ1 AvQCggLzApEC6AKWAugClwLtAqYC9AKyAvQCvALxAsoC7ALgAuwC4AL6AuQC/gLsAv4C9AL2Av0C 6AIPA+ICFgPhAhwD2wIaA9ECIgPEAhsDuQIiA6cCLgOmAj4DoAJRA5ECVgOGAl0DcgJnA1ICaQNA Am0DLgJ1AxACbQP+AW0D5wFoA9cBXAPRAVwD3QFRA9wBUQPQAVcDxAFXA7gBSgO/ATkDvwE0A7kB PQO3AUYDrQFWA60BSQOgATEDmwEcA5EBEgOEAQoDfAEKA2UBEQNcARUDVAEhA0kBIgM9ARwDOwET A0MB+AJIAfcCVAHyAmEB0wJOAc4COgHUAiwB2QIYAeECCQHsAv8A9wILAfcCHQH9AigB/wIvARYD CwEWA/kAHAP2ABwD6wAhA9cAHQPJACQDwAA7A7kAJwOuADQDnQA9A4gASgONAEsDhABDA3oALgNf ACgDVAA4A0cANAMYACEDAQAVAwEAEQMjAP0CKwDlAhcAtgIrAJcCCwB1AgAAagFsAQIAAEAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9wEAAPgDAAB/BgAAjQgA AA8ABPBAAQAAAgAK8AgAAABCuAUAAgoAAAMBC/AQAQAABAAAAAAAQgFVAAAAQwFHAAAARAEEAAAA RcFQAAAARsFaAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAAFAAUAPD/AAAAAAAACQAIABEAGAAYACEAIQAvAC0ANwAwAEgAQQBTAEcA UgBDAFUAQQBIADsARAA1AFAAMwBFACwAOwAlACoAHAAgABAAEAAGAAAAAAAqACwAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAP4FAAAEAwAAbwYAAGgDAAAPAATwYAEAAAIACvAI AAAAQ7gFAAIKAAADAQvwMAEAAAQAAAAAAEIBKAAAAEMBYAAAAEQBBAAAAEXBYAAAAEbBagAAAH8B AQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAA ABgAGADw/xIAAAAHAAUAAAASAAAAIwAAADcABABIAAwAUQARAFUAFwBdACAAYAAjAFsAHQBTAB0A TgAlAEUAKAA9ACUAMgAhAC4AIgAhABwAHQAaABkAHwAZAB8ADwAcAAoAEgAAADIANAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAFwGAAAYBwAAkQYA AKEHAAAPAATwUAEAAAIACvAIAAAARLgFAAIKAAADAQvwIAEAAAQAAAAAAEIBNwAAAEMBQQAAAEQB BAAAAEXBWAAAAEbBYgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEA AM4BAAAAAP8BEAAYAIgDAAAAABYAFgDw/ywAAQAmAAgAGQAMAA4ADwAIABQABAAZAAAAJAACACoA CgAzABMAOgAbAEEAIgA+ACkAOAAtADMAMQApADQAHgAzABoANwAUADcADAA1AAQAMwAAACwAAQAu ADAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAbwUAAE0IAAC4 BQAArAgAAA8ABPCAAgAAAgAK8AgAAABFuAUAAgoAAAMBC/BQAgAABAAAAAAAQgHUAAAAQwFBAQAA RAEEAAAARcHwAAAARsH6AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGc MQAAzgEAAAAA/wEQABgAiAMAAAAAPAA8APD/fwAIAHUADABoAAwAWgAFAFoAAABTAAAAQgAMADcA DAAfABgAAAAkAAwAMQAlADwAJQBCADAAQwA2AD0AQgBJAEcASgA8AFMAQgBmAFIAawBqAHUAeQCE AIoAigCPAI8AmgClAJwArAClALYAqwDAAK4AxgCoANYAnQDnAI8A8ACSAPcAlQD6AJUAAgGJAAkB hAAUAYQAGgGLABgBhAAjAYkAQQGSAEABowAoAagACAHLAPgA0gDlANQAzADPAMQA0wC/AMUApwC4 AJoAtACPAKwAiACjAIEAkAB3AHwAbABtAGMAYQBZAGsALwB/AAgAegB8AAIAAEAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAsAQAACwIAADFBQAA+QkAAA8ABPDIAQAAAgAK8AgAAABGuAUAAgoAAAMBC/CY AQAABAAAAAAAQgGyAAAAQwGaAAAARAEEAAAARcGUAAAARsGeAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAJQAlAPD/GAAAACIADQA7 ABcAOwAeAEYAHgBMABkAWAAkAF8AJQBTAC8AWABAAGgARgCBAFEAjwBfAKAAZQClAGsAqwB1ALAA fwCyAIkApwCJAJoAjwCaAJoAjgCaAIkAkACIAIgAfAB9AHwAdgBwAHYAaABwAGkAXwBjAFkAIgBT ACEATgAWAEwABQA7AAsAJAAAAB8AGAAAAEwAUAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAADKBAAAYAgAALMFAAA8CQAADwAE8HABAAACAArwCAAAAEe4BQAC CgAAAwEL8EABAAAEAAAAAABCAXcAAABDAW0AAABEAQQAAABFwWgAAABGwXIAAAB/AQEAAQCAAQAA AACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAaABoA8P9m AAAAWwAAAEwABwBMABEAMgARAAAAKwAAADYADAA+ABcATgAcAGUAJABlAC8AbQA0AGYAQQBtAE0A bQBNAGcAUgBdAF4AVgBfAE8AWwBJAFkAQwBmADwAcQAqAHcAGQBtAAkAZgAAADYAOAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9wQA ACIJAACUBQAAvgkAAA8ABPAYAgAAAgAK8AgAAABIuAUAAgoAAAMBC/DoAQAABAAAAAAAQgG1AAAA QwE7AQAARAEEAAAARcG8AAAARsHGAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEA AAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAALwAvAPD/KwAAADwAEgBHABMASQAZAIgAHgCQACQA jwA2AJYAPACiADwAowBCAK8ATwCvAFYAtQBgAKYAYAB0AHkAdACEAH8AiwCKAJsAkACzAHQAoQBQ ALkATQD0AFUA7wCdADABlAA7AX8AKwF6ADEBcwAxAUcADAE8ABUBPADfAEMA0gBCALMAPACmAD4A mwAmAIsAHgB/AB4AbAAmAGYAIABcAAAAPQAHADcABwAgABcAIAAdABUAHgAAACsAAABgAGQAAgAA QACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAJkEAACxCAAAhwUAAHYKAAAPAATwSAIAAAIACvAI AAAASbgFAAIKAAADAQvwGAIAAAQAAAAAAEIBsgAAAEMBegEAAEQBBAAAAEXB1AAAAEbB3gAAAH8B AQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAA ADUANQDw/y8ADABIAAAAVQALAF0AHABdADcAWgBNAFoAXgBnAFgAagBRAJUAfAChAIIAmgCZAI4A mACNAK8AhwC5AHcAuQB2ANEAbwDVAI8A8wCWAP4AjgAEAY4AFwGWACQBrgAyAasAPgGyAEsBsgBq AasAegGnAHYBpgBUAYwAOAGJAB8BfgAMAXYA8wBqAPIAYgDuAF4A8QBpAPgAawAHAWQABQFaAA4B RgAbATUAFQE5AAIBLADdACkA1AAAAK4ADACkAAoAggAcAFEAHAAzACkAJwAvAAwAbABwAAIAAEAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAAIBAAA1QcA APEEAAD5CQAADwAE8BABAAACAArwCAAAAEq4BQACCgAAAwEL8OAAAAAEAAAAAABCATsAAABDAVUA AABEAQQAAABFwTgAAABGwUIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAAOAA4A8P8ZAAAAAAASAAgAHgAIACQAAAAjAAAAMQALADEA EwA+ABEASQAfAFUAOwA0ADYAEgAiAAUAGQAAAB4AIAACAABAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAYQYAAGAFAACsBgAA 3QUAAA8ABPB4AQAAAgAK8AgAAABLuAUAAgoAAAMBC/BIAQAABAAAAAAAQgFaAAAAQwGWAAAARAEE AAAARcFsAAAARsF2AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAA zgEAAAAA/wEQABgAiAMAAAAAGwAbAPD/LwAGACMAAAAWABgACwAmAB0AMgAJADgAAQBDAAYATwAA AGQAAABxABIAcQASAHcAGACFABIAkgAdAJYALACKAEIAhQBaAHQAWgBuAEcAaAA2AGYANwBhAC4A TwA2AEoAPAAtAC4AGQAvAAYAOAA8AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAACQYAALwEAAB/BgAAlAUAAA8ABPDoAQAAAgAK 8AgAAABMuAUAAgoAAAMBC/C4AQAABAAAAAAAQgG0AQAAQwEDAQAARAEEAAAARcGkAAAARsGuAAAA fwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMA AAAAKQApAPD/eQEAACABNgADATEA7wAxANkARACxAC8AkAAwAIcAUACUAFwAZABnAEQAYwAUAIgA AACeAAkAqQAkAK4AOAC2AEEAywBBAN8AbwDgAIMA5ACkAPUAtAADAdQA8QAZAe8AOgHrAEwB3QBX AdIAaAHBAHYBuQB9AZgAcgGOAHIBegCHAXsAlQFvAJoBXQCgAUoArQExALQBGwCgARsAhQEpAHkB AABUAFgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAAPwCAACzBAAAOgUAACsGAAAPAATwsAEAAAIACvAIAAAATbgFAAIKAAADAQvw gAEAAAQAAAAAAEIBdQAAAEMBYAAAAEQBBAAAAEXBiAAAAEbBkgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAACIAIgDw/wAAAAAKAAgA EAAIABwADwAoABQAMwATADoADQBAAAgATQAAAFQAAgBRAA4ATAAUAEMAGABBABwATgArAFYALABT AB8AWgAZAF8AJwBqADMAcQAiAHUAQQBoAEsAYABgAFsAVQBZAE0AVQBEADEANgA3AD4ANgBPABYA VQANAC4AAAAfAAAAAABGAEgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAfwMA AGUIAAAbBAAA7ggAAA8ABPAgAQAAAgAK8AgAAABOuAUAAgoAAAMBC/DwAAAABAAAAAAAQgE6AAAA QwE2AAAARAEEAAAARcFAAAAARsFKAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEA AAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAEAAQAPD/FQAAAAoABgAHABAAAAAYAAcALAASADUA FwA2AB4AMAAhACwAJwAoAC8AKAA4ACEAOgAYADYABgAvAAsAFQAAACIAJAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACA AAAP8BAAAACKAwAAAAgAANUDAABNCAAADwAE8CABAAACAArwCAAAAE+4BQACCgAAAwEL8PAAAAAE AAAAAABCAZsAAABDAUkAAABEAQQAAABFwUAAAABGwUoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAQABAA8P8CAAAAmwAeAJsAPwCS AEkAfwBJAHIAOwBsAEMAWQBDAE8APQA9ADYAIwA2ABMAJgAAACsAAAANAAUACAACAAAAIgAkAAIA AEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAAKQCAAD0BwAAcgMAAGAIAAAPAATwOAUAAAIACvAIAAAAULgFAAIK AAADAQvwCAUAAAQAAAAAAEIBIQIAAEMBXgIAAEQBBAAAAEXBTAIAAEbBVgIAAH8BAQABAIABAAAA AIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAJMAkwDw/+YA dQDOAHAAvQBVALkASwC+ADcAvgAqAMoAJQDYABcAvQAAAJoAEgBlABYAZQAuAHAANABwAD4AfgBH AIMARgB7AE0AdgBbAHcAYgByAGoAbQB0AGYAewBfAIMAWACPAE4AnQBIAKUASACxABkAtwAYAMgA JADJACQA5QA1APEANQD+ABMA/gAAABABAAAXAQsAGwEcABYBKgAcASMAIwEZADkBLwBLAU0ALQFZ AC0BWQBBAWAATQFYAGkBYAB1AWUAlQFlAKsBeADIAYoA4AGKAOoBlAAEAqEADwKhABoCqwAhArAA JQK6ADMCswA9ArgASwK+AFECygBXAt0AXgLjAEwC6QBEAvUAPgL0ACcC/wAhAv8A8wEHAecBAgHi AfoA1QH7ALEBCwGxASUBpAErAZkBIwGKAUABfwFMAXEBWwFSAWYBTAF0AUoBeQFHAXcBOQF+AS4B eAEtAYABIAGMARcBoAEXAZcB7gCLAeAAiwHEAJIBzACaAcwApQHSALEB1gC9AdYAxAHQAM8ByADX AcIA3gHFANsBzwDVAdYAzAHZAMoB3QDXAe4A4QHuAN4B4QDjAdwA6QHpAPQB9gD7AeQA/gHbAA4C sgAOApIAGQKJACECagAYAmMADQJjAPcBUADiAWwAxwGCAMsBlADIAZ4AwQGjALkBowCxAagAqAGy AJoBqACUAZQAjwGSAH4BkgB+AbIAdAG8AGMBvABVAa4ATgG2AD4BtgAtAa4AHwGoAAYBqAD2AJkA 5ACeAOQAgwDpAHwA5gB1ACgBLAECAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAD4EAABM BwAADQcAALYKAAAPAATw8AIAAAIACvAIAAAAUbgFAAIKAAADAQvwwAIAAAQAAAAAAEIBhgQAAEMB EQMAAEQBBAAAAEXBKAEAAEbBMgEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAA AMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAEoASgDw/wAA+gIkABEDMQAKA0UA9gJTANYCYgDdAnYA 4QKHAO0ClwDzAtMA8wLkAN0C7gDdAvQA+QIMAfICKwHyAjcB7wIjAdYCGAG/AigBsQI2AacCSAGn AmkBlAKDAYsCfwGDAqEBEgLEAQ0CywHxAd8B5AH1Ac0BJQKoAUICrQF1AqIBZwKVAW8CdQGPAnUB uAKJAc4CdwHgAncBAQN7AS8DXwFVA0kBdgMxAW4DGQFxA/MAYQPtAIwDxgCrA88AywPwAPsD3QAT BPMAKgToAC0ExQA2BMcARwTbAE8ECwE8BBgBYQRHAYYEJgGABPwAbAS1AGwEkwA+BHAAMARGABoE SAAUBD0ABAQtAPsDOwD5A1MA5QNaAM0DUwDNAyIAuQMAAAAAAAAAAPoClgCYAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAACIAAAA3wIAAHoGAABJBwAADwAE8MABAAACAArwCAAAAFK4BQACCgAAAwEL 8JABAAAEAAAAAABCAQQBAABDAcsAAABEAQQAAABFwZAAAABGwZoAAAB/AQEAAQCAAQAAAACBAQYA AAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAkACQA8P8uAAAAIAAg AAwANAAAADsACQBZAAMAiwADAKcABwC4AE8AywBvALsAdgCfAIkAqACOAJ0AoACXAKgAjQCuAH4A uAB6ALMAZgDEAGYAxABhANAASADRAEIAywA3AOUAKgD8ACMABAEdAOkAHQDQACMAygAGAMEABgCu AB0AdAAdAGUAGABUAAwAPgAHAC4AAABKAEwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAAC3AAAA9AYAAA0CAAAZCAAADwAE8IgCAAACAArwCAAAAFO4BQACCgAAAwEL 8FgCAAAEAAAAAABCAUkBAABDATMBAABEAQQAAABFwfQAAABGwf4AAAB/AQEAAQCAAQAAAACBAQYA AAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAA9AD0A8P8EAJ4ARgCv AGYAoABtAIIAgQCMAIYAgACYAHoAngBxAKQAYgCvAF4AqgBKALsASgC6AEYAxgAvAMgAJwDCABoA 2gAPAPIACAD9AAAACAETABABIwBJASMAJwE1APIAOQDyAFAA/wBXAP8AYAAJAWgAEAFpAAgBcAAE AXwABQGGAAEBiwD7AJcA7wCjAOUAtADWAMkA1gDUAKYA2wCmAOoAsgDqALIABwHDABIBwwAhAaAA IQGPADMBeAApAWgADwFZAP0AQQAIASgAAgEcAAoBAAABAQsA8wAaAOUAIgDcAB8AzgAdAL8ACwC9 AAQAsgAEAJ4AfACAAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAMIAAAAcBwAAcQIAANYI AAAPAATwOAEAAAIACvAIAAAAVLgFAAIKAAADAQvwCAEAAAQAAAAAAEIBTgAAAEMB+AAAAEQBBAAA AEXBTAAAAEbBVgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4B AAAAAP8BEAAYAIgDAAAAABMAEwDw/wAAAAAjABYALgA1ACcAZgAoAIQALACTADEAlQAxAKkAOAC0 AEkAtQBLAMIATgDTAEUA3wA4AOoALgD4ACEA9gAQAPYAAADqAAAAAAAoACwAAgAAQACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAiAAAACgHAADvAAAAjQgAAA8ABPDoAAAAAgAK8AgAAABVuAUA AgoAAAMBC/C4AAAABAAAAAAAQgE9AAAAQwFgAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEA AAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/ PABSACEAYAAOAFIABQBFAAAAIQAEAAAAKQAPAD0AJwA8AFIAFAAYAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAuAIAALwKAAAHAwAARgsAAA8AA/AEBAAA DwAE8FQAAAABAAnwEAAAABsJAAAYCQAAQQkAALgJAAACAArwCAAAAFa4BQADAgAAIwAL8AwAAAAE AAAAAACIAwAAAAAAAA/wEAAAABsEAACyCQAASgQAAJoKAAAPAATw4gAAAAIACvAIAAAAV7gFAAIK AADzAAvwsgAAAEIBIAAAAEMBJAAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkACQDw/wAABQAPAAAA GQAFAB0ACgAgABcAHgAkAAsAHgAAABUAAAAFABQAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAFgAIAAAA/wEAAAABsJAACUCQAAOwkAALgJAAAPAATw4gAAAAIACvAIAAAA WLgFAAIKAADzAAvwsgAAAEIBFAAAAEMBJwAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQABAIABAAAA AIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkACQDw/xQA BgALAAAABAAGAAIACwAAABkAAQAnAA4AIQAUABcAFAAGABQAGAACAABAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACkJAAA9CQAAPQkAAGQJAAAPAATw4gAAAAIA CvAIAAAAWbgFAAIKAADzAAvwsgAAAEIBFgAAAEMBHQAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkA CQDw/xYAAwAMAAAABAAEAAIACAAAABMAAQAdABAAGQAWABIAFgADABQAGAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACIJAAB1CQAAOAkAAJIJAAAPAATw 4gAAAAIACvAIAAAAWrgFAAIKAADzAAvwsgAAAEIBFgAAAEMBIgAAAEQBBAAAAEXBJAAAAEbBLgAA AH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgD AAAAAAkACQDw/xYAAwAMAAAABAAFAAIACQAAABcAAQAiAA8AHQAWABQAFgADABQAGAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACsJAAAYCQAAQQkAADoJ AAAPAAPwnhAAAA8ABPBUAAAAAQAJ8BAAAABtBwAAKwoAALQHAAAiCwAAAgAK8AgAAABbuAUAAwIA ACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADmAQAARgsAAEICAACrDAAADwAE8OoAAAACAArw CAAAAFy4BQACCgAA8wAL8LoAAABCAREAAABDARYAAABEAQQAAABFwSgAAABGwTIAAAB/AQEAAQCA AQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAKAAoA 8P8AAAQABQAAAAsAAgAPAAIAEQAIABAADQAKABYAAgAVAAEADQAAAAQAFgAYAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHQHAACCCgAAhQcAAJgK AAAPAATw6gAAAAIACvAIAAAAXbgFAAIKAADzAAvwugAAAEIBEQAAAEMBFgAAAEQBBAAAAEXBKAAA AEbBMgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8B EAAYAIgDAAAAAAoACgDw/wAAAwAFAAAACwABABAAAgARAAgAEAANAAsAFgACABQAAQANAAAAAwAW ABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA oAcAAEEKAACxBwAAVwoAAA8ABPDqAAAAAgAK8AgAAABeuAUAAgoAAPMAC/C6AAAAQgERAAAAQwEX AAAARAEEAAAARcEoAAAARsEyAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAA ywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACgAKAPD/AAAEAAUAAAALAAIADwADABEACQAQAA4ACgAX AAIAFQABAA4AAAAEABYAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAAB3BwAAnQoAAIgHAAC0CgAADwAE8OoAAAACAArwCAAAAF+4BQACCgAA8wAL 8LoAAABCAREAAABDARYAAABEAQQAAABFwSgAAABGwTIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAKAAoA8P8AAAQABQAAAAsAAgAQ AAMAEQAIABAADgAKABYAAgAVAAEADgAAAAQAFgAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHwHAAAMCwAAjQcAACILAAAPAATw4gAAAAIACvAI AAAAYLgFAAIKAADzAAvwsgAAAEIBFwAAAEMBFwAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQABAIAB AAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkACQDw /wAAAwAKAAAAEwADABUABgAXAA8AFQAXAAcAFAAAAA4AAAADABQAGAACAABAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAG4HAAArCgAAhQcAAEIKAAAPAATwEgEA AAIACvAIAAAAYbgFAAIKAADzAAvw4gAAAEIBFgAAAEMBHwAAAEQBBAAAAEXBPAAAAEbBRgAAAH8B AQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAA AA8ADwDw/xYAGwAVABMAEgAKAA4ABQALAAAABgAAAAMABAADAAgAAwALAAAAEQAAABoABAAeAAoA HwASAB8AFgAbACAAJAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAG0HAADGCgAAgwcAAOUKAAAPAATwEgEAAAIA CvAIAAAAYrgFAAIKAADzAAvw4gAAAEIBEwAAAEMBHwAAAEQBBAAAAEXBPAAAAEbBRgAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAA8A DwDw/xMAAwATAAwADwAVAAsAGgAKAB8ABgAfAAMAGwADABcAAgAUAAAADgAAAAUAAwABAAgAAAAQ AAAAEwADACAAJAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAIkHAADsCgAAnAcAAAsLAAAPAATw6gAAAAIACvAI AAAAY7gFAAIKAADzAAvwugAAAEIBEQAAAEMBFgAAAEQBBAAAAEXBKAAAAEbBMgAAAH8BAQABAIAB AAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAoACgDw /wAABAAFAAAACwABABAAAgARAAgAEAANAAoAFgACABUAAQANAAAABAAWABgAAgAAQACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAmAcAAIsKAACpBwAAoQoA AA8ABPDqAAAAAgAK8AgAAABkuAUAAgoAAPMAC/C6AAAAQgERAAAAQwEWAAAARAEEAAAARcEoAAAA RsEyAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQ ABgAiAMAAAAACgAKAPD/AAAEAAUAAAALAAEAEAACABEACAARAA0ACwAWAAMAFQABAA0AAAAEABYA GAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABw BwAA5goAAIEHAAD8CgAADwAE8OoAAAACAArwCAAAAGW4BQACCgAA8wAL8LoAAABCAREAAABDARYA AABEAQQAAABFwSgAAABGwTIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAAKAAoA8P8AAAQABQAAAAsAAQAPAAIAEQAIABAADQAKABYA AgAVAAAADQAAAAQAFgAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAAJQHAADECgAApQcAANoKAAAPAATw6gAAAAIACvAIAAAAZrgFAAIKAADzAAvw ugAAAEIBEQAAAEMBHwAAAEQBBAAAAEXBKAAAAEbBMgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQ AMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAoACgDw/wAAGgAFAB8ACwAeAA8A HAARABQAEAAMAAoAAAACAAEAAAAMAAAAGgAWABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAhgcAAFwKAACXBwAAewoAAA8ABPDqAAAAAgAK8AgA AABnuAUAAgoAAPMAC/C6AAAAQgEQAAAAQwEQAAAARAEEAAAARcEoAAAARsEyAAAAfwEBAAEAgAEA AAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACgAKAPD/ AAAOAAQAEAAKAA8ADgAPABAACgAPAAYACQAAAAEAAQAAAAYAAAAOABYAGAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAACBBwAAygoAAJEHAADaCgAA DwAE8OoAAAACAArwCAAAAGi4BQACCgAA8wAL8LoAAABCARAAAABDARMAAABEAQQAAABFwSgAAABG wTIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAAKAAoA8P8AABEABAATAAoAEgAOABEAEAAMAA8ACAAJAAAAAQAAAAAACAAAABEAFgAY AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAI0H AACaCgAAnQcAAK0KAAAPAATw6gAAAAIACvAIAAAAabgFAAIKAADzAAvwugAAAEIBDwAAAEMBEwAA AEQBBAAAAEXBKAAAAEbBMgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAAAoACgDw/wAAEQAEABMACQATAA4AEgAPAA0ADwAIAAkAAAAB AAEAAAAIAAAAEQAWABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAiwcAAC8KAACaBwAAQgoAAA8ABPDiAAAAAgAK8AgAAABquAUAAgoAAPMAC/Cy AAAAQgESAAAAQwEUAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAA wAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAASAAkAFAAPABIAEQAP ABIABwARAAAABgADAAAACAAAABIAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAogcAAFsKAAC0BwAAbwoAAA8ABPDiAAAAAgAK8AgAAABruAUAAgoA APMAC/CyAAAAQgESAAAAQwEUAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAASAAgAFAAP ABIAEQAPABIABwARAAAABgADAAAACAAAABIAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAlwcAANkKAACpBwAA7QoAAA8ABPDiAAAAAgAK8AgAAABs uAUAAgoAAPMAC/CyAAAAQgERAAAAQwEUAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAAS AAgAFAAPABIAEAAPABEABwARAAAABgADAAAACAAAABIAFAAYAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgcAAGAKAACDBwAAdAoAAA8AA/B2KQAADwAE 8E4AAAABAAnwEAAAAKYEAACUCQAA+QkAAGoMAAACAArwCAAAAG24BQADAgAAEwAL8AYAAACIAwAA AAAAAA/wEAAAAKYEAACUCQAA+QkAAGoMAAAPAATwwAAAAAIACvAIAAAAbrgFAAIKAAADAQvwkAAA AAQAAAAAAEIBBwAAAEMBDAAAAEQBBAAAAEXBEAAAAEbBGgAAAH8BAQABAIABAAAAAIEBBgAACL8B EAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAQABADw/wIAAAAHAAwAAAAJ AAIAAAAKAAwAAgAAQACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAKQcAAJQJAAAzBwAApgkAAA8A BPAIAQAAAgAK8AgAAABvuAUAAgoAAAMBC/DYAAAABAAAAAAAQgElAAAAQwEmAAAARAEEAAAARcE0 AAAARsE+AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA /wEQABgAiAMAAAAADQANAPD/GwAAACUABAAiAA8AIgAmABoAHAAUABoAEgAiAAwAIgAAAB8ADQAZ AA0ACAAZABIAGwAAABwAIAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABtBwAAyAkAAKAHAAD+CQAADwAE8EgBAAACAArwCAAA AHC4BQACCgAAAwEL8BgBAAAEAAAAAABCAWAAAABDAXcAAABEAQQAAABFwVQAAABGwV4AAAB/AQEA AQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAV ABUA8P8BAAYAAAATAA4AMgAbAFIAMwBjAD0AbgBGAHcAUgBxAGAAdwBZAGAATwBbAEgATgBIADwA UwA3AE4AKQBCABcAKgAEACIADwANAAAACAAGAAEABgAsADAAAgAAQACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAAD1BAAAXQoAAHMFAAAMCwAADwAD8G4fAAAPAATwVAAAAAEACfAQ AAAAhgkAAKAJAACUDQAA+woAAAIACvAIAAAAcbgFAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAA D/AQAAAApgQAAHYKAAD5CQAAagwAAA8ABPDiAAAAAgAK8AgAAAByuAUAAgoAAPMAC/CyAAAAQgEW AAAAQwEdAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAI xAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/FgADAAwAAAAEAAQAAgAIAAAAEwAB AB0ADwAZABYAEQAWAAMAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAA8gkAAHMKAAAICgAAkAoAAA8ABPDiAAAAAgAK8AgAAABzuAUAAgoAAPMAC/Cy AAAAQgEbAAAAQwEhAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAA wAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAAEAAwAAAAWAAUAGQAJ ABsAFgAZACEACAAdAAAAEwAAAAQAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAxgkAAEUKAADhCQAAZgoAAA8ABPDiAAAAAgAK8AgAAAB0uAUAAgoA APMAC/CyAAAAQgEaAAAAQwEoAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/GgAFAA4AAAAF AAYAAgAMAAAAGgACACgAEwAiABoAGAAaAAUAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAqwkAABQKAADFCQAAPAoAAA8ABPDiAAAAAgAK8AgAAAB1 uAUAAgoAAPMAC/CyAAAAQgEaAAAAQwEoAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/GgAk AA4AKAAFACIAAgAdAAAADgABAAAAEgAGABoAEQAaACQAFAAYAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAlgkAAOcJAACwCQAADwoAAA8ABPAiAgAAAgAK 8AgAAAB2uAUAAgoAAPMAC/DyAQAAQgHxAAAAQwEJAQAARAEEAAAARcHEAAAARsHOAAAAfwEBAAEA gAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAMQAx APD/BAAAABcACwAlAAkAMgALAEEAIwBCADAAUQA5AF8AOABlAEMAbQBEAHQATgB+AE8AhgBbAJQA YQCYAGwAqgBsALcAdAC/AIMAtQCFALAAiwDGAJMAywCeANQAqADVALAA3QCxAPEAwADrAMgA7ADR APAA2ADxAP0A5QD7ANoA+wDaAAkBxwD6AKgA6QCWANEAewC7AHQAnQBlAJEAVwB+AFkAawA5AFIA OABGADIAPQAhAD4AHQA1AAEAFwAAAA0ABAAAAGQAaAACAABAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAACGCQAAoAkAAHcKAACpCgAADwAE8AIBAAACAArwCAAAAHe4BQACCgAA8wAL 8NIAAABCATMAAABDAaMAAABEAQQAAABFwTQAAABGwT4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAANAA0A8P8zAAkAHQAAAB0ACAAO AAEADgBMAAAAVQAOAF0ADgCPABIAmgAdAKAAHQCjADMAowAzAAkAHAAgAAIAAEAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGENAAA7 CgAAlA0AAN4KAAAPAATwggIAAAIACvAIAAAAeLgFAAIKAADzAAvwUgIAAEIB0gAAAEMBxAAAAEQB BAAAAEXB9AAAAEbB/gAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEA AM4BAAAAAP8BEAAYAIgDAAAAAD0APQDw/9IANgDSAIMAxACKANIAkgDSAMQAxQC0ALkAtACtAKYA rQCeAKkAkQCbAIwAjAB8AIQAawB1AGcAawBnAFoAYgBTAGIATABaAD0AVgA9AE8ANgBWADYAXAAr AGIAJQBbACQAVgAeAE0AHgBHABcARwARAEEAFAA8AC0AQgA3ADcALgAjABQAJAAMAB4AAAAeAAAA FgAGAAYADAAAABcAAAAlAAYAMQAGAEEAAAA9AA8APAAaAD8AJQBEACwAUwA8AFwAPABsADEAcgAl AHwAHwCKABEAjgAXAJQAGACfAB8ApwAeAKwAJAC7ACQAxQAeANIANgB8AIAAAgAAQACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAnQwAAAYKAABvDQAAygoAAA8ABPDyAAAAAgAK8AgAAAB5uAUAAgoA APMAC/DCAAAAQgElAAAAQwEZAAAARAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACwALAPD/AQAEABAAAAAc AAAAIwAIACUADwAjABQAHAAZABAAGQAEABUAAAALAAEABAAYABwAAgAAQACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAKIMAACECgAAxwwAAJ0KAAAP AATw8gAAAAIACvAIAAAAergFAAIKAADzAAvwwgAAAEIBIQAAAEMBFAAAAEQBBAAAAEXBLAAAAEbB NgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAY AIgDAAAAAAsACwDw/wAAEAAPABQAGQATACAADQAhAAgAHwADABkAAAAPAAAAAwADAAAACwAAABAA GAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAADKDAAAagoAAOsMAAB+CgAADwAE8PIAAAACAArwCAAAAHu4BQACCgAA8wAL8MIAAABCASUA AABDARoAAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjE AQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAALAAsA8P8kAAUAFQAAAAkAAQABAAgAAAAQAAIA FQAJABoAFQAaACAAFgAlAAwAJAAFABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAlAwAAGAKAAC5DAAAegoAAA8ABPBKAQAAAgAK8AgA AAB8uAUAAgoAAPMAC/AaAQAAQgE/AAAAQwEiAAAARAEEAAAARcFYAAAARsFiAAAAfwEBAAEAgAEA AAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAFgAWAPD/ MgABACwABQAdAAYAEAAIAAkACgAEAA0AAAATAAIAFgAMABsAFgAeAB8AIgAnACEALgAdADQAGwA4 ABYAPAAQADsADQA/AAoAPwAGAD0AAgA7AAAAMgABAC4AMAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBYACAAAAP8BAAAADjCwAAOgoAACIMAABcCgAADwAE8EoBAAACAArwCAAAAH24 BQACCgAA8wAL8BoBAABCAUEAAABDASIAAABEAQQAAABFwVgAAABGwWIAAAB/AQEAAQCAAQAAAACB AQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAWABYA8P80AAEA LQAFAB4ABgASAAgACQALAAQADgAAABMAAwAXAAwAGwAYAB8AIAAiACkAIAAwAB0ANQAbADoAFgA+ ABAAPAAOAEEACwBBAAYAPwADADwAAAA0AAEALgAwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAALkLAACxCgAA+gsAANMKAAAPAATw8gAAAAIACvAIAAAAfrgFAAIK AADzAAvwwgAAAEIBNwAAAEMBGgAAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/wEABQAYAAAA KQABADUACAA3ABAAMwAVACkAGgAYABoABgAWAAAADAABAAUAGAAcAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAAMDAAAGAoAAEMMAAAyCgAA DwAE8PIAAAACAArwCAAAAH+4BQACCgAA8wAL8MIAAABCATgAAABDARoAAABEAQQAAABFwSwAAABG wTYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAALAAsA8P8BAAUAGAAAACoAAQA2AAkAOAAQADQAFQAqABoAGAAaAAYAFgAAAAwAAQAF ABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAA D/AQAAAApQsAANMKAADdCwAA7QoAAA8ABPBKAQAAAgAK8AgAAACAuAUAAgoAAPMAC/AaAQAAQgFA AAAAQwEhAAAARAEEAAAARcFYAAAARsFiAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAI xAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAFgAWAPD/MgAhACwAHQAdABsAEAAaAAkAFwAE ABQAAAAPAAIACwAMAAcAFgADAB8AAAAnAAIALwAEADQABwA4AAwAPQASADsAFABAABcAQAAbAD0A HwA7ACEAMgAhAC4AMAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAA AAAuDAAAuAoAAG4MAADZCgAADwAE8EoBAAACAArwCAAAAIG4BQACCgAA8wAL8BoBAABCAToAAABD ASUAAABEAQQAAABFwVgAAABGwWIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAA AADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAWABYA8P8MACQAEgAgAB8AHgArAB0AMgAaADcAFgA6 ABAAOQAMADAABwAmAAMAHQAAABYAAQAPAAQACgAHAAYADQACABQAAwAWAAAAGgAAAB4AAQAiAAMA JQAMACQALgAwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAEML AACrCgAAfQsAANAKAAAPAATw8gAAAAIACvAIAAAAgrgFAAIKAADzAAvwwgAAAEIBLgAAAEMBGQAA AEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/y0ABAAaAAAACwAAAAEABwAAAA8AAwAUAAsAGQAa ABkAKAAVAC4ACwAtAAQAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAAB+DAAA4wkAAKwMAAD8CQAADwAE8OIAAAACAArwCAAAAIO4BQAC CgAA8wAL8LIAAABCATMAAABDARoAAABEAQQAAABFwSQAAABGwS4AAAB/AQEAAQCAAQAAAACBAQYA AAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAJAAkA8P8AAAMAGAAA ACkABAAvAAgAMwARADEAGgAPABcAAAAQAAAAAwAUABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABpCwAA4QoAAJwLAAD7CgAADwAE8PIAAAACAArwCAAA AIS4BQACCgAA8wAL8MIAAABCATUAAABDARoAAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAA AACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAALAAsA8P8B AAUAGAAAACgAAQA0AAgANQAQADIAFQAoABoAGAAaAAYAFgAAAAwAAQAFABgAHAACAABAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA7gsAAM4KAAAj DAAA6AoAAA8ABPDyAAAAAgAK8AgAAACFuAUAAgoAAPMAC/DCAAAAQgEjAAAAQwEVAAAARAEEAAAA RcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAACwALAPD/AAADABAAAAAaAAAAIgAHACMADAAhABEAGgAVABAAFQAEABIA AAAJAAAAAwAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAACgMAADVCgAASwwAAOoKAAAPAATw8gAAAAIACvAIAAAAhrgFAAIKAADzAAvw wgAAAEIBMQAAAEMBFQAAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQ AMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/wAAAwAWAAAAJQAAADEA BwAxAA0AMAARACUAFQAWABUABQASAAAACgAAAAMAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAACDAAArwoAADMMAADECgAADwAE8OIA AAACAArwCAAAAIe4BQACCgAA8wAL8LIAAABCATsAAABDAR4AAABEAQQAAABFwSQAAABGwS4AAAB/ AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAA AAAJAAkA8P87AAMAHwAAAAsABAADAAgAAAATAAIAHgApABoAOwASADsAAwAUABgAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABwCwAAwAoAAKsLAADeCgAA DwAE8NoBAAACAArwCAAAAIi4BQACCgAA8wAL8KoBAABCAfkAAABDAVgAAABEAQQAAABFwaAAAABG waoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAAoACgA8P8TAAAANAAAAEIACwBIABEAZwARAGoACgB5AAYAjwAFAJYADACcAA0AoAAQ AKYAEQClABYArAAcANYAHwDQACYA0QAtAN0APQD5AEIA9ABXANwAWADMAFIAuQA/AK4AOwCWADsA dwBAAHAAOwBlADQAVwA1ADsALwAyACgAJQAoAB4AIwASACMAAAAXAAEADAAFAAsABgAFAA4ABQAT AAAAUgBUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAGwKAACjCgAAZQsAAPsKAAAPAATwwgIAAAIACvAIAAAAibgFAAIKAADzAAvwkgIA AEIBlwAAAEMBtAAAAEQBBAAAAEXBFAEAAEbBHgEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMAB BwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAEUARQDw/5cAAACSABwAgQApAFsALwBU ACgASwAoAEUAJAA3ACwALgAyACkAOQArADsAMQA6ADcATgA8AE4APABIAEIARABCADsAYgA8AGQA NQBnADQAbQBBAGcASABhAEgAXQBSAFUAXABVAFwAZwCFAGcAiwBcAIsAXACSAFQAlgBIAJYASgCF AEIAgwBCAHgAPgBzAD0AbAAqAGoAKgB7ADIAfwAqAIcAMQCLAC8AkQA3AJQANwCsAC4AtAAgALMA HgCFABMAggAAAG8AAABgAA0AUgAVAFEAHABJAB8AQAAfACkAJQAeACwAFwAzABcANwAUADgADAA9 AAsAQgARAEoAEgBKABcAdAAXAIEAEgCHABIAlwAAAIwAkAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAH0LAADdCQAAFAwAAJEKAAAP AATwEgEAAAIACvAIAAAAirgFAAIKAADzAAvw4gAAAEIBRAAAAEMBJgAAAEQBBAAAAEXBPAAAAEbB RgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAY AIgDAAAAAA8ADwDw/zsAAAApAAEAFQAHAAkADgABABIAAAAaAAgAHwASAB8AGQAgACUAJgA5ACYA QAAeAEIAEwBEAAYAOwAAACAAJAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAADIMAAA0CgAAdgwAAFoKAAAPAAPw igUAAA8ABPBUAAAAAQAJ8BAAAACsCgAAdwkAAJULAABvCgAAAgAK8AgAAACLuAUAAwIAACMAC/AM AAAABAAAAAAAiAMAAAAAAAAP8BAAAADxBQAAzwoAACEHAAA0DAAADwAE8PoBAAACAArwCAAAAIy4 BQACCgAA8wAL8MoBAABCAd4AAABDAZYAAABEAQQAAABFwbAAAABGwboAAAB/AQEAAQCAAQAAAACB AQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAsACwA8P8AAIAA FACVABwAlgAhAI4ANACJAD4AhABEAH4AZQB+AHMAeABzAG0AhABaAIYAVACRAEkAkgA8ALYAPADG ADcAyAAsANcAKADeACcA2QAhAMwAIQC9ABoAuQAhALAAGwC9AAsAsAAAAJ4ACgCXABgAigAnAH8A MgBuADUAZwA7AFkASwBWAFQASQBZADkAWQAxAGIAMQByACYAeAAmAH4ADgB+AA4AeAAAAHIAAACA AFoAXAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAtwoAAHcJAACVCwAADQoAAA8ABPBKAgAAAgAK8AgAAACN uAUAAgoAAPMAC/AaAgAAQgHkAAAAQwG+AAAARAEEAAAARcHYAAAARsHiAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAANgA2APD/DABG ACAAWwAmAFsALABSAD4ATgBJAEoATwBCAHAAQwB8AD4AfAAxAI4AHwCRABcAmwAOAJsAAADAAAAA wQAIAMUADgDGABQAwAAaAMYAIgDGADIA1QBAANwAQwDkAEoA3wBKANAAUQDCAGEAxgB0ALoAcwCu AIAArQCWAJoAtwCGAL4AhQC4AH4ArwBxAK4AaACrAGAArgBYALcAQQC2ADUAqwAlAKoAIACiACAA mQAZAJcAHwCLABkAfwASAIgACQB6AAMAcwAAAGoAAQBJAAcAQQAMAEYAbgBwAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAArAoAALEJAACQ CwAAbwoAAA8ABPDSAAAAAgAK8AgAAACOuAUAAgoAAPMAC/CiAAAAQgEmAAAAQwEhAAAARAEEAAAA RcEcAAAARsEmAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAABwAHAPD/JgAHABgAAAAIAAYAAAAQAAMAGwAPACEAJgAHABAAFAACAABA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAAACwAApAkAACYLAADFCQAADwAE 8OgAAAACAArwCAAAAI+4BQACCgAAAwEL8LgAAAAEAAAAAABCAQ4AAABDARMAAABEAQQAAABFwSQA AABGwS4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ ARAAGACIAwAAAAAJAAkA8P8AAAIABwAAAAsAAgAOAAUADgAMAA4AEwAFABAAAAALAAAAAgAUABgA AgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB2BQAApAsA AIoFAADACwAADwAE8F4AAABCAQrwCAAAAJC4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQA AAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIErBWsFbIGDwAE 8F4AAABCAQrwCAAAAJG4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAA EADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIEMA4wDrIGDwAE8F4AAABCAQrwCAAA AJK4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSU AAD/ARgAGAABAgIAAAgAABDwCAAAACMF/Av8C7IGDwAE8F4AAABCAQrwCAAAAJO4BQAACgAAkwAL 8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIA AAgAABDwCAAAAAMFfAV8BbIGDwAE8F4AAABCAQrwCAAAAJS4BQAACgAAkwAL8DYAAACFAAIAAACH AAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAOMG MgIyAjAMDwAE8F4AAABCAQrwCAAAAJW4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIG7BTsFDEJDwAE8FgA AAAyAArwCAAAAJa4BQAACgAAgwAL8DAAAACFAAIAAACHAAEAAAC/AAAADQCBAf8AAAC/ARAAEAD/ AQYABgA/AgAAAQB/AwAADwAAABDwCAAAAJMEqgtaDEQFDwAE8FgAAAAyAArwCAAAAJe4BQAACgAA gwAL8DAAAACFAAIAAACHAAEAAAC/AAAADQCBAQCZAAC/ARAAEAD/AQYABgA/AgAAAQB/AwAADwAA ABDwCAAAAIAE0A2ADjIFDwAE8FgAAAAyAArwCAAAAJi4BQAACgAAgwAL8DAAAACFAAIAAACHAAEA AAC/AAAADQCBAQCZAAC/ARAAEAD/AQYABgA/AgAAAQB/AwAADwAAABDwCAAAAIAEchUgFjIFDwAE 8F4AAABCAQrwCAAAAJm4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAA EADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIG1A7UDvMLDwAE8F4AAABCAQrwCAAA AJq4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSU AAD/ARgAGAABAgIAAAgAABDwCAAAAPIGdgx2DPMLDwAE8F4AAAAiAArwCAAAAJu4BQAACgAAkwAL 8DYAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAAD/AQgACAABAgIA AAgAABDwCAAAALMD+AoADa4FDwAE8GQAAAAiAArwCAAAAJy4BQAACgAAowAL8DwAAACFAAIAAACH AAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAADOAQIAAAD/AQgACAABAgIAAAgAABDw CAAAAHEIgBM7FjEKDwAE8FgAAAAyAArwCAAAAJ24BQAACgAAgwAL8DAAAACFAAIAAACHAAEAAAC/ AAAADQCBAQCZAAC/ARAAEAD/AQYABgA/AgAAAQB/AwAADwAAABDwCAAAAIAEFAXEBTIFDwAE8KAA AACiDArwCAAAAJ64BQAACgAAgwAL8DAAAACAABByBASFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAi/ AQAAEADAAQEAAAj/AQAACAAAABDwCAAAAKkDqAOcBpAEDwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKgP CAAAAE5TUElYUC02AAChDxwAAAAJAAAAAAAAAAoABwAJAAAAAQAGAIEAEgD/AAD+DwAE8JwAAACi DArwCAAAAJ+4BQAACgAAgwAL8DAAAACAAKh2BASFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAi/AQAA EADAAQEAAAj/AQAACAAAABDwCAAAAKkDWw0vD5AEDwAN8DwAAAAAAJ8PBAAAAAQAAAAAAKgPBAAA AFBBSVgAAKEPHAAAAAUAAAAAAAAACgAHAAUAAAABAAYAgQASAP8AAP4PAATwnAAAAKIMCvAIAAAA oLgFAAAKAACDAAvwMAAAAIAAgHoEBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACL8BAAAQAMABAQAA CP8BAAAIAAAAEPAIAAAAswMsC8AMmgQPAA3wPAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAUy1JWAAA oQ8cAAAABQAAAAAAAAAKAAcABQAAAAEABgCBABIA/wAA/g8ABPCeAAAAogwK8AgAAAChuAUAAAoA AIMAC/AwAAAAgAAgfgQEhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIvwEAABAAwAEBAAAI/wEAAAgA AAAQ8AgAAACpA3sU/xaQBA8ADfA+AAAAAACfDwQAAAAEAAAAAACoDwYAAABBTVMtSVgAAKEPHAAA AAcAAAAAAAAACgAHAAcAAAABAAYAgQASAP8AAP4PAATwngAAAKIMCvAIAAAAorgFAAAKAACTAAvw NgAAAIAAkIIEBIUAAgAAAIcABgAAAL8AAgACAIEB/8zMAL8BAAAQAMABAQAACP8BAAAIAAECAgAA CAAAEPAIAAAARALDAqIEZAMPAA3wOAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAQXNpYQAAoQ8YAAAA BQAAAAAAAAgKAAEABwAFAAAAEQAAAJEADwAE8HgAAACyBArwCAAAAKO4BQAQCgAAowAL8DwAAAAE QQcAAAALAegEAAA/AQAAAQCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAA AgAAABDwCAAAAGMKyw98EtIKDwAR8AwAAAAAAMELBAAAAOgEAAAPAAPwSAQAAA8ABPBMAAAAAQAJ 8BAAAAD7AwAAdQsAAFsLAAAMEAAAAgAK8AgAAACkuAUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAA AAAQ8AgAAAA9CQMU1RTVCQ8AA/AIAwAADwAE8E4AAAABAAnwEAAAAPsDAAC4DgAAWwsAAAwQAAAC AArwCAAAAKW4BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATw /gAAAAIACvAIAAAAprgFAAIKAAATAQvwzgAAAEIBYAcAAEMBVAEAAEQBBAAAAEXBLAAAAEbBNgAA AH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4B AAAAAP8BGAAYAIgDAAAAAAsACwDw/+oAAAB8BgAAXgc1AWAHQwFYB1ABSQdUARsAVAEIAE4BAAA/ AQQALgHqAAAAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8M4AAAACAArwCAAAAKe4BQACCgAAEwEL 8J4AAABCAegEAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf// /wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P+p AAAArQQAAOgE2gAAANoAqQAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA YwQAAAIPAABLCQAA3A8AAA8ABPDOAAAAAgAK8AgAAACouAUAAgoAABMBC/CeAAAAQgF8AQAAQwHa AAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAA wgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/AAAAAOEAAAB8AdoARwDa AAAAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHIJAAACDwAA7goAANwP AAAPAATwQgAAABIACvAIAAAAqbgFAAIKAAAzAAvwEgAAAL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQ AAAApQUAAHULAACvCQAArw4AAA8ABPBIAAAAEgAK8AgAAACquAUAAgoAAEMAC/AYAAAAgQEQUP8A vwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAAAzBgAA5gsAACEJAAAhDgAADwAE8EIAAAASAArwCAAA AKu4BQACCgAAMwAL8BIAAACBAQAAAAC/ARAAEAD/AQAACAAAAA/wEAAAAMMIAABSDgAAIAkAAIAO AAAPAAPwSAQAAA8ABPBMAAAAAQAJ8BAAAAD7AwAAdQsAAFsLAAAMEAAAAgAK8AgAAACsuAUAAQIA ACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAAA9CQIV1BXVCQ8AA/AIAwAADwAE8E4AAAABAAnw EAAAAPsDAAC4DgAAWwsAAAwQAAACAArwCAAAAK24BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAA APsDAAC4DgAAWwsAAAwQAAAPAATw/gAAAAIACvAIAAAArrgFAAIKAAATAQvwzgAAAEIBYAcAAEMB VAEAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAA AMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAsACwDw/+oAAAB8BgAAXgc1AWAH QwFYB1ABSQdUARsAVAEIAE4BAAA/AQQALgHqAAAAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8M4A AAACAArwCAAAAK+4BQACCgAAEwEL8J4AAABCAegEAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/ AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAA AAD/ARgAGACIAwAAAAAFAAUA8P+pAAAArQQAAOgE2gAAANoAqQAAAAwAEAACAABAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAYwQAAAIPAABLCQAA3A8AAA8ABPDOAAAAAgAK8AgAAACwuAUA AgoAABMBC/CeAAAAQgF8AQAAQwHaAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH/ //8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAA BQAFAPD/AAAAAOEAAAB8AdoARwDaAAAAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAA AA/wEAAAAHIJAAACDwAA7goAANwPAAAPAATwQgAAABIACvAIAAAAsbgFAAIKAAAzAAvwEgAAAL8B EAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAApQUAAHULAACvCQAArw4AAA8ABPBIAAAAEgAK8AgAAACy uAUAAgoAAEMAC/AYAAAAgQEQUP8AvwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAAAzBgAA5gsAACEJ AAAhDgAADwAE8EIAAAASAArwCAAAALO4BQACCgAAMwAL8BIAAACBAQAAAAC/ARAAEAD/AQAACAAA AA/wEAAAAMMIAABSDgAAIAkAAIAOAAAPAATwSAAAALIECvAIAAAAtLgFAAAKAABDAAvwIAAAAH8A gACAAARBCQAAAAXBCAAAAAYBAQAAAG4AdAB0AAAAAAAQ8AgAAABfCogTYBYBCw8ABPBIAAAAsgQK 8AgAAAC1uAUAAAoAAEMAC/AgAAAAfwCAAIAABEEJAAAABcEIAAAABgEBAAAAbgB0AHQAAAAAABDw CAAAAKAFWAkwDEIGDwAE8NIAAACiDArwCAAAALa4BQAACgAAAwEL8GAAAACAAOyKBASBAJBfAQCC ANC2AACDAJBfAQCEANC2AACFAAIAAACHAAEAAAC/AAIADwCBAQAAAAiDAQAAAAi/AQwAHgDAAQEA AAj/AQYADgABAgIAAAg/AgAAAwB/AwAADwAAABDwCAAAAAMLsRNvFsMLDwAN8EIAAAAAAJ8PBAAA AAQAAAAAAKgPCgAAAE5UVCBFdXJvcGUAAKEPHAAAAAsAAAAAAAAoCgABABQABwALAAAAgwQCAAME DgAPAATwzwAAAKIMCvAIAAAAt7gFAAAKAAADAQvwYAAAAIAAHI8EBIEAkF8BAIIA0LYAAIMAkF8B AIQA0LYAAIUAAgAAAIcAAQAAAL8AAgAPAIEBAAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAEC AgAACD8CAAADAH8DAAAPAAAAEPAIAAAA4ARgCboLoAUPAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8H AAAATlRUIE1DTAAAoQ8cAAAACAAAAAAAACgKAAEAFAAHAAgAAACDBAIAAwQOAA8ABPCeAAAAogwK 8AgAAAC4uAUAAAoAAJMAC/A2AAAAgAD0kgQEhQACAAAAhwAGAAAAvwACAAIAgQH/zMwAvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABEArQTiBZkAw8ADfA4AAAAAACfDwQAAAAEAAAAAACo DwYAAABFdXJvcGUAAKEPFgAAAAcAAAAAAAAACgAHAAcAAAARAAAAkQAPAATwSAAAALIECvAIAAAA ubgFAAAKAABDAAvwIAAAAH8AgACAAARBCgAAAAXBCAAAAAYBAQAAAG4AdAB0AAAAAAAQ8AgAAABA D9UKWg9DEA8ABPBeAAAAQgEK8AgAAAC6uAUAAAoAAJMAC/A2AAAAhQACAAAAhwABAAAARAEEAAAA fwEAAAEAvwEAABAAwAEBAAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgAAADjBjoEOgTGCA8ABPBe AAAAQgEK8AgAAAC7uAUAAAoAAJMAC/A2AAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEAvwEAABAA wAEBAAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgAAADyBhAREBExCQ8ABPBkAAAAIgAK8AgAAAC8 uAUAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAH/AAAAywHUlAAA zgECAAAA/wEIAAgAAQICAAAIAAAQ8AgAAABxCK8PahIxCg8AA/BIBAAADwAE8EwAAAABAAnwEAAA APsDAAB1CwAAWwsAAAwQAAACAArwCAAAAL24BQABAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAABDw CAAAAD0JLRD/ENUJDwAD8AgDAAAPAATwTgAAAAEACfAQAAAA+wMAALgOAABbCwAADBAAAAIACvAI AAAAvrgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPD+AAAA AgAK8AgAAAC/uAUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAARAEEAAAARcEsAAAARsE2AAAAfwEB AAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA /wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgHUAFJB1QBGwBUAQgATgEAAD8BBAAu AeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIACvAIAAAAwLgFAAIKAAATAQvwngAA AEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8B EAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/6kAAACt BAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABjBAAA Ag8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAMG4BQACCgAAEwEL8J4AAABCAXwBAABDAdoAAABE AQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf// /wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P8AAAAA4QAAAHwB2gBHANoAAAAA AAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgkAAAIPAADuCgAA3A8AAA8A BPBCAAAAEgAK8AgAAADCuAUAAgoAADMAC/ASAAAAvwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAACl BQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAAMO4BQACCgAAQwAL8BgAAACBARBQ/wC/ARAA EADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEOAAAPAATwQgAAABIACvAIAAAAxLgF AAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQAAAAwwgAAFIOAAAgCQAAgA4AAA8A A/BIBAAADwAE8EwAAAABAAnwEAAAAPsDAAB1CwAAWwsAAAwQAAACAArwCAAAAMW4BQABAgAAIwAL 8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAD0JKxH9EdUJDwAD8AgDAAAPAATwTgAAAAEACfAQAAAA +wMAALgOAABbCwAADBAAAAIACvAIAAAAxrgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMA ALgOAABbCwAADBAAAA8ABPD+AAAAAgAK8AgAAADHuAUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAA RAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH/ //8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgH UAFJB1QBGwBUAQgATgEAAD8BBAAuAeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIA CvAIAAAAyLgFAAIKAAATAQvwngAAAEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQAB AIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8B GAAYAIgDAAAAAAUABQDw/6kAAACtBAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBYACAAAAP8BAAAABjBAAAAg8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAMm4BQACCgAA EwEL8J4AAABCAXwBAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCD Af///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA 8P8AAAAA4QAAAHwB2gBHANoAAAAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQ AAAAcgkAAAIPAADuCgAA3A8AAA8ABPBCAAAAEgAK8AgAAADKuAUAAgoAADMAC/ASAAAAvwEQABAA ywGcMQAA/wEIAAgAAAAP8BAAAAClBQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAAMu4BQAC CgAAQwAL8BgAAACBARBQ/wC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEO AAAPAATwQgAAABIACvAIAAAAzLgFAAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQ AAAAwwgAAFIOAAAgCQAAgA4AAA8ABPBeAAAAIgAK8AgAAADNuAUAAAoAAJMAC/A2AAAAhQACAAAA hwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAH/AAAAywHUlAAA/wEIAAgAAQICAAAIAAAQ8AgAAACt DIURtxJqDQ8ABPBkAAAAIgAK8AgAAADOuAUAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAAgQEEAAAI gwEAAAAIvwEAABAAwAH/AAAAywHUlAAAzgECAAAA/wEIAAgAAQICAAAIAAAQ8AgAAAARDoMRtBLV Dg8ABPDbAAAAogwK8AgAAADPuAUAAAoAAAMBC/BgAAAAgADMnAQEgQCQXwEAggDQtgAAgwCQXwEA hADQtgAAhQACAAAAhwABAAAAvwACAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMAfwMAAA8AAAAQ8AgAAACoDBsTxhd8DQ8ADfBLAAAAAACfDwQAAAAEAAAAAACoDxMA AABDb21tZXJjaWFsIHNlcnZpY2VzAAChDxwAAAAUAAAAAAAAKAoAAQAUAAcAFAAAAIAEAgAABBAA DwAE8N8AAACiDArwCAAAANC4BQAACgAAAwEL8GAAAACAAFShBASBAJBfAQCCANC2AACDAJBfAQCE ANC2AACFAAIAAACHAAEAAAC/AAIADwCBAQAAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIA AAg/AgAAAwB/AwAADwAAABDwCAAAABAOQBMrGOQODwAN8E8AAAAAAJ8PBAAAAAQAAAAAAKgPFwAA AFRyaWFsIC8gUGxhbmVkIHNlcnZpY2VzAAChDxwAAAAYAAAAAAAAKAoAAQAUAAcAGAAAAIAEAgAA BBAADwAD8IkKAAAPAATwTAAAAAEACfAQAAAALQIAABYIAADdBAAAVAsAAAIACvAIAAAA0bgFAAEC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAAYwiPAnkFoQsPAATwTgAAALIECvAIAAAA0rgF AAIKAABDAAvwHgAAAH8AgACAAARBCwAAAAXBBgAAAAYBAQAAAGgAawAAAAAAD/AQAAAAZAIAANAJ AABwBAAAnQoAAA8ABPByAAAAIgAK8AgAAADTuAUAAgoAALMAC/BCAAAAhQACAAAAhwABAAAAgQEE AAAIgwEAAAAIvwEAABAAwAH/AAAAywHUlAAAzgECAAAA1wEAAAAA/wEIAAgAAQICAAAIAAAP8BAA AABAAgAAFggAAMQEAADGCQAADwAD8FAEAAAPAATwVAAAAAEACfAQAAAA+wMAAHULAABbCwAADBAA AAIACvAIAAAA1LgFAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAArQIAANIIAABvAwAA agkAAA8AA/AIAwAADwAE8E4AAAABAAnwEAAAAPsDAAC4DgAAWwsAAAwQAAACAArwCAAAANW4BQAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATw/gAAAAIACvAIAAAA 1rgFAAIKAAATAQvwzgAAAEIBYAcAAEMBVAEAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAA AIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgD AAAAAAsACwDw/+oAAAB8BgAAXgc1AWAHQwFYB1ABSQdUARsAVAEIAE4BAAA/AQQALgHqAAAAGAAc AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAA AAD7AwAAuA4AAFsLAAAMEAAADwAE8M4AAAACAArwCAAAANe4BQACCgAAEwEL8J4AAABCAegEAABD AdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAA AADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P+pAAAArQQAAOgE2gAA ANoAqQAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAYwQAAAIPAABLCQAA 3A8AAA8ABPDOAAAAAgAK8AgAAADYuAUAAgoAABMBC/CeAAAAQgF8AQAAQwHaAAAARAEEAAAARcEU AAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAA ywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/AAAAAOEAAAB8AdoARwDaAAAAAAAMABAAAgAA QACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHIJAAACDwAA7goAANwPAAAPAATwQgAAABIA CvAIAAAA2bgFAAIKAAAzAAvwEgAAAL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAApQUAAHULAACv CQAArw4AAA8ABPBIAAAAEgAK8AgAAADauAUAAgoAAEMAC/AYAAAAgQEQUP8AvwEQABAAywGcMQAA /wEIAAgAAAAP8BAAAAAzBgAA5gsAACEJAAAhDgAADwAE8EIAAAASAArwCAAAANu4BQACCgAAMwAL 8BIAAACBAQAAAAC/ARAAEAD/AQAACAAAAA/wEAAAAMMIAABSDgAAIAkAAIAOAAAPAAPwUAQAAA8A BPBUAAAAAQAJ8BAAAAD7AwAAdQsAAFsLAAAMEAAAAgAK8AgAAADcuAUAAwIAACMAC/AMAAAABAAA AAAAiAMAAAAAAAAP8BAAAACYAwAA0ggAAFoEAABqCQAADwAD8AgDAAAPAATwTgAAAAEACfAQAAAA +wMAALgOAABbCwAADBAAAAIACvAIAAAA3bgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMA ALgOAABbCwAADBAAAA8ABPD+AAAAAgAK8AgAAADeuAUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAA RAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH/ //8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgH UAFJB1QBGwBUAQgATgEAAD8BBAAuAeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIA CvAIAAAA37gFAAIKAAATAQvwngAAAEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQAB AIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8B GAAYAIgDAAAAAAUABQDw/6kAAACtBAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBYACAAAAP8BAAAABjBAAAAg8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAOC4BQACCgAA EwEL8J4AAABCAXwBAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCD Af///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA 8P8AAAAA4QAAAHwB2gBHANoAAAAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQ AAAAcgkAAAIPAADuCgAA3A8AAA8ABPBCAAAAEgAK8AgAAADhuAUAAgoAADMAC/ASAAAAvwEQABAA ywGcMQAA/wEIAAgAAAAP8BAAAAClBQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAAOK4BQAC CgAAQwAL8BgAAACBARBQ/wC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEO AAAPAATwQgAAABIACvAIAAAA47gFAAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQ AAAAwwgAAFIOAAAgCQAAgA4AAA8ABPCtAAAAogwK8AgAAADkuAUAAgoAAJMAC/A2AAAAgADMqgQE hQACAAAAhwAGAAAAvwACAAIAgQH/zMwAvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAAAt AgAAgAoAAN0EAABUCwAADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEhvbmcgS29uZwAAoQ8a AAAACgAAAAAAAAgKAAEABwAKAAAAEQACAJEAEAAPAATwXgAAAEIBCvAIAAAA5bgFAAAKAACTAAvw NgAAAIUAAgAAAIcAAQAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAAP8BGAAYAAECAgAA CAAAEPAIAAAAAwWICIgIsgYPAATwnQAAAKIMCvAIAAAA5rgFAAAKAACDAAvwMAAAAIAARK8EBIUA AgAAAIcABgAAAL8AAgACAIEBBAAACL8BAAAQAMABAQAACP8BAAAIAAAAEPAIAAAAqQNQB4wJkAQP AA3wPQAAAAAAnw8EAAAABAAAAAAAqA8FAAAASlBOQVAAAKEPHAAAAAYAAAAAAAAACgAHAAYAAAAB AAYAgQASAP8AAP4PAATwagAAACIACvAIAAAA57gFAAAKAACzAAvwQgAAAIUAAgAAAIcAAQAAAIEB BAAACIMBAAAACL8BAAAQAMAB/wAAAMsB1JQAAM4BAgAAANcBAAAAAP8BCAAIAAECAgAACAAAEPAI AAAAswNQB8AJrgUPAATwVAAAALIECvAIAAAA6LgFAAAKAABDAAvwLAAAAH8AgACAAARBDAAAAAXB FAAAAAYBAQAAAG0AZgAtAGwAbwBnAG8AXwBsAAAAAAAQ8AgAAABQBJAG/AdtBQ8ABPBYAAAAMgAK 8AgAAADpuAUAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAvwAAAA0AgQH/AAAAvwEQABAA/wEGAAYA PwIAAAEAfwMAAA8AAAAQ8AgAAACTBCAI0QhEBQ8ABPBeAAAAQgEK8AgAAADquAUAAAoAAJMAC/A2 AAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywHUlAAA/wEYABgAAQICAAAI AAAQ8AgAAAC3BCkUKRR3Bg8ABPBYAAAAMgAK8AgAAADruAUAAAoAAIMAC/AwAAAAhQACAAAAhwAB AAAAvwAAAA0AgQEAmQAAvwEQABAA/wEGAAYAPwIAAAEAfwMAAA8AAAAQ8AgAAABdBM4TfhQPBQ8A BPCcAAAAogwK8AgAAADsuAUAAAoAAIMAC/AwAAAAgAB4tAQEhQACAAAAhwAGAAAAvwACAAIAgQEE AAAIvwEAABAAwAEBAAAI/wEAAAgAAAAQ8AgAAAB6A+wSyBRhBA8ADfA8AAAAAACfDwQAAAAEAAAA AACoDwQAAABMSU5YAAChDxwAAAAFAAAAAAAAAAoABwAFAAAAAQAGAIEAEgD/AAD+DwAD8I4JAAAP AATwTAAAAAEACfAQAAAA2QMAAKMDAADoBwAA5wYAAAIACvAIAAAA7bgFAAECAAAjAAvwDAAAAAQA AAAAAIgDAAAAAAAAEPAIAAAAkwh3BlQI9QkPAATwYAAAALIECvAIAAAA7rgFAAIKAACDAAvwMAAA AARBDQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAA 2QMAACMFAACIBQAA5wYAAA8ABPBgAAAAsgQK8AgAAADvuAUAAgoAAIMAC/AwAAAABEEOAAAAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAACuBgAAUQUAAOgH AADDBgAADwAD8GIDAAAPAATwVAAAAAEACfAQAAAAfw0AAPIDAAC0DwAAIgQAAAIACvAIAAAA8LgF AEMCAAAjAAvwDAAAAAQAMZDV/4gDAAAAAAAAD/AQAAAA1gYAALwEAACoBwAAAAUAAA8ABPACAQAA AgAK8AgAAADxuAUAAgoAAGMBC/DSAAAAQgFQAQAAQwEXAAAARAEEAAAARcEgAAAARsEoAAAAfwEB AAEAgAEAAAAAgQEAgAAAvwEQABAAwAEAmQAAwQEAAAEAxAEAAAAAywGcMQAAzQEAAAAAzgEAAAAA 0AEAAAAA0QEAAAAA1wEAAAAA/wEYABgAAQICAAAIPwIAAAIAiAMAAAAACAAIAPD/TAAWAFAAEQBJ ARUATwEKAFYABgBZAAAAAAAKAEwAFgARABQAAgAAQACwAQAAsAEAALABAACwAQAAsAEAALABAACw AQAAsACAAAAP8BAAAAB/DQAACwQAAM8OAAAiBAAADwAE8AIBAAACAArwCAAAAPK4BQACCgAAYwEL 8NIAAABCAWQBAABDARYAAABEAQQAAABFwSAAAABGwSgAAAB/AQEAAQCAAQAAAACBAQCAAAC/ARAA EADAAQCZAADBAQAAAQDEAQAAAADLAZwxAADNAQAAAADOAQAAAADQAQAAAADRAQAAAADXAQAAAAD/ ARgAGAABAgIAAAg/AgAAAgCIAwAAAAAIAAgA8P8SAQAADwEFAAYAAQAAAAsACAEQAAUBFQBjAQwA EgEAABEAFAACAABAALABAACwAQAAsAEAALABAACwAQAAsAEAALABAACwAIAAAA/wEAAAAFAOAADy AwAAtA8AAAgEAAAPAATw6gAAAAIACvAIAAAA87gFAAIKAABjAQvwugAAAEIBfQAAAEMBLQAAAEQB BAAAAEXBFAAAAEbBHAAAAH8BAQABAIABAAAAAIEBAIAAAL8BEAAQAMABAJkAAMEBAAABAMQBAAAA AMsBnDEAAM0BAAAAAM4BAAAAANABAAAAANEBAAAAANcBAAAAAP8BGAAYAAECAgAACD8CAAACAIgD AAAAAAUABQDw/1oALAAAAAoAIgAAAHwAIgBaACwACwAMAAIAAEAAsAEAALABAACwAQAAsAEAALAA gAAAD/AQAAAAVw4AAPQDAADUDgAAIQQAAA8AA/COAQAADwAE8FQAAAABAAnwEAAAALICAAC2BwAA EgMAAAoIAAACAArwCAAAAPS4BQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAANsFAACj AwAAqQYAAEEEAAAPAATwYAAAAEIBCvAIAAAA9bgFAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAD/AQAAAA+gIAALYHAAD6AgAA5gcA AA8ABPBgAAAAQgEK8AgAAAD2uAUAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAP8BAAAADWAgAAtgcAANYCAADyBwAADwAE8FoAAAAS AArwCAAAAPe4BQACCgAAcwAL8CoAAACFAAIAAACHAAEAAACBATMzMwC/ARAAEADAAQEAAAj/AQgA CAABAgIAAAgAAA/wEAAAALICAADaBwAAEgMAAAoIAAAPAAPwYgMAAA8ABPBUAAAAAQAJ8BAAAAB/ DQAA8gMAALQPAAAiBAAAAgAK8AgAAAD4uAUAAwIAACMAC/AMAAAABAAxkNX/iAMAAAAAAAAP8BAA AABOBQAAxQQAADMGAAD7BAAADwAE8AIBAAACAArwCAAAAPm4BQACCgAAYwEL8NIAAABCAVABAABD ARcAAABEAQQAAABFwSAAAABGwSgAAAB/AQEAAQCAAQAAAACBAQCAAAC/ARAAEADAAQCZAADBAQAA AQDEAQAAAADLAZwxAADNAQAAAADOAQAAAADQAQAAAADRAQAAAADXAQAAAAD/ARgAGAABAgIAAAg/ AgAAAgCIAwAAAAAIAAgA8P9MABYAUAARAEkBFQBPAQoAVgAGAFkAAAAAAAoATAAWABEAFAACAABA ALABAACwAQAAsAEAALABAACwAQAAsAEAALABAACwAIAAAA/wEAAAAH8NAAALBAAAzw4AACIEAAAP AATwAgEAAAIACvAIAAAA+rgFAAIKAABjAQvw0gAAAEIBZAEAAEMBFgAAAEQBBAAAAEXBIAAAAEbB KAAAAH8BAQABAIABAAAAAIEBAIAAAL8BEAAQAMABAJkAAMEBAAABAMQBAAAAAMsBnDEAAM0BAAAA AM4BAAAAANABAAAAANEBAAAAANcBAAAAAP8BGAAYAAECAgAACD8CAAACAIgDAAAAAAgACADw/xIB AAAPAQUABgABAAAACwAIARAABQEVAGMBDAASAQAAEQAUAAIAAEAAsAEAALABAACwAQAAsAEAALAB AACwAQAAsAEAALAAgAAAD/AQAAAAUA4AAPIDAAC0DwAACAQAAA8ABPDqAAAAAgAK8AgAAAD7uAUA AgoAAGMBC/C6AAAAQgF9AAAAQwEtAAAARAEEAAAARcEUAAAARsEcAAAAfwEBAAEAgAEAAAAAgQEA gAAAvwEQABAAwAEAmQAAwQEAAAEAxAEAAAAAywGcMQAAzQEAAAAAzgEAAAAA0AEAAAAA0QEAAAAA 1wEAAAAA/wEYABgAAQICAAAIPwIAAAIAiAMAAAAABQAFAPD/WgAsAAAACgAiAAAAfAAiAFoALAAL AAwAAgAAQACwAQAAsAEAALABAACwAQAAsACAAAAP8BAAAABXDgAA9AMAANQOAAAhBAAADwAE8F4A AABCAQrwCAAAAPy4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAABMHhAeEB4QIDwAE8GQAAAAiAArwCAAAAP24 BQAACgAAowAL8DwAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAADO AQIAAAD/AQgACAABAgIAAAgAABDwCAAAAHEIIwbeCDEKDwAE8NUAAAAyAArwCAAAAP64BQAACgAA owAL8DwAAACAAIy8BASFAAIAAACHAAEAAACBAZnM/wC/ARAAEADAAQEAAAj/AQgACAABAgIAAAg/ AgIAAgC/AgAACAAAABDwCAAAADIGoAHPFqQHDwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPHwAAAE5U VC9WRVJJTyBHbG9iYWwgSVB2NiBCYWNrYm9uZSAAAKEPLgAAACAAAAAAAAAICgABAAcACQAAAAMA RwCDAAMAAwAUAAAAzP4XAAAAAQACAIEAFAAPAATwwQAAABIACvAIAAAA/7gFAAAKAACjAAvwPAAA AIAAfL4EBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC AgAACAAAEPAIAAAAqQx2DSMQIw8PAA3wVQAAAAAAnw8EAAAABAAAAAAAqA8VAAAASVB2Ng1HYXRl d2F5DVNlcnZpY2VzAAChDyQAAAAWAAAAAAAACAoAAQAHABUAAAADAAIAgwAUAAEAAAADAAAAgwAP AATwXgAAACIACvAIAAAAALkFAAAKAACTAAvwNgAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8B AAAQAMAB/wAAAMsBPt8AAP8BCAAIAAECAgAACAAAEPAIAAAAgQuiBagQGQ8PAATwxgAAABIACvAI AAAAAbkFAAAKAACjAAvwPAAAAIAA3MYEBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8B AAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAngw1Cl4NGA8PAA3wWgAAAAAAnw8EAAAABAAA AAAAqA8YAAAASVB2Ng1UdW5uZWxpbmcNU2VydmljZXMgAAChDyYAAAAZAAAAAAAACAoAAQAHABcA AAADAAIAgwAUAAIAAAADAAIAgwASAA8AA/BIBAAADwAE8EwAAAABAAnwEAAAAPsDAAB1CwAAWwsA AAwQAAACAArwCAAAAAK5BQABAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAAUMQQsTDJ0M DwAD8AgDAAAPAATwTgAAAAEACfAQAAAA+wMAALgOAABbCwAADBAAAAIACvAIAAAAA7kFAAMCAAAT AAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPD+AAAAAgAK8AgAAAAEuQUA AgoAABMBC/DOAAAAQgFgBwAAQwFUAQAARAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQH/ //8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAA CwALAPD/6gAAAHwGAABeBzUBYAdDAVgHUAFJB1QBGwBUAQgATgEAAD8BBAAuAeoAAAAYABwAAgAA QACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAPsD AAC4DgAAWwsAAAwQAAAPAATwzgAAAAIACvAIAAAABbkFAAIKAAATAQvwngAAAEIB6AQAAEMB2gAA AEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB ////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/6kAAACtBAAA6ATaAAAA2gCp AAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABjBAAAAg8AAEsJAADcDwAA DwAE8M4AAAACAArwCAAAAAa5BQACCgAAEwEL8J4AAABCAXwBAABDAdoAAABEAQQAAABFwRQAAABG wR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwx AADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P8AAAAA4QAAAHwB2gBHANoAAAAAAAwAEAACAABAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgkAAAIPAADuCgAA3A8AAA8ABPBCAAAAEgAK8AgA AAAHuQUAAgoAADMAC/ASAAAAvwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAAClBQAAdQsAAK8JAACv DgAADwAE8EgAAAASAArwCAAAAAi5BQACCgAAQwAL8BgAAACBARBQ/wC/ARAAEADLAZwxAAD/AQgA CAAAAA/wEAAAADMGAADmCwAAIQkAACEOAAAPAATwQgAAABIACvAIAAAACbkFAAIKAAAzAAvwEgAA AIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQAAAAwwgAAFIOAAAgCQAAgA4AAA8AA/BIBAAADwAE8EwA AAABAAnwEAAAAPsDAAB1CwAAWwsAAAwQAAACAArwCAAAAAq5BQABAgAAIwAL8AwAAAAEAAAAAACI AwAAAAAAABDwCAAAAAUMPwwRDZ0MDwAD8AgDAAAPAATwTgAAAAEACfAQAAAA+wMAALgOAABbCwAA DBAAAAIACvAIAAAAC7kFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMAALgOAABbCwAADBAA AA8ABPD+AAAAAgAK8AgAAAAMuQUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAARAEEAAAARcEsAAAA RsE2AAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGc MQAAzgEAAAAA/wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgHUAFJB1QBGwBUAQgA TgEAAD8BBAAuAeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIACvAIAAAADbkFAAIK AAATAQvwngAAAEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB//// AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUA BQDw/6kAAACtBAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAABjBAAAAg8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAA65BQACCgAAEwEL8J4AAABCAXwB AABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADA AQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P8AAAAA4QAAAHwB 2gBHANoAAAAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgkAAAIPAADu CgAA3A8AAA8ABPBCAAAAEgAK8AgAAAAPuQUAAgoAADMAC/ASAAAAvwEQABAAywGcMQAA/wEIAAgA AAAP8BAAAAClBQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAABC5BQACCgAAQwAL8BgAAACB ARBQ/wC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEOAAAPAATwQgAAABIA CvAIAAAAEbkFAAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQAAAAwwgAAFIOAAAg CQAAgA4AAA8ABPCgAAAAMgAK8AgAAAASuQUAAAoAAIMAC/AwAAAAgABc0AQEhQACAAAAhwABAAAA gQEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADeCzQNQBCyDA8ADfBAAAAAAACf DwQAAAAEAAAAAACoDwgAAABJU1AsIGlEQwAAoQ8cAAAACQAAAAAAAAgKAAEABwAJAAAAAAAGABAA AAAAAw8ABPBWAAAAsgQK8AgAAAATuQUAAAoAAEMAC/AuAAAAfwCAAIAABEEPAAAABcEWAAAABgEB AAAAaQBjAG8AbgBfAG4AZQB3ADAAMwAAAAAAEPAIAAAA7QfKBRwHkwgPAATwVgAAALIECvAIAAAA FLkFAAAKAABDAAvwLgAAAH8AgACAAARBDwAAAAXBFgAAAAYBAQAAAGkAYwBvAG4AXwBuAGUAdwAw ADMAAAAAABDwCAAAAD0DgAbSB+MDDwAE8MoAAAASAArwCAAAABW5BQAACgAAowAL8DwAAACAANDU BASFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA ABDwCAAAAJ4MtQVWCRgPDwAN8F4AAAAAAJ8PBAAAAAQAAAAAAKgPHAAAAElQdjYvSVB2NA1EdWFs IEFjY2Vzcw13LyBQblAAAKEPJgAAAB0AAAAAAAAICgABAAcAHAAAAAMAAgCDABQAAQAAAAMAAgCD ABIADwAD8EgEAAAPAATwTAAAAAEACfAQAAAA+wMAAHULAABbCwAADBAAAAIACvAIAAAAFrkFAAEC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAABQzLBp0HnQwPAAPwCAMAAA8ABPBOAAAAAQAJ 8BAAAAD7AwAAuA4AAFsLAAAMEAAAAgAK8AgAAAAXuQUAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAA AAD7AwAAuA4AAFsLAAAMEAAADwAE8P4AAAACAArwCAAAABi5BQACCgAAEwEL8M4AAABCAWAHAABD AVQBAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAA AADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAALAAsA8P/qAAAAfAYAAF4HNQFg B0MBWAdQAUkHVAEbAFQBCABOAQAAPwEEAC4B6gAAABgAHAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPDO AAAAAgAK8AgAAAAZuQUAAgoAABMBC/CeAAAAQgHoBAAAQwHaAAAARAEEAAAARcEUAAAARsEeAAAA fwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEA AAAA/wEYABgAiAMAAAAABQAFAPD/qQAAAK0EAADoBNoAAADaAKkAAAAMABAAAgAAQACsAQAArAEA AKwBAACsAQAArAFgAIAAAA/wEAAAAGMEAAACDwAASwkAANwPAAAPAATwzgAAAAIACvAIAAAAGrkF AAIKAAATAQvwngAAAEIBfAEAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB ////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAA AAUABQDw/wAAAADhAAAAfAHaAEcA2gAAAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACA AAAP8BAAAAByCQAAAg8AAO4KAADcDwAADwAE8EIAAAASAArwCAAAABu5BQACCgAAMwAL8BIAAAC/ ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAAKUFAAB1CwAArwkAAK8OAAAPAATwSAAAABIACvAIAAAA HLkFAAIKAABDAAvwGAAAAIEBEFD/AL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAAMwYAAOYLAAAh CQAAIQ4AAA8ABPBCAAAAEgAK8AgAAAAduQUAAgoAADMAC/ASAAAAgQEAAAAAvwEQABAA/wEAAAgA AAAP8BAAAADDCAAAUg4AACAJAACADgAADwAD8EgEAAAPAATwTAAAAAEACfAQAAAA+wMAAHULAABb CwAADBAAAAIACvAIAAAAHrkFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAABQzJB5wI nQwPAAPwCAMAAA8ABPBOAAAAAQAJ8BAAAAD7AwAAuA4AAFsLAAAMEAAAAgAK8AgAAAAfuQUAAwIA ABMAC/AGAAAAiAMAAAAAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8P4AAAACAArwCAAAACC5 BQACCgAAEwEL8M4AAABCAWAHAABDAVQBAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACB Af///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAA AAALAAsA8P/qAAAAfAYAAF4HNQFgB0MBWAdQAUkHVAEbAFQBCABOAQAAPwEEAC4B6gAAABgAHAAC AABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA +wMAALgOAABbCwAADBAAAA8ABPDOAAAAAgAK8AgAAAAhuQUAAgoAABMBC/CeAAAAQgHoBAAAQwHa AAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAA wgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/qQAAAK0EAADoBNoAAADa AKkAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGMEAAACDwAASwkAANwP AAAPAATwzgAAAAIACvAIAAAAIrkFAAIKAAATAQvwngAAAEIBfAEAAEMB2gAAAEQBBAAAAEXBFAAA AEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsB nDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/wAAAADhAAAAfAHaAEcA2gAAAAAADAAQAAIAAEAA rAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAByCQAAAg8AAO4KAADcDwAADwAE8EIAAAASAArw CAAAACO5BQACCgAAMwAL8BIAAAC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAAKUFAAB1CwAArwkA AK8OAAAPAATwSAAAABIACvAIAAAAJLkFAAIKAABDAAvwGAAAAIEBEFD/AL8BEAAQAMsBnDEAAP8B CAAIAAAAD/AQAAAAMwYAAOYLAAAhCQAAIQ4AAA8ABPBCAAAAEgAK8AgAAAAluQUAAgoAADMAC/AS AAAAgQEAAAAAvwEQABAA/wEAAAgAAAAP8BAAAADDCAAAUg4AACAJAACADgAADwAE8F4AAABCAQrw CAAAACa5BQBACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjL AdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAEMKlQcFChQMDwAD8GIBAAAPAATwTAAAAAEACfAQAAAA 4AQAANALAACfBwAAbQ0AAAIACvAIAAAAJ7kFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAI AAAAUwkmCSAM8AoPAATwrAAAADIACvAIAAAAKLkFAAIKAACDAAvwMAAAAIAA7MAEBIUAAgAAAIcA AQAAAIEBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAA4AQAANALAACfBwAAbQ0A AA8ADfBEAAAAAACfDwQAAAAEAAAAAAChDxwAAAABAAAAAAAACAoAAgAHAAEAAAAAAAYAEAAAAAAD AACqDwwAAAABAAAABgAAAAkEAAAPAATwUgAAALIECvAIAAAAKbkFAAIKAABDAAvwIgAAAH8AgACA AARBBQAAAAXBCgAAAAYBAQAAAGEAYwBjAGEAAAAAAA/wEAAAAEAFAAAwDAAANgcAABQNAAAPAAPw YAEAAA8ABPBMAAAAAQAJ8BAAAABABQAAcAgAAP8HAAANCgAAAgAK8AgAAAAquQUAAQIAACMAC/AM AAAABAAAAAAAiAMAAAAAAAAQ8AgAAABGCOgK4Q3jCQ8ABPCsAAAAMgAK8AgAAAAruQUAAgoAAIMA C/AwAAAAgACk4wQEhQACAAAAhwABAAAAgQEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP 8BAAAABABQAAcAgAAP8HAAANCgAADwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKEPHAAAAAEAAAAAAAAI CgACAAcAAQAAAAAABgAQAAAAAAMAAKoPDAAAAAEAAAAGAAAACQQAAA8ABPBQAAAAsgQK8AgAAAAs uQUAAgoAAEMAC/AgAAAAfwCAAIAABEEEAAAABcEIAAAABgEBAAAAbwBjAG4AAAAAAA/wEAAAANAF AABwCAAAXAcAAPwJAAAPAATwmgAAALIECvAIAAAALbkFACAKAADDAAvwWgAAAAQAAAAAAH8ABAAF AARBEAAAAAXBEAAAAAYBAQAAAIEB////AL8BAAABAMABAAAAAP8BAAABAAEDAwQAAIHDAgAAAIgD AAAAAGgAbwB0AHMAcABvAHQAAAAAAAAAEPAIAAAAYwpXBtII0AoPABHwEAAAAAAAwwsIAAAAAQAA ABMABAQPAATw7wAAAKIMCvAIAAAALrkFAAAKAADzAAvwWgAAAIAAuOYEBIEAkF8BAIIA0LYAAIMA kF8BAIQA0LYAAIcAAQAAAL8AAgAPAIEBAAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAA CD8CAAADAH8DAAAPAAAAEPAIAAAA7g1+ALIDrg4PAA3wZQAAAAAAnw8EAAAABAAAAAAAqA8LAAAA TlRUIEF1c3QgSVAAAKEPHAAAAAwAAAAAAAAoCgABABQABwAMAAAAgwQCAAMEDgAAAKoPGgAAAAQA AAAAAAAABAAAAAEAAAADAAQAAAAAAAAADwAE8GQAAAAiAArwCAAAAC+5BQAACgAAowAL8DwAAACF AAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAADOAQIAAAD/AQgACAABAgIA AAgAABDwCAAAAIMM2QBdA+kNDwAD8EgEAAAPAATwTAAAAAEACfAQAAAA+wMAAHULAABbCwAADBAA AAIACvAIAAAAMLkFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAA9QxGAQgCjQ0PAAPw CAMAAA8ABPBOAAAAAQAJ8BAAAAD7AwAAuA4AAFsLAAAMEAAAAgAK8AgAAAAxuQUAAwIAABMAC/AG AAAAiAMAAAAAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8P4AAAACAArwCAAAADK5BQACCgAA EwEL8M4AAABCAWAHAABDAVQBAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAf///wCD Af///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAALAAsA 8P/qAAAAfAYAAF4HNQFgB0MBWAdQAUkHVAEbAFQBCABOAQAAPwEEAC4B6gAAABgAHAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA+wMAALgO AABbCwAADBAAAA8ABPDOAAAAAgAK8AgAAAAzuQUAAgoAABMBC/CeAAAAQgHoBAAAQwHaAAAARAEE AAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8A xAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/qQAAAK0EAADoBNoAAADaAKkAAAAM ABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGMEAAACDwAASwkAANwPAAAPAATw zgAAAAIACvAIAAAANLkFAAIKAAATAQvwngAAAEIBfAEAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAA AH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4B AAAAAP8BGAAYAIgDAAAAAAUABQDw/wAAAADhAAAAfAHaAEcA2gAAAAAADAAQAAIAAEAArAEAAKwB AACsAQAArAEAAKwBYACAAAAP8BAAAAByCQAAAg8AAO4KAADcDwAADwAE8EIAAAASAArwCAAAADW5 BQACCgAAMwAL8BIAAAC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAAKUFAAB1CwAArwkAAK8OAAAP AATwSAAAABIACvAIAAAANrkFAAIKAABDAAvwGAAAAIEBEFD/AL8BEAAQAMsBnDEAAP8BCAAIAAAA D/AQAAAAMwYAAOYLAAAhCQAAIQ4AAA8ABPBCAAAAEgAK8AgAAAA3uQUAAgoAADMAC/ASAAAAgQEA AAAAvwEQABAA/wEAAAgAAAAP8BAAAADDCAAAUg4AACAJAACADgAADwAD8EgEAAAPAATwTAAAAAEA CfAQAAAA+wMAAHULAABbCwAADBAAAAIACvAIAAAAOLkFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAA AAAAEPAIAAAA9QwxAvMCjQ0PAAPwCAMAAA8ABPBOAAAAAQAJ8BAAAAD7AwAAuA4AAFsLAAAMEAAA AgAK8AgAAAA5uQUAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE 8P4AAAACAArwCAAAADq5BQACCgAAEwEL8M4AAABCAWAHAABDAVQBAABEAQQAAABFwSwAAABGwTYA AAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADO AQAAAAD/ARgAGACIAwAAAAALAAsA8P/qAAAAfAYAAF4HNQFgB0MBWAdQAUkHVAEbAFQBCABOAQAA PwEEAC4B6gAAABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAWAAgAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPDOAAAAAgAK8AgAAAA7uQUAAgoAABMB C/CeAAAAQgHoBAAAQwHaAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH/ //8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/ qQAAAK0EAADoBNoAAADaAKkAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAA AGMEAAACDwAASwkAANwPAAAPAATwzgAAAAIACvAIAAAAPLkFAAIKAAATAQvwngAAAEIBfAEAAEMB 2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAA AMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/wAAAADhAAAAfAHaAEcA 2gAAAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAByCQAAAg8AAO4KAADc DwAADwAE8EIAAAASAArwCAAAAD25BQACCgAAMwAL8BIAAAC/ARAAEADLAZwxAAD/AQgACAAAAA/w EAAAAKUFAAB1CwAArwkAAK8OAAAPAATwSAAAABIACvAIAAAAPrkFAAIKAABDAAvwGAAAAIEBEFD/ AL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAAMwYAAOYLAAAhCQAAIQ4AAA8ABPBCAAAAEgAK8AgA AAA/uQUAAgoAADMAC/ASAAAAgQEAAAAAvwEQABAA/wEAAAgAAAAP8BAAAADDCAAAUg4AACAJAACA DgAADwAE8KUAAACiDArwCAAAAEC5BQAACgAAkwAL8DYAAACAAPzvBASFAAIAAACHAAYAAAC/AAIA AgCBAf/MzAC/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAEkONAGpAx0PDwAN8D8AAAAA AJ8PBAAAAAQAAAAAAKgPCQAAAEF1c3RyYWxpYQAAoQ8aAAAACgAAAAAAAAgKAAEABwAKAAAAEQAC AJEAEAAPAATwXgAAAEIBCvAIAAAAQbkFAAAKAACTAAvwNgAAAIUAAgAAAIcAAQAAAEQBBAAAAH8B AAABAL8BAAAQAMABAQAACMsB1JQAAP8BGAAYAAECAgAACAAAEPAIAAAAigQJEgkSSgYPAATwWAAA ADIACvAIAAAAQrkFAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAL8AAAANAIEBAJkAAL8BEAAQAP8B BgAGAD8CAAABAH8DAAAPAAAAEPAIAAAANwSpEUsS6QQPAATwnAAAAKIMCvAIAAAAQ7kFAAAKAACD AAvwMAAAAIAAvPQEBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACL8BAAAQAMABAQAACP8BAAAIAAAA EPAIAAAAYAPdENkSRwQPAA3wPAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAVUs2WAAAoQ8cAAAABQAA AAAAAAAKAAcABQAAAAEABgCBABIA/wAA/g8ABPBIAAAAEgAK8AgAAAABuAUAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBOBAAAADwCKE3kAAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTWQAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAC5EwD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDu A4KMAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwATAA8ADAQxfAAADwAC8Cl8AAAADAjw CAAAAGgBAABptQUADwAD8Hl7AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAALQFAAUAAAAPAAPwTAEAAA8ABPBMAAAAAQAJ8BAAAABABQAAcAgAAP8HAAANCgAAAgAK8AgA AAACtAUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAAAmBi4Ecgh2CA8ABPCYAAAAMgAK 8AgAAAADtAUAAgoAAIMAC/AwAAAAgABEAe0EhQACAAAAhwABAAAAgQEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAP8BAAAABABQAAcAgAAP8HAAANCgAADwAN8DAAAAAAAJ8PBAAAAAQAAAAA AKEPHAAAAAEAAAAAAAAICgACAAcAAQAAAAAABgAQAAAAAAMPAATwUAAAALIECvAIAAAABLQFAAIK AABDAAvwIAAAAH8AgACAAARBBAAAAAXBCAAAAAYBAQAAAG8AYwBuAAAAAAAP8BAAAADQBQAAcAgA AFwHAAD8CQAADwAD8E4BAAAPAATwTAAAAAEACfAQAAAA4AQAANALAACfBwAAbQ0AAAIACvAIAAAA BbQFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAAeQaBB3oKFggPAATwmAAAADIACvAI AAAABrQFAAIKAACDAAvwMAAAAIAAqAXtBIUAAgAAAIcAAQAAAIEBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACAAAD/AQAAAA4AQAANALAACfBwAAbQ0AAA8ADfAwAAAAAACfDwQAAAAEAAAAAACh DxwAAAABAAAAAAAACAoAAgAHAAEAAAAAAAYAEAAAAAADDwAE8FIAAACyBArwCAAAAAe0BQACCgAA QwAL8CIAAAB/AIAAgAAEQQUAAAAFwQoAAAAGAQEAAABhAGMAYwBhAAAAAAAP8BAAAABABQAAMAwA ADYHAAAUDQAADwAE8H4AAAASAArwCAAAAAi0BQAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACAAMQG 7QS/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAGAA1AGMFjADDwAR8BAAAAAAAMMLCAAA AAAAAAANAO0EDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwWAAAAEIBCvAIAAAACbQFAAAKAACDAAvw MAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BAgAAANcBAAAAAP8BGAAYAAECAgAACAAAEPAI AAAAhgc4BDgERg4PAATwWAAAAEIBCvAIAAAACrQFAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8B AAAQAMABAQAACM4BAgAAANcBAAAAAP8BGAAYAAECAgAACAAAEPAIAAAAdgedC50LNg4PAATwWAAA AEIBCvAIAAAAC7QFAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BAgAAANcB AAAAAP8BGAAYAAECAgAACAAAEPAIAAAAdgeBEYERNg4PAATwWAAAAEIBCvAIAAAADLQFAAAKAACD AAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BAgAAANcBAAAAAP8BGAAYAAECAgAACAAA EPAIAAAAdgeqFqoWNg4PAATwzAAAAGIBCvAIAAAADrQFAAAKAADzAAvwWgAAAIAA8AntBIEAkF8B AIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgAPAIEBBAAACL8BHAAeAMABAQAACP8B DgAOAAECAgAACD8CAAADAH8DAAAPAAAAEPAIAAAA8wZFAzIF6wcPAA3wQgAAAAAAnw8EAAAABAAA AAAAqA8GAAAAUkFESVVTAAChDyAAAAAHAAAAAAAAKAoAAQAUAAcABwAAAIAEQwAABAQABAAMAA8A BPB8AAAAAgIK8AgAAAAPtAUAAAsAAOMAC/BUAAAAhQACAAAAvwAAAA8AvwEAABAAwAEBAAAI1gEB AAAA/wEOAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AAwMAAAAAfwMQAD8AhAMAAAAAhgMAAAAA AAAQ8AgAAABGBwkNfRBLBw8ABPB8AAAAAgIK8AgAAAAQtAUAgAsAAOMAC/BUAAAAhQACAAAAvwAA AA8AvwEAABAAwAEBAAAI1gEBAAAA/wEOAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AAwMAAAAA fwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAAAEB1cSKxZLBw8ABPDMAAAAogwK8AgAAAARtAUAAAoA AAMBC/BgAAAAgADQ/QQEhQACAAAAhwAGAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI /wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAABG B3gNEQ8GCA8ADfA8AAAAAACfDwQAAAAEAAAAAACoDwQAAABBRFNMAAChDxwAAAAFAAAAAAAQAAoA BAAHAAUAAAAAAEMABAAEAA4ADwAE8MsAAACiDArwCAAAABK0BQAACgAAAwEL8GAAAACAANwP7QSF AAIAAACHAAYAAAC/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAA AwC/AgEADwD/AhYAHwB/AxAAPwCEAwAAAACGAwAAAAAAABDwCAAAAEYHgBPUFAYIDwAN8DsAAAAA AJ8PBAAAAAQAAAAAAKgPAwAAAExBTgAAoQ8cAAAABAAAAAAAEAAKAAQABwAEAAAAAABDAAQABAAO AA8ABPBqAAAAsgQK8AgAAAATtAUAAAoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEGAAAA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAABgBioKCQ0r CA8ABPBqAAAAsgQK8AgAAAAUtAUAAAoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEGAAAA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAAC2Bn0QVxLf Bw8AA/AwWwAADwAE8EwAAAABAAnwEAAAAAoCAADXCwAA3QIAAMgMAAACAArwCAAAABW0BQABAgAA IwAL8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAIYGDhZ6FwYIDwAD8CINAAAPAATwTgAAAAEACfAQ AAAATAIAAHsMAACbAgAApwwAAAIACvAIAAAAFrQFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA TAIAAHsMAACbAgAApwwAAA8AA/B6DAAADwAE8E4AAAABAAnwEAAAAEwCAAB7DAAAmgIAAKYMAAAC AArwCAAAABe0BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAEwCAAB7DAAAmgIAAKYMAAAPAATw QgAAABIACvAIAAAAGLQFAAIKAAAzAAvwEgAAAIEBVktwAL8BEAAQAP8BAAAIAAAAD/AQAAAATAIA AHsMAABOAgAApgwAAA8ABPBCAAAAEgAK8AgAAAAZtAUAAgoAADMAC/ASAAAAgQFWS3EAvwEQABAA /wEAAAgAAAAP8BAAAABOAgAAewwAAFACAACmDAAADwAE8EIAAAASAArwCAAAABq0BQACCgAAMwAL 8BIAAACBAVdMcgC/ARAAEAD/AQAACAAAAA/wEAAAAFACAAB7DAAAUgIAAKYMAAAPAATwQgAAABIA CvAIAAAAG7QFAAIKAAAzAAvwEgAAAIEBWU10AL8BEAAQAP8BAAAIAAAAD/AQAAAAUgIAAHsMAABU AgAApgwAAA8ABPBCAAAAEgAK8AgAAAActAUAAgoAADMAC/ASAAAAgQFaT3YAvwEQABAA/wEAAAgA AAAP8BAAAABUAgAAewwAAFYCAACmDAAADwAE8EIAAAASAArwCAAAAB20BQACCgAAMwAL8BIAAACB AVxReAC/ARAAEAD/AQAACAAAAA/wEAAAAFYCAAB7DAAAVwIAAKYMAAAPAATwQgAAABIACvAIAAAA HrQFAAIKAAAzAAvwEgAAAIEBX1N7AL8BEAAQAP8BAAAIAAAAD/AQAAAAVwIAAHsMAABZAgAApgwA AA8ABPBCAAAAEgAK8AgAAAAftAUAAgoAADMAC/ASAAAAgQFiVX8AvwEQABAA/wEAAAgAAAAP8BAA AABZAgAAewwAAFsCAACmDAAADwAE8EIAAAASAArwCAAAACC0BQACCgAAMwAL8BIAAACBAWRXggC/ ARAAEAD/AQAACAAAAA/wEAAAAFsCAAB7DAAAXQIAAKYMAAAPAATwQgAAABIACvAIAAAAIbQFAAIK AAAzAAvwEgAAAIEBaFqGAL8BEAAQAP8BAAAIAAAAD/AQAAAAXQIAAHsMAABfAgAApgwAAA8ABPBC AAAAEgAK8AgAAAAitAUAAgoAADMAC/ASAAAAgQFrXYoAvwEQABAA/wEAAAgAAAAP8BAAAABfAgAA ewwAAGECAACmDAAADwAE8EIAAAASAArwCAAAACO0BQACCgAAMwAL8BIAAACBAW1fjgC/ARAAEAD/ AQAACAAAAA/wEAAAAGECAAB7DAAAYwIAAKYMAAAPAATwQgAAABIACvAIAAAAJLQFAAIKAAAzAAvw EgAAAIEBcGKRAL8BEAAQAP8BAAAIAAAAD/AQAAAAYwIAAHsMAABlAgAApgwAAA8ABPBCAAAAEgAK 8AgAAAAltAUAAgoAADMAC/ASAAAAgQFzZJQAvwEQABAA/wEAAAgAAAAP8BAAAABlAgAAewwAAGYC AACmDAAADwAE8EIAAAASAArwCAAAACa0BQACCgAAMwAL8BIAAACBAXVmlwC/ARAAEAD/AQAACAAA AA/wEAAAAGYCAAB7DAAAaAIAAKYMAAAPAATwQgAAABIACvAIAAAAJ7QFAAIKAAAzAAvwEgAAAIEB d2eaAL8BEAAQAP8BAAAIAAAAD/AQAAAAaAIAAHsMAABqAgAApgwAAA8ABPBCAAAAEgAK8AgAAAAo tAUAAgoAADMAC/ASAAAAgQF4aZsAvwEQABAA/wEAAAgAAAAP8BAAAABqAgAAewwAAGwCAACmDAAA DwAE8EIAAAASAArwCAAAACm0BQACCgAAMwAL8BIAAACBAXlqnQC/ARAAEAD/AQAACAAAAA/wEAAA AGwCAAB7DAAAbgIAAKYMAAAPAATwQgAAABIACvAIAAAAKrQFAAIKAAAzAAvwEgAAAIEBemqeAL8B EAAQAP8BAAAIAAAAD/AQAAAAbgIAAHsMAABwAgAApgwAAA8ABPBCAAAAEgAK8AgAAAArtAUAAgoA ADMAC/ASAAAAgQF7a58AvwEQABAA/wEAAAgAAAAP8BAAAABwAgAAewwAAHICAACmDAAADwAE8EIA AAASAArwCAAAACy0BQACCgAAMwAL8BIAAACBAXxsoAC/ARAAEAD/AQAACAAAAA/wEAAAAHICAAB7 DAAAdAIAAKYMAAAPAATwQgAAABIACvAIAAAALbQFAAIKAAAzAAvwEgAAAIEBfGygAL8BEAAQAP8B AAAIAAAAD/AQAAAAdAIAAHsMAAB1AgAApgwAAA8ABPBCAAAAEgAK8AgAAAAutAUAAgoAADMAC/AS AAAAgQF7a54AvwEQABAA/wEAAAgAAAAP8BAAAAB1AgAAewwAAHcCAACmDAAADwAE8EIAAAASAArw CAAAAC+0BQACCgAAMwAL8BIAAACBAXpqngC/ARAAEAD/AQAACAAAAA/wEAAAAHcCAAB7DAAAeQIA AKYMAAAPAATwQgAAABIACvAIAAAAMLQFAAIKAAAzAAvwEgAAAIEBeWmcAL8BEAAQAP8BAAAIAAAA D/AQAAAAeQIAAHsMAAB7AgAApgwAAA8ABPBCAAAAEgAK8AgAAAAxtAUAAgoAADMAC/ASAAAAgQF4 aJsAvwEQABAA/wEAAAgAAAAP8BAAAAB7AgAAewwAAH0CAACmDAAADwAE8EIAAAASAArwCAAAADK0 BQACCgAAMwAL8BIAAACBAXZnmAC/ARAAEAD/AQAACAAAAA/wEAAAAH0CAAB7DAAAfwIAAKYMAAAP AATwQgAAABIACvAIAAAAM7QFAAIKAAAzAAvwEgAAAIEBdGWWAL8BEAAQAP8BAAAIAAAAD/AQAAAA fwIAAHsMAACBAgAApgwAAA8ABPBCAAAAEgAK8AgAAAA0tAUAAgoAADMAC/ASAAAAgQFyY5MAvwEQ ABAA/wEAAAgAAAAP8BAAAACBAgAAewwAAIICAACmDAAADwAE8EIAAAASAArwCAAAADW0BQACCgAA MwAL8BIAAACBAW9hkAC/ARAAEAD/AQAACAAAAA/wEAAAAIICAAB7DAAAhAIAAKYMAAAPAATwQgAA ABIACvAIAAAANrQFAAIKAAAzAAvwEgAAAIEBbF6MAL8BEAAQAP8BAAAIAAAAD/AQAAAAhAIAAHsM AACGAgAApgwAAA8ABPBCAAAAEgAK8AgAAAA3tAUAAgoAADMAC/ASAAAAgQFpXIgAvwEQABAA/wEA AAgAAAAP8BAAAACGAgAAewwAAIgCAACmDAAADwAE8EIAAAASAArwCAAAADi0BQACCgAAMwAL8BIA AACBAWZZhAC/ARAAEAD/AQAACAAAAA/wEAAAAIgCAAB7DAAAigIAAKYMAAAPAATwQgAAABIACvAI AAAAObQFAAIKAAAzAAvwEgAAAIEBY1aAAL8BEAAQAP8BAAAIAAAAD/AQAAAAigIAAHsMAACMAgAA pgwAAA8ABPBCAAAAEgAK8AgAAAA6tAUAAgoAADMAC/ASAAAAgQFgVH0AvwEQABAA/wEAAAgAAAAP 8BAAAACMAgAAewwAAI4CAACmDAAADwAE8EIAAAASAArwCAAAADu0BQACCgAAMwAL8BIAAACBAV5S egC/ARAAEAD/AQAACAAAAA/wEAAAAI4CAAB7DAAAkAIAAKYMAAAPAATwQgAAABIACvAIAAAAPLQF AAIKAAAzAAvwEgAAAIEBW1B3AL8BEAAQAP8BAAAIAAAAD/AQAAAAkAIAAHsMAACRAgAApgwAAA8A BPBCAAAAEgAK8AgAAAA9tAUAAgoAADMAC/ASAAAAgQFaTnUAvwEQABAA/wEAAAgAAAAP8BAAAACR AgAAewwAAJMCAACmDAAADwAE8EIAAAASAArwCAAAAD60BQACCgAAMwAL8BIAAACBAVhNcwC/ARAA EAD/AQAACAAAAA/wEAAAAJMCAAB7DAAAlQIAAKYMAAAPAATwQgAAABIACvAIAAAAP7QFAAIKAAAz AAvwEgAAAIEBV0xxAL8BEAAQAP8BAAAIAAAAD/AQAAAAlQIAAHsMAACXAgAApgwAAA8ABPBCAAAA EgAK8AgAAABAtAUAAgoAADMAC/ASAAAAgQFWS3AAvwEQABAA/wEAAAgAAAAP8BAAAACXAgAAewwA AJkCAACmDAAADwAE8EIAAAASAArwCAAAAEG0BQACCgAAMwAL8BIAAACBAVZLcAC/ARAAEAD/AQAA CAAAAA/wEAAAAJkCAAB7DAAAmgIAAKYMAAAPAATwQgAAABIACvAIAAAAQrQFAAIKAAAzAAvwEgAA AL8BAAAQAMsBaSsAAP8BCAAIAAAAD/AQAAAATAIAAHsMAACbAgAApwwAAA8AA/BCNQAADwAE8E4A AAABAAnwEAAAAAoCAADXCwAA3QIAAIYMAAACAArwCAAAAEO0BQADAgAAEwAL8AYAAACIAwAAAAAA AA/wEAAAAAoCAADXCwAA3QIAAIYMAAAPAAPweh4AAA8ABPBOAAAAAQAJ8BAAAAAKAgAA1wsAAN0C AACGDAAAAgAK8AgAAABEtAUAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAAKAgAA1wsAAN0CAACG DAAADwAD8NIdAAAPAATwTgAAAAEACfAQAAAACgIAANcLAADcAgAAhQwAAAIACvAIAAAARbQFAAMC AAATAAvwBgAAAIgDAAAAAAAAD/AQAAAACgIAANcLAADcAgAAhQwAAA8ABPBCAAAAEgAK8AgAAABG tAUAAgoAADMAC/ASAAAAgQGyjmsAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA1wsAANwCAADZCwAA DwAE8EIAAAASAArwCAAAAEe0BQACCgAAMwAL8BIAAACBAbKOawC/ARAAEAD/AQAACAAAAA/wEAAA AAoCAADZCwAA3AIAANoLAAAPAATwQgAAABIACvAIAAAASLQFAAIKAAAzAAvwEgAAAIEBs45rAL8B EAAQAP8BAAAIAAAAD/AQAAAACgIAANoLAADcAgAA3AsAAA8ABPBCAAAAEgAK8AgAAABJtAUAAgoA ADMAC/ASAAAAgQGzj2wAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA3AsAANwCAADeCwAADwAE8EIA AAASAArwCAAAAEq0BQACCgAAMwAL8BIAAACBAbSQbAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADe CwAA3AIAAN8LAAAPAATwQgAAABIACvAIAAAAS7QFAAIKAAAzAAvwEgAAAIEBtZBtAL8BEAAQAP8B AAAIAAAAD/AQAAAACgIAAN8LAADcAgAA4QsAAA8ABPBCAAAAEgAK8AgAAABMtAUAAgoAADMAC/AS AAAAgQG2kW0AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA4QsAANwCAADjCwAADwAE8EIAAAASAArw CAAAAE20BQACCgAAMwAL8BIAAACBAbeSbgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADjCwAA3AIA AOQLAAAPAATwQgAAABIACvAIAAAATrQFAAIKAAAzAAvwEgAAAIEBuJNuAL8BEAAQAP8BAAAIAAAA D/AQAAAACgIAAOQLAADcAgAA5gsAAA8ABPBCAAAAEgAK8AgAAABPtAUAAgoAADMAC/ASAAAAgQG5 lG8AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA5gsAANwCAADoCwAADwAE8EIAAAASAArwCAAAAFC0 BQACCgAAMwAL8BIAAACBAbuVcAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADoCwAA3AIAAOoLAAAP AATwQgAAABIACvAIAAAAUbQFAAIKAAAzAAvwEgAAAIEBvJZxAL8BEAAQAP8BAAAIAAAAD/AQAAAA CgIAAOoLAADcAgAA6wsAAA8ABPBCAAAAEgAK8AgAAABStAUAAgoAADMAC/ASAAAAgQG+l3IAvwEQ ABAA/wEAAAgAAAAP8BAAAAAKAgAA6wsAANwCAADtCwAADwAE8EIAAAASAArwCAAAAFO0BQACCgAA MwAL8BIAAACBAcCZcwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADtCwAA3AIAAO8LAAAPAATwQgAA ABIACvAIAAAAVLQFAAIKAAAzAAvwEgAAAIEBwZp0AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAO8L AADcAgAA8AsAAA8ABPBCAAAAEgAK8AgAAABVtAUAAgoAADMAC/ASAAAAgQHDnHUAvwEQABAA/wEA AAgAAAAP8BAAAAAKAgAA8AsAANwCAADyCwAADwAE8EIAAAASAArwCAAAAFa0BQACCgAAMwAL8BIA AACBAcWedgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADyCwAA3AIAAPQLAAAPAATwQgAAABIACvAI AAAAV7QFAAIKAAAzAAvwEgAAAIEByJ94AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAPQLAADcAgAA 9gsAAA8ABPBCAAAAEgAK8AgAAABYtAUAAgoAADMAC/ASAAAAgQHKoXkAvwEQABAA/wEAAAgAAAAP 8BAAAAAKAgAA9gsAANwCAAD3CwAADwAE8EIAAAASAArwCAAAAFm0BQACCgAAMwAL8BIAAACBAcyj egC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAD3CwAA3AIAAPkLAAAPAATwQgAAABIACvAIAAAAWrQF AAIKAAAzAAvwEgAAAIEBz6V8AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAPkLAADcAgAA+wsAAA8A BPBCAAAAEgAK8AgAAABbtAUAAgoAADMAC/ASAAAAgQHRp30AvwEQABAA/wEAAAgAAAAP8BAAAAAK AgAA+wsAANwCAAD8CwAADwAE8EIAAAASAArwCAAAAFy0BQACCgAAMwAL8BIAAACBAdSpfwC/ARAA EAD/AQAACAAAAA/wEAAAAAoCAAD8CwAA3AIAAP4LAAAPAATwQgAAABIACvAIAAAAXbQFAAIKAAAz AAvwEgAAAIEB1quAAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAP4LAADcAgAAAAwAAA8ABPBCAAAA EgAK8AgAAABetAUAAgoAADMAC/ASAAAAgQHZrYIAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAAAwA ANwCAAACDAAADwAE8EIAAAASAArwCAAAAF+0BQACCgAAMwAL8BIAAACBAdyvhAC/ARAAEAD/AQAA CAAAAA/wEAAAAAoCAAACDAAA3AIAAAMMAAAPAATwQgAAABIACvAIAAAAYLQFAAIKAAAzAAvwEgAA AIEB3rGFAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAAMMAADcAgAABQwAAA8ABPBCAAAAEgAK8AgA AABhtAUAAgoAADMAC/ASAAAAgQHhs4cAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAABQwAANwCAAAH DAAADwAE8EIAAAASAArwCAAAAGK0BQACCgAAMwAL8BIAAACBAeO1iAC/ARAAEAD/AQAACAAAAA/w EAAAAAoCAAAHDAAA3AIAAAgMAAAPAATwQgAAABIACvAIAAAAY7QFAAIKAAAzAAvwEgAAAIEB5beJ AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAAgMAADcAgAACgwAAA8ABPBCAAAAEgAK8AgAAABktAUA AgoAADMAC/ASAAAAgQHnuYsAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAACgwAANwCAAAMDAAADwAE 8EIAAAASAArwCAAAAGW0BQACCgAAMwAL8BIAAACBAeq7jAC/ARAAEAD/AQAACAAAAA/wEAAAAAoC AAAMDAAA3AIAAA0MAAAPAATwQgAAABIACvAIAAAAZrQFAAIKAAAzAAvwEgAAAIEB7LyNAL8BEAAQ AP8BAAAIAAAAD/AQAAAACgIAAA0MAADcAgAADwwAAA8ABPBCAAAAEgAK8AgAAABntAUAAgoAADMA C/ASAAAAgQHuvo4AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAADwwAANwCAAARDAAADwAE8EIAAAAS AArwCAAAAGi0BQACCgAAMwAL8BIAAACBAe+/jwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAARDAAA 3AIAABMMAAAPAATwQgAAABIACvAIAAAAabQFAAIKAAAzAAvwEgAAAIEB8cGQAL8BEAAQAP8BAAAI AAAAD/AQAAAACgIAABMMAADcAgAAFAwAAA8ABPBCAAAAEgAK8AgAAABqtAUAAgoAADMAC/ASAAAA gQHzwpEAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAFAwAANwCAAAWDAAADwAE8EIAAAASAArwCAAA AGu0BQACCgAAMwAL8BIAAACBAfTDkgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAWDAAA3AIAABgM AAAPAATwQgAAABIACvAIAAAAbLQFAAIKAAAzAAvwEgAAAIEB9cSTAL8BEAAQAP8BAAAIAAAAD/AQ AAAACgIAABgMAADcAgAAGQwAAA8ABPBCAAAAEgAK8AgAAABttAUAAgoAADMAC/ASAAAAgQH3xZQA vwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAGQwAANwCAAAbDAAADwAE8EIAAAASAArwCAAAAG60BQAC CgAAMwAL8BIAAACBAfjGlQC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAbDAAA3AIAAB0MAAAPAATw QgAAABIACvAIAAAAb7QFAAIKAAAzAAvwEgAAAIEB+ceVAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIA AB0MAADcAgAAHwwAAA8ABPBCAAAAEgAK8AgAAABwtAUAAgoAADMAC/ASAAAAgQH6yJYAvwEQABAA /wEAAAgAAAAP8BAAAAAKAgAAHwwAANwCAAAgDAAADwAE8EIAAAASAArwCAAAAHG0BQACCgAAMwAL 8BIAAACBAfvIlgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAgDAAA3AIAACIMAAAPAATwQgAAABIA CvAIAAAAcrQFAAIKAAAzAAvwEgAAAIEB+8mXAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAACIMAADc AgAAJAwAAA8ABPBCAAAAEgAK8AgAAABztAUAAgoAADMAC/ASAAAAgQH8ypcAvwEQABAA/wEAAAgA AAAP8BAAAAAKAgAAJAwAANwCAAAlDAAADwAE8EIAAAASAArwCAAAAHS0BQACCgAAMwAL8BIAAACB Af3KlwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAlDAAA3AIAACcMAAAPAATwQgAAABIACvAIAAAA dbQFAAIKAAAzAAvwEgAAAIEB/cqYAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAACcMAADcAgAAKQwA AA8ABPBCAAAAEgAK8AgAAAB2tAUAAgoAADMAC/ASAAAAgQH+y5gAvwEQABAA/wEAAAgAAAAP8BAA AAAKAgAAKQwAANwCAAAqDAAADwAE8EIAAAASAArwCAAAAHe0BQACCgAAMwAL8BIAAACBAf7LmAC/ ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAqDAAA3AIAACwMAAAPAATwQgAAABIACvAIAAAAeLQFAAIK AAAzAAvwEgAAAIEB/8yZAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAACwMAADcAgAALgwAAA8ABPBC AAAAEgAK8AgAAAB5tAUAAgoAADMAC/ASAAAAgQH/zJkAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA LgwAANwCAAAwDAAADwAE8EIAAAASAArwCAAAAHq0BQACCgAAMwAL8BIAAACBAf7LmAC/ARAAEAD/ AQAACAAAAA/wEAAAAAoCAAAwDAAA3AIAADEMAAAPAATwQgAAABIACvAIAAAAe7QFAAIKAAAzAAvw EgAAAIEB/suYAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAADEMAADcAgAAMwwAAA8ABPBCAAAAEgAK 8AgAAAB8tAUAAgoAADMAC/ASAAAAgQH9ypgAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAMwwAANwC AAA1DAAADwAE8EIAAAASAArwCAAAAH20BQACCgAAMwAL8BIAAACBAf3KlwC/ARAAEAD/AQAACAAA AA/wEAAAAAoCAAA1DAAA3AIAADYMAAAPAATwQgAAABIACvAIAAAAfrQFAAIKAAAzAAvwEgAAAIEB /MqXAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAADYMAADcAgAAOAwAAA8ABPBCAAAAEgAK8AgAAAB/ tAUAAgoAADMAC/ASAAAAgQH7yZcAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAOAwAANwCAAA6DAAA DwAE8EIAAAASAArwCAAAAIC0BQACCgAAMwAL8BIAAACBAfvIlgC/ARAAEAD/AQAACAAAAA/wEAAA AAoCAAA6DAAA3AIAADwMAAAPAATwQgAAABIACvAIAAAAgbQFAAIKAAAzAAvwEgAAAIEB+siWAL8B EAAQAP8BAAAIAAAAD/AQAAAACgIAADwMAADcAgAAPQwAAA8ABPBCAAAAEgAK8AgAAACCtAUAAgoA ADMAC/ASAAAAgQH5x5UAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAPQwAANwCAAA/DAAADwAE8EIA AAASAArwCAAAAIO0BQACCgAAMwAL8BIAAACBAfjGlQC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAA/ DAAA3AIAAEEMAAAPAATwQgAAABIACvAIAAAAhLQFAAIKAAAzAAvwEgAAAIEB98WUAL8BEAAQAP8B AAAIAAAAD/AQAAAACgIAAEEMAADcAgAAQgwAAA8ABPBCAAAAEgAK8AgAAACFtAUAAgoAADMAC/AS AAAAgQH1xJMAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAQgwAANwCAABEDAAADwAE8EIAAAASAArw CAAAAIa0BQACCgAAMwAL8BIAAACBAfTDkgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABEDAAA3AIA AEYMAAAPAATwQgAAABIACvAIAAAAh7QFAAIKAAAzAAvwEgAAAIEB88KRAL8BEAAQAP8BAAAIAAAA D/AQAAAACgIAAEYMAADcAgAARwwAAA8ABPBCAAAAEgAK8AgAAACItAUAAgoAADMAC/ASAAAAgQHx wZAAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAARwwAANwCAABJDAAADwAE8EIAAAASAArwCAAAAIm0 BQACCgAAMwAL8BIAAACBAe+/jwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABJDAAA3AIAAEsMAAAP AATwQgAAABIACvAIAAAAirQFAAIKAAAzAAvwEgAAAIEB7r6OAL8BEAAQAP8BAAAIAAAAD/AQAAAA CgIAAEsMAADcAgAATQwAAA8ABPBCAAAAEgAK8AgAAACLtAUAAgoAADMAC/ASAAAAgQHsvI0AvwEQ ABAA/wEAAAgAAAAP8BAAAAAKAgAATQwAANwCAABODAAADwAE8EIAAAASAArwCAAAAIy0BQACCgAA MwAL8BIAAACBAeq7jAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABODAAA3AIAAFAMAAAPAATwQgAA ABIACvAIAAAAjbQFAAIKAAAzAAvwEgAAAIEB57mLAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAFAM AADcAgAAUgwAAA8ABPBCAAAAEgAK8AgAAACOtAUAAgoAADMAC/ASAAAAgQHlt4kAvwEQABAA/wEA AAgAAAAP8BAAAAAKAgAAUgwAANwCAABTDAAADwAE8EIAAAASAArwCAAAAI+0BQACCgAAMwAL8BIA AACBAeO1iAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABTDAAA3AIAAFUMAAAPAATwQgAAABIACvAI AAAAkLQFAAIKAAAzAAvwEgAAAIEB4bOHAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAFUMAADcAgAA VwwAAA8ABPBCAAAAEgAK8AgAAACRtAUAAgoAADMAC/ASAAAAgQHesYUAvwEQABAA/wEAAAgAAAAP 8BAAAAAKAgAAVwwAANwCAABZDAAADwAE8EIAAAASAArwCAAAAJK0BQACCgAAMwAL8BIAAACBAduv gwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABZDAAA3AIAAFoMAAAPAATwQgAAABIACvAIAAAAk7QF AAIKAAAzAAvwEgAAAIEB2a2CAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAFoMAADcAgAAXAwAAA8A BPBCAAAAEgAK8AgAAACUtAUAAgoAADMAC/ASAAAAgQHWq4AAvwEQABAA/wEAAAgAAAAP8BAAAAAK AgAAXAwAANwCAABeDAAADwAE8EIAAAASAArwCAAAAJW0BQACCgAAMwAL8BIAAACBAdSpfwC/ARAA EAD/AQAACAAAAA/wEAAAAAoCAABeDAAA3AIAAF8MAAAPAATwQgAAABIACvAIAAAAlrQFAAIKAAAz AAvwEgAAAIEB0ad9AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAF8MAADcAgAAYQwAAA8ABPBCAAAA EgAK8AgAAACXtAUAAgoAADMAC/ASAAAAgQHPpXwAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAYQwA ANwCAABjDAAADwAE8EIAAAASAArwCAAAAJi0BQACCgAAMwAL8BIAAACBAcyjegC/ARAAEAD/AQAA CAAAAA/wEAAAAAoCAABjDAAA3AIAAGUMAAAPAATwQgAAABIACvAIAAAAmbQFAAIKAAAzAAvwEgAA AIEByqF5AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAGUMAADcAgAAZgwAAA8ABPBCAAAAEgAK8AgA AACatAUAAgoAADMAC/ASAAAAgQHIn3gAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAZgwAANwCAABo DAAADwAE8EIAAAASAArwCAAAAJu0BQACCgAAMwAL8BIAAACBAcWedgC/ARAAEAD/AQAACAAAAA/w EAAAAAoCAABoDAAA3AIAAGoMAAAPAATwQgAAABIACvAIAAAAnLQFAAIKAAAzAAvwEgAAAIEBw5x1 AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAGoMAADcAgAAawwAAA8ABPBCAAAAEgAK8AgAAACdtAUA AgoAADMAC/ASAAAAgQHBmnQAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAawwAANwCAABtDAAADwAE 8EIAAAASAArwCAAAAJ60BQACCgAAMwAL8BIAAACBAcCZcwC/ARAAEAD/AQAACAAAAA/wEAAAAAoC AABtDAAA3AIAAG8MAAAPAATwQgAAABIACvAIAAAAn7QFAAIKAAAzAAvwEgAAAIEBvpdyAL8BEAAQ AP8BAAAIAAAAD/AQAAAACgIAAG8MAADcAgAAcAwAAA8ABPBCAAAAEgAK8AgAAACgtAUAAgoAADMA C/ASAAAAgQG8lnEAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAcAwAANwCAAByDAAADwAE8EIAAAAS AArwCAAAAKG0BQACCgAAMwAL8BIAAACBAbuVcAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAByDAAA 3AIAAHQMAAAPAATwQgAAABIACvAIAAAAorQFAAIKAAAzAAvwEgAAAIEBuZRvAL8BEAAQAP8BAAAI AAAAD/AQAAAACgIAAHQMAADcAgAAdgwAAA8ABPBCAAAAEgAK8AgAAACjtAUAAgoAADMAC/ASAAAA gQG4k24AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAdgwAANwCAAB3DAAADwAE8EIAAAASAArwCAAA AKS0BQACCgAAMwAL8BIAAACBAbeSbgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAB3DAAA3AIAAHkM AAAPAATwQgAAABIACvAIAAAApbQFAAIKAAAzAAvwEgAAAIEBtpFtAL8BEAAQAP8BAAAIAAAAD/AQ AAAACgIAAHkMAADcAgAAewwAAA8ABPBCAAAAEgAK8AgAAACmtAUAAgoAADMAC/ASAAAAgQG1kG0A vwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAewwAANwCAAB8DAAADwAE8EIAAAASAArwCAAAAKe0BQAC CgAAMwAL8BIAAACBAbSQbAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAB8DAAA3AIAAH4MAAAPAATw QgAAABIACvAIAAAAqLQFAAIKAAAzAAvwEgAAAIEBs49sAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIA AH4MAADcAgAAgAwAAA8ABPBCAAAAEgAK8AgAAACptAUAAgoAADMAC/ASAAAAgQGzjmsAvwEQABAA /wEAAAgAAAAP8BAAAAAKAgAAgAwAANwCAACCDAAADwAE8EIAAAASAArwCAAAAKq0BQACCgAAMwAL 8BIAAACBAbKOawC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAACCDAAA3AIAAIMMAAAPAATwQgAAABIA CvAIAAAAq7QFAAIKAAAzAAvwEgAAAIEBso5rAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAIMMAADc AgAAhQwAAA8ABPBCAAAAEgAK8AgAAACstAUAAgoAADMAC/ASAAAAvwEAABAAywFpKwAA/wEIAAgA AAAP8BAAAAAKAgAA1wsAAN0CAACGDAAADwAD8GIWAAAPAATwTgAAAAEACfAQAAAAGwIAAOcLAADM AgAAZQwAAAIACvAIAAAArbQFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAGwIAAOcLAADMAgAA ZQwAAA8AA/C6FQAADwAE8E4AAAABAAnwEAAAABsCAADnCwAAywIAAGUMAAACAArwCAAAAK60BQAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAABsCAADnCwAAywIAAGUMAAAPAATwQgAAABIACvAIAAAA r7QFAAIKAAAzAAvwEgAAAIEBkZG1AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAOcLAADLAgAA6QsA AA8ABPBCAAAAEgAK8AgAAACwtAUAAgoAADMAC/ASAAAAgQGRkbUAvwEQABAA/wEAAAgAAAAP8BAA AAAbAgAA6QsAAMsCAADqCwAADwAE8EIAAAASAArwCAAAALG0BQACCgAAMwAL8BIAAACBAZGRtQC/ ARAAEAD/AQAACAAAAA/wEAAAABsCAADqCwAAywIAAOwLAAAPAATwQgAAABIACvAIAAAAsrQFAAIK AAAzAAvwEgAAAIEBkZG2AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAOwLAADLAgAA7gsAAA8ABPBC AAAAEgAK8AgAAACztAUAAgoAADMAC/ASAAAAgQGSkrYAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA 7gsAAMsCAADwCwAADwAE8EIAAAASAArwCAAAALS0BQACCgAAMwAL8BIAAACBAZKStwC/ARAAEAD/ AQAACAAAAA/wEAAAABsCAADwCwAAywIAAPELAAAPAATwQgAAABIACvAIAAAAtbQFAAIKAAAzAAvw EgAAAIEBkpK3AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAPELAADLAgAA8wsAAA8ABPBCAAAAEgAK 8AgAAAC2tAUAAgoAADMAC/ASAAAAgQGTk7gAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA8wsAAMsC AAD1CwAADwAE8EIAAAASAArwCAAAALe0BQACCgAAMwAL8BIAAACBAZOTuAC/ARAAEAD/AQAACAAA AA/wEAAAABsCAAD1CwAAywIAAPYLAAAPAATwQgAAABIACvAIAAAAuLQFAAIKAAAzAAvwEgAAAIEB lJS5AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAPYLAADLAgAA+AsAAA8ABPBCAAAAEgAK8AgAAAC5 tAUAAgoAADMAC/ASAAAAgQGUlLkAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA+AsAAMsCAAD6CwAA DwAE8EIAAAASAArwCAAAALq0BQACCgAAMwAL8BIAAACBAZWVugC/ARAAEAD/AQAACAAAAA/wEAAA ABsCAAD6CwAAywIAAPwLAAAPAATwQgAAABIACvAIAAAAu7QFAAIKAAAzAAvwEgAAAIEBlpa7AL8B EAAQAP8BAAAIAAAAD/AQAAAAGwIAAPwLAADLAgAA/QsAAA8ABPBCAAAAEgAK8AgAAAC8tAUAAgoA ADMAC/ASAAAAgQGWlrwAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA/QsAAMsCAAD/CwAADwAE8EIA AAASAArwCAAAAL20BQACCgAAMwAL8BIAAACBAZeXvQC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAD/ CwAAywIAAAEMAAAPAATwQgAAABIACvAIAAAAvrQFAAIKAAAzAAvwEgAAAIEBmJi9AL8BEAAQAP8B AAAIAAAAD/AQAAAAGwIAAAEMAADLAgAAAgwAAA8ABPBCAAAAEgAK8AgAAAC/tAUAAgoAADMAC/AS AAAAgQGZmb8AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAAgwAAMsCAAAEDAAADwAE8EIAAAASAArw CAAAAMC0BQACCgAAMwAL8BIAAACBAZmZwAC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAEDAAAywIA AAYMAAAPAATwQgAAABIACvAIAAAAwbQFAAIKAAAzAAvwEgAAAIEBmprBAL8BEAAQAP8BAAAIAAAA D/AQAAAAGwIAAAYMAADLAgAABwwAAA8ABPBCAAAAEgAK8AgAAADCtAUAAgoAADMAC/ASAAAAgQGb m8IAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAABwwAAMsCAAAJDAAADwAE8EIAAAASAArwCAAAAMO0 BQACCgAAMwAL8BIAAACBAZycwwC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAJDAAAywIAAAsMAAAP AATwQgAAABIACvAIAAAAxLQFAAIKAAAzAAvwEgAAAIEBnZ3EAL8BEAAQAP8BAAAIAAAAD/AQAAAA GwIAAAsMAADLAgAADQwAAA8ABPBCAAAAEgAK8AgAAADFtAUAAgoAADMAC/ASAAAAgQGensYAvwEQ ABAA/wEAAAgAAAAP8BAAAAAbAgAADQwAAMsCAAAODAAADwAE8EIAAAASAArwCAAAAMa0BQACCgAA MwAL8BIAAACBAZ+fxwC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAODAAAywIAABAMAAAPAATwQgAA ABIACvAIAAAAx7QFAAIKAAAzAAvwEgAAAIEBoaHJAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAABAM AADLAgAAEgwAAA8ABPBCAAAAEgAK8AgAAADItAUAAgoAADMAC/ASAAAAgQGiosoAvwEQABAA/wEA AAgAAAAP8BAAAAAbAgAAEgwAAMsCAAATDAAADwAE8EIAAAASAArwCAAAAMm0BQACCgAAMwAL8BIA AACBAaOjzAC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAATDAAAywIAABUMAAAPAATwQgAAABIACvAI AAAAyrQFAAIKAAAzAAvwEgAAAIEBpKTNAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAABUMAADLAgAA FwwAAA8ABPBCAAAAEgAK8AgAAADLtAUAAgoAADMAC/ASAAAAgQGmps8AvwEQABAA/wEAAAgAAAAP 8BAAAAAbAgAAFwwAAMsCAAAZDAAADwAE8EIAAAASAArwCAAAAMy0BQACCgAAMwAL8BIAAACBAaen 0AC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAZDAAAywIAABoMAAAPAATwQgAAABIACvAIAAAAzbQF AAIKAAAzAAvwEgAAAIEBqKjSAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAABoMAADLAgAAHAwAAA8A BPBCAAAAEgAK8AgAAADOtAUAAgoAADMAC/ASAAAAgQGpqdQAvwEQABAA/wEAAAgAAAAP8BAAAAAb AgAAHAwAAMsCAAAeDAAADwAE8EIAAAASAArwCAAAAM+0BQACCgAAMwAL8BIAAACBAaur1gC/ARAA EAD/AQAACAAAAA/wEAAAABsCAAAeDAAAywIAAB8MAAAPAATwQgAAABIACvAIAAAA0LQFAAIKAAAz AAvwEgAAAIEBrKzXAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAB8MAADLAgAAIQwAAA8ABPBCAAAA EgAK8AgAAADRtAUAAgoAADMAC/ASAAAAgQGurtkAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAIQwA AMsCAAAjDAAADwAE8EIAAAASAArwCAAAANK0BQACCgAAMwAL8BIAAACBAa+v2gC/ARAAEAD/AQAA CAAAAA/wEAAAABsCAAAjDAAAywIAACUMAAAPAATwQgAAABIACvAIAAAA07QFAAIKAAAzAAvwEgAA AIEBsLDcAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAACUMAADLAgAAJgwAAA8ABPBCAAAAEgAK8AgA AADUtAUAAgoAADMAC/ASAAAAgQGxsd4AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAJgwAAMsCAAAo DAAADwAE8EIAAAASAArwCAAAANW0BQACCgAAMwAL8BIAAACBAbOz4AC/ARAAEAD/AQAACAAAAA/w EAAAABsCAAAoDAAAywIAACoMAAAPAATwQgAAABIACvAIAAAA1rQFAAIKAAAzAAvwEgAAAIEBtLTh AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAACoMAADLAgAAKwwAAA8ABPBCAAAAEgAK8AgAAADXtAUA AgoAADMAC/ASAAAAgQG2tuMAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAKwwAAMsCAAAtDAAADwAE 8EIAAAASAArwCAAAANi0BQACCgAAMwAL8BIAAACBAbe35AC/ARAAEAD/AQAACAAAAA/wEAAAABsC AAAtDAAAywIAAC8MAAAPAATwQgAAABIACvAIAAAA2bQFAAIKAAAzAAvwEgAAAIEBuLjmAL8BEAAQ AP8BAAAIAAAAD/AQAAAAGwIAAC8MAADLAgAAMAwAAA8ABPBCAAAAEgAK8AgAAADatAUAAgoAADMA C/ASAAAAgQG5uecAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAMAwAAMsCAAAyDAAADwAE8EIAAAAS AArwCAAAANu0BQACCgAAMwAL8BIAAACBAbq66QC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAyDAAA ywIAADQMAAAPAATwQgAAABIACvAIAAAA3LQFAAIKAAAzAAvwEgAAAIEBu7vqAL8BEAAQAP8BAAAI AAAAD/AQAAAAGwIAADQMAADLAgAANgwAAA8ABPBCAAAAEgAK8AgAAADdtAUAAgoAADMAC/ASAAAA gQG8vOsAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAANgwAAMsCAAA3DAAADwAE8EIAAAASAArwCAAA AN60BQACCgAAMwAL8BIAAACBAb6+7QC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAA3DAAAywIAADkM AAAPAATwQgAAABIACvAIAAAA37QFAAIKAAAzAAvwEgAAAIEBvr7uAL8BEAAQAP8BAAAIAAAAD/AQ AAAAGwIAADkMAADLAgAAOwwAAA8ABPBCAAAAEgAK8AgAAADgtAUAAgoAADMAC/ASAAAAgQHAwO8A vwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAOwwAAMsCAAA8DAAADwAE8EIAAAASAArwCAAAAOG0BQAC CgAAMwAL8BIAAACBAcDA8QC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAA8DAAAywIAAD4MAAAPAATw QgAAABIACvAIAAAA4rQFAAIKAAAzAAvwEgAAAIEBwcHyAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIA AD4MAADLAgAAQAwAAA8ABPBCAAAAEgAK8AgAAADjtAUAAgoAADMAC/ASAAAAgQHCwvMAvwEQABAA /wEAAAgAAAAP8BAAAAAbAgAAQAwAAMsCAABCDAAADwAE8EIAAAASAArwCAAAAOS0BQACCgAAMwAL 8BIAAACBAcPD9AC/ARAAEAD/AQAACAAAAA/wEAAAABsCAABCDAAAywIAAEMMAAAPAATwQgAAABIA CvAIAAAA5bQFAAIKAAAzAAvwEgAAAIEBxMT1AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAEMMAADL AgAARQwAAA8ABPBCAAAAEgAK8AgAAADmtAUAAgoAADMAC/ASAAAAgQHFxfYAvwEQABAA/wEAAAgA AAAP8BAAAAAbAgAARQwAAMsCAABHDAAADwAE8EIAAAASAArwCAAAAOe0BQACCgAAMwAL8BIAAACB AcXF9wC/ARAAEAD/AQAACAAAAA/wEAAAABsCAABHDAAAywIAAEgMAAAPAATwQgAAABIACvAIAAAA 6LQFAAIKAAAzAAvwEgAAAIEBxsb3AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAEgMAADLAgAASgwA AA8ABPBCAAAAEgAK8AgAAADptAUAAgoAADMAC/ASAAAAgQHGxvgAvwEQABAA/wEAAAgAAAAP8BAA AAAbAgAASgwAAMsCAABMDAAADwAE8EIAAAASAArwCAAAAOq0BQACCgAAMwAL8BIAAACBAcfH+QC/ ARAAEAD/AQAACAAAAA/wEAAAABsCAABMDAAAywIAAE0MAAAPAATwQgAAABIACvAIAAAA67QFAAIK AAAzAAvwEgAAAIEBx8f5AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAE0MAADLAgAATwwAAA8ABPBC AAAAEgAK8AgAAADstAUAAgoAADMAC/ASAAAAgQHIyPoAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA TwwAAMsCAABRDAAADwAE8EIAAAASAArwCAAAAO20BQACCgAAMwAL8BIAAACBAcjI+wC/ARAAEAD/ AQAACAAAAA/wEAAAABsCAABRDAAAywIAAFMMAAAPAATwQgAAABIACvAIAAAA7rQFAAIKAAAzAAvw EgAAAIEBycn7AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAFMMAADLAgAAVAwAAA8ABPBCAAAAEgAK 8AgAAADvtAUAAgoAADMAC/ASAAAAgQHJyfwAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAVAwAAMsC AABWDAAADwAE8EIAAAASAArwCAAAAPC0BQACCgAAMwAL8BIAAACBAcrK/AC/ARAAEAD/AQAACAAA AA/wEAAAABsCAABWDAAAywIAAFgMAAAPAATwQgAAABIACvAIAAAA8bQFAAIKAAAzAAvwEgAAAIEB ysr9AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAFgMAADLAgAAWQwAAA8ABPBCAAAAEgAK8AgAAADy tAUAAgoAADMAC/ASAAAAgQHKyv0AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAWQwAAMsCAABbDAAA DwAE8EIAAAASAArwCAAAAPO0BQACCgAAMwAL8BIAAACBAcvL/QC/ARAAEAD/AQAACAAAAA/wEAAA ABsCAABbDAAAywIAAF0MAAAPAATwQgAAABIACvAIAAAA9LQFAAIKAAAzAAvwEgAAAIEBy8v+AL8B EAAQAP8BAAAIAAAAD/AQAAAAGwIAAF0MAADLAgAAXwwAAA8ABPBCAAAAEgAK8AgAAAD1tAUAAgoA ADMAC/ASAAAAgQHLy/4AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAXwwAAMsCAABgDAAADwAE8EIA AAASAArwCAAAAPa0BQACCgAAMwAL8BIAAACBAcvL/gC/ARAAEAD/AQAACAAAAA/wEAAAABsCAABg DAAAywIAAGIMAAAPAATwQgAAABIACvAIAAAA97QFAAIKAAAzAAvwEgAAAIEBy8v+AL8BEAAQAP8B AAAIAAAAD/AQAAAAGwIAAGIMAADLAgAAZAwAAA8ABPBCAAAAEgAK8AgAAAD4tAUAAgoAADMAC/AS AAAAgQHMzP8AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAZAwAAMsCAABlDAAADwAE8EIAAAASAArw CAAAAPm0BQACCgAAMwAL8BIAAAC/AQAAEADLAWkrAAD/AQgACAAAAA/wEAAAABsCAADnCwAAzAIA AGUMAAAPAAPwDBIAAA8ABPBOAAAAAQAJ8BAAAAA7AgAAmwwAAKsCAAC3DAAAAgAK8AgAAAD6tAUA AwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAA7AgAAmwwAAKsCAAC3DAAADwAD8GQRAAAPAATwTgAA AAEACfAQAAAAOwIAAJsMAACqAgAAtgwAAAIACvAIAAAA+7QFAAMCAAATAAvwBgAAAIgDAAAAAAAA D/AQAAAAOwIAAJsMAACqAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAD8tAUAAgoAADMAC/ASAAAAgQGy jmsAvwEQABAA/wEAAAgAAAAP8BAAAAA7AgAAmwwAAD0CAAC2DAAADwAE8EIAAAASAArwCAAAAP20 BQACCgAAMwAL8BIAAACBAbOPawC/ARAAEAD/AQAACAAAAA/wEAAAAD0CAACbDAAAPwIAALYMAAAP AATwQgAAABIACvAIAAAA/rQFAAIKAAAzAAvwEgAAAIEBtI9sAL8BEAAQAP8BAAAIAAAAD/AQAAAA PwIAAJsMAABBAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAD/tAUAAgoAADMAC/ASAAAAgQG1kW0AvwEQ ABAA/wEAAAgAAAAP8BAAAABBAgAAmwwAAEMCAAC2DAAADwAE8EIAAAASAArwCAAAAAC1BQACCgAA MwAL8BIAAACBAbeSbgC/ARAAEAD/AQAACAAAAA/wEAAAAEMCAACbDAAARQIAALYMAAAPAATwQgAA ABIACvAIAAAAAbUFAAIKAAAzAAvwEgAAAIEBuZRvAL8BEAAQAP8BAAAIAAAAD/AQAAAARQIAAJsM AABHAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAACtQUAAgoAADMAC/ASAAAAgQG8lnEAvwEQABAA/wEA AAgAAAAP8BAAAABHAgAAmwwAAEgCAAC2DAAADwAE8EIAAAASAArwCAAAAAO1BQACCgAAMwAL8BIA AACBAb+YcgC/ARAAEAD/AQAACAAAAA/wEAAAAEgCAACbDAAASgIAALYMAAAPAATwQgAAABIACvAI AAAABLUFAAIKAAAzAAvwEgAAAIEBwpt0AL8BEAAQAP8BAAAIAAAAD/AQAAAASgIAAJsMAABMAgAA tgwAAA8ABPBCAAAAEgAK8AgAAAAFtQUAAgoAADMAC/ASAAAAgQHFnnYAvwEQABAA/wEAAAgAAAAP 8BAAAABMAgAAmwwAAE4CAAC2DAAADwAE8EIAAAASAArwCAAAAAa1BQACCgAAMwAL8BIAAACBAcmh eQC/ARAAEAD/AQAACAAAAA/wEAAAAE4CAACbDAAAUAIAALYMAAAPAATwQgAAABIACvAIAAAAB7UF AAIKAAAzAAvwEgAAAIEBzaR7AL8BEAAQAP8BAAAIAAAAD/AQAAAAUAIAAJsMAABSAgAAtgwAAA8A BPBCAAAAEgAK8AgAAAAItQUAAgoAADMAC/ASAAAAgQHSp34AvwEQABAA/wEAAAgAAAAP8BAAAABS AgAAmwwAAFQCAAC2DAAADwAE8EIAAAASAArwCAAAAAm1BQACCgAAMwAL8BIAAACBAdargAC/ARAA EAD/AQAACAAAAA/wEAAAAFQCAACbDAAAVgIAALYMAAAPAATwQgAAABIACvAIAAAACrUFAAIKAAAz AAvwEgAAAIEB2q6DAL8BEAAQAP8BAAAIAAAAD/AQAAAAVgIAAJsMAABXAgAAtgwAAA8ABPBCAAAA EgAK8AgAAAALtQUAAgoAADMAC/ASAAAAgQHfsoUAvwEQABAA/wEAAAgAAAAP8BAAAABXAgAAmwwA AFkCAAC2DAAADwAE8EIAAAASAArwCAAAAAy1BQACCgAAMwAL8BIAAACBAeO1iAC/ARAAEAD/AQAA CAAAAA/wEAAAAFkCAACbDAAAWwIAALYMAAAPAATwQgAAABIACvAIAAAADbUFAAIKAAAzAAvwEgAA AIEB57iKAL8BEAAQAP8BAAAIAAAAD/AQAAAAWwIAAJsMAABdAgAAtgwAAA8ABPBCAAAAEgAK8AgA AAAOtQUAAgoAADMAC/ASAAAAgQHqu4wAvwEQABAA/wEAAAgAAAAP8BAAAABdAgAAmwwAAF8CAAC2 DAAADwAE8EIAAAASAArwCAAAAA+1BQACCgAAMwAL8BIAAACBAe6+jwC/ARAAEAD/AQAACAAAAA/w EAAAAF8CAACbDAAAYQIAALYMAAAPAATwQgAAABIACvAIAAAAELUFAAIKAAAzAAvwEgAAAIEB8cCQ AL8BEAAQAP8BAAAIAAAAD/AQAAAAYQIAAJsMAABjAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAARtQUA AgoAADMAC/ASAAAAgQH0w5IAvwEQABAA/wEAAAgAAAAP8BAAAABjAgAAmwwAAGUCAAC2DAAADwAE 8EIAAAASAArwCAAAABK1BQACCgAAMwAL8BIAAACBAfbFkwC/ARAAEAD/AQAACAAAAA/wEAAAAGUC AACbDAAAZgIAALYMAAAPAATwQgAAABIACvAIAAAAE7UFAAIKAAAzAAvwEgAAAIEB+MaVAL8BEAAQ AP8BAAAIAAAAD/AQAAAAZgIAAJsMAABoAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAUtQUAAgoAADMA C/ASAAAAgQH6yJYAvwEQABAA/wEAAAgAAAAP8BAAAABoAgAAmwwAAGoCAAC2DAAADwAE8EIAAAAS AArwCAAAABW1BQACCgAAMwAL8BIAAACBAfvJlwC/ARAAEAD/AQAACAAAAA/wEAAAAGoCAACbDAAA bAIAALYMAAAPAATwQgAAABIACvAIAAAAFrUFAAIKAAAzAAvwEgAAAIEB/MqXAL8BEAAQAP8BAAAI AAAAD/AQAAAAbAIAAJsMAABuAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAXtQUAAgoAADMAC/ASAAAA gQH9ypgAvwEQABAA/wEAAAgAAAAP8BAAAABuAgAAmwwAAHACAAC2DAAADwAE8EIAAAASAArwCAAA ABi1BQACCgAAMwAL8BIAAACBAf7LmAC/ARAAEAD/AQAACAAAAA/wEAAAAHACAACbDAAAcgIAALYM AAAPAATwQgAAABIACvAIAAAAGbUFAAIKAAAzAAvwEgAAAIEB/8yZAL8BEAAQAP8BAAAIAAAAD/AQ AAAAcgIAAJsMAAB0AgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAatQUAAgoAADMAC/ASAAAAgQH/zJkA vwEQABAA/wEAAAgAAAAP8BAAAAB0AgAAmwwAAHUCAAC2DAAADwAE8EIAAAASAArwCAAAABu1BQAC CgAAMwAL8BIAAACBAf3KmAC/ARAAEAD/AQAACAAAAA/wEAAAAHUCAACbDAAAdwIAALYMAAAPAATw QgAAABIACvAIAAAAHLUFAAIKAAAzAAvwEgAAAIEB/MqXAL8BEAAQAP8BAAAIAAAAD/AQAAAAdwIA AJsMAAB5AgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAdtQUAAgoAADMAC/ASAAAAgQH7yZcAvwEQABAA /wEAAAgAAAAP8BAAAAB5AgAAmwwAAHsCAAC2DAAADwAE8EIAAAASAArwCAAAAB61BQACCgAAMwAL 8BIAAACBAfrIlgC/ARAAEAD/AQAACAAAAA/wEAAAAHsCAACbDAAAfQIAALYMAAAPAATwQgAAABIA CvAIAAAAH7UFAAIKAAAzAAvwEgAAAIEB+MaVAL8BEAAQAP8BAAAIAAAAD/AQAAAAfQIAAJsMAAB/ AgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAgtQUAAgoAADMAC/ASAAAAgQH2xZMAvwEQABAA/wEAAAgA AAAP8BAAAAB/AgAAmwwAAIECAAC2DAAADwAE8EIAAAASAArwCAAAACG1BQACCgAAMwAL8BIAAACB AfTDkgC/ARAAEAD/AQAACAAAAA/wEAAAAIECAACbDAAAggIAALYMAAAPAATwQgAAABIACvAIAAAA IrUFAAIKAAAzAAvwEgAAAIEB8cCQAL8BEAAQAP8BAAAIAAAAD/AQAAAAggIAAJsMAACEAgAAtgwA AA8ABPBCAAAAEgAK8AgAAAAjtQUAAgoAADMAC/ASAAAAgQHuvo8AvwEQABAA/wEAAAgAAAAP8BAA AACEAgAAmwwAAIYCAAC2DAAADwAE8EIAAAASAArwCAAAACS1BQACCgAAMwAL8BIAAACBAeq7jAC/ ARAAEAD/AQAACAAAAA/wEAAAAIYCAACbDAAAiAIAALYMAAAPAATwQgAAABIACvAIAAAAJbUFAAIK AAAzAAvwEgAAAIEB57iKAL8BEAAQAP8BAAAIAAAAD/AQAAAAiAIAAJsMAACKAgAAtgwAAA8ABPBC AAAAEgAK8AgAAAAmtQUAAgoAADMAC/ASAAAAgQHjtYgAvwEQABAA/wEAAAgAAAAP8BAAAACKAgAA mwwAAIwCAAC2DAAADwAE8EIAAAASAArwCAAAACe1BQACCgAAMwAL8BIAAACBAd+yhQC/ARAAEAD/ AQAACAAAAA/wEAAAAIwCAACbDAAAjgIAALYMAAAPAATwQgAAABIACvAIAAAAKLUFAAIKAAAzAAvw EgAAAIEB2q6DAL8BEAAQAP8BAAAIAAAAD/AQAAAAjgIAAJsMAACQAgAAtgwAAA8ABPBCAAAAEgAK 8AgAAAAptQUAAgoAADMAC/ASAAAAgQHWq4AAvwEQABAA/wEAAAgAAAAP8BAAAACQAgAAmwwAAJEC AAC2DAAADwAE8EIAAAASAArwCAAAACq1BQACCgAAMwAL8BIAAACBAdKnfgC/ARAAEAD/AQAACAAA AA/wEAAAAJECAACbDAAAkwIAALYMAAAPAATwQgAAABIACvAIAAAAK7UFAAIKAAAzAAvwEgAAAIEB zaR7AL8BEAAQAP8BAAAIAAAAD/AQAAAAkwIAAJsMAACVAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAs tQUAAgoAADMAC/ASAAAAgQHJoXkAvwEQABAA/wEAAAgAAAAP8BAAAACVAgAAmwwAAJcCAAC2DAAA DwAE8EIAAAASAArwCAAAAC21BQACCgAAMwAL8BIAAACBAcWedgC/ARAAEAD/AQAACAAAAA/wEAAA AJcCAACbDAAAmQIAALYMAAAPAATwQgAAABIACvAIAAAALrUFAAIKAAAzAAvwEgAAAIEBwpt0AL8B EAAQAP8BAAAIAAAAD/AQAAAAmQIAAJsMAACbAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAvtQUAAgoA ADMAC/ASAAAAgQG/mHIAvwEQABAA/wEAAAgAAAAP8BAAAACbAgAAmwwAAJ0CAAC2DAAADwAE8EIA AAASAArwCAAAADC1BQACCgAAMwAL8BIAAACBAbyWcQC/ARAAEAD/AQAACAAAAA/wEAAAAJ0CAACb DAAAnwIAALYMAAAPAATwQgAAABIACvAIAAAAMbUFAAIKAAAzAAvwEgAAAIEBuZRvAL8BEAAQAP8B AAAIAAAAD/AQAAAAnwIAAJsMAACgAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAytQUAAgoAADMAC/AS AAAAgQG3km4AvwEQABAA/wEAAAgAAAAP8BAAAACgAgAAmwwAAKICAAC2DAAADwAE8EIAAAASAArw CAAAADO1BQACCgAAMwAL8BIAAACBAbWRbQC/ARAAEAD/AQAACAAAAA/wEAAAAKICAACbDAAApAIA ALYMAAAPAATwQgAAABIACvAIAAAANLUFAAIKAAAzAAvwEgAAAIEBtI9sAL8BEAAQAP8BAAAIAAAA D/AQAAAApAIAAJsMAACmAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAA1tQUAAgoAADMAC/ASAAAAgQGz j2sAvwEQABAA/wEAAAgAAAAP8BAAAACmAgAAmwwAAKgCAAC2DAAADwAE8EIAAAASAArwCAAAADa1 BQACCgAAMwAL8BIAAACBAbKOawC/ARAAEAD/AQAACAAAAA/wEAAAAKgCAACbDAAAqgIAALYMAAAP AATwQgAAABIACvAIAAAAN7UFAAIKAAAzAAvwEgAAAL8BAAAQAMsBaSsAAP8BCAAIAAAAD/AQAAAA OwIAAJsMAACrAgAAtwwAAA8AA/BMBgAADwAE8E4AAAABAAnwEAAAAAoCAACsDAAA3QIAAMgMAAAC AArwCAAAADi1BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAAoCAACsDAAA3QIAAMgMAAAPAAPw ngUAAA8ABPBOAAAAAQAJ8BAAAAAKAgAArAwAAN0CAADIDAAAAgAK8AgAAAA5tQUAAwIAABMAC/AG AAAAiAMAAAAAAAAP8BAAAAAKAgAArAwAAN0CAADIDAAADwAD8PYEAAAPAATwTgAAAAEACfAQAAAA CgIAAKwMAADcAgAAxwwAAAIACvAIAAAAOrUFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAACgIA AKwMAADcAgAAxwwAAA8ABPBCAAAAEgAK8AgAAAA7tQUAAgoAADMAC/ASAAAAgQGyjmsAvwEQABAA /wEAAAgAAAAP8BAAAAAKAgAArAwAANwCAACuDAAADwAE8EIAAAASAArwCAAAADy1BQACCgAAMwAL 8BIAAACBAbSQbAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAACuDAAA3AIAALAMAAAPAATwQgAAABIA CvAIAAAAPbUFAAIKAAAzAAvwEgAAAIEBuJNuAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAALAMAADc AgAAsQwAAA8ABPBCAAAAEgAK8AgAAAA+tQUAAgoAADMAC/ASAAAAgQG8lnEAvwEQABAA/wEAAAgA AAAP8BAAAAAKAgAAsQwAANwCAACzDAAADwAE8EIAAAASAArwCAAAAD+1BQACCgAAMwAL8BIAAACB AcKbdAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAACzDAAA3AIAALUMAAAPAATwQgAAABIACvAIAAAA QLUFAAIKAAAzAAvwEgAAAIEByaB5AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAALUMAADcAgAAtgwA AA8ABPBCAAAAEgAK8AgAAABBtQUAAgoAADMAC/ASAAAAgQHRp30AvwEQABAA/wEAAAgAAAAP8BAA AAAKAgAAtgwAANwCAAC4DAAADwAE8EIAAAASAArwCAAAAEK1BQACCgAAMwAL8BIAAACBAdmtggC/ ARAAEAD/AQAACAAAAA/wEAAAAAoCAAC4DAAA3AIAALoMAAAPAATwQgAAABIACvAIAAAAQ7UFAAIK AAAzAAvwEgAAAIEB4bSHAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAALoMAADcAgAAvAwAAA8ABPBC AAAAEgAK8AgAAABEtQUAAgoAADMAC/ASAAAAgQHpuosAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA vAwAANwCAAC9DAAADwAE8EIAAAASAArwCAAAAEW1BQACCgAAMwAL8BIAAACBAe+/jwC/ARAAEAD/ AQAACAAAAA/wEAAAAAoCAAC9DAAA3AIAAL8MAAAPAATwQgAAABIACvAIAAAARrUFAAIKAAAzAAvw EgAAAIEB9MOSAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAL8MAADcAgAAwQwAAA8ABPBCAAAAEgAK 8AgAAABHtQUAAgoAADMAC/ASAAAAgQH5x5UAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAwQwAANwC AADCDAAADwAE8EIAAAASAArwCAAAAEi1BQACCgAAMwAL8BIAAACBAfvJlwC/ARAAEAD/AQAACAAA AA/wEAAAAAoCAADCDAAA3AIAAMQMAAAPAATwQgAAABIACvAIAAAASbUFAAIKAAAzAAvwEgAAAIEB /cuYAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAMQMAADcAgAAxgwAAA8ABPBCAAAAEgAK8AgAAABK tQUAAgoAADMAC/ASAAAAgQH/zJkAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAxgwAANwCAADHDAAA DwAE8EIAAAASAArwCAAAAEu1BQACCgAAMwAL8BIAAAC/AQAAEADLAWkrAAD/AQgACAAAAA/wEAAA AAoCAACsDAAA3QIAAMgMAAAPAATwSAAAABIACvAIAAAATLUFAAIKAABDAAvwGAAAAIEBfGygAL8B EAAQAMsBaSsAAP8BCAAIAAAAD/AQAAAAnwIAALwMAADMAgAAyAwAAA8ABPDJAAAAogwK8AgAAABN tQUAAAoAAAMBC/BgAAAAgADQa+0EhQACAAAAhwAGAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4A wAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ 8AgAAABmBbgKoQyGBg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwMAAABCQVMAAKEPGgAAAAQAAAAA ABAACgAEAAcABAAAAAAAQQAEAAQADwAE8M4AAACiDArwCAAAAE61BQAACgAAAwEL8GAAAACAAOBu 7QSFAAIAAACHAAYAAAC/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AxAAPwCEAwAAAACGAwAAAAAAABDwCAAAAGYFrg9VE4YGDwAN8D4A AAAAAJ8PBAAAAAQAAAAAAKgPCAAAAEItUm91dGVyAAChDxoAAAAJAAAAAAAQAAoABAAHAAkAAAAA AEEABAAEAA8ABPDKAAAAogwK8AgAAABPtQUAAAoAAAMBC/BgAAAAgAB4c+0EhQACAAAAhwAGAAAA vwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAABmBdoV+BeGBg8ADfA6AAAAAACfDwQAAAAEAAAA AACoDwQAAABIb3N0AAChDxoAAAAFAAAAAAAQAAoABAAHAAUAAAAAAEEABAAEAA8AA/DjAgAADwAE 8IAAAAABAAnwEAAAAAwEAAD2CAAAuAoAAIAKAAACAArwCAAAAFC1BQABAgAAIwAL8AwAAAAEAAAA AACIAwAAAAAAABDwCAAAAPYIYgSdC4AKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBEAAAA AAAAAAAAAAIAAQABCgAAAAAKMA8ABPCuAAAAQgEK8AgAAABRtQUAAgoAAFMBC/B+AAAAgQCQXwEA ggDQtgAAgwCQXwEAhADQtgAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAE5K3UAywE8 2AQA0AEBAAAA0QEBAAAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEeAB4AAQICAAAIPwIAAAMA fwMAAA8AAAAP8BAAAAAMBAAAZgkAALgKAABmCQAADwAE8OQAAACiDArwCAAAAFK1BQACCgAAEwEL 8GYAAACAANB37QSBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIADwCBAQAA AAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwAEAwkAAAB/AwAADwAAAA/wEAAA ALwFAAD2CAAAAwkAAPAJAAAPAA3wRgAAAAAAnw8EAAAABAAAAAAAqA8IAAAAUkFESVVTdjYAAKEP IgAAAAkAAAAAAAAgCgAUAAcACQAAAIAERwAABAQABAAUAAAAAAAPAATwsQAAAKIMCvAIAAAAU7UF AAIKAACjAAvwPAAAAIAAyHvtBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAD/AQAAAATAYAAOYJAAD8BwAAgAoAAA8ADfA9AAAAAACfDwQAAAAE AAAAAACoDwcAAABSRkMzMTYyAAChDxoAAAAIAAAAAAAAAAoABwAIAAAAAABDAAQABAAKAA8AA/B6 AwAADwAE8IAAAAABAAnwEAAAALgKAADCCAAAKBAAAEYKAAACAArwCAAAAFS1BQABAgAAIwAL8AwA AAAEAAAAAACIAwAAAAAAABDwCAAAAMIInQuBEUYKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAA BwBEAAAAAAAAAAAAAAEAAQABCgAAAAAKMA8ABPCuAAAAQgEK8AgAAABVtQUAAgoAAFMBC/B+AAAA gQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAE5 K3UAywE82AQA0AEBAAAA0QEBAAAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEeAB4AAQICAAAI PwIAAAMAfwMAAA8AAAAP8BAAAAC4CgAALAkAACgQAAAsCQAADwAD8DQCAAAPAATwggAAAAEACfAQ AAAAogsAAMIIAACYDwAARgoAAAIACvAIAAAAVrUFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA ogsAAMIIAACYDwAARgoAAA8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAAB AAEAAAoDAAAACjAPAATw6QAAAKIMCvAIAAAAV7UFAAIKAAATAQvwZgAAAIAAwIDtBIEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgAPAIEBAAAACIMBAAAACL8BDAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAAQDCQAAAH8DAAAPAAAAD/AQAAAAogsAAMIIAACYDwAAvAkAAA8A DfBLAAAAAACfDwQAAAAEAAAAAACoDwsAAABQUFAoSVBWNkNQKQAAoQ8kAAAADAAAAAAAACgKAAEA FAAHAAwAAACABEcAAAQEAAQAFAAAAAAADwAE8LEAAACiDArwCAAAAFi1BQACCgAAowAL8DwAAACA AJSF7QSFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA AAgAAA/wEAAAAJgMAACsCQAASA4AAEYKAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8HAAAAUkZD MjQ3MgAAoQ8aAAAACAAAAAAAAAAKAAcACAAAAAAAQwAEAAQACgAPAAPwZwMAAA8ABPCAAAAAAQAJ 8BAAAADICQAAdgoAAEYQAADsDAAAAgAK8AgAAABZtQUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAA AAAQ8AgAAAB2CpkKoRHsDA8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAAD AAEAAQoCAAAACjAPAATwrgAAAEIBCvAIAAAAWrUFAAIKAABTAQvwfgAAAIEAkF8BAIIA0LYAAIMA kF8BAIQA0LYAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABOSt1AMsBPNgEANABAQAA ANEBAQAAANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BHgAeAAECAgAACD8CAAADAH8DAAAPAAAA D/AQAAAAuAoAAOYKAAAoEAAA5goAAA8ABPDiAAAAogwK8AgAAABbtQUAAgoAABMBC/BmAAAAgACc iO0EgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAA8AgQEAAAAIgwEAAAAI vwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMABAMJAAAAfwMAAA8AAAAP8BAAAAAcDAAAdgoA AMYOAABwCwAADwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAERIQ1B2NgAAoQ8iAAAABwAAAAAA ACAKABQABwAHAAAAgARHAAAEBAAEABQAAAAAAA8ABPA3AQAAogwK8AgAAABctQUAAgoAAKMAC/A8 AAAAgAA8jO0EhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAP8BAAAADICQAAkgsAAEYQAADsDAAADwAN8MMAAAAAAJ8PBAAAAAQAAAAAAKgPawAA AGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni0yNg1kcmFmdC10cm9hbi1kaGNwdjYtb3B0LXByZWZpeC1k ZWxlZ2F0aW9uLTAxDWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1vcHQtZG5zY29uZmlnLTAyAAChDzwA AABsAAAAAAAACAoAAQAHABgAAAAAAEMABQAEAAoALQAAAAAAQwAEAAQACgAnAAAAAARjAIAEBAAG AAQACgAPAAPw6QIAAA8ABPCAAAAAAQAJ8BAAAAAoEAAAxgsAAPEUAABGDQAAAgAK8AgAAABdtQUA AQIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAADGC4ERsBZGDQ8AEfAsAAAADwAUECQAAAAB APEPHAAAAAAAAAcARAAAAAAAAAAAAAAEAAEAAQoCAAAACjAPAATwrgAAAEIBCvAIAAAAXrUFAAIK AABTAQvwfgAAAIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABOSt1AMsBPNgEANABAQAAANEBAQAAANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8B HgAeAAECAgAACD8CAAADAH8DAAAPAAAAD/AQAAAAKBAAADYMAADsFAAANgwAAA8ABPDqAAAAogwK 8AgAAABftQUAAgoAABMBC/BmAAAAgABkk+0EgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAA hwAGAAAAvwACAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMABAMJ AAAAfwMAAA8AAAAP8BAAAAA8EAAAxgsAAPEUAADADAAADwAN8EwAAAAAAJ8PBAAAAAQAAAAAAKgP DgAAAFN0YXRlbGVzcyBBRERSAAChDyIAAAAPAAAAAAAAIAoAFAAHAA8AAACABEcAAAQEAAQAFAAA AAAADwAE8LEAAACiDArwCAAAAGC1BQACCgAAowAL8DwAAACAABCY7QSFAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAALwRAACsDAAAbBMA AEYNAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8HAAAAUkZDMjQ2MgAAoQ8aAAAACAAAAAAAAAAK AAcACAAAAAAAQwAEAAQACgAPAAPwEAMAAA8ABPCAAAAAAQAJ8BAAAAAoEAAARg0AAEwVAAAADwAA AgAK8AgAAABhtQUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAABGDYEREhcADw8AEfAs AAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAAFAAEAAQoCAAAACjAPAATwrgAAAEIB CvAIAAAAYrUFAAIKAABTAQvwfgAAAIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIcAAQAAAL8AAAAP AEQBBAAAAH8BAAABAL8BAAAQAMABOSt1AMsBPNgEANABAQAAANEBAQAAANIBAAAAANMBAAAAANQB AAAAANUBAAAAAP8BHgAeAAECAgAACD8CAAADAH8DAAAPAAAAD/AQAAAAKBAAALYNAADsFAAAtg0A AA8ABPDlAAAAogwK8AgAAABjtQUAAgoAABMBC/BmAAAAgAA4m+0EgQCQXwEAggDQtgAAgwCQXwEA hADQtgAAhQACAAAAhwAGAAAAvwACAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMABAMJAAAAfwMAAA8AAAAP8BAAAACcEAAARg0AAHEUAABADgAADwAN8EcAAAAAAJ8P BAAAAAQAAAAAAKgPCQAAAFdLU0xVIEROUwAAoQ8iAAAACgAAAAAAACAKABQABwAKAAAAgARHAAAE BAAEABQAAAAAAA8ABPDdAAAAogwK8AgAAABktQUAAgoAAKMAC/A8AAAAgACsn+0EhQACAAAAhwAG AAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABnEAAA Zg4AAEwVAAAADwAADwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPIQAAAGRyYWZ0LWlldGYtaXB2Ni1k bnMtZGlzY292ZXJ5LTA1IAAAoQ8sAAAAIgAAAAAAAAAKAAcAIAAAAAAAYwAEAAYABAAKAAIAAAAA BEMAgAQEAAQACgAPAATw7QAAACIACvAIAAAAZbUFAAAKAAADAQvwYAAAAIAAdKTtBIUAAgAAAIcA BgAAAL8AAgAPAIEB//9mAL8BHAAeAMABAQAACNYBAQAAAP8BDgAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DEAA/AIQDAAAAAIYDAAAAAAAAEPAIAAAA8whEAPMDMwoPAA3wXQAAAAAAnw8EAAAA BAAAAAAAqA8jAAAAQXV0aGVudGljYXRpb24gLw1MaW5rIEVzdGFibGlzaG1lbnQAAKEPHgAAACQA AAAAABAICgAEAAEABwAkAAAAAABDAAQABAAMAA8ABPAQAQAAIgAK8AgAAABmtQUAAAoAAAMBC/Bg AAAAgADQpe0EhQACAAAAhwAGAAAAvwACAA8AgQH//2YAvwEcAB4AwAEBAAAI1gEBAAAA/wEOAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAAC+ClEAWgT+ Cw8ADfCAAAAAAACfDwQAAAAEAAAAAACgD0YAAABSAG8AdQB0AGUAcgAgAEMAbwBuAGYAaQBnAHUA cgBhAHQAaQBvAG4ADQAI/1AAcgBlAGYAaQB4ACAALwAgAEQATgBTAAn/AAChDx4AAAAkAAAAAAAQ CAoABAABAAcAJAAAAAAAQwAEAAQADAAPAATwAgEAACIACvAIAAAAZ7UFAAAKAADjAAvwVAAAAIAA gKjtBL8AAgAPAIEB//9mAL8BHAAeAMABAQAACNYBAQAAAP8BDgAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DEAA/AIQDAAAAAIYDAAAAAAAAEPAIAAAAkgxNADcE0g0PAA3wfgAAAAAAnw8EAAAA BAAAAAAAoA9EAAAASABvAHMAdAAgAEMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4ADQAI/0EAZABk AHIAZQBzAHMAIAAvACAARABOAFMACf8AAKEPHgAAACMAAAAAABAICgAEAAEABwAjAAAAAABDAAQA BAAMAA8ABPCOAAAAEgAK8AgAAABotQUAAAoAABMBC/BmAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQ tgAAhQACAAAAhwABAAAAvwAAAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAIzgECAAAA1wEAAAAA /wEOAA4AAQICAAAIPwIAAAMAfwMAAA8AAAAQ8AgAAABwBaQP+BdACA8ABPDnAAAAogwK8AgAAABp tQUAAAoAAAMBC/BgAAAAgAD8su0EhQACAAAAhwAGAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4A wAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ 8AgAAAB9Bm4NGA89Bw8ADfBXAAAAAACfDwQAAAAEAAAAAACoDwUAAABQUFBvRQAAoQ8cAAAABgAA AAAAEAAKAAQABwAGAAAAAABDAAQABAAOAAAAqg8SAAAABQAAAAEAAAADAAEAAAAAAAAADwAE8EgA AAASAArwCAAAAAG0BQAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAR5AlwCUAd69aAC/ARIAEgD/ AQAACAAEAwkAAAA/AwEAAQAvAAXwQAAAAAEAEvAYAAAAAQAAABO0BQAUtAUAD7QFAAMAAAABAAAA AQAS8BgAAAACAAAAFLQFAPm0BQAQtAUAAwAAAAEAAAAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIADwCIE/kPAAAPAIoT8Q8AAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixPRDwAAAAAAKwQAAADNM3f0HwBE8bUPAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAALkT AP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAAHwBE8XAPAAAAACfxIAAAAAAAAAAAAAAAAQAA AAAAAAAAAAAAAAAAAP////8YAAAADwA98Q0AAABAAULxBQAAAAEEAAAAAABB8RQAAAABAAAAAQAA AAAAAAAAAAAAAwAAAD8AJfEsAAAAAAAo8RAAAAABAAAACQAAAAAAAAAAAAAADwA88QwAAAAAAAEr BAAAAAEAAABPACXxLAAAAAAAKPEQAAAAAQAAAAoAAAAAAAAAAAAAAA8APPEMAAAAAAABKwQAAAAB AAAAHwBE8ekCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAALcTAAAAAAABAAAADwA98QAA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPGRAgAAAAAn8SAAAAAAAAAAAAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETxOQIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEWAAAAoABC8QUAAAABAgAAALAAQvEFAAAAAQEA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAA AAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAA EABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAA HwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwA AAAAAPsqFAAAAAAAAAABAAAAVLUFAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETxrQAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA9AEAABgAAAAPAD3x AAAAAA8ALfF1AAAAAAA28QgAAAADAAAAAAAAABAAQvEZAAAAA3cAaQBwAGUAKAByAGkAZwBoAHQA KQAAAA8AKvE8AAAAAAAz8RAAAAAAAAAAAAAAAAAAAAAAAAAADwA88RwAAAAAAPsqFAAAAAAAAAAB AAAAVLUFAP//////////HwBE8ekCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAALcTAAAA AAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPGRAgAAAAAn 8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjx EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxOQIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEWAAAAoABC8QUAAAABAgAA ALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn 8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrx CAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAA AAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkA dAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAULUFAP//////////HwAl8RgAAAAAACjxEAAA AAAAAAAAAAAAAAAAAAAAAAAfAETxrQAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA 9AEAABgAAAAPAD3xAAAAAA8ALfF1AAAAAAA28QgAAAADAAAAAAAAABAAQvEZAAAAA3cAaQBwAGUA KAByAGkAZwBoAHQAKQAAAA8AKvE8AAAAAAAz8RAAAAAAAAAAAAAAAAAAAAAAAAAADwA88RwAAAAA APsqFAAAAAAAAAABAAAAULUFAP//////////HwBE8ecCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMA AAAAAAAAALcTAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA//// /x8ARPGPAgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxNwIAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEWAAAA oABC8QUAAAABCAAAALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAA AB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAA DwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAA AAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkA cwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAWbUFAP//////////HwAl 8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxqwAAAAAAJ/EgAAAAAAAAAAAAAAADAAAA AAAAAAAAAAAAAAAA9AEAABgAAAAPAD3xAAAAAA8ALfFzAAAAAAA28QgAAAADAAAAAAAAABAAQvEX AAAAA3cAaQBwAGUAKABsAGUAZgB0ACkAAAAPACrxPAAAAAAAM/EQAAAAAAAAAAAAAAAAAAAAAAAA AA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAFm1BQD//////////x8ARPHnAgAAAAAn8SAAAAAAAAAA AAAAAAAAAAADAAAAAAAAAAC3EwAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA AAAAAAAAAP////8fAETxjwIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEA AAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8TcCAAAAACfxIAAA AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC 8QUAAAABFgAAAKAAQvEFAAAAAQgAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA AAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkA AAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUA AAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkA bABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAF21BQD/ /////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8asAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAPQBAAAYAAAADwA98QAAAAAPAC3xcwAAAAAANvEIAAAAAwAA AAAAAAAQAELxFwAAAAN3AGkAcABlACgAbABlAGYAdAApAAAADwAq8TwAAAAAADPxEAAAAAAAAAAA AAAAAAAAAAAAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAABdtQUA//////////8fAETx5wIAAAAA J/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAtxMAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo 8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8Y8CAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAA AAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPE3 AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUA AAABAQAAAJAAQvEFAAAAARYAAACgAELxBQAAAAEIAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo 8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAA AAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkA cwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEj AAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAA AAEAAABhtQUA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGrAAAA AAAn8SAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAD0AQAAGAAAAA8APfEAAAAADwAt8XMAAAAA ADbxCAAAAAMAAAAAAAAAEABC8RcAAAADdwBpAHAAZQAoAGwAZQBmAHQAKQAAAA8AKvE8AAAAAAAz 8RAAAAAAAAAAAAAAAAAAAAAAAAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAYbUFAP////////// DwACKwAAAAAPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABMADwAMBJQBAAAP AALwjAEAADAMCPAIAAAAAwAAAAPABQAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAAwAUABQAAAA8ABPByAAAAEgAK8AgAAAACwAUAIAIAAFMAC/AeAAAAfwAA AAQAgACIpvsDvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAABgANQBjBYwAw8AEfAQAAAAAADDCwgA AAAAAAAADQD7Aw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAPABQAgAgAAUwAL 8B4AAAB/AAAABACAALSs+wO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPAD1AGMFhAODwAR8BAA AAAAAMMLCAAAAAEAAAAOAPsDDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAcAF AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBHkCXAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMw AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAERfwgEw4x89DwDuAyQC AAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwATAA8ADASUAQAADwAC8IwBAABQDAjwCAAA AAMAAAADyAUADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA AMgFAAUAAAAPAATwcgAAABIACvAIAAAAAsgFACACAABTAAvwHgAAAH8AAAAEAIAAKL/tBL8BAAAB AP8BAAABAAEDAgQAAAAAEPAIAAAAYADUAYwWMAMPABHwEAAAAAAAwwsIAAAAAAAAAA0A7QQPAA3w DAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADyAUAIAIAAFMAC/AeAAAAfwAAAAQAgAAc se0EvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwA9QBjBYQDg8AEfAQAAAAAADDCwgAAAABAAAA DgDtBA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHIBQAADAAAgwAL8DAAAACB AQAAAAiDAQUAAAiTAR5AlwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP// /wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAABFX8IBsJ+v7BAAERCXBwAAAFwDAHic7dYHeJSF AYfx7xJQCIgyxIgLN25woLgBwQnBjVvUKCCIQMC9F6jg3gskbts6utu0ttVuR/du7bR72l2TvjfQ 1PE84e8offr+8ryQS+7y5e7++e6ee7bv84sfHfTD4lV2LeqL9o6exQqdvtaNSksvrFIUdbXL7R0d HZ2v8y36NnVoufcSfbP2HLbXLpef8xWpB/WkBupFvWkl6kMrVydQ9KV+1J8G0Ko0kFajRlqdBtEa tCatRWvTOjSY1qX1aH3agDakjWhjGkKb0Ka0GW1OW9CWtBUNpWG0NW1D29J2NJy2px1oBO1IO9HO tEtl20WxG+1OI2kUjaY9aAyNpT1pL9qb9qF9aT8aR+OpiSbQ/nQAHUgH0cF0CB1KE+kwOpyOoCPp KDqajqFjaRIdR8fTCdRMJ9JJNJmm0FQ6mabRdDqFZtCpNJNm0WxqoTk0l06j0+kMOpPOorPpHDqX zqPzK7/7DD5aeC7G8HNb+FnlW3TdwKL7y3/n5fNBA+eNsieq3x7b+bqLnpreOm/BE6X6V77P+aOJ +9W8TMfsrKGoK3Xec1dvN+Dl44/m/k/nsWzieZi6zMfvx/HL58Dyferq8cvXH1f7vK52/yfwyDfz LA6tfHRdY+3+d1uG43enHq3VM3l77Xlrf4fON1q+lKov47ESy6lvqG7v1X/75deQCaNmzZk9uXj9 T18c8djMN3NwvWkX0IV0EV1Ml9CldBnNo/l0OV1BV9ICWkhX0dV0DV1L19H1dAPdSDfRzXQL3Uq3 0e10B91Jd9EiWkx30xJqpXvoXrqP7qcH6EF6iB6md9G76T30CD1Kj9Hj9F56H72fPkAfpA/Rh+kj 9FFqo4/Rx4vqTj9Bn6RP0ZP0FH2aPkOfpc/R5+kL9EV6mp6hZ+k5+hJ9mb5CX6Wv0dfpG8V/vqcq 912+9j36Pv2AnqfyG+8f0Y/pJ/RT+hm9QD+nX9Av6Vf0a/oN/ZZ+R7+nP9Af6U/0Iv2Z/kJ/pb/R 3+kf9E/6F71U/r2o8kJRqv7dlv9ql763L19eekKY37/aM0tKfI93gvUvlO9u8XTl3/It6ks9Kq8m vetGd7RVPutVt/QaI3sN5hFrqzzivL/qqP4/pPYctFWO11i8kf/W+VCSJEmSJEmSJEmSJEmSJEmS JEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmS JEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmS JEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJC3/6gvpFaWiqZhWNBfDiqHF+GJS0VJMKeZyuasGFXVF 53115TbfodYlpfRXfo1lPf5b7X/5+CWehjqqp27UnVagFakH9aQG6kW9aSXqQyvTKtSX+lF/GkCr 0kBajRppdRpEa9CatBatTevQYFqX1qP1aQPakDaijWkIbUKb0ma0OW1BW9JWNJSG0da0DW1L29Fw 2p52oBG0I+1EO9MutCvtRrvTSBpFo2kPGkNjaU/ai/amfWhf2o/G0Xhqogm0Px1AB9JBdDAdQofS RDqMDqcj6Eg6io6mY+hYmkTH0fF0AjXTiXQSTaYpNJVOpmk0nU6hGXQqzaRZNJtaaA7NpdPodDqD zqSz6Gw6h86l8+h8uoAupIvoYrqELqXLaB7Np8vpCrqSFtBCuoqupmvoWrqOrqcb6Ea6iW6mW+hW uo1upzvoTrqLFtFiupvKp4NWuofupfvofnqAHqSH6GFqf/teGv8vLeKBHzVuYe1sPJyGUFutUtFY +fpEvv9kn6LS6511pC5yN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o 4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyN Eu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLd KOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXc jRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC 3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl 3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtR wt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3Srgb JdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7 UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kaJ4p31bwpRRpwQABEQ+h4A AAAiBAB4nO2cBZzlZfXGf3cWJAURbMW1sRDFwkQRmxILWxEVRVdhsbs7EETFTuzuQsUO7O5uUVHM 3f9zZ3aXYf9zf+/pc2b2ffg8O7sz9/c+33POe+6MCHzltF1+8sp3XPCnw2a63rBqWLd+u+Eciz63 NTzZ+IdzDcPchj+vW79+/cZPb7XhddvhC9vD67tK63/wtpOFGa7b8Oept8EMt53OEd4e3gHeET4n vBO888IVGHaBzw3vCu8Gnwc+L3w++PzwBeALwheCLwxfBN4dvii8Gr4YfHH4EvAl4UvBl4YvA+8B Xxa+HHx5+ArwFeE94SvBe8FXhq8C7w1fFb4afHX4GvA14X3ga8HXhq8DX3f+bg/D9eF94RvAN4T3 g28E7w/fGL4JfFP4ZvDN4VvAt4QPgA+ED4IPhg+BbwUfCt8avg18W/h28O3hw+A7wHeE7wTfGb4L fFf4bvDd4XvAh8P3hI+A7wXfG74PfCR8X/h+8FHw/eEHwGvgB8IPgo+Gj4HXwsfCD4YfAj8Ufhj8 cPgR8CPhR8GPhh8DP3aefQ3+WotZ7I9z1+Ks6RN0nRfbvvEuTd8P9t3n+F1+dPXTdjnhesMpJ+97 2d8ufu0p11397dPPPGWyavqHDW8kE3TyqPmqZdp+mJssvs/U53YbNubvh/rvj14ehDncl51/buRP S5m+71Hzp68/dsPv90Pugbg5+8//eqgkf+DWP31PP2lubv736zbMbeP+d21Zmix8GxdrgpuzavuF u7/57k/f0w848vCj1xyz5l5rVx98nzVr16ze/55Hrl1z9Oq999xr9cFHHr722KOPmP92csCh819e +Or8N5pNn9lz7+GMfd75oBn501wN/5aux8GPh58APxF+Evxk+CnwU+GnwU+HnwE/E34W/Gz4OfBz 4efBx8HPh4+HT4BfAJ8IvxB+Efxi+CT4JfBL4ZfBL4dfAb8SfhX8avg18Gvh18Gvh0+G3wC/EX4T /Gb4LfBb4bfBb4ffAb8Tfhf8bvg98Hvh98Hvhz8AfxD+EPxh+CPwR+GPwafAH4c/AX8SPhX+FPxp +DPwZ+HPwZ+HvwB/Ef4S/GX4NPgr8Ffhr8Ffh78BfxP+Fvxt+Dvwd+Hvwd+HfwD/EP4R/GP4J/D0 B++fwT+HfwH/Ev4V/Gv4N/D0G+jv4N/Df4D/CP8J/jN8OvwX+K/w3+Az4L/D/4DPhP8J/wv+N/wf +L/w/+B18PzSYPmn37zm4FXwVvDW8DngbZb4mXBHfO6c8E7wzvC54F3gc8O7wrvB54HPC58PPj98 AfiC8IXgC8MXgXeHLwqvhi8GXxy+BHxJ+FLwpeHLwHvAl4UvB18evgJ8RXhP+ErwXvCV4avAe8NX ha8GXx2+BnxNeB/4WvC14evA14WvB18f3he+AXxDeD/4RvD+8I3hm8A3hW8G3xy+BXxL+AD4QPgg +GD4EPhW8KHwreHbwLeFbwffHj4MvgN8R/hO8J3hu8B3he8G3x2+B3w4fE/4CPhe8L3h+8BHwveF 7wcfBd8ffgC8Bn4g/CD4aPgYeC18LPxg+CHwQ+GHwQ+HHwE/En4U/Gj4MfBjp7MfDl813VXc/p0W fiKFdj3kuP622rVlqvXj0EmHnbTzXFfXitRkRNlsXV3LW2Pb1Retq0sj4nb1NevqEoi7X33Lurro ku1XwJb5JYbVoultZKu5rO4wlrDJzALUMHK/vLBC9O0N6LOG1Z3KDnbZgKrZFz236eGlT3HrVNwE bBrsx2fC6k5mA7tMMA3wFz206cmlj3DrVNwEclocz+oOZwAbzmg5fVYBix7Z+OCsA7xa5XQsNcm3 v0ms/nxa2GBC6wXjlTBZ9M0rYcUCB5DR3SxWf0IdbCifx4JxapgsXrFJXzHT5iay+jNqYAPpnBaM UcXk7Cs2+1mfXrkcyojybG0yqz+lHDaMzXPDqHVMUlfM40xWll9j81n9McWwUWi+C0YsZHLWim34 IXHGgy698jiTleXW1wqs/pxS2CAy9w0jlTKhrpjLjjkcycvyaWoV1gBSGWxZMI9aJpkrZn8iN8yl p3VYA1DrrphVE7XFTBat2KJfyMT2TVCdyA3zaOkWxlp1xcx6qK1mQl4xhx0zP5Ad5tDRUqxFYWtS yeULbX2gFS0tLbOfEaxF/95MSSiNXKmtDzSCJaYltjOENQJ3hTDp5MptfJ4RKzEtr5khrCG8BZks +xdakvHZjqTUOL80neisYcPnweYiCYj0ciS3Pc4ElBznl6YTjzVk+PL4cCIBkIUc2U1PM+Ekx/ml 6cRm9Z+9MDuBSMBjIz94y8MsKBl5jnEqSVidZy8KzgAS4FjJjd7yMANITp5jnEoiVtfRi3IzgAQ0 ZvLjNzzLApKR5xinkozVd/aC2AQeAYyh3AqwO8oAkRXomaeRlNVx9PzQEVViMZVXBXZH6Ql5gZ55 GolZ/UbPzxxRJRZbeZVgdpIekBfomaeRmNVv8vzMERVCsZZTDVYHqfG4ia6BCslZvQbPjxxTHRJz ORVhdZAaj5voGqiQgtVr8uzEMZUBcZBPGYnn6BJdAxVSsHoNnp04pjIgHvIpw+YYLRs/0jdRLg2r z9zZgaOqwuEinzpsjtGy8SN9E+XSsPrMnR04qiocPnIpxOQULVm9SLFUrC5j5+aNqwiGk3wqsThE SybIdI4US8XqM3du3qhqULjJpRSLQ5RgkkznSLFUrC5jZ+eNqgaFm1xqMThDy1UxUyodq8vYmXHj KgHhKJdi9EcosUSh3plS6ViD20u5c+4wAghHuRSjP0KJJQr1zpRKxxrcXsqd84YRMLjKoxz1CUqo oqFC6Vg9hs6NG1cFBle5lKM9QAklS3UPFUrHGtxfypXzhhEw+MqjHO0BOiZhqnuoUDrW4P5Sbpwz jADBWR4FKZ9XIpVNlUnH6jFzbty4CiDMpLI5K/fbmAORNNY/VSYda3CDKRfOF0ZA0ACyP9GiIt3j OiJprH+qTDrW4AZTLpwvjICgSaM8M/cnRQegwrEi6Vg9Rs6NG1c+AYFFdWrqtzEHHnFuQKxIKlaP ifPzRpUOQENxO1hak+ZhHY84NyBWJBWrx8T5eaNKByCCKE7O/EnRAad0rkQqVo+Bs/PGlQ5A5pCf nfdtzIGGpqxciVSs0R2mXDdPGkE+A8P3dG6u/FEdDU1ZuRJpWD3mLQgcVXY+h8L5eF6u+EklDE1p wQJpWF3mzQ8cVXa+QUPdixQf6gFDU1qwQBpWl3nzA0eVnc9iEJ6f9pOiAwtRacECKVg9pi1JHFVy PJPBP4EeK3xOiUJUXjJfClaXaQsSR5Ucz0UIiKCmuj1mobxkvuSsPtOWRI4pOZ6LEBBBTpU9pkQh Ki+ZLzGrz7BFmWNKjmcTRGQQU0VPaUmISoxmS8zqNGxJ5piS49kEsoyUnxQ9QKhKjGZLyuo0a1no iJLj+QCikJSfFD1AqJJ1KRxzJqvwMX/03F4K0gUAMSmkVMEzWg6qZF2K55zFKnooAj23l4J0Qb4o pa9YcL+0rJJnQshzeylIl+QHxVBC+Y9oOagSNSmBcxYr/4kg8NxeCtKXzYoJFsYFgypRkzJAZ7Ay Xx4HnttLQXpfMSeJmpQBOoNVWlYKbByTIF0SL4lxWjH2m60aQ4cb2K9A1lDsXKignkhiDMrkHutD QZWoSSmkfcV80/uKOUnUpBRSyxWrCZubLoqPyqGk8l6up9DRRvYrjjUUOhcrqitROZRY1qsNIFSw sf0KYw1lzuWKaktUDiWW9WoDCBVsbL/CWEORc8Gi+hKVQ4rlvNgAQgcb2q8w1lDiXLKoxkTlkHIZ r7VgULEG9yuKNZQ3ly2oNZKYvmIJ/YpiDcXNhQvqjSTGb8WWPtmNQcca268o1uqwuenL5x+gmplM fqUJggo1ul8xrJGofcWcy6Sf7IagQQ0FYEg00KyichGDWhQUQ06mvtAEQYMaCsCQaKBZBeVixrRJ lGJUJvVoPwINaSwBXVnTDIJNXzE2QEwKI5v4OhsCDWksAV1Ls7oP0w62odx0AUBMCiNb/DJP5RPQ NZPVeZpmsA0lx7MBRBlmZdLOdgTQgAYjkDXC6jxOI9iGkuPZBLKMvmLxCGSNsTrP0wa2oeR4LoEs InbFPAE0oMEIZI2yOg/UBLah5HguQkAEP5/wGjMABWc0A1XjrO4j1cM2lBzPRBAm9BXLYKCqweo+ UzVsQ8nxTAb/BAkA+yX+qsBAVYvVfaha2IaS43kQ7gFChOYr7PIVmOEQRIk6mlUP5bZ5cgryORTi 4/uKpUAQ1WZ1n6oOtqHsfAaG7+maElkvCFEJCKIIrP5z1cA2lJ1P53A9XFlj4+uW+XLKeAqaCKwR g5XDNpSdTwbxPFtdY+PrlvlyyngKmiisAYOVwzaUDkAj0RwcumLe8QrKBAySSKwBkxXDNpQOQGLx OtesxtGv2uaLIRMwSKKxhsxWBttQOgCBxudU0xpHv2qbL4ZMwCCJyBoyXBFsQ/kEDSD9idkrZhsv h8zgoIjIGjJcEWxD+QSzqUwP862R8rVIVeGgiMoaNF4+bEP5BO4yLnH021hEvpQxg4MiMmvQfNmw DRVA8FZIibO/Zh0vZkwBIYjMGjRfNmxDBRCcZV3h2J2IyVch1hOdNWzCPNiGKjD4yrzCvmK2YrCG jZgF21AFBleZFzj2k2JMvhAxh6QtBmvcjDmwDVVgcJV5gTNqnPUFj3wFYUFxWAOHzAIYUwkIR9nX N6PEsc/Hqw5JWyzWyDEz8sdUAsJR9vXNKHHG513y5YQVxWKNHDMjf0w1KNzkUN6sEpf+tBOAELCk eKyxg6bGj6kGhZscyptVYql7XQilKSZr7KSJ6WMqguEkj+pmVVjpm1hfsUjYhqpw+MiluhkV9hUT issaPWtK+JiqcLjIpbhZFfYVE4rLGj9tQviIyoB4yKc4RoF+AAK+NJiG2KyZzSYO3p9LAOIgn9o4 FXoSsPHSYBrisyZ2mzb3CCwBibmcSuMU6IrAxUuDaYjPmtht2txDsAQo1vIqjV6fKwEbL49mXALW vH7Trl4MlYDFVm6V0etzRmDS5dGMS8Ca13Da3YuBErCYyq0wRn3eDDy6PJpxSVjTGk68fTFQAhhD +dVFL8+dgUeXiDMqEWvhsQcyCWjM5FgWvbwACA5cIs6oRKxZPadewCAkAY6RPKuiVxdBwYBLxBmV jDWp5+QrGIQk4LGRa1XU4iIgOHCZPGMSsuZ0nX4Hg4gEQBbyLYpaXAwFnS2TZ0xC1py20y9hVN8F RHo510StLQiDzJbJMyYpa0rbGdcwqu8CJK28SyKWFoUhYSvVUGlkCm699iXsmHtFxNLiONhotToq jszArdc+GZRC/vVQK4skYaLV6qk4MoO3XvuEVGIFlEMsLJSEh1asqfLIBOB67ZNiCRVRDbGwYBQG WbWuKiLjgeu1Tw4mUUwxtLKiWehk1dqqiIwnrtc+BVnVUmhVxcNQyco1VhMZjlyvfRq0opXQqsqg IYHV66wmMhy5Xvt0cCXroNWUw0MAq9dbVWQ0c732KekqlkEqKYmnDVawuarIaOZ67VPz1SuCVFEe 0ThXxfbqIoOh67XPgLBaCaR6MpnGuCo2WBkZS12vfSaMxSogVJPKNMJVssPKyFjqeu0zoqyETykm m2pLWrHYHavXPjPOOvBnV1Ewqw5HVKONDOWu1z5L1CroZ1NRMoP2hpWjjozkrtc+W9gS3JupJpyu ubHlqCMjweu1z5w3H3ozVefr2uK1rPerq2t5qG9XV1eA+nZ1dXV1dXV1dXV1dXV1dXV1dXV1LUMN Xf6aGw4ajhqOGA4ejsavxwx7zf9F1/mHuckqfNwaXg9RntlhMgzf2nZhvvsh/8Dh1sP+878eOtx2 2JubP5+7UZRnpry7MTJa4uZbS5P/OMzi8fAT4CfCT4KfDD8Ffir8NPjp8DPgZ8LPgp8NPwd+Lvw8 +Dj4+fDx8AnwC+AT4RfCL4JfDJ8EvwR+Kfwy+OXwK+BXwq+CXw2/Bn4t/Dr49fDJ8BvgN8Jvgt8M vwV+K/w2+O3wO+B3wu+C3w2/B34v/D74/fAH4A/CH4I/DH8E/ij8MfgU+OPwJ+BPwqfCn4I/DX8G /iz8Ofjz8BfgL8Jfgr8MnwZ/Bf4q/DX46/A34G9O7zb8bfg78Hfh78Hfh38A/xD+Efxj+CfwT+Gf wT+HfwH/Ev4V/Gv4N/Bv4d/Bv4f/AP8R/hP8Z/h0+C/wX+G/wWfAf4f/AZ8J/xP+F/xv+D/wf+H/ wevg9TBWZ5jA07faVfBW8NbwOeBt4OmKbgdvD+8A7wifE94J3hlet75rJWj6frgVPNnwXrLxO+9J h8E7Y29xESbDdrgkB241we9Wz01fOX1q9/n3/R3mH5j+bse5Fwz3WDW9Q2dOXzB92bDrIcdNTzV4 n+vq6lpOmr6rXHVu4b3iavPvENvM/7Q4fQfZb+fVwxfx+xOHw6ef2vRxD3j6uxOH6TvStvPn/Bff rk7daZj3wrvKgo47ZNf+3tLVtQUq+29PdHWtcPUd6+ryVd+xri5f9R3r6vJV37GuLl/1Hevq8lXf sa4VqjL/rnDfsa4Vp2L/yQvejmW/I3R1NUTdr8D7uxJ2jN3WxJarIyPB67XPnDcCmrVj9bo6G6to v9WRkdz12mcLG8St37H8JdN1N7YabWQod732WaKGofcdi61GGxmKXa99ZpyR8Jwdq9RWAlepPo+x Kh/3o67XPiPKWHyDHUtfMssm9x0jpOW1z4QxuoK+Y7HF6CKDoeu1z4AwvgTGjlXpKx2sRIfbrKqH PZnrtU/Nl1GExY5lL1nl/lJYVQ97Mtdrn5Iup4y+Y7G1aCLDkeu1TweXVAd9x0o0lkuW21wiq+ZZ V+R67dOgpVVismPJS1a0tWRWxaO+xPXapyDLK6XvWGwpish44Hrtk4NJZERL3rECnRWhJfWVwyp/ 0hm4XvukWELZ8Nrs2PL8x60zKhFHZvDWa5+QSiwT4L5jsZWIIzNw67VPBqWQBTF1xwJQxCrXVCar psZw2Nz2Ra+YSUVGO5a6ZNV4xiRlTWk74yZG9V2ApJWaue9YrISsOW2n38OovguI9NJCE3fMnUOj ajxjErLmdJ1+DYOIBEAWUlJb7VjmpS6GMyoZa1LPyZcwCEnAYyMddt+xWIlYs3pOvYJBSAIcI+m4 aTvmjqFSMZxRiVizWk69gjFMAhozqcDNdqzYf5Eoj2ZcEta0hhMvYAyUAMZQGvK+Y7ESsOY1nHb9 YqAELKZSoJN2zBtCqVo04xKw5vWbdvtiqAQstpKj2+1Y3rUuBdMQnzWx27S5h2AJUKwlZu87Fis+ a2K3aXOPwBKQmEsMT9kxbwatSsE0xGbNbDZx8P5cAhAHSemFOzbjkzmy7Ie3uKzW81bDNlQGxENC +r5jseKy2k7bALahKhwuEuITdmzpNDsEtQzb4S4mq+2wLWAbqsLhIxm+5Y5lXexCKE0xWU1nbQLb UBEMJ8n4xTtW6BuZXTf8xWM1HbUNbEM1KNwkKqC9Y7OirAj0MmtGgFisloO2gm2oBoWbRAWY7ljS za5D0haL1XLQVrANlYBwlKQC+Y7V+UZm1YsIcVgNx2wH21AJCEdJKmju2OwkIwK9rHoRIQar4ZQN YRuqwOAqQQmiHWt9JVhlQAhisNoN2RK2oQoMrhKU0HcsVnRWuxmbwjZUgcFX/BJaOzYWYwJgIJtO xIjMajZhY9iGCiA4i1+D8Y6l3O0qHBSRWc0mbAzbUAEEb7FrkOwY5WuRqsJBEZXVar7msA3lE7iL XURjx8ZDLAAMZNKIIBFZrcZrD9tQPsFsKtPDGLLesYzLXQSDJCKr1XjtYRvKJ2gA6U9k19h3LFY0 VqPhesA2lA5AoPE5dbbGd6wRYQFgoCIYJJFYjWbrAttQOgCJxevcpaXasSK3uwYFTRRWo9H6wDaU DkAj0RzMLrLvWKwIrEaTdYJtKDufDOJ59mYa3bFmgAWBXiUgiCKw2gzWC7ah7Hw6h+vhZ5Nux2pc 7xIQRLVZbebqBttQdj4Dw/f0Reo7FitRR7Pqodw3T05BPodCfDyzyrEdIxxvQKBXBQaqWqw2U3WE bSg5ngfhHrAg5Y6VuN8VGKhqsNoM1RO2oeR4JoN/wlR9x2I1zmozU1fYhpLjmQjCBLsdI51ugKBW AQSyRlltRuoL21ByPBchIEK/YxUueAEEssZYbSbqDNtQcjyXQBbBDOk7FqsRVpN5usM2lBzPJpBl WO0Y8WyDOrXKJ6BrJqvNOP1hG0qOZwOIMqJ3rMANzyega2lWq2kGwDaUmy4ACEjpOxYr53Fmw/Yd W0Izd4x8tkmlKqUDMCQbaVJBuZgxbRKleO4Y+ZW8OpVKB2BINtKkonIRg1rkH7NSd8ytYbmskah9 x4xiZu0Y42ijWuUSdWmZslaHzU1fATvGeC0LQilRl5YpayhuLlxQbyQxfcdcG5bMGsqbyxbUGkmM yY6xTraqVipRl3JQTXYsjDiXLKox7jmcHWNRsih0kjQpCdVox4KQc8Gi+uKe03dsWe5YDHMuV1Rb 3HOW3jHmwWblyiRpUg6p3Y6FQOdiRXXFPYexY0xMFoZKkiblkBruWAR1LlVUU9xz+o4t1x0LwM6F CuqJJMZgx9jnWtUrk6hLGaAGrKHYuVBBPZHEeO0YG5TFoZGoSxmgM1ilZaXAxjEJ0vuOeUnUpQzQ GazMl8eB5/ZSkL58/lkqwbFG9cok6lIC5yxW/hNB4Lm9FKQv8x0TkLJAFBJ1KYFzFqvkmRDy3F4K 0vuOeUnUpQTOWayihyLQc3spSF82/46m6FSbgmWStSkccyar8DF/9NxeCtIFAAEp1B0TobJI5EqM ZkvKajJsC9iGkuNX9I5lXvTEaLbErBbDtoBtKDmeTSDL0O6Y8FCDeqXKS+ZLzGoxbAvYhpLj2QQR GcQdE8LyWKTKS+ZLzmoybj1sQ8nxXISACMMdS7zpecl8KVgtxq2HbSg5nosQELHEjokPNYARKi1Y IAWrxbj1sA0lxzMZ/BOm6jsWKw2rxbzVsA1l57MYhOf77JiYmAcjVFqwQBpWi3mrYRvKzjdoqHmR m++Y4lALHJGyciXSsJoMXAvbUHY+h8L5+E3qOxYrFWt0hyn3zZNGkM/A8D19kUg7RjzLAEekrFyJ VKwWA9fCNpQOQOaQn63cMdWZFjwSJcWKpGI1mbgStqF0ACKI4mR2jX3HYqVitRm5DrahdAAaitvB S4myY6qWcIEESooVScdqMnJl3LjyCQgsqlO1O6Y804SIr5xUmXSswQ2mXDhfGAFBk0Z5Jr/EvmOx 0rEGN5hy43xhBAQNIPsTmyLsmLIlbCS2clJl0rHazFwXN64CCDOpbM5S7pj6TBsmrlJChdKxBveX cuOcYQQIzuLX0HcsVjrW4P5Srpw3jIDBV/wS2jum7ggfiqmUUKF0rEZDV8WNqwKDqwQlLN4xg0Ot sNSh3plS6ViD20u5c94wAgZXCUroOxYrHWtweyl3zh1GAOEoSQXNHTPoiISreqZUOlazsSvixlUC wlGSChbtmMmhZmDKTOdIsVSsdmPX5I2qBoWbRAX0HYuVitVw7oq8UdWgcJOogNaOmXRERFY6UiwV q93YFXnjKoLhJBn/WTtmdKohmybSN1EuDavl3BWBo6rC4SMZft+xWGlYLeeuCBxVFQ4XCfEbO2bV ECGdPNE1UCEFq+3gFYljKgPiISH9ph0zO9WSTp7oGqiQgtV28IrEMZUBcZCUvu9YrOSsxoNXRI6p Dom5xPD2Oxa/ZNF5GolZzSevyBxRIRRridk37pjhsbaAwkDPPI3ErOaTV2SOqBKLreTofcdiJWW1 n7widESVWEylQHfYsRL/V6ljnEoyVpfRa2ITeAQwhtKQD2MFWHZDAynIc4xTScTqM3oZbEO1aMyk Au87FisJq9fsRbANFcOxkorbY8cq/CsYfmk6sVn9Ri+Dbagaj4102MMIvG0vdJzcOL80nXisvrMX waYSCYAspKTuOxYrOqv/7EWwuUgCIr200C47FrxkVXoZyRrCW5DJsn9RJQ2zwa07oWZlpaV0M5A1 AneFMOmkR+47FkHowBpBu1KgNDIg9tmx2CWr1M8w1qKwNanksgAeZkLb98GClxyW1dAVxFp0xwKX rA1y1sezftlcfccCAB1YA1DL7ljYkhE4zvo4id6x0CUL62kd1gBSGWxZMI9aJot2bOGJJZ8afFZs ee7Ysvlf7P6cUtggsogtI0Fs+rjwyJKP9R0LALRm9ccUw0ahuS8ZkWHTx4WHlnzQa8cilyy2sfms /pRy2DA25y2jEiwimZv15OC0Yn3HvFj9GTWwgXSOS0YHWATSd8yyt4ms/oQ62FA+py3jxC/C2PDx /7/MbccClyyhu0ms/nxa2GBCjy1jhZ8FMTd7x9xaFTeClP4msLrDGcCGM1pvmSC375hPh8NZ3cls YJcJpgH+ooc2Pbn0EX47FrdkOT0OZHWnsoNdNqBq9kXPbXp46VOW3jGDsvuOqVndYSxhk5kFqGHk Q/slXV3LQTUXbK7vWNdKUsEFm+s71rXCVG3B5vqOda1E1dmvqfqOda1QFdiuBQ1bDcNwmcn69auG Lp3+D/+JBCEAAHIXSAAAAAEAQAAAAAAAezcAAA1BAABrSAAAHgAQAFkjAgC3ABAAVU0AALkAEACJ UgAATgFgAARQAAD4KgIAZFUAAHeSAQABHwIALSECAAAA9Q8cAAAAAAEAAD8KAAMAAAAA+kkCAAEA AABTAQAAAQCiAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAALxPAAAOAAAAAQAAAHgAAAACAAAAgAAAAAMAAAC4AAAABAAAAMQAAAAHAAAA3AAAAAgAAAAw AQAACQAAAEgBAAASAAAAVAEAAAoAAAB0AQAACwAAAIABAAAMAAAAjAEAAA0AAACYAQAADwAAAKQB AAARAAAArAEAAAIAAACkAwAAHgAAAC4AAABJUHY2IGFjdGl2aXRpZXMgb2YgTlRUIGluIEphcGFu IGFuZCB0aGUgd29ybGQAd2UeAAAAAQAAAABQdjYeAAAADgAAAFNoaW4gTWl5YWthd2EAcyAeAAAA SQAAAEM6XFByb2dyYW0gRmlsZXNcTWljcm9zb2Z0IE9mZmljZVxUZW1wbGF0ZVzM39q+3t3DsLyu 3SDD3rvest1cV09STERKLlBPVAAAZQAeAAAADgAAAE1JWUFLQVdBIFNoaW4AZXMeAAAABAAAADE0 MQAeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AG9zb0AAAABwCjXkXwIAAEAAAACgtwH8CMe/ AUAAAABAV8HmEze/AUAAAAAAHNohW1/CAQMAAADjAQAARwAAAAhOAAD/////AwAAAAgAiRB0CwAA AQAJAAAD/CYAAAEA0SQAAAAABAAAAAMBCAAFAAAACwIAAAAABQAAAAwCmgLBAwkCAAD3AAADAgEA AAAAgAAAAACAAACAgAAAAACAAIAAgAAAgIAAwMDAAMDcwACmyvAABAQEAAgICAAMDAwAERERABYW FgAcHBwAIiIiACkpKQBVVVUATU1NAEJCQgA5OTkA/3yAAP9QUADWAJMAzOz/AO/WxgDn59YAramQ ADMAAABmAAAAmQAAAMwAAAAAMwAAMzMAAGYzAACZMwAAzDMAAP8zAAAAZgAAM2YAAGZmAACZZgAA zGYAAP9mAAAAmQAAM5kAAGaZAACZmQAAzJkAAP+ZAAAAzAAAM8wAAGbMAACZzAAAzMwAAP/MAABm /wAAmf8AAMz/AAAAADMAMwAzAGYAMwCZADMAzAAzAP8AMwAAMzMAMzMzAGYzMwCZMzMAzDMzAP8z MwAAZjMAM2YzAGZmMwCZZjMAzGYzAP9mMwAAmTMAM5kzAGaZMwCZmTMAzJkzAP+ZMwAAzDMAM8wz AGbMMwCZzDMAzMwzAP/MMwAz/zMAZv8zAJn/MwDM/zMA//8zAAAAZgAzAGYAZgBmAJkAZgDMAGYA /wBmAAAzZgAzM2YAZjNmAJkzZgDMM2YA/zNmAABmZgAzZmYAZmZmAJlmZgDMZmYAAJlmADOZZgBm mWYAmZlmAMyZZgD/mWYAAMxmADPMZgCZzGYAzMxmAP/MZgAA/2YAM/9mAJn/ZgDM/2YA/wDMAMwA /wAAmZkAmTOZAJkAmQDMAJkAAACZADMzmQBmAJkAzDOZAP8AmQAAZpkAM2aZAGYzmQCZZpkAzGaZ AP8zmQAzmZkAZpmZAJmZmQDMmZkA/5mZAADMmQAzzJkAZsxmAJnMmQDMzJkA/8yZAAD/mQAz/5kA ZsyZAJn/mQDM/5kA//+ZAAAAzAAzAJkAZgDMAJkAzADMAMwAADOZADMzzABmM8wAmTPMAMwzzAD/ M8wAAGbMADNmzABmZpkAmWbMAMxmzAD/ZpkAAJnMADOZzABmmcwAmZnMAMyZzAD/mcwAAMzMADPM zABmzMwAmczMAMzMzAD/zMwAAP/MADP/zABm/5kAmf/MAMz/zAD//8wAMwDMAGYA/wCZAP8AADPM ADMz/wBmM/8AmTP/AMwz/wD/M/8AAGb/ADNm/wBmZswAmWb/AMxm/wD/ZswAAJn/ADOZ/wBmmf8A mZn/AMyZ/wD/mf8AAMz/ADPM/wBmzP8Amcz/AMzM/wD/zP8AM///AGb/zACZ//8AzP//AP9mZgBm /2YA//9mAGZm/wD/Zv8AZv//AKUAIQBfX18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj 4wDq6uoA8fHxAPj4+AD/+/AAoKCkAICAgAD/AAAAAP8AAP//AAAAAP8A/wD/AP///wAAAAAA/NbW APjr6wAEAAAANAIAAAQAAAAHAQMA0SQAAEELIADMAG8AoAAAAAAAmQLAAwAAAAAoAAAAoAAAAG8A AAABAAgAAAAAAGBFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAA AMDAwADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIiIgApKSkAVVVVAE1NTQBCQkIA OTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMAAABmAAAAmQAAAMwAADMAAAAzMwAA M2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABmzAAAZv8AAJkAAACZMwAAmWYAAJmZAACZ zAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8AAP9mAAD/mQAA/8wAMwAAADMAMwAzAGYAMwCZ ADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMzzAAzM/8AM2YAADNmMwAzZmYAM2aZADNmzAAzZv8A M5kAADOZMwAzmWYAM5mZADOZzAAzmf8AM8wAADPMMwAzzGYAM8yZADPMzAAzzP8AM/8zADP/ZgAz /5kAM//MADP//wBmAAAAZgAzAGYAZgBmAJkAZgDMAGYA/wBmMwAAZjMzAGYzZgBmM5kAZjPMAGYz /wBmZgAAZmYzAGZmZgBmZpkAZmbMAGaZAABmmTMAZplmAGaZmQBmmcwAZpn/AGbMAABmzDMAZsyZ AGbMzABmzP8AZv8AAGb/MwBm/5kAZv/MAMwA/wD/AMwAmZkAAJkzmQCZAJkAmQDMAJkAAACZMzMA mQBmAJkzzACZAP8AmWYAAJlmMwCZM2YAmWaZAJlmzACZM/8AmZkzAJmZZgCZmZkAmZnMAJmZ/wCZ zAAAmcwzAGbMZgCZzJkAmczMAJnM/wCZ/wAAmf8zAJnMZgCZ/5kAmf/MAJn//wDMAAAAmQAzAMwA ZgDMAJkAzADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADMZjMAmWZmAMxmmQDMZswAmWb/ AMyZAADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzMmQDMzMwAzMz/AMz/AADM/zMA mf9mAMz/mQDM/8wAzP//AMwAMwD/AGYA/wCZAMwzAAD/MzMA/zNmAP8zmQD/M8wA/zP/AP9mAAD/ ZjMAzGZmAP9mmQD/ZswAzGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA/5n/AP/MAAD/zDMA/8xmAP/M mQD/zMwA/8z/AP//MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/ZmYA/2b/AP//ZgAhAKUAX19f AHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx8QD4+PgA8Pv/AKSgoACAgIAA AAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AP////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////AP///////////////////wAAAAD///////////////8AAP////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8AAAAAAP8A/wAAAAD/ AAD//wD/AAAAAAAA/wAA/wAA/wAAAP8AAAAA//////////////////////////////////////// //////////////////////////////////8A//////////////////////////////////////// ////////////////////////////////////////////AAAAAAAA//8AAAD//wAAAAAA/wAAAAAA AP8AAP8AAAD/AAD//wAAAP////////////////////////////////////////////////////// ////////////////////AP////////////////////////////////////////////////////// //////////////////////////////////////////8A/////////////wAAAAD/////AAD//wD/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////AP////8A//8A//8AAAAAAP8AAAAAAAAAAAAA/wAA/wAAAAAA AAAAAP8AAP8AAP////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////wAAAP//AP//AP//AP//AAD/AAAAAAAAAAAAAP8AAP8AAP8AAAAAAAD/AAD/AP// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A /wD//wD//wD//wAAAP////////////////////////////8A//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AP8AAP8AAAAA //8A/wAAAAD/AP8AAP8A/wD///8AAAD/AP8AAAD/AAAAAAAAAAAA/wD/AAD/AAAAAAAAAP8AAAAA //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wD/AAD/AAAAAP8A//8AAAAAAP// AAD/AP//AP//AP8A/wD/AAAA/wAAAAAA/wAAAP8A/wAA/wD//wAAAAD/AAAAAP////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8A//////////////////8A/////////wD/AAAA//8A //////8A////AP////8A//////////8AAAD//////wD///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////8AAP//////AP//////////////////////////////AP////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8AAP8A/wD/AAAAAAAAAAAAAAAA/wAAAAD//wD/AAAA AAAA/wAAAP//AAAA////AP8A////AP8AAP//AAAA/wAAAP8AAAAA//////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wD/AP////8A/wAAAP8AAAAAAP8A/wAA////AP8AAAAAAP8AAAAA/wAA AP///wD//wD/AP//AAD//wD/AP8AAAD/AAAAAP////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wAA//////8AAAD///////////////8A////AP//AP////////////////////8A/wAAAP// /wD///8AAAD///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////AP////////////////////////8A//////////////////////// /wD//wAAAAAA////////////////AAAAAP///wD///////////////////////////////////// //////////////////////////////////////////////////////8AAAD/AAAA/wAAAAD///8A ////AP8A/wD//wAAAAAA/wAAAP8A/wD/AAAAAP//AP//AAAA////AAAAAP///wD///8A////AAAA /wD/AP///////wAAAAD///8A//////////////////////////////////////////////////// //////////////////////////////////////////8A/wD/AP8AAP8A////AP8AAAD/AP8AAP8A /wAA//8A/wD/AAAA/wD/AP///wAA/wD/AP///wD///8A//8A////AAAAAAD/AP8A/wD///////8A AAAA////AP////////////////////////////////////////////////////////////////// //////////////////////////8A//8AAAD/AAAAAP///wAA/wAA/wAAAAD/AAAAAP//AAAAAP8A /wAAAAD///8A/wAAAAD///8A////AP//AP///wAAAAD//wD/AP8A//////8AAAAAAAAA/wD///// //////////////////////////////////////////////////////////////////////////// //////////8A////AP//////////////AP//AP//////////AP//////////////////////AP// AP//////AP//AAD//wD///8AAAAA//8A/wD/AP////////8AAAD///8A//////////////////// /////////////////////////////////////////////////////////////////////////wAA /wD/////////////AP////8A/////////wD//////////////////////wAAAAD//////wAAAP// //8AAP8AAAAAAAD/AP8A/wD///////8AAAAAAP//AP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////AP// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////e//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////4v/////////////////D//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////3v/////i//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////i//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////8P///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////97///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////3v//////4v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////8P///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////3v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////i///////D//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////i//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////wAA/////////////wD///// //8A//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8AAAAA/wD/////AAAAAP8A/wAA//8A AP8AAAD/AAAAAAAAAAAAAAD/AAAA/wAAAAAAAAAA//8AAAAA/wAAAAAAAAAA/wAA/wAAAAAAAAAA //////////////////////////////////////////////////////////////////////////// /////////////////////////////wD/AAAAAP8AAP8AAAAAAP8AAAAA//8AAAD/AP///wAAAAAA AAAAAAAA/wAAAP8AAAAAAAAAAAD/AAAAAP8A/wAAAAAAAP8A////AAAAAAD/AP8A//////////// //////////////////////////////////////////////////////////////////////////// /////////////////wAAAAAAAAD///8A/wAA/wAAAAD/AAD/AAAA//8A////////AP////8A//// /////wD/////////////AAD/////////AAD/AP//////AP////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////AAD///////////////////////////////////////////////////// /////////wD/AP///wD/AAAA////AP///////wAAAAAAAAAAAP//AAAAAAAAAAD/AAD//wAA/wAA AAD/AAAA/wAA/wAA/wD/AAAA/wAAAP///wD//wAAAAD/AAAAAAAA//8AAAAA/wD//wD/AAAA/wAA //8AAAD/AAAA/wAAAP8A/wD/AAAAAAAAAP8AAAAA/wD///////////////////////////8A/wAA /wAA/wD/AAD/AAD/AAD///8A/wAA/wAA/wD//wAAAP8AAAD//wAA//8A//8A/wAA/wAAAP8AAP8A //8A/wD/AP8AAAD/////AAD/AP//AP8AAAD/////AAAA//8A/wAA/wAA//8A////AAAA/wAA//8A /wD/AP8A/wD/AAD/AAD/AP8AAP8A////////////////////////////AP8A/wAA/wAAAP8A/wD/ AAAA////AAAAAP8AAP8A//8AAAAAAAAAAP8AAP//AAD/AAD/AAD/AAAA/wD/AAD/AAAAAAD/AAAA /////wAA/wD//wAA//8A/////wAAAAD/AAAA/wAAAAD/AAD//wAAAAD/AAD/AAAA/wAAAP8AAAAA /wAA/wAA/wAA/////////////////////////////wD/AAAA/////wD/AP//////////////AP// ////AP//////////////AP//////////////////////////////////////AP////////8AAAD/ AAAAAP////////////////////////////////////////////8AAAD///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////u92Z vL27kpKTu5KYkY2Sk7ttvJKStv////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////mLuYtZiTvLW8trxzvI28krWTtpKYtW2NkpK7k5m7mLa8try2 vI28kraSkpK7//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////5KTjUpsvJOYtm27kruNkpK2tpOStryTmbuYtZOSSmy2kruSbbaYmZGSkpm7mLa73ru1tpP/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////7ySvK6Zko21kpK7tZKSkpi7tpmStW28bruSvJK8c7tzkpK1kv////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////5K0cm67u7uStbuSvLVzjbuYjW27//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////227k7v///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////ewr3D3sP///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////88PDw8PDw8PDxCQjw8 PDw8PDw8PDw8PDz//96aeXqZvMLd3t3d4sK8vd3dwt28wt7D//////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////PGBlZmY9ZjxgZWBDZ2ZmbGZmZmZsbWZC ///CWTJ5kq61krW7vLa23La8vLa8tde84v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////zxmbY2SrmdDbWxmZrWuko2Rk5Ftko1tjf//vVlYUpKTvNy8 3bzi3b3D3cK84rzC4v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////88YJG2rpK1ro2ubG61rrWSkby1krWSrrv//8PDmnp6mZmUvJrCvb3Cvby9w8P/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// PEJmZmBsbWxmbWVmZkOGbWZsZ2xnbGxn/////8PDvb2ZoL2Zvby9vcPDw/////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////D///D3sP/w97///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAA AALVzdWcLhsQk5cIACss+a4wAAAAiAMAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAA uAAAAAYAAADAAAAABwAAAMgAAAAIAAAA0AAAAAkAAADYAAAACgAAAOAAAAAXAAAA6AAAAAsAAADw AAAAEAAAAPgAAAATAAAAAAEAABYAAAAIAQAADQAAABABAAAMAAAA5QIAAAIAAACkAwAAHgAAABAA AABBNCAyMTAgeCAyOTcgbW0AHgAAAAgAAABOVFQgTUNMAAMAAAA4cQMAAwAAAGcAAAADAAAABwAA AAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAABBCgoACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAEQAAABAAAABUaW1lcyBOZXcgUm9tYW4AEAAAAIJsgnIggm+DU4NWg2KDTgAM AAAAgmyCciCCb5a+kqkADAAAAEFyaWFsIEJsYWNrAAcAAABUYWhvbWEAEQAAAEFyaWFsIFVuaWNv ZGUgTVMACgAAAIJsgnIglr6SqQASAAAAkFaCtYKizN/avt7dw7C8rt0AFgAAAINyg2KDZ4N9g2KD diCDQ4OBgVuDVwAhAAAATWljcm9zb2Z0IFBob3RvIEVkaXRvciAzLjAgUGhvdG8AbAAAAElQdjYv djQgZHVhbCBzdGFjayBjb21tZXJjaWFsIEFEU0wgc2VydmljZSBzcGVjaWZpY2F0aW9uICAtIElF VEYgdjZPUFMgV0cgSW50ZXJpbSBNZWV0aW5nIG9uIFNlcHQuMTgsMjAwMiAtAAcAAAB0b3BpY3MA EAAAAFRoZSBDb21wYW55IE5UVAArAAAATlRUL1ZFUklPIEdsb2JhbCBJUHY2IEJhY2tib25lICYg U29sdXRpb25zABYAAABTcGVjaWZpY2F0aW9uIHN1bW1hcnkAFwAAAFNwZWNpZmljYXRpb24gaGkt bGlnaHQACwAAAEF0IHRoZSBlbmQADBAAAAgAAAAeAAAAFwAAAI5nl3CCs4LqgsSCooLpg3SDSIOT g2cAAwAAAAcAAAAeAAAAFgAAAINmg1WDQ4OTIINlg5ODdoOMgVuDZwADAAAAAQAAAB4AAAAaAAAA loSC342egtyC6oK9IE9MRSCDVIFbg2+BWwADAAAAAgAAAB4AAAASAAAAg1iDiYNDg2ggg16DQ4Nn g4sAAwAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8lAAAAFAAAAF/AkeNKSgIADQD0AwMAnQBNSVlBS0FX QSBTaGluCAAAAE0ASQBZAEEASwBBAFcAQQAgAFMAaABpAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAo AAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA AAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAA AEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAA UwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABh AAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8A AABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAA AH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAA jAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAAD+////lQAAAJYAAACXAAAAmAAAAJkAAACa AAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgA AACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAA ALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAA xQAAAMYAAADHAAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADT AAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEA AADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAA APAAAADxAAAA8gAAAPMAAAD0AAAA9QAAAPYAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA /gAAAP8AAAAAAQAAAQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAM AQAADQEAAA4BAAAPAQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoB AAAbAQAAHAEAAB0BAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEA ACkBAAAqAQAAKwEAACwBAAAtAQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAA NwEAADgBAAA5AQAAOgEAADsBAAA8AQAAPQEAAD4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAABF AQAARgEAAEcBAABIAQAASQEAAEoBAABLAQAATAEAAE0BAABOAQAATwEAAFABAABRAQAAUgEAAFMB AABUAQAAVQEAAFYBAABXAQAAWAEAAFkBAABaAQAAWwEAAFwBAABdAQAAXgEAAF8BAABgAQAAYQEA AGIBAABjAQAAZAEAAGUBAABmAQAAZwEAAGgBAABpAQAAagEAAGsBAABsAQAAbQEAAG4BAABvAQAA cAEAAHEBAAByAQAAcwEAAHQBAAB1AQAAdgEAAHcBAAB4AQAAeQEAAHoBAAB7AQAAfAEAAH0BAAB+ AQAAfwEAAIABAACBAQAAggEAAIMBAACEAQAAhQEAAIYBAACHAQAAiAEAAIkBAACKAQAAiwEAAIwB AACNAQAAjgEAAI8BAACQAQAAkQEAAJIBAACTAQAAlAEAAJUBAACWAQAAlwEAAJgBAACZAQAAmgEA AJsBAACcAQAAnQEAAJ4BAACfAQAAoAEAAKEBAACiAQAAowEAAKQBAAClAQAApgEAAKcBAACoAQAA qQEAAKoBAACrAQAArAEAAK0BAACuAQAArwEAALABAACxAQAAsgEAALMBAAC0AQAAtQEAALYBAAC3 AQAAuAEAALkBAAD+////uwEAALwBAAC9AQAAvgEAAL8BAADAAQAAwQEAAMIBAADDAQAAxAEAAMUB AADGAQAAxwEAAMgBAADJAQAAygEAAMsBAADMAQAAzQEAAM4BAADPAQAA0AEAANEBAADSAQAA0wEA ANQBAADVAQAA1gEAANcBAADYAQAA2QEAANoBAADbAQAA3AEAAN0BAADeAQAA3wEAAOABAADhAQAA /v///+MBAADkAQAA5QEAAOYBAADnAQAA6AEAAOkBAAD+////6wEAAOwBAADtAQAA7gEAAO8BAADw AQAA8QEAAP7////9/////f////3////9////9wEAAP7///////////////////////////////// /////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAA AAAAAAAAAAAAAAAA/v///wAAAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyiYBAAAAAABDAHUAcgByAGUAbgB0ACAAVQBz AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD///// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOoBAAAAEAAAAAAAAAUAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAoAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAugEA AOxPAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACUAAAAbkoCAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkA bgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOIBAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA= ----Next_Part(Thu_Sep_19_07:40:05_2002_726)---- From owner-v6ops@ops.ietf.org Wed Sep 18 18:41:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02591 for ; Wed, 18 Sep 2002 18:41:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rnXa-000Emq-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 15:43:26 -0700 Received: from [2001:218:1:10c2::2] (helo=guri.nttv6.jp) by psg.com with esmtp (Exim 3.36 #1) id 17rnXQ-000EkZ-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 15:43:17 -0700 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1:10c1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id 22D19B16AA for ; Thu, 19 Sep 2002 07:42:46 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id BA221125CD6 for ; Thu, 19 Sep 2002 07:42:43 +0900 (JST) Date: Thu, 19 Sep 2002 07:42:43 +0900 (JST) Message-Id: <20020919.074243.59683841.miyakawa@nttv6.jp> To: v6ops@ops.ietf.org Subject: my slides From: Shin Miyakawa Organizaton: NTT Communications X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Sep_19_07:42:43_2002_181)--" Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk ----Next_Part(Thu_Sep_19_07:42:43_2002_181)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, Here is the PPT file which I used in my presentation. Cheers, Shin Miyakawa, Ph.D Sr.Research Manager, IPv6 Group, Innovative IP Architecture Center NTT Communications Corporation ----Next_Part(Thu_Sep_19_07:42:43_2002_181)-- Content-Type: Application/Vnd.ms-Powerpoint Content-Disposition: attachment; filename="ADSL-Spec-v6OPS.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAA9gEAAAAAAAAA EAAA/v///wAAAAD+////AAAAAPIBAADzAQAA9AEAAPUBAAD///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A bh7w/AMAADwgDsnOVVsOCNMt7QKaRpr/iVBORw0KGgoAAAANSUhEUgAAAH0AAABCCAMAAABNcilv AAAAA3NCSVQFBQUYJt5DAAAAYFBMVEUAAMwzM8xmZv9mZsyZmf+ZmczMzP8AM/8AM8wzZv8zZsxm mf9mmcyZzP+ZzMzM///////MzMyZmZlmZmYzMzMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACkqgCRAAAAAWJLR0T/pQfyxQAAAx1JREFUeJztmNmWgyAMhrUqIm4s+v6vOpCwKdieOWrn YkxPK6WUj59Aghb8L6146A/9oT/0h/7Q/yd9nojAEpkI+Sp9ZJS2lNJuGJm56lLzLfoAvILS7bW6 cgaO6IQeWVffTh8P4dqqm+kj+PvwfRk+Sx/Rz0U5EOdz825qZsvDnXQ7w9rBDAplDxemx1XiTxct vRydecKEcLcBRr0aSzeQm+gw2y2ddfEFfjaVnR0GJ8zNizWxKHjpolS2rLhc1O4l5L5GyQwdui9M 9zP4G0A4C40vUd9crmgqFNeVL+vepEyrUvoMnb9MsYk4pVdc+YGgdteX4CrQVYISaZVK6dj5ZIp1 5OLel6PhxdrX5QrtnfE1cz5onYcHU375gbRh6pXrVmjXwjCUBO1KoVysRe1YXpVc8tqDrw29cJGt NmUcVAN7fgp/8eLRDWYBQud2/rEBaF+sowTP00m0n2GfddyNxE+32347uu4T+lZmQgzPugIbgPZP 9DpaaRjte6fXR3gYSRTvgud/pz31ex/p5RjXXzWpML/Pnt6GZRfoq/TauRCCe+3CfBP46WbJWF67 C2XVNr+z0KaIw11YxV47mtMemaODJfRhs53KKLHSkmTbWLoKH/4H+Vt67UIq2OaQ4VNLtwv1QfZ6 UnsNvg7fmcvrHdnWRUccZPhYdkI7AR9HGXQy65CxaINxusvx0co+qX3eRvGcka0fPF2d184/5+9q m+Q8XSyntdtw8+7wYhZddLazcV664OK066jv4rwMbV2cV3m6oJtVn1rv8z9YSF2Sb7THOS1pa1pn zzYspNiczbvRhZ0mbO9Wu0rpIqoSeTouqlIc0DEAhRUfa0fPn9KuT3Owv/Nwu/9DhfDnNG5PdtbL 8TkuaavPeQd0gXGd5dTbmH/jidqmU1omu362cf+qW7n8nZQ90VM2x7Wkd9UXwY/uIm0+N7ndsyHI tFH2v43u1Rv/G6PR9+vu4A+fHjQdzduFt+9vnl0IloVf+vDm3XMbwvb37lc+t/hE1/p762t4b3L8 F+jaCBlq85rmTy3voN9qD/2hP/SH/h/oP7Sz9Tkfiy0eAAAAAXRFWHQAT0ba5wAAAABJRU5ErkJg ggBuHvAsBAAAGoiJrOuonVjD7kWnYXCpa/+JUE5HDQoaCgAAAA1JSERSAAAAngAAAB4IAwAAAOrr V5EAAABgUExURQAAM4+PpTAwWf///87O2F9ff7+/zBAQQH9/me7u8UBAZq+vv1BQcyAgTd/f5Z+f sm9vjICAmXBwjZSUpWBggDs7Yu/v9/4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGYGnKIAAAAY dFJOU///////////////////////////////AM0TLuoAAAABYktHRACIBR1IAAAABGdJRmcBAAAU Puq3VQAAAAxjbVBQSkNtcDA3MTIAAAADSABzvAAAAx1JREFUWEftV9uum0AMXCDhFi5JdPr/v1rP jA0LJVUanUipdPySXVjbY3vsJSn9yCdkYLx9fQKMRxiu1eWT4V2q6yfD66rym+A1fd83j23VEnmb bVUkf/TwJ6Wy6ux0mWmmdMdu+NpopdxW0dMHTzhzh8tUQabbeIyw5OuqKvC6wart/VH8nHb7OqUz qTfyxSDDNHRKdX540tNFaqTpgi2R9pnl7rgaV9c94fxAzXYPZ7dvLcuiHl/YFkJcpR6FzCnM+5PZ DnZYA+d9c7Y7zB9jgeBtgUUqjQ39jGWNVf9rtzfTk6hHSIJHHG1i5qVmMipVhS3lxxLvWXZnXTum RvkA9D8EtSeUs7szCxCaY4oO9iOp54eoMCInVgF6ytSYKobCQhoExmFUYqW8pAQgk1shfc7AAvDY eK1Wu1LY7EU9B0N4jMZgeInDCc3TbxMGeHLw/V0HCbU6gHfG8xERmRFWRu3FEmTxbPezB0FtmKV9 BEYQN4n55gELpRyQvA4VcurxzeSI1IwH8JBW769SldEhliC7GLb7yYMIsw0ogubaNKqps2ohF9A7 qMc0c1yY0M5RcUk9hdSyMs9RLyKl514tBYZtGvWKFtqhW6jnmoLHHj64JckNMwNC1P9APQ9CleoZ PDlLYs2tZPTBGAg5Opx6SrOI5IxF5XdCBljY/NXU44nnqBeTBbzi3BTc1UdQz7MK2049TXSHp9oe 3GzgBmrO02x92X6OejG7PEaPKjJrZkg9K44PcEOzTD3C09XW0LFPjE3+wA3WPEiiJKgEmcJmb1df GFkuGGKI2by4oFVwUsmy/DCfmGG0OCFjJdFlQS3qQb21xbyXxKk1ks1+WG3F9Zw3FJGwEAIFK8vk WG4APekus+7d09FHS1DPo7Jjut9Xu0K43RdrXn2QxH3JKEJqpYrI1dFRJd6umpkuxeEnFQaCxo0A 6Kp21Szdqx+8PWV5lZZKu2vUVtQjRQIe3fgwLuPjppu/69sRrjLqrdV/aTUONn6G78RmMDLqvQTq zUoZ9d7s6SXzp/g+fkn77Upt+5d/Lm/3/uPgP83Ab/LNHjLHISQpAAAAAElFTkSuQmCCAG4e8JkD AABnViI1jqJOHy/BdYRyWY21/4lQTkcNChoKAAAADUlIRFIAAAC9AAAAvQgCAAAAabXrZwAAAAFz UkdCAK7OHOkAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAMtSURBVHhe7dKxDQAgDAQxYP+dgxiBq506 35y8Z2Y5BT4LnM9/7wq8AtxwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZ cMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRq NtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADel mg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBN qWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApw U6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC 3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOl ADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNA KcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtww UApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03 DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbD DQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZ cMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRq NtwwUApwU6rZcMNAKcBNqWbDDQOlADelmg03DJQC3JRqNtwwUApwU6rZcMNAKXABrvIEd1LKdAcA AAAASUVORK5CYIIAbh7wMwkAAGFboKUia4mVu1MMQGXdsfn/iVBORw0KGgoAAAANSUhEUgAAAEIA AABCCAMAAADUivDaAAADAFBMVEXvnKVKQkqUjJS9tb3e1t7Oxs7v5+9za3ucnKWMjJTe3ufOztb3 9//v7/cACAhjY1q9vbXn597Ozsb///fGvbX/7+e1UkrWY1rOY1q9IRi9KSG9Qjm9GBi1GBi9ISGt ISGcISG9KSm1KSmtKSm9MTGUKSnGOTm9OTmcMTGtOTnGQkK9QkKMMTG1QkKEMTG9SkrOUlJ7MTGl QkK9UlK9WlqcSkrOY2O1WlqlUlLGY2OUSkqEQkIQCAjOa2u9Y2OMSkree3uESkrWe3ucWlpjOTm1 a2vOe3u9c3Ota2vGe3uEUlKcY2PnlJTelJStc3N7UlIYEBDnnJwxISHWlJS9hISMY2O1hIR7Wlpa QkKcc3PepaXnra1jSkqthITWra0pISGEa2vnvb21lJRaSkq9nJzvxsaUe3vOra0xKSlrWlrWtbWc hITevb2ljIznxsatlJTvzs5zY2M5MTH31tZCOTnGra29paWEc3POtbWMe3vWvb3nzs5KQkLv1tb3 3t5SSkrOvb3WxsZrY2Pv3t7n1tbezs5za2v35+eMhISlnJyclJS1ra3e1tbWzs7v5+fAwMD39/fv 7+/n5+fe3t7W1tbOzs7Gxsa9vb21tbWtra2lpaWcnJyUlJSMjIyEhIR7e3tzc3Nra2tjY2NaWlpS UlJKSkpCQkI5OTkxMTEpKSkhISEYGBgQEBAICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8iYF8AAAAkHRS TlP///////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////wADZeeHAAAAAWJLR0T/pQfyxQAABTRJREFU eJztlvl7E0UYx1ErIkfBxqLFbWJpqVjQIsilAoKoCIJVwROhCOHyoCAWBXpjkUK7O3vO3neaNt38 jb6TTRq6STYFHn/S99ln353Zmc9+33euXUI/sS35H/F4iMQeitryZIjPKYpqQwzz+AjURRAsixYy HgXRt46iWjoEPsJ4FEQ6CSq2YXEFix4TsbKvjaI6flLkJm4xiOa7g3fvJhbWMeijTTt1XVPE+ojf jr7U1QnWteNouth48NOjfQziJWVRiOYDoLdkLZ0H0lB3poOi1n3HAkLTVFmokwv0cti3cBFL7hgY 6yQPnZOCJCuKLPJs/Ii8XwRQJVKy69SBsOJckyitkcRJdlUs4vtkEVCUkdx2Tmx6Law4LonPCjxX b2rNhxFC2nsh9v51oaRjWBK45VOozgTvLvcH23hp3NTVrwrKWlq/VSTIZHSJRBFkLRYBLVRru+fa lqEeAwRcqRsaXsFGARUI5nJbUQDcUwcBYWrLriTDmvYjMJ51EeiFPeUB2eB7jqkrGHeXcvtDZFZV VbH89/VhFHB/6+RnvboiNYlr1iZTKVLzhsRFkxlFMAwnfDivArqltvULDbx4//yJ/SlC/rFKJFEV rIB3LZidr4xwHP+MahwuVB4S+QoZUQRZSh+k5ucmYHYDQpS17QXkLhxZIJUIGoEM7UR7eYlQbcM8 L0hX1hdqtipShYwogkEcfPLw/AqB67gAjL1hzTsarouAbPDSva0PrVTqkCTwN9vCsK7qssDVRSB2 RX9yfobCtUsRJ7tD2uZxQxGjyajccoDxSXm1g21X8duhqI2r7UUhgLF7Pg9E/L6/1xLS+tf3u661 mEDApkrLtXBPfd3bsal777HzluPYpor56OSqhkBbypsGIEbNCRnLqm7Ztvk02XsXgWB2tzyUzc2j pibLiqobpqHJUoWI6ir2PKQidRLUK8DQNE3BUvQ0rIX4srUs403XNlRMTIZ9j6+Y3jUQI+WTZMPQ 6udAvkCMb4A8VOx71RArEfdxuMJaqNQ3HoiAr3McR/4KKgE1VHDiTrJXtKZePTjkWDqGUUCIqQ6o MSKsIOuW6/k+7HyWrpA9gqGrdq+N4CXVsBzXdR2LhMFW/3wcAnECVg3Tsiw4RbBQZb+MRTBcOp2+ LIhYUWEmqPcm0mf6JBSKQwUPeYk92R9k8sRyzrAoYTysZwtF72cgePAwAYSZfD6IQQxeyxft7BjP 8+NzxdJ7N2naBd8j0AioczGI26S9X1ByCSGZ+KxHOBd5hiDymQR9MRbxKzQKNIYZBz/HMFfBTbMM ngX/oKAinz9HAsnVRtjQZobEEwBqzVISlQBFPZPJ/IG8MEtCfCAkAps8QLNGVchBY7H0LhGqyE/n YhE+NDHAk5TldQECmBVK70gugnC84gKxyACSL4JvfDFBArkFxQnfz5xCBKGHjBgVS8j49aOpX0ha mxND4N5toMe+AH9hFUFIk3N1EPRMYThJ13wvTd8sxH6DEK4naEhn4/3En3UCocWZ0tTqJb/PR0ql YCTMhUajuToq6Dtne4J8EAS9S0kpcSE3F+Qbe07/BekczfXMKvAnnMv1nI5D0PSIqitNd0qlqeFl uhaWmIEBklv61sDgQDzikW0BwrPcbMYzHYZ2PNfzMk/5WVXz/evWtENrvmc7VoY0mLnmZnAthJKZ dVycu0+LcHhNB9msZxiW7ZuzLmcH/vOaYAVZ2wxyTlaqgTAddhltW5AzD2MXWQaiMYahyFjw0rJv czRjcbojYZ0z/r1c/McR/wDV+JbgJ8/hfwAAAABJRU5ErkJgggBuHvCCCgAAqFlgZsZin5fKFicO aELhYv+JUE5HDQoaCgAAAA1JSERSAAAAowAAAEoIAwAAAOD5FPgAAAGAUExURdnV5vLw9t3a6FJG jqqixn1yqMXA2NHN4XVpo1lMkmldnHFmodXR4+zq8k5Bi+Hd6ks9ifr6/JWMuT4vgMC71ero8YV5 rnltpvDu9enm8P7+/l5RlP38/fn4+2VZms3J3jopfbexz8nB2Yl+sOjl76CYwD0tf0U2hb220rq1 0q2lyJGFtZ2VvpKIt5qSvcK81m1gnq+pylZKkPb1+UY5htvY50AygoJ4rWBUlubk74B1qqSZweLg 7I2BsrWvzpiOuu7s9L651MS/2Ek7h8jE2/Tz+MrG3NTP4vf3+riy0K6oyouBs7Gqy6Wcw25joMS9 1o6Ds+bj7o6Etaidw9DJ3u3s87iuzqGVvmNWmM3G3Ih7r/j3+p2TvdjT5EM2hODb6fPy90I0g4Z8 r8C307OszbCmyaOcwuXg7MvE26igxZyQu56XvzkofP39/uXj7vX0+OPh7ff2+f79/sO71eLf7Pv7 /L2306KXwDsrfqWdw+Xh7OTf6ryz0LaszDoqff///8zJ0A4AAAABYktHRACIBR1IAAAADGNtUFBK Q21wMDcxMgAAAANIAHO8AAAIh0lEQVRoQ9Wa60MSSxTAEeSxIAu4yFs00SU1lAyBtJJclUwkLTPT NLDHzUzBTKN7u2f/9XtmdhEQq90FH3c+LcvszO885syZh068prLl2LPolPWtsJqyxpTXst/2QmVb Yf1rYbSPbQAUTxUiitfA6Ng1AEAlpxTxyhld20YOCQHuKEa8asa+FAUEmFKOeLWMc0ZeRgyXbibj tjcqE4JT1TBQVVmF7E1V/buSH5JSeaSqpStiLM+c6RAZI6oQr8Yfez9OnOkQH9IdN48xF6wnBH5S HeLl6zGgy1cHs0w6ohLx0hkPY5UGJQJY7t0sxoO9BkcktE6HWsTL1aMpfE6HAPxT1YiXyeiLJZsQ IXxwgxhDw2wzIeyoHdNEosuK4ZOpJN/fDPlDvRYvi/HkI5NIctAEme+9MYx6I8sK0STXfw4yOacF 8TJs3XFrgzGwzsROkv/SaG2V83RVoPb7oy4STgcpZPGcS7J+TWpsux5Pct64dSPNTBhY4bxL3tWG 2G7GbzGvJW+1oiIJJHXJs7kw77oJjK7XD6eMBLJq7Z2kweuVUwouqxGxrXrM5FY2PUajxRaXIQ2p XFnclceNR1PcaXMM334xM0ogvQQSXdL2lAzIQUYKQKz6XKLt43prYPrV5+7Rh5spAmmNR7IF2oc5 KYXybq2Wbt888/L2yIvpN59jK5FNdEnP0Lcq0h4GIIRk7dfNGHD8/PdD5/L3z9TaD3O1QNg7VeQq yKh856RZlrbEcJfu+Pb6vx/2pgnkqLs+VBfIxF3pn3iiXY1tGdfzXZ9mj3+u50b2pl+9MfkaaPQ0 lPcvtoDYBsZAx3Z27dOzdz/XP4yMDEgDpVaG6cSdn79WxgOf421X9vXA8bv19U/NA6ObzImJ4VYQ W9bjQaFn1TGZNSPk654LSCxkTswfXSujaz7T85dDl11bG7xoOr4XZiZYtjU1tqbHgCgGjgp2/z9v dX+fXKiqyTCmafmWtNhaDD/whUTxoNTRM+j/1br+cRjTtMfXx3ikf/sSe3eVOkpff0XxFCfuvOqN iXOtaY/hPcfHWQcJNa7fLJlnMANyt6hG7f6oX37xc1b39+/z1kAsbrVcNNxVYWvV48LmyvfOdwOT jbPK+a4LEVtc9TZZE79GxkdWiyc2/WHg94jiasRidKjS2UWVNTG69g3puHdz5lnpD/3rPd43GKBa LFoYQ88rTkM4/3D7j91np4zmFgHxcw2MrhX4wrGGO5k/997nea5hn+x8u+oZM0bM/L8YxpsIvx70 4qRz3zFYy33GN1sOPFr02JEnqxNvWUY8ycxnCiRIu+757Kv/6B1+33wtHpkiCpT9R3Oo1WPJQs6A ptwDe0Njo92x0WkMQDRKBu4VMh2lk8YZ53QZZ8uWi0rGAkGkBV1ywmrzrLxCSL0fve6g2fMCubWW AVXbOlA9NiWQRZaRouTxJEkuLignz1qeY0irqvQY6q4/yPiSYNNxY/f46vyvDLr1TfPeRL3EqhjH GrYT+7kJ72J56zdBMqR1F6rRJmoYH9UjJjYiwyrP/bT6pgpGd+1MjdntNLdjxCqjVs5olk93K/kf 5kFljbeplmLGHgYtXTR4TjNtGQdq8JUyztsqBuuQuQ2zrxo6qa5Sxqxn+GoNXCeKUsbWVvHqdac5 PrbWleavlepRcwdt+PB/w1go99Qi8ttx92w16/Ob3OP3q5qwl3sah3XvYbmESZldShxc/sPV1UOy KyC6BvERC8krAy/L5Zfik/sPCmKBVCflyYLbfaac+VXyXTWglcqrh+LJ4AN5Meeac8/6SNVQWmCr JJPWBJfkLHTbNWN04nNQ/ssRFDYal4GzguAJib7wqBQhGMHpdKbIo96QEAQhwdITmRVBmBKnBaFT jDB68iK0zyajyahNVsRjJ34nMDLznCAExVwiLPVkMhSLHEv+ymF0lpdGfTtQSb23GIlae/AKYP7u UlzeOsaEYmehwbvu4HezYtfOGH2LU6WzM0e7ur+CyXoiFaMU3XjNI4QTwHJox0IrxgDCa1MAS1I2 0glgtQFQ4ShLfjvJSQe0kywEF1JL2OYRmUGkw28Xtm1Bg1LrLQEwKI48r/idmH+/b2Akp0MGlwmk BklfZ38v8hCX3QdlSy3gPa79HGeiHUeh2CfOAkSlPXLsZn//jDECsJuGMQl/GglMYi8yPgUUw0vf bjshWd3l8uHNof0a0xjLAkgaqxYiG+zdAmltswIwsbcv782jrlJy0oaasWHPkAoyNFVD5vCW+Bjf lMjPgBH4qQ3g5aNtVJIA6VorKLhDJ3akmfeoDzocbuNDdb+4S4BozbYZLjaEktQnO0eCNYz1406a ogXQejzHyR6LUlfluQXAcQYOWI7uqoS82IwoYp7H0HFiD0IFtXxXlogmLkE68kRxgF4amdKJi5BE x6tQ3xnBPqtJoakC0doCfgacAn5cv+Gtjw4Nk7x8g+rDngZuOJCRhUD4ql/M7aBZY0VMSGjPIVwR DYkiLjp2qVocBqhgK/KiooMDzADP7guYbcgc1j0JshYrvp8lH6DMyBXoIz2Zi8DhZZxt2rLdOWGx chCtv4rsLo6fxJFxl3J9Y6HokMQXRf8EJKnzYcmiIxtPUSNLEj/SxUQfCtxHf/bxsJMGkHeuFngI ok91U63OD5+QE9F93Sm8D9nxmvEMeZtBH2RiNoa01otGYWPe4APyRwyygVXsrP5CxHKySzSjmT7S vsw8cMZdGawvCoYqMA5O7tSPjLJRTGj2ZXS7mLSQwMHD4tC3SQKhIW3einyzz8zH8Xqx069zho/E XgvPx2kdPTltrqAtsPh20UAQISLpBNKGgefrB00qib14eJ5aQBzmefxUPurPcXyw6jM+Bp8Po7xV fhE4ZdC41kV5rfOR570/eF4+T3zO87ERjpfOuvXkvp9NL/4Hh22bhBmdjJgAAAAASUVORK5CYIJg IRvwBwcAAFXbHQYsP2GcgDvz3Oaxnq9UBQAAAAAAAAAAAAAoBQAACAMAAGD4HwDIyhIA1gEAAAD+ eJyVlC9s20AUxr/v3bl19zdSq8nSpM2aos1kU2ChYWBh0BQYGBhoGGgY2LEqqGAgcDAwcDBoMgys tkm3d+fYaqUsrU86vzt/v3v37j37iDPALAWwuIBvkfbn0oxeSGyyyOrI8iW8/cIkWCEDcdayFOcc jI7e4Zk+P568Vuv8y9BOtf/19Gzp/Wn/TPj98VtOEKtd/nL4sFcY+MT6/fOWi4In77LhJNid8q/U 9o0nKu2ZpJHvVZgf09q4vrs2Lu69/j8+7ONbMwtBHTrx0SyEVvsy7RkengmhJn0T41putU4bVGaK K1vqvjlik2NmRkHrys0kZiIVLjnkGhnBQucFrzmm17pyW4yQ81IzW6KUGUayhl+x4m3QunK5nXBr 5oTJWIoScoetucPE9Oi1p3IPK8BHq1K/aCrc7HIjK83iT+yMRmwXSO0QPTNEYcZB68oV0mMqO83E FTcYMOZc53PecEKvdeUqjDWLOQaywEIKjGUDv+IHV0Hryg3tlJUpGZsBF6KEQOfg1CT02lO5x7PP NvtvbCr++zh2I9R3S02/F6v0H+d/vgv55uo76Fy+mrp+n+hcY++vSyWLtkiiwz77qr2NGp9p1PhM o8bXofjv7wP8A17q3C5DBbABWJmr32WfiFHJqfWQaVVOCAAAAAAAAAAAAAApBQAACQMAAGD4HwDI yhIAywQAAAD+eJyV1V9I1FkUB/DvOfdedty0NCQGtc0o090IBiLK6mGWehhJVqckzAdRIY1AKvJh hCIhgqLQCSYyY6MMKnwoH4Y1qbCgUqJSImuhHvpH+RRGD05lO/v9/dzcl2VjfvLjzrnn3J/cM5/f ncBv4GWy3M/I03Q20n8BGp65ZzPe9RMKgFisrw+CH2czAWQhKqw1AVeGc/gDlnlBQV/f27fpNPMB 7NH53yokogmp0CdSaRZI1NRIremURnNXWs1XabchOWIb5ZTtlD6blBt2XEbtB3ntnHxy+TrXLdSl rljXcqxivN05bbcf9Kgd1zM2qVdspw7ZRh21IX1mvuo7c1cnTadOmRqdNgs0rU8MNMFxs07rfJ2S xzopPfpOmvSZLNdRpHQIw3oFPXoGbXoUW7Qdq3U7lmgV8nUt5uhSBHQu5sgn5MtrLJFRrJYb2CJ9 aJNT6JEjGJZ2pKRVlkujNEmt9EhUHksle1Chm/39h3n/qk9lowlKhdnKPhyXOnNPmq3IXrtKDtoW SdiEXLDXZNA+l/s2JS9djky5Is1xJexBma7jGGXc4nJ0n01pl32uvfaaJm1C79gWHber9JUVfW/u cf/HNW22GmuC5gd9agKa4Bg1VnM1LY/Yh5P6Xur1lZTqOD7qHdzSJBLai1btQqXuQ0hbUKhRZOs6 GPYAmgMjU8iWlyiU+wjJICrlAlolgYQcxC3Zi4/SLKVSJ/Xc/0mpkEeyUXO576i3/1lLnp89tDXB Z5a54pnx2+eZ+Lt5PiuZpLWop1JG/s/hbAV7gCx9gmyzAHmmBkHTicXmLlaYryi3IVTYRmyzndhp k9hvx9FlP+C8cxh0+XjoFuIN//dnt1DmuXwpoc9yOt1Er/V0u4t+D9BxFz2fpuuL9N1P5wP0fp3u h+j/Jg0M0cN1uhigj346uUgvp+mmi34O0NEueqqnq030VU5nJfQ2D/n4jDl4w/085DjI+DyWoAur sR9bsBNt2IYeVGAY5UhhhSzHYmlCUHqQJ4/5Dc7nvjf7++e7ANGnoAtkma3sw3EUmHtYZgUr7Sps sC2osQk022tot89xzKZwzuVgwBXhgSthD8rwxZVIniuSUvpcT6dV9NpEt230e4iOT9BzL11fpu8B Oh+i99t0P0z/I+zBMD3cposh+higk8v00ks3J+jnEB210VMTXVXR13o6K6W3PGTjCwx7ADzgOMD4 HApxDCG0oxLNaEUNEtiAW1iJj1jGVQXsZJ6cRJY8At1z31F//wUzp9w/Dn9BWM9izFaj3xsNsNtM IM44bIMImwBqTczPZVo7gRHp0JgENIYJDUpE1kiZN0ekHYwb5Kyfy7R2DV5gROOo5biGp2ycb0eM 8YjWckUE/XLVz2Vam9K4HLZh2cH7sHkhZQY8u+KcH0GKca7Z4eUyqi1I+5e/JqKX8KetxVVvZK9i ZhLdjCO2GBGTiwbT4ecyrZ3EmBzWDsnVDkxqsVRLWELenAQ4Xyw75JKfy7Q2zG9lTLvRwDHMXnVr CB2Mx7SBK6pxVW76uQxrBdotcRuR3bzjZkJCJiDVnIOOCRgHzW4vl1Htv6fff336diJ6v+Iv+A4s 4vwP/vno/RWnf09Pm7r09Hee4q92hbrILfXWuCJTx1Mh/Tdb+dt6AG4e8EEPAACR9rbal2ZUL0Ke rPcuPiOZ/4lQTkcNChoKAAAADUlIRFIAAANjAAAAlwgDAAAArwRzqQAAAARnQU1BAACxiJWY9KYA AAMAUExURQAAABNRkv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYHn4MAAAAJcEhZcwAADsQAAA7EAZUr DhsAAAvGSURBVHic7Z3bshvEDkS3+f+PPgUHNk6wZ6S+SPIurQdeiKeXJDdQqYR8/bEsP5LHgVKR r9K0ZangVK/6pm3Hlh9FsF6VPduOLT+HbMFqarYdW34IWMEKavbliywbhllu5a6zrnYZpWyzM6Ba Zv66Y5LAskn4/RYsmnG1W+lkP0aUdn/63PeHX7/i61jdCTQb9vlJXO1mGtkP0RToP33o+5Ovn9iO +f1UrnY5gWy5o/L6qQGePvLPB9888PXG0TQ7/2w0ybvgJle/HytbbKhuWG6Ex9O/vjo6VniBjvV2 ufoNOdlSP0fDMjM8njv22I5pt9vo6ndkZAvtTA1LTPH4tWPvPvv1TtWyAPbRRJRzt82ufktctszN WbHoHI/ejjneTGX5Ntvv6teEZavUvA0LDvL4t2N//3fiyw9uxwoE5a5+T1S2yMxesdAoj3DHLCUz PJnL8mx1imuBKSY7Vswxy6O1Y/oXs2GWpc5xLVCd2zHVEtlhHk8de/rL72zHCgQ/1HVqx2Q7ZKd5 xDtmKJn8wXSYYaWjXIfKzrTCUQh7OmbTjad1LbTKdehP0IyUYhAYb8cqDA2uFbo/xImDV/46iIsX wctm0lq2Weda4jvQSbm/qpEsHfOopuJ8aRxx14rrA7K9SoARDyu9Hasl5+q+PiDbagQIKSCtv07y 0lWQosk4XxpH2tV5fET2wjQfDZy2o2MGzXSeMY4CcbUdnwjuEAJ0VFDe27FaIFfT7YncDiHARgYl /s//+035tN4yn2eMo8BcTcfHYxt8ABkhjLmhY3JHJNCZx4C6Om4Phx6Y5CKFUN+O1QK7Gm4PZx6Y 5KIFV//+/wTrHhYbYoHOPAbYVX96PPPAIBU1sLu+Y1o/NNEaSIC7qi+PR56YYyIHlt+O1UK4qk8P J54YI2IAtf/3z5RQPSvVgxOtgQSEq/jyeOKJMSIOQPtLx/LPKuWISG8iDuMqPTweeGSKhwVQfztW C+MqPTweeGSKhwdM/+nPH9O8qlObHAlDuQrvjuedGaJhAvO/dSz7rFCNyjRHwlCuysPjeUdmWNiA BtiO1UK5Cu9O5B2ZYWEDGuD5z6pVvCoTG56Jwrnq7o7HnRkhYQSZ4Nqx3KsyLzbUnYnCuRavN/Kl s8sAEkaQCbZjtXCuxeuNfOncMoCDFWCE544JTiiyytESCsK5qq7OxJ2Z4GAFGOHescyrKqscLaEg nGvxfiPfObcM4OAlP8J2rBbOtXi/ka+cWQZQMJOf4ZeO0TfUOGXpScXgXEVHp+LODFB4a6V5Kz9i oGNzfx3CIdafisG5Fi848o3zygAGFyH9i1e2Y7VwrsULjnzjvDKAwdWGfJPtGHlEiVGeplgIzlVz cy7uTL9BwIV6NT9jpGPUb3DKCgE0xUJQrpqTc7IX2gViKraHX7Edq4Vy1Zyck73QLhAUIV5mO0b1 ROGD0JWLQLlKLk7KXmgXCHvgb2eHDHUs9qhCB6IrF4Fyrd5w5PvmtAHyExre15/YjtXCuEoOzspe 6M7PWJif/+b3jhFNEdhgtAUDMK6Sg7OyF7rzBQuVDxnrWORVhQ1GWzAA4yo5OCt7oTs/5QC+n51y O1YL4ao4Ny97oTk+6eBP+JP/dAzuCu+C0pech3BVnJuXvdAcn1UoiBB2TOCC0pecB3eVnJuXvdAc n1UoiAh37P6qwAWlLzkP7Cq5tkD2QnN82qAi478dA9vCq8A0RqeBXSXXFsheaI5PG2AZuRBVxwTj wjRGp0FdJcdWyF5ojs8LQCGejkG//itlgoOtqVzzrSv4Mb967y6BdECgIOVFx6C+KMZFwdZU7/nO FfpQhXrvLoF0IB9K2Y5ZF2ZwRT5TYt67SyAdyffHhDt2flY0Lwa0pQbPd675TxSJ9+4SSP+cjgGN 0YwLAm2pQ/SNa/KH14n37hJI3465gLbUIfrGFR2rRbbOCUhH4pEYV8fS/7hNeTBAW+oQFbiWavdK Fe0EiRF0LN0Z0bgg0JZaTLdj3vTtmAtoSy2myo7NlO1Nh+LtOYmOvX9YNi4GsqQeU2HHhsr2pn9S x5KtUU0LgiypSVXWsamyvenbMRfIkppUVR0bK9ub/vkdS/0kc25OCmRJTaqijs2V7U3/qI6leqMa FgVZ0qe6lvr2uhWtBonZjlkX1uxaqtsrV7QbJMbYsddPq4aFgbb0oa7TZXvTP+jXUr2NDv/I3Jgk 0JaaZD9IdTsmivmpHSsVSABdtGuoXsWiFfljch179bZoVIJ2gQTQRbsG6tWsWROUIupYuDuSSSn6 DeKYz9kt296xtEBBynaslteuqmsWyF7oTQcEClLojkkG5eg3iPPWVXNOv+yF5vi0AJQh61iwPYI5 WQYohDm4Su5pl73QHJ82wDK2Yw0KYU6ukoO6ZS80x2cNsIjijvEGPAMUwhxdJRc1y15ojs8qFEQc OxbqD2/AM8EhytlVc1Or7IXm+KQCmLAda3GIcnHVHNUpe6E5PungT/gTsmMCA54JDlFurpqrGmUv NMfnJOwB/+fUsUCDeAEBIySCQBvtmifydXN6AvkZC/j57ViPRJC7q+SsPtkL3fkJDe/rT3AdUxjw jJAIEnDVHNYle6E7P+5hffwXjh27dkggIGCGRYyAq+iyJtkL3flhEefbv7EdqyXiqrmsSfZCu0DM hHm4tmOCfAVDNEKEXDWn9cheaBcIubjefc25Y5eSKQQEDNEIEXMVHdche6FdIGDjefU927Fagq6i 6xpkL/QbXIT4F9s7ls1XoNhDFUFX0XUNshf6Dd5bSR9LcOlY+teJpwUETPGIEHVV3Vcue6HfwE56 CKRjp9/wlBYQMMUjQthVdWC17IUBCm7SM4g7ls5XIFlEEWFX1YHVshcGKJjJz3Dr2OFLoREQMEYk QNxVdmKt7IUJDl7yI2zHakm4ym4slb0wwcEKMALUsce7vwMICBCtooSEq+7IStkLExysACNcO/b+ W6ERECBaRQkZV92VhbIXRkgYQSbAO6Yy4JljciflKryzTPbCCAkjyATSjiECAlS7qCDlKryzTPbC DAsb0AD3jr37WqgMeGTLKCDnqry0SPbCDAsb0ABwx2QGPINUriRdlafWyF4YomEC81d2DDPg0W3D T9JVemuJ7IUpHh4w/UDHXtdJZsCj24afrKv02ArZC1M8LID627Fasq7ic/OyF8aIOADtwY4JDXhG yVxIu3YuO3h4vxcgYgC1j3QsOCKqQDNK5kLetXHbsbtXaAEmcmD57VgtedfGbcfuXqIFqKiB3XUd gxVoZtmcAVz79h377tVYAS5acPVQx0ID4g4ss2zOAK59C499+WqkABcphPp2rBbEtW3hwa9fjRQg I4Qxl3WMkSAZpnMEcu1aefQLWOME2MigxGMdC8xHWXAM0zkCuXbtPPoNLFICdERw3tuxWjDXpp2H v4NFSoCPBk5b1THOgmOazwnQtWfr8S9hkREgpIC0DnbsOh2pQTHN5wTo2rP2+Lewau+AEQ8rvR2r BXVtWXvie1i1d0CJhXYWdYz2YJi10bwrM2O5bO/6GkrGK0c7dpmNFyEYttK0KzNkuWzv+jApAoXx dqx2Ejiyw3fe+kArGImwpmMSFZh5W8254p80C89bH6oFovENd+w4mcYFZeBaU67ER73C89aHiyGI bLdjtaMQkfXG89ZHmPWNIumYzAZj5mbjrsxnrcrz1seotU0S79hhLJ0OxNDVhl2Zz1qV562Pk2ua YztWOwsVWe08b32kXc8Yio5JhQDmbjfmSn3Y6TxvfbRfxxCJjjX+hlzMa8J+I67cp43S89YnMKwf YTtWOwwZWWs9b30Sx+oJBB3TSyUZvuKrK/lxn/W89Yksa/UzHXszjcWL15q05bMr+3mb9rz1yTwr 5bdjtdOwkaXe89anVC1T5zvmMiO1xm36vSv9gMt73vq0skXeqY4N/d2Q3HZrx6EjK8XnrU/uWyH9 Ezq2LN9MK9gf2Y4tywcwp15/sR1bfigT6vUX27Fl8bIdWxYv27Fl8bIdWxYv27Fl8bIdWxYv/wN4 WV/UyuqELwAAAABJRU5ErkJggqBGHfA9GQAAxH+YSkwRufLHq3g/np/Mfwv/2P/gABBKRklGAAEB AQBLAEsAAP/jAw5NU08gUGFsZXR0ZSBvcXJ4ent/gYKFhoiKjI2PkJKTlJeYmJqbnZ+fn6KipKem pqioqa2srK+ur7OysbS0tbm3t7q5ur69vcC/wMTDwsbFxcrIyM3Ly9DPztPS0tfW1tvb2+Dj4+hH SUtiZGZmZ2hmaWtpamtpbG5rb3Ftbm9vcHJvcnNwc3Zzc3RzdXZzdnh1eHp2d3h2en15eXl6e3x6 fH56foB8fH19foB9gIJ+gYSAgICAgoKBg4SBhIeDhomEhYaEh4mGiYqHh4eHioyIiYmJioyJi46J jI+Li4uLjI6MjY+Mj5GNjpGNkJOOkJOPkJGQkpSQk5aRkJCRk5WSkpKSlZiTk5STk5aTlpmUlZeU l5uWlZaWl5iWmJuXmZuYmJmYmp2Ym5+ZnJ+ampubm52bnJ6bnZ6bnaKcnqCcoKSdn6KenZ2enqCe oaSfn6GfoqagoaOhoaKho6ahpKiioqSjo6WjpKejpamkpqilo6Wlpaalp6mlp6umqKynp6mnqayo p6ioqKyoqq6oq66pqKmpqq2prLCqrK+rqqurq62rrbKrrrOsrK6srbCtrrKura+urrGusLKusLWv r7KvsbWxr7GxsLOxsbSxsbaxsrWxtLiys7aytLeztLmztbm0srW0tLa0trq1tbm1uLy2tLa2trm3 uLq3uL23ub24t7q4ur65uLu5ur25u8C6u8C7u7+7vMC8ur28vL+8vcC8vcK9vL+9vsK9v8S+v8O/ vsG/wMXAv8PAwcTAwsfCwMPCwcXCwsbDw8fDxMnEw8fExcvFxMnFxsrGxcnGxsvGx8zHxsrHyM3I x8zIyc7Iys/JyMzKyMzKyc7Ky9DLys7Ly8/LzNHMzNDMzdLOzNDOzdHOztPPz9PPz9XQ0dbRz9TR 0tfS0dXT0tbU09jU1NrV1NrV1tzW1drX19zY19zY2d/Z2NzZ2d7a2uDc2t/c3OHd3eLe3uTf3+Tg 4OXi4efk4+np6e8kJSg7PD9CRUdKTE5PUVNSVVVVWFlZW1xbXl9dYGJgYWJiZGVjZmj/2wBDAAsI CAoIBwsKCQoNDAsNERwSEQ8PESIZGhQcKSQrKigkJyctMkA3LTA9MCcnOEw5PUNFSElIKzZPVU5G VEBHSEX/2wBDAQwNDREPESESEiFFLicuRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVF RUVFRUVFRUVFRUVFRUVFRUX/wAARCACAAIADASIAAhEBAxEB/8QAGgAAAwEBAQEAAAAAAAAAAAAA AgMEAQUABv/EADMQAAICAQMDAgUDAwQDAQAAAAECAxEEABIhEzFBUWEFFCJxgSMykaGxwUJS0fAV JHLh/8QAFQEBAQAAAAAAAAAAAAAAAAAAAAH/xAAUEQEAAAAAAAAAAAAAAAAAAAAA/9oADAMBAAIR AxEAPwD6MOyY0GTDG3VlW5w6gM4rkkfxqd2xpsjHmSZiqRl4kaQrVkbvq88f217IhM0bQw2qzxhn lZ/3ntt3dx6++vR47QxzN8RC7YlJTaoIWM1YJHHi/XxqoVHPLnfFWZKaJ2sRyUCB2J9/PbxpuXgR R4zY2LKjfrOws/Uhrcx9u549Ne/XEeRJ8qkjQfVE++qUcc+4BY8arycqQYAkx4Wm3kBSQSXQii3H bvoIcGaLHz5EhczbVPU2lQXIAsgA+hv2vTBJBFlsd3y8e7dHHM5IazZIHj007Bhmx8t4ZYoPlXQq rhTvJ87j5+mtRzLiTYXTx1QpjOWMFAla7VzwCefQ6Bs2ZFlMEwZ/12cfpDjaB3bb5F1zopHnjwTF G4cHcd/Z4kPN0RR7Ec6yCBoJHyZsdZp2+rqo20qncKvsPOlxxQ/EJYgMf6thdiZLALeSAef21oGf DJMURsYjNC8ikh3NgsSCRXYXXHto3ykXLZllZg4HLftjo9qPqfNaTJLAmCYZmYpJJvURttICnkDb fatPxsjBeIZHw1FnBJZ6K2hHJJvk2ONAGc2OvRbJuWKS4tsZ+kjb5J83/wB41H8OyEyykKMcjGB3 W0g3OvYWoFMPHPIrXQ6cJylx9zJO5MixvLYF2C3A9DQ1KBjoMhMOKOOSOILG5BU7AD9J/Pkgd9BZ PCIsnIfdEkckKxF1QM5JPcV48axGWMyQfNqRFEpXdGqjvxdaidIZ8JMg47rOIy4x2lbaHJok2aIH GiwncYTnLWIfV1GKivHbm+/HfQMg+Y4Qus0Ub8/p95L4Nk9uar20uJosGQGGKS3ILAuCYALPr9R5 7eNUQZDHIdROs6s60Nt7yRZI/wCO3pWl42IYMsLLETC26SORxt20LAIr17Dnv7aKjxBjQwopzYPl 0cGC2oWpskE1xzfnzrslJcQ9KTZ05G3ixtUcDge+pYcJVeSXIQyKsgKRHaey0SvmvvpM8TT9KTLq JhJ+ghc7SfB3dh30RRK5XGI2zTQshTe78iu1cXZN2fbSJsNMrEjjjyHdVAnjkUUXo3tbwQe3j11W 8EOJgELIZ3Xe9oLJY23IPe/86fg5HzMLsrwkFA1O1KPF3+PXRUj5GLJCHSVpnbbbGX9vFmweK7du 96CSDHeKYiF5nsAwpQ3BqHtY88+mhmzI2hkBEqKV2SbV/cDwHo9hxXP30wY0sDxNLhKzs25mU7VC 1Y7+bH476IUI44siVomKoMcoqENs7/uN8evjWw/JfBoVWGURblBSNUJbb54HiyD+TqqTJU4sj5Mi xmRnKN1LoV6dtehy4yh4uSwFKr+1RzYJNUf86CCVhI8PUkhY7i4Cw0rCqF32PFemvYOPknJkhdYE WSzHjRfSQK7k+Oa/jSsz4hgr8RRXRRBFQeeYEAljwAa7C+OfOuiBhxzL8pII0xkZuFslTwe/Pj/A 0EuJgY3wvLjmjMkrkN1siZuYK/atdq8axMXKgnx4pzIizMH6qSAGQjnbx3U+h1ZM2RH8OKwujIR9 PUIAF+vqAL799LlmiyYIFE170TbGBuLKRVjyB350B5YjyVaaNes3MamwyK98X4JGlzYRSboszA5K qJZOGJI7cHye96DKy8mLF6fSnilQAERCwQSPq9TQOsnbIaGNYD8xKoEjEEJJ7X+KHHroKZ1w3x1S YY6zILQgcihzXkX6jSwpysOGWdFEbfucmqJav5HroEf/AMgVBLKKIOOUokXRs+K7/nVCwCKeFei8 jDdtFfsXg2faxfroooWnz4kkx3jMUid2sFh34AF83zpMWOsMPysbFQfqZiv7R3LV/p7V+dTzZEdr BkMX+p1DxpsUGq444JDarx8MN1FVemywosa7hyt8/g15541UBlSDLD5bJPjx4ZKiiVWSgOQovcPT 7aVBJJkxlMiCPFxqtZdwUPyDZF8AnjnTJ5YstoxhTdCSOo5ADuDccLfkcn+NAsuHvjiyaM0eMxLS cMfqAqh9PkfyNQPwoYXiyNk0EqGQkC9pDbjQJPe+fbSIZ4VgbEjebJdXKSqzGv69+PGmSZoimx8T GgWWJ1L7pVJKHcO57eum5whjWMrslmJKRszV3FsQfXj30UpYsTrKMqFwIntRGgsN5agexr7aYZgz ZMmCY2KIXjhf912bNjtfp40wiKbE6E7KJQ20gSi+Bf7r7d9c74diywQjH6oVHWRlKPTBT5DXzz2v j76Iq3R5OHjdSHro628O0PvIFqTfYg64+PiSZXxGWJJxjl0Us0bUUA488ePN99XZM8yNGpT6CwDy KTQBAs8dySO/bRwTRS/EujJEyxPcsTkWxckAg+D2u9B0YU6wEUvTljZCJNren/7fOufnRtI8b4kK fMB1WTpyKoKHyb7fah41S7qJ2ADUAdrKSt8dgSORxpOO0r5BXp9Cdk6YJAZEHJDUft76DZycnr/K yCzQNWQfYgc3YH86h+KSRYWXFOclWy5pF2LEoAkagNp9L4s+g108qRMLozFpkQxNtCRWGb0YjvyQ QDoVXEhikfJMRySpapLLEXRN3wL0Uh+vHE2z97ttIkYuVJNbQRyB/wDmnNmLF8PmWWUmRI2LliQy UP3Hwfb7aCLHnmwJJsYsrtuEwcFTKaoAHwAdtfbQHLzJrinjjTLVGZY2W9tdyTzfkUNEHmf+wohw phCVkXqncCDZAJN/6q8e+mZfSxcgx9dcZybEhqtouuSK450j5d5F6SJIylyvUdQRuI5BArz3/wDn WTMsYWKeJcrIgUBmZDTWeAo8ngcaKBkSLHWIQq/TkUrJHGNjncCSB7dv51VPG0/xAIxjSQRXOw3K Hog1fpxpHSZ4njIXHV2EY3twas9rBPHj11VNMDPIEMrjJVYjzRSrsqKrnvoMjmHzbRyVIUdUhCKK Hmw32NXpvTjC/OtBK7QvXRZACncWK7mmPOp7m+ILFHPEYYVUo0kThWDDm+3AqtKyJcnGRDJFO0c+ 63dvqXaw2sNvc8X9tAWY8GXkYoxHjeNjvdWtekTyCSK8+POn4xikkJdMYRSbVchCpJ5snxRNVffX PfNwY/hcKZF5AaQoJSKIJDNbV54r76bhri/E/h1Ys8mOuWu6lUWu0AE2RVe/uK0G5hjkabEghZAs aP8ASnJ5JojtVDx3rTSi5s5kxgwfoKLqhtu+R4Js0Doy7TJHF8Q+hUciN1O1WP8AprnvV869FHPH HMMwb4FB6fUoOa48dx4F+ugTCVzGlOHA7hAm2pACrA8qPA9+3jWHHeafJrKlKBhujVNpj5s7WJ83 X4OslyYp1EEbSx5LxtRjtRYANH/n/nVsGLh40EEzbl2gxghaUKSeWr/t6DnZmJmoomOayNvajEpA IugxHnj17HRZPw+L4ziIW3TZWzb1HbbY3BiGA+w/nR5uXAidQkzGCgwlQqrGwAv357+uqmyBFEkh lp1bpsFqqPgeCaPH20Ch1l+JPC86kkb46UbYyP8ARvuyeRzoovqgyfmZBK6imlRCB0u9qfIokfzr JMWDervIyYqbmkldxQPFc8/00jJnbGkf5Q5LvGCzI20HtwAB7A8aCqQ5e3p5JSfHCjpkErW0fU19 yfb+NB8MkilnIjBUwkhY3SqbuLB5Jrz6accqabGQssscUY3Sspr6geeDyR/HGpWzo4Fmy4wUVACY xByWHcrV3usUNBZHEJviEWWwkmR0KhWWwKIrjweTz/bQ5GTBHlYyzKyyr9KxxpakG9oJriiB29Od c9fmMuF+jkssOYwb6WP6Kjtzf0ntx766PxDImGMyiGRskqCrKV4b/dt8V/fQc/MyBH1BPLNHNkVU asCF2j9wB9DzV86qSd5skRR9aUom4PMtCwO/jkg/bSsqLD3Qt02aUbdjyM24MxB5HazXbt207LjM E8zPAZOrtd+SCtH9vHINcj7aAWxo5lffEnVdOUc0S1djRAB/wNSfPKZ5MAwk48SV+owKs4PA4oev /Gqc2eIZmB83EoXcE6kjV9TcC188evbWTRrtyIJ3BxWcSPsNVZ8kckUKFd60Gww5i5jTq4CBdzxx c2tgEIP63ocj5edZVgeSFg4WRtpNC7oXwb5N+g1SqQHGhljSeLe5KbWJCKRf4v08XosZcV4j8vvd ch97Sq21Sw44v8/xoA+GSxO8i4sbKh3VnBRRa+QPbg8/86XjfMJmpi/MSNCFYuOKjFmya/1G+B6a VkNDDmSY8aoIQQRSM1SWT9Qv8aDMRPiU0G/HhZqHzMNlAq3W4+CPOg9iCXLmaZk2YqApFtA3MfPF ccjxpJkSH4djRilKgxllYkEILPilPfVR+HwYOSk5laaOcCPZI24KCRt57AVZr21TKuNkYbHOO6MB t5cbiAfDEVwRXbnQRmQJmdbF3Jjhxe9unG1g7SB5Jsc9r1YFEhe8jiMFKXglrsf/AF4/n10UCZGN SRRQfLRqQkS1QUftHuL5vx20jKx4WwI4yyO8W10eL62C2LKjt5GgZjxSbYTK24RyO0YEpY8AAI3q dY0z4zvFAGkuQNIAB9K14vxfF+t6XkSSumXCqJsWUGIyHYpB7k14F/mtFiiHotjpOsi9PqAhyWIB qq71oIQ8GXljDkDxQS/qR7FAUgnljfvQ5v8Atqj4i6nHkitsiYsUBV1uJq81579tPhmX5SYDHHXh UpEDZKg0avvyTpD5QxdkqYMbSvZlogDgckMbN8fmtBTFGEiOQIZN6wkSeOoa4H3GggnyxkQoJVZY lAckmmBAJ5rn2+3vpuPkw5tRRbiGh2yRvyBxYJriz99QRZGZlPKmdjzIuPkKYjGyjqKOCFJ8Dm/O gL4thTLsxlkilacuerIVsduF47kcVp+EmCnw8wYsbptTlJgXMJ/21fr4B0rNgnORMJMiJDW2HYBY B7qWPb2rnSRjtBOXZVyMyUjcFariNE1ffgf00HR6a5LO0xEcZiqSFhwijuCb4POo8GbHiw4ocEHI jViyBCFLKbHA9AOSftpkx68roCOjIyM8b8n04739uONOxhFFlyRqblssgYfQRto7QPQCiPXQLiMW Mz5WWiwcLGdtufa/bn37jTXzVTMmm+XdI2UdOiKY8Dcee3I0GfHFlGFMroFLJSRkscDiueP6cjUw EsLStLILWVVAn5jjShuoX2rt+dAU7TyQySsBlSGKliVfpLDglmPbmx7aOWCaeCO+qA+0tAg4rnvx 9v415JVx45FEMaiaQJuVySxLWGv1Io/nTJo5I/icEEUVJKS7ZAYlQFNkV45P9dB7FhZUmMuXkBg/ 1h1sbQf2gDgd/Gpzg4omZMfLnjeQ/WyEruPJ+njjtdaYc3IyoWkhjMc6WoD9m54LcGl9+Tqgrj4k Cc3UhkcIbaRvtXI5/GgU0Qkix55CYwoO1JBurbdnj++k4q5EUUifpEhuoHRK3ITxtNdjwfxWvSGG CQLJOy2V3Ag/RvB3fUOxPH8DTMmA4EXROU0TPXRWUioz6jyV9vHGgqiXHDIk0v8A7A7ovcceg8V6 6SYUygJZZfmohZaiuwMP83/FaQMqLH+JyzBQxQKsjldterX27Vqj9d4Qk0q9Ka26YpGYdzQ9KPjQ SmYYONLkXt6hKCOibocUK/7/ABpXzMk0uPK8vSaSRukkyEg+PB4sevmtPnhEZxY0lMuIkdSCi8ln swbxXk+mqMZEfpRiNZDGvVVyosKSefYEaBDtjSGSL4fhtkzxv+ozE7DfcknvXv8AjU2eMyaIRw3M 24xvIF4CAWAa4HegNdKNpMWaaYxCdJArOIbAHHLC/wDHfS4M9ckxyIiRLOSJFaO3NcDkdidBjQQt ihosh4Wc7o1RuKIqrBquDXNa5+WZMXDi2Bw4kVEfHO5mHcgr6ci6vvqiCDKTq4kJHT27Fctaqlml r1H/AH00jqY/xLKkQPFHkI6mBgSBv8MQe5AF17aIrx5YcJpoMoJGNzdNZgAXA72fbv8AbXNZDDPl SxZayzZTjpu0Z6ca1wBZ7+R666Esk73DNjFmjJ25TRW5okbjxQuh9/bXo1AzJ8mfrTM8QRYVAoEE k8Dsfua0Vr5bU+NMHkdSpjZEIBQ0AxaqJ9fTVGYmQmICHMrFlGwcKRfOhxM7/wAg4ORui2G1V/oZ L4rg/bnSpJ9i9NnMs25yjRoQFrigBwaP+DoE9Y4cRORNIiREArIQWQ1xfe7sj05GrJspZZ3foSPI kG9CajD7qFA+v3/xqWH5nGneaUFdu0P1IQTK4B+oePI83xWmpOskbwyQCL9MSPNKtj/4Nex9fOgL Iw5cnAoRxMpUSMrISzMOQD6/n01uRGmZkPBkYxiVFWSRnAYP4BDfzx7amjlnhnkXFxlEZj/U4AcM Tt5J9L73pZiy4pzk9UvizOAyS/SUAq7J9/x40Gri5Zk6khikLIxKIm3cvZb9CFvtQPGmQ5WQjGWB CY1VWUyUjDgcc9ztPH+dVPLjxTRSrLulI2bUpjVGr/n8DXsZoZNysn6ijiR1JCtzQI9R7eugkHy8 eXXQnJ2MixWQoBo7uOPHrxZ0WEyfB+ni9VhFW0gEyiQgGzu8Hg2OdBniVYiajnRdq9EfX0zftzR8 8+mh+KY82HA8OLGYhK+5nCARoe7Nz447e/50FP1fJvLi/WsgB3ba6YN9h3PjjUWecvFwjAX6pkFt JAnKqaPP+3ue2qFyJZ8WPKkmiMatuSZUK9Tx2r93j059dUpK2RNAv6kcisWIQBfpHHI9O/voiLDk XbDDG0iI8Py5iRh9NH99sSTfazzpsvwwTmKLFiSNBKLYMHZaNggnz59ffWsceaWVogoPIlkC2NoI oHiweRqiTJjvoiSVCx2Bo03EsRzZ/jn3GgKIvGsyzyB40G1ygIZQO/A9a/vrmwT42LmCTIZ48WW4 BG610l8fyT59TqvFcB8gFVmxzIUMjsULAeB6CwfvrMxUM02XFu2uwRxI1p9IFEAd/XQbP8MyIkWS R4Ztrll6h+rbV3x3OmvPjZEJkiVgF2shKfTu9AL4N0f40Pw7NEp6OUxlyFUuZDX0r43DxwQPzpkT xYuFNPBuCmTaUb6i44Ue3Pf86Kmw/iUmSqLJDMoYNboSoLXZABonv/TTp988TpPAyxsN7oSCarsR zfbUnzDfNZU69aKCArEkoXabvyT48ayDLVoUyOtJJKTcjiisnJ+kdqHb05Gg/9kAbh7w4AQAANg7 tcVrSQNJ+MyUCQhGTon/iVBORw0KGgoAAAANSUhEUgAAAHAAAAAbCAMAAACTDfvgAAAAA3NCSVQI CAjb4U/gAAAAwFBMVEXAwMD9/P3w7vT5+Pv49/rs6vH29fnd2uc5KnU9LnhHOX9PQYRXSopkWJNw ZZt6cKKPhrGakrmjnL+rpMSzrcrCvdXl4+3z8vc7LXdBM3uDeqm6tc/U0eHLyNv6+vz///7zzwH3 1xzz0jvlvAH42VPXqAD43HD745HarR3+9djHkgL75ab+7Lb+8Mn+9+T+/frbtVfkyoz+/PfSpj7h wXbq16vs3b39+O2zeQW9iSDFlDH17Nn9+vT//v3+/v4AAAAgsfSTAAAAAXRSTlMAQObYZgAAAAFi S0dE/6UH8sUAAAOhSURBVHicvZaLcqIwFECjFQiEQCAhlJdtfUARpSCoRdv9/8/aANa2s1vrtp09 cUIGYk4eN5kA8Ak3zw9PuzxP03T1lnSVpnme79YPz5+1cDE3611rWb4je494s2rVu/XN92TrPF0d G1+KlCVJWddFUe33TdM8vtA0+31VFHVdJtlSaJ++Ntp13rqSLglT63l1HEVN62rlL1+avRAn2Srd /aP0IV0mJ+J3qmZf1eVmq0hui9xnw6G03W7Kuti3NZuqiLNlfrkz72xxm97KmqrebA9D+ex/B08H Ia6aVrpMHy7RpVnckcSzYr9YPHY/4To8XdxjAFptta/iZf5ZzTyJj0yqXva4qMrtv8hO7DZ1VSTp uSo3y3jWM7lf9FT1p508w3Na1snHDTwkf+g2XxrbO+eqXH20lsmk5+6ou99819aTf9Dr1V3PdLGY L+bzeZG7juNEg8hRFKcjkvqnI/1IR2a3PfOeGgALQqhLCFITdmC7f8IIjCKHn20tcF7LA9f+Wxfv 3vkKcS62HhRBGGBPhdDzCNE8CFUPyRwj3T8rtNhLaUhGkjn8UDidzrskwllGEKnIgip3XQNq3L2S XTFG6soDbHB3yAnhI2pbIWFXjJLQssdMAZQzm3DZHrWfbeJwEwZhAAKfgZASOgiJdRTGxxFOWybi hXINfU8zoD4GAwRxV4nAawWASBXzyZFvYgcSpBMvgD5GRA1QJHmO6mMzQiHybU5t5OjYIaaNLI35 muUFiLyMfXU7vZ2+ELfLADWmqhoUc6eosJvBAYaamB0b/RKZDhREdIBtGVkI+CYQD9nRGQK2QQ1L 9FCxLU0xKMAEMWCamAIUYPN0OmbTV+6u2pjRQ7F2kALAILTbKlyFhnAF1yEYEwyobhCAwkAnBtCZ olNdeEXZJAIMZN2iiOvRCDEvGovOhVzjQ0ROq5i10TLtlzIBwIAm97qYFDPZ5mIuIWxXYGxohhVp hkYx45pLTJ+4Gqc48gyVmhbADFNRZrqJDRkZDnJNHeMIjZhu+ch+jZvD5KS8WwKxAcftrnMBCB1n 1I3Q6XfDVUBDEQMhiCTJAaESctkBSggcFvFQEm8jkVFFYZECQsYjIDPmSpGoElJn/CZS1+X9yZid DfsfY1dW4qSZ3oojJz570v8cT5uiPUgnk9ks2f0fJThsimZxfz+L4yz95k3sYvJtXYibwizOVv9r mGI9l2VRVUWdpbuLric/g3zYluKidvjiffOv/AZ7DpZk1+g6NgAAAABJRU5ErkJgggBuHvA/XQAA 0gykEotd2DcKt7VRgttVS/+JUE5HDQoaCgAAAA1JSERSAAADGAAAAMAIAwAAALAmNYkAAAMAUExU RaxiBNubBH+ds/zRiAQ2cdCbR8TP1E1qg/zCRrVqBMmEBHqdvfy8BPzrydKbKHSCkMaFLtekZCpQ cqO3w+q/Z+HRqLrQ5cGEIOqxR9/q7PSsBNy3hD1pnNKQBPrTaeWsKQpDc8J4BJ241l6Frfz46iJR hfviqY+rwdTKZPTgx8/f6uXIntecGPy+JuC0Z9ynSfvgi+SwWVB4oNGcOG6QrzBdib55HfvLSfzb qd7DiM6VRa7E19SFBAdDfeC/elZ2kvvSlsmQL93s9+isGdyQBMx5BOC2d8qSIeWcBOGyhJSns4Wd vAQ2fEFqk/r6+q/DzN2qOpGvzN/g122VvfTHiNadWOraxcTS5cTg9/zMJL/K2PnBV7RuBMeFFPvt 1zFglI+dp758FEZ4rISOlN2cN/zetU1ukd+3Wc6UPPzGCOq4STxde86RFB5GcfzvuaGww/u+Ntuo WH2VsfTCeMfX2+CdJ7m7wUJvnMJ+BD1fh+3x9/////m0BPziufrmx+64aPzXmAY1ZGGEouzVtdyu ePzNeOyrNvvTefvem/fl1dfZ2/y/F/vLWvnNOPzIGiNRfN++lHuiwPKzKOOjGfS0F4mlvsrZ5/vW pvrx5tnm9W6HoezKrLhwFCRSlHKPpPzWi92tZ/zKaN2hScSKPJ63zPvEacyHIO++hK2+1d3l6158 nuLFlLDI5NSHFGh6kNaTMNyVFMx+FO24d9aTIMDHyp2yzfDKlI+ftLG8zNmkBwQ7c9SjJrzX6NSj N+ykBEJuk/vz2eKkNuClKPS0Ob/Q3PzCKgQ8fPzCOPzbePzonCxSfAo7ZHmezPjKnOieGL7K5L1x BPC4WfW5SE5xnYimzNDa9MqKBdOWBWOKrvv+6yVWhcR+HxZKfZyutOSyNNaiWPzGWFF+rfzqt3Si zH+WpH+is9OiR09uhPzGSvvyycaKMuTGZuTWpMSKIuTy7OC+hxRKdKS+1JSyxNTm7N+6Z1R+onCW szFijLHK2NWKBODGeMuWMuPy+d6WBMx+BN+6ef3S/VcAAAB8dFJOU/////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////wABatoxAAAA AWJLR0QAiAUdSAAAIABJREFUeJzsXU9o3MiaDwgfLOiQgQQHTLIImoYmg40xDEpognyQw7uI5dHx Je2GQMSYZVgwTUBkUEfgp2kH3uHBO8jwDO32o51DGDyxIZdlwdl3nkWZg5eQg5ccAm+YkMtcvIH2 1vd9VaVSd/tfEqfbTn9SS6WqUkmq+v2+31fqjnPu+4Ep5igJx3EesGWJWXmpXM6Uy9VH1XK1Ws37 eZ8Z7PIHrj6u+Wo1U2WnPmItMIP2lh4ssdZ7+aADO8TO9foG+sWyzJbKW4wB5cyjah7R77q+ixwA GuSJD7R1fX+GbQ5ZWAt5F08llsCetYmtuC5lPXpUfsTYUn7w4IGTJsuAOL20L5YYDISoBUiDPLl/ QDtHvMv5gBRw4dB1ZT5Dez6pcZBBrbzvipagiRnJNVfsoBI2zw6YshBRsgNN6aV9WcRgZNiCcAbC IQFU1+X+nXl3FzfADnT1LscucGZGHgnAt+lDV9HAqlSK8qOwCa4DCz+VlyDhXM5CuDLqyVI2qwZ5 Azt5+wKI4WRBGogLLvh62JngtmdclAiOSD/BuusmrBHG0U1pP8WLfUIpkgDZDCeHPOKscf0k6bqu mgXq4nKCsE81w2YpWSc7oMZnsLNLjGx2ayuTqfKYxRShi4B+zvRzErOmhL7w3onD5wkpLRLdapYv ZSdRIcEhkZHzYRX8SBpOmOemr+Yql5E3aObgrqrVsqoiA/vkdtaI4TB92CozPpgcciKUgQzIY3TI MYDmEjwSZ3JQzBYZ90A9ky85xaGrqHflNXz1WF41fUwtwUdcjC4It0WsgRI4y/R55VxOEikH2awe VxQhLExEtrIwGxmw5JPa2SEGCERVxDg5l+sBwYvtCJ4AN0EKnxjiEwgBdckJCqs4omXsQz49p85P VM/OgyhJCRQJU0wkXBQv6f351MI1VV4hXUwRufnIUYV0SGKTNyP48dqvIkF6PQhnx047MUAhQCAI +QcYVEjXMVN7UazsUyfkTGZqXVPA1kTQyzIOa+npTdEU16yO1SUtENej83z+RKZLLZjJfSZXz8Fq +kKg0Ng8BAniDCTko+z0EsPJspCJ3HhOYvWgRa5KRnrXvhdlhEOcsyuxkSSKKQuU6XXOBI5IaqnT +P2oS/GWKS7JHst0FVVSeKq+CHDbnoezEviR7XzhO2DLEe0UEgMZkRHwM4Un784E8WlnRJoQ7XyQ TlnRCKkGClcgz+QUQUyygwhKIiqN2oG778o+ETvJjNwFCfgFbIEaN+lC8jKm+uBtD0Ptsa6BMLFc zmZf9nrITqGdFmKgp3Oy5TLNOwkWMgLxCalti6mCymwrkBmpGmoV11S3si1RKVXLNzkLEkpFJkN6 pPDIPGilGguQjCJTXlMlNyeHKy8jiJl6FqyZM+XLBdS6fCaztDQQi+PYKSGG47CZtZuA1JfQ9FPg PUAxDlqUVYGXgKPqpvET0SUj+kS4IKTZ6nJvzmmSnHWIgWTItplamNS4SzSBtCvbTtimPrjokVSj qrH46p9bA3oczfqeGGxyncn7yTC7Xcc8OgL00oARuOqEksyIRLFQChb2d1zSJcACfqPiu8fvKpXp r27f3tmZX71xgezVhVffDJ87d/i6/A1UZvbrjdX5ndu3VzY2KhvvipF6O/s/kJJ2haa2uQSq51fL XSYfA0tbnxLjpYOUKFf9Njj4QReQRO4xiXGIpYKr5Crsg1dHmj57XNnY+Or2V0OI/2+Wh8nOid05 Ojgncg63c3J7jk47lxQsv/r7hb8Pre7sjD2++dhS7tQ9QI5cftdRN1LB7Hzwa6z9rU+J4WQz8Hq/ w6JApFIEWWTLCVv07HGREWFn7sKFteV9wX1CVmrPWGayMrSzs7JR+VlMSri1U1mmAzNlRHE/szT4 8qOr9R8xsuWMawYw2AGskVxYZjqsp8JAlmOGKQsi0UAgaKRghUsMzpDxtIg3w9QnivjEOXi8UdnZ Wb1wYeSzU+E4dpfFXrd3NjaK0GkW8STiTxGJ3jjA/Hx5MDNvt74iBuMEhimL3KVFCarxiG2DCD5J IZXhPkIS4JZnCcJIWATQNJQsLkJFURPxs8gBZRUrY/O3h9ZGYu6nS8OluM1nK0fxPmjdL/+o5Uc2 dm8l0WDp1ciN2/NjSJFISAm6jCCKUvSIUEJgXeROw89sHfBe94t749s3xOCciBhgFyXgFVqobt80 leMgyWjPggSjgMlbDExTxtzRIssLEDoAmEWzWNmYX526MMJQhjhjZGCIiwlvuAI78FNCGGIRJkuY hi0keE2AKxxBc2wplaheic7CFlnhkWxYLqKZkrgo0YsahjuOOUfi4ZH1ufmxyrMoEJJIPRaARUln Yu8uIjuiQWilWB8Qw8mWfROAimMkR0uyIUrCoUBZ1PKAh0xqViQOpZ/EXEBKkLDJ2piefzM1YsQc pcPxMtsuM5DBXmrDMifHsHDOhGzOgeFhpZBKFUEoJQJD+I6PKxiCGF3LSoKEjBnEFXbnSE94nvju 2tzqykYRu5TCKwwYA5PEU8oyT8POr25lew2KnluPiZF14EdB4NMjgKxw+MyrqdAPUrv2ki61FMWJ kAfoJzFkWsQQKvp5Y2Vn6oIXkyigOgCcCEwxd9Sx8NIlToGY3LwUDw507smFBvAiKQjDHc5fNHxU k3rRabGsQuSAu4/pIXiKSr9ZW59fualhH0BECboRQJcHAXca3KHwY4iseouN3loPiZEtV32CrKm4 cM4JHCKxmqlde0mXWjKZFEaBxfaWxSYQ70fuImSWYwJWXFoWtEBOIEviBHdCTeIEm5iMeTTTDa7d s0/GMF6Du8TYr0RRleBejAyJY/5E8cjU0ESlaIGioqcwF2kIaAK2KMR6kSKr8lbv8NFb6w0xXma3 UNoDnBSisAfcIp4REDWiBOZRCvgRpSNl24Ub2DKECpZ2c+zN3IgxTFiRJECGSOygnxd+Vm4lqj4c uPueT2jtsuxfu2s+6VUsyMDzMbIT1x8u8edm2ctPb7wZq2jCLUW8+0lBeC7xJWDTDph1fGkzj89O DIdNKfImqbmYDNKYcHHHmSAfpEjsOC0iccSZkqpDu4gnAxFBBZWJN1NvY6PEljg2JE4kXGMFX3wb J6ThmiEcb8pK3bP3z22vUTpCvcOaEfcb4xSDUsRlMEMwTbkrI8auYFXuvp3c2dCIB9TBtMFehE3A p2qZzIAYJ2fwbfZWjqLbhA7ptW3DVyUlT7YgafH5tDjBAgtgYWXFh/NDvxpHQmk31ArgUXo4lmBT AT0sckuxRGBJQlG5sDjXUFax625YUjIElrveZElpOZkixYkK8p0h7mG425O+ndt5+Jh1Gus1S8Ou tVK6QdqRy3xJcdVnIIbwNS+3MqZUayugzrdkSuZZfEnVkZm8ohCbZOTQQGwsEyixvmYo6OgA9D62 T4USAFSE68PqtDbudpH0nptgqAiVDr4RcQZpnGhN4SuVCzErJe2Rfhg454gFYTGiUu9KvT4+W8lY m5t/qFlRZKFSmKLfI4v0BN9Z+FXnC5mSnzQxKDx1XmarfhDUEwRbwT62b4FawUL3hkf1hFlW3bLq Dycm3xoCAh2g/RBDfMFcOubvhhLvTyEJfsXWRg5Dgax06aW7a+s35mj56k97e9Ngo6PT3ZY/jI6u 3L4xxwxqX/gmJm/PNQlJgZA2uCIYgnYxdwiYPyyJOExPkMReCo/4itlTQ/MXtUD2bzIeMuF/Ecrx OUKpl1t+LuGEpUqC0AVVEpTCpI4iIXyE6kgQCxwahE+BVRlbnbLZ2NoxfgzDiAVuPsoMyQJo0+Cu 3+B4NPBKBpbKaxkjc+8nh1YY6v9wbSGfn5l5RH42HagfJWxvq1P+48yMv3Dpyejo6J9u37hxY+qV IYUDbyHmD80TnDN4n4aUoDjtL+SjUCXG9pGp8UrRSiKqpNfRIjP3+qwrx4kTI5txg0CrJz2M23qa DSpV2umgZllyr5qmNccnn9o48AZiwaZ9HEtgJOm446Nujbbw3+BRvsHRU0L00FWMZcooGcuv1m8M rexN/+WSO5PnvzvqhP3x5q/0y9euf7NT/C1Pvlmqzvjuu+nplaHJqbexvFtgqkh0zmbUx1Q7KCbP wp7L+3X1YZH3/s/Yz9D9Gvkjq2764hdWZ/I3uidKDGfLXwTXrgXRz6xLxcxYS3x/HWKhugiyNNxD fbEJMFKialRJ46qDA8UOH46vv+Ju3AadoGFVPL10nqoDjZW05ENSou6EP2XtM09sD8ecfywmH1p5 Nzozky/jHx7g6BAgIdAeApkjI2pfBMrLKEX5Bffa6E0WiEFMaXgkBHZJ6EZCf2VKbxjcldh8a2NP 2vHavYmKpnGXFWj8EwBV6oHpn9m3VSdFDOf7bDkX1DXmzgHWDMUoEpoGrz1YlkUU4IxAT6TxCEkV bSuVxYiEXNKQNlplfF03OBXsNBliHju0O0pxoJyigEFUsVPUKNmlZTpv2DBmh4am957MzJSTB+2h dSeK+rVDdmbhb3+Z/mrohsEjqGXqlpLaLXa6X9KdxqrfnRp/EbJOr1so/mwBIx9XNzNnMqg6IWJk yyYDNKEewAzdCAxBedAsTgUMi0gNuGJYXDGQJigmGtFH41oBp7Dsytj6Gjo5G0bVsA0aT/RxItYR +mGLjVjIVVJd7kRtYoHNaSGExxAEW5+bHn2ykE+77P7+K2cOBlyKji3lZ56N3pxcX1PchpgzyZhK 0EOpYJAUM3Y81DR87UGjRAxhw1EP/LP3L2ZPghjwWhbci7JwrINUEMaT41Qpc0h1i3qeJVG+63Iu AfpjacUXq2uGdGuGcPViityuC8qwJx7SSLtEGYNLptGU+u7a0Pzek4XyWRv1bH7h3cb80BQ+Jn9g Zjb3KlIpyLcYQoHtuLR2fuWiBgaRAFs0HCUYUDN/tt5VfXJigFYAuDWG44B6DxEtEhRdUY/KCpBm K1Srg6DwCKyOSdYcowsORnP+3qxH0bCNwwmxsCE+qByUtukVC5WrNUQsbVPwLWsIo4PZyYnr1/yz +693uJI4S3l/dO/N3Kwn+pOe30OO2AbXUIO/r6LONp7eWq0UwYtp9EIQeAK6oUX+Gfrd4aclRjZj asgHTbABCQIswCNODc6HgOpihuQOcEKra2R1dE3QmqVdHJ/SPUO4NxgvCovsWAyg+sEtd4A8uort 5GQeIdiIAmlsQv3+9+u/lZ1+D5M+wpKncmSYBb/SeTc6/97D3lI9hNglboR6zyussjk5HyYiRwCD FZnlpbPxkuoTEuNlJhdgX6Eo1Anv9TrHO7KgzslQJ+GwRD6GUVQf+QMzPFQdDQMp7eHzTY7dlhyr di9vd+R0LWTsAEFhGbaHBTb4Svvp0Ng795HDX4U6Z/QdpGLinbKjztdZjLU3NrdGimtjb0N3sT4y VGFl2R47HFl/UdFIMch9ga6zGceZmI1/NDGE29nyA012UZ331NGsS11Le8ZT4cV//ZEj2LDbSWGn gG/zat3S4gDCAc9TAiv71tD0pbwjISLsi/i3nPyBX6YPv/++/Nv1saEL2D86EaEFkuHJfvREr+qT lxvqwAUw+HWzeurnZZ9GMbKv6xLRiGYZDH2ABXguCHMISmHDuEhJ51DHcDdRe1uhRsdWrSmJBcN8 a37vUrX9Udq+jjir5nQk5deSSVF54frK+xGl36U/omM+MLPn4asOcoc1BoAaDGCQ23r5/Snux09B jMwiMqEoXD8oalHAvKikZSrJUY7UU1iDzcubs6DhEOgQllEFYqRFgvADA6su82psYmTo97/Jr6ZO 7didmKXDyOzMk4tDb2FOZ9tKL3IHE9NETb830ZRjWNRq4NgCf+v0Ku9HE2PLt6A76iGAmW1q1D21 NCP2JUVHJqbCF5OFp8wjeTrEPZ7q60HTPc/zjJROKJGTZ7TLR3LEyt7Pv3MffIqeO/uWVpX8tb3J WdCIltcSsRROQzzbY1me11p7/gJRICwE3Titf1vh44jhvG6fH4RJx4TtmUqviWq1NDsgM7z4w5qH vW202ArjoC6GXGw6xI/t2TYQBpyapzPaAEtaHgyb3oKk3TJmJy9ey3+ibvti7Y/WzaFZ1pvMPPZh Cdb30NseTtFb343D9xwh94rwsfxT+QXHxxAj6wv8h3xJUB9qbdlJoSZpwsWlhmnkSOXF+VkQCexv ALbKhLbFs8WG2APWAmqg5OtQAoNntHRvdvLbS2fiXUnPDf52Khv4dyvfgZgzSbeJJDrrZnrF12pt wpQjcYtaUXlPdWr041jESP3UsxzUQgXnEvZdFENLKUZCFHAsbF+EgloxbI5vzrIetpkfslEw7C6K 4bXEhvaUYPVs8F9IDTZiug7DVWCqYmxOXM+LcTnr72A/g/HXu2xX/nns3lPocnBhOG4680EeCLa3 +R93QvR3Ya2G4x2U5Rj08u6Pbh+oGNl/D9rEQmiDkg7VNKdFuhh6LaTkw/FNHcXZ1pn/Ye5IEoCF SRg42RRbeZ7KDDXGAolgQ0Ok8Aq2PfvmurtENzz4n7dOxpZ+e/dmtsUNhkHHMWAkmb0/UWG0oIA5 ZCPsLp2mb02PTwz4HihXL4ZhDYBfS6M9zYWEE6JMYUURnAk2UgxfPN9G7894wYCNDkgVhtTaanUe 0F5nZ9otEg59auXSI/WfMHzSXhtYypYWfl+dBYekF2wYNnBNLKjy9M3xZi0EqBA5Av/0hLMfoBhZ UyN3rwGua0QQda3hp4Z7MC0MU5ShvBonSPjivA59yhcGcx0DV6/VjRaeGkApoRWxQ4eTdf38dNTl Z+EDbnxK63jZXb60N6nrhacwfC1vloZDb/147w6MeK2IslEPtpZ6dMPHtOMS42XZFFQIweuT1fiK RaqlCvgGaMFbqDUn7l+h2AfiKB3eIcG8u0XvPXTRu+oiREIIhdALzPP0uTFzacCB3pjzIH99/JZn 6Kj3NFRsIPX7vzTCqxwNjfrrU/GW6njEcDI5wHWjgdvwWFaTW01kXDz/I02SdZwpM09TsJEJSABd UCNtOl85TeQhW9f3FrIDZeixOVl3bBICYgoDdBya2fsvaNCLAAAz0+ubPNyORgyOtbJ5PC608aKY yrhzb7tDENrVodvSknuklI7hU0GfmjBPTwB75s0pF8fXdBwejAdYJKDfv9wMQ7ZWwquNeq7fB+vo iuEswfvZNpmoHHCUWIPKSGdQOe5c/nFWLxQKCPGC6v/FUmhRCRUnH6Yu7Dzdhj5ndWw4uPLmWvnw BxjYZ7Qs/Nr62sp6AYYMBhpigcLXl1kshVgohrlyX78ZOTIxsiZ7pEZDxboaTDVETiNUS9p41MCl eXmzwFhBMRQCvNuKH1mu5MDLJx0bwOPze/5JdtDAPsDke9ns1rOx87pwZ2y3e//fkBhXGQ6CTOqM /rIjEcNxsubVWq0BvGiEKvYbybHcy+JGsm+AiOJx5cXzXfD1fCnox17QBbHdbEHfHreUf2Y3+Pqu L81ZujS/2YLhKpD91x1GDQSD1r8+7WjEeM1iqAYGSk2CeUPswuRYSTQkHxJeYN3m5Z/A84PvQIjr h/KggxacF63CrW9N/ncOT7iPBvahJkcmy+Ycs/ruto6+UL/y/E6Fwo9ark/fUR2FGK/r7CFgatBo hGEa+h2EUBihlLD1ai1s3rlf4OBOYC5Cp86Qqo0cIr3LztJ3128Ofg94WkzQo/r75i6OYKGwq//0 QxNCkEal1p8vTQ4nxlYQNsiQGY0mgZ1SDbGGSTbP4IeyWvMfm9skpQDwXQl0DIsEXdRVUQk9yYFq //l/fepmBtbdpHJsLUzcwuklG8Xt/77McHE1bF5d7MPhPJQYpiZVoCEVgN67ibkDZDRoQyUKOxq4 C5vN598BpsFj7O5uFzjC0fsrc+vOCCoRDFFw/gm8ger4+5UD63/DObnz6PH5KzrNN7774SKBZfGf vb63djuEGJlQyMUhFvKPOAjFIdLkl78iJygKUje7hW32kYsuF9IPfgZSim23tyeLfam7AzuWOWXr 210c1cLu1780m81Gsxn0mWocSAxnsXFEXuxPmGbjfy9/vasTujusPYBKbJv1HPJnG/KBQIX7xT7r vIF9sDnOwrf/w5zi9u72lX+5UwE3uog+r1+igAOI4WRqH8kKVIzLP4G7hwnXkZcCaQTKBK6MJVc2 Hn2+XhnYZ7H83n2Sjb/+gljpp2l4BzFk8M7k4s8NWPe1P++TVuzOP65c0SkSOjoviA4FvmHaUfhx YoH/47F+cSgD+3/2rjU0riu/T9SLOlTOLsSLiIWUDNYoKmK1FCHhgDIEnPkg6pmbbFPI1qJ2P3S1 uMGNcA0iuspjBI53V9oKxysR90OMwGKrZT8ENtmkB2O58ehMmykpiU1qGbUo3ppO2LI4cS1bywh6 /o9z7kP3jkbyQ1pn/vfOfZx7zrnnnvP/nf/jnHvnrlDyR9/6xmcrLZ+trH46A/rFE9vmyyKREuPA 8SXk9/HpGWT8mXGlCU4v0RnhAALGZ+gMdksuRpbG4az/jRZCBMNiZb2fXhEOiv4SNum//tU26klq dOfkn7L+6rd+Ca3f8kb/+PjMsb/dJm0dAgx8q/cJxdfjBAq11eyP6xKeK6TwOZ4RLJbwMqJFgejx 9FNp4OyWlZUqBIaGBcVdaUk/taJSt7zzf69uix6kRveQfvTaQ9ADfvzJzPTfnd4eDqpwiXH+9fEZ xeTQ6SMCcJnhlUQC/QgUBAuMiIhRB0tLb6RX0oiLNKzA5ZUXjrhCSRQsVtJ/1PLcr35P3mup0WbI iA7befI7LU+lW779qVI2wEG15Z1hqI1x4Hg/sLZi8iXmdEDAuFlZMtAPgUBheq9kyqcMinSaGX7d pYV2BifplZYfvLLl9VOje0MhDZt8/Z9Vw69emJk+dnXr2z0IDCjR1em4Ym4lMpaW8Kekxzht9er9 YTwQMHAwPt4/rUIuVIcF74Iio4UAAduWb/9sm2ibNbpvdOB332hpeejC+PjxLX+NwAMMRmnyCdCM gMmXZhQeZsbD12mIofYqCsYDBIH1obYXPk6n0xvExQpv0oiRlpaT/7utvNo1ul/05KMtK+9cGJ+5 6v2E4RawQUBi2M7500tL/cTmGyQEyUx//EPg7tWNSgyFhxaChfo9+v37XxM12ib0xc8+Xul7o/84 GOFb9+VbFxiEyvN/MF5SwFgqbRQW/bx7/B1g8tX05gjFxScPR/0hcI0edKI2//5z6dVPp7fUwgxI jAPH+meWSspSACYncJTooORu9VryxgErpL90YTXNBvcmIAHU8lk/zvuogeJrRvrPCLhPTH7y0EOD x5PV/Sv0vSA/MA48VlqKKx4Hvu9fWiM3vKcInbjaaWjE+0mL8vH5RrHR8lrSP/pTo68nLTj2n398 Mv7qlrGBDxgHpuOK12fi/SQPFDbiZukv4WLO4TKLDLq8tEeJC1ChNqdGgYHR8h3XGVHDxdeQbP/x 6x8+fnqr/ijZAMMGXJSUgVEq7VmKI6eXPEpTiQ9NCIIHIAErBHx6crOY0ND4wfYY86zRtiH7yUd/ c35rvnirgaHUuORjceT8EiOA8eANMTuFiVKJsAPQiJf63+xTsFgFmVHdAnFhY44f3b4vxtdo6+iV P37Y3orX+jUwFpzkccX18X7F6PFSHLk/jsc6hPc6BLER70eNSp2eXGVOrwIRaVa5MAGCaXX1w9+j 7/3W6D6SbV+1t8Jry8BQiDxd6F/a06/VJ2J9433yr7xg5DjEu9DXt8ocvi4y9I5gQQd9v6tNKa9R KNlbNJhhbIwnSnFFuAHqN0cRVMJfCczx0puECf2rSCYCYkLhqW919TU9U7AGjRptE9LAeHhPCZWn 6imOP7UUTqY1n6fXw4V7PU1iI/1Q+uQTujA1XNRouxAD463pwhKzOy0Fc+RZ1gapBIMfr2LX3xdk /UhoaKULkqRXj8P9a5CoUTht7ThG8nShNLinoNAQLyAqGBoF3vLqHqnAeEEBpTQ4aCCxqpm9IvXp FTf/8dyWT6OsUY1CiIBxtVBQTF6ID8YLCIYC70ruqYKMXuhcxVcJLvT5sNBHsmOdBbHU15de7Tvm 1KRFjbYjxfArWKX4T5DnDfPrI/+ugAIFrypUwNmbVcDAv6QREICL1dX/Cv6BiG0nbSd8WXDcecg2 /IM9X0jatu3+lWhE4gqLTo2JTWbVL86WeNlrdK8JJcbriueB1V2hEISFWUlgkGCJDz6znuK0VpPq A2iQ3Jge9hRk/YliduSJcycuPbvK29foa0UAjGRJg8Gzp5/euuRGQlz0bZBWKYnanHsyUJTbA9m5 oWw2O5ed8668ZOduGCbONg95rqhlYBbD59SFLIVUvTZfVGkw29GB7JBaQuO5m5ALs/ezwWp0fwiA 8SedhQ3SIG5ObhQVGht951b7Hker2/ufqicsKYUUEZSyGnXUqZQnmjpKCYHhHSIVmTySUpYUAIyk kxBSSmvD6UXq/rZYje4LKWCcV7rRfIF+sJlfFxcQY3Dwp5vDRd/qObX5Dc8A8fzdVFaxWVHIjDQr LPpMinr+EJxzRkXMSb4mhOLsZrwyqY6LnqTBJSxAiqIU3ZDtC8DmAA73WkZ6U4Zlq9KLOac2m+XB oxgJjE6QAoNqN6j382qBLYbNG8jMFzhg07joA1wcC5kyCT2/kQIiKDukyFM022lVLGrCVRefSi1j +OVMKiPCSOqt9J3xUUr0EqxSwSRuHH9pfGGyoWaePIAUc5J7BucL82oNLAW99wS5h4CLc5sExurJ 19fCwp4CLcbKWBEkrdtkIdtOj0hIocPVgRAv2eBO6gFOjUofna8Uu1S2yS5MHHn/yPTyy5rp/gBS zLk62KkYvTOABg0VPyDMQWen7vs3IS9OXg0piN0OFoZldHzL7HQPP6lVKXMVtqBMiVnAhaPOwyWG L0d/ANwwhX7XRbi9sCzPtXXSM/3Z/W6zGt0HijnjSjdSKOiEZb5TaVC0x3N1oRNA06kvU2BhvlMx eJVaNRkPAAAgAElEQVSL2fXx+kzo358nnydzwQLuhANgRDjHBRi+jnHRqFAiIYiuWsr8hfEIpzcB KQRdwcSYF+dHnE4XIIa+hdrMQb57lbCAs4zQkfne0hPd5KezVUVpCx3GwBESGudQy/CDL1OSl7Jz c3PN2aG76KQL+OChDndnh25lm7PZ7I/v2l3CKZbcA8KCqcCbwrwOK3iOea+w0dlUNS76zI4DFC5C maSHO2nmZ2Zv80sJ0uXtZDuxP27UFcWwzVhr74NYsYReNcCAeT35GdAwPlTyBsdecOqR83OcaYZz Z/b3lYivS4KM7NJOZG/7uaSH/+yFhQd7JPAguE5U1V6/d3MZVL5dqCyrJrjXVRn7ohPkwxiIBr24 h4Pq17k2uPOnHlFQpcRANUqdAC5Cu1hkTM3XhiM9UuME/0NBFwFAA0ggZ1M45IDsipztYX8XE4Eg yCoPNd5goRYlXYkgze2lt0TSoJIKOxl4Gmb/cu+RrrnmK6InOzfw9vu3T/G1B5ewLtFJd/eeMsAp 6uwweluEOHivKzP2QwWKzjG1GevkTadaxjrhN2Z+EIwhdOAVBVVKjHPnECKoR4UNUzfmhFaliH0l 9dgsMYRMPM+V00bGgFFzhOil8AyaI5prMakHAkaJctUsiiKGoYoHUq62pdWkjNDw1FIGb+cmhvsf 9TSb3s2293j8VribaL19Txtyq6kjx73Kr+8Sw4Z+LWYXW3u50btzk2iKPTZGAgNXvZmf560hHYww IiavfnUh8swrUdr2JHbXQhheNH0ysz+ZAo5d1pYw2wuKbsCF35JPilnbAMcF2xr7gE4SE1ikBDKx zjNjDAoNThPEcNHGT6Lsazo4zg/AUCV7fGHMURJAEnsfYInxpxaKayF7715XDu3imzbkPCtJiZUv 3a17RFGs8PedY50sJcbGxvQ2SN7QkXObo6a+ptPuMwaoFZnN0h2yV1iQyiNp4oadt6RWmQgCog2n 8/UK1sUy2lx3sWB5+nltH/AdpLgIpdnFmHTlhTRqnQGWa/NILaysHp/AV0enLloJ9ldJLJFEO0ck MlceZF3qJvZGqv5P3YWH1H/rNdXdttP3CdsTPIKVm7rje6xDsfkKaIigDQMC13Pn/qnpWHRBYBAi Y7pz4ena2WJQwMA6qkMAZLSqo7Zd+C9kR5Tqqbtzo0W5ahNf8MsjvMs+yLYXs5ImijRwkBqcXleA 0DgSrYHnuHSYRAVlQyMt7Ou9/CAD4xZL3Ct4djees6NbKc3CaKpovM1JMPEFzwG6lxQbO6RY/dBG cNHUtFFY6N3fuM8YpOEcqByWVmRc7tM4URKDzNqsIK+qKw8aMHwAGdIMZFgaBwZoUfOgGqHHv7Y2 3AWo0bBCcmj3jeGXnyYTFAEEyXjABeSG1fsg+2wtHhW6eXd8bz/uvmKhHmpCbBrCIq9K8z2vydjY jkOHdqjNDlzHYMcHsB/TWw6GTRPxebWLByLJiDpToY2uGs+YKGYYFVprOUipidNQ1wROTQmYRKUo hT4RCdOXcJUiYfgZdSiCnhuB1oTAbOckMbQUKYlRLG3Ia2ljSeZ5b2op9+tnsBeU/XOQRwgtK6Fa leZEQqyUKmfCqeY7MOu1+D3hiNAv7q/xCFVK/O9KV4QqF/99p2VJ4jsy17mXbPbduwNqH2buLN/p XdalGLD6DsP0eMQ/xopeOXzHyLmNSQyMDtpUU+TXq7HHdocXSPVftLwmg5USRYw5a7nygOwwsRfy uBHoyXM5AwwyNzKCtZoAHcS28Iy482HOIzOg60fXWNGVJ9RF+mR6uSenxUMCI2RbGxpas22YIBVU uu6UIr7QFxhVqZj+bpSh6nxDwyN6ig4auhLi7Y1kthmKyii2g0FwyD3Qp35k6KWJ5cXGVvWbjn4a 2+nyeZFgyWrVxdIKEqZ/1jKDGGw89+DT7Vquq2s4UbevTu1gOVI3ZJnRam2KC9FDV92l4T24v92g A+r2HdlX93xd3efG9JYICwRpW90Rk3CfuteRyfc8DzXcw9IMLRw5+iy2u5Ikb/XeVIi67VEyNse3 xoMZgYlg1NA4INkq3gXJy7DVMaEe549IUCUnc7QzZHBK8YH3kroIr3GGPf4GXlSz/TUQUYKYkQSM DUNrBAZdVgJj47BQKZpG3qpUO22CmVfbu9YJaSU8biUJwEg6TjcNyhmdXwrj0g6MON/kOR8aaQiT MBm8RvWH8waQERan1dZFV7D+fCm7qJgAi5yoK9s6c8i/XCeG/X5du9JbsbYpl615bSFwPZr1/UXU h0lPsjV3qpDUPU36L3kygz29FhxSLXbEiG60xLOdboEOFmnRLDh+dZln2oQUuFJPEfSmR5K3NezY IcPyRlsKBPmvNBnVaCOLWn9YqUCzWofiMQu1finMmAY6ZaWFJc+SwPDYHpPeuvY02yPGm0QyB2wM K19F3SHLduWo43fvI2C6VjIilaL3aWI72vjZWds0Jm/Lfp6xzevlQbZZq9vbnp2te7zKnR7zj1sd toZi8A7BrELOHfMwVGY7tMY0Lrx4tD2rflJdBp1sTQ0oqXCLJpRmEraJ6ZjOJAQWJjTcv8GBSYd7 o5BYw5Sa5ripXWzMoyv5YHEosDBWmpqIzzeECwWjN4MN4qNn9WQN42taPKq7au2AEqcgPQW67iYp 6m1v9Rjam5PaZtAuLkvmyqGVFtJjTmgtjOGFtz1rR7+TtGuRxZOWS6YF6Q5JfZ+1tRCUJI7uvZKc ydqGtFkKePq4QJPbBkn+nt2XRBcsEOjyoHtqU98d1mN7ztbKNdsXS3OvtyTBjkFdJTNSFMETiVna SW8Sf4UZoIXWrcGyM+yph5DOSMtwuhT7Sbh8CKdDO0YAEwyN6klFDr7h7S9VQ0pbDrqD7nKAyXKu a0ha+1VEfGsj43UZiXC42fuF8Mx0IgyJjyqUwUe/ZdtasIVCWlIlf+vLUmoAfddJrokYCMg//3l2 sSh6ht7+shyIN1z/QmNj/mjjFKTZ2z6gLJeh0S/19aQzvHs0e0UkLrb7prHmiRqh5yvvbs0qg6jr u2X33o0NQz1FkR1t9BblqLrRWXWr/d6chutVaGNj4350ajiz6qy+8YXGPLBMx7WhNrHYPHom0MF0 NL6wX9288d3A03a0tw6pLub6raHu9qOe+PYLl7rnsteFWMzOHTnruTALt77dzi2W+DyvaiKvyocZ 7srX59VpPu8ZDocLvQ3ZIcUJPXPdveVgTXdwxXTAyS+WsymRyC73Omuo/EHd3JAy968MzTWcmYIp IR5ghAmJgDwZ2QgePDSytiieh7MHzHxzZkZr0rG07U29thQAjDN43cqY8btUc4QkakC/ntHQUMOR n1cqhpfe5TmNlrHeLTDzo4HxCxzoRqukPVRW05Pi9lTrIvpxwaGrCvn0C74e7BLmJIsDjnN2AL3D MiESj7ASuHdUWORRlqLBTTSsvWVvOeUTh1UhwF0sDmvn6eRHIoHvp0sxt9eUw3nZoskq171l3A3u AxU9txtPR8lBKlWf0tijglPwArBY9Ltls5hPQua8geXJCSq+lCkLStPN4bsvJrQfG17Zl4sNBmd/ hQ+fo4lrqtVymC/3Z13sIy96a7d+dBHf9YcHVgX75il/jQ/xnf7QsV96BJ9L1Z710W5/k+Sfhpff UlBFNH/n89i/7nBBsY602OEBxsYAMtJU6c8vVNGYhxEANBJQ72BXnzHTXBNKZ7KTz/MIjzEeRHcE D17U/t+MjqsY7P0KXb6vQP+mh1SMR8Br5oekyHK8hJmHHpYtdAIdl3PujDBCX2t5QTNr0r5Mos6q s9uLlhlWtMQZgFt7ihzFJJt6yrrvbNSlTJ6d4Pky6DsYhURn21L4AIT11JTR80kSSjHgFnnBXpas EqJESjbzQP6t8tOWO24qxa2yqxHZVsLCMaUsnuLDlBtS4LdWJclpP3k7VQI/NPn6qCoSvXgvx5lD PdkdkyX/RyskW3Da4Jkk+iF1fU5l3UIlSMdeHnYWXIkt2avzD98bMPMVYNOqzTAVdW8zzWbBCzmc /zARO+8BRFBi+L23uNmkwGiq8L0AUJB40JqnUcBZ2QFHNpsG1NB59SQHhZmXQZ5UcSaCDyc0xlwb Q0bY3mtKZDvNvncwyMbBUe4ImtIOsNThvZWe1HGuJdCsZw+CQA3PeuSsq/72kNut+NVNS09SQYUw pxSK1qKFDM+jPrn/0fnW8SDM0NlFmlhDpzL3tmN/dRjb24zRHD7LqfI8N807XoYfpZDYi9C55qau CSsj2W0trJywXiwbO3qKTAIp3mZFX4HxsB4asszuKGrw7yZkxvAnIyBn7STzZVHoztGisSSE8yRW XRmrQ1XeqENAsZ2GHNZOUaXI6MEt0TPs2iJl7aa5nLL0ZGeK9k3zyB1Ftzg0F0taN2POmJYHVRka XikQIThG1hyNNI1XYkMl5NzXJNgY6IE3X6jr0lwtr9kwJ0A7rngKrdURDowOao+M+/IFCJ2qBAZk uOhqUW7JImauQcc5ahy7UUDlxmLNxLQQMaGV+B7HsG1BHl+r2aJRdq4E+MrPZak/0sASIKe1qVEL C2k1w6hmSpK6CcOR1q6OFEzaB2bWU1R62FCd1BPje72FFOzmpkmbN3TnIlSPjLFTulNaNklekqT4 WDu1hfwejz6hRoTPkRJt9IA7OTAl2IlHj4NGwC5CiqXFIj5twqrHOs5bCdSfpfZDDmcFzoFw64QU sB7X+bZf6O8CeGBI8n+Sm64jQW2dsXgWNFzfHXP+5VBVoGBNagTY3KdPjfDCFzxhnigVTG+gZc0M ZsbeqA1SlUUu6zR1tp3XT2eGyBc9TOelfzT6BnevluGIdcmGcXTd/PzuEjBGdIrh61o0TVT2GP5c I0K6/Rc+zotsNtqAaFlU7ZQS9KEtQhx01WeEmcJO02EkvNWLdNAomEqJtsAKYKGR+PUEGBzo8WbO tsR7lGiU+mYcLTDlnCI5JfmNyQ80DIkSzDpYsl061WX9mvAsS4yvihSZ5tEABiz6SpGiEwq4Kf0Y koGjTGJI2ZvQ79RACiq1pCmDtrOPX9HEOUA2TDSQWB4qTIKLB2V323kf3DjDotnCuRCSHf6Hy5Tt hMIs6MCMVCrVcMz+wsv7gTkgwbMdBhQja0TGiH/jCxtZ58tLt9z3J1g+tMNsQWmsbzw4kbQnU240 gkt2re8Nqc7Iaj30rajKWRk22vhaJhmB0xwdv5f64gwIjMhI6jcqdN9lpIae9tjNCvtXqBXDNx5y CdYmOCZ0+6r/LEIDpiy2JHaSm9FMUZFFkbBI/cL7FPnVEIvRZAELXCT+7SFBLQ97i3mGccFipIG9 c5KBliPuRIbu1k+GEztVkRe5A+hlDpZkjmRIDaAMnTn8LF5R9GSHmie4kwe1UIkMezLHqKdKRx0n k6AZu/jqJtYcnZZf5IkNVBsgI0lwKcau0yXrco05iJ3IEY5QO6Wmuiakvmnxo1tDQ3j0sh1znL9Q /B4hIw4FQ7TEGGFoBE59QZ7DzkodNZpjnq8goHI5BRJDuhaGRInhjCphqt+3Rr7P7AuDhQpqdmFG sSHb/6xWYixLv0MLuSLKzAdNKoXckxGJECe5G+2a+dRhRtw8s3+48dKVou7FYcoXJFw2r/hKcf1S fra3hz7+gL270htGe6f2Hzls3m4Hh4CN3TzrHnLxcn3H/ssip2cmA028lL9xBt+qz1ipIs+uGWbz Qc55C9mtkTuLkeYsnmig4NbWnr+Rb+BvTijRdEWPHSQYhVmasrErgV/+ksomsa5399a/le9dfgTm umH/+JEQ13++k33Ns//f3rcHR3WdeUata0xJIn+EjRJY8LRNYwr8yESWyni1bQh2xZRRHzIxlZkB B4dsgQvbGmwPNRK6DUUrpRIxciiSSBhPlRmqoMpyUvvPDCE6sRGVFZcMmqpk1rUSorRjwoaMvMaJ XyAKi8qe73Eet/t208LiNXu/7r59+/Z9nHvu+Z3veb6TaOa+L1ACgf8X3YkXE2dHm1iiTvwuoejs XXSZUYZnA2kx7dhZ4KPJta+s7R1YMJ9GJKg719zAPyW1C0B64wumLao9OajZh1yC59nCPFsmE2Qb W9ZdJ6sx4ZqVlK5I2bymP9tZZgsBAQt431G6Ib5JorZndTtQBtoHAz0eiZ7UE744FWg5UQf2NRY5 J/dDBh1YG4tKl8NSJs3jQIxWJktpD6r+ScLwSgy5FP5mFozUng09HOrQnqNWkNY2r3ErK7UDN2iD gPpAy4TNqxF4Pc2ak7bAmcWCNEuLSozAM/sLpDSidfJV8Ja3tTWAII1ZHDHlz2oCXAAyqi1lA/MX zn6SNA/Aq4ZmL8TeZqPpcIVs1gpWgnx3GdAL8Inmzi6jVuz7tcxflsm6lb6wbvieJN2/l6ENIxgf hCXf5dSdL/Zq3vUq4uR1uAi2gSADQzjVHU60D8LNKcnR66ajJgI9JMYDKzpZBfTzTOMIQcNaa200 QltbCnLXlocJ1jGwoeOHFs6SP/o//oa1HSV6avXPdwLmgZJHIAVzVAmrdSNCbVvdYUbMglSzxlSE N7Q32o3xktRsVo/ODpAHl6l9S8sxkC9hv1R0bJr4WF8t11jqtOMeRd2CRkGwUMsl9NiMFSjHjsIm xAU8qkU54ni5tOdt5qPqtZxIGVLajXiW5KAGyLqCfaViSa/ypp5B7D9Vd46R+jTkSy1WuvUC/Aku iFZn0SsZYIE8JDhaYpMqYg7UjEFCKerecKr0h/j7kMdja7zkgGGgxur2yl7f9fOk/I8wRCFIZjiw IzXhkawVvC2EE2C2UlURlgQTjE00g0iEh57X8Sjqpqn5BN44XlJMM4PGgloqfEq1K2JHmHXJv+g1 oRmb9BLYg5z3AIxf5TV+/XbW9B81pvUzM5htMGBhMTvvO5stPYW3OBmy/0Chf6dKmKCW32RUv4x/ kTVRZgLqhpojT6gkZceDIdmq5WVKFsM5fIClV8PGoEzJ4pLUAerTlQJUGHKiKQWeM3omwbPWdSv2 DmoN4CV4NG/mgkEcDpLcNaE9G6NkeFb7fYdvT/X2knhEP/a8T6VRmFdF/Tt94guBjlA1Ha9gIUkG PXBqI7P3OrhY7ZGAkqY0Xo1ai4cAcG0DNZbmAYE3Ng+flGJasxAF8zH6U+kc5VjHheilcGTkfXiN AXruQfJwaL/qNOk6cjMA6F8GUbwIgvQG57kMaJ1Soi1DnOX2EsjHzT7fpMx+pNOLaaDjD6r++Fnf mk0EAePoD6j9Z4soG2GOQVKS4Qr5r3xw4K6RKdbMLfvjUmcsIAN2WqmUqkPTQeNslFLASMjAdS2o G15S5Jyse+tUIYSi+jJHl4kFXtravTy2lhbTvdmLgFd4quj51aVPGKV7kbt9nFsZRUPOhCFaWPgD uh3isF/CpsadGPC4J9/AsUXcUWTMsz0rtTH2p+ZSpKio+sUe9hTL7CHEd7PXLfhLPOICa/Wy2UTy 4agu1KqTq6kpjZMaGDRjj9+odX15Nq+aCiuONUxgD1x0dcYEJa0P4yqFV0X+j7+TLCkGzctMwVCn YBFhAH/XaQV1l3NNrUSlgR1NY3EzFOGu9vsc7LsjWsPI2u+s/r46Km2UElI6/mzsoT4GuVlKrY0T Elr8fpIzWGmEJp+IOp/va0egyzJkUX2k4PDzJKcFLMmRJF4ieXM/OIZg57qiuwjwrKD1RbqhHNj2 uN0noJpOsgElGLV78IP0goRpTI2MBHAmAP9I0x165hbb6vUDP2UvJjVB+OEEOcexq7a3Nk+7qQW6 yeZ4ZFjyXCNHhozF0hug4mhGRBx5gzZEOxeOqA4tYolZOXJmbND/vc3aeMjrJPxmvqF+iISdye3Z Cw6EOvo6HRu3AmXOUV00O25G+FpXQYT1yGSOfo1exNwBfKLP4erLWd30tfTkbnAEqatDRk2JGlKF qMV7MXlq1PIDuKvVksOVtHHllJ80Kgf3vV5ksibohUwGBLprlIL3Ru0cRU9pkJrMUkEJWKlOn/sv 74kSXcBracks/A/CPfiwloIxMCMTkAEiOGnNWyg0wR0vM20gwb6NAPXdBfys5S7rj9hANaQdWUBt ugAoztfmkiRK1bvAYO7kzfcxeDfJPZC0WYLa/CTrN2w3HaAOKA1mQ1/8IamtqB9FVxZ8UJTc/E/T IOxxQY7cGef1/808XjLsdaIhml46QONgHdsEVKMIVXm17kah8xGzdB7W+bZeDI45sEundFFyZ8Kp CJqc8t18DhHJMrJa/bb4qNE/atwfzj60LAw2dSkhTQAsfprI7DdA4gn/A9E4vcY3ISnE1ovM1Ki2 TdPhAVbVKKKPRBzOzmebJKRQEg9dTYBREB+a6qeKntXfFbAN4LchuUJcxAHq6oqgMPr69uQiBsGI qNW8v8Ee1q47DFRvzxPTSboW5Q+ShAtvFiNMwInoXjCCKqEdEofcYkoW0eqwzIsYs3JJWD8nyc6j 8y7QQTeN8KvRY+/FqB9ZYerSbSur+3eRR9rL5XA8PtjGeHdqzUGe10l8qAW0AylV+EFi6YGXZ0Pf rQOGUEP/UHPS1ywwRA97YgKSjdu1jU1dMrOXHpWvgSF+FeIU2YiV8N/u72zWWbE7ZLOGw9QcLdpe gOq0vGJYQYI4hhZk9ODS19GCqhkL1N2uIohbEEgTf2t4Tpm6N5iPGX9GmWni7FXRJAymXy/eA7Sx A7hJhrKFqOY6yEFdcyDCkN0GnpMr+hB1HGmyhuJBfgsrxV4b9L4Nkn6ybIP2FZ3ydJc1AS0IOE45 AdwgIzmarMcRM/6SdJfAw4A/cUCyB8X2/igTkp2O87ac1H0ucsJEQBa94LfaUGuPRJpZR6WFGGGM E25yZXxHR1kQquMLHlspobikn6vSN/WEOhk0OeFDqwbrUoL2SstaZ2bTWtZOvHasmGWj3A1KrykY PKCL+TmfzIYvF1iiCt4kVoU5Bv8yW2ssu3C4Sk1U3n97N/PZkqx9FjKYph5m6k3tWpJaV6g2uoXH BpX2yIaY8ucFJqaWYaGuUbw7zytQN4YNBJ5rsw3qitl6BYRwYtGTwYLIPZBW635fhnMX+okkxq7R jGeHqNF47oDdejYeyQG30yYh+xSqq0k9YsRCbrVO+1Zvr3Y+YHaAmukH7B4JifLdutXQ/FX1Ov7V Hfvxc4hWgZ0uEDAaWGg75ZNWkqSyzIyMjan9AoaAGQGGDoWqXsT60wVyZOd5nUSGjcuDKDtyqygI 09mtmwjyn4zOwuoOZVxBulXAQz9Hfj1o2pm6gq73z/ERR0tiIoSarPuu0ZKUwzGy4bfaUnxYq6K2 QXxAzAPxeVPafHDUMBvhLt8kA2xi23p+RmWqWoox4UTngacTVV0szyalWBg7fbSTD1f/T7HRewAM toAFieJWqW7d4zX4LsSEMM+yXgAICAPeTLvHOErA0uRYUs1xEYe7DcIAEzGNH6rOSQf0eBONDg1W Wt10XPsX4UcvtUjQvZ1Ct3uU6ISvxd5GR0ZXO7/IgU5aieAQpoAsD/N1p9UTVd3/TceIUf9Gjxtz zEs9Bq+fRR0vzKJ19bWAloMhBCErHD+J8wxseRh+pklCCkJxQ0sAeNjPMEtrTHuDHLWiOqgtlmMg bQ1xhhKvsHgVkrlcq2/oXcLzLURjOif5PsnTpcfZoe9Be+lMchCjZEANr44+5wRrLU1mSXAri1IY 9x8Y7x6nlJpWwtY7x+OI2ZPFgUFuGbSqhB/mHJgGEC5xQUCroNhPr9caSNh24PXrJp6CHpNGKjwO OxygikERSRO1EA8UdmsX9SA6kSfjbKT2mXYcFGDu9Ki7R/QKkcbYKlQxTHn9For7C2QPNqyLSTJt eGexYfPjgnxd4dQdcPp5AY8qCNKYhyqANEckJYzrG5aswdweYtHav5N+DYAxT0IgVQASk1uVvr+L jWoeeNdnseLq1ouA6Ak8v+WUPVswgJAF6DosqQEGRIZks7MdjaEYLmrywRHaIXL/Y8WaC9xNwnYh GE5OhjtVtpxt3joQkL5oxbMxCfnnnCYDN9E5qijB/KKNNq9Ay3SACh7o8WKiOC7IxC49M4Qm6rQJ eBjQHVeHRAwyKUqwfr6OMec4f403ann/APXsgXzCHKIaGAZmqbaJslaan+qALeN8ttuRfIOLaTTa IEAVXVxgC1Wwydg71a17xIo5BGuAQlFDpmqhZDDq6pP0s1v38NPwRDnJw2gi6qs7p0Unb3C8fsHF NwdW1z5BtZ3WUvFLWnkPp5Q6QP4dGeB4rf4kd3Yhc73w92pxFaPYN+nYx0an+G2kWYWeFQWI6eCy buh6LDBEV7nG15DglM2DUiGWakpq3xiaic1cB9xwx0f5GG3TNumktJ1KPZli7TARaIOieUtZdGRd Pg1IHb4o6SHBxcb9IvHkQCfTLBsMFkRjGTkmwWc11hfe/qHUD7MXLCYsVBpDgRAL2HhkfRQo1tME UHiqLVhKpWjYFj6h66iOCyEooTxuhBOJjI4xtG40QbwHGggpS910W2FXWy93AjQThhB13OWz7kRJ rL20V1jdE6xZeE3J6r363zqSj9M8CkxskqjBpJWg5lY4+3c8Cf480R/Q+GYv4SIWJ/RlIcPH5s5D 1VwN6SLbEyCVsL5t4dfuMoIJ+DJdjoHIKM9PofVwl2MUiFFmAbv+eX4dOZcdlVpaso9KkEk/TYzd c/6lnywd1Ue1dbVpQ2DDdQ2Oisv/ecRx/8aDgWbFecVtUr4/06TMdU3h4X1eTKex1Enb++IKpXmX 6WCXUmJmBhxz7Yypa+fm7O01R02w3yTYghuSkvqQ+fbEAxpt1bY8OLMO7Idi2q40mXi9ZbYsog4h Ngi9P16alYngD86dNLJuomMP53OZ+ep8kcI5j8QIGDWQSZ1YprPUCDHIg3XfZBi8qLnvx6GjtX9n FF2D85ArqXeegzdDY1QDyC/p81hEmGTRVoLqoFi3P2Afgvq0LTGDwqQSwyww1H+pY9TuZ5d8Z665 yEAAABk8SURBVLN5OoUBQZ4kpcEDdKx4o+zlgDNrPdLCXybQNiX9ke6qLDL4QeCz0pYs64eoLVqE PBpP6iApkqKwiZWwN6l78NLMWZIFaSp0qRLMVOTb+ln41LVzdxC8BtZGvjXLHXioq2pq1i+Ac5Lj CFYUijDmHI6qGzEHVbNG4/T1Yj6bEj7A82hB1XNY4cce2/35EbAZ2Bn4AzFLZLPjMoo/sCYWvOEz x+Ced6AAGXMCTKnqJZeNCH3VlSwU63x0Yg7fTDpcj1qz3KBvz8MaCCXQExe1/c77C5/HQkK8vGun F0t0P9MT6qBgEKYchEElQW53SMdQNHK8XGmqpiay/ddknYUjW9Vk/yaqsWChDlDxTVgUmW2QX0pj nPW03cczFlRY7YnG24Q0MfhSwynIt5IWp2bdVjV/IvG91OFbuLYD7w2/CM9YrUOX3FaGQ/rY6LAI ZWcenWm6aCG0APS2PRfPspP0UHg+wFxGz2sLVMdCi5xwTuQlUczAE+kRtIF0ckFVa4htwcIJDiBM hthli8ey0iwUpaZxgELAzJKG0qm/u8MVIdh8NajgDLEXnCdzDg6hQF2I9h4NsF8KW5J8499Bj7aR Cr1wbsgN2gWCo54W8SOUL7olmU+RwEEyLBmrX1+QGPlIDq8QMPzUfT8uHFtRONKCGnteUFU2DAvn T/jnwaLJRV+VaU7RwK05aOfb6Df+Z9S2dQpPjnols2NhGxSU39YExurIkPGSLds5fi9Z+wNHepPh 5M35Rwh/U9rg6GT0Tqll3FQhMsVWRq3krl09jTbf/4B3MkIR6N6owATBCnvYGwFnPEShqJ49udLR vU+xJGXmqgPpikeudUOTgLh8CB5PG+MMeO44sJvUc5/m6AkgC4Qjyjczx/iArHwrSGswXpYMi1Ky paC6udl6tTbv1jTmBN55jQMciio9PZcf7/gRaZ8eijlgR+D7a3bDmT80DglMl3CIBUG52nnybSxe BfnuXoxHh5aYxHBRFxgQi35ci1J6iB7H0poVWnNZQoSWkS1kKEeLIEP0Sx01yXVkxrrX83gMzTIc PzQ5KVqKNPULer5jl+Gc9Ms0167Una2eawaWLSUOUE+qLa3d5Gn5Rv51Nr2EO83HQfdKmfjvFqIw qoB9mI2+SH2sxao66zP5neYHq+31tgR4PSVwp6gGAxQsjP0JHj+d1Rk4ldCsB+PL2lhsDUCkYOw8 GzRRugH5EWxJ6VgdF3Eo+mLH8V26HDp9YFQpyUapf2E+T3nAXHqJKjbt1fIfqvDPsujm7dY7B5xG LOy7hWQPOAqYxzkyLgLPhpP7m2kgIRTnf0G9tOsYvGVO8VezPC6fEOEoKwIGnuBCvigF1KWzGRAe 3CHcZrg3MY0ofTsPIw46Hsy/kCaPrOuGGQTyJX68h8lFxX2+8XToXhyCvqKB0RJoTkvBJHje/12m INVGAxloXJ3JQFGEDxh6HEUO6pF3HVJtHHyUAqS3TackZRd5DQdyS+wxcebvlN/ToM363ga44w+p ZwiA+TOlvksye9oI4ZRdDTvQfhJ4qGNRPJF3wBPhpsAMaYAQbPI/8Im8NFvJlkBuJShNO/WYsEsv cozvUn2H5i8SH9JhGDII5xml5hSMk3AEoUjUKTcpFdtvE+qtNveyoTRQqk1uE818rra/oV2wrO37 yDGSCuTBLkoTjXWg9D5u8jrebQkPQfea/wqzd6ZSkLDHk5Tpox19KE+hIhaE009WwziOQU+mf64K tnk3PCG4DsQSbyAhIciddZVvc+OdehgSgqBPK9yWYWhcZPO0CRuNa3/X2B12RIsym4lFms490C5Q O3mYZhUWPMgLA29lkVbabEdyaFUBRPgie+fdv5YFGIBN5EgtOhmiPiuoyDmakUPmBusbZ8HGZT9/ FWQTGnS3V90O5dPNkfg9UZ1UongO7zmJPeFuMg+nXcUV7YiqNKeccA+tHlTDiXu4ZXJ4KpYpwVKp 1b0FjLVG4O4iZfMUqwY6j1xtg+aUUpJmIuYzvJ5y75eMCJ4e5tHLLD0wvGk+WbbUcc2cYc1feT4H AgmLBvILE2Rc3duiDRKeZ9isB3HgqkEPdhPOfFZPaM9x3qvR0yJo8iOUdSZe9PTwqYDlK7qfpnBY fR09T4mh1vXyxGGdHcvfreUTCYNcC4Dhi392mYSTOCqcQ8qxTbnKRDg4191hY/R8So9rCapJmrn2 uCCHbdRtqJHztkDOijifj14ezzRs/PK8kkpC+HDJ4xQYhHgu74qjxWGyH4lPFGKFQOXIYT0HOEea r6P2mBM1b0icbWnWrLvJy92FMwn1sz/Nie1ZRrGmnpvgsFpzDBRxZlILCWhQM1GGww6td1csIvQk ddAqGmHIG3DijUT7/BybkzzkRHDcxCDbeEID2TMsELFazy3Umu3EXXqL+pxYklgxTzV/VDiEHsst k9UDP62d2S5pVCk8eDv6BBKbEGDHLyQyo5RSboAcegGPv1Ena2A7gbrHXW90V2c84hXY4/8aueYA qzRBaLxUA1t6RuEk46oEo7+9a2Bg2rRunvRHHYHO1UJg+P67Pz7iZIaKJOApocaftdzDilguPmpq uvyoqbbaZdhrEJg8MhhQJ3luSjPCz4zg9vINer6us49kYCxKWhYLMiX8c6HjF3FfZIxaaDu88rGv 55rQNii5A6dY8mRykFuiAuwHQaD1ZGxaWk4zyT9ZwncNVzRUT6Gt22wTdbrlYUxZPYtEJjhJkHwD 2xwPqGnB3fbEZn4DyXmZeA4Gcn4M6C44lIExzSxiF10p4XHmK5uN7kSADudBMyNikuKoRuZhtCQK j7kkBkglA46XsqpwRsc2UiW9hkV5PCANw3LANyGfI8//Bvvp+C110plUsm6GIYzZsf2D7lYB+20y RGSqDsgXFQUMP3UcW3+fzWneh29ew6X6rsknwzGyYUgw/bkfIU01BDYIFtpz0uPhAcK/GDhWIQ0c w0Ckl4lkQTjriBWFWKSQF8o01opDoCrYWWwoOm/8ygf6B5JNgTTeSNJssWWZqN4DHseEab+Zh/jx BhEXENvDxqZ2W9gEcT+Ze9N4MTigSQbzfS36oWRlzUu9NH+hTL9q76uaH7xpW3MgxNUCgxoV4Xom H6GHdjt3uYgNEmnmYJgMEHYzz3akh7KPeAFFkA3C9274+03Jsxty3SjAPDVH4jyKxlEHw4oDLhf0 4eiqEu3YSpLumPqEh7MpeoFmdJKzDFHhMecjKSKu4WpA3yqE8F80+CNWQ8WiziQCGNCz3vEIQSJr EWHQoX/3ZbMF0ChNEc4MY6XX4VCB1Dk3MUjIpDUnfzfJXOyxi/Yym0HUmrPQkyx3xnRx0h5rZDhH GS5Bi0541ON7trZB4a41YXzUuescalraBSkEE2R8yE3c7aLrtL3O3mwbP010qZGfA1rbuK2NRl2r m+yJMvz4pc4428M7YSk44FSppbDS4wtGHOLYreVGzUaYg/GAU0/zJnKsMKv19Ol5PEc9pBehtkwp phsmSFK1Opxo4+AMSRmhl2HdNCQJtM5YM9GOIy10x0ldvupYD+nKRn0ddSpOPwK0QBt0ITNKPUcb k4WBumevmRhvJMdQ/9z94z7FLhRjwKkw+ohFHJmtoXGEfk4SGTuPFjRkZOie7dudlPRiQLOKIH/J HVkR4UgaTuOxsuFJWTzVct6tN7DDSqsp2AYbr8RuaGaSdoygphzt3CxUPzdhhhf5Hw2a1kJxMJ6X a+jRlZ6Q+s7seTHgQh3iKMCrtRUVxfoebtKBEx/zYppP5Hh3k3hUE1my8HKHBm3dw5XbT2qw4i4Q q6PKnwuzy2rJbh4y4e6FA2Aw5atW0vP9Q5x4HBUocJp5q9FaNvEsq0MU0JJrmPgm7KRavbVFiwM8 wyeWKk1nZFXEGVOvrlI/mCO9v4lk5yaZy2XMJAfLdO9U5w4Kb6cH64F3UjRonk6gGITtW9i2Gw0M RWun98FMqzBtfR/PigQwYbD0EViORCJjY963/flywWUOk25shaVgjhmmtkhKt4WHX7JgwI+++c1S j6aw2JBBtE0sgpi7Otfx0t7HVzhYT8SzbB7zNBan4PhR48GFHFEZ6gg5BtDz5t/F//g8EiGQDncQ vbpDO+lKV5zyFVqT2JSmKKLgIwuCDDsFnb6+VzORJ+wwwLtGqe00QdNOrhRLKMkl+0J7MSt7AENM nbvP5FjHpUKv5HYm7YQTeKyxmHOP3Et/tJ23go9qsm3iIlexe/CBtORcQBxMKaZRqEoAQ6OcPWtP hawxqjIP0bPAYyQ7NKvdR9/AA3kwwXR/UhcFDQAgTe2mg0sAw/c7cbI9jYojfVHTd8/uiwBEFEiY Xj6a10C/05JHtzvxTxvmvJ3J/9/QhiKZc/zGDZmWOXa//v6W/kzLE0V2LqC/+vcMHNNvD5/TMuf2 co+GKZD6eToU0ge3tDeGdxiAiU5QOU/LE/NCfy6hK2Ycwe0lXY6/s9sSG1TxVKkorcaBDZl+vEcn F/vtmRZV7P4N9YX3dTtfEZ/CRPcJSTNnNzzeprpgqCxz/UVwmf6WzIaQVXyeeiSqPvs5i/4mXb6X 8urh1+0feCS1p+XoPMsCGzODKM2n5RLYOLMFrxGu4L3tozjsNZ374C6+x354ov3/np9vvnFJM03M rnY+0R6KhouoF3XPt1N76Kf2sHdBhswkaZjbprluplVHSgDD3/YMzrSnELG8yNzeIGhlQ3OVmamY nBmR8cWZcF8euXJupzK79jJ3myxNwWk3D3QnqhMrEodW90b9LT5+fXf14cThn5Yr3pWkQnlSRK4X ua+emYcTiQN7fd3TOjtPqiYidn5zZkLVQ/fFvNucaFyROJsYmCh5hYGPDr+44lBv3g5RbWfRzxOJ xOHugd68UkTVS9T1pg0kVqxIJFas/jh0glLA8Ec6H1HC03LV/uGtPvqlv4hrFE18WzA/MiAjJXxb 8YKK675Cdxbxv91PFK1Z4fuF+5ZHIq9YkyXWbHn0mvCjnpBvM7e622w5HXE9shxWNNMHCT29UbhW 3LWIa4JPWZij7ZEiYuEWPVSUIlWsNxUeYMpOK3mTY7pldmfOFPaQgmv4hQUoqBe9Nb+w4VsuAxi4 y7vTgWEcOWJQUEDLjzg6eKF2Ydey/OOvU+HCTD2JIvVc9tHuUaKgyss8i8grR/gKIvQUipViMn8U XCESTFHsReS1q6u74yIFEYUNUePZKVfUz1AulSt0UpPo9/I3CAcszr+lOAbsltoOTKNi9pEK9Voe Wi7vU6/lJFBlC6CQN3e4RcbGvy6dTOcq7vYa06TLUcYBV9jlSmcom5dNjlNOmkoec4WWXJ7DdWqp aEdV8E9JUYqgsR/EqT7LNtyl+qoAmCimsdHhF3rKPr2N9AxEBuz47pTc5E1L1+6Bl81ibpY+5WpJ 5H1/9jNNlkoDg2jbM5ZP0EJ9LV/O6yBOqT+z2RAU7LQzBhzOH/98xQ6qbImhrM2TrJ0b3qyu1BGX U8CIfSYlcNyoSoi6bpTS9BmvcaUTXREYWEdn/kyBAegIfAFIACfL9Td+jhRoGvk6hzNt2RVmkonp KumGQ/oa0me5t8kfWw7HUDSy9Uif4g3IKfoqkFmYj9I0Kpbjtqxu+HYO5I15gpX+2mnDCf8jP8yY blUqExh+SnQ8UlHRh2xDKRwAiT6w41aYD7yOhISosHcjzD42brzbnLvoqNeYYrpRVC4wFL2ioKH4 AqJCoQCWFcvNixYuNDbmI8JuxcUdYKO+EaaJmGK6Ik0CGIptdPT1IRwMFizxporlsx3GsDEME5c2 7qw5/jdw0jJ1yZhiup40KWAIP7XqXtX4L6vPsFo6r8sED1ivOLJz586anZZq4F2zc+NOeCPh9w9q du5TTGNkJAZGTDcdTQoYQCOXfmTZxGUCyeUKly5XHJn942M777tPvdXXMX4R7bxvJ/51bOdOtXHn gzOKOGRjiumG0qSBAQLVL+dW9F0eHr6sX5fVp+Ly8FzcBGuXl/cpUByDtyENkGPHjhmkHDt+369K z88XU0w3hCYNDPRrLP7GoyhNEeH3sGEbw8RDHtl533GCQSTdd+wHaqnYxljJyTNiiumG0FVwDKDU 2mdU+38UNI3hYQWKRx+9DF/qB/IQ9a6Ye7nvh/cdf/7Y8ePqffz4888fd+mYXpl+/PgdodmOY6kq ppuArhIYqv2ufa+v4tFHldoNkpTCQYUCxdzLFVq8mgtrfT8ERExHBLx8PJoURF7e98pU3lNMMX1m unpgKLax9Bdz5wIc5oKCMXfu5cuPKj1j7mV8ITzUP3/2PCBizPIHojGDizFYfXBH7OaL6WaiqwYG OSDOrFHQUIAAfAzPfVQBYe4wvS7PBYwA5/jRD6ePTVc0hkui4+4a/HH89N1XvmJMMV0v+gzAIBKr FNtAXChMVDwKmCBozOUVtdb3b6r5n1ZvhYAxwAG8+fUgYmaN+uyHuV1jDSOmm4I+MzAUbfvkXgQC LWhl2K4ANIYfeR7ZxumxNaenrxlbo5b8UmBZoz5dgJr926agNDHFNAX0mYBhwvZTS7+sITGs8YHC FcNFoWMIJKquB9eMjY2dHhvDJb6mT+8am366a/oawMdY55nYrRHTzUBTwTEQHEdRpMqnYXdt+Jf/ 47RDY7hcA9+KjzzYpVbUj84zcVxhTDeepgQYTDPeuxf0b0ND+BkaUuyCfymRas3p010HT+9XkIBl Vxe+CSkH8a+u/THXiOmG01QCQ7GOuz9hHjFEYBiaOzzsIEVtG/rRv/1PhEFX15gCwZqu0wcVLvYr jKiXwsua/V1r9t9t/Box94jphtDUAkOR2PpVxMQwMYnhIcM3aG1YvR95RiEB6GBX18H9uN4Fr4Pq c8fBgx1dXZ078mJuY4DEdF1pyoEBaQ7WP/0YAAFZBABiaIiRYT7Dv3hmDUFjfx516a/t705dqoiY YpokTT3HwGVq678+MISSEzOKEOHP4V/+63v5qDBA6VDfXb86U+Z0kjHFNNU09RyDSAh/xqXPVykA /NehYjR3+BvP3PHeQYWCgwCIDkQEfg6eVt8H/3b/HXfHenhMN4SmDBgFSR6Bjla+NTRUNVQVBgRu qKKNw798pkshoaNjP70YGopjdHR03KE275gRS1IxXX+6VhzDgCN17v7HCA1DDkCqeAHweO4XT++/ g3DhEANFrVXGbCOm607XDhgObXvo85pRKChUDbVqjlEFX7DlF1/uuNTR0XmpI0Sd+O74287FMduI 6frSdQGGopE999+LEGDBqrUVIYEQUb/Uj3u//J8IC/ipJGisol/7O/edKTcVdEwxTQFdL2AoEt// yVeeQ2RUVWneAbBorSJqHXruG093dlZ2rKqs7Ois7Kxc1aFW1KuzsrJy1arOPG0j5iExXUO6bsBg M+62S2+1Vmn1WzGM1qoqq4/D64EvX1J46OwERChcMDZguapj3+KjNzTfcEz//9D1A4Yw0xBse/it IeYSVbwy1IpyVRWCRjGOVUsrNa2Cxb5OvWHb2hgWMV17us4cw8wYuvDhrxjVmxgH6R/EQaqeu/eF 9wgI+/Z1Vu6Db1gCOrbvOBOPEI/pWtN11DEcoqmwtj30++da1yk1vJU+rcgwkHGoz7eH3nq6c1/l 0u3bFRyWLt23b+nS7ZX7tgM69t09IxXzjZiuJd0YYBDBoPHvV97/KSLChUcrsZDWqnWPvfX0vu1L dyhQ/EyhonK7egNKFDa2zoi9GzFdO7qRwNCUWvjwA89pbORTVetjX/kEoKCAoRaKgRAt3b508YxU rIjHdG3oZgAG0sIv3v/At5FPoA5OoMAVeD/3jUuVCgznlGSlQMKf7dv3rF8bzyQQ07WgmwYYQKlt D331H11mEVr99J1LCgqV5xRAlu7Zs1299gD/WBybqWKaerqpgAEkxNY/fvVrBhUWHHfC4v23gHOA ILUHvhaTWLXY6uIxSGKaErppgMFmXB16+M17/vQAIGGdRUUVr73/wCeV288pfvFF4BqL9+xZvH3x 4sVrj47gSeKEhjFNBd00wGAKObZf+d5/fucxAMWdhIk76dN657pvf17JVTv2ACz2EDK2L16/MA6n immq6OYBhnDn/namk2lbeM+fblPQeNJA4076bn3/9588tGPHYqTv7VGLPeu3rY1V8Zimgm4eYJQm 8b2f/Om2L7X+5s4nLTLUV+u6T79y6dw5Asd6XG5dGzs4YvrMdKsAg2hk4RcffuFrAI3ftP6mFfGh 1u98/9MXLp1DjrH4nILH+q0LX8EZYW90cWO6denWAgbo1qq5r13/0P2fvt/6JPKMJxUbAQbypU+f VuhYv554x/cU44iBEdNV060GDCbU0dcufuiF2x5bBzxDgUQh5Ml1X/r0Hx66e/36rYrWL9464yjE 9KZiH2BMk6ZbERjhZi7WfuueP73zwDqUrBTnePLOdZ++8PDPCB1bz7DGESMjpknRrQgMJCE4Rtds WKv083du+/Y6JWEB8/ja7z95aP3ChWe2Lvx+rI7HNFm6VYFRwAHshrULv/jHr/+XT7/05J2Kebz/ D1//2ZkzM7bOiMdwxDQZulWBEUEFg15T3zr30MPv3Pa1J9f933e+fs/6bfEgjpjKpv9AwCASgoUs 8hjyUPNvbf3JH3/yx3v2/P3WWA+PqRz6f3H02g7T90p1AAAAAElFTkSuQmCCoEYd8H4NAACS2Qan 2jNmhxJZiQHycfw7///Y/+AAEEpGSUYAAQEBASwBLAAA/9sAQwAFAwQEBAMFBAQEBQUFBgcMCAcH BwcPCwsJDBEPEhIRDxERExYcFxMUGhURERghGBodHR8fHxMXIiQiHiQcHh8e/9sAQwEFBQUHBgcO CAgOHhQRFB4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4e /8AAEQgAOgCUAwEiAAIRAQMRAf/EABwAAAMAAgMBAAAAAAAAAAAAAAAHCAYJAwQFAv/EAEgQAAED AwIDBAQJCAcJAAAAAAECAwQABREGBwgSITFBUWETInGBFBUWN1JydLKzMjU4QnWRobEYNlSSlLTT IzRDU4LB0eHw/8QAHAEAAQUBAQEAAAAAAAAAAAAAAAEDBAUGAgcI/8QANBEAAQQBAgMFBQcFAAAA AAAAAQACAxEEBSESMVEGE0FxsRQiMmGhB0JSgZHB0WKi4eLx/9oADAMBAAIRAxEAPwCyqKTequI/ b/TepLhYLhHvipdvkLjvFqKhSCpJwcErGR7qb8V5EiM1IbyEOoC057cEZrt8b2AFwq1yHA8ly0Uv d1t3tK7az4MLULVzW5NaU618FYSsYScHOVDFfGmN4tKah0Deta29m6C2WYqElLjCUunlSFHlTzYP RQ7SKXuX8PFWyONt1aYtFJ/Q/EPoTWGq4Gm7XEviJk5ZQ0p+M2lAISVdSHCR0B7qat4uUGz2uTdL nKaiQ4zZceecVhKEjtJpHxPYacN0BwO4XbopDucVW2iVqSIeolgEgKTDbwfMZczWezN0LLC2vVuH PtV7iWkchS09HQmQtK1pQlYRz45SVDtI6dfDPbseRtWOaQPaeRWd0UlNP8TW294vcK1Nt3qI5LeS yh6TGbS0hSjgFRDhwM9+KddcyRPj2cKShwdyRSx3Q3o0tol1yAgqu12R0VFjqAS2fBxfYn2DJ8qX vEHxAxbMu56N023Pj3hh4x5cxTaQlpOOvoiFEknOMkDHtqbQpchYXlbi3Dnr1Uon/vUXKMkIG1X4 redjOzWJq7nS5Elhv3Qd/M9B9T8vFwX/AIi9fz3lG3fF1paz6qWo4cUB5lzIJ9wry4m/O6DDoWvU DchP0HYLOD/dQD/GvZ0Jw8aqv0JufeJbNiYdAUht1suPkeJQCAn3nPlWSXXhflojFVr1Yy88B0RI iFCVH6wUcfuNROGd2+62r8vshiu9nLY7G3w8X91H1XPofiYUp5uNrCzNpQTgy4GfV8y2onPuPuqg tP3q1X+1M3SzTmZsN4ZQ60rI9h7wR3g9RUEa20lftHXhVrv8JUZ7HM2oHmQ6n6SVdhH/AMa7e027 UvbvU3pmjIftziwidEH5LiQccyevRY7j7j0qRjGaR3CBdKj7U9m9HjxRmYsrYy7kL913l0P08uav yikN/Ss20/sOpP8ACN/6lH9KzbT+w6k/wbf+pVj7JN+ErynvWdU+aKxXbDXdl3D02q/2JqY3ETIV HIlNpQvmSEk9AojHrDvophzS00V0De4UE77/ADz6v/a8j75rYpZPzLB+zt/dFa699/nn1f8AteR9 819tHdv0SfRfLj0eBy8olYx3Y8qvJ8fvo2b1Q/hQ2ScDjsm/x8/1q0x9he++K4djf0TtyvrvfgN0 h9VfKr4Qx8qfjr03IfQ/GXpeblz15fSd2fCnxsb+iduV9d78Buh8fdwNbd0R6oDuJ5KWPDbIjw97 tNSpTzbDDLzi3HHFBKUJDKySSewAVlHExvO/r+6KsNiecZ0zEc9XGQZqx/xFD6I/VT7z17EoCQcg kdMdK9bR1zhWbVVsutxtjN0iRZKHXojv5LqQeoP/AL6Z7cipLoWmTvDuQE2HGuFUFwu7EG6qja21 pExbwQ5b4Dqf948HHAf1PAfrdp6dri4ugE7AX5KQAAuKAB9obpj6Uvdr1Hp2De7K+h+BLZDjKk9w 8CO4g9CO4ilzxefMDf8A68X/ADDdU3fPlyGl3Ueql8AbGaUCVefDNua1q/bBSrtJButha9FPUo+s ttKSUO+9IIPmk1KmwuhGdw7rqGwkhExNkckQXCeiH0utcufIglJ8lGvA0hqO9aDvt0YQlxhyRFkW yfHXkHC0lBBHilWCPMedWWZGJmOaPiG6bxAO9aHmmkgE9P8Ai6e4V5e1Dri83yQMOTpa3in6IJ6D 3DAp+cImj41+1U9fp7KXY9nabU0hQyC+vPKfPlCVH24qbrmQZ7xByCroatLgpbQNv7s6Mc6rgEn2 BpGP5mqzPbxRwX0/YLa4OQcGLVBBtuGiuhe4emy5uIDeidpG8/JnTLbBuDbaVypLqecM8wylKU9h VjBJPTqKV+nuIbX8C4Idub8S6xeb/aMuR0tkjv5VIAwfbmqL1DA2pdvMly/NaVVciofCDLUz6XOB jm5uvZjtrofFmyX/ACNE/wB6P/5qpex5dYcrbTtR0iDDbDJgOea3dW5PUHmB0pdHdG22rdPZU3u3 tczyYpnwFEeuhaQSts+3CkkdmceFQ8/Z0uvLd9ORzqKscvZmthcDUG31stHxXbb5p2JDQlQQwzLa ShPNknAB7ySffUFLACyB1ANK7Ikx3B0bqJ5q17JaXjarDNi5kRMbHcTA6wRxX0I6D81ic+OI0lTI VzYA64qiNsOGiHrLQVp1O5qx+Gq4Ml0sphhYR6xGM8wz2VPt8/OTnsH8q2B8NPzF6U+xn8RVaGTI kbixvB3NX+i8w1XFig1PIgjFNa9wA6AGgu7stt81tro9enWbmu4pVLXJ9MtoNn1gkYwCfo/xorOK KqXOLyXHmo4AAoLW/vv88+r/ANryPvmtilk/MsH7O390VJ+53Djr/Ue4d/v1vfswiXCe7IZDslQU EqUSMjkODVaW1lce3Ro7mOdplCFY7MgAVOzZWPYwNN1/hMxNIcbUk8fP9atMfYXvviuHY39E7cr6 734DdMjii2i1VuVe7LM087bkNwozjTvwl4oOVKBGMJNce2mz+q9O7Gax0XPdtxuV4U4Yym3lFscz SEjmPLkdUnuNOtmZ7O1t72PVcljuMmlMewNnt1+3i03artGRKhPyiXWV/kr5UKUAfEZSOnfTT4w9 qE2C6fLqwRAi1zVhM9ltOEx3j2LAHYlf8FfWFe1szw9a70hudZNSXR+zqhwXlLdDMhSlkFCk9AUj vIqob9aoF8s0uz3SMiTCmNKaeaWOikkYPv8APupcjLDZmuYbFJGRWwgqMuEndj5IagGk75J5bFc3 R6FxZ9WLIPQHySroD4HB8aoHi767A38j6cX/ADDdIe+cKmuG7xLRZ7haH7cHVfBlvvqQ4W8+rzAI IBx24pw3LQW5F/4d5mgdQP2t69oUw3FlCSpSHWW3ULHpDy5CgEkZwc4HfmknMJlbKx3iLSs4w0tI Sb4E/nZun7Ed/GZr1uNbbf4uuzW4Nqj4izlBm5JQOiHseq57FAYPmB9Ks04ZdltXbc66m3q/vWxc Z+3LjJEZ9S1c5cbUMgpHTCDT31ZYrdqbTc+wXVkOw5zKmnU94z2EeBBwQfECuJckMyeNpsJWxkx0 Vq+queCm/sNO3jTTzgS6+huXHST+VyjlWB54KD7jSc3N2H1noWEq5zDDmWz05aD8daiUjPqqWMer n39enhXjadulxsNziXS1ylxpsVQU06juI/mD2Ed4qPq+VGSzgN1a9A7F6BNqODlxvFB4bwu8OJpJ /i/kU8OJ7bW/nWUnVtnt78+BNQhUgMIK1MuJSEnKR15SEg58c0lrVp++3WaiFbrROlSFq5QhthRO fPp099UtoPiQsMuG2xq+I/bpiQAuRHbLjK/PA9ZPswfbWUXHfzbOJHLrN3kTFgZDTENzmPvUAP3m qZ0cTzxB1LT4etdoNLgbhSYReWig4XVDldAg/qPmlhO4frXY9Avah1JqORFlRoan5DLTaChK8ZDY J7TnCfM9lT7TP3q3due4DiYEZhdvsjK+dEfmyt5Q7FOEdOncB0HnWAaes9xv96i2e1RlSJkpwIbQ nx8T4ADqT3AUzJwk0wLW6C3UYcV0+qye8d62po/L686WF3z85OewfyrYHw0/MXpT7GfxFUgda8Lu r5F757BLtKoQjspK5EhSVrcCB6RWAk4BXzY69mKpbZ7Ts/SW2lj05c1MqmQY5bdLKipBPMo9CQPH wrSSyNOLGwHcV6L581OZuTqWROz4XOcR5E2FltFFFQFGRmjNFFCEZozRRQhGaM0UUIRmjNFFCEZo zRRQhcFxhxbjCegzo7ciM+godacTlK0ntBFTHupw73GJIeuWh1CZEUSo291YDrfkhR6KHkSD7aqO im5ImyDdXOja9maPIX4ztjzB3B8x+43Wuq82a7WaSY12tkyA8DjkkMqbP8RXRAKiAAST2AVsffZa ebLbzSHEHtStIIP7668a2W2M56SPb4jK/pNspSf3gVFOLvVr0OD7R3OiLnY+4/q/1KiHQ+0+uNWv o+BWZ6JEURmXMSWmgPEZGVf9INVVtDtZY9vYRWwfht2eTyyJricHH0UD9VP8T3nswwKKfjgazfxW P13thnau3ujTI/wjx8z4/QfJFFFFPrJoooooQv/ZoEYd8NwoAACV0HfBNcnzrfYUiYU16TQ////Y /+AAEEpGSUYAAQEAAAEAAQAA/9sAQwABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sAQwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/8AAEQgAawB+AwEiAAIR AQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAAB fQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMB AQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A/v4ooooA KKKKACiiigAooooAKKKKACiiv4U/+Di//g5X8a/Afx742/YF/wCCePi6z0X4jeFxeeGP2if2ltHe DUNT8B+IZoJrbV/hR8IbgpLY6d430BJRbeNfiDG11qHgzXTc+GfDSaT400PUdY0UA/pI/wCCi3/B a/8A4J8/8ExtOvLD9ob4w2+s/FwacuoaN+zx8K4rTxz8atXS4haewe+8OQX9lpXgXTtSjSR9P134 k674O0PUVimTTL++ukFs/wDPb+25/wAHD/8AwWq+Dn7P/hf9s/4b/wDBJLwV8Af2O/F2o6LbeHPi b+1BrviH4reKNS03xLuTwprvifwB8M/iH8GfF/wr0zxg9xpZ8Pal4u8PXXhzUJ76y0/SPEmuT6zp c8v5F/8ABrr/AMEjtI/4KL/Hv4kft9ftjWGu/FH4PfAn4g6ePDum+N9Svtbtfjx+0ndCHxjqV54/ v9Ta9v8AxjoHw5sb7QPFXizSNUvkg8X+JPFnhOy159f8Nx+LvD+pf3w/8FXf2TfEf7cv/BOn9rf9 lfwX/Zh8dfFf4UX9t8P4danis9Ju/iF4T1XSvHngLT9Rv5yIdLtNR8YeFtFsJtXlDx6QlwdSeORb UxsAfx9fsJ/8HpvjXX/ip4f8G/8ABQ39nj4V+Gfhp4m1a30u7+MP7Nlv490iT4cRXkscEOt+I/hr 468XfEvUPF2g2cj+drk3h3xbpetWGnJPeaToHiK9hi0i7/0BLG+stTsrPUtNvLXUNO1C1t76wv7G 4iu7K+sruJJ7W8s7qB5ILm1uYJI5re4hkeKaJ0kjdkZWP+L/APC//ghN/wAFbfif8bNH+B0X7BP7 S/gjVr/xOvhzVPHvxG+E/i/wV8HPDkEOoR2Wq+I9Q+L+u6XZ/DnUPD+mQtNqKXnh7xLrEmvWVu3/ AAi8Ot3E1rBP/slfCbwInwt+Ffwz+GUWoPq0Xw6+H/gzwJHqskAtn1NPCPhzTfD6ag9uryLbverp 4uWgWRxEZDGHYLuIB6BXjvhT4neIvEfxe+K3wz1D4U+NvDPh74dWngy50D4p6vbqngr4mP4o0OHV tTtvCNwIkaWfwldSnR9bVpZdt/FIBsC7a9ir+Yv9vb4s/FTw58Qf+CsNv4e+JnxA0G38F/8ADCf/ AAh0GjeM/Eelw+E/+Ej0Twc/iH/hGYrHUoE0H+3nnnfWf7KW1/tRppWvvPMjkgH9OlcJ8Ofid4C+ LnhpfGXw18T6b4w8LPqutaJFrmkmZ9Pn1Pw7qdzo2s29vNNDCLhbLU7O5tGuIBJazPCz2800RVz+ Nv7Q/wCzjP8AA/45/skeH/CPx7/aTmtf2nPH/iX4S/H241X4z+Mb278e2lz4XTU4fFFq0moG38Ie JNNvLedtJuPC9tp1vpcE0Npp8FtaQzwXn5n/AARsvFPhnwh+yD8PPBep/tM+JdI/aV+IX7UyfFXw F8Lfi3ceHtY8Z6B8EfFGrXmi+FvBFx4h8S+GtB8KNq7S3Wq/Ey/s9b0rVfEWmIwjuZ7+5jtLwA/r 9or+W341ax+078IPhf8AtR+D/C0Px7+Cvwikf9nbWfhTpnxZ+M/h3xv8S/hZ4wvPip4W0HXdG0i/ 8L+PvF3ii08FeLdP1m61BrPXb+e0ubfS1sw7rc3Ud39cfGj9mzxH8PP2mv8Agn7+z9pP7Tv7UOpa Z8bdd/ar1z4ueLtX+MPiX/hKPFbeGPhN4B1fUrCzu9Onsk0LS9Uh03VbXTLK0WU+F5fEGo3+h3Ft qDm7YA/dqsTxN4k0Hwb4b8QeL/FOqWmh+GPCmiat4k8R63fyeVYaPoOhWFxqmr6pey4byrTT9Ptb i7uZMHZDC7YOMV/Mj+0z49+L37Hfxb+Nn7LfwK+Jvxxufhz8QvEH7L2i6BZS+N7jxZ46+HA+Jlz4 jk8WR/DXxf41vml8O3fiKPw2nh6xn1TWbaxjvdet3vL+G4httQt6nx8+D/xT0m28Z+GvDPgf9rj4 JfAS+/Zv/aN8ZfEnwf8AGH9pTwz4iOreNfhz8FfHnijwT4m0TStL+KfjPxLq2la1rljb+HviHoVr bx6Jq+nalEmpWw02ArZgH9OvhPxT4f8AHPhbw1428J6nBrfhXxhoGjeKfDWs2qyrbav4f8Qadbat o2p263EcM6wX+nXdtdQrNDFKI5VEkaOGUb9fDf8AwTn+FuifDX9kL4EXuj63401iT4i/B/4P+P8A Vo/F/i7WPFVvpGqa58LvCL3Wk+E4dWnnXwz4VtnQtpnhvTPK0zTRJIlpDHEVRfuSgD8VP+C+n/BS iX/gmR/wTx+JHxT8HalFZfHv4qT/APCk/wBnkYt5p9K+Ifi/StTlu/HwtLguksPw08L2Gt+MLU3F pe6bceJbDw1o2qW0lnrLqf8AG+nn1DWNQmurqa81TVdUvJJ7i4nknvdQ1HUL2dpJZppZGlubu8u7 mVnkkdpJ7ieRmZnkck/1Zf8AB3z+2zP+0T/wUmsP2afD2rSXXw4/Yq8B2Hgp7WG7hutLu/jJ8TLL R/HnxP1m0e3kZFmsdEl+HXw/1K0uEF1p2veA9chYgTGNPg7/AINzP2K3/bb/AOCsH7OXhnWNIGq/ DX4G6pL+0z8VVlhmmsx4c+EF5pup+FtOvokie3uLLxL8VL74feGNRs7yW3t7nSNY1LJuGjFncgH+ op/wSX/Y2sv2CP8Agnf+yx+zIdMh03xZ4N+GGi618VPLSPzLv4xeOUbxn8UpZZ0jje8is/Geuato +lz3ANwuhaXpVq5C2yIv6L0UUAFFFFABX8+//BVr4of8Elf2OoPjr4v/AG4vj54q8HeNP2ubX4S3 us/CXwBq9t4n+LHiiz+DUNtpvg3UfAvw+0jw5q2r+HvD8zeG5LXWPF/i+Wx8G3ep21zpi+IbHUpr axf17/gsj/wVu0v/AIJxeA/h98LPg94QPxz/AG9/2pNYt/AP7KH7PWmW95qNzq/iLW9Tt/DNj468 X21gY5Y/CWm+JNS03SdK0Vb2w1fx94luE0HQ5YNO07xd4i8K/wAR3/Ban/gkNrf7Hf7EVh+3l/wU S/ae+Ifxu/4KkftZ/Hzwzp0/hXw7rPhqX4T+EbC98O654l8ZaHqrXfh+51zxdH4G8PaJp/h6DVfB mreDvBHhfVdT8LeFPC3h3UvCunxa1q4B/S18Cf8Ag4u/4JJ/8FMP2wv2UfgzDov7Xnwl+KWifFpb j4Ea98UPBPwx8OfDjxP8TvEFm/h/QPCmtX3gj4ofFLXUl8UzyQ6R4fjvtG0Gyl1jULK2vdWspJ4w v6e/Fj9hP9iz9mX4TeL/AIo/F79pj4wfA/4TfDPxVcfFTwl4/wDFXxw0Hwhon7NfiHWNX1CbUp/h Lrd74ZgbS7jxvqWu2+jXega9J40vPGmqR+HrG3sdR8Riyef/ADX/APg3a+CHhv4gf8FJ/h78f/ir rNh4N/Z3/YM8MeKP21fjz8QtaZrfRfCPh74NWYvPBMkt20EsMup3vxQvvBslro8ROralpOn6/Po9 tdXWmtGP7If2bv2dPib/AMHHHxmj/b0/bq0jxr4K/wCCV/gDxNqlj+wz+w7qGr6v4Zj+OD6HI2l3 X7QnxvHhvVLN9Us73Uk1G20q1hv3N7Jb3nhjSbpPAen6vqXxVAPkL4of8F+P+CC/g2T4wfDm4b/g o1+1ZqHxM8X+Ddc8d/tJ6P4T+Gl1r/jg/DPWdO1fwlp2lap8VfH3wc1nTvCNneaZCLbTIvhdoHmW X7jEMMGmi1/qN/ZK+Pf7Gn/BV3Qf2dP+CgX7PPjTxV4ls/gZrHxf8MeGtMvbceFtU8IeMfH3hLR/ DHxA8HfFDwle2l9cprul6BLo9/pX9mawdKmg1Ky1vTNU1zSNQtJ5P82f/g6L+BH7JH7Nn/BUnUfh F+yF8L/B/wAHfDfh/wCAHwhvPip4D8BWaaR4T034t663ijWnutK8O223TfDv9p/Cy++Fl9fafpUF taXupT3mvzxPqes6hcz/ALXf8EEP2wPBf/BHb/ghX+0N+3N8crTVtcvf2g/2p/EWgfss/Be21aC2 v/jZ4n8IeCvDHgeyl8MwSSynTtMbxtp3jiy+IniOOxuLnSPDXw5luILHWdUHh3RNUAP6k/8Ago/P /wAExf2bdL+KP7QP7ffxmsvhjZ/G3wd4b8FQabqXiab/AISrWLj4W3tvrmgal8FPBPhXR7/4i6v4 28PahcWdzeXvh611uztIr6KLXraDRr6aOb+bXRv+Djb/AIIkaN4x8Zv4+0v/AIKsftJax4m+H/ib 4CwfFv4y6J8C/FEegfC7xjp1z4b8THwZBb/GXwTrWlWWtaZfXl5qGqaj4Hn8bXa3N21xby3V1PZz fXX/AAT4/wCCHvxM/wCCgvxCk/4Kkf8ABd2O/wDi18Y/i1DBrfwa/Y51t7zRvh78FfhXcpdXvgvR vHvhrTrm1Nq9tZ6mt3onwg8xU8PQhNX+Lt74q+JXiTxdonhr8mL7/gl3+xd/wUJ/4OYPiF+zV+zN 8HfBvw6/Yn/ZA8P+F/EH7Vfhz4f203h/wJ4u8VfC+30nTfGPgrw5pVhfW8OjyeLfiZr3h74TeLLL QDoEn2Pwr8R/F+lQ3F/A+p6oAfUf7ZH/AAcq/CD/AIJ6fAnwZ+z/AP8ABMy8+PP7RPi74k/Dvwp8 Q/CXxc/bN0fxJpHhD4C/D7xJ4fsbLwX4a+G/gHXPBHw317x3Da6RYSXujfuYfhlpryafqOk+JPiR pVzdaLYfxpftPf8ABTr/AIKBftlazqerftH/ALXPxx+I1pqssskng+bxzq/h34aWSzOzvDo/wu8K T6H8PdGiIYRuNM8NWrzRxwrcPN5UZX93v+Dxb4g/C3XP+Cmfwr+Evw20fQNMuv2eP2Rfhj8N/F8e g2GnaZa6Jf6n4q8f+O/C/gW3sNOtIIrTSvC/gHxT4V1HSbWOUWllD4nmsbPT7FLV5Lz+TSgAr+27 /gkZ4p8cf8EVPCXw48ZWvgbwb4w+M37UXwq8FfF39ofwv4rhktPEfhL4eeM5bvxJ8EvhDp2swW76 z4E1+L4bXPh/4veI5Zra4W81f4q6b4f8UeFdQ/4V7od7N/JT+xh8KfD/AMcv2uf2ZfhB4wnSz8E/ ET46/C3wt491CVwkel/D/U/GWkRePNXk/ewySJpHhD+2tTeC2k+2XK2pt7GOa8lgif8Aq0+PfxTu fjd8aPid8WJ7IaVD468Z63ruk6Giwpb+GvDc15JF4V8KWUduqwQ6b4U8Nw6V4c0yCBRDb6fpdtDH 8kYNfl3ijxPi8gy3AYfLMVPC5jjsX7WNWnyucMLg+WdXSUZRtVrVMPBxmnCrTVanKMouaP8ARL9n Z9H3hnxo4+41zrj/AIfw3EXBHCHDDwFXLcfGssJi+IuKpVsHgGqlGrRqKrgMqwedYunVw1SOJwGO llmNo1cPiIYaq/8AQA/ZA/bE+D/7afwrtviZ8KdSliuLOWLTfGvgjV5LaPxX4D1943kGma5aW8sq SWl6kUt1oWt2jSabrdkkj28kV9Z6pp2nfVlf56X/AAT/AP2wfEn7F37RnhH4mWt7qkvw/wBTuoPD fxc8LWMoMHiXwJqEpivJjZvHKlxrHheaVPE3h1o/s10+o6cNL+322m6vqkdx/oRWF/ZarY2Wp6bd W9/p2o2ltf2F9aSpPa3lleQpcWt1bTxlo5re4gkjmhlRmSSN1dSVINevwFxcuK8rnLERhTzTAShR x8Ka5YVFUjJ0MXTjryQrqFSMoX9yrSqJJU3Tv+Z/TP8AoxS+jb4iYShklXFY3w84zoYzM+DsXjJ+ 1xeAngqtGGb8N46vaLxGJyeWLwVWhi3BfW8tx+BlUnUxtPHcluiiivuj+OT8cf2Z/wDgkhoHwz/4 KK/tQ/8ABTb9oj4qy/tJ/tE/FfxXrGj/ALOz6t4WGheHf2VfgH9luNF8OfDzwRYXeteIDc+MIfCc /wDwi/iLxzYnQoNUsW1q5sPD+lXvjPxhNrH8H3/B3J+3SP2nv+Ckifs7eE9bk1D4YfsTeFG+Gggg uJ5NMuvjV4vax8S/GHVbeJzHHHdaWsPg34caivkb49V+H2pNHcT208JX/Sb/AG7/ANqzwv8AsPfs c/tGftY+LhaTab8D/hb4j8Yadpl87x23iPxj5C6T8PvB7PHLA6SeM/Hmp+G/CduyzwbbjWYiZ4QD Iv8Ah5eNfF/jb4x/Ejxb4+8WX2peL/iP8VPG+veL/EupGKW81jxR428ca9d61rN8YYEea61LW9d1 S5nMUKPLPdXOyNGdgCAf05f8EbP2HPF/7Zlj8N/+Ccfgu+1TQPh18cdY8Bftr/8ABU34iaE93pl3 Yfs2eDZ3P7Kf7KUWr27Wc8ms/EVtU1X4yXEEN1e2T/8AC0vh14pt7R7/AOC3ieym/wBN/wAYeJvg 3+x7+zn4j8W39no3w1+Av7NPwg1LWptM0O0s9N0TwZ8MfhT4Sluk0nQtO82zs4LbSfDuiJp+jaak sCO0VrZxMrOtfl9/wQW/4Jrzf8E4f2G/DmkfETTBH+1H+0Jd2nxt/ae1S5uX1DUrLxtr1ireHvhm 2oTh7g6f8KPDdxB4blslvNR08eMZvG2s6Zf3Nrromf8AJ3/g8b/byf4GfsS/D39ivwZrJtPHn7YX io6n46SyuWS90/4E/CXUdI17VrWc27x3Vh/wm/xDn8F6VaySOLTWvD/h/wAeaLNDdW8l2kQB/nrf H34u/FH/AIKIftt/Ef4va49ofib+1Z8eL/VbK11jV4bLRPDsvjzxOmn+FPDlxrmoNHa6V4T8D6JP o/h2DUr+SO00fw1ocVxeTJb2kso/ux/4IqfsKeGv+Chfxt+EP7Vfi7Rb24/4Jnf8Ew9Lg/Z6/wCC afw11rR7rRdA+O/xZ8D6oL/4qftkeIvDV5bQw3EnjD4pR6l8Sr1HF5cXHxFvdH8Jatqk/wDwp7W9 N1v+KD/glj+xJ8VP+Chv7bfwj/ZX+Fl7q/h5PiDPq8fxS8eaTZJdt8OfgfBp0sPxZ8W3Ms6fZbUN 4Su73w1pcF5cWdv4i8ReItE8GtcF/Esdtcf7SfwK+CPwz/Zs+Dfw0+Afwb8M2vg/4XfCPwbofgXw P4dtGeVdP0HQLKOztTdXUpa51HU7xkkv9Y1e9km1DWNWur3VNQnnvby4mkAPzj/4Ld/8FHtI/wCC Yv8AwT8+Lfx2stRtIvjL4rtJfhN+zlo8ywXEuo/GbxnpmpR6Frb2E7BLzSPh9plpq3xD12GXZBe2 Hhk6KJo73WLBJf5L/wDg1q/aN+Fv7HH7CP8AwWC/4KMfG+7bV9a8Ha/8N7nxHq+q3jP4h8a6npnh /wAea/4Y8G6dqlwl3NHrvxM+JHj2DSJp1hK32rX2k3urmeDSoJLT8pf+Dof/AIKcv+3r+37rHwj+ HPiU6p+zb+xzLrnwn8Arp9zFLovi/wCJ5u4I/jN8Sont2livo7zxBpln4E8O3iXd3p1z4W8C6dr+ krZyeKNWS4/PbVfgT+2t8Lv+CPOh/G+9nv8AQf2Iv2nv21rPSl8PSWN/Z3viX4j/AAY+GXi6y8G+ Oft6Tra3vgTXJNe+K3hi3tJbcw3PjP4UNeSlptI0eUAHw3+0p+0F8R/2rfj98YP2kfi7qv8AbHxI +NfxA8SfEPxZdRmYWdvqHiLUZryPR9Hgnlmex8PeH7JrXQfDmlrI0Gk6DpunaZbBbe0iVfEa9X8d fAz4u/DHwN8JviT8QfAHiDwf4J+Ouia94m+EOua9bx2Efj7w14Z1k+HtX8R6DZSyjUpvD8WtrLpt nrc1lBpmrXNrerpF1fLY3jQeUUAf0Hf8ECf2K5fj74i/bg/aj1mBl8I/sX/smePNc0q6MUssU3xa +MGheIvBPhOwlj86C2lhHgCy+LV+ZJftTafqlnol7FafaBb3Nt9xV+wP7CPwEtf+CeX/AAbQpq3i OytdH+Mv/BQfxHonxIv4r6Em9l0D4maho0vgTS0W9FrdyWqfs7+CF8VW8EUPk6T4h8Xancwi5jkk u7v8fq/m3xkr06nEGXUISvPD5VB1UndRdbFYiUItdJckVN6XcZw1elv98P2VOT47B+CXHGcYil7L B5z4kYqnl8pU1GeIhlnD2R0cTiITsnUw/wBZrzw0PecYV8NiopRlzuRX+iH/AME9/Et54t/Ye/ZU 1vUJ57q9b4HeANLuLm6Ja5uZPD2hWvh77RPIZJXnlmGliSS5lkM1yzG4nCzSOi/549hYX2q31lpe l2V3qWp6ld21hp2nWFtNeX1/fXkyW9pZWVpbpJcXV3dXEkcFtbQRyTTzSJFEjOyqf9Jv9nr4XRfB L4EfBz4QRyee3w1+GngvwXdXXmtP9s1Dw/4fsNO1O+8xsA/btRgurzbGkUCef5dvDBAscKdvgtRr PMs7xCv9XhgsNRqPo61WvKdHybUKNf0T89flP2smaZXT4E8I8lqODzvGcW59mmDj7rqRyvLcnoYT M2/tRhUxea5SltGpKm93TfL7FRRRX9Cn+HR/CP8A8HqX7c6eHvhz+zn/AME8vCGqGPV/iDqY/aR+ M0FvLGskfgnwvc6x4S+E2g3apK7y2XiPxivjPxJd280EDQXvw98OXMM0yXEsafjp/wAGn/8AwTBj /bK/bZm/as+KXho6n+z/APsXXmjeK7SHU7K2uNC8b/tBaiJrn4Y+GnivB/p9v4GS2ufihq/2FZxp uraL4EsdYRLDxRDFd/01/wDBVD/g1f0z/gpj+2V8Qv2wJ/29fGXwp1L4iReDLK88Ba58BtI+Kmme G9I8HeD9C8JWui+EtZs/ix8L5dO0yb+x59Wjiv8AS9VlgvtUvHuJr+V5Lib98f8AgnH+wJ8Hv+Ca H7Jnw7/ZO+C8t/q2h+EDqet+KfGutW9vbeIviP8AEDxJcLeeKfHGvw2jPb291qUyW2n6bp0Ms8Wh +HNK0PQIbm5g0qO4kAPuev8AGa/4L2/t5v8A8FC/+CnP7Qfxb0HxBPrvwg+H+sj4E/AQi5iutJT4 XfCy5vdHj13QJISQ2j/EXxnL4v8AijZtNm6WLxslvOIhbR20H+wt8bvhzd/GH4L/ABd+Elh4y1/4 c33xS+GHj74c2XxC8KC2bxR4Eu/G/hTVvDNv4y8Nreq9m2v+F5tTTW9HF2j2x1GxthOrRbwf41f2 ev8Agyl+BXww+PHgX4kfGT9tLxF8efhN4N8YaN4o1H4JH9nvSvAQ8c2OiXseox+EfF3jaT4xeNor jw5rE9vBZeJYdN8G6bd6losl/p9nd6VcXcWoWgB9tf8ABqf/AMEvV/Yp/Ygj/ae+JuhRWv7Qv7aW m+H/AB0VvbJI9V8CfANLYah8LfB6tc2cd/YX3iyO+n+I/imGK5S3u49Y8G6Vf2Ueo+EDNL9+/wDB fz9v6+/4J0/8Ey/jb8XPCOqnSfjF8RzYfAL4F3kUjQ3Nh8SPiZZ6rHN4kspo7m3ng1HwL4D0jxt4 80iaITr/AG14Z0yC4ga2uJXT9noooreKKCCKOGCGNIoYYkWOKKKNQkcUUaBUjjjRQiIgCqoCqAAB X5Ff8Fm/+CSfhH/gsJ+zT4R+AniD4ya78CNe+HvxS0z4q+DPH+keD7L4g2EGqWvh3xF4U1HSPEfg u78Q+EJNb0nUdG8TXkkJ0/xb4ev7DVrPTbwXl1Yx32lagAf4zmgxaVqniXRofFWr3elaHqOuadF4 k1+K1l1a+03Sru/hTWNXisQ6zand2dnJcXqWokWW9mjEIcPJur/RO1b9rMf8FUfAHwR/4JGf8EV/ 2RPCHxV/YL/Z+1P4CWfx0/ay/a5+F/iSy/Z8h8J/BfxT4X8ZWng+Hwncad4Z1+68QeOZtBs9Q8VT 38ugfFf4gW+reNrPRPB/h3T7u/8AiPa/QH7K/wDwZkfsAfCTxFYeJ/2l/jL8Zv2sX014pF8EiOy+ Bvw01Vgn73+39O8GarrnxGukEwSW1i0j4qaDEih4b9NTjfC/uv8Atw/HH4G/8EhP+Cafxz+L3wt+ H/w++FPgv4DfDDUbP4N/DLwX4c0Xwn4Su/ij4nkh8LfC7w5aaBo1lBatFrfxA1rQ5PEl5DY3l4ul f214g1CO7W0vJCAf5OP/AAWB+JH7RXjv/gob+0r4d/aY8d+AvGnjf4KfETxB8CdDsPg9avo3wN+H vgX4W6lc+GPCfw4+CnhHCJ4L+HvhLTLSPTrDw7Kj6zb6gmpXPiq+1fxZda5rF/4z/wAE8f2Stc/b p/bZ/Zs/ZS0UXsUHxh+KPh/Q/FuqaeP9K8OfDjT5m1/4neK4naGeKOTwv8PtJ8Sa7C1xH5Dz2EUU rKsm4fJPiDxBrnizXtb8U+JtW1DX/EniXV9S8QeIdd1e7mv9V1rXNZvZtR1bVtTvrl5Li91DUr+5 uLy9u55HmuLmaWaV2d2Y/wBcv/Br5/wS0+Nn7U+gftY/tWeBPiZYfBW20XQj+y/4H8X6t4N1LxC3 iC78eadbeIvjTZeHdWs9c0VvC+paZ4NXwX4W1HWLa2165n8OfE3xBp0Ntp1y0V6efF1qtDDV61DD VMZWpUpzpYWlOlTqYipGLcaUZ1pwpQc5WXNOSUVd6tWft8NZZl2c8QZNlOb59guFsrzDMcLhMx4j zLDY/GYHJcHWqxjiMxxGEyvDYvMMVDC0nKosPhaE6taSjT5qcZSqw/V//grr+1t4Z+P3xu0H4P8A whktrb9n79mLSZ/hp4BsdKiW30TUNc08WmkeJta0pYpZI7rQ7WLQ9J8MeFpxm3fRtC/tPT9sGtyt L+Slf0baP/wbm/GafUJYtf8A2j/hjpmlLPtgvdH8JeKtc1CS1zN++l0y9n8PW0M+1bc/Zk1eePMs w+1YgRrj9Mv2WP8Agh5+yp8ANW0fxn8RLzW/2iPHujT217Yz+NbKz0T4d6fqVm8jw6hYfDiwn1CO 9kJkBktPGfiPxlpiyQW1xa2NrdQmd/5sr8B8ccUZzicxzPB08veNrupWxGLxNB06FNWhCjSo0atf EzjRoxjSox9mouMIqdWN3M/30yf6Zf0QPo8eFXD/AAN4f8V47jenwpk1PA5XknDeQ5tDH5vjantM Ti8yzHNM1y/KcjwtfNMzxFfMM1qvGyr0q2KxEsPgK7pxw7/M3/gix/wTW1/xd4y8N/tg/HLwxNpv w/8ACktprvwR8M67ZSwXXjbxVE8V3o/xHa1maKSPwr4YdI9R8LXEtu0fiLXmsdYsZRpmiK2r/wBa VMjjjhjjiijSKKJFjiijVUjjjRQqRxooCoiKAqqoCqoAAAAFPr954Y4bwXC+V08uwbdSTk62LxU4 qNXFYmSSlVlFNqEIxioUqSlJU6cUnKc3OpP/ABi+kJ498W/SJ8Q8Zx1xRGngMPChHLOHOHcLWqVs Bw5kdCpUqUMBQq1I05YrE1atWri8yzCdKlPHY2tUnCjhsJDCYLClFFFfRH4aFFFFABRRRQAUV5L8 cvjv8HP2aPhd4r+NXx9+JHhT4T/CrwRZJfeJ/HHjPVIdJ0XTIppo7W0txJJunvdS1K8mgsNJ0fTo LvVtX1G4t9O0uyu724hgk+IP2Ov+Cy3/AATN/b8+I+qfCH9k79q3wn8T/idpWl3mtN4HvvCHxQ+G niHVtK03Lane+FbD4s+BvAsnjOLTIQbzU/8AhEf7bfTtPVtRvVgsFa4AB+nNfwSf8Ht/7Veoaf4b /Yz/AGKNA1uKKz8SX/jT9pP4oaJFMUvpoPD6p8Ofg7NOkNyrPpF1e6p8Y5Zbe8tnt7nU9E0y5tpD caVJ5f8Ae3X+RZ/wdN/tFx/tB/8ABZP4/wCnadqj6t4c/Z68MfDn9nTw9KWRo7OTwZoLeKfHGlwB HcImmfFXx14/tJVJVzdRXDsiM5UAH88dnZ3eo3lrp+n2tzfX99cwWdlY2cEt1eXl3dSrBbWtrbQK 81xc3EzpDBBCjyyyuscas7AH/a7/AOCPP7DFr/wTq/4J2/s4fsxXNvAnjvQvCTeM/jFfRrbNLqPx i+Il1L4u8fRy3VqkaahbeG9T1NfBGg3rhpn8L+FtCilkkeEyN/nQ/wDBrP8A8E2L39t7/gof4a+N vjbQJ7v9n39iq80D4zeLr25gb+yvEXxctb97j4H+AVmOUnnPinTJviLrFpJBdWFz4c8Aahoeqi3/ AOEk077R/rJUAFFFFABRRRQAUUUUAFFFFABRRRQB/Ix/weT/AAT+NvxP/wCCbXwx8d/DaHWdb+HX wM/aG0jx18bvDOj20919k8O6v4M8VeDvDfxG1RIAzf2N4L17XP7DvmKuloPHkeqXCx2Wm3d1bfwL f8EbfFWv+Df+CsX/AATh1nw3rr+Hb+4/bS/Z08N3mopey6f5vhrxp8UfDfg3xjo8lxC8bGDxH4R1 7W/D1xau3kX8GqSWNyr29zKjf7Y19Y2Wp2V5pupWdrqGnaha3Fjf2F9bxXdlfWV3E8F1Z3lrOkkF za3MEkkNxbzRvFNE7xyIyMyn+Lf/AILP/wDBGH/gmP8ADXxl4B+I3w2/ZP8ACfw58T/EPVNa1LxS Ph94w+KXgjw1Ne2gSS3l0bwL4X8daV4G8JrHKPN8nwn4c0OBpiZniaVmcgH9I3/BTP8A4KQfAL/g mJ+y/wCN/wBoL40eJtHj1230fVbD4QfDFr+FfFnxg+JTWMp8O+D/AA3pKTLqNxZSai1rP4q12GJr Dwp4dW+1vUpo47eKOf8AyKP2Uf2Mv22P+CwP7W3iLQ/hD4T1f4lfFL4t/EHXPiL8avi3rVrcaZ8P PA13488TXev+M/iX8UvFVpYy6d4d0t9T1XUtVNhZ291r2vXTf2L4P8P65rlzYaTcf2B/8E9v+CUP 7B37XH7U+j6R+0v8HvE3xrsNN8M6rfWcXj74+ftGa1LHJpFtdajYW8l3J8WkvLjTY7yNZZdIuZ5t Ku1aWG8sriCaaN/7g/gj8Afgh+zV4B0z4Wfs+/Cb4ffBn4d6QTJY+Dvhv4U0fwloa3LRRQzahc2e j2lqt/qt2kEP27V783Wp37xrLe3c8uXIB82f8E3P+CfnwY/4JmfsmfDv9lf4LwG9svDcMmueP/Hd 7ZQWfiD4qfFDWoLU+MPiF4hSF5jFcarcWtvYaLpbXV6nhvwnpfh/wvbXl1aaLBPJ94UUUAFFFFAB RRRQAUUUUAf/2QBuHvAwEQAAK9gS7wUbD+3pLrJxxgMnl/+JUE5HDQoaCgAAAA1JSERSAAAAgAAA AIAIAwAAAPTgkfkAAAAEZ0FNQQAAsYiVmPSmAAADAFBMVEUAAAAAAAgAABAACAAACCEACCkAEAgA EBAAECkAEDEAEEIAGBAAGEoAGFIAGFoAIRAAIRgAISEAIWsAIXsAKYwAMSEAMTEAMZQAMZwAMaUA Oa0AObUAOb0AQikAQkIAQr0ASikAUlIAWjEAWjkAY2MAa0IAc0IAc3MAe3sAhFIAhIQAjFIAlFoA pWMArWsAtWsAvXMAznsAzoQA1oQA3oQA54wA75QA95wA/5wIAAAIAAgIABgICAAICAgICBAIEAAI GBAIISEIMSEIMTkQAAAQCAAQCBAQEBAQGAAQGBAQIQAYAAAYCAAYEBAYGAgYGBgYGCEYITEYKQAY OTkhAAAhCAghGAAhGBAhGBghIQAhISEhMTEhQmMpECkpGAgpIQgpKSkpKTEpSmsxAAAxGAAxGBgx IRAxISExISkxKSkxMRAxMTExMTkxMUIxQjkxQkIxQlIxUgAxY4w5AAA5IRg5MQA5MSE5OTE5OUI5 Sko5a5xCAABCAABCKRBCKSlCMQBCMTFCQhhCQilCQkJCQlJCe7VKKUpKShhKSjFKSkpSAABSKVJS MRhSOTlSSmNSUlJSUlpSUmtaAABaMQBaMVpaOTlaQiFaWiFaWlpaWmtjQiFjQkJjY0JjY2NjY3tr AAhrOQBrOWtrQgBrQiFrSkprayFraylra2tra4RzAAhzSkpzc0pzc4x7ABB7Qnt7SgB7Uil7UlJ7 Wlp7eyl7e1p7e3t7e5R7e5yEUgCEUimEWlqEhFqEhJyE1gCMABCMUgCMY2OMjDGMjIyMjK2UABCU UpSUYzGUY2OUlJSUlLWcYzGca2ucnDmcnJycnL2lABClazGlc3OlpTmlpXOlpcatABitY62tra2t rda1ezm1e3u1tUK1tee9ABi9a729hEK9hIS9vYS9vb29ve/GABjGa8bGjIzGxkLGxsbOzkrOzozO zs7OzvfWABjWlJTW1krW1tbee97nnJzn51Ln55zn5+fvhO/vpaX391r396X3963/////jP//ra3/ tbX///+ZKCtDAAAACXBIWXMAAA7DAAAOwwHHb6hkAAANtUlEQVR4nM2bD3xTVxXHL5HShf5Z05T0 LwlZQ+higWJLaZTopu3qTFkmZmvWuS5bHVTi1Nlp0LSKdhukFqJxjDBs42SSgWQCLmyMWbcSt2zY ZVXiA7ZsWDLt1gQjUjup5Hnfe2ma5CXv3awh8wfty6efNuf7zj3n3HPvuwE4uibHsPHgZAp/gCKA bN2lkyuVjXLQrHeMfQQAIwqlwUzJ0KFsdaTNEWgAwV5lnzlaXUrLRAYBgs0d5ngZGk1p8QISgJ5u H0rdbAxmBmBCnsg+4QV5ZgBsCR1ACDmH5gagNxgSGO+Gg2DLCEBQ3ZXIBXJ1o2Pu9lEA9AalMgFA 45Y0DAAKAKbu6AbdXfQkOLcxDUmAANBmUBvk6niAbnPXkVfSUYtYAYLA3GFQqmn3b+g6MpqRGMDU 5r5EAN3qI6M67fTVB4BFoK9P3dcdD9AhP3d4xObKAAA9/Mx98tvkjWAUjNjmPggfCkD5ylQr0GgU A0bt1Qdw0QEMmpNTmp2h0BFsIAMecNHiz6w8+3zo4hUIYFHMvRKwAozTAcDZkyFCR5pH5myfHWAa 0AEOP08CbM9MJdTTpsIZAEUa7KPMBfEzkQE8OUXYP6fPDMC0ti/OPthOOuDw3KsQEgBRjKPU3QjA xlcIF2zMWFOqN8zWgq4OJeg8p7kAR2AgHfaRACZb1dAJBnOHWW3uVoPWi6FO6ICd6cgBxLZ8UquU dzV2yc1wBmjqJO4+FJpKSwiirowm9XJASt5y4CIZgaHn0xKC6GtDTEUCtF4gjBMh2Dn3ViAlAFiT B1pHqbu/uCc0tTMNHXmKAPjEHsr5oRebNOvSZT8VgJHDU+HhT+c2BTLAsPGz1+YoNh44dyU0iqXN PDrAQPWaBqja6iU3P7glDbNwqgCuBdLKxQVLllRKq5dXgjQ0wykCYAsqV6ysra1duVwqXbKoAOjS R4AEgBXUNUSr/vqc9EwEiAATBfUNcVqz2JJBAMtK0uj1q6MJFg1nDCC4iLJ5fewwFNB2C4PRmsAw bCIYZA0WBADjCtLiqk/EjkKNKroauXiCGQlJCYRiMXERCG5mLBsILRmgIqA6Pg6kpmhKiUwiEZM2 SfGgfVLLJICnZdhaRWhKF1P2ltfVxALUg6iW5EZZzq2bdwwOvnCC0tHBQeNDUG3QCTIxwwqOHcAh pcytlMbngnR2RhoXSBTn/YRO7TAODu4+4Q9rUCKQyKoYmhd2gHAI1KyWxo9B/Q2REHNIhLvDFo3D LpfjhRmAb1blyGRChoxhB1DVUiFQszweoKEy8sa6qpzTlMXTJw4e3Wx8agbgc2KBTJbDMHmyA4Da 8BCspgGsagv/ziSv6h7/rE7pNp84cYp49bqQGIHvMr09OwBVhtesoNlvaFgUzrARofipWfunb3r0 aahHb3rIv3tZtkwmZlrEI3uAnoZQq79O/Y5FwnsrCuCu/5J6d9D/pWU8mYzHtJvGDqClAOKTMOwC 6r0VMi1p+tUTr5+fBXji9CmhWCiT3ch4f6wAvZTlmvpEBNXknDSeIx70+0/85Od/Pv5rveqnu5+g ADqpJJSYmN6eHcBC+b6mblUk9iojAPULiEx0CHmn/c8ev3z5/UuX3v/r+9uepgB2+O8kk5BxBcEO MEzl/4qoIJReF3m5lGjPesX3+9+65dJlSHD5P5cvX/rRPwn7bx89LSCTkHENxw4wNlOKo9JwSaQm 1BD+vUF80H8UfGY90Gzb9gzULe+SIXDqoFAglklUjG/PDjC5IGxrZVT0L4jQ3AmnYYHglL/58w88 8MDvSAFqCDrPb5bwqmRC5uYJYTrWhY1Ft2Ufj4TB0iA+LL7R798Nfvn723/w7TvWr1//BRLg7c3+ G2REEjI38QgAw7GdCKWCmZC8DsM3izcTAPK1TV/52S9+89xzLW8TAD9+9VWeRChbBpgXMQwAkwMD ZJZP5iQAWLV4JhyM0zzBQf/5r+lcDofNZNSqwCP/JgDu8u8QwxAQsyzjGQAGrEMdbXqHC9NVr6iB PXkswWIyK9asAAqbMOce7f2a49v0ehNUr4oKgVv9bcuyq2QClmU8A4DcPhQIOK0Gg6FLrVaHNwgA +FhBweIlldU1oKZ2ZWUOOPAiEKx97yUAmvTb9Jptx5/ZpnnkD9D+X+55NrsKhkA2yzIyOUBQHXCb rXan0+sLhOUl5XEO2c1qaSUAnQdOXghd+f66W/70wb57HxY9/L1v3Qv1ZcUdd3zn7l0v7RKIYRL2 MttnAJhuJI36nFar1W7ostoDHivx0gnlDQwVNNRoroTX66PrNr330m8J7du69W7wxw9I/VAM6zBz GWQEwNsid06TzxpQ1zUsPRsGCE3tBPs+mNG/wte15EzItpXFAGAbSgoQsAfM1Q2rDoQiOrtu0z+g 0Td3bd20rmkr8fLv2RCg6k4W+0wAWEdyALfbvrShvnVqlmDqSfCrf+3aODp14cL27ffBUdgHFwgy MesakqkQNTONgROulyr3hKJ0TgM0YaIpxZsfbJLwJDIB61YCE4CJYQz2+wCcjK/dcyUaYYqyf7Zz anTtJkUV7MZYyiALgMuQHMAZkMMpYjnYOBqDQOYEAHsuZEvEEp5MomOzzwgwKWcIgoAazo6L6hYA sOXk36JiIfQkUa06gVDCE7KWQRYAXOdmiEIDrMW1DQXh+rhOs2V7685zF17UgIiyBewjwAzgsCaP QruZnCSlPLgSBeQyVCIR8gDI4Ql5PHKFDEZcCA/VGAHGGRLRbidbtTrYc8lgtCUQQNpIYgSYBMkB hpxLSIAcAkBCmVwmWRYNgGKfpSFRzQZBfDgMea+FjdHKOgAdDrIJzY49qW+gPdRkBjDZIwbjw8EZ APXS6oY6kMUnVVQCVSYSEZcSfj6X05sOgKhKEF8VnYHGRTAPVgCOKKEqijlI5xuYAcaVSWPAE+hY CjuiAsApS0wg4iJtKTMDTINk04HbEzBIG9YszuJwSsorrhoArncmA/AGrNKaHG4hH4iKSuJtl6cN wGZOBgDDEnCLy+aXzRcVx3ugOJf4npWGGMAxdRIAb8Br54gquMX5+XTn5xYTXmhGsc8GkLQUQQAn p3whv5xDDwA+l/hehLafzVautB7SHi0WPQRAcbmITxt/UQmnPB8GQR7aYw02AFs4Cn0xpdAHO3SP G1aAcj7NfjG3mEv8FK0MsAKM9c3ccSwAnI+9IFHyFeWWcAoJPzCvypEBpm+bGXN39DB4A84+Nw2g ophfmFc0v4h4nY/4YI91ytL5wmnniy4JnoDTHOOB8qK8+RygVCvnZZFFQJSF+GiNFcBhJy06yf/R HrAGQGnYOD+XozZY4XoJyv4pEqBMgfhYif0sGdmUeL3ugCcKwB2wUwDFhfzceYahyI8DHjk5N+Qb 0eyzA1CVwO2zx2ShnQBQk7O/2hoODp/d7oaLyPnUCKA+XEfYJyTv3BkLYA4MQQCnVW0O+8U3ZHfC MPHa3WQVqkBoR1EBMLPX7nSbnTEtkR0umgPqrjAVHCA3ERcer8f+SbIyFLEvCJABiKbE47Rb7dEE Tq9nf6Q8+qgvT8CuVA1Q/Uk+8iEzhCcmTh9pyeeGXvZRryFAXJPoCXjMjdx5k9NUbmaNpxFgPxV1 kZsfcjqdBmdUUkAoZ5+cm8Unyq+WyM1SxDKIBOC6rctKVkGvOwZkPzX8MAOHDIDDr6jgFIsWYriR qIN89PMNCM37mEqvAMqOPruHGmuflfD4TF3yGkBWYYmoNG/+PJGo0IUPwImgKA/9hAECwIQRNw1j DoexDTR29FnJkHATvhiCcW8AeaWwKeFy+UQXAO/ckScqL8xCP2GBAmDDTeE7CmIOixY0dlmHiN0y u+G+gRFotqyoqKIcrgXgFGiBABW55V9Eto8CMO7CdTEuDWLDNgWA/4ZhlbgmNz8/P5ebV1qYLyot 68VHuNyiMsZHFCkDjGC4lrbXZQrioBe2HA5+GbEUgm4g1wdt+Bjgi/gpHDVFAHCM4220qY0EwOBM MdMSZRGdcBkHn4aVqDCFUy4oAEGcfnaSANDDaqNv//RCfmlpaRGnOL+Qz58/gbdViND6YWQASxCn P3w2YUGgCuLTLe+cOdbf0tLSlCsiFkgLR/DeklK27dkUAUzTSQCagzjW/w6l167hh+cAS3FRCjGI AgDvh77nTwJguO1QGODlte3zrsnn51twW14WMJqQPwmFAABvn35LDgigxXD9y2GAvXvfeePY4/09 etzVtPfMMQCa2lsASjIgAQQTAwAMV/S8RgFseIO8vKHCsR54PdS/F/qmH+GoDQIAwIP0WyEBYCa0 y1s2PAa1NuwJgI+3E9djJA7C2XcEgGZ8PBEATnRdJvmGnp4NPY/1gPZDZwibTcEgoFDO7O25vWmO +4SkJrU4lhiAuAbHXDaj0WJqP9TTBFpu71k7FgT9UBta2vt77rOx9+bsAEFGgJlfaidi4Myx13pG psHeQ4ce69+74atImcAOAGfj4YQAMfUO04GW9g09jz/owBUtrVqTzYV46hehKzbhDvohFAhAj7AJ LIhZcG1K5x0RAAYIazSAkQQAUEGVUZHSxy4QAByRfiQawJUYAG+26a4CAP0oVlIAhxYh9FMCcFkm dPSASgqQqhDWBc0q8JECTNtMFrpTMwiQWP8PAB/2T9MHkJazvR8WwKhqSxCaGQRw6W2qjH3IJZGm HaZ0fN4Sx/8H1sE8qeWajHQAAAAASUVORK5CYIIAbh7wqgoAAAXKxw/JlbzoOQLAAF9tmIP/iVBO Rw0KGgoAAAANSUhEUgAAAIAAAACACAMAAAD04JH5AAAABGdBTUEAALGIlZj0pgAAAwBQTFRFAAAA CAgIECk5GBgYGDkhIVp7KSkpMYy9OTEpOTk5OXtKQr3/Ur1rWlpac/+Ue2Nae3t7tZyEvb299861 ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdzDz0QAAAAlwSFlzAAAOwwAADsMBx2+oZAAABy9JREFU eJzFm4uWoyAMhqlKLfSCne77P+vKTQIhXNTO5Jzd7Xjq5CP5CRFZ9m+vLcsi2GrLsvtXaGN774vs twHs0KGJ3WHYA7Ck7o3tROgH+Mn730vQD0C430vQC/BD+9+nxd6bSv53EfTdQ6X/QBLOBdgRgr5b av6/DUD6/ahfAYAzQG1/rfb+fHaHoOcOqICPsfD5VwCQ/8/nrZR66w+7c3AQINgvALA/BoASvKXu 378AACWo9JDh2LcIdNfCdgCRAKgbU8oQmH++DwAlADSgYg38AQD7JQBGAqi/BfjEAGJxdhYAyxuc /xEAsGMAehCEc21qA0hKMWOT9J+aopAFKHjO5CAKwMtbKwEGCG23lPIBf18B4J36X21qIkAAm4tX ZAQAc39U7ibWooPkK4vN4uOVGgFws3rw/qfDADrwyHk9BVvS0nvqOYgBFhT6IwCvboCFDEAZQJ0F QPsvA7C/BQg1iCXinToBChlIATKjZ1g/8jwASQHAi1Pmrq8DQAJ0by9AQQOSyQm4urUowBTjswDS IOQA8C3sPIBHmgMFADj3OZDSf9187Ab4lx0HmgJ3GIMV4H6/ewQ7APDd4wBh6HxePc3m78E8EQMA zcBtJOSqllGIswDCsKHxkIMVLLpuDHRTxwDc8Ad+vzcB3E12xuXJ2FWIcTQwP/sBrP/Uu/VDAOgY CL2VK6zZgDQDLPE0mFziywDRN2aTgNH7F+I6XgwTFYhiP5AffQqQJsf00wLaWJBDCSCVXpxqCkAg /x4hm4kCgAS/e17nWBMAY89VAZcUYFMkgsA9YTYBPJmJFICbgtg/qUgM8AgJCPKaEwCeB+DrFFz9 jwTAGodLGoVUGds0kCi26VAzAHYK0v69HJYGgIkNicN4RrhirCAAtwm4FgH0zARTggSIHXI0I8Ha lPinFBCJYaEAFgeAI14HGNYEPNv8sx8agPk1CLrjqCb4n8N1MwNqCvAqIDVgAR64BtEAbq7MtgbW /YsLLIp5AImLME4Bj/6lamA2AYVZYJcjliwxGYAhAeC6Bj57E5AFYEgBcKDe+ObYg+BFiArAvwqA zKxC6EoCoNuQJgWmxTgHkPHPKwDcLPn9CSC3aDAAvgIB9k1BGmDL98wHewF1Jj4msy7Ztg0Z+xVA AWyJ94Y7Iw4qUbYNalIAAcC3sd/0O6F1wRkQwAwABq3AJdeG1BJAiNAPPnoCTgkCgBHAqoAdCcgD cNt/pI/ASYPsc2AbcdCJF/2LFoB79PAHn4GTvtCXINGmgBErIA9gxv/+xKZuTo8Ddza4j6tWxLPe hphFCDfG2RTkXssFMRC2SwEYwL6cUwSAjoQ273T9eAsI5TJ0zSWArIQ0QD4owvXcFQVg/5nterEN rhAHbzczBZxj++wxEoHIKiAHUMpzkh7F0Awgk5FPQF4Dk0x3hBCEflGjK+Qo7JGyMYzbxoFdxmuL f6opjTZH9Ee0OhhboldLSRjgFUIACEC/rol2+yb7nAAL8bxtiomnO1E3mj0AZgNxHWPI9dpVCwDV wBzAktsjkjGAL79h+GGQJcv7R1s0wPGWBwQQh3/EoYcBKPtPNyol3JsyP+kd2hjA1F7zhnRkieB1 sdGL1uCWMjNNVlnSEkgBNv9+7DYWEMAEffHnKXGxucO1TLlvtAH8OIDJClE/Hj0MAXhU5979U+ip FrnX8tOdy8CiVqIdwEcgEYIMAEF8Cx6+sMOP13L3tS6AoMSHkYFRhI/+uEV/TNbfq+sP9GL+jgCs ZpsBJNgqNCGAAEtG+9vwt2e03PsMwj/artdewV6lVkEK4JM/jqEAX8J+LotPF7gyRW6WZt4XxAAy TgH5Uh/MEhUD0OsAAnCFgMUA4VmVE85h287ibm798cJK29VZAEYAhMUoLopJmUj7lYL7FEAYgAc8 NmAB3Ahnlj6jaAewX59j/7oU9mzXo8XIA2y7IHinBm1WJwBF900AMpph97Lx+JzZ7VQAzuj9+xCR qJOsKaAfoOL/KICgAFoDcBSAlQBYQwCOA6AjCBvA3BaA7wG0KODbAFX/M0OHO4hmeAdASwA4BqiF oAHg5QHwRlETQDkGPQBVCSKASjOSA3ilAA+3dc3w/nUTgKosB5mOKAZ4ucWoRQJZgE/Hu2MaYGgG gP6V6U6OAxgR7AX4HAOYtjdILXXwCwDS9WgmBN0AVhE95wfQNJTbAyoDByk4sAKAOg2gvGNDArDT ANBZOoogAlBuZToE8HAXpqznyZ3v2hKBAN6dALktmlfZJIwCAvhUV+TiIRYzdvp0WYww2H3rdA50 A+ARVwkijaQAqhsAnylusMe2twkBbp/6owk+wtEw4GIgooWoJsEcQE11JZMBQG0ZKPrPnKA4QhAD NEjwbIBXALAKuFWPFmdfXp8DoFoCkH9jsp/AA4Qi1A1gX1gcBFChCNWONpOvbE6y6tHq3Iu0M63m P/ufXE70Xz9b/h+34EGt5rDVyQAAAABJRU5ErkJgggBuHvAYAQAASGM3rl515M6DXOsjAzNt3f+J UE5HDQoaCgAAAA1JSERSAAAAHgAAABAEAwAAAPMU0uEAAAAYUExURf/MABAAAP8AAJiYmP/NAP7L AP7+AP///yu9SYQAAAAIdFJOU/////////8A3oO9WQAAAAFiS0dEBxZhiOsAAAAMY21QUEpDbXAw NzEyAAAAB09tt6UAAABxSURBVBjTYygXhAHxciBgKGQNhYJEMF+AAQbYxMF8JgYmKF8YwlfA5Csx KDAwqEH5QMCggMpXUgASMPUMSkAD0PgKQB1siUALGUScGEDmgfhpQAFk94DcjMwXNjYGut8FBhzN QeYh/CcM4RcbwwDIfwCAqCZWOXu7ywAAAABJRU5ErkJggqBGHfDKFgAAMqKiwjSyMQY57tpNP6EI kv//2P/gABBKRklGAAEBAQBgAGAAAP/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8e HRocHCAkLicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/AABEIADgBSAMB IgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUE BAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1 Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOk paanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAf AQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQF ITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdI SUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1 tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APf6 KztD1m31/TBf2qSpEZZYsSgA5jkaM9CeMqce1R6Jr9rrx1L7LHKn9n30ljL5gAy6YyRgnjmq5Xr5 AN8V3txpvg7W760k8u5trCeaJ8A7XWNiDg8HkDrXzN/wtzx7/wBDDJ/4Cwf/ABFe/eKtcttR8L+O NMiSVZtN02ZJmYDaxeBmG3n09cV8vXuiXNjoelatK8Rg1PzvJVSdy+W+xt3GOvTGa9LA04NPnX9W uZzb6HRN8XfHoUn/AISF+n/PrB/8RX1Rp0rz6ZaSytukeFGY4xklQTXxnLotynhZNeLxfZZLtrMJ k794TfnGMYx719k6T/yBrH/r3j/9BFTj4wio8ituOF+p8x33xZ8dRajdRx+IHVEndVH2WDgBiB/B 7VX/AOFuePf+hhk/8BYP/iKxG0ifUrnxDdwvGsenF7iUOTllMuzC4HXLDriqdhpU2o22pTxPGq2F t9plDk5Zd6pgcdcuP1rvVKjb4V9xF2fXXgzULrVPBWj6hfTebcz2iSSyEBdzEcnAAA/CqOr+LWjZ odLjWVhwZ3zt/Ad/r/Oue0C+lufAnh/RrWRUb+y0nuCT/CFBCj6/4etWLK0+0zRW8ewM/ALdOma8 f2aUm2aXMLUtZ1+Yln1S5X2jbyx+S4rnpPF3ifTJN9vrNycfwy4lU/gwP6c1193afaJooE2h5XEa k9AScCuJ161Ntd3Fu+0tFI0bY6ZBI/pXVT5Xo0Szu/Bfxbg1jUE0nXY4LK8k+WCdWIimb+7g/db0 ycHp1wD5745+JnjLSfHGs6fY628Npb3BSKMW8LbVwOMlCe9cj4x0mXRtUutNuXjeWBgrGPO05APG fqKwZp77WL6W4mM93dPhpH2l2bAAycfQc10U8NSUudLRicnsdZ/wtzx7/wBDFJ/4Cwf/ABFH/C3P Hv8A0MMn/gLB/wDEVyLWN4iF3s7lVUZLNCwAH1xUFdHsaX8q+4m7O1/4W549/wChhf8A8BYP/iKP +FuePf8AoYZP/AWD/wCIriqsf2fff8+N1/35b/Cj2NL+VfcF2ex/Cn4geKvEXjqHTtW1drm0a3lc xmCJckAY5VQf1r2zV9XsNB0ufUtTuFt7SBdzu36ADqSegA5NfOnwTs7qH4kwPLazxp9lmG542UdB 3IrY/aC1ueXXNN0JXxawwC7dQfvSMWUZ+gU4/wB8151ahGeIUI6Kxado3G+JPj7qlzNJD4dsYrO3 HC3FyPMlb3C/dX6HdXDXXxK8a3km+XxLfA/9MSsQ/JABXLVseGPDOo+Ltbj0rTFj85lLs8rbUjQd WJ5PcDgHrXeqFGnG9kTdsmXxv4rRty+JNVB9ftb/AONX7T4oeN7I/uvEd23/AF2VJf8A0NTXar+z 1rJQF9esFbHIELkD8eKzL/4D+LrWMvbS6de/7EcxRv8Ax4AfrWftcLLTT7gtI6HUPiL4of4NWGvx 6gsGpyaobZ5o4E+aMK/G1gR2HIA6Vwn/AAtzx7/0MMn/AICwf/EV0PiPRtS0D4EWGn6raPa3Sa4S Y3IPBWTBBBII+leU0UKVKSb5U9WDbO1/4W549/6GGT/wFg/+Io/4W749/wChhf8A8BYP/iK5/wAN 6Dc+KPENpotnLDFcXRcI8xIQbUZznAJ6Ke1dJ4p+E3ibwppr6jcra3VlFjzZbWQnywTjJDAHHuM1 co4eMuVpX9AvIt6Z8bfGljMGuru31GPvHcW6Jx7GML+ua9x8CfEXSvHVo4t1a11CFd09nI2So/vK 2BuXPGeD6gZGfkqtPw/r194Z1y21bTnC3MBOAwyrAjBUjuCDWdfB05x91WYKTR9JfEL4p6d4KzY2 8a32sMuRbhsLCD0aQ9vUKOT7A5r5/wBc+IHirxDKzX2tXKxnpBbt5MYHphcZ/HJrn7m5nvbua6up nmuJnMksrnLOx6k0yOOSaVIoo3kkc7VRFJZj6ADrV0cLCktrvuDk2KssiSiVJHWQHIdWIYH1z1rs fDnxU8WeHJk26jJf2o+9bXrGQEezH5l/A49jWZN4D8W29k15N4c1JIFXczGE5A9SvUflXPVq1TqK zsxao+orX4lWfif4fa1qmjytZ6rZWUkj274Z4HCkhhkYZcjg4+oHSvEv+Fu+Pf8AoYZP/AWD/wCI rkrS9ubCWSS1maJpInhfb/Ejjayn1BBpI7K7ljDx2lw6HoyxMQfxArGnhadNu6uvMbk2dd/wtzx7 /wBDDJ/4Cwf/ABFH/C3PHv8A0MUn/gLB/wDEVx0tvPb486CWLd08xCufpmo619jS/lX3Cuztf+Fu ePf+hhk/8BYP/iKP+FuePf8AoYpP/AWD/wCIrjYoZp2KwxSSsBkiNCxA9eKm/s++/wCfG6/78N/h R7Gl/KvuC7PsbwveXGoeEdFvbuTzLm4sIJZXwBudo1JOBwMknpRUPgxWTwL4fVlKsNNtgQRgg+Ut FfPT+Jm6M74a/wDImJ/1+3v/AKUy1V+G/Xxd/wBjJef+yVa+Gv8AyJkf/X7e/wDpTLVX4b9fF3/Y yXn/ALJW0vt+v6i7GLqH3fi1/wBeQ/8ASM1434i/5Jt4H+l//wClFey6j934tf8AXkP/AEjNeNeI v+SbeB/pf/8ApRXdht16r/0kiWwk4z8G7Qf9R+T/ANECuk0n4jeLP+Ff63ef2u3n2VxZQ27+TH8i NvDDG3nO0dfSubm/5I5Z/wDYfk/9ECodJZf+FZeKOR/x+2Hf3lrolCMou66/qTcf4YkebQfG0sh3 O+mqzH1JuEJqv4X/AOQP4u/7Ax/9KIam8Kf8i34z/wCwWn/o+OofC/8AyB/F3/YGP/pRDVv7Xqv0 A9U+H0xSNYncsY9McEk+kYH+fpXTeG74SaxZpnksf5GuB8AXwku7nn/mF3Df+Q61vBeoCTxVpse7 70h7/wCya4KsNZFJmrBfCTW7Bc9buIf+PiuQ8WTj+3tSGel5KP8Ax81PpeoB/EelrnrfQDk/9NFr nvF14B4m1cZ6X84/8iNWlOFpg3oQfFhx/wAJ7rC/9Nl/9AWovg9qkmm/E/S1VysV2JLaUf3gVJUf 99KtQ/FaTPxJ1tfSZf8A0BarfC63e6+J+gInJFyZD9FRmP6CtZ2+rpeX6CW59M/EL/knfiH/ALB8 3/oJr4/HSvsD4hf8k78Q/wDXhN/6Ca+P+1Z5d8D9QnuNk/1bfQ19xWv/AB6Q/wDXNf5V8Oyf6tvo a+4bX/jzh/65r/KozL7Pz/QdMmr56/aB0ieHxJpusBP9GuLX7MWA6SIzNz9Q3H+6a+hayPE3hyw8 V6DcaRqCnyZgCHXG6Nh0ZSehH+I71xYer7KopMuSuj4xq3pmqX+jahHf6bdy2t1HnbLGcEZ6j3Hs a7nxF8F/FeiyyNZW66taDlZLY/vMe8Z5z/u5rhL3Tr7TZDHf2N1aOOq3ELRkfgwFe7GpCovddzGz R6Ppnx48WWe1b6Gw1BO5eIxOfxU4/wDHa77w/wDHnw/qUqQavaz6VIxx5pIlh/Fhgj8Rj3r5xorG eDoy6W9BqTPoz48Tw3Xw60+e3ljlhk1CJkkjYMrAxyYII4Ir5zrfXxLLJ4Bk8Mzszxx38d5bEknY Njq6c9BkqwA7lvWsCrw1J0ocj7hJ3dztfhF/yVXQv96b/wBESV7p8W9a02x+H+rWdxeQJdXUPlQQ FwXdiR0Xrx69BXyuCVOVJBHcHFISWbcxJb1JyairhlUqqo3sClZWCiilwdobBwTgHHFdRIlfSPwU 8GWmleGYPENxCr6lqCl0dxkxQ5woX03D5ie+QO1fN1fW/wAMNTg1T4caJLCwJht1t5FB5V4/lIPp 0z9CK4cwlJU0l1LhuddXgvx28GWll5HiiwhSEzzeTeogwGcglZMepwQT3yPeveq8q+PepQW3geDT 2ZTcXl2mxO+1MszfQHaP+BV52ElJVlYuWx8319IfAPUnuvA9zZOxIsrx1QE9FcB//Qi1fN9fQn7P ULr4Z1eYjCSXoVT64Rc/zr08el7FkQ3Mz9or73hz/t5/9p14dXuP7RX3vDn/AG8f+068OqsF/Aj/ AF1FPc9Y/Z+/5HjUP+wa3/oyOvo2vnL9n7/keNQ/7Brf+jI6+ja83H/xmaQ2CiiiuMo5zwNpt3pP hhLS+hMM4urqQoSD8rzyMp49VIP41B4I0m+0k+I/tsHlfa9cubqD5gd8TbdrcdM4NdVRVuo3fzFY 861rS7yz074m3txCUt72wLW77gd4W1ZW47YPrXgetapZ3Xgfwpp8Mwe6sRefaI8EbN825eehyOeK +ovHP/JP/En/AGC7r/0U1fHNengffTb6W/KxE9Dop9Ts2+GNvpImH25NXkuWiweIzCFDZ6deK+rN J0rTv7DtE+wWuySGNnXyVwxC8EjHPU18YP8AcP0r7a0n/kDWP/XvH/6CKnMFyqNu7CB8n6fqFnYw +NLaeURyXcDQ26YPzsLhWwMdOAfyqloF/bWem+I4riUI93pnkQDB+d/OibH5KT+FZupf8ha+/wCv iT/0I1V7V6CgrepFz1Wwgg8IjTtVupPJ0/V/D8gifaSBcGIApwOCTgj/AHj6VleCvEVppvi3TLu/ n8m1ikJkcgnaNpHQZr2jQ/DWneLPg/oulakhaKSxiZHTh4nA4ZT2I/XkdDXz74x8B674Iu2W/gaW xLYivoVJicds/wBxvY++MjmuKlUhUcoSeuxTTWpY0nXYbXxHpd1cS7IIb6GWRzztQSKWPHPQVleJ tVjv/E2rXNtJvt5r6eSN8EbkaRipx9CKwvMzTC3rwK6vdTuhHS/EDVLPWvHer6hp8wmtJ5Q0cgBG 4bVHQ89Qa9H/AGf/AAtJLqN54nuIiIYUNtakj7zn77D6DAz/ALR9K4r4f/DTU/HF6sjLLZ6OnMt4 yEb/APZjyMM3v0H6H6p0vS7LRdLt9N063W3tLdNkca9AP6knJJ7k152JqqMfZouK6mN8Qv8Aknfi H/rwm/8AQTXx+K+wPiF/yTvxD/14Tf8AoJr4/rfLvgfqTPcbJ/q2+hr7itf+POH/AK5r/Kvh2T/V t9DX3Da/8ecH/XNf5VGZfZ+f6Dpk1ef+NvilbeB/Etrpt7ps1xbT2wnM0Djep3spG04B6eor0Cvn P9oMgeNNNJ4/4l4/9GPXJhKcalTllsVJ2R6fYfGTwPfIC2rNauRylzA6Efjgj8jV+f4i+BZoSs+v 6bJGRyrNuB/DFfJFFeg8up30bI52dr8TdR8I6l4hil8JWqwxLGRcyRReVFI+RgomBjAzk4Gf1PFU VoaNoeqeIb5bLSLGa8nOMiNeFHTLN0Ue5NdkYqnC19F3J3ZRCMyM4UlVxuOOBnpTa9Z8Z+AU8DfC a3SeRJtTu9The6lT7q4jkwi+oGTz3JPsB5NSp1FUV47A1Y0/DmkDXvEmnaQZjALydYjKF3bM98ZG a9i/4Z1j/wChnk/8Ah/8XXl/w7/5KN4e/wCv1K+wK4cbXqU5pQdi4JNankOl/s/aFbTCTUtUvr4A 58tAsKn2OMn8iKd8X/A1ovw/tptEsY7dNFcyeTCmB5LACQ+5GFYk+hJr1ymuiSRtHIqujAhlYZBB 7EVwrFVOdSk72K5VY+HK6zwP8QNW8DXkjWYS4spyDPaSkhWI/iU/wtjjPfuDgY6H4l/Cm88M3U+q 6NA9xojkuUTLPaexHUp6N26H1PmQORkV7cZU68O6Zlqme/zftDaYLItBoN6bvHCSSII8+7DJx+Fe M+KPFGqeLtZfU9VlVpMbY40GEiT+6o9P1NY1HUgDkk4AHeppYenSd4oHJsOTwAST0A6mvrr4ceG3 8K+BtP06dAt2yme5x/z0c5IP0GF/4DXm/wAKPhPcQ3cHiPxHbmIxESWdlIPm3dpJB2x2Xrnk4xXu defjsQp/u47I0hG2p4X+0V97w5/28f8AtOvDq9x/aK+94c/7eP8A2nXh1duC/gR/rqRPc9Y/Z+/5 HjUP+wa3/oyOvo2vnL9n7/keNQ/7Brf+jI6+ja83H/xmaQ2CiiiuMoKKKKAIrm3hvLWW2uYklgmQ xyRuMq6kYII7gisD/hX/AIO/6FfSP/ARP8KKKpSktmAf8K+8Hf8AQr6R/wCAif4V0UaJFGscahUU BVUDAAHaiihyk92Bz7+AvCEkjO/hnSWdiSzG0Qkk9+lN/wCFf+Dv+hX0j/wET/Ciin7SfdhY3rW0 t7G0itbSGOC3iUJHFGoVUUdAAOgqSSOOaJopUV43BVlYZDD0IooqAOQ1D4U+B9SmM0/h62Vz1Nu7 wg/gjAU7Tfhb4J0mcTWvh62Mg5DTs0+D7bycUUVftJ2tdisjrlVUUKqhVUYAAwAKWiioGQ3Vrb31 rLa3UMc1vKpSSKRdyup6gg9RWD/wr/wd/wBCvpH/AICJ/hRRVKUlswD/AIV94O/6FfSP/ARP8K6N VCqFUAADAA7UUUnJvdgLUNzaW17F5V1bxTx/3JUDD8jRRSA529+HHg2/JM/hzTwxOS0UXlk/iuKz D8G/AR/5gRH0vJ//AIuiitFWqLaT+8VkWLT4T+BrKUSR+Hrd2HaeSSYfk7EfpXWWlna2EAgs7aG3 hHSOJAij8BRRSlOUvidx2IdU0fTdbtVttUsLe9gVxIsdxGHUMAQDg98E/nWR/wAK/wDB3/Qr6R/4 CJ/hRRSU5LRMCa08E+FrG7iurTw9pkFxEwaOWO2RWUjuCBxW9RRScm92AUUUUgCuH134SeD9emad 9NNncN1ksn8rP1X7v6UUVUJyg7xdgauc4v7PvhsShm1TVmTP3N8Y/XZXZeHPh14X8LSCfTtMQ3Q/ 5eZ2Mkg+hP3fwxRRWksRVmrSkKyOpooorEZm6r4e0bXfK/tbS7O+8nPl/aIVfZnGcZHGcD8qzf8A hX/g7/oV9I/8BE/wooqlOSVkwsXtL8L6Doly1xpWj2NlM6bGkt4FRiuQcEgdMgflWtRRSbb1YBRR RSA//9kAbh7wEgsAADdsb01sucA69ump+e0VAC//iVBORw0KGgoAAAANSUhEUgAAAIoAAAAwCAMA AAD5CBJFAAADAFBMVEX/1BbZpjaoUwH//PP/4U64czbDegFGSIzU1OT/1Tj/1QHdpgDsswD/zADR jQLit2Xi4u3jrQGTlb17fK7cq1TxvQDluDjx8fbSmDf+5JLktEejSQDz8/j+5oL/+7W0tdHYo1DE xNv+7b3/+uvMkDzXt4rHhSXTm0Xr1rqbnMGDhbLz1oSho8WXOgD/+uT+9uPkyqndnQD/0iL/9b// 9dr/85X//v2rrMv//fnd3uvt1afTlBn+3WS9dQK6u9X+89Lu7vT+4X1rbKPSlSr/8rz/+dO0fhr/ 66I+QYj/5WD+44n/8s3/8qvIl1fo6fH5xQApLHz/8qD+3XH/7pHNnGb/20Xrv0T/1StiZJ7ryXbI lyu5bAE6PYbu2rhzdan/7sL/+tvLzN+Ki7dSVJTkt1Z0dL7y5dTZuWzpwmjkmAf/+77/64v/7bXJ ggDGiDD2ymrRqGGyYAAOEWr+21sTFm3DjhbKoHT/3zatrdr/1UMYGnD52mzw4My8hkbruh737tTD fBXMlAD/6pm8iyr/6nry2ZP79e3v5dn7+/3+43fFjAH879S7ggIzNYH10lz+6JicQADEi1W2axvV ngDixJr/6oW1ZwHWrXD37uPPz+FbXZnjpgDVrH7+667/5qAhJHbsw1bVq4XwtwD4+futcgD/6W02 OIOyZA3Dh0dOUZLevZstMH0dIHR3eavOiABWWJZfYZyyss9xc6ePkLr/2E6sWxR+gLD+3n2/wNf7 1lauXAL/104IDGwnKXrWlQD/zwokJ3iGiLXr6/Ntb6Woqcmur82mp8hKTY/Y2ef7yxT/+MX//M/2 vQD1zz8vMn7aw6T8+veoawW1aAv01mL00mn29vn/7Gbv4bznrADPkj7+56vct08AAnL/7HDcphWO j7n/96T41HH22nzy0XP16dm2t9P1vwDlz7X62FTasXr06tDW1+bSpnTTp3j/8Me5cBDAfSwjK4Fl Z6Dzxy7sqi7tvSzn6PDl5e/cngrfvYD/5mvs2MFkZ6P/9q9iYq7///8nIhTHAAABAHRSTlP///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////8AU/cHJQAAAAFiS0dE/6UH8sUAAAAMY21QUEpDbXAwNzEy AAAAA0gAc7wAAAaLSURBVFhH7Zd/XMx3HMdPpWvpVFeEainROqcfNJVJ50LXD5yKju6RfliMZbyL 5jDJrzRHDOn8OFM7S79rThKVo5hYM/kxW7NZzTQ/Nr+G2Xuf712IftzXPHj4o9f37vv5fO7e3+/7 +Xm/35/7fo6Bb4wYbwwJdqK0lYvOqHRGhe4apV0rHh61zs5u3gHXp061e6ypo64HeHu7OfXT1R1K 12H7dlpRhnr0cwuYavf9jh07fH0DAx89ertNzZw580SEk67HSxB1gOLh7BYwavuO3pTW+QZeunRp QlLvgZeNjY3Nzfs6OFxwuGBvT172Fxwc+vY1Nzc2njxwRVIgISJI/4eoPRTn6769/dWaNSs4+N1g 68szzH0GbCjVsUwlGvS8UgeRI9Wy9MbNXuYzfvEPfjQk4oVx2kIZGrHdfx/RSOtNwZs2WY8806fX ht06qZaDUi0tdXR0SnVKS3dv6Gq/PiTkj20aXQsJWf/l4g171ZyWpacTu0z72TppiNML5asVivMo 331BC4OCglYvX7584c4uPgPCSCQIQ+nc0zdmj03rv9HlnUVb2knAypiHw1z2fD5/fde9cxN9evU5 kzQkgnZBP4sy1G3dcKK4Bw+++PHB/j4+p3XUDJvDwhLt52w8t5J+CdTGuFxbT/HsXBhIk6Ylisdo /7i4/XFXhvudHb6/Z5cbJBObw7y8vBJnp7n8Sp/iqWVtzJ6Qm4k+J1eP6kfj8hYodkFfER04oOen d+e9xLDSuWFe+vr6ve6f2/JCKX/e6ZaHv9v7TLIerRXmCYpH7wMLKE08S0DCNm8O09fPy+tuPEzr HegYLErzmbTOSYvlYxSnuLfUSki4Ve9FYcTmfXD7o0/p+KFnM2zaQO+Oo9uMorsglOhWaEJofax+ bGxeXkqezwp6PmhbLbHruGKaUfwGUwplDHbVj+2u1jRn4sOKh8gzIW8LKysrCx4P6yys6kjvrgVt APqGGpQPGcePD2YwGMf/zut+SK3JiB//KRYLCj3lp2zchQoBUXaWY7W6oxBWUpyHtbu5V/WsUWGJ tsfhxPLycla5YXl93iFX9UElR1AG8cDhAnAFoFF8fnMHOHiX9Ku1wuRC0xPfybaIEK0NZTCLyJDF IhSuW11dXddSF+SUEcdKM8g24P7DJF2RjGsjUkkAmCp+Bh4k41wSmse3Tm7Th0EVYh2xGUe+zVXw 8MgxRE1yKftn46pJ0JXG8ZR2bXXdSsl0CfnMhPiUQj4TmGQQRQYaZ9kAnqQJBzJHHJEdL7awYEqz +VkVxSiTKwqi4ysP59tiVnGhQlHBRlkVikFkUFShOMoGKD4cjUcl8mg0UeTIi5M5EmFLfg3K1R6U Gk3Pa3Sbem64A/xUDdlC+IsMSDbMNJMBkJDmnkREnUGWDrk2UKUCtiw+EkRKKKo+yJUYJAM7HEZI IQM4bOCOQ890scgWqtFRHgkqW4gqAUdlTi5EkVXxVM0raK2RUQ9To11Gap2/Q30fDpLIaKo2SBp4 pwDc1ReNAKCmEglsci4CHgoEIjFWSpAjdJdgIWkVuQL0hHRmOOE/fJArJRXepFJBpSe5QzSfTyaS JY5iYonQViwki7MVCk4yJSEx3VWzi5IR9QMgLBMiVSKUU1vSaOovlxSrOipScpblIEpU8mIUipCZ X8xEfjTKRLJoZOeMg0isKIiUewIX78Urj4GjI0lsTlV+BaldZZYS+QJyLRm0RtHt2Y3ItIbVWFPT 2OiPeOyHMgVWUCgNiGYApzTBzAEoolpHADk7PV4IwkhSNcQfmIn5GM9HSSUXpMBsgDoEtlJCZlPA kRyshoajUJAOTSUgAKEBmZ5QWlkN4rZQECd/RtSthsUaP76xZgLWvv9vAxb/Y1YURRaADb9Akx/k qFTp6s4RhXQElkiZvDplXUY4D5VN7HTkpGPlMVTlh9tGRmGG2b3CKjRhCgxKqs1IWcjMDJRWyM0u sLLim6BjA0de1FatUDdfeXHpoaUppixDQ9Z4w+9a8r6e/jNbp6tdUlLWrDE9nmDIMJx44vUAtK6V 5k/OTZ+yJnNe/SehCQkM64jXC9N6mx0zfUxm5pr6k3p6eqtfK0ybO/5zc8Z8mzmv51o/v1lf094l v3QI2/sfFOPSf+yyeVP67AyaMKTfS20oaSN29Ec1edU38xePWXZxxgq7CN3aVx6ejlDU86lb9du2 tPvDlrz60GhFoR3flzbsRGkrhJ1R6YwK3aXVWStveK38B1pihgx2orCVAAAAAElFTkSuQmCCAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A6ANzNwAAAQDpAygAAABgGAAA4BAAAOAQAABvFgAABQAA AAoAAAADAAAABAAAAAEAAgAAAAAADwAJBGwBAAAAAAoEBAAAAOwEAAAPAMwPjgAAAAAAzQ8IAAAA AAAAAAEAAAABAMMPGAAAAAEAAAAAAAAAjgAAAAAAAAAeAAAAAA8AABAAug8WAAAA0zDDMMgw3jDD MNcwIACkMOEw/DC4MCAAug8aAAAAUABhAGkAbgB0AC4AUABpAGMAdAB1AHIAZQAwALoPFgAAANMw wzDIMN4wwzDXMCAApDDhMPwwuDAPAMwPwgAAAAAAzQ8IAAAAAAAAAAEBAAABAMMPGAAAAAEAAAAA AAAA6AQAAAAAAABPAQAAAA8AABAAug8kAAAAUABoAG8AdABvACAARQBkAGkAdABvAHIAIABQAGgA bwB0AG8AIAC6DxYAAABNAFMAUABoAG8AdABvAEUAZAAuADMAMAC6D0AAAABNAGkAYwByAG8AcwBv AGYAdAAgAFAAaABvAHQAbwAgAEUAZABpAHQAbwByACAAMwAuADAAIABQAGgAbwB0AG8ADwDyA9wC AAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QcUAgAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAg AFIAbwBtAGEAbgAAAAi4EwDwtxMAFucHMAgAAAAAAAAACLgTAHpbCTAAuBMAAAAEEhAAtw9EAAAA Lf8z/yAAMP+0MLcwwzCvMAAAIABSAG8AbQBhAG4AAAAIuBMA8LcTABbnBzAIAAAAAAAAAAi4EwB6 WwkwALgTAIAABDIgALcPRAAAAC3/M/8gADD/DmYdZwAArzAAACAAUgBvAG0AYQBuAAAACLgTAPC3 EwAW5wcwCAAAAAAAAAAIuBMAelsJMAC4EwCAAAQSMAC3D0QAAABBAHIAaQBhAGwAIABCAGwAYQBj AGsAAABtAGEAbgAAAAi4EwDwtxMAFucHMAgAAAAAAAAACLgTAHpbCTAAuBMAAAAEIkAAtw9EAAAA VABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBhAG4AAAAIuBMA8LcTABbnBzAIAAAAAAAAAAi4EwB6 WwkwALgTAAAABCJQALcPRAAAAEEAcgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAAATAPC3 EwAW5wcwCAAAAAAAAAAIuBMAelsJMAC4EwABAAAAYAC3D0QAAAAt/zP/IAAOZh1nAABVAG4AaQBj AG8AZABlACAATQBTAAAAEwDwtxMAFucHMAgAAAAAAAAACLgTAHpbCTAAuBMAgAAEEQAApA8IAAAA gABAAIAAAAAAAKUPDAAAAAAAAAguAAAAAgAAAAAAqQ8KAAAABwAAAAIAEQQJBEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wCAAAAAAQAAAP//GAAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABfAOQHPgcA AAAA5QcEAAAAAQAAAA8A5gcqBwAAAAC6DxQAAAB3AGgAbwBvAHMAaAAuAHcAYQB2ABAAug8IAAAA LgBXAEEAVgAgALoPAgAAADEAMAC6DwYAAAAxADAAMwAAAOcH3gYAAFJJRkbWBgAAV0FWRWZtdCAQ AAAAAQABABErAAARKwAAAQAIAGRhdGGyBgAAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA foCAgICAgICAgICAfn6AfoCAgIB+gH6AgICAgH5+fn5+fn5+gH6AgICAgH5+gICAgICAgICAgICA gICAgICAgH6AgICAgICAgICAgH5+gIB+fn6AgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA gICAgICAgICAgH5+foCAgICAgICCgoB+fHx8fn5+foCChoiGgn56dnR2eHp8foKIjI6QjIJ6dnJu bHJ2fISIkJSUjoiAfHZ0cnBwdHp+gIiQkIqEgHx4dnR2fH5+goaGhIKChoiGgHp4dnZ2enx+goSG jJKOioJ4cmxobnR6goqSkpCIgHp2cnJwcHJyeH6IkJKYnJCOfGpbUVVffJy1u6uljmJJQ0NZhKOx t6uIbltJQ1l+lqu7sZJ6bG5oXV9ygJKep6OYmJR8XVNVU1NqiIaWlHp8kJqIhoSChHhfX2x+mKmv mHZfXWRyipKGjIpuVWJ8gparsY5uZmRfXYSrs6GlgmRdNT1ycpi7q4xual1qeoycoYh+lGxNbIya nJCCZHKUnpiKeFtbX2Z8paWcgllRZldLX5K7p5qhiHhoW3qhvZ6OlnhbQ0lqiJSUpaeYenh4hGRT UXqxxXxfZkk5V6/TuYhNO1FumsHV5r92SztPVXiGfpS9p3hqXV1ZU36tybWnlGxNP3CvtaVsTTtD R3C15tm1jFspEktopbnV33wlDCU7eLvZ5L10S1FTXZ7f5smWYkdyfIpsU252eo6voX5uZlNbboie w6t4OxpBeqGvv449K0FZksndu3w9Lxgxcsf88rlfEgAKP3yl1ea9hFc1L0N6rdPVw6NmKRQvcI6h v7WedmJNUXKInqmhmJiOinxPPU+Ws5Z0amRoapyvq7e1lmxHP0dfjLnD0cmKSxQIM4TT8tecZFFD TXCMp7O3t6uGcFc7MVOa0dnFt5BBDg5NmrfV6tF6LyM/Ynilx82WU0FNW2h2kqWzq6GciGhZcH5+ eoieinJ2gIB0W11wjJirt550V09VdIyamJSCeHhkXXaIfnZ2eJ6nioB6ZF94jox6aF9uhpaemIiC clNRbJCaoZyOdGJkcIZ+X2yEiIicmnJRX2xdW4q1s450Zl1XXX6rt6eCaFdmcHyhmpCEZldobmiA ioiIoaOYgGJVW2h6jKOhlohsU0NXjq+ro56AYllibniUpZRwZGhqdoyprZ6Gak05T3SElKu7tZqA XUdRW2RwcH6cra+pmoJoaGhkcHh+hpacmpSMeGhdWW6CkJicjoyGgHRucoqajnBdZGx2lq+rp4Zq UU1ifIyQmpiWkop2ZGpwgIqIioR6eHp6goqIkpaKdGxqcnyImp6YfF9bcn6CkJyYmJJ+amJfanyM mKOUenx4cHB+foCSnpSUjHZdV2h8io6Sjnx6eIKChI6GfHh8gIR6gIiEem5kaHB4iIyaraeOcl1Z Zm50ipiWhIB6amx8gHqCjIqEfHx+hIiGgnZwcG5yeoaMjpSShHBocnh6fISGgICAfoKGhoaEfHh0 cmpqdHZ+io6OlI5+dnp8enyAgHx4cnJ2foiEhoyKgHhycHJ0eoSMjIaCgIB8fHx2eoKAeHZ4fICG iIiGiIR4dHh+fn5+fn5+gISEgoCAenh4eHiAhoqKhIB8enh6fn6Ciop+cnJ6gH6AhIJ8eHp+foCG hoSAfHZ0eHyAhISCgoB6eHp8fn5+gISGhIB8gIB8enh8fHx+gICAgIKAgIKAgH56enx6en6ChoaE gH5+fnx+gIB+fHx+gICCiIZ+fHx6enyAgoKAfnx8en5+foSIioqEfnp4enp8foCAgoKCgoKCgoKA fn5+fH5+gISEgoB+fH6AgoKAgoSCgHx8fn6AgoKCgoB+gIKEgn5+foCAgICAgICCgoKCgIB+fn5+ gICEgoKCgoJ+foCCfoCAfHx8gIKCgoCAgH6AgIB+gICAgICAfn6Afn5+foCAfoCAgICAgICAgH5+ fn58fH6AgoKCgH58fH58fH6AgoKCgH5+fnx8fH5+foCAgICAgIB+fHx8fH6AgIB+gICAfn6AgH5+ fHx8fH5+fn5+gIB+fn5+fn58fn5+gICAgoKAfnx6en6AgICCgH5+fn5+gH58fHx8foCCgIB+fHx+ foCAgoCAfn5+fHx8fn5+foCAgoKAfnx8fH58foCCgoB8fn5+gH58enx+fn5+gICAgIB+fn58fHx+ foCAgICAfn5+fn5+gIKEgHx8fn5+fn6AfoCAgH5+gA8ACwTMDwAADwAA8MQPAAAAAAbwoAsAAATI BQBzAQAA6wIAAAoAAAABAAAAFwAAAAEAAAAGAAAAFQAAAAgAAAAMAAAACAAAAAAAAAACAAAADAAA AAgAAAAAAAAABAAAAAAAAAACAAAAAAAAAFsAAAAAAAAACwAAAAAAAAALAAAAAAAAACoAAAAAAAAA DAAAAAAAAAAKAAAAAAAAAAcAAAAAAAAA3gAAAAAAAAAEAAAAAAAAANcAAAAAAAAA2AAAAAAAAADZ AAAAAAAAAAYAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAABQAAAAAAAAAKAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAA AAAAAAAvAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAAKgAAAAAAAAAEAAAA AAAAAE4BAAAAAAAABQAAAAAAAAAFAAAAAAAAAAcAAAAAAAAAVQAAAAAAAAAEAAAAAAAAAAoAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAHkAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAkAAAAAAAAANQAAAAAAAAAABAAAAAAAANQAAAAAAAAA CwAAAAAAAAAFAAAAAAAAAAoAAAAAAAAABAAAAAAAAAALAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAE AAAAAAAAAAUAAAAAAAAABQAAAAAAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAMA AAAAAAAAAwAAAAAAAAAJAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABwAA AAAAAADYAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAUAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAA AAAABQAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABQAAAAAA AAAFAAAAAAAAAAoAAAAAAAAABwAAAAAAAAASAAAAAAAAAA0AAAAAAAAABgAAAAAAAAAKAAAAAAAA AAUAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAMAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAMAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAW AAAAAAAAAAUAAAAAAAAADgAAAAAAAAAEAAAAAAAAAAgAAAAAAAAAAwAAAAAAAAAbAAAAAAAAADEA AAAAAAAABQAAAAAAAAAFAAAAAAAAABQAAAAAAAAABgAAAAAAAAAPAAAAAAAAABQAAAAAAAAABQAA AAAAAAAFAAAAAAAAAAUAAAAAAAAAHwAAAAAAAAAhAAAAAAAAAAUAAAAAAAAABAAAAAAAAAARAAAA AAAAAAUAAAAAAAAARgEAAAAAAAARAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAD AAAABwAAAAAAAAAEAAAAAwAAAAQAAAAAAAAABAAAAAYAAAAFAAAAAAAAAAQAAAAAAAAAIQAAAAAA AAAEAAAAAAAAABYAAAAAAAAABQAAAAAAAAALAAAAAAAAAAQAAAAAAAAABAAAAAAAAABGAQAAAAAA ACMAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAIAAAAAAAAABAAAAAAAAAACAAAAAAAAAG4BAAAAAAAA CgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAABzAAAAAAAAACYAAAAGAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAYAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQA AAAAAAAABgAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACoAAAAAAAAABAAA AAAAAABqAAAAAAAAAAQAAAAAAAAAagAAAAAAAAAEAAAAAAAAAGoAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAQAAAAAAAAAAwAAAAAAAAAGAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAHAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAABUAAAAAAAAABAAAAAAAAACNAAAAAAAA AAQAAAAAAAAAhQAAAAAAAAAEAAAAAAAAADsCAAAAAAAAAwAAAAAAAAAEAAAAAAAAABcAAAAAAAAA EQAAAAAAAACbAgAAAAAAAD0AAAAAAAAABwAAAAAAAAAJAAAAAAAAAAMAAAAAAAAAFAAAAAAAAAAJ AAAAAAAAAAMAAAAAAAAABAAAAAAAAAAEAAAAAAAAAD8AAAAAAAAABAAAAAAAAAAGAAAAAAAAAAsA AAAAAAAABQAAAAAAAAAEAAAAAAAAAAYAAAAAAAAAxQEAAAAAAAD+AAAAAAAAAAAEAAAAAAAAagEA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAA9AAAAAAAAAPUAAAAAAAAABQAAAAAAAAAFAAAA AAAAAAoAAAAAAAAABwAAAAAAAAAFAAAAAAAAADsAAAAAAAAABAAAAAAAAAAbAAAAAAAAAAQAAAAA AAAABwAAAAAAAAAQAAAAAAAAABEAAAAAAAAAOgAAAAAAAAAVAAAAAAAAAAkAAAAAAAAABgAAAAAA AAAEAAAAAAAAAAQAAAAAAAAAHAAAAAAAAAAEAAAAAAAAAA8AAAAAAAAAFAAAAAAAAAAKAAAAAAAA AAQAAAAAAAAADwAAAAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAADAAAAAAAAAAQAAAAAAAAA CAAAAAAAAAAHAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAsAAAAAAAAAAQAAAAAAAAAAwAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAUA AAAAAAAABAAAAAAAAAAFAAAAAAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAACMAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAUAAAAAAAAABAAAAAAAAAAFAAAAAAAAAGsAAAAAAAAABAAAAAAAAAAFAAAA AAAAAAQAAAAAAAAABQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABwAAAAAAAAAEAAAAAAAAAAUAAAAA AAAABAAAAAAAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAYAAAAAAAAAxQEAAAAA AAD+AAAAAAAAAAAEAAAAAAAAagEAAAAAAAByAAAAAAAAACcAAAAAAAAABQAAAAAAAAAEAAAAAAAA AAUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAcAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQAAAAAAAAA CgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAoAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAC/AAAABAAAAMAAAABqAQAAwQAAAEQBAAAAAAAABAAAAMMAAAAEAAAAAAAAAAQA AADFAAAABAAAAF8BAfCcAwAAYgAH8CQAAAAGBjwgDsnOVVsOCNMt7QKaRpr/AAQEAAABAAAAAAAA AAAAAABiAAfwJAAAAAYGGoiJrOuonVjD7kWnYXCpa/8ANAQAAAEAAAAEBAAAAAAAAGIAB/AkAAAA BgZnViI1jqJOHy/BdYRyWY21/wChAwAAAQAAADgIAAAAAAAAYgAH8CQAAAAGBmFboKUia4mVu1MM QGXdsfn/ADsJAAACAAAA2QsAAAAAAABiAAfwJAAAAAYGqFlgZsZin5fKFicOaELhYv8AigoAAAIA AAAUFQAAAAAAADIAB/AkAAAAAwRV2x0GLD9hnIA789zmsZ6v/wAPBwAAAgAAAJ4fAAAAAAAAYgAH 8CQAAAAGBpH2ttqXZlQvQp6s9y4+I5n/AEkPAAABAAAArSYAAAAAAABSAAfwJAAAAAUFxH+YSkwR ufLHq3g/np/Mf/8ARRkAAAEAAAD2NQAAAAAAAGIAB/AkAAAABgbYO7XFa0kDSfjMlAkIRk6J/wDo BAAAAgAAADtPAAAAAAAAYgAH8CQAAAAGBtIMpBKLXdg3Cre1UYLbVUv/AEddAAABAAAAI1QAAAAA AABSAAfwJAAAAAUFktkGp9ozZocSWYkB8nH8O/8Ahg0AAAEAAABqsQAAAAAAAFIAB/AkAAAABQWV 0HfBNcnzrfYUiYU16TQ//wDkKAAAAQAAAPC+AAAAAAAAYgAH8CQAAAAGBivYEu8FGw/t6S6yccYD J5f/ADgRAAABAAAA1OcAAAAAAABiAAfwJAAAAAYGBcrHD8mVvOg5AsAAX22Yg/8AsgoAAAEAAAAM +QAAAAAAAGIAB/AkAAAABgZIYzeuXnXkzoNc6yMDM23d/wAgAQAAAgAAAL4DAQAAAAAAUgAH8CQA AAAFBTKiosI0sjEGOe7aTT+hCJL/ANIWAAABAAAA3gQBAAAAAAACAAfwJAAAAAAAAAAAAAAAAAAA AAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAA AAAAAAAAAAAAAAAAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAAAAC AAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAAAGIAB/AkAAAABgY3bG9N bLnAOvbpqfntFQAv/wAaCwAAAQAAALAbAQAAAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ ARAAEADAAQEAAAjFQQAAAAD/AQgACAABAgIAAAiAABrxIAAAAP/MzAD/MwAAmf9mAP9mmQCZzP8A /wAAAADMmQD//2YAQAAe8RAAAAAAAAAI/zMAAP/////3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAE AAAAAAAAAAAAAIAAAAAADwDQB1wCAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAABAAAADwD6A2cA AAAAAP4DAwAAAAABAAAA/QM0AAAATAAAAGQAAABMAAAAZAAAAAgAAAAAAAAAILgTAHpbCTAAAAAA AAAAAGT///+a////AQATAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAAAwDAAAHwAIBDwAAAAA AP0DNAAAAEIAAABkAAAAQgAAAGQAAABMuBMA3x0JMIi5EwCwLJ0AAAAAAAAAAAAAAAAAag4AAAAA EwAfAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAACAAAAAAAAAAguBMA elsJMAAAAAAAAAAArPn//8T///8AABMAcAD7AwgAAAAAAAAAOAsAAHAA+wMIAAAAAQAAAHAIAAAf AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAEy4EwDfHQkwiLkTALAsnQAAAAAAAAAAAAAA AAAAAAAAAAETAB8AFAQcAAAAAAAVBBQAAABGbE8JAMqaO60HlMcAypo7AQEAAB8AEwQ8AAAAAAD9 AzQAAABkAAAAZAAAAGQAAABkAAAATLgTAHwtCTA4uBMAFAAAAAAAAAAAAAAAAAAAAAAAAAAAARMA DwCIE2oAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAAANBAgAAABw tQAAcLUAAA8AihMqAAAAAAC6Dw4AAABfAF8AXwBQAFAAVAA5AAAAixMMAAAAAAB6FwQAAAAABAAA PwDZDzgAAAAAANoPBAAAAAAALAAgALoPJAAAAE4AVABUACAARQB1AHIAbwBwAGUAIABMAGkAbQBp AHQAZQBkAE8A2Q8MAAAAAADaDwQAAAAAAD0ADwDwD+UYAAAAAPMDFAAAALcAAAAAAAAAAgAAAAAB AAAAAAAAAACfDwQAAAAGAAAAAACoD2sAAABJUHY2L3Y0IGR1YWwgc3RhY2sgY29tbWVyY2lhbCBB RFNMIHNlcnZpY2Ugc3BlY2lmaWNhdGlvbiALLSBJRVRGIHY2T1BTIFdHIEludGVyaW0gTWVldGlu ZyBvbiBTZXB0LjE4LDIwMDIgLQAAoQ84AAAAbAAAAAAAAAAAADgAAACAAAIAAAAcAAIAAACAAAIA AAAYADEAAACAAAIAAAASAAEAAAAAAAIAEgAQAJ8PBAAAAAUAAAAAAKAPBAEAAFMAaABpAG4AIABN AGkAeQBhAGsAYQB3AGEALAAgAFAAaAAuAEQAIAAI/65b3V0AMEtmCf8NAFMAcgAuACAAUgBlAHMA ZQBhAHIAYwBoACAATQBhAG4AYQBnAGUAcgAsACAASQBQAHYANgAgAEcAcgBvAHUAcAANAEkAbgBu AG8AdgBhAHQAaQB2AGUAIABJAFAAIABBAHIAYwBoAGkAdABlAGMAdAB1AHIAZQAgAEMAZQBuAHQA ZQByAA0ATgBUAFQAIABDAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBuAHMADQBtAGkAeQBhAGsAYQB3 AGEAQABuAHQAdAB2ADYALgBqAHAAAAChDxwAAACDAAAAAAAAAAAAGwAAAAAAAABoAAAAAAACABgA AACqD2AAAAAFAAAABgAAAAkEAAAIAAAABwAAAAMACQQAAAIAAAAGAAAACQQAAAQAAAAHAAAAAwAJ BAAAAQAAAAYAAAAJBAAABwAAAAAAAABWAAAAAAAAABEAAAAAAAAAAQAAAAAAAAAPAPIPGAAAAAAA 8w8QAAAAAAAAAAAAAAAAAAAACFUKMAAA3w8IAAAAcQAAAIIAAAAAAPMDFAAAAE4BAAAAAAAAAgAA AAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDwYAAAB0b3BpY3MQAJ8PBAAAAAEAAAAAAKAPTgYAAFcA ZQAgAE4AVABUACAAQwBvAG0AbQB1AG4AaQBjAGEAdABpAG8AbgBzACAAZwByAG8AdQBwACAAaABh AHMAIABhAGwAcgBlAGEAZAB5ACAAcwB0AGEAcgB0AGUAZAAgAGMAbwBtAG0AZQByAGMAaQBhAGwA IABJAFAAdgA2AC8AdgA0ACAAZAB1AGEAbAAgAHMAdABhAGMAawAgAGMAbwBtAG0AZQByAGMAaQBh AGwAIABzAGUAcgB2AGkAYwBlACAAaQBuACAASgBhAHAAYQBuACwAIABpAG4AaQB0AGkAYQBsAGwA eQAgAGYAcgBvAG0AIABkAG8AdwBuACAAdABvAHcAbgAgAFQAbwBrAHkAbwAgAHMAaQBuAGMAZQAg AHQAaABpAHMAIABzAHUAbQBtAGUAcgANAFcAZQAgAGgAYQB2AGUAIAB0AGEAbABrAGUAZAAgAHcA aQB0AGgAIAB0AGgAZQAgAG8AdABoAGUAcgAgAEkAUwBQAHMAIABhAG4AZAAgAGEAbABzAG8AIAAo AG0AbwBzAHQAbAB5ACAASgBhAHAAYQBuAGUAcwBlACAAYgBhAHMAZQBkACAAYgB1AHQAIABuAG8A dAAgAGwAaQBtAGkAdABlAGQAIAB0AG8AKQAgAHYAZQBuAGQAbwByAHMAIAB3AGgAbwAgAHMAdQBw AHAAbAB5AGkAbgBnACAAZQBxAHUAaQBwAG0AZQBuAHQAcwAgAGEAbgBkACAAcwBvAGYAdAB3AGEA cgBlAHMAIABhAGwAcgBlAGEAZAB5ACAAYQBiAG8AdQB0ACAAdABoAGUAIABzAHAAZQBjAGkAZgBp AGMAYQB0AGkAbwBuACAAdwBoAGkAYwBoACAAaQBzACAAbwBwAGUAbgBlAGQAIAB0AG8AIAB0AGgA ZQAgAHAAdQBiAGwAaQBjACAAYgB1AHQAIAB3AHIAaQB0AHQAZQBuACAAaQBuACAASgBhAHAAYQBu AGUAcwBlAA0AaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHYANgAuAG4AdAB0AC4AbgBlAHQALwB3AGgA YQB0AC8AMgAwADAAMgAwADcAMwAxAC4AaAB0AG0AbAANAFMAbwBtAGUAIABuAG8AbgAgAEoAYQBw AGEAbgBlAHMAZQAgAGIAYQBzAGUAZAAgAG4AZQB0AHcAbwByAGsAIABvAHAAZQByAGEAdABvAHIA cwAgAGEAbgBkACAAcwBvAG0AZQAgAG8AdABoAGUAcgAgAHYAZQBuAGQAbwByAHMALwBzAG8AZgB0 AHcAYQByAGUAIABkAGUAdgBlAGwAbwBwAGUAcgBzACAAYQByAGUAIABpAG4AdABlAHIAZQBzAHQA ZQBkACAAYgB5ACAAdABoAGUAIABzAHAAZQBjAGkAZgBpAGMAYQB0AGkAbwBuACwAIABiAGUAYwBh AHUAcwBlACAAdABoAGUAeQAgAGMAbwB1AGwAZAAgAGMAdQB0AC0AbwBmAGYAIAB0AGgAZQAgAGMA bwBzAHQAIABvAGYAIABkAGUAcwBpAGcAbgAgAHcAbwByAGsAIABhAG4AZAAgAGkAbQBwAGwAZQBt AGUAbgB0AGEAdABpAG8AbgANAFMAbwAsACAAcwBpAG0AcABsAHkAIAB3AGUAGSBkACAAbABpAGsA ZQAgAHQAbwAgAHQAcgBhAG4AcwBsAGEAdABlACAAbwB1AHIAIABzAHAAZQBjAGkAZgBpAGMAYQB0 AGkAbwBuACAAaQBuAHQAbwAgAEUAbgBnAGwAaQBzAGgAIABhAG4AZAAgAHAAdQBiAGwAaQBzAGgA IABhAHMAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AYQBsACAAZAByAGEAZgB0ACAAdQBuAGQAZQBy ACAAdABoAGUAIABuAGEAbQBlACAAbwBmACAAdgA2AG8AcABzACAAdwBvAHIAawBpAG4AZwAgAGcA cgBvAHUAcAAgAGEAcwAgAGEAbgAgAHIAdQBuAG4AaQBuAGcAIABlAHgAYQBtAHAAbABlACAAZgBv AHIAIABBAEQAUwBMACAASQBQAHYANgAvAEkAUAB2ADQAIABkAHUAYQBsACAAcwB0AGEAYwBrACAA cwBlAHIAdgBpAGMAZQAuAAAAoQ9CAAAAeAEAAAAAABAAAFAAKQAAAAEAABAAAFAAhwEAAAAAABAA AFAAeAEAAAAAAgAUACkAAAAAAAIAEgCHAQAAAAACABQAAACqDxoAAAAYAQAAAAAAAAkAAAABAAAA AwAHAgAAAAAAAAAA8wMUAAAAuQAAAAQAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAA AFRoZSBDb21wYW55IE5UVBAAnw8EAAAAAQAAAAAAoA+MBQAATgBpAHAAcABvAG4AIABUAGUAbABl AGcAcgBhAHAAaAAgAGEAbgBkACAAVABlAGwAZQBwAGgAbwBuAGUAIAANAGgAaQBzAHQAbwByAHkA IABzAHQAYQByAHQAZQBkACAAaQBuACAAMQA4ADYAOQANAHQAaABlACAAbQBpAG4AaQBzAHQAcgB5 ACAAbwBmACAAdABlAGwAZQBjAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBuACAAbwBmACAASgBhAHAA YQBuAGUAcwBlACAAZwBvAHYAZQByAG4AbQBlAG4AdAANAGIAZQBjAGEAbQBlACAAYQAgABwgcAB1 AGIAbABpAGMAIABjAG8AcgBwAG8AcgBhAHQAaQBvAG4AHSAgAGkAbgAgADEAOQA1ADIADQBpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgACgAbwByACAAHCBwAHIAaQB2AGEAdABpAHoAZQBkAB0gKQAg AGkAbgAgADEAOQA4ADQADQByAGUALQBvAHIAZwBhAG4AaQB6AGUAZAAgAG8AbgAgADcALwAxACwA MQA5ADkAOQANAFQAaABlACAAYwBvAG0AcABhAG4AeQAgAE4AVABUACAAYgBlAGMAYQBtAGUAIAB0 AGgAZQAgAHMAaABhAHIAZQAtAGgAbwBsAGQAaQBuAGcAIABhAG4AZAAgAFIAJgBEACAAYwBvAG0A cABhAG4AeQAgAHcAaABpAGMAaAAgAGgAYQBzAA0ATgBUAFQAIABFAGEAcwB0ACAAYQBuAGQAIABO AFQAVAAgAFcAZQBzAHQAIABhAHMAIAB0AHcAbwAgAGwAbwBjAGEAbAAgAHMAZQByAHYAaQBjAGUA IABjAG8AbQBwAGEAbgBpAGUAcwAsAA0ATgBUAFQAIABDAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBu AHMAIABhAHMAIABsAG8AbgBnAC0AZABpAHMAdABhAG4AYwBlACwAIABpAG4AdABlAHIAbgBhAHQA aQBvAG4AYQBsACwAIABGAFIALAAgAEEAVABNACAAYQBuAGQAIABJAG4AdABlAHIAbgBlAHQAIABz AGUAcgB2AGkAYwBlACwADQBOAFQAVAAgAEQAbwBDAG8ATQBvACAAZABvAGkAbgBnACAAYwBlAGwA bAB1AGwAYQByACAAcABoAG8AbgBlACAAYgB1AHMAaQBuAGUAcwBzACwADQBOAFQAVAAgAEQAYQB0 AGEAIABhAHMAIABhACAAcwB5AHMAdABlAG0AIABzAG8AbAB1AHQAaQBvAG4AIABzAGUAcgB2AGkA YwBlACAAYwBvAG0AcABhAG4AeQAsAA0AYQBuAGQAIABhACAAbABvAHQAIABvAGYAIABnAHIAbwB1 AHAAIABzAHUAYgBzAGkAZABpAGEAcgBpAGUAcwAuAA0AVQBSAEwAOgAgAGgAdAB0AHAAOgAvAC8A dwB3AHcALgBuAHQAdAAuAGMAbwAuAGoAcAAvAA0ATgBUAFQALQBDAG8AbQBtAHUAbgBpAGMAYQB0 AGkAbwBuAHMAIABoAHQAdABwADoALwAvAHcAdwB3AC4AbgB0AHQALgBjAG8AbQAvAA0AVwBvAHIA bABkACAAbwBwAGUAcgBhAHQAaQBvAG4AIAAgAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBuAHQAdAB2 AGUAcgBpAG8ALgBjAG8AbQAvAA0ASQBQAHYANgAgAHIAZQBsAGEAdABlAGQAIABoAHQAdABwADoA LwAvAHcAdwB3AC4AdgA2AC4AbgB0AHQALgBuAGUAdAAvACAAKABtAG8AcwB0AGwAeQAgAEoAYQBw AGEAbgBlAHMAZQAsACAAcwBvAHIAcgB5ACkADQANAAAAoQ++AAAAIAAAAAEAABAAAFAAGAAAAAIA ABAAAFAAOQAAAAMAABAAAFAAZgAAAAIAABAAAFAARQEAAAMAABAAAFAAQgAAAAIAABAAAFAAZwAA AAMAABAAAFAAAgAAAAEAABAAAFAAIAAAAAAAAgAYABgAAAAABAIAgAQUADkAAAAABAIAgAQSAGYA AAAACAIAgAgUAEUBAAAACAIAgAgSAEIAAAAADAIAgAwUAGcAAAAAEAIAgBASAAIAAAAAFAIAgBQY AAAAqg9YAAAApgEAAAAAAAAGAAAAAQAAAAMAfAAAAAAAAAANAAAAAQAAAAMAHAAAAAAAAAALAAAA AQAAAAMAGgAAAAAAAAAQAAAAAQAAAAMAQAAAAAAAAAABAAAAAAAAAAAA8wMUAAAAUAEAAAQAAAAB AAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPKgAAAE5UVC9WRVJJTyBHbG9iYWwgSVB2NiBCYWNr Ym9uZSAmIFNvbHV0aW9ucwAAoQ8UAAAAKwAAAAAAAAAAACsAAAAAAAIAHAAAAKoPFAAAACoAAAAA AAAAAQAAAAYAAAAJBAAAAADzAxQAAABRAQAABAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8VAAAAU3BlY2lmaWNhdGlvbiBzdW1tYXJ5EACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAA AADzAxQAAABSAQAAAAAAAAIAAAAHAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8WAAAAU3BlY2lmaWNh dGlvbiBoaS1saWdodBAAnw8EAAAAAQAAAAAAoA9mBAAAMQAgAEkAUAB2ADQAIABhAGQAZAByAGUA cwBzACAAKwAgADEAIABJAFAAdgA2ACAAcAByAGUAZgBpAHgAIAAoAHUAcwB1AGEAbABsAHkAIAAv ADQAOAApAA0AVQBzAGkAbgBnACAAIABEAEgAQwBQAHYANgAgACgAZQBzAHAAZQBjAGkAYQBsAGwA eQAgAFAARAAgAG8AcAB0AGkAbwBuACkAIABhAHMAIAAoAEQAeQBuAGEAbQBpAGMAKQAgAFMAaQB0 AGUAIABDAG8AbgBmAGkAZwB1AHIAYQB0AGkAbwBuACAAUAByAG8AdABvAGMAbwBsAC4AIABQAGwA ZQBhAHMAZQAgAGQAbwAgAG4AbwB0ACAAYgBlACAAYwBvAG4AZgB1AHMAZQBkAC4ADQBJAFAAdgA2 ACAAcAByAGUAZgBpAHgAIABkAGUAbABlAGcAYQB0AGkAbwBuACAAcwB0AGEAdABpAGMAYQBsAGwA eQANAFMAdQBiAHMAYwByAGkAYgBlAHIAIABnAGUAdABzACAAcwBhAG0AZQAgAHAAcgBlAGYAaQB4 AA0ASQBQAHYANAAgAGEAZABkAHIAZQBzAHMAIABhAHMAcwBpAGcAbgBtAGUAbgB0ACAAZAB5AG4A YQBtAGkAYwBhAGwAbAB5AA0ASQBQAHYANAAgAGEAZABkAHIAZQBzAHMAIABtAGEAeQAgAGMAaABh AG4AZwBlACAADQBJAFAAdgA2ACAAZgByAGkAZQBuAGQAbAB5ACAARABOAFMAIABvAHAAZQByAGEA dABpAG8AbgANAE8AdQByACAARABOAFMAIABzAGUAcgB2AGUAcgBzACAAaABhAHYAZQAgAEkAUAB2 ADYAIAB0AHIAYQBuAHMAcABvAHIAdAAgAGEAbgBkACAAYQBjAGMAZQBwAHQAaQBuAGcAIABEAE4A UwAgAHQAcgBhAG4AcwBmAGUAcgAgAGIAeQAgAHQAaABhAHQADQBDAGEAbgAgAGIAZQAgAGMAdQBz AHQAbwBtAGUAcgAZIHMAIABzAGUAYwBvAG4AZABhAHIAeQAgAHMAZQByAHYAZQByAA0AQQBzAHMA dQBtAGkAbgBnACAAWwBhAHMAcwBpAGcAbgBlAGQAIABwAHIAZQBmAGkAeABdADoAOgA1ADMAIABh AHMAIABjAHUAcwB0AG8AbQBlAHIAGSBzACAARABOAFMAIABwAHIAaQBtAGEAcgB5ACAAcwBlAHIA dgBlAHIAIABsAG8AYwBhAHQAaQBvAG4ADQBTAG8AIAB0AGgAYQB0ACAAYwB1AHMAdABvAG0AZQBy ACAAYwBhAG4AIAByAHUAbgAgAA0ARAB1AGEAbAAgAFMAdABhAGMAawAgAE0AYQBpAGwAIABTAGUA cgB2AGUAcgAgAA0ARAB1AGEAbAAgAFMAdABhAGMAawAgAFcAVwBXACAAUwBlAHIAdgBlAHIADQBh AG4AZAAgAG0AbwByAGUAIAANAAAAoQ+8AAAAuQAAAAAAABAAAFAAHAAAAAEAABAAAFAAJAAAAAAA ABAAAFAAGQAAAAEAABAAAFAAHAAAAAAAABAAAFAAzQAAAAEAABAAAFAAOAAAAAIAABAAAFAAAQAA AAEAABAAAFAAuQAAAAAAAgASABwAAAAAAAIAEAAkAAAAAAQCAIAEEgAZAAAAAAQCAIAEEAAcAAAA AAgCAIAIEgDNAAAAAAwCAIAMEAA4AAAAAAwCAIAMDgABAAAAAAwCAIAMEAAAAPMDFAAAAFMBAAAA AAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABBdCB0aGUgZW5kEACfDwQAAAABAAAA AACoD0ABAABXZSBob3BlIHRoYXQgd2UgY291bGQgcHVibGlzaCBhIGRldGFpbGVkIHNwZWNpZmlj YXRpb24gYXMgSW5mb3JtYXRpb25hbCBSRkMgYXMgc28gdGhhdCBhbnlib2R5IHdobyBpbnRlcmVz dGVkIGJ5IHNhbWUga2luZCBvZiBzZXJ2aWNlIGNhbiB1c2UgaXQgdG8gc2F2ZSB0aW1lIGFuZCBl ZmZvcnRzIA1BbHNvIGZyb20gdmVuZG9ycyBwb2ludCBvZiB2aWV3LCBpZiB0aGlzIG1ldGhvZCB3 b3VsZCBiZSB3aWRlbHkgdXNlZCBpbiB0aGUgd29ybGQgd2lkZSwgdGhhdCBtZWFucyB0aGV5IGFs c28gY2FuIHNhdmUgdGltZSBhbmQgY29zdHMgZm9yIGRldmVsb3BtZW50DQAAoQ8eAAAAQAEAAAAA AAAAAAEAAAAAAAEAAAAAAEEBAAAAAAAAAADqAwAAAAAPAPgDigkAAAIA7wMYAAAAAQAAAAECBwkI AAAAAAAAAAAAAAAAABMAYADwByAAAAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAGAA 8AcgAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA//8A/wAzAJaWlgBgAPAHIAAAAP//zAAAAAAAgIAA AJmZMwAzmTMAgAAAAAAzzAD/zGYAYADwByAAAAD///8AAAAAADk5OQAAAAAAy8vLAIaGhgBNTU0A 6urqAGAA8AcgAAAA////AAAAAACfn58AAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAA AAAAhoaGAAAAAADLy8sAAGb/AP8AMwAAmQAAYADwByAAAAD///8AAAAAAJaWlgAAAAAAM5n/AJn/ zADMAMwAsrKyAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAABwAA AP//7wCAAAAAAQAAAP//LAAAAAADAAAQAKMPfAAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA 2AAAAEACAAAAAAcAAAD//+8AgAAAAAEAAAD//yAAAAAAAQAAgAUAABMg1AEgAQAAAgAcAIAFAAAi INACQAIAAAIAGACABQAAEyDwA2ADAAACABQAgAUAALsAEAWABAAAAAAgAKMPbgAAAAUA//0/AAAA IiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAcAAAD//+8AgAAAAAIAAAD//wwAAAAAAQAAAAUA ACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAA AQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBg AwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAA AAACABwAAQAAAAAAAAACABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACj Dz4AAAAFAAAAAAAAAAAAAgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQA AAAAAAAAAgAQAA8ADATEBQAADwAC8LwFAAAQAAjwCAAAAAgAAAAWBAAADwAD8EIFAAAPAATwKAAA AAEACfAQAAAA9fX19fX19fX19fX19fX19QIACvAIAAAAAAQAAAUAAAAPAATwwAAAABIACvAIAAAA AgQAAAAKAABzAAvwKgAAAH8AAQABAIAAyBX7A4cAAQAAAIEBBAAACL8BAQARAMABAQAACP8BAQAJ AAAAEPAIAAAAYADUAYwWMAMPABHwEAAAAAAAwwsIAAAAAAAAAAEA+wMPAA3wTgAAAAAAnw8EAAAA AAAAAAAAoA8aAAAA3jC5ML8w/DC/MKQwyDDrMG4w+GYPXy2KmlsAAKIPBgAAAA4AAAAAAAAAqg8K AAAADgAAAAEAAAAAAA8ABPBiAQAAEgAK8AgAAAADBAAAAAoAAGMAC/AkAAAAfwABAAEAgAB0GPsD gQEEAAAIvwEBABEAwAGAAIAA/wEBAAkAAAAQ8AgAAADwA9QBjBYQDg8AEfAQAAAAAADDCwgAAAAB AAAAAgD7Aw8ADfD2AAAAAACfDwQAAAABAAAAAACgD1oAAADeMLkwvzD8MMYwrTC5MMgwbjD4Zg9f LYqaWw0ALHsgADIAIADsMNkw6zANACx7IAAzACAA7DDZMOswDQAseyAANAAgAOww2TDrMA0ALHsg ADUAIADsMNkw6zAAAKIPHgAAAA4AAAAAAAgAAAABAAgAAAACAAgAAAADAAgAAAAEAAAAqg9aAAAA EAAAAAEAAAAAAAIAAAABAAAAAAAGAAAAAQAAAAAAAgAAAAEAAAAAAAYAAAABAAAAAAACAAAAAQAA AAAABgAAAAEAAAAAAAIAAAABAAAAAAAEAAAAAQAAAAAADwAE8LAAAAASAArwCAAAAAYEAAAACgAA YwAL8CQAAAB/AAEAAQCAAIgg+wOBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAMAPTBNg GOAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAvsDDwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoA AAChDxoAAAACAAAAAAAAKAoAAgAyAAcAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBuAAAAsgQK 8AgAAAAJBAAAEAoAAGMAC/AkAAAABEEDAAAACwGOAAAAPwEAAAEAvwEAABAA/wEAAAgAPwIAAAIA EwAi8QYAAAC/AwAEAAQAABDwCAAAADgG+QlnDqYKDwAR8AwAAAAAAMELBAAAAI4AAAAPAATw1AAA AAIACvAIAAAACwQAAAAKAAAzAQvwrAAAAIUAAgAAAIcAAQAAAEIBkAkAAEMB8AAAAEQBBAAAAEXB EAAAAEbBGgAAAH8BAQABAIABAgAAAIEB3d3dAIZBCAAAAIfBCgAAAJUBAAAAAL8BFAAUAMABAQAA CMQBAAAAAP8BEAAYAAECAgAACIgDAAAAAAQABADw/wAAkACQCQAAoAjwAAAAkAAKAAwAAgAAQACs AQAArAEAAKwBAACsAWAAgH8wSzBSMPN3AAAAABDwCAAAAKACIAewEJADDwAE8GIAAACyBArwCAAA AA0EAAAACgAAQwAL8CwAAAB/AIAAgAAEQRUAAAAFwRQAAAAGAQEAAABuAGMAbwBtAF8AcgBvAGcA bwAAABMAIvEGAAAAvwMABAAEAAAQ8AgAAAAAAAAA4gNaAQ8ABPBkAAAAsgQK8AgAAAAWBAAAAAoA AEMAC/AuAAAAfwCAAIAABEECAAAABcEWAAAABgEBAAAAbABvAGcAbwBiAG8AdAB0AG8AbQAAABMA IvEGAAAAvwMABAAEAAAQ8AgAAABJAFcUCxj9AA8ABPBaAAAAEgAK8AgAAAABBAAAAAwAALMAC/BC AAAAgQEAAAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgAAQIAAAACBQKoKQEABgKoKQEAPwIDAAMA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyACAAug8c AAAAsGVXMEQwjP+f/5r/fv+e/53/g/9w/3z/bv+d/w8A8ANWBwAAAQDxAwgAAAAAAACAAAAKMA8A DATWBgAADwAC8M4GAADAAAjwCAAAAAcAAAAHEAAADwAD8GwGAAAPAATwKAAAAAEACfAQAAAA9fX1 9fX19fX19fX19fX19QIACvAIAAAAABAAAAUAAAAPAATwBgEAABIACvAIAAAAAhAAAAAKAACzAAvw QgAAAH8AAQABAIAAzELxBIEA2V8BAIIA7K8AAIMA2V8BAIQA7K8AAL8AEAAfAIEBBAAACL8BAQAR AMABAQAACP8BAQAJAAAAEPAIAAAAAAAAAFEHHwEPABHwEAAAAAAAwwsIAAAAAAAAAAoC8QQPAA3w fAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGAAAAAIAAAAAAAAgCgAyAAcAAgAAAAAAAgAM AAAA+Q8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAAAKYPFgAAAPEeAAA4AhwB HAE4AjgCUwNTA28EbwQPAATwCAEAABIACvAIAAAAAxAAAAAKAACzAAvwQgAAAH8AAQABAIAADE7x BIEA2V8BAIIA7K8AAIMA2V8BAIQA7K8AAL8AEAAfAIEBBAAACL8BAQARAMABAQAACP8BAQAJAAAA EPAIAAAAAACPCeAQHwEPABHwEAAAAAAAwwsIAAAAAQAAAAcA8QQPAA3wfgAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAoCgACADIABwACAAAAAAACAAwAAAD4DwQAAAAAAAAA AACqDxQAAAABAAAAAQAAAAAAAQAAAAEAAAAAAAAApg8WAAAA8R4AADgCHAEcATgCOAJTA1MDbwRv BA8ABPBkAAAAEgAK8AgAAAAEEAAAAAoAAGMAC/AkAAAAhwABAAAAfwEAAAEAgQEEAAAIvwERABEA wAEBAAAI/wEIAAkAAAAQ8AgAAACuAV0ChA4YCg8AEfAQAAAAAADDCwgAAAACAAAABQDxBA8ABPCA AQAAEgAK8AgAAAAFEAAAAAoAALMAC/BCAAAAfwABAAEAgAC4V/EEgQDZXwEAggDsrwAAgwDZXwEA hADsrwAAvwAQAB8AgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACnCkACoA7BFA8AEfAQ AAAAAADDCwgAAAADAAAABgLxBA8ADfD2AAAAAACfDwQAAAACAAAAAACgD1oAAADeMLkwvzD8MMYw rTC5MMgwbjD4Zg9fLYqaWw0ALHsgADIAIADsMNkw6zANACx7IAAzACAA7DDZMOswDQAseyAANAAg AOww2TDrMA0ALHsgADUAIADsMNkw6zAAAKIPHgAAAA4AAAAAAAgAAAABAAgAAAACAAgAAAADAAgA AAAEAAAAqg9aAAAAEAAAAAEAAAAAAAIAAAABAAAAAAAGAAAAAQAAAAAAAgAAAAEAAAAAAAYAAAAB AAAAAAACAAAAAQAAAAAABgAAAAEAAAAAAAIAAAABAAAAAAAEAAAAAQAAAAAADwAE8AwBAAASAArw CAAAAAYQAAAACgAAwwAL8EgAAAB/AAEAAQCAAHwG8QSBANlfAQCCAOyvAACDANlfAQCEAOyvAACH AAIAAAC/ABAAHwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAFAVAABRB28WDwAR8BAA AAAAAMMLCAAAAAQAAAAJAvEEDwAN8HwAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxgAAAAC AAAAAAAAIAoAMgAHAAIAAAAAAAIADAAAAPoPBAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAA AQAAAAAAAACmDxYAAADxHgAAOAIcARwBOAI4AlMDUwNvBG8EDwAE8A4BAAASAArwCAAAAAcQAAAA CgAAwwAL8EgAAAB/AAEAAQCAAJhm8QSBANlfAQCCAOyvAACDANlfAQCEAOyvAACHAAIAAAC/ABAA HwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAFAVjwngEG8WDwAR8BAAAAAAAMMLCAAA AAUAAAAIAvEEDwAN8H4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxoAAAACAAAAAAAAKAoA AgAyAAcAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAA AKYPFgAAAPEeAAA4AhwBHAE4AjgCUwNTA28EbwQPAATwQgAAABIACvAIAAAAARAAAAAMAABzAAvw KgAAAIEBAAAACJMB3r1oAJQBIzaLAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8A XwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAIFUwgHwPTZNDwDJD+IEAAAPAAwEcgQAAA8AAvBq BAAAUAEI8AgAAAAFAAAABQgAAA8AA/AIBAAADwAE8CgAAAABAAnwEAAAAPX19fX19fX19fX19fX1 9fUCAArwCAAAAAAIAAAFAAAADwAE8OoAAAASAArwCAAAAAIIAAAACgAAswAL8EIAAAB/AAEAAQCA AKyF8QSBANlfAQCCAOyvAACDANlfAQCEAOyvAAC/ABAAHwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEA CQAAABDwCAAAAAAAAABRBx8BDwAR8BAAAAAAAMMLCAAAAAAAAAAKAvEEDwAN8GAAAAAAAJ8PBAAA AAQAAAAAAKAPAgAAACoAAAChDxgAAAACAAAAAAAAIAoAMgAHAAIAAAAAAAIADAAAAPkPBAAAAAAA AAAAAKYPFgAAAPEeAAA4AhwBHAE4AjgCUwNTA28EbwQPAATw7AAAABIACvAIAAAAAwgAAAAKAACz AAvwQgAAAH8AAQABAIAA/JXxBIEA2V8BAIIA7K8AAIMA2V8BAIQA7K8AAL8AEAAfAIEBBAAACL8B AQARAMABAQAACP8BAQAJAAAAEPAIAAAAAACPCeAQHwEPABHwEAAAAAAAwwsIAAAAAQAAAAcC8QQP AA3wYgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAoCgACADIABwACAAAA AAACAAwAAAD4DwQAAAAAAAAAAACmDxYAAADxHgAAOAIcARwBOAI4AlMDUwNvBG8EDwAE8PAAAAAS AArwCAAAAAQIAAAACgAAwwAL8EgAAAB/AAEAAQCAANCN8QSBANlfAQCCAOyvAACDANlfAQCEAOyv AACHAAIAAAC/ABAAHwCBAQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAFAVAABRB28WDwAR 8BAAAAAAAMMLCAAAAAIAAAAJAvEEDwAN8GAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxgA AAACAAAAAAAAIAoAMgAHAAIAAAAAAAIADAAAAPoPBAAAAAAAAAAAAKYPFgAAAPEeAAA4AhwBHAE4 AjgCUwNTA28EbwQPAATw8gAAABIACvAIAAAABQgAAAAKAADDAAvwSAAAAH8AAQABAIAAIKrxBIEA 2V8BAIIA7K8AAIMA2V8BAIQA7K8AAIcAAgAAAL8AEAAfAIEBBAAACL8BAQARAMABAQAACP8BAQAJ AAAAEPAIAAAAUBWPCeAQbxYPABHwEAAAAAAAwwsIAAAAAwAAAAgC8QQPAA3wYgAAAAAAnw8EAAAA BAAAAAAAoA8CAAAAKgAAAKEPGgAAAAIAAAAAAAAoCgACADIABwACAAAAAAACAAwAAADYDwQAAAAA AAAAAACmDxYAAADxHgAAOAIcARwBOAI4AlMDUwNvBG8EDwAE8EIAAAASAArwCAAAAAEIAAAADAAA cwAL8CoAAACBAQAAAAiTAd69aACUASM2iwC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAA AP///wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAA XwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACBVMIBcMhNTg8A7gOnAgAAAgDvAxgAAAAA AAAADxAAAAAAAAAAAACAAAAAAAcAEwAPAAwEzgEAAA8AAvDGAQAAMAAI8AgAAAADAAAABowCAA8A A/BWAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACMAgAFAAAADwAE 8HIAAAASAArwCAAAAAOMAgAgAgAAUwAL8B4AAAB/AAAABACAAJTH+wO/AQAAAQD/AQAAAQABAwME AAAAABDwCAAAAOAKwAPQFDAPDwAR8BAAAAAAAMMLCAAAAAEAAAAQAPsDDwAN8AwAAAAAAJ4PBAAA AAEAAAAPAATwpAAAABIACvAIAAAAAowCACACAABzAAvwKgAAAH8AAAAEAIAAlM77A4ABAAAAAIEB AAAACL8BEAARAP8BAAABAAEDAgQAAFMAIvEeAAAAngH/////nwH/////oAEAAAAgocEAAAAApgH/ ////AAAQ8AgAAACgBQYBWhdwCA8AEfAQAAAAAADDCwgAAAAAAAAADwD7Aw8ADfAMAAAAAACeDwQA AAAAAAAADwAE8EgAAAASAArwCAAAAAGMAgAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAR5AlwCU Ad69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAPAAXwAAAAABAA8AcgAAAA////AAAAAACWlpYA AAAAAADMmQAzM8wAzMz/ALKysgAPAIgTgQAAAA8AihN5AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLE1kAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAAAuRMA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gN9AgAAAgDvAxgA AAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwElAEAAA8AAvCMAQAA8AsI8AgAAAADAAAAA7AF AA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACwBQAFAAAA DwAE8HIAAAASAArwCAAAAAKwBQAgAgAAUwAL8B4AAAB/AAAABACAAGgAnQC/AQAAAQD/AQAAAQAB AwIEAAAAABDwCAAAAGAA1AGMFjADDwAR8BAAAAAAAMMLCAAAAAAAAAANAAQEDwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATwcgAAABIACvAIAAAAA7AFACACAABTAAvwHgAAAH8AAAAEAIAAHCmdAL8BAAAB AP8BAAABAAEDAwQAAAAAEPAIAAAA8APUAYwWEA4PABHwEAAAAAAAwwsIAAAAAQAAAA4AnQAPAA3w DAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABsAUAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJaW lgAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABU ADEAMAAAAIsTaQAAAAAA6y4IAAAAOl/CAaDdrEoAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAA AAAAAAMAAAAAAAAAAAAAAAAAAAAAuRMA/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIr AAAAAA8A7gPTAgAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAEwAPAAwE+gEAAA8AAvDy AQAAYAAI8AgAAAAEAAAABJwCAA8AA/CKAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAACcAgAFAAAADwAE8HgAAAASAArwCAAAAAKcAgAgAgAAYwAL8CQAAAB/AAAABACA AIApBAS/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAGAA1AGMFjADDwAR8BAAAAAAAMML CAAAAAAAAAANAAQEDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATweAAAABIACvAIAAAAA5wCACACAABj AAvwJAAAAH8AAAAEAIAAVCoEBL8BAAABAP8BAAABAAEDAwQAAIgDAAAAAAAAEPAIAAAAkANgAGAY wA8PABHwEAAAAAAAwwsIAAAAAQAAAA4ABAQPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBSAAAAsgQK 8AgAAAAEnAIAAAoAAEMAC/AqAAAAfwCAAIAABEEBAAAABcESAAAABgEBAAAAbgB0AHQAXwBsAG8A ZwBvAAAAAAAQ8AgAAAAsAQAA7gK4Ag8ABPBIAAAAEgAK8AgAAAABnAIAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAJaWlgAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBOBAAAADwCKE3kAAAAAALoPEAAAAF8AXwBf AFAAUABUADEAMAAAAIsTWQAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAA AAAAAAAAAAAAAAC5EwD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuAws9 AQACAO8DGAAAAAEAAAANEwAAAAAAAAAAAIAAAAAABwATAA8ADAQyPAEADwAC8Co8AQAQDAjwCAAA AEMBAABDuQUADwAD8MI7AQAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA ALgFAAUAAAAPAATwfgAAABIACvAIAAAAArgFACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAAED8E BL8BAAABAP8BAAABAAEDAgQAAIgDAAAAAAAAEPAIAAAAAADpAaEW0AIPABHwEAAAAAAAwwsIAAAA AAAAAA0ABAQPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPCfAAAAogwK8AgAAAADuAUAAAoAAJMAC/A2 AAAAgAAAQAQEhQACAAAAhwAGAAAAvwACAAIAgQH/zMwAvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAQ8AgAAAAjD+kHUwpDEA8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwUAAABKYXBhbgAAoQ8YAAAA BgAAAAAAAAgKAAEABwAGAAAAEQAAAJEADwAE8J4AAACiDArwCAAAAAS4BQAACgAAkwAL8DYAAACA AFxDBASFAAIAAACHAAYAAAC/AAIAAgCBAf/MzAC/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDw CAAAAMAJwAxFD+AKDwAN8DgAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAFUuUy5BLgAAoQ8WAAAABwAA AAAAAAAKAAcABwAAABEAAACRAA8AA/DaQwAADwAE8EwAAAABAAnwEAAAADAPAAAsBQAA6RQAAHwL AAACAArwCAAAAAW4BQABAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAPICfRKgF7EIDwAE 8NgCAAACAArwCAAAAAa4BQACCgAAAwEL8KgCAAAEAAAAAABCAegAAABDAUsBAABEAQQAAABFwRwB AABGwSYBAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ ARAAGACIAwAAAABHAEcA8P91AAMAhgAAAJEADQCTABwAlwAgAKAAHQC6ACgAwgAjAMwAIgDTACsA 2QA6AOIARADoAEkA5QBOANIAVAC8AGAAvQB0ALAAfwClAIgApACcAKQAqQCbALIAlACpAIgArACH ALMAhQDDAIkAyQCHANoAfwDhAHUA7gBxAPkAcwANAXsAGAF2AB8BYAAmAVgALgFXADcBVwBIAT4A SAEtAEsBGQA0AQ4ANAEFADQBAAAsAQUAIwERABMBFwACASQA7gAnAOMAIQDbABkA0wAXAM4AIQDL ACcAvwAcALwAEQDCABEAtAAXAKwAHACjAB8AmAAhAJAAJwCNADAAkwA+AH8ARgBxAFwAWABcAE0A aAA8AGsAKABwAB0AdQADAJAAlAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAMA8AABMJAAAYEAAAXgoAAA8AA/BkBwAA DwAE8FQAAAABAAnwEAAAAHcNAAC6CQAA9A8AANoLAAACAArwCAAAAAe4BQADAgAAIwAL8AwAAAAE AAAAAACIAwAAAAAAAA/wEAAAAIcPAACsCAAABBIAAMwKAAAPAATwagQAAAIACvAIAAAACLgFAAIK AADzAAvwOgQAAEIBZgIAAEMBIAIAAEQBBAAAAEXB6AEAAEbB8gEAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAHoAegDw/x8AagAcAGIA HwBXADAAOwAnADUAKwAsACEAKgAhAB8AJwAWAEQADgBaABAAXAAIAG0AAAB2AAMAiQAcAKgAKgDE ACoAzAAsABgBVwAuAVoAPwFqAFgBZABmAW0AdQF7AIUBewCRAX4AlgGDAJEBjACRAZcAvQG2ANYB ygDiAccA7wHEABoC2AAfAuYAJQLrADMC7gA7AvQARwL0AFIC9ABdAvcAYAL0AGYC/wBmAg0BXQIW ATECNwEdAjcB5QFFAdEBSAHRAVgBxgFYAboBYQGvAW8BpAF6AZYBfQGLAYsBiwGfAZMBqQGWAbIB lgHAAZMBxgGIAckBdwHXAWEB6wFYAfMBUwH4AVMBAQI6AQECKwEEAiABBwIbAQwCEgEXAgQBHQL8 AB0C6wAaAs8AFwKdAAQCiQABAnYABwJoAA8CVwARAkkAGgJAACACIQD+ASEAzwEUAL0BAwCwAQAA pwEAAJYBCACNAR8AhQEkAIABHAB0ARkAYQEhAFABMwA/ATMAMgEtACYBMwATATUAEAE9ABABRAAZ AUwADQFPAO4AZQDbAGUAzwBlAMcAfAC5AIwAtgCSALAAhACjAHkAjABzAIcAYwCPAFcAigBHAIMA QACHADsAgAA7AHYAMwBqAC0AZwAfAGoA9gD4AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBYACAAAAP8BAAAAB3DQAAugkAAN0PAADaCwAADwAE8MoAAAACAArwCAAAAAm4BQACCgAA 8wAL8JoAAABCARgAAABDAREAAABEAQQAAABFwRgAAABGwSIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAGAAYA8P8YAAAADQAAAAAA DAAGABEAEgARABgAAAAOABAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABK DwAAfQsAAGIPAACOCwAADwAE8PIAAAACAArwCAAAAAq4BQACCgAA8wAL8MIAAABCATUAAABDASoA AABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAALAAsA8P8nAAAAIgAFAAsACAAAABcAEAAiABkAKgAqACcA NQAiADIAFwAqAA4AJwAAABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAjw8AAFMLAADEDwAAfQsAAA8ABPDCAAAAAgAK8AgAAAALuAUA AgoAAPMAC/CSAAAAQgERAAAAQwEWAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQEG AAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAABQAFAPD/CwAAAAAA BQAJAA0AEQAWAAsAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAOMPAABW CwAA9A8AAGwLAAAPAAPwQggAAA8ABPBUAAAAAQAJ8BAAAACsEAAAygkAANkSAACKDAAAAgAK8AgA AAAMuAUAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAAC8EgAAvAgAAOkUAAB8CwAADwAE 8GIBAAACAArwCAAAAA24BQACCgAA8wAL8DIBAABCAVkAAABDAZIAAABEAQQAAABFwWQAAABGwW4A AAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACI AwAAAAAZABkA8P81AAAAJwAIABwAEQAQABQAAAARAAMAIgALAC0ACABKAAgAVwALAGMAAwB5AAUA igAQAJIAIQCHACcAhAA4AIcAQwB8AEMAcABRAFoAVgBMAFEAPgBZAC0AVAAUAFEABQA1AAAANAA4 AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAA AMAQAAA/CwAAGREAANELAAAPAATwggEAAAIACvAIAAAADrgFAAIKAADzAAvwUgEAAEIBpAAAAEMB ZwAAAEQBBAAAAEXBdAAAAEbBfgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAA AMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAB0AHQDw/5wAAACkAAkAnwARAJkAHgCQACcAkwBBAJkA VACKAFwAiABkAHwAZwBsAFcAYABXAFcASQBHAEEAOwA+ADAAOAAlAC8AEQAiAAkAHgAAABYAAAAM AAMAAwAUAAUALgAFADMADgBPAA4AYwAOAHwACQCcAAAAPABAAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAACPEQAA IwwAADMSAACKDAAADwAE8OoEAAACAArwCAAAAA+4BQACCgAA8wAL8LoEAABCAS0CAABDAXUCAABE AQQAAABFwSgCAABGwTICAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwx AADOAQAAAAD/ARAAGACIAwAAAACKAIoA8P+UAW0CnAF1AqoBbQK7AVYCwwE1AswBMgLSATcC3QEs AtoBHgLfARMC3QENAs8BAgLKAQICzAH8AcEB/wG7AfoBuwH0AcwB6QHUAd4B1AHMAd0BygH5AdgB BALbARIC7gEYAvoBIAL6ASkC7gEtAuMBIwLPARgCxAENAsQBDQLCAQcCwgHrAaUB3QGoAcwBkgHB AY8BsAF+AacBeAGtAXMBtgFwAaoBZwGcAW0BkQFnAXIBTgFvAUMBZAFAAVkBOAE9AfoANAHyAB4B 3gAFAbcABQGgABMBmAATAYwACAGCAAIBfAAFAXMAEAFuADIBZgBAAV0ASwFSAEgBNQBLASsAOgEo ABYBHwAQARcADgEUAA4BDAALAQMA9wAAAMcAAwDCAA8AsQARAKYAKACmADAAmwAoAIkAJQB/ACsA dgA7AGUAMABoAB8AYwAUAFcAFwBUACUATAAtAEMALQAcACgADgAzABEAQQAUAEwAAABdAAUAaAAL AG4AAAB8AAAAkAAFAJgAEQCYABcAngAcAKwAHAC6ACcAvQAwALoATwCbAFwAoAB4AK8AjAC9AI8A zgCbANkAoADtAKYACwGuABkBuQAlAc0ALQHeAEgB7wBfAf8AagEeAY8BNAGPAU4BpQFOAbwBVgHC AWcBtgFqAcIBagHPAXsB3gGAAeYBlwHgAZoB6QGXAfwBogENAqUBGwKqASkCpwE1ApwBQAKaAU4C kQFeApQBbQIWARgBAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACA AAAP8BAAAACsEAAAygkAANkSAAA/DAAADwAE8IACAAACAArwCAAAABC4BQACCgAAAwEL8FACAAAE AAAAAABCAeEAAABDAZMAAABEAQQAAABFwfAAAABGwfoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAA8ADwA8P92ABwAawASAGwADgBl AAgAXwAAAFgACABUAAUATAANAEwAEABCABUAKQApACIAMQAiADsAGQA+AAcAUQAHAFgAAABhAAMA agALAGUAEwBcACAAWgApAFwALABqACoAdAAwAHsANgCAAEUAgQBkAIUAawCBAG8AewByAG4AfgBu AIEAdgCBAIkAkACTAJoAggCmAH0AswB+ALwAgwDAAIgAwwB6AMsAaQDbAGYA4QBbANsAUgDUAE4A vwBLAL4AQAC+ADUAvgAsALEAJgCqACkAnwAgAJ0AGgCZABMAmQAQAI0ADQCIABIAgAAYAHYAHAB6 AHwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAChEgAAZAgAAIITAAD3CAAADwAE8KACAAACAArw CAAAABG4BQACCgAAAwEL8HACAAAEAAAAAABCAVYBAABDAZwAAABEAQQAAABFwQABAABGwQoBAAB/ AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAA AABAAEAA8P8AADgADgA3ABQANQAbAD4AJAA7ADAAPQA3AEIAQwA7AFMAPABZAEMAYwBFAGkAQAB6 AD0AggA9AI8AQgCeAEwAqgBHAKwAPQCkADAAoQAeAMcABADQAAQA0QANANwADwD1AAwA/wABAB0B AAAkAQ0AMAENADsBBgBOARIATgEnAFYBMABUAT4ATgFMAEQBTABAAVAARgFbAEYBZgBAAXAAMAF4 AC8BggAvAYwAIAGPAAYBjgD6AJEA5ACRANsAnAC4AJEApwCRAHsAiAB1AH0AdQByAHIAawBsAGgA UQBpACsAbQAnAGQAIQBhABUAXQAKAFoACgBQAAoAQAAAADgAggCEAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAFUTAABTCAAAqxQAAO8IAAAPAATwgAEAAAIACvAIAAAA ErgFAAIKAAADAQvwUAEAAAQAAAAAAEIBlgAAAEMBVwAAAEQBBAAAAEXBcAAAAEbBegAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAABwA HADw/w0AMAAcAD8AGABGABEATAAJAE0AAABPABAAVgAWAFcAKQBMAFIAVgBtADgAcwArAHgAJwCH ACkAlgAXAJUACwCKAAAAgwABAHwABABuAAEAYQABAFMABQBAAAQAOAAPABgABQAMAAUADAAYAA0A MAA6ADwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAA+RMAAOAIAACPFAAANwkAAA8ABPDgAQAAAgAK8AgAAAATuAUAAgoA AAMBC/CwAQAABAAAAAAAQgGeAAAAQwGMAAAARAEEAAAARcGgAAAARsGqAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAKAAoAPD/AAAZ AAQAFAACAA0AGgAAAB0ABAAuAAEAPAACADYACQA5ABIARQAWAE8AFQBYAA4AaAANAGwAEwB1ABgA ggAZAIAAIwCBADkAgwBGAJEARACWAE0AlwBVAJ4AXwCVAGcAjQBtAIQAbQB5AHAAeQB7AHQAgwBp AIwAVgB+AFEAcQBAAG0AOgBcAC4AUgApAEYAIAA6ABkALgAMACUAAAAZAFIAVAACAABAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABWEgAAVgcA APQSAADiBwAADwAE8CgBAAACAArwCAAAABS4BQACCgAAAwEL8PgAAAAEAAAAAABCASwAAABDATYA AABEAQQAAABFwUQAAABGwU4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAARABEA8P8fADYAIgAkACwAHgAsABUAJgAPACEABwAeAAAA FAAAAA0AAwANAA4ABwAYAAAAGwADACQADAAmABYAKAAbAC0AHwA2ACQAKAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAwRIAAMMHAADtEgAA+QcAAA8ABPBgAgAAAgAK8AgAAAAVuAUAAgoAAAMBC/Aw AgAABAAAAAAAQgGhAAAAQwGsAAAARAEEAAAARcHgAAAARsHqAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAOAA4APD/QwAEADIAGQAy AB8AKAApACoAKwAnADIAHQA7ABMARwAPAE0AEwBSABAAWwALAGEABwBkAAAAbQABAHUACAB6ABoA egAkAHQALwByADcAegBAAH0ASwB/AEgAjABMAKwAVgCrAFwAqgBeAKEAYACOAGcAhABnAHQAbQBq AHkAZACRAEoAlAA+AJAALACfACAAoQAMAJcAAwCQAAEAgwAAAGcAAABfAAYAWAAPAFkAFgBjAB0A agAlAGoAMQBfADkAUwA7AEsAPQBHADYARAAsAEoAJABIABoARwAQAEMABAByAHQAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAA AI0SAADwBgAALhMAAJwHAAAPAATw6AIAAAIACvAIAAAAFrgFAAIKAAADAQvwuAIAAAQAAAAAAEIB 5QAAAEMB0gAAAEQBBAAAAEXBJAEAAEbBLgEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAA CMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAEkASQDw/1UATwBSAFcAVQBjAFAAaQBJAGUA QQBmAEEAbwAwAH8AJgCCABkAkQARAJUACgCUAAcAlgAFAJkACACeAAgAqAAAALEAAwC6AAMAugAN ALoAEQCzABcAuQAPAL4AEgDHABcAyAApAMsALADNAD0A0gBDAM8AUgDHAGcAywCNAMsAogDHAKwA twC5ALEAvQCoAMEAmwDLAJQA0wB/ANIAZgDlAFsA2gBRANYAQADPADoAxgA6AL4ANQCvACMAtgAf ANAABwDNAAAAxQACAKkAAwCfAAoAmAAOAI4ADQCIABEAjQAYAJsAIQCRACMAeAAmAGcAHwBWABgA UAAcAEwAKQBNADAASwAzAEEANwBCAEQAQQBHADcAVABAAGEAQwBgAFUATwCUAJgAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAZRAAAOEFAABKEQAAswYAAA8AA/CwBwAADwAE8FQAAAABAAnwEAAAAGARAAD+ BgAAaBIAAMwHAAACAArwCAAAABe4BQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAHAT AADwBQAAeBQAAL4GAAAPAATwQgIAAAIACvAIAAAAGLgFAAIKAADzAAvwEgIAAEIBbQAAAEMBiAAA AEQBBAAAAEXB1AAAAEbB3gAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAADUANQDw/wgAdAAOAH4AGgB+ACUAgQAuAIgANwCIADEAfwA1 AHQAOwBnAD4AWQBLAFAAVQBKAFQAQgBUADQAVwAuAGEALQBlADAAbQAmAGoAHQBlABwAWwAcAFcA HABUAA8AVQADAE4AAABLAAQAOwABADcABQA7ABEAOQAcADIAFAAvAA0AJQAOACIAFQAfABgAHwAi AB0AIAAVABQAEAAPAAsAEgAMABkADAAdAAUAIAAFACoACwA0AAsAOwAIAEIAAABJAAEAUAAJAFcA DABeAAsAbAAIAHQAbABwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAABgEQAAKAcAAM0RAACwBwAADwAE8BoBAAACAArwCAAAABm4BQACCgAA8wAL 8OoAAABCAVMAAABDATQAAABEAQQAAABFwUAAAABGwUoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAQABAA8P8AADIABwA0AA8ALgAY ACQALgAkAEIAIABOABcAUQAMAFMAAABEAAcAKAAUACAAFQAYABwABwAfAAAAIgAAADIAIgAkAAIA AEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAAHYRAAD+BgAAyREAADIHAAAPAATw8gAAAAIACvAIAAAAGrgFAAIK AADzAAvwwgAAAEIBIwAAAEMBKwAAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/wsAAAAiAA8A IwAWABsAHgATACQAFQArAAsAKQABAB4AAAAWAAQADQALAAAAGAAcAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAChEQAAfQcAAMQRAACoBwAA DwAE8DIBAAACAArwCAAAABu4BQACCgAA8wAL8AIBAABCATUAAABDAT8AAABEAQQAAABFwUwAAABG wVYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAATABMA8P8yAAAANQADADIABgA1AA0AMQAWACkAHAAsACMAKQApACwALwAiAD8ADAAv AAAAJwAHACMABwAZABUAEAAcABMAIgAQAC4ACAAyAAAAKAAsAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAAM0RAABxBwAAAhIAALAHAAAPAATw2gAAAAIACvAIAAAAHLgFAAIKAADzAAvw qgAAAEIBFQAAAEMBGgAAAEQBBAAAAEXBIAAAAEbBKgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQ AMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAgACADw/wAAAAAOAAQAEwALABUA FQAOABoAAwAWAAEADwAAAAAAEgAUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB YACAAAAP8BAAAADHEQAAsgcAANwRAADMBwAADwAE8MoAAAACAArwCAAAAB24BQACCgAA8wAL8JoA AABCARAAAABDARYAAABEAQQAAABFwRgAAABGwSIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADA AQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAGAAYA8P8FAAAAAAAEAAAADwALABYA EAAMAAUAAAAOABAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABYEgAAqwcA AGgSAADBBwAADwAD8NAGAAAPAATwVAAAAAEACfAQAAAAzxAAAKUHAABSEgAAqwkAAAIACvAIAAAA HrgFAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAA3xIAAJcGAABiFAAAnQgAAA8ABPDK AAAAAgAK8AgAAAAfuAUAAgoAAPMAC/CaAAAAQgESAAAAQwERAAAARAEEAAAARcEYAAAARsEiAAAA fwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMA AAAABgAGAPD/AQAAAAAAAwABAAwACwARABIACgABAAAADgAQAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAFxIAANYHAAApEgAA5wcAAA8ABPCaBQAAAgAK8AgAAAAguAUAAgoA APMAC/BqBQAAQgGDAQAAQwEGAgAARAEEAAAARcGAAgAARsGKAgAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAoACgAPD/oAAAAJcABQCX AAsAmQARAJoAGQCcACQAlwApAJcAMACZADYApABAAKsAQgCuAFEAngBNAJYARQCPAEkAggBZAH0A XgB3AFwAdgBWAHIAUABmAEwAVQBMAFAAUwBHAFwATwBjAE8AcABNAHcASgB9AEAAhAA9AIUAPwCP AEMAlgBAAJ4AOQCoADEAsgArALkAIQDAABoAwwAVAM4AFADfAA4A6QAOAPcACAD+AAcAAgELAAkB DgAVARUAHgEBAC8BBQA5AQ0AQAEOAEEBDgBIAQQATwEAAFkBBABmAQoAbgEVAHIBIwB1ATEAdgE8 AHgBRQB+AU0AhQFDAIoBOwCSATMAmgExAKMBLQC3ASYAxAEhAM0BLQDcATAA4AE2AOYBPQDlAUYA 4AFKANwBTADaAVkA3AFeAOMBYgDsAWgA8wFwAPQBgQDzAYkA8QGUAPkBnQD2AaUA+AGtAP4BugD4 AccA+AHRAP4B2AABAuAA+wHoAPsB9wD4AQEB/gECAfsBDQECAhYBBgIgAQICIgH7ARsB8QEaAewB FgHbATwBwQFGAcEBSAG9AToBuAEwAa4BFwGYARQBhgEGAYMBBAFyAQEBZAH7AF0B/wBWAQIBUwEK AVQBIQFNAVMBNAFeAS8BaAEoAXEBMQF8AS0BfwEhAX4BGwGDARMBfQEKAXYB+gB7AeMAcwHYAHAB zQB0AcIAcQG5AGIBpwBqAZ0AagGLAGsBdQBaAWIAUgFXAEgBTQA5AUAALwE6ACgBOAAeAT8AFwFD AAEBVADxAFAA6gBQAOoASgDtAEIA8QA7ANwALgDWAC0AzAAkAMkAFQDEAAsAvQANALUAAwCqAAEA oAAAAEIBRAECAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAADPEAAApQcAAFISAACrCQAADwAD8FgI AAAPAATwVAAAAAEACfAQAAAA3A4AAHsIAAAcEQAAKQsAAAIACvAIAAAAIbgFAAMCAAAjAAvwDAAA AAQAAAAAAIgDAAAAAAAAD/AQAAAA7BAAAG0HAAAsEwAAGwoAAA8ABPD6AAAAAgAK8AgAAAAiuAUA AgoAAPMAC/DKAAAAQgEzAAAAQwFcAAAARAEEAAAARcEwAAAARsE6AAAAfwEBAAEAgAEAAAAAgQEG AAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAADAAMAPD/MwAAACIA EwAPABMAAAAfAAMALwADAEgADwBcABwAVwAfAEsALgAyAC4AJAAzAAAAGgAcAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA6RAAAM0K AAAcEQAAKQsAAA8ABPDyBgAAAgAK8AgAAAAjuAUAAgoAAPMAC/DCBgAAQgFAAgAAQwE1AgAARAEE AAAARcEsAwAARsE2AwAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAA zgEAAAAA/wEQABgAiAMAAAAAywDLAPD/CgBQAA8AXgAKAGkACABtAAAAagADAHEAAwB4AAoAgwAX AIAAJwCSAC4AngA4AKcARQCnAEoAsgBVALwAXAC9AF4AwgBaAMsAWgDTAFgA2wBVAOoAYQD3AG4A AQFuAAgBbAAgAWkANAFsADwBdwBFAXcAVQF3AGEBawBQAWQARQFfAEgBYgBQAV4AWgFXAGQBUgBr AVgAcQFUAHkBSgCDAUkAiwFDAJUBNACnASsAuQErALwBMADCASoAygEsANQBNQDhAVgA9AFxAAoC egAHAocAAgKyABQCuAAaArwAJgLDACoCzQArAtwAMwL1ADUC/QArAv8AIAL/ABQCCgEKAiAB/gEp Af0BNQH3AT8B9wFKAf4BUgEIAlwBCAJlAQoCdQEMAoEBGgKKASECmQEmAqUBLQKsAS4CvAEdAsgB GgLQARQC3AEKAuwBCgLrAfYB6AHwAeEB5gHbAegB1QHmAdAB3gHPAcoB2gG9AdIBswHSAa4B4gGd AeIBlwHfAYMB6QF5AeEBbgHhAWUB3wFXAdsBUwHSAVMByAFVAcYBWAHAAV4BuAFhAbUBWAG7AVIB vgFMAb4BRQHNATYB1QEzAdcBJwHfAR0B9wELAf4BCwEBAgQBCgL8ABAC/AATAvcAFwL0AB0C6wAj AtsAJALSACQCyQAsAr8AOQK4AEACsQBAAq4ANQKmAC8CowAfAqEADAKeAAUCnQD+AZoA9wGTAPEB iADsAYEA5QF+ANwBewDYAXoAzQFwAL8BZAC2AVoArQFXAKgBUgCjAUgAlwE5AJQBLwCKASYAhgEd AIEBFgB3AQ8AbQEEAGUBAABPAQEARwEBADwBCQBCARAAOgEaACUBNQAaATsA/QA+APAAQgDpAEgA 5gBOANsASwDJAE4AvQBNALMARgCsAD4ApgA7AKsANACjACwAnAArAJYAKgCVACwAmgAyAJcANgCa AD8AnABIAJwAUACaAFEAlQBVAJMAXACTAGQAkgBpAIoAZwCAAGIAegBnAHAAYQBrAF8AZABkAF4A ZABeAF8ARgBIAEAASAA8AEsAMwBQACwAUQAmAEoAFQBKAAoAUACYAZwBAgAAQACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAANwOAAB7CAAAHBEAALAKAAAPAAPw0AoAAA8ABPBUAAAAAQAJ8BAAAADiDgAA OgYAADcQAAB1CAAAAgAK8AgAAAAkuAUAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADy EAAALAUAAEcSAABnBwAADwAE8NIFAAACAArwCAAAACW4BQACCgAA8wAL8KIFAABCAVUBAABDATQC AABEAQQAAABFwZwCAABGwaYCAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAACnAKcA8P9mAGoBdgB4AW8AhgFlAJEBVQCZAUkAoAE8AKEB NgCnAT8AtwFPALcBVQC5AVUAxAFeAMQBZADBAWgAzQFwANYBfgDWAYgA0wGRANYBewDpAXMA7QFo AOkBTwDfAUIA3wE2AOkBJwD1AR8A/AEVAP8BCgAFAgEACwIAABACCgARAhEAGAIaAB0CJAAYAi0A FAI2ABUCRQAeAlMAJAJcAB4CYQATAnAACgJ6AAoCgwAUAooAGgKVABoCpAAbAq4AHwK4ABgCwAAY AskAHQLSACcC3wApAu4ALAL4ADECBAE0Ag0BLwIaAScCIwEmAi0BJAI2ARsCMAETAiABCgIaAQUC GgH/ASEB+QEtAfgBOAHyAUoB3wFSAdUBVQHEAVUBugFNAbMBQgGrATgBpwEtAagBJgGsASMBpQEp AZoBKwGRASoBggEpAW0BLQFcASoBUwEjAUYBEgEpAQsBGwEIAQsBBwEBAQsB8AALAeMACAHVAAEB zgD0AMEA6wC9AOEAvADaALoA2gCzAN4ArgDpAK0A8wCwAPoAsgD+AKsA/QCjACYBfQAtAXQALQFj ACMBWwAXAVkADQFKAPoASgD6AEoA6ABNAOQATADfAEUA6AA/APAANgABAScADwEmABwBHAApARIA DAELAAABCgDxAAgA4QAAANIAEADSABkAygAcALwAJACwACkAsAA1AK4APwCjAE8AkQBiAIoAbACN AHMAoABxAKEAdQChAH0AiACdAIAArgB6AL0AgADEAIsAtgCXAKYAnwCrAKAAwwChANIAkgDbAIgA 5QCFAO0AmQD+AKoA+wCuAAQBwAD5AL8AAgGwABQBtgAoAbgAMwHIADQByQA+AbYAVAGwAFEBqQBY AacAYwGVAFkBZgBqAVABVAECAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAWAAgAAAD/AQAAAA4g4AAEEGAAA3EAAAdQgAAA8ABPDSAAAAAgAK8AgAAAAmuAUAAgoAAPMA C/CiAAAAQgEcAAAAQwEVAAAARAEEAAAARcEcAAAARsEmAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQ ABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAABwAHAPD/DwAAABsAAgAcAAkA DwASAAIAFQAAAAwADwAAABAAFAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAABdDwAAUgcAAHkPAABnBwAADwAE8NIAAAACAArwCAAAACe4BQACCgAA8wAL8KIAAABCARwA AABDARQAAABEAQQAAABFwRwAAABGwSYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjE AQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAHAAcA8P8XAAAAHAAKAA4AEQADABQAAAAKAAUA BAAXAAAAEAAUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAEoPAADO BgAAZg8AAOIGAAAPAATw2gAAAAIACvAIAAAAKLgFAAIKAADzAAvwqgAAAEIBEAAAAEMBJwAAAEQB BAAAAEXBIAAAAEbBKgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEA AM4BAAAAAP8BEAAYAIgDAAAAAAgACADw/wYAJwAQAB0ADAAQAAkACgAGAAAAAAAEAAMAEgAGACcA EgAUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB0DwAAZwYA AIQPAACOBgAADwAE8BIBAAACAArwCAAAACm4BQACCgAA8wAL8OIAAABCAUoAAABDAUsAAABEAQQA AABFwTwAAABGwUYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADO AQAAAAD/ARAAGACIAwAAAAAPAA8A8P8aAAAAKwAAADcAAwBAAA8ASAAiAEoAMwBBADsAPgBHADYA SwAuAEEAJgAuACEAKAASACYAAAATABoAAAAgACQAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAADDwAAAQcAAE0P AABMBwAADwAE8OIAAAACAArwCAAAACq4BQACCgAA8wAL8LIAAABCASYAAABDARwAAABEAQQAAABF wSQAAABGwS4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAA AAD/ARAAGACIAwAAAAAJAAkA8P8iAAAAJgAHABgADwAKABwAAgAZAAAACgAAAAUAFwAAACIAAAAU ABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABvDwAA OgYAAJUPAABWBgAADwAE8PAQAAACAArwCAAAACu4BQAACgAAAwEL8MgQAAAEAAAAAABCAc8JAABD AfEFAABEAQQAAABFwSwIAABGwTYIAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAA AADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAALAgsC8P90CQkAZwkAAFkJAABQCQEASgkMAD8JCQA3 CQwAMQkbAB8JPQAoCVIAIQlrACcJdgAmCYoAIwmcABgJnwAPCZUA/gi9AN0IxQCyCNIAkwjaAHsI 7wBqCAYBXAgHAUwIIAFTCCkBVwg9AU8IRAFECFMBOAhXATQIYQEfCGQBAghlAesHcwHuB4kB5wec AdQHtQG8B8wBpAfVAZ0H5wFsB/sBUQf1AUwH7wFYB+MBWQfTAVAHxQFaB74BaAfBAWYHowFjB4sB Wwd1AU4HagE8B2UBLgdvASEHgQETB30BGAd0AR8HbwEoB2kBNQdZASsHOgEoByEBEwcdAe0GBgHX BhAB0wYbAdgGJAHNBikBzAY7AcIGOwGyBkoBrAZVAacGYQGmBn4BowaeAasGsAG2Bs4BtgbzAawG HAKaBh8CjgYYAoQGCQJ5BvMBewbWAXsGwwFyBrEBdAaNAXgGcAF6BmEBjAZIAYIGPQF5BkIBcwZQ AV4GZgFqBlQBawZHAWcGOAFqBioBcwYdAXUGCgF5BgABfQYRAY8GEgGaBgcBrAb/AMAG/QDIBgQB 1wYBAe4G/AD6BvsA/AbxAP4G8QD0BuYA5wbgANEG2QC+BtkAsgbXAKwGzwCWBswAggbQAHQG0gBk BuAAUAbXAEAG0AAtBtkAIAbTAC4GvwAqBrgAIga7AA8G0gAABuQA8QX4ANwF9gDTBd8AywXgAMQF 8QCrBfIAxgXQAAUGqQAJBp8A5gWhAMIFlAC1BaUAmQWbAIcFogB7BY4AXAWPAFMFmAAwBYIAKwVt AAMFZQAVBYIAxQJvAKECZgBiAl4AEgJSAK4BSQCIAUIAUgE5ACsBMADDABIAvAAVAL8AIwDFADMA wAA6ALkAQQC9AEwAzABlAMAAdgC5AIsAqACLALYAgQC7AHYAuABrAK8AaACzAGAAvwBjAL8AXQC3 AEoArgBJAJsARgCMADgAggAxAHYALABuADkAcwBOAHYAXwB0AHQAcwCHAHYAjgB9AJwAdgCmAHcA rwB4AL4AbQDDAGUA5QBdAAMBUQAiAUIAOgE0AFkBJgBsASYAmwEmAMUBIADVARIA8AEAAA0CEgAy Ag0AUAIIAGUCFwCKAiIAogIyAKwCQQCbAkYApgJKAK8COwCxAjwAvAIuALUCMADMAjYA4AI5AO8C TADsAkkA8wI5AP4COQAWA08ALgNYADYDUgBAA1kATgNdAF8DYwBqA2YAdwNnAIQDYwCNA3IAkQOA AJIDjACPA5sAkQOfAJ0DogCnA7EAtwO4AL4DvwDLA8AA0wPOANsD2gDmA+cA+gPpABIE6AAfBPUA IQQDAR4EEQEdBCYBHgQ6AR8EVQEfBGcBIQRqASwEZgE3BHwBRQSSAVAEvAFmBNsBdwT9AYQEIAKQ BDcCkgRLAo8EagKTBH4ClgSUApQEqQKZBLsCmAS9An8E3QKDBAMDhAQhA6cERQPFBFoD3ARbA/AE YgMGBXADFQV/AyMFqwM+BboDOgXDAzIFyAMiBcwDFQXdAxQF8AMVBQgEGgUWBCQFKAQsBS4EOQU3 BE4FQARiBUoEcgVcBH0FawSNBXEEpAV3BLcFgwTWBZQE2QWnBOEFugTmBdME5wXhBPEFAwXvBQUF 1wXyBMYF7wSsBfwEmgX7BIcFAAWCBQIFdAUOBWwFJAVdBTAFXQVLBUwFXAU8BXcFLAVwBRcFdgUS BX4FKAWjBQgFwQUJBeoFEgUKBg0FGQYLBREG/QQfBv8EKAYKBSgGFAVGBhYFVQYXBVsGEQVoBhwF cgYfBX4GHAV1BgsFgwYKBYwGDwWZBhkFogYWBasGDAWlBv8EmAb6BJAG8wSWBuUElQbYBIgG2AR8 BuUEegbTBGoG3QRbBuIEVgbZBGIGygSMBtIElQbCBKoGvATCBsIEywa8BMsGqATXBsEE2wbKBO0G wAT7BrAEAge6BA4HvgQhB7YESQevBFEHuARbB8MEawfGBHsHyASOB8EEmge1BKUHsQSsB7YEtgfB BMUHzgTTB9IE3wfUBOwH4QT0B/AE/gf6BPoHDwX7ByAF+wcsBf8HNQUFCDcFCQglBRIILwULCD0F CQhJBREITwUhCF8FLghiBTUIdgU9CHoFSQiQBVkImAVoCJ4FcwiwBYkIrAWnCKUFrwiEBaoIbwWq CEoFogg/BZMILQWGCBkFeggABW4I4wRcCMgETQi1BDsImgQuCIMEKQhvBCcIYAQqCFMELQhOBC4I LgQ/CBEEOwj/A1UI+AN2CNgDhwikA7EIkgPKCGID8whTAwcJLgMHCRQDCAn9Av4I/gL+CCQD5QhA A8MIRwPkCDYD0QguA+QIKgPwCCsD9ggVA/QIAQPiCAEDxwgLA8gI+ALXCAAD7gj1AvEI6wLhCOUC 4wjOAtEIxQLLCM0CxQi9AscIqwLKCJkCqgiMArMIiAKrCGECqghKArAIRAKxCGQCvQh6As8IjwLP CLcC4wi6AvMIkgLyCFgC3QhIAt8IPAL4CEkCBQkrAgYJEgIGCecB+gjZAQAJzgEJCdoBPQm/AWEJ ogFGCZ8BHwm2AQYJwAEYCaoBKQmfATMJowFPCZQBVQmGAV0JhgFoCX8BdAlxAYkJeQGUCW8BnQlh AZQJTwGHCUQBfwlDAXUJSAF/CVcBhAlgAXgJXwFrCU4BXglRAWEJRAFnCTYBXAk0AWUJGQFiCQkB bwn9AGgJ7AB0CeQAggnaAI8J1QCUCboAogm6ALUJrQC/CZ8AzwmSAM0JgAC3CXcAqgllAJIJZQCI CVAAhQk5AH4JJAB0CQkAGAQcBAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAFgAIAAABDwCAAAADYDcQtaEVoHDwAD8GSEAAAPAATwTAAAAAEACfAQAAAAiAAAAN8CAAD5 CQAAqwwAAAIACvAIAAAALLgFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAAigPwACsL Vg0PAAPwjgsAAA8ABPBUAAAAAQAJ8BAAAABiCwAAdwgAAC0MAACRCQAAAgAK8AgAAAAtuAUAAwIA ACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADfBgAAyggAAOoHAABhCgAADwAE8AIBAAACAArw CAAAAC64BQACCgAA8wAL8NIAAABCATsAAABDAVQAAABEAQQAAABFwTQAAABGwT4AAAB/AQEAAQCA AQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAANAA0A 8P8tAAAAOwAEAC0ALAAgADAAGgA6AA4ARQAKAFQAAABLAB4AJwAfABsAIwAbACUACgAtAAAAHAAg AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAGILAAAOCQAAnQsAAGIJAAAPAATw+gAAAAIACvAIAAAAL7gFAAIKAADzAAvwygAA AEIBGQAAAEMBHAAAAEQBBAAAAEXBMAAAAEbBOgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMAB BwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAwADADw/w4AAAABAAAAAAAGAAAACwAQ AAwACgATAAkAGQAPABwAFwAYABkADgAVAAYADgAAABoAHAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAKALAADwCAAAuQsAAAwJAAAP AATwwgAAAAIACvAIAAAAMLgFAAIKAADzAAvwkgAAAEIBDQAAAEMBEQAAAEQBBAAAAEXBFAAAAEbB HgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAY AIgDAAAAAAUABQDw/wEAAAANAAQACAARAAAADQABAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAADwCwAA1AgAAP0LAADlCAAADwAE8EoBAAACAArwCAAAADG4BQACCgAA8wAL 8BoBAABCASYAAABDAT0AAABEAQQAAABFwVgAAABGwWIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAWABYA8P8KAAAAFwAGAB8ABwAf ABgAJgAjABUAIwAUACwAGwAxABoANAAMAD0ADAAwAAkAMAAIACgAAAAhAAEAIAAHABsADAAcAAcA FwAIABIAAQARAAMABwAKAAAALgAwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAPULAAD1CAAAGwwAADIJAAAPAATwAgEAAAIACvAIAAAAMrgFAAIKAADzAAvw0gAA AEIBMgAAAEMBOwAAAEQBBAAAAEXBNAAAAEbBPgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMAB BwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAA0ADQDw/yAAAAAnAAUAMgAKADEAEwAg ABMAJgAcABwAIgAVAC0AAAA7AAgAEQAaABEAGgAGACAAAAAcACAAAgAAQACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAvwsAAPwIAADx CwAANwkAAA8ABPBSAgAAAgAK8AgAAAAzuAUAAgoAAPMAC/AiAgAAQgFmAAAAQwF+AAAARAEEAAAA RcHcAAAARsHmAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAANwA3APD/FAAIACAABgAvAA0ANAAJADQAAAA7AAwAQgATAD0AGQA9ACAA QwAsADwAMwA8AEIAMABCADAASQA0AE8APQBPAD0AVQA1AFsAMABaADUAYABBAGEATwBaAFgAZQBg AGsAYgB3AGYAeABmAH0AWwB+AFYAeQBPAHgASQBzAEcAegA8AH4APAB3AEIAcwA9AGsAGQByABcA aAAfAGMAHgBaABkAWwAFAE4ABwBGAAAAQgABADYACAA2AAUAPwAKAEMAEgBCABEAMAALAC4ACgAl AAcAHwARAAAAFAAIAHAAdAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBYACAAAAP8BAAAACKCwAAdwgAAPALAAD1CAAADwAE8LoAAAACAArwCAAAADS4 BQACCgAA8wAL8IoAAABCAQwAAABDARIAAABEAQQAAABFwRAAAABGwRoAAAB/AQEAAQCAAQAAAACB AQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAEAAQA8P8AAAAA DAAJAAQAEgAAAAAACgAMAAIAAEAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAABQMAAAeCQAAIAwA ADAJAAAPAATwygAAAAIACvAIAAAANbgFAAIKAADzAAvwmgAAAEIBCQAAAEMBFwAAAEQBBAAAAEXB GAAAAEbBIgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAA AP8BEAAYAIgDAAAAAAYABgDw/wMAAAAJAAoACQAXAAMAEQAAAAsAAwAAAA4AEAACAABAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACIMAAApCQAAKwwAAEAJAAAPAATwCgIAAAIACvAI AAAANrgFAAIKAADzAAvw2gEAAEIBZgAAAEMBWgAAAEQBBAAAAEXBuAAAAEbBwgAAAH8BAQABAIAB AAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAC4ALgDw /0gAAABTAAAAUwAGAFkABgBgAA0AYQAUAGYAHQBmADUAXwA+AF8ARwBYAEcAWQA7AEwAPABMAD8A UwBBAFMATQBMAFIASQBaAEIAUgA5AFIAMQBJACkAQAApAD4AMQA1ACkANgAmADAAIwA1ABMANwAS ACwACwA2AAwAPwAFAEcAAABBAAAALgAHACkADwAoABIAJAAXACIAHQAdACkAHQAuACIALwAdADoA HgA6ABEASAAMAEgAAABeAGAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAxwsAADcJAAAtDAAA kQkAAA8AA/BiDgAADwAE8FQAAAABAAnwEAAAAPUKAACrBAAAxwsAAEAHAAACAArwCAAAADe4BQAD AgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAIgGAABTAwAAmwcAAAwHAAAPAATwCgEAAAIA CvAIAAAAOLgFAAIKAADzAAvw2gAAAEIBDQAAAEMBFgAAAEQBBAAAAEXBOAAAAEbBQgAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAA4A DgDw/wIADgAEAAoABQAEAAYAAQALAAAADQAFAAsADgAJABIACAAVAAUAFgACABYAAgAUAAAAEgAC AA4AHgAgAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAAB0CwAAogYAAIELAAC4BgAADwAD8OwMAAAPAATwTgAAAAEACfAQ AAAA9QoAAKsEAADHCwAAQAcAAAIACvAIAAAAObgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA 9QoAAKsEAADHCwAAQAcAAA8ABPByAgAAAgAK8AgAAAA6uAUAAgoAAPMAC/BCAgAAQgFnAAAAQwGP AAAARAEEAAAARcHsAAAARsH2AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAA ywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAOwA7APD/RgAAAEsADgBGABYAPwAWADsAHAAqACMAFwAg AAUAIQAAAB8AAAAnAAQALQAJADUAEAAzABMANwAXADcAGwBBACIARgAfAEwAJwBUACUAXgAZAGMA HABoACIAbgAlAHMAJwB9AC8AhgA1AIIAOwCLAEEAjwBDAI4ARACGAEMAfgBHAHsASQBzAEAAcQA2 AHYALQB2ADEAbQA4AG0APwBnAEEAXABKAFkATgBWAFoAVwBbAFQAYwBRAFoARgBWAEAAWQA3AFkA LwBhACYAXwAhAGMAIABjABgAZwAUAGIAEABfABAAUgAHAEYAAAB4AHwAAgAAQACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAA AA/wEAAAAPUKAACrBAAAXAsAADoFAAAPAATwKgQAAAIACvAIAAAAO7gFAAIKAADzAAvw+gMAAEIB jwAAAEMBQwEAAEQBBAAAAEXByAEAAEbB0gEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAA CMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAHIAcgDw/yMADAAtAAoANQAOADwADgBFABMA SgAcAFAAIABRACoAVAAyAF4AOgBTAD4AWABCAFsASABwAFgAcQBgAHYAawB9AHIAigB3AIcAggCP AJEAjgCWAHoAlgB6AJ4AdgCkAHYAqQB4ALMAdgC8AHMAwwBuAMkAZwDSAGsA2wBjAOEAaADpAGkA 8ABrAPwAaAACAWAA/wBaAAEBVAD8AFAA9gBPAO8ASgDrAEQA8QA9APYANgD8ADYABQExAA8BLQAV AS0AGwElACABHAAmASQAMgEfADgBFwA3AQ0AQwEJAEMBAABAAQwAIwEJABIBDgAHAQ4A/wAUAPoA FwD9ACEA8wAlAOUALQDfADAA1gA1ANoAPQDRADsAyQA2AMYAMgCqACsApAAoAJ0AKQCWAC0AkAAw AJIAMACeADYAoQA5AKMAPQCgAD4AmQA+AJIAQwCNAEIAfwA9AG0AQABjADwAWwA2AFUANgBPAC8A RgArAEAAKgA5ACQANgAdADsAGgA3ABYALwAUACoADgAtAA0AJgANAB8ABwAXAAkAEgARABIAFgAV ABcAEAAbAAsAFAAGAA8ACwALAAoADQACABMAAAAaAAUAIwAMAOYA6AACAABAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAADgL AAAkBQAAxwsAAGcGAAAPAATwggEAAAIACvAIAAAAPLgFAAIKAADzAAvwUgEAAEIBJAAAAEMBPwAA AEQBBAAAAEXBdAAAAEbBfgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAAB0AHQDw/yIABQAYAAAAFAADAA8ABAAMAA0ACQAQAAgAGQAG AB8AAAAiAAIAKQADAC8AAAA3AAMAPAAHADcACgA8AA4APwASAD4AGAA+ABsANgAXADMAFwAoABQA IgAZAB0AHAAbACEAGgAkABgAJAATAB8AEAAiAAUAPABAAAIAAEAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABoCwAAKQYA AIwLAABoBgAADwAE8IIBAAACAArwCAAAAD24BQACCgAA8wAL8FIBAABCAUIAAABDAToAAABEAQQA AABFwXQAAABGwX4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADO AQAAAAD/ARAAGACIAwAAAAAdAB0A8P8cAAAAEQAFAAwABQAJAAwABwAUAAUAFwAHABwAAAAiAAYA KAAOACsAFAAlAA4AFwAZABgAIgAaACUAIAAmADMALAA4ADEAOgA3ADYAOQAyAEIALABBACUAPAAi ADgAFwA1ABEAMwAHADEAAAApAAMAHAAAADwAQAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAOAsAAG0GAAB6CwAA pwYAAA8ABPDaAAAAAgAK8AgAAAA+uAUAAgoAAPMAC/CqAAAAQgENAAAAQwELAAAARAEEAAAARcEg AAAARsEqAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA /wEQABgAiAMAAAAACAAIAPD/BwAAAAEAAQAAAAgAAwAKAAkACwANAAcADAACAAcAAAASABQAAgAA QACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGILAAC1BgAAbwsAAMAG AAAPAATwCgEAAAIACvAIAAAAP7gFAAIKAADzAAvw2gAAAEIBNAAAAEMBOgAAAEQBBAAAAEXBOAAA AEbBQgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8B EAAYAIgDAAAAAA4ADgDw/wUAJQAOABkAFQALABcAAwApAAAANAANACwAJQAjAC4AHgA2ABEAOgAF ADoABQA1AAAAMAAFACUAHgAgAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABhCwAA1gYAAJULAAAQBwAADwAE8NoAAAAC AArwCAAAAEC4BQACCgAA8wAL8KoAAABCARoAAABDARgAAABEAQQAAABFwSAAAABGwSoAAAB/AQEA AQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAI AAgA8P8OAAAAAwACAAAAEgAFABcAEwAYABoADgAZAAMADgAAABIAFAACAABAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAXQsAACgHAAB3CwAAQAcAAA8ABPBABgAAAgAK 8AgAAABBuAUAAgoAAAMBC/AQBgAABAAAAAAAQgF1AwAAQwEsAwAARAEEAAAARcHQAgAARsHaAgAA fwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMA AAAAtAC0APD/dQIAAEcCKgBYAjAAVwJXAF0CbAA/AoIATAKsAGoCnQB6Ap0AcwKyAGgCyABhAt4A WwLwAE4C+wA6AvoAOQIQAUQCGQE8AjoBMAJBARcCWgECAmsB3AFwAZwBcAGOAXgBewGDAWsBdAFY AWsBSgFkATgBXwEKAV8BCgFOAQEBNQHuAC4B0QAoAcgAHgGzACwBrQBJAYoATgFnAMABbADGAVIA zwFBANkBMgDiAR8A4gEQAO0BAAD7AQsAEwIZACMCHwArAhIALgIlAFACXgBQAngAZgJrAHICYAB4 Al8AhgJaAJkCYACoAm4AvwIgAeMCLwHhAjYB4wI8AdsCPwHSAkkBzAJjAdgChAG8ApkBoQKuAbMC uAGyAsMBuQLbAa4C5wG6Au4BygLuAeYC6wH8AusBDgP7AQYD/QEAAygCLANBAgsDTgIGA2UC/QJ1 AvQCggLzApEC6AKWAugClwLtAqYC9AKyAvQCvALxAsoC7ALgAuwC4AL6AuQC/gLsAv4C9AL2Av0C 6AIPA+ICFgPhAhwD2wIaA9ECIgPEAhsDuQIiA6cCLgOmAj4DoAJRA5ECVgOGAl0DcgJnA1ICaQNA Am0DLgJ1AxACbQP+AW0D5wFoA9cBXAPRAVwD3QFRA9wBUQPQAVcDxAFXA7gBSgO/ATkDvwE0A7kB PQO3AUYDrQFWA60BSQOgATEDmwEcA5EBEgOEAQoDfAEKA2UBEQNcARUDVAEhA0kBIgM9ARwDOwET A0MB+AJIAfcCVAHyAmEB0wJOAc4COgHUAiwB2QIYAeECCQHsAv8A9wILAfcCHQH9AigB/wIvARYD CwEWA/kAHAP2ABwD6wAhA9cAHQPJACQDwAA7A7kAJwOuADQDnQA9A4gASgONAEsDhABDA3oALgNf ACgDVAA4A0cANAMYACEDAQAVAwEAEQMjAP0CKwDlAhcAtgIrAJcCCwB1AgAAagFsAQIAAEAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9wEAAPgDAAB/BgAAjQgA AA8ABPBAAQAAAgAK8AgAAABCuAUAAgoAAAMBC/AQAQAABAAAAAAAQgFVAAAAQwFHAAAARAEEAAAA RcFQAAAARsFaAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAAFAAUAPD/AAAAAAAACQAIABEAGAAYACEAIQAvAC0ANwAwAEgAQQBTAEcA UgBDAFUAQQBIADsARAA1AFAAMwBFACwAOwAlACoAHAAgABAAEAAGAAAAAAAqACwAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAP4FAAAEAwAAbwYAAGgDAAAPAATwYAEAAAIACvAI AAAAQ7gFAAIKAAADAQvwMAEAAAQAAAAAAEIBKAAAAEMBYAAAAEQBBAAAAEXBYAAAAEbBagAAAH8B AQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAA ABgAGADw/xIAAAAHAAUAAAASAAAAIwAAADcABABIAAwAUQARAFUAFwBdACAAYAAjAFsAHQBTAB0A TgAlAEUAKAA9ACUAMgAhAC4AIgAhABwAHQAaABkAHwAZAB8ADwAcAAoAEgAAADIANAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAFwGAAAYBwAAkQYA AKEHAAAPAATwUAEAAAIACvAIAAAARLgFAAIKAAADAQvwIAEAAAQAAAAAAEIBNwAAAEMBQQAAAEQB BAAAAEXBWAAAAEbBYgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEA AM4BAAAAAP8BEAAYAIgDAAAAABYAFgDw/ywAAQAmAAgAGQAMAA4ADwAIABQABAAZAAAAJAACACoA CgAzABMAOgAbAEEAIgA+ACkAOAAtADMAMQApADQAHgAzABoANwAUADcADAA1AAQAMwAAACwAAQAu ADAAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAbwUAAE0IAAC4 BQAArAgAAA8ABPCAAgAAAgAK8AgAAABFuAUAAgoAAAMBC/BQAgAABAAAAAAAQgHUAAAAQwFBAQAA RAEEAAAARcHwAAAARsH6AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGc MQAAzgEAAAAA/wEQABgAiAMAAAAAPAA8APD/fwAIAHUADABoAAwAWgAFAFoAAABTAAAAQgAMADcA DAAfABgAAAAkAAwAMQAlADwAJQBCADAAQwA2AD0AQgBJAEcASgA8AFMAQgBmAFIAawBqAHUAeQCE AIoAigCPAI8AmgClAJwArAClALYAqwDAAK4AxgCoANYAnQDnAI8A8ACSAPcAlQD6AJUAAgGJAAkB hAAUAYQAGgGLABgBhAAjAYkAQQGSAEABowAoAagACAHLAPgA0gDlANQAzADPAMQA0wC/AMUApwC4 AJoAtACPAKwAiACjAIEAkAB3AHwAbABtAGMAYQBZAGsALwB/AAgAegB8AAIAAEAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAsAQAACwIAADFBQAA+QkAAA8ABPDIAQAAAgAK8AgAAABGuAUAAgoAAAMBC/CY AQAABAAAAAAAQgGyAAAAQwGaAAAARAEEAAAARcGUAAAARsGeAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAJQAlAPD/GAAAACIADQA7 ABcAOwAeAEYAHgBMABkAWAAkAF8AJQBTAC8AWABAAGgARgCBAFEAjwBfAKAAZQClAGsAqwB1ALAA fwCyAIkApwCJAJoAjwCaAJoAjgCaAIkAkACIAIgAfAB9AHwAdgBwAHYAaABwAGkAXwBjAFkAIgBT ACEATgAWAEwABQA7AAsAJAAAAB8AGAAAAEwAUAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAADKBAAAYAgAALMFAAA8CQAADwAE8HABAAACAArwCAAAAEe4BQAC CgAAAwEL8EABAAAEAAAAAABCAXcAAABDAW0AAABEAQQAAABFwWgAAABGwXIAAAB/AQEAAQCAAQAA AACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAaABoA8P9m AAAAWwAAAEwABwBMABEAMgARAAAAKwAAADYADAA+ABcATgAcAGUAJABlAC8AbQA0AGYAQQBtAE0A bQBNAGcAUgBdAF4AVgBfAE8AWwBJAFkAQwBmADwAcQAqAHcAGQBtAAkAZgAAADYAOAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA9wQA ACIJAACUBQAAvgkAAA8ABPAYAgAAAgAK8AgAAABIuAUAAgoAAAMBC/DoAQAABAAAAAAAQgG1AAAA QwE7AQAARAEEAAAARcG8AAAARsHGAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEA AAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAALwAvAPD/KwAAADwAEgBHABMASQAZAIgAHgCQACQA jwA2AJYAPACiADwAowBCAK8ATwCvAFYAtQBgAKYAYAB0AHkAdACEAH8AiwCKAJsAkACzAHQAoQBQ ALkATQD0AFUA7wCdADABlAA7AX8AKwF6ADEBcwAxAUcADAE8ABUBPADfAEMA0gBCALMAPACmAD4A mwAmAIsAHgB/AB4AbAAmAGYAIABcAAAAPQAHADcABwAgABcAIAAdABUAHgAAACsAAABgAGQAAgAA QACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAJkEAACxCAAAhwUAAHYKAAAPAATwSAIAAAIACvAI AAAASbgFAAIKAAADAQvwGAIAAAQAAAAAAEIBsgAAAEMBegEAAEQBBAAAAEXB1AAAAEbB3gAAAH8B AQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAA ADUANQDw/y8ADABIAAAAVQALAF0AHABdADcAWgBNAFoAXgBnAFgAagBRAJUAfAChAIIAmgCZAI4A mACNAK8AhwC5AHcAuQB2ANEAbwDVAI8A8wCWAP4AjgAEAY4AFwGWACQBrgAyAasAPgGyAEsBsgBq AasAegGnAHYBpgBUAYwAOAGJAB8BfgAMAXYA8wBqAPIAYgDuAF4A8QBpAPgAawAHAWQABQFaAA4B RgAbATUAFQE5AAIBLADdACkA1AAAAK4ADACkAAoAggAcAFEAHAAzACkAJwAvAAwAbABwAAIAAEAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAAIBAAA1QcA APEEAAD5CQAADwAE8BABAAACAArwCAAAAEq4BQACCgAAAwEL8OAAAAAEAAAAAABCATsAAABDAVUA AABEAQQAAABFwTgAAABGwUIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAAOAA4A8P8ZAAAAAAASAAgAHgAIACQAAAAjAAAAMQALADEA EwA+ABEASQAfAFUAOwA0ADYAEgAiAAUAGQAAAB4AIAACAABAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAYQYAAGAFAACsBgAA 3QUAAA8ABPB4AQAAAgAK8AgAAABLuAUAAgoAAAMBC/BIAQAABAAAAAAAQgFaAAAAQwGWAAAARAEE AAAARcFsAAAARsF2AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAA zgEAAAAA/wEQABgAiAMAAAAAGwAbAPD/LwAGACMAAAAWABgACwAmAB0AMgAJADgAAQBDAAYATwAA AGQAAABxABIAcQASAHcAGACFABIAkgAdAJYALACKAEIAhQBaAHQAWgBuAEcAaAA2AGYANwBhAC4A TwA2AEoAPAAtAC4AGQAvAAYAOAA8AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAACQYAALwEAAB/BgAAlAUAAA8ABPDoAQAAAgAK 8AgAAABMuAUAAgoAAAMBC/C4AQAABAAAAAAAQgG0AQAAQwEDAQAARAEEAAAARcGkAAAARsGuAAAA fwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMA AAAAKQApAPD/eQEAACABNgADATEA7wAxANkARACxAC8AkAAwAIcAUACUAFwAZABnAEQAYwAUAIgA AACeAAkAqQAkAK4AOAC2AEEAywBBAN8AbwDgAIMA5ACkAPUAtAADAdQA8QAZAe8AOgHrAEwB3QBX AdIAaAHBAHYBuQB9AZgAcgGOAHIBegCHAXsAlQFvAJoBXQCgAUoArQExALQBGwCgARsAhQEpAHkB AABUAFgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAAPwCAACzBAAAOgUAACsGAAAPAATwsAEAAAIACvAIAAAATbgFAAIKAAADAQvw gAEAAAQAAAAAAEIBdQAAAEMBYAAAAEQBBAAAAEXBiAAAAEbBkgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAACIAIgDw/wAAAAAKAAgA EAAIABwADwAoABQAMwATADoADQBAAAgATQAAAFQAAgBRAA4ATAAUAEMAGABBABwATgArAFYALABT AB8AWgAZAF8AJwBqADMAcQAiAHUAQQBoAEsAYABgAFsAVQBZAE0AVQBEADEANgA3AD4ANgBPABYA VQANAC4AAAAfAAAAAABGAEgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAfwMA AGUIAAAbBAAA7ggAAA8ABPAgAQAAAgAK8AgAAABOuAUAAgoAAAMBC/DwAAAABAAAAAAAQgE6AAAA QwE2AAAARAEEAAAARcFAAAAARsFKAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEA AAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAEAAQAPD/FQAAAAoABgAHABAAAAAYAAcALAASADUA FwA2AB4AMAAhACwAJwAoAC8AKAA4ACEAOgAYADYABgAvAAsAFQAAACIAJAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACA AAAP8BAAAACKAwAAAAgAANUDAABNCAAADwAE8CABAAACAArwCAAAAE+4BQACCgAAAwEL8PAAAAAE AAAAAABCAZsAAABDAUkAAABEAQQAAABFwUAAAABGwUoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAQABAA8P8CAAAAmwAeAJsAPwCS AEkAfwBJAHIAOwBsAEMAWQBDAE8APQA9ADYAIwA2ABMAJgAAACsAAAANAAUACAACAAAAIgAkAAIA AEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAAKQCAAD0BwAAcgMAAGAIAAAPAATwOAUAAAIACvAIAAAAULgFAAIK AAADAQvwCAUAAAQAAAAAAEIBIQIAAEMBXgIAAEQBBAAAAEXBTAIAAEbBVgIAAH8BAQABAIABAAAA AIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAJMAkwDw/+YA dQDOAHAAvQBVALkASwC+ADcAvgAqAMoAJQDYABcAvQAAAJoAEgBlABYAZQAuAHAANABwAD4AfgBH AIMARgB7AE0AdgBbAHcAYgByAGoAbQB0AGYAewBfAIMAWACPAE4AnQBIAKUASACxABkAtwAYAMgA JADJACQA5QA1APEANQD+ABMA/gAAABABAAAXAQsAGwEcABYBKgAcASMAIwEZADkBLwBLAU0ALQFZ AC0BWQBBAWAATQFYAGkBYAB1AWUAlQFlAKsBeADIAYoA4AGKAOoBlAAEAqEADwKhABoCqwAhArAA JQK6ADMCswA9ArgASwK+AFECygBXAt0AXgLjAEwC6QBEAvUAPgL0ACcC/wAhAv8A8wEHAecBAgHi AfoA1QH7ALEBCwGxASUBpAErAZkBIwGKAUABfwFMAXEBWwFSAWYBTAF0AUoBeQFHAXcBOQF+AS4B eAEtAYABIAGMARcBoAEXAZcB7gCLAeAAiwHEAJIBzACaAcwApQHSALEB1gC9AdYAxAHQAM8ByADX AcIA3gHFANsBzwDVAdYAzAHZAMoB3QDXAe4A4QHuAN4B4QDjAdwA6QHpAPQB9gD7AeQA/gHbAA4C sgAOApIAGQKJACECagAYAmMADQJjAPcBUADiAWwAxwGCAMsBlADIAZ4AwQGjALkBowCxAagAqAGy AJoBqACUAZQAjwGSAH4BkgB+AbIAdAG8AGMBvABVAa4ATgG2AD4BtgAtAa4AHwGoAAYBqAD2AJkA 5ACeAOQAgwDpAHwA5gB1ACgBLAECAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAD4EAABM BwAADQcAALYKAAAPAATw8AIAAAIACvAIAAAAUbgFAAIKAAADAQvwwAIAAAQAAAAAAEIBhgQAAEMB EQMAAEQBBAAAAEXBKAEAAEbBMgEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAA AMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAEoASgDw/wAA+gIkABEDMQAKA0UA9gJTANYCYgDdAnYA 4QKHAO0ClwDzAtMA8wLkAN0C7gDdAvQA+QIMAfICKwHyAjcB7wIjAdYCGAG/AigBsQI2AacCSAGn AmkBlAKDAYsCfwGDAqEBEgLEAQ0CywHxAd8B5AH1Ac0BJQKoAUICrQF1AqIBZwKVAW8CdQGPAnUB uAKJAc4CdwHgAncBAQN7AS8DXwFVA0kBdgMxAW4DGQFxA/MAYQPtAIwDxgCrA88AywPwAPsD3QAT BPMAKgToAC0ExQA2BMcARwTbAE8ECwE8BBgBYQRHAYYEJgGABPwAbAS1AGwEkwA+BHAAMARGABoE SAAUBD0ABAQtAPsDOwD5A1MA5QNaAM0DUwDNAyIAuQMAAAAAAAAAAPoClgCYAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAACIAAAA3wIAAHoGAABJBwAADwAE8MABAAACAArwCAAAAFK4BQACCgAAAwEL 8JABAAAEAAAAAABCAQQBAABDAcsAAABEAQQAAABFwZAAAABGwZoAAAB/AQEAAQCAAQAAAACBAQYA AAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAkACQA8P8uAAAAIAAg AAwANAAAADsACQBZAAMAiwADAKcABwC4AE8AywBvALsAdgCfAIkAqACOAJ0AoACXAKgAjQCuAH4A uAB6ALMAZgDEAGYAxABhANAASADRAEIAywA3AOUAKgD8ACMABAEdAOkAHQDQACMAygAGAMEABgCu AB0AdAAdAGUAGABUAAwAPgAHAC4AAABKAEwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAAC3AAAA9AYAAA0CAAAZCAAADwAE8IgCAAACAArwCAAAAFO4BQACCgAAAwEL 8FgCAAAEAAAAAABCAUkBAABDATMBAABEAQQAAABFwfQAAABGwf4AAAB/AQEAAQCAAQAAAACBAQYA AAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAA9AD0A8P8EAJ4ARgCv AGYAoABtAIIAgQCMAIYAgACYAHoAngBxAKQAYgCvAF4AqgBKALsASgC6AEYAxgAvAMgAJwDCABoA 2gAPAPIACAD9AAAACAETABABIwBJASMAJwE1APIAOQDyAFAA/wBXAP8AYAAJAWgAEAFpAAgBcAAE AXwABQGGAAEBiwD7AJcA7wCjAOUAtADWAMkA1gDUAKYA2wCmAOoAsgDqALIABwHDABIBwwAhAaAA IQGPADMBeAApAWgADwFZAP0AQQAIASgAAgEcAAoBAAABAQsA8wAaAOUAIgDcAB8AzgAdAL8ACwC9 AAQAsgAEAJ4AfACAAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAMIAAAAcBwAAcQIAANYI AAAPAATwOAEAAAIACvAIAAAAVLgFAAIKAAADAQvwCAEAAAQAAAAAAEIBTgAAAEMB+AAAAEQBBAAA AEXBTAAAAEbBVgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4B AAAAAP8BEAAYAIgDAAAAABMAEwDw/wAAAAAjABYALgA1ACcAZgAoAIQALACTADEAlQAxAKkAOAC0 AEkAtQBLAMIATgDTAEUA3wA4AOoALgD4ACEA9gAQAPYAAADqAAAAAAAoACwAAgAAQACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAiAAAACgHAADvAAAAjQgAAA8ABPDoAAAAAgAK8AgAAABVuAUA AgoAAAMBC/C4AAAABAAAAAAAQgE9AAAAQwFgAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEA AAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/ PABSACEAYAAOAFIABQBFAAAAIQAEAAAAKQAPAD0AJwA8AFIAFAAYAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAuAIAALwKAAAHAwAARgsAAA8AA/AEBAAA DwAE8FQAAAABAAnwEAAAABsJAAAYCQAAQQkAALgJAAACAArwCAAAAFa4BQADAgAAIwAL8AwAAAAE AAAAAACIAwAAAAAAAA/wEAAAABsEAACyCQAASgQAAJoKAAAPAATw4gAAAAIACvAIAAAAV7gFAAIK AADzAAvwsgAAAEIBIAAAAEMBJAAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkACQDw/wAABQAPAAAA GQAFAB0ACgAgABcAHgAkAAsAHgAAABUAAAAFABQAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAFgAIAAAA/wEAAAABsJAACUCQAAOwkAALgJAAAPAATw4gAAAAIACvAIAAAA WLgFAAIKAADzAAvwsgAAAEIBFAAAAEMBJwAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQABAIABAAAA AIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkACQDw/xQA BgALAAAABAAGAAIACwAAABkAAQAnAA4AIQAUABcAFAAGABQAGAACAABAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACkJAAA9CQAAPQkAAGQJAAAPAATw4gAAAAIA CvAIAAAAWbgFAAIKAADzAAvwsgAAAEIBFgAAAEMBHQAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkA CQDw/xYAAwAMAAAABAAEAAIACAAAABMAAQAdABAAGQAWABIAFgADABQAGAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACIJAAB1CQAAOAkAAJIJAAAPAATw 4gAAAAIACvAIAAAAWrgFAAIKAADzAAvwsgAAAEIBFgAAAEMBIgAAAEQBBAAAAEXBJAAAAEbBLgAA AH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgD AAAAAAkACQDw/xYAAwAMAAAABAAFAAIACQAAABcAAQAiAA8AHQAWABQAFgADABQAGAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAACsJAAAYCQAAQQkAADoJ AAAPAAPwnhAAAA8ABPBUAAAAAQAJ8BAAAABtBwAAKwoAALQHAAAiCwAAAgAK8AgAAABbuAUAAwIA ACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAADmAQAARgsAAEICAACrDAAADwAE8OoAAAACAArw CAAAAFy4BQACCgAA8wAL8LoAAABCAREAAABDARYAAABEAQQAAABFwSgAAABGwTIAAAB/AQEAAQCA AQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAKAAoA 8P8AAAQABQAAAAsAAgAPAAIAEQAIABAADQAKABYAAgAVAAEADQAAAAQAFgAYAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHQHAACCCgAAhQcAAJgK AAAPAATw6gAAAAIACvAIAAAAXbgFAAIKAADzAAvwugAAAEIBEQAAAEMBFgAAAEQBBAAAAEXBKAAA AEbBMgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8B EAAYAIgDAAAAAAoACgDw/wAAAwAFAAAACwABABAAAgARAAgAEAANAAsAFgACABQAAQANAAAAAwAW ABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA oAcAAEEKAACxBwAAVwoAAA8ABPDqAAAAAgAK8AgAAABeuAUAAgoAAPMAC/C6AAAAQgERAAAAQwEX AAAARAEEAAAARcEoAAAARsEyAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAA ywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACgAKAPD/AAAEAAUAAAALAAIADwADABEACQAQAA4ACgAX AAIAFQABAA4AAAAEABYAGAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAAB3BwAAnQoAAIgHAAC0CgAADwAE8OoAAAACAArwCAAAAF+4BQACCgAA8wAL 8LoAAABCAREAAABDARYAAABEAQQAAABFwSgAAABGwTIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAKAAoA8P8AAAQABQAAAAsAAgAQ AAMAEQAIABAADgAKABYAAgAVAAEADgAAAAQAFgAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHwHAAAMCwAAjQcAACILAAAPAATw4gAAAAIACvAI AAAAYLgFAAIKAADzAAvwsgAAAEIBFwAAAEMBFwAAAEQBBAAAAEXBJAAAAEbBLgAAAH8BAQABAIAB AAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAkACQDw /wAAAwAKAAAAEwADABUABgAXAA8AFQAXAAcAFAAAAA4AAAADABQAGAACAABAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAG4HAAArCgAAhQcAAEIKAAAPAATwEgEA AAIACvAIAAAAYbgFAAIKAADzAAvw4gAAAEIBFgAAAEMBHwAAAEQBBAAAAEXBPAAAAEbBRgAAAH8B AQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAA AA8ADwDw/xYAGwAVABMAEgAKAA4ABQALAAAABgAAAAMABAADAAgAAwALAAAAEQAAABoABAAeAAoA HwASAB8AFgAbACAAJAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAG0HAADGCgAAgwcAAOUKAAAPAATwEgEAAAIA CvAIAAAAYrgFAAIKAADzAAvw4gAAAEIBEwAAAEMBHwAAAEQBBAAAAEXBPAAAAEbBRgAAAH8BAQAB AIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAA8A DwDw/xMAAwATAAwADwAVAAsAGgAKAB8ABgAfAAMAGwADABcAAgAUAAAADgAAAAUAAwABAAgAAAAQ AAAAEwADACAAJAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAIkHAADsCgAAnAcAAAsLAAAPAATw6gAAAAIACvAI AAAAY7gFAAIKAADzAAvwugAAAEIBEQAAAEMBFgAAAEQBBAAAAEXBKAAAAEbBMgAAAH8BAQABAIAB AAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAoACgDw /wAABAAFAAAACwABABAAAgARAAgAEAANAAoAFgACABUAAQANAAAABAAWABgAAgAAQACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAmAcAAIsKAACpBwAAoQoA AA8ABPDqAAAAAgAK8AgAAABkuAUAAgoAAPMAC/C6AAAAQgERAAAAQwEWAAAARAEEAAAARcEoAAAA RsEyAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQ ABgAiAMAAAAACgAKAPD/AAAEAAUAAAALAAEAEAACABEACAARAA0ACwAWAAMAFQABAA0AAAAEABYA GAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABw BwAA5goAAIEHAAD8CgAADwAE8OoAAAACAArwCAAAAGW4BQACCgAA8wAL8LoAAABCAREAAABDARYA AABEAQQAAABFwSgAAABGwTIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADL AZwxAADOAQAAAAD/ARAAGACIAwAAAAAKAAoA8P8AAAQABQAAAAsAAQAPAAIAEQAIABAADQAKABYA AgAVAAAADQAAAAQAFgAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAAJQHAADECgAApQcAANoKAAAPAATw6gAAAAIACvAIAAAAZrgFAAIKAADzAAvw ugAAAEIBEQAAAEMBHwAAAEQBBAAAAEXBKAAAAEbBMgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQ AMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAoACgDw/wAAGgAFAB8ACwAeAA8A HAARABQAEAAMAAoAAAACAAEAAAAMAAAAGgAWABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAhgcAAFwKAACXBwAAewoAAA8ABPDqAAAAAgAK8AgA AABnuAUAAgoAAPMAC/C6AAAAQgEQAAAAQwEQAAAARAEEAAAARcEoAAAARsEyAAAAfwEBAAEAgAEA AAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACgAKAPD/ AAAOAAQAEAAKAA8ADgAPABAACgAPAAYACQAAAAEAAQAAAAYAAAAOABYAGAACAABAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAACBBwAAygoAAJEHAADaCgAA DwAE8OoAAAACAArwCAAAAGi4BQACCgAA8wAL8LoAAABCARAAAABDARMAAABEAQQAAABFwSgAAABG wTIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAAKAAoA8P8AABEABAATAAoAEgAOABEAEAAMAA8ACAAJAAAAAQAAAAAACAAAABEAFgAY AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAI0H AACaCgAAnQcAAK0KAAAPAATw6gAAAAIACvAIAAAAabgFAAIKAADzAAvwugAAAEIBDwAAAEMBEwAA AEQBBAAAAEXBKAAAAEbBMgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAAAoACgDw/wAAEQAEABMACQATAA4AEgAPAA0ADwAIAAkAAAAB AAEAAAAIAAAAEQAWABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAAiwcAAC8KAACaBwAAQgoAAA8ABPDiAAAAAgAK8AgAAABquAUAAgoAAPMAC/Cy AAAAQgESAAAAQwEUAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAA wAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAASAAkAFAAPABIAEQAP ABIABwARAAAABgADAAAACAAAABIAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAogcAAFsKAAC0BwAAbwoAAA8ABPDiAAAAAgAK8AgAAABruAUAAgoA APMAC/CyAAAAQgESAAAAQwEUAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAASAAgAFAAP ABIAEQAPABIABwARAAAABgADAAAACAAAABIAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAlwcAANkKAACpBwAA7QoAAA8ABPDiAAAAAgAK8AgAAABs uAUAAgoAAPMAC/CyAAAAQgERAAAAQwEUAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAAS AAgAFAAPABIAEAAPABEABwARAAAABgADAAAACAAAABIAFAAYAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgcAAGAKAACDBwAAdAoAAA8AA/B2KQAADwAE 8E4AAAABAAnwEAAAAKYEAACUCQAA+QkAAGoMAAACAArwCAAAAG24BQADAgAAEwAL8AYAAACIAwAA AAAAAA/wEAAAAKYEAACUCQAA+QkAAGoMAAAPAATwwAAAAAIACvAIAAAAbrgFAAIKAAADAQvwkAAA AAQAAAAAAEIBBwAAAEMBDAAAAEQBBAAAAEXBEAAAAEbBGgAAAH8BAQABAIABAAAAAIEBBgAACL8B EAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAQABADw/wIAAAAHAAwAAAAJ AAIAAAAKAAwAAgAAQACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAKQcAAJQJAAAzBwAApgkAAA8A BPAIAQAAAgAK8AgAAABvuAUAAgoAAAMBC/DYAAAABAAAAAAAQgElAAAAQwEmAAAARAEEAAAARcE0 AAAARsE+AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA /wEQABgAiAMAAAAADQANAPD/GwAAACUABAAiAA8AIgAmABoAHAAUABoAEgAiAAwAIgAAAB8ADQAZ AA0ACAAZABIAGwAAABwAIAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABtBwAAyAkAAKAHAAD+CQAADwAE8EgBAAACAArwCAAA AHC4BQACCgAAAwEL8BgBAAAEAAAAAABCAWAAAABDAXcAAABEAQQAAABFwVQAAABGwV4AAAB/AQEA AQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAV ABUA8P8BAAYAAAATAA4AMgAbAFIAMwBjAD0AbgBGAHcAUgBxAGAAdwBZAGAATwBbAEgATgBIADwA UwA3AE4AKQBCABcAKgAEACIADwANAAAACAAGAAEABgAsADAAAgAAQACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAAD1BAAAXQoAAHMFAAAMCwAADwAD8G4fAAAPAATwVAAAAAEACfAQ AAAAhgkAAKAJAACUDQAA+woAAAIACvAIAAAAcbgFAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAA D/AQAAAApgQAAHYKAAD5CQAAagwAAA8ABPDiAAAAAgAK8AgAAAByuAUAAgoAAPMAC/CyAAAAQgEW AAAAQwEdAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAI xAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/FgADAAwAAAAEAAQAAgAIAAAAEwAB AB0ADwAZABYAEQAWAAMAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AWAAgAAAD/AQAAAA8gkAAHMKAAAICgAAkAoAAA8ABPDiAAAAAgAK8AgAAABzuAUAAgoAAPMAC/Cy AAAAQgEbAAAAQwEhAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAA wAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/AAAEAAwAAAAWAAUAGQAJ ABsAFgAZACEACAAdAAAAEwAAAAQAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAxgkAAEUKAADhCQAAZgoAAA8ABPDiAAAAAgAK8AgAAAB0uAUAAgoA APMAC/CyAAAAQgEaAAAAQwEoAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/GgAFAA4AAAAF AAYAAgAMAAAAGgACACgAEwAiABoAGAAaAAUAFAAYAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAqwkAABQKAADFCQAAPAoAAA8ABPDiAAAAAgAK8AgAAAB1 uAUAAgoAAPMAC/CyAAAAQgEaAAAAQwEoAAAARAEEAAAARcEkAAAARsEuAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACQAJAPD/GgAk AA4AKAAFACIAAgAdAAAADgABAAAAEgAGABoAEQAaACQAFAAYAAIAAEAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAlgkAAOcJAACwCQAADwoAAA8ABPAiAgAAAgAK 8AgAAAB2uAUAAgoAAPMAC/DyAQAAQgHxAAAAQwEJAQAARAEEAAAARcHEAAAARsHOAAAAfwEBAAEA gAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAMQAx APD/BAAAABcACwAlAAkAMgALAEEAIwBCADAAUQA5AF8AOABlAEMAbQBEAHQATgB+AE8AhgBbAJQA YQCYAGwAqgBsALcAdAC/AIMAtQCFALAAiwDGAJMAywCeANQAqADVALAA3QCxAPEAwADrAMgA7ADR APAA2ADxAP0A5QD7ANoA+wDaAAkBxwD6AKgA6QCWANEAewC7AHQAnQBlAJEAVwB+AFkAawA5AFIA OABGADIAPQAhAD4AHQA1AAEAFwAAAA0ABAAAAGQAaAACAABAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAACGCQAAoAkAAHcKAACpCgAADwAE8AIBAAACAArwCAAAAHe4BQACCgAA8wAL 8NIAAABCATMAAABDAaMAAABEAQQAAABFwTQAAABGwT4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAA EADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAANAA0A8P8zAAkAHQAAAB0ACAAO AAEADgBMAAAAVQAOAF0ADgCPABIAmgAdAKAAHQCjADMAowAzAAkAHAAgAAIAAEAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGENAAA7 CgAAlA0AAN4KAAAPAATwggIAAAIACvAIAAAAeLgFAAIKAADzAAvwUgIAAEIB0gAAAEMBxAAAAEQB BAAAAEXB9AAAAEbB/gAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEA AM4BAAAAAP8BEAAYAIgDAAAAAD0APQDw/9IANgDSAIMAxACKANIAkgDSAMQAxQC0ALkAtACtAKYA rQCeAKkAkQCbAIwAjAB8AIQAawB1AGcAawBnAFoAYgBTAGIATABaAD0AVgA9AE8ANgBWADYAXAAr AGIAJQBbACQAVgAeAE0AHgBHABcARwARAEEAFAA8AC0AQgA3ADcALgAjABQAJAAMAB4AAAAeAAAA FgAGAAYADAAAABcAAAAlAAYAMQAGAEEAAAA9AA8APAAaAD8AJQBEACwAUwA8AFwAPABsADEAcgAl AHwAHwCKABEAjgAXAJQAGACfAB8ApwAeAKwAJAC7ACQAxQAeANIANgB8AIAAAgAAQACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAWAAgAAAD/AQAAAAnQwAAAYKAABvDQAAygoAAA8ABPDyAAAAAgAK8AgAAAB5uAUAAgoA APMAC/DCAAAAQgElAAAAQwEZAAAARAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQEGAAAI vwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAACwALAPD/AQAEABAAAAAc AAAAIwAIACUADwAjABQAHAAZABAAGQAEABUAAAALAAEABAAYABwAAgAAQACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAKIMAACECgAAxwwAAJ0KAAAP AATw8gAAAAIACvAIAAAAergFAAIKAADzAAvwwgAAAEIBIQAAAEMBFAAAAEQBBAAAAEXBLAAAAEbB NgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAY AIgDAAAAAAsACwDw/wAAEAAPABQAGQATACAADQAhAAgAHwADABkAAAAPAAAAAwADAAAACwAAABAA GAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAADKDAAAagoAAOsMAAB+CgAADwAE8PIAAAACAArwCAAAAHu4BQACCgAA8wAL8MIAAABCASUA AABDARoAAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjE AQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAALAAsA8P8kAAUAFQAAAAkAAQABAAgAAAAQAAIA FQAJABoAFQAaACAAFgAlAAwAJAAFABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAlAwAAGAKAAC5DAAAegoAAA8ABPBKAQAAAgAK8AgA AAB8uAUAAgoAAPMAC/AaAQAAQgE/AAAAQwEiAAAARAEEAAAARcFYAAAARsFiAAAAfwEBAAEAgAEA AAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAFgAWAPD/ MgABACwABQAdAAYAEAAIAAkACgAEAA0AAAATAAIAFgAMABsAFgAeAB8AIgAnACEALgAdADQAGwA4 ABYAPAAQADsADQA/AAoAPwAGAD0AAgA7AAAAMgABAC4AMAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBYACAAAAP8BAAAADjCwAAOgoAACIMAABcCgAADwAE8EoBAAACAArwCAAAAH24 BQACCgAA8wAL8BoBAABCAUEAAABDASIAAABEAQQAAABFwVgAAABGwWIAAAB/AQEAAQCAAQAAAACB AQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAWABYA8P80AAEA LQAFAB4ABgASAAgACQALAAQADgAAABMAAwAXAAwAGwAYAB8AIAAiACkAIAAwAB0ANQAbADoAFgA+ ABAAPAAOAEEACwBBAAYAPwADADwAAAA0AAEALgAwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAALkLAACxCgAA+gsAANMKAAAPAATw8gAAAAIACvAIAAAAfrgFAAIK AADzAAvwwgAAAEIBNwAAAEMBGgAAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAA CL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/wEABQAYAAAA KQABADUACAA3ABAAMwAVACkAGgAYABoABgAWAAAADAABAAUAGAAcAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAAMDAAAGAoAAEMMAAAyCgAA DwAE8PIAAAACAArwCAAAAH+4BQACCgAA8wAL8MIAAABCATgAAABDARoAAABEAQQAAABFwSwAAABG wTYAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAALAAsA8P8BAAUAGAAAACoAAQA2AAkAOAAQADQAFQAqABoAGAAaAAYAFgAAAAwAAQAF ABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAA D/AQAAAApQsAANMKAADdCwAA7QoAAA8ABPBKAQAAAgAK8AgAAACAuAUAAgoAAPMAC/AaAQAAQgFA AAAAQwEhAAAARAEEAAAARcFYAAAARsFiAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAI xAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAAFgAWAPD/MgAhACwAHQAdABsAEAAaAAkAFwAE ABQAAAAPAAIACwAMAAcAFgADAB8AAAAnAAIALwAEADQABwA4AAwAPQASADsAFABAABcAQAAbAD0A HwA7ACEAMgAhAC4AMAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAA AAAuDAAAuAoAAG4MAADZCgAADwAE8EoBAAACAArwCAAAAIG4BQACCgAA8wAL8BoBAABCAToAAABD ASUAAABEAQQAAABFwVgAAABGwWIAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAA AADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAWABYA8P8MACQAEgAgAB8AHgArAB0AMgAaADcAFgA6 ABAAOQAMADAABwAmAAMAHQAAABYAAQAPAAQACgAHAAYADQACABQAAwAWAAAAGgAAAB4AAQAiAAMA JQAMACQALgAwAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAEML AACrCgAAfQsAANAKAAAPAATw8gAAAAIACvAIAAAAgrgFAAIKAADzAAvwwgAAAEIBLgAAAEMBGQAA AEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsB nDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/y0ABAAaAAAACwAAAAEABwAAAA8AAwAUAAsAGQAa ABkAKAAVAC4ACwAtAAQAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBYACAAAAP8BAAAAB+DAAA4wkAAKwMAAD8CQAADwAE8OIAAAACAArwCAAAAIO4BQAC CgAA8wAL8LIAAABCATMAAABDARoAAABEAQQAAABFwSQAAABGwS4AAAB/AQEAAQCAAQAAAACBAQYA AAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAJAAkA8P8AAAMAGAAA ACkABAAvAAgAMwARADEAGgAPABcAAAAQAAAAAwAUABgAAgAAQACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABpCwAA4QoAAJwLAAD7CgAADwAE8PIAAAACAArwCAAA AIS4BQACCgAA8wAL8MIAAABCATUAAABDARoAAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAA AACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAALAAsA8P8B AAUAGAAAACgAAQA0AAgANQAQADIAFQAoABoAGAAaAAYAFgAAAAwAAQAFABgAHAACAABAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA7gsAAM4KAAAj DAAA6AoAAA8ABPDyAAAAAgAK8AgAAACFuAUAAgoAAPMAC/DCAAAAQgEjAAAAQwEVAAAARAEEAAAA RcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAACwALAPD/AAADABAAAAAaAAAAIgAHACMADAAhABEAGgAVABAAFQAEABIA AAAJAAAAAwAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAFgAIAAAA/wEAAAACgMAADVCgAASwwAAOoKAAAPAATw8gAAAAIACvAIAAAAhrgFAAIKAADzAAvw wgAAAEIBMQAAAEMBFQAAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQ AMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAAsACwDw/wAAAwAWAAAAJQAAADEA BwAxAA0AMAARACUAFQAWABUABQASAAAACgAAAAMAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAACDAAArwoAADMMAADECgAADwAE8OIA AAACAArwCAAAAIe4BQACCgAA8wAL8LIAAABCATsAAABDAR4AAABEAQQAAABFwSQAAABGwS4AAAB/ AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAA AAAJAAkA8P87AAMAHwAAAAsABAADAAgAAAATAAIAHgApABoAOwASADsAAwAUABgAAgAAQACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABwCwAAwAoAAKsLAADeCgAA DwAE8NoBAAACAArwCAAAAIi4BQACCgAA8wAL8KoBAABCAfkAAABDAVgAAABEAQQAAABFwaAAAABG waoAAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAA GACIAwAAAAAoACgA8P8TAAAANAAAAEIACwBIABEAZwARAGoACgB5AAYAjwAFAJYADACcAA0AoAAQ AKYAEQClABYArAAcANYAHwDQACYA0QAtAN0APQD5AEIA9ABXANwAWADMAFIAuQA/AK4AOwCWADsA dwBAAHAAOwBlADQAVwA1ADsALwAyACgAJQAoAB4AIwASACMAAAAXAAEADAAFAAsABgAFAA4ABQAT AAAAUgBUAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAGwKAACjCgAAZQsAAPsKAAAPAATwwgIAAAIACvAIAAAAibgFAAIKAADzAAvwkgIA AEIBlwAAAEMBtAAAAEQBBAAAAEXBFAEAAEbBHgEAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMAB BwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAYAIgDAAAAAEUARQDw/5cAAACSABwAgQApAFsALwBU ACgASwAoAEUAJAA3ACwALgAyACkAOQArADsAMQA6ADcATgA8AE4APABIAEIARABCADsAYgA8AGQA NQBnADQAbQBBAGcASABhAEgAXQBSAFUAXABVAFwAZwCFAGcAiwBcAIsAXACSAFQAlgBIAJYASgCF AEIAgwBCAHgAPgBzAD0AbAAqAGoAKgB7ADIAfwAqAIcAMQCLAC8AkQA3AJQANwCsAC4AtAAgALMA HgCFABMAggAAAG8AAABgAA0AUgAVAFEAHABJAB8AQAAfACkAJQAeACwAFwAzABcANwAUADgADAA9 AAsAQgARAEoAEgBKABcAdAAXAIEAEgCHABIAlwAAAIwAkAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAH0LAADdCQAAFAwAAJEKAAAP AATwEgEAAAIACvAIAAAAirgFAAIKAADzAAvw4gAAAEIBRAAAAEMBJgAAAEQBBAAAAEXBPAAAAEbB RgAAAH8BAQABAIABAAAAAIEBBgAACL8BEAAQAMABBwAACMQBAAAAAMsBnDEAAM4BAAAAAP8BEAAY AIgDAAAAAA8ADwDw/zsAAAApAAEAFQAHAAkADgABABIAAAAaAAgAHwASAB8AGQAgACUAJgA5ACYA QAAeAEIAEwBEAAYAOwAAACAAJAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAADIMAAA0CgAAdgwAAFoKAAAPAAPw igUAAA8ABPBUAAAAAQAJ8BAAAACsCgAAdwkAAJULAABvCgAAAgAK8AgAAACLuAUAAwIAACMAC/AM AAAABAAAAAAAiAMAAAAAAAAP8BAAAADxBQAAzwoAACEHAAA0DAAADwAE8PoBAAACAArwCAAAAIy4 BQACCgAA8wAL8MoBAABCAd4AAABDAZYAAABEAQQAAABFwbAAAABGwboAAAB/AQEAAQCAAQAAAACB AQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ARAAGACIAwAAAAAsACwA8P8AAIAA FACVABwAlgAhAI4ANACJAD4AhABEAH4AZQB+AHMAeABzAG0AhABaAIYAVACRAEkAkgA8ALYAPADG ADcAyAAsANcAKADeACcA2QAhAMwAIQC9ABoAuQAhALAAGwC9AAsAsAAAAJ4ACgCXABgAigAnAH8A MgBuADUAZwA7AFkASwBWAFQASQBZADkAWQAxAGIAMQByACYAeAAmAH4ADgB+AA4AeAAAAHIAAACA AFoAXAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAWAAgAAAD/AQAAAAtwoAAHcJAACVCwAADQoAAA8ABPBKAgAAAgAK8AgAAACN uAUAAgoAAPMAC/AaAgAAQgHkAAAAQwG+AAAARAEEAAAARcHYAAAARsHiAAAAfwEBAAEAgAEAAAAA gQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEAAAAA/wEQABgAiAMAAAAANgA2APD/DABG ACAAWwAmAFsALABSAD4ATgBJAEoATwBCAHAAQwB8AD4AfAAxAI4AHwCRABcAmwAOAJsAAADAAAAA wQAIAMUADgDGABQAwAAaAMYAIgDGADIA1QBAANwAQwDkAEoA3wBKANAAUQDCAGEAxgB0ALoAcwCu AIAArQCWAJoAtwCGAL4AhQC4AH4ArwBxAK4AaACrAGAArgBYALcAQQC2ADUAqwAlAKoAIACiACAA mQAZAJcAHwCLABkAfwASAIgACQB6AAMAcwAAAGoAAQBJAAcAQQAMAEYAbgBwAAIAAEAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAA rAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAArAoAALEJAACQ CwAAbwoAAA8ABPDSAAAAAgAK8AgAAACOuAUAAgoAAPMAC/CiAAAAQgEmAAAAQwEhAAAARAEEAAAA RcEcAAAARsEmAAAAfwEBAAEAgAEAAAAAgQEGAAAIvwEQABAAwAEHAAAIxAEAAAAAywGcMQAAzgEA AAAA/wEQABgAiAMAAAAABwAHAPD/JgAHABgAAAAIAAYAAAAQAAMAGwAPACEAJgAHABAAFAACAABA AKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAAACwAApAkAACYLAADFCQAADwAE 8OgAAAACAArwCAAAAI+4BQACCgAAAwEL8LgAAAAEAAAAAABCAQ4AAABDARMAAABEAQQAAABFwSQA AABGwS4AAAB/AQEAAQCAAQAAAACBAQYAAAi/ARAAEADAAQcAAAjEAQAAAADLAZwxAADOAQAAAAD/ ARAAGACIAwAAAAAJAAkA8P8AAAIABwAAAAsAAgAOAAUADgAMAA4AEwAFABAAAAALAAAAAgAUABgA AgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAB2BQAApAsA AIoFAADACwAADwAE8F4AAABCAQrwCAAAAJC4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQA AAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIErBWsFbIGDwAE 8F4AAABCAQrwCAAAAJG4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAA EADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIEMA4wDrIGDwAE8F4AAABCAQrwCAAA AJK4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSU AAD/ARgAGAABAgIAAAgAABDwCAAAACMF/Av8C7IGDwAE8F4AAABCAQrwCAAAAJO4BQAACgAAkwAL 8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIA AAgAABDwCAAAAAMFfAV8BbIGDwAE8F4AAABCAQrwCAAAAJS4BQAACgAAkwAL8DYAAACFAAIAAACH AAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAOMG MgIyAjAMDwAE8F4AAABCAQrwCAAAAJW4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIG7BTsFDEJDwAE8FgA AAAyAArwCAAAAJa4BQAACgAAgwAL8DAAAACFAAIAAACHAAEAAAC/AAAADQCBAf8AAAC/ARAAEAD/ AQYABgA/AgAAAQB/AwAADwAAABDwCAAAAJMEqgtaDEQFDwAE8FgAAAAyAArwCAAAAJe4BQAACgAA gwAL8DAAAACFAAIAAACHAAEAAAC/AAAADQCBAQCZAAC/ARAAEAD/AQYABgA/AgAAAQB/AwAADwAA ABDwCAAAAIAE0A2ADjIFDwAE8FgAAAAyAArwCAAAAJi4BQAACgAAgwAL8DAAAACFAAIAAACHAAEA AAC/AAAADQCBAQCZAAC/ARAAEAD/AQYABgA/AgAAAQB/AwAADwAAABDwCAAAAIAEchUgFjIFDwAE 8F4AAABCAQrwCAAAAJm4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAA EADAAQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAPIG1A7UDvMLDwAE8F4AAABCAQrwCAAA AJq4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAdSU AAD/ARgAGAABAgIAAAgAABDwCAAAAPIGdgx2DPMLDwAE8F4AAAAiAArwCAAAAJu4BQAACgAAkwAL 8DYAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAAD/AQgACAABAgIA AAgAABDwCAAAALMD+AoADa4FDwAE8GQAAAAiAArwCAAAAJy4BQAACgAAowAL8DwAAACFAAIAAACH AAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAADOAQIAAAD/AQgACAABAgIAAAgAABDw CAAAAHEIgBM7FjEKDwAE8FgAAAAyAArwCAAAAJ24BQAACgAAgwAL8DAAAACFAAIAAACHAAEAAAC/ AAAADQCBAQCZAAC/ARAAEAD/AQYABgA/AgAAAQB/AwAADwAAABDwCAAAAIAEFAXEBTIFDwAE8KAA AACiDArwCAAAAJ64BQAACgAAgwAL8DAAAACAABByBASFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAi/ AQAAEADAAQEAAAj/AQAACAAAABDwCAAAAKkDqAOcBpAEDwAN8EAAAAAAAJ8PBAAAAAQAAAAAAKgP CAAAAE5TUElYUC02AAChDxwAAAAJAAAAAAAAAAoABwAJAAAAAQAGAIEAEgD/AAD+DwAE8JwAAACi DArwCAAAAJ+4BQAACgAAgwAL8DAAAACAAKh2BASFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAi/AQAA EADAAQEAAAj/AQAACAAAABDwCAAAAKkDWw0vD5AEDwAN8DwAAAAAAJ8PBAAAAAQAAAAAAKgPBAAA AFBBSVgAAKEPHAAAAAUAAAAAAAAACgAHAAUAAAABAAYAgQASAP8AAP4PAATwnAAAAKIMCvAIAAAA oLgFAAAKAACDAAvwMAAAAIAAgHoEBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACL8BAAAQAMABAQAA CP8BAAAIAAAAEPAIAAAAswMsC8AMmgQPAA3wPAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAUy1JWAAA oQ8cAAAABQAAAAAAAAAKAAcABQAAAAEABgCBABIA/wAA/g8ABPCeAAAAogwK8AgAAAChuAUAAAoA AIMAC/AwAAAAgAAgfgQEhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIvwEAABAAwAEBAAAI/wEAAAgA AAAQ8AgAAACpA3sU/xaQBA8ADfA+AAAAAACfDwQAAAAEAAAAAACoDwYAAABBTVMtSVgAAKEPHAAA AAcAAAAAAAAACgAHAAcAAAABAAYAgQASAP8AAP4PAATwngAAAKIMCvAIAAAAorgFAAAKAACTAAvw NgAAAIAAkIIEBIUAAgAAAIcABgAAAL8AAgACAIEB/8zMAL8BAAAQAMABAQAACP8BAAAIAAECAgAA CAAAEPAIAAAARALDAqIEZAMPAA3wOAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAQXNpYQAAoQ8YAAAA BQAAAAAAAAgKAAEABwAFAAAAEQAAAJEADwAE8HgAAACyBArwCAAAAKO4BQAQCgAAowAL8DwAAAAE QQcAAAALAegEAAA/AQAAAQCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAA AgAAABDwCAAAAGMKyw98EtIKDwAR8AwAAAAAAMELBAAAAOgEAAAPAAPwSAQAAA8ABPBMAAAAAQAJ 8BAAAAD7AwAAdQsAAFsLAAAMEAAAAgAK8AgAAACkuAUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAA AAAQ8AgAAAA9CQMU1RTVCQ8AA/AIAwAADwAE8E4AAAABAAnwEAAAAPsDAAC4DgAAWwsAAAwQAAAC AArwCAAAAKW4BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATw /gAAAAIACvAIAAAAprgFAAIKAAATAQvwzgAAAEIBYAcAAEMBVAEAAEQBBAAAAEXBLAAAAEbBNgAA AH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4B AAAAAP8BGAAYAIgDAAAAAAsACwDw/+oAAAB8BgAAXgc1AWAHQwFYB1ABSQdUARsAVAEIAE4BAAA/ AQQALgHqAAAAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEA AKwBYACAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8M4AAAACAArwCAAAAKe4BQACCgAAEwEL 8J4AAABCAegEAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf// /wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P+p AAAArQQAAOgE2gAAANoAqQAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA YwQAAAIPAABLCQAA3A8AAA8ABPDOAAAAAgAK8AgAAACouAUAAgoAABMBC/CeAAAAQgF8AQAAQwHa AAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAA wgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/AAAAAOEAAAB8AdoARwDa AAAAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHIJAAACDwAA7goAANwP AAAPAATwQgAAABIACvAIAAAAqbgFAAIKAAAzAAvwEgAAAL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQ AAAApQUAAHULAACvCQAArw4AAA8ABPBIAAAAEgAK8AgAAACquAUAAgoAAEMAC/AYAAAAgQEQUP8A vwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAAAzBgAA5gsAACEJAAAhDgAADwAE8EIAAAASAArwCAAA AKu4BQACCgAAMwAL8BIAAACBAQAAAAC/ARAAEAD/AQAACAAAAA/wEAAAAMMIAABSDgAAIAkAAIAO AAAPAAPwSAQAAA8ABPBMAAAAAQAJ8BAAAAD7AwAAdQsAAFsLAAAMEAAAAgAK8AgAAACsuAUAAQIA ACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAAA9CQIV1BXVCQ8AA/AIAwAADwAE8E4AAAABAAnw EAAAAPsDAAC4DgAAWwsAAAwQAAACAArwCAAAAK24BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAA APsDAAC4DgAAWwsAAAwQAAAPAATw/gAAAAIACvAIAAAArrgFAAIKAAATAQvwzgAAAEIBYAcAAEMB VAEAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAA AMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAsACwDw/+oAAAB8BgAAXgc1AWAH QwFYB1ABSQdUARsAVAEIAE4BAAA/AQQALgHqAAAAGAAcAAIAAEAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8M4A AAACAArwCAAAAK+4BQACCgAAEwEL8J4AAABCAegEAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/ AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAA AAD/ARgAGACIAwAAAAAFAAUA8P+pAAAArQQAAOgE2gAAANoAqQAAAAwAEAACAABAAKwBAACsAQAA rAEAAKwBAACsAWAAgAAAD/AQAAAAYwQAAAIPAABLCQAA3A8AAA8ABPDOAAAAAgAK8AgAAACwuAUA AgoAABMBC/CeAAAAQgF8AQAAQwHaAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH/ //8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAA BQAFAPD/AAAAAOEAAAB8AdoARwDaAAAAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAA AA/wEAAAAHIJAAACDwAA7goAANwPAAAPAATwQgAAABIACvAIAAAAsbgFAAIKAAAzAAvwEgAAAL8B EAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAApQUAAHULAACvCQAArw4AAA8ABPBIAAAAEgAK8AgAAACy uAUAAgoAAEMAC/AYAAAAgQEQUP8AvwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAAAzBgAA5gsAACEJ AAAhDgAADwAE8EIAAAASAArwCAAAALO4BQACCgAAMwAL8BIAAACBAQAAAAC/ARAAEAD/AQAACAAA AA/wEAAAAMMIAABSDgAAIAkAAIAOAAAPAATwSAAAALIECvAIAAAAtLgFAAAKAABDAAvwIAAAAH8A gACAAARBCQAAAAXBCAAAAAYBAQAAAG4AdAB0AAAAAAAQ8AgAAABfCogTYBYBCw8ABPBIAAAAsgQK 8AgAAAC1uAUAAAoAAEMAC/AgAAAAfwCAAIAABEEJAAAABcEIAAAABgEBAAAAbgB0AHQAAAAAABDw CAAAAKAFWAkwDEIGDwAE8NIAAACiDArwCAAAALa4BQAACgAAAwEL8GAAAACAAOyKBASBAJBfAQCC ANC2AACDAJBfAQCEANC2AACFAAIAAACHAAEAAAC/AAIADwCBAQAAAAiDAQAAAAi/AQwAHgDAAQEA AAj/AQYADgABAgIAAAg/AgAAAwB/AwAADwAAABDwCAAAAAMLsRNvFsMLDwAN8EIAAAAAAJ8PBAAA AAQAAAAAAKgPCgAAAE5UVCBFdXJvcGUAAKEPHAAAAAsAAAAAAAAoCgABABQABwALAAAAgwQCAAME DgAPAATwzwAAAKIMCvAIAAAAt7gFAAAKAAADAQvwYAAAAIAAHI8EBIEAkF8BAIIA0LYAAIMAkF8B AIQA0LYAAIUAAgAAAIcAAQAAAL8AAgAPAIEBAAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAEC AgAACD8CAAADAH8DAAAPAAAAEPAIAAAA4ARgCboLoAUPAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8H AAAATlRUIE1DTAAAoQ8cAAAACAAAAAAAACgKAAEAFAAHAAgAAACDBAIAAwQOAA8ABPCeAAAAogwK 8AgAAAC4uAUAAAoAAJMAC/A2AAAAgAD0kgQEhQACAAAAhwAGAAAAvwACAAIAgQH/zMwAvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABEArQTiBZkAw8ADfA4AAAAAACfDwQAAAAEAAAAAACo DwYAAABFdXJvcGUAAKEPFgAAAAcAAAAAAAAACgAHAAcAAAARAAAAkQAPAATwSAAAALIECvAIAAAA ubgFAAAKAABDAAvwIAAAAH8AgACAAARBCgAAAAXBCAAAAAYBAQAAAG4AdAB0AAAAAAAQ8AgAAABA D9UKWg9DEA8ABPBeAAAAQgEK8AgAAAC6uAUAAAoAAJMAC/A2AAAAhQACAAAAhwABAAAARAEEAAAA fwEAAAEAvwEAABAAwAEBAAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgAAADjBjoEOgTGCA8ABPBe AAAAQgEK8AgAAAC7uAUAAAoAAJMAC/A2AAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEAvwEAABAA wAEBAAAIywHUlAAA/wEYABgAAQICAAAIAAAQ8AgAAADyBhAREBExCQ8ABPBkAAAAIgAK8AgAAAC8 uAUAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAH/AAAAywHUlAAA zgECAAAA/wEIAAgAAQICAAAIAAAQ8AgAAABxCK8PahIxCg8AA/BIBAAADwAE8EwAAAABAAnwEAAA APsDAAB1CwAAWwsAAAwQAAACAArwCAAAAL24BQABAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAABDw CAAAAD0JLRD/ENUJDwAD8AgDAAAPAATwTgAAAAEACfAQAAAA+wMAALgOAABbCwAADBAAAAIACvAI AAAAvrgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPD+AAAA AgAK8AgAAAC/uAUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAARAEEAAAARcEsAAAARsE2AAAAfwEB AAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA /wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgHUAFJB1QBGwBUAQgATgEAAD8BBAAu AeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFg AIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIACvAIAAAAwLgFAAIKAAATAQvwngAA AEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8B EAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/6kAAACt BAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABjBAAA Ag8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAMG4BQACCgAAEwEL8J4AAABCAXwBAABDAdoAAABE AQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf// /wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P8AAAAA4QAAAHwB2gBHANoAAAAA AAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgkAAAIPAADuCgAA3A8AAA8A BPBCAAAAEgAK8AgAAADCuAUAAgoAADMAC/ASAAAAvwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAACl BQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAAMO4BQACCgAAQwAL8BgAAACBARBQ/wC/ARAA EADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEOAAAPAATwQgAAABIACvAIAAAAxLgF AAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQAAAAwwgAAFIOAAAgCQAAgA4AAA8A A/BIBAAADwAE8EwAAAABAAnwEAAAAPsDAAB1CwAAWwsAAAwQAAACAArwCAAAAMW4BQABAgAAIwAL 8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAD0JKxH9EdUJDwAD8AgDAAAPAATwTgAAAAEACfAQAAAA +wMAALgOAABbCwAADBAAAAIACvAIAAAAxrgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMA ALgOAABbCwAADBAAAA8ABPD+AAAAAgAK8AgAAADHuAUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAA RAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH/ //8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgH UAFJB1QBGwBUAQgATgEAAD8BBAAuAeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIA CvAIAAAAyLgFAAIKAAATAQvwngAAAEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQAB AIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8B GAAYAIgDAAAAAAUABQDw/6kAAACtBAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBYACAAAAP8BAAAABjBAAAAg8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAMm4BQACCgAA EwEL8J4AAABCAXwBAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCD Af///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA 8P8AAAAA4QAAAHwB2gBHANoAAAAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQ AAAAcgkAAAIPAADuCgAA3A8AAA8ABPBCAAAAEgAK8AgAAADKuAUAAgoAADMAC/ASAAAAvwEQABAA ywGcMQAA/wEIAAgAAAAP8BAAAAClBQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAAMu4BQAC CgAAQwAL8BgAAACBARBQ/wC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEO AAAPAATwQgAAABIACvAIAAAAzLgFAAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQ AAAAwwgAAFIOAAAgCQAAgA4AAA8ABPBeAAAAIgAK8AgAAADNuAUAAAoAAJMAC/A2AAAAhQACAAAA hwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAH/AAAAywHUlAAA/wEIAAgAAQICAAAIAAAQ8AgAAACt DIURtxJqDQ8ABPBkAAAAIgAK8AgAAADOuAUAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAAgQEEAAAI gwEAAAAIvwEAABAAwAH/AAAAywHUlAAAzgECAAAA/wEIAAgAAQICAAAIAAAQ8AgAAAARDoMRtBLV Dg8ABPDbAAAAogwK8AgAAADPuAUAAAoAAAMBC/BgAAAAgADMnAQEgQCQXwEAggDQtgAAgwCQXwEA hADQtgAAhQACAAAAhwABAAAAvwACAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMAfwMAAA8AAAAQ8AgAAACoDBsTxhd8DQ8ADfBLAAAAAACfDwQAAAAEAAAAAACoDxMA AABDb21tZXJjaWFsIHNlcnZpY2VzAAChDxwAAAAUAAAAAAAAKAoAAQAUAAcAFAAAAIAEAgAABBAA DwAE8N8AAACiDArwCAAAANC4BQAACgAAAwEL8GAAAACAAFShBASBAJBfAQCCANC2AACDAJBfAQCE ANC2AACFAAIAAACHAAEAAAC/AAIADwCBAQAAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIA AAg/AgAAAwB/AwAADwAAABDwCAAAABAOQBMrGOQODwAN8E8AAAAAAJ8PBAAAAAQAAAAAAKgPFwAA AFRyaWFsIC8gUGxhbmVkIHNlcnZpY2VzAAChDxwAAAAYAAAAAAAAKAoAAQAUAAcAGAAAAIAEAgAA BBAADwAD8IkKAAAPAATwTAAAAAEACfAQAAAALQIAABYIAADdBAAAVAsAAAIACvAIAAAA0bgFAAEC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAAYwiPAnkFoQsPAATwTgAAALIECvAIAAAA0rgF AAIKAABDAAvwHgAAAH8AgACAAARBCwAAAAXBBgAAAAYBAQAAAGgAawAAAAAAD/AQAAAAZAIAANAJ AABwBAAAnQoAAA8ABPByAAAAIgAK8AgAAADTuAUAAgoAALMAC/BCAAAAhQACAAAAhwABAAAAgQEE AAAIgwEAAAAIvwEAABAAwAH/AAAAywHUlAAAzgECAAAA1wEAAAAA/wEIAAgAAQICAAAIAAAP8BAA AABAAgAAFggAAMQEAADGCQAADwAD8FAEAAAPAATwVAAAAAEACfAQAAAA+wMAAHULAABbCwAADBAA AAIACvAIAAAA1LgFAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAArQIAANIIAABvAwAA agkAAA8AA/AIAwAADwAE8E4AAAABAAnwEAAAAPsDAAC4DgAAWwsAAAwQAAACAArwCAAAANW4BQAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATw/gAAAAIACvAIAAAA 1rgFAAIKAAATAQvwzgAAAEIBYAcAAEMBVAEAAEQBBAAAAEXBLAAAAEbBNgAAAH8BAQABAIABAAAA AIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgD AAAAAAsACwDw/+oAAAB8BgAAXgc1AWAHQwFYB1ABSQdUARsAVAEIAE4BAAA/AQQALgHqAAAAGAAc AAIAAEAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAA AAD7AwAAuA4AAFsLAAAMEAAADwAE8M4AAAACAArwCAAAANe4BQACCgAAEwEL8J4AAABCAegEAABD AdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAA AADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P+pAAAArQQAAOgE2gAA ANoAqQAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAYwQAAAIPAABLCQAA 3A8AAA8ABPDOAAAAAgAK8AgAAADYuAUAAgoAABMBC/CeAAAAQgF8AQAAQwHaAAAARAEEAAAARcEU AAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAA ywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/AAAAAOEAAAB8AdoARwDaAAAAAAAMABAAAgAA QACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAHIJAAACDwAA7goAANwPAAAPAATwQgAAABIA CvAIAAAA2bgFAAIKAAAzAAvwEgAAAL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAApQUAAHULAACv CQAArw4AAA8ABPBIAAAAEgAK8AgAAADauAUAAgoAAEMAC/AYAAAAgQEQUP8AvwEQABAAywGcMQAA /wEIAAgAAAAP8BAAAAAzBgAA5gsAACEJAAAhDgAADwAE8EIAAAASAArwCAAAANu4BQACCgAAMwAL 8BIAAACBAQAAAAC/ARAAEAD/AQAACAAAAA/wEAAAAMMIAABSDgAAIAkAAIAOAAAPAAPwUAQAAA8A BPBUAAAAAQAJ8BAAAAD7AwAAdQsAAFsLAAAMEAAAAgAK8AgAAADcuAUAAwIAACMAC/AMAAAABAAA AAAAiAMAAAAAAAAP8BAAAACYAwAA0ggAAFoEAABqCQAADwAD8AgDAAAPAATwTgAAAAEACfAQAAAA +wMAALgOAABbCwAADBAAAAIACvAIAAAA3bgFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMA ALgOAABbCwAADBAAAA8ABPD+AAAAAgAK8AgAAADeuAUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAA RAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH/ //8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgH UAFJB1QBGwBUAQgATgEAAD8BBAAuAeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIA CvAIAAAA37gFAAIKAAATAQvwngAAAEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQAB AIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8B GAAYAIgDAAAAAAUABQDw/6kAAACtBAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAA rAEAAKwBYACAAAAP8BAAAABjBAAAAg8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAOC4BQACCgAA EwEL8J4AAABCAXwBAABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCD Af///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA 8P8AAAAA4QAAAHwB2gBHANoAAAAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQ AAAAcgkAAAIPAADuCgAA3A8AAA8ABPBCAAAAEgAK8AgAAADhuAUAAgoAADMAC/ASAAAAvwEQABAA ywGcMQAA/wEIAAgAAAAP8BAAAAClBQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAAOK4BQAC CgAAQwAL8BgAAACBARBQ/wC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEO AAAPAATwQgAAABIACvAIAAAA47gFAAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQ AAAAwwgAAFIOAAAgCQAAgA4AAA8ABPCtAAAAogwK8AgAAADkuAUAAgoAAJMAC/A2AAAAgADMqgQE hQACAAAAhwAGAAAAvwACAAIAgQH/zMwAvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAAAt AgAAgAoAAN0EAABUCwAADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgPCQAAAEhvbmcgS29uZwAAoQ8a AAAACgAAAAAAAAgKAAEABwAKAAAAEQACAJEAEAAPAATwXgAAAEIBCvAIAAAA5bgFAAAKAACTAAvw NgAAAIUAAgAAAIcAAQAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAAP8BGAAYAAECAgAA CAAAEPAIAAAAAwWICIgIsgYPAATwnQAAAKIMCvAIAAAA5rgFAAAKAACDAAvwMAAAAIAARK8EBIUA AgAAAIcABgAAAL8AAgACAIEBBAAACL8BAAAQAMABAQAACP8BAAAIAAAAEPAIAAAAqQNQB4wJkAQP AA3wPQAAAAAAnw8EAAAABAAAAAAAqA8FAAAASlBOQVAAAKEPHAAAAAYAAAAAAAAACgAHAAYAAAAB AAYAgQASAP8AAP4PAATwagAAACIACvAIAAAA57gFAAAKAACzAAvwQgAAAIUAAgAAAIcAAQAAAIEB BAAACIMBAAAACL8BAAAQAMAB/wAAAMsB1JQAAM4BAgAAANcBAAAAAP8BCAAIAAECAgAACAAAEPAI AAAAswNQB8AJrgUPAATwVAAAALIECvAIAAAA6LgFAAAKAABDAAvwLAAAAH8AgACAAARBDAAAAAXB FAAAAAYBAQAAAG0AZgAtAGwAbwBnAG8AXwBsAAAAAAAQ8AgAAABQBJAG/AdtBQ8ABPBYAAAAMgAK 8AgAAADpuAUAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAvwAAAA0AgQH/AAAAvwEQABAA/wEGAAYA PwIAAAEAfwMAAA8AAAAQ8AgAAACTBCAI0QhEBQ8ABPBeAAAAQgEK8AgAAADquAUAAAoAAJMAC/A2 AAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywHUlAAA/wEYABgAAQICAAAI AAAQ8AgAAAC3BCkUKRR3Bg8ABPBYAAAAMgAK8AgAAADruAUAAAoAAIMAC/AwAAAAhQACAAAAhwAB AAAAvwAAAA0AgQEAmQAAvwEQABAA/wEGAAYAPwIAAAEAfwMAAA8AAAAQ8AgAAABdBM4TfhQPBQ8A BPCcAAAAogwK8AgAAADsuAUAAAoAAIMAC/AwAAAAgAB4tAQEhQACAAAAhwAGAAAAvwACAAIAgQEE AAAIvwEAABAAwAEBAAAI/wEAAAgAAAAQ8AgAAAB6A+wSyBRhBA8ADfA8AAAAAACfDwQAAAAEAAAA AACoDwQAAABMSU5YAAChDxwAAAAFAAAAAAAAAAoABwAFAAAAAQAGAIEAEgD/AAD+DwAD8I4JAAAP AATwTAAAAAEACfAQAAAA2QMAAKMDAADoBwAA5wYAAAIACvAIAAAA7bgFAAECAAAjAAvwDAAAAAQA AAAAAIgDAAAAAAAAEPAIAAAAkwh3BlQI9QkPAATwYAAAALIECvAIAAAA7rgFAAIKAACDAAvwMAAA AARBDQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAA 2QMAACMFAACIBQAA5wYAAA8ABPBgAAAAsgQK8AgAAADvuAUAAgoAAIMAC/AwAAAABEEOAAAAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAACuBgAAUQUAAOgH AADDBgAADwAD8GIDAAAPAATwVAAAAAEACfAQAAAAfw0AAPIDAAC0DwAAIgQAAAIACvAIAAAA8LgF AEMCAAAjAAvwDAAAAAQAMZDV/4gDAAAAAAAAD/AQAAAA1gYAALwEAACoBwAAAAUAAA8ABPACAQAA AgAK8AgAAADxuAUAAgoAAGMBC/DSAAAAQgFQAQAAQwEXAAAARAEEAAAARcEgAAAARsEoAAAAfwEB AAEAgAEAAAAAgQEAgAAAvwEQABAAwAEAmQAAwQEAAAEAxAEAAAAAywGcMQAAzQEAAAAAzgEAAAAA 0AEAAAAA0QEAAAAA1wEAAAAA/wEYABgAAQICAAAIPwIAAAIAiAMAAAAACAAIAPD/TAAWAFAAEQBJ ARUATwEKAFYABgBZAAAAAAAKAEwAFgARABQAAgAAQACwAQAAsAEAALABAACwAQAAsAEAALABAACw AQAAsACAAAAP8BAAAAB/DQAACwQAAM8OAAAiBAAADwAE8AIBAAACAArwCAAAAPK4BQACCgAAYwEL 8NIAAABCAWQBAABDARYAAABEAQQAAABFwSAAAABGwSgAAAB/AQEAAQCAAQAAAACBAQCAAAC/ARAA EADAAQCZAADBAQAAAQDEAQAAAADLAZwxAADNAQAAAADOAQAAAADQAQAAAADRAQAAAADXAQAAAAD/ ARgAGAABAgIAAAg/AgAAAgCIAwAAAAAIAAgA8P8SAQAADwEFAAYAAQAAAAsACAEQAAUBFQBjAQwA EgEAABEAFAACAABAALABAACwAQAAsAEAALABAACwAQAAsAEAALABAACwAIAAAA/wEAAAAFAOAADy AwAAtA8AAAgEAAAPAATw6gAAAAIACvAIAAAA87gFAAIKAABjAQvwugAAAEIBfQAAAEMBLQAAAEQB BAAAAEXBFAAAAEbBHAAAAH8BAQABAIABAAAAAIEBAIAAAL8BEAAQAMABAJkAAMEBAAABAMQBAAAA AMsBnDEAAM0BAAAAAM4BAAAAANABAAAAANEBAAAAANcBAAAAAP8BGAAYAAECAgAACD8CAAACAIgD AAAAAAUABQDw/1oALAAAAAoAIgAAAHwAIgBaACwACwAMAAIAAEAAsAEAALABAACwAQAAsAEAALAA gAAAD/AQAAAAVw4AAPQDAADUDgAAIQQAAA8AA/COAQAADwAE8FQAAAABAAnwEAAAALICAAC2BwAA EgMAAAoIAAACAArwCAAAAPS4BQADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAANsFAACj AwAAqQYAAEEEAAAPAATwYAAAAEIBCvAIAAAA9bgFAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAD/AQAAAA+gIAALYHAAD6AgAA5gcA AA8ABPBgAAAAQgEK8AgAAAD2uAUAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAP8BAAAADWAgAAtgcAANYCAADyBwAADwAE8FoAAAAS AArwCAAAAPe4BQACCgAAcwAL8CoAAACFAAIAAACHAAEAAACBATMzMwC/ARAAEADAAQEAAAj/AQgA CAABAgIAAAgAAA/wEAAAALICAADaBwAAEgMAAAoIAAAPAAPwYgMAAA8ABPBUAAAAAQAJ8BAAAAB/ DQAA8gMAALQPAAAiBAAAAgAK8AgAAAD4uAUAAwIAACMAC/AMAAAABAAxkNX/iAMAAAAAAAAP8BAA AABOBQAAxQQAADMGAAD7BAAADwAE8AIBAAACAArwCAAAAPm4BQACCgAAYwEL8NIAAABCAVABAABD ARcAAABEAQQAAABFwSAAAABGwSgAAAB/AQEAAQCAAQAAAACBAQCAAAC/ARAAEADAAQCZAADBAQAA AQDEAQAAAADLAZwxAADNAQAAAADOAQAAAADQAQAAAADRAQAAAADXAQAAAAD/ARgAGAABAgIAAAg/ AgAAAgCIAwAAAAAIAAgA8P9MABYAUAARAEkBFQBPAQoAVgAGAFkAAAAAAAoATAAWABEAFAACAABA ALABAACwAQAAsAEAALABAACwAQAAsAEAALABAACwAIAAAA/wEAAAAH8NAAALBAAAzw4AACIEAAAP AATwAgEAAAIACvAIAAAA+rgFAAIKAABjAQvw0gAAAEIBZAEAAEMBFgAAAEQBBAAAAEXBIAAAAEbB KAAAAH8BAQABAIABAAAAAIEBAIAAAL8BEAAQAMABAJkAAMEBAAABAMQBAAAAAMsBnDEAAM0BAAAA AM4BAAAAANABAAAAANEBAAAAANcBAAAAAP8BGAAYAAECAgAACD8CAAACAIgDAAAAAAgACADw/xIB AAAPAQUABgABAAAACwAIARAABQEVAGMBDAASAQAAEQAUAAIAAEAAsAEAALABAACwAQAAsAEAALAB AACwAQAAsAEAALAAgAAAD/AQAAAAUA4AAPIDAAC0DwAACAQAAA8ABPDqAAAAAgAK8AgAAAD7uAUA AgoAAGMBC/C6AAAAQgF9AAAAQwEtAAAARAEEAAAARcEUAAAARsEcAAAAfwEBAAEAgAEAAAAAgQEA gAAAvwEQABAAwAEAmQAAwQEAAAEAxAEAAAAAywGcMQAAzQEAAAAAzgEAAAAA0AEAAAAA0QEAAAAA 1wEAAAAA/wEYABgAAQICAAAIPwIAAAIAiAMAAAAABQAFAPD/WgAsAAAACgAiAAAAfAAiAFoALAAL AAwAAgAAQACwAQAAsAEAALABAACwAQAAsACAAAAP8BAAAABXDgAA9AMAANQOAAAhBAAADwAE8F4A AABCAQrwCAAAAPy4BQAACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAjLAdSUAAD/ARgAGAABAgIAAAgAABDwCAAAABMHhAeEB4QIDwAE8GQAAAAiAArwCAAAAP24 BQAACgAAowAL8DwAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAADO AQIAAAD/AQgACAABAgIAAAgAABDwCAAAAHEIIwbeCDEKDwAE8NUAAAAyAArwCAAAAP64BQAACgAA owAL8DwAAACAAIy8BASFAAIAAACHAAEAAACBAZnM/wC/ARAAEADAAQEAAAj/AQgACAABAgIAAAg/ AgIAAgC/AgAACAAAABDwCAAAADIGoAHPFqQHDwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPHwAAAE5U VC9WRVJJTyBHbG9iYWwgSVB2NiBCYWNrYm9uZSAAAKEPLgAAACAAAAAAAAAICgABAAcACQAAAAMA RwCDAAMAAwAUAAAAzP4XAAAAAQACAIEAFAAPAATwwQAAABIACvAIAAAA/7gFAAAKAACjAAvwPAAA AIAAfL4EBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC AgAACAAAEPAIAAAAqQx2DSMQIw8PAA3wVQAAAAAAnw8EAAAABAAAAAAAqA8VAAAASVB2Ng1HYXRl d2F5DVNlcnZpY2VzAAChDyQAAAAWAAAAAAAACAoAAQAHABUAAAADAAIAgwAUAAEAAAADAAAAgwAP AATwXgAAACIACvAIAAAAALkFAAAKAACTAAvwNgAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8B AAAQAMAB/wAAAMsBPt8AAP8BCAAIAAECAgAACAAAEPAIAAAAgQuiBagQGQ8PAATwxgAAABIACvAI AAAAAbkFAAAKAACjAAvwPAAAAIAA3MYEBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8B AAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAngw1Cl4NGA8PAA3wWgAAAAAAnw8EAAAABAAA AAAAqA8YAAAASVB2Ng1UdW5uZWxpbmcNU2VydmljZXMgAAChDyYAAAAZAAAAAAAACAoAAQAHABcA AAADAAIAgwAUAAIAAAADAAIAgwASAA8AA/BIBAAADwAE8EwAAAABAAnwEAAAAPsDAAB1CwAAWwsA AAwQAAACAArwCAAAAAK5BQABAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAAUMQQsTDJ0M DwAD8AgDAAAPAATwTgAAAAEACfAQAAAA+wMAALgOAABbCwAADBAAAAIACvAIAAAAA7kFAAMCAAAT AAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPD+AAAAAgAK8AgAAAAEuQUA AgoAABMBC/DOAAAAQgFgBwAAQwFUAQAARAEEAAAARcEsAAAARsE2AAAAfwEBAAEAgAEAAAAAgQH/ //8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAA CwALAPD/6gAAAHwGAABeBzUBYAdDAVgHUAFJB1QBGwBUAQgATgEAAD8BBAAuAeoAAAAYABwAAgAA QACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAPsD AAC4DgAAWwsAAAwQAAAPAATwzgAAAAIACvAIAAAABbkFAAIKAAATAQvwngAAAEIB6AQAAEMB2gAA AEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB ////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/6kAAACtBAAA6ATaAAAA2gCp AAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAABjBAAAAg8AAEsJAADcDwAA DwAE8M4AAAACAArwCAAAAAa5BQACCgAAEwEL8J4AAABCAXwBAABDAdoAAABEAQQAAABFwRQAAABG wR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwx AADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P8AAAAA4QAAAHwB2gBHANoAAAAAAAwAEAACAABAAKwB AACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgkAAAIPAADuCgAA3A8AAA8ABPBCAAAAEgAK8AgA AAAHuQUAAgoAADMAC/ASAAAAvwEQABAAywGcMQAA/wEIAAgAAAAP8BAAAAClBQAAdQsAAK8JAACv DgAADwAE8EgAAAASAArwCAAAAAi5BQACCgAAQwAL8BgAAACBARBQ/wC/ARAAEADLAZwxAAD/AQgA CAAAAA/wEAAAADMGAADmCwAAIQkAACEOAAAPAATwQgAAABIACvAIAAAACbkFAAIKAAAzAAvwEgAA AIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQAAAAwwgAAFIOAAAgCQAAgA4AAA8AA/BIBAAADwAE8EwA AAABAAnwEAAAAPsDAAB1CwAAWwsAAAwQAAACAArwCAAAAAq5BQABAgAAIwAL8AwAAAAEAAAAAACI AwAAAAAAABDwCAAAAAUMPwwRDZ0MDwAD8AgDAAAPAATwTgAAAAEACfAQAAAA+wMAALgOAABbCwAA DBAAAAIACvAIAAAAC7kFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA+wMAALgOAABbCwAADBAA AA8ABPD+AAAAAgAK8AgAAAAMuQUAAgoAABMBC/DOAAAAQgFgBwAAQwFUAQAARAEEAAAARcEsAAAA RsE2AAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGc MQAAzgEAAAAA/wEYABgAiAMAAAAACwALAPD/6gAAAHwGAABeBzUBYAdDAVgHUAFJB1QBGwBUAQgA TgEAAD8BBAAuAeoAAAAYABwAAgAAQACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAQAArAFgAIAAAA/wEAAAAPsDAAC4DgAAWwsAAAwQAAAPAATwzgAAAAIACvAIAAAADbkFAAIK AAATAQvwngAAAEIB6AQAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB//// AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUA BQDw/6kAAACtBAAA6ATaAAAA2gCpAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP 8BAAAABjBAAAAg8AAEsJAADcDwAADwAE8M4AAAACAArwCAAAAA65BQACCgAAEwEL8J4AAABCAXwB AABDAdoAAABEAQQAAABFwRQAAABGwR4AAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADA AQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAAFAAUA8P8AAAAA4QAAAHwB 2gBHANoAAAAAAAwAEAACAABAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAAcgkAAAIPAADu CgAA3A8AAA8ABPBCAAAAEgAK8AgAAAAPuQUAAgoAADMAC/ASAAAAvwEQABAAywGcMQAA/wEIAAgA AAAP8BAAAAClBQAAdQsAAK8JAACvDgAADwAE8EgAAAASAArwCAAAABC5BQACCgAAQwAL8BgAAACB ARBQ/wC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAADMGAADmCwAAIQkAACEOAAAPAATwQgAAABIA CvAIAAAAEbkFAAIKAAAzAAvwEgAAAIEBAAAAAL8BEAAQAP8BAAAIAAAAD/AQAAAAwwgAAFIOAAAg CQAAgA4AAA8ABPCgAAAAMgAK8AgAAAASuQUAAAoAAIMAC/AwAAAAgABc0AQEhQACAAAAhwABAAAA gQEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADeCzQNQBCyDA8ADfBAAAAAAACf DwQAAAAEAAAAAACoDwgAAABJU1AsIGlEQwAAoQ8cAAAACQAAAAAAAAgKAAEABwAJAAAAAAAGABAA AAAAAw8ABPBWAAAAsgQK8AgAAAATuQUAAAoAAEMAC/AuAAAAfwCAAIAABEEPAAAABcEWAAAABgEB AAAAaQBjAG8AbgBfAG4AZQB3ADAAMwAAAAAAEPAIAAAA7QfKBRwHkwgPAATwVgAAALIECvAIAAAA FLkFAAAKAABDAAvwLgAAAH8AgACAAARBDwAAAAXBFgAAAAYBAQAAAGkAYwBvAG4AXwBuAGUAdwAw ADMAAAAAABDwCAAAAD0DgAbSB+MDDwAE8MoAAAASAArwCAAAABW5BQAACgAAowAL8DwAAACAANDU BASFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA ABDwCAAAAJ4MtQVWCRgPDwAN8F4AAAAAAJ8PBAAAAAQAAAAAAKgPHAAAAElQdjYvSVB2NA1EdWFs IEFjY2Vzcw13LyBQblAAAKEPJgAAAB0AAAAAAAAICgABAAcAHAAAAAMAAgCDABQAAQAAAAMAAgCD ABIADwAD8EgEAAAPAATwTAAAAAEACfAQAAAA+wMAAHULAABbCwAADBAAAAIACvAIAAAAFrkFAAEC AAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAABQzLBp0HnQwPAAPwCAMAAA8ABPBOAAAAAQAJ 8BAAAAD7AwAAuA4AAFsLAAAMEAAAAgAK8AgAAAAXuQUAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAA AAD7AwAAuA4AAFsLAAAMEAAADwAE8P4AAAACAArwCAAAABi5BQACCgAAEwEL8M4AAABCAWAHAABD AVQBAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAA AADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAALAAsA8P/qAAAAfAYAAF4HNQFg B0MBWAdQAUkHVAEbAFQBCABOAQAAPwEEAC4B6gAAABgAHAACAABAAKwBAACsAQAArAEAAKwBAACs AQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPDO AAAAAgAK8AgAAAAZuQUAAgoAABMBC/CeAAAAQgHoBAAAQwHaAAAARAEEAAAARcEUAAAARsEeAAAA fwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEA AAAA/wEYABgAiAMAAAAABQAFAPD/qQAAAK0EAADoBNoAAADaAKkAAAAMABAAAgAAQACsAQAArAEA AKwBAACsAQAArAFgAIAAAA/wEAAAAGMEAAACDwAASwkAANwPAAAPAATwzgAAAAIACvAIAAAAGrkF AAIKAAATAQvwngAAAEIBfAEAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB ////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAA AAUABQDw/wAAAADhAAAAfAHaAEcA2gAAAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACA AAAP8BAAAAByCQAAAg8AAO4KAADcDwAADwAE8EIAAAASAArwCAAAABu5BQACCgAAMwAL8BIAAAC/ ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAAKUFAAB1CwAArwkAAK8OAAAPAATwSAAAABIACvAIAAAA HLkFAAIKAABDAAvwGAAAAIEBEFD/AL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAAMwYAAOYLAAAh CQAAIQ4AAA8ABPBCAAAAEgAK8AgAAAAduQUAAgoAADMAC/ASAAAAgQEAAAAAvwEQABAA/wEAAAgA AAAP8BAAAADDCAAAUg4AACAJAACADgAADwAD8EgEAAAPAATwTAAAAAEACfAQAAAA+wMAAHULAABb CwAADBAAAAIACvAIAAAAHrkFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAABQzJB5wI nQwPAAPwCAMAAA8ABPBOAAAAAQAJ8BAAAAD7AwAAuA4AAFsLAAAMEAAAAgAK8AgAAAAfuQUAAwIA ABMAC/AGAAAAiAMAAAAAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8P4AAAACAArwCAAAACC5 BQACCgAAEwEL8M4AAABCAWAHAABDAVQBAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACB Af///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAA AAALAAsA8P/qAAAAfAYAAF4HNQFgB0MBWAdQAUkHVAEbAFQBCABOAQAAPwEEAC4B6gAAABgAHAAC AABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA +wMAALgOAABbCwAADBAAAA8ABPDOAAAAAgAK8AgAAAAhuQUAAgoAABMBC/CeAAAAQgHoBAAAQwHa AAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAA wgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/qQAAAK0EAADoBNoAAADa AKkAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGMEAAACDwAASwkAANwP AAAPAATwzgAAAAIACvAIAAAAIrkFAAIKAAATAQvwngAAAEIBfAEAAEMB2gAAAEQBBAAAAEXBFAAA AEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsB nDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/wAAAADhAAAAfAHaAEcA2gAAAAAADAAQAAIAAEAA rAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAByCQAAAg8AAO4KAADcDwAADwAE8EIAAAASAArw CAAAACO5BQACCgAAMwAL8BIAAAC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAAKUFAAB1CwAArwkA AK8OAAAPAATwSAAAABIACvAIAAAAJLkFAAIKAABDAAvwGAAAAIEBEFD/AL8BEAAQAMsBnDEAAP8B CAAIAAAAD/AQAAAAMwYAAOYLAAAhCQAAIQ4AAA8ABPBCAAAAEgAK8AgAAAAluQUAAgoAADMAC/AS AAAAgQEAAAAAvwEQABAA/wEAAAgAAAAP8BAAAADDCAAAUg4AACAJAACADgAADwAE8F4AAABCAQrw CAAAACa5BQBACgAAkwAL8DYAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjL AdSUAAD/ARgAGAABAgIAAAgAABDwCAAAAEMKlQcFChQMDwAD8GIBAAAPAATwTAAAAAEACfAQAAAA 4AQAANALAACfBwAAbQ0AAAIACvAIAAAAJ7kFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAI AAAAUwkmCSAM8AoPAATwrAAAADIACvAIAAAAKLkFAAIKAACDAAvwMAAAAIAA7MAEBIUAAgAAAIcA AQAAAIEBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAA4AQAANALAACfBwAAbQ0A AA8ADfBEAAAAAACfDwQAAAAEAAAAAAChDxwAAAABAAAAAAAACAoAAgAHAAEAAAAAAAYAEAAAAAAD AACqDwwAAAABAAAABgAAAAkEAAAPAATwUgAAALIECvAIAAAAKbkFAAIKAABDAAvwIgAAAH8AgACA AARBBQAAAAXBCgAAAAYBAQAAAGEAYwBjAGEAAAAAAA/wEAAAAEAFAAAwDAAANgcAABQNAAAPAAPw YAEAAA8ABPBMAAAAAQAJ8BAAAABABQAAcAgAAP8HAAANCgAAAgAK8AgAAAAquQUAAQIAACMAC/AM AAAABAAAAAAAiAMAAAAAAAAQ8AgAAABGCOgK4Q3jCQ8ABPCsAAAAMgAK8AgAAAAruQUAAgoAAIMA C/AwAAAAgACk4wQEhQACAAAAhwABAAAAgQEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAP 8BAAAABABQAAcAgAAP8HAAANCgAADwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKEPHAAAAAEAAAAAAAAI CgACAAcAAQAAAAAABgAQAAAAAAMAAKoPDAAAAAEAAAAGAAAACQQAAA8ABPBQAAAAsgQK8AgAAAAs uQUAAgoAAEMAC/AgAAAAfwCAAIAABEEEAAAABcEIAAAABgEBAAAAbwBjAG4AAAAAAA/wEAAAANAF AABwCAAAXAcAAPwJAAAPAATwmgAAALIECvAIAAAALbkFACAKAADDAAvwWgAAAAQAAAAAAH8ABAAF AARBEAAAAAXBEAAAAAYBAQAAAIEB////AL8BAAABAMABAAAAAP8BAAABAAEDAwQAAIHDAgAAAIgD AAAAAGgAbwB0AHMAcABvAHQAAAAAAAAAEPAIAAAAYwpXBtII0AoPABHwEAAAAAAAwwsIAAAAAQAA ABMABAQPAATw7wAAAKIMCvAIAAAALrkFAAAKAADzAAvwWgAAAIAAuOYEBIEAkF8BAIIA0LYAAIMA kF8BAIQA0LYAAIcAAQAAAL8AAgAPAIEBAAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAA CD8CAAADAH8DAAAPAAAAEPAIAAAA7g1+ALIDrg4PAA3wZQAAAAAAnw8EAAAABAAAAAAAqA8LAAAA TlRUIEF1c3QgSVAAAKEPHAAAAAwAAAAAAAAoCgABABQABwAMAAAAgwQCAAMEDgAAAKoPGgAAAAQA AAAAAAAABAAAAAEAAAADAAQAAAAAAAAADwAE8GQAAAAiAArwCAAAAC+5BQAACgAAowAL8DwAAACF AAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAf8AAADLAdSUAADOAQIAAAD/AQgACAABAgIA AAgAABDwCAAAAIMM2QBdA+kNDwAD8EgEAAAPAATwTAAAAAEACfAQAAAA+wMAAHULAABbCwAADBAA AAIACvAIAAAAMLkFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAA9QxGAQgCjQ0PAAPw CAMAAA8ABPBOAAAAAQAJ8BAAAAD7AwAAuA4AAFsLAAAMEAAAAgAK8AgAAAAxuQUAAwIAABMAC/AG AAAAiAMAAAAAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE8P4AAAACAArwCAAAADK5BQACCgAA EwEL8M4AAABCAWAHAABDAVQBAABEAQQAAABFwSwAAABGwTYAAAB/AQEAAQCAAQAAAACBAf///wCD Af///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADOAQAAAAD/ARgAGACIAwAAAAALAAsA 8P/qAAAAfAYAAF4HNQFgB0MBWAdQAUkHVAEbAFQBCABOAQAAPwEEAC4B6gAAABgAHAACAABAAKwB AACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAWAAgAAAD/AQAAAA+wMAALgO AABbCwAADBAAAA8ABPDOAAAAAgAK8AgAAAAzuQUAAgoAABMBC/CeAAAAQgHoBAAAQwHaAAAARAEE AAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH///8AvwEQABAAwAEAAAAAwgH///8A xAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/qQAAAK0EAADoBNoAAADaAKkAAAAM ABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAAAGMEAAACDwAASwkAANwPAAAPAATw zgAAAAIACvAIAAAANLkFAAIKAAATAQvwngAAAEIBfAEAAEMB2gAAAEQBBAAAAEXBFAAAAEbBHgAA AH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAAAMIB////AMQBAAAAAMsBnDEAAM4B AAAAAP8BGAAYAIgDAAAAAAUABQDw/wAAAADhAAAAfAHaAEcA2gAAAAAADAAQAAIAAEAArAEAAKwB AACsAQAArAEAAKwBYACAAAAP8BAAAAByCQAAAg8AAO4KAADcDwAADwAE8EIAAAASAArwCAAAADW5 BQACCgAAMwAL8BIAAAC/ARAAEADLAZwxAAD/AQgACAAAAA/wEAAAAKUFAAB1CwAArwkAAK8OAAAP AATwSAAAABIACvAIAAAANrkFAAIKAABDAAvwGAAAAIEBEFD/AL8BEAAQAMsBnDEAAP8BCAAIAAAA D/AQAAAAMwYAAOYLAAAhCQAAIQ4AAA8ABPBCAAAAEgAK8AgAAAA3uQUAAgoAADMAC/ASAAAAgQEA AAAAvwEQABAA/wEAAAgAAAAP8BAAAADDCAAAUg4AACAJAACADgAADwAD8EgEAAAPAATwTAAAAAEA CfAQAAAA+wMAAHULAABbCwAADBAAAAIACvAIAAAAOLkFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAA AAAAEPAIAAAA9QwxAvMCjQ0PAAPwCAMAAA8ABPBOAAAAAQAJ8BAAAAD7AwAAuA4AAFsLAAAMEAAA AgAK8AgAAAA5uQUAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAD7AwAAuA4AAFsLAAAMEAAADwAE 8P4AAAACAArwCAAAADq5BQACCgAAEwEL8M4AAABCAWAHAABDAVQBAABEAQQAAABFwSwAAABGwTYA AAB/AQEAAQCAAQAAAACBAf///wCDAf///wC/ARAAEADAAQAAAADCAf///wDEAQAAAADLAZwxAADO AQAAAAD/ARgAGACIAwAAAAALAAsA8P/qAAAAfAYAAF4HNQFgB0MBWAdQAUkHVAEbAFQBCABOAQAA PwEEAC4B6gAAABgAHAACAABAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwBAACsAQAArAEAAKwB AACsAWAAgAAAD/AQAAAA+wMAALgOAABbCwAADBAAAA8ABPDOAAAAAgAK8AgAAAA7uQUAAgoAABMB C/CeAAAAQgHoBAAAQwHaAAAARAEEAAAARcEUAAAARsEeAAAAfwEBAAEAgAEAAAAAgQH///8AgwH/ //8AvwEQABAAwAEAAAAAwgH///8AxAEAAAAAywGcMQAAzgEAAAAA/wEYABgAiAMAAAAABQAFAPD/ qQAAAK0EAADoBNoAAADaAKkAAAAMABAAAgAAQACsAQAArAEAAKwBAACsAQAArAFgAIAAAA/wEAAA AGMEAAACDwAASwkAANwPAAAPAATwzgAAAAIACvAIAAAAPLkFAAIKAAATAQvwngAAAEIBfAEAAEMB 2gAAAEQBBAAAAEXBFAAAAEbBHgAAAH8BAQABAIABAAAAAIEB////AIMB////AL8BEAAQAMABAAAA AMIB////AMQBAAAAAMsBnDEAAM4BAAAAAP8BGAAYAIgDAAAAAAUABQDw/wAAAADhAAAAfAHaAEcA 2gAAAAAADAAQAAIAAEAArAEAAKwBAACsAQAArAEAAKwBYACAAAAP8BAAAAByCQAAAg8AAO4KAADc DwAADwAE8EIAAAASAArwCAAAAD25BQACCgAAMwAL8BIAAAC/ARAAEADLAZwxAAD/AQgACAAAAA/w EAAAAKUFAAB1CwAArwkAAK8OAAAPAATwSAAAABIACvAIAAAAPrkFAAIKAABDAAvwGAAAAIEBEFD/ AL8BEAAQAMsBnDEAAP8BCAAIAAAAD/AQAAAAMwYAAOYLAAAhCQAAIQ4AAA8ABPBCAAAAEgAK8AgA AAA/uQUAAgoAADMAC/ASAAAAgQEAAAAAvwEQABAA/wEAAAgAAAAP8BAAAADDCAAAUg4AACAJAACA DgAADwAE8KUAAACiDArwCAAAAEC5BQAACgAAkwAL8DYAAACAAPzvBASFAAIAAACHAAYAAAC/AAIA AgCBAf/MzAC/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAEkONAGpAx0PDwAN8D8AAAAA AJ8PBAAAAAQAAAAAAKgPCQAAAEF1c3RyYWxpYQAAoQ8aAAAACgAAAAAAAAgKAAEABwAKAAAAEQAC AJEAEAAPAATwXgAAAEIBCvAIAAAAQbkFAAAKAACTAAvwNgAAAIUAAgAAAIcAAQAAAEQBBAAAAH8B AAABAL8BAAAQAMABAQAACMsB1JQAAP8BGAAYAAECAgAACAAAEPAIAAAAigQJEgkSSgYPAATwWAAA ADIACvAIAAAAQrkFAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAL8AAAANAIEBAJkAAL8BEAAQAP8B BgAGAD8CAAABAH8DAAAPAAAAEPAIAAAANwSpEUsS6QQPAATwnAAAAKIMCvAIAAAAQ7kFAAAKAACD AAvwMAAAAIAAvPQEBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACL8BAAAQAMABAQAACP8BAAAIAAAA EPAIAAAAYAPdENkSRwQPAA3wPAAAAAAAnw8EAAAABAAAAAAAqA8EAAAAVUs2WAAAoQ8cAAAABQAA AAAAAAAKAAcABQAAAAEABgCBABIA/wAA/g8ABPBIAAAAEgAK8AgAAAABuAUAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwEeQJcAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8AiBOBAAAADwCKE3kAAAAAALoPEAAAAF8A XwBfAFAAUABUADEAMAAAAIsTWQAAAAAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAC5EwD/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDu A4KMAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwATAA8ADAQxfAAADwAC8Cl8AAAADAjw CAAAAGgBAABptQUADwAD8Hl7AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAALQFAAUAAAAPAAPwTAEAAA8ABPBMAAAAAQAJ8BAAAABABQAAcAgAAP8HAAANCgAAAgAK8AgA AAACtAUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAAAmBi4Ecgh2CA8ABPCYAAAAMgAK 8AgAAAADtAUAAgoAAIMAC/AwAAAAgABEAe0EhQACAAAAhwABAAAAgQEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAP8BAAAABABQAAcAgAAP8HAAANCgAADwAN8DAAAAAAAJ8PBAAAAAQAAAAA AKEPHAAAAAEAAAAAAAAICgACAAcAAQAAAAAABgAQAAAAAAMPAATwUAAAALIECvAIAAAABLQFAAIK AABDAAvwIAAAAH8AgACAAARBBAAAAAXBCAAAAAYBAQAAAG8AYwBuAAAAAAAP8BAAAADQBQAAcAgA AFwHAAD8CQAADwAD8E4BAAAPAATwTAAAAAEACfAQAAAA4AQAANALAACfBwAAbQ0AAAIACvAIAAAA BbQFAAECAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAEPAIAAAAeQaBB3oKFggPAATwmAAAADIACvAI AAAABrQFAAIKAACDAAvwMAAAAIAAqAXtBIUAAgAAAIcAAQAAAIEBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACAAAD/AQAAAA4AQAANALAACfBwAAbQ0AAA8ADfAwAAAAAACfDwQAAAAEAAAAAACh DxwAAAABAAAAAAAACAoAAgAHAAEAAAAAAAYAEAAAAAADDwAE8FIAAACyBArwCAAAAAe0BQACCgAA QwAL8CIAAAB/AIAAgAAEQQUAAAAFwQoAAAAGAQEAAABhAGMAYwBhAAAAAAAP8BAAAABABQAAMAwA ADYHAAAUDQAADwAE8H4AAAASAArwCAAAAAi0BQAgAgAAcwAL8CoAAAAEAAAAAAB/AAAABACAAMQG 7QS/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAGAA1AGMFjADDwAR8BAAAAAAAMMLCAAA AAAAAAANAO0EDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwWAAAAEIBCvAIAAAACbQFAAAKAACDAAvw MAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BAgAAANcBAAAAAP8BGAAYAAECAgAACAAAEPAI AAAAhgc4BDgERg4PAATwWAAAAEIBCvAIAAAACrQFAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8B AAAQAMABAQAACM4BAgAAANcBAAAAAP8BGAAYAAECAgAACAAAEPAIAAAAdgedC50LNg4PAATwWAAA AEIBCvAIAAAAC7QFAAAKAACDAAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BAgAAANcB AAAAAP8BGAAYAAECAgAACAAAEPAIAAAAdgeBEYERNg4PAATwWAAAAEIBCvAIAAAADLQFAAAKAACD AAvwMAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACM4BAgAAANcBAAAAAP8BGAAYAAECAgAACAAA EPAIAAAAdgeqFqoWNg4PAATwzAAAAGIBCvAIAAAADrQFAAAKAADzAAvwWgAAAIAA8AntBIEAkF8B AIIA0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgAPAIEBBAAACL8BHAAeAMABAQAACP8B DgAOAAECAgAACD8CAAADAH8DAAAPAAAAEPAIAAAA8wZFAzIF6wcPAA3wQgAAAAAAnw8EAAAABAAA AAAAqA8GAAAAUkFESVVTAAChDyAAAAAHAAAAAAAAKAoAAQAUAAcABwAAAIAEQwAABAQABAAMAA8A BPB8AAAAAgIK8AgAAAAPtAUAAAsAAOMAC/BUAAAAhQACAAAAvwAAAA8AvwEAABAAwAEBAAAI1gEB AAAA/wEOAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AAwMAAAAAfwMQAD8AhAMAAAAAhgMAAAAA AAAQ8AgAAABGBwkNfRBLBw8ABPB8AAAAAgIK8AgAAAAQtAUAgAsAAOMAC/BUAAAAhQACAAAAvwAA AA8AvwEAABAAwAEBAAAI1gEBAAAA/wEOAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AAwMAAAAA fwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAAAEB1cSKxZLBw8ABPDMAAAAogwK8AgAAAARtAUAAAoA AAMBC/BgAAAAgADQ/QQEhQACAAAAhwAGAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI /wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAABG B3gNEQ8GCA8ADfA8AAAAAACfDwQAAAAEAAAAAACoDwQAAABBRFNMAAChDxwAAAAFAAAAAAAQAAoA BAAHAAUAAAAAAEMABAAEAA4ADwAE8MsAAACiDArwCAAAABK0BQAACgAAAwEL8GAAAACAANwP7QSF AAIAAACHAAYAAAC/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAA AwC/AgEADwD/AhYAHwB/AxAAPwCEAwAAAACGAwAAAAAAABDwCAAAAEYHgBPUFAYIDwAN8DsAAAAA AJ8PBAAAAAQAAAAAAKgPAwAAAExBTgAAoQ8cAAAABAAAAAAAEAAKAAQABwAEAAAAAABDAAQABAAO AA8ABPBqAAAAsgQK8AgAAAATtAUAAAoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEGAAAA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAABgBioKCQ0r CA8ABPBqAAAAsgQK8AgAAAAUtAUAAAoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEGAAAA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAAC2Bn0QVxLf Bw8AA/AwWwAADwAE8EwAAAABAAnwEAAAAAoCAADXCwAA3QIAAMgMAAACAArwCAAAABW0BQABAgAA IwAL8AwAAAAEAAAAAACIAwAAAAAAABDwCAAAAIYGDhZ6FwYIDwAD8CINAAAPAATwTgAAAAEACfAQ AAAATAIAAHsMAACbAgAApwwAAAIACvAIAAAAFrQFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA TAIAAHsMAACbAgAApwwAAA8AA/B6DAAADwAE8E4AAAABAAnwEAAAAEwCAAB7DAAAmgIAAKYMAAAC AArwCAAAABe0BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAEwCAAB7DAAAmgIAAKYMAAAPAATw QgAAABIACvAIAAAAGLQFAAIKAAAzAAvwEgAAAIEBVktwAL8BEAAQAP8BAAAIAAAAD/AQAAAATAIA AHsMAABOAgAApgwAAA8ABPBCAAAAEgAK8AgAAAAZtAUAAgoAADMAC/ASAAAAgQFWS3EAvwEQABAA /wEAAAgAAAAP8BAAAABOAgAAewwAAFACAACmDAAADwAE8EIAAAASAArwCAAAABq0BQACCgAAMwAL 8BIAAACBAVdMcgC/ARAAEAD/AQAACAAAAA/wEAAAAFACAAB7DAAAUgIAAKYMAAAPAATwQgAAABIA CvAIAAAAG7QFAAIKAAAzAAvwEgAAAIEBWU10AL8BEAAQAP8BAAAIAAAAD/AQAAAAUgIAAHsMAABU AgAApgwAAA8ABPBCAAAAEgAK8AgAAAActAUAAgoAADMAC/ASAAAAgQFaT3YAvwEQABAA/wEAAAgA AAAP8BAAAABUAgAAewwAAFYCAACmDAAADwAE8EIAAAASAArwCAAAAB20BQACCgAAMwAL8BIAAACB AVxReAC/ARAAEAD/AQAACAAAAA/wEAAAAFYCAAB7DAAAVwIAAKYMAAAPAATwQgAAABIACvAIAAAA HrQFAAIKAAAzAAvwEgAAAIEBX1N7AL8BEAAQAP8BAAAIAAAAD/AQAAAAVwIAAHsMAABZAgAApgwA AA8ABPBCAAAAEgAK8AgAAAAftAUAAgoAADMAC/ASAAAAgQFiVX8AvwEQABAA/wEAAAgAAAAP8BAA AABZAgAAewwAAFsCAACmDAAADwAE8EIAAAASAArwCAAAACC0BQACCgAAMwAL8BIAAACBAWRXggC/ ARAAEAD/AQAACAAAAA/wEAAAAFsCAAB7DAAAXQIAAKYMAAAPAATwQgAAABIACvAIAAAAIbQFAAIK AAAzAAvwEgAAAIEBaFqGAL8BEAAQAP8BAAAIAAAAD/AQAAAAXQIAAHsMAABfAgAApgwAAA8ABPBC AAAAEgAK8AgAAAAitAUAAgoAADMAC/ASAAAAgQFrXYoAvwEQABAA/wEAAAgAAAAP8BAAAABfAgAA ewwAAGECAACmDAAADwAE8EIAAAASAArwCAAAACO0BQACCgAAMwAL8BIAAACBAW1fjgC/ARAAEAD/ AQAACAAAAA/wEAAAAGECAAB7DAAAYwIAAKYMAAAPAATwQgAAABIACvAIAAAAJLQFAAIKAAAzAAvw EgAAAIEBcGKRAL8BEAAQAP8BAAAIAAAAD/AQAAAAYwIAAHsMAABlAgAApgwAAA8ABPBCAAAAEgAK 8AgAAAAltAUAAgoAADMAC/ASAAAAgQFzZJQAvwEQABAA/wEAAAgAAAAP8BAAAABlAgAAewwAAGYC AACmDAAADwAE8EIAAAASAArwCAAAACa0BQACCgAAMwAL8BIAAACBAXVmlwC/ARAAEAD/AQAACAAA AA/wEAAAAGYCAAB7DAAAaAIAAKYMAAAPAATwQgAAABIACvAIAAAAJ7QFAAIKAAAzAAvwEgAAAIEB d2eaAL8BEAAQAP8BAAAIAAAAD/AQAAAAaAIAAHsMAABqAgAApgwAAA8ABPBCAAAAEgAK8AgAAAAo tAUAAgoAADMAC/ASAAAAgQF4aZsAvwEQABAA/wEAAAgAAAAP8BAAAABqAgAAewwAAGwCAACmDAAA DwAE8EIAAAASAArwCAAAACm0BQACCgAAMwAL8BIAAACBAXlqnQC/ARAAEAD/AQAACAAAAA/wEAAA AGwCAAB7DAAAbgIAAKYMAAAPAATwQgAAABIACvAIAAAAKrQFAAIKAAAzAAvwEgAAAIEBemqeAL8B EAAQAP8BAAAIAAAAD/AQAAAAbgIAAHsMAABwAgAApgwAAA8ABPBCAAAAEgAK8AgAAAArtAUAAgoA ADMAC/ASAAAAgQF7a58AvwEQABAA/wEAAAgAAAAP8BAAAABwAgAAewwAAHICAACmDAAADwAE8EIA AAASAArwCAAAACy0BQACCgAAMwAL8BIAAACBAXxsoAC/ARAAEAD/AQAACAAAAA/wEAAAAHICAAB7 DAAAdAIAAKYMAAAPAATwQgAAABIACvAIAAAALbQFAAIKAAAzAAvwEgAAAIEBfGygAL8BEAAQAP8B AAAIAAAAD/AQAAAAdAIAAHsMAAB1AgAApgwAAA8ABPBCAAAAEgAK8AgAAAAutAUAAgoAADMAC/AS AAAAgQF7a54AvwEQABAA/wEAAAgAAAAP8BAAAAB1AgAAewwAAHcCAACmDAAADwAE8EIAAAASAArw CAAAAC+0BQACCgAAMwAL8BIAAACBAXpqngC/ARAAEAD/AQAACAAAAA/wEAAAAHcCAAB7DAAAeQIA AKYMAAAPAATwQgAAABIACvAIAAAAMLQFAAIKAAAzAAvwEgAAAIEBeWmcAL8BEAAQAP8BAAAIAAAA D/AQAAAAeQIAAHsMAAB7AgAApgwAAA8ABPBCAAAAEgAK8AgAAAAxtAUAAgoAADMAC/ASAAAAgQF4 aJsAvwEQABAA/wEAAAgAAAAP8BAAAAB7AgAAewwAAH0CAACmDAAADwAE8EIAAAASAArwCAAAADK0 BQACCgAAMwAL8BIAAACBAXZnmAC/ARAAEAD/AQAACAAAAA/wEAAAAH0CAAB7DAAAfwIAAKYMAAAP AATwQgAAABIACvAIAAAAM7QFAAIKAAAzAAvwEgAAAIEBdGWWAL8BEAAQAP8BAAAIAAAAD/AQAAAA fwIAAHsMAACBAgAApgwAAA8ABPBCAAAAEgAK8AgAAAA0tAUAAgoAADMAC/ASAAAAgQFyY5MAvwEQ ABAA/wEAAAgAAAAP8BAAAACBAgAAewwAAIICAACmDAAADwAE8EIAAAASAArwCAAAADW0BQACCgAA MwAL8BIAAACBAW9hkAC/ARAAEAD/AQAACAAAAA/wEAAAAIICAAB7DAAAhAIAAKYMAAAPAATwQgAA ABIACvAIAAAANrQFAAIKAAAzAAvwEgAAAIEBbF6MAL8BEAAQAP8BAAAIAAAAD/AQAAAAhAIAAHsM AACGAgAApgwAAA8ABPBCAAAAEgAK8AgAAAA3tAUAAgoAADMAC/ASAAAAgQFpXIgAvwEQABAA/wEA AAgAAAAP8BAAAACGAgAAewwAAIgCAACmDAAADwAE8EIAAAASAArwCAAAADi0BQACCgAAMwAL8BIA AACBAWZZhAC/ARAAEAD/AQAACAAAAA/wEAAAAIgCAAB7DAAAigIAAKYMAAAPAATwQgAAABIACvAI AAAAObQFAAIKAAAzAAvwEgAAAIEBY1aAAL8BEAAQAP8BAAAIAAAAD/AQAAAAigIAAHsMAACMAgAA pgwAAA8ABPBCAAAAEgAK8AgAAAA6tAUAAgoAADMAC/ASAAAAgQFgVH0AvwEQABAA/wEAAAgAAAAP 8BAAAACMAgAAewwAAI4CAACmDAAADwAE8EIAAAASAArwCAAAADu0BQACCgAAMwAL8BIAAACBAV5S egC/ARAAEAD/AQAACAAAAA/wEAAAAI4CAAB7DAAAkAIAAKYMAAAPAATwQgAAABIACvAIAAAAPLQF AAIKAAAzAAvwEgAAAIEBW1B3AL8BEAAQAP8BAAAIAAAAD/AQAAAAkAIAAHsMAACRAgAApgwAAA8A BPBCAAAAEgAK8AgAAAA9tAUAAgoAADMAC/ASAAAAgQFaTnUAvwEQABAA/wEAAAgAAAAP8BAAAACR AgAAewwAAJMCAACmDAAADwAE8EIAAAASAArwCAAAAD60BQACCgAAMwAL8BIAAACBAVhNcwC/ARAA EAD/AQAACAAAAA/wEAAAAJMCAAB7DAAAlQIAAKYMAAAPAATwQgAAABIACvAIAAAAP7QFAAIKAAAz AAvwEgAAAIEBV0xxAL8BEAAQAP8BAAAIAAAAD/AQAAAAlQIAAHsMAACXAgAApgwAAA8ABPBCAAAA EgAK8AgAAABAtAUAAgoAADMAC/ASAAAAgQFWS3AAvwEQABAA/wEAAAgAAAAP8BAAAACXAgAAewwA AJkCAACmDAAADwAE8EIAAAASAArwCAAAAEG0BQACCgAAMwAL8BIAAACBAVZLcAC/ARAAEAD/AQAA CAAAAA/wEAAAAJkCAAB7DAAAmgIAAKYMAAAPAATwQgAAABIACvAIAAAAQrQFAAIKAAAzAAvwEgAA AL8BAAAQAMsBaSsAAP8BCAAIAAAAD/AQAAAATAIAAHsMAACbAgAApwwAAA8AA/BCNQAADwAE8E4A AAABAAnwEAAAAAoCAADXCwAA3QIAAIYMAAACAArwCAAAAEO0BQADAgAAEwAL8AYAAACIAwAAAAAA AA/wEAAAAAoCAADXCwAA3QIAAIYMAAAPAAPweh4AAA8ABPBOAAAAAQAJ8BAAAAAKAgAA1wsAAN0C AACGDAAAAgAK8AgAAABEtAUAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAAKAgAA1wsAAN0CAACG DAAADwAD8NIdAAAPAATwTgAAAAEACfAQAAAACgIAANcLAADcAgAAhQwAAAIACvAIAAAARbQFAAMC AAATAAvwBgAAAIgDAAAAAAAAD/AQAAAACgIAANcLAADcAgAAhQwAAA8ABPBCAAAAEgAK8AgAAABG tAUAAgoAADMAC/ASAAAAgQGyjmsAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA1wsAANwCAADZCwAA DwAE8EIAAAASAArwCAAAAEe0BQACCgAAMwAL8BIAAACBAbKOawC/ARAAEAD/AQAACAAAAA/wEAAA AAoCAADZCwAA3AIAANoLAAAPAATwQgAAABIACvAIAAAASLQFAAIKAAAzAAvwEgAAAIEBs45rAL8B EAAQAP8BAAAIAAAAD/AQAAAACgIAANoLAADcAgAA3AsAAA8ABPBCAAAAEgAK8AgAAABJtAUAAgoA ADMAC/ASAAAAgQGzj2wAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA3AsAANwCAADeCwAADwAE8EIA AAASAArwCAAAAEq0BQACCgAAMwAL8BIAAACBAbSQbAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADe CwAA3AIAAN8LAAAPAATwQgAAABIACvAIAAAAS7QFAAIKAAAzAAvwEgAAAIEBtZBtAL8BEAAQAP8B AAAIAAAAD/AQAAAACgIAAN8LAADcAgAA4QsAAA8ABPBCAAAAEgAK8AgAAABMtAUAAgoAADMAC/AS AAAAgQG2kW0AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA4QsAANwCAADjCwAADwAE8EIAAAASAArw CAAAAE20BQACCgAAMwAL8BIAAACBAbeSbgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADjCwAA3AIA AOQLAAAPAATwQgAAABIACvAIAAAATrQFAAIKAAAzAAvwEgAAAIEBuJNuAL8BEAAQAP8BAAAIAAAA D/AQAAAACgIAAOQLAADcAgAA5gsAAA8ABPBCAAAAEgAK8AgAAABPtAUAAgoAADMAC/ASAAAAgQG5 lG8AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA5gsAANwCAADoCwAADwAE8EIAAAASAArwCAAAAFC0 BQACCgAAMwAL8BIAAACBAbuVcAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADoCwAA3AIAAOoLAAAP AATwQgAAABIACvAIAAAAUbQFAAIKAAAzAAvwEgAAAIEBvJZxAL8BEAAQAP8BAAAIAAAAD/AQAAAA CgIAAOoLAADcAgAA6wsAAA8ABPBCAAAAEgAK8AgAAABStAUAAgoAADMAC/ASAAAAgQG+l3IAvwEQ ABAA/wEAAAgAAAAP8BAAAAAKAgAA6wsAANwCAADtCwAADwAE8EIAAAASAArwCAAAAFO0BQACCgAA MwAL8BIAAACBAcCZcwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADtCwAA3AIAAO8LAAAPAATwQgAA ABIACvAIAAAAVLQFAAIKAAAzAAvwEgAAAIEBwZp0AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAO8L AADcAgAA8AsAAA8ABPBCAAAAEgAK8AgAAABVtAUAAgoAADMAC/ASAAAAgQHDnHUAvwEQABAA/wEA AAgAAAAP8BAAAAAKAgAA8AsAANwCAADyCwAADwAE8EIAAAASAArwCAAAAFa0BQACCgAAMwAL8BIA AACBAcWedgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAADyCwAA3AIAAPQLAAAPAATwQgAAABIACvAI AAAAV7QFAAIKAAAzAAvwEgAAAIEByJ94AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAPQLAADcAgAA 9gsAAA8ABPBCAAAAEgAK8AgAAABYtAUAAgoAADMAC/ASAAAAgQHKoXkAvwEQABAA/wEAAAgAAAAP 8BAAAAAKAgAA9gsAANwCAAD3CwAADwAE8EIAAAASAArwCAAAAFm0BQACCgAAMwAL8BIAAACBAcyj egC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAD3CwAA3AIAAPkLAAAPAATwQgAAABIACvAIAAAAWrQF AAIKAAAzAAvwEgAAAIEBz6V8AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAPkLAADcAgAA+wsAAA8A BPBCAAAAEgAK8AgAAABbtAUAAgoAADMAC/ASAAAAgQHRp30AvwEQABAA/wEAAAgAAAAP8BAAAAAK AgAA+wsAANwCAAD8CwAADwAE8EIAAAASAArwCAAAAFy0BQACCgAAMwAL8BIAAACBAdSpfwC/ARAA EAD/AQAACAAAAA/wEAAAAAoCAAD8CwAA3AIAAP4LAAAPAATwQgAAABIACvAIAAAAXbQFAAIKAAAz AAvwEgAAAIEB1quAAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAP4LAADcAgAAAAwAAA8ABPBCAAAA EgAK8AgAAABetAUAAgoAADMAC/ASAAAAgQHZrYIAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAAAwA ANwCAAACDAAADwAE8EIAAAASAArwCAAAAF+0BQACCgAAMwAL8BIAAACBAdyvhAC/ARAAEAD/AQAA CAAAAA/wEAAAAAoCAAACDAAA3AIAAAMMAAAPAATwQgAAABIACvAIAAAAYLQFAAIKAAAzAAvwEgAA AIEB3rGFAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAAMMAADcAgAABQwAAA8ABPBCAAAAEgAK8AgA AABhtAUAAgoAADMAC/ASAAAAgQHhs4cAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAABQwAANwCAAAH DAAADwAE8EIAAAASAArwCAAAAGK0BQACCgAAMwAL8BIAAACBAeO1iAC/ARAAEAD/AQAACAAAAA/w EAAAAAoCAAAHDAAA3AIAAAgMAAAPAATwQgAAABIACvAIAAAAY7QFAAIKAAAzAAvwEgAAAIEB5beJ AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAAgMAADcAgAACgwAAA8ABPBCAAAAEgAK8AgAAABktAUA AgoAADMAC/ASAAAAgQHnuYsAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAACgwAANwCAAAMDAAADwAE 8EIAAAASAArwCAAAAGW0BQACCgAAMwAL8BIAAACBAeq7jAC/ARAAEAD/AQAACAAAAA/wEAAAAAoC AAAMDAAA3AIAAA0MAAAPAATwQgAAABIACvAIAAAAZrQFAAIKAAAzAAvwEgAAAIEB7LyNAL8BEAAQ AP8BAAAIAAAAD/AQAAAACgIAAA0MAADcAgAADwwAAA8ABPBCAAAAEgAK8AgAAABntAUAAgoAADMA C/ASAAAAgQHuvo4AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAADwwAANwCAAARDAAADwAE8EIAAAAS AArwCAAAAGi0BQACCgAAMwAL8BIAAACBAe+/jwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAARDAAA 3AIAABMMAAAPAATwQgAAABIACvAIAAAAabQFAAIKAAAzAAvwEgAAAIEB8cGQAL8BEAAQAP8BAAAI AAAAD/AQAAAACgIAABMMAADcAgAAFAwAAA8ABPBCAAAAEgAK8AgAAABqtAUAAgoAADMAC/ASAAAA gQHzwpEAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAFAwAANwCAAAWDAAADwAE8EIAAAASAArwCAAA AGu0BQACCgAAMwAL8BIAAACBAfTDkgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAWDAAA3AIAABgM AAAPAATwQgAAABIACvAIAAAAbLQFAAIKAAAzAAvwEgAAAIEB9cSTAL8BEAAQAP8BAAAIAAAAD/AQ AAAACgIAABgMAADcAgAAGQwAAA8ABPBCAAAAEgAK8AgAAABttAUAAgoAADMAC/ASAAAAgQH3xZQA vwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAGQwAANwCAAAbDAAADwAE8EIAAAASAArwCAAAAG60BQAC CgAAMwAL8BIAAACBAfjGlQC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAbDAAA3AIAAB0MAAAPAATw QgAAABIACvAIAAAAb7QFAAIKAAAzAAvwEgAAAIEB+ceVAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIA AB0MAADcAgAAHwwAAA8ABPBCAAAAEgAK8AgAAABwtAUAAgoAADMAC/ASAAAAgQH6yJYAvwEQABAA /wEAAAgAAAAP8BAAAAAKAgAAHwwAANwCAAAgDAAADwAE8EIAAAASAArwCAAAAHG0BQACCgAAMwAL 8BIAAACBAfvIlgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAgDAAA3AIAACIMAAAPAATwQgAAABIA CvAIAAAAcrQFAAIKAAAzAAvwEgAAAIEB+8mXAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAACIMAADc AgAAJAwAAA8ABPBCAAAAEgAK8AgAAABztAUAAgoAADMAC/ASAAAAgQH8ypcAvwEQABAA/wEAAAgA AAAP8BAAAAAKAgAAJAwAANwCAAAlDAAADwAE8EIAAAASAArwCAAAAHS0BQACCgAAMwAL8BIAAACB Af3KlwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAlDAAA3AIAACcMAAAPAATwQgAAABIACvAIAAAA dbQFAAIKAAAzAAvwEgAAAIEB/cqYAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAACcMAADcAgAAKQwA AA8ABPBCAAAAEgAK8AgAAAB2tAUAAgoAADMAC/ASAAAAgQH+y5gAvwEQABAA/wEAAAgAAAAP8BAA AAAKAgAAKQwAANwCAAAqDAAADwAE8EIAAAASAArwCAAAAHe0BQACCgAAMwAL8BIAAACBAf7LmAC/ ARAAEAD/AQAACAAAAA/wEAAAAAoCAAAqDAAA3AIAACwMAAAPAATwQgAAABIACvAIAAAAeLQFAAIK AAAzAAvwEgAAAIEB/8yZAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAACwMAADcAgAALgwAAA8ABPBC AAAAEgAK8AgAAAB5tAUAAgoAADMAC/ASAAAAgQH/zJkAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA LgwAANwCAAAwDAAADwAE8EIAAAASAArwCAAAAHq0BQACCgAAMwAL8BIAAACBAf7LmAC/ARAAEAD/ AQAACAAAAA/wEAAAAAoCAAAwDAAA3AIAADEMAAAPAATwQgAAABIACvAIAAAAe7QFAAIKAAAzAAvw EgAAAIEB/suYAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAADEMAADcAgAAMwwAAA8ABPBCAAAAEgAK 8AgAAAB8tAUAAgoAADMAC/ASAAAAgQH9ypgAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAMwwAANwC AAA1DAAADwAE8EIAAAASAArwCAAAAH20BQACCgAAMwAL8BIAAACBAf3KlwC/ARAAEAD/AQAACAAA AA/wEAAAAAoCAAA1DAAA3AIAADYMAAAPAATwQgAAABIACvAIAAAAfrQFAAIKAAAzAAvwEgAAAIEB /MqXAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAADYMAADcAgAAOAwAAA8ABPBCAAAAEgAK8AgAAAB/ tAUAAgoAADMAC/ASAAAAgQH7yZcAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAOAwAANwCAAA6DAAA DwAE8EIAAAASAArwCAAAAIC0BQACCgAAMwAL8BIAAACBAfvIlgC/ARAAEAD/AQAACAAAAA/wEAAA AAoCAAA6DAAA3AIAADwMAAAPAATwQgAAABIACvAIAAAAgbQFAAIKAAAzAAvwEgAAAIEB+siWAL8B EAAQAP8BAAAIAAAAD/AQAAAACgIAADwMAADcAgAAPQwAAA8ABPBCAAAAEgAK8AgAAACCtAUAAgoA ADMAC/ASAAAAgQH5x5UAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAPQwAANwCAAA/DAAADwAE8EIA AAASAArwCAAAAIO0BQACCgAAMwAL8BIAAACBAfjGlQC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAA/ DAAA3AIAAEEMAAAPAATwQgAAABIACvAIAAAAhLQFAAIKAAAzAAvwEgAAAIEB98WUAL8BEAAQAP8B AAAIAAAAD/AQAAAACgIAAEEMAADcAgAAQgwAAA8ABPBCAAAAEgAK8AgAAACFtAUAAgoAADMAC/AS AAAAgQH1xJMAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAQgwAANwCAABEDAAADwAE8EIAAAASAArw CAAAAIa0BQACCgAAMwAL8BIAAACBAfTDkgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABEDAAA3AIA AEYMAAAPAATwQgAAABIACvAIAAAAh7QFAAIKAAAzAAvwEgAAAIEB88KRAL8BEAAQAP8BAAAIAAAA D/AQAAAACgIAAEYMAADcAgAARwwAAA8ABPBCAAAAEgAK8AgAAACItAUAAgoAADMAC/ASAAAAgQHx wZAAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAARwwAANwCAABJDAAADwAE8EIAAAASAArwCAAAAIm0 BQACCgAAMwAL8BIAAACBAe+/jwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABJDAAA3AIAAEsMAAAP AATwQgAAABIACvAIAAAAirQFAAIKAAAzAAvwEgAAAIEB7r6OAL8BEAAQAP8BAAAIAAAAD/AQAAAA CgIAAEsMAADcAgAATQwAAA8ABPBCAAAAEgAK8AgAAACLtAUAAgoAADMAC/ASAAAAgQHsvI0AvwEQ ABAA/wEAAAgAAAAP8BAAAAAKAgAATQwAANwCAABODAAADwAE8EIAAAASAArwCAAAAIy0BQACCgAA MwAL8BIAAACBAeq7jAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABODAAA3AIAAFAMAAAPAATwQgAA ABIACvAIAAAAjbQFAAIKAAAzAAvwEgAAAIEB57mLAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAFAM AADcAgAAUgwAAA8ABPBCAAAAEgAK8AgAAACOtAUAAgoAADMAC/ASAAAAgQHlt4kAvwEQABAA/wEA AAgAAAAP8BAAAAAKAgAAUgwAANwCAABTDAAADwAE8EIAAAASAArwCAAAAI+0BQACCgAAMwAL8BIA AACBAeO1iAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABTDAAA3AIAAFUMAAAPAATwQgAAABIACvAI AAAAkLQFAAIKAAAzAAvwEgAAAIEB4bOHAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAFUMAADcAgAA VwwAAA8ABPBCAAAAEgAK8AgAAACRtAUAAgoAADMAC/ASAAAAgQHesYUAvwEQABAA/wEAAAgAAAAP 8BAAAAAKAgAAVwwAANwCAABZDAAADwAE8EIAAAASAArwCAAAAJK0BQACCgAAMwAL8BIAAACBAduv gwC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAABZDAAA3AIAAFoMAAAPAATwQgAAABIACvAIAAAAk7QF AAIKAAAzAAvwEgAAAIEB2a2CAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAFoMAADcAgAAXAwAAA8A BPBCAAAAEgAK8AgAAACUtAUAAgoAADMAC/ASAAAAgQHWq4AAvwEQABAA/wEAAAgAAAAP8BAAAAAK AgAAXAwAANwCAABeDAAADwAE8EIAAAASAArwCAAAAJW0BQACCgAAMwAL8BIAAACBAdSpfwC/ARAA EAD/AQAACAAAAA/wEAAAAAoCAABeDAAA3AIAAF8MAAAPAATwQgAAABIACvAIAAAAlrQFAAIKAAAz AAvwEgAAAIEB0ad9AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAF8MAADcAgAAYQwAAA8ABPBCAAAA EgAK8AgAAACXtAUAAgoAADMAC/ASAAAAgQHPpXwAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAYQwA ANwCAABjDAAADwAE8EIAAAASAArwCAAAAJi0BQACCgAAMwAL8BIAAACBAcyjegC/ARAAEAD/AQAA CAAAAA/wEAAAAAoCAABjDAAA3AIAAGUMAAAPAATwQgAAABIACvAIAAAAmbQFAAIKAAAzAAvwEgAA AIEByqF5AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAGUMAADcAgAAZgwAAA8ABPBCAAAAEgAK8AgA AACatAUAAgoAADMAC/ASAAAAgQHIn3gAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAZgwAANwCAABo DAAADwAE8EIAAAASAArwCAAAAJu0BQACCgAAMwAL8BIAAACBAcWedgC/ARAAEAD/AQAACAAAAA/w EAAAAAoCAABoDAAA3AIAAGoMAAAPAATwQgAAABIACvAIAAAAnLQFAAIKAAAzAAvwEgAAAIEBw5x1 AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAGoMAADcAgAAawwAAA8ABPBCAAAAEgAK8AgAAACdtAUA AgoAADMAC/ASAAAAgQHBmnQAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAawwAANwCAABtDAAADwAE 8EIAAAASAArwCAAAAJ60BQACCgAAMwAL8BIAAACBAcCZcwC/ARAAEAD/AQAACAAAAA/wEAAAAAoC AABtDAAA3AIAAG8MAAAPAATwQgAAABIACvAIAAAAn7QFAAIKAAAzAAvwEgAAAIEBvpdyAL8BEAAQ AP8BAAAIAAAAD/AQAAAACgIAAG8MAADcAgAAcAwAAA8ABPBCAAAAEgAK8AgAAACgtAUAAgoAADMA C/ASAAAAgQG8lnEAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAcAwAANwCAAByDAAADwAE8EIAAAAS AArwCAAAAKG0BQACCgAAMwAL8BIAAACBAbuVcAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAByDAAA 3AIAAHQMAAAPAATwQgAAABIACvAIAAAAorQFAAIKAAAzAAvwEgAAAIEBuZRvAL8BEAAQAP8BAAAI AAAAD/AQAAAACgIAAHQMAADcAgAAdgwAAA8ABPBCAAAAEgAK8AgAAACjtAUAAgoAADMAC/ASAAAA gQG4k24AvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAdgwAANwCAAB3DAAADwAE8EIAAAASAArwCAAA AKS0BQACCgAAMwAL8BIAAACBAbeSbgC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAB3DAAA3AIAAHkM AAAPAATwQgAAABIACvAIAAAApbQFAAIKAAAzAAvwEgAAAIEBtpFtAL8BEAAQAP8BAAAIAAAAD/AQ AAAACgIAAHkMAADcAgAAewwAAA8ABPBCAAAAEgAK8AgAAACmtAUAAgoAADMAC/ASAAAAgQG1kG0A vwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAewwAANwCAAB8DAAADwAE8EIAAAASAArwCAAAAKe0BQAC CgAAMwAL8BIAAACBAbSQbAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAAB8DAAA3AIAAH4MAAAPAATw QgAAABIACvAIAAAAqLQFAAIKAAAzAAvwEgAAAIEBs49sAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIA AH4MAADcAgAAgAwAAA8ABPBCAAAAEgAK8AgAAACptAUAAgoAADMAC/ASAAAAgQGzjmsAvwEQABAA /wEAAAgAAAAP8BAAAAAKAgAAgAwAANwCAACCDAAADwAE8EIAAAASAArwCAAAAKq0BQACCgAAMwAL 8BIAAACBAbKOawC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAACCDAAA3AIAAIMMAAAPAATwQgAAABIA CvAIAAAAq7QFAAIKAAAzAAvwEgAAAIEBso5rAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAIMMAADc AgAAhQwAAA8ABPBCAAAAEgAK8AgAAACstAUAAgoAADMAC/ASAAAAvwEAABAAywFpKwAA/wEIAAgA AAAP8BAAAAAKAgAA1wsAAN0CAACGDAAADwAD8GIWAAAPAATwTgAAAAEACfAQAAAAGwIAAOcLAADM AgAAZQwAAAIACvAIAAAArbQFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAGwIAAOcLAADMAgAA ZQwAAA8AA/C6FQAADwAE8E4AAAABAAnwEAAAABsCAADnCwAAywIAAGUMAAACAArwCAAAAK60BQAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAABsCAADnCwAAywIAAGUMAAAPAATwQgAAABIACvAIAAAA r7QFAAIKAAAzAAvwEgAAAIEBkZG1AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAOcLAADLAgAA6QsA AA8ABPBCAAAAEgAK8AgAAACwtAUAAgoAADMAC/ASAAAAgQGRkbUAvwEQABAA/wEAAAgAAAAP8BAA AAAbAgAA6QsAAMsCAADqCwAADwAE8EIAAAASAArwCAAAALG0BQACCgAAMwAL8BIAAACBAZGRtQC/ ARAAEAD/AQAACAAAAA/wEAAAABsCAADqCwAAywIAAOwLAAAPAATwQgAAABIACvAIAAAAsrQFAAIK AAAzAAvwEgAAAIEBkZG2AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAOwLAADLAgAA7gsAAA8ABPBC AAAAEgAK8AgAAACztAUAAgoAADMAC/ASAAAAgQGSkrYAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA 7gsAAMsCAADwCwAADwAE8EIAAAASAArwCAAAALS0BQACCgAAMwAL8BIAAACBAZKStwC/ARAAEAD/ AQAACAAAAA/wEAAAABsCAADwCwAAywIAAPELAAAPAATwQgAAABIACvAIAAAAtbQFAAIKAAAzAAvw EgAAAIEBkpK3AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAPELAADLAgAA8wsAAA8ABPBCAAAAEgAK 8AgAAAC2tAUAAgoAADMAC/ASAAAAgQGTk7gAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA8wsAAMsC AAD1CwAADwAE8EIAAAASAArwCAAAALe0BQACCgAAMwAL8BIAAACBAZOTuAC/ARAAEAD/AQAACAAA AA/wEAAAABsCAAD1CwAAywIAAPYLAAAPAATwQgAAABIACvAIAAAAuLQFAAIKAAAzAAvwEgAAAIEB lJS5AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAPYLAADLAgAA+AsAAA8ABPBCAAAAEgAK8AgAAAC5 tAUAAgoAADMAC/ASAAAAgQGUlLkAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA+AsAAMsCAAD6CwAA DwAE8EIAAAASAArwCAAAALq0BQACCgAAMwAL8BIAAACBAZWVugC/ARAAEAD/AQAACAAAAA/wEAAA ABsCAAD6CwAAywIAAPwLAAAPAATwQgAAABIACvAIAAAAu7QFAAIKAAAzAAvwEgAAAIEBlpa7AL8B EAAQAP8BAAAIAAAAD/AQAAAAGwIAAPwLAADLAgAA/QsAAA8ABPBCAAAAEgAK8AgAAAC8tAUAAgoA ADMAC/ASAAAAgQGWlrwAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA/QsAAMsCAAD/CwAADwAE8EIA AAASAArwCAAAAL20BQACCgAAMwAL8BIAAACBAZeXvQC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAD/ CwAAywIAAAEMAAAPAATwQgAAABIACvAIAAAAvrQFAAIKAAAzAAvwEgAAAIEBmJi9AL8BEAAQAP8B AAAIAAAAD/AQAAAAGwIAAAEMAADLAgAAAgwAAA8ABPBCAAAAEgAK8AgAAAC/tAUAAgoAADMAC/AS AAAAgQGZmb8AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAAgwAAMsCAAAEDAAADwAE8EIAAAASAArw CAAAAMC0BQACCgAAMwAL8BIAAACBAZmZwAC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAEDAAAywIA AAYMAAAPAATwQgAAABIACvAIAAAAwbQFAAIKAAAzAAvwEgAAAIEBmprBAL8BEAAQAP8BAAAIAAAA D/AQAAAAGwIAAAYMAADLAgAABwwAAA8ABPBCAAAAEgAK8AgAAADCtAUAAgoAADMAC/ASAAAAgQGb m8IAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAABwwAAMsCAAAJDAAADwAE8EIAAAASAArwCAAAAMO0 BQACCgAAMwAL8BIAAACBAZycwwC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAJDAAAywIAAAsMAAAP AATwQgAAABIACvAIAAAAxLQFAAIKAAAzAAvwEgAAAIEBnZ3EAL8BEAAQAP8BAAAIAAAAD/AQAAAA GwIAAAsMAADLAgAADQwAAA8ABPBCAAAAEgAK8AgAAADFtAUAAgoAADMAC/ASAAAAgQGensYAvwEQ ABAA/wEAAAgAAAAP8BAAAAAbAgAADQwAAMsCAAAODAAADwAE8EIAAAASAArwCAAAAMa0BQACCgAA MwAL8BIAAACBAZ+fxwC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAODAAAywIAABAMAAAPAATwQgAA ABIACvAIAAAAx7QFAAIKAAAzAAvwEgAAAIEBoaHJAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAABAM AADLAgAAEgwAAA8ABPBCAAAAEgAK8AgAAADItAUAAgoAADMAC/ASAAAAgQGiosoAvwEQABAA/wEA AAgAAAAP8BAAAAAbAgAAEgwAAMsCAAATDAAADwAE8EIAAAASAArwCAAAAMm0BQACCgAAMwAL8BIA AACBAaOjzAC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAATDAAAywIAABUMAAAPAATwQgAAABIACvAI AAAAyrQFAAIKAAAzAAvwEgAAAIEBpKTNAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAABUMAADLAgAA FwwAAA8ABPBCAAAAEgAK8AgAAADLtAUAAgoAADMAC/ASAAAAgQGmps8AvwEQABAA/wEAAAgAAAAP 8BAAAAAbAgAAFwwAAMsCAAAZDAAADwAE8EIAAAASAArwCAAAAMy0BQACCgAAMwAL8BIAAACBAaen 0AC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAZDAAAywIAABoMAAAPAATwQgAAABIACvAIAAAAzbQF AAIKAAAzAAvwEgAAAIEBqKjSAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAABoMAADLAgAAHAwAAA8A BPBCAAAAEgAK8AgAAADOtAUAAgoAADMAC/ASAAAAgQGpqdQAvwEQABAA/wEAAAgAAAAP8BAAAAAb AgAAHAwAAMsCAAAeDAAADwAE8EIAAAASAArwCAAAAM+0BQACCgAAMwAL8BIAAACBAaur1gC/ARAA EAD/AQAACAAAAA/wEAAAABsCAAAeDAAAywIAAB8MAAAPAATwQgAAABIACvAIAAAA0LQFAAIKAAAz AAvwEgAAAIEBrKzXAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAB8MAADLAgAAIQwAAA8ABPBCAAAA EgAK8AgAAADRtAUAAgoAADMAC/ASAAAAgQGurtkAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAIQwA AMsCAAAjDAAADwAE8EIAAAASAArwCAAAANK0BQACCgAAMwAL8BIAAACBAa+v2gC/ARAAEAD/AQAA CAAAAA/wEAAAABsCAAAjDAAAywIAACUMAAAPAATwQgAAABIACvAIAAAA07QFAAIKAAAzAAvwEgAA AIEBsLDcAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAACUMAADLAgAAJgwAAA8ABPBCAAAAEgAK8AgA AADUtAUAAgoAADMAC/ASAAAAgQGxsd4AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAJgwAAMsCAAAo DAAADwAE8EIAAAASAArwCAAAANW0BQACCgAAMwAL8BIAAACBAbOz4AC/ARAAEAD/AQAACAAAAA/w EAAAABsCAAAoDAAAywIAACoMAAAPAATwQgAAABIACvAIAAAA1rQFAAIKAAAzAAvwEgAAAIEBtLTh AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAACoMAADLAgAAKwwAAA8ABPBCAAAAEgAK8AgAAADXtAUA AgoAADMAC/ASAAAAgQG2tuMAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAKwwAAMsCAAAtDAAADwAE 8EIAAAASAArwCAAAANi0BQACCgAAMwAL8BIAAACBAbe35AC/ARAAEAD/AQAACAAAAA/wEAAAABsC AAAtDAAAywIAAC8MAAAPAATwQgAAABIACvAIAAAA2bQFAAIKAAAzAAvwEgAAAIEBuLjmAL8BEAAQ AP8BAAAIAAAAD/AQAAAAGwIAAC8MAADLAgAAMAwAAA8ABPBCAAAAEgAK8AgAAADatAUAAgoAADMA C/ASAAAAgQG5uecAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAMAwAAMsCAAAyDAAADwAE8EIAAAAS AArwCAAAANu0BQACCgAAMwAL8BIAAACBAbq66QC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAAyDAAA ywIAADQMAAAPAATwQgAAABIACvAIAAAA3LQFAAIKAAAzAAvwEgAAAIEBu7vqAL8BEAAQAP8BAAAI AAAAD/AQAAAAGwIAADQMAADLAgAANgwAAA8ABPBCAAAAEgAK8AgAAADdtAUAAgoAADMAC/ASAAAA gQG8vOsAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAANgwAAMsCAAA3DAAADwAE8EIAAAASAArwCAAA AN60BQACCgAAMwAL8BIAAACBAb6+7QC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAA3DAAAywIAADkM AAAPAATwQgAAABIACvAIAAAA37QFAAIKAAAzAAvwEgAAAIEBvr7uAL8BEAAQAP8BAAAIAAAAD/AQ AAAAGwIAADkMAADLAgAAOwwAAA8ABPBCAAAAEgAK8AgAAADgtAUAAgoAADMAC/ASAAAAgQHAwO8A vwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAOwwAAMsCAAA8DAAADwAE8EIAAAASAArwCAAAAOG0BQAC CgAAMwAL8BIAAACBAcDA8QC/ARAAEAD/AQAACAAAAA/wEAAAABsCAAA8DAAAywIAAD4MAAAPAATw QgAAABIACvAIAAAA4rQFAAIKAAAzAAvwEgAAAIEBwcHyAL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIA AD4MAADLAgAAQAwAAA8ABPBCAAAAEgAK8AgAAADjtAUAAgoAADMAC/ASAAAAgQHCwvMAvwEQABAA /wEAAAgAAAAP8BAAAAAbAgAAQAwAAMsCAABCDAAADwAE8EIAAAASAArwCAAAAOS0BQACCgAAMwAL 8BIAAACBAcPD9AC/ARAAEAD/AQAACAAAAA/wEAAAABsCAABCDAAAywIAAEMMAAAPAATwQgAAABIA CvAIAAAA5bQFAAIKAAAzAAvwEgAAAIEBxMT1AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAEMMAADL AgAARQwAAA8ABPBCAAAAEgAK8AgAAADmtAUAAgoAADMAC/ASAAAAgQHFxfYAvwEQABAA/wEAAAgA AAAP8BAAAAAbAgAARQwAAMsCAABHDAAADwAE8EIAAAASAArwCAAAAOe0BQACCgAAMwAL8BIAAACB AcXF9wC/ARAAEAD/AQAACAAAAA/wEAAAABsCAABHDAAAywIAAEgMAAAPAATwQgAAABIACvAIAAAA 6LQFAAIKAAAzAAvwEgAAAIEBxsb3AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAEgMAADLAgAASgwA AA8ABPBCAAAAEgAK8AgAAADptAUAAgoAADMAC/ASAAAAgQHGxvgAvwEQABAA/wEAAAgAAAAP8BAA AAAbAgAASgwAAMsCAABMDAAADwAE8EIAAAASAArwCAAAAOq0BQACCgAAMwAL8BIAAACBAcfH+QC/ ARAAEAD/AQAACAAAAA/wEAAAABsCAABMDAAAywIAAE0MAAAPAATwQgAAABIACvAIAAAA67QFAAIK AAAzAAvwEgAAAIEBx8f5AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAE0MAADLAgAATwwAAA8ABPBC AAAAEgAK8AgAAADstAUAAgoAADMAC/ASAAAAgQHIyPoAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAA TwwAAMsCAABRDAAADwAE8EIAAAASAArwCAAAAO20BQACCgAAMwAL8BIAAACBAcjI+wC/ARAAEAD/ AQAACAAAAA/wEAAAABsCAABRDAAAywIAAFMMAAAPAATwQgAAABIACvAIAAAA7rQFAAIKAAAzAAvw EgAAAIEBycn7AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAFMMAADLAgAAVAwAAA8ABPBCAAAAEgAK 8AgAAADvtAUAAgoAADMAC/ASAAAAgQHJyfwAvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAVAwAAMsC AABWDAAADwAE8EIAAAASAArwCAAAAPC0BQACCgAAMwAL8BIAAACBAcrK/AC/ARAAEAD/AQAACAAA AA/wEAAAABsCAABWDAAAywIAAFgMAAAPAATwQgAAABIACvAIAAAA8bQFAAIKAAAzAAvwEgAAAIEB ysr9AL8BEAAQAP8BAAAIAAAAD/AQAAAAGwIAAFgMAADLAgAAWQwAAA8ABPBCAAAAEgAK8AgAAADy tAUAAgoAADMAC/ASAAAAgQHKyv0AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAWQwAAMsCAABbDAAA DwAE8EIAAAASAArwCAAAAPO0BQACCgAAMwAL8BIAAACBAcvL/QC/ARAAEAD/AQAACAAAAA/wEAAA ABsCAABbDAAAywIAAF0MAAAPAATwQgAAABIACvAIAAAA9LQFAAIKAAAzAAvwEgAAAIEBy8v+AL8B EAAQAP8BAAAIAAAAD/AQAAAAGwIAAF0MAADLAgAAXwwAAA8ABPBCAAAAEgAK8AgAAAD1tAUAAgoA ADMAC/ASAAAAgQHLy/4AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAXwwAAMsCAABgDAAADwAE8EIA AAASAArwCAAAAPa0BQACCgAAMwAL8BIAAACBAcvL/gC/ARAAEAD/AQAACAAAAA/wEAAAABsCAABg DAAAywIAAGIMAAAPAATwQgAAABIACvAIAAAA97QFAAIKAAAzAAvwEgAAAIEBy8v+AL8BEAAQAP8B AAAIAAAAD/AQAAAAGwIAAGIMAADLAgAAZAwAAA8ABPBCAAAAEgAK8AgAAAD4tAUAAgoAADMAC/AS AAAAgQHMzP8AvwEQABAA/wEAAAgAAAAP8BAAAAAbAgAAZAwAAMsCAABlDAAADwAE8EIAAAASAArw CAAAAPm0BQACCgAAMwAL8BIAAAC/AQAAEADLAWkrAAD/AQgACAAAAA/wEAAAABsCAADnCwAAzAIA AGUMAAAPAAPwDBIAAA8ABPBOAAAAAQAJ8BAAAAA7AgAAmwwAAKsCAAC3DAAAAgAK8AgAAAD6tAUA AwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAA7AgAAmwwAAKsCAAC3DAAADwAD8GQRAAAPAATwTgAA AAEACfAQAAAAOwIAAJsMAACqAgAAtgwAAAIACvAIAAAA+7QFAAMCAAATAAvwBgAAAIgDAAAAAAAA D/AQAAAAOwIAAJsMAACqAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAD8tAUAAgoAADMAC/ASAAAAgQGy jmsAvwEQABAA/wEAAAgAAAAP8BAAAAA7AgAAmwwAAD0CAAC2DAAADwAE8EIAAAASAArwCAAAAP20 BQACCgAAMwAL8BIAAACBAbOPawC/ARAAEAD/AQAACAAAAA/wEAAAAD0CAACbDAAAPwIAALYMAAAP AATwQgAAABIACvAIAAAA/rQFAAIKAAAzAAvwEgAAAIEBtI9sAL8BEAAQAP8BAAAIAAAAD/AQAAAA PwIAAJsMAABBAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAD/tAUAAgoAADMAC/ASAAAAgQG1kW0AvwEQ ABAA/wEAAAgAAAAP8BAAAABBAgAAmwwAAEMCAAC2DAAADwAE8EIAAAASAArwCAAAAAC1BQACCgAA MwAL8BIAAACBAbeSbgC/ARAAEAD/AQAACAAAAA/wEAAAAEMCAACbDAAARQIAALYMAAAPAATwQgAA ABIACvAIAAAAAbUFAAIKAAAzAAvwEgAAAIEBuZRvAL8BEAAQAP8BAAAIAAAAD/AQAAAARQIAAJsM AABHAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAACtQUAAgoAADMAC/ASAAAAgQG8lnEAvwEQABAA/wEA AAgAAAAP8BAAAABHAgAAmwwAAEgCAAC2DAAADwAE8EIAAAASAArwCAAAAAO1BQACCgAAMwAL8BIA AACBAb+YcgC/ARAAEAD/AQAACAAAAA/wEAAAAEgCAACbDAAASgIAALYMAAAPAATwQgAAABIACvAI AAAABLUFAAIKAAAzAAvwEgAAAIEBwpt0AL8BEAAQAP8BAAAIAAAAD/AQAAAASgIAAJsMAABMAgAA tgwAAA8ABPBCAAAAEgAK8AgAAAAFtQUAAgoAADMAC/ASAAAAgQHFnnYAvwEQABAA/wEAAAgAAAAP 8BAAAABMAgAAmwwAAE4CAAC2DAAADwAE8EIAAAASAArwCAAAAAa1BQACCgAAMwAL8BIAAACBAcmh eQC/ARAAEAD/AQAACAAAAA/wEAAAAE4CAACbDAAAUAIAALYMAAAPAATwQgAAABIACvAIAAAAB7UF AAIKAAAzAAvwEgAAAIEBzaR7AL8BEAAQAP8BAAAIAAAAD/AQAAAAUAIAAJsMAABSAgAAtgwAAA8A BPBCAAAAEgAK8AgAAAAItQUAAgoAADMAC/ASAAAAgQHSp34AvwEQABAA/wEAAAgAAAAP8BAAAABS AgAAmwwAAFQCAAC2DAAADwAE8EIAAAASAArwCAAAAAm1BQACCgAAMwAL8BIAAACBAdargAC/ARAA EAD/AQAACAAAAA/wEAAAAFQCAACbDAAAVgIAALYMAAAPAATwQgAAABIACvAIAAAACrUFAAIKAAAz AAvwEgAAAIEB2q6DAL8BEAAQAP8BAAAIAAAAD/AQAAAAVgIAAJsMAABXAgAAtgwAAA8ABPBCAAAA EgAK8AgAAAALtQUAAgoAADMAC/ASAAAAgQHfsoUAvwEQABAA/wEAAAgAAAAP8BAAAABXAgAAmwwA AFkCAAC2DAAADwAE8EIAAAASAArwCAAAAAy1BQACCgAAMwAL8BIAAACBAeO1iAC/ARAAEAD/AQAA CAAAAA/wEAAAAFkCAACbDAAAWwIAALYMAAAPAATwQgAAABIACvAIAAAADbUFAAIKAAAzAAvwEgAA AIEB57iKAL8BEAAQAP8BAAAIAAAAD/AQAAAAWwIAAJsMAABdAgAAtgwAAA8ABPBCAAAAEgAK8AgA AAAOtQUAAgoAADMAC/ASAAAAgQHqu4wAvwEQABAA/wEAAAgAAAAP8BAAAABdAgAAmwwAAF8CAAC2 DAAADwAE8EIAAAASAArwCAAAAA+1BQACCgAAMwAL8BIAAACBAe6+jwC/ARAAEAD/AQAACAAAAA/w EAAAAF8CAACbDAAAYQIAALYMAAAPAATwQgAAABIACvAIAAAAELUFAAIKAAAzAAvwEgAAAIEB8cCQ AL8BEAAQAP8BAAAIAAAAD/AQAAAAYQIAAJsMAABjAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAARtQUA AgoAADMAC/ASAAAAgQH0w5IAvwEQABAA/wEAAAgAAAAP8BAAAABjAgAAmwwAAGUCAAC2DAAADwAE 8EIAAAASAArwCAAAABK1BQACCgAAMwAL8BIAAACBAfbFkwC/ARAAEAD/AQAACAAAAA/wEAAAAGUC AACbDAAAZgIAALYMAAAPAATwQgAAABIACvAIAAAAE7UFAAIKAAAzAAvwEgAAAIEB+MaVAL8BEAAQ AP8BAAAIAAAAD/AQAAAAZgIAAJsMAABoAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAUtQUAAgoAADMA C/ASAAAAgQH6yJYAvwEQABAA/wEAAAgAAAAP8BAAAABoAgAAmwwAAGoCAAC2DAAADwAE8EIAAAAS AArwCAAAABW1BQACCgAAMwAL8BIAAACBAfvJlwC/ARAAEAD/AQAACAAAAA/wEAAAAGoCAACbDAAA bAIAALYMAAAPAATwQgAAABIACvAIAAAAFrUFAAIKAAAzAAvwEgAAAIEB/MqXAL8BEAAQAP8BAAAI AAAAD/AQAAAAbAIAAJsMAABuAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAXtQUAAgoAADMAC/ASAAAA gQH9ypgAvwEQABAA/wEAAAgAAAAP8BAAAABuAgAAmwwAAHACAAC2DAAADwAE8EIAAAASAArwCAAA ABi1BQACCgAAMwAL8BIAAACBAf7LmAC/ARAAEAD/AQAACAAAAA/wEAAAAHACAACbDAAAcgIAALYM AAAPAATwQgAAABIACvAIAAAAGbUFAAIKAAAzAAvwEgAAAIEB/8yZAL8BEAAQAP8BAAAIAAAAD/AQ AAAAcgIAAJsMAAB0AgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAatQUAAgoAADMAC/ASAAAAgQH/zJkA vwEQABAA/wEAAAgAAAAP8BAAAAB0AgAAmwwAAHUCAAC2DAAADwAE8EIAAAASAArwCAAAABu1BQAC CgAAMwAL8BIAAACBAf3KmAC/ARAAEAD/AQAACAAAAA/wEAAAAHUCAACbDAAAdwIAALYMAAAPAATw QgAAABIACvAIAAAAHLUFAAIKAAAzAAvwEgAAAIEB/MqXAL8BEAAQAP8BAAAIAAAAD/AQAAAAdwIA AJsMAAB5AgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAdtQUAAgoAADMAC/ASAAAAgQH7yZcAvwEQABAA /wEAAAgAAAAP8BAAAAB5AgAAmwwAAHsCAAC2DAAADwAE8EIAAAASAArwCAAAAB61BQACCgAAMwAL 8BIAAACBAfrIlgC/ARAAEAD/AQAACAAAAA/wEAAAAHsCAACbDAAAfQIAALYMAAAPAATwQgAAABIA CvAIAAAAH7UFAAIKAAAzAAvwEgAAAIEB+MaVAL8BEAAQAP8BAAAIAAAAD/AQAAAAfQIAAJsMAAB/ AgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAgtQUAAgoAADMAC/ASAAAAgQH2xZMAvwEQABAA/wEAAAgA AAAP8BAAAAB/AgAAmwwAAIECAAC2DAAADwAE8EIAAAASAArwCAAAACG1BQACCgAAMwAL8BIAAACB AfTDkgC/ARAAEAD/AQAACAAAAA/wEAAAAIECAACbDAAAggIAALYMAAAPAATwQgAAABIACvAIAAAA IrUFAAIKAAAzAAvwEgAAAIEB8cCQAL8BEAAQAP8BAAAIAAAAD/AQAAAAggIAAJsMAACEAgAAtgwA AA8ABPBCAAAAEgAK8AgAAAAjtQUAAgoAADMAC/ASAAAAgQHuvo8AvwEQABAA/wEAAAgAAAAP8BAA AACEAgAAmwwAAIYCAAC2DAAADwAE8EIAAAASAArwCAAAACS1BQACCgAAMwAL8BIAAACBAeq7jAC/ ARAAEAD/AQAACAAAAA/wEAAAAIYCAACbDAAAiAIAALYMAAAPAATwQgAAABIACvAIAAAAJbUFAAIK AAAzAAvwEgAAAIEB57iKAL8BEAAQAP8BAAAIAAAAD/AQAAAAiAIAAJsMAACKAgAAtgwAAA8ABPBC AAAAEgAK8AgAAAAmtQUAAgoAADMAC/ASAAAAgQHjtYgAvwEQABAA/wEAAAgAAAAP8BAAAACKAgAA mwwAAIwCAAC2DAAADwAE8EIAAAASAArwCAAAACe1BQACCgAAMwAL8BIAAACBAd+yhQC/ARAAEAD/ AQAACAAAAA/wEAAAAIwCAACbDAAAjgIAALYMAAAPAATwQgAAABIACvAIAAAAKLUFAAIKAAAzAAvw EgAAAIEB2q6DAL8BEAAQAP8BAAAIAAAAD/AQAAAAjgIAAJsMAACQAgAAtgwAAA8ABPBCAAAAEgAK 8AgAAAAptQUAAgoAADMAC/ASAAAAgQHWq4AAvwEQABAA/wEAAAgAAAAP8BAAAACQAgAAmwwAAJEC AAC2DAAADwAE8EIAAAASAArwCAAAACq1BQACCgAAMwAL8BIAAACBAdKnfgC/ARAAEAD/AQAACAAA AA/wEAAAAJECAACbDAAAkwIAALYMAAAPAATwQgAAABIACvAIAAAAK7UFAAIKAAAzAAvwEgAAAIEB zaR7AL8BEAAQAP8BAAAIAAAAD/AQAAAAkwIAAJsMAACVAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAs tQUAAgoAADMAC/ASAAAAgQHJoXkAvwEQABAA/wEAAAgAAAAP8BAAAACVAgAAmwwAAJcCAAC2DAAA DwAE8EIAAAASAArwCAAAAC21BQACCgAAMwAL8BIAAACBAcWedgC/ARAAEAD/AQAACAAAAA/wEAAA AJcCAACbDAAAmQIAALYMAAAPAATwQgAAABIACvAIAAAALrUFAAIKAAAzAAvwEgAAAIEBwpt0AL8B EAAQAP8BAAAIAAAAD/AQAAAAmQIAAJsMAACbAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAvtQUAAgoA ADMAC/ASAAAAgQG/mHIAvwEQABAA/wEAAAgAAAAP8BAAAACbAgAAmwwAAJ0CAAC2DAAADwAE8EIA AAASAArwCAAAADC1BQACCgAAMwAL8BIAAACBAbyWcQC/ARAAEAD/AQAACAAAAA/wEAAAAJ0CAACb DAAAnwIAALYMAAAPAATwQgAAABIACvAIAAAAMbUFAAIKAAAzAAvwEgAAAIEBuZRvAL8BEAAQAP8B AAAIAAAAD/AQAAAAnwIAAJsMAACgAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAAytQUAAgoAADMAC/AS AAAAgQG3km4AvwEQABAA/wEAAAgAAAAP8BAAAACgAgAAmwwAAKICAAC2DAAADwAE8EIAAAASAArw CAAAADO1BQACCgAAMwAL8BIAAACBAbWRbQC/ARAAEAD/AQAACAAAAA/wEAAAAKICAACbDAAApAIA ALYMAAAPAATwQgAAABIACvAIAAAANLUFAAIKAAAzAAvwEgAAAIEBtI9sAL8BEAAQAP8BAAAIAAAA D/AQAAAApAIAAJsMAACmAgAAtgwAAA8ABPBCAAAAEgAK8AgAAAA1tQUAAgoAADMAC/ASAAAAgQGz j2sAvwEQABAA/wEAAAgAAAAP8BAAAACmAgAAmwwAAKgCAAC2DAAADwAE8EIAAAASAArwCAAAADa1 BQACCgAAMwAL8BIAAACBAbKOawC/ARAAEAD/AQAACAAAAA/wEAAAAKgCAACbDAAAqgIAALYMAAAP AATwQgAAABIACvAIAAAAN7UFAAIKAAAzAAvwEgAAAL8BAAAQAMsBaSsAAP8BCAAIAAAAD/AQAAAA OwIAAJsMAACrAgAAtwwAAA8AA/BMBgAADwAE8E4AAAABAAnwEAAAAAoCAACsDAAA3QIAAMgMAAAC AArwCAAAADi1BQADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAAoCAACsDAAA3QIAAMgMAAAPAAPw ngUAAA8ABPBOAAAAAQAJ8BAAAAAKAgAArAwAAN0CAADIDAAAAgAK8AgAAAA5tQUAAwIAABMAC/AG AAAAiAMAAAAAAAAP8BAAAAAKAgAArAwAAN0CAADIDAAADwAD8PYEAAAPAATwTgAAAAEACfAQAAAA CgIAAKwMAADcAgAAxwwAAAIACvAIAAAAOrUFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAACgIA AKwMAADcAgAAxwwAAA8ABPBCAAAAEgAK8AgAAAA7tQUAAgoAADMAC/ASAAAAgQGyjmsAvwEQABAA /wEAAAgAAAAP8BAAAAAKAgAArAwAANwCAACuDAAADwAE8EIAAAASAArwCAAAADy1BQACCgAAMwAL 8BIAAACBAbSQbAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAACuDAAA3AIAALAMAAAPAATwQgAAABIA CvAIAAAAPbUFAAIKAAAzAAvwEgAAAIEBuJNuAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAALAMAADc AgAAsQwAAA8ABPBCAAAAEgAK8AgAAAA+tQUAAgoAADMAC/ASAAAAgQG8lnEAvwEQABAA/wEAAAgA AAAP8BAAAAAKAgAAsQwAANwCAACzDAAADwAE8EIAAAASAArwCAAAAD+1BQACCgAAMwAL8BIAAACB AcKbdAC/ARAAEAD/AQAACAAAAA/wEAAAAAoCAACzDAAA3AIAALUMAAAPAATwQgAAABIACvAIAAAA QLUFAAIKAAAzAAvwEgAAAIEByaB5AL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAALUMAADcAgAAtgwA AA8ABPBCAAAAEgAK8AgAAABBtQUAAgoAADMAC/ASAAAAgQHRp30AvwEQABAA/wEAAAgAAAAP8BAA AAAKAgAAtgwAANwCAAC4DAAADwAE8EIAAAASAArwCAAAAEK1BQACCgAAMwAL8BIAAACBAdmtggC/ ARAAEAD/AQAACAAAAA/wEAAAAAoCAAC4DAAA3AIAALoMAAAPAATwQgAAABIACvAIAAAAQ7UFAAIK AAAzAAvwEgAAAIEB4bSHAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAALoMAADcAgAAvAwAAA8ABPBC AAAAEgAK8AgAAABEtQUAAgoAADMAC/ASAAAAgQHpuosAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAA vAwAANwCAAC9DAAADwAE8EIAAAASAArwCAAAAEW1BQACCgAAMwAL8BIAAACBAe+/jwC/ARAAEAD/ AQAACAAAAA/wEAAAAAoCAAC9DAAA3AIAAL8MAAAPAATwQgAAABIACvAIAAAARrUFAAIKAAAzAAvw EgAAAIEB9MOSAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAL8MAADcAgAAwQwAAA8ABPBCAAAAEgAK 8AgAAABHtQUAAgoAADMAC/ASAAAAgQH5x5UAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAwQwAANwC AADCDAAADwAE8EIAAAASAArwCAAAAEi1BQACCgAAMwAL8BIAAACBAfvJlwC/ARAAEAD/AQAACAAA AA/wEAAAAAoCAADCDAAA3AIAAMQMAAAPAATwQgAAABIACvAIAAAASbUFAAIKAAAzAAvwEgAAAIEB /cuYAL8BEAAQAP8BAAAIAAAAD/AQAAAACgIAAMQMAADcAgAAxgwAAA8ABPBCAAAAEgAK8AgAAABK tQUAAgoAADMAC/ASAAAAgQH/zJkAvwEQABAA/wEAAAgAAAAP8BAAAAAKAgAAxgwAANwCAADHDAAA DwAE8EIAAAASAArwCAAAAEu1BQACCgAAMwAL8BIAAAC/AQAAEADLAWkrAAD/AQgACAAAAA/wEAAA AAoCAACsDAAA3QIAAMgMAAAPAATwSAAAABIACvAIAAAATLUFAAIKAABDAAvwGAAAAIEBfGygAL8B EAAQAMsBaSsAAP8BCAAIAAAAD/AQAAAAnwIAALwMAADMAgAAyAwAAA8ABPDJAAAAogwK8AgAAABN tQUAAAoAAAMBC/BgAAAAgADQa+0EhQACAAAAhwAGAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4A wAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ 8AgAAABmBbgKoQyGBg8ADfA5AAAAAACfDwQAAAAEAAAAAACoDwMAAABCQVMAAKEPGgAAAAQAAAAA ABAACgAEAAcABAAAAAAAQQAEAAQADwAE8M4AAACiDArwCAAAAE61BQAACgAAAwEL8GAAAACAAOBu 7QSFAAIAAACHAAYAAAC/AAIADwCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AxAAPwCEAwAAAACGAwAAAAAAABDwCAAAAGYFrg9VE4YGDwAN8D4A AAAAAJ8PBAAAAAQAAAAAAKgPCAAAAEItUm91dGVyAAChDxoAAAAJAAAAAAAQAAoABAAHAAkAAAAA AEEABAAEAA8ABPDKAAAAogwK8AgAAABPtQUAAAoAAAMBC/BgAAAAgAB4c+0EhQACAAAAhwAGAAAA vwACAA8AgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIW AB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAABmBdoV+BeGBg8ADfA6AAAAAACfDwQAAAAEAAAA AACoDwQAAABIb3N0AAChDxoAAAAFAAAAAAAQAAoABAAHAAUAAAAAAEEABAAEAA8AA/DjAgAADwAE 8IAAAAABAAnwEAAAAAwEAAD2CAAAuAoAAIAKAAACAArwCAAAAFC1BQABAgAAIwAL8AwAAAAEAAAA AACIAwAAAAAAABDwCAAAAPYIYgSdC4AKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBEAAAA AAAAAAAAAAIAAQABCgAAAAAKMA8ABPCuAAAAQgEK8AgAAABRtQUAAgoAAFMBC/B+AAAAgQCQXwEA ggDQtgAAgwCQXwEAhADQtgAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAE5K3UAywE8 2AQA0AEBAAAA0QEBAAAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEeAB4AAQICAAAIPwIAAAMA fwMAAA8AAAAP8BAAAAAMBAAAZgkAALgKAABmCQAADwAE8OQAAACiDArwCAAAAFK1BQACCgAAEwEL 8GYAAACAANB37QSBAJBfAQCCANC2AACDAJBfAQCEANC2AACFAAIAAACHAAYAAAC/AAIADwCBAQAA AAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwAEAwkAAAB/AwAADwAAAA/wEAAA ALwFAAD2CAAAAwkAAPAJAAAPAA3wRgAAAAAAnw8EAAAABAAAAAAAqA8IAAAAUkFESVVTdjYAAKEP IgAAAAkAAAAAAAAgCgAUAAcACQAAAIAERwAABAQABAAUAAAAAAAPAATwsQAAAKIMCvAIAAAAU7UF AAIKAACjAAvwPAAAAIAAyHvtBIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAD/AQAAAATAYAAOYJAAD8BwAAgAoAAA8ADfA9AAAAAACfDwQAAAAE AAAAAACoDwcAAABSRkMzMTYyAAChDxoAAAAIAAAAAAAAAAoABwAIAAAAAABDAAQABAAKAA8AA/B6 AwAADwAE8IAAAAABAAnwEAAAALgKAADCCAAAKBAAAEYKAAACAArwCAAAAFS1BQABAgAAIwAL8AwA AAAEAAAAAACIAwAAAAAAABDwCAAAAMIInQuBEUYKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAA BwBEAAAAAAAAAAAAAAEAAQABCgAAAAAKMA8ABPCuAAAAQgEK8AgAAABVtQUAAgoAAFMBC/B+AAAA gQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAE5 K3UAywE82AQA0AEBAAAA0QEBAAAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEeAB4AAQICAAAI PwIAAAMAfwMAAA8AAAAP8BAAAAC4CgAALAkAACgQAAAsCQAADwAD8DQCAAAPAATwggAAAAEACfAQ AAAAogsAAMIIAACYDwAARgoAAAIACvAIAAAAVrUFAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAA ogsAAMIIAACYDwAARgoAAA8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAAB AAEAAAoDAAAACjAPAATw6QAAAKIMCvAIAAAAV7UFAAIKAAATAQvwZgAAAIAAwIDtBIEAkF8BAIIA 0LYAAIMAkF8BAIQA0LYAAIUAAgAAAIcABgAAAL8AAgAPAIEBAAAACIMBAAAACL8BDAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAAQDCQAAAH8DAAAPAAAAD/AQAAAAogsAAMIIAACYDwAAvAkAAA8A DfBLAAAAAACfDwQAAAAEAAAAAACoDwsAAABQUFAoSVBWNkNQKQAAoQ8kAAAADAAAAAAAACgKAAEA FAAHAAwAAACABEcAAAQEAAQAFAAAAAAADwAE8LEAAACiDArwCAAAAFi1BQACCgAAowAL8DwAAACA AJSF7QSFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA AAgAAA/wEAAAAJgMAACsCQAASA4AAEYKAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8HAAAAUkZD MjQ3MgAAoQ8aAAAACAAAAAAAAAAKAAcACAAAAAAAQwAEAAQACgAPAAPwZwMAAA8ABPCAAAAAAQAJ 8BAAAADICQAAdgoAAEYQAADsDAAAAgAK8AgAAABZtQUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAA AAAQ8AgAAAB2CpkKoRHsDA8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAAD AAEAAQoCAAAACjAPAATwrgAAAEIBCvAIAAAAWrUFAAIKAABTAQvwfgAAAIEAkF8BAIIA0LYAAIMA kF8BAIQA0LYAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABOSt1AMsBPNgEANABAQAA ANEBAQAAANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BHgAeAAECAgAACD8CAAADAH8DAAAPAAAA D/AQAAAAuAoAAOYKAAAoEAAA5goAAA8ABPDiAAAAogwK8AgAAABbtQUAAgoAABMBC/BmAAAAgACc iO0EgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAAhwAGAAAAvwACAA8AgQEAAAAIgwEAAAAI vwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMABAMJAAAAfwMAAA8AAAAP8BAAAAAcDAAAdgoA AMYOAABwCwAADwAN8EQAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAERIQ1B2NgAAoQ8iAAAABwAAAAAA ACAKABQABwAHAAAAgARHAAAEBAAEABQAAAAAAA8ABPA3AQAAogwK8AgAAABctQUAAgoAAKMAC/A8 AAAAgAA8jO0EhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAP8BAAAADICQAAkgsAAEYQAADsDAAADwAN8MMAAAAAAJ8PBAAAAAQAAAAAAKgPawAA AGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni0yNg1kcmFmdC10cm9hbi1kaGNwdjYtb3B0LXByZWZpeC1k ZWxlZ2F0aW9uLTAxDWRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1vcHQtZG5zY29uZmlnLTAyAAChDzwA AABsAAAAAAAACAoAAQAHABgAAAAAAEMABQAEAAoALQAAAAAAQwAEAAQACgAnAAAAAARjAIAEBAAG AAQACgAPAAPw6QIAAA8ABPCAAAAAAQAJ8BAAAAAoEAAAxgsAAPEUAABGDQAAAgAK8AgAAABdtQUA AQIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAADGC4ERsBZGDQ8AEfAsAAAADwAUECQAAAAB APEPHAAAAAAAAAcARAAAAAAAAAAAAAAEAAEAAQoCAAAACjAPAATwrgAAAEIBCvAIAAAAXrUFAAIK AABTAQvwfgAAAIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABOSt1AMsBPNgEANABAQAAANEBAQAAANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8B HgAeAAECAgAACD8CAAADAH8DAAAPAAAAD/AQAAAAKBAAADYMAADsFAAANgwAAA8ABPDqAAAAogwK 8AgAAABftQUAAgoAABMBC/BmAAAAgABkk+0EgQCQXwEAggDQtgAAgwCQXwEAhADQtgAAhQACAAAA hwAGAAAAvwACAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMABAMJ AAAAfwMAAA8AAAAP8BAAAAA8EAAAxgsAAPEUAADADAAADwAN8EwAAAAAAJ8PBAAAAAQAAAAAAKgP DgAAAFN0YXRlbGVzcyBBRERSAAChDyIAAAAPAAAAAAAAIAoAFAAHAA8AAACABEcAAAQEAAQAFAAA AAAADwAE8LEAAACiDArwCAAAAGC1BQACCgAAowAL8DwAAACAABCY7QSFAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAALwRAACsDAAAbBMA AEYNAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8HAAAAUkZDMjQ2MgAAoQ8aAAAACAAAAAAAAAAK AAcACAAAAAAAQwAEAAQACgAPAAPwEAMAAA8ABPCAAAAAAQAJ8BAAAAAoEAAARg0AAEwVAAAADwAA AgAK8AgAAABhtQUAAQIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAQ8AgAAABGDYEREhcADw8AEfAs AAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAAFAAEAAQoCAAAACjAPAATwrgAAAEIB CvAIAAAAYrUFAAIKAABTAQvwfgAAAIEAkF8BAIIA0LYAAIMAkF8BAIQA0LYAAIcAAQAAAL8AAAAP AEQBBAAAAH8BAAABAL8BAAAQAMABOSt1AMsBPNgEANABAQAAANEBAQAAANIBAAAAANMBAAAAANQB AAAAANUBAAAAAP8BHgAeAAECAgAACD8CAAADAH8DAAAPAAAAD/AQAAAAKBAAALYNAADsFAAAtg0A AA8ABPDlAAAAogwK8AgAAABjtQUAAgoAABMBC/BmAAAAgAA4m+0EgQCQXwEAggDQtgAAgwCQXwEA hADQtgAAhQACAAAAhwAGAAAAvwACAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQIC AAAIPwIAAAMABAMJAAAAfwMAAA8AAAAP8BAAAACcEAAARg0AAHEUAABADgAADwAN8EcAAAAAAJ8P BAAAAAQAAAAAAKgPCQAAAFdLU0xVIEROUwAAoQ8iAAAACgAAAAAAACAKABQABwAKAAAAgARHAAAE BAAEABQAAAAAAA8ABPDdAAAAogwK8AgAAABktQUAAgoAAKMAC/A8AAAAgACsn+0EhQACAAAAhwAG AAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAABnEAAA Zg4AAEwVAAAADwAADwAN8GkAAAAAAJ8PBAAAAAQAAAAAAKgPIQAAAGRyYWZ0LWlldGYtaXB2Ni1k bnMtZGlzY292ZXJ5LTA1IAAAoQ8sAAAAIgAAAAAAAAAKAAcAIAAAAAAAYwAEAAYABAAKAAIAAAAA BEMAgAQEAAQACgAPAATw7QAAACIACvAIAAAAZbUFAAAKAAADAQvwYAAAAIAAdKTtBIUAAgAAAIcA BgAAAL8AAgAPAIEB//9mAL8BHAAeAMABAQAACNYBAQAAAP8BDgAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DEAA/AIQDAAAAAIYDAAAAAAAAEPAIAAAA8whEAPMDMwoPAA3wXQAAAAAAnw8EAAAA BAAAAAAAqA8jAAAAQXV0aGVudGljYXRpb24gLw1MaW5rIEVzdGFibGlzaG1lbnQAAKEPHgAAACQA AAAAABAICgAEAAEABwAkAAAAAABDAAQABAAMAA8ABPAQAQAAIgAK8AgAAABmtQUAAAoAAAMBC/Bg AAAAgADQpe0EhQACAAAAhwAGAAAAvwACAA8AgQH//2YAvwEcAB4AwAEBAAAI1gEBAAAA/wEOAA4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ8AgAAAC+ClEAWgT+ Cw8ADfCAAAAAAACfDwQAAAAEAAAAAACgD0YAAABSAG8AdQB0AGUAcgAgAEMAbwBuAGYAaQBnAHUA cgBhAHQAaQBvAG4ADQAI/1AAcgBlAGYAaQB4ACAALwAgAEQATgBTAAn/AAChDx4AAAAkAAAAAAAQ CAoABAABAAcAJAAAAAAAQwAEAAQADAAPAATwAgEAACIACvAIAAAAZ7UFAAAKAADjAAvwVAAAAIAA gKjtBL8AAgAPAIEB//9mAL8BHAAeAMABAQAACNYBAQAAAP8BDgAOAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DEAA/AIQDAAAAAIYDAAAAAAAAEPAIAAAAkgxNADcE0g0PAA3wfgAAAAAAnw8EAAAA BAAAAAAAoA9EAAAASABvAHMAdAAgAEMAbwBuAGYAaQBnAHUAcgBhAHQAaQBvAG4ADQAI/0EAZABk AHIAZQBzAHMAIAAvACAARABOAFMACf8AAKEPHgAAACMAAAAAABAICgAEAAEABwAjAAAAAABDAAQA BAAMAA8ABPCOAAAAEgAK8AgAAABotQUAAAoAABMBC/BmAAAAgQCQXwEAggDQtgAAgwCQXwEAhADQ tgAAhQACAAAAhwABAAAAvwAAAA8AgQEAAAAIgwEAAAAIvwEMAB4AwAEBAAAIzgECAAAA1wEAAAAA /wEOAA4AAQICAAAIPwIAAAMAfwMAAA8AAAAQ8AgAAABwBaQP+BdACA8ABPDnAAAAogwK8AgAAABp tQUAAAoAAAMBC/BgAAAAgAD8su0EhQACAAAAhwAGAAAAvwACAA8AgQEEAAAIgwEAAAAIvwEMAB4A wAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMQAD8AhAMAAAAAhgMAAAAAAAAQ 8AgAAAB9Bm4NGA89Bw8ADfBXAAAAAACfDwQAAAAEAAAAAACoDwUAAABQUFBvRQAAoQ8cAAAABgAA AAAAEAAKAAQABwAGAAAAAABDAAQABAAOAAAAqg8SAAAABQAAAAEAAAADAAEAAAAAAAAADwAE8EgA AAASAArwCAAAAAG0BQAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAR5AlwCUAd69aAC/ARIAEgD/ AQAACAAEAwkAAAA/AwEAAQAvAAXwQAAAAAEAEvAYAAAAAQAAABO0BQAUtAUAD7QFAAMAAAABAAAA AQAS8BgAAAACAAAAFLQFAPm0BQAQtAUAAwAAAAEAAAAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIADwCIE/kPAAAPAIoT8Q8AAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixPRDwAAAAAAKwQAAADNM3f0HwBE8bUPAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAALkT AP////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAAHwBE8XAPAAAAACfxIAAAAAAAAAAAAAAAAQAA AAAAAAAAAAAAAAAAAP////8YAAAADwA98Q0AAABAAULxBQAAAAEEAAAAAABB8RQAAAABAAAAAQAA AAAAAAAAAAAAAwAAAD8AJfEsAAAAAAAo8RAAAAABAAAACQAAAAAAAAAAAAAADwA88QwAAAAAAAEr BAAAAAEAAABPACXxLAAAAAAAKPEQAAAAAQAAAAoAAAAAAAAAAAAAAA8APPEMAAAAAAABKwQAAAAB AAAAHwBE8ekCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAALcTAAAAAAABAAAADwA98QAA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPGRAgAAAAAn8SAAAAAAAAAAAAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETxOQIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEWAAAAoABC8QUAAAABAgAAALAAQvEFAAAAAQEA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAA AAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAA EABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAA HwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwA AAAAAPsqFAAAAAAAAAABAAAAVLUFAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETxrQAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA9AEAABgAAAAPAD3x AAAAAA8ALfF1AAAAAAA28QgAAAADAAAAAAAAABAAQvEZAAAAA3cAaQBwAGUAKAByAGkAZwBoAHQA KQAAAA8AKvE8AAAAAAAz8RAAAAAAAAAAAAAAAAAAAAAAAAAADwA88RwAAAAAAPsqFAAAAAAAAAAB AAAAVLUFAP//////////HwBE8ekCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAALcTAAAA AAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPGRAgAAAAAn 8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjx EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxOQIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEWAAAAoABC8QUAAAABAgAA ALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn 8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrx CAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAA AAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkA dAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAULUFAP//////////HwAl8RgAAAAAACjxEAAA AAAAAAAAAAAAAAAAAAAAAAAfAETxrQAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA 9AEAABgAAAAPAD3xAAAAAA8ALfF1AAAAAAA28QgAAAADAAAAAAAAABAAQvEZAAAAA3cAaQBwAGUA KAByAGkAZwBoAHQAKQAAAA8AKvE8AAAAAAAz8RAAAAAAAAAAAAAAAAAAAAAAAAAADwA88RwAAAAA APsqFAAAAAAAAAABAAAAULUFAP//////////HwBE8ecCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMA AAAAAAAAALcTAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA//// /x8ARPGPAgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxNwIAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEWAAAA oABC8QUAAAABCAAAALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAA AB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAA DwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAA AAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkA cwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAWbUFAP//////////HwAl 8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxqwAAAAAAJ/EgAAAAAAAAAAAAAAADAAAA AAAAAAAAAAAAAAAA9AEAABgAAAAPAD3xAAAAAA8ALfFzAAAAAAA28QgAAAADAAAAAAAAABAAQvEX AAAAA3cAaQBwAGUAKABsAGUAZgB0ACkAAAAPACrxPAAAAAAAM/EQAAAAAAAAAAAAAAAAAAAAAAAA AA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAFm1BQD//////////x8ARPHnAgAAAAAn8SAAAAAAAAAA AAAAAAAAAAADAAAAAAAAAAC3EwAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA AAAAAAAAAP////8fAETxjwIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEA AAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8TcCAAAAACfxIAAA AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC 8QUAAAABFgAAAKAAQvEFAAAAAQgAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAA AAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkA AAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUA AAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkA bABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAAF21BQD/ /////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8asAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAPQBAAAYAAAADwA98QAAAAAPAC3xcwAAAAAANvEIAAAAAwAA AAAAAAAQAELxFwAAAAN3AGkAcABlACgAbABlAGYAdAApAAAADwAq8TwAAAAAADPxEAAAAAAAAAAA AAAAAAAAAAAAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAABdtQUA//////////8fAETx5wIAAAAA J/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAtxMAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo 8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8Y8CAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAA AAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPE3 AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUA AAABAQAAAJAAQvEFAAAAARYAAACgAELxBQAAAAEIAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo 8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAA AAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkA cwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEj AAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAA AAEAAABhtQUA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGrAAAA AAAn8SAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAD0AQAAGAAAAA8APfEAAAAADwAt8XMAAAAA ADbxCAAAAAMAAAAAAAAAEABC8RcAAAADdwBpAHAAZQAoAGwAZQBmAHQAKQAAAA8AKvE8AAAAAAAz 8RAAAAAAAAAAAAAAAAAAAAAAAAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAYbUFAP////////// DwACKwAAAAAPAO4DJAIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABMADwAMBJQBAAAP AALwjAEAADAMCPAIAAAAAwAAAAPABQAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAAwAUABQAAAA8ABPByAAAAEgAK8AgAAAACwAUAIAIAAFMAC/AeAAAAfwAA AAQAgACIpvsDvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAABgANQBjBYwAw8AEfAQAAAAAADDCwgA AAAAAAAADQD7Aw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAPABQAgAgAAUwAL 8B4AAAB/AAAABACAALSs+wO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPAD1AGMFhAODwAR8BAA AAAAAMMLCAAAAAEAAAAOAPsDDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAcAF AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBHkCXAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACWlpYAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8AihMw AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAERfwgEw4x89DwDuAyQC AAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwATAA8ADASUAQAADwAC8IwBAABQDAjwCAAA AAMAAAADyAUADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAA AMgFAAUAAAAPAATwcgAAABIACvAIAAAAAsgFACACAABTAAvwHgAAAH8AAAAEAIAAKL/tBL8BAAAB AP8BAAABAAEDAgQAAAAAEPAIAAAAYADUAYwWMAMPABHwEAAAAAAAwwsIAAAAAAAAAA0A7QQPAA3w DAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADyAUAIAIAAFMAC/AeAAAAfwAAAAQAgAAc se0EvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwA9QBjBYQDg8AEfAQAAAAAADDCwgAAAABAAAA DgDtBA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHIBQAADAAAgwAL8DAAAACB AQAAAAiDAQUAAAiTAR5AlwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP// /wAAAAAAlpaWAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBf AF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAABFX8IBsJ+v7BAAERCXBwAAAFwDAHic7dYHeJSF AYfx7xJQCIgyxIgLN25woLgBwQnBjVvUKCCIQMC9F6jg3gskbts6utu0ttVuR/du7bR72l2TvjfQ 1PE84e8offr+8ryQS+7y5e7++e6ee7bv84sfHfTD4lV2LeqL9o6exQqdvtaNSksvrFIUdbXL7R0d HZ2v8y36NnVoufcSfbP2HLbXLpef8xWpB/WkBupFvWkl6kMrVydQ9KV+1J8G0Ko0kFajRlqdBtEa tCatRWvTOjSY1qX1aH3agDakjWhjGkKb0Ka0GW1OW9CWtBUNpWG0NW1D29J2NJy2px1oBO1IO9HO tEtl20WxG+1OI2kUjaY9aAyNpT1pL9qb9qF9aT8aR+OpiSbQ/nQAHUgH0cF0CB1KE+kwOpyOoCPp KDqajqFjaRIdR8fTCdRMJ9JJNJmm0FQ6mabRdDqFZtCpNJNm0WxqoTk0l06j0+kMOpPOorPpHDqX zqPzK7/7DD5aeC7G8HNb+FnlW3TdwKL7y3/n5fNBA+eNsieq3x7b+bqLnpreOm/BE6X6V77P+aOJ +9W8TMfsrKGoK3Xec1dvN+Dl44/m/k/nsWzieZi6zMfvx/HL58Dyferq8cvXH1f7vK52/yfwyDfz LA6tfHRdY+3+d1uG43enHq3VM3l77Xlrf4fON1q+lKov47ESy6lvqG7v1X/75deQCaNmzZk9uXj9 T18c8djMN3NwvWkX0IV0EV1Ml9CldBnNo/l0OV1BV9ICWkhX0dV0DV1L19H1dAPdSDfRzXQL3Uq3 0e10B91Jd9EiWkx30xJqpXvoXrqP7qcH6EF6iB6md9G76T30CD1Kj9Hj9F56H72fPkAfpA/Rh+kj 9FFqo4/Rx4vqTj9Bn6RP0ZP0FH2aPkOfpc/R5+kL9EV6mp6hZ+k5+hJ9mb5CX6Wv0dfpG8V/vqcq 912+9j36Pv2AnqfyG+8f0Y/pJ/RT+hm9QD+nX9Av6Vf0a/oN/ZZ+R7+nP9Af6U/0Iv2Z/kJ/pb/R 3+kf9E/6F71U/r2o8kJRqv7dlv9ql763L19eekKY37/aM0tKfI93gvUvlO9u8XTl3/It6ks9Kq8m vetGd7RVPutVt/QaI3sN5hFrqzzivL/qqP4/pPYctFWO11i8kf/W+VCSJEmSJEmSJEmSJEmSJEmS JEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmS JEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmS JEmSJEmSJEmSJEmSJEmSJEmSJEmSJEmSJC3/6gvpFaWiqZhWNBfDiqHF+GJS0VJMKeZyuasGFXVF 53115TbfodYlpfRXfo1lPf5b7X/5+CWehjqqp27UnVagFakH9aQG6kW9aSXqQyvTKtSX+lF/GkCr 0kBajRppdRpEa9CatBatTevQYFqX1qP1aQPakDaijWkIbUKb0ma0OW1BW9JWNJSG0da0DW1L29Fw 2p52oBG0I+1EO9MutCvtRrvTSBpFo2kPGkNjaU/ai/amfWhf2o/G0Xhqogm0Px1AB9JBdDAdQofS RDqMDqcj6Eg6io6mY+hYmkTH0fF0AjXTiXQSTaYpNJVOpmk0nU6hGXQqzaRZNJtaaA7NpdPodDqD zqSz6Gw6h86l8+h8uoAupIvoYrqELqXLaB7Np8vpCrqSFtBCuoqupmvoWrqOrqcb6Ea6iW6mW+hW uo1upzvoTrqLFtFiupvKp4NWuofupfvofnqAHqSH6GFqf/teGv8vLeKBHzVuYe1sPJyGUFutUtFY +fpEvv9kn6LS6511pC5yN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o 4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyN Eu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLd KOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXc jRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC 3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl 3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3SrgbJdyNEu5GCXejhLtR wt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7UcLdKOFulHA3Srgb JdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kYJd6OEu1HC3SjhbpRwN0q4GyXcjRLuRgl3o4S7 UcLdKOFulHA3SrgbJdyNEu5GCXejhLtRwt0o4W6UcDdKuBsl3I0S7kaJ4p31bwpRRpwQABEQ+h4A AAAiBAB4nO2cBZzlZfXGf3cWJAURbMW1sRDFwkQRmxILWxEVRVdhsbs7EETFTuzuQsUO7O5uUVHM 3f9zZ3aXYf9zf+/pc2b2ffg8O7sz9/c+33POe+6MCHzltF1+8sp3XPCnw2a63rBqWLd+u+Eciz63 NTzZ+IdzDcPchj+vW79+/cZPb7XhddvhC9vD67tK63/wtpOFGa7b8Oept8EMt53OEd4e3gHeET4n vBO888IVGHaBzw3vCu8Gnwc+L3w++PzwBeALwheCLwxfBN4dvii8Gr4YfHH4EvAl4UvBl4YvA+8B Xxa+HHx5+ArwFeE94SvBe8FXhq8C7w1fFb4afHX4GvA14X3ga8HXhq8DX3f+bg/D9eF94RvAN4T3 g28E7w/fGL4JfFP4ZvDN4VvAt4QPgA+ED4IPhg+BbwUfCt8avg18W/h28O3hw+A7wHeE7wTfGb4L fFf4bvDd4XvAh8P3hI+A7wXfG74PfCR8X/h+8FHw/eEHwGvgB8IPgo+Gj4HXwsfCD4YfAj8Ufhj8 cPgR8CPhR8GPhh8DP3aefQ3+WotZ7I9z1+Ks6RN0nRfbvvEuTd8P9t3n+F1+dPXTdjnhesMpJ+97 2d8ufu0p11397dPPPGWyavqHDW8kE3TyqPmqZdp+mJssvs/U53YbNubvh/rvj14ehDncl51/buRP S5m+71Hzp68/dsPv90Pugbg5+8//eqgkf+DWP31PP2lubv736zbMbeP+d21Zmix8GxdrgpuzavuF u7/57k/f0w848vCj1xyz5l5rVx98nzVr16ze/55Hrl1z9Oq999xr9cFHHr722KOPmP92csCh819e +Or8N5pNn9lz7+GMfd75oBn501wN/5aux8GPh58APxF+Evxk+CnwU+GnwU+HnwE/E34W/Gz4OfBz 4efBx8HPh4+HT4BfAJ8IvxB+Efxi+CT4JfBL4ZfBL4dfAb8SfhX8avg18Gvh18Gvh0+G3wC/EX4T /Gb4LfBb4bfBb4ffAb8Tfhf8bvg98Hvh98Hvhz8AfxD+EPxh+CPwR+GPwafAH4c/AX8SPhX+FPxp +DPwZ+HPwZ+HvwB/Ef4S/GX4NPgr8Ffhr8Ffh78BfxP+Fvxt+Dvwd+Hvwd+HfwD/EP4R/GP4J/D0 B++fwT+HfwH/Ev4V/Gv4N/D0G+jv4N/Df4D/CP8J/jN8OvwX+K/w3+Az4L/D/4DPhP8J/wv+N/wf +L/w/+B18PzSYPmn37zm4FXwVvDW8DngbZb4mXBHfO6c8E7wzvC54F3gc8O7wrvB54HPC58PPj98 AfiC8IXgC8MXgXeHLwqvhi8GXxy+BHxJ+FLwpeHLwHvAl4UvB18evgJ8RXhP+ErwXvCV4avAe8NX ha8GXx2+BnxNeB/4WvC14evA14WvB18f3he+AXxDeD/4RvD+8I3hm8A3hW8G3xy+BXxL+AD4QPgg +GD4EPhW8KHwreHbwLeFbwffHj4MvgN8R/hO8J3hu8B3he8G3x2+B3w4fE/4CPhe8L3h+8BHwveF 7wcfBd8ffgC8Bn4g/CD4aPgYeC18LPxg+CHwQ+GHwQ+HHwE/En4U/Gj4MfBjp7MfDl813VXc/p0W fiKFdj3kuP622rVlqvXj0EmHnbTzXFfXitRkRNlsXV3LW2Pb1Retq0sj4nb1NevqEoi7X33Lurro ku1XwJb5JYbVoultZKu5rO4wlrDJzALUMHK/vLBC9O0N6LOG1Z3KDnbZgKrZFz236eGlT3HrVNwE bBrsx2fC6k5mA7tMMA3wFz206cmlj3DrVNwEclocz+oOZwAbzmg5fVYBix7Z+OCsA7xa5XQsNcm3 v0ms/nxa2GBC6wXjlTBZ9M0rYcUCB5DR3SxWf0IdbCifx4JxapgsXrFJXzHT5iay+jNqYAPpnBaM UcXk7Cs2+1mfXrkcyojybG0yqz+lHDaMzXPDqHVMUlfM40xWll9j81n9McWwUWi+C0YsZHLWim34 IXHGgy698jiTleXW1wqs/pxS2CAy9w0jlTKhrpjLjjkcycvyaWoV1gBSGWxZMI9aJpkrZn8iN8yl p3VYA1DrrphVE7XFTBat2KJfyMT2TVCdyA3zaOkWxlp1xcx6qK1mQl4xhx0zP5Ad5tDRUqxFYWtS yeULbX2gFS0tLbOfEaxF/95MSSiNXKmtDzSCJaYltjOENQJ3hTDp5MptfJ4RKzEtr5khrCG8BZks +xdakvHZjqTUOL80neisYcPnweYiCYj0ciS3Pc4ElBznl6YTjzVk+PL4cCIBkIUc2U1PM+Ekx/ml 6cRm9Z+9MDuBSMBjIz94y8MsKBl5jnEqSVidZy8KzgAS4FjJjd7yMANITp5jnEoiVtfRi3IzgAQ0 ZvLjNzzLApKR5xinkozVd/aC2AQeAYyh3AqwO8oAkRXomaeRlNVx9PzQEVViMZVXBXZH6Ql5gZ55 GolZ/UbPzxxRJRZbeZVgdpIekBfomaeRmNVv8vzMERVCsZZTDVYHqfG4ia6BCslZvQbPjxxTHRJz ORVhdZAaj5voGqiQgtVr8uzEMZUBcZBPGYnn6BJdAxVSsHoNnp04pjIgHvIpw+YYLRs/0jdRLg2r z9zZgaOqwuEinzpsjtGy8SN9E+XSsPrMnR04qiocPnIpxOQULVm9SLFUrC5j5+aNqwiGk3wqsThE SybIdI4US8XqM3du3qhqULjJpRSLQ5RgkkznSLFUrC5jZ+eNqgaFm1xqMThDy1UxUyodq8vYmXHj KgHhKJdi9EcosUSh3plS6ViD20u5c+4wAghHuRSjP0KJJQr1zpRKxxrcXsqd84YRMLjKoxz1CUqo oqFC6Vg9hs6NG1cFBle5lKM9QAklS3UPFUrHGtxfypXzhhEw+MqjHO0BOiZhqnuoUDrW4P5Sbpwz jADBWR4FKZ9XIpVNlUnH6jFzbty4CiDMpLI5K/fbmAORNNY/VSYda3CDKRfOF0ZA0ACyP9GiIt3j OiJprH+qTDrW4AZTLpwvjICgSaM8M/cnRQegwrEi6Vg9Rs6NG1c+AYFFdWrqtzEHHnFuQKxIKlaP ifPzRpUOQENxO1hak+ZhHY84NyBWJBWrx8T5eaNKByCCKE7O/EnRAad0rkQqVo+Bs/PGlQ5A5pCf nfdtzIGGpqxciVSs0R2mXDdPGkE+A8P3dG6u/FEdDU1ZuRJpWD3mLQgcVXY+h8L5eF6u+EklDE1p wQJpWF3mzQ8cVXa+QUPdixQf6gFDU1qwQBpWl3nzA0eVnc9iEJ6f9pOiAwtRacECKVg9pi1JHFVy PJPBP4EeK3xOiUJUXjJfClaXaQsSR5Ucz0UIiKCmuj1mobxkvuSsPtOWRI4pOZ6LEBBBTpU9pkQh Ki+ZLzGrz7BFmWNKjmcTRGQQU0VPaUmISoxmS8zqNGxJ5piS49kEsoyUnxQ9QKhKjGZLyuo0a1no iJLj+QCikJSfFD1AqJJ1KRxzJqvwMX/03F4K0gUAMSmkVMEzWg6qZF2K55zFKnooAj23l4J0Qb4o pa9YcL+0rJJnQshzeylIl+QHxVBC+Y9oOagSNSmBcxYr/4kg8NxeCtKXzYoJFsYFgypRkzJAZ7Ay Xx4HnttLQXpfMSeJmpQBOoNVWlYKbByTIF0SL4lxWjH2m60aQ4cb2K9A1lDsXKignkhiDMrkHutD QZWoSSmkfcV80/uKOUnUpBRSyxWrCZubLoqPyqGk8l6up9DRRvYrjjUUOhcrqitROZRY1qsNIFSw sf0KYw1lzuWKaktUDiWW9WoDCBVsbL/CWEORc8Gi+hKVQ4rlvNgAQgcb2q8w1lDiXLKoxkTlkHIZ r7VgULEG9yuKNZQ3ly2oNZKYvmIJ/YpiDcXNhQvqjSTGb8WWPtmNQcca268o1uqwuenL5x+gmplM fqUJggo1ul8xrJGofcWcy6Sf7IagQQ0FYEg00KyichGDWhQUQ06mvtAEQYMaCsCQaKBZBeVixrRJ lGJUJvVoPwINaSwBXVnTDIJNXzE2QEwKI5v4OhsCDWksAV1Ls7oP0w62odx0AUBMCiNb/DJP5RPQ NZPVeZpmsA0lx7MBRBlmZdLOdgTQgAYjkDXC6jxOI9iGkuPZBLKMvmLxCGSNsTrP0wa2oeR4LoEs InbFPAE0oMEIZI2yOg/UBLah5HguQkAEP5/wGjMABWc0A1XjrO4j1cM2lBzPRBAm9BXLYKCqweo+ UzVsQ8nxTAb/BAkA+yX+qsBAVYvVfaha2IaS43kQ7gFChOYr7PIVmOEQRIk6mlUP5bZ5cgryORTi 4/uKpUAQ1WZ1n6oOtqHsfAaG7+maElkvCFEJCKIIrP5z1cA2lJ1P53A9XFlj4+uW+XLKeAqaCKwR g5XDNpSdTwbxPFtdY+PrlvlyyngKmiisAYOVwzaUDkAj0RwcumLe8QrKBAySSKwBkxXDNpQOQGLx OtesxtGv2uaLIRMwSKKxhsxWBttQOgCBxudU0xpHv2qbL4ZMwCCJyBoyXBFsQ/kEDSD9idkrZhsv h8zgoIjIGjJcEWxD+QSzqUwP862R8rVIVeGgiMoaNF4+bEP5BO4yLnH021hEvpQxg4MiMmvQfNmw DRVA8FZIibO/Zh0vZkwBIYjMGjRfNmxDBRCcZV3h2J2IyVch1hOdNWzCPNiGKjD4yrzCvmK2YrCG jZgF21AFBleZFzj2k2JMvhAxh6QtBmvcjDmwDVVgcJV5gTNqnPUFj3wFYUFxWAOHzAIYUwkIR9nX N6PEsc/Hqw5JWyzWyDEz8sdUAsJR9vXNKHHG513y5YQVxWKNHDMjf0w1KNzkUN6sEpf+tBOAELCk eKyxg6bGj6kGhZscyptVYql7XQilKSZr7KSJ6WMqguEkj+pmVVjpm1hfsUjYhqpw+MiluhkV9hUT issaPWtK+JiqcLjIpbhZFfYVE4rLGj9tQviIyoB4yKc4RoF+AAK+NJiG2KyZzSYO3p9LAOIgn9o4 FXoSsPHSYBrisyZ2mzb3CCwBibmcSuMU6IrAxUuDaYjPmtht2txDsAQo1vIqjV6fKwEbL49mXALW vH7Trl4MlYDFVm6V0etzRmDS5dGMS8Ca13Da3YuBErCYyq0wRn3eDDy6PJpxSVjTGk68fTFQAhhD +dVFL8+dgUeXiDMqEWvhsQcyCWjM5FgWvbwACA5cIs6oRKxZPadewCAkAY6RPKuiVxdBwYBLxBmV jDWp5+QrGIQk4LGRa1XU4iIgOHCZPGMSsuZ0nX4Hg4gEQBbyLYpaXAwFnS2TZ0xC1py20y9hVN8F RHo510StLQiDzJbJMyYpa0rbGdcwqu8CJK28SyKWFoUhYSvVUGlkCm699iXsmHtFxNLiONhotToq jszArdc+GZRC/vVQK4skYaLV6qk4MoO3XvuEVGIFlEMsLJSEh1asqfLIBOB67ZNiCRVRDbGwYBQG WbWuKiLjgeu1Tw4mUUwxtLKiWehk1dqqiIwnrtc+BVnVUmhVxcNQyco1VhMZjlyvfRq0opXQqsqg IYHV66wmMhy5Xvt0cCXroNWUw0MAq9dbVWQ0c732KekqlkEqKYmnDVawuarIaOZ67VPz1SuCVFEe 0ThXxfbqIoOh67XPgLBaCaR6MpnGuCo2WBkZS12vfSaMxSogVJPKNMJVssPKyFjqeu0zoqyETykm m2pLWrHYHavXPjPOOvBnV1Ewqw5HVKONDOWu1z5L1CroZ1NRMoP2hpWjjozkrtc+W9gS3JupJpyu ubHlqCMjweu1z5w3H3ozVefr2uK1rPerq2t5qG9XV1eA+nZ1dXV1dXV1dXV1dXV1dXV1dXV1LUMN Xf6aGw4ajhqOGA4ejsavxwx7zf9F1/mHuckqfNwaXg9RntlhMgzf2nZhvvsh/8Dh1sP+878eOtx2 2JubP5+7UZRnpry7MTJa4uZbS5P/OMzi8fAT4CfCT4KfDD8Ffir8NPjp8DPgZ8LPgp8NPwd+Lvw8 +Dj4+fDx8AnwC+AT4RfCL4JfDJ8EvwR+Kfwy+OXwK+BXwq+CXw2/Bn4t/Dr49fDJ8BvgN8Jvgt8M vwV+K/w2+O3wO+B3wu+C3w2/B34v/D74/fAH4A/CH4I/DH8E/ij8MfgU+OPwJ+BPwqfCn4I/DX8G /iz8Ofjz8BfgL8Jfgr8MnwZ/Bf4q/DX46/A34G9O7zb8bfg78Hfh78Hfh38A/xD+Efxj+CfwT+Gf wT+HfwH/Ev4V/Gv4N/Bv4d/Bv4f/AP8R/hP8Z/h0+C/wX+G/wWfAf4f/AZ8J/xP+F/xv+D/wf+H/ wevg9TBWZ5jA07faVfBW8NbwOeBt4OmKbgdvD+8A7wifE94J3hlet75rJWj6frgVPNnwXrLxO+9J h8E7Y29xESbDdrgkB241we9Wz01fOX1q9/n3/R3mH5j+bse5Fwz3WDW9Q2dOXzB92bDrIcdNTzV4 n+vq6lpOmr6rXHVu4b3iavPvENvM/7Q4fQfZb+fVwxfx+xOHw6ef2vRxD3j6uxOH6TvStvPn/Bff rk7daZj3wrvKgo47ZNf+3tLVtQUq+29PdHWtcPUd6+ryVd+xri5f9R3r6vJV37GuLl/1Hevq8lXf sa4VqjL/rnDfsa4Vp2L/yQvejmW/I3R1NUTdr8D7uxJ2jN3WxJarIyPB67XPnDcCmrVj9bo6G6to v9WRkdz12mcLG8St37H8JdN1N7YabWQod732WaKGofcdi61GGxmKXa99ZpyR8Jwdq9RWAlepPo+x Kh/3o67XPiPKWHyDHUtfMssm9x0jpOW1z4QxuoK+Y7HF6CKDoeu1z4AwvgTGjlXpKx2sRIfbrKqH PZnrtU/Nl1GExY5lL1nl/lJYVQ97Mtdrn5Iup4y+Y7G1aCLDkeu1TweXVAd9x0o0lkuW21wiq+ZZ V+R67dOgpVVismPJS1a0tWRWxaO+xPXapyDLK6XvWGwpish44Hrtk4NJZERL3rECnRWhJfWVwyp/ 0hm4XvukWELZ8Nrs2PL8x60zKhFHZvDWa5+QSiwT4L5jsZWIIzNw67VPBqWQBTF1xwJQxCrXVCar psZw2Nz2Ra+YSUVGO5a6ZNV4xiRlTWk74yZG9V2ApJWaue9YrISsOW2n38OovguI9NJCE3fMnUOj ajxjErLmdJ1+DYOIBEAWUlJb7VjmpS6GMyoZa1LPyZcwCEnAYyMddt+xWIlYs3pOvYJBSAIcI+m4 aTvmjqFSMZxRiVizWk69gjFMAhozqcDNdqzYf5Eoj2ZcEta0hhMvYAyUAMZQGvK+Y7ESsOY1nHb9 YqAELKZSoJN2zBtCqVo04xKw5vWbdvtiqAQstpKj2+1Y3rUuBdMQnzWx27S5h2AJUKwlZu87Fis+ a2K3aXOPwBKQmEsMT9kxbwatSsE0xGbNbDZx8P5cAhAHSemFOzbjkzmy7Ie3uKzW81bDNlQGxENC +r5jseKy2k7bALahKhwuEuITdmzpNDsEtQzb4S4mq+2wLWAbqsLhIxm+5Y5lXexCKE0xWU1nbQLb UBEMJ8n4xTtW6BuZXTf8xWM1HbUNbEM1KNwkKqC9Y7OirAj0MmtGgFisloO2gm2oBoWbRAWY7ljS za5D0haL1XLQVrANlYBwlKQC+Y7V+UZm1YsIcVgNx2wH21AJCEdJKmju2OwkIwK9rHoRIQar4ZQN YRuqwOAqQQmiHWt9JVhlQAhisNoN2RK2oQoMrhKU0HcsVnRWuxmbwjZUgcFX/BJaOzYWYwJgIJtO xIjMajZhY9iGCiA4i1+D8Y6l3O0qHBSRWc0mbAzbUAEEb7FrkOwY5WuRqsJBEZXVar7msA3lE7iL XURjx8ZDLAAMZNKIIBFZrcZrD9tQPsFsKtPDGLLesYzLXQSDJCKr1XjtYRvKJ2gA6U9k19h3LFY0 VqPhesA2lA5AoPE5dbbGd6wRYQFgoCIYJJFYjWbrAttQOgCJxevcpaXasSK3uwYFTRRWo9H6wDaU DkAj0RzMLrLvWKwIrEaTdYJtKDufDOJ59mYa3bFmgAWBXiUgiCKw2gzWC7ah7Hw6h+vhZ5Nux2pc 7xIQRLVZbebqBttQdj4Dw/f0Reo7FitRR7Pqodw3T05BPodCfDyzyrEdIxxvQKBXBQaqWqw2U3WE bSg5ngfhHrAg5Y6VuN8VGKhqsNoM1RO2oeR4JoN/wlR9x2I1zmozU1fYhpLjmQjCBLsdI51ugKBW AQSyRlltRuoL21ByPBchIEK/YxUueAEEssZYbSbqDNtQcjyXQBbBDOk7FqsRVpN5usM2lBzPJpBl WO0Y8WyDOrXKJ6BrJqvNOP1hG0qOZwOIMqJ3rMANzyega2lWq2kGwDaUmy4ACEjpOxYr53Fmw/Yd W0Izd4x8tkmlKqUDMCQbaVJBuZgxbRKleO4Y+ZW8OpVKB2BINtKkonIRg1rkH7NSd8ytYbmskah9 x4xiZu0Y42ijWuUSdWmZslaHzU1fATvGeC0LQilRl5YpayhuLlxQbyQxfcdcG5bMGsqbyxbUGkmM yY6xTraqVipRl3JQTXYsjDiXLKox7jmcHWNRsih0kjQpCdVox4KQc8Gi+uKe03dsWe5YDHMuV1Rb 3HOW3jHmwWblyiRpUg6p3Y6FQOdiRXXFPYexY0xMFoZKkiblkBruWAR1LlVUU9xz+o4t1x0LwM6F CuqJJMZgx9jnWtUrk6hLGaAGrKHYuVBBPZHEeO0YG5TFoZGoSxmgM1ilZaXAxjEJ0vuOeUnUpQzQ GazMl8eB5/ZSkL58/lkqwbFG9cok6lIC5yxW/hNB4Lm9FKQv8x0TkLJAFBJ1KYFzFqvkmRDy3F4K 0vuOeUnUpQTOWayihyLQc3spSF82/46m6FSbgmWStSkccyar8DF/9NxeCtIFAAEp1B0TobJI5EqM ZkvKajJsC9iGkuNX9I5lXvTEaLbErBbDtoBtKDmeTSDL0O6Y8FCDeqXKS+ZLzGoxbAvYhpLj2QQR GcQdE8LyWKTKS+ZLzmoybj1sQ8nxXISACMMdS7zpecl8KVgtxq2HbSg5nosQELHEjokPNYARKi1Y IAWrxbj1sA0lxzMZ/BOm6jsWKw2rxbzVsA1l57MYhOf77JiYmAcjVFqwQBpWi3mrYRvKzjdoqHmR m++Y4lALHJGyciXSsJoMXAvbUHY+h8L5+E3qOxYrFWt0hyn3zZNGkM/A8D19kUg7RjzLAEekrFyJ VKwWA9fCNpQOQOaQn63cMdWZFjwSJcWKpGI1mbgStqF0ACKI4mR2jX3HYqVitRm5DrahdAAaitvB S4myY6qWcIEESooVScdqMnJl3LjyCQgsqlO1O6Y804SIr5xUmXSswQ2mXDhfGAFBk0Z5Jr/EvmOx 0rEGN5hy43xhBAQNIPsTmyLsmLIlbCS2clJl0rHazFwXN64CCDOpbM5S7pj6TBsmrlJChdKxBveX cuOcYQQIzuLX0HcsVjrW4P5Srpw3jIDBV/wS2jum7ggfiqmUUKF0rEZDV8WNqwKDqwQlLN4xg0Ot sNSh3plS6ViD20u5c94wAgZXCUroOxYrHWtweyl3zh1GAOEoSQXNHTPoiISreqZUOlazsSvixlUC wlGSChbtmMmhZmDKTOdIsVSsdmPX5I2qBoWbRAX0HYuVitVw7oq8UdWgcJOogNaOmXRERFY6UiwV q93YFXnjKoLhJBn/WTtmdKohmybSN1EuDavl3BWBo6rC4SMZft+xWGlYLeeuCBxVFQ4XCfEbO2bV ECGdPNE1UCEFq+3gFYljKgPiISH9ph0zO9WSTp7oGqiQgtV28IrEMZUBcZCUvu9YrOSsxoNXRI6p Dom5xPD2Oxa/ZNF5GolZzSevyBxRIRRridk37pjhsbaAwkDPPI3ErOaTV2SOqBKLreTofcdiJWW1 n7widESVWEylQHfYsRL/V6ljnEoyVpfRa2ITeAQwhtKQD2MFWHZDAynIc4xTScTqM3oZbEO1aMyk Au87FisJq9fsRbANFcOxkorbY8cq/CsYfmk6sVn9Ri+Dbagaj4102MMIvG0vdJzcOL80nXisvrMX waYSCYAspKTuOxYrOqv/7EWwuUgCIr200C47FrxkVXoZyRrCW5DJsn9RJQ2zwa07oWZlpaV0M5A1 AneFMOmkR+47FkHowBpBu1KgNDIg9tmx2CWr1M8w1qKwNanksgAeZkLb98GClxyW1dAVxFp0xwKX rA1y1sezftlcfccCAB1YA1DL7ljYkhE4zvo4id6x0CUL62kd1gBSGWxZMI9aJot2bOGJJZ8afFZs ee7Ysvlf7P6cUtggsogtI0Fs+rjwyJKP9R0LALRm9ccUw0ahuS8ZkWHTx4WHlnzQa8cilyy2sfms /pRy2DA25y2jEiwimZv15OC0Yn3HvFj9GTWwgXSOS0YHWATSd8yyt4ms/oQ62FA+py3jxC/C2PDx /7/MbccClyyhu0ms/nxa2GBCjy1jhZ8FMTd7x9xaFTeClP4msLrDGcCGM1pvmSC375hPh8NZ3cls YJcJpgH+ooc2Pbn0EX47FrdkOT0OZHWnsoNdNqBq9kXPbXp46VOW3jGDsvuOqVndYSxhk5kFqGHk Q/slXV3LQTUXbK7vWNdKUsEFm+s71rXCVG3B5vqOda1E1dmvqfqOda1QFdiuBQ1bDcNwmcn69auG Lp3+D/+JBCEAAHIXSAAAAAEAQAAAAAAAezcAAA1BAABrSAAAHgAQAFkjAgC3ABAAVU0AALkAEACJ UgAATgFgAARQAAD4KgIAZFUAAHeSAQABHwIALSECAAAA9Q8cAAAAAAEAAD8KAAMAAAAA+kkCAAEA AABTAQAAAQCiAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAALxPAAAOAAAAAQAAAHgAAAACAAAAgAAAAAMAAAC4AAAABAAAAMQAAAAHAAAA3AAAAAgAAAAw AQAACQAAAEgBAAASAAAAVAEAAAoAAAB0AQAACwAAAIABAAAMAAAAjAEAAA0AAACYAQAADwAAAKQB AAARAAAArAEAAAIAAACkAwAAHgAAAC4AAABJUHY2IGFjdGl2aXRpZXMgb2YgTlRUIGluIEphcGFu IGFuZCB0aGUgd29ybGQAd2UeAAAAAQAAAABQdjYeAAAADgAAAFNoaW4gTWl5YWthd2EAcyAeAAAA SQAAAEM6XFByb2dyYW0gRmlsZXNcTWljcm9zb2Z0IE9mZmljZVxUZW1wbGF0ZVzM39q+3t3DsLyu 3SDD3rvest1cV09STERKLlBPVAAAZQAeAAAADgAAAE1JWUFLQVdBIFNoaW4AZXMeAAAABAAAADE0 MQAeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AG9zb0AAAABwCjXkXwIAAEAAAACgtwH8CMe/ AUAAAABAV8HmEze/AUAAAAAAHNohW1/CAQMAAADjAQAARwAAAAhOAAD/////AwAAAAgAiRB0CwAA AQAJAAAD/CYAAAEA0SQAAAAABAAAAAMBCAAFAAAACwIAAAAABQAAAAwCmgLBAwkCAAD3AAADAgEA AAAAgAAAAACAAACAgAAAAACAAIAAgAAAgIAAwMDAAMDcwACmyvAABAQEAAgICAAMDAwAERERABYW FgAcHBwAIiIiACkpKQBVVVUATU1NAEJCQgA5OTkA/3yAAP9QUADWAJMAzOz/AO/WxgDn59YAramQ ADMAAABmAAAAmQAAAMwAAAAAMwAAMzMAAGYzAACZMwAAzDMAAP8zAAAAZgAAM2YAAGZmAACZZgAA zGYAAP9mAAAAmQAAM5kAAGaZAACZmQAAzJkAAP+ZAAAAzAAAM8wAAGbMAACZzAAAzMwAAP/MAABm /wAAmf8AAMz/AAAAADMAMwAzAGYAMwCZADMAzAAzAP8AMwAAMzMAMzMzAGYzMwCZMzMAzDMzAP8z MwAAZjMAM2YzAGZmMwCZZjMAzGYzAP9mMwAAmTMAM5kzAGaZMwCZmTMAzJkzAP+ZMwAAzDMAM8wz AGbMMwCZzDMAzMwzAP/MMwAz/zMAZv8zAJn/MwDM/zMA//8zAAAAZgAzAGYAZgBmAJkAZgDMAGYA /wBmAAAzZgAzM2YAZjNmAJkzZgDMM2YA/zNmAABmZgAzZmYAZmZmAJlmZgDMZmYAAJlmADOZZgBm mWYAmZlmAMyZZgD/mWYAAMxmADPMZgCZzGYAzMxmAP/MZgAA/2YAM/9mAJn/ZgDM/2YA/wDMAMwA /wAAmZkAmTOZAJkAmQDMAJkAAACZADMzmQBmAJkAzDOZAP8AmQAAZpkAM2aZAGYzmQCZZpkAzGaZ AP8zmQAzmZkAZpmZAJmZmQDMmZkA/5mZAADMmQAzzJkAZsxmAJnMmQDMzJkA/8yZAAD/mQAz/5kA ZsyZAJn/mQDM/5kA//+ZAAAAzAAzAJkAZgDMAJkAzADMAMwAADOZADMzzABmM8wAmTPMAMwzzAD/ M8wAAGbMADNmzABmZpkAmWbMAMxmzAD/ZpkAAJnMADOZzABmmcwAmZnMAMyZzAD/mcwAAMzMADPM zABmzMwAmczMAMzMzAD/zMwAAP/MADP/zABm/5kAmf/MAMz/zAD//8wAMwDMAGYA/wCZAP8AADPM ADMz/wBmM/8AmTP/AMwz/wD/M/8AAGb/ADNm/wBmZswAmWb/AMxm/wD/ZswAAJn/ADOZ/wBmmf8A mZn/AMyZ/wD/mf8AAMz/ADPM/wBmzP8Amcz/AMzM/wD/zP8AM///AGb/zACZ//8AzP//AP9mZgBm /2YA//9mAGZm/wD/Zv8AZv//AKUAIQBfX18Ad3d3AIaGhgCWlpYAy8vLALKysgDX19cA3d3dAOPj 4wDq6uoA8fHxAPj4+AD/+/AAoKCkAICAgAD/AAAAAP8AAP//AAAAAP8A/wD/AP///wAAAAAA/NbW APjr6wAEAAAANAIAAAQAAAAHAQMA0SQAAEELIADMAG8AoAAAAAAAmQLAAwAAAAAoAAAAoAAAAG8A AAABAAgAAAAAAGBFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAA AMDAwADA3MAA8MqmAAQEBAAICAgADAwMABEREQAWFhYAHBwcACIiIgApKSkAVVVVAE1NTQBCQkIA OTk5AIB8/wBQUP8AkwDWAP/szADG1u8A1ufnAJCprQAAADMAAABmAAAAmQAAAMwAADMAAAAzMwAA M2YAADOZAAAzzAAAM/8AAGYAAABmMwAAZmYAAGaZAABmzAAAZv8AAJkAAACZMwAAmWYAAJmZAACZ zAAAmf8AAMwAAADMMwAAzGYAAMyZAADMzAAAzP8AAP9mAAD/mQAA/8wAMwAAADMAMwAzAGYAMwCZ ADMAzAAzAP8AMzMAADMzMwAzM2YAMzOZADMzzAAzM/8AM2YAADNmMwAzZmYAM2aZADNmzAAzZv8A M5kAADOZMwAzmWYAM5mZADOZzAAzmf8AM8wAADPMMwAzzGYAM8yZADPMzAAzzP8AM/8zADP/ZgAz /5kAM//MADP//wBmAAAAZgAzAGYAZgBmAJkAZgDMAGYA/wBmMwAAZjMzAGYzZgBmM5kAZjPMAGYz /wBmZgAAZmYzAGZmZgBmZpkAZmbMAGaZAABmmTMAZplmAGaZmQBmmcwAZpn/AGbMAABmzDMAZsyZ AGbMzABmzP8AZv8AAGb/MwBm/5kAZv/MAMwA/wD/AMwAmZkAAJkzmQCZAJkAmQDMAJkAAACZMzMA mQBmAJkzzACZAP8AmWYAAJlmMwCZM2YAmWaZAJlmzACZM/8AmZkzAJmZZgCZmZkAmZnMAJmZ/wCZ zAAAmcwzAGbMZgCZzJkAmczMAJnM/wCZ/wAAmf8zAJnMZgCZ/5kAmf/MAJn//wDMAAAAmQAzAMwA ZgDMAJkAzADMAJkzAADMMzMAzDNmAMwzmQDMM8wAzDP/AMxmAADMZjMAmWZmAMxmmQDMZswAmWb/ AMyZAADMmTMAzJlmAMyZmQDMmcwAzJn/AMzMAADMzDMAzMxmAMzMmQDMzMwAzMz/AMz/AADM/zMA mf9mAMz/mQDM/8wAzP//AMwAMwD/AGYA/wCZAMwzAAD/MzMA/zNmAP8zmQD/M8wA/zP/AP9mAAD/ ZjMAzGZmAP9mmQD/ZswAzGb/AP+ZAAD/mTMA/5lmAP+ZmQD/mcwA/5n/AP/MAAD/zDMA/8xmAP/M mQD/zMwA/8z/AP//MwDM/2YA//+ZAP//zABmZv8AZv9mAGb//wD/ZmYA/2b/AP//ZgAhAKUAX19f AHd3dwCGhoYAlpaWAMvLywCysrIA19fXAN3d3QDj4+MA6urqAPHx8QD4+PgA8Pv/AKSgoACAgIAA AAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AP////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////AP///////////////////wAAAAD///////////////8AAP////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8AAAAAAP8A/wAAAAD/ AAD//wD/AAAAAAAA/wAA/wAA/wAAAP8AAAAA//////////////////////////////////////// //////////////////////////////////8A//////////////////////////////////////// ////////////////////////////////////////////AAAAAAAA//8AAAD//wAAAAAA/wAAAAAA AP8AAP8AAAD/AAD//wAAAP////////////////////////////////////////////////////// ////////////////////AP////////////////////////////////////////////////////// //////////////////////////////////////////8A/////////////wAAAAD/////AAD//wD/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////AP////8A//8A//8AAAAAAP8AAAAAAAAAAAAA/wAA/wAAAAAA AAAAAP8AAP8AAP////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////wAAAP//AP//AP//AP//AAD/AAAAAAAAAAAAAP8AAP8AAP8AAAAAAAD/AAD/AP// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8A /wD//wD//wD//wAAAP////////////////////////////8A//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AP8AAP8AAAAA //8A/wAAAAD/AP8AAP8A/wD///8AAAD/AP8AAAD/AAAAAAAAAAAA/wD/AAD/AAAAAAAAAP8AAAAA //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wD/AAD/AAAAAP8A//8AAAAAAP// AAD/AP//AP//AP8A/wD/AAAA/wAAAAAA/wAAAP8A/wAA/wD//wAAAAD/AAAAAP////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8A//////////////////8A/////////wD/AAAA//8A //////8A////AP////8A//////////8AAAD//////wD///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////8AAP//////AP//////////////////////////////AP////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8AAP8A/wD/AAAAAAAAAAAAAAAA/wAAAAD//wD/AAAA AAAA/wAAAP//AAAA////AP8A////AP8AAP//AAAA/wAAAP8AAAAA//////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////wD/AP////8A/wAAAP8AAAAAAP8A/wAA////AP8AAAAAAP8AAAAA/wAA AP///wD//wD/AP//AAD//wD/AP8AAAD/AAAAAP////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wAA//////8AAAD///////////////8A////AP//AP////////////////////8A/wAAAP// /wD///8AAAD///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////AP////////////////////////8A//////////////////////// /wD//wAAAAAA////////////////AAAAAP///wD///////////////////////////////////// //////////////////////////////////////////////////////8AAAD/AAAA/wAAAAD///8A ////AP8A/wD//wAAAAAA/wAAAP8A/wD/AAAAAP//AP//AAAA////AAAAAP///wD///8A////AAAA /wD/AP///////wAAAAD///8A//////////////////////////////////////////////////// //////////////////////////////////////////8A/wD/AP8AAP8A////AP8AAAD/AP8AAP8A /wAA//8A/wD/AAAA/wD/AP///wAA/wD/AP///wD///8A//8A////AAAAAAD/AP8A/wD///////8A AAAA////AP////////////////////////////////////////////////////////////////// //////////////////////////8A//8AAAD/AAAAAP///wAA/wAA/wAAAAD/AAAAAP//AAAAAP8A /wAAAAD///8A/wAAAAD///8A////AP//AP///wAAAAD//wD/AP8A//////8AAAAAAAAA/wD///// //////////////////////////////////////////////////////////////////////////// //////////8A////AP//////////////AP//AP//////////AP//////////////////////AP// AP//////AP//AAD//wD///8AAAAA//8A/wD/AP////////8AAAD///8A//////////////////// /////////////////////////////////////////////////////////////////////////wAA /wD/////////////AP////8A/////////wD//////////////////////wAAAAD//////wAAAP// //8AAP8AAAAAAAD/AP8A/wD///////8AAAAAAP//AP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////AP// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////e//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////4v/////////////////D//////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////3v/////i//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////i//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////8P///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////97///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////3v//////4v////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////8P///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////3v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////i///////D//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////i//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////wAA/////////////wD///// //8A//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8AAAAA/wD/////AAAAAP8A/wAA//8A AP8AAAD/AAAAAAAAAAAAAAD/AAAA/wAAAAAAAAAA//8AAAAA/wAAAAAAAAAA/wAA/wAAAAAAAAAA //////////////////////////////////////////////////////////////////////////// /////////////////////////////wD/AAAAAP8AAP8AAAAAAP8AAAAA//8AAAD/AP///wAAAAAA AAAAAAAA/wAAAP8AAAAAAAAAAAD/AAAAAP8A/wAAAAAAAP8A////AAAAAAD/AP8A//////////// //////////////////////////////////////////////////////////////////////////// /////////////////wAAAAAAAAD///8A/wAA/wAAAAD/AAD/AAAA//8A////////AP////8A//// /////wD/////////////AAD/////////AAD/AP//////AP////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////AAD///////////////////////////////////////////////////// /////////wD/AP///wD/AAAA////AP///////wAAAAAAAAAAAP//AAAAAAAAAAD/AAD//wAA/wAA AAD/AAAA/wAA/wAA/wD/AAAA/wAAAP///wD//wAAAAD/AAAAAAAA//8AAAAA/wD//wD/AAAA/wAA //8AAAD/AAAA/wAAAP8A/wD/AAAAAAAAAP8AAAAA/wD///////////////////////////8A/wAA /wAA/wD/AAD/AAD/AAD///8A/wAA/wAA/wD//wAAAP8AAAD//wAA//8A//8A/wAA/wAAAP8AAP8A //8A/wD/AP8AAAD/////AAD/AP//AP8AAAD/////AAAA//8A/wAA/wAA//8A////AAAA/wAA//8A /wD/AP8A/wD/AAD/AAD/AP8AAP8A////////////////////////////AP8A/wAA/wAAAP8A/wD/ AAAA////AAAAAP8AAP8A//8AAAAAAAAAAP8AAP//AAD/AAD/AAD/AAAA/wD/AAD/AAAAAAD/AAAA /////wAA/wD//wAA//8A/////wAAAAD/AAAA/wAAAAD/AAD//wAAAAD/AAD/AAAA/wAAAP8AAAAA /wAA/wAA/wAA/////////////////////////////wD/AAAA/////wD/AP//////////////AP// ////AP//////////////AP//////////////////////////////////////AP////////8AAAD/ AAAAAP////////////////////////////////////////////8AAAD///////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////u92Z vL27kpKTu5KYkY2Sk7ttvJKStv////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////mLuYtZiTvLW8trxzvI28krWTtpKYtW2NkpK7k5m7mLa8try2 vI28kraSkpK7//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////5KTjUpsvJOYtm27kruNkpK2tpOStryTmbuYtZOSSmy2kruSbbaYmZGSkpm7mLa73ru1tpP/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////7ySvK6Zko21kpK7tZKSkpi7tpmStW28bruSvJK8c7tzkpK1kv////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////5K0cm67u7uStbuSvLVzjbuYjW27//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////227k7v///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////ewr3D3sP///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////88PDw8PDw8PDxCQjw8 PDw8PDw8PDw8PDz//96aeXqZvMLd3t3d4sK8vd3dwt28wt7D//////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////PGBlZmY9ZjxgZWBDZ2ZmbGZmZmZsbWZC ///CWTJ5kq61krW7vLa23La8vLa8tde84v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////zxmbY2SrmdDbWxmZrWuko2Rk5Ftko1tjf//vVlYUpKTvNy8 3bzi3b3D3cK84rzC4v////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////88YJG2rpK1ro2ubG61rrWSkby1krWSrrv//8PDmnp6mZmUvJrCvb3Cvby9w8P/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// PEJmZmBsbWxmbWVmZkOGbWZsZ2xnbGxn/////8PDvb2ZoL2Zvby9vcPDw/////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////D///D3sP/w97///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////wMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAA AALVzdWcLhsQk5cIACss+a4wAAAAiAMAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAA uAAAAAYAAADAAAAABwAAAMgAAAAIAAAA0AAAAAkAAADYAAAACgAAAOAAAAAXAAAA6AAAAAsAAADw AAAAEAAAAPgAAAATAAAAAAEAABYAAAAIAQAADQAAABABAAAMAAAA5QIAAAIAAACkAwAAHgAAABAA AABBNCAyMTAgeCAyOTcgbW0AHgAAAAgAAABOVFQgTUNMAAMAAAA4cQMAAwAAAGcAAAADAAAABwAA AAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAABBCgoACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAEQAAABAAAABUaW1lcyBOZXcgUm9tYW4AEAAAAIJsgnIggm+DU4NWg2KDTgAM AAAAgmyCciCCb5a+kqkADAAAAEFyaWFsIEJsYWNrAAcAAABUYWhvbWEAEQAAAEFyaWFsIFVuaWNv ZGUgTVMACgAAAIJsgnIglr6SqQASAAAAkFaCtYKizN/avt7dw7C8rt0AFgAAAINyg2KDZ4N9g2KD diCDQ4OBgVuDVwAhAAAATWljcm9zb2Z0IFBob3RvIEVkaXRvciAzLjAgUGhvdG8AbAAAAElQdjYv djQgZHVhbCBzdGFjayBjb21tZXJjaWFsIEFEU0wgc2VydmljZSBzcGVjaWZpY2F0aW9uICAtIElF VEYgdjZPUFMgV0cgSW50ZXJpbSBNZWV0aW5nIG9uIFNlcHQuMTgsMjAwMiAtAAcAAAB0b3BpY3MA EAAAAFRoZSBDb21wYW55IE5UVAArAAAATlRUL1ZFUklPIEdsb2JhbCBJUHY2IEJhY2tib25lICYg U29sdXRpb25zABYAAABTcGVjaWZpY2F0aW9uIHN1bW1hcnkAFwAAAFNwZWNpZmljYXRpb24gaGkt bGlnaHQACwAAAEF0IHRoZSBlbmQADBAAAAgAAAAeAAAAFwAAAI5nl3CCs4LqgsSCooLpg3SDSIOT g2cAAwAAAAcAAAAeAAAAFgAAAINmg1WDQ4OTIINlg5ODdoOMgVuDZwADAAAAAQAAAB4AAAAaAAAA loSC342egtyC6oK9IE9MRSCDVIFbg2+BWwADAAAAAgAAAB4AAAASAAAAg1iDiYNDg2ggg16DQ4Nn g4sAAwAAAAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8lAAAAFAAAAF/AkeNKSgIADQD0AwMAnQBNSVlBS0FX QSBTaGluCAAAAE0ASQBZAEEASwBBAFcAQQAgAFMAaABpAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAA AAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAA GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAo AAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA AAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAA AEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAA UwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABh AAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8A AABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAA AH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAA jAAAAI0AAACOAAAAjwAAAJAAAACRAAAAkgAAAJMAAAD+////lQAAAJYAAACXAAAAmAAAAJkAAACa AAAAmwAAAJwAAACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgA AACpAAAAqgAAAKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAA ALcAAAC4AAAAuQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAA xQAAAMYAAADHAAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADT AAAA1AAAANUAAADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEA AADiAAAA4wAAAOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAA APAAAADxAAAA8gAAAPMAAAD0AAAA9QAAAPYAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA /gAAAP8AAAAAAQAAAQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAM AQAADQEAAA4BAAAPAQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoB AAAbAQAAHAEAAB0BAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEA ACkBAAAqAQAAKwEAACwBAAAtAQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAA NwEAADgBAAA5AQAAOgEAADsBAAA8AQAAPQEAAD4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAABF AQAARgEAAEcBAABIAQAASQEAAEoBAABLAQAATAEAAE0BAABOAQAATwEAAFABAABRAQAAUgEAAFMB AABUAQAAVQEAAFYBAABXAQAAWAEAAFkBAABaAQAAWwEAAFwBAABdAQAAXgEAAF8BAABgAQAAYQEA AGIBAABjAQAAZAEAAGUBAABmAQAAZwEAAGgBAABpAQAAagEAAGsBAABsAQAAbQEAAG4BAABvAQAA cAEAAHEBAAByAQAAcwEAAHQBAAB1AQAAdgEAAHcBAAB4AQAAeQEAAHoBAAB7AQAAfAEAAH0BAAB+ AQAAfwEAAIABAACBAQAAggEAAIMBAACEAQAAhQEAAIYBAACHAQAAiAEAAIkBAACKAQAAiwEAAIwB AACNAQAAjgEAAI8BAACQAQAAkQEAAJIBAACTAQAAlAEAAJUBAACWAQAAlwEAAJgBAACZAQAAmgEA AJsBAACcAQAAnQEAAJ4BAACfAQAAoAEAAKEBAACiAQAAowEAAKQBAAClAQAApgEAAKcBAACoAQAA qQEAAKoBAACrAQAArAEAAK0BAACuAQAArwEAALABAACxAQAAsgEAALMBAAC0AQAAtQEAALYBAAC3 AQAAuAEAALkBAAD+////uwEAALwBAAC9AQAAvgEAAL8BAADAAQAAwQEAAMIBAADDAQAAxAEAAMUB AADGAQAAxwEAAMgBAADJAQAAygEAAMsBAADMAQAAzQEAAM4BAADPAQAA0AEAANEBAADSAQAA0wEA ANQBAADVAQAA1gEAANcBAADYAQAA2QEAANoBAADbAQAA3AEAAN0BAADeAQAA3wEAAOABAADhAQAA /v///+MBAADkAQAA5QEAAOYBAADnAQAA6AEAAOkBAAD+////6wEAAOwBAADtAQAA7gEAAO8BAADw AQAA8QEAAP7////9/////f////3////9////9wEAAP7///////////////////////////////// /////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAA AAAAAAAAAAAAAAAA/v///wAAAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyiYBAAAAAABDAHUAcgByAGUAbgB0ACAAVQBz AGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD///// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOoBAAAAEAAAAAAAAAUAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAoAAIBAgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAugEA AOxPAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACUAAAAbkoCAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkA bgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOIBAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////// ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA= ----Next_Part(Thu_Sep_19_07:42:43_2002_181)---- From owner-v6ops@ops.ietf.org Wed Sep 18 20:03:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04209 for ; Wed, 18 Sep 2002 20:03:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ronm-000Jkx-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 17:04:14 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17ronh-000Jkk-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 17:04:09 -0700 Received: from dhcp64-134-140-111.wgs.sjc.wayport.net (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8J0HfE18908 for ; Wed, 18 Sep 2002 20:17:41 -0400 (EDT) Date: Wed, 18 Sep 2002 20:01:34 -0400 From: Marc Blanchet To: v6ops@ops.ietf.org Subject: input to the scenario design team for the analysis of solutions. Message-ID: <424550000.1032393694@classic.viagenie.qc.ca> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I would like to describe in a nutshell the TSP protocol that could be useful in some/many possible situations described in the scenario documents. TSP (Tunnel setup protocol) is a control channel established between entities that need a tunnel. The control protocol enables the negociation of: - tunnel parameters (encapsulated and encapsulating protocol IP addresses: ipv6, ipv4), as well as other parameters: - dns delegation info - prefix assignment (in this case, the requesting tsp client would be a router with a network behind) - routing peering if needed This negociation: - is based on authentication of parties (anonymous is also possible) - could be used for IPv6 over IPv4, IPv6 over IPv4-nat, IPv4 over IPv6, any over any TSP could be applied as an optional feature with another mechanism (eg: isatap with tsp document made by Fred Templin) TSP has been implemented by many implementors and is used in production in freenet6.net. For example, freenet6.net handles many many thousands of users, and handles tunnel requests, dns delegation and prefix assignment automatically. The tsp client is included in many open source operating systems distributions. As a user, I have a laptop that is moving over different networks: ipv4 global address, ipv4 nat address (hotels,...), ipv6-only network, dual-ip network. All these are handled by tsp for me, without any manual intervention. It gives me stability of my IPv6 prefix which is always working. I hope that design teams will look at the documents to see if the tsp solution works for their requirements. draft-blanchet-ngtrans-tsp-applicability-00.txt (applicability, overview) draft-vg-ngtrans-tsp-01.txt (tsp protocol) draft-vg-ngtrans-tsp-v6v4profile-01.txt (v6 over v4) draft-blanchet-ngtrans-tsp-dstm-profile-01.txt (ipv4 over ipv6 with tsp) draft-parent-blanchet-ngtrans-tsp-teredo-00.txt (ipv6 over ipv4 with nat traversal) draft-templin-ngtrans-isatap-tsp-00.txt (isatap with tsp) Marc. From owner-v6ops@ops.ietf.org Wed Sep 18 20:09:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04303 for ; Wed, 18 Sep 2002 20:09:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rouX-000KEh-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 17:11:13 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rouR-000KEH-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 17:11:07 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8J0B3i06300; Thu, 19 Sep 2002 03:11:03 +0300 Date: Thu, 19 Sep 2002 03:11:03 +0300 (EEST) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org Subject: Re: input to the scenario design team for the analysis of solutions. In-Reply-To: <424550000.1032393694@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Marc Blanchet wrote: > TSP has been implemented by many implementors [...] Could you elaborate? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 20:13:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04376 for ; Wed, 18 Sep 2002 20:13:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17roxw-000KRa-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 17:14:44 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17roxr-000KRO-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 17:14:40 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 412397B9; Thu, 19 Sep 2002 09:14:25 +0900 (JST) To: v6ops@ops.ietf.org X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: memo, 1st day PM From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 09:14:25 +0900 Message-Id: <20020919001425.412397B9@starfruit.itojun.org> X-Spam-Status: No, hits=1.6 required=5.0 tests=DOUBLE_CAPSWORD,PORN_3 version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk [not a official minutes] shin miyakawa (operator's input) commercial IPv4/v6 dual stack ADSL operation tokyo only, $6/mo, 8-10Mbps DSL existing application - IPv4 new applications (VoIP, VCR, whatever) - IPv6 specification between NTT and router vendors translate spec into informational RFC? RADIUS -1- BAS -2- DSL router -3- host 1: RADIUS/IPv6 2: PPP(IPv6CP), DHCPv6 <-- this part, NTT cares 3: stateless addr conf, DNS discovery (up to customer) 1 IPv4 dynamic, /48 IPv6 static IPv4 addr change - reassignment at POP, whatever IPv6 friendly DNS server customer: primary server (IPv6 only) NTT: secondary server (IPv4/IPv6) hesham: where to buy router? shin: yes, there are vendors (JP and non-JP). thaler: ::53, subnet number = 0x0000? shin: yes. ?: charging model? per-address? shin: no, not for IPv6. shin: pressure for preserving IPv4 addr is severe in JP translate it, and make v6ops wg document (informational) hinden: not the only way to realize DSL service (clarify) shin: correct, example scenario itojun: change control? shin: ok important thing: use same mechanism everywhere include it into ISP document ?: what kind of other magic numbers are you using? shin: ::1, ::2 ?: there are other translators involved in SMTP and such? shin: no, customers use IPv4 (dynamic) addr intro to breakout session cellular scenarios document changes introduction to relevant 3GPP concepts added PDP type PPP added picture added this document should be pretty stable by now GPRS scenarios dual stack -> IPv4/v6 nodes IPv6 only --IPv4 cloud-- IPv6 only IPv4 only --IPv6 cloud-- IPv4 only IPv6 only -> IPv4 only IPv4 only -> IPv6 only IMS scenarios target dates 04/2002 - first rev 09/2002 - second rev design team started 05/2002 first solution draft published IETF54 09/2002 second draft solution draft finalized IETF55/end of 2002 could this document be taken as a WG item? agenda for drafting session solution, document introduction nat-pt issues scenario walk-through GPRS scenarios transition scenarios with IMS wrap-up randy: confused about 2 documents environment, what we need, how do we solve problems bound: do we want to do the same for 3GPP-2? soi: not sure hesham: 3GPP-2 haven't done with any of IPv6 thingy yet (especially mobile-ip6) soi: multiple document for 3GPP and 3GPP-2? should be fine. sense of room people willing to review/help improve document? (modulo design team) - there are. read? - a lot accept as starting point? - a lot should not accept as starting point? - none ISP scope of work define the problem set of scenarios core/backbone broadband hybrid fiber coax/cable broadband dslmnarrowband dialup ethernet to the home/home networking internet exchange points security (detection/prevention) network management outline toplogy physical, logical hardware routers, switches, cpe routing igp, egp, irr, addressing, nat, aggregation policing filtering, traffic engineering security IDS, prevention network management out of band conf tools, snmp hosting gear DNS, radius, tacacs, mail, tools, cacheing updates since IETF54 accepted as ngtrans wg document 01 draft submitted detailed discussion on DSL renamed to v6ops remain personal draft until all sections filled in added IX section all sections should be filled in by IETF55 breakout review outline review existing document itojun: DSL detail maybe too much rob: DSL detail was helpful unmanaged scenario (scoping) evaluation (analysis) scope: exploring the problem space applications what are the application needs? local, client, p2p, server presented in yokohama phases(X), stages(X), cases of transition A: gateway is IPv4 only B: gateway & ISP dual stack C: gateway dual stack, ISP v4 only D: gateway dual stack, ISP v6 only A: consensus - this is a real need, not all gateways can be easily upgraded hosts ipv4 or dual stack applications: client, p2p with outside connectivity requirement automatic tunnelling over UDP aim for minimal server requirement naming requirement DNS access over v4 reverse lookup for client apps B: main line transition case hosts: v4 only, dual stack, v6 only apps: local applications across the stacks ipv6 only clients access ipv4 services question mark: ipv4 client access ipv6 services backward vs forward compatibility p2p with outside = single stack ipv6 servers accessible from outside connectivity requirements unmanaged network is dual stack need "ipv6 prefix delegation" to gateway some form of translation between local ipv4 and local ipv6 some form of translation between local ipv6 and global ipv4 services naming requirements name lookup service independent of protocol dual stack home must get same answer if querying over v4 or v6 local applications must work shadow of ipv4 only hosts in ipv6, and vice versa not just a DNS issue (SLP, proprietary naming) need to 'register' autoconfigured ipv6 addr direct lookup (local/server apps) reverse lookup (client apps) rob: adhoc needs another analysis bound: military case hinden: military is more like adhoc? ?: some people don't consider it important to make v4-only and v6-only interwork. dualstack short-lived or long-lived? rob: (some comment on v4/v6 interwork) C: mostly same requirement as case B connectivity gateway need to "self provision" a prefix, use some form of automatic tunnelling naming use DNSv4 for both A and AAAA lookup may need to register with 3rd party service need solution for reverse lookup D: case of "green field" isp same appliation requirement as case B connectivity access to IPv4 internet through IPv6 this cannot be done with a gateway based system namging DNS access over ipv6 evaluation of mechanisms still very sketchy connectivity A: teredo B: RA proxy vs explicit delegation, variation of SIIT/NAT-PT C: 6to4 D: network based variations of SIIT, DSTM alain: NAT64? rob: NAT-PT/SIIT/NAT64, what is same and what is different? they are basically the same beast. naming discovery of the DNS server by IPv6 hosts DHCPv6, LLMNR, or reserved IPv6 addrss local naming for IPv6 applications dynamic update of server, or LLMNR naming bridge for local applications variation of NAT-PT, bridges to LLMNR, etc access to IPv4 servers configured SIIT prefix in IPv6 vs variations of NAT-PT mechanisms, continued - breakout session! wg item? scenario document - accepted by ngtrans, reasonable to assume next revision gonna be wg item ?: design team consensus != wg consensus mar: yes shin: definition of "scope", prefix delegation/accounting could be ISP, or unmanaged home? mar: all of groups will touch each other somewhere, somehow (scenario only) read? - alot people willing to review/help improve document? (modulo design team) - pretty good accept as wg item? - alot enterprise still a young group, no way for this document to become wg item what we have done? definition of an enterprise define our assumptions what is our strategy? discuss scenarios first then point of transition randy: who is administer network? goals focus on defining: set of technology scenarios set of transitioni mechanisms needed by different scenarios set of tools needed for ipv6 deployment within the enterprise focus on defining a template for how existing/new transition mechanisms and tools could be used in the enterprise network scenarios non-goals (missed) enterprise connected to ISP actively managed multiple independent networks may also have mobile ip users accessing network within the enterprise or from outside enterprise can be a large business small office business itojun: mobile-ip, does it mean mobile-ip, or roaming laptop? huitema: remove protocol/techs while working on scenario. that biases your thought. ?: multihoming? - possible. assumptions rate/methods for adoption of ipv6 will vary no one can tell users how to transition, they will all do it differently some users have hardly any ipv4 addresses some have plenty of them some users will move right to ipv6 not later simply because it is easier need to state our assumptions vs isp, unmanaged and 3gpp though these will apply to the enterprise too strategy out initial consensus strategy is to discuss the scenarios first then deal with the technical and transitional details below the scenarios the following scenarios list is not complete 1: enterprise, with an existing ipv4 network, wants to turn on ipv6 for a group of 100 clients that exist at two geographic sites ipv6 clients need to commuinicate with each other , but still need access to ipv4 based services what needs to be done to enable this deployment and where which transitoin technology are applicable? 2: enterprise, ipv4 existing, wireless services - optimize support mobile ip and choose to make this service ipv6 only mobile ipv6 only node needs to still need access to ipv4 based services provided 3: multi-site enterprise has deployed ipv4-nat withoverlapping private addrss ranges to deploy peer-to-peer application deployed they update OS to support both ipv4 and ipv6 what needs to be done to enable this deployment and where which transition technologies are applicable as they begin using the application? what chhanges or additional technologies are applicable when some isp for some site, but not all sites, offers native ipv6 service? 4: more than one business unit, each unit run differently one of the business unit decide wireless, p2p conferencing, and keep ipv4 apps 5: two large enterprises using ipv4-nat merge with the consequence that large segments of private network address space overlap to allow the network operations to merge they decide to deploy ipv6 across the network core and support infrastructure first to further integrate the systems, what transition technologies are applicable to the end nodes? plan of action specify and define the scenarios in an incremental fashion small network/single building/location medium size/campus size/single location larger network/campus environment/multiple location wireless/mobiltiy incorporation (which fits into any of the previous casese) specify points of transition software points of transition enterprise will be required to determine what software will be extended affected by transition must be managed this will define the policy for the enterprise dns, routing, autoconf, security, application/api, address scoping, netman, address plan tools for config routing, dns, v4 address allloc, v6 address alloc, vpn/tunnel, mobile node cellular - 8 ISP - 13 unmanaged - 8 enterprise - 16 From owner-v6ops@ops.ietf.org Wed Sep 18 20:18:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04527 for ; Wed, 18 Sep 2002 20:18:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rp3b-000Kqp-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 17:20:35 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17rp3X-000KqX-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 17:20:32 -0700 Received: from dhcp64-134-140-111.wgs.sjc.wayport.net (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8J0XRE19112; Wed, 18 Sep 2002 20:33:28 -0400 (EDT) Date: Wed, 18 Sep 2002 20:17:20 -0400 From: Marc Blanchet To: huitema@microsoft.com, satapati@cisco.com cc: v6ops@ops.ietf.org Subject: comment on unmanaged analysis presentation/doc Message-ID: <434870000.1032394640@classic.viagenie.qc.ca> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA04527 draft-huitema-ngtrans-unmaneval-00.txt case A where IPv4 nat is present: - teredo is one mechanism. In fact, what is needed is ipv6 over udp-ipv4 (i.e. nat traversal). - in this space, tsp with udp-ipv4 encapsulation is also a viable solution. It also enables the unmanaged network to receive automatic data needed for the unmanaged network: i.e. ipv6 network prefix for example. (reference = draft-parent-blanchet-ngtrans-tsp-teredo-00.txt). - the unmanaged draft says: "A variant of the [TEREDO] technology could be used to establish tunnels over UDP when the client cannot use a global IPv4 address; this variant is however not standardized." (if this text refers to our draft, then the comment is not appropriate: i.e. the variant is not standardized. teredo is also not standardized yet.) 3.1.7 DNS delegation tsp does this. should be looked at. I could provide some text if you want. Marc. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Wed Sep 18 20:47:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05408 for ; Wed, 18 Sep 2002 20:47:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rpUo-000Mbm-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 17:48:42 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rpUj-000Maz-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 17:48:38 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8J0l8C06593; Thu, 19 Sep 2002 03:47:08 +0300 Date: Thu, 19 Sep 2002 03:47:06 +0300 (EEST) From: Pekka Savola To: Marc Blanchet cc: huitema@microsoft.com, , Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: <434870000.1032394640@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Marc Blanchet wrote: > case A where IPv4 nat is present: > - teredo is one mechanism. In fact, what is needed is ipv6 over udp-ipv4 > (i.e. nat traversal). > - in this space, tsp with udp-ipv4 encapsulation is also a viable > solution. It also enables the unmanaged network to receive automatic data > needed for the unmanaged network: i.e. ipv6 network prefix for example. > (reference = draft-parent-blanchet-ngtrans-tsp-teredo-00.txt). > - the unmanaged draft says: "A variant of the [TEREDO] technology could be > used to establish > tunnels over UDP when the client cannot use a global IPv4 address; > this variant is however not standardized." > (if this text refers to our draft, then the comment is not appropriate: > i.e. the variant is not standardized. teredo is also not standardized yet.) Teredo does more than just sets up a tunnel. In the case of NAT, in particular, keeping the pipe open is also an important task. The draft does not explicitly address this, I believe. Further discussion on teredo/tsp should probably be sent to ngtrans. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 20:48:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05436 for ; Wed, 18 Sep 2002 20:48:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rpUF-000MWC-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 17:48:07 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rpUC-000MW1-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 17:48:04 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 7B1607B9; Thu, 19 Sep 2002 09:47:49 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Thu, 19 Sep 2002 00:52:09 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: raw thoughts on v6 firewalls From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 09:47:49 +0900 Message-Id: <20020919004749.7B1607B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I don't think v6 firewalls can be killed. They're a mechanism to ensure >some form of security policy; trusting end nodes to do the right thing is >not enough. > >But there are problems with v6 firewalling. I've been trying to get >around to writing a draft for a year or so now but never did it (further >than the baseline summary of the content): perhaps now it's a better time. i understand we can't kill firewall. they need to be more flexible - like allowing inbound connection for p2p protocols and such. but then, we may be opening a big can of worms... >One potentially major deployment issue is how the firewall is supposed to >handle packets where extension header contains a header it does not not >recognize and thus cannot parse e.g. UDP/TCP headers. i'm trying to implement IPv6 stateful inspection into OpenBSD PF, but having no time to do so... itojun From owner-v6ops@ops.ietf.org Wed Sep 18 21:04:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05827 for ; Wed, 18 Sep 2002 21:04:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rpl0-000Ned-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 18:05:26 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17rpkw-000Ne9-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 18:05:22 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA17675; Wed, 18 Sep 2002 18:05:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8J15JM15827; Wed, 18 Sep 2002 18:05:19 -0700 X-mProtect: <200209190105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9YFQwf; Wed, 18 Sep 2002 18:05:17 PDT Message-ID: <3D89262A.3060407@iprg.nokia.com> Date: Wed, 18 Sep 2002 18:19:38 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: v6ops@ops.ietf.org CC: Marc Blanchet Subject: Re: input to the scenario design team for the analysis of solutions. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marc Blanchet wrote: > draft-templin-ngtrans-isatap-tsp-00.txt (isatap with tsp) Minor note on Marc's message. The above-mentioned document is only a placeholder that will be updated when Marc and I co-author a replacement (as we have discussed in private e-mails.) The placeholder is not suitable for consideration by any design teams at this point in time. In the meantime, when reviewing the other TSP-related documents, please also consider the following individual submission entitled "ISATAP Interactions with TSP": http://www.ietf.org/internet-drafts/draft-templin-interact-00.txt Fred Templin ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Wed Sep 18 21:09:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05870 for ; Wed, 18 Sep 2002 21:09:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rpqK-000O27-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 18:10:56 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rpqH-000O1u-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 18:10:53 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8J1AlW07064; Thu, 19 Sep 2002 04:10:47 +0300 Date: Thu, 19 Sep 2002 04:10:47 +0300 (EEST) From: Pekka Savola To: Marc Blanchet cc: v6ops@ops.ietf.org, , , =?ISO-8859-1?Q?Jean-Fran=E7ois_Boudreault?= Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt In-Reply-To: <302330000.1032383002@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Wed, 18 Sep 2002, Marc Blanchet wrote: > -- mercredi, septembre 18, 2002 23:32:17 +0300 Pekka Savola > wrote/a écrit: > > > Implemented != ratified in the protocol (specification). > > > > There are probably code bases which have nothing to do with Dave Mills'. > > you are right. You are suggesting which process? Re-publish the old refid internet-draft or or create a new one; one indended to Update the NTP RFC. Perhaps D. Mills as the NTP author and/or apps Area Director could have some ideas how to proceed. I think you agree that we need to keep this issue up and open until we're a bit farther in the NTP for v6 extension specification process. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 18 21:13:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05915 for ; Wed, 18 Sep 2002 21:13:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rpuT-000OGk-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 18:15:13 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17rpuQ-000OGZ-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 18:15:10 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 335147B9; Thu, 19 Sep 2002 10:14:55 +0900 (JST) To: Pekka Savola Cc: Marc Blanchet , v6ops@ops.ietf.org, phil@nesser.com, ntp@viagenie.qc.ca, =?ISO-8859-1?Q?Jean-Fran=E7ois_Boudreault?= In-reply-to: pekkas's message of Thu, 19 Sep 2002 04:10:47 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt From: Jun-ichiro itojun Hagino Date: Thu, 19 Sep 2002 10:14:55 +0900 Message-Id: <20020919011455.335147B9@starfruit.itojun.org> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >On Wed, 18 Sep 2002, Marc Blanchet wrote: >> -- mercredi, septembre 18, 2002 23:32:17 +0300 Pekka Savola >> wrote/a $BqD(Brit: >> >> > Implemented != ratified in the protocol (specification). >> > >> > There are probably code bases which have nothing to do with Dave Mills'. >> >> you are right. You are suggesting which process? > >Re-publish the old refid internet-draft or or create a new one; one >indended to Update the NTP RFC. > >Perhaps D. Mills as the NTP author and/or apps Area Director could have >some ideas how to proceed. > >I think you agree that we need to keep this issue up and open until we're >a bit farther in the NTP for v6 extension specification process. this is a slide i will be using tomorrow. hope it is useful. itojun %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page 32bit IDs A lot of protocols use 32bit IDs 32bit IDs = management headaches, scalability limitation What is the domain of uniqueness? OSPF - within an AS BGP - worldwide uniqueness needed How wide does ID need to be? 128bit - global IPv6 address can be used 64bit - EUI64 maybe? (not guaranteed to be unique) 64bit - 32bit AS number + 32bit serial (management headache) 32bit - insufficient (32bit AS numbers) From owner-v6ops@ops.ietf.org Wed Sep 18 21:18:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05994 for ; Wed, 18 Sep 2002 21:18:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rpyx-000OdN-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 18:19:51 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17rpyt-000Od0-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 18:19:48 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8J1Jh407137; Thu, 19 Sep 2002 04:19:43 +0300 Date: Thu, 19 Sep 2002 04:19:43 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: v6ops@ops.ietf.org, Subject: Re: ISP scenarios comments (multicast) In-Reply-To: <3D88EC5A.1B69FB82@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002, Brian Haberman wrote: > Pekka Savola wrote: > > > > On Wed, 18 Sep 2002, bkhabs wrote: > > > > > Pekka, > > > > > > >On Wed, 18 Sep 2002 18:25:58 0300 (EEST) Pekka Savola > > > wrote. > > > > * multicast issues > > > > - support is yet a bit .. raw or non-existant. > > > > > > Are you talking standards or implementations? > > > > Both. > > > > As for standards, there is the problem with MSDP. Another partially > > related one is related to site-local group scoping. There needs to be > > some feature like 'bsr-border' to site-local scopes to work properly > > inside only one PIM domain, I think. > > I brought up the issue of site-locals and PIM in a PIM for v6 draft a > few years ago. The PIM group came to consensus that in order to use > site-locals in certain PIM messages (e.g. C-RP or Bootstrap) then a > PIM domain border MUST be the same as the site-local border. > > That draft was eventually merged into the new pim draft. Ok; this is still a bit problematic with the one PIM domain requirement.. :-/ > > > > - should we focus on SSM only > > > > > > For the short term definitely. > > > > I believe most don't realize that's the only option at the moment. > > Agreed. The interesting thing is that, just like in v4, multicast > in v6 is lagging in development effort. Yes. This is sad as SSM video broadcasts could be one "killer" application for IPv6 (it would be available for v4 too.. :-) > Another possibility is whether or not RFC 3306 can be exploited to > help with the issue of RP location and such. Haven't had much time > to look into that though. This might be an interesting point to develop more. It's quite possible if we can hard-code assumptions about address assignment for the RP there. Possibly through an additional bit flag in the address. This would have to go to the PIM implementation then, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 00:20:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10060 for ; Thu, 19 Sep 2002 00:20:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rslQ-000A7k-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 21:18:04 -0700 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #1) id 17rsl7-000A7M-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 21:17:45 -0700 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8J4IAM19257 for ; Wed, 18 Sep 2002 23:18:10 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 18 Sep 2002 23:17:43 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 21:16:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: transitioning server farms to IPv6 Date: Wed, 18 Sep 2002 21:16:19 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE01771C9C@mvebe001.americas.nokia.com> Thread-Topic: transitioning server farms to IPv6 Thread-Index: AcJfk0xK1m+1SwGnQyOS2ba2YIpjPA== From: To: X-OriginalArrivalTime: 19 Sep 2002 04:16:20.0737 (UTC) FILETIME=[4ED77710:01C25F93] X-Spam-Status: No, hits=0.5 required=5.0 tests=NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA10060 Which of these sub-groups should be responsible for how to build a large server farm? Web or email servers, for example. Simple ones are obvious, but more complex ones involving firewalls, server load balancers, round-robin DNS, fault- tolerant routing, PKI, LDAP, etc. may or may not be straightforward (though maybe the issues are more about product selection/availability than technical architecture?). The SMTP operational experience doc is good one (thanks, Nakamura-san and itojun); which group would it fall into? The "enterprise" group would seem to be the closest, but even there the focus is different. I also haven't yet met anyone from e.g. Yahoo! or ebay here at the meeting; do we have folks with _that_ kind of operational experience involved? --Rod From owner-v6ops@ops.ietf.org Thu Sep 19 00:40:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11288 for ; Thu, 19 Sep 2002 00:40:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rt7H-000Bck-00 for v6ops-data@psg.com; Wed, 18 Sep 2002 21:40:39 -0700 Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.36 #1) id 17rt7A-000BcL-00 for v6ops@ops.ietf.org; Wed, 18 Sep 2002 21:40:32 -0700 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8J4eMT28062 for ; Thu, 19 Sep 2002 07:40:23 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 19 Sep 2002 07:40:27 +0300 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 19 Sep 2002 07:40:28 +0300 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Sep 2002 21:40:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: raw thoughts on v6 firewalls Date: Wed, 18 Sep 2002 21:40:11 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE01771CA0@mvebe001.americas.nokia.com> Thread-Topic: raw thoughts on v6 firewalls Thread-Index: AcJfXeZ6C/D2kv6WT3OflktigU2fqAANq6zQ From: To: , X-OriginalArrivalTime: 19 Sep 2002 04:40:16.0153 (UTC) FILETIME=[A66A9090:01C25F96] X-Spam-Status: No, hits=0.5 required=5.0 tests=NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA11288 Unless I'm suffering total brain failure (never out of the question), every extension header is supposed to have the length in the same place, and one use is exactly that reason. grepgrepgrep...from RFC2460: With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. There, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or the upper-layer header if no extension header is present. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. I suspect that someone excessively literal could read this as a prohibition on intermediate nodes *looking* any deeper into the packet than the hop-by-hop, which would effectively kill firewalls and complex packet classification for QoS, but in practice we *know* that firewalls will get built. I can't off hand think of any specific reason that the classical- music-ignorant Superdumb Firewall Model 88888 couldn't skip the "Beethoven extension header" that plays the Fifth on iFruit 99999 hosts and go on to the TCP header, but there may be a corner case buried there somewhere. It's worth a look. Firewall products are starting to appear; I wonder how they will handle extension headers they don't recognize. My guess is they will discard the packet, which is the paranoid (read: "correct if you're a firewall") thing to do. Pekka, are there other v6-specific firewall issues, and is this the right place to discuss them? --Rod -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: Wednesday, September 18, 2002 2:52 PM To: v6ops@ops.ietf.org Subject: raw thoughts on v6 firewalls Hi, Regarding v6ops meeting discussion.. I don't think v6 firewalls can be killed. They're a mechanism to ensure some form of security policy; trusting end nodes to do the right thing is not enough. But there are problems with v6 firewalling. I've been trying to get around to writing a draft for a year or so now but never did it (further than the baseline summary of the content): perhaps now it's a better time. One potentially major deployment issue is how the firewall is supposed to handle packets where extension header contains a header it does not not recognize and thus cannot parse e.g. UDP/TCP headers. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 05:04:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27456 for ; Thu, 19 Sep 2002 05:04:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rxDJ-0002Wi-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 02:03:09 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17rxDD-0002Uf-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 02:03:04 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17rxBf-0001XH-00; Thu, 19 Sep 2002 10:01:27 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17rxBf-0001XC-00; Thu, 19 Sep 2002 10:01:27 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA25176; Thu, 19 Sep 2002 10:01:24 +0100 Message-ID: <3D899267.5538DE52@hursley.ibm.com> Date: Thu, 19 Sep 2002 11:01:27 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Keith Moore CC: Paul Vixie , v6ops@ops.ietf.org Subject: Re: renumbering References: <200209182158.g8ILwK020251@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit below... Keith Moore wrote: > > > Any application author who wants to make their > > work NAT-unfriendly can't be -- and shouldn't be -- stopped. But as far as > > the core protocols go, I think we should do a better job avoiding moralism > > tham IPsec did. > > well, let's be clear here. the argument about NAT isn't a moral argument. > it's about the flexibility of the network to support a variety of > applications, reliability, network management, and user support issues. if > it looks like a moral argument to some people it's just because the deeper > technical and economic issues are not immediately obvious to everyone. > > it's hard to imagine that any authors "want" to make their work NAT-unfriendly. > however for some applications there are not good, or even feasible, > alternatives within the current internet architecture, and it's very difficult > to retro-fit the current architecture to provide such alternatives. > (see draft-moore-nat-tolerance-recommendations-00.txt) > > just because NAT shifts some burdens from network operators to applications > implementors, doesn't mean that it actually solves any problems - it just > moves the problems to a group of people who are fundamentally less able > to solve them. > > btw, I'm fully in agreement that people will use NATv6 or simply avoid v6 > if we don't make renumbering fairly painless. and we really need *some* WG > to seriously tackle that problem. perhaps this is the one? Perhaps, but the real point is that with AAAA records, the main need is for tools not standards - specifically, tools to perform bulk updates of a site's DNS table. Many sites and enterprises have such tools already and adapting them to IPv6 is straightforward enough, but sites that don't have such a tool (and therefore probably don't have an organized host database or even an organized host naming strategy) will find IPv6 renumbering almost as obnoxious as IPv4 renumbering. This matters. Paul is being pragmatic, but if the NAT fungus infects IPv6 deployment we will have painted IPv6 into a corner. So, still being pragmatic, how can we stimulate the creation of renumbering tools (especially DNS bulk renumbering tools)? Brian From owner-v6ops@ops.ietf.org Thu Sep 19 05:05:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27474 for ; Thu, 19 Sep 2002 05:05:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rxFx-0002mf-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 02:05:53 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17rxFt-0002mT-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 02:05:50 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17rxFs-0001ec-00; Thu, 19 Sep 2002 10:05:48 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17rxFs-0001eX-00; Thu, 19 Sep 2002 10:05:48 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA25608; Thu, 19 Sep 2002 10:05:45 +0100 Message-ID: <3D899372.68397326@hursley.ibm.com> Date: Thu, 19 Sep 2002 11:05:54 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Rod.VanMeter@nokia.com CC: pekkas@netcore.fi, v6ops@ops.ietf.org Subject: Re: raw thoughts on v6 firewalls References: <4D7B558499107545BB45044C63822DDE01771CA0@mvebe001.americas.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This isn't v6 specific, but we should encourage the notion that IPv6 firewalls should support MIDCOM pinholes as a mandatory feature (like IPv6 stacks are supposed to support IPSEC as a mandatory feature). That will allow firewalls to co-exist with e2e IPSEC. It would help if the MIDCOM protocol was already defined, of course. Brian Rod.VanMeter@nokia.com wrote: > > Unless I'm suffering total brain failure (never out of > the question), every extension header is supposed to have > the length in the same place, and one use is exactly that > reason. > > grepgrepgrep...from RFC2460: > > With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header. > There, normal demultiplexing on the Next Header field of the IPv6 > header invokes the module to process the first extension header, or > the upper-layer header if no extension header is present. The > contents and semantics of each extension header determine whether or > not to proceed to the next header. Therefore, extension headers must > be processed strictly in the order they appear in the packet; a > receiver must not, for example, scan through a packet looking for a > particular kind of extension header and process that header prior to > processing all preceding ones. > > I suspect that someone excessively literal could read this as > a prohibition on intermediate nodes *looking* any deeper into the > packet than the hop-by-hop, which would effectively kill firewalls > and complex packet classification for QoS, but in practice we *know* > that firewalls will get built. > > I can't off hand think of any specific reason that the classical- > music-ignorant Superdumb Firewall Model 88888 couldn't skip the > "Beethoven extension header" that plays the Fifth on iFruit > 99999 hosts and go on to the TCP header, but there may be a corner > case buried there somewhere. It's worth a look. > > Firewall products are starting to appear; I wonder how they will handle > extension headers they don't recognize. My guess is they will discard > the packet, which is the paranoid (read: "correct if you're a firewall") > thing to do. > > Pekka, are there other v6-specific firewall issues, and is this > the right place to discuss them? > > --Rod > > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 18, 2002 2:52 PM > To: v6ops@ops.ietf.org > Subject: raw thoughts on v6 firewalls > > Hi, > > Regarding v6ops meeting discussion.. > > I don't think v6 firewalls can be killed. They're a mechanism to ensure > some form of security policy; trusting end nodes to do the right thing is > not enough. > > But there are problems with v6 firewalling. I've been trying to get > around to writing a draft for a year or so now but never did it (further > than the baseline summary of the content): perhaps now it's a better time. > > One potentially major deployment issue is how the firewall is supposed to > handle packets where extension header contains a header it does not not > recognize and thus cannot parse e.g. UDP/TCP headers. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Thu Sep 19 05:58:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28497 for ; Thu, 19 Sep 2002 05:58:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ry5O-0005t5-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 02:59:02 -0700 Received: from [202.28.97.6] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17ry5K-0005rH-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 02:58:58 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8J9wU321587; Thu, 19 Sep 2002 16:58:34 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8J9wFK28839; Thu, 19 Sep 2002 16:58:18 +0700 (ICT) From: Robert Elz To: Rod.VanMeter@nokia.com cc: pekkas@netcore.fi, v6ops@ops.ietf.org Subject: Re: raw thoughts on v6 firewalls In-Reply-To: <4D7B558499107545BB45044C63822DDE01771CA0@mvebe001.americas.nokia.com> References: <4D7B558499107545BB45044C63822DDE01771CA0@mvebe001.americas.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Sep 2002 16:58:15 +0700 Message-ID: <28837.1032429495@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Wed, 18 Sep 2002 21:40:11 -0700 From: Message-ID: <4D7B558499107545BB45044C63822DDE01771CA0@mvebe001.americas.nokia.com> | Unless I'm suffering total brain failure (never out of | the question), every extension header is supposed to have | the length in the same place No, they're not. Most probably will, but there's no guarantee that things will always be that way - if only because the standard layout puts a (smallish) length limit on the size of extension headers. These things are parsable only if you know their individual syntax. This (aside from its effect on firewalls) is one of the reasons that new headers are so hard to deploy, and why there's a pretty good chance, that, apart from new application protocols, there never will be any new ones now - anything new will be turned into an option instead. kre From owner-v6ops@ops.ietf.org Thu Sep 19 07:57:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00977 for ; Thu, 19 Sep 2002 07:57:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17rzvc-000CoE-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 04:57:04 -0700 Received: from [149.99.32.11] (helo=mail2) by psg.com with esmtp (Exim 3.36 #1) id 17rzvX-000Co3-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 04:56:59 -0700 Received: from ATP2 (unverified [149.99.32.51]) by mail2 (Rockliffe SMTPRA 4.2.2) with ESMTP id ; Thu, 19 Sep 2002 05:27:27 -0700 Message-ID: <4547540.1032436716750.JavaMail.Administrator@ATP2> Date: Thu, 19 Sep 2002 04:58:36 -0700 (PDT) From: bkhabs Reply-To: bkhabs@nc.rr.com To: pekkas@netcore.fi Subject: Re: Re: ISP scenarios comments (multicast) Cc: v6ops@ops.ietf.org, micklesc@aol.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: E-mailanywhere V2.0 (Windows) X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_NAME_NO_SPACES,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >On Thu, 19 Sep 2002 04:19:43 0300 (EEST) Pekka Savola wrote. >On Wed, 18 Sep 2002, Brian Haberman wrote: >> Pekka Savola wrote: >> > >> > On Wed, 18 Sep 2002, bkhabs wrote: >> > >> > > Pekka, >> > > >> > > >On Wed, 18 Sep 2002 18:25:58 0300 (EEST) Pekka Savola >> > > wrote. >> > > > * multicast issues >> > > > - support is yet a bit .. raw or non-existant. >> > > >> > > Are you talking standards or implementations? >> > >> > Both. >> > >> > As for standards, there is the problem with MSDP. Another partially >> > related one is related to site-local group scoping. There needs to be >> > some feature like 'bsr-border' to site-local scopes to work properly >> > inside only one PIM domain, I think. >> >> I brought up the issue of site-locals and PIM in a PIM for v6 draft a >> few years ago. The PIM group came to consensus that in order to use >> site-locals in certain PIM messages (e.g. C-RP or Bootstrap) then a >> PIM domain border MUST be the same as the site-local border. >> >> That draft was eventually merged into the new pim draft. > >Ok; this is still a bit problematic with the one PIM domain requirement.. >:-/ I don't think it is problematic when you consider the overhead that would have to occur in order to support PIM domain != site-local domain. The major problem is that PIM messages are mostly sent hop-by-hop with IP addresses in the payload. So, the Bootstrap message is transmitted hop-by-hop using the All-PIM-Routers link-local multicast address. But the BSR address is in the payload. That means that a site-local border router would have to recognize the Bootstrap message, parse into the PIM payload and check to see if the BSR-Address was a site-local. In this case, I prefer simplicity. Let pim domain == site-domain. > >> > > > - should we focus on SSM only >> > > >> > > For the short term definitely. >> > >> > I believe most don't realize that's the only option at the moment. >> >> Agreed. The interesting thing is that, just like in v4, multicast >> in v6 is lagging in development effort. > >Yes. This is sad as SSM video broadcasts could be one "killer" >application for IPv6 (it would be available for v4 too.. :-) > >> Another possibility is whether or not RFC 3306 can be exploited to >> help with the issue of RP location and such. Haven't had much time >> to look into that though. > >This might be an interesting point to develop more. It's quite possible >if we can hard-code assumptions about address assignment for the RP there. >Possibly through an additional bit flag in the address. This would have to >go to the PIM implementation then, though. You can't encode the RP in the field. But, a new RP discovery mechanism could utilize the prefix information to know where to look for the RP. Brian From owner-v6ops@ops.ietf.org Thu Sep 19 09:05:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03110 for ; Thu, 19 Sep 2002 09:05:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s0yn-000Gy2-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 06:04:25 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17s0yh-000GxX-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 06:04:19 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E5EC14401; Thu, 19 Sep 2002 09:04:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 19 Sep 2002 09:04:14 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comment on unmanaged analysis presentation/doc X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 19 Sep 2002 09:04:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92A4@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on unmanaged analysis presentation/doc Thread-Index: AcJfeaQr5gi08GcGTHGBoa9xacwO6AAYx9wA From: "Bound, Jim" To: "Pekka Savola" , "Marc Blanchet" Cc: , , X-OriginalArrivalTime: 19 Sep 2002 13:04:14.0429 (UTC) FILETIME=[0DD550D0:01C25FDD] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03110 Marc did explicitly ask that TSP be a v6ops mechanism for discussion. To address that question with my input. I believe TSP is an important tool for users. I believe we can begin work on this tool within v6ops and support it being worked on within this list. Others should respond here with your opinion and this is important per Margarets talk today. One way or the other. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, September 18, 2002 8:47 PM > To: Marc Blanchet > Cc: huitema@microsoft.com; satapati@cisco.com; v6ops@ops.ietf.org > Subject: Re: comment on unmanaged analysis presentation/doc > > > On Wed, 18 Sep 2002, Marc Blanchet wrote: > > case A where IPv4 nat is present: > > - teredo is one mechanism. In fact, what is needed is ipv6 > over udp-ipv4 > > (i.e. nat traversal). > > - in this space, tsp with udp-ipv4 encapsulation is also a viable > > solution. It also enables the unmanaged network to receive > automatic data > > needed for the unmanaged network: i.e. ipv6 network prefix > for example. > > (reference = draft-parent-blanchet-ngtrans-tsp-teredo-00.txt). > > - the unmanaged draft says: "A variant of the [TEREDO] > technology could be > > used to establish > > tunnels over UDP when the client cannot use a global IPv4 address; > > this variant is however not standardized." > > (if this text refers to our draft, then the comment is > not appropriate: > > i.e. the variant is not standardized. teredo is also not > standardized yet.) > > Teredo does more than just sets up a tunnel. In the case of NAT, in > particular, keeping the pipe open is also an important task. > The draft > does not explicitly address this, I believe. > > Further discussion on teredo/tsp should probably be sent to ngtrans. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Thu Sep 19 10:15:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06503 for ; Thu, 19 Sep 2002 10:15:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s25f-000LVd-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 07:15:35 -0700 Received: from postal3.es.net ([198.128.3.207]) by psg.com with esmtp (Exim 3.36 #1) id 17s25Y-000LV3-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 07:15:29 -0700 Received: from pinnacle.es.net ([131.243.212.196]) by postal3.es.net (Postal Node 3) with SMTP id MUA74016 for ; Thu, 19 Sep 2002 07:15:26 -0700 Message-Id: <5.1.0.14.0.20020919070813.00b5ea18@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Sep 2002 07:15:23 -0700 To: v6ops@ops.ietf.org From: Bob Fink Subject: ipv6ops web page Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk v6ops Folk, I have created a v6ops web page at: I have placed the presentations I have received so far on the minutes page at: There is a first cut at what I understand our active projects to be at: Please let me know when you find errors. Thanks, Bob From owner-v6ops@ops.ietf.org Thu Sep 19 10:27:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07020 for ; Thu, 19 Sep 2002 10:27:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s2IU-000MKz-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 07:28:50 -0700 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by psg.com with esmtp (Exim 3.36 #1) id 17s2IR-000MKo-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 07:28:47 -0700 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8JESiM23601; Thu, 19 Sep 2002 09:28:45 -0500 (CDT) Message-ID: <3D89DF51.3090901@alcatel.com> Date: Thu, 19 Sep 2002 09:29:37 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org Subject: Re: raw thoughts on v6 firewalls References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Pekka, Site-local addresses would provide the same functionality and therefore there is no need to introduce firewalls into v6. Is there anything wrong with the above argument? Regards, Pekka Savola wrote: >Hi, > >Regarding v6ops meeting discussion.. > >I don't think v6 firewalls can be killed. They're a mechanism to ensure >some form of security policy; trusting end nodes to do the right thing is >not enough. > >But there are problems with v6 firewalling. I've been trying to get >around to writing a draft for a year or so now but never did it (further >than the baseline summary of the content): perhaps now it's a better time. > >One potentially major deployment issue is how the firewall is supposed to >handle packets where extension header contains a header it does not not >recognize and thus cannot parse e.g. UDP/TCP headers. > > > -- Behcet From owner-v6ops@ops.ietf.org Thu Sep 19 10:40:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07763 for ; Thu, 19 Sep 2002 10:40:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s2Vh-000N9s-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 07:42:29 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17s2VY-000N8y-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 07:42:20 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8JEet016937; Thu, 19 Sep 2002 10:40:55 -0400 (EDT) Message-Id: <200209191440.g8JEet016937@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , Paul Vixie , v6ops@ops.ietf.org Subject: Re: renumbering In-reply-to: (Your message of "Thu, 19 Sep 2002 11:01:27 +0200.") <3D899267.5538DE52@hursley.ibm.com> Date: Thu, 19 Sep 2002 10:40:55 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Perhaps, but the real point is that with AAAA records, the main need > is for tools not standards - specifically, tools to perform bulk updates > of a site's DNS table. Many sites and enterprises have such tools already > and adapting them to IPv6 is straightforward enough, but sites that > don't have such a tool (and therefore probably don't have an organized > host database or even an organized host naming strategy) will find > IPv6 renumbering almost as obnoxious as IPv4 renumbering. > > This matters. Paul is being pragmatic, but if the NAT fungus infects > IPv6 deployment we will have painted IPv6 into a corner. > > So, still being pragmatic, how can we stimulate the creation of > renumbering tools (especially DNS bulk renumbering tools)? IMHO, there is a need for both tools and guidance, and perhaps also for minor protocol tweaks. this was true even with A6 records. if someone were to write a "how to renumber your network" document, with appropriate consideration for all of the components of the network that might need to be tweaked (incl. routers, firewalls, software that is configured to allow access only from local IP addresses) and also consideration for what it takes to keep software from breaking during the switch-over (listing different phases and recommending times for each) the exercise of writing this document might also serve to identify any missing bits of protocol and missing tools. perhaps I've missed it, but I don't think I've ever seen anything like a complete story on how to renumber a large network - and until we have that, how can we be sure that the necessary pieces are all in place? Keith From owner-v6ops@ops.ietf.org Thu Sep 19 11:01:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08670 for ; Thu, 19 Sep 2002 11:01:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s2pg-000OR1-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:03:08 -0700 Received: from [206.157.230.254] (helo=hatl0ms20.CORP.COX.COM) by psg.com with esmtp (Exim 3.36 #1) id 17s2pd-000OQn-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:03:05 -0700 Received: from CPHX0MS01.corp.cox.com ([10.9.6.1]) by catl0ms20.corp.cox.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 19 Sep 2002 11:02:58 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C25FED.A3CFFD00" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: raw thoughts on v6 firewalls Date: Thu, 19 Sep 2002 11:02:57 -0400 Message-ID: <7D786F7378A6CF4C8369BA7D53555F5707FAA4@CPHX0MS01.corp.cox.com> X-MS-TNEF-Correlator: <7D786F7378A6CF4C8369BA7D53555F5707FAA4@CPHX0MS01.corp.cox.com> Thread-Topic: raw thoughts on v6 firewalls Thread-Index: AcJf6sMUPvfjuOmNTCOeEK/yuYT5BAAAlDwW From: "Sassaman, Kim (CCI-Phoenix)" To: "Behcet Sarikaya" , "Pekka Savola" Cc: X-Spam-Status: No, hits=2.5 required=5.0 tests=SUPERLONG_LINE,BASE64_ENC_TEXT version=2.31 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C25FED.A3CFFD00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlIG9ubHkgaXNzdWUgSSBjYW4gc2VlIGFyaXNlIGlzIHdoZW4gYSBzaXRlLWxvY2FsIGFkZHJl c3Mgd291bGQgaGF2ZSB0byBjb21tdW5pY2F0ZSB3aXRoIGZvcmVpZ24gZW50aXRpZXMgbm90IGxv Y2FsIHRvIGl0c2VsZi4gIEluIHN1Y2ggYSBpbXBsZW1lbnRhdGlvbiBhICJiYXJyaWVyIiB0aGF0 IGxvZ2ljYWxseSBhbmQvb3IgcGh5c2ljYWxseSBzZXBwZXJhdGVzIHRoZSB0d28gZW50aXRpZXMg ZnJvbSBvbmUgYW5vdGhlciB3b3VsZCBzZXJ2ZSBhIHB1cnBvc2UuICBUaGlzICJiYXJyaWVyIiBj YW4gYmUgaW4gbWFueSBmb3JtcyBhIHByb3h5LCBhIG5hdCBkZXZpY2UsIGFuZCB3aGF0IGlzIGNv bW1vbmx5IGtub3duIGFzIGEgZmlyZXdhbGwuICBCZWluZyBhIHNlY3VyaXR5IHByb2Zlc3Npb25h bCBhcyB3ZWxsIGFzIGEgbmV0d29yayBwcm9mZXNzaW9uYWwgYmxhbmtldCBkaXNtaXNzYWwgb2Yg c2VjdXJpdHkgZGV2aWNlcyBjb3VsZCBwcm92ZSB0byBiZWNvbWUgYSBodWdlIGZsYXcgaWYgd2Ug dGFrZSBhIHN0YW5jZSBvZiBuZWdhdGluZyB0aGVtIHNvIGVhcmx5IG9uIGluIHRoZSBwcm9jZXNz Lg0KIA0KS2ltIFNhc3NhbWFuDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglG cm9tOiBCZWhjZXQgU2FyaWtheWEgW21haWx0bzpiZWhjZXQuc2FyaWtheWFAYWxjYXRlbC5jb21d IA0KCVNlbnQ6IFRodSA5LzE5LzIwMDIgNzoyOSBBTSANCglUbzogUGVra2EgU2F2b2xhIA0KCUNj OiB2Nm9wc0BvcHMuaWV0Zi5vcmcgDQoJU3ViamVjdDogUmU6IHJhdyB0aG91Z2h0cyBvbiB2NiBm aXJld2FsbHMNCgkNCgkNCg0KCUhlbGxvIFBla2thLCANCgkgIFNpdGUtbG9jYWwgYWRkcmVzc2Vz IHdvdWxkIHByb3ZpZGUgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBhbmQgDQoJdGhlcmVmb3JlIHRo ZXJlIGlzIG5vIG5lZWQgdG8gaW50cm9kdWNlIGZpcmV3YWxscyBpbnRvIHY2LiANCgkgIElzIHRo ZXJlIGFueXRoaW5nIHdyb25nIHdpdGggdGhlIGFib3ZlIGFyZ3VtZW50PyANCg0KCVJlZ2FyZHMs IA0KDQoJUGVra2EgU2F2b2xhIHdyb3RlOiANCg0KCT5IaSwgDQoJPiANCgk+UmVnYXJkaW5nIHY2 b3BzIG1lZXRpbmcgZGlzY3Vzc2lvbi4uIA0KCT4gDQoJPkkgZG9uJ3QgdGhpbmsgdjYgZmlyZXdh bGxzIGNhbiBiZSBraWxsZWQuICBUaGV5J3JlIGEgbWVjaGFuaXNtIHRvIGVuc3VyZSANCgk+c29t ZSBmb3JtIG9mIHNlY3VyaXR5IHBvbGljeTsgdHJ1c3RpbmcgZW5kIG5vZGVzIHRvIGRvIHRoZSBy aWdodCB0aGluZyBpcyANCgk+bm90IGVub3VnaC4gDQoJPiANCgk+QnV0IHRoZXJlIGFyZSBwcm9i bGVtcyB3aXRoIHY2IGZpcmV3YWxsaW5nLiAgSSd2ZSBiZWVuIHRyeWluZyB0byBnZXQgDQoJPmFy b3VuZCB0byB3cml0aW5nIGEgZHJhZnQgZm9yIGEgeWVhciBvciBzbyBub3cgYnV0IG5ldmVyIGRp ZCBpdCAoZnVydGhlciANCgk+dGhhbiB0aGUgYmFzZWxpbmUgc3VtbWFyeSBvZiB0aGUgY29udGVu dCk6IHBlcmhhcHMgbm93IGl0J3MgYSBiZXR0ZXIgdGltZS4gDQoJPiANCgk+T25lIHBvdGVudGlh bGx5IG1ham9yIGRlcGxveW1lbnQgaXNzdWUgaXMgaG93IHRoZSBmaXJld2FsbCBpcyBzdXBwb3Nl ZCB0byANCgk+aGFuZGxlIHBhY2tldHMgd2hlcmUgZXh0ZW5zaW9uIGhlYWRlciBjb250YWlucyBh IGhlYWRlciBpdCBkb2VzIG5vdCBub3QgDQoJPnJlY29nbml6ZSBhbmQgdGh1cyBjYW5ub3QgcGFy c2UgZS5nLiBVRFAvVENQIGhlYWRlcnMuIA0KCT4gDQoJPiAgDQoJPiANCg0KCS0tIA0KCUJlaGNl dCANCg0KDQoNCg0K ------_=_NextPart_001_01C25FED.A3CFFD00 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgUPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADSBwkAEwALAAIAOQAEAD8BASCAAwAOAAAA0gcJABMACwADAAQABAALAQEJgAEAIQAAAEJB M0VGQ0M1MDk0QTE5NDY5QjE5NDBCMTM4MEIxODJDACUHAQOQBgBgCwAAKQAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBPAFQARQAAAAAAAwAmAAAAAAADADYAAAAAAB8ANwABAAAAQgAAAFIARQA6ACAA cgBhAHcAIAB0AGgAbwB1AGcAaAB0AHMAIABvAG4AIAB2ADYAIABmAGkAcgBlAHcAYQBsAGwAcwAA AAAAQAA5AIBmN6PtX8IBHwA9AAEAAAAKAAAAUgBFADoAIAAAAAAAHwBwAAEAAAA6AAAAcgBhAHcA IAB0AGgAbwB1AGcAaAB0AHMAIABvAG4AIAB2ADYAIABmAGkAcgBlAHcAYQBsAGwAcwAAAAAAAgFx AAEAAAAbAAAAAcJf6sMUPvfjuOmNTCOeEK/yuYT5BAAAlDwWAB8AGgwBAAAAOAAAAFMAYQBzAHMA YQBtAGEAbgAsACAASwBpAG0AIAAoAEMAQwBJAC0AUABoAG8AZQBuAGkAeAApAAAAHwAdDgEAAAA6 AAAAcgBhAHcAIAB0AGgAbwB1AGcAaAB0AHMAIABvAG4AIAB2ADYAIABmAGkAcgBlAHcAYQBsAGwA cwAAAAAAAgEJEAEAAACXBQAAkwUAADwJAABMWkZ1qofWhAMACgByY3BnMTI14jIDQ3RleAVBAQMB 9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEz CO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgVIhoZSACIGx5IAQB4QpQIEkgYwORFBAdEM8K wAQAHRAEACB3HQADoOphHjBpDrAtF7AeAAMgWGFkZBggBBF3CGBslGQgE+B2HRB0bx3w+QNwbXUD AB4ADrAfAB+QzGggAhAYIGlnA6AJ8M50H5AIkAQgbm8FQB/UhyFhH5AUEGxmLiAd0L8eIRrQIoAf YAdwC1BlB4CbAjAiEGkCIB9RImIKwF0IgiIhUBPgI9JnIfFsEx1RAHBkLwWxcGh55w3RKAMUEHBw BJAiEQQg/yJwIUEgsCMYA1IdIR5hI7FvHQAFwCC0FBByITEfYHD5CHBwbxQQJOEc8B7hJsh9HgJi HsEDoAOBHWAioW1HBCAtAQNgeHksH1Fu6yeBAQB2DeBlMHEoYB8BryeBHuEhkh0zayOwdx9BaS/i ZmkYIHcoASThQrki0G5nH1IFkAhxdB1g/TAhZiBxJmEgAh7xJLA14+cwkRQgILByazUsAmAAcO5r FCAw4AQAbQQBIAE1UP80mDD0MhIg0jAhITQu8CGR0SziaHVnHRBmC2AH4HcGkDYhIVBhOGAfUgGQ bvcxMDkyK5BnJkE0USohK2D+cyqBCsAdUSZxLyEqIjAheTpBcy4KogqACuMKgEt/B3AGATjxA4FA q0KlAZEgui1Dsk8FECfQNcJNIHFeYTwgQ7NClkNyRgNhOj00EWgxMAVABhAFEGthunkfYFsAwAMQ IWA6LvDtRpIuOQBHBEAHQCICM+B9IZFdRVoGYAIwRlAc8HWwIDkvMUsQAdAwFEBQNzoyORDATUVa VGFH0CBQZWtHIAYBdicG8B9gQwlDY0ZQdjbQb3BzQE8BLgiQADCOLgWwNGBJynViagWQ+UqhUmVG UCnAB+AicAhgvGdoJJA/ck7gM2dzQwn7U19DCUg2QSFwTSMwcEMJvSTwUx+fB5EgtDriaQEA/yoT QeE8MSHQURA1ozTyMXL/Qwkr8gEQIrFb5B7SI7A2we8JgCRDAjADYGQa0DwxUtbfXcIhcE7gJOBW m0kqA1xh9y9hInA0QncDYGFiImIqIqcBoDsCCsBndSYCP1Sv91FBPjALIHNWd0MYTSthkUcOsEZQ ZS8+SGlWez7/aMtklDRCTuMvQAngPlM4obs0wDWDLl+LaYwd4GQCIL4nBUBhMjcwUpoupmsDEMUl 4GQtk2V5J2DSa1H/E9EDADjAIVIJ8B2gXGFn2j8+8FnyL7E5Oy1QWrBjefo7IVBybCA+UwnwIPAj sP8BACoBIXBuYCoTRBFSIG6z/zRgHuFn2iOyCfBR8myfZ/j8QnVuomDDXGEwIQJgJfDfHvEiYlKZ NEEk4ichMS7w+x8xXfB5PmMhcDwgBUFn6f8KwAhgMYEhYWGQI1E0UyBQ7mEBgCKSH1F5PyEdIAXA /z7xMtEu4HtRK5AhMAXAOKDzIPBXcCAoWiAAICwCZ9r/J2E/xCbQJKELgFmxYxAAwL9+wDkyKiIF oAIwIyEpRlDfKaET4GsxgwJXcCcv4i7wvwJAEoEjQAeAeZ9n+E8rkd8tUIfiBzEdUQDAagWxAQD9 C1BvBsAjIR11HuFR4FGy/15YHtIdoCmQLWFdg2faccH+ZCXgKLAA0DhhHvNcYQ7B/3JhJmIdACAw EoGHsgtxL+L/kzWEIW5gI4UjsmfaGCAFoPki8Gl6K6JdgTwAb9Mjsg8KsR6xLYB90VVEUC/4VENQ kyVAgIpPmhiZ319C3kVaRnWca58/faCwAB8ANRABAAAAgAAAADwANwBEADcAOAA2AEYANwAzADcA OABBADYAQwBGADQAQwA4ADMANgA5AEIAQQA3AEQANQAzADUANQA1AEYANQA3ADAANwBGAEEAQQA0 AEAAQwBQAEgAWAAwAE0AUwAwADEALgBjAG8AcgBwAC4AYwBvAHgALgBjAG8AbQA+AAAACwDyEAEA /HcfAPMQAQAAAE4AAABSAEUAJQAzAEEAIAByAGEAdwAgAHQAaABvAHUAZwBoAHQAcwAgAG8AbgAg AHYANgAgAGYAaQByAGUAdwBhAGwAbABzAC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMGd4ZaTtX8IB QAAIMJaUdqftX8IBAwDeP+n9AAADAPE/AAAAAB8A+D8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBk AG0AaQBuAGkAcwB0AHIAYQB0AG8AcgAAAAAAAgH5PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv 4YIBAAAAAAAAAC4AAAAfAPo/AQAAACoAAABTAHkAcwB0AGUAbQAgAEEAZABtAGkAbgBpAHMAdABy AGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAA AwD9P+QEAAADABlAAAAAAAMAGkAAAAAAHwAwQAEAAAASAAAASwBTAEEAUwBTAEEATQBBAAAAAAAf ADFAAQAAABIAAABLAFMAQQBTAFMAQQBNAEEAAAAAAB8AOEABAAAABAAAAC4AAAAfADlAAQAAAAQA AAAuAAAAHwBBQAEAAAAKAAAAUwBNAFQAUAAAAAAAHwBCQAEAAAAqAAAASwBpAG0ALgBTAGEAcwBz AGEAbQBhAG4AQABjAG8AeAAuAGMAbwBtAAAAAAAfAE+AhgMCAAAAAADAAAAAAAAARgEAAAAcAAAA YwBvAG4AdABlAG4AdAAtAGMAbABhAHMAcwAAAAEAAAA4AAAAdQByAG4AOgBjAG8AbgB0AGUAbgB0 AC0AYwBsAGEAcwBzAGUAcwA6AG0AZQBzAHMAYQBnAGUAAAALACkAAAAAAAsAIwAAAAAAAwAGEA6w mpcDAAcQLQUAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABUSEVPTkxZSVNTVUVJQ0FOU0VF QVJJU0VJU1dIRU5BU0lURS1MT0NBTEFERFJFU1NXT1VMREhBVkVUT0NPTU1VTklDQVRFV0lUSEZP UkVJR05FTlRJVElFU05PVExPQ0FMVE9JAAAAAAIBfwABAAAAQAAAADw3RDc4NkY3Mzc4QTZDRjRD ODM2OUJBN0Q1MzU1NUY1NzA3RkFBNEBDUEhYME1TMDEuY29ycC5jb3guY29tPgBC2Q== ------_=_NextPart_001_01C25FED.A3CFFD00-- From owner-v6ops@ops.ietf.org Thu Sep 19 11:20:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09527 for ; Thu, 19 Sep 2002 11:20:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s37C-000Pdb-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:21:14 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17s375-000PdA-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:21:08 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17s373-0004ij-00; Thu, 19 Sep 2002 16:21:05 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17s373-0004ie-00; Thu, 19 Sep 2002 16:21:05 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA30726; Thu, 19 Sep 2002 16:20:56 +0100 Message-ID: <3D89EB63.810A2CA5@hursley.ibm.com> Date: Thu, 19 Sep 2002 17:21:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Behcet Sarikaya CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: raw thoughts on v6 firewalls References: <3D89DF51.3090901@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Behcet Sarikaya wrote: > > Hello Pekka, > Site-local addresses would provide the same functionality and > therefore there is no need to introduce firewalls into v6. > Is there anything wrong with the above argument? Lots. It's very similar to the argument that NAT is a security feature, which is absolutely untrue. Firewalls block incoming connections with global destination addresses. The existence of site-local addresses is orthogonal to this. You still need to allow some incoming connections to global addresses, and block others. (Firewalls do more than that, but this is sufficient to answer your question.) Brian From owner-v6ops@ops.ietf.org Thu Sep 19 11:34:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10212 for ; Thu, 19 Sep 2002 11:34:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3K7-0000Ve-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:34:35 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s3Jz-0000Ul-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:34:28 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JFYNs14221 for ; Thu, 19 Sep 2002 18:34:23 +0300 Date: Thu, 19 Sep 2002 18:34:23 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: unmanaged scope comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Larger issues: 1) Especially for case A and C. I think there needs to be a clearer characterization of (IPv4) connectivity and addresses, like (this has all cases I think -- it could be simplified): 1. global addresses a) dynamic - enough addresses for every node - only one b) static - ^ - ^ 2. private addresses: NAT by ISP (or outside of your control) [otherwise one of cases above] - dynamic - static 2) 4 Application requirements of an IPv6 unmanaged network The application requirements are expressed in mostly three dimensions: connectivity, naming, and security. Connectivity issues include the provision of IPv6 addresses and their quality: do host need a global scope address, should this address be stable, or more precisely what should be the expected lifetime of the address. ==> connectivity includes one very important component IMO: the quality of network connections. This is often ignored. It's a high risk for a vendor to enable IPv6 by default, for example, if that'd result in lower quality connections to e.g. dual-stack web servers (a very real fact in 6bone), this should be taken into consideration at least in the short term. 3) 4.2 Requirements of client applications [...] maintaining the privacy of the client. Many potential users of IPv6 observe that the current NAT configuration provides some level of privacy: all communications to outside servers appear to come from the single IPv4 address of the NAT; the source IPv4 address does not identify a specific host inside the unmanaged network .. ==> .. or even a specific host in the ISP. IMO it's usually a non-issue, particularly in unmanaged case, whether someone can identify which node in a sparsely populated subnet is which. 4) Triggered by sect 4.3 and 4.4, but it's more generic than that; I think the draft needs to consider differences wrt. static/dynamic addresses/prefixes. In particular, privacy, server address and generally DNS issues come to mind. 5) The case where the ISP is IPv6 capable, but the gateway is not is similar to case A. 5.1 Case A, host deployment of IPv6 applications In this case the gateway doesn't provide IPv6; the ISP may or may not provide IPv6, but this is not relevant, since the non-upgraded gateway would prevent the hosts from using the ISP service. Some hosts will try to get IPv6 connectivity, in order to run applications that require IPv6, or work better with IPv6. ==> This is not true I think: for example, even if gateway runs v4 private addresses, ISP could provide e.g. internal tunnel service or something like ISATAP to their v6-enabled network. ==> Do you refer to *layer 3* gateway? (Otherwise, this gets simpler with e.g. bridged ATM encapsulation in xDSL). 6) 5.1.1 Application support in Case A Server applications are also not a primary focus of Case A. Server applications require DNS support, which is difficult to engineer for clients located behind a NAT. Besides, server applications, at this stage, cater mostly to IPv4 clients; putting up an IPv6 only server is not very attractive. ==> I'm not quite sure how DNS support is difficult to engineer; this probably has an unstated assumption that the address behind NAT would change too often to be really updateable or writable in DNS. This does not need to be the case. ==> In case A, clients don't necessarily need to be behind a NAT. 7) backward/upward compatibility; I brought this up in the interim meeting. IMO I don't see it as a hard requirement to be able to be able to perform v4only <-> v6only conversions. This depends quite a bit on what our "dual stack" deployment strategy is: whether we encourage vendors (e.g. LCNA type applications) to ship v6-only stacks or dual-stacks. 8) A comment: -- I think that there is a case to be made that using translation tools boosts the previously mentioned network effect and makes it work in our favor; the somewhat crippled nature of the translation tools is in fact also a good thing, because it gives people an incentive to throw them away once they realize that they are broken. I realize that this is heresy, so be it. -- ==> No I don't agree with the last statement: this gives folks only an incentive to enhance and tweak these features, not fix them *properly*. Think NAT ALGs... Semi-editorial: nat/firewall with that name. Since updating DNS is a management task, it somewhat falls outside the scope of an unmanaged network. ==> management, yes, but it's often automatic. A peer to peer session typically starts by an exchange of synchronization messages through the rendezvous servers, during which the peers exchange the addresses that will be used for the session. ==> not knowing better these protocols, I'm only guessing, but some of these messages could be done e.g. to initiate NAT, and thus be at least partially unnecessary with IPv6. There are multiple aspects to the security of peer-to-peer applications, many of which relate to the security of the rendezvous system. ==> I'm not sure which threats you refer to; the one I can think of is some kind of information disclosure. But I'm more afraid of the (programming) security of p2p apps myself. 4.4 Requirements of server applications The DNS entries for the server will have to be updated, preferably in real time, if the server's address changes. In practice, updating the DNS is slow, which implies that server applications will have a ==> The slowness of DNS is debatable, I think. TTL can be tuned if necessary. The security of server applications depends mostly on the correctness of the server, and also on the absence of collateral effects: many incidents occur when the opening of a server on the Internet inadvertently enables remote access to some other services on the same host. ==> s/host/node/ ==> not necessarily only the same node, even on the same local network ==> does 'correctness of the server' refer to the server application? 5.1.3 Naming services in Case A At this phase of IPv6 deployment, hosts in the unmanaged domain have access to DNS services over IPv4, through the existing gateway. DNS resolvers are supposed to serve AAAA records, even if they only implement IPv4; the local hosts should thus be able to obtain the IPv6 addresses of IPv6 only servers. ==> s/are supposed to// ==> s/should thus be/are/ (are these really worth the conditionals..) presence of translation or port mapping services; there is also not much of a case for letting local IPv4 servers publish their service on the IPv6 Internet. ==> I agree! These should be dual-stacked if they're important. To enable this scenario, the gateway need to use a mechanism obtain a global address prefix from the ISP, and advertise this address prefix to the hosts in the unmanaged network; several solutions will be assessed in a companion memo [EVAL]. ==> and in the degenate case...? 5.2.3 Naming services in Case B [...]. Currently, IPv4 only hosts discover the IPv4 address of the local DNS server using DHCP; there must be a way for IPv6 only hosts to discover the IPv6 address of the DNS server. ==> s/discover/usually discover/ Generic issue: I think that perhaps case B and case C could be reversed; I find it more probable that ISP is the last party of the three to offer v6 service. 5.3.2 Addresses and connectivity in Case C There are two ways to bring immediate IPv6 connectivity on top of an IPv4 only infrastructure: automatic tunnels provided by the [6TO4] technology, or configured tunnels. Both technologies have advantages and limitations, which will be studied in a companion document. ==> + mechanisms if gateway does not have global addresses. 5.4 Case D, ISP stops providing native IPv4 connectivity In this case the ISP is IPv6-only, so the gateway looses IPv4 connectivity, and is faced with an IPv6-only service provider. The gateway itself is dual stack, and the unmanaged network includes IPv4 only, IPv6 only and dual stack hosts. ==> no IPv4 connectivity to the customer, or no v4 at all (e.g. no possibility for ALG's, web caches, DNS / SMTP servers etc.). Probably the former. Editorial: s/IPv6 only/IPv6-only/ ? s/IPv4 only/IPv4-only/ ? 2 Topology (ISP)connection. Several hosts are connected to the subnet: ==> s/are/may be/ or may not perform NAT and firewall function. A key point of this ==> s/function/functions/ 3.2 Client applications network and a server at a remote location. A typical example is accessing a web server from a client inside the managed network, or reading and sending e-mail with the help of a server outside the managed network. ==> s/managed/unmanaged/g (whoops.. :-) 3.3 Peer-to-peer applications There are two kinds of peer-to-peer applications, the "local peer- to-peer" that only involve hosts on the unmanaged network, and the s/on the unmanaged network/in the unmanaged network/ (lots of other places; I'm not sure which one is correct, but 'in' sounds better to my ear at least) well identified peers outside the unmanaged network. These ==> s/well identified/well-identified/ ? applications are often facilitated by a server outside the managed networks. Examples of a peer-to-peer application would be a video- ==> s/managed/unmanaged/ (whoops :-) ==> s/networks/network/ 3.4 Server applications ==> I think the order should be changed: Server before Peer-to-peer, as peer to peer is IMO the most generic case. requires some special programming of the NAT or firewall. When the NAT only publishes a small number of global IP addresses and relies on "port ==> s/requires/require/ ==> s/publishes/maps to/ (or something else, publishes sounds funny)? nat/firewall with that name. Since updating DNS is a management task, it somewhat falls outside the scope of an unmanaged network. ==> s/nat/NAT/ 4.2 Requirements of client applications An important security issues with client applications is, ==> s/issues/issue/ ==> s/is,/is/ 4.3 Requirements of peer-to-peer applications Peer-to-peer applications require global connectivity. In an IPv6 network, we would expect the peers to use a global IPv6 address, which will have to remain stable for the duration of the peer-to- peer between client and server. ==> s/peer/peer session/ ==> "client and server" is a bit funny wording in P-2-P case.. :-) to deploy, and light weight; it will have to involve tunneling over ==> s/light weight/light-weight/ (not sure..?) 5.2.1 Application support in Case B We expect the unmanaged network to include three kinds of hosts: IPv4 only, IPv6 only, and dual stack. ==> soften the wording a bit: not every unmanaged network need to include all three. IPv4 only hosts use the services a brand new IPv6 only printer. ==> s/services/services, like/ To enable this scenario, the gateway need to use a mechanism obtain ==> s/need/needs/, s/obtain/to obtain/ not. The gateway has been upgraded and offers both IPv4 and IPv6 connectivity the hosts. It cannot rely on the ISP for IPv6 ==> s/connectivity/connectivity to/ connectivity, because the ISP does not offer ISP connectivity yet. ==> s/offer ISP/offer IPv6/ representation of the IPv4 address of the server, either by sing a ==> s/sing/using/ -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 11:34:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10269 for ; Thu, 19 Sep 2002 11:34:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3L1-0000a3-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:35:31 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s3Ku-0000Z9-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:35:25 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JFZM814240 for ; Thu, 19 Sep 2002 18:35:22 +0300 Date: Thu, 19 Sep 2002 18:35:22 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: unamanged solutions comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk 2.1 Evaluation of connectivity mechanisms ==> this needs to reworded or split: many of these are IMO not strictly speaking connectivity mechanisms 2.1.2 6to4 Another potential limitation of the technology is the reliance on publicly accessible "6to4 relay routers" that accept packets from 6to4 routers and relay them to the "regular" IPv6 Internet. These relays all listen to the same IPv4 anycast address [RFC3056], which enables gateways to start operating as 6to4 routers without requiring any explicit configuration. As the deployment of IPv6 progresses, a growing fraction of the traffic originating from 6to4 routers will have to be carried through these relays, potentially leading to severe congestion of the relays. ==> There are two problems with relays: 1) configuring the relay on 6to4 router; anycast address helps a bit there. 2) v6 nodes finding the closest relay advertising 2002::/16. This is not addressed here, and I think is a major problem: there is zero guarantee about how unoptimal the return path is (you can make some assumption about the forward path, to the 6to4 relay close to you)! 2.1.6 SIIT Stateless IP/ICMP Translation Algorithm (SIIT) is a generic translation mechanism between IPv4 and IPv6. The main characteristics of DSTM are as follow: ==> s/DSTM/SIIT/ 2.1.7 NAT-PT particular, the specification discusses a DNS ALG that would enable the NAT-PT system to reply with a "translated" record, e.g. a AAAA record contained the IPv6-mapped IPv4 address of an IPv4 only host, or a A record containing the IPv4 address statically assigned to an IPv6 only host. ==> mapped address is NAT64 semantic, not NAT-PT. 2.1.10 DSTM DSTM may have a role to play in the transition of large network, or in that of ISP networks, but its role in the transition of unmanaged networks is thus marginal at best: it does not support IPv6 only hosts, and it does not provide an operational advantage in the unmanaged network. ==> Some generalized form of DSTM could be implemented in case D (e.g. gateway performing DSTM tunneling function and providing v4 to the local v4-only nodes) 3.1.3 MDNS -- discussion of [MDNS] -- ==> I'm not sure how LLMNR is all that applicable (at best, if there's a disconnected site scenario). 3.1.6 Reverse lookup wildcard 1234:5678:9ABC::1 by providing a pointer to either "1234-5678-9ABC- 0-0-0-0-1.example.net", or "1234-5678-9ABC-0-0-0-0- 1.foo.example.net" - i.e. with or without an identification of the client's account in the pointed name. Privacy advocates will probably insist that ISP do not include client identification in such pointers, as this would negate all benefits of privacy addresses. ==> or e.g. 0-0-0-0-1.foo.example.net. ==> "foo" is unlikely a clearly identifiable (like a surname) so "foo" or the prefix (assuming it's static) will reveal the same thing anyway. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 11:35:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10333 for ; Thu, 19 Sep 2002 11:35:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3LU-0000dZ-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:36:00 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s3LO-0000d8-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:35:55 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JFZpO14250 for ; Thu, 19 Sep 2002 18:35:51 +0300 Date: Thu, 19 Sep 2002 18:35:51 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: 3GPP soluations comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk 1.1 Scope of this Document The scope of this informational document is to analyze and solve the possible transition scenarios in the 3GPP defined GPRS network where a UE connects to, or is contacted from the Internet, or ==> s/from/from,/, s/, or/ or/ 2.2 Tunneling Tunneling is a transition mechanism that requires dual IPv4/IPv6 stack functionality in the encapsulating and decapsulating nodes. IPv6-in-IPv4 tunneling mechanisms are implemented by virtual interfaces that are configured over one or more physical IPv4 interfaces. Sending nodes encapsulate IPv6 packets in IPv4 packets when the IPv6 routing table determines that the next hop toward the IPv6 destination address is via a tunnel interface. Receiving nodes decapsulate IPv6 packets from IPv4 packets that arrive on tunnel interfaces. Tunneling can be static or dynamic. ==> implicitly this discusses only v6-in-v4 tunneling. This means that the IPv4 source address is taken from an IPv4 interface over which the automatic tunnel is configured. Examples of dynamic tunneling mechanisms are "6to4" [RFC3056], ISATAP [ISATAP] and DSTM [DSTM]. ==> In the above IPv4 context, DSTM is not a dynamic tunneling mechanism. 3.1 Dual Stack UE connecting to IPv4 and IPv6 nodes However, if the GGSN does not support IPv6 Access Points, and an application on the UE needs to communicate with an IPv6 node, the ==> I didn't know Access Points enter to the picture; they weren't mentioned in the architecture section in any case. UE may activate an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a dynamic or static tunneling mechanism. Tunneling in ==> I assume the use can connect to a different GGSN for v4 and v6. 3.4 IPv6 UE connecting to an IPv4 node ==> Here, it's possibly better to talk about NA(P)T-PT than plain NAPT-PT; the latter might confuse folks. 3GPP networks are expected to handle a very large number of subscribers on a single GGSN (default router). Each GGSN is expected to handle hundreds of thousands of connections. Furthermore, high reliability is expected for 3GPP networks. Consequently, a single point of failure on the GGSN external interface, would raise concerns on the overall network reliability. ==> Note that if NAT-PT function is implemented in the GGSN, the reliability requirement for NAT-PT need not be higher than with GGSN: if GGSN terminates hundreds of thousands of connections, the wording appears to hint to a possible fact that GGSN may be single point of failure (for a more basic set of functionlity) for them too. 4.2 UE connecting to a node in an IPv4 network through IMS This scenario occurs when an IMS UE (IPv6) connects to a node in the IPv4 Internet through the IMS, or vice versa. This happens when the other node is a part of a different system than 3GPP, e.g. a fixed PC, with only IPv4 capabilities. Apparently there will be a number of legacy IPv4 nodes in the Internet that will communicate with the IMS UEs. As the IMS is exclusively IPv6, translators have to be used in the communication between the IPv6 IMS and legacy IPv4 hosts. This section aims to give an overview on how that interworking can be handled. ==> IMO, I'm not 100% sure this number of legacy IPv4 nodes *IMS* communicates with is necessarily all that large. If I understood correctly, that means basically v4-only SIP phones. Are there really all that many of those. SIP phones that could not be relatively easily upgraded to IPv6? If the number of scenarios to support were to be shortened, IMO this would be among the first ones to go. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 11:36:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10361 for ; Thu, 19 Sep 2002 11:36:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3N3-0000gs-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:37:37 -0700 Received: from dns.nexthop.com ([64.211.218.216] helo=presque.djinesys.com) by psg.com with esmtp (Exim 3.36 #1) id 17s3My-0000fT-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:37:32 -0700 Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8JFbOO70902; Thu, 19 Sep 2002 11:37:24 -0400 (EDT) (envelope-from mrr@mrichardson.nexthop.com) Received: from paradigm.nexthop.com (mrichardson.nexthop.com [64.211.218.45]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8JFbLG70893; Thu, 19 Sep 2002 11:37:21 -0400 (EDT) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8JFbLN08623; Thu, 19 Sep 2002 11:37:21 -0400 (EDT) Date: Thu, 19 Sep 2002 11:37:21 -0400 From: Mathew Richardson To: Jun-ichiro itojun Hagino Cc: v6ops@ops.ietf.org Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Message-ID: <20020919153721.GF15788@nexthop.com> References: <20020919011455.335147B9@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020919011455.335147B9@starfruit.itojun.org> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Jun-ichiro itojun Hagino [Thu, Sep 19, 2002 at 10:14:55AM +0900]: >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >%page > >32bit IDs > > A lot of protocols use 32bit IDs > 32bit IDs = management headaches, scalability limitation > > What is the domain of uniqueness? > OSPF - within an AS > BGP - worldwide uniqueness needed I just thought it was worth mentioning that BGP doesn't require a worldwide, unique ID. Indeed, it is my understanding that even in actual operational deployment, rfc1918 addresses are often used for BGP IDs. mrr From owner-v6ops@ops.ietf.org Thu Sep 19 11:45:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10905 for ; Thu, 19 Sep 2002 11:45:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3VA-0001Md-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:46:00 -0700 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by psg.com with esmtp (Exim 3.36 #1) id 17s3V6-0001MQ-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:45:56 -0700 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8JFjrM16037; Thu, 19 Sep 2002 10:45:53 -0500 (CDT) Message-ID: <3D89F165.70402@alcatel.com> Date: Thu, 19 Sep 2002 10:46:45 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: raw thoughts on v6 firewalls References: <3D89DF51.3090901@alcatel.com> <3D89EB63.810A2CA5@hursley.ibm.com> Content-Type: multipart/alternative; boundary="------------030700010207070100080606" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --------------030700010207070100080606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Now I understand that it is somewhat orthogonal. Using site local addresses the intranet can avoid seeing company emails on Google's search engine, but how to avoid having ftp sites to be not accessible from the Internet? Maybe this is also possible using site local addresses. Would then be a good idea to ask MIDCOM WG to come up with new RFCs (-bis) replacing the present v4 only ones to standardize v6 firewalls? Why this such an important issue did not come up during the long standardization period in which v6 was developed? Regards, Brian E Carpenter wrote: >Behcet Sarikaya wrote: > > >>Hello Pekka, >> Site-local addresses would provide the same functionality and >>therefore there is no need to introduce firewalls into v6. >> Is there anything wrong with the above argument? >> >> > >Lots. It's very similar to the argument that NAT is a security >feature, which is absolutely untrue. > >Firewalls block incoming connections with global destination addresses. >The existence of site-local addresses is orthogonal to this. You still >need to allow some incoming connections to global addresses, and >block others. > >(Firewalls do more than that, but this is sufficient to answer >your question.) > > Brian > > > -- Behcet --------------030700010207070100080606 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Now I understand that it is somewhat orthogonal. Using site local addresses the intranet can avoid seeing company emails on Google's search engine, but how to avoid having ftp sites to be not accessible from the Internet? Maybe this is also possible using site local addresses.

Would then be a good idea to ask MIDCOM WG to come up with new RFCs (-bis) replacing the present v4 only ones to standardize v6 firewalls?
Why this such an important issue did not come up during the long standardization period in which v6 was developed?

Regards,

Brian E Carpenter wrote:
Behcet Sarikaya wrote:
  
Hello Pekka,
  Site-local addresses would provide the same functionality and
therefore there is no need to introduce firewalls into v6.
  Is there anything wrong with the above argument?
    

Lots. It's very similar to the argument that NAT is a security
feature, which is absolutely untrue.

Firewalls block incoming connections with global destination addresses. 
The existence of site-local addresses is orthogonal to this. You still
need to allow some incoming connections to global addresses, and
block others.

(Firewalls do more than that, but this is sufficient to answer
your question.)
  
   Brian

  

-- 
Behcet

--------------030700010207070100080606-- From owner-v6ops@ops.ietf.org Thu Sep 19 11:46:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10994 for ; Thu, 19 Sep 2002 11:46:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3XH-0001SL-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:48:11 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17s3XE-0001S7-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:48:08 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 4E7667BB; Fri, 20 Sep 2002 00:48:01 +0900 (JST) To: Pekka Savola Cc: v6ops@ops.ietf.org In-reply-to: pekkas's message of Thu, 19 Sep 2002 18:34:23 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: unmanaged scope comments From: Jun-ichiro itojun Hagino Date: Fri, 20 Sep 2002 00:48:01 +0900 Message-Id: <20020919154801.4E7667BB@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >==> connectivity includes one very important component IMO: the quality of >network connections. This is often ignored. It's a high risk for a vendor >to enable IPv6 by default, for example, if that'd result in lower quality >connections to e.g. dual-stack web servers (a very real fact in 6bone), this >should be taken into consideration at least in the short term. i don't understand what you want to do about it. will you ping/ping6 destination and pick shorter roundtrip? when multiple A records are returned for www.foo.com, do you probe them to get the optimal performance? i believe the "quality" factor does not matter, and it cannot be measured from endpoint (at least within short time). itojun From owner-v6ops@ops.ietf.org Thu Sep 19 11:48:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11055 for ; Thu, 19 Sep 2002 11:48:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3Z8-0001dD-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 08:50:06 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17s3Z4-0001cb-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 08:50:02 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A0F487BB; Fri, 20 Sep 2002 00:49:58 +0900 (JST) To: Mathew Richardson Cc: v6ops@ops.ietf.org In-reply-to: mrr's message of Thu, 19 Sep 2002 11:37:21 -0400. <20020919153721.GF15788@nexthop.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt From: Jun-ichiro itojun Hagino Date: Fri, 20 Sep 2002 00:49:58 +0900 Message-Id: <20020919154958.A0F487BB@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> BGP - worldwide uniqueness needed >I just thought it was worth mentioning that BGP doesn't require >a worldwide, unique ID. Indeed, it is my understanding that >even in actual operational deployment, rfc1918 addresses are >often used for BGP IDs. does the above still hold for EBGP routers? itojun From owner-v6ops@ops.ietf.org Thu Sep 19 12:00:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11634 for ; Thu, 19 Sep 2002 12:00:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3k5-0002Ok-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 09:01:25 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s3k1-0002OZ-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 09:01:22 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JG1Fr14721; Thu, 19 Sep 2002 19:01:15 +0300 Date: Thu, 19 Sep 2002 19:01:15 +0300 (EEST) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: Re: unmanaged scope comments In-Reply-To: <20020919154801.4E7667BB@starfruit.itojun.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=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 20 Sep 2002, Jun-ichiro itojun Hagino wrote: > >==> connectivity includes one very important component IMO: the quality of > >network connections. This is often ignored. It's a high risk for a vendor > >to enable IPv6 by default, for example, if that'd result in lower quality > >connections to e.g. dual-stack web servers (a very real fact in 6bone), this > >should be taken into consideration at least in the short term. > > i don't understand what you want to do about it. will you ping/ping6 > destination and pick shorter roundtrip? when multiple A records > are returned for www.foo.com, do you probe them to get the optimal > performance? That's a difficult, general question to consider. It's not easy. I've said one very real possibility to *not* introduce production services in the same DNS names yet.. > i believe the "quality" factor does not matter, and > it cannot be measured from endpoint (at least within short time). Connection to U.S. from Europe being 400 ms (and a few packets getting lost here and there) versus 150 ms is very measurable even without any tools e.g. in web browsing. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 12:06:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11989 for ; Thu, 19 Sep 2002 12:06:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3q5-0002qi-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 09:07:37 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17s3q1-0002qI-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 09:07:33 -0700 Received: from pixsv68.isi.com (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8JGL6E28804; Thu, 19 Sep 2002 12:21:06 -0400 (EDT) Date: Thu, 19 Sep 2002 12:04:58 -0400 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: input to the scenario design team for the analysis of solutions. Message-ID: <553710000.1032451498@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11989 -- jeudi, septembre 19, 2002 03:11:03 +0300 Pekka Savola wrote/a écrit: > On Wed, 18 Sep 2002, Marc Blanchet wrote: >> TSP has been implemented by many implementors [...] > > Could you elaborate? I haven't compiled a list, but we received questions on the draft from guys that were implementing it. We actually fixed a few things based on some comments. Marc. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Thu Sep 19 12:13:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12446 for ; Thu, 19 Sep 2002 12:13:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3xm-0003QK-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 09:15:34 -0700 Received: from web13003.mail.yahoo.com ([216.136.174.13]) by psg.com with smtp (Exim 3.36 #1) id 17s3xh-0003Pi-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 09:15:29 -0700 Message-ID: <20020919161529.89974.qmail@web13003.mail.yahoo.com> Received: from [192.73.222.228] by web13003.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 09:15:29 PDT Date: Thu, 19 Sep 2002 09:15:29 -0700 (PDT) From: Fred Templin Subject: Re: memo, 1st day PM To: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Cc: osprey67@yahoo.com In-Reply-To: <20020919001425.412397B9@starfruit.itojun.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-1.9 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello Itojun, Fred Templin here - I don't currently have access to my work e-mail so I'm using a private e-mail account. I noticed an item missing from your "memo, 1st day PM" during Yanick's enterprise/managed talk. At the end of the talk, I noted that during the Yokohama IETF Tim Gleeson offered our document entitled "ISATAP Transition Scenario for Enterprise/Managed Network" for the enterprise team and that I subsequently re-iterated the offer. Yanick responded in the affirmative and mentioned that a document from Paul Gilbert from cisco had also been offered. I asked whether the team had examined the ISATAP document for possible text reuse, and Yanick responded that the document was still on the table. Thank you, Fred Templin osprey67@yahoo.com P.S. (In case you are wondering, the "osprey" is my favorite bird because it is the most skilled of all fishing hawks, and fishing is my favorite activity. "67" is my high school football jersey number, as can only be told by checking P. 146 of the 1979 class yearbook from Dallas High School in Dallas, PA.) --- Jun-ichiro itojun Hagino wrote: > [not a official minutes] > > shin miyakawa (operator's input) > commercial IPv4/v6 dual stack ADSL operation > tokyo only, $6/mo, 8-10Mbps DSL > existing application - IPv4 > new applications (VoIP, VCR, whatever) - IPv6 > > specification between NTT and router vendors > > translate spec into informational RFC? > > RADIUS -1- BAS -2- DSL router -3- host > > 1: RADIUS/IPv6 > 2: PPP(IPv6CP), DHCPv6 <-- this part, NTT cares > 3: stateless addr conf, DNS discovery (up to customer) > > 1 IPv4 dynamic, /48 IPv6 static > IPv4 addr change - reassignment at POP, whatever > IPv6 friendly DNS server > customer: primary server (IPv6 only) > NTT: secondary server (IPv4/IPv6) > > hesham: where to buy router? > shin: yes, there are vendors (JP and non-JP). > thaler: ::53, subnet number = 0x0000? > shin: yes. > ?: charging model? per-address? > shin: no, not for IPv6. > shin: pressure for preserving IPv4 addr is severe in JP > > translate it, and make v6ops wg document (informational) > > hinden: not the only way to realize DSL service (clarify) > shin: correct, example scenario > itojun: change control? > shin: ok > > important thing: use same mechanism everywhere > > include it into ISP document > > ?: what kind of other magic numbers are you using? > shin: ::1, ::2 > ?: there are other translators involved in SMTP and such? > shin: no, customers use IPv4 (dynamic) addr > > intro to breakout session > > cellular > scenarios document changes > introduction to relevant 3GPP concepts added > PDP type PPP added > picture added > this document should be pretty stable by now > > GPRS scenarios > dual stack -> IPv4/v6 nodes > IPv6 only --IPv4 cloud-- IPv6 only > IPv4 only --IPv6 cloud-- IPv4 only > IPv6 only -> IPv4 only > IPv4 only -> IPv6 only > IMS scenarios > > target dates > 04/2002 - first rev > 09/2002 - second rev > design team started > 05/2002 > first solution draft published > IETF54 > 09/2002 second draft > solution draft finalized > IETF55/end of 2002 > > could this document be taken as a WG item? > > agenda for drafting session > solution, document introduction > nat-pt issues > scenario walk-through > GPRS scenarios > transition scenarios with IMS > wrap-up > > randy: confused about 2 documents > environment, what we need, how do we solve problems > bound: do we want to do the same for 3GPP-2? > soi: not sure > hesham: 3GPP-2 haven't done with any of IPv6 thingy yet > (especially mobile-ip6) > soi: multiple document for 3GPP and 3GPP-2? should be fine. > > sense of room > people willing to review/help improve document? (modulo design team) > - there are. > > read? - a lot > > accept as starting point? - a lot > should not accept as starting point? - none > > ISP > scope of work > define the problem set of scenarios > core/backbone > broadband hybrid fiber coax/cable > broadband dslmnarrowband dialup > ethernet to the home/home networking > internet exchange points > security (detection/prevention) > network management > > outline > toplogy > physical, logical > hardware > routers, switches, cpe > routing > igp, egp, irr, addressing, nat, aggregation > policing > filtering, traffic engineering > security > IDS, prevention > network management > out of band conf tools, snmp > hosting gear > DNS, radius, tacacs, mail, tools, cacheing > > updates since IETF54 > accepted as ngtrans wg document > 01 draft submitted > detailed discussion on DSL > renamed to v6ops > remain personal draft until all sections filled in > added IX section > all sections should be filled in by IETF55 > > breakout > review outline > review existing document > > itojun: DSL detail maybe too much > rob: DSL detail was helpful > > unmanaged > scenario (scoping) > evaluation (analysis) > > scope: exploring the problem space > applications > what are the application needs? > local, client, p2p, server > presented in yokohama > phases(X), stages(X), cases of transition > A: gateway is IPv4 only > B: gateway & ISP dual stack > C: gateway dual stack, ISP v4 only > D: gateway dual stack, ISP v6 only > > A: > consensus - this is a real need, not all gateways can be easily upgraded > hosts ipv4 or dual stack > applications: client, p2p with outside > connectivity requirement > automatic tunnelling over UDP > aim for minimal server requirement > naming requirement > DNS access over v4 > reverse lookup for client apps > > B: > main line transition case > hosts: v4 only, dual stack, v6 only > apps: > local applications across the stacks > ipv6 only clients access ipv4 services > question mark: ipv4 client access ipv6 services > backward vs forward compatibility > p2p with outside = single stack > ipv6 servers accessible from outside > connectivity requirements > unmanaged network is dual stack > need "ipv6 prefix delegation" to gateway > some form of translation between local ipv4 and local ipv6 > some form of translation between local ipv6 and global ipv4 services > naming requirements > name lookup service independent of protocol > dual stack home must get same answer if querying over v4 or v6 > local applications must work > shadow of ipv4 only hosts in ipv6, and vice versa > not just a DNS issue (SLP, proprietary naming) > need to 'register' autoconfigured ipv6 addr > direct lookup (local/server apps) > reverse lookup (client apps) > > rob: adhoc needs another analysis > bound: military case > hinden: military is more like adhoc? > ?: some people don't consider it important to make v4-only and v6-only interwork. dualstack > short-lived === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com From owner-v6ops@ops.ietf.org Thu Sep 19 12:14:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12474 for ; Thu, 19 Sep 2002 12:14:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s3yE-0003Sh-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 09:16:02 -0700 Received: from [2001:240:5b:1:202:2dff:fe09:7fe1] (helo=fiji.nezu.wide.ad.jp) by psg.com with esmtp (Exim 3.36 #1) id 17s3y8-0003SK-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 09:15:57 -0700 Received: from localhost (fiji.nezu.wide.ad.jp [::1]) by fiji.nezu.wide.ad.jp (8.11.6/8.11.3) with ESMTP id g8JGFWm25924; Fri, 20 Sep 2002 01:15:32 +0900 (JST) Date: Fri, 20 Sep 2002 01:15:32 +0900 (JST) Message-Id: <20020920.011532.117806032.kato@wide.ad.jp> To: itojun@iijlab.net Cc: mrr@nexthop.com, v6ops@ops.ietf.org Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt From: Akira Kato In-Reply-To: <20020919154958.A0F487BB@starfruit.itojun.org> References: <20020919153721.GF15788@nexthop.com> <20020919154958.A0F487BB@starfruit.itojun.org> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> BGP - worldwide uniqueness needed >>I just thought it was worth mentioning that BGP doesn't require >>a worldwide, unique ID. Indeed, it is my understanding that >>even in actual operational deployment, rfc1918 addresses are >>often used for BGP IDs. > does the above still hold for EBGP routers? Yes. It is an ID rather than an address. You can not establish an (E|I)BGP session between a pair of routers with the same ID. If you use BGP route reflectors, the ID should be unique in the AS, as well. If you use BGP route servers, the ID should be unique in the IX, as well. In a private peering, randomly choosen IDs from RFC1918 space rarely cause a collision. It is better to have deterministic ways to define the IDs in bigger IXes, however. -- Akira Kato, WIDE Project From owner-v6ops@ops.ietf.org Thu Sep 19 12:30:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13068 for ; Thu, 19 Sep 2002 12:30:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s4DU-0004V2-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 09:31:48 -0700 Received: from dns.nexthop.com ([64.211.218.216] helo=presque.djinesys.com) by psg.com with esmtp (Exim 3.36 #1) id 17s4DQ-0004Up-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 09:31:44 -0700 Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8JGVY373038; Thu, 19 Sep 2002 12:31:34 -0400 (EDT) (envelope-from mrr@mrichardson.nexthop.com) Received: from paradigm.nexthop.com (mrichardson.nexthop.com [64.211.218.45]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8JGVUG73022; Thu, 19 Sep 2002 12:31:30 -0400 (EDT) (envelope-from mrr@mrichardson.nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8JGVUk08820; Thu, 19 Sep 2002 12:31:30 -0400 (EDT) Date: Thu, 19 Sep 2002 12:31:30 -0400 From: Mathew Richardson To: Akira Kato Cc: itojun@iijlab.net, v6ops@ops.ietf.org Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Message-ID: <20020919163130.GI15788@nexthop.com> References: <20020919153721.GF15788@nexthop.com> <20020919154958.A0F487BB@starfruit.itojun.org> <20020920.011532.117806032.kato@wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020920.011532.117806032.kato@wide.ad.jp> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Akira Kato [Fri, Sep 20, 2002 at 01:15:32AM +0900]: > >>>> BGP - worldwide uniqueness needed >>>I just thought it was worth mentioning that BGP doesn't require >>>a worldwide, unique ID. Indeed, it is my understanding that >>>even in actual operational deployment, rfc1918 addresses are >>>often used for BGP IDs. > >> does the above still hold for EBGP routers? > >Yes. It is an ID rather than an address. You can not establish an >(E|I)BGP session between a pair of routers with the same ID. If you >use BGP route reflectors, the ID should be unique in the AS, as well. >If you use BGP route servers, the ID should be unique in the IX, as >well. Agreed with all of the above. I'd say that operationally, even without route-reflectors, IDs should be unique within the AS. (IBGP peering sessions often take place over addresses that correspond to the BGP ID, for example.) >In a private peering, randomly choosen IDs from RFC1918 space rarely >cause a collision. It is better to have deterministic ways to define >the IDs in bigger IXes, however. Also agreed. As a final point, the current BGP specification does require that the BGP Identifier be set to an IP[v4] address assigned to the BGP speaker; however, there are deployed implementations that don't require this. mrr From owner-v6ops@ops.ietf.org Thu Sep 19 12:49:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13830 for ; Thu, 19 Sep 2002 12:49:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s4Vi-0005qr-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 09:50:38 -0700 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #1) id 17s4Ve-0005qD-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 09:50:34 -0700 Subject: RE: raw thoughts on v6 firewalls Date: Thu, 19 Sep 2002 09:50:36 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E30A@server2000> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: raw thoughts on v6 firewalls content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Index: AcJf9CwtFYCGYILkScqusIuNQvtudQABsUUw From: "Michel Py" To: "Behcet Sarikaya" , "Brian E Carpenter" Cc: "Pekka Savola" , X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13830 > Behcet Sarikaya wrote: > Site-local addresses would provide the same functionality > and therefore there is no need to introduce firewalls into > v6. Is there anything wrong with the above argument? Something very wrong, IMHO: you would have to introduce IPv6 NAT if these hosts have to talk to the outside world. > Now I understand that it is somewhat orthogonal. Using > site local addresses the intranet can avoid seeing company > emails on Google's search engine, but how to avoid having > ftp sites to be not accessible from the Internet? Maybe > this is also possible using site local addresses. Site-local addresses make sense for hosts that *never* have to access the Internet, neither egress nor ingress. If a host with a site-local address needs to communicate with the outside, I think that everyone agrees that it is much preferable to give it a public address as well as the site-local one rather than using the site-local only and IPv6 NAT. Michel. From owner-v6ops@ops.ietf.org Thu Sep 19 13:57:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16237 for ; Thu, 19 Sep 2002 13:57:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s5ZJ-000ARH-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 10:58:25 -0700 Received: from mail.s3.kth.se ([130.237.48.5] helo=elixir.e.kth.se) by psg.com with esmtp (Exim 3.36 #1) id 17s5ZE-000AR4-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 10:58:21 -0700 Received: from staffan.e.kth.se (staffan.e.kth.se [130.237.48.118]) by elixir.e.kth.se (8.12.3/8.12.3) with ESMTP id g8JHw3Ae317105; Thu, 19 Sep 2002 19:58:03 +0200 (CEST) Received: (from lha@localhost) by staffan.e.kth.se (8.11.6/8.9.3) id g8JHw2L29785; Thu, 19 Sep 2002 19:58:02 +0200 X-Authentication-Warning: staffan.e.kth.se: lha set sender to lha@stacken.kth.se using -f To: "Bound, Jim" Cc: "Pekka Savola" , "Marc Blanchet" , , , Subject: Re: comment on unmanaged analysis presentation/doc References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92A4@tayexc13.americas.cpqcorp.net> From: Love Date: 19 Sep 2002 19:57:57 +0200 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92A4@tayexc13.americas.cpqcorp.net> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,FROM_NAME_NO_SPACES version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk "Bound, Jim" writes: > Marc did explicitly ask that TSP be a v6ops mechanism for discussion. > > To address that question with my input. > > I believe TSP is an important tool for users. I believe we can begin > work on this tool within v6ops and support it being worked on within this > list. > > Others should respond here with your opinion and this is important per > Margarets talk today. One way or the other. There are issues with tsp-draft as it is today, I've sent some comments to the authors. I think tsp is good tool when you want to set up explicit tunnels. Love From owner-v6ops@ops.ietf.org Thu Sep 19 14:07:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16575 for ; Thu, 19 Sep 2002 14:07:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s5j3-000B88-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:08:29 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17s5iz-000B7d-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:08:25 -0700 Received: from pixsv68.isi.com (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8JILvE30201; Thu, 19 Sep 2002 14:21:57 -0400 (EDT) Date: Thu, 19 Sep 2002 12:33:55 -0400 From: Marc Blanchet To: Pekka Savola cc: v6ops@ops.ietf.org, phil@nesser.com, ntp@viagenie.qc.ca, =?ISO-8859-1?Q?Jean-Fran=E7ois_Boudreault?= Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Message-ID: <579940000.1032453235@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16575 -- jeudi, septembre 19, 2002 04:10:47 +0300 Pekka Savola wrote/a écrit: > On Wed, 18 Sep 2002, Marc Blanchet wrote: >> -- mercredi, septembre 18, 2002 23:32:17 +0300 Pekka Savola >> wrote/a écrit: >> >> >> you are right. You are suggesting which process? > > Re-publish the old refid internet-draft or or create a new one; one > indended to Update the NTP RFC. > > Perhaps D. Mills as the NTP author and/or apps Area Director could have > some ideas how to proceed. > > I think you agree that we need to keep this issue up and open until we're > a bit farther in the NTP for v6 extension specification process. > This is more a process item that I leave to the wg chairs to what to do. We are open to do whatever is needed to help. We do have good links with the ntp team. Marc. > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Thu Sep 19 14:07:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16595 for ; Thu, 19 Sep 2002 14:07:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s5jZ-000BCl-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:09:01 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17s5jU-000BCR-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:08:56 -0700 Received: from pixsv68.isi.com (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8JILsE30196; Thu, 19 Sep 2002 14:21:54 -0400 (EDT) Date: Thu, 19 Sep 2002 12:15:24 -0400 From: Marc Blanchet To: Pekka Savola cc: huitema@microsoft.com, satapati@cisco.com, v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc Message-ID: <561560000.1032452123@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16595 -- jeudi, septembre 19, 2002 03:47:06 +0300 Pekka Savola wrote/a écrit: > On Wed, 18 Sep 2002, Marc Blanchet wrote: >> case A where IPv4 nat is present: >> - teredo is one mechanism. In fact, what is needed is ipv6 over >> udp-ipv4 (i.e. nat traversal). >> - in this space, tsp with udp-ipv4 encapsulation is also a viable >> solution. It also enables the unmanaged network to receive automatic >> data needed for the unmanaged network: i.e. ipv6 network prefix for >> example. (reference = draft-parent-blanchet-ngtrans-tsp-teredo-00.txt). >> - the unmanaged draft says: "A variant of the [TEREDO] technology could >> be used to establish >> tunnels over UDP when the client cannot use a global IPv4 address; >> this variant is however not standardized." >> (if this text refers to our draft, then the comment is not >> appropriate: i.e. the variant is not standardized. teredo is also not >> standardized yet.) > > Teredo does more than just sets up a tunnel. In the case of NAT, in > particular, keeping the pipe open is also an important task. agreed. > The draft > does not explicitly address this, I believe. we had a hard time to write this document, because it was enough similar to teredo. So we decide to only state the diffs. And you are right that the info on the keep-alive/bubble is not really discussed. should be fixed in the next rev. > > Further discussion on teredo/tsp should probably be sent to ngtrans. I leave it to the chairs. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Thu Sep 19 14:07:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16612 for ; Thu, 19 Sep 2002 14:07:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s5jC-000B9V-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:08:38 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17s5j5-000B8X-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:08:31 -0700 Received: from pixsv68.isi.com (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8JIM0E30207; Thu, 19 Sep 2002 14:22:00 -0400 (EDT) Date: Thu, 19 Sep 2002 12:37:15 -0400 From: Marc Blanchet To: Jun-ichiro itojun Hagino , Pekka Savola cc: v6ops@ops.ietf.org, phil@nesser.com, ntp@viagenie.qc.ca, =?ISO-8859-1?Q?Jean-Fran=E7ois_Boudreault?= Subject: Re: draft-ietf-ngtrans-ipv4survey-02.txt Message-ID: <583540000.1032453435@classic.viagenie.qc.ca> In-Reply-To: <20020919011455.335147B9@starfruit.itojun.org> References: <20020919011455.335147B9@starfruit.itojun.org> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16612 -- jeudi, septembre 19, 2002 10:14:55 +0900 Jun-ichiro itojun Hagino wrote/a écrit: >> On Wed, 18 Sep 2002, Marc Blanchet wrote: >>> -- mercredi, septembre 18, 2002 23:32:17 +0300 Pekka Savola >>> wrote/a ?$BqD?(Brit: >>> > > this is a slide i will be using tomorrow. hope it is useful. > > itojun > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %page > > 32bit IDs > > A lot of protocols use 32bit IDs > 32bit IDs = management headaches, scalability limitation > > What is the domain of uniqueness? > OSPF - within an AS > BGP - worldwide uniqueness needed > > How wide does ID need to be? > 128bit - global IPv6 address can be used > 64bit - EUI64 maybe? (not guaranteed to be unique) > 64bit - 32bit AS number + 32bit serial (management headache) > 32bit - insufficient (32bit AS numbers) very good start. one note about eui-64: for any "server-permanent-like" service, generic bcp is to not use the eui-64 as the published address so that in the event of hardware change, then the published non-eui64 address is still working. this means that there is a low chance that eui-64 would be a universal solution to identifiers. (not that it could not be used, but it has some limitations) Marc. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Thu Sep 19 14:08:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16707 for ; Thu, 19 Sep 2002 14:08:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s5kr-000BId-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:10:21 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17s5kn-000BIE-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:10:17 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E72273A59; Thu, 19 Sep 2002 14:10:16 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 19 Sep 2002 14:10:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comment on unmanaged analysis presentation/doc Date: Thu, 19 Sep 2002 14:10:16 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92B8@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on unmanaged analysis presentation/doc Thread-Index: AcJgBhvX544+5ieKQSSnY4yt3LS/tAAAXyFQ From: "Bound, Jim" To: "Love" Cc: "Pekka Savola" , "Marc Blanchet" , , , X-OriginalArrivalTime: 19 Sep 2002 18:10:16.0639 (UTC) FILETIME=[CE9034F0:01C26007] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16707 clearly making the tsp spec (converged marc/fred) is our mission. and setting up explicit tunnels is required for deployment right now. the key is if the chairs can bless this work and say lets go and do tsp. Or if I were marc and fred I would be hard pressed into putting a lot of work into this. /jim > -----Original Message----- > From: Love [mailto:lha@stacken.kth.se] > Sent: Thursday, September 19, 2002 1:58 PM > To: Bound, Jim > Cc: Pekka Savola; Marc Blanchet; huitema@microsoft.com; > satapati@cisco.com; v6ops@ops.ietf.org > Subject: Re: comment on unmanaged analysis presentation/doc > > > "Bound, Jim" writes: > > > Marc did explicitly ask that TSP be a v6ops mechanism for > discussion. > > > > To address that question with my input. > > > > I believe TSP is an important tool for users. I believe we > can begin > > work on this tool within v6ops and support it being worked > on within this > > list. > > > > Others should respond here with your opinion and this is > important per > > Margarets talk today. One way or the other. > > There are issues with tsp-draft as it is today, I've sent > some comments to > the authors. > > I think tsp is good tool when you want to set up explicit tunnels. > > Love > From owner-v6ops@ops.ietf.org Thu Sep 19 14:19:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17254 for ; Thu, 19 Sep 2002 14:19:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s5vg-000C9b-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:21:32 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17s5vd-000C9E-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:21:29 -0700 Received: from kenawang.windriver.com ([147.11.233.36]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA00082; Thu, 19 Sep 2002 11:18:00 -0700 (PDT) Message-Id: <5.1.0.14.2.20020919141356.029ca520@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Sep 2002 14:19:38 -0400 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: comment on unmanaged analysis presentation/doc Cc: "Love" , "Pekka Savola" , "Marc Blanchet" , , , In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92B8@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Jim, >the key is if the chairs can bless this work and say lets go and do >tsp. Or if I were marc and fred I would be hard pressed into putting a >lot of work into this. It isn't covered in our charter to "bless" any new transition mechanisms work unless/until the need for a new mechanism is identified and document in the scenario/analysis effort. If we keep pushing on the analysis documents, I hope we will get to a point in the next few months where we do have consensus to start work on some of the needed transition mechanisms. But, we aren't there yet. We will also need to make sure that we understand how the existing transition mechanisms RFCs do/don't fit together, so that we understand the impact of introducing new mechanisms into the overall architecture. Margaret From owner-v6ops@ops.ietf.org Thu Sep 19 14:21:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17338 for ; Thu, 19 Sep 2002 14:21:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s5xK-000CHs-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:23:14 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17s5xG-000CHc-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:23:10 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A70037C1; Fri, 20 Sep 2002 03:18:30 +0900 (JST) To: v6ops@ops.ietf.org Subject: breakout session - ISP X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Fri, 20 Sep 2002 03:18:30 +0900 Message-Id: <20020919181830.A70037C1@starfruit.itojun.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk [not a official minutes] review outline review existing draft scope of work define the problem set of scenarios core backbone broadband hybrid fiber coax/cable broadband dsl narrowband dialup ethernet to home/home networking IX security (detection/prevention) network management provide solutions/analysis in a companion document each of the sections need reviews/inputs/text to be added. pekka: ethernet - not necessarily home itojun: ethernet - in japan, nationwide ethernet service is popular so non-home use is popular ?: focus to ethernet access pekka: focus to "ethernet access", not "ethernet vpn" - why "home"? ?: ethernet access. itojun: does link type matter? split like "p2p" "broadcast shared medium" droms: home networking? itojun: dsl can be home, can be office. let's remove "home" pekka: there are specific problem in home, but it can be covered in other areas droms: overwrap between "home" and unmanaged group uncertain ?: server farms? itojun: enterprise. pekka: dns, smtp, whatever services? itojun: add "infrastructure services" droms: last-mile provider, "managed access" -> in 3.4 ?: included in dsl/whatever ?: wireless hotspot itojun: special case for dialup ?: L2 point of view, droms: dialup -> dialup/wireless core backbone broadband hybrid fiber coax/cable broadband dsl narrowband dialup broadband ethernet wireless hotspot IX security (detection/prevention) network management infrastucture services outline - problem set (each section authors will fill in details, for items that are applicable to their sections) topoology - physical/logical hardware - routers/switches/cpe routing - igp/egp/multicast/irr (routing policy)/addressing/nat/aggr traffic engineering security - ids, prevention, ingress filtering network management - out of band, config tools, snmp hosting gear - dns, radius, tacacs, mail, tools, caching ?: nat? itojun: there are providers giving out private address to customers ?: "policing" - implies QoS draft review core backbone - does the draft cover your model? DSL - does the draft cover your model? dynamic/static p2p/multi-access dialup - does the draft cover your model? core - cpe -> another isp itojun: there are 5 dsl pictures, no need to have 5 - anything under PPP shouldn't matter ?: ppp, shared medium DSL services droms: interaction with other standards groups? - docsis, cablelabs, whatever droms: how cpe will support ipv6? cleve: -> Aidan Williams droms: in analysis document, we need to capture those include discussions on applications, naming connectivity in all scenarios? shin: mail server? pop server? ?: infrasturcture service for yourself, and providing for customer From owner-v6ops@ops.ietf.org Thu Sep 19 14:28:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17663 for ; Thu, 19 Sep 2002 14:28:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s64P-000CoS-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:30:33 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17s64L-000Co1-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:30:29 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BED5D3BC2; Thu, 19 Sep 2002 14:30:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 19 Sep 2002 14:30:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comment on unmanaged analysis presentation/doc Date: Thu, 19 Sep 2002 14:30:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92BB@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on unmanaged analysis presentation/doc Thread-Index: AcJgCP0V3zJmzZ9zSTmAfyxCs3reXAAAYFig From: "Bound, Jim" To: "Margaret Wasserman" Cc: "Love" , "Pekka Savola" , "Marc Blanchet" , , , X-OriginalArrivalTime: 19 Sep 2002 18:30:26.0428 (UTC) FILETIME=[9FA75BC0:01C2600A] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA17663 Margaret, OK. So the general Internet community cannot send individual IDs for tools to v6ops? I view tsp as tool not as transition mechanism? thanks /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, September 19, 2002 2:20 PM > To: Bound, Jim > Cc: Love; Pekka Savola; Marc Blanchet; huitema@microsoft.com; > satapati@cisco.com; v6ops@ops.ietf.org > Subject: RE: comment on unmanaged analysis presentation/doc > > > > Hi Jim, > > >the key is if the chairs can bless this work and say lets go and do > >tsp. Or if I were marc and fred I would be hard pressed > into putting a > >lot of work into this. > > It isn't covered in our charter to "bless" any new transition > mechanisms > work unless/until the need for a new mechanism is identified > and document > in the scenario/analysis effort. > > If we keep pushing on the analysis documents, I hope we will get to a > point in the next few months where we do have consensus to start work > on some of the needed transition mechanisms. But, we aren't there > yet. > > We will also need to make sure that we understand how the > existing transition > mechanisms RFCs do/don't fit together, so that we understand > the impact > of introducing new mechanisms into the overall architecture. > > Margaret > > > > > > > From owner-v6ops@ops.ietf.org Thu Sep 19 14:36:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17961 for ; Thu, 19 Sep 2002 14:36:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s6Be-000DKP-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:38:02 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17s6Bb-000DKD-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:37:59 -0700 Received: from kenawang.windriver.com ([147.11.233.36]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA14332; Thu, 19 Sep 2002 11:36:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20020919143555.029d0b70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Sep 2002 14:38:00 -0400 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: comment on unmanaged analysis presentation/doc Cc: "Love" , "Pekka Savola" , "Marc Blanchet" , , , In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92BB@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Jim, What do you mean by "send individual IDs for tools to v6ops"? Anyone can submit an individual ID, but v6ops may not adopt a work item (i.e. publish a WG ID) that isn't covered in our charter. Margaret At 02:30 PM 9/19/02, Bound, Jim wrote: >Margaret, > >OK. So the general Internet community cannot send individual IDs for >tools to v6ops? >I view tsp as tool not as transition mechanism? > >thanks >/jim > > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@windriver.com] > > Sent: Thursday, September 19, 2002 2:20 PM > > To: Bound, Jim > > Cc: Love; Pekka Savola; Marc Blanchet; huitema@microsoft.com; > > satapati@cisco.com; v6ops@ops.ietf.org > > Subject: RE: comment on unmanaged analysis presentation/doc > > > > > > > > Hi Jim, > > > > >the key is if the chairs can bless this work and say lets go and do > > >tsp. Or if I were marc and fred I would be hard pressed > > into putting a > > >lot of work into this. > > > > It isn't covered in our charter to "bless" any new transition > > mechanisms > > work unless/until the need for a new mechanism is identified > > and document > > in the scenario/analysis effort. > > > > If we keep pushing on the analysis documents, I hope we will get to a > > point in the next few months where we do have consensus to start work > > on some of the needed transition mechanisms. But, we aren't there > > yet. > > > > We will also need to make sure that we understand how the > > existing transition > > mechanisms RFCs do/don't fit together, so that we understand > > the impact > > of introducing new mechanisms into the overall architecture. > > > > Margaret > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Thu Sep 19 14:52:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18442 for ; Thu, 19 Sep 2002 14:52:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s6RC-000EU2-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 11:54:06 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17s6R1-000ETE-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 11:53:55 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9CDDC39FD; Thu, 19 Sep 2002 14:53:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 19 Sep 2002 14:53:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comment on unmanaged analysis presentation/doc Date: Thu, 19 Sep 2002 14:53:52 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE92BC@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on unmanaged analysis presentation/doc Thread-Index: AcJgC5N760bOm5FwSuKdI2qFrGMnKAAAeOkw From: "Bound, Jim" To: "Margaret Wasserman" Cc: "Love" , "Pekka Savola" , "Marc Blanchet" , , , X-OriginalArrivalTime: 19 Sep 2002 18:53:53.0247 (UTC) FILETIME=[E62EE6F0:01C2600D] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA18442 Margaret, draft-privatename-function-00.txt. But what I think I am hearing is that we have a potential log jam via the scenarios being done? I do not believe those will be done till July/August 2003? Thats too late for current IPv6 deployment if true? thanks /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, September 19, 2002 2:38 PM > To: Bound, Jim > Cc: Love; Pekka Savola; Marc Blanchet; huitema@microsoft.com; > satapati@cisco.com; v6ops@ops.ietf.org > Subject: RE: comment on unmanaged analysis presentation/doc > > > > Jim, > > What do you mean by "send individual IDs for tools to v6ops"? > > Anyone can submit an individual ID, but v6ops may not adopt a work > item (i.e. publish a WG ID) that isn't covered in our charter. > > Margaret > > > At 02:30 PM 9/19/02, Bound, Jim wrote: > >Margaret, > > > >OK. So the general Internet community cannot send > individual IDs for > >tools to v6ops? > >I view tsp as tool not as transition mechanism? > > > >thanks > >/jim > > > > > -----Original Message----- > > > From: Margaret Wasserman [mailto:mrw@windriver.com] > > > Sent: Thursday, September 19, 2002 2:20 PM > > > To: Bound, Jim > > > Cc: Love; Pekka Savola; Marc Blanchet; huitema@microsoft.com; > > > satapati@cisco.com; v6ops@ops.ietf.org > > > Subject: RE: comment on unmanaged analysis presentation/doc > > > > > > > > > > > > Hi Jim, > > > > > > >the key is if the chairs can bless this work and say > lets go and do > > > >tsp. Or if I were marc and fred I would be hard pressed > > > into putting a > > > >lot of work into this. > > > > > > It isn't covered in our charter to "bless" any new transition > > > mechanisms > > > work unless/until the need for a new mechanism is identified > > > and document > > > in the scenario/analysis effort. > > > > > > If we keep pushing on the analysis documents, I hope we > will get to a > > > point in the next few months where we do have consensus > to start work > > > on some of the needed transition mechanisms. But, we aren't there > > > yet. > > > > > > We will also need to make sure that we understand how the > > > existing transition > > > mechanisms RFCs do/don't fit together, so that we understand > > > the impact > > > of introducing new mechanisms into the overall architecture. > > > > > > Margaret > > > > > > > > > > > > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Thu Sep 19 16:09:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21517 for ; Thu, 19 Sep 2002 16:09:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s7by-000KOL-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 13:09:18 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s7bu-000KOA-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 13:09:14 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JK8dZ17278; Thu, 19 Sep 2002 23:08:39 +0300 Date: Thu, 19 Sep 2002 23:08:38 +0300 (EEST) From: Pekka Savola To: bkhabs cc: v6ops@ops.ietf.org, Subject: Re: Re: ISP scenarios comments (multicast) In-Reply-To: <4547540.1032436716750.JavaMail.Administrator@ATP2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Sep 2002, bkhabs wrote: > >Ok; this is still a bit problematic with the one PIM domain requirement.. > >:-/ > > I don't think it is problematic when you consider the overhead that > would have to occur in order to support PIM domain != site-local domain. > > The major problem is that PIM messages are mostly sent hop-by-hop with > IP addresses in the payload. So, the Bootstrap message is transmitted > hop-by-hop using the All-PIM-Routers link-local multicast address. But > the BSR address is in the payload. That means that a site-local border > router would have to recognize the Bootstrap message, parse into the > PIM payload and check to see if the BSR-Address was a site-local. > > In this case, I prefer simplicity. Let pim domain == site-domain. I agree with the simplicity -- but the problem I was referring to was due to the fact that for all practical purposes, currently there can only be one PIM domain. That limits the applicability of multicast quite a bit. For one perspective, look at one PIM-domain at: http://sem2.renater.fr/m6bone/ Multicast works -- kinda. > >This might be an interesting point to develop more. It's quite possible > >if we can hard-code assumptions about address assignment for the RP there. > > >Possibly through an additional bit flag in the address. This would have to > >go to the PIM implementation then, though. > > You can't encode the RP in the field. Which field? Destination address could include the address of the RP, with some rather strict assumptions. > But, a new RP discovery mechanism > could utilize the prefix information to know where to look for the RP. That too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 16:18:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21836 for ; Thu, 19 Sep 2002 16:18:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s7ly-000LBD-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 13:19:38 -0700 Received: from secundus.nysernet.org ([192.77.173.5]) by psg.com with esmtp (Exim 3.36 #1) id 17s7lu-000LAY-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 13:19:34 -0700 Received: from [199.109.32.35] (cookiemonster.nysernet.org [199.109.32.35]) by secundus.nysernet.org (Postfix) with ESMTP id B21B9508F3; Thu, 19 Sep 2002 16:13:55 -0400 (EDT) Mime-Version: 1.0 X-Sender: owens@secundus.nysernet.org Message-Id: In-Reply-To: References: Date: Thu, 19 Sep 2002 16:19:32 -0400 To: Pekka Savola , v6ops@ops.ietf.org From: Bill Owens Subject: Re: unmanaged solutions comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 18:35 +0300 9/19/02, Pekka Savola wrote: >==> There are two problems with relays: > 1) configuring the relay on 6to4 router; anycast address helps a bit there. > 2) v6 nodes finding the closest relay advertising 2002::/16. This is not >addressed here, and I think is a major problem: there is zero guarantee >about how unoptimal the return path is (you can make some assumption about >the forward path, to the 6to4 relay close to you)! It strikes me that no tunneled infrastructure (automatic or manual setup) is likely to grow dense enough to provide really good performance, at least not without becoming unmanageable in its complexity. I have always regarded that as a fundamental tradeoff when using tunnels for anything, not just IPv6. 6to4 at least has the advantage of providing good pairwise connectivity between 6to4 routers, something that is not always the case with manually configured tunnels. Bill. From owner-v6ops@ops.ietf.org Thu Sep 19 16:26:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22016 for ; Thu, 19 Sep 2002 16:26:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s7tj-000Llb-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 13:27:39 -0700 Received: from secundus.nysernet.org ([192.77.173.5]) by psg.com with esmtp (Exim 3.36 #1) id 17s7te-000Lkg-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 13:27:35 -0700 Received: from [199.109.32.35] (cookiemonster.nysernet.org [199.109.32.35]) by secundus.nysernet.org (Postfix) with ESMTP id A8994508F3 for ; Thu, 19 Sep 2002 16:21:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: owens@secundus.nysernet.org Message-Id: In-Reply-To: <200209182158.g8ILwK020251@astro.cs.utk.edu> References: <200209182158.g8ILwK020251@astro.cs.utk.edu> Date: Thu, 19 Sep 2002 16:27:33 -0400 To: v6ops@ops.ietf.org From: Bill Owens Subject: Re: renumbering Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 17:58 -0400 9/18/02, Keith Moore wrote: >btw, I'm fully in agreement that people will use NATv6 or simply avoid v6 >if we don't make renumbering . . . and multihoming . . . >fairly painless. Bill. From owner-v6ops@ops.ietf.org Thu Sep 19 16:31:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22198 for ; Thu, 19 Sep 2002 16:31:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s7z4-000M9Y-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 13:33:10 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s7z0-000M9G-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 13:33:07 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JKX1T17556; Thu, 19 Sep 2002 23:33:01 +0300 Date: Thu, 19 Sep 2002 23:33:01 +0300 (EEST) From: Pekka Savola To: Bill Owens cc: v6ops@ops.ietf.org Subject: Re: unmanaged solutions comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Sep 2002, Bill Owens wrote: > At 18:35 +0300 9/19/02, Pekka Savola wrote: > >==> There are two problems with relays: > > 1) configuring the relay on 6to4 router; anycast address helps a bit there. > > 2) v6 nodes finding the closest relay advertising 2002::/16. This is not > >addressed here, and I think is a major problem: there is zero guarantee > >about how unoptimal the return path is (you can make some assumption about > >the forward path, to the 6to4 relay close to you)! > > It strikes me that no tunneled infrastructure (automatic or manual > setup) is likely to grow dense enough to provide really good > performance, at least not without becoming unmanageable in its > complexity. I have always regarded that as a fundamental tradeoff > when using tunnels for anything, not just IPv6. I'd perhaps reword that as "no global tunneled infrastructure". And even then I'd be a bit hesistant: tunneling across short distances is not that big a deal, but adding different administrative parties can make it more and more difficult. Solutions like ISATAP can provide rather good performance in a limited case; connections outside of the "site" could be native v6. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 16:39:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22479 for ; Thu, 19 Sep 2002 16:39:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s86w-000MhX-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 13:41:18 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s86q-000Mgs-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 13:41:13 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JKf9v17633; Thu, 19 Sep 2002 23:41:09 +0300 Date: Thu, 19 Sep 2002 23:41:09 +0300 (EEST) From: Pekka Savola To: Rod.VanMeter@nokia.com cc: v6ops@ops.ietf.org Subject: RE: raw thoughts on v6 firewalls In-Reply-To: <4D7B558499107545BB45044C63822DDE01771CA0@mvebe001.americas.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 18 Sep 2002 Rod.VanMeter@nokia.com wrote: > Unless I'm suffering total brain failure (never out of > the question), every extension header is supposed to have > the length in the same place, and one use is exactly that > reason. Not really, see other messages. > Pekka, are there other v6-specific firewall issues, and is this > the right place to discuss them? Yes, but that is the most major issue (the same applies to some specific destination options too). Others, not necessarily all IPv6-specific: - peer2peer recognition allow/disallow mechanism - need to be able to, in some cases, to be able to parse routing header or home-address option contents - the role of firewall in the presence of ESP-encrypted traffic -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 16:51:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22876 for ; Thu, 19 Sep 2002 16:51:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s8I5-000NV5-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 13:52:49 -0700 Received: from secundus.nysernet.org ([192.77.173.5]) by psg.com with esmtp (Exim 3.36 #1) id 17s8Hy-000NUj-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 13:52:42 -0700 Received: from [199.109.32.35] (cookiemonster.nysernet.org [199.109.32.35]) by secundus.nysernet.org (Postfix) with ESMTP id 82CAB508F2 for ; Thu, 19 Sep 2002 16:47:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: owens@secundus.nysernet.org Message-Id: In-Reply-To: References: Date: Thu, 19 Sep 2002 16:52:41 -0400 To: v6ops@ops.ietf.org From: Bill Owens Subject: Re: unmanaged solutions comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 23:33 +0300 9/19/02, Pekka Savola wrote: >I'd perhaps reword that as "no global tunneled infrastructure". And even >then I'd be a bit hesistant: tunneling across short distances is not that >big a deal, but adding different administrative parties can make it more >and more difficult. > >Solutions like ISATAP can provide rather good performance in a limited >case; connections outside of the "site" could be native v6. That's a good point. I'm thinking of the global IPv6 infrastructure and individual hosts or sites connecting to it. And I suspect that any solution for this case that uses tunnels, automatic or manual, is likely to face the problem of sub-optimal forward and/or reverse paths that you mentioned originally. In other words 6to4 is neither better nor worse, just different. As long as the density of tunnels is much less than the density of the connections in the underlying network, the path taken by the tunneled traffic between two points will be likely to be worse than the path taken by native traffic. And the well-known scaling problems of tunnels (including crossing administrative domains) makes it unlikely that they will become very dense without suffering maintainability problems. Since there are relatively few 6to4 relay routers out there, performance is often poor for 6to4 to native traffic. But the same is often true for tunnel brokers, and sometimes for manual tunnels. And at least 6to4 has good performance to other 6to4 sites. Bill. From owner-v6ops@ops.ietf.org Thu Sep 19 17:18:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23783 for ; Thu, 19 Sep 2002 17:18:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s8hy-000PJ9-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 14:19:34 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17s8hr-000PIC-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 14:19:27 -0700 Received: from pixsv68.isi.com (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8JLWmE32859; Thu, 19 Sep 2002 17:32:49 -0400 (EDT) Date: Thu, 19 Sep 2002 17:16:39 -0400 From: Marc Blanchet To: Bill Owens , v6ops@ops.ietf.org Subject: Re: unmanaged solutions comments Message-ID: <797030000.1032470199@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA23783 -- jeudi, septembre 19, 2002 16:52:41 -0400 Bill Owens wrote/a écrit: > At 23:33 +0300 9/19/02, Pekka Savola wrote: >> I'd perhaps reword that as "no global tunneled infrastructure". And even >> then I'd be a bit hesistant: tunneling across short distances is not that >> big a deal, but adding different administrative parties can make it more >> and more difficult. >> >> Solutions like ISATAP can provide rather good performance in a limited >> case; connections outside of the "site" could be native v6. > > That's a good point. I'm thinking of the global IPv6 infrastructure and > individual hosts or sites connecting to it. And I suspect that any > solution for this case that uses tunnels, automatic or manual, is likely > to face the problem of sub-optimal forward and/or reverse paths that you > mentioned originally. In other words 6to4 is neither better nor worse, > just different. automatic tunnels techniques usually mean (by design) that the path is not "controlled". > > As long as the density of tunnels is much less than the density of the > connections in the underlying network, the path taken by the tunneled > traffic between two points will be likely to be worse than the path taken > by native traffic. And the well-known scaling problems of tunnels > (including crossing administrative domains) makes it unlikely that they > will become very dense without suffering maintainability problems. > > Since there are relatively few 6to4 relay routers out there, performance > is often poor for 6to4 to native traffic. But the same is often true for > tunnel brokers, and sometimes for manual tunnels. And at least 6to4 has > good performance to other 6to4 sites. semi-automatic tunnels techniques like tunnel brokers can be deployed so that it does have less sub-optimal forward/reverse paths. It depends on where/how you deploy them. If they are near to you, network topologically speaking, then the sub-optimal paths might be not that a problem. Marc. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Thu Sep 19 17:58:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24697 for ; Thu, 19 Sep 2002 17:58:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s9LC-0002Hq-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 15:00:06 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #1) id 17s9L8-0002HS-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 15:00:02 -0700 Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g8JLxpib004951; Thu, 19 Sep 2002 17:59:51 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 19 Sep 2002 17:59:55 -0400 Message-ID: <3D8A483D.E341D5DD@nc.rr.com> Date: Thu, 19 Sep 2002 17:57:17 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: v6ops@ops.ietf.org, micklesc@aol.net Subject: Re: ISP scenarios comments (multicast) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.0 required=5.0 tests=RCVD_IN_MULTIHOP_DSBL,X_RCVD_IN_UNCONFIRMED_DSBL, FUDGE_MULTIHOP_RELAY version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Pekka Savola wrote: > > On Thu, 19 Sep 2002, bkhabs wrote: > > >Ok; this is still a bit problematic with the one PIM domain requirement.. > > >:-/ > > > > I don't think it is problematic when you consider the overhead that > > would have to occur in order to support PIM domain != site-local domain. > > > > The major problem is that PIM messages are mostly sent hop-by-hop with > > IP addresses in the payload. So, the Bootstrap message is transmitted > > hop-by-hop using the All-PIM-Routers link-local multicast address. But > > the BSR address is in the payload. That means that a site-local border > > router would have to recognize the Bootstrap message, parse into the > > PIM payload and check to see if the BSR-Address was a site-local. > > > > In this case, I prefer simplicity. Let pim domain == site-domain. > > I agree with the simplicity -- but the problem I was referring to was due > to the fact that for all practical purposes, currently there can only be > one PIM domain. That limits the applicability of multicast quite a bit. > Well, actually you can have more if the PIM domains are completely contained within a site-local domain. Using site-locals for multicast is limiting the applicability anyway. > For one perspective, look at one PIM-domain at: > > http://sem2.renater.fr/m6bone/ > > Multicast works -- kinda. Yes, I have looked at their network before. Interesting. I am assuming that they are not using site-locals. > > > >This might be an interesting point to develop more. It's quite possible > > >if we can hard-code assumptions about address assignment for the RP there. > > > > >Possibly through an additional bit flag in the address. This would have to > > >go to the PIM implementation then, though. > > > > You can't encode the RP in the field. > > Which field? Destination address could include the address of the RP, > with some rather strict assumptions. I was talking about the prefix field in the multicast address. There are not enough bits to represent an RP unless you did some interesting address assignments for RPs and can encode the entire address in 64 bits. > > > But, a new RP discovery mechanism > > could utilize the prefix information to know where to look for the RP. > > That too. Brian From owner-v6ops@ops.ietf.org Thu Sep 19 18:22:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25033 for ; Thu, 19 Sep 2002 18:22:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17s9hC-0003tk-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 15:22:50 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17s9h7-0003tG-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 15:22:46 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8JMM6o18571; Fri, 20 Sep 2002 01:22:06 +0300 Date: Fri, 20 Sep 2002 01:22:06 +0300 (EEST) From: Pekka Savola To: Brian Haberman cc: v6ops@ops.ietf.org, Subject: Re: ISP scenarios comments (multicast) In-Reply-To: <3D8A483D.E341D5DD@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Sep 2002, Brian Haberman wrote: > > For one perspective, look at one PIM-domain at: > > > > http://sem2.renater.fr/m6bone/ > > > > Multicast works -- kinda. > > Yes, I have looked at their network before. Interesting. I am > assuming that they are not using site-locals. Yes, they're not using site-locals, but some parties would like to use site-locals in addition to globals -- and that's impossible at the moment with current implementations. We use unicast prefix-based addresses there btw. > > Which field? Destination address could include the address of the RP, > > with some rather strict assumptions. > > I was talking about the prefix field in the multicast address. There > are not enough bits to represent an RP unless you did some interesting > address assignments for RPs and can encode the entire address in 64 > bits. Both are doable. One idea I've been toying with is specifying some default suffix values (for example), and including a 16-bit(?) hash of the RP's full address to be able for the recipients to verify the guess. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Thu Sep 19 18:51:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25641 for ; Thu, 19 Sep 2002 18:51:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sAAI-00061k-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 15:52:54 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17sAAE-00061Y-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 15:52:50 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 4FD4E7BA; Fri, 20 Sep 2002 06:46:47 +0900 (JST) To: v6ops@ops.ietf.org Subject: breakout summary 1 X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Fri, 20 Sep 2002 06:46:47 +0900 Message-Id: <20020919214647.4FD4E7BA@starfruit.itojun.org> X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk [not an official minutes] homework rob: dnssec and dnsalg analysis breakout actions ISP: added additional work areas (and volunteers) wireless broadband ethernet infrastructure services (overlap area data centers outline clarifications add multicast add multi-homing/managed access security traffic engineering dsl detail L2 discussion not necessary other issues send to list agreement that the draft represents the majority of ISP networks IIJ presentation on IPv6 ISP in Japan provides input for the analysis draft wireless: keep it, or move it? still open question 3G: (missed a slide) IMS UE connecting to a IPv4 SIP node not as general as normal Ipv6 only node scenario - SIP-ALG vs DNS-ALG two cases exist SIP ALG and media flow translation in the same box SIP ALG and media flow translation in the separate box next steps mroe text to clear up the analysis protocol between SIP ALG - media flow translation GRPS IPv6 only case a long discussion of the problems of NAT-PT DNS ALG - breaks DNSSEC scalability issues - how to use multiple NATs NAT64 vs NAT-PT having DNS ALG in DNS server in the network having A record support in the end-node itself DNS-ALG in end-node trust models trusting operator DNS server not trusting operator infrasturcutre hybrid model huitema: trust model change is bad - it's not the main topic of 3G, common problem mar: NAT-PT issue applies to other uses? - unsure. mar: scalability? - no real diffs. rob: DNSSEC issue needs to be digged further itojun: dnsext or dnsop or v6ops? rob: not sure, anyways rob will volunteer (before atlanta) alain: need to go quick, IPv6 only device will start to appear unmanaged: unmanaged team report get organized list of issues list of other works the name resolution issue multiple link issue list of issues different topologies (routers, multiple routers) multihousing unit, shared subnet, multiple subnets shared wireless (single/multiple isp, security) fixed ethernet (impacts, naming, discovery) prefix delegation use of tunnel broker for case A - dualstack host, v4 gateway, v4 isp monitoring requirements how do you debug your network - some discussion SIIT issue: only layer 3, support for port mapping, v4 to v6 support? registration of new appliances, notification, device capability, security (application vs network) mar: what is related to IPv6 deployment? - that was the discussion security: is the inside really safer? what support do we need for legacy ipv4 ipv4 only, local connectivity to local ipv6, remote ipv6 (legacy apps vs new apps) solutions for name resolution -> LLMNR, DDNS, etc mobility, roaming -> guest in the house, call back home work for another team ad hoc (car) personal area network mobile network mar: 4 teams won't cover every type of networks. it's not possible to cover all possible cases name resolution from A to B B v4 only B dual B v6 only --- --- --- A v4 only v4(B) v4(B) some translation A dual v4(B) v4/v6(B) v6(B) A v6 only some translation v6(B) v6(B) problems with NAT-PT we don't want to use ISP NAT-PT box A dual, B v4 only A dual, B v6 only recommendations for naming IPv6 host initially be dual stack ipv6 host will also look for A record solves the "literal URL" issue if not dual stack, use "local SIIT" (BIA) need to reserve of configure a SIIT prefix or just forego interoperability with ipv4 leave the AAAA requests alone sincce the host will look for A if needed bound: why are you digging this far huitema: we're already doing analysis document, not scoping document thomas: how can you talk to IPv4? huitema: i'm talking about naming. header translation in network somewhere. result of dual-stack or SIIT v4 only -> v6 only, no solution more naming recommendation ipv4 only host need some translation need a DNS ALG but translating A requeest is harmful to dual stack hosts suggestions use two different DNS services, based on protocol type, port number or names use a special address range for translated addresses class E? itojun: which node needs changing? huitema: dualstack, or ipv6only more naming stuff configuration both dhcp option and reserved address work dynamic DNS - stateless, can lose database acquiring autoconfigured addresses gateway receive request for local name gateway issues LLMNR request, cache the result returns AAAA reply advantage: stateless rob: conflicts with dnsext recommendation on LLMNR (TTL and such) hain: is it the name leak problem? - yes multiple links some medias are hard to bridge bluetooth, ieee1394, possibly power line request to support two topologies star every link goes to the router mesh routers connected to the home network connectivity issues two options for mesh topology multilink subnet (single /64) proxy arp need a detailed specification configured subnet prefixes require multiple /64 prefixes require a prefix allocation specification star topology simple solutions. e.g. allocation of subnet # by the gateway + use of classic RS/RA huitema: no solution for mesh topology for now. - hole. naming issue in star topology configuration both dhcp and reserved address work LLMNR for resolving AAAA gateway must repeat the query on multiple links naming issue in mesh topology configuring the dns server the reserved addr approach just works dhcp requires a set of dhcp proxies options for using LLMNR LLMNR cache + relays at routers or, "right scope" multicast subnet scope if multilink subnet site local scope if configured routers multicast issue appear in LLMNR, but also duplicate address detection thaler: dynamic dns? - (lost answer) mar: how do you discover addr? rob: dynamic update needs to be explored ?: scope really is a domain? is it really a DNS domain/scope? templin: meshed network case has a lot of overwrap with adhoc network space From owner-v6ops@ops.ietf.org Thu Sep 19 18:52:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25664 for ; Thu, 19 Sep 2002 18:52:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sABf-00066T-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 15:54:19 -0700 Received: from web13004.mail.yahoo.com ([216.136.174.14]) by psg.com with smtp (Exim 3.36 #1) id 17sABc-00066H-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 15:54:16 -0700 Message-ID: <20020919225409.73997.qmail@web13004.mail.yahoo.com> Received: from [192.73.222.228] by web13004.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 15:54:09 PDT Date: Thu, 19 Sep 2002 15:54:09 -0700 (PDT) From: Fred Templin Subject: Re: unmanaged solutions comments To: Marc Blanchet , Bill Owens , v6ops@ops.ietf.org Cc: osprey67@yahoo.com In-Reply-To: <797030000.1032470199@classic.viagenie.qc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I should probably comment on this, since I've spent some time thinking about the subject recently: --- Marc Blanchet wrote: > automatic tunnels techniques usually mean (by design) that the path is not > "controlled". In the case of ISATAP, "control" is provided by the site security recommendations in the base document. If a particular deployment perceives a need, stronger degrees of control might be possible by fusing end-to-end (or, end-to-edge) mechanisms with the ISATAP base specification. This would result in a "semi-automatic-automatic" tunnel; cumbersome wording, but still a useful mechanism. > semi-automatic tunnels techniques like tunnel brokers can be deployed so > that it does have less sub-optimal forward/reverse paths. It depends on > where/how you deploy them. If they are near to you, network topologically > speaking, then the sub-optimal paths might be not that a problem. This is never a problem with automatic tunnels (even when they are "semi-automatic-automatic"); route optimization is enabled by default. Fred osprey67@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-v6ops@ops.ietf.org Thu Sep 19 19:00:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25768 for ; Thu, 19 Sep 2002 19:00:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sAJR-0006fJ-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 16:02:21 -0700 Received: from [2001:218:1:10c2::2] (helo=guri.nttv6.jp) by psg.com with esmtp (Exim 3.36 #1) id 17sAJO-0006eH-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 16:02:19 -0700 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1:10c1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id 39E4BB16AA; Fri, 20 Sep 2002 08:01:48 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id 79EFF125CD6; Fri, 20 Sep 2002 08:01:45 +0900 (JST) Date: Fri, 20 Sep 2002 08:01:45 +0900 (JST) Message-Id: <20020920.080145.85367783.miyakawa@nttv6.jp> To: itojun@iijlab.net Cc: v6ops@ops.ietf.org Subject: Re: memo, 1st day PM From: Shin Miyakawa In-Reply-To: <20020919001425.412397B9@starfruit.itojun.org> References: <20020919001425.412397B9@starfruit.itojun.org> Organizaton: NTT Communications X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > [not a official minutes] > > shin miyakawa (operator's input) > commercial IPv4/v6 dual stack ADSL operation > tokyo only, $6/mo, 8-10Mbps DSL I said that $60/mo ;-) Of course, $6/mo is too cheap ;-p And, now we're expanding service area from Tokyo to the other areas Shin From owner-v6ops@ops.ietf.org Thu Sep 19 19:12:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25938 for ; Thu, 19 Sep 2002 19:12:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sAV7-0007ZB-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 16:14:25 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17sAV2-0007Yq-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 16:14:20 -0700 Received: from pixsv68.isi.com (pixsv68.isi.com [192.73.222.219]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8JNPrE33896; Thu, 19 Sep 2002 19:25:53 -0400 (EDT) Date: Thu, 19 Sep 2002 19:09:42 -0400 From: Marc Blanchet To: Fred Templin , Bill Owens , v6ops@ops.ietf.org Subject: Re: unmanaged solutions comments Message-ID: <871110000.1032476982@classic.viagenie.qc.ca> In-Reply-To: <20020919225409.73997.qmail@web13004.mail.yahoo.com> References: <20020919225409.73997.qmail@web13004.mail.yahoo.com> X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA25938 -- jeudi, septembre 19, 2002 15:54:09 -0700 Fred Templin wrote/a écrit: > I should probably comment on this, since I've spent some time thinking > about the subject recently: > > --- Marc Blanchet wrote: >> automatic tunnels techniques usually mean (by design) that the path is >> not "controlled". > > In the case of ISATAP, "control" is provided by the site security > recommendations in the base document. If a particular deployment > perceives a need, stronger degrees of control might be possible by fusing > end-to-end (or, end-to-edge) mechanisms with the ISATAP base > specification. This would result in a "semi-automatic-automatic" tunnel; > cumbersome wording, but still a useful mechanism. agreed. my statement was generic, knowing that there are many variations of this. > >> semi-automatic tunnels techniques like tunnel brokers can be deployed so >> that it does have less sub-optimal forward/reverse paths. It depends on >> where/how you deploy them. If they are near to you, network >> topologically speaking, then the sub-optimal paths might be not that a >> problem. > > This is never a problem with automatic tunnels (even when they are > "semi-automatic-automatic"); route optimization is enabled by default. some automatic tunnels are not so much route optimized: just one example: 6to4 user, sending a packet to 2001:.. through some 6to4 relay. the reverse path could be very different... Marc. From owner-v6ops@ops.ietf.org Thu Sep 19 19:31:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26217 for ; Thu, 19 Sep 2002 19:31:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sAmP-0008nN-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 16:32:17 -0700 Received: from web13004.mail.yahoo.com ([216.136.174.14]) by psg.com with smtp (Exim 3.36 #1) id 17sAmM-0008nC-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 16:32:14 -0700 Message-ID: <20020919233211.87992.qmail@web13004.mail.yahoo.com> Received: from [192.73.222.228] by web13004.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 16:32:11 PDT Date: Thu, 19 Sep 2002 16:32:11 -0700 (PDT) From: Fred Templin Subject: Re: unmanaged solutions comments To: Marc Blanchet , Bill Owens , v6ops@ops.ietf.org Cc: osprey67@yahoo.com In-Reply-To: <871110000.1032476982@classic.viagenie.qc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Marc Blanchet wrote: > some automatic tunnels are not so much route optimized: > just one example: 6to4 user, sending a packet to 2001:.. through some 6to4 > relay. the reverse path could be very different... I would view this as asymmetric paths in the forward and reverse directions. But, you are right that true shortest-path routing may not occur in one or both of the directions. Fred osprey67@yahoo.com __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-v6ops@ops.ietf.org Thu Sep 19 20:03:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26814 for ; Thu, 19 Sep 2002 20:03:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sBI4-000B6g-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 17:05:00 -0700 Received: from pixsv201.isi.com ([192.73.222.252] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17sBHz-000B6R-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 17:04:55 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 96D547B9; Fri, 20 Sep 2002 09:04:51 +0900 (JST) To: v6ops@ops.ietf.org X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: breakout summary 2, and other topics From: Jun-ichiro itojun Hagino Date: Fri, 20 Sep 2002 09:04:51 +0900 Message-Id: <20020920000451.96D547B9@starfruit.itojun.org> X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk [not an official minutes] enterprise scenarios brainstorming session plan of action 1. establish drivers that would make an enterprise interested in ipv6 (migration benefits), brainstorm ideas get to 80% coverage approach 2. evaluate new/existing scnearios enterprise drivers/reasons for ipv6 better address space economics simplified mobility model simplified operation model security ipv6 development new ipv6 and the 'killer app' enterprise buliding blocks - arbitrary order internet data center - server farm intranet data center - server farm vpn infra wan corporate backbone wan extranet lan (single site, single routing domain) network edge devices or perimeter (firewall, mail proxy etc) connectivity - multi-isp - multi-address applications inventory audit/understanding the network mapping call for more scenarios outside attempted to list some more scenarios internet data center - providing access to ipv6 apps/ipv4 apps across isps (v4 and v6) outgoing/incoming access cross of perimeter outsourced all/most of corporate backbone and desire to deploy native ipv6 simpler case - entire enterprise move to v6 call for more scenarios brainstorming session outcome try to order the scenarios by complexity difficulty to define complexity decided to not order the building blocks generate a matrix of buliding blocks versus scenarios how they apply to different scenarios single building/single location campus/single location campus/multiple locations connectivity models/use the buildling blocks to create scenarios hostv6/nodev6/devicev6 etc on v4 lan on v6 lan lanv6 (island) to lanv6 (island) over v6 over v4/v6 lanv6 (island) to lanv4 (island) over v6 over v4/v6 simplest scenarios single location (in an ipv4-constrained region) don't have a perm/globally routable v4 address don't have infrastructure for a server for e.g. need "permanent" addrss, aneed peer-to-peer solution to go to ipv6 --- dhcpv6 stuff(droms) oeprational issues with dhcpv6 purpose and outcomes list potential operational issues around dhcpv6 are there other, similar issues? does each issue require action? what needs to be done and who should take ownership? try not to dig the hole too deep dhcp == stateful autoconfiguration?? dhcp is loosely referred to (RFC2461/2462) as "stateful autoconfiguration" mechanism does this loose reference require clarification? imporatnt to clarify? - itojun yes. "0" or ">= 2" could be problem + need to fix it. + who should fix it? - ipv6wg. M, O and A bits A bit set in prefix advert causes SLAAC, independent of M or O bits in RA M bit set in RA causes DHCP for address assignment (and implies O bit), independent of SLAAC; M bit not set gives no guidance on use of DHCP O bit set in RA causes DHCP for other configuration (but not address assignment); O bit not set gives no guidance on use of DHCP net admin restricts hosts to DHCP addresses by not setting A bits in any prefixes dual use possible (A + M) thomas: "no guidance" - wording in spec is different droms: "not set" behavior is not clearly specified thaler: "M bit indicates whether or not" - so, "M=0" means "no DHCP" rob: take it to the list. + ask on the list if "whether or not" is clear enough + send to the list requirement for stateful autoconf an IPv6 stack must include stateful autoconf? required for use when M or O bit set huitema: manual config is "stateful" thomas: don't use of "stateful" or "stateless" wording Q: to be fully compliant, need to implement DHCP? rob: we don't know enough about service discovery yet huitema: stateless is a must, DHCP is optional blanchet: network admin policy decision - orthogonal, should not be a MUST hain: should implement DHCP, if you claim to support M/O bit bound: are there requirement for dhcpv4 ever? - no rob: (1) we end up with the same situation as ipv4 (2) (logger missed) (3) not entirely convinced about service discovery part + O bit, "information other than addresses" is not clear huitema: "O" bit means "you may want to get config info from stateful config mech". huitema: how about MAY on M bit and MUST on O bit? itojun: how about MAY on M bit and SHOULD on O bit looks okay rob: multiple protocol for same service does not work well + some need for further discussion + which mailing list? - ipv6wg authentication for DHCPv6 evolved from RFC3118 (DHCPv4 auth) incorporates input from steve bellovin keys now include: DHCP realm for roaming lifetime and key selection for key rollover if it is not good enough for you, let us know. thaler: it is needed for addr stuff, it is not needed for other stuff how do we go describing in dhcp spec, clients and server does O bit style of config? simple-dhcp? "this part of protocol spec is mandatory?" huitema: dhcp-lite profile? + dhcp-lite (mandatory part) - dhcp group issue inconsistencies between dhcp and other sources preferred and valid lifetime on advertised prefixes do not apply to addresses assigned through dhcp (*) other inconsistencies are not fatal and are resolved by "latest information wins" (vaguely related question) are these three questions equivalent? - not advertising a prefix - advertising a prefix as not on link - letting the lifetime of a prefix expire itojun: misconfiguration thaler: don't think so bound: latest wins (RA overrides DHCP info) thomas: authenticated DHCP info, vs unauthenticated RA info bound: stateful/stateless configured address doesn't mix + (*) put toghether clarification for the result - lots of hands for "yes" + consensus - needs some work at ipv6wg dns configuration net admin can select DNS resolver autoconfig with O bit not set and DNS resolver config through DHCP with O bit set requires stack MUST have DHCP for use with O bit set rob: what happens if there are tons of other service discovery ways? itojun: MUST is too strong, SHOULD may be okay itojun: what if dns server address is not available from dhcp? hain: ?? huitema: we do have several config protocols. dhcpv4, dhcpv6, dns-slv, slp. huitema: O bit, no way that we can say in the ipv6 spec what to do. should be documented in application specification (DNS/whatever). what to do against O bit should be specified per-protocol manner hesham: O bit "try dhcp, then blah" thomas: application protocol specifies O bit behavior does not seem to work huitema: dhcpv4 vs dhcpv6 - how to resolve conflicts? who? mar: only purpose of O bit is to tell you "don't use DHCP" thomas: original rationale is to avoid dhcp delay optimization rob: we don't see a need for this bit rob: whole bunch other of synchronization issues in multiple protocols + need to revisit O bit description + go to ipv6wg SLLAC and DHCP from same prefix does current DAD specification protect against conflict among SLAAC addresses and DHCP assignment from prefix adverrtised with A bit set? should there be a recommendation against DHCP assignment from an SLAAC prefix? thaler: "yes" to first line (2nd line - no) huitema: RA tells you how long you can use an address, ... + go to ipv6wg reserved interface identifiers should there be a recomendation against assigning dhcp that use any resreved interface identifiers? thaler: reserved anycast addr ?: u bit, g bit + if you can think of other items, let me know (itojun) snmp - 0.0.0.0 (IPX) wrap-up charter changes - need to talk to randy, that's all From owner-v6ops@ops.ietf.org Thu Sep 19 23:33:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01356 for ; Thu, 19 Sep 2002 23:33:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sEXY-000Pvs-00 for v6ops-data@psg.com; Thu, 19 Sep 2002 20:33:12 -0700 Received: from secundus.nysernet.org ([192.77.173.5]) by psg.com with esmtp (Exim 3.36 #1) id 17sEXV-000Pvh-00 for v6ops@ops.ietf.org; Thu, 19 Sep 2002 20:33:09 -0700 Received: by secundus.nysernet.org (Postfix, from userid 1001) id D4783508F2; Thu, 19 Sep 2002 23:27:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by secundus.nysernet.org (Postfix) with ESMTP id B88F14E5E2 for ; Thu, 19 Sep 2002 23:27:30 -0400 (EDT) Date: Thu, 19 Sep 2002 23:27:30 -0400 (EDT) From: owens@nysernet.org To: v6ops@ops.ietf.org Subject: Re: unmanaged solutions comments In-Reply-To: <797030000.1032470199@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 19 Sep 2002, Marc Blanchet wrote: > automatic tunnels techniques usually mean (by design) that the path is not > "controlled". Perhaps I'm misunderstanding you, but I would expect that any tunnel between the same two endpoints would follow the same underlying path, regardless of how it was set up. Everything is driven by the destination IPv4 address, after all. Unless you have some sort of traffic engineering going on, but that's always an exception case. And although automatic tunnels don't usually allow you to control the path, they should select the best possible path based on whatever IPv4 metrics you use, so you probably don't care to be involved ;) > semi-automatic tunnels techniques like tunnel brokers can be deployed so > that it does have less sub-optimal forward/reverse paths. It depends on > where/how you deploy them. If they are near to you, network topologically > speaking, then the sub-optimal paths might be not that a problem. I think we're agreeing on the general point that if we use a tunnel protocol that depends on fixed relays/brokers/servers, having more of them is better because the odds are that one will be closer to you, and (if the path is asymmetric, as it is for 6to4 relays) one will also be closer to the other end. Or are you saying that something else can be done to improve the situation, without increasing the number of relays? I am making some underlying assumptions for relays, that they will in some reasonable fashion connect to the native infrastructure, and further that the native infrastructure will perform well (though perhaps not as well as the equivalent IPv4 path). Someone who has a marginal connection to the 'core' of the native IPv6 network (wherever that is) probably won't help matters by running a relay. In a semi-utopia, we'd have everyone who is able to connect to the native IPv6 network doing so, have all our manual tunnels following the best IPv4 paths to the native infrastructure, and have lots of relays/brokers/servers well connected to both IPv4 and IPv6. I'm working on all those angles, at least in my little corner of the network ;) Bill. From owner-v6ops@ops.ietf.org Fri Sep 20 03:20:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15225 for ; Fri, 20 Sep 2002 03:20:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sI5O-000H5O-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 00:20:22 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17sI5I-000H5D-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 00:20:17 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17sI5H-0005cz-00; Fri, 20 Sep 2002 08:20:15 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17sI5H-0005cu-00; Fri, 20 Sep 2002 08:20:15 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA23666; Fri, 20 Sep 2002 08:20:13 +0100 Message-ID: <3D8ACC38.9E3668A8@hursley.ibm.com> Date: Fri, 20 Sep 2002 09:20:24 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Behcet Sarikaya CC: Pekka Savola , v6ops@ops.ietf.org Subject: Re: raw thoughts on v6 firewalls References: <3D89DF51.3090901@alcatel.com> <3D89EB63.810A2CA5@hursley.ibm.com> <3D89F165.70402@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Behcet Sarikaya wrote: > > Now I understand that it is somewhat orthogonal. Using site local addresses the intranet can avoid seeing company emails on > Google's search engine, but how to avoid having ftp sites to be not accessible from the Internet? Maybe this is also possible > using site local addresses. > > Would then be a good idea to ask MIDCOM WG to come up with new RFCs (-bis) replacing the present v4 only ones to standardize > v6 firewalls? There are no standards for firewalls. MIDCOM is working on firewall (and IPv4-NAT) traversal techniques only. > Why this such an important issue did not come up during the long standardization period in which v6 was developed? Because IPv6 is aimed at restoring transparency and enabling end to end security. Certainly, the MIDCOM mechanisms must be equally valid for v4 and v6. Brian > > Regards, > > Brian E Carpenter wrote: > > > Behcet Sarikaya wrote: > > > > > >> Hello Pekka, > >> Site-local addresses would provide the same functionality and > >> therefore there is no need to introduce firewalls into v6. > >> Is there anything wrong with the above argument? > >> > >> > > Lots. It's very similar to the argument that NAT is a security > > feature, which is absolutely untrue. > > > > Firewalls block incoming connections with global destination addresses. > > The existence of site-local addresses is orthogonal to this. You still > > need to allow some incoming connections to global addresses, and > > block others. > > > > (Firewalls do more than that, but this is sufficient to answer > > your question.) > > > > Brian > > > > > > > > -- > Behcet -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-v6ops@ops.ietf.org Fri Sep 20 04:25:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16160 for ; Fri, 20 Sep 2002 04:25:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sJ6Z-000LFp-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 01:25:39 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17sJ6T-000LFJ-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 01:25:33 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23996 for ; Fri, 20 Sep 2002 02:25:32 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8K8POA24698; Fri, 20 Sep 2002 10:25:24 +0200 (MEST) Date: Fri, 20 Sep 2002 10:22:59 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on draft-ietf-ngtrans-mech-v2-00.txt To: Alain Durand Cc: erik.nordmark@Sun.COM, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3D868E3E.60107@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks for the comments. > However, IPv6 may be used in some environments where interoperability > with IPv4 is not required. IPv6 nodes that are designed to be used > in such environments need not use or even implement these mechanisms > > > => This last paragraph could be read as a hint that IPv6 nodes do not > have to > implement dual stack if and only they it will never have to > interoperate > in any way with any IPv4 node. > I think that in its introduction, this document should not close > the door > to Ipv6-only devices interoperating with IPv4 devices via some > sort of relays. The paragraph doesn't talk about that case. It says that if interoperability with IPv4 isn't needed the mechanisms in the spec aren't needed. Having said that, I have no problem dropping the paragraph in question. > 1.1 terminology > > IPv6-native address: > > The remainder of the IPv6 address space. An IPv6 > address that bears a prefix other than 0:0:0:0:0:0. > > > > => It will be good to have a terminology to distinguish IPv6 addresses > that embed > IPv4 addresses for automatic tunneling purposes (6to4, Isatap) from > other 'regular' types of Ipv6 addresses. I note that this specification doesn't need such a distinction. Exactly what would you like to distinguish using some new terminology? > => the word 'stack' is confusing here. Does it covers the kernel only or > does it cover the libraries and applications as well? > How to differenciate a node with an IPv6 kernel but no IPv6 > application? Example: a v6 dual stack node with > a popd listening only on Ipv4 sockets? The document in fact doesn't use the "IPv4 operation" etc terms, so I'll just remove those definitions > => And even from a kernel perspective, the work 'stack enabled' is > confusing. > Does it mean that the kernel has code to process IPv6 packets? > Does it mean that an IPv6 address has been configured on an interface? > Is a node with only link local address configured operating in > IPv6/IPv4 mode? > What about loopback only? > What about a node listening to RA on an IPv4-only network where a > rogue IPv6 router is sending a bogus prefix? Loosly the intent is to capture the fact that the code to handle IPv4 and IPv6 is present, but only one of the two has been configured to be operational. The IP layer can't operate without IP addresses, so at a minimum an address needs to be assigned. Do we need this to be more "exact" than this? Which things break or are confusion if we omit to specify whether link-local only is "enabled" or whether loopback only is "enabled"? > 2. Dual IP Layer Operation > > The most straightforward way for IPv6 nodes to remain compatible with > IPv4-only nodes is by providing a complete IPv4 implementation. IPv6 > nodes that provide a complete IPv4 and IPv6 implementations are > called "IPv6/IPv4 nodes." > > => Same comment as above. The intent is (or was) that this capture not only the IP layer but all applications as well. Any suggestions how this can be made more clear? > 2.2. DNS > > > => This section should say that the actual DNS query can be done using > either IPv4 or Ipv6 as transport. ok > => On an IPv6-only node, would it be correct for a resolver library > recieving only A answers for a name to address question to > pass the application an IPv6 address using the IPv4-mapped format? > [This is an asumption made in NAT64] That is an API question, which I think is out of scope for this document. [But I personally agree it would be correct.] > > 2.3. Advertising Addresses in the DNS > > The recommendation is that AAAA records for a node should not be > added to the DNS until all of these are true: > > [...] > > => I think a extra rule is needed: The applications have to be IPv6 ready. > (see my comment on IPv4/IPv6 operation). > However, what to do when some services are IPv6 ready and some are not? > Example, there is a telnetd listening on v4 and v6, but popd only > listen on v4? In many cases that rule wouldn't be helpful; for instance a student might right up a new IPv4 application and run it on my server - how am I as a system admin supposed to know this? I would make more sense add text pointing out the issue when (server) applications on dual nodes do not support IPv6. What type of warnings would you like to see? > 4.1. Ingress Filtering > > [..] > > => This only applies to configured tunnels, and CAN NOT be implemented > for automatic tunnels like 6to4 using relay routers. > I understand this is a sub-section of '4 Configured Tunneling' > but this somehow contradic the text in the security considerations. What is the contradiction? This document is about configured tunnels and not about 6to4. > 6. Security Considerations > > Tunneling is not known to introduce any security holes except for the > possibility to circumvent ingress filtering [13]. This is prevented > by requiring that decapsulating routers only forward packets if they > have been configured to accept encapsulated packets from the IPv4 > source address in the receive packet. > > => This is not true for automatic tunneling (see above comment) > I think that any kind of automatic tunneling mechanism > using open relays such a 6to4 creates serious risks in the Internet. That is a good comment for the 6to4 document(s), but I don't see how it applies to this document on configured tunneling. Erik From owner-v6ops@ops.ietf.org Fri Sep 20 05:12:43 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16817 for ; Fri, 20 Sep 2002 05:12:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sJrO-000ODN-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 02:14:02 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17sJrK-000ODA-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 02:13:58 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25193 for ; Fri, 20 Sep 2002 02:13:57 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8K9DqA29453; Fri, 20 Sep 2002 11:13:52 +0200 (MEST) Date: Fri, 20 Sep 2002 11:11:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt To: ngtrans@sunroof.eng.sun.com Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20020917152646.1DE8F7B9@starfruit.itojun.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=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > (since this is transition tool discussion replies to ngtrans please) I thought the topic of the discussion was draft-itojun-v6ops which the author seems to think belongs in v6ops :-) > if the above assumption is true, what do you intend to do about the > dual use of IPv4 mapped address? telnet client on dual stack machine > would make a send(2) request to ::ffff:a.b.c.d, which will be captured > by an AF_INET6 socket, and goes out of the node as IPv4 packet. > there's no documented way in which ::ffff:a.b.c.d would go out as IPv6 > packet. either RFC2553 API does not work, or SIIT dose not work. An implementation needs to be configured to either be IPv6-only or dual stack. In the dual stack case the mapped addresses at the API correspond to IPv4 packets on the wire. In the IPv6-only case the mapped addresses at the API correspond to IPv6 packets on the wire next to the node, and on the other side of the translator they correspond to IPv4 packets. What part of section 3.7 in RFC 2553 conflicts with this? That section doesn't say that IPv4 packets are sent, it says that the address is used to for IPv6 applications to interoperate with IPv4 applications. What part of the SIIT spec conflicts with RFC 2553? Please be specific. Erik From owner-v6ops@ops.ietf.org Fri Sep 20 05:55:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17400 for ; Fri, 20 Sep 2002 05:55:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sKW2-0000pc-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 02:56:02 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17sKVy-0000pR-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 02:55:58 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04085; Fri, 20 Sep 2002 02:55:56 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8K9ttA05098; Fri, 20 Sep 2002 11:55:55 +0200 (MEST) Date: Fri, 20 Sep 2002 11:53:28 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: comment on unmanaged analysis presentation/doc To: "Bound, Jim" Cc: Pekka Savola , Marc Blanchet , huitema@microsoft.com, satapati@cisco.com, v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B02BE92A4@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Marc did explicitly ask that TSP be a v6ops mechanism for discussion. > > To address that question with my input. > > I believe TSP is an important tool for users. I believe we can begin work > on this tool within v6ops and support it being worked on within this list. > > Others should respond here with your opinion and this is important per > Margarets talk today. One way or the other. While I won't comment on TSP vs. some other way of explicitly configuring tunnels, I'll make a more general comment. I'm very concerned about trying to fully automate tunnel setup (whether over IPv4 NATs or just plain old IPv4) due to the trust and security issues. Thus I think it makes sense to have an authenticated and properly authorizable tunnel establishment method that can work whether or not there is an IPv4 NAT in the path. The operational model for this is that the user establishes a trust relationship with the tunnel provider and uses this to establish and maintain the tunnel automatically. I think this can be made really simple but yet secure. Erik From owner-v6ops@ops.ietf.org Fri Sep 20 06:17:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17611 for ; Fri, 20 Sep 2002 06:17:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sKro-0002Am-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 03:18:32 -0700 Received: from parsmtp1.rd.francetelecom.com ([194.167.105.13]) by psg.com with esmtp (Exim 3.36 #1) id 17sKrl-0002AX-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 03:18:29 -0700 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 20 Sep 2002 12:18:27 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: 3GPP soluations comments Date: Fri, 20 Sep 2002 12:18:26 +0200 Message-ID: Thread-Topic: 3GPP soluations comments Thread-Index: AcJf856oss5VkcFxTkKeasoTj0k+tQAmoSow From: "BELOEIL Luc FTRD/DMI/CAE" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 20 Sep 2002 10:18:27.0609 (UTC) FILETIME=[0F7AC890:01C2608F] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA17611 Hi all, > -----Message d'origine----- > De : Pekka Savola [mailto:pekkas@netcore.fi] > > 4.2 UE connecting to a node in an IPv4 network through IMS > > This scenario occurs when an IMS UE (IPv6) connects to a node in > the IPv4 Internet through the IMS, or vice versa. This > happens when > the other node is a part of a different system than 3GPP, e.g. a > fixed PC, with only IPv4 capabilities. > > Apparently there will be a number of legacy IPv4 nodes in the > Internet that will communicate with the IMS UEs. As the IMS is > exclusively IPv6, translators have to be used in the > communication > between the IPv6 IMS and legacy IPv4 hosts. This section aims to > give an overview on how that interworking can be handled. > > ==> IMO, I'm not 100% sure this number of legacy IPv4 nodes *IMS* > communicates with is necessarily all that large. If I > understood correctly, > that means basically v4-only SIP phones. Are there really > all that many of > those. SIP phones that could not be relatively easily > upgraded to IPv6? If > the number of scenarios to support were to be shortened, IMO > this would be > among the first ones to go. > ==> Unfortunately SIP architectures are already under deployement and do not seem to take enough care about IPv6. Moreover a lot of SIP phones that can be used in such architectures are IPv4-only with no upgrade capabilities. I do think that such a scenario MUST be analyzed. Regards, Luc > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-v6ops@ops.ietf.org Fri Sep 20 09:48:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22247 for ; Fri, 20 Sep 2002 09:48:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sNig-000EAO-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 06:21:18 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17sNib-000EA4-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 06:21:13 -0700 Received: from dhcp64-134-140-111.wgs.sjc.wayport.net (dhcp64-134-140-111.wgs.sjc.wayport.net [64.134.140.111]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8KDVrE39686; Fri, 20 Sep 2002 09:31:53 -0400 (EDT) Date: Fri, 20 Sep 2002 08:47:32 -0400 From: Marc Blanchet To: Erik Nordmark , "Bound, Jim" cc: Pekka Savola , huitema@microsoft.com, satapati@cisco.com, v6ops@ops.ietf.org Subject: RE: comment on unmanaged analysis presentation/doc Message-ID: <1185840000.1032526052@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22247 -- vendredi, septembre 20, 2002 11:53:28 +0200 Erik Nordmark wrote/a écrit: >> Marc did explicitly ask that TSP be a v6ops mechanism for discussion. >> >> To address that question with my input. >> >> I believe TSP is an important tool for users. I believe we can begin >> work on this tool within v6ops and support it being worked on within >> this list. >> >> Others should respond here with your opinion and this is important per >> Margarets talk today. One way or the other. > > While I won't comment on TSP vs. some other way of explicitly configuring > tunnels, I'll make a more general comment. > > I'm very concerned about trying to fully automate tunnel setup (whether > over IPv4 NATs or just plain old IPv4) due to the trust and security > issues. Thus I think it makes sense to have an authenticated and properly > authorizable tunnel establishment method that can work whether or not > there is an IPv4 NAT in the path. that is _exactly_ what tsp is doing. Marc. > > The operational model for this is that the user establishes a trust > relationship with the tunnel provider and uses this to establish and > maintain the tunnel automatically. > > I think this can be made really simple but yet secure. > > Erik > From owner-v6ops@ops.ietf.org Fri Sep 20 15:38:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05466 for ; Fri, 20 Sep 2002 15:38:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sTc4-000HE2-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 12:38:52 -0700 Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no) by psg.com with esmtp (Exim 3.36 #1) id 17sTby-000HDc-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 12:38:46 -0700 Received: from HALVESTR-W2K1.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C796962204; Fri, 20 Sep 2002 21:38:38 +0200 (CEST) Date: Fri, 20 Sep 2002 14:39:27 +0200 From: Harald Tveit Alvestrand To: Jun-ichiro itojun Hagino , Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: unmanaged scope comments Message-ID: <38654542.1032532767@localhost> In-Reply-To: <20020919154801.4E7667BB@starfruit.itojun.org> References: <20020919154801.4E7667BB@starfruit.itojun.org> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_06_12 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 20. september 2002 00:48 +0900 Jun-ichiro itojun Hagino wrote: >> ==> connectivity includes one very important component IMO: the quality >> of network connections. This is often ignored. It's a high risk for a >> vendor to enable IPv6 by default, for example, if that'd result in lower >> quality connections to e.g. dual-stack web servers (a very real fact in >> 6bone), this should be taken into consideration at least in the short >> term. > > i don't understand what you want to do about it. will you ping/ping6 > destination and pick shorter roundtrip? when multiple A records > are returned for www.foo.com, do you probe them to get the optimal > performance? i believe the "quality" factor does not matter, and > it cannot be measured from endpoint (at least within short time). > I have wanted for a long time someone more competent than me to run an experiment where one, after a name lookup, would send SYN packets to *all* the addresses returned, and only complete the three-way handshake on the first one to reply. after all, it seems impossible to get anyone to take seriously the job of getting the network to tell me which of two addresses are "best", and the servers in these DOS-attack days have to defend against synfloods anyway. just wasting some SYN packets seems to me to be likely to achieve the "low hanging fruit" of *most of the time* picking the best address to use. so far, afaik, nobodoy's tried it. Harald From owner-v6ops@ops.ietf.org Fri Sep 20 18:16:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11560 for ; Fri, 20 Sep 2002 18:16:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sW2a-0003H0-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 15:14:24 -0700 Received: from dial-31-d02.qxo1.equant.net ([57.72.132.31] helo=starfruit.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17sW2V-0003Gh-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 15:14:20 -0700 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id DB3CA7B9; Sat, 21 Sep 2002 07:14:09 +0900 (JST) To: Erik Nordmark Cc: v6ops@ops.ietf.org In-reply-to: Erik.Nordmark's message of Fri, 20 Sep 2002 11:53:28 +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: comment on unmanaged analysis presentation/doc From: Jun-ichiro itojun Hagino Date: Sat, 21 Sep 2002 07:14:09 +0900 Message-Id: <20020920221409.DB3CA7B9@starfruit.itojun.org> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >I'm very concerned about trying to fully automate tunnel setup (whether >over IPv4 NATs or just plain old IPv4) due to the trust and security issues. >Thus I think it makes sense to have an authenticated and properly authorizable >tunnel establishment method that can work whether or not there is an >IPv4 NAT in the path. in that case, what is your comment to 6to4 routers? they accept tunnelled packet from anyone, with no authentication whatsoever. i raised the concern in draft-itojun-ipv6-transition-abuse-*.txt. itojun From owner-v6ops@ops.ietf.org Fri Sep 20 18:56:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13139 for ; Fri, 20 Sep 2002 18:56:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sWj7-0006Av-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 15:58:21 -0700 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 17sWj3-0006Ak-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 15:58:17 -0700 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 20 Sep 2002 15:58:17 -0700 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Sep 2002 15:58:17 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 20 Sep 2002 15:58:16 -0700 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 20 Sep 2002 15:58:16 -0700 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Fri, 20 Sep 2002 15:58:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6757.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: ipv6IfStateChange traps in RFC2465 Date: Fri, 20 Sep 2002 15:57:53 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073842A8@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: ipv6IfStateChange traps in RFC2465 Thread-Index: AcEqX01xFg0+hnYwT7qNk8iiHBNDCBCRi+LgAAAOIqA9FKjGsA== From: "Dave Thaler" To: X-OriginalArrivalTime: 20 Sep 2002 22:58:02.0408 (UTC) FILETIME=[2C2D3A80:01C260F9] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA13139 During the meeting, Itojun mentioned a problem with traps prior to SNMPv3, and I indicated this is not in fact a problem. Here's the relevant exchange which took place on the ipng and snmpv3 lists last year. -Dave -----Original Message----- From: David T. Perkins [mailto:dperkins@dsperkins.com] Sent: Tuesday, August 21, 2001 9:27 AM To: Steve Moulton; Dave Thaler Cc: Daniel Chuang; ipng@sunroof.eng.sun.com; snmpv3@lists.tislabs.com Subject: Re: ipv6IfStateChange traps in RFC2465 HI, There is NO PROBLEM in sending a v1TRAP (or sending v2TRAP or INFORM with SNMPv2c) using IPv6! NO PROBLEM! Comments below... At 10:37 AM 8/21/2001 -0400, Steve Moulton wrote >On Monday, August 20 2001, "Dave Thaler" > wrote: >> > From: Daniel Chuang [mailto:ipv6_dchuang@yahoo.com] >> > >> > [...] what kind of information >> > will be put into the "agent-addr" in the v1 Trap >> > PDU in the ipv6-only node? >> > >> > A couple of options: >> > >> > 1. SNMPv1 traps are not allowed for ipv6-only node. >> > >> > 2. modify RFC1157. >> > >> > 3. any other creative methods !! This question is ALREADY asked and answered. The value is 0.0.0.0, which should be the value ALWAYS. I'll leave it for Steve to find the documents. Hint: what do you put in the field when running over IPX, see RFC 1420. >> It looks to me like the answer is (1). No, the value 0.0.0.0 MUST be used. >> Cc'ing SNMPv3 list, where other experts reside. > >Currently, as best as I can tell, this can't be done. Incorrect. Do more homework. >Please pardon me for being didactic - I'm figuring this out for the >first time myself. > >Talking to: > >If you are using the coexistence framework (rfc2576), the >notification destination is specified in the snmpTargetAddrTable. >The address is specified using the TDomain and TAddress >textual conventions. rfc1906 defines the OIDs for TDomain, >but they can also be defined elsewhere, though as far as >I can tell, no domain has been defined in an RFC for IPv6 addresses. Well, one of the "wonderful properties" of OID values is that they can be defined by anyone, and, thus, there is 1) no way of knowing all assignments, or 2) no way of knowing if there are duplicate assignments. So it is possible for some WG to have defined an OID that identifies the value as an IPv6 transport address, or that one or more vendors have created definitions. >There is a proposal to add new transport domain OIDs for IPv6 in >draft-ops-taddress-mib-00.txt. I'm pretty sure this is also in >draft-ops-taddress-mib-01.txt, but both have expired, and I don't have >the text for it. So, there is currently no way to specify an IPv6 >target address in a standard fashion, though either the IETF or vendors >will have to deal with this as IPv6 support demand increases. If your data is accurate, then there is no "standard" identification, but there is a standard way to specify IPv6 addresses. >Juergen, Mike, am I up to date here? > >Talking about: > >As for the trap contents itself, the agent address >parameter is a NetworkAddress, a choice that has >only one defined type, IpAddress, an implicit octet >string of length 4. > >So it appears that either the NetworkAddress type must >change, or the Trap-PDU (an obsolete pdu) must change, to convey IPv6 >addresses in an SNMPv1 packet. In both cases, interoperability would >be lost. No, the NetworkAddress type does not need to change, and v1Traps do not need to be changed. The agent address is 0.0.0.0. One determines the "source" of the information contained in the v1 TRAP (and v2Trap and Inform used in SNMPv2c) from the transport address of the sender (the "reporter") and the community string value. On receiving a v1Trap (or v2Trap or Inform with SNMPv2c), the trap receiver must use the pair of the transport address (more likely just the Network address) and the community string together to figure out the source. In v3 speak, the source is an EngineID and context string. Remember the community string field and the transport address is just an associative key pair to get the triple: isProxy(and, if so, proxy info), context, and security info. (Table snmpCommunityTable is just one way, which is not too useful in an SNMPv1 or SNMPv2c environment, of describing the triple.) If the above is not clear, please provide example scenarios and I'll fill in the values. > - Steve Regards, /david t. perkins From owner-v6ops@ops.ietf.org Fri Sep 20 20:19:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14777 for ; Fri, 20 Sep 2002 20:19:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sY0X-000B8q-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 17:20:25 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17sY0T-000B8Z-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 17:20:21 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA02356; Fri, 20 Sep 2002 17:20:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8L0KHx11331; Fri, 20 Sep 2002 17:20:17 -0700 X-mProtect: <200209210020> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxeyBP9; Fri, 20 Sep 2002 17:20:15 PDT Message-ID: <3D8BBEA7.7010004@iprg.nokia.com> Date: Fri, 20 Sep 2002 17:34:47 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: "Bound, Jim" , Pekka Savola , Marc Blanchet , huitema@microsoft.com, satapati@cisco.com, v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > While I won't comment on TSP vs. some other way of explicitly configuring > tunnels, I'll make a more general comment. I don't know what other ways you have in mind, but as a technologist I must admit that I do see merits in the TSP approach. > I'm very concerned about trying to fully automate tunnel setup (whether > over IPv4 NATs or just plain old IPv4) due to the trust and security issues. > Thus I think it makes sense to have an authenticated and properly authorizable > tunnel establishment method that can work whether or not there is an > IPv4 NAT in the path. I think we will soon need to be careful about how we define the term "automatic tunnel". Marc Blanchet has introduced a new term "semi-automatic" tunnel into the discussion to refer to the process of automating configured tunnel setup (am I representing this properly, Marc?) I have been struggling with the cumbersome terminology this imparts, i.e., we now have "semi-automatic configured tunnels" and we may one day also have "semi-automatic-automatic tunnels". It might help to look to the characteristics of the two different mechansims: "Configured" tunnels, as we know them today, are (in part) defined to "...behave as virtual point-to-point links" [MECH, 1.1]. "Automatic" tunnels, as we know them today, are understood to behave as virtual point-to-multi- point links. But, both point-to-point and point-to-multipoint virtual links may benefit from "semi-automatic" explicit configuration mechanisms such as TSP. > The operational model for this is that the user establishes a trust > relationship with the tunnel provider and uses this to establish and maintain > the tunnel automatically. My individual submission entitled "ISATAP interactions with TSP" explores possible benefits for using TSP with ISATAP, including exactly the sort of trust relationship you describe above. It is possible that these same benefits may extend to the general case of point-to-multipoint virtual links, but I'm not prepared to make any claims in that regard. The draft can be found at: http://www.ietf.org/internet-drafts/draft-templin-interact-00.txt > I think this can be made really simple but yet secure. As above, as a technologist I admit that I do see merits in this approach. Fred ftemplin@iprg.nokia.com From owner-v6ops@ops.ietf.org Fri Sep 20 20:35:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15034 for ; Fri, 20 Sep 2002 20:35:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sYGW-000CCP-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 17:36:56 -0700 Received: from mailhost1-chcgil.chcgil.ameritech.net ([206.141.192.67] helo=mailhost.chi1.ameritech.net) by psg.com with esmtp (Exim 3.36 #1) id 17sYGR-000CBb-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 17:36:51 -0700 Received: from repligate ([67.37.178.198]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020921003650.UIMC1118.mailhost.chi1.ameritech.net@repligate> for ; Fri, 20 Sep 2002 19:36:50 -0500 Message-ID: <06c001c26107$02a469f0$c6b22543@repligate> From: "Jim Fleming" To: References: <20020918212122.9385628B01@as.vix.com> Subject: "A6 was a concrete solution, with plusses and minuses, and is dead now." Date: Fri, 20 Sep 2002 19:37:04 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=2.5 required=5.0 tests=DOUBLE_CAPSWORD,PORN_4 version=2.31 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "A6 was a concrete solution, with plusses and minuses, and is dead now." A6 can not be dead, it is the heart and soul of IPv6. Without A6, how can there be an IPv6 ? AAAA is for use with IPv4++. New versions of Windows produce IPv4 packets when sent 2002: model year addresses. 128-bit DNS AAAA Record Flag Day Formats 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved ("Spare") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://www.netfilter.org/ http://www.analogx.com/contents/dnsdig.htm http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au http://ipv8.ods.org ----- Original Message ----- From: "Paul Vixie" To: Sent: Wednesday, September 18, 2002 4:21 PM Subject: Re: renumbering > > | however, at size 10**4 and above, renumbering of this kind will be > > | expensive. > > > > The actual renumbering need not be expensive. At the minute it would be, > > but more tools/protocols can be developed to make the kind of renumbering > > we're talking about more or less invisible as far as the site is > > concerned (and yes, A6 would certainly have helped). > > A6 was a concrete solution, with plusses and minuses, and is dead now. > > Alternatives which would also make renumbering less expensive are just > vaporware at the moment, and since I can't evaluate them I can't accept > your assertion that actual renumbering need not be expensive. > > > | and at size 10**5 and above, it will be constant/overlapping. > > > > Huh? What does the size of the net have to do with the frequency of > > renumbering - if anything, smaller nets are the ones that tend to shift > > around more frequently (they don't have the clout to get good deals from > > providers initially, nor do they usually engage in longer term agreements > > to achieve that - bigger places do). > > Larger networks are less mobile only when renumbering makes it so. If you > take away the renumbering penality (for example, if you use NAT) then I'd > expect any network who attends a transit exchange such as PAIX or Equinix > to change their provider at least once a month during fee wars. > > > | ..., that's a big reason why folks will ask "why not just use NAT?" > > > > And the answer will be, that NAT achieves nothing, but does limit > > applications, some things just don't work. And once we get into an > > environment where the default isn't "everyone uses NAT", more of the > > kinds of applications that just don't work with NAT are likely to appear > > (there will be no reason for them not to). > > What odds are you giving and how much are you putting up? > > Please don't misunderstand my intent here. I'm not using NAT and ISC is 99% > done rolling out IPv6 internally and I'm not trying to get anybody to feel > bad or act different concerning renumbering technologies, A6 or otherwise. > > However, at the moment my take on all this is that folks are likely to use > more NAT rather than less. Any application author who wants to make their > work NAT-unfriendly can't be -- and shouldn't be -- stopped. But as far as > the core protocols go, I think we should do a better job avoiding moralism > tham IPsec did. ("L4 routing/switching/firewalling is evil, so let's cover > the port numbers under the encryption envelope.") > From owner-v6ops@ops.ietf.org Fri Sep 20 22:22:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16544 for ; Fri, 20 Sep 2002 22:22:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sZvC-000InH-00 for v6ops-data@psg.com; Fri, 20 Sep 2002 19:23:02 -0700 Received: from mailhost1-chcgil.chcgil.ameritech.net ([206.141.192.67] helo=mailhost.chi1.ameritech.net) by psg.com with esmtp (Exim 3.36 #1) id 17sZv8-000ImZ-00 for v6ops@ops.ietf.org; Fri, 20 Sep 2002 19:22:58 -0700 Received: from repligate ([67.37.178.198]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020921022257.WAPC1118.mailhost.chi1.ameritech.net@repligate>; Fri, 20 Sep 2002 21:22:57 -0500 Message-ID: <07ba01c26115$d5db9420$c6b22543@repligate> From: "Jim Fleming" To: "Pekka Savola" , References: Subject: Re: 3GPP soluations comments Date: Fri, 20 Sep 2002 21:23:12 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.4 required=5.0 tests=PORN_4 version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Pekka Savola" > > ==> IMO, I'm not 100% sure this number of legacy IPv4 nodes *IMS* > communicates with is necessarily all that large. If I understood correctly, > that means basically v4-only SIP phones. Are there really all that many of > those. SIP phones that could not be relatively easily upgraded to IPv6? If > the number of scenarios to support were to be shortened, IMO this would be > among the first ones to go. > The Killer AP for IPv8 has always been voice... http://www.vonage.com/howitworks_technology.php "We use the emerging standard in the VoIP industry called SIP (Session Initiation Protocol). This allows us to provide you with unsurpassed high speed internet phone service without monopolizing your high-speed Internet connection." ==== Bandwidth is still important...as well as price of the service...in this case $39.95 per month... ...on top of the $50 per month for the high-speed connection... What problem does IPv6 solve again ? Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://www.netfilter.org/ http://www.analogx.com/contents/dnsdig.htm http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au http://ipv8.ods.org From owner-v6ops@ops.ietf.org Sat Sep 21 03:40:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06948 for ; Sat, 21 Sep 2002 03:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sesA-000C7G-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 00:40:14 -0700 Received: from [3ffe:501:100f:0:200:f8ff:fe01:61cf] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 17ses6-000C74-00 for v6ops@ops.ietf.org; Sat, 21 Sep 2002 00:40:11 -0700 Received: from localhost ([3ffe:501:4819:2000:18f9:3c21:3093:6dd7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g8L7e0t70601; Sat, 21 Sep 2002 16:40:00 +0900 (JST) Date: Sat, 21 Sep 2002 16:40:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Harald Tveit Alvestrand Cc: v6ops@ops.ietf.org Subject: Re: unmanaged scope comments In-Reply-To: <38654542.1032532767@localhost> References: <20020919154801.4E7667BB@starfruit.itojun.org> <38654542.1032532767@localhost> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 41 X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,CHARSET_FARAWAY_HEADERS version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Fri, 20 Sep 2002 14:39:27 +0200, >>>>> Harald Tveit Alvestrand said: >> i don't understand what you want to do about it. will you ping/ping6 >> destination and pick shorter roundtrip? when multiple A records >> are returned for www.foo.com, do you probe them to get the optimal >> performance? i believe the "quality" factor does not matter, and >> it cannot be measured from endpoint (at least within short time). > I have wanted for a long time someone more competent than me to run an > experiment where one, after a name lookup, would send SYN packets to *all* > the addresses returned, and only complete the three-way handshake on the > first one to reply. > after all, it seems impossible to get anyone to take seriously the job of > getting the network to tell me which of two addresses are "best", and the > servers in these DOS-attack days have to defend against synfloods anyway. > just wasting some SYN packets seems to me to be likely to achieve the "low > hanging fruit" of *most of the time* picking the best address to use. > so far, afaik, nobodoy's tried it. This sounds like an experimental library function I wrote two years ago: http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/libinet6/mconnect.c (though the library makes a short delay between two consecutive connect(2)s.) I used the library with some applications and found it worked well, but I've not promoted the new library because I didn't know how this could be widely deployed. Also, if I understand correctly, there is a web client that has a similar routine inside the application. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Sat Sep 21 09:37:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11156 for ; Sat, 21 Sep 2002 09:37:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17skOq-0005Il-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 06:34:20 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17skOn-0005IZ-00; Sat, 21 Sep 2002 06:34:17 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17skOi-000FWO-00; Sat, 21 Sep 2002 06:34:12 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bob Fink , Jun-ichiro itojun Hagino , Margaret Wasserman Cc: v6ops@ops.ietf.org Subject: ocean: do not boil Message-Id: Date: Sat, 21 Sep 2002 06:34:12 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit first, thanks for doing a great job in sunnyvale. i think it was worth the effort and pains. of course, time will tell, as we see how the scenarios flesh out. but, i have been rather worried by one vector. i don't think we should try to solve the problem of an arbitrary user/service on a pure v6 site/host trying to communicate with a user/service on a pure v4 site/host or vice versa. dns is critical infrastructure, and we need to understand how everyone will see the same namespace whether they are on v4 or v6 transport [0]. and we have some clues on how to do that, point mono-stack resolvers at dual-stack caching servers. but services such as http, smtp, blah, blah, blah just can't be completely transparent, and we *vastly* increase the size of the problem if we try to make them so. if i want my web site seen by both v4 and v6 users, then i can connect it to v4 and v6 space and run dual stack. in fact, i do so today. as v6 deploys, folk every useful site will do so. if i want to send mail to v4 users and i live in a pure v6 world, then i can make an arrangement with a dual-stack relay to provide forwarding service to me. and to receive mail, i can just point an MX naming an A record to a dual-stack forwarding service. if i want to play a net.game which is in v6-land, then i need to be at least partially in v6-land. no magic. tough patooties. trying to make pure v4 sites/hosts communicate for arbitrary services with pure v6 sites/hosts and vice verse is a nice way to make the problem vastly more complicated, the solutions vastly more complex, and the net much less reliable. let's not go there. randy --- [0] - if you're in private v6 space, i.e. site local or other 1918-envy games, use multiple views just as a v4 1918 site does today. From owner-v6ops@ops.ietf.org Sat Sep 21 09:43:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11206 for ; Sat, 21 Sep 2002 09:43:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17skYq-0005lC-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 06:44:40 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17skYo-0005l0-00; Sat, 21 Sep 2002 06:44:38 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17skYn-000FmH-00; Sat, 21 Sep 2002 06:44:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: IESG Secretary Cc: ngtrans@sunroof.eng.sun.com, v6ops@ops.ietf.org Subject: please close ngtrans Message-Id: Date: Sat, 21 Sep 2002 06:44:37 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit it is time for ngtrans to declare victory and close. ngtrans has come up with many tools, even more than were expected. but, as we saw in yokohama, v6 is here. the v6ops wg is taking responsibility for running the combined v4/v6 net and the tools and protocols necessary for doing so. in the next months, current ngtrans documents will be moving one at a time from ngtrans to v6ops. but, in the meantime, please keep the ngtrans mailing list open and archived. please continue to accept _updates_ to internet-drafts with names draft-ietf-ngtrans-... as they await formal processing into v6ops. thanks. randy From owner-v6ops@ops.ietf.org Sat Sep 21 09:58:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11382 for ; Sat, 21 Sep 2002 09:58:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17skoC-0006Zd-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 07:00:32 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17sko8-0006ZP-00; Sat, 21 Sep 2002 07:00:29 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8LE0Pd03971; Sat, 21 Sep 2002 17:00:25 +0300 Date: Sat, 21 Sep 2002 17:00:25 +0300 (EEST) From: Pekka Savola To: Randy Bush cc: Bob Fink , Jun-ichiro itojun Hagino , Margaret Wasserman , Subject: Re: ocean: do not boil In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, 21 Sep 2002, Randy Bush wrote: > first, thanks for doing a great job in sunnyvale. i think it was > worth the effort and pains. of course, time will tell, as we see > how the scenarios flesh out. > > but, i have been rather worried by one vector. > > i don't think we should try to solve the problem of an arbitrary > user/service on a pure v6 site/host trying to communicate with a > user/service on a pure v4 site/host or vice versa. [...] My feelings exactly. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sat Sep 21 10:47:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12083 for ; Sat, 21 Sep 2002 10:47:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17slYN-0008UW-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 07:48:15 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17slYJ-0008UI-00 for v6ops@ops.ietf.org; Sat, 21 Sep 2002 07:48:11 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F314161BF; Sat, 21 Sep 2002 10:48:10 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 21 Sep 2002 10:48:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Sat, 21 Sep 2002 10:48:10 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5AA@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJhdHNsZE/e3MVTSJKNgfzhUfdJyAABuFPg From: "Bound, Jim" To: "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 21 Sep 2002 14:48:10.0662 (UTC) FILETIME=[E7BE7460:01C2617D] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12083 > i don't think we should try to solve the problem of an arbitrary > user/service on a pure v6 site/host trying to communicate with a > user/service on a pure v4 site/host or vice versa. Nor do I for the general case. The market will solve this problem quickly anyway IMO. The one deprecated case that the scenarios will see (all of them) is when they are going to a v6site and that ASP site can only provide that service by going to a v4 site. It may beg the question do we need an ASP set of scenarios in addition to ISP scenarios? Which came up at the Interim meeting. > > dns is critical infrastructure, and we need to understand how > everyone will see the same namespace whether they are on v4 or v6 > transport [0]. and we have some clues on how to do that, point > mono-stack resolvers at dual-stack caching servers. that would be nice. > > but services such as http, smtp, blah, blah, blah just can't be > completely transparent, and we *vastly* increase the size of the > problem if we try to make them so. What do you mean by completely transparent? > > if i want my web site seen by both v4 and v6 users, then i can > connect it to v4 and v6 space and run dual stack. in fact, i do so > today. as v6 deploys, folk every useful site will do so. we do this today too on the 6bone and internal net. I don't see a pure v6 site that don't have a dual stack for a long time IMO. > > if i want to send mail to v4 users and i live in a pure v6 world, > then i can make an arrangement with a dual-stack relay to provide > forwarding service to me. and to receive mail, i can just point an > MX naming an A record to a dual-stack forwarding service. I agree but this should be transparent to the transport the node uses. > > if i want to play a net.game which is in v6-land, then i need to be > at least partially in v6-land. no magic. tough patooties. I agree. > > trying to make pure v4 sites/hosts communicate for arbitrary > services with pure v6 sites/hosts and vice verse is a nice way to > make the problem vastly more complicated, the solutions vastly more > complex, and the net much less reliable. let's not go there. I think I agree but not sure. Let me provide a scenario I am working for deployment as we talk. user has v6site except for parts suppliers have not completed v6 services and for now in the site uses private v4 addreses to get to them. but the v6site must get data from v4 site to use for its operations that requires use of global v4 address over Internet network. Today the user just uses one of their global v4 addresses for that data transfer. But the network ops design evolution requires all sites to move to dominant v6 site. What will happen though is the network edge will move last and remain v4. The plan is to tunnel v6 inside v4 to communicate between two v6 sites. The above assumes I think what you say is way to complex and the net ops plan above avoids that complexity. Am I on same wave length as your vector issue? /jim > > randy > > --- > > [0] - if you're in private v6 space, i.e. site local or other > 1918-envy games, use multiple views just as a v4 1918 site > does today. > > > From owner-v6ops@ops.ietf.org Sat Sep 21 11:22:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12327 for ; Sat, 21 Sep 2002 11:22:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sm6k-0008u2-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 08:23:46 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17sm6d-0008tg-00; Sat, 21 Sep 2002 08:23:40 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8LFNXE04570; Sat, 21 Sep 2002 18:23:33 +0300 Date: Sat, 21 Sep 2002 18:23:33 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , Margaret Wasserman , Subject: RE: ocean: do not boil In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5AA@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Some of my own comments. On Sat, 21 Sep 2002, Bound, Jim wrote: > > i don't think we should try to solve the problem of an arbitrary > > user/service on a pure v6 site/host trying to communicate with a > > user/service on a pure v4 site/host or vice versa. > > Nor do I for the general case. The market will solve this problem quickly anyway IMO. > The one deprecated case that the scenarios will see (all of them) is when they > are going to a v6site and that ASP site can only provide that service by going > to a v4 site. It may beg the question do we need an ASP set of scenarios in addition > to ISP scenarios? Which came up at the Interim meeting. ASP is an enterprise, IMO. If they don't feel providing v6 service important enough, you can always: 1) switch ASP's so make the market decide 2) implement some v6 -> v4 translation yourself (we're doing something remotely similar ourselves) > > if i want my web site seen by both v4 and v6 users, then i can > > connect it to v4 and v6 space and run dual stack. in fact, i do so > > today. as v6 deploys, folk every useful site will do so. > > we do this today too on the 6bone and internal net. I don't see a pure > v6 site that don't have a dual stack for a long time IMO. Yes. And btw, in especially in enterprise scenarios, one has to really careful about 'ipv6-only'; there are some services that usually need to be dual-stack, like authoritative DNS servers, WWW caching proxies, and some MX's; this can be partially worked around of course. > > trying to make pure v4 sites/hosts communicate for arbitrary > > services with pure v6 sites/hosts and vice verse is a nice way to > > make the problem vastly more complicated, the solutions vastly more > > complex, and the net much less reliable. let's not go there. > > I think I agree but not sure. Let me provide a scenario I am working for deployment > as we talk. > > user has v6site except for parts suppliers have not completed v6 services > and for now in the site uses private v4 addreses to get to them. but the v6site > must get data from v4 site to use for its operations that requires use of global > v4 address over Internet network. Today the user just uses one of their global > v4 addresses for that data transfer. But the network ops design evolution requires > all sites to move to dominant v6 site. What will happen though is the network > edge will move last and remain v4. The plan is to tunnel v6 inside v4 to communicate > between two v6 sites. > > The above assumes I think what you say is way to complex and the net ops plan above > avoids that complexity. > > Am I on same wave length as your vector issue? I believe "tunneling v4 through v6" in a completely v6-enabled site is not too complex. If it's too complex, the decision to move to v6-only has possibly been made prematurely (for some part of the network, at least). In the above case, depending on the service I'd probably provide a TCP relay access to the service (if transport-agnostic), or just keep v4 service until there is no more need for it. Restricted use of TCP relay is IMO a rather good transition solution for some services. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Sat Sep 21 11:40:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12579 for ; Sat, 21 Sep 2002 11:40:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17smO4-000982-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 08:41:40 -0700 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17smNy-00097n-00 for v6ops@ops.ietf.org; Sat, 21 Sep 2002 08:41:34 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A5A72838; Sat, 21 Sep 2002 11:41:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 21 Sep 2002 11:41:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Sat, 21 Sep 2002 11:41:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5AB@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJhguFpIJ6tHSZOQAWZ26mrLAGLEAAAEoAg From: "Bound, Jim" To: "Pekka Savola" Cc: "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , "Margaret Wasserman" , X-OriginalArrivalTime: 21 Sep 2002 15:41:31.0364 (UTC) FILETIME=[5B82D240:01C26185] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA12579 > ASP is an enterprise, IMO. Be good to get the group to all agree about this so the Enterprise Design Team understands that from the beginning. I for one was unclear whether folks felt ASP stuff should be in the Enterprise. I don't care either way. Just want to know early on as I am sure my colleagues on the Ent Design team want to know too. > > Restricted use of TCP relay is IMO a rather good transition > solution for > some services. > Not sure yet either way. But the more relays, ALGs, and parts of this nature that one puts in the network will also cause more stuff for the users and operators to manage. Maybe we need to have matrix somewhere and possibly in each scenario a "degrees of complexity/performance" for the overall operation of the network? E.G. (this is just for discussion making no judgements of complexity/peformance below just view as "model" for discussion) Legend: C1 == Not complex just tunnels C2 == Medium Complex tunnels and gateways C3 == Very Complex tunnels, gateways, relays, bump-in-apis P1 == best performance P2 == fair performance P3 == least performance Scenario1 Solution A | Sceneario2 Solution B | Scenario3 Solution C C1/P3 | C2/P1 | C1/P1 The scenario, solution, and methods of transition would affect the matrix entry. We would need template to cause the most "objetive" analysis of course so it is not subjective or supporting any specific agenda. Could this actually be an informational rfc for v6ops too? regards, /jim /jim From owner-v6ops@ops.ietf.org Sat Sep 21 18:24:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18184 for ; Sat, 21 Sep 2002 18:24:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ssfY-000FYf-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 15:24:08 -0700 Received: from mailhost1-chcgil.chcgil.ameritech.net ([206.141.192.67] helo=mailhost.chi1.ameritech.net) by psg.com with esmtp (Exim 3.36 #1) id 17ssfT-000FYT-00 for v6ops@ops.ietf.org; Sat, 21 Sep 2002 15:24:03 -0700 Received: from repligate ([67.37.178.198]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020921222402.LBTR1118.mailhost.chi1.ameritech.net@repligate> for ; Sat, 21 Sep 2002 17:24:02 -0500 Message-ID: <0a6901c261bd$a3b84170$c6b22543@repligate> From: "Jim Fleming" To: References: Subject: A Mirage is not an Ocean....Re: ocean: do not boil Date: Sat, 21 Sep 2002 17:24:23 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit IPv6 users are like people on boats yelling to people on land that they (on the boats) are on land. The boats may get larger, but they are still floating and not land. The boats may become islands for people from the continents to visit, but few will. It is much easier to add a second story and more to all of the places on the continent... ...as opposed to trying to convince people they need to move to a boat and an island for more space... ...people do not see that the risk has a pay-off.... ...especially when obvious expansion solutions are in in front of them... ...as the islands regress and become boats, the boats can be moved ashore and mapped to land... ...some can continue to stand at the wheel of their boat and **think** they are on the ocean... ...put them in the desert and let them look at the mirages in the heat of the day and they will be fine... ...full-steam ahead....the S.S. ICANIC is ready to launch... From owner-v6ops@ops.ietf.org Sat Sep 21 22:06:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20849 for ; Sat, 21 Sep 2002 22:06:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17sw8l-000KfS-00 for v6ops-data@psg.com; Sat, 21 Sep 2002 19:06:31 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17sw8i-000KfH-00 for v6ops@ops.ietf.org; Sat, 21 Sep 2002 19:06:28 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 444364B22; Sun, 22 Sep 2002 11:06:24 +0900 (JST) To: Pekka Savola Cc: Randy Bush , Bob Fink , Margaret Wasserman , v6ops@ops.ietf.org In-reply-to: pekkas's message of Sat, 21 Sep 2002 17:00:25 +0300. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ocean: do not boil From: itojun@iijlab.net Date: Sun, 22 Sep 2002 11:06:24 +0900 Message-Id: <20020922020624.444364B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >On Sat, 21 Sep 2002, Randy Bush wrote: >> first, thanks for doing a great job in sunnyvale. i think it was >> worth the effort and pains. of course, time will tell, as we see >> how the scenarios flesh out. >> >> but, i have been rather worried by one vector. >> >> i don't think we should try to solve the problem of an arbitrary >> user/service on a pure v6 site/host trying to communicate with a >> user/service on a pure v4 site/host or vice versa. >[...] > >My feelings exactly. seconded. the internet is so successful since it was designed under "keep it simple and stupid" approach. i think it critical to follow same way for IPv6 be successful (and this is one of the reason why IPv6 is following a lot of IPv4 design principles). itojun From owner-v6ops@ops.ietf.org Sun Sep 22 10:50:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08703 for ; Sun, 22 Sep 2002 10:50:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17t7yN-0006ru-00 for v6ops-data@psg.com; Sun, 22 Sep 2002 07:44:35 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17t7yK-0006rh-00; Sun, 22 Sep 2002 07:44:32 -0700 Received: from kenawang.windriver.com ([147.11.233.7]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA18659; Sun, 22 Sep 2002 07:43:48 -0700 (PDT) Message-Id: <5.1.0.14.2.20020922101942.022428b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 22 Sep 2002 10:44:36 -0400 To: Randy Bush From: Margaret Wasserman Subject: Re: ocean: do not boil Cc: Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >i don't think we should try to solve the problem of an arbitrary >user/service on a pure v6 site/host trying to communicate with a >user/service on a pure v4 site/host or vice versa. I agree with this. We need to focus on the scenarios that are most likely to occur in the next few years, as IPv6 is added to the existing IPv4 infrastructure. In this immediate future, most networks/hosts will continue to have some IPv4 connectivity, often using NAT. IPv6-only hosts are likely to be limited to special-purpose devices that only need to reach specialized IPv6 services. We so need to support IPv6-only services, but it isn't necessary for IPv4-only nodes to be able to participate. So, there shouldn't be a need for direct IPv4-only <-> IPv6-only communication. Margaret From owner-v6ops@ops.ietf.org Sun Sep 22 15:20:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12095 for ; Sun, 22 Sep 2002 15:20:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tCH5-000AiJ-00 for v6ops-data@psg.com; Sun, 22 Sep 2002 12:20:11 -0700 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 17tCH2-000Ai7-00; Sun, 22 Sep 2002 12:20:08 -0700 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA10315; Sun, 22 Sep 2002 12:20:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g8MJK3E27735; Sun, 22 Sep 2002 12:20:03 -0700 X-mProtect: <200209221920> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (32.106.20.139, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmfeFKv; Sun, 22 Sep 2002 12:20:00 PDT Message-Id: <4.3.2.7.2.20020922120942.02782a48@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 22 Sep 2002 12:19:41 -0700 To: Margaret Wasserman From: Bob Hinden Subject: Re: ocean: do not boil Cc: Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: <5.1.0.14.2.20020922101942.022428b0@mail.windriver.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >>i don't think we should try to solve the problem of an arbitrary >>user/service on a pure v6 site/host trying to communicate with a >>user/service on a pure v4 site/host or vice versa. > >I agree with this. I don't agree with one case of this. I think there is a need to have IPv6 only hosts that are able to reach the same IPv4 services that an IPv4 host behind a NAT today can reach. This will make IPv6 only hosts much more attractive than if they can only reach IPv6 services. This will make IPv6 only a real possibility for new deployments of new types of devices. If we don't support this case, then these devices (and resulting infrastructure) will have to be dual stack. I do agree that doing more than this case is not necessary. Bob From owner-v6ops@ops.ietf.org Mon Sep 23 01:39:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20446 for ; Mon, 23 Sep 2002 01:39:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tLvk-000MmG-00 for v6ops-data@psg.com; Sun, 22 Sep 2002 22:38:48 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17tLvg-000Mm3-00 for v6ops@ops.ietf.org; Sun, 22 Sep 2002 22:38:45 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2CF5465C7 for ; Mon, 23 Sep 2002 01:38:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 23 Sep 2002 01:38:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Transition affects business decisions Date: Mon, 23 Sep 2002 01:38:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5AE@tayexc13.americas.cpqcorp.net> Thread-Topic: (ngtrans) Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Thread-Index: AcJimfPV59sG3NyfSPuzXl2MFfHHEwAIWyuQAAGb0wA= From: "Bound, Jim" To: X-OriginalArrivalTime: 23 Sep 2002 05:38:43.0910 (UTC) FILETIME=[7ADACE60:01C262C3] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA20446 Folks, My input to you is that unlike TCP, SCTP, IPv6 (the IP protocol) et al are technical specifications for protocols we build in the IETF that users will specify usually to build their networks, developing transition mechanisms are not exactly the same work. Transition mechanisms have protocol parts but they also have policy that affects a users business decision on how they adopt and use IPv6. Users will for the most part IMO adhere to our policies affecting protocols and interoperability. But IMO they will not adhere to practices or policy that negatively impact their business. The problem with transition mechanisms is that for some users some mechanisms will be good, and some will be bad. What is good for one will be bad for another. Etc. Etc. Etc. How a business is affected by transition is not a binary or ternary or ###^X decision, but based on industry economics, state of budget, and politics. My point is we cannot assume anything about a users business in our work in the IETF because the minute we do we will be proven wrong by some business entity IMO and my input to our forthcoming work. IMO we need to build whatever we build that is new in v6ops with this in mind if we are to be successful and have what we do be used by the market. /jim From owner-v6ops@ops.ietf.org Mon Sep 23 03:39:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01348 for ; Mon, 23 Sep 2002 03:39:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tNod-000PKk-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 00:39:35 -0700 Received: from [193.145.218.216] (helo=laptop.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 17tNoa-000PKZ-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 00:39:32 -0700 Received: from laptop.kurtis.pp.se (localhost [127.0.0.1]) by laptop.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id g8N7d1bu005766; Mon, 23 Sep 2002 09:39:12 +0200 (CEST) Date: Sun, 22 Sep 2002 22:02:12 +0200 Subject: Re: comments on draft-itojun-v6ops-v4mapped-harmful-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: v6ops@ops.ietf.org To: Paul Vixie From: Kurt Erik Lindqvist In-Reply-To: <20020917185058.53B2B28B02@as.vix.com> Message-Id: <2F335A80-CE66-11D6-8FDD-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_06_12 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >> If NAT works so well in the first place, why do we then need IPv6 at >> all? > > i expect that question to come up quite a lot, as part of the business > case > analysis. "i've got 20,000 ip-speaking devices, but only 7 of them > have > universally unique addresses, the rest are in private address space > because > i was not able to get a class B. if i move to ipv6 i can get my own > /48 but > it will be in my isp's address space, which will make multihoming hard > and > make switching providers even harder. do i really want to have to > renumber, > even with ipv6's extensive automated assistance for this, whenever > there's > a rate war at my local transit exchange?" and then will come the > question > you gave above. > I have long been arguing that there is nothing I can do in IPv6 that I can't do in IPv4. It might be done in different ways, or in some ways easier, but it can still be done (in my opinion cleaner and easier in a lot of cases in IPv4). Still, I don't see another path ahead than IPv6 at the moment, although I will be the first to point out the problems that IPv6 won't solve. I do think that we should go ahead, becuase if nothing else it will help us understand the real problems of migration and the problems with IPv4/IPv6 better. This said, I think we have had enough of IPv6 "priest" and now need to get more operationally focused people in to the v6 discussions. Here Paul points out a interesting thing, so far we have seen the early adopters. I think they are generally keener to ignore potential problems for downstreams than then downstreams them selves - for obvious reasons. In away I think we are back to pre-CIDR - which have it's advantages and disadvantages. Keeping the number of routes down should be a priority concern in my opinon. Then again - I wan't to see the first first +100k employee organization renumber. Best regards, - kurtis - From owner-v6ops@ops.ietf.org Mon Sep 23 03:50:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01507 for ; Mon, 23 Sep 2002 03:50:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tO0h-000PTW-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 00:52:03 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17tO0e-000PTK-00; Mon, 23 Sep 2002 00:52:00 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tO0c-0006Er-00; Mon, 23 Sep 2002 08:51:58 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tO0c-0006Em-00; Mon, 23 Sep 2002 08:51:58 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA61884; Mon, 23 Sep 2002 08:51:57 +0100 Message-ID: <3D8EC827.56C0A1EE@hursley.ibm.com> Date: Mon, 23 Sep 2002 09:52:07 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Randy Bush CC: Bob Fink , Jun-ichiro itojun Hagino , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: ... > but, i have been rather worried by one vector. > > i don't think we should try to solve the problem of an arbitrary > user/service on a pure v6 site/host trying to communicate with a > user/service on a pure v4 site/host or vice versa. Agree but: ... > if i want my web site seen by both v4 and v6 users, then i can > connect it to v4 and v6 space and run dual stack. in fact, i do so > today. as v6 deploys, folk every useful site will do so. Alternatively, arrange to have a dual stack HTTP proxy in the right place. Effect is the same, but like a dual stack SMTP relay it allows a v4 only host to play HTTP with a v6 only host. Brian From owner-v6ops@ops.ietf.org Mon Sep 23 04:02:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01594 for ; Mon, 23 Sep 2002 04:02:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tOC5-000Pdb-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 01:03:49 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17tOC1-000PdO-00; Mon, 23 Sep 2002 01:03:45 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8N83e528630; Mon, 23 Sep 2002 11:03:40 +0300 Date: Mon, 23 Sep 2002 11:03:40 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , Margaret Wasserman , Subject: Re: ocean: do not boil In-Reply-To: <3D8EC827.56C0A1EE@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 23 Sep 2002, Brian E Carpenter wrote: > > if i want my web site seen by both v4 and v6 users, then i can > > connect it to v4 and v6 space and run dual stack. in fact, i do so > > today. as v6 deploys, folk every useful site will do so. > > Alternatively, arrange to have a dual stack HTTP proxy in the right > place. Effect is the same, but like a dual stack SMTP relay it allows > a v4 only host to play HTTP with a v6 only host. Note that Randy said 'want my web site seen by both v4 and v6 users', not 'want my client to reach both v4 and v6 sites'. In all cases I can think of, if you want your web content be available for both v4/v6 users, you should run it on dual stack at least for now: you shouldn't have to rely on the the clients being able to perform transport IP version changes (like with ALG). From the client perspective I agree that dual-stack web proxies seem like a very interesting and probably quite robust approach. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Mon Sep 23 04:03:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01628 for ; Mon, 23 Sep 2002 04:03:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tODl-000PfW-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 01:05:33 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17tODi-000PfK-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 01:05:30 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 89A2D28B6E for ; Mon, 23 Sep 2002 08:05:27 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-Reply-To: Message from Bob Hinden of "Sun, 22 Sep 2002 12:19:41 MST." <4.3.2.7.2.20020922120942.02782a48@mailhost.iprg.nokia.com> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Mon, 23 Sep 2002 08:05:27 +0000 Message-Id: <20020923080527.89A2D28B6E@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >>i don't think we should try to solve the problem of an arbitrary > >>user/service on a pure v6 site/host trying to communicate with a > >>user/service on a pure v4 site/host or vice versa. > > > >I agree with this. > > I don't agree with one case of this. I think there is a need to have IPv6 > only hosts that are able to reach the same IPv4 services that an IPv4 host > behind a NAT today can reach. [...] in the specific case of dns, we (isc) agree with this and will be adding an application level capability to choose a specific forwarder set when recursion requires contacting an "A RR" on a host with only ipv6 interfaces. From owner-v6ops@ops.ietf.org Mon Sep 23 09:36:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08481 for ; Mon, 23 Sep 2002 09:36:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tTMr-00049v-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 06:35:17 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17tTMo-00049j-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 06:35:14 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22389; Mon, 23 Sep 2002 06:35:13 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8NDZCA00121; Mon, 23 Sep 2002 15:35:12 +0200 (MEST) Date: Mon, 23 Sep 2002 15:32:44 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comment on unmanaged analysis presentation/doc To: Jun-ichiro itojun Hagino Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20020920221409.DB3CA7B9@starfruit.itojun.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=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > in that case, what is your comment to 6to4 routers? they accept > tunnelled packet from anyone, with no authentication whatsoever. You mean 6to4 relay (routers)? 6to4 routers should only accept tunneled packets from their configured relay(s). I think the relays are quite problematic because of this behavior. Erik From owner-v6ops@ops.ietf.org Mon Sep 23 09:41:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08633 for ; Mon, 23 Sep 2002 09:41:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tTTx-0004IC-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 06:42:37 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17tTTe-0004HG-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 06:42:18 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 92AF74B22; Mon, 23 Sep 2002 22:42:14 +0900 (JST) To: Erik Nordmark Cc: v6ops@ops.ietf.org In-reply-to: Erik.Nordmark's message of Mon, 23 Sep 2002 15:32:44 +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: comment on unmanaged analysis presentation/doc From: itojun@iijlab.net Date: Mon, 23 Sep 2002 22:42:14 +0900 Message-Id: <20020923134214.92AF74B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> in that case, what is your comment to 6to4 routers? they accept >> tunnelled packet from anyone, with no authentication whatsoever. >You mean 6to4 relay (routers)? no, 6to4 router for any sites, not just relay routers. if a node in 6to4 site A (2002:xxxx:xxxx::/48) tries to talk to a node in 6to4 site B (2002:yyyy:yyyy::/48), 6to4 router for site A will directly contact 6to4 router for site B. therefore, any 6to4 routers will need to accept tunnelled packet from anybody. >6to4 routers should only accept tunneled packets from their configured >relay(s). if you've done the first sentence, packets from other 6to4 sites will get (mistakenly) rejected. >I think the relays are quite problematic because of this behavior. the problem is not just relays, but all 6to4 routers. itojun From owner-v6ops@ops.ietf.org Mon Sep 23 10:02:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09391 for ; Mon, 23 Sep 2002 10:02:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tTnT-0004lr-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 07:02:47 -0700 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17tTnQ-0004ld-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 07:02:44 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B579B6B50; Mon, 23 Sep 2002 10:02:43 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 23 Sep 2002 10:02:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comment on unmanaged analysis presentation/doc Date: Mon, 23 Sep 2002 10:02:43 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE933B@tayexc13.americas.cpqcorp.net> Thread-Topic: comment on unmanaged analysis presentation/doc Thread-Index: AcJjBrTEq3GLuuuhT8WXEMLTO2H+dQAAx5Ew From: "Bound, Jim" To: "Erik Nordmark" , "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 23 Sep 2002 14:02:43.0621 (UTC) FILETIME=[E3208550:01C26309] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09391 yes they are and this was provided as input to 6to4 from me and others on my team. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Monday, September 23, 2002 9:33 AM > To: Jun-ichiro itojun Hagino > Cc: Erik Nordmark; v6ops@ops.ietf.org > Subject: Re: comment on unmanaged analysis presentation/doc > > > > in that case, what is your comment to 6to4 routers? they accept > > tunnelled packet from anyone, with no authentication whatsoever. > > You mean 6to4 relay (routers)? > 6to4 routers should only accept tunneled packets from their configured > relay(s). > > I think the relays are quite problematic because of this behavior. > > Erik > > > > From owner-v6ops@ops.ietf.org Mon Sep 23 10:11:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09847 for ; Mon, 23 Sep 2002 10:11:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tTxL-00050M-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 07:12:59 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17tTxI-000509-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 07:12:56 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13092; Mon, 23 Sep 2002 08:12:54 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8NECrA05219; Mon, 23 Sep 2002 16:12:53 +0200 (MEST) Date: Mon, 23 Sep 2002 16:10:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comment on unmanaged analysis presentation/doc To: itojun@iijlab.net Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20020923134214.92AF74B22@coconut.itojun.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=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > if a node in 6to4 site A (2002:xxxx:xxxx::/48) tries to talk to a node > in 6to4 site B (2002:yyyy:yyyy::/48), 6to4 router for site A > will directly contact 6to4 router for site B. therefore, any 6to4 > routers will need to accept tunnelled packet from anybody. Yes, but they can verify that - The IPv4 source is identical to the IPv4 part of the IPv6 source address (same xx.xx.xx.xx) The first check ensures that spoofing the IPv4 source requires spoofing the IPv6 source, hence there is no loss of information by removing the IPv4 source address when decapsulating the packet. Stated differently, if you apply IPv4 ingress filtering in the network and IPv6 ingress filtering in the IPv6-native parts of the network, the use of encapsulation doesn't create additional holes in your filtering. The use of relays to allow IPv6-native hosts to send to 6to4 domains make this impossible, because any relay needs to be able to encapsulate packets towards a particular 6to4 router. Thus the router will receive packets where the IPv4 source and IPv6 source are unrelated. Even if ingress filtering is applied as above, is it impossible to tell whether a given relay is allowed to forward packets from a given IPv6 prefix. Hence the use of encapsulation creates a hole in the ingress filtering being used. > >6to4 routers should only accept tunneled packets from their configured > >relay(s). > > if you've done the first sentence, packets from other 6to4 sites will > get (mistakenly) rejected. Sorry, I forgot to mention the case when 6to4 router communicate directly (the case above). > the problem is not just relays, but all 6to4 routers. If we discard the need for IPv6-native to communicate with 6to4 sites i.e. there is no need for relays, then the use of encapsulation doesn't create any new holes in an ingress filtering setup. Erik From owner-v6ops@ops.ietf.org Mon Sep 23 10:16:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10041 for ; Mon, 23 Sep 2002 10:16:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tU1O-00055w-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 07:17:10 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17tU1L-00055l-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 07:17:07 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id BC2174B22; Mon, 23 Sep 2002 23:17:05 +0900 (JST) To: Erik Nordmark Cc: v6ops@ops.ietf.org In-reply-to: Erik.Nordmark's message of Mon, 23 Sep 2002 16:10:22 +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: comment on unmanaged analysis presentation/doc From: itojun@iijlab.net Date: Mon, 23 Sep 2002 23:17:05 +0900 Message-Id: <20020923141705.BC2174B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> if a node in 6to4 site A (2002:xxxx:xxxx::/48) tries to talk to a node >> in 6to4 site B (2002:yyyy:yyyy::/48), 6to4 router for site A >> will directly contact 6to4 router for site B. therefore, any 6to4 >> routers will need to accept tunnelled packet from anybody. >Yes, but they can verify that > - The IPv4 source is identical to the IPv4 part of the IPv6 source > address (same xx.xx.xx.xx) IIRC a couple of IETFs ago Alain was arguing that the check shouldn't be applied, for some reasons. from my vague memory the reason was this: - make it possible for a site to put multiple 6to4 routers (to load-balance outgoing traffic?). - make it possible to put 6to4 site behind 6to4 site? itojun From owner-v6ops@ops.ietf.org Mon Sep 23 10:55:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11485 for ; Mon, 23 Sep 2002 10:55:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tUbB-0005v0-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 07:54:09 -0700 Received: from [202.28.97.9] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17tUb7-0005tw-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 07:54:05 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8NErP305037; Mon, 23 Sep 2002 21:53:26 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8NEr3720641; Mon, 23 Sep 2002 21:53:05 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Erik Nordmark , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: <20020923141705.BC2174B22@coconut.itojun.org> References: <20020923141705.BC2174B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Sep 2002 21:53:03 +0700 Message-ID: <20639.1032792783@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Mon, 23 Sep 2002 23:17:05 +0900 From: itojun@iijlab.net Message-ID: <20020923141705.BC2174B22@coconut.itojun.org> | IIRC a couple of IETFs ago Alain was arguing that the check shouldn't | be applied, for some reasons. I don't know why Alain argued against that, but I also would. Erik.Nordmark@sun.com said: | If we discard the need for IPv6-native to communicate with 6to4 sites We can't do that - the only reason for having a 6to4 site is to be able to communicate with the rest of the IPv6 universe. We can't restrict that to the subset of that universe who are using 6to4. kre From owner-v6ops@ops.ietf.org Mon Sep 23 14:32:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19967 for ; Mon, 23 Sep 2002 14:32:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tY0n-000B0E-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 11:32:49 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17tY0e-000Azx-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 11:32:41 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8NIQ5023859; Mon, 23 Sep 2002 14:26:05 -0400 (EDT) Message-Id: <200209231826.g8NIQ5023859@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Mon, 23 Sep 2002 21:53:03 +0700.") <20639.1032792783@munnari.OZ.AU> Date: Mon, 23 Sep 2002 14:26:05 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > the only reason for having a 6to4 site is to be able > to communicate with the rest of the IPv6 universe. false. 6to4 is extremely useful for allowing interconnection between arbitrary hosts that are sited on networks that only have a single global IPv4 address. communicating between 6to4 and native v6 is of course useful also, but it's not the only reason that people will use (are using!) 6to4. Keith From owner-v6ops@ops.ietf.org Mon Sep 23 15:15:47 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21254 for ; Mon, 23 Sep 2002 15:15:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tYgf-000CEB-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 12:16:05 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17tYgW-000CDl-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 12:15:56 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8NJ9G024400; Mon, 23 Sep 2002 15:09:17 -0400 (EDT) Message-Id: <200209231909.g8NJ9G024400@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Randy Bush cc: Keith Moore , Robert Elz , itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Mon, 23 Sep 2002 12:05:19 PDT.") Date: Mon, 23 Sep 2002 15:09:16 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > wow! keith advocates pure nat! nope. keith advocates tunneling of v6 over v4 as an alternative to nat. From owner-v6ops@ops.ietf.org Mon Sep 23 15:42:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22119 for ; Mon, 23 Sep 2002 15:42:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tZ7Z-000CxU-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 12:43:53 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tZ7W-000Cwz-00; Mon, 23 Sep 2002 12:43:50 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8NJgxKV027177; Mon, 23 Sep 2002 21:42:59 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 21:43:00 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A13@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Bob Hinden'" , Margaret Wasserman Cc: Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 21:42:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >>i don't think we should try to solve the problem of an arbitrary > >>user/service on a pure v6 site/host trying to communicate with a > >>user/service on a pure v4 site/host or vice versa. > > > >I agree with this. > > I don't agree with one case of this. I think there is a > need to have IPv6 > only hosts that are able to reach the same IPv4 services > that an IPv4 host > behind a NAT today can reach. This will make IPv6 only > hosts much more > attractive than if they can only reach IPv6 services. This > will make IPv6 > only a real possibility for new deployments of new types of > devices. If we > don't support this case, then these devices (and resulting > infrastructure) > will have to be dual stack. => I completely agree with Bob. I don't understand how we can rule out the v6only => v4 only communication. What do we say to operators who can't get enough v4 addreses? Deploy a v4 NAT as well as IPv6? I can understand that communication between a v4only host initiating a connection with a v6 only host is too difficult and probably should not be a priority. Hesham From owner-v6ops@ops.ietf.org Mon Sep 23 16:26:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23585 for ; Mon, 23 Sep 2002 16:26:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tZn8-000E8Z-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 13:26:50 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tZn5-000E8M-00; Mon, 23 Sep 2002 13:26:47 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8NKQ9KV029862; Mon, 23 Sep 2002 22:26:09 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 22:26:09 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A18@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "Hesham Soliman (EAB)" , "'Bob Hinden'" , Margaret Wasserman Cc: Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 22:26:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I should clarify that my comment was in the context of new applications (other than HTTP and email, i.e. p2p). Hesham > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: Monday, September 23, 2002 9:43 PM > To: 'Bob Hinden'; Margaret Wasserman > Cc: Randy Bush; Bob Fink; Jun-ichiro itojun Hagino; > v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > > > >>i don't think we should try to solve the problem of > an arbitrary > > >>user/service on a pure v6 site/host trying to > communicate with a > > >>user/service on a pure v4 site/host or vice versa. > > > > > >I agree with this. > > > > I don't agree with one case of this. I think there is a > > need to have IPv6 > > only hosts that are able to reach the same IPv4 services > > that an IPv4 host > > behind a NAT today can reach. This will make IPv6 only > > hosts much more > > attractive than if they can only reach IPv6 services. This > > will make IPv6 > > only a real possibility for new deployments of new types of > > devices. If we > > don't support this case, then these devices (and resulting > > infrastructure) > > will have to be dual stack. > > => I completely agree with Bob. I don't understand how we > can rule out the v6only => v4 only communication. > What do we say to operators who can't get enough > v4 addreses? Deploy a v4 NAT as well as IPv6? > > I can understand that communication between a v4only > host initiating a connection with a v6 only host > is too difficult and probably should not be a priority. > > Hesham > From owner-v6ops@ops.ietf.org Mon Sep 23 16:46:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24327 for ; Mon, 23 Sep 2002 16:46:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ta6H-000ElJ-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 13:46:37 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17ta6E-000El7-00; Mon, 23 Sep 2002 13:46:34 -0700 Received: from kenawang.windriver.com ([147.11.233.22]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA12485; Mon, 23 Sep 2002 13:45:40 -0700 (PDT) Message-Id: <5.1.0.14.2.20020923164424.0202d5e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Sep 2002 16:46:18 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A13@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >=> I completely agree with Bob. I don't understand how we >can rule out the v6only => v4 only communication. >What do we say to operators who can't get enough >v4 addreses? Deploy a v4 NAT as well as IPv6? Why not? How do we think that our attempts at v6->v4 translation will be better than deploying an IPv4 NAT? >I can understand that communication between a v4only >host initiating a connection with a v6 only host >is too difficult and probably should not be a priority. So, perhaps we are all in agreement on that. Margaret From owner-v6ops@ops.ietf.org Mon Sep 23 16:53:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24541 for ; Mon, 23 Sep 2002 16:53:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17taEY-000F2w-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 13:55:10 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17taER-000F1p-00; Mon, 23 Sep 2002 13:55:03 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8NKsrKV001627; Mon, 23 Sep 2002 22:54:53 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 22:54:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A1A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" Cc: "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 22:54:53 +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.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >=> I completely agree with Bob. I don't understand how we > >can rule out the v6only => v4 only communication. > >What do we say to operators who can't get enough > >v4 addreses? Deploy a v4 NAT as well as IPv6? > > Why not? How do we think that our attempts at v6->v4 > translation will be better than deploying an IPv4 NAT? => I don't understand how you could convice someone that IPv6 is needed because of the existing problems with IPv4 (lack of addresses, NATs ....etc) but tell them that they need NATs anyway to deploy v6. There is something broken in that logic. The difference between v4 NATs and NAT-PT is that, in time we will hopefully phase out NAT-PT or its use will be reduced significantly. You can't say the same thing about v4 NATs. I think a fresh operator would see an advantage in deploying v6 immediately and run a single network. I'm not sure about the strength of the logic demanding the deployment of v6 and v4 NATs at the same time. > > >I can understand that communication between a v4only > >host initiating a connection with a v6 only host > >is too difficult and probably should not be a priority. > > So, perhaps we are all in agreement on that. => I think so. Hesham From owner-v6ops@ops.ietf.org Mon Sep 23 17:18:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25437 for ; Mon, 23 Sep 2002 17:18:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tacn-000FqN-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 14:20:13 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17taci-000FpF-00; Mon, 23 Sep 2002 14:20:08 -0700 Received: from kenawang.windriver.com ([147.11.233.22]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA07805; Mon, 23 Sep 2002 14:19:06 -0700 (PDT) Message-Id: <5.1.0.14.2.20020923170111.02025070@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Sep 2002 17:19:31 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A1A@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Why not? How do we think that our attempts at v6->v4 > > translation will be better than deploying an IPv4 NAT? > >=> I don't understand how you could convice someone >that IPv6 is needed because of the existing problems with >IPv4 (lack of addresses, NATs ....etc) but tell them that >they need NATs anyway to deploy v6. And, you think this will read differently if the "NAT" has a "-PT" on the end? >There is something >broken in that logic. The difference between v4 NATs and >NAT-PT is that, in time we will hopefully phase out NAT-PT >or its use will be reduced significantly. You can't >say the same thing about v4 NATs. They phase out at the same time -- as soon as it isn't necessary for any host within the site to communicate with an IPv4-only host, the NAT(-PT) functionality won't be used any more and can be removed. There are actually some advantages to the IPv4 NAT approach: - IPv4 communication works inside and outside the site. - Leverages existing infrastructure/expertise in IPv4 networking. - Doesn't break anything that worked before you installed IPv6. The main disadvantages would seem to be: - Need to run dual-stack on all nodes that need to access IPv4-only nodes or services. - Need to assign IPv4 addresses (probably requires a DHCP server) I can see why those might be bigger issues for an all-new installation, but do you really think they are blocking issues? Would you agree that a current site that is using IPv4 behind a NAT should deploy IPv6 side-by-side with the current IPv4 NAT infrastructure? Margaret From owner-v6ops@ops.ietf.org Mon Sep 23 17:34:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25973 for ; Mon, 23 Sep 2002 17:34:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17taqf-000GJq-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 14:34:33 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17taqb-000GJc-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 14:34:30 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E60A918E3 for ; Mon, 23 Sep 2002 17:34:28 -0400 (EDT) Date: Mon, 23 Sep 2002 17:34:28 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-Reply-To: <5.1.0.14.2.20020923164424.0202d5e0@mail.windriver.com> References: <4DA6EA82906FD511BE2F00508BCF0538044F0A13@Esealnt861.al.sw.ericsson.se> <5.1.0.14.2.20020923164424.0202d5e0@mail.windriver.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020923213429.E60A918E3@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Mon, 23 Sep 2002 16:46:18 -0400, Margaret Wasserman wrote: > > >What do we say to operators who can't get enough > >v4 addreses? Deploy a v4 NAT as well as IPv6? > > Why not? How do we think that our attempts at v6->v4 > translation will be better than deploying an IPv4 NAT? Bingo. > >I can understand that communication between a v4only > >host initiating a connection with a v6 only host > >is too difficult and probably should not be a priority. > > So, perhaps we are all in agreement on that. I mostly agree. - I think it's not too hard to add magic translating routers (or whatever) that let IPv4-only boxes at an edge site speak a limited form of IPv6 as well (been there, done that, at the detail level it's no worse than IPv4 NAPT and in some ways it's not as bad). - The exactly parallel case of IPv6-only boxes at an edge site is not very hard either, but it's also not very interesting, since deploying small IPv6-only edge sites onto a dual-service network is not likely to be a particularly useful thing to do any time soon. - The interesting IPv6-only translation case is a big IPv6-only cloud, and that one -is- hard, because the translators don't scale well. - I think that we have enough important work to do that does not require translation that I think we should focus on the non-translation cases (see, I said I mostly agreed). From owner-v6ops@ops.ietf.org Mon Sep 23 17:34:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26004 for ; Mon, 23 Sep 2002 17:34:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tarL-000GLA-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 14:35:15 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tarH-000GKy-00; Mon, 23 Sep 2002 14:35:12 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8NLYdOW012911; Mon, 23 Sep 2002 23:34:39 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 23:34:38 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A1B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" Cc: "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 23:34:37 +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.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > Why not? How do we think that our attempts at v6->v4 > > > translation will be better than deploying an IPv4 NAT? > > > >=> I don't understand how you could convice someone > >that IPv6 is needed because of the existing problems with > >IPv4 (lack of addresses, NATs ....etc) but tell them that > >they need NATs anyway to deploy v6. > > And, you think this will read differently if the "NAT" has > a "-PT" on the end? => It will read and deploy differently :) > >There is something > >broken in that logic. The difference between v4 NATs and > >NAT-PT is that, in time we will hopefully phase out NAT-PT > >or its use will be reduced significantly. You can't > >say the same thing about v4 NATs. > > They phase out at the same time -- as soon as it isn't > necessary for any host within the site to communicate with > an IPv4-only host, the NAT(-PT) functionality won't be > used any more and can be removed. => They probably will but what is the driver for someone building a network to deply both ? I can't see anything getting simpler here. > > There are actually some advantages to the IPv4 NAT approach: > > - IPv4 communication works inside and outside the > site. > - Leverages existing infrastructure/expertise in > IPv4 networking. => I'm not addressing existing infrastructures, I was referring to a fresh operator. In our DT's scope (cellular) there will be a lot of those since the infrastructure is new. > The main disadvantages would seem to be: > > - Need to run dual-stack on all nodes that need to > access IPv4-only nodes or services. > - Need to assign IPv4 addresses (probably requires a > DHCP server) => Need to manage IPv4 multiple NATs as well. (I'm still talking in the context of our DT). > > I can see why those might be bigger issues for an all-new > installation, but do you really think they are blocking issues? => I don't know if they are blocking or not (an operator would need to answer that), but having to deploy IPv4 NATs certainly seems redundant and does not make anything simpler than deploying an IPv6 network with translators. > > Would you agree that a current site that is using IPv4 behind a > NAT should deploy IPv6 side-by-side with the current IPv4 NAT > infrastructure? => If they have it already, yes, I agree, but that was not my point. Even if they already have IPv4 infrastructure without NATs but forecast to need more IPv4 addresses in future, I don't see the need to force them to deploy v4 NATs. Hesham From owner-v6ops@ops.ietf.org Mon Sep 23 17:41:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26308 for ; Mon, 23 Sep 2002 17:41:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17taxn-000GY0-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 14:41:55 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17taxk-000GXo-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 14:41:52 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8NLfmOW013371; Mon, 23 Sep 2002 23:41:48 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 23:41:48 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A1D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rob Austein'" , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 23:41:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I mostly agree. > > - I think it's not too hard to add magic translating routers (or > whatever) that let IPv4-only boxes at an edge site speak a limited > form of IPv6 as well (been there, done that, at the detail level > it's no worse than IPv4 NAPT and in some ways it's not as bad). > > - The exactly parallel case of IPv6-only boxes at an edge > site is not > very hard either, but it's also not very interesting, since > deploying small IPv6-only edge sites onto a dual-service > network is > not likely to be a particularly useful thing to do any time soon. > > - The interesting IPv6-only translation case is a big > IPv6-only cloud, > and that one -is- hard, because the translators don't scale well. => Agreed. But why would they scale well for a large v4 cloud if v4 NATs are used? Hesham From owner-v6ops@ops.ietf.org Mon Sep 23 17:41:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26331 for ; Mon, 23 Sep 2002 17:41:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tazB-000Gcz-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 14:43:21 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17taz8-000Gcm-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 14:43:18 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 23 Sep 2002 14:43:18 -0700 Reply-To: From: "Tony Hain" To: "'Randy Bush'" , "'Bob Fink'" , "'Jun-ichiro itojun Hagino'" , "'Margaret Wasserman'" Cc: Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 14:43:11 -0700 Message-ID: <076a01c2634a$36ccdb00$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA26331 This was the primary reason I stressed that ngtrans needed to focus on the dual stack approach first. Even though that is a much simpler approach, there have been a variety of situations exposed over time to show that it simply not possible for everyone to take the easy road. The most obvious case at the moment is the substantial deployment of IPv4-only NAT CPE that for financial reasons *will not be upgraded* until the ISP is ready to provide native IPv6 support (in North America that is looking like ~2006, or in the case of docsis devices much later). For those end sites that want to move sooner, and don't have a reasonable option for an alternate ISP, just saying we only support dual stack is telling them they can't use IPv6 capable apps & appliances for at least 5 years. This will in turn put a damper on the app development community, because to get their app deployed in that timeframe they will have to figure out how to do nat traversal. Once they have gone down that path, where do they find additional incentive to put in IPv6 support? Yes the alternative tools add complexity, but in the grand scheme of things, is that complexity less than the mess we would end up with if everyone came up with their own nat traversal schemes? I think it is, and that we need more than dual stack. Also, as a meta point, declaring an approach for transition out of scope before the scenario documents are done is just a bit short sighted. Indeed there are a few ISPs deploying native service today, and these will simplify the global transition. To extrapolate from there that dual stack is all we need is really doing a disservice to the entire effort to make the transition as smooth as possible for the end site. Just as there is no single network design that works for all sites, there is no single transition approach that will work universally. Before deciding what problem doesn't need to be solved, why don't we get working group consensus on the problems that the design teams are trying to describe to see what they believe (due to first-hand experience or customer feedback) are the real problems existing networks will face as they try to move. Tony > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Randy Bush > Sent: Saturday, September 21, 2002 6:34 AM > To: Bob Fink; Jun-ichiro itojun Hagino; Margaret Wasserman > Cc: v6ops@ops.ietf.org > Subject: ocean: do not boil > > > first, thanks for doing a great job in sunnyvale. i think it > was worth the effort and pains. of course, time will tell, > as we see how the scenarios flesh out. > > but, i have been rather worried by one vector. > > i don't think we should try to solve the problem of an > arbitrary user/service on a pure v6 site/host trying to > communicate with a user/service on a pure v4 site/host or vice versa. > > dns is critical infrastructure, and we need to understand how > everyone will see the same namespace whether they are on v4 > or v6 transport [0]. and we have some clues on how to do > that, point mono-stack resolvers at dual-stack caching servers. > > but services such as http, smtp, blah, blah, blah just can't > be completely transparent, and we *vastly* increase the size > of the problem if we try to make them so. > > if i want my web site seen by both v4 and v6 users, then i > can connect it to v4 and v6 space and run dual stack. in > fact, i do so today. as v6 deploys, folk every useful site > will do so. > > if i want to send mail to v4 users and i live in a pure v6 > world, then i can make an arrangement with a dual-stack relay > to provide forwarding service to me. and to receive mail, i > can just point an MX naming an A record to a dual-stack > forwarding service. > > if i want to play a net.game which is in v6-land, then i need > to be at least partially in v6-land. no magic. tough patooties. > > trying to make pure v4 sites/hosts communicate for arbitrary > services with pure v6 sites/hosts and vice verse is a nice > way to make the problem vastly more complicated, the > solutions vastly more complex, and the net much less > reliable. let's not go there. > > randy > > --- > > [0] - if you're in private v6 space, i.e. site local or other > 1918-envy games, use multiple views just as a v4 1918 site > does today. > > From owner-v6ops@ops.ietf.org Mon Sep 23 17:51:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26547 for ; Mon, 23 Sep 2002 17:51:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tb7v-000GyZ-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 14:52:23 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tb7r-000GyH-00; Mon, 23 Sep 2002 14:52:20 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8NLpjOW013850; Mon, 23 Sep 2002 23:51:45 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 23 Sep 2002 23:51:45 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A1F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'alh-ietf@tndh.net'" , "'Randy Bush'" , "'Bob Fink'" , "'Jun-ichiro itojun Hagino'" , "'Margaret Wasserman'" Cc: v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 23:51:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I can't agree more. Hesham > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Monday, September 23, 2002 11:43 PM > To: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino'; 'Margaret > Wasserman' > Cc: v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > This was the primary reason I stressed that ngtrans needed > to focus on > the dual stack approach first. Even though that is a much simpler > approach, there have been a variety of situations exposed > over time to > show that it simply not possible for everyone to take the > easy road. The > most obvious case at the moment is the substantial deployment of > IPv4-only NAT CPE that for financial reasons *will not be upgraded* > until the ISP is ready to provide native IPv6 support (in > North America > that is looking like ~2006, or in the case of docsis devices much > later). For those end sites that want to move sooner, and > don't have a > reasonable option for an alternate ISP, just saying we only > support dual > stack is telling them they can't use IPv6 capable apps & > appliances for > at least 5 years. This will in turn put a damper on the app > development > community, because to get their app deployed in that > timeframe they will > have to figure out how to do nat traversal. Once they have gone down > that path, where do they find additional incentive to put in IPv6 > support? > > Yes the alternative tools add complexity, but in the grand scheme of > things, is that complexity less than the mess we would end > up with if > everyone came up with their own nat traversal schemes? I > think it is, > and that we need more than dual stack. > > Also, as a meta point, declaring an approach for transition > out of scope > before the scenario documents are done is just a bit short sighted. > Indeed there are a few ISPs deploying native service today, > and these > will simplify the global transition. To extrapolate from > there that dual > stack is all we need is really doing a disservice to the > entire effort > to make the transition as smooth as possible for the end > site. Just as > there is no single network design that works for all sites, > there is no > single transition approach that will work universally. > Before deciding > what problem doesn't need to be solved, why don't we get > working group > consensus on the problems that the design teams are trying > to describe > to see what they believe (due to first-hand experience or customer > feedback) are the real problems existing networks will face > as they try > to move. > > Tony > > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Randy Bush > > Sent: Saturday, September 21, 2002 6:34 AM > > To: Bob Fink; Jun-ichiro itojun Hagino; Margaret Wasserman > > Cc: v6ops@ops.ietf.org > > Subject: ocean: do not boil > > > > > > first, thanks for doing a great job in sunnyvale. i think it > > was worth the effort and pains. of course, time will tell, > > as we see how the scenarios flesh out. > > > > but, i have been rather worried by one vector. > > > > i don't think we should try to solve the problem of an > > arbitrary user/service on a pure v6 site/host trying to > > communicate with a user/service on a pure v4 site/host or > vice versa. > > > > dns is critical infrastructure, and we need to understand how > > everyone will see the same namespace whether they are on v4 > > or v6 transport [0]. and we have some clues on how to do > > that, point mono-stack resolvers at dual-stack caching servers. > > > > but services such as http, smtp, blah, blah, blah just can't > > be completely transparent, and we *vastly* increase the size > > of the problem if we try to make them so. > > > > if i want my web site seen by both v4 and v6 users, then i > > can connect it to v4 and v6 space and run dual stack. in > > fact, i do so today. as v6 deploys, folk every useful site > > will do so. > > > > if i want to send mail to v4 users and i live in a pure v6 > > world, then i can make an arrangement with a dual-stack relay > > to provide forwarding service to me. and to receive mail, i > > can just point an MX naming an A record to a dual-stack > > forwarding service. > > > > if i want to play a net.game which is in v6-land, then i need > > to be at least partially in v6-land. no magic. tough patooties. > > > > trying to make pure v4 sites/hosts communicate for arbitrary > > services with pure v6 sites/hosts and vice verse is a nice > > way to make the problem vastly more complicated, the > > solutions vastly more complex, and the net much less > > reliable. let's not go there. > > > > randy > > > > --- > > > > [0] - if you're in private v6 space, i.e. site local or other > > 1918-envy games, use multiple views just as a v4 1918 site > > does today. > > > > > > From owner-v6ops@ops.ietf.org Mon Sep 23 18:06:18 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27104 for ; Mon, 23 Sep 2002 18:06:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tbMv-000HVx-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 15:07:53 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17tbMs-000HVl-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 15:07:50 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 14C3118E2 for ; Mon, 23 Sep 2002 18:07:50 -0400 (EDT) Date: Mon, 23 Sep 2002 18:07:50 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A1D@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF0538044F0A1D@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020923220750.14C3118E2@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Mon, 23 Sep 2002 23:41:46 +0200, Hesham Soliman (EAB) wrote: > > But why would they scale well for a large v4 cloud if v4 NATs are > used? Hah, I knew someone would spot that. Because you don't use 'em for a large v4 cloud. You use 'em for a little v4 edge site behind some kind of combination NAPT/NAT-PT box and use some kind of v6-over-v4 tunneling over the rest of the v4 cloud. So you've got a lot of little translators converting to IPv6 as early as possible, which scales much better than big honking translators at the border between the cloud and the rest of the world. The same approach would "work" for large v6 clouds, but the result would not be useful, because it'd require so many IPv4 addresses that there'd be no point to the exercise. ["How do you climb down off an elephant? You don't. You climb down off a duck, because it's so much safer."] From owner-v6ops@ops.ietf.org Mon Sep 23 18:10:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27279 for ; Mon, 23 Sep 2002 18:10:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tbRJ-000HkJ-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 15:12:25 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17tbRG-000Hk6-00; Mon, 23 Sep 2002 15:12:22 -0700 Received: from kenawang.windriver.com ([147.11.233.22]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA22762; Mon, 23 Sep 2002 15:11:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20020923175825.02021470@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Sep 2002 18:12:30 -0400 To: From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "'Randy Bush'" , "'Bob Fink'" , "'Jun-ichiro itojun Hagino'" , In-Reply-To: <076a01c2634a$36ccdb00$011aa8c0@eagleswings> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tony, >The most obvious case at the moment is the substantial deployment of >IPv4-only NAT CPE that for financial reasons *will not be upgraded* >until the ISP is ready to provide native IPv6 support (in North America >that is looking like ~2006, or in the case of docsis devices much >later). For those end sites that want to move sooner, and don't have a >reasonable option for an alternate ISP, just saying we only support dual >stack is telling them they can't use IPv6 capable apps & appliances for >at least 5 years. I'm not sure how this follows from Randy's comments... If a node in the end site wants to access an IPv6-only service, the user would need to install IPv6 on that node (or buy a new appliance with IPv6 included, etc.). If the IPv6 infrastructure isn't present to route IPv6 natively, then they might use one of our several tunneling mechanisms to tunnel the packet over the IPv4 infrastructure to an IPv6 network. >Also, as a meta point, declaring an approach for transition out of scope >before the scenario documents are done is just a bit short sighted. I actually think that we were discussing some prioritization of the scenarios, not declaring any of the solutions in or out of scope. Once we have a full set of scenarios, I think it will make sense to try to trim down the set of scenarios, based on what we think is most likely to occur. Margaret From owner-v6ops@ops.ietf.org Mon Sep 23 18:25:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27798 for ; Mon, 23 Sep 2002 18:25:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tbfq-000IO4-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 15:27:26 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tbfl-000INk-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 15:27:21 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8NMRFKV007375; Tue, 24 Sep 2002 00:27:15 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 00:27:15 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A23@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rob Austein'" , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 00:27:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Hah, I knew someone would spot that. > > Because you don't use 'em for a large v4 cloud. You use 'em for a > little v4 edge site behind some kind of combination NAPT/NAT-PT box > and use some kind of v6-over-v4 tunneling over the rest of the v4 > cloud. So you've got a lot of little translators converting to IPv6 > as early as possible, which scales much better than big honking > translators at the border between the cloud and the rest of > the world. => ok, I thought you eliminated NA(P)T-PTs but I obviously misunderstood that. There were several discussions in our DT meeting in Sunnyvale to make NAT-PT scale in a similar manner by having "translator clusters". Essentially, it all boils down to removing the DNS ALG from NAT-PT and different ways were proposed. I think we can make it scale with very little effort actually. > The same approach would "work" for large v6 clouds, but the result > would not be useful, because it'd require so many IPv4 > addresses that > there'd be no point to the exercise. => Wouldn't it require the same number of addresses? Eventually you are translating from a private (be it v6 or 1918 addresses) space to public one. The public space would need public v4 addresses. So I'm not sure why you would run out of addresses in one case but not the other. Hesham From owner-v6ops@ops.ietf.org Mon Sep 23 19:18:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29021 for ; Mon, 23 Sep 2002 19:18:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tcTy-000KLv-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 16:19:14 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17tcTv-000KLj-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 16:19:11 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E8F8918E3 for ; Mon, 23 Sep 2002 19:19:10 -0400 (EDT) Date: Mon, 23 Sep 2002 19:19:10 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A23@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF0538044F0A23@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020923231911.E8F8918E3@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Tue, 24 Sep 2002 00:27:15 +0200, Hesham Soliman (EAB) wrote: > >> The same approach would "work" for large v6 clouds, but the result >> would not be useful, because it'd require so many IPv4 addresses >> that there'd be no point to the exercise. > > Wouldn't it require the same number of addresses? Eventually you > are translating from a private (be it v6 or 1918 addresses) space to > public one. The public space would need public v4 addresses. So I'm > not sure why you would run out of addresses in one case but not the > other. In the case where you're adding IPv6 to an existing IPv4 edge site, you already have IPv4 addreses for the IPv4 site. They may be screwed up shared RFC 1918 IPv4 addresess, but they're already there, you don't need to do anything new with them, and adding IPv6 addresses on top of that is easy because IPv6 addresses are plentiful. In the reverse case (the one discussed in the text quoted above) you have IPv6 addressses already but don't yet have IPv4 addresses. Of course you can get IPv4 addresses, but when you've done that much of the argument for having a v6-only cloud in the first place is gone. BTW, I was -really- impressed by the model underlying Miyakawa-san's explanation of how NTT/Verio is combining stable IPv6 /48 allocations with very small numbers of dynamic IPv4 address. Their approach requires no translation, drops very neatly into a number of existing configurations, and carefully avoids any change to the status quo for IPv4, so it doesn't violate the Principal of Least Astonishment. Yay! From owner-v6ops@ops.ietf.org Mon Sep 23 21:16:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01982 for ; Mon, 23 Sep 2002 21:16:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17teK2-000PKb-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 18:17:06 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17teJz-000PKK-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 18:17:03 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 23 Sep 2002 18:17:02 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: "'Randy Bush'" , "'Bob Fink'" , "'Jun-ichiro itojun Hagino'" , Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 18:16:53 -0700 Message-ID: <078401c26368$13609300$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5.1.0.14.2.20020923175825.02021470@mail.windriver.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA01982 Margaret Wasserman wrote: > Hi Tony, > > >The most obvious case at the moment is the substantial deployment of > >IPv4-only NAT CPE that for financial reasons *will not be upgraded* > >until the ISP is ready to provide native IPv6 support (in > North America > >that is looking like ~2006, or in the case of docsis devices much > >later). For those end sites that want to move sooner, and > don't have a > >reasonable option for an alternate ISP, just saying we only support > >dual stack is telling them they can't use IPv6 capable apps & > >appliances for at least 5 years. > > I'm not sure how this follows from Randy's comments... >> if i want my web site seen by both v4 and v6 users, then i can connect >> it to v4 and v6 space and run dual stack. in fact, i do so today. >> as v6 deploys, folk every useful site will do so. Asserts that if a content site wants to be seen as IPv6 that it is in control and can just advertise that and all IPv6-only nodes will be able to reach it. The reality is that a consumer behind an IPv4-only NAT CPE will need some form of IPv6-over-foo to get past the CPE. The hidden and invalid assumption in Randy's comment is that the IPv6 network is contiguous. > > If a node in the end site wants to access an IPv6-only > service, the user would need to install IPv6 on that node (or > buy a new appliance with IPv6 included, etc.). If the IPv6 > infrastructure isn't present to route IPv6 natively, then > they might use one of our several tunneling mechanisms to > tunnel the packet over the IPv4 infrastructure to an IPv6 network. This is specifically what Randy's note was asserting, that we don't need the complexity that the mechanisms bring to the table. > > >Also, as a meta point, declaring an approach for transition out of > >scope before the scenario documents are done is just a bit short > >sighted. > > I actually think that we were discussing some prioritization > of the scenarios, not declaring any of the solutions in or > out of scope. >> trying to make pure v4 sites/hosts communicate for arbitrary services with pure >> v6 sites/hosts and vice verse is a nice way to make the problem vastly more >> complicated, the solutions vastly more complex, and the net much less reliable. >> let's not go there. Sounds like precluding a class of transition scenarios to me. > > Once we have a full set of scenarios, I think it will make > sense to try to trim down the set of scenarios, based on what > we think is most likely to occur. > This is absolutely silly. The whole exercise is designed to refocus on the scenarios that are actively being deployed, or currently on the drawing board for deployment. Claiming that we can out guess the market acceptance of those and whittle that down further presumes access to a crystal ball I haven't seen yet. Prioritizing based on relative broad applicability would make sense if there were limited resources, but we seem to have plenty of interested participants. Developing them in parallel doesn't appear to be a problem, so why artificially restrict the working set? Tony > Margaret > > From owner-v6ops@ops.ietf.org Mon Sep 23 22:55:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05114 for ; Mon, 23 Sep 2002 22:55:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tfrG-0003et-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 19:55:30 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17tfrD-0003ei-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 19:55:27 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6A1274B22; Tue, 24 Sep 2002 11:55:23 +0900 (JST) To: alh-ietf@tndh.net Cc: v6ops@ops.ietf.org In-reply-to: alh-ietf's message of Mon, 23 Sep 2002 18:16:53 MST. <078401c26368$13609300$011aa8c0@eagleswings> 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: ocean: do not boil From: itojun@iijlab.net Date: Tue, 24 Sep 2002 11:55:23 +0900 Message-Id: <20020924025525.6A1274B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Asserts that if a content site wants to be seen as IPv6 that it is in >control and can just advertise that and all IPv6-only nodes will be able >to reach it. The reality is that a consumer behind an IPv4-only NAT CPE >will need some form of IPv6-over-foo to get past the CPE. The hidden and >invalid assumption in Randy's comment is that the IPv6 network is >contiguous. so we need to get small (< $200) router vendors to do IPv6. upstream can be IPv6 over PPPoE (if upstream ISP supports it), or 6to4. if these small router vendors are using IP code from Linux, BSD or VxWorks, it's no-brainer, code is already there - more problem reside in education (for support call desks). if we've done that, we can simplify it very much - no need for NAT penetration like Teredo. itojun From owner-v6ops@ops.ietf.org Mon Sep 23 22:56:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05138 for ; Mon, 23 Sep 2002 22:56:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tfta-0003kV-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 19:57:54 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17tftX-0003kJ-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 19:57:51 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D81B24B23; Tue, 24 Sep 2002 11:57:49 +0900 (JST) To: "Hesham Soliman (EAB)" Cc: v6ops@ops.ietf.org In-reply-to: hesham.soliman's message of Tue, 24 Sep 2002 00:27:15 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0A23@Esealnt861.al.sw.ericsson.se> 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: ocean: do not boil From: itojun@iijlab.net Date: Tue, 24 Sep 2002 11:57:49 +0900 Message-Id: <20020924025749.D81B24B23@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > The same approach would "work" for large v6 clouds, but the result > > would not be useful, because it'd require so many IPv4 > > addresses that > > there'd be no point to the exercise. >=> Wouldn't it require the same number of addresses? >Eventually you are translating from a private (be it >v6 or 1918 addresses) space to public one. The public >space would need public v4 addresses. So I'm not sure >why you would run out of addresses in one case but not >the other. you can run IPv4 with NAT, and IPv6 globally-routable, on the same cloud. we don't need to fix IPv4 problem people are having - and better, IPv6 will be able to provide a better applications experience than IPv4 with NAT. itojun From owner-v6ops@ops.ietf.org Tue Sep 24 00:45:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07295 for ; Tue, 24 Sep 2002 00:45:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tha8-0008dx-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 21:45:56 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17tha5-0008dm-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 21:45:53 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8A7CD18A2 for ; Tue, 24 Sep 2002 00:45:52 -0400 (EDT) Date: Tue, 24 Sep 2002 00:45:52 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: References: <20020923134214.92AF74B22@coconut.itojun.org> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020924044552.8A7CD18A2@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Mon, 23 Sep 2002 16:10:22 +0200 (CEST), Erik Nordmark wrote: > > Stated differently, if you apply IPv4 ingress filtering in the network > and IPv6 ingress filtering in the IPv6-native parts of the network, the > use of encapsulation doesn't create additional holes in your filtering. This is the key point. While it's somewhat tedious to set up, a 6to4 router can use the usual topological defenses to keep from letting any bad stuff through. A 6to4 relay (or a terado relay or an xyz relay) has a much harder task, because the network topology doesn't tell it much of anything that it can use as a basis for filtering out the bogons. From owner-v6ops@ops.ietf.org Tue Sep 24 01:08:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07627 for ; Tue, 24 Sep 2002 01:08:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17thwC-0009jr-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 22:08:44 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17thw8-0009jc-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 22:08:40 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BE15E65A6; Tue, 24 Sep 2002 01:08:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 24 Sep 2002 01:08:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 01:08:39 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE935F@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJjS7tXnIhAQE7gTGWPYy3FdBZdegAPK3uA From: "Bound, Jim" To: "Hesham Soliman (EAB)" , , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 24 Sep 2002 05:08:39.0661 (UTC) FILETIME=[71DA01D0:01C26388] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA07627 I agree with Tony too. /jim > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: Monday, September 23, 2002 5:52 PM > To: 'alh-ietf@tndh.net'; 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun > Hagino'; 'Margaret Wasserman' > Cc: v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > I can't agree more. > > Hesham > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Monday, September 23, 2002 11:43 PM > > To: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino'; > 'Margaret > > Wasserman' > > Cc: v6ops@ops.ietf.org > > Subject: RE: ocean: do not boil > > > > > > This was the primary reason I stressed that ngtrans needed > > to focus on > > the dual stack approach first. Even though that is a much simpler > > approach, there have been a variety of situations exposed > > over time to > > show that it simply not possible for everyone to take the > > easy road. The > > most obvious case at the moment is the substantial deployment of > > IPv4-only NAT CPE that for financial reasons *will not be > upgraded* > > until the ISP is ready to provide native IPv6 support (in > > North America > > that is looking like ~2006, or in the case of docsis devices much > > later). For those end sites that want to move sooner, and > > don't have a > > reasonable option for an alternate ISP, just saying we only > > support dual > > stack is telling them they can't use IPv6 capable apps & > > appliances for > > at least 5 years. This will in turn put a damper on the app > > development > > community, because to get their app deployed in that > > timeframe they will > > have to figure out how to do nat traversal. Once they > have gone down > > that path, where do they find additional incentive to put in IPv6 > > support? > > > > Yes the alternative tools add complexity, but in the > grand scheme of > > things, is that complexity less than the mess we would end > > up with if > > everyone came up with their own nat traversal schemes? I > > think it is, > > and that we need more than dual stack. > > > > Also, as a meta point, declaring an approach for transition > > out of scope > > before the scenario documents are done is just a bit > short sighted. > > Indeed there are a few ISPs deploying native service today, > > and these > > will simplify the global transition. To extrapolate from > > there that dual > > stack is all we need is really doing a disservice to the > > entire effort > > to make the transition as smooth as possible for the end > > site. Just as > > there is no single network design that works for all sites, > > there is no > > single transition approach that will work universally. > > Before deciding > > what problem doesn't need to be solved, why don't we get > > working group > > consensus on the problems that the design teams are trying > > to describe > > to see what they believe (due to first-hand experience or customer > > feedback) are the real problems existing networks will face > > as they try > > to move. > > > > Tony > > > > > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Randy Bush > > > Sent: Saturday, September 21, 2002 6:34 AM > > > To: Bob Fink; Jun-ichiro itojun Hagino; Margaret Wasserman > > > Cc: v6ops@ops.ietf.org > > > Subject: ocean: do not boil > > > > > > > > > first, thanks for doing a great job in sunnyvale. i think it > > > was worth the effort and pains. of course, time will tell, > > > as we see how the scenarios flesh out. > > > > > > but, i have been rather worried by one vector. > > > > > > i don't think we should try to solve the problem of an > > > arbitrary user/service on a pure v6 site/host trying to > > > communicate with a user/service on a pure v4 site/host or > > vice versa. > > > > > > dns is critical infrastructure, and we need to understand how > > > everyone will see the same namespace whether they are on v4 > > > or v6 transport [0]. and we have some clues on how to do > > > that, point mono-stack resolvers at dual-stack caching servers. > > > > > > but services such as http, smtp, blah, blah, blah just can't > > > be completely transparent, and we *vastly* increase the size > > > of the problem if we try to make them so. > > > > > > if i want my web site seen by both v4 and v6 users, then i > > > can connect it to v4 and v6 space and run dual stack. in > > > fact, i do so today. as v6 deploys, folk every useful site > > > will do so. > > > > > > if i want to send mail to v4 users and i live in a pure v6 > > > world, then i can make an arrangement with a dual-stack relay > > > to provide forwarding service to me. and to receive mail, i > > > can just point an MX naming an A record to a dual-stack > > > forwarding service. > > > > > > if i want to play a net.game which is in v6-land, then i need > > > to be at least partially in v6-land. no magic. tough > patooties. > > > > > > trying to make pure v4 sites/hosts communicate for arbitrary > > > services with pure v6 sites/hosts and vice verse is a nice > > > way to make the problem vastly more complicated, the > > > solutions vastly more complex, and the net much less > > > reliable. let's not go there. > > > > > > randy > > > > > > --- > > > > > > [0] - if you're in private v6 space, i.e. site local or other > > > 1918-envy games, use multiple views just as a v4 1918 site > > > does today. > > > > > > > > > > > > From owner-v6ops@ops.ietf.org Tue Sep 24 01:08:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07645 for ; Tue, 24 Sep 2002 01:08:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17thxn-0009qh-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 22:10:23 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17thxk-0009qN-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 22:10:20 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id ADE685A35; Tue, 24 Sep 2002 01:10:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 24 Sep 2002 01:10:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 01:10:19 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9360@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJjTnUN4VJazL1wQCGQHDtj6RBCkQAOijXQ From: "Bound, Jim" To: "Margaret Wasserman" , Cc: "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 24 Sep 2002 05:10:19.0648 (UTC) FILETIME=[AD72D000:01C26388] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA07645 Margaret, You keep saying trim down the scenarios. That could be the last thing we want. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, September 23, 2002 6:13 PM > To: alh-ietf@tndh.net > Cc: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino'; > v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > > Hi Tony, > > >The most obvious case at the moment is the substantial deployment of > >IPv4-only NAT CPE that for financial reasons *will not be upgraded* > >until the ISP is ready to provide native IPv6 support (in > North America > >that is looking like ~2006, or in the case of docsis devices much > >later). For those end sites that want to move sooner, and > don't have a > >reasonable option for an alternate ISP, just saying we only > support dual > >stack is telling them they can't use IPv6 capable apps & > appliances for > >at least 5 years. > > I'm not sure how this follows from Randy's comments... > > If a node in the end site wants to access an IPv6-only > service, the user > would need to install IPv6 on that node (or buy a new appliance with > IPv6 included, etc.). If the IPv6 infrastructure isn't > present to route > IPv6 natively, then they might use one of our several > tunneling mechanisms > to tunnel the packet over the IPv4 infrastructure to an IPv6 network. > > >Also, as a meta point, declaring an approach for transition > out of scope > >before the scenario documents are done is just a bit short sighted. > > I actually think that we were discussing some prioritization of the > scenarios, not declaring any of the solutions in or out of scope. > > Once we have a full set of scenarios, I think it will make sense to > try to trim down the set of scenarios, based on what we think is most > likely to occur. > > Margaret > > > > From owner-v6ops@ops.ietf.org Tue Sep 24 01:10:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07682 for ; Tue, 24 Sep 2002 01:10:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17thzW-0009uR-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 22:12:10 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17thzS-0009uD-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 22:12:06 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id EB99A4153; Tue, 24 Sep 2002 01:12:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 24 Sep 2002 01:12:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 01:12:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9361@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJjaHGfsJfbm0dbRKazga6IGbBhZQAIHCjQ From: "Bound, Jim" To: , "Margaret Wasserman" Cc: "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 24 Sep 2002 05:12:05.0833 (UTC) FILETIME=[ECBD5B90:01C26388] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA07682 yes why artificially limit the working set? /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Monday, September 23, 2002 9:17 PM > To: 'Margaret Wasserman' > Cc: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino'; > v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > Margaret Wasserman wrote: > > Hi Tony, > > > > >The most obvious case at the moment is the substantial > deployment of > > >IPv4-only NAT CPE that for financial reasons *will not be > upgraded* > > >until the ISP is ready to provide native IPv6 support (in > > North America > > >that is looking like ~2006, or in the case of docsis devices much > > >later). For those end sites that want to move sooner, and > > don't have a > > >reasonable option for an alternate ISP, just saying we > only support > > >dual stack is telling them they can't use IPv6 capable apps & > > >appliances for at least 5 years. > > > > I'm not sure how this follows from Randy's comments... > > >> if i want my web site seen by both v4 and v6 users, then i can > connect > >> it to v4 and v6 space and run dual stack. in fact, i do > so today. > >> as v6 deploys, folk every useful site will do so. > > Asserts that if a content site wants to be seen as IPv6 that it is in > control and can just advertise that and all IPv6-only nodes > will be able > to reach it. The reality is that a consumer behind an > IPv4-only NAT CPE > will need some form of IPv6-over-foo to get past the CPE. The > hidden and > invalid assumption in Randy's comment is that the IPv6 network is > contiguous. > > > > > > If a node in the end site wants to access an IPv6-only > > service, the user would need to install IPv6 on that node (or > > buy a new appliance with IPv6 included, etc.). If the IPv6 > > infrastructure isn't present to route IPv6 natively, then > > they might use one of our several tunneling mechanisms to > > tunnel the packet over the IPv4 infrastructure to an IPv6 network. > > This is specifically what Randy's note was asserting, that we > don't need > the complexity that the mechanisms bring to the table. > > > > > >Also, as a meta point, declaring an approach for transition out of > > >scope before the scenario documents are done is just a bit short > > >sighted. > > > > I actually think that we were discussing some prioritization > > of the scenarios, not declaring any of the solutions in or > > out of scope. > > >> trying to make pure v4 sites/hosts communicate for > arbitrary services > with pure > >> v6 sites/hosts and vice verse is a nice way to make the problem > vastly more > >> complicated, the solutions vastly more complex, and the > net much less > reliable. > >> let's not go there. > > Sounds like precluding a class of transition scenarios to me. > > > > > Once we have a full set of scenarios, I think it will make > > sense to try to trim down the set of scenarios, based on what > > we think is most likely to occur. > > > > This is absolutely silly. The whole exercise is designed to refocus on > the scenarios that are actively being deployed, or currently on the > drawing board for deployment. Claiming that we can out guess > the market > acceptance of those and whittle that down further presumes access to a > crystal ball I haven't seen yet. Prioritizing based on relative broad > applicability would make sense if there were limited resources, but we > seem to have plenty of interested participants. Developing them in > parallel doesn't appear to be a problem, so why artificially restrict > the working set? > > Tony > > > > Margaret > > > > > > > From owner-v6ops@ops.ietf.org Tue Sep 24 01:14:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07768 for ; Tue, 24 Sep 2002 01:14:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ti2C-000A3L-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 22:14:56 -0700 Received: from [202.28.97.9] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17ti1g-000A0M-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 22:14:25 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8O5Dq324605; Tue, 24 Sep 2002 12:13:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8O5Cm723766; Tue, 24 Sep 2002 12:12:51 +0700 (ICT) From: Robert Elz To: Keith Moore cc: itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: <200209231826.g8NIQ5023859@astro.cs.utk.edu> References: <200209231826.g8NIQ5023859@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Sep 2002 12:12:48 +0700 Message-ID: <23764.1032844368@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Mon, 23 Sep 2002 14:26:05 -0400 From: Keith Moore Message-ID: <200209231826.g8NIQ5023859@astro.cs.utk.edu> | communicating between 6to4 and native v6 is of course useful also, | but it's not the only reason that people will use (are using!) 6to4. I didn't say anything about native IPv6. What I said was "the rest of the v6 universe". That includes native v6 (or course), other people using 6to4, and others who get their IPv6 addresses & connectivity from any other random source (including the 6bone). The point was that 6to4 to 6to4 only as a restriction wouldn't work. kre From owner-v6ops@ops.ietf.org Tue Sep 24 01:22:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07935 for ; Tue, 24 Sep 2002 01:22:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tiAE-000AUh-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 22:23:14 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17tiAA-000ATi-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 22:23:10 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 23 Sep 2002 22:23:11 -0700 Reply-To: From: "Tony Hain" To: Cc: Subject: RE: ocean: do not boil Date: Mon, 23 Sep 2002 22:23:02 -0700 Message-ID: <078801c2638a$74a48190$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <20020924025525.6A1274B22@coconut.itojun.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun wrote: > ... > so we need to get small (< $200) router vendors to do > IPv6. upstream > can be IPv6 over PPPoE (if upstream ISP supports it), or 6to4. > if these small router vendors are using IP code from > Linux, BSD or VxWorks, > it's no-brainer, code is already there - more problem > reside in education > (for support call desks). if we've done that, we can > simplify it very much - > no need for NAT penetration like Teredo. Just because a new device exists, doesn't mean that the service providers will deploy it. Unlike the past few years, there will need to be a strong motivation to replace CPE gear that is not completely amortized yet. If you want to have an impact, put effort into getting a docsis spec for IPv6 in place. Without that, it won't matter if the consumer puts in a $100 router because it will still have an IPv4-only device in its path. Tony From owner-v6ops@ops.ietf.org Tue Sep 24 01:31:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08164 for ; Tue, 24 Sep 2002 01:31:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tiJD-000Azj-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 22:32:31 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17tiJ4-000AzW-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 22:32:22 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8O5Pu027353; Tue, 24 Sep 2002 01:25:56 -0400 (EDT) Message-Id: <200209240525.g8O5Pu027353@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Tue, 24 Sep 2002 12:12:48 +0700.") <23764.1032844368@munnari.OZ.AU> Date: Tue, 24 Sep 2002 01:25:56 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The point was that 6to4 to 6to4 only as a restriction wouldn't work. agree entirely. Keith From owner-v6ops@ops.ietf.org Tue Sep 24 02:09:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17920 for ; Tue, 24 Sep 2002 02:09:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tiso-000Clg-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 23:09:18 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17tisk-000ClU-00; Mon, 23 Sep 2002 23:09:15 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8O699C20552; Tue, 24 Sep 2002 09:09:09 +0300 Date: Tue, 24 Sep 2002 09:09:08 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: "'Randy Bush'" , "'Bob Fink'" , "'Jun-ichiro itojun Hagino'" , "'Margaret Wasserman'" , Subject: RE: ocean: do not boil In-Reply-To: <076a01c2634a$36ccdb00$011aa8c0@eagleswings> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 23 Sep 2002, Tony Hain wrote: [...] > show that it simply not possible for everyone to take the easy road. The > most obvious case at the moment is the substantial deployment of > IPv4-only NAT CPE that for financial reasons *will not be upgraded* [...] In the case of xDSL, using bridged ATM encapsulation is enough, you don't need to worry about IPv4-only properties of CPE. [...] > For those end sites that want to move sooner, and don't have a > reasonable option for an alternate ISP, just saying we only support dual > stack is telling them they can't use IPv6 capable apps & appliances for > at least 5 years. I don't think anyone has suggested that we don't try to find some solutions which enable these users, too, to get IPv6 connectivity. [...] > Also, as a meta point, declaring an approach for transition out of scope > before the scenario documents are done is just a bit short sighted. > Indeed there are a few ISPs deploying native service today, and these > will simplify the global transition. To extrapolate from there that dual > stack is all we need is really doing a disservice to the entire effort > to make the transition as smooth as possible for the end site. Just as > there is no single network design that works for all sites, there is no > single transition approach that will work universally. Before deciding > what problem doesn't need to be solved, why don't we get working group > consensus on the problems that the design teams are trying to describe > to see what they believe (due to first-hand experience or customer > feedback) are the real problems existing networks will face as they try > to move. It seems some design teams move faster than others: unmanaged networks team IMO was already working on solutions. At this point, until we know the problem space better, I think it's best to assume "don't try to solve every possible problem unless shown otherwise" -stance. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 24 02:37:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18333 for ; Tue, 24 Sep 2002 02:37:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tjKD-000EHw-00 for v6ops-data@psg.com; Mon, 23 Sep 2002 23:37:37 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17tjK9-000EHk-00 for v6ops@ops.ietf.org; Mon, 23 Sep 2002 23:37:33 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8O6aTo20781; Tue, 24 Sep 2002 09:36:29 +0300 Date: Tue, 24 Sep 2002 09:36:29 +0300 (EEST) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: quality of v6 connections [Re: unmanaged scope comments] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'll revisit this due to a private comment. Perhaps I should clarify this a bit. Your take seems to be "how do we solve this problem given the network and v6 connectivity we have". Mine is basically "we have a problem with network connectivity and v6 and with the current state, turning v6 on for everything will produce dissatisfied users". With "network connectivity" I'm referring to the 6bone mess. People usually just say, "enable IPv6" but it's more complex that. As an user that actually uses IPv6 quite a bit, I'd be very hesitant to enable full use in a generic form. I'm not sure whether trying to solve this is in our charter or not (or even if it was, would we be able to do anything), but that's one real problem. 6bone mess is hindering IPv6 deployment. FWIW, I think 6bone addresses etc. are useful to get people started and acquainted with IPv6. But tunnel-to-everyone, transit-to-everyone mess is not. Those 6bone sites should be connected as leaf sites to proper connectivity providers. On Thu, 19 Sep 2002, Pekka Savola wrote: > On Fri, 20 Sep 2002, Jun-ichiro itojun Hagino wrote: > > >==> connectivity includes one very important component IMO: the quality of > > >network connections. This is often ignored. It's a high risk for a vendor > > >to enable IPv6 by default, for example, if that'd result in lower quality > > >connections to e.g. dual-stack web servers (a very real fact in 6bone), this > > >should be taken into consideration at least in the short term. > > > > i don't understand what you want to do about it. will you ping/ping6 > > destination and pick shorter roundtrip? when multiple A records > > are returned for www.foo.com, do you probe them to get the optimal > > performance? > > That's a difficult, general question to consider. It's not easy. I've > said one very real possibility to *not* introduce production services in > the same DNS names yet.. > > > i believe the "quality" factor does not matter, and > > it cannot be measured from endpoint (at least within short time). > > Connection to U.S. from Europe being 400 ms (and a few packets getting > lost here and there) versus 150 ms is very measurable even without any > tools e.g. in web browsing. > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 24 03:00:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18600 for ; Tue, 24 Sep 2002 03:00:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tjgc-000FSb-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 00:00:46 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17tjgY-000FSQ-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 00:00:43 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3674C4B22; Tue, 24 Sep 2002 16:00:41 +0900 (JST) To: alh-ietf@tndh.net Cc: v6ops@ops.ietf.org In-reply-to: alh-ietf's message of Mon, 23 Sep 2002 22:23:02 MST. <078801c2638a$74a48190$011aa8c0@eagleswings> 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: ocean: do not boil From: itojun@iijlab.net Date: Tue, 24 Sep 2002 16:00:41 +0900 Message-Id: <20020924070041.3674C4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Just because a new device exists, doesn't mean that the service >providers will deploy it. Unlike the past few years, there will need to >be a strong motivation to replace CPE gear that is not completely >amortized yet. If you want to have an impact, put effort into getting a >docsis spec for IPv6 in place. Without that, it won't matter if the >consumer puts in a $100 router because it will still have an IPv4-only >device in its path. who in this group participates to docsis group? what is the relationship between IETF and docsis group? (are there any kind of relationship like IETF-3GPP?) if there's anything i/we can do, i think we should do that. itojun From owner-v6ops@ops.ietf.org Tue Sep 24 05:46:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21066 for ; Tue, 24 Sep 2002 05:46:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tmGy-000NSO-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 02:46:28 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17tmGv-000NSA-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 02:46:25 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tmGt-0007LU-00; Tue, 24 Sep 2002 10:46:23 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tmGt-0007LP-00; Tue, 24 Sep 2002 10:46:23 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA34366; Tue, 24 Sep 2002 10:46:20 +0100 Message-ID: <3D903474.AFF0643D@hursley.ibm.com> Date: Tue, 24 Sep 2002 11:46:28 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: itojun@iijlab.net CC: alh-ietf@tndh.net, v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: <20020924025525.6A1274B22@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: > > >Asserts that if a content site wants to be seen as IPv6 that it is in > >control and can just advertise that and all IPv6-only nodes will be able > >to reach it. The reality is that a consumer behind an IPv4-only NAT CPE > >will need some form of IPv6-over-foo to get past the CPE. The hidden and > >invalid assumption in Randy's comment is that the IPv6 network is > >contiguous. > > so we need to get small (< $200) router vendors to do IPv6. upstream > can be IPv6 over PPPoE (if upstream ISP supports it), or 6to4. > if these small router vendors are using IP code from Linux, BSD or VxWorks, > it's no-brainer, code is already there - more problem reside in education > (for support call desks). if we've done that, we can simplify it very much - > no need for NAT penetration like Teredo. Indeed. This was the thinking behind 6to4 all along. But we do need the $200 devices to enable it by default. Brian From owner-v6ops@ops.ietf.org Tue Sep 24 05:47:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21099 for ; Tue, 24 Sep 2002 05:47:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tmJV-000NXd-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 02:49:05 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17tmJP-000NXC-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 02:49:00 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tmJP-0007Mn-00; Tue, 24 Sep 2002 10:48:59 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tmJO-0007Mi-00; Tue, 24 Sep 2002 10:48:58 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA16556; Tue, 24 Sep 2002 10:48:57 +0100 Message-ID: <3D90350F.4D4444CB@hursley.ibm.com> Date: Tue, 24 Sep 2002 11:49:03 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: alh-ietf@tndh.net CC: itojun@iijlab.net, v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: <078801c2638a$74a48190$011aa8c0@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: > > itojun wrote: > > ... > > so we need to get small (< $200) router vendors to do > > IPv6. upstream > > can be IPv6 over PPPoE (if upstream ISP supports it), or 6to4. > > if these small router vendors are using IP code from > > Linux, BSD or VxWorks, > > it's no-brainer, code is already there - more problem > > reside in education > > (for support call desks). if we've done that, we can > > simplify it very much - > > no need for NAT penetration like Teredo. > > Just because a new device exists, doesn't mean that the service > providers will deploy it. Unlike the past few years, there will need to > be a strong motivation to replace CPE gear that is not completely > amortized yet. If you want to have an impact, put effort into getting a > docsis spec for IPv6 in place. Without that, it won't matter if the > consumer puts in a $100 router because it will still have an IPv4-only > device in its path. Why we standardised tunnels and 6to4. But they do have to allow type 41. Brian From owner-v6ops@ops.ietf.org Tue Sep 24 05:50:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21169 for ; Tue, 24 Sep 2002 05:50:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tmMW-000NmU-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 02:52:12 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17tmMP-000Nly-00; Tue, 24 Sep 2002 02:52:06 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tmMN-0007Pl-00; Tue, 24 Sep 2002 10:52:03 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tmMN-0007Pg-00; Tue, 24 Sep 2002 10:52:03 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id KAA34470; Tue, 24 Sep 2002 10:51:59 +0100 Message-ID: <3D9035B2.2878CD59@hursley.ibm.com> Date: Tue, 24 Sep 2002 11:51:46 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: <4DA6EA82906FD511BE2F00508BCF0538044F0A18@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit p2p applications can be designed to use intermediaries, just like SMTP and HTTP. If I was designing an apps protocol today, I would definitely make sure it could be relayed between address spaces at applications level. Brian "Hesham Soliman (EAB)" wrote: > > I should clarify that my comment was > in the context of new applications (other than > HTTP and email, i.e. p2p). > > Hesham > > > -----Original Message----- > > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Monday, September 23, 2002 9:43 PM > > To: 'Bob Hinden'; Margaret Wasserman > > Cc: Randy Bush; Bob Fink; Jun-ichiro itojun Hagino; > > v6ops@ops.ietf.org > > Subject: RE: ocean: do not boil > > > > > > > > > >>i don't think we should try to solve the problem of > > an arbitrary > > > >>user/service on a pure v6 site/host trying to > > communicate with a > > > >>user/service on a pure v4 site/host or vice versa. > > > > > > > >I agree with this. > > > > > > I don't agree with one case of this. I think there is a > > > need to have IPv6 > > > only hosts that are able to reach the same IPv4 services > > > that an IPv4 host > > > behind a NAT today can reach. This will make IPv6 only > > > hosts much more > > > attractive than if they can only reach IPv6 services. This > > > will make IPv6 > > > only a real possibility for new deployments of new types of > > > devices. If we > > > don't support this case, then these devices (and resulting > > > infrastructure) > > > will have to be dual stack. > > > > => I completely agree with Bob. I don't understand how we > > can rule out the v6only => v4 only communication. > > What do we say to operators who can't get enough > > v4 addreses? Deploy a v4 NAT as well as IPv6? > > > > I can understand that communication between a v4only > > host initiating a connection with a v6 only host > > is too difficult and probably should not be a priority. > > > > Hesham From owner-v6ops@ops.ietf.org Tue Sep 24 05:58:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21305 for ; Tue, 24 Sep 2002 05:58:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tmTK-000O9x-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 02:59:14 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tmTG-000O9Y-00; Tue, 24 Sep 2002 02:59:10 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8O9wCKW016427; Tue, 24 Sep 2002 11:58:13 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 11:58:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A2C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Brian E Carpenter'" , "Hesham Soliman (EAB)" Cc: "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 11:58:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > p2p applications can be designed to use intermediaries, > just like SMTP and HTTP. If I was designing an apps > protocol today, I would definitely make sure it could > be relayed between address spaces at applications level. => Are we in a position to mandate this? Hesham From owner-v6ops@ops.ietf.org Tue Sep 24 06:09:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21512 for ; Tue, 24 Sep 2002 06:09:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tmeO-000OnB-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 03:10:40 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17tmeL-000Omu-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 03:10:37 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13747; Tue, 24 Sep 2002 04:10:35 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8OAAYA17548; Tue, 24 Sep 2002 12:10:34 +0200 (MEST) Date: Tue, 24 Sep 2002 12:08:03 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comment on unmanaged analysis presentation/doc To: Robert Elz Cc: itojun@iijlab.net, Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <20639.1032792783@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > We can't do that - the only reason for having a 6to4 site is to be able > to communicate with the rest of the IPv6 universe. We can't restrict that > to the subset of that universe who are using 6to4. Understood. But that means that 6to4 provides the ultimate packet laundering service for source address spoofing that a combination of IPv4 and IPv6 ingress filtering can not prevent. If an attacker wants to spoof the source address of IPv6 packets it can just send IPv4 src = its own address IPv4 dst = victim 6to4 site IPv6 src = anything it desires IPv6 dst = victim host Any IPv4 ingress filtering will happily let such packets through since the IPv4 src is not spoofed. The 6to4 router at the victim's site will blindly decapsulate and loose all track of the IPv4 source. The victim might be able to insert a probe (after noticing the attack) at its 6to4 router and see the IPv4 source. But presumably this mechanism could also use helpful 6to4 relays as intermediaries where the original IPv4 source address would be lost at the relay and the victim has no easy way to install a probe at the relay since it is likely to be operated by some remote entity in the internet. This has me concerned. We don't need more wide-open relays than the once we already have at various protocol layers in the Internet. An approach for handling native to 6to4 site communication differently would be for the 6to4 site to explicitly establish a bidirectional tunnel (which can be authenticated etc) with a relay, and have that cause the relay to announce the /48 prefix into IPv6 routing. Then packets from native addresses would only arrive over that bidirectional tunnel. (And 6to4 sites could communicate with eachother using the direct path i.e. when the IPv4 source of the packet matches the IPv6 source of the packet this is safe; otherwise tunnel to the designated relay). But that implies some additional configuration (need to find a relay which is willing to server) and potentially lots of /48 routes being passed around. Erik From owner-v6ops@ops.ietf.org Tue Sep 24 06:52:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22226 for ; Tue, 24 Sep 2002 06:52:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tnIV-0000kl-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 03:52:07 -0700 Received: from [202.28.97.9] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17tnIM-0000gd-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 03:51:59 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8OApD327326; Tue, 24 Sep 2002 17:51:14 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8OAoK725399; Tue, 24 Sep 2002 17:50:21 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Sep 2002 17:50:20 +0700 Message-ID: <25397.1032864620@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Tue, 24 Sep 2002 12:08:03 +0200 (CEST) From: Erik Nordmark Message-ID: | But that means that 6to4 provides the ultimate packet laundering service | for source address spoofing that a combination of IPv4 and IPv6 ingress | filtering can not prevent. Not really any more than any other IP tunnel system does. | Any IPv4 ingress filtering will happily let such packets through since | the IPv4 src is not spoofed. Ingress filters wouldn't block this anyway - (except in rare cases where the destination doesn't want to be visible to most of the internet). It is egress filters that can block spoofed IPv4 addresses (and which make the mobile IP people upset...). Whether they should be used at all is still something that seems to be debated (my mind changes on this each time I hear the arguments from the other side). But assuming that they are to be used, first, no-one can count upon them (ie: this is something other sites, ISPs etc, do, in order to protect their own good name, to stop attacks coming from their net - it isn't to protect the target), and second, there's nothing to prohibit such filters from gazing inside (unencrypted) tunnels and filtering based upon what is there - so if I was really concerned about preventing spoofed IPv6 src addrs from escaping my net, then I'd be having my filter look at the IPv6 src addr inside the tunneled packet (or filtering that at or before, my 6to4 router, and blocking all 6to4 packets from other random internal hosts). | The 6to4 router at the victim's site will blindly decapsulate and | loose all track of the IPv4 source. yes. Just as a pure IPv6 router will blindly pass on a native IPv6 packet and loose all track of the IPv6 source (as does IPv4). The only filtering that can be done at the destination, is to make sure that the source address isn't meant to be on the destination link. A 6to4 decapsulator can do that as well (check that the IPv6 packet it is about to forward isn't one which really belongs in the local IPv6 net). | The victim might be able to insert a probe (after noticing the attack) | at its 6to4 router and see the IPv4 source. Tracing spoofed source addr attacks is hard, however the packets are transmitted. The only mitigating factor is that they can't require any kind of response, so the range of attacks is limited (mostly DoS only, though there are a couple of other hard to get right ones). | An approach for handling native to 6to4 site communication differently | would be for the 6to4 site to explicitly establish a bidirectional tunnel Hmm - isn't that exactly what 6to4 is supposed to be avoiding? That is, if this was to be required, wouldn't it be easier to just scrap 6to4, and replace it with TSP instead? That then also gets rid of the :lots of /48 prefixes" problem, as the assigned address would be one from the remote endpoint's address block. kre From owner-v6ops@ops.ietf.org Tue Sep 24 07:16:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22614 for ; Tue, 24 Sep 2002 07:16:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tnhP-0001y4-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 04:17:51 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17tnhL-0001xV-00; Tue, 24 Sep 2002 04:17:47 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tnhK-0001S1-00; Tue, 24 Sep 2002 12:17:46 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17tnhK-0001Rw-00; Tue, 24 Sep 2002 12:17:46 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA30984; Tue, 24 Sep 2002 12:17:43 +0100 Message-ID: <3D9049E0.B99C8E56@hursley.ibm.com> Date: Tue, 24 Sep 2002 13:17:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: <4DA6EA82906FD511BE2F00508BCF0538044F0A2C@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Hesham Soliman (EAB)" wrote: > > > p2p applications can be designed to use intermediaries, > > just like SMTP and HTTP. If I was designing an apps > > protocol today, I would definitely make sure it could > > be relayed between address spaces at applications level. > > => Are we in a position to mandate this? > This is the Internet, so no. But we (or if we were lucky the IAB) could make an architectural recommendation. Brian From owner-v6ops@ops.ietf.org Tue Sep 24 07:36:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22943 for ; Tue, 24 Sep 2002 07:36:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tnzo-0002ml-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 04:36:52 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tnzk-0002mZ-00; Tue, 24 Sep 2002 04:36:49 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8OBaSOW026165; Tue, 24 Sep 2002 13:36:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 13:36:13 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A2E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Brian E Carpenter'" , "Hesham Soliman (EAB)" Cc: "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 13:36:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > p2p applications can be designed to use intermediaries, > > > just like SMTP and HTTP. If I was designing an apps > > > protocol today, I would definitely make sure it could > > > be relayed between address spaces at applications level. > > > > => Are we in a position to mandate this? > > > > This is the Internet, so no. But we (or if we were lucky the IAB) > could make an architectural recommendation. => Well, we can recommend, but I don't think we can _assume_ that things will be done the way we recommend them. Especially when we're talking about applications. I know many application developers that don't know what v6ops is. It'll be hard to get this message to everyone so well that we can assume it will be followed. Hesham From owner-v6ops@ops.ietf.org Tue Sep 24 07:36:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22962 for ; Tue, 24 Sep 2002 07:36:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17to1H-0002sA-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 04:38:23 -0700 Received: from [63.175.42.17] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17to19-0002qh-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 04:38:16 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17to19-0000lH-00; Tue, 24 Sep 2002 04:38:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Tony Hain Cc: v6ops@ops.ietf.org Subject: RE: ocean: do not boil References: <5.1.0.14.2.20020923175825.02021470@mail.windriver.com> <078401c26368$13609300$011aa8c0@eagleswings> Message-Id: Date: Tue, 24 Sep 2002 04:38:15 -0700 X-Spam-Status: No, hits=4.2 required=5.0 tests=AS_SEEN_ON,RCVD_IN_OSIRUSOFT_COM version=2.31 X-Spam-Level: **** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> if i want my web site seen by both v4 and v6 users, then i can >> connect it to v4 and v6 space and run dual stack. in fact, i do >> so today. as v6 deploys, folk every useful site will do so. > Asserts that if a content site wants to be seen as IPv6 that it > is in control and can just advertise that and all IPv6-only nodes > will be able to reach it. yup. and if they want to be seen on broadband tv, they have to get broadband tv broadcast service. > The reality is that a consumer behind an IPv4-only NAT CPE will > need some form of IPv6-over-foo to get past the CPE. a content site is not a 'consumer'. they are provdng a servce. if they want to provide the service, they need things like mains power, the appropriate ip service(s), etc. > The hidden and invalid assumption in Randy's comment is that the > IPv6 network is contiguous. no, the assumption is that, if you are providing a service you have the service to provide. >> trying to make pure v4 sites/hosts communicate for arbitrary >> services with pure v6 sites/hosts and vice verse is a nice way >> to make the problem vastly more complicated, the solutions >> vastly more complex, and the net much less reliable. let's not >> go there. > Sounds like precluding a class of transition scenarios to me. exactly. hence the subject line. let's not pay the 90% to solve the last 10% if we really don't need to go there. we are providing engineering not marketing and engineering magic. randy From owner-v6ops@ops.ietf.org Tue Sep 24 09:23:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26317 for ; Tue, 24 Sep 2002 09:23:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tpfB-0007xk-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 06:23:41 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17tpf8-0007xZ-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 06:23:38 -0700 Received: from classic.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8ODbfE83087; Tue, 24 Sep 2002 09:37:41 -0400 (EDT) Date: Tue, 24 Sep 2002 09:14:12 -0400 From: Marc Blanchet To: Pekka Savola , Jun-ichiro itojun Hagino cc: v6ops@ops.ietf.org Subject: Re: quality of v6 connections [Re: unmanaged scope comments] Message-ID: <89600000.1032873252@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA26317 -- mardi, septembre 24, 2002 09:36:29 +0300 Pekka Savola wrote/a écrit: > I'll revisit this due to a private comment. > > Perhaps I should clarify this a bit. > > Your take seems to be "how do we solve this problem given the network and > v6 connectivity we have". > > Mine is basically "we have a problem with network connectivity and v6 and > with the current state, turning v6 on for everything will produce > dissatisfied users". > > With "network connectivity" I'm referring to the 6bone mess. 6bone = experimental network. 6bone is not the IPv6 internet. > > People usually just say, "enable IPv6" but it's more complex that. As an > user that actually uses IPv6 quite a bit, I'd be very hesitant to enable > full use in a generic form. > > I'm not sure whether trying to solve this is in our charter or not (or > even if it was, would we be able to do anything), but that's one real > problem. 6bone mess is hindering IPv6 deployment. not really. > > FWIW, I think 6bone addresses etc. are useful to get people started and > acquainted with IPv6. But tunnel-to-everyone, transit-to-everyone mess > is not. Those 6bone sites should be connected as leaf sites to proper > connectivity providers. s/6bone/internet ipv6/ Marc. From owner-v6ops@ops.ietf.org Tue Sep 24 09:41:04 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26906 for ; Tue, 24 Sep 2002 09:41:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tpwG-0008u5-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 06:41:20 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17tpw8-0008t2-00; Tue, 24 Sep 2002 06:41:12 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8ODdY023502; Tue, 24 Sep 2002 09:39:34 -0400 (EDT) Message-Id: <200209241339.g8ODdY023502@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'Brian E Carpenter'" , "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Tue, 24 Sep 2002 11:58:04 +0200.") <4DA6EA82906FD511BE2F00508BCF0538044F0A2C@Esealnt861.al.sw.ericsson.se> Date: Tue, 24 Sep 2002 09:39:34 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > p2p applications can be designed to use intermediaries, > > just like SMTP and HTTP. If I was designing an apps > > protocol today, I would definitely make sure it could > > be relayed between address spaces at applications level. > > => Are we in a position to mandate this? no. and I find the suggestion somewhat naive. it essentially requires that the application define its own address space and implement its own routing protocols. From owner-v6ops@ops.ietf.org Tue Sep 24 09:44:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27100 for ; Tue, 24 Sep 2002 09:44:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tq12-00099O-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 06:46:16 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17tq0t-000997-00; Tue, 24 Sep 2002 06:46:07 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8ODie023564; Tue, 24 Sep 2002 09:44:40 -0400 (EDT) Message-Id: <200209241344.g8ODie023564@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: "Hesham Soliman (EAB)" , "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Tue, 24 Sep 2002 13:17:52 +0200.") <3D9049E0.B99C8E56@hursley.ibm.com> Date: Tue, 24 Sep 2002 09:44:40 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > p2p applications can be designed to use intermediaries, > > > just like SMTP and HTTP. If I was designing an apps > > > protocol today, I would definitely make sure it could > > > be relayed between address spaces at applications level. > > > > => Are we in a position to mandate this? > > > > This is the Internet, so no. But we (or if we were lucky the IAB) > could make an architectural recommendation. It would strike me as extremely bizarre for the IAB to recommend that P2P applications define their own addressing system and routing protocols when IPv6 offers reasonably good ones. From owner-v6ops@ops.ietf.org Tue Sep 24 09:53:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27559 for ; Tue, 24 Sep 2002 09:53:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tq8u-0009aF-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 06:54:24 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17tq8r-0009a4-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 06:54:21 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8ODs4w30187; Tue, 24 Sep 2002 16:54:04 +0300 Date: Tue, 24 Sep 2002 16:54:04 +0300 (EEST) From: Pekka Savola To: Marc Blanchet cc: Jun-ichiro itojun Hagino , Subject: Re: quality of v6 connections [Re: unmanaged scope comments] In-Reply-To: <89600000.1032873252@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT 6bone is what we have. Saying it is not "ipv6 internet" won't change the truth, unfortunately. We have a small, with a couple of million potential users, native IPv6 network in Europe too, called 6NET, but I wouldn't go as far as calling that "ipv6 internet" either. One must either acknowledge that or live in a dream world thinking we have good connections, "ipv6 internet" is doing well etc. And how we can fix that? Start building real v6 connections and start ignoring 6bone. But there is no IPv6 internet other than 6bone yet. Sorry. On Tue, 24 Sep 2002, Marc Blanchet wrote: > -- mardi, septembre 24, 2002 09:36:29 +0300 Pekka Savola > wrote/a écrit: > > > I'll revisit this due to a private comment. > > > > Perhaps I should clarify this a bit. > > > > Your take seems to be "how do we solve this problem given the network and > > v6 connectivity we have". > > > > Mine is basically "we have a problem with network connectivity and v6 and > > with the current state, turning v6 on for everything will produce > > dissatisfied users". > > > > With "network connectivity" I'm referring to the 6bone mess. > > 6bone = experimental network. 6bone is not the IPv6 internet. > > > > > People usually just say, "enable IPv6" but it's more complex that. As an > > user that actually uses IPv6 quite a bit, I'd be very hesitant to enable > > full use in a generic form. > > > > I'm not sure whether trying to solve this is in our charter or not (or > > even if it was, would we be able to do anything), but that's one real > > problem. 6bone mess is hindering IPv6 deployment. > > not really. > > > > > FWIW, I think 6bone addresses etc. are useful to get people started and > > acquainted with IPv6. But tunnel-to-everyone, transit-to-everyone mess > > is not. Those 6bone sites should be connected as leaf sites to proper > > connectivity providers. > > s/6bone/internet ipv6/ > > Marc. > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 24 10:20:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28927 for ; Tue, 24 Sep 2002 10:20:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tqYl-000Aot-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:21:07 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17tqYi-000Aog-00; Tue, 24 Sep 2002 07:21:04 -0700 Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA26399; Tue, 24 Sep 2002 07:20:07 -0700 (PDT) Message-Id: <5.1.0.14.2.20020924095519.0202a260@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Sep 2002 10:19:28 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "'Brian E Carpenter'" , "Hesham Soliman (EAB)" , "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A2C@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Hesham, At 05:58 AM 9/24/02, Hesham Soliman (EAB) wrote: > > p2p applications can be designed to use intermediaries, > > just like SMTP and HTTP. If I was designing an apps > > protocol today, I would definitely make sure it could > > be relayed between address spaces at applications level. > >=> Are we in a position to mandate this? We're not in a position to _mandate_ anything. However, we are in a position to make recommendations about the best way to resolve certain scenarios. Say we have a scenario that runs like this: HostA is an IPv6-only node in an IPv6-only network in SiteA. HostA wants to reach ServiceB which runs on HostB in SiteB, an IPv4-only service on an IPv4-only node in an IPv4-only network. Now what are the possible solutions to that scenario? We could say that the best solution for this scenario is to install a NAT-PT-like box at the border of SiteA, modify the resolver in HostA (or the DNS server for SiteA) so that HostA will receive special IPv4-mapped addresses instead of A records for IPv4-only hosts, insert special routes to send packets to those addresses to the NAT-PT-like box, and translate traffic to those addresses from IPv6->IPv4 at the border of SiteA. We could say that the NAT-PT-like box should be installed at the border of SiteB, AAAA DNS entries should be advertised for the IPv4-only hosts within SiteB, routes should be advertised to cause IPv6 traffic to those addresses to come to NAT-PT-like box on the border of SiteB, and packets will be translated from IPv6->IPv4 at that border. Or, we could simply suggest that, if people want to reach IPv4-only services from a given host, they should support IPv4 connectivity to that host. This would mean installing a dual-stack on HostA and providing IPv4 connectivity (perhaps via NAT if IPv4 address space is an issue) within SiteA. We can suggest any one of these solutions, and people are, of course, entitled to ignore us. Given the choice between these three, though, the third one seems simpler and less prone to introducing new architectural and application-level issues, since the IPv4 infrastructure would be exactly the same as what many people are using today. Margaret From owner-v6ops@ops.ietf.org Tue Sep 24 10:20:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28947 for ; Tue, 24 Sep 2002 10:20:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tqZb-000Aqs-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:21:59 -0700 Received: from [3ffe:b00:c18:3::a] (helo=jazz.viagenie.qc.ca) by psg.com with esmtp (Exim 3.36 #1) id 17tqZX-000Aqh-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:21:55 -0700 Received: from classic.viagenie.qc.ca (classic.viagenie.qc.ca [206.123.31.136]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g8OEa3E83801; Tue, 24 Sep 2002 10:36:03 -0400 (EDT) Date: Tue, 24 Sep 2002 10:19:18 -0400 From: Marc Blanchet To: Pekka Savola cc: Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: quality of v6 connections [Re: unmanaged scope comments] Message-ID: <120180000.1032877157@classic.viagenie.qc.ca> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28947 -- mardi, septembre 24, 2002 16:54:04 +0300 Pekka Savola wrote/a écrit: > 6bone is what we have. we have more than 6bone. one good way to differentiate is: 6bone = 3ffe::/16. ipv6 internet = 2001::/16. > > Saying it is not "ipv6 internet" won't change the truth, unfortunately. sorry, but in the networks I'm controlling or involved, there is a clear distinction between the two: - production = 2001::/16, reliable connections, v6 native if possible - test/experiment = 3ffe::/16, experimental code from vendors, testing new mechanisms, etc.... > We have a small, with a couple of million potential users, native IPv6 > network in Europe too, called 6NET, but I wouldn't go as far as calling > that "ipv6 internet" either. > > One must either acknowledge that or live in a dream world thinking we > have good connections, "ipv6 internet" is doing well etc. > > And how we can fix that? Start building real v6 connections and start > ignoring 6bone. I'll rephrase: start building production v6 networks and use only 6bone for experimental work. > But there is no IPv6 internet other than 6bone yet. some. more coming, I agree... What I'm trying to say is that the current 6bone should not be seen as a model or a reference of the "ipv6 internet". it is a testbed, experimental network, crash and burn, ... Marc. > Sorry. > > On Tue, 24 Sep 2002, Marc Blanchet wrote: >> -- mardi, septembre 24, 2002 09:36:29 +0300 Pekka Savola >> wrote/a écrit: >> >> > I'll revisit this due to a private comment. >> > >> > Perhaps I should clarify this a bit. >> > >> > Your take seems to be "how do we solve this problem given the network >> > and v6 connectivity we have". >> > >> > Mine is basically "we have a problem with network connectivity and v6 >> > and with the current state, turning v6 on for everything will produce >> > dissatisfied users". >> > >> > With "network connectivity" I'm referring to the 6bone mess. >> >> 6bone = experimental network. 6bone is not the IPv6 internet. >> >> > >> > People usually just say, "enable IPv6" but it's more complex that. As >> > an user that actually uses IPv6 quite a bit, I'd be very hesitant to >> > enable full use in a generic form. >> > >> > I'm not sure whether trying to solve this is in our charter or not (or >> > even if it was, would we be able to do anything), but that's one real >> > problem. 6bone mess is hindering IPv6 deployment. >> >> not really. >> >> > >> > FWIW, I think 6bone addresses etc. are useful to get people started >> > and acquainted with IPv6. But tunnel-to-everyone, >> > transit-to-everyone mess is not. Those 6bone sites should be >> > connected as leaf sites to proper connectivity providers. >> >> s/6bone/internet ipv6/ >> >> Marc. >> >> >> > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From owner-v6ops@ops.ietf.org Tue Sep 24 10:22:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29022 for ; Tue, 24 Sep 2002 10:22:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tqbV-000Ayd-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:23:57 -0700 Received: from secundus.nysernet.org ([192.77.173.5]) by psg.com with esmtp (Exim 3.36 #1) id 17tqbO-000Ay0-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:23:51 -0700 Received: from [199.109.32.35] (cookiemonster.nysernet.org [199.109.32.35]) by secundus.nysernet.org (Postfix) with ESMTP id B156450904; Tue, 24 Sep 2002 10:18:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: owens@secundus.nysernet.org Message-Id: In-Reply-To: References: Date: Tue, 24 Sep 2002 10:23:48 -0400 To: Pekka Savola , From: Bill Owens Subject: Re: quality of v6 connections [Re: unmanaged scope comments] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,WEIRD_PORT version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 16:54 +0300 9/24/02, Pekka Savola wrote: >6bone is what we have. > >Saying it is not "ipv6 internet" won't change the truth, unfortunately. >We have a small, with a couple of million potential users, native IPv6 >network in Europe too, called 6NET, but I wouldn't go as far as calling >that "ipv6 internet" either. > >One must either acknowledge that or live in a dream world thinking we have >good connections, "ipv6 internet" is doing well etc. > >And how we can fix that? Start building real v6 connections and start >ignoring 6bone. But there is no IPv6 internet other than 6bone yet. >Sorry. There is perhaps something in between: [cookiemonster:~] owens% traceroute6 hammer.uoregon.edu traceroute6 to hammer.uoregon.edu (2001:468:d01:dc::80df:dc1d) from 2001:468:901:1:203:93ff:fed6:dfcc, 30 hops max, 12 byte packets 1 c7206-ge0-0.nysernet.net 1.291 ms 0.484 ms 0.503 ms 2 nyc-m20-nnsyr.nysernet.net 13.811 ms 13.981 ms 13.925 ms 3 roc-m10-nyc-m20.nysernet.net 21.467 ms 21.235 ms 20.965 ms 4 buf-m20-roc-m10.nysernet.net 23.047 ms 22.945 ms 22.881 ms 5 clev-nysernet.abilene.ucaid.edu 27.226 ms 27.581 ms 27.362 ms 6 ipls-clev.abilene.ucaid.edu 33.778 ms 33.685 ms 33.449 ms 7 kscy-ipls.abilene.ucaid.edu 42.633 ms 42.661 ms 43.221 ms 8 kscy-dnvr.abilene.ucaid.edu 54.519 ms 53.815 ms 53.663 ms 9 snva-dnvr.abilene.ucaid.edu 78.355 ms 78.035 ms 79.221 ms 10 2001:468:ff:b4d::2 92.055 ms * 91.137 ms 11 2001:468:d3f:1::2 91.39 ms 91.674 ms 91.789 ms 12 hammer.ipv6.uoregon.edu 92.268 ms 91.678 ms 91.538 ms [cookiemonster:~] owens% traceroute hammer.uoregon.edu traceroute to hammer.uoregon.edu (128.223.220.29), 30 hops max, 40 byte packets 1 c7206-1.nysernet.org (199.109.32.254) 0.92 ms 0.836 ms 0.476 ms 2 199.109.5.86 (199.109.5.86) 13.738 ms 13.693 ms 13.754 ms 3 roc-m10-nyc-m20.nysernet.net (199.109.5.53) 21.355 ms 22.949 ms 20.973 ms 4 buf-m20-roc-m10.nysernet.net (199.109.6.2) 22.692 ms 23.851 ms 23.228 ms 5 abilene-clev-buf-m20.nysernet.net (199.109.2.2) 27.101 ms 26.637 ms 27.035 ms 6 ipls-clev.abilene.ucaid.edu (198.32.8.25) 33.208 ms 33.272 ms 33.877 ms 7 kscy-ipls.abilene.ucaid.edu (198.32.8.5) 42.53 ms 42.008 ms 42.355 ms 8 dnvr-kscy.abilene.ucaid.edu (198.32.8.13) 53.762 ms 53.011 ms 53.15 ms 9 pos-6-3.core0.eug.oregon-gigapop.net (198.32.163.13) 86.98 ms 86.256 ms 90.283 ms 10 uo-0.eug.oregon-gigapop.net (198.32.163.147) 86.877 ms 84.327 ms 85.403 ms 11 ge-1-1.uonet2-gw.uoregon.edu (128.223.2.2) 85.201 ms 84.273 ms 86.951 ms 12 hammer.uoregon.edu (128.223.220.29) 85.456 ms 84.671 ms 86.446 ms The reason those traceroutes look so similar is that they're both native paths from Syracuse, NY (central NY state) to Eugene, OR. There's a slight difference at the far end because UO is dual connected to Abilene, and the BGP config is slightly different for v4 and v6. But they're basically the same path, over the same equipment, all running dual-stack and native. Of course other R&E networks have had native v6 capabilities for quite some time, too. One thing that stands out for me with respect to this path is that it crosses five ASes and all the participants are running released code on standard hardware, routing IPv4 and IPv6 with the same boxes. And for most of us that means all the boxes - we have no IPv4-only routers any more. I'm not sure how many other networks are doing that (if you are, I'd like to compare notes ;). Of course, NYSERNet, the Oregon GigaPoP and Abilene are not the 'real internet', where 'real internet' = 'commercial DFZ providers'. But we definitely aren't the 6Bone either. Bill. From owner-v6ops@ops.ietf.org Tue Sep 24 10:31:12 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29497 for ; Tue, 24 Sep 2002 10:31:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tqit-000BPW-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:31:35 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17tqip-000BPI-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:31:32 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8OEVR730610; Tue, 24 Sep 2002 17:31:27 +0300 Date: Tue, 24 Sep 2002 17:31:27 +0300 (EEST) From: Pekka Savola To: Bill Owens cc: v6ops@ops.ietf.org Subject: Re: quality of v6 connections [Re: unmanaged scope comments] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Sep 2002, Bill Owens wrote: > Of course other R&E networks have had native v6 capabilities for > quite some time, too. One thing that stands out for me with respect > to this path is that it crosses five ASes and all the participants > are running released code on standard hardware, routing IPv4 and IPv6 > with the same boxes. And for most of us that means all the boxes - we > have no IPv4-only routers any more. I'm not sure how many other > networks are doing that (if you are, I'd like to compare notes ;). We have a full dual-stack backbone in Finland. > Of course, NYSERNet, the Oregon GigaPoP and Abilene are not the 'real > internet', where 'real internet' = 'commercial DFZ providers'. But we > definitely aren't the 6Bone either. Sure.. but I calling that (using today's terminology) "IPv6 Internet" would be as much joke as calling the-network-that-was-in-1980 an Internet. A good joke. Heh! (Sure, you weren't making such an assertion.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 24 10:32:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29532 for ; Tue, 24 Sep 2002 10:32:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tqlE-000BWP-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:34:00 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17tqlA-000BWD-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:33:57 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8OEXlU30616; Tue, 24 Sep 2002 17:33:47 +0300 Date: Tue, 24 Sep 2002 17:33:47 +0300 (EEST) From: Pekka Savola To: Marc Blanchet cc: Jun-ichiro itojun Hagino , Subject: Re: quality of v6 connections [Re: unmanaged scope comments] In-Reply-To: <120180000.1032877157@classic.viagenie.qc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Tue, 24 Sep 2002, Marc Blanchet wrote: > -- mardi, septembre 24, 2002 16:54:04 +0300 Pekka Savola > wrote/a écrit: > > > 6bone is what we have. > > we have more than 6bone. one good way to differentiate is: > 6bone = 3ffe::/16. ipv6 internet = 2001::/16. Routing is independent of addressing. [...] > What I'm trying to say is that the current 6bone should not be seen as a > model or a reference of the "ipv6 internet". it is a testbed, experimental > network, crash and burn, ... Sure.. sure.. but before we can have *any* credibility, we must have a network that is reasonably global. Today that that is 6bone, unfortunately. > > On Tue, 24 Sep 2002, Marc Blanchet wrote: > >> -- mardi, septembre 24, 2002 09:36:29 +0300 Pekka Savola > >> wrote/a écrit: > >> > >> > I'll revisit this due to a private comment. > >> > > >> > Perhaps I should clarify this a bit. > >> > > >> > Your take seems to be "how do we solve this problem given the network > >> > and v6 connectivity we have". > >> > > >> > Mine is basically "we have a problem with network connectivity and v6 > >> > and with the current state, turning v6 on for everything will produce > >> > dissatisfied users". > >> > > >> > With "network connectivity" I'm referring to the 6bone mess. > >> > >> 6bone = experimental network. 6bone is not the IPv6 internet. > >> > >> > > >> > People usually just say, "enable IPv6" but it's more complex that. As > >> > an user that actually uses IPv6 quite a bit, I'd be very hesitant to > >> > enable full use in a generic form. > >> > > >> > I'm not sure whether trying to solve this is in our charter or not (or > >> > even if it was, would we be able to do anything), but that's one real > >> > problem. 6bone mess is hindering IPv6 deployment. > >> > >> not really. > >> > >> > > >> > FWIW, I think 6bone addresses etc. are useful to get people started > >> > and acquainted with IPv6. But tunnel-to-everyone, > >> > transit-to-everyone mess is not. Those 6bone sites should be > >> > connected as leaf sites to proper connectivity providers. > >> > >> s/6bone/internet ipv6/ > >> > >> Marc. > >> > >> > >> > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > ------------------------------------------ > Marc Blanchet > Viagénie > tel: +1-418-656-9254x225 > > ------------------------------------------ > http://www.freenet6.net: IPv6 connectivity > ------------------------------------------ > http://www.normos.org: IETF(RFC,draft), > IANA,W3C,... standards. > ------------------------------------------ > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 24 10:38:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29667 for ; Tue, 24 Sep 2002 10:38:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tqpr-000Bof-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:38:47 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17tqpo-000BoR-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:38:44 -0700 Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA04887; Tue, 24 Sep 2002 07:37:54 -0700 (PDT) Message-Id: <5.1.0.14.2.20020924103559.03ac2bc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Sep 2002 10:39:27 -0400 To: Pekka Savola From: Margaret Wasserman Subject: Re: quality of v6 connections [Re: unmanaged scope comments] Cc: Marc Blanchet , Jun-ichiro itojun Hagino , In-Reply-To: References: <120180000.1032877157@classic.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >Routing is independent of addressing. No, it's not. :-) Seriously, I hear this statement a lot, and it is pretty clear to me that routing is not independent of addressing, since IPv4 and IPv6 both imbed topological routing information in the address prefixes. In what sense to do you consider routing and addressing to be independent? > > What I'm trying to say is that the current 6bone should not be seen as a > > model or a reference of the "ipv6 internet". it is a testbed, experimental > > network, crash and burn, ... > >Sure.. sure.. but before we can have *any* credibility, we must have a >network that is reasonably global. Today that that is 6bone, >unfortunately. From what I heard in our meeting, NTT has a "reasonably global" commercial IPv6 backbone active in Asia, Europe and North America... Margaret From owner-v6ops@ops.ietf.org Tue Sep 24 10:40:02 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29730 for ; Tue, 24 Sep 2002 10:40:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tqsh-000Bym-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:41:43 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tqse-000ByP-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:41:40 -0700 Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8OEfbOa022724 for ; Tue, 24 Sep 2002 16:41:38 +0200 (MEST) Received: by esealnt611.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 16:41:37 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A3E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Hesham Soliman (EAB)" Cc: "'Brian E Carpenter'" , "Hesham Soliman (EAB)" , "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 16:41:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > > p2p applications can be designed to use intermediaries, > > > just like SMTP and HTTP. If I was designing an apps > > > protocol today, I would definitely make sure it could > > > be relayed between address spaces at applications level. > > > >=> Are we in a position to mandate this? > > We're not in a position to _mandate_ anything. However, we are > in a position to make recommendations about the best way to resolve > certain scenarios. => I'm not trying to be -ve, but unless we mandate that all applications will use this model, or alternatively assume that HTTP and SMTP are the only important applications for the medium term there is no point eliminating the v6 -> v4 scenarios. Clearly (at least to me), it would be pointless to start making "recommendation for application layer protocol developers" in this group. This _is_ boiling the ocean IMHO. > Say we have a scenario that runs like this: > > HostA is an IPv6-only node in an IPv6-only network > in SiteA. > HostA wants to reach ServiceB which runs on HostB > in SiteB, an > IPv4-only service on an IPv4-only node in an > IPv4-only network. > > Now what are the possible solutions to that scenario? > > We could say that the best solution for this scenario is to install > a NAT-PT-like box at the border of SiteA, modify the resolver in > HostA (or the DNS server for SiteA) so that HostA will > receive special > IPv4-mapped addresses instead of A records for IPv4-only hosts, > insert special routes to send packets to those addresses to the > NAT-PT-like box, and translate traffic to those addresses from > IPv6->IPv4 at the border of SiteA. > > We could say that the NAT-PT-like box should be installed at the > border of SiteB, AAAA DNS entries should be advertised for the > IPv4-only hosts within SiteB, routes should be advertised to cause > IPv6 traffic to those addresses to come to NAT-PT-like box on the > border of SiteB, and packets will be translated from IPv6->IPv4 > at that border. > > Or, we could simply suggest that, if people want to reach IPv4-only > services from a given host, they should support IPv4 connectivity to > that host. This would mean installing a dual-stack on HostA and > providing IPv4 connectivity (perhaps via NAT if IPv4 > address space is > an issue) within SiteA. => This is a separate discussion from the "recommendations for applications" discussion I think. > > We can suggest any one of these solutions, and people are, > of course, > entitled to ignore us. Given the choice between these > three, though, > the third one seems simpler => Can you please explain why it is "simpler" ? and less prone to introducing new > architectural and application-level issues, => What does this mean?`what architectural issues are reduced by v4 NATs? since the IPv4 > infrastructure > would be exactly the same as what many people are using today. => Margaret, please consider my concern: I am not talking about networks with _existing_ IPv4 infrastructures/NATs. I hope my intention is clear. I know that many ISPs already have v4 NATs and this is not the case I'm bringing up. Hesham From owner-v6ops@ops.ietf.org Tue Sep 24 10:41:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29839 for ; Tue, 24 Sep 2002 10:41:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tquH-000C59-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:43:21 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 17tquC-000C41-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:43:16 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA11783 for ; Tue, 24 Sep 2002 15:43:05 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:ULidsywJpvckZIFkDg9/cM0zWp1/KoyG@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8OEguRA019046 for ; Tue, 24 Sep 2002 15:42:56 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g8OEguP30059 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 15:42:56 +0100 Date: Tue, 24 Sep 2002 15:42:56 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: quality of v6 connections [Re: unmanaged scope comments] Message-ID: <20020924144256.GO28669@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <120180000.1032877157@classic.viagenie.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <120180000.1032877157@classic.viagenie.qc.ca> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,WEIRD_PORT version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Sep 24, 2002 at 10:19:18AM -0400, Marc Blanchet wrote: > > sorry, but in the networks I'm controlling or involved, there is a clear > distinction between the two: > - production = 2001::/16, reliable connections, v6 native if possible > - test/experiment = 3ffe::/16, experimental code from vendors, testing new > mechanisms, etc.... and how do you distinguish these prefixes in terms of peering and transit policies? performance isn't just down to which prefix is used, e.g. i am here in tilab's network in turin and have a 2001: route all the way back to my home network in the uk: >tracert6 www.ipv6.ecs.soton.ac.uk Tracing route to seven.ecs.soton.ac.uk [2001:630:d0:200:a00:20ff:feb5:ef1e] from 2001:6b8:10:1600:8157:1234:8972:6034 over a maximum of 30 hops: 1 3 ms 3 ms 3 ms 2001:6b8:10:1600:207:85ff:fea8:6f61 2 4 ms 60 ms 4 ms 2001:6b8:10:1700:201:2ff:fed8:3b0b 3 * * * Request timed out. 4 8 ms 8 ms 7 ms 6bone-gw4.ipv6.cselt.it [2001:6b8:0:100::6] 5 8 ms 9 ms 8 ms 6bone-gw1.ipv6.cselt.it [2001:6b8:0:100::2] 6 230 ms 297 ms 200 ms nl-ams-re-02-t-7.ipv6.aorta.net [2001:730::1: 8] 7 446 ms 349 ms 326 ms 2001:630:0:1::1e 8 294 ms 256 ms 402 ms 2001:630:d0:200:a00:20ff:feb5:ef1e [excuse the broken reverse dns, which i guess should work on a "production" network] the response time via the v4 path is much better. it depends what the operators are doing with tunnels so i think pekka's point is the mesh mess, which is annoying when you try to use ipv6 for day to day use, especially for interactive ssh access. tim From owner-v6ops@ops.ietf.org Tue Sep 24 10:52:44 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00541 for ; Tue, 24 Sep 2002 10:52:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tr3P-000Cc6-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 07:52:47 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17tr3L-000Cbu-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 07:52:43 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8OEqMd30843; Tue, 24 Sep 2002 17:52:22 +0300 Date: Tue, 24 Sep 2002 17:52:22 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Marc Blanchet , Jun-ichiro itojun Hagino , Subject: Re: quality of v6 connections [Re: unmanaged scope comments] In-Reply-To: <5.1.0.14.2.20020924103559.03ac2bc0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 24 Sep 2002, Margaret Wasserman wrote: > >Routing is independent of addressing. > > No, it's not. :-) > > Seriously, I hear this statement a lot, and it is pretty clear to me > that routing is not independent of addressing, since IPv4 and IPv6 > both imbed topological routing information in the address prefixes. Well.. I made a presentation in a conference about "IPv6 routing and addressing" where I showed their connection so they aren't with current policies.. but for all practical purposes they're not. Let me elaborate a bit. Routing is completely independent of the addressing in the sense that I can advertise any prefix I want in the routing protocols (in this case, BGP). Therefore, when I receive a 2001::/16 or 3ffe::/16 prefix, there is *no* way to say "2001" is production while "3ffe" is not. Indeed, both 3ffe prefixes are advertised over production backbones, and 2001 prefixes over 6bone. The only connection in routing/addressing is that currently there is a widely-implemented prefixlength restrictions in place everywhere. This restricts a bit what you can do with your addresses. But if you're a major player like an ISP, that's entirely up to you (and your neighbors). > In what sense to do you consider routing and addressing to be independent? > > > > What I'm trying to say is that the current 6bone should not be seen as a > > > model or a reference of the "ipv6 internet". it is a testbed, experimental > > > network, crash and burn, ... > > > >Sure.. sure.. but before we can have *any* credibility, we must have a > >network that is reasonably global. Today that that is 6bone, > >unfortunately. > > From what I heard in our meeting, NTT has a "reasonably global" commercial > IPv6 backbone active in Asia, Europe and North America... Market speak, I'd say. The more important point is, how many other IPv6 backbones they connect to. Private walled gardens help no one. When you can reach e.g. 80-90% of all IPv6 users through commercial-grade networks, we're in a very good shape.. that's not happening yet. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Tue Sep 24 11:13:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01630 for ; Tue, 24 Sep 2002 11:13:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17trMq-000Dit-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 08:12:52 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17trMn-000Did-00; Tue, 24 Sep 2002 08:12:49 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17trMl-0001iZ-00; Tue, 24 Sep 2002 16:12:47 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17trMl-0001iU-00; Tue, 24 Sep 2002 16:12:47 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA45232; Tue, 24 Sep 2002 16:12:41 +0100 Message-ID: <3D9080F1.F78AFAD4@hursley.ibm.com> Date: Tue, 24 Sep 2002 17:12:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Keith Moore CC: "Hesham Soliman (EAB)" , "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: <200209241344.g8ODie023564@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > > > > > p2p applications can be designed to use intermediaries, > > > > just like SMTP and HTTP. If I was designing an apps > > > > protocol today, I would definitely make sure it could > > > > be relayed between address spaces at applications level. > > > > > > => Are we in a position to mandate this? > > > > > > > This is the Internet, so no. But we (or if we were lucky the IAB) > > could make an architectural recommendation. > > It would strike me as extremely bizarre for the IAB to recommend > that P2P applications define their own addressing system and > routing protocols when IPv6 offers reasonably good ones. Who said anything about a new address space or about routing? Obviously we are talking about scenarios where the basic dual stack mechanism fails due to a connectivity gap. You then have two choices - resolve this by the sort of network level complexity Margaret's message refers to. - resolve it at applications level. This may well involve an applications level identifier namespace that works everywhere, like URIs or RFC 2822, but it doesn't imply replacing the IP locator namespace (a.k.a. addresses) or the IP routing system. I'm not suggesting that v6ops should work on this. But it's the way distributed computing systems are very likely to go, in self-defence. If the v6ops scenarios ignore this, they are incomplete. Brian From owner-v6ops@ops.ietf.org Tue Sep 24 11:13:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01652 for ; Tue, 24 Sep 2002 11:13:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17trP0-000Drj-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 08:15:06 -0700 Received: from mail-gw2.hursley.ibm.com ([194.196.110.19]) by psg.com with esmtp (Exim 3.36 #1) id 17trOt-000Dr0-00; Tue, 24 Sep 2002 08:14:59 -0700 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17trOs-0001w3-00; Tue, 24 Sep 2002 16:14:58 +0100 Received: from [9.20.45.103] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.10) id 17trOs-0001vy-00; Tue, 24 Sep 2002 16:14:58 +0100 Received: from hursley.ibm.com (dhcp22-199.zurich.ibm.com [9.4.22.199]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA30906; Tue, 24 Sep 2002 16:14:58 +0100 Message-ID: <3D90817A.45F68592@hursley.ibm.com> Date: Tue, 24 Sep 2002 17:15:06 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: "'Margaret Wasserman'" , "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: <4DA6EA82906FD511BE2F00508BCF0538044F0A3E@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "Hesham Soliman (EAB)" wrote: > > > > > > > p2p applications can be designed to use intermediaries, > > > > just like SMTP and HTTP. If I was designing an apps > > > > protocol today, I would definitely make sure it could > > > > be relayed between address spaces at applications level. > > > > > >=> Are we in a position to mandate this? > > > > We're not in a position to _mandate_ anything. However, we are > > in a position to make recommendations about the best way to resolve > > certain scenarios. > > => I'm not trying to be -ve, but unless we mandate > that all applications will use this model, or alternatively > assume that HTTP and SMTP are the only important applications > for the medium term there is no point eliminating the > v6 -> v4 scenarios. I didn't suggest eliminating them. But since they will be even worse to manage than IPv4 NAT, we should use them only when forced to. Brian From owner-v6ops@ops.ietf.org Tue Sep 24 11:42:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03083 for ; Tue, 24 Sep 2002 11:42:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17trqO-000FMs-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 08:43:24 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17trqJ-000FLd-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 08:43:19 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1793C18E3 for ; Tue, 24 Sep 2002 11:43:18 -0400 (EDT) Date: Tue, 24 Sep 2002 11:43:18 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: References: <20639.1032792783@munnari.OZ.AU> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020924154318.1793C18E3@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Tue, 24 Sep 2002 12:08:03 +0200 (CEST), Erik Nordmark wrote: > > Any IPv4 ingress filtering will happily let such packets through since > the IPv4 src is not spoofed. > The 6to4 router at the victim's site will blindly decapsulate and > loose all track of the IPv4 source. There's a piece missing from this picture. Every packet filtering system I have ever used allows one to make filtering decisions based on the interface on which a packet has been received or will be transmitted. So, conceptually, if you can divide the total set of interfaces into discrete sets and write down straightforward rules about which interfaces may be used as receive and transmit interfaces when forwarding packets, this becomes a small matter of writing (a whole bunch of) filtering rules. For example, in the KAME 6to4 edge router I'm using right now, the rule is (conceptually) simple: if the packet came in on an external interface, it may not be forwarded back out an external interface. In KAME it happens that encapsulation shows up as one of several types of virtual interfaces, but the other obvious alternative implementation just keeps track of the original interface all the way through decapsulation. It works either way, so long as you don't end up with any interfaces that you can't assign to exactly one partition. Relays are a harder problem, because as far as I know there is no useful partition one can apply to a relay's interfaces. I'd like to be proven wrong about this. From owner-v6ops@ops.ietf.org Tue Sep 24 11:43:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03110 for ; Tue, 24 Sep 2002 11:43:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17trqy-000FNO-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 08:44:00 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17trqv-000FN0-00; Tue, 24 Sep 2002 08:43:57 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8OFhiKV014270; Tue, 24 Sep 2002 17:43:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 17:43:44 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A3F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Brian E Carpenter'" Cc: "'Margaret Wasserman'" , "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 17:43:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > > > > p2p applications can be designed to use intermediaries, > > > > > just like SMTP and HTTP. If I was designing an apps > > > > > protocol today, I would definitely make sure it could > > > > > be relayed between address spaces at applications level. > > > > > > > >=> Are we in a position to mandate this? > > > > > > We're not in a position to _mandate_ anything. > However, we are > > > in a position to make recommendations about the best > way to resolve > > > certain scenarios. > > > > => I'm not trying to be -ve, but unless we mandate > > that all applications will use this model, or alternatively > > assume that HTTP and SMTP are the only important applications > > for the medium term there is no point eliminating the > > v6 -> v4 scenarios. > > I didn't suggest eliminating them. But since they will be even worse > to manage than IPv4 NAT, we should use them only when forced to. => I fully agree that this is something that should only be used/deployed if people are forced to do it. Translators in general are not pretty and don't make life simpler, but are necessary sometimes. What I'm not sure about is whether running a dual network containing IPv6 (global) and IPv4 private addresses is simpler than just running an IPv6 network with v6 <=> v4 translators. Hesham From owner-v6ops@ops.ietf.org Tue Sep 24 12:06:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03862 for ; Tue, 24 Sep 2002 12:06:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tsE9-000GbL-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 09:07:57 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17tsE4-000GaS-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 09:07:52 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D5B6218A2 for ; Tue, 24 Sep 2002 12:07:51 -0400 (EDT) Date: Tue, 24 Sep 2002 12:07:51 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-Reply-To: <20020924070041.3674C4B22@coconut.itojun.org> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020924160751.D5B6218A2@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Tue, 24 Sep 2002 16:00:41 +0900, itojun@iijlab.net wrote: > > who in this group participates to docsis group? what is the > relationship between IETF and docsis group? (are there any kind of > relationship like IETF-3GPP?) if there's anything i/we can do, i > think we should do that. There's no current formal liaison relationship between the IETF and Cablelabs (the DOCSIS people), but the subject has come up recently for other reasons, and a few IAB and IESG folks have an action item to talk to Cablelabs about a liaison (see recent IESG minutes). I forwarded Itojun's message to the folks who are looking into this. Don't hold your breath waiting for a reply, this is still at a very preliminary stage and it's too soon to tell where it's going to go. From owner-v6ops@ops.ietf.org Tue Sep 24 12:06:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03886 for ; Tue, 24 Sep 2002 12:06:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tsEg-000GeD-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 09:08:30 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17tsEb-000GdL-00; Tue, 24 Sep 2002 09:08:25 -0700 Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA27012; Tue, 24 Sep 2002 09:07:23 -0700 (PDT) Message-Id: <5.1.0.14.2.20020924114738.0205b680@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Sep 2002 12:08:58 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "Hesham Soliman (EAB)" , "'Brian E Carpenter'" , "Hesham Soliman (EAB)" , "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A3E@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Hesham, >=> I'm not trying to be -ve, I'm not sure what "-ve" means, but I'm certain that you aren't trying to be it :-). >but unless we mandate >that all applications will use this model, or alternatively >assume that HTTP and SMTP are the only important applications >for the medium term there is no point eliminating the >v6 -> v4 scenarios. Which model? All widely deployed IPv4 applications work with the existing IPv4 model. If that model continues to be the way to reach IPv4 services (as I have suggested), there wouldn't be any need to change existing IPv4 services. >Clearly (at least to me), it would be pointless to start >making "recommendation for application layer protocol >developers" in this group. This _is_ boiling the >ocean IMHO. I agree. Requiring a application-layer proxy for each type of application is not desirable. > > We can suggest any one of these solutions, and people are, > > of course, > > entitled to ignore us. Given the choice between these > > three, though, > > the third one seems simpler > >=> Can you please explain why it is "simpler" ? In my opinion, the use of parallel IPv4 and IPv6 infrastructure is simpler than IPv4<->IPv6 translation, because it doesn't require special support from the DNS system (either servers or resolvers), doesn't require injection of routes for special IPv6 address prefixes, and doesn't, inherently, require any translation. Now, it is true that the IPv4 infrastructure may include a NAT. But, even in those cases, the parallel use of IPv4 avoids complexity in the DNS and routing tables. >and less prone to introducing new > > architectural and application-level issues, > >=> What does this mean?`what architectural issues >are reduced by v4 NATs? The use of parallel IPv4 and IPv6 infrastructure, even with the use of IPv4 NATs, does not introduce any _new_ architectural issues. Yes, there are some major architectural issues with IPv4 NATs, but these issues are not new, and IPv4 applications have already been modified/limited to work within this type of environment. >since the IPv4 > > infrastructure > > would be exactly the same as what many people are using today. > >=> Margaret, please consider my concern: I am not talking >about networks with _existing_ IPv4 infrastructures/NATs. >I hope my intention is clear. I know that many ISPs >already have v4 NATs and this is not the case I'm bringing >up. Yes, I understand this, Hesham. But, I really do think that it would be wiser for a networ operator to install parallel IPv4 and IPv6 infrastructure in a new installation, if any of the nodes on their network will need to access IPv4-only services. Installing an IPv4 NAT and DHCP server won't be any harder than installing a v4<->v6 translator with DNS and routing tie-ins. You won't need any more IPv4 addresses than you do in a v4<->v6 translation model (you will always need a v4 address to access a v4 service), and using a "normal" (by today's standards) IPv4 infrastructure will result in fewer problems accessing IPv4 applications and services. What am I missing? Margaret From owner-v6ops@ops.ietf.org Tue Sep 24 13:00:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05957 for ; Tue, 24 Sep 2002 13:00:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tt3m-000JgO-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 10:01:18 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17tt3e-000Jfz-00; Tue, 24 Sep 2002 10:01:10 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8OGxe024213; Tue, 24 Sep 2002 12:59:40 -0400 (EDT) Message-Id: <200209241659.g8OGxe024213@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: Keith Moore , "Hesham Soliman (EAB)" , "'Bob Hinden'" , Margaret Wasserman , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Tue, 24 Sep 2002 17:12:49 +0200.") <3D9080F1.F78AFAD4@hursley.ibm.com> Date: Tue, 24 Sep 2002 12:59:40 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > It would strike me as extremely bizarre for the IAB to recommend > > that P2P applications define their own addressing system and > > routing protocols when IPv6 offers reasonably good ones. > > Who said anything about a new address space or about routing? > > Obviously we are talking about scenarios where the basic dual stack > mechanism fails due to a connectivity gap. You then have two choices > - resolve this by the sort of network level complexity Margaret's > message refers to. > - resolve it at applications level. This may well involve an > applications level identifier namespace that works everywhere, > like URIs or RFC 2822, but it doesn't imply replacing the IP > locator namespace (a.k.a. addresses) or the IP routing system. for the p2p app to work with an arbitrary mesh of v4/v6 connectivity it has to do its own routing using its own namespace. whether you think of this as replacing the IP routing system is up to you. but however you think of it, it ends up fulfilling most of the same functions. From owner-v6ops@ops.ietf.org Tue Sep 24 13:26:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06679 for ; Tue, 24 Sep 2002 13:26:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ttTZ-000LGt-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 10:27:57 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17ttTP-000LGh-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 10:27:47 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8OHMW024414; Tue, 24 Sep 2002 13:22:32 -0400 (EDT) Message-Id: <200209241722.g8OHMW024414@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Pekka Savola , Marc Blanchet , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: Re: quality of v6 connections [Re: unmanaged scope comments] In-reply-to: (Your message of "Tue, 24 Sep 2002 10:39:27 EDT.") <5.1.0.14.2.20020924103559.03ac2bc0@mail.windriver.com> Date: Tue, 24 Sep 2002 13:22:32 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >Routing is independent of addressing. > > No, it's not. :-) > > Seriously, I hear this statement a lot, and it is pretty clear to me > that routing is not independent of addressing, since IPv4 and IPv6 > both imbed topological routing information in the address prefixes. that, and the best strategy we know of for making it scale is to do topological aggregation. which is not to say that we couldn't have addresses that were completely independent of topology - we'd just need to propagate a rather large address-to-location mapping table to all of the routers along with the routing table. Keith From owner-v6ops@ops.ietf.org Tue Sep 24 14:17:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08060 for ; Tue, 24 Sep 2002 14:17:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tuF7-000OE5-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 11:17:05 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17tuF4-000ODq-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 11:17:02 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id BE91018A2 for ; Tue, 24 Sep 2002 14:17:01 -0400 (EDT) Date: Tue, 24 Sep 2002 14:17:01 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Docsis support for IPv6 References: <20020924181448.10B6D1905@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: multipart/mixed; boundary="Multipart_Tue_Sep_24_14:17:01_2002-1" Message-Id: <20020924181701.BE91018A2@thrintun.hactrn.net> X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Multipart_Tue_Sep_24_14:17:01_2002-1 Content-Type: text/plain; charset=US-ASCII Forwarded with permission. --Multipart_Tue_Sep_24_14:17:01_2002-1 Content-Type: message/rfc822 Date: Tue, 24 Sep 2002 12:48:22 -0400 From: Michael StJohns To: Rob Austein Reply-To: mstjohns@mindspring.com Subject: Re: Something else to talk to Cablelabs about? Sender: mstjohns@mindspring.com Message-ID: MIME-Version: 1.0 Actually, not a problem. 1) Docsis cable modems are bridges not routers and pass ethernet packets. 2) The "new" MIBs have the proper language for managing IPv6 customers. The modems themselves will probably have IPv4 stacks only for a while, but they're managed out of private address space. The only thing that really needs to be done is enable IPv6 forwarding at the head end (e.g. in the Cable Modem Termination System - CMTS). That's a $$ decision by the cable operators and by the CMTS vendors based on cable operator input. Later, Mike --Multipart_Tue_Sep_24_14:17:01_2002-1-- From owner-v6ops@ops.ietf.org Tue Sep 24 14:35:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08425 for ; Tue, 24 Sep 2002 14:35:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tuYV-000PSh-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 11:37:07 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17tuYQ-000PSU-00; Tue, 24 Sep 2002 11:37:03 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8OIahOW026274; Tue, 24 Sep 2002 20:36:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 24 Sep 2002 20:36:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A42@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Hesham Soliman (EAB)" Cc: "Hesham Soliman (EAB)" , "'Brian E Carpenter'" , "Hesham Soliman (EAB)" , "'Bob Hinden'" , Randy Bush , Bob Fink , Jun-ichiro itojun Hagino , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 20:36:32 +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.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >=> I'm not trying to be -ve, > > I'm not sure what "-ve" means, but I'm certain that you > aren't trying to be it :-). => Good! > > >but unless we mandate > >that all applications will use this model, or alternatively > >assume that HTTP and SMTP are the only important applications > >for the medium term there is no point eliminating the > >v6 -> v4 scenarios. > > Which model? All widely deployed IPv4 applications work with > the existing IPv4 model. => see below. If that model continues to be the way > to reach IPv4 services (as I have suggested), there wouldn't > be any need to change existing IPv4 services. > > >Clearly (at least to me), it would be pointless to start > >making "recommendation for application layer protocol > >developers" in this group. This _is_ boiling the > >ocean IMHO. > > I agree. Requiring a application-layer proxy for each type > of application is not desirable. => ok, that's what I was referring too above ("the model" suggested in an earlier email) > >=> Can you please explain why it is "simpler" ? > > In my opinion, the use of parallel IPv4 and IPv6 infrastructure > is simpler than IPv4<->IPv6 translation, because it doesn't > require special support from the DNS system (either servers or > resolvers), doesn't require injection of routes for special > IPv6 address prefixes, and doesn't, inherently, require any > translation. => Depending on the solution you choose there might not be any special addresses or special routing. In fact, regardless of the model you choose I don't see the need for any special routing. Translation is already there, whether it's a v4 NAT or a NAT-PT. The scalability issue is also there regardless. What you mention about the DNS issues is valid, but this kind of "simplicity" (of removing the DNS issues) is not necessarily operationally simpler when compared to running IPv4 NATs. Any operator can jump in about now and tell us what they think. > Now, it is true that the IPv4 infrastructure may include a > NAT. But, even in those cases, the parallel use of IPv4 avoids > complexity in the DNS and routing tables. => I don't understand what complexity is there with the routing tables. > >=> What does this mean?`what architectural issues > >are reduced by v4 NATs? > > The use of parallel IPv4 and IPv6 infrastructure, even with > the use of IPv4 NATs, does not introduce any _new_ > architectural issues. Yes, there are some major architectural > issues with IPv4 NATs, but these issues are not new, and IPv4 > applications have already been modified/limited to work within > this type of environment. > > >since the IPv4 > > > infrastructure > > > would be exactly the same as what many people are using today. > > > >=> Margaret, please consider my concern: I am not talking > >about networks with _existing_ IPv4 infrastructures/NATs. > >I hope my intention is clear. I know that many ISPs > >already have v4 NATs and this is not the case I'm bringing > >up. > > Yes, I understand this, Hesham. > > But, I really do think that it would be wiser for a networ > operator to install parallel IPv4 and IPv6 infrastructure in a > new installation, if any of the nodes on their network will > need to access IPv4-only services. > > Installing an IPv4 NAT and DHCP server won't be any harder than > installing a v4<->v6 translator with DNS and routing tie-ins. You > won't need any more IPv4 addresses than you do in a v4<->v6 > translation model (you will always need a v4 address to access > a v4 service), and using a "normal" (by today's standards) > IPv4 infrastructure will result in fewer problems accessing > IPv4 applications and services. > > What am I missing? => I don't exactly think one of us is missing something (except that I don't think there are any routing issues here, unless running a dual network involves more management of the routing infrastructure). I think the issue here is a matter of assumptions. You assume that it's ok to tell a new operator in china or anywhere that to deploy their new IPv6 network they need to buy and run an IPv4 private network (well, buy the NATs anyway). I assume that they would rather not do that and that this extra infrastructure is redundant. I also think that simplicities you mention (regarding the DNS)are simpler for us (IETF people), but I'm not sure that operationally it will be simpler for people to buy and run a dual network, especially when they don't need it. I'm not pushing for NAT-PT/SIIT deployment everywhere, but my preferences for a new operator are: 1. Run a dual stack network with public addresses 2. If public addresses are not possible (for v4) then just run a v6 network. Hesham PS: I think this discussion is a proof that we need to get more operators involved and more discussions before we eliminate anything. From owner-v6ops@ops.ietf.org Tue Sep 24 15:42:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10242 for ; Tue, 24 Sep 2002 15:42:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tvZO-0003Pf-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 12:42:06 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17tvZI-0003PH-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 12:42:00 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 24 Sep 2002 12:41:59 -0700 Reply-To: From: "Tony Hain" To: "'Randy Bush'" Cc: Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 12:41:48 -0700 Message-ID: <000001c26402$6e552060$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,AS_SEEN_ON version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA10242 Randy Bush wrote: > > >> if i want my web site seen by both v4 and v6 users, then i can > >> connect it to v4 and v6 space and run dual stack. in > fact, i do so > >> today. as v6 deploys, folk every useful site will do so. > > Asserts that if a content site wants to be seen as IPv6 > that it is in > > control and can just advertise that and all IPv6-only nodes will be > > able to reach it. > > yup. and if they want to be seen on broadband tv, they have > to get broadband tv broadcast service. So all content sites are held hostage until their ISP gets around to providing IPv6 service... > > > The reality is that a consumer behind an IPv4-only NAT CPE > will need > > some form of IPv6-over-foo to get past the CPE. > > a content site is not a 'consumer'. they are provdng a > servce. if they want to provide the service, they need > things like mains power, the appropriate ip service(s), etc. This model precludes any consumer from providing content. Specifically it precludes any peer-to-peer applications. I realize that many ISPs currently don't like the idea of a consumer hosting personal web or mail services, but their business practice should not have any impact on the range of technology standards we are developing. > > > The hidden and invalid assumption in Randy's comment is > that the IPv6 > > network is contiguous. > > no, the assumption is that, if you are providing a service > you have the service to provide. In other words, the edge sites can't use any tunneling technologies because those aren't 'provided', and when the provider gets around to it there will be an IPv6 network service that is contiguous. > > >> trying to make pure v4 sites/hosts communicate for > arbitrary services > >> with pure v6 sites/hosts and vice verse is a nice way to make the > >> problem vastly more complicated, the solutions vastly more > complex, > >> and the net much less reliable. let's not go there. > > Sounds like precluding a class of transition scenarios to me. > > exactly. hence the subject line. let's not pay the 90% to > solve the last 10% if we really don't need to go there. we > are providing engineering not marketing and engineering magic. I am not the one trying to prejudge the market needs. Since we know that some of the transition technologies will be complex, why are we concerned about their existence? The simplest mechanism to solve the deployment problems will become predominate through natural selection. If there are a substantial number of networks that can't use the predominate tool, and we have precluded them from deploying because we didn't finish the tool that would work, have we done proper engineering? I can understand the desire to sort and prioritize to manage resource constraints, but at the moment I see an abundance of people willing to work on the problems. Where is the resource constraint we are trying to manage? Is it the time of the DNSext wg in trying to document that the mx record an IPv6-only node sees for an IPv4-only node needs to point to a dual-stack MTA? Even when that is identified, is it reasonable to prejudge a class of transition tools as out of scope when the wg is in the midst of trying to document the cases they or their customers are currently facing? Personally I will not be spending a lot of my time on translation tools, as I tell my customers that the translation approach should be looked at as a last resort. That said, there have been cases where those customers are stuck at that last resort point, so I a glad there are people in the wg who want to work out the details. The process of declaring those situations out of scope at this point is telling sites that want to deploy IPv6 that they need to deploy an IPv4 network, even when they only want occasional access to the existing public Internet. Yes application specific proxies at the edge will solve some of the problems, but the IETF doesn't specify every possible application. Taking the position that http & smtp are enough is focused on the limited applications that service providers typically offer. End sites have a much broader mix for their specific needs, so precluding generic translation is condemning them to build their own application specific proxy, or wait for their ISP. This puts us back in the chicken-and-egg situation where the ISP won't deploy without demonstrated demand, but the sites can't demonstrate demand through new apps until their ISP deploys. Tony From owner-v6ops@ops.ietf.org Tue Sep 24 16:22:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11406 for ; Tue, 24 Sep 2002 16:22:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17twCV-00065p-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 13:22:31 -0700 Received: from [63.175.42.195] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 17twCR-000651-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 13:22:27 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17twCO-0000Na-00; Tue, 24 Sep 2002 13:22:24 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Tony Hain" Cc: v6ops@ops.ietf.org Subject: RE: ocean: do not boil References: <000001c26402$6e552060$011aa8c0@eagleswings> Message-Id: Date: Tue, 24 Sep 2002 13:22:24 -0700 X-Spam-Status: No, hits=2.0 required=5.0 tests=RCVD_IN_OSIRUSOFT_COM version=2.31 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So all content sites are held hostage until their ISP gets around > to providing IPv6 service... nice hyperventilation. but if you'll look at the beginning of this thread, the basic idea is that we should not try to provide v4<->v6 access to *all* services. in fact, i listed the service(s) which _must_ be interoperable. >> a content site is not a 'consumer'. they are provdng a >> servce. if they want to provide the service, they need >> things like mains power, the appropriate ip service(s), etc. > This model precludes any consumer from providing content. > Specifically it precludes any peer-to-peer applications. I > realize that many ISPs currently don't like the idea of a > consumer hosting personal web or mail services, but their > business practice should not have any impact on the range of > technology standards we are developing. no, but nice emotional appeal. those evil isps just won't let good red-blooded amurikans do anything. we should put them in jail. it merely says that when you decide to provide a service you must have the tools to provide it. if you want to provide email service, you need smtp, not http. if you want folk to access your server over tv, you need to put it on a tv service. if you want it on v4, you need to put it on v4. same for v6. > I can understand the desire to sort and prioritize to manage resource > constraints, but at the moment I see an abundance of people willing to > work on the problems. there is an abundance of people willing to make careers at making a complex world to try to put marketing whitewash on the fact that it is still hard to have a merged v4/v6 infrastructure because o few vendors make the hardware o there is no motivation to move to v6 it's like the failing sales force going back to engineering for an endless list of features which they hope will sell the product. a good recipe for turning a failing sales force into a failing company. but this is the engineering department, and our task is to do our job prudently and properly. we need to make sure that the *basic* and *critical* things needed to operate v6 in a v4 world can be done, and done reliably and scalably. randy From owner-v6ops@ops.ietf.org Tue Sep 24 16:43:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12047 for ; Tue, 24 Sep 2002 16:43:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17twVl-0007Kk-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 13:42:25 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17twVa-0007Js-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 13:42:14 -0700 Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA00518; Tue, 24 Sep 2002 13:41:31 -0700 (PDT) Message-Id: <5.1.0.14.2.20020924162446.01a62ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Sep 2002 16:39:22 -0400 To: From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "'Randy Bush'" , In-Reply-To: <000001c26402$6e552060$011aa8c0@eagleswings> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,AS_SEEN_ON version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Tony, > > yup. and if they want to be seen on broadband tv, they have > > to get broadband tv broadcast service. > >So all content sites are held hostage until their ISP gets around to >providing IPv6 service... Not necessarily. We have mechanisms, such as 6to4 and other tunneling mechanisms, that will allow sites with an IPv4-only ISP to obtain IPv6 service from a separate provider. For example, my ISP is IPv4-only, but I have IPv6 on my home network through a 6to4 gateway. I can use IPv4 to access IPv4 services, and IPv6 to see the dancing kame (the only IPv6-only service I've ever accessed). All this is accomplished without translation, and without the need for a v4-only node to access v6-only services or vice versa. > > > > no, the assumption is that, if you are providing a service > > you have the service to provide. > >In other words, the edge sites can't use any tunneling technologies >because those aren't 'provided', and when the provider gets around to it >there will be an IPv6 network service that is contiguous. One of us must be misunderstanding what Randy is saying... When did he say that you "can't use tunneling technologies"? >I am not the one trying to prejudge the market needs. Since we know that >some of the transition technologies will be complex, why are we >concerned about their existence? The simplest mechanism to solve the >deployment problems will become predominate through natural selection. >If there are a substantial number of networks that can't use the >predominate tool, and we have precluded them from deploying because we >didn't finish the tool that would work, have we done proper engineering? It isn't proper engineering to build a complex solution when a simple solution exists, particularly if the complex solution will have long-lived architectural consequences. >Personally I will not be spending a lot of my time on translation tools, >as I tell my customers that the translation approach should be looked at >as a last resort. That said, there have been cases where those customers >are stuck at that last resort point, so I a glad there are people in the >wg who want to work out the details. What are the cases where customers are stuck at this last resort point? How are translation tools easier, cheaper or better to deploy in those situations than running IPv4 and IPv6 in parallel? >The process of declaring those >situations out of scope... There is a big difference between suggesting that something may not be needed and "declaring it out of scope". We have at least one translation tool in our charter (NAT-PT), so no one has declared them out-of-scope for this WG. Or, at least if they have, they haven't told me :-). What are the technical reasons why it would ever be the best choice to use a IPv4<->IPv6 translation tool? Bob Hinden raised the suggestion that we might want folks to be able to build IPv6-only equipment, but still have that equipment access IPv4 services. That may be an interesting longer-term cases. At the moment, though, does anyone even ship a stack that can be built in an IPv6-only configuration? >at this point is telling sites that want to >deploy IPv6 that they need to deploy an IPv4 network, even when they >only want occasional access to the existing public Internet. Right. And, why is that worse than deploying IPv6<->IPv4 translation? Maybe there is a good reason why it is worse... I just don't know what it is. Margaret From owner-v6ops@ops.ietf.org Tue Sep 24 19:09:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14839 for ; Tue, 24 Sep 2002 19:09:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tymf-000FlU-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 16:08:01 -0700 Received: from dhcp4.kurtis.pp.se ([195.43.225.73] helo=laptop.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #1) id 17tymc-000FlH-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 16:07:58 -0700 Received: from laptop.kurtis.pp.se (localhost [127.0.0.1]) by laptop.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id g8ON7gNr007083; Wed, 25 Sep 2002 01:07:48 +0200 (CEST) Date: Tue, 24 Sep 2002 18:06:28 +0200 Subject: Re: unmanaged solutions comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: v6ops@ops.ietf.org To: owens@nysernet.org From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <952C38D6-CFD7-11D6-B153-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,DATE_IN_PAST_06_12 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Perhaps I'm misunderstanding you, but I would expect that any tunnel > between the same two endpoints would follow the same underlying path, > regardless of how it was set up. Everything is driven by the > destination > IPv4 address, after all. Unless you have some sort of traffic > engineering > going on, but that's always an exception case. > During the lifetime of a tunnel the underlaying path can change due to policy or failures (or even restorations), without it affecting the functionality of the tunnel as that is based on the IPv4 end-point, just as you point out. Best regards, - kurtis - From owner-v6ops@ops.ietf.org Tue Sep 24 19:18:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15022 for ; Tue, 24 Sep 2002 19:18:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tyyT-000GRv-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 16:20:13 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17tyyP-000GRc-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 16:20:09 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 24 Sep 2002 16:20:12 -0700 Reply-To: From: "Tony Hain" To: "'Randy Bush'" Cc: Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 16:20:01 -0700 Message-ID: <009d01c26420$e885a940$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15022 Randy Bush wrote: > > So all content sites are held hostage until their ISP gets > around to > > providing IPv6 service... > > nice hyperventilation. but if you'll look at the beginning > of this thread, the basic idea is that we should not try to > provide v4<->v6 access to *all* services. in fact, i listed > the service(s) which _must_ be interoperable. > So we should provide application proxies for the services that we know work through IPv4 NAT. More to the point though, the *only* services we should be worried about are the ones that are important to ISPs. If it is useful to an end site, but not to an ISP it doesn't matter. > >> a content site is not a 'consumer'. they are provdng a > >> servce. if they want to provide the service, they need > >> things like mains power, the appropriate ip service(s), etc. > > This model precludes any consumer from providing content. > Specifically > > it precludes any peer-to-peer applications. I realize that > many ISPs > > currently don't like the idea of a consumer hosting personal web or > > mail services, but their business practice should not have > any impact > > on the range of technology standards we are developing. > > no, but nice emotional appeal. those evil isps just won't > let good red-blooded amurikans do anything. we should put > them in jail. > > it merely says that when you decide to provide a service you > must have the tools to provide it. if you want to provide > email service, you need smtp, not http. if you want folk to > access your server over tv, you need to put it on a tv > service. if you want it on v4, you need to put it on v4. > same for v6. So now I am confused. Is the tool set we defined for providing IPv6 service, even when intermediate ISPs do not, in scope or out? How does the end node know when the IPv6 service it sees is based on a real underlying ISP service, or is simply a translated service? Outside of NAT application issues, why should it know if the service is live or translated? > > > I can understand the desire to sort and prioritize to > manage resource > > constraints, but at the moment I see an abundance of people > willing to > > work on the problems. > > there is an abundance of people willing to make careers at > making a complex world to try to put marketing whitewash on > the fact that it is still hard to have a merged v4/v6 > infrastructure because > o few vendors make the hardware > o there is no motivation to move to v6 > > it's like the failing sales force going back to engineering > for an endless list of features which they hope will sell the > product. a good recipe for turning a failing sales force into > a failing company. > > but this is the engineering department, and our task is to do > our job prudently and properly. we need to make sure that > the *basic* and *critical* things needed to operate v6 in a > v4 world can be done, and done reliably and scalably. Fine, but this didn't answer where the constrained resource is, and there appear to be different viewpoints on what the scope of the IPv4 world is. If the scope of the working group is restricted to only those things that are critical for an ISP to deploy service, we will be seeing a much longer transition period, and possibly an outright failure to get IPv6 deployed. If on the other hand the IPv4 world includes the edge sites, we have a much larger set of tools that are basic and critical. In particular for those sites who have had requests for public IPv4 address space turned down so they decide to go straight to IPv6 to avoid a messy 1918/nat deployment & transition, are they restricted to web and mail proxies? Tony > > randy > From owner-v6ops@ops.ietf.org Tue Sep 24 20:04:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15625 for ; Tue, 24 Sep 2002 20:04:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tzgf-000IWy-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 17:05:53 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17tzgc-000IWn-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 17:05:50 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 854F818A2 for ; Tue, 24 Sep 2002 20:05:46 -0400 (EDT) Date: Tue, 24 Sep 2002 20:05:46 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-Reply-To: <009d01c26420$e885a940$011aa8c0@eagleswings> References: <009d01c26420$e885a940$011aa8c0@eagleswings> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020925000546.854F818A2@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Tony, I'm puzzled by your apparent belief that the IETF should be developing solutions to circumvent bad ISPs. Depending on the market environment in which such an ISP operates, this is either a regulatory problem for the ISP's captive market or a case of evolution in action. If there's a problem here that'd be in scope for an IETF working group, please tell me what it is, because it's not obvious to me. From owner-v6ops@ops.ietf.org Tue Sep 24 20:20:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15888 for ; Tue, 24 Sep 2002 20:20:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17tzva-000J01-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 17:21:18 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17tzvT-000Izg-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 17:21:12 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 24 Sep 2002 17:21:09 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" Cc: "'Randy Bush'" , Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 17:20:58 -0700 Message-ID: <00a801c26429$6c2c8950$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5.1.0.14.2.20020924162446.01a62ec0@mail.windriver.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-1.2 required=5.0 tests=IN_REP_TO,AS_SEEN_ON version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA15888 Margaret Wasserman wrote: > > > yup. and if they want to be seen on broadband tv, they > have to get > > > broadband tv broadcast service. > > > >So all content sites are held hostage until their ISP gets around to > >providing IPv6 service... > > Not necessarily. We have mechanisms, such as 6to4 and other > tunneling mechanisms, that will allow sites with an IPv4-only > ISP to obtain IPv6 service from a separate provider. > You have not been reading Randy's messages closely: ... if i want my web site seen by both v4 and v6 users, then i can connect it to v4 and v6 space and run dual stack. ... ... if they want to provide the service, they need things like mains power, the appropriate ip service ... ...if you want folk to access your server over tv, you need to put it on a tv service. if you want it on v4, you need to put it on v4. same for v6 ... his stated premise is precluding generic IPv4-only to IPv6-only translation, but he is continually casting that in the realm of the unrealistic scenario where everyone simply subscribes to an IPv6 service. > For example, my ISP is IPv4-only, but I have IPv6 on my home > network through a 6to4 gateway. I can use IPv4 to access > IPv4 services, and IPv6 to see the dancing kame (the only > IPv6-only service I've ever accessed). All this is > accomplished without translation, and without the need for a > v4-only node to access v6-only services or vice versa. > I presume you do this for the same reason I do, you can't subscribe to an IPv6 service. In our cases we appear to be some of the lucky few with public IPv4 addresses so we can make 6to4 work. For all those stuck behind an ISP nat, their only hope is an IPv6 over UDP/IPv4, but that is not "critical" to an ISPs perspective on what it takes to deploy IPv6, but is absolutely so for the site connected to an ISP with a glacial pace. In any case, you haven't gotten to the point where you have an IPv6-only device that needs to talk to the IPv4-only printer that the vendor will refuse to build an IPv6 stack for. When you do you will find that bouncing everything through a dual-stack print server works, but leaves the IPv6-only device with a different view of the printer than the rest of the nodes. > > > > > > no, the assumption is that, if you are providing a > service you have > > > the service to provide. > > > >In other words, the edge sites can't use any tunneling technologies > >because those aren't 'provided', and when the provider gets > around to > >it there will be an IPv6 network service that is contiguous. > > One of us must be misunderstanding what Randy is saying... > > When did he say that you "can't use tunneling technologies"? When he repeatedly slipped in the requirement that anyone wanting to export an application over IPv6 needs to subscribe to an IPv6 service. > > >I am not the one trying to prejudge the market needs. Since we know > >that some of the transition technologies will be complex, why are we > >concerned about their existence? The simplest mechanism to solve the > >deployment problems will become predominate through natural > selection. > >If there are a substantial number of networks that can't use the > >predominate tool, and we have precluded them from deploying > because we > >didn't finish the tool that would work, have we done proper > >engineering? > > It isn't proper engineering to build a complex solution when > a simple solution exists, particularly if the complex > solution will have long-lived architectural consequences. The whole world is a nail when you have a simple hammer... The point is that the simple approach *will not* solve all of the problems. It isn't proper engineering to ignore a large part of the problem space simply because a tool exists to solve the easiest pieces. > > >Personally I will not be spending a lot of my time on translation > >tools, as I tell my customers that the translation approach > should be > >looked at as a last resort. That said, there have been cases where > >those customers are stuck at that last resort point, so I a > glad there > >are people in the wg who want to work out the details. > > What are the cases where customers are stuck at this last > resort point? I can't go into details, but one decide to go there to avoid building a fresh IPv4/nat network, only to convert it to IPv6 on or before completion. The other is a case I was working on today where a customer was sold a bill of goods about dual-stack end systems being more complex and unstable by another supplier. All I can do in these cases is point out what is required to make it work, and what costs would go away if they could figure out a dual-stack deployment. > > How are translation tools easier, cheaper or better to deploy > in those situations than running IPv4 and IPv6 in parallel? Both of the cases I have been involved in are fresh networks with over 500,000 end systems. It is very hard to argue that deploying IPv4/nat at that scale is cheaper than deploying nat-pt. > > >The process of declaring those > >situations out of scope... > > There is a big difference between suggesting that something > may not be needed and "declaring it out of scope". We have > at least one translation tool in our charter (NAT-PT), so no > one has declared them out-of-scope for this WG. Or, at least > if they have, they haven't told me :-). > >> let's not go there How else do you read that? Particularly when the current problem space is being documented, but still incomplete. How do we know what is not needed? > What are the technical reasons why it would ever be the best > choice to use a IPv4<->IPv6 translation tool? When it is not worth the cost to upgrade a machine that will be thrown away once it is fully amortized, but the service it provides needs to be accessed from new IPv6-only nodes. I am sure someone will argue that an application specific proxy could be built, but why would we require everyone to build a unique proxy when we could finish a generic translation tool, but refuse to because it is not critical to an ISPs view of a deployment. > > Bob Hinden raised the suggestion that we might want folks to > be able to build IPv6-only equipment, but still have that > equipment access IPv4 services. That may be an interesting > longer-term cases. At the moment, though, does anyone even > ship a stack that can be built in an IPv6-only configuration? Just because it is not public doesn't mean it doesn't exist. If the wg is going to have such a short term focus that it can only deal with the network that will exist in the next 6 months, there will be chaos. > > >at this point is telling sites that want to > >deploy IPv6 that they need to deploy an IPv4 network, even when they > >only want occasional access to the existing public Internet. > > Right. And, why is that worse than deploying IPv6<->IPv4 translation? > > Maybe there is a good reason why it is worse... I just don't > know what it is. > If you have to deploy translation anyway, why take a giant step backward that will have to be retraced in short order? The people building these networks are trying to do prudent engineering, and their cost minimum is coming out in a much different place. Rather than recognize that difference and deal with it, the approach appears to be to claim the IETF knows better, so figure out how to use our simple hammer to screw in your light bulb. Tony > Margaret > > > From owner-v6ops@ops.ietf.org Tue Sep 24 20:53:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16589 for ; Tue, 24 Sep 2002 20:53:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u0SP-000K2f-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 17:55:13 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17u0SH-000K2T-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 17:55:05 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8P0rX027067; Tue, 24 Sep 2002 20:53:35 -0400 (EDT) Message-Id: <200209250053.g8P0rX027067@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: alh-ietf@tndh.net cc: "'Margaret Wasserman'" , "'Randy Bush'" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Tue, 24 Sep 2002 17:20:58 PDT.") <00a801c26429$6c2c8950$011aa8c0@eagleswings> Date: Tue, 24 Sep 2002 20:53:33 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > his stated premise is precluding generic IPv4-only to IPv6-only > translation, but he is continually casting that in the realm of the > unrealistic scenario where everyone simply subscribes to an IPv6 > service. there's no such thing as generic IPv4-only to IPv6-only translation, there are only mechanisms that work for subsets of apps. for instance, most p2p apps will not work properly through such mechanisms. those that do work only because they have bought into a huge amount of complexity. Keith From owner-v6ops@ops.ietf.org Tue Sep 24 21:30:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17160 for ; Tue, 24 Sep 2002 21:30:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u119-000LB3-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 18:31:07 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17u116-000LAp-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 18:31:04 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 24 Sep 2002 18:31:07 -0700 Reply-To: From: "Tony Hain" To: "'Rob Austein'" , Subject: RE: ocean: do not boil Date: Tue, 24 Sep 2002 18:30:55 -0700 Message-ID: <00b501c26433$3211eb20$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20020925000546.854F818A2@thrintun.hactrn.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA17160 Rob Austein wrote: > Tony, I'm puzzled by your apparent belief that the IETF > should be developing solutions to circumvent bad ISPs. > Depending on the market environment in which such an ISP > operates, this is either a regulatory problem for the ISP's > captive market or a case of evolution in action. > I never claimed they were bad ISPs. On the contrary, they are the ones that are most likely to succeed because the business side of the house is not going to allow the engineers to arbitrarily swap out equipment just to get the latest protocol. You might argue that we the IETF know this protocol is for the greater good, but until it is required by regulation, or lack of it starts seriously impacting revenue, the existing box will stay. This is not bad, just a reality to be addressed. > If there's a problem here that'd be in scope for an IETF > working group, please tell me what it is, because it's not > obvious to me. > The IETF defined a protocol to move us beyond the addressing constraints of what we have today. We started down the path to create tools to allow organizations to move to this protocol at their own pace, with minimal interdependencies, and the express goal that this would avoid a flag day. We focused on the approach that would have the biggest payoff first, recognizing there would need to be additional tools to fill the holes. Unfortunately now that we have the simple tool, we are being told that is all we need and the minimal interdependencies goal is absolutely unimportant. Our only goal now is to make sure we have completely polished the tools for a core-out approach. Never mind there is no substantial business driver for that approach to work. We are not here to do marketing, but we have to at least understand the money flow enough to understand which technical approaches are doomed to fail for non-technical reasons. Since the end site is the origin of the money, it should follow that approaches that satisfy that need first and incrementally grow will be viable. If we insist that massive multi-party infrastructure upgrades have to happen first, where is the income that justifies the expense? (if someone knows please tell me because a boat load of customers have asked) Since it will likely lag the buildout expense by several years, will the ISP chain still be viable businesses by then? So to get directly to your question, what is in scope of the v6ops wg? If it is only the set of tools that an ISP needs to build out today, how does that fit the reality? If we require sites to subscribe to a non-existant IPv6 service and refuse to provide standard tunnel or nat tools, where is the incentive for an app provider to bother with IPv6? Basically my point is that we need to finish the scenario descriptions and agree as a wg that these represent the problems that need to be solved. Declaring a class of problems out of scope before that happens is procedurally possible, but will lead to an incomplete set of tools and possibly failure of the protocol to gain market acceptance. Tony From owner-v6ops@ops.ietf.org Tue Sep 24 21:43:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17683 for ; Tue, 24 Sep 2002 21:43:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u1Ez-000LZB-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 18:45:25 -0700 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by psg.com with esmtp (Exim 3.36 #1) id 17u1Ew-000LYz-00; Tue, 24 Sep 2002 18:45:22 -0700 Message-ID: <014901c26435$05840e60$806015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Hesham Soliman \(EAB\)" , "Margaret Wasserman" Cc: "'Brian E Carpenter'" , "Hesham Soliman \(EAB\)" , "'Bob Hinden'" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , References: <5.1.0.14.2.20020924095519.0202a260@mail.windriver.com> Subject: Re: ocean: do not boil Date: Tue, 24 Sep 2002 18:43:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Now what are the possible solutions to that scenario? > > We could say that the best solution for this scenario is to install > a NAT-PT-like box at the border of SiteA, modify the resolver in > HostA (or the DNS server for SiteA) so that HostA will receive special > IPv4-mapped addresses instead of A records for IPv4-only hosts, > insert special routes to send packets to those addresses to the > NAT-PT-like box, and translate traffic to those addresses from > IPv6->IPv4 at the border of SiteA. > > We could say that the NAT-PT-like box should be installed at the > border of SiteB, AAAA DNS entries should be advertised for the > IPv4-only hosts within SiteB, routes should be advertised to cause > IPv6 traffic to those addresses to come to NAT-PT-like box on the > border of SiteB, and packets will be translated from IPv6->IPv4 > at that border. > > Or, we could simply suggest that, if people want to reach IPv4-only > services from a given host, they should support IPv4 connectivity to > that host. This would mean installing a dual-stack on HostA and > providing IPv4 connectivity (perhaps via NAT if IPv4 address space is > an issue) within SiteA. > > We can suggest any one of these solutions, and people are, of course, > entitled to ignore us. Given the choice between these three, though, > the third one seems simpler and less prone to introducing new > architectural and application-level issues, since the IPv4 infrastructure > would be exactly the same as what many people are using today. Shouldn't we also be considering how any of these choices effect the overall IPv6 transition of the Internet? Gradually we'd like to see IPv6 replace IPv4, right? So, if we marry the existence of an IPv6 instance to existance of a matching IPv4 instance, how are we going to see Internet's transition to IPv6... If we pick the 3rd choice, we cannot really have IPv6-only hosts. When can we have one? Maybe as soon as IPv6 has a critical mass and some of those hosts declare IPv4 Internet is not worth the access...? This choice also keeps the pressure on the IPv4 address demand and the complexity to handle them.. I think deployment of IPv6->IPv4 (IPv6 connecting to IPv4) will expedite the IPv6 transition of the Internet... "Co-existence" of IPv6 in the current Internet is the must-have first step, but "transition" of Internet to IPv6 is the ultimate goal.. (unless we want to live with IPv4 forever, and create an alternate/parallel universe of IPv6..) alper From owner-v6ops@ops.ietf.org Tue Sep 24 22:32:54 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18704 for ; Tue, 24 Sep 2002 22:32:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u1zd-000MRf-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 19:33:37 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17u1zZ-000MRT-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 19:33:34 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5C1E54B22; Wed, 25 Sep 2002 11:33:32 +0900 (JST) To: "Alper E. YEGIN" Cc: v6ops@ops.ietf.org In-reply-to: alper's message of Tue, 24 Sep 2002 18:43:55 MST. <014901c26435$05840e60$806015ac@AlperVAIO> 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: ocean: do not boil From: itojun@iijlab.net Date: Wed, 25 Sep 2002 11:33:32 +0900 Message-Id: <20020925023332.5C1E54B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Shouldn't we also be considering how any of these choices effect the >overall IPv6 transition of the Internet? Gradually we'd like to see IPv6 >replace IPv4, right? So, if we marry the existence of an IPv6 instance >to existance of a matching IPv4 instance, how are we going to see >Internet's transition to IPv6... If we pick the 3rd choice, we cannot >really >have IPv6-only hosts. When can we have one? Maybe as soon as >IPv6 has a critical mass and some of those hosts declare IPv4 Internet >is not worth the access...? > >This choice also keeps the pressure on the IPv4 address demand and >the complexity to handle them.. > >I think deployment of IPv6->IPv4 (IPv6 connecting to IPv4) will >expedite the IPv6 transition of the Internet... "Co-existence" of IPv6 in >the current Internet is the must-have first step, but "transition" of >Internet >to IPv6 is the ultimate goal.. (unless we want to live with IPv4 forever, >and create an alternate/parallel universe of IPv6..) it's just like we have transitioned from closed TSS systems like compuserve to IP. we will eventually see services available only over IPv6, IPv4 services (as a collective means) become less attractive, and people will less motivated to maintain their IPv4 connection. then IPv4 will gradually cease. so yes, IPv4/v6 dual stack age could be very long. it will take a long time until all IPv4-capable-and-configured devices go away. (speaking of codebase, IPv4 code will stay forever in the kernel. in fact, we still have ISO/CCITT protocol stack in NetBSD and such...) itojun From owner-v6ops@ops.ietf.org Tue Sep 24 23:02:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19399 for ; Tue, 24 Sep 2002 23:02:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u2Sp-000N0V-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 20:03:47 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17u2Sh-000N0G-00; Tue, 24 Sep 2002 20:03:39 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8P324027343; Tue, 24 Sep 2002 23:02:04 -0400 (EDT) Message-Id: <200209250302.g8P324027343@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Alper E. YEGIN" cc: "Hesham Soliman \(EAB\)" , "Margaret Wasserman" , "'Brian E Carpenter'" , "'Bob Hinden'" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Tue, 24 Sep 2002 18:43:55 PDT.") <014901c26435$05840e60$806015ac@AlperVAIO> Date: Tue, 24 Sep 2002 23:02:04 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Gradually we'd like to see IPv6 replace IPv4, right? sometimes I think this is actually a non-goal. or at least I think it's more constructive to think in terms of migrating different classes of applications separately. some apps will never run on IPv4, and some apps may run on IPv4 essentially "forever", even though the normal case may eventually to talk to them using IPv4-over-IPv6 tunnels over an entirely IPv6 network. Keith From owner-v6ops@ops.ietf.org Tue Sep 24 23:52:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20354 for ; Tue, 24 Sep 2002 23:52:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u3Da-000Nhd-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 20:52:06 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17u3DP-000NhS-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 20:51:55 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8P3prKV023961; Wed, 25 Sep 2002 05:51:53 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 25 Sep 2002 05:51:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A4C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'itojun@iijlab.net'" Cc: v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 05:51:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > it's just like we have transitioned from closed TSS systems like > compuserve to IP. we will eventually see services > available only > over IPv6, IPv4 services (as a collective means) become > less attractive, > and people will less motivated to maintain their IPv4 > connection. > then IPv4 will gradually cease. > so yes, IPv4/v6 dual stack age could be very long. it will take > a long time until all IPv4-capable-and-configured > devices go away. > > (speaking of codebase, IPv4 code will stay forever in > the kernel. > in fact, we still have ISO/CCITT protocol stack in > NetBSD and such...) > => I think we're drifting from the main issue a little bit. Here is a scenario that I'd like to understand how it would work: What do we recommend a new small 3g operator who only has 10 million subscribers (just a small town in china!) and wants to allow people to run p2p apps: a. Run a dual network with 1918 addresses b. Just run an IPv6 network If people want to do a), do you really think this would be simpler than b) ? Easier to manage and operate? Hesham From owner-v6ops@ops.ietf.org Wed Sep 25 01:37:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22317 for ; Wed, 25 Sep 2002 01:37:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u4qM-000OyT-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 22:36:14 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17u4qG-000Oy9-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 22:36:08 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D67C74B24; Wed, 25 Sep 2002 14:35:57 +0900 (JST) To: "Hesham Soliman (EAB)" Cc: v6ops@ops.ietf.org In-reply-to: hesham.soliman's message of Wed, 25 Sep 2002 05:51:51 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0A4C@Esealnt861.al.sw.ericsson.se> 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: ocean: do not boil From: itojun@iijlab.net Date: Wed, 25 Sep 2002 14:35:57 +0900 Message-Id: <20020925053557.D67C74B24@coconut.itojun.org> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >=> I think we're drifting from the main issue >a little bit. Here is a scenario that I'd like >to understand how it would work: >What do we recommend a new small 3g operator who only >has 10 million subscribers (just a small town >in china!) and wants to allow people to run p2p apps: > >a. Run a dual network with 1918 addresses >b. Just run an IPv6 network > >If people want to do a), do you really think >this would be simpler than b) ? Easier to manage >and operate? "10 million subscriber" scenario is nontrivial by nature. for (a), 10.0.0.0/8 space only servers 17 million subscribers (theoretical maximum), and since address alloation efficiency is not that good, you can't have a single NAT cloud. you need to split customers into multiple NAT clouds (also I don't think any single NAT box can take traffic from 10 million subscribers). even for (b), I don't think single NAT-PT box (Alain, forget about DNSSEC for now) can take traffic from 10 million subscribers, so we at least need to split NAT-PT load to multiple NAT-PT box somehow. (i assume the customers will want to use IPv4-only yahoo.com.cn, right?) so if we need to take a pick, it is between (a) IPv4 multiple NAT cloudm and global IPv6, or (b) global IPv6 and multiple NAT-PT. itojun From owner-v6ops@ops.ietf.org Wed Sep 25 01:40:37 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22363 for ; Wed, 25 Sep 2002 01:40:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u4wC-000P20-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 22:42:16 -0700 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17u4w9-000P1p-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 22:42:13 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8P5gBKV004673; Wed, 25 Sep 2002 07:42:11 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 25 Sep 2002 07:42:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A53@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'itojun@iijlab.net'" , "Hesham Soliman (EAB)" Cc: v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 07:42:11 +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.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk > "10 million subscriber" scenario is nontrivial by nature. > > for (a), 10.0.0.0/8 space only servers 17 million subscribers > (theoretical maximum), and since address alloation > efficiency is not > that good, you can't have a single NAT cloud. you need to split > customers into multiple NAT clouds (also I don't think > any single > NAT box can take traffic from 10 million subscribers). > > even for (b), I don't think single NAT-PT box (Alain, > forget about > DNSSEC for now) can take traffic from 10 million > subscribers, so we > at least need to split NAT-PT load to multiple NAT-PT > box somehow. > (i assume the customers will want to use IPv4-only > yahoo.com.cn, right?) > > so if we need to take a pick, it is between (a) IPv4 > multiple NAT cloudm and global IPv6, or (b) global IPv6 and > multiple NAT-PT. => Fully agree. But there is a big difference: The multiple NAT-PT cloud will not having overlapping addresses, which makes for a simpler routing. Hesham > > itojun > From owner-v6ops@ops.ietf.org Wed Sep 25 02:15:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02201 for ; Wed, 25 Sep 2002 02:15:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u5SJ-000PRV-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 23:15:27 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17u5SD-000PRK-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 23:15:21 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AC49F438E; Wed, 25 Sep 2002 02:15:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 02:15:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: quality of v6 connections [Re: unmanaged scope comments] Date: Wed, 25 Sep 2002 02:15:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5B4@tayexc13.americas.cpqcorp.net> Thread-Topic: quality of v6 connections [Re: unmanaged scope comments] Thread-Index: AcJj2m3W2ctkHzPeTjuC4LDo/HHI/gAf4uNQ From: "Bound, Jim" To: "Pekka Savola" , "Margaret Wasserman" Cc: "Marc Blanchet" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 25 Sep 2002 06:15:18.0427 (UTC) FILETIME=[EBB706B0:01C2645A] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA02201 Pekka, > > From what I heard in our meeting, NTT has a "reasonably > global" commercial > > IPv6 backbone active in Asia, Europe and North America... > > Market speak, I'd say. You really mean't to say IMO or IN MY OPINION really? Otherwise your being insulting to NTT and the presenter? You have no right to say this in this manner at all. And NTT was the first ISP in North America I know personally to provide a production ISP service cause I was involved in help setting it up as a vendor. Your out of line in tone. And Margaret is correct addressing has everything to do with the execution of any routiug protocol whether ripng on a host for second ethernet, or mpls labels in a core switch, which derive an address for the path. Or on an ASIC fast path in hardware doing traffic analysis. If your saying that a production network cannot be defined by a prefix for routing or that peering is not solely determined by addresses your correct but to say addresses are not integral or inherent for routing I simply don't agree. /jim > From owner-v6ops@ops.ietf.org Wed Sep 25 02:15:17 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02379 for ; Wed, 25 Sep 2002 02:15:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u5Tl-000PSp-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 23:16:57 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17u5Te-000PSN-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 23:16:50 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 26187494C; Wed, 25 Sep 2002 02:16:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 02:16:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 02:16:49 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9372@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJj3VW4Zp1SksR+R0OfO77gjr+IkAAfbqyw From: "Bound, Jim" To: "Brian E Carpenter" , "Keith Moore" Cc: "Hesham Soliman (EAB)" , "Bob Hinden" , "Margaret Wasserman" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 25 Sep 2002 06:16:49.0905 (UTC) FILETIME=[223D7610:01C2645B] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA02379 If the v6ops even try to address this they are going to not be listened too. Its none of the IETFs business. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, September 24, 2002 11:13 AM > To: Keith Moore > Cc: Hesham Soliman (EAB); 'Bob Hinden'; Margaret Wasserman; > Randy Bush; > Bob Fink; Jun-ichiro itojun Hagino; v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > Keith Moore wrote: > > > > > > > p2p applications can be designed to use intermediaries, > > > > > just like SMTP and HTTP. If I was designing an apps > > > > > protocol today, I would definitely make sure it could > > > > > be relayed between address spaces at applications level. > > > > > > > > => Are we in a position to mandate this? > > > > > > > > > > This is the Internet, so no. But we (or if we were lucky the IAB) > > > could make an architectural recommendation. > > > > It would strike me as extremely bizarre for the IAB to recommend > > that P2P applications define their own addressing system and > > routing protocols when IPv6 offers reasonably good ones. > > Who said anything about a new address space or about routing? > > Obviously we are talking about scenarios where the basic dual stack > mechanism fails due to a connectivity gap. You then have two choices > - resolve this by the sort of network level complexity Margaret's > message refers to. > - resolve it at applications level. This may well involve an > applications level identifier namespace that works everywhere, > like URIs or RFC 2822, but it doesn't imply replacing the IP > locator namespace (a.k.a. addresses) or the IP routing system. > > I'm not suggesting that v6ops should work on this. But it's the > way distributed computing systems are very likely to go, in > self-defence. If the v6ops scenarios ignore this, they are incomplete. > > Brian > > From owner-v6ops@ops.ietf.org Wed Sep 25 02:16:46 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03657 for ; Wed, 25 Sep 2002 02:16:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u5VF-000PUQ-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 23:18:29 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17u5VC-000PU7-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 23:18:26 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id EE63958F9; Wed, 25 Sep 2002 02:18:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 02:18:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 02:18:25 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9373@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJj3XaDIJi/gGU6TQGc0+0qZ53ZoQAfboJA From: "Bound, Jim" To: "Brian E Carpenter" , "Hesham Soliman (EAB)" Cc: "Margaret Wasserman" , "Bob Hinden" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 25 Sep 2002 06:18:25.0771 (UTC) FILETIME=[5B6173B0:01C2645B] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA03657 Who is we? First Bank of USA, GM, AB Germany, Worldcom? I can't follow what "we" your referring to so I can respond? I am sure you don't me v6ops an IETF working group? We are not running a network? We have folks who build, run, deploy, them but for who? /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, September 24, 2002 11:15 AM > To: Hesham Soliman (EAB) > Cc: 'Margaret Wasserman'; 'Bob Hinden'; Randy Bush; Bob Fink; > Jun-ichiro > itojun Hagino; v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > "Hesham Soliman (EAB)" wrote: > > > > > > > > > > p2p applications can be designed to use intermediaries, > > > > > just like SMTP and HTTP. If I was designing an apps > > > > > protocol today, I would definitely make sure it could > > > > > be relayed between address spaces at applications level. > > > > > > > >=> Are we in a position to mandate this? > > > > > > We're not in a position to _mandate_ anything. However, we are > > > in a position to make recommendations about the best > way to resolve > > > certain scenarios. > > > > => I'm not trying to be -ve, but unless we mandate > > that all applications will use this model, or alternatively > > assume that HTTP and SMTP are the only important applications > > for the medium term there is no point eliminating the > > v6 -> v4 scenarios. > > I didn't suggest eliminating them. But since they will be even worse > to manage than IPv4 NAT, we should use them only when forced to. > > Brian > > From owner-v6ops@ops.ietf.org Wed Sep 25 02:22:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10349 for ; Wed, 25 Sep 2002 02:22:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u5ZW-000Pb8-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 23:22:54 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17u5ZT-000Pao-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 23:22:51 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id EB2409132; Wed, 25 Sep 2002 02:22:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 02:22:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 02:22:50 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9374@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJj4XyhILKxS88WQ2qTwyOWlANKAgAeiNRw From: "Bound, Jim" To: "Hesham Soliman (EAB)" , "Brian E Carpenter" Cc: "Margaret Wasserman" , "Bob Hinden" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 25 Sep 2002 06:22:50.0771 (UTC) FILETIME=[F9553E30:01C2645B] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA10349 We should not declare either. It is not IMO the working groups job to tell user how to deploy. One user will want to use NAT and the other will want to use DS. Our job is to make sure both are understood and the end results from both. This will truly help the user decide maybe. If we declare a specific mechanism as PS then we need to make sure it has no known protocol technical deficiencies. Then we have done our job. Anything else is absurd and borders on pure egomania. /jim > -----Original Message----- > From: Hesham Soliman (EAB) [mailto:hesham.soliman@era.ericsson.se] > Sent: Tuesday, September 24, 2002 11:44 AM > To: 'Brian E Carpenter' > Cc: 'Margaret Wasserman'; 'Bob Hinden'; Randy Bush; Bob Fink; > Jun-ichiro > itojun Hagino; v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > > > > > > > p2p applications can be designed to use > intermediaries, > > > > > > just like SMTP and HTTP. If I was designing an apps > > > > > > protocol today, I would definitely make sure it could > > > > > > be relayed between address spaces at > applications level. > > > > > > > > > >=> Are we in a position to mandate this? > > > > > > > > We're not in a position to _mandate_ anything. > > However, we are > > > > in a position to make recommendations about the best > > way to resolve > > > > certain scenarios. > > > > > > => I'm not trying to be -ve, but unless we mandate > > > that all applications will use this model, or alternatively > > > assume that HTTP and SMTP are the only important applications > > > for the medium term there is no point eliminating the > > > v6 -> v4 scenarios. > > > > I didn't suggest eliminating them. But since they will be > even worse > > to manage than IPv4 NAT, we should use them only when forced to. > > => I fully agree that this is something that should > only be used/deployed if people are forced to do > it. Translators in general are not pretty and don't > make life simpler, but are necessary sometimes. > What I'm not sure about is whether running a dual > network containing IPv6 (global) and IPv4 private addresses > is simpler than just running an IPv6 network with > v6 <=> v4 translators. > > Hesham > > > From owner-v6ops@ops.ietf.org Wed Sep 25 02:24:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13358 for ; Wed, 25 Sep 2002 02:24:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u5ct-000Pei-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 23:26:23 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17u5cp-000PeQ-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 23:26:19 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D2B682E2D; Wed, 25 Sep 2002 02:26:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 02:26:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 02:26:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9375@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJj5MzYTitCQKqUSkK8aX8vM72M7gAd2yZg From: "Bound, Jim" To: "Margaret Wasserman" , "Hesham Soliman (EAB)" Cc: "Hesham Soliman (EAB)" , "Brian E Carpenter" , "Hesham Soliman (EAB)" , "Bob Hinden" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 25 Sep 2002 06:26:18.0636 (UTC) FILETIME=[753AECC0:01C2645C] X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13358 Margaret, The piece that I think your missing is pretty simple really. The customer does not want a parallel IPv4 infrastructure and wants it removed as soon as possible. It only wants to permit access to IPv4 in a temporary mode or through NAT ( that will be the two customer choices). But to say we know best about this is not wise. We don't have a clue. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, September 24, 2002 12:09 PM > To: Hesham Soliman (EAB) > Cc: Hesham Soliman (EAB); 'Brian E Carpenter'; Hesham Soliman (EAB); > 'Bob Hinden'; Randy Bush; Bob Fink; Jun-ichiro itojun Hagino; > v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > > Hi Hesham, > > >=> I'm not trying to be -ve, > > I'm not sure what "-ve" means, but I'm certain that you > aren't trying to be it :-). > > >but unless we mandate > >that all applications will use this model, or alternatively > >assume that HTTP and SMTP are the only important applications > >for the medium term there is no point eliminating the > >v6 -> v4 scenarios. > > Which model? All widely deployed IPv4 applications work with > the existing IPv4 model. If that model continues to be the way > to reach IPv4 services (as I have suggested), there wouldn't > be any need to change existing IPv4 services. > > >Clearly (at least to me), it would be pointless to start > >making "recommendation for application layer protocol > >developers" in this group. This _is_ boiling the > >ocean IMHO. > > I agree. Requiring a application-layer proxy for each type > of application is not desirable. > > > > We can suggest any one of these solutions, and people are, > > > of course, > > > entitled to ignore us. Given the choice between these > > > three, though, > > > the third one seems simpler > > > >=> Can you please explain why it is "simpler" ? > > In my opinion, the use of parallel IPv4 and IPv6 infrastructure > is simpler than IPv4<->IPv6 translation, because it doesn't > require special support from the DNS system (either servers or > resolvers), doesn't require injection of routes for special > IPv6 address prefixes, and doesn't, inherently, require any > translation. > > Now, it is true that the IPv4 infrastructure may include a > NAT. But, even in those cases, the parallel use of IPv4 avoids > complexity in the DNS and routing tables. > > >and less prone to introducing new > > > architectural and application-level issues, > > > >=> What does this mean?`what architectural issues > >are reduced by v4 NATs? > > The use of parallel IPv4 and IPv6 infrastructure, even with > the use of IPv4 NATs, does not introduce any _new_ > architectural issues. Yes, there are some major architectural > issues with IPv4 NATs, but these issues are not new, and IPv4 > applications have already been modified/limited to work within > this type of environment. > > >since the IPv4 > > > infrastructure > > > would be exactly the same as what many people are using today. > > > >=> Margaret, please consider my concern: I am not talking > >about networks with _existing_ IPv4 infrastructures/NATs. > >I hope my intention is clear. I know that many ISPs > >already have v4 NATs and this is not the case I'm bringing > >up. > > Yes, I understand this, Hesham. > > But, I really do think that it would be wiser for a networ > operator to install parallel IPv4 and IPv6 infrastructure in a > new installation, if any of the nodes on their network will > need to access IPv4-only services. > > Installing an IPv4 NAT and DHCP server won't be any harder than > installing a v4<->v6 translator with DNS and routing tie-ins. You > won't need any more IPv4 addresses than you do in a v4<->v6 > translation model (you will always need a v4 address to access > a v4 service), and using a "normal" (by today's standards) > IPv4 infrastructure will result in fewer problems accessing > IPv4 applications and services. > > What am I missing? > > Margaret > > > > > From owner-v6ops@ops.ietf.org Wed Sep 25 02:45:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16829 for ; Wed, 25 Sep 2002 02:45:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u5vC-000Pzm-00 for v6ops-data@psg.com; Tue, 24 Sep 2002 23:45:18 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17u5v8-000PzY-00 for v6ops@ops.ietf.org; Tue, 24 Sep 2002 23:45:14 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B76AE6422; Wed, 25 Sep 2002 02:45:13 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 02:45:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 02:45:11 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9379@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJkISLtnHWn7jc6Tlisq7qPkIaJegAPbcGg From: "Bound, Jim" To: , "Randy Bush" Cc: X-OriginalArrivalTime: 25 Sep 2002 06:45:11.0926 (UTC) FILETIME=[18B94160:01C2645F] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA16829 Tony, Also add the commerical Intranets deploying IPv6. They will not have the same needs and in some cases far different needs than ISPs. If that is out of scope we need to support that elswhere than v6ops for transition. If that is the case we should declare that now. That would mean we don't care about the Enterprise too. Important assumptions and view points to bring up. Thanks for doing that. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Tuesday, September 24, 2002 7:20 PM > To: 'Randy Bush' > Cc: v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > Randy Bush wrote: > > > So all content sites are held hostage until their ISP gets > > around to > > > providing IPv6 service... > > > > nice hyperventilation. but if you'll look at the beginning > > of this thread, the basic idea is that we should not try to > > provide v4<->v6 access to *all* services. in fact, i listed > > the service(s) which _must_ be interoperable. > > > > So we should provide application proxies for the services that we know > work through IPv4 NAT. More to the point though, the *only* > services we > should be worried about are the ones that are important to ISPs. If it > is useful to an end site, but not to an ISP it doesn't matter. > > > >> a content site is not a 'consumer'. they are provdng a > > >> servce. if they want to provide the service, they need > > >> things like mains power, the appropriate ip service(s), etc. > > > This model precludes any consumer from providing content. > > Specifically > > > it precludes any peer-to-peer applications. I realize that > > many ISPs > > > currently don't like the idea of a consumer hosting > personal web or > > > mail services, but their business practice should not have > > any impact > > > on the range of technology standards we are developing. > > > > no, but nice emotional appeal. those evil isps just won't > > let good red-blooded amurikans do anything. we should put > > them in jail. > > > > it merely says that when you decide to provide a service you > > must have the tools to provide it. if you want to provide > > email service, you need smtp, not http. if you want folk to > > access your server over tv, you need to put it on a tv > > service. if you want it on v4, you need to put it on v4. > > same for v6. > > So now I am confused. Is the tool set we defined for providing IPv6 > service, even when intermediate ISPs do not, in scope or out? How does > the end node know when the IPv6 service it sees is based on a real > underlying ISP service, or is simply a translated service? Outside of > NAT application issues, why should it know if the service is live or > translated? > > > > > > I can understand the desire to sort and prioritize to > > manage resource > > > constraints, but at the moment I see an abundance of people > > willing to > > > work on the problems. > > > > there is an abundance of people willing to make careers at > > making a complex world to try to put marketing whitewash on > > the fact that it is still hard to have a merged v4/v6 > > infrastructure because > > o few vendors make the hardware > > o there is no motivation to move to v6 > > > > it's like the failing sales force going back to engineering > > for an endless list of features which they hope will sell the > > product. a good recipe for turning a failing sales force into > > a failing company. > > > > but this is the engineering department, and our task is to do > > our job prudently and properly. we need to make sure that > > the *basic* and *critical* things needed to operate v6 in a > > v4 world can be done, and done reliably and scalably. > > Fine, but this didn't answer where the constrained resource is, and > there appear to be different viewpoints on what the scope of the IPv4 > world is. If the scope of the working group is restricted to > only those > things that are critical for an ISP to deploy service, we > will be seeing > a much longer transition period, and possibly an outright > failure to get > IPv6 deployed. If on the other hand the IPv4 world includes the edge > sites, we have a much larger set of tools that are basic and critical. > In particular for those sites who have had requests for public IPv4 > address space turned down so they decide to go straight to > IPv6 to avoid > a messy 1918/nat deployment & transition, are they restricted > to web and > mail proxies? > > Tony > > > > > > > randy > > > > > From owner-v6ops@ops.ietf.org Wed Sep 25 03:11:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17422 for ; Wed, 25 Sep 2002 03:11:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u6Kn-0000a9-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 00:11:45 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17u6Kk-0000Zw-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 00:11:42 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6291B4331; Wed, 25 Sep 2002 03:11:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 03:11:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 03:11:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE937C@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJkViNWTvrwUoKcTY6rt+KT7kqtcwAC+tew From: "Bound, Jim" To: , "Hesham Soliman (EAB)" Cc: X-OriginalArrivalTime: 25 Sep 2002 07:11:41.0072 (UTC) FILETIME=[CBEDB100:01C26462] X-Spam-Status: No, hits=1.5 required=5.0 tests=DOUBLE_CAPSWORD,SUPERLONG_LINE version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17422 I inherently agree with avoiding NAT (that is what DSTM is all about). But I would like to hear discussion on Tony's mail to Rob. I think we have a serious issue to reach a group resolution on here and Tony has stated it very well. I believe we need to work on NAT and will work on it even though I don't like it and will avoid recommending it to any user I have to support. But I don't like what I am hearing from some here nor that all we care about are ISPs which is what I think I am hearing from some. Why is it some are saying "don't do as I do but do as I say". We were told that we needed the scenarios (and ISP is only one of them) to complete analysis. Yet I am hearing same proponents tell us we should select a default before we have them all worked out? This is not good folks. Or maybe I am missing intentions or assumptions? /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, September 25, 2002 1:36 AM > To: Hesham Soliman (EAB) > Cc: v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > >=> I think we're drifting from the main issue > >a little bit. Here is a scenario that I'd like > >to understand how it would work: > >What do we recommend a new small 3g operator who only > >has 10 million subscribers (just a small town > >in china!) and wants to allow people to run p2p apps: > > > >a. Run a dual network with 1918 addresses > >b. Just run an IPv6 network > > > >If people want to do a), do you really think > >this would be simpler than b) ? Easier to manage > >and operate? > > "10 million subscriber" scenario is nontrivial by nature. > > for (a), 10.0.0.0/8 space only servers 17 million subscribers > (theoretical maximum), and since address alloation > efficiency is not > that good, you can't have a single NAT cloud. you need to split > customers into multiple NAT clouds (also I don't think > any single > NAT box can take traffic from 10 million subscribers). > > even for (b), I don't think single NAT-PT box (Alain, > forget about > DNSSEC for now) can take traffic from 10 million > subscribers, so we > at least need to split NAT-PT load to multiple NAT-PT > box somehow. > (i assume the customers will want to use IPv4-only > yahoo.com.cn, right?) > > so if we need to take a pick, it is between (a) IPv4 > multiple NAT cloudm and global IPv6, or (b) global IPv6 and > multiple NAT-PT. > > itojun > > From owner-v6ops@ops.ietf.org Wed Sep 25 03:48:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18106 for ; Wed, 25 Sep 2002 03:48:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u6th-00013q-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 00:47:49 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17u6tc-00013d-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 00:47:45 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8P7lfn07059 for ; Wed, 25 Sep 2002 10:47:42 +0300 Date: Wed, 25 Sep 2002 10:47:41 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft on v6 firewalling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello, I've submitted an I-D on IPv6 firewalling issues, and it should be available in the repository shortly. In the meantime, it's available at: http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-firewalling-00.txt Below is the abstract: 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. It's 8 pages. Thanks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Wed Sep 25 03:49:26 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18147 for ; Wed, 25 Sep 2002 03:49:26 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u6ww-00016u-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 00:51:10 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17u6wt-00016i-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 00:51:07 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06249; Wed, 25 Sep 2002 00:51:05 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8P7p4A14641; Wed, 25 Sep 2002 09:51:04 +0200 (MEST) Date: Wed, 25 Sep 2002 09:48:33 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comment on unmanaged analysis presentation/doc To: Robert Elz Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <25397.1032864620@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > | But that means that 6to4 provides the ultimate packet laundering service > | for source address spoofing that a combination of IPv4 and IPv6 ingress > | filtering can not prevent. > > Not really any more than any other IP tunnel system does. Which (widely deployed) IP tunneling system accepts encapsulated packets from any source address, decapsulates them, and forwards then on based on the inner source address? > yes. Just as a pure IPv6 router will blindly pass on a native IPv6 > packet and loose all track of the IPv6 source (as does IPv4). The only You use "loose track" in a completely different meaning than I do. In the decapsulation case the IPv4 source address is not part of the packet that is forwarded, hence the victim can't inspect it. All the victim sees in a packet is an IPv6 source address which could be arbitrarely spoofed and can't be filtered because of this. A regular router (IPv6 or IPv4) passes on the packet unmodified. Hence ingress filtering doesn't become less useful. When decapsulation from arbitrary source addresses with out strong checks between the inner and outter source is deployed ingress filtering becomes completely ineffective. Erik From owner-v6ops@ops.ietf.org Wed Sep 25 04:43:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19378 for ; Wed, 25 Sep 2002 04:43:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u7lX-0001tB-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 01:43:27 -0700 Received: from [202.28.97.9] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.36 #1) id 17u7lM-0001sL-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 01:43:17 -0700 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g8P8gXJ13948; Wed, 25 Sep 2002 15:42:38 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g8P8gB703310; Wed, 25 Sep 2002 15:42:17 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Sep 2002 15:42:11 +0700 Message-ID: <3308.1032943331@munnari.OZ.AU> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Date: Wed, 25 Sep 2002 09:48:33 +0200 (CEST) From: Erik Nordmark Message-ID: | Which (widely deployed) IP tunneling system accepts encapsulated | packets from any source address, decapsulates them, and forwards then on | based on the inner source address? The mbone used to, though whether the implementations still act that way I'm not sure. | You use "loose track" in a completely different meaning than I do. | In the decapsulation case the IPv4 source address is not part of | the packet that is forwarded, hence the victim can't inspect it. But we're assuming spoofed source addresses, inspecting them is a waste of time. That the encapsulating packet might have once had a valid source address is irrelevant. | All the victim sees in a packet is an IPv6 source address which could | be arbitrarely spoofed and can't be filtered because of this. Exactly, which is always the case. Whether the packet was once encapsulated or not. | A regular router (IPv6 or IPv4) passes on the packet unmodified. | Hence ingress filtering doesn't become less useful. I now begin to suspect that you're using ingress filtering meaning something different than I thought. That is, are you implying that it is being done by the ISP near the source of the packets? Ingress filtering there would be defeated by tunneling (any kind) unless the filter looks inside the tunnel (which it certainly can for 6to4, unlike some other tunnels, as the content cannot be encrypted if it is to work). [Aside: when discussing filtering, please make explicit where you're expecting the filter to be installed - how effective/practical it will be will depend upon that, filtering at an unknown location is impossible to analyse]. But someone interested in source address spoofing doesn't connect to an ISP that does that kind of filtering - they just connect to one that doesn't (of which there are plenty). So, for any practical purpose, unless you could convince the whole world that they're required to do this kind of filtering, there is none of it that matters to take into account. So, it really doesn't matter that it would be ineffective, if it were applied, because when it matters, it isn't applied anyway. Beyond there (the ISPs near the sourve), filtering on source addresses is useless/impossible anyway (as protection against spoofing). The only real practical difference that 6to4 makes to any of this is the widely advertised anycast address for relay sites, so it is trivially easy for anyone to find a relay to use. For 6to4 that's a feature of course. For someone intent on using this relaying to achieve easier anonymous packets, I doubt it makes any difference. They'll find some node somewhere that will decapsulate and forward random packets in any case. That's what they do - find the unsuspecting victim. 6to4 relays probably aren't what they'd use by choice, because they (shouldn't be) unsuspecting, and are more likely to be monitoring what is happening, that some other random node that just happens to have decapsulation implemented but which no-one really understands. kre From owner-v6ops@ops.ietf.org Wed Sep 25 05:25:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20028 for ; Wed, 25 Sep 2002 05:25:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u8QO-0002W0-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 02:25:40 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17u8QE-0002VN-00; Wed, 25 Sep 2002 02:25:31 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8P9Ns028960; Wed, 25 Sep 2002 05:23:55 -0400 (EDT) Message-Id: <200209250923.g8P9Ns028960@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Brian E Carpenter" , "Keith Moore" , "Hesham Soliman (EAB)" , "Bob Hinden" , "Margaret Wasserman" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Wed, 25 Sep 2002 02:16:49 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B02BE9372@tayexc13.americas.cpqcorp.net> Date: Wed, 25 Sep 2002 05:23:54 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > If the v6ops even try to address this they are going to not be > listened too. Its none of the IETFs business. oh, that's silly. developing mechanisms to allow apps to cope with a mixture of v4 and v6 is certainly within IETF's business. the reason it won't be listened to is because having apps do their own addressing and routing is simply too difficult for most implementors. it will be easier to arrange for v6 everywhere (by shipping 6to4 and/or Teredo drivers with the app) than to build ad hoc networks at layer 7. Keith From owner-v6ops@ops.ietf.org Wed Sep 25 05:37:30 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20290 for ; Wed, 25 Sep 2002 05:37:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17u8cN-0002jD-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 02:38:03 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17u8cE-0002iy-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 02:37:54 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8P9ZI005750; Wed, 25 Sep 2002 05:35:18 -0400 (EDT) Message-Id: <200209250935.g8P9ZI005750@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (EAB)" cc: "'itojun@iijlab.net'" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Wed, 25 Sep 2002 05:51:51 +0200.") <4DA6EA82906FD511BE2F00508BCF0538044F0A4C@Esealnt861.al.sw.ericsson.se> Date: Wed, 25 Sep 2002 05:35:17 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I think we're drifting from the main issue > a little bit. Here is a scenario that I'd like > to understand how it would work: > What do we recommend a new small 3g operator who only > has 10 million subscribers (just a small town > in china!) and wants to allow people to run p2p apps: > > a. Run a dual network with 1918 addresses > b. Just run an IPv6 network > > If people want to do a), do you really think > this would be simpler than b) ? Easier to manage > and operate? I think they're going to want to run a dual network for the near future at least. but the dual network isn't going to help with most p2p apps - for the most part it's only going to work with two-party (client-server) apps. if a few p2p apps can make use of the dual network, so much the better, but p2p will use IPv6 as soon as it becomes a realistic option... which I think will be the case when either - hosts ship with 6to4 and Teredo, or the vendor can ship a driver for the above along with the app Keith From owner-v6ops@ops.ietf.org Wed Sep 25 09:55:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26259 for ; Wed, 25 Sep 2002 09:55:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uCcU-0007fS-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 06:54:26 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17uCcQ-0007fG-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 06:54:22 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13937; Wed, 25 Sep 2002 07:54:21 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8PDsKA03116; Wed, 25 Sep 2002 15:54:20 +0200 (MEST) Date: Wed, 25 Sep 2002 15:51:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comment on unmanaged analysis presentation/doc To: Robert Elz Cc: Erik Nordmark , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <3308.1032943331@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The mbone used to, though whether the implementations still act that > way I'm not sure. Not as I recall. The MBONE had the equivalent of RFC 2893 configured tunnels i.e. the receipient of a packet would verify the outer source address against peer addresses in the list of configured tunnels. Thus it didn't provide a wide open packet relay service like 6to4 relays. > I now begin to suspect that you're using ingress filtering meaning > something different than I thought. That is, are you implying that > it is being done by the ISP near the source of the packets? RFC 2267 is what defines ingress filtering for me. > Ingress > filtering there would be defeated by tunneling (any kind) unless the > filter looks inside the tunnel (which it certainly can for 6to4, unlike > some other tunnels, as the content cannot be encrypted if it is to > work). It can be defeated by tunneling but the issue is how easy it is for an attacker to get a 3rd party to serve as the other end of the tunnel. All deployed IP tunneling schemes I know of requires that the decapsulator be configured with the encapsulator's IP address. Thus an attacker would need a cooperating 3rd party. 6to4 relays don't require this. Hence they are qualitatively different in my mind when it comes to reducing the utility of ingress filtering. > But someone interested in source address spoofing doesn't connect to > an ISP that does that kind of filtering - they just connect to one that > doesn't (of which there are plenty). > > So, for any practical purpose, unless you could convince the whole world > that they're required to do this kind of filtering, there is none of it > that matters to take into account. So, it really doesn't matter that > it would be ineffective, if it were applied, because when it matters, it > isn't applied anyway. My understanding is that the use of ingress filtering, even though it has lots of holes, has made attackers largely stop using spoofed addresses. So I'm far from convinced that ingress filtering has zero utility as you seem to claim. And therefor I fail to see why IPv6 transition mechanisms should give that tool back to the attackers to use. Erik From owner-v6ops@ops.ietf.org Wed Sep 25 10:15:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27127 for ; Wed, 25 Sep 2002 10:15:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uCyG-0008GF-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 07:16:56 -0700 Received: from [63.175.42.11] (helo=reserve.guest-tek.com) by psg.com with esmtp (Exim 3.36 #1) id 17uCyB-0008G3-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 07:16:52 -0700 Received: from roam.psg.com (exim@[192.168.1.89]) by reserve.guest-tek.com (8.11.6/8.8.7) with ESMTP id g8PEJlG05122; Wed, 25 Sep 2002 07:19:48 -0700 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17uCy5-0000db-00; Wed, 25 Sep 2002 07:16:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Bound, Jim" Cc: "Margaret Wasserman" , "Hesham Soliman (EAB)" , "Brian E Carpenter" , "Bob Hinden" , "Bob Fink" , "Jun-ichiro itojun Hagino" , Subject: RE: ocean: do not boil References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9375@tayexc13.americas.cpqcorp.net> Message-Id: Date: Wed, 25 Sep 2002 07:16:45 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The piece that I think your missing is pretty simple really. The customer > does not want a parallel IPv4 infrastructure and wants it removed as soon > as possible. hypothesis: the customer does not care. they just want to get their job done. anecdotal evidence: the low adoption rate of any of this stuff. randy From owner-v6ops@ops.ietf.org Wed Sep 25 10:25:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27422 for ; Wed, 25 Sep 2002 10:25:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uD7j-0008Xg-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 07:26:43 -0700 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17uD7f-0008XS-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 07:26:39 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 37B19918; Wed, 25 Sep 2002 10:26:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 10:26:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 10:26:38 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9382@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJkdUrQO9sExI07RgCREElsBsoMOQAKggVg From: "Bound, Jim" To: "Keith Moore" Cc: "Brian E Carpenter" , "Hesham Soliman (EAB)" , "Bob Hinden" , "Margaret Wasserman" , "Randy Bush" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 25 Sep 2002 14:26:39.0029 (UTC) FILETIME=[8F85E650:01C2649F] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA27422 I agree in context usually. What I am saying is that users in this case cannot be told to use relays. Some may listen and some may not. Those that don't will ignore it. And I am not convinced we should be building relays in the IETF but I see your point. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, September 25, 2002 5:24 AM > To: Bound, Jim > Cc: Brian E Carpenter; Keith Moore; Hesham Soliman (EAB); Bob Hinden; > Margaret Wasserman; Randy Bush; Bob Fink; Jun-ichiro itojun Hagino; > v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > If the v6ops even try to address this they are going to not be > > listened too. Its none of the IETFs business. > > oh, that's silly. developing mechanisms to allow apps to > cope with a mixture > of v4 and v6 is certainly within IETF's business. > > the reason it won't be listened to is because having apps do > their own addressing > and routing is simply too difficult for most implementors. > it will be easier to > arrange for v6 everywhere (by shipping 6to4 and/or Teredo > drivers with the app) > than to build ad hoc networks at layer 7. > > > Keith > From owner-v6ops@ops.ietf.org Wed Sep 25 10:38:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27906 for ; Wed, 25 Sep 2002 10:38:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uDL0-0008z4-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 07:40:26 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17uDKw-0008yp-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 07:40:22 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2A4712FD0; Wed, 25 Sep 2002 10:40:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Sep 2002 10:40:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 10:40:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE9384@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJknm15bw0Jtf58TNm4m1ocufh45QAAmmdQ From: "Bound, Jim" To: "Randy Bush" Cc: "Margaret Wasserman" , "Hesham Soliman (EAB)" , "Brian E Carpenter" , "Bob Hinden" , "Bob Fink" , "Jun-ichiro itojun Hagino" , X-OriginalArrivalTime: 25 Sep 2002 14:40:22.0044 (UTC) FILETIME=[7A1405C0:01C264A1] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA27906 Hmmmm. This is important assumption discussion. > -----Original Message----- > From: Randy Bush [mailto:randy@iij.com] > Sent: Wednesday, September 25, 2002 10:17 AM > To: Bound, Jim > Cc: Margaret Wasserman; Hesham Soliman (EAB); Brian E Carpenter; Bob > Hinden; Bob Fink; Jun-ichiro itojun Hagino; v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > > The piece that I think your missing is pretty simple > really. The customer > > does not want a parallel IPv4 infrastructure and wants it > removed as soon > > as possible. > > hypothesis: the customer does not care. they just want to get their > job done. Don't agree. This is similar in engineering when architects tell me customers did not hire Computer Science or Software Engineering personnel that are capable of making very hard networking decisions and analysis for the enterprise. Many customer sites do have operation expertise and engineering expertise and do develop their own visions, strategies, etc about how they approach a large networking problem like IPv6. I have personally heard of customers telling me they believe it cheaper to kill off IPv4 as soon as possible. I think there are many customers that have this hypothesis. I go back to what Tony said we need to permit work and drive work that helps many customers. I don't know how many either way and cannot say. I am saying this case does exist. > > anecdotal evidence: the low adoption rate of any of this stuff. A lot of that now is the economy and the Internet bubble having burst. /jim > > randy > > > From owner-v6ops@ops.ietf.org Wed Sep 25 11:36:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29666 for ; Wed, 25 Sep 2002 11:36:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uEE1-000AWo-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 08:37:17 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uEDt-000AWT-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 08:37:09 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PFVx025699; Wed, 25 Sep 2002 11:31:59 -0400 (EDT) Message-Id: <200209251531.g8PFVx025699@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Robert Elz , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Wed, 25 Sep 2002 15:51:49 +0200.") Date: Wed, 25 Sep 2002 11:31:59 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I'm fairly convinced that ingress filtering needs to apply the same criteria to tunneled packets as are applied to non-tunneled packets. So if (e.g.) NFS is blocked at the router/firewall for v4, it needs to be blocked for 6to4 and native v6 also, unless the policy is to treat NFS traffic differently depending on v4 vs. v6. This implies that filters need to look inside type 41 IP packets. of course, it's dangerous to suggest this, because there will be a strong temptation to just block all type 41 packets - since presumably it's much easier to do that. Keith From owner-v6ops@ops.ietf.org Wed Sep 25 12:39:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02068 for ; Wed, 25 Sep 2002 12:39:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uFDD-000CSU-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 09:40:31 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17uFDA-000CSJ-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 09:40:28 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09904; Wed, 25 Sep 2002 09:40:26 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8PGeLA28405; Wed, 25 Sep 2002 18:40:22 +0200 (MEST) Date: Wed, 25 Sep 2002 18:37:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comment on unmanaged analysis presentation/doc To: Keith Moore Cc: Erik Nordmark , Robert Elz , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <200209251531.g8PFVx025699@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > I'm fairly convinced that ingress filtering needs to apply the same > criteria to tunneled packets as are applied to non-tunneled packets. > > So if (e.g.) NFS is blocked at the router/firewall for v4, it needs > to be blocked for 6to4 and native v6 also, unless the policy is > to treat NFS traffic differently depending on v4 vs. v6. > > This implies that filters need to look inside type 41 IP packets. > > of course, it's dangerous to suggest this, because there will be > a strong temptation to just block all type 41 packets - since > presumably it's much easier to do that. While such a scheme might work for protocol 41 packets, I don't see how it can be made to work for other tunnels, especially encrypted tunnels. Thus I think a simpler and more general approach is to require that nodes only decapsulate packets when they trust the sender. Erik From owner-v6ops@ops.ietf.org Wed Sep 25 12:43:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02196 for ; Wed, 25 Sep 2002 12:43:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uFHJ-000Cbj-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 09:44:45 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17uFHH-000CbY-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 09:44:43 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 9475B28B6E for ; Wed, 25 Sep 2002 16:44:42 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: Message from Keith Moore of "Wed, 25 Sep 2002 11:31:59 -0400." <200209251531.g8PFVx025699@astro.cs.utk.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 25 Sep 2002 16:44:42 +0000 Message-Id: <20020925164442.9475B28B6E@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > This implies that filters need to look inside type 41 IP packets. yes. > of course, it's dangerous to suggest this, because there will be > a strong temptation to just block all type 41 packets - since > presumably it's much easier to do that. it's easier still to run dual-stack hosts. and there's a closure: whenever it becomes reasonable for other reasons to run ipv6-only, we won't need the 6to4 tunnels. either way, in the short term the thing most folks will actually do is either dual-stack or nat, since either one of them is easier than 6to4 (with or without tunnels and tunnel filters.) From owner-v6ops@ops.ietf.org Wed Sep 25 12:51:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02558 for ; Wed, 25 Sep 2002 12:51:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uFPF-000CsR-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 09:52:57 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uFP7-000Cs6-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 09:52:49 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PGlg025823; Wed, 25 Sep 2002 12:47:42 -0400 (EDT) Message-Id: <200209251647.g8PGlg025823@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Robert Elz , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Wed, 25 Sep 2002 18:37:48 +0200.") Date: Wed, 25 Sep 2002 12:47:42 -0400 X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,PORN_10,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > While such a scheme might work for protocol 41 packets, I don't > see how it can be made to work for other tunnels, especially encrypted > tunnels. there's no way to deal with xxx-to-host encrypted tunnels except to have the host do the filtering. that doesn't mean ingress filtering isn't useful, just that it can't prevent all threats. but we already knew that. > Thus I think a simpler and more general approach is to require that nodes > only decapsulate packets when they trust the sender. one problem is, the node really doesn't know who the "sender" is - it only knows the source address. another problem is, the reason that sites implement ingress filtering in the first place is that they don't trust the nodes to filter or ignore those packets - perhaps because they lack adequate means of communicating policy to those nodes and ensuring that the nodes enforce that policy. Keith p.s. another idea that might be worth exploring is to have relay-routers and address-translators embed the original source address in the packet in a way that won't interfere with the processing of the payload but still preserves trace information - say as an IP option. I realize that there are serious penalties with use of IP options - in particular causing routers to do "slow path" processing - but perhaps somebody knows another way to embed that information in packets or a way to use IP options that doesn't cause such problems. From owner-v6ops@ops.ietf.org Wed Sep 25 13:05:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02914 for ; Wed, 25 Sep 2002 13:05:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uFcQ-000DN2-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 10:06:34 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17uFcL-000DMr-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 10:06:29 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28214; Wed, 25 Sep 2002 11:06:27 -0600 (MDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8PH6LA01362; Wed, 25 Sep 2002 19:06:22 +0200 (MEST) Date: Wed, 25 Sep 2002 19:03:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comment on unmanaged analysis presentation/doc To: Keith Moore Cc: Erik Nordmark , Robert Elz , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <200209251647.g8PGlg025823@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > one problem is, the node really doesn't know who the "sender" is - it > only knows the source address. Correct. But, if there is X amount of ingress filtering between the sender and the node that establishes some amount of relationship between the sender and the source address. Thus relying on the source address is better than running an open decapsulator, since in the case when ingress filtering is used (even if the ingress filtering is far from perfect) the use of tunneling doesn't make ingress filtering less effective. > another problem is, the reason that > sites implement ingress filtering in the first place is that they don't > trust the nodes to filter or ignore those packets - perhaps because > they lack adequate means of communicating policy to those nodes and > ensuring that the nodes enforce that policy. I don't follow. The receiving nodes can do any reasonable filtering since what matters in this case is trying to weed out folks that forge the source address, and the receiving node doesn't know from where in the topology the packet was sent. Erik From owner-v6ops@ops.ietf.org Wed Sep 25 13:19:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03347 for ; Wed, 25 Sep 2002 13:19:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uFqG-000Drr-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 10:20:52 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uFq8-000DrK-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 10:20:44 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PHFc026141; Wed, 25 Sep 2002 13:15:38 -0400 (EDT) Message-Id: <200209251715.g8PHFc026141@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Robert Elz , v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Wed, 25 Sep 2002 19:03:48 +0200.") X-SUBJECT-MSG-FROM: Erik Nordmark Date: Wed, 25 Sep 2002 13:15:38 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > one problem is, the node really doesn't know who the "sender" is - it > > only knows the source address. > > Correct. > But, if there is X amount of ingress filtering between the sender > and the node that establishes some amount of relationship between the > sender and the source address. I suspect you mean 'egress filtering' - filtering of packets as they _leave_ a network to make sure that they have valid source addresses. Filtering based on source address - whether done at a host or at a router or firewall only works if 'egress filtering' is widely implemented. > Thus relying on the source address is better than running an open > decapsulator, since in the case when ingress filtering is used (even > if the ingress filtering is far from perfect) the use of tunneling > doesn't make ingress filtering less effective. I agree that filtering on source address is at least marginally better than admitting all traffic. > > another problem is, the reason that > > sites implement ingress filtering in the first place is that they don't > > trust the nodes to filter or ignore those packets - perhaps because > > they lack adequate means of communicating policy to those nodes and > > ensuring that the nodes enforce that policy. > > I don't follow. The receiving nodes can do any reasonable filtering since > what matters in this case is trying to weed out folks that forge the source > address, and the receiving node doesn't know from where in the topology > the packet was sent. neither does the ingress filter. the same information from the packet in question is available to either. the principal difference is that the ingress filter allows centralized administration of policy and centralized control. Keith From owner-v6ops@ops.ietf.org Wed Sep 25 13:53:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04506 for ; Wed, 25 Sep 2002 13:53:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uGMa-000Eme-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 10:54:16 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uGMS-000EmT-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 10:54:08 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PHqo026388; Wed, 25 Sep 2002 13:52:50 -0400 (EDT) Message-Id: <200209251752.g8PHqo026388@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Vixie cc: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Wed, 25 Sep 2002 16:44:42 -0000.") <20020925164442.9475B28B6E@as.vix.com> Date: Wed, 25 Sep 2002 13:52:50 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > This implies that filters need to look inside type 41 IP packets. > > yes. > > > of course, it's dangerous to suggest this, because there will be > > a strong temptation to just block all type 41 packets - since > > presumably it's much easier to do that. > > it's easier still to run dual-stack hosts. not sure what you mean, since 6to4 isn't useful without v6 support on the hosts anyway. (it doesn't have to be dual-stack, since v4 support is optional :) > and there's a closure: > whenever it becomes reasonable for other reasons to run ipv6-only, > we won't need the 6to4 tunnels. what is reasonable in one place may not be reasonable in another. we will still need tunnels to connect to those places where native v6 is not reasonable. Keith From owner-v6ops@ops.ietf.org Wed Sep 25 14:03:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04943 for ; Wed, 25 Sep 2002 14:03:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uGWt-000F5w-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 11:04:55 -0700 Received: from as.vix.com ([204.152.187.70]) by psg.com with esmtp (Exim 3.36 #1) id 17uGWq-000F5l-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 11:04:52 -0700 Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (Postfix) with ESMTP id 17A7C28B6E for ; Wed, 25 Sep 2002 18:04:52 +0000 (GMT) From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-Reply-To: Message from Keith Moore of "Wed, 25 Sep 2002 13:52:50 -0400." <200209251752.g8PHqo026388@astro.cs.utk.edu> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Wed, 25 Sep 2002 18:04:52 +0000 Message-Id: <20020925180452.17A7C28B6E@as.vix.com> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > and there's a closure: whenever it becomes reasonable for other > > reasons to run ipv6-only, we won't need the 6to4 tunnels. > > what is reasonable in one place may not be reasonable in another. we > will still need tunnels to connect to those places where native v6 is > not reasonable. the simple model of where that could happen is 1. one side 2. the middle 3. the other side the more interesting model, boiled down to the assymetric tcp case, is: a. the initiator b. the initiator's upstream c. somebody out in the middle d. the responder's upstream e. the responder so far on this list i've seen "a" and "e" ruled out as places to put protocol-translation/bridging machinery, though a tunnel from "a" or "e" to some kind of "c" seems popular. every time anybody mentions asking "b" or "d" to do this they get shot down, which is too bad, since (1) they already have a service provision relationship with a party who evidently wants a new service, (2) they tend to have more technical know-how than their customers, (3) topologically these are the most-bang-for-the-littlest-cost, and finally (4) we can stop talking about it since it's just nat or an application layer proxy at that point, not in need of any standardization work. From owner-v6ops@ops.ietf.org Wed Sep 25 15:42:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07996 for ; Wed, 25 Sep 2002 15:42:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uI2a-000HlZ-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 12:41:44 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uI2R-000HkO-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 12:41:35 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PJeI026634; Wed, 25 Sep 2002 15:40:18 -0400 (EDT) Message-Id: <200209251940.g8PJeI026634@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Vixie cc: v6ops@ops.ietf.org Subject: Re: comment on unmanaged analysis presentation/doc In-reply-to: (Your message of "Wed, 25 Sep 2002 18:04:52 -0000.") <20020925180452.17A7C28B6E@as.vix.com> Date: Wed, 25 Sep 2002 15:40:18 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > the simple model of where that could happen is > > 1. one side > 2. the middle > 3. the other side > > the more interesting model, boiled down to the assymetric tcp case, is: > > a. the initiator > b. the initiator's upstream > c. somebody out in the middle > d. the responder's upstream > e. the responder > > so far on this list i've seen "a" and "e" ruled out as places to put > protocol-translation/bridging machinery, though a tunnel from "a" or > "e" to some kind of "c" seems popular. every time anybody mentions > asking "b" or "d" to do this they get shot down, which is too bad, > since (1) they already have a service provision relationship with a > party who evidently wants a new service, (2) they tend to have more > technical know-how than their customers, (3) topologically these > are the most-bang-for-the-littlest-cost, and finally (4) we can stop > talking about it since it's just nat or an application layer proxy at > that point, not in need of any standardization work. One problem with putting bridging machinery anywhere in the middle is there's no such thing as generic bridging machinery that will work for all or even most apps without causing significant problems for the others. That doesn't mean that there aren't corner cases where bridging machinery in the middle might be useful. And as long as there is an identifiable case where such machinery seems useful, and we don't pretend that they are generic/universal solutions, I see no reason they shouldn't be worked on. Whether such work is appropriate for v6ops or another WG is a different question. What we need most now is to understand which cases would benefit from machinery in which places, and conversely, which kinds of machinery are the most useful and deserving of v6ops attention. Keith From owner-v6ops@ops.ietf.org Wed Sep 25 22:44:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16570 for ; Wed, 25 Sep 2002 22:44:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uOcn-0003yc-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 19:43:33 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17uOck-0003yR-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 19:43:30 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 67F714B22; Thu, 26 Sep 2002 11:43:26 +0900 (JST) To: "Bound, Jim" Cc: v6ops@ops.ietf.org In-reply-to: randy's message of Wed, 25 Sep 2002 07:16:45 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ocean: do not boil From: itojun@iijlab.net Date: Thu, 26 Sep 2002 11:43:26 +0900 Message-Id: <20020926024326.67F714B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> The piece that I think your missing is pretty simple really. The customer >> does not want a parallel IPv4 infrastructure and wants it removed as soon >> as possible. in almost all of the installation of IPv6, they run IPv4 and IPv6 in parallel - usually IPv4 is NATed, and IPv6 is globally reachable (sometimes IPv6 filtering device is in place). i don't share your view on this aspect on customer demand. itojun From owner-v6ops@ops.ietf.org Wed Sep 25 23:10:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16850 for ; Wed, 25 Sep 2002 23:10:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uP3h-0004k5-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 20:11:21 -0700 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #1) id 17uP3e-0004jt-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 20:11:18 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 25 Sep 2002 20:11:17 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 25 Sep 2002 20:11:17 -0700 Received: from RED-MSG-01.redmond.corp.microsoft.com ([157.54.12.52]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 25 Sep 2002 20:11:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ocean: do not boil Date: Wed, 25 Sep 2002 20:11:16 -0700 Message-ID: <240659DFBDD99C4299EF7483EAD70F24DB07AC@RED-MSG-01.redmond.corp.microsoft.com> Thread-Topic: ocean: do not boil thread-index: AcJlCbwZBORvfPSaSH2/A4Q75YRmjAAAG2nw From: "Stewart Tansley" To: , "Bound, Jim" Cc: X-OriginalArrivalTime: 26 Sep 2002 03:11:17.0388 (UTC) FILETIME=[6127ECC0:01C2650A] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA16850 Is it demand, or is it necessity. Stewart. > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, September 25, 2002 7:43 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > >> The piece that I think your missing is pretty simple really. The > >> customer does not want a parallel IPv4 infrastructure and wants it > >> removed as soon as possible. > > in almost all of the installation of IPv6, they run > IPv4 and IPv6 in > parallel - usually IPv4 is NATed, and IPv6 is globally reachable > (sometimes IPv6 filtering device is in place). i don't > share your > view on this aspect on customer demand. > > itojun > > From owner-v6ops@ops.ietf.org Wed Sep 25 23:34:39 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17138 for ; Wed, 25 Sep 2002 23:34:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uPRb-0005Sn-00 for v6ops-data@psg.com; Wed, 25 Sep 2002 20:36:03 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17uPRY-0005Sc-00 for v6ops@ops.ietf.org; Wed, 25 Sep 2002 20:36:00 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0A2AB4B22; Thu, 26 Sep 2002 12:35:58 +0900 (JST) To: "Stewart Tansley" Cc: "Bound, Jim" , v6ops@ops.ietf.org In-reply-to: stansley's message of Wed, 25 Sep 2002 20:11:16 MST. <240659DFBDD99C4299EF7483EAD70F24DB07AC@RED-MSG-01.redmond.corp.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ocean: do not boil From: itojun@iijlab.net Date: Thu, 26 Sep 2002 12:35:58 +0900 Message-Id: <20020926033559.0A2AB4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> in almost all of the installation of IPv6, they run IPv4 and IPv6 in >> parallel - usually IPv4 is NATed, and IPv6 is globally reachable >> (sometimes IPv6 filtering device is in place). i don't share your >> view on this aspect on customer demand. >Is it demand, or is it necessity. i should have written "in almost all of the installation I'VE SEEN". so it's an input from real experiences. and since Jim is talking about customer demand, i think i was talking about customer demand too. (and normally it's simpler to leave NAT'ed IPv4 as is - don't touch it if it's running) itojun From owner-v6ops@ops.ietf.org Thu Sep 26 04:04:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00055 for ; Thu, 26 Sep 2002 04:04:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uTdC-000CVM-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 01:04:18 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17uTd8-000CUx-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 01:04:15 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8761A2FD8; Thu, 26 Sep 2002 04:03:58 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 04:03:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 04:03:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE939E@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlBqNgM4o1CtuhSyWOC/aMvy2NdAALIKpA From: "Bound, Jim" To: Cc: X-OriginalArrivalTime: 26 Sep 2002 08:03:58.0243 (UTC) FILETIME=[443DBF30:01C26533] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00055 Thats fine I suspected you did not. Thats why we all come here to share our views and do work. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, September 25, 2002 10:43 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > >> The piece that I think your missing is pretty simple > really. The customer > >> does not want a parallel IPv4 infrastructure and wants it > removed as soon > >> as possible. > > in almost all of the installation of IPv6, they run > IPv4 and IPv6 in > parallel - usually IPv4 is NATed, and IPv6 is globally reachable > (sometimes IPv6 filtering device is in place). i don't > share your > view on this aspect on customer demand. > > itojun > From owner-v6ops@ops.ietf.org Thu Sep 26 04:04:40 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00069 for ; Thu, 26 Sep 2002 04:04:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uTeT-000CWW-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 01:05:37 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17uTeP-000CWL-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 01:05:33 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id D302741CB; Thu, 26 Sep 2002 04:05:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 04:05:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 04:05:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE939F@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlCbwZBORvfPSaSH2/A4Q75YRmjAAAG2nwAApJszA= From: "Bound, Jim" To: "Stewart Tansley" , Cc: X-OriginalArrivalTime: 26 Sep 2002 08:05:26.0755 (UTC) FILETIME=[78FF9B30:01C26533] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00069 for me it is demand. or the customer is always right. We will need multiple solutions to resolve multiple demands. I don't see necessity as principle from my view at all. /jim > -----Original Message----- > From: Stewart Tansley [mailto:stansley@microsoft.com] > Sent: Wednesday, September 25, 2002 11:11 PM > To: itojun@iijlab.net; Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > Is it demand, or is it necessity. > > Stewart. > > > -----Original Message----- > > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > > Sent: Wednesday, September 25, 2002 7:43 PM > > To: Bound, Jim > > Cc: v6ops@ops.ietf.org > > Subject: Re: ocean: do not boil > > > > > > >> The piece that I think your missing is pretty simple > really. The > > >> customer does not want a parallel IPv4 infrastructure > and wants it > > >> removed as soon as possible. > > > > in almost all of the installation of IPv6, they run > > IPv4 and IPv6 in > > parallel - usually IPv4 is NATed, and IPv6 is globally reachable > > (sometimes IPv6 filtering device is in place). i don't > > share your > > view on this aspect on customer demand. > > > > itojun > > > > > From owner-v6ops@ops.ietf.org Thu Sep 26 04:06:15 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00093 for ; Thu, 26 Sep 2002 04:06:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uTgB-000CYr-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 01:07:23 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17uTg8-000CYf-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 01:07:20 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 72C4C5B5A; Thu, 26 Sep 2002 04:07:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 04:07:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 04:07:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93A0@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlDd5QPRt2qqtgR/aspH0e5rBL9gAJaffA From: "Bound, Jim" To: , "Stewart Tansley" Cc: X-OriginalArrivalTime: 26 Sep 2002 08:07:19.0398 (UTC) FILETIME=[BC239060:01C26533] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA00093 every input I get is that they don't want NAT and want it to go away as soon as possible. for "some" (I say some) I am being told how fast can I get rid of IPv4 period at least on my site. that "some" is as important as the Lowest Common Denominator or one size fits all view to me as an engineer. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Wednesday, September 25, 2002 11:36 PM > To: Stewart Tansley > Cc: Bound, Jim; v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > >> in almost all of the installation of IPv6, they run > IPv4 and IPv6 in > >> parallel - usually IPv4 is NATed, and IPv6 is globally reachable > >> (sometimes IPv6 filtering device is in place). i don't > share your > >> view on this aspect on customer demand. > >Is it demand, or is it necessity. > > i should have written "in almost all of the > installation I'VE SEEN". > so it's an input from real experiences. and since Jim > is talking about > customer demand, i think i was talking about customer > demand too. > (and normally it's simpler to leave NAT'ed IPv4 as is - > don't touch it > if it's running) > > itojun > From owner-v6ops@ops.ietf.org Thu Sep 26 05:09:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00853 for ; Thu, 26 Sep 2002 05:09:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uUeP-000DZf-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 02:09:37 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17uUeK-000DZS-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 02:09:32 -0700 Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA13681; Thu, 26 Sep 2002 02:08:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20020926041139.04311cc0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Sep 2002 04:52:17 -0400 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: , "Stewart Tansley" , In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93A0@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 04:07 AM 9/26/02, Bound, Jim wrote: >every input I get is that they don't want NAT and want it to go away as >soon as possible. To be replaced by NAT-PT? What is the technical advantage to running an IPv6-only internal network that uses NAT-PT to reach external IPv4-only services, as opposed to running a shared IPv4/IPv6 network with IPv4 NAT? [Please give _technical_ reasons, like X works with NAT-PT, but doesn't work with IPv4 NAT... I understand that some folks have emotional/marketing/ other reasons for wanting to use something they think of as "pure IPv6", and we may need to deal with that attitude in the marketplace. I'd just like to put that aside for a moment and understand the technical differences between these two solutions.] I've been thinking about this a lot, and I have come up with the following thoughts: Network set-up is fairly similar in these two cases: - An IPv4/IPv6 network with IPv4 NAT requires: - Setting up an IPv4 NAT box(es). This includes providing at least one globally routable IPv4 address (to use as the source address for translated packets). - Configuring routers with IPv4 and IPv6 prefixes and default routes, including IPv4 default routes that lead out through the NAT box(es) - Setting up an IPv4 DHCP server - Running dual-stack hosts and routers - An IPv6-only network with NAT-PT requires: - Setting up a NAT-PT box(es). This includes providing at least one globally routable IPv4 address (to use as the source address for translated packets). - Configuring routers with IPv6 prefixes and default routes, plus static routes to send traffic addressed to IPv4 mapped addresses out through the NAT-PT box(es) - Running special DNS resolver code on the hosts and/or configuring DNS servers to return AAAA IPv4 mapped addresses for any A records. Please note that both solutions require IPv4 service at the translation point, including at least one globally routable IPv4 address. Once the network has been set-up, these two choices _should_ work the same for IPv4 traffic sent outside the site. However, there are a few of key differences: - The IPv4 NAT solution supports the use of IPv4-only services within the site, whereas NAT-PT only supports IPv4 communication with the outside (there is no internal IPv4 routing). - The NAT-PT solution does not require running a DHCP server or assigning private IPv4 prefixes to internal networks. - The NAT-PT solution involves changes to DNS (either to resolver on each host, or to the server), and the IPv4 NAT solution does not. Are there some other technical advantages to the NAT-PT solution that I am missing? How will hosts know that they are running in a NAT-PT environment, and that they shouldn't send IPv4 traffic? Will they default to using IPv4-mapped addresses whenever they don't have IPv4 addresses configured? What would be the implications of this behaviour (if any) in the event of a DHCP failure on an IPv4-only or IPv4/IPv6 network that is running these same implementations? Is the routing set-up necessary to support multiple NAT-PT boxes the same as the routing set-up needed to support multiple IPv4 NATs? What are the key differences, if any? I am concerned about the DNS modifications needed to make NAT-PT work correctly. We know that applications that currently work behind an IPv4 NAT will work properly with the IPv4 NAT choice. Are we _sure_ that all of those applications will work properly in the NAT-PT case? Who has explored this in detail, and what did you find? BTW, I think it is _very_ appropriate for the working group to be analyzing different solution choices at this point. Two of our scenario documents are nearly complete (3GPP and unmanaged) and work is already underway on the analysis documents. Those analysis documents will contain our recommended solutions for different scenarios, so it makes perfect sense for us to discuss which solutions we will recommend and why. Margaret From owner-v6ops@ops.ietf.org Thu Sep 26 07:36:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02968 for ; Thu, 26 Sep 2002 07:36:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uWx4-000G4k-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 04:37:02 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17uWx0-000G4Y-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 04:36:59 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8QBapOZ020818; Thu, 26 Sep 2002 13:36:51 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 26 Sep 2002 13:36:51 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A61@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Bound, Jim" Cc: itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 13:36:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Please note that both solutions require IPv4 service at the > translation > point, including at least one globally routable IPv4 address. > > Once the network has been set-up, these two choices > _should_ work the > same for IPv4 traffic sent outside the site. However, there are a > few of key differences: > > - The IPv4 NAT solution supports the use of IPv4-only > services within the site, whereas NAT-PT only > supports IPv4 communication with the outside (there > is no internal IPv4 routing). > > - The NAT-PT solution does not require running a > DHCP server > or assigning private IPv4 prefixes to > internal networks. > > - The NAT-PT solution involves changes to DNS (either to > resolver on each host, or to the server), > and the IPv4 > NAT solution does not. > > Are there some other technical advantages to the NAT-PT > solution that I > am missing? > => Are nodes inside the network capable of communicating with each other using IPv4? I don't think that would be possible. Also, and if the different private address clouds are not physically separated then we end up with having overlapping IPv4 address spaces. This will mean that operators need to use BGP-based MPLS vpns (eek), virtual routers ...etc. which is definitely a disadvantage to the v4 NAT solution. This situation could happen if the operator starts with a large network or when they expand an existing network. Could be very messy. The only way to go around that would be to assume that _all_ hosts inside the network will have v6 enabled and can communicate using v6. I.e. no v4 only devices in the network. This is probably unrealistic, especially in a public access network. > How will hosts know that they are running in a NAT-PT environment, > and that they shouldn't send IPv4 traffic? => This is part of the NAT-PT solution, whether you use DNS ALG in the network or modify the client's resolver this would work fine. It doesn't need to be a mapped address. If the DNS ALG is in the network then it can be any IPv6 unicast prefix. If the client's resolver is changed it can also be any prefix, but in this case it has to be a "well known" prefix. A mapped prefix would work fine. > Who has explored this in detail, and what did you find? => Alain's draft addresses this. I've also explored an alternative that I presented in the DT. This involved having a DNS ALG in the network. The advantage of Alain's altrnative is that it allows DNSSEC in the client's resolver (as opposed to being verfied in the operator's DNS). The advantage of having the DNS ALG in the network is that we don't have to change (or guarantee changing) resolvers in all clients. There are other pros and cons related to how equally a load can be distributed between the translators but the DNSSEC was the most significant difference. I don't know if v4 NATs can be distributed for load sharing and I haven't looked into that, I'd be interested in a pointer though if someone else studied it. Hesham From owner-v6ops@ops.ietf.org Thu Sep 26 08:03:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03483 for ; Thu, 26 Sep 2002 08:03:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uXNi-000Gal-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 05:04:34 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17uXNe-000Gaa-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 05:04:30 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11338; Thu, 26 Sep 2002 05:04:28 -0700 (PDT) Received: from buse (buse [129.157.212.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8QC4RA25113; Thu, 26 Sep 2002 14:04:28 +0200 (MEST) Date: Thu, 26 Sep 2002 14:04:27 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: ocean: do not boil To: Margaret Wasserman Cc: "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.0.14.2.20020926041139.04311cc0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Overall these are good questions. However, some details are muddled due to us having both NAT-PT and NAT64 and they work slightly differently. Example below. There is also a larger issue to keep in mind when comparing NATv4 and transition specific NATs (whether NAT-PT, nat64, or something else). Presumably there is a gradual evolution of the ALG support in NATv4 boxes (special support for special application protocols). There is a danger in having a separate transition specific NAT in that it might lag behind the NATv4 ALG support. Hence folks might get less things to work with the transition specific NAT until IPv6 sales volume makes the transition specific NAT be ahead of NATv4 in terms of special ALGs. For that reason it might make to look very hard at the use of off the shelf NATv4 technology combined with an IPv6 router. > How will hosts know that they are running in a NAT-PT environment, > and that they shouldn't send IPv4 traffic? Will they default to > using IPv4-mapped addresses whenever they don't have IPv4 addresses > configured? What would be the implications of this behaviour > (if any) in the event of a DHCP failure on an IPv4-only or IPv4/IPv6 > network that is running these same implementations? - NAT-PT ensures, using the DNS ALG, that the host only receives AAAA records, thus the host doesn't do anything special. - A host with NAT64 support would receive A records thus presumably it would determine to send using IPv6 based on the fact that it doesn't have any configured IPv4 addresses (or no IPv4 routers in the routing table, or an implementation specific knob). Erik From owner-v6ops@ops.ietf.org Thu Sep 26 08:55:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05244 for ; Thu, 26 Sep 2002 08:55:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uYAw-000Hew-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 05:55:26 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17uYAs-000Hek-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 05:55:22 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4801860A4; Thu, 26 Sep 2002 08:55:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 08:55:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 08:55:20 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5BA@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlPGq4xyDfc7QlRkGAOBdLZ9QyEAAHuyGg From: "Bound, Jim" To: "Margaret Wasserman" Cc: , "Stewart Tansley" , X-OriginalArrivalTime: 26 Sep 2002 12:55:22.0068 (UTC) FILETIME=[F969B940:01C2655B] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA05244 Margaret, > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, September 26, 2002 4:52 AM > To: Bound, Jim > Cc: itojun@iijlab.net; Stewart Tansley; v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > At 04:07 AM 9/26/02, Bound, Jim wrote: > >every input I get is that they don't want NAT and want it to > go away as > >soon as possible. > > To be replaced by NAT-PT? No. > > What is the technical advantage to running an IPv6-only > internal network > that uses NAT-PT to reach external IPv4-only services, as > opposed to running > a shared IPv4/IPv6 network with IPv4 NAT? None. > > [Please give _technical_ reasons, like X works with NAT-PT, > but doesn't > work with IPv4 NAT... I understand that some folks have > emotional/marketing/ > other reasons for wanting to use something they think of as > "pure IPv6", and > we may need to deal with that attitude in the marketplace. > I'd just like to > put that aside for a moment and understand the technical > differences between > these two solutions.] Another solution is to use DSTM to avoid using NAT-PT. Which is technically a different solution. > > I've been thinking about this a lot, and I have come up with > the following > thoughts: > > Network set-up is fairly similar in these two cases: > > - An IPv4/IPv6 network with IPv4 NAT requires: > - Setting up an IPv4 NAT box(es). This includes > providing at least one globally routable > IPv4 address (to use as the source address > for translated packets). > - Configuring routers with IPv4 and IPv6 > prefixes and default routes, > including IPv4 default routes > that lead out through the NAT box(es) > - Setting up an IPv4 DHCP server > - Running dual-stack hosts and routers > > - An IPv6-only network with NAT-PT requires: > - Setting up a NAT-PT box(es). This includes > providing at least one globally routable > IPv4 address (to use as the source address > for translated packets). > - Configuring routers with IPv6 prefixes and default > routes, plus static routes to send traffic > addressed to IPv4 mapped addresses > out through > the NAT-PT box(es) > - Running special DNS resolver code on the > hosts and/or > configuring DNS servers to return > AAAA IPv4 mapped > addresses for any A records. > > Please note that both solutions require IPv4 service at the > translation > point, including at least one globally routable IPv4 address. > > Once the network has been set-up, these two choices _should_ work the > same for IPv4 traffic sent outside the site. However, there are a > few of key differences: > > - The IPv4 NAT solution supports the use of IPv4-only > services within the site, whereas NAT-PT only > supports IPv4 communication with the outside (there > is no internal IPv4 routing). > > - The NAT-PT solution does not require running a DHCP server > or assigning private IPv4 prefixes to > internal networks. > > - The NAT-PT solution involves changes to DNS (either to > resolver on each host, or to the server), > and the IPv4 > NAT solution does not. > > Are there some other technical advantages to the NAT-PT > solution that I > am missing? > > How will hosts know that they are running in a NAT-PT environment, > and that they shouldn't send IPv4 traffic? Will they default to > using IPv4-mapped addresses whenever they don't have IPv4 addresses > configured? What would be the implications of this behaviour > (if any) in the event of a DHCP failure on an IPv4-only or IPv4/IPv6 > network that is running these same implementations? > > Is the routing set-up necessary to support multiple NAT-PT boxes the > same as the routing set-up needed to support multiple IPv4 NATs? What > are the key differences, if any? > > I am concerned about the DNS modifications needed to make NAT-PT work > correctly. We know that applications that currently work behind an > IPv4 NAT will work properly with the IPv4 NAT choice. Are we _sure_ > that all of those applications will work properly in the NAT-PT case? > Who has explored this in detail, and what did you find? > > BTW, I think it is _very_ appropriate for the working group to be > analyzing different solution choices at this point. Two of > our scenario > documents are nearly complete (3GPP and unmanaged) and work is already > underway on the analysis documents. Those analysis documents will > contain our recommended solutions for different scenarios, so it > makes perfect sense for us to discuss which solutions we will > recommend and why. This can be completely avoided when users have a large pool of IPv4 address space or can use private IPv4 address space with DSTM and then NAT-PT is NOT required. NAT-PT breaks end-2-end security and apps just like NAT in IPv4. /jim > > Margaret > > > > From owner-v6ops@ops.ietf.org Thu Sep 26 09:26:36 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06655 for ; Thu, 26 Sep 2002 09:26:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uYgT-000IPR-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 06:28:01 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uYgQ-000IPG-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 06:27:58 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QDPB025033; Thu, 26 Sep 2002 09:25:20 -0400 (EDT) Message-Id: <200209261325.g8QDPB025033@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: itojun@iijlab.net, "Stewart Tansley" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 04:07:18 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B02BE93A0@tayexc13.americas.cpqcorp.net> Date: Thu, 26 Sep 2002 09:25:11 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > every input I get is that they don't want NAT and want it to go away as > soon as possible. for "some" (I say some) I am being told how fast can > I get rid of IPv4 period at least on my site. that's quite interesting, and encouraging. what it indicates to me is that people need a way to disable IPv4-NAT and still leave IPv6 running. I don't think that's rocket science. and I understand why sites might want to get rid of IPv4 as much as possible, as soon as possible. but it's hard to believe that most sites won't need at least some IPv4-NAT in addition to IPv6 during a transition phase, at least for awhile. if nothing else many locally-used apps will have IPv4 wired into them, and it will take time to upgrade all of those apps. Keith From owner-v6ops@ops.ietf.org Thu Sep 26 09:28:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06763 for ; Thu, 26 Sep 2002 09:28:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uYj1-000ITU-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 06:30:39 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uYiy-000ITH-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 06:30:36 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QDRr025066; Thu, 26 Sep 2002 09:27:54 -0400 (EDT) Message-Id: <200209261327.g8QDRr025066@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: "Bound, Jim" , itojun@iijlab.net, "Stewart Tansley" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 04:52:17 EDT.") <5.1.0.14.2.20020926041139.04311cc0@mail.windriver.com> Date: Thu, 26 Sep 2002 09:27:53 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > What is the technical advantage to running an IPv6-only internal network > that uses NAT-PT to reach external IPv4-only services, as opposed to running > a shared IPv4/IPv6 network with IPv4 NAT? it's a tradeoff - NAT-PT is probably slightly less functional to apps (will cause a few more apps to break than NATs do) but in exchange for using it you get to get rid of all IPv4 traffic on your local network. From owner-v6ops@ops.ietf.org Thu Sep 26 09:30:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06793 for ; Thu, 26 Sep 2002 09:30:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uYkE-000IXZ-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 06:31:54 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uYkB-000IXI-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 06:31:51 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QDT9025100; Thu, 26 Sep 2002 09:29:09 -0400 (EDT) Message-Id: <200209261329.g8QDT9025100@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Margaret Wasserman , "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 14:04:27 +0200.") X-SUBJECT-MSG-FROM: Erik Nordmark Date: Thu, 26 Sep 2002 09:29:09 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk - NAT-PT ensures, using the DNS ALG, that the host only receives AAAA records, thus the host doesn't do anything special. this doesn't prevent IPv4 traffic - it only eliminates one source of IPv4 addresses. DNS is not the only such source. From owner-v6ops@ops.ietf.org Thu Sep 26 09:57:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07984 for ; Thu, 26 Sep 2002 09:57:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZ9D-000J9W-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 06:57:43 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17uZ9A-000J9I-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 06:57:40 -0700 Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA28936; Thu, 26 Sep 2002 06:56:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20020926094446.04315c90@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Sep 2002 09:58:16 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org In-Reply-To: References: <"Your message with ID" <5.1.0.14.2.20020926041139.04311cc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Erik, >Overall these are good questions. >However, some details are muddled due to us having both NAT-PT and NAT64 >and they work slightly differently. Example below. I agree. In retrospect, I probably should not have tried to lump the NAT-PT and NAT64 cases together, because of the DNS differences that you have outlined. >For that reason it might make to look very hard at the use of off the shelf >NATv4 technology combined with an IPv6 router. Right. We should at least consider parallel IPv4 and IPv6 infrastructure as part of the solution space when customers need to access IPv4 and IPv6 services from the same site. We may need to compare this solution to other solutions on a case-by-case basis, depending upon the scenario we are discussing, especially if there are significant differences in scalability, performance, etc. > - NAT-PT ensures, using the DNS ALG, that the host only receives AAAA > records, > thus the host doesn't do anything special. And, if the application tries to send to an IPv4 address? Would it just fail with "no route to address", or something like that? > - A host with NAT64 support would receive A records thus presumably it > would determine to send using IPv6 based on the fact that it doesn't > have any configured IPv4 addresses (or no IPv4 routers in the routing > table, or an implementation specific knob). Right, and this is the part that raises my concerns... In order for a dual-stack node to exist in this environment, it would need to have two different "modes" of operation -- one where all A records are translated to AAAA records (if behind NAT-PT), and one where the A records result in IPv4 traffic (when on an IPv4 network). How would the node decide which "mode" it should be using? Margaret From owner-v6ops@ops.ietf.org Thu Sep 26 09:59:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08043 for ; Thu, 26 Sep 2002 09:59:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZBj-000JE9-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:00:19 -0700 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17uZBZ-000JDl-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:00:09 -0700 Received: from kenawang.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA00265; Thu, 26 Sep 2002 06:59:20 -0700 (PDT) Message-Id: <5.1.0.14.2.20020926095950.0214c0d0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Sep 2002 10:00:38 -0400 To: Keith Moore From: Margaret Wasserman Subject: Re: ocean: do not boil Cc: "Bound, Jim" , itojun@iijlab.net, "Stewart Tansley" , v6ops@ops.ietf.org In-Reply-To: <200209261327.g8QDRr025066@astro.cs.utk.edu> References: <(Your message of "Thu, 26 Sep 2002 04:52:17 EDT.") <5.1.0.14.2.20020926041139.04311cc0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >it's a tradeoff - NAT-PT is probably slightly less functional to apps (will >cause a few more apps to break than NATs do) but in exchange for using it >you get to get rid of all IPv4 traffic on your local network. What is the advantage of getting rid of all IPv4 traffic on the local network, since it will just be replaced with translated IPv6 traffic? Margaret From owner-v6ops@ops.ietf.org Thu Sep 26 10:01:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08122 for ; Thu, 26 Sep 2002 10:01:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZEO-000JJ3-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:03:04 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uZEL-000JIs-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:03:01 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28151; Thu, 26 Sep 2002 08:02:58 -0600 (MDT) Received: from buse (buse [129.157.212.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8QE2vA03007; Thu, 26 Sep 2002 16:02:57 +0200 (MEST) Date: Thu, 26 Sep 2002 16:02:57 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: ocean: do not boil To: Margaret Wasserman Cc: Erik Nordmark , "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <5.1.0.14.2.20020926094446.04315c90@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > - NAT-PT ensures, using the DNS ALG, that the host only receives AAAA > > records, > > thus the host doesn't do anything special. > > And, if the application tries to send to an IPv4 address? Would it just > fail with "no route to address", or something like that? I think so; at least I don't recall seeing this case discussed. > Right, and this is the part that raises my concerns... In order for a > dual-stack node to exist in this environment, it would need to have two > different "modes" of operation -- one where all A records are translated > to AAAA records (if behind NAT-PT), and one where the A records result > in IPv4 traffic (when on an IPv4 network). How would the node decide > which "mode" it should be using? One way is to determine the mode based on whether the node has an IPv4 address. Thus the node tries to use DHCPv4 to get an IPv4 address and if that fails it assumes it is IPv6 only and operates in the nat65 mode. Of course, if the IPv4 address can be assigned using autonet (i.e. link-local IPv4 addresses), then this needs to be taken into account when trying to automate this mode selection. But operationally I suspect always assigning IPv4 addresses, whether link-local or private RFC 1918 space, and using an IPv4 NAT is simpler since there is one less mode to worry about. Erik From owner-v6ops@ops.ietf.org Thu Sep 26 10:04:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08264 for ; Thu, 26 Sep 2002 10:04:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZGv-000JNk-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:05:41 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uZGs-000JNZ-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:05:38 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QE2q025864; Thu, 26 Sep 2002 10:02:52 -0400 (EDT) Message-Id: <200209261402.g8QE2q025864@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: Keith Moore , "Bound, Jim" , itojun@iijlab.net, "Stewart Tansley" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 10:00:38 EDT.") <5.1.0.14.2.20020926095950.0214c0d0@mail.windriver.com> Date: Thu, 26 Sep 2002 10:02:52 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > What is the advantage of getting rid of all IPv4 traffic on the local > network, since it will just be replaced with translated IPv6 traffic? I don't really know, since I don't manage networks. But I can imagine that it's somewhat saner to have only one IP protocol to monitor and only one set of host-to-address bindings to deal with. From owner-v6ops@ops.ietf.org Thu Sep 26 10:11:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08503 for ; Thu, 26 Sep 2002 10:11:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZO7-000JaD-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:13:07 -0700 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 17uZO4-000Ja2-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:13:04 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19517; Thu, 26 Sep 2002 07:13:02 -0700 (PDT) Received: from buse (buse [129.157.212.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8QED1A04199; Thu, 26 Sep 2002 16:13:01 +0200 (MEST) Date: Thu, 26 Sep 2002 16:13:01 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ocean: do not boil To: Keith Moore Cc: Erik Nordmark , Margaret Wasserman , "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <200209261329.g8QDT9025100@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > - NAT-PT ensures, using the DNS ALG, that the host only receives AAAA > records, > thus the host doesn't do anything special. > > this doesn't prevent IPv4 traffic - it only eliminates one source of > IPv4 addresses. DNS is not the only such source. Yep. But it is far from clear to me that NAT-PT handles the case when an IPv4 address is used by an application (whether it came from some application protocol payload or elsewhere). I think this is just the NAT+ALG issue restated; if IP addresses appear in the payload of packets an ALG is needed in the NAT to map those IP addresses. Erik From owner-v6ops@ops.ietf.org Thu Sep 26 10:14:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08573 for ; Thu, 26 Sep 2002 10:14:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZQv-000Jfm-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:16:01 -0700 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by psg.com with esmtp (Exim 3.36 #1) id 17uZQn-000JfW-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:15:53 -0700 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24023; Thu, 26 Sep 2002 07:15:47 -0700 (PDT) Received: from buse (buse [129.157.212.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8QEFkA04488; Thu, 26 Sep 2002 16:15:46 +0200 (MEST) Date: Thu, 26 Sep 2002 16:15:46 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ocean: do not boil To: Keith Moore Cc: Margaret Wasserman , "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org In-Reply-To: "Your message with ID" <200209261327.g8QDRr025066@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > it's a tradeoff - NAT-PT is probably slightly less functional to apps (will > cause a few more apps to break than NATs do) but in exchange for using it > you get to get rid of all IPv4 traffic on your local network. But you can get rid of the local IPv4 traffic (i.e. no need to configure local IPv4 routing) by tunneling IPv4 in IPv6 locally and using the DSTM DHCP options for getting such tunnels configured. This requires implementing more stuff on the nodes, and it adds tunneling overhead on the wire. Erik From owner-v6ops@ops.ietf.org Thu Sep 26 10:18:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08769 for ; Thu, 26 Sep 2002 10:18:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZVJ-000JoC-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:20:33 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uZVG-000Jo1-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:20:30 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QEHe025903; Thu, 26 Sep 2002 10:17:40 -0400 (EDT) Message-Id: <200209261417.g8QEHe025903@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Margaret Wasserman , "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 16:13:01 +0200.") Date: Thu, 26 Sep 2002 10:17:40 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Yep. But it is far from clear to me that NAT-PT handles the case when an > IPv4 address is used by an application (whether it came from some application > protocol payload or elsewhere). I think this is just the NAT+ALG issue > restated; if IP addresses appear in the payload of packets an ALG is needed in > the NAT to map those IP addresses. actually there are cases where IP addresses in the payload work fine through NAT (the app deals with scoped addresses by passing around multiple addresses and since it can't tell which addresses are valid in which scope it tries multiple addresses, doing its own identity checks to make sure it's got the right host) but such apps might still have v4 assumptions wired into them - 4 byte addresses, etc. From owner-v6ops@ops.ietf.org Thu Sep 26 10:21:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08869 for ; Thu, 26 Sep 2002 10:21:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uZXR-000JsM-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:22:45 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uZXJ-000Jrr-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:22:37 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QEJr025921; Thu, 26 Sep 2002 10:19:53 -0400 (EDT) Message-Id: <200209261419.g8QEJr025921@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Nordmark cc: Keith Moore , Margaret Wasserman , "Bound, Jim" , itojun@iijlab.net, Stewart Tansley , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 16:15:46 +0200.") Date: Thu, 26 Sep 2002 10:19:53 -0400 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > it's a tradeoff - NAT-PT is probably slightly less functional to apps (will > > cause a few more apps to break than NATs do) but in exchange for using it > > you get to get rid of all IPv4 traffic on your local network. > > But you can get rid of the local IPv4 traffic (i.e. no need to configure > local IPv4 routing) by tunneling IPv4 in IPv6 locally and using the DSTM > DHCP options for getting such tunnels configured. yes you can, and this makes far more sense to me than using NAT-PT. in most cases tunneling seems far better than messing with DNS. it would be interesting to see all of these scenarios compared side-by-side. Keith From owner-v6ops@ops.ietf.org Thu Sep 26 10:59:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10524 for ; Thu, 26 Sep 2002 10:59:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ua6E-000Kuo-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 07:58:42 -0700 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by psg.com with esmtp (Exim 3.36 #1) id 17ua64-000Ku0-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 07:58:32 -0700 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g8QEwSd02421; Thu, 26 Sep 2002 09:58:28 -0500 (CDT) Message-ID: <3D9320CA.6090502@alcatel.com> Date: Thu, 26 Sep 2002 09:59:22 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: v6ops@ops.ietf.org Subject: Re: ocean: do not boil References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93A0@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jim, Bound, Jim wrote: >every input I get is that they don't want NAT and want it to go away as soon as possible. for "some" (I say some) I am being told how fast can I get rid of IPv4 period at least on my site. that "some" is as important as the Lowest Common Denominator or one size fits all view to me as an engineer. > > I would like to hope that you are right (and are in line with the operators and enterprises). For Keith, I understand, in academia one wants the latest. What are the views then on the issue of IPv6 NATs? >/jim > > > --behcet >> >> From owner-v6ops@ops.ietf.org Thu Sep 26 11:29:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11825 for ; Thu, 26 Sep 2002 11:29:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uabI-000Lpt-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 08:30:48 -0700 Received: from [2001:470:1f00:ffff::35f] (helo=persephone.cfrq.net) by psg.com with esmtp (Exim 3.36 #1) id 17uaaz-000Low-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 08:30:29 -0700 Received: from elisabeth.cfrq.net (elisabeth.chk.cfrq.net [199.85.99.82] (may be forged)) by persephone.cfrq.net (8.12.2/8.12.2) with ESMTP id g8QFUQmR021465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 26 Sep 2002 11:30:27 -0400 Received: from elisabeth.cfrq.net (localhost [127.0.0.1]) by elisabeth.cfrq.net (8.12.2/8.12.2) with ESMTP id g8QFUPFm032077 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 26 Sep 2002 11:30:26 -0400 Received: from elisabeth.cfrq.net (chk@localhost) by elisabeth.cfrq.net (8.12.2/8.12.2/Submit) with ESMTP id g8QFUMTQ032073 for ; Thu, 26 Sep 2002 11:30:24 -0400 X-Authentication-Warning: elisabeth.cfrq.net: chk owned process doing -bs To: v6ops@ops.ietf.org Subject: tiny v6 operational issue From: Harald Koch MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32070.1033054222.1@elisabeth.cfrq.net> Date: Thu, 26 Sep 2002 11:30:22 -0400 Message-ID: <32072.1033054222@elisabeth.cfrq.net> X-Spam-Status: No, hits=0.9 required=5.0 tests=X_AUTH_WARNING,MAY_BE_FORGED,LINES_OF_YELLING version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk The nameservers for 'ops.ietf.org' (the host for this list) are listed as: DOKKA.MAXWARE.NO. NN.UNINETT.NO. PSG.COM. PSG.COM tells me that its addresses are: A 147.28.0.62 AAAA 2001:418:1::62 DNS lookups to 2001:418:1::62 give me "udp port domain unreachable". Conclusions left as an exercise to the reader. -- Harald Koch "It takes a child to raze a village." -Michael T. Fry From owner-v6ops@ops.ietf.org Thu Sep 26 12:23:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13553 for ; Thu, 26 Sep 2002 12:23:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ubR1-000NSm-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 09:24:15 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #1) id 17ubQt-000NSa-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 09:24:07 -0700 Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8QGO6W4015368; Thu, 26 Sep 2002 09:24:06 -0700 (PDT) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjcm-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG74044; Thu, 26 Sep 2002 09:24:05 -0700 (PDT) Date: Thu, 26 Sep 2002 09:24:05 -0700 (PDT) From: Suresh K Satapati To: Margaret Wasserman cc: v6ops@ops.ietf.org Subject: RE: ocean: do not boil In-Reply-To: <5.1.0.14.2.20020926041139.04311cc0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > - Running special DNS resolver code on the hosts and/or > configuring DNS servers to return AAAA IPv4 mapped > addresses for any A records. DNS-ALG does this. resolver code does not have to chang in NAT-PT case > - The NAT-PT solution involves changes to DNS (either to > resolver on each host, or to the server), and the IPv4 > NAT solution does not. both NAT and NAT-PT do not involve any changes to DNS resolver/server > > Are there some other technical advantages to the NAT-PT solution that I > am missing? technically, network has IPv6-only traffic. router either runs dual-stack+v4NAT or dual-stack+NAT-PT; both may not be equal in terms of complexity, as Erik already mentioned the ALG factor which is more in v4NAT today than in NAT-PT. there are clearly operational advantages, as mentioned already by folks. > > How will hosts know that they are running in a NAT-PT environment, > and that they shouldn't send IPv4 traffic? the problem here is dual-stack behavior is not clear. i tend to think they would try to resolve using a AAAA first and then A, there might be implementations that are doing A first, then AAAA there is a problem for dual-stacks that are behind a NAT-PT, which i will come to later. > > Is the routing set-up necessary to support multiple NAT-PT boxes the > same as the routing set-up needed to support multiple IPv4 NATs? What > are the key differences, if any? no differences. > > I am concerned about the DNS modifications needed to make NAT-PT work > correctly. We know that applications that currently work behind an > IPv4 NAT will work properly with the IPv4 NAT choice. Are we _sure_ > that all of those applications will work properly in the NAT-PT case? as i said, no DNS modifications are needed. just like in v4NAT, one would point host resolver to a NAT-PT box. apps will work as they were with v4NAT, as long as ALG support is there with NAT-PT > Who has explored this in detail, and what did you find? while Alain did explore this, there are solutions to overcome most problems that Alain pointed out except DNS-SEC. Now the dual-stack problem: with NAT-PT, dual-stack will always be forced to use a IPv6-mapped address (translation path) that the DNS-ALG synthesized for a v4 destination. dual-stack could very well use IPv4 to talk to the destination, but is forced to use IPv6+NAT-PT because of DNS-ALG's current behavior. this is assuming dual-stack is sending AAAA first, and then A; but not true for other cases. -Suresh From owner-v6ops@ops.ietf.org Thu Sep 26 13:09:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15319 for ; Thu, 26 Sep 2002 13:09:15 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uc7b-000Ov3-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 10:08:15 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17uc7Z-000Oup-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 10:08:13 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17uc7Y-00062U-00; Thu, 26 Sep 2002 10:08:12 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Harald Koch Cc: v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue References: <32072.1033054222@elisabeth.cfrq.net> Message-Id: Date: Thu, 26 Sep 2002 10:08:12 -0700 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The nameservers for 'ops.ietf.org' (the host for this list) are listed > as: > > DOKKA.MAXWARE.NO. > NN.UNINETT.NO. > PSG.COM. > > PSG.COM tells me that its addresses are: > > A 147.28.0.62 > AAAA 2001:418:1::62 > > DNS lookups to 2001:418:1::62 give me "udp port domain unreachable". hmmm. not sure why. server does have options { ... listen-on { 127.0.0.1; 147.28.0.62; 147.28.0.34; 2001:418:1::62; } ; but thanks for bug report, despite the rather strange list to which you chose to report it. i guess it was more a political than technical statement. but i will be looking. randy From owner-v6ops@ops.ietf.org Thu Sep 26 14:03:50 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16624 for ; Thu, 26 Sep 2002 14:03:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ucyn-0003Fq-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 11:03:13 -0700 Received: from [2001:470:1f00:ffff::35f] (helo=persephone.cfrq.net) by psg.com with esmtp (Exim 3.36 #1) id 17ucyj-0003Fe-00; Thu, 26 Sep 2002 11:03:10 -0700 Received: from elisabeth.cfrq.net (elisabeth.chk.cfrq.net [199.85.99.82] (may be forged)) by persephone.cfrq.net (8.12.2/8.12.2) with ESMTP id g8QI37mR022792 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 26 Sep 2002 14:03:07 -0400 Received: from elisabeth.cfrq.net (localhost [127.0.0.1]) by elisabeth.cfrq.net (8.12.2/8.12.2) with ESMTP id g8QI34Fm002452 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Sep 2002 14:03:06 -0400 Received: from elisabeth.cfrq.net (chk@localhost) by elisabeth.cfrq.net (8.12.2/8.12.2/Submit) with ESMTP id g8QI30EO002448; Thu, 26 Sep 2002 14:03:03 -0400 X-Authentication-Warning: elisabeth.cfrq.net: chk owned process doing -bs To: Randy Bush cc: v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue References: <32072.1033054222@elisabeth.cfrq.net> In-reply-to: randy's message of "Thu, 26 Sep 2002 10:08:12 -0700". From: Harald Koch Date: Thu, 26 Sep 2002 14:02:59 -0400 Message-ID: <2447.1033063379@elisabeth.cfrq.net> X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,MAY_BE_FORGED version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > but thanks for bug report, despite the rather strange list to which you > chose to report it. i guess it was more a political than technical > statement. but i will be looking. Well, my only dealings with 'ops.ietf.org' are through the mailing list; I found it particularly amusing in that context. Not a political statement at all, but I guess people will read almost anything between the lines these days. -- Harald Koch From owner-v6ops@ops.ietf.org Thu Sep 26 14:36:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17638 for ; Thu, 26 Sep 2002 14:36:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17udWu-0004OC-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 11:38:28 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #1) id 17udWr-0004O0-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 11:38:25 -0700 Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8QIcO1X020515; Thu, 26 Sep 2002 11:38:24 -0700 (PDT) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjcm-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG78235; Thu, 26 Sep 2002 11:38:20 -0700 (PDT) Date: Thu, 26 Sep 2002 11:38:18 -0700 (PDT) From: Suresh K Satapati To: Margaret Wasserman cc: v6ops@ops.ietf.org Subject: RE: ocean: do not boil In-Reply-To: <5.1.0.14.2.20020926094446.04315c90@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > Right, and this is the part that raises my concerns... In order for a > dual-stack node to exist in this environment, it would need to have two > different "modes" of operation -- one where all A records are translated > to AAAA records (if behind NAT-PT), and one where the A records result > in IPv4 traffic (when on an IPv4 network). How would the node decide > which "mode" it should be using? Node should not be aware of presence of NAT-PT. It is entirely config dependent. If one chooses to point the resolver to a v4 DNS server, for which it doesnt have to go through a NAT-PT, then the problem is solved. On the other hand, one could still use a mapped address for the IPv6 DNS server, which is reachable only through NAT-PT. Comments ?? From owner-v6ops@ops.ietf.org Thu Sep 26 14:40:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17704 for ; Thu, 26 Sep 2002 14:40:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uda8-0004WL-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 11:41:48 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #1) id 17uda5-0004WA-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 11:41:45 -0700 Received: from ssenthil-u5.cisco.com (ssenthil-u5.cisco.com [128.107.162.100]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8QIfV1Y022255; Thu, 26 Sep 2002 11:41:31 -0700 (PDT) Date: Thu, 26 Sep 2002 11:41:30 -0700 (PDT) From: Senthil Sivakumar To: Margaret Wasserman cc: Keith Moore , "Bound, Jim" , , Stewart Tansley , Subject: Re: ocean: do not boil In-Reply-To: <5.1.0.14.2.20020926095950.0214c0d0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 26 Sep 2002, Margaret Wasserman wrote: > > > >it's a tradeoff - NAT-PT is probably slightly less functional to apps (will > >cause a few more apps to break than NATs do) but in exchange for using it > >you get to get rid of all IPv4 traffic on your local network. > > What is the advantage of getting rid of all IPv4 traffic on the local > network, since it will just be replaced with translated IPv6 traffic? > You dont have to run IPv4 routing protocols along with IPv6 routing protocols, which IMO, is an operational advantage. Senthil > Margaret > > > > From owner-v6ops@ops.ietf.org Thu Sep 26 15:01:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18451 for ; Thu, 26 Sep 2002 15:01:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17udqj-000545-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 11:58:57 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17udqe-000535-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 11:58:52 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17udqd-00097a-00; Thu, 26 Sep 2002 11:58:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Harald Koch , v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue References: <32072.1033054222@elisabeth.cfrq.net> Message-Id: Date: Thu, 26 Sep 2002 11:58:51 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > options { ... > listen-on { 127.0.0.1; > 147.28.0.62; > 147.28.0.34; > 2001:418:1::62; } ; so, pekka pointed out that bind is a bit convoluted here, and that won't work. listen-on-v6 { any; }; did. thanks pekka. randy From owner-v6ops@ops.ietf.org Thu Sep 26 16:27:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20879 for ; Thu, 26 Sep 2002 16:27:58 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ufFc-0007U5-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 13:28:44 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17ufFT-0007Tr-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 13:28:35 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QKR8027019; Thu, 26 Sep 2002 16:27:08 -0400 (EDT) Message-Id: <200209262027.g8QKR8027019@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Behcet Sarikaya cc: "Bound, Jim" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 09:59:22 CDT.") <3D9320CA.6090502@alcatel.com> Date: Thu, 26 Sep 2002 16:27:08 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > For Keith, I understand, in academia one wants the latest. what I want is a network where I can build large distributed applications without having to design my own addressing system and routing protocols on top of layer 7. this is trivial with v6, it's nearly infeasible with v4+NAT. From owner-v6ops@ops.ietf.org Thu Sep 26 16:28:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20895 for ; Thu, 26 Sep 2002 16:28:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ufGX-0007Vy-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 13:29:41 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17ufGP-0007Vb-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 13:29:33 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QKRt027033; Thu, 26 Sep 2002 16:27:55 -0400 (EDT) Message-Id: <200209262027.g8QKRt027033@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Suresh K Satapati cc: Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 09:24:05 PDT.") Date: Thu, 26 Sep 2002 16:27:55 -0400 X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk DNS-ALG and NAT-PT both change DNS results for some hosts, which breaks apps that reasonably expect a consistent view of DNS. don't use NAT brain-damage as an excuse to break DNS also. From owner-v6ops@ops.ietf.org Thu Sep 26 16:56:32 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21740 for ; Thu, 26 Sep 2002 16:56:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ufi2-0008K8-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 13:58:06 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #1) id 17ufhz-0008Jv-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 13:58:03 -0700 Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8QKw11X006192; Thu, 26 Sep 2002 13:58:01 -0700 (PDT) Received: from satapati-u10.cisco.com (satapati-u10.cisco.com [128.107.162.133]) by mira-sjcm-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG82191; Thu, 26 Sep 2002 13:58:00 -0700 (PDT) Date: Thu, 26 Sep 2002 13:57:57 -0700 (PDT) From: Suresh K Satapati To: Keith Moore cc: Margaret Wasserman , Subject: Re: ocean: do not boil In-Reply-To: <200209262027.g8QKRt027033@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk seems like people still have a hard time accepting the need of NAT-PT/dns-alg; hopefully scenarios work will change that mindset. On Thu, 26 Sep 2002, Keith Moore wrote: > DNS-ALG and NAT-PT both change DNS results for some hosts, which breaks > apps that reasonably expect a consistent view of DNS. > > don't use NAT brain-damage as an excuse to break DNS also. > From owner-v6ops@ops.ietf.org Thu Sep 26 18:03:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23428 for ; Thu, 26 Sep 2002 18:03:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ugkA-000AK7-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 15:04:22 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17ugk2-000AJw-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 15:04:14 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QM2k027911; Thu, 26 Sep 2002 18:02:46 -0400 (EDT) Message-Id: <200209262202.g8QM2k027911@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Suresh K Satapati cc: Keith Moore , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 13:57:57 PDT.") Date: Thu, 26 Sep 2002 18:02:46 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > seems like people still have a hard time accepting the need of > NAT-PT/dns-alg; hopefully scenarios work will change that mindset. no doubt that there's some need for these things, but there's also a need for IPv6 to work better that IPv4+NAT. the scenarios work should indeed help to make the relative needs clear. From owner-v6ops@ops.ietf.org Thu Sep 26 19:06:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25016 for ; Thu, 26 Sep 2002 19:06:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uhiw-000CD1-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 16:07:10 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 17uhis-000CCn-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 16:07:06 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA09941 for ; Fri, 27 Sep 2002 00:07:04 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:1WUujgt+op74jhI0VTl6xEon1ZIeD6Rt@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8QN70n0005272 for ; Fri, 27 Sep 2002 00:07:00 +0100 Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id g8QN70p24535 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 00:07:00 +0100 Date: Fri, 27 Sep 2002 00:07:00 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: ocean: do not boil Message-ID: <20020926230700.GC23198@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <5.1.0.14.2.20020926095950.0214c0d0@mail.windriver.com> <200209261402.g8QE2q025864@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209261402.g8QE2q025864@astro.cs.utk.edu> User-Agent: Mutt/1.3.27i X-ECS-MailScanner: Found to be clean X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Sep 26, 2002 at 10:02:52AM -0400, Keith Moore wrote: > > I don't really know, since I don't manage networks. But I can imagine > that it's somewhat saner to have only one IP protocol to monitor and > only one set of host-to-address bindings to deal with. But are we in a position now to be able to monitor and manage a network over IPv6 only? (I haven't yet seen much discussion of this in v6ops, as an operational issue, or does it belong elsewhere?) Tim From owner-v6ops@ops.ietf.org Thu Sep 26 21:12:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27098 for ; Thu, 26 Sep 2002 21:12:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ujfE-000FTV-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 18:11:28 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17ujf9-000FT2-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 18:11:23 -0700 Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26230 for ; Thu, 26 Sep 2002 19:11:22 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H3200B9FOMYPX@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Thu, 26 Sep 2002 19:11:22 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H32003YFOMXL1@mail.sun.net> for v6ops@ops.ietf.org; Thu, 26 Sep 2002 19:11:22 -0600 (MDT) Date: Thu, 26 Sep 2002 18:10:26 -0700 From: Alain Durand Subject: Re: ocean: do not boil To: Margaret Wasserman Cc: itojun@iijlab.net, v6ops@ops.ietf.org Message-id: <3D93B002.6040405@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/20020719 Netscape/7.0 References: <" <5.1.0.14.2.20020926041139.04311cc0"@mail.windriver.com> <5.1.0.14.2.20020926095950.0214c0d0@mail.windriver.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Margaret Wasserman wrote: > > >> it's a tradeoff - NAT-PT is probably slightly less functional to apps >> (will >> cause a few more apps to break than NATs do) but in exchange for >> using it >> you get to get rid of all IPv4 traffic on your local network. > > > What is the advantage of getting rid of all IPv4 traffic on the local > network, since it will just be replaced with translated IPv6 traffic? > > Margaret This all thread is focussing at today's network. Does it make any sense in _today's_networks_ to turn off private v4 and translate v6-only instead? Maybe not. Simple reason: what works and what does not work is 99% the same, so no need to change for something that is still unproven technology. However, the real question is for network in the future. Please, let's think for a minute at 5 or 10 years for now, when IPv6 will be mainstream technology, but a lot of the Internet is still IPv4 only. Say that someone want to build a large network from scratch, whre hosts usually communicates with each other but need from time to time to communicate with IPv4 'things'. Do you want to tell this person that he/she needs to also deploy IPv4? - Alain. From owner-v6ops@ops.ietf.org Thu Sep 26 22:54:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29393 for ; Thu, 26 Sep 2002 22:54:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulG6-000INb-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 19:53:38 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17ulG2-000INP-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 19:53:34 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D10542F53; Thu, 26 Sep 2002 22:53:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 22:53:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 22:53:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93AA@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlYC0klP3d0IxBRGWFsYZxQ2BD9wAcLiig From: "Bound, Jim" To: "Keith Moore" Cc: , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 02:53:33.0583 (UTC) FILETIME=[117DE9F0:01C265D1] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA29393 most will for sure. what I am concerned about is that we don't have mechanisms for those who want to not do nat at all. I think I am hearing from margaret and randy they don't want to work on that aspect of v6ops. I have a problem with that if that is the case and I would ask the working group to support me. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, September 26, 2002 9:25 AM > To: Bound, Jim > Cc: itojun@iijlab.net; Stewart Tansley; v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > every input I get is that they don't want NAT and want it > to go away as > > soon as possible. for "some" (I say some) I am being told > how fast can > > I get rid of IPv4 period at least on my site. > > that's quite interesting, and encouraging. what it indicates to me is > that people need a way to disable IPv4-NAT and still leave > IPv6 running. > I don't think that's rocket science. > > and I understand why sites might want to get rid of IPv4 as > much as possible, > as soon as possible. but it's hard to believe that most sites > won't need at > least some IPv4-NAT in addition to IPv6 during a transition phase, > at least for awhile. if nothing else many locally-used apps > will have IPv4 > wired into them, and it will take time to upgrade all of those apps. > > Keith > From owner-v6ops@ops.ietf.org Thu Sep 26 23:04:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29591 for ; Thu, 26 Sep 2002 23:04:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulQp-000Ilb-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:04:43 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17ulQm-000IlJ-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:04:40 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BA089941; Thu, 26 Sep 2002 23:04:39 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 23:04:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 23:04:39 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93AE@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlZXE2TtDjtUCeQ3iu3GM/i1mQ0AAbQ87A From: "Bound, Jim" To: "Keith Moore" , "Margaret Wasserman" Cc: , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 03:04:39.0536 (UTC) FILETIME=[9E6E4700:01C265D2] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29591 the advantage is that IPv6 apps must be deployed and if IPv6 is the network preference then that supports that effort. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, September 26, 2002 10:03 AM > To: Margaret Wasserman > Cc: Keith Moore; Bound, Jim; itojun@iijlab.net; Stewart Tansley; > v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > What is the advantage of getting rid of all IPv4 traffic on > the local > > network, since it will just be replaced with translated > IPv6 traffic? > > I don't really know, since I don't manage networks. But I can imagine > that it's somewhat saner to have only one IP protocol to monitor and > only one set of host-to-address bindings to deal with. > From owner-v6ops@ops.ietf.org Thu Sep 26 23:04:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29607 for ; Thu, 26 Sep 2002 23:04:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulSC-000Iq2-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:06:08 -0700 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17ulS9-000Ipp-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:06:05 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id BA3825A7C; Thu, 26 Sep 2002 23:06:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 23:06:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 23:06:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93AF@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlZz0PavP0o8XARbawnMPr3HufmAAa3pnw From: "Bound, Jim" To: "Erik Nordmark" , "Keith Moore" Cc: "Margaret Wasserman" , , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 03:06:04.0593 (UTC) FILETIME=[D120F210:01C265D2] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29607 yes. this would be a cost for a network wanting to do this they would have to weigh against other approaches. This is the kind of metric I think we need to record for each mechanism. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Thursday, September 26, 2002 10:16 AM > To: Keith Moore > Cc: Margaret Wasserman; Bound, Jim; itojun@iijlab.net; > Stewart Tansley; > v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > it's a tradeoff - NAT-PT is probably slightly less > functional to apps (will > > cause a few more apps to break than NATs do) but in > exchange for using it > > you get to get rid of all IPv4 traffic on your local network. > > But you can get rid of the local IPv4 traffic (i.e. no need > to configure > local IPv4 routing) by tunneling IPv4 in IPv6 locally and > using the DSTM > DHCP options for getting such tunnels configured. > > This requires implementing more stuff on the nodes, and it adds > tunneling overhead on the wire. > > Erik > > From owner-v6ops@ops.ietf.org Thu Sep 26 23:05:48 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29623 for ; Thu, 26 Sep 2002 23:05:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulTV-000It0-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:07:29 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17ulTS-000Isp-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:07:26 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8E0152C1D; Thu, 26 Sep 2002 23:07:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 23:07:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 23:07:25 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93B0@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlZ9LV7ndOBNCfRxOuOd6dDmM3yAAawp6A From: "Bound, Jim" To: "Keith Moore" , "Erik Nordmark" Cc: "Margaret Wasserman" , , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 03:07:25.0311 (UTC) FILETIME=[013D88F0:01C265D3] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29623 yes yes yes yes. And add the Cost and our best guess performance factor to it as a matrix as in mail I sent the other day. this would be highly useful to operators and users planning v6 networks too. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, September 26, 2002 10:20 AM > To: Erik Nordmark > Cc: Keith Moore; Margaret Wasserman; Bound, Jim; itojun@iijlab.net; > Stewart Tansley; v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > > it's a tradeoff - NAT-PT is probably slightly less > functional to apps (will > > > cause a few more apps to break than NATs do) but in > exchange for using it > > > you get to get rid of all IPv4 traffic on your local network. > > > > But you can get rid of the local IPv4 traffic (i.e. no need > to configure > > local IPv4 routing) by tunneling IPv4 in IPv6 locally and > using the DSTM > > DHCP options for getting such tunnels configured. > > yes you can, and this makes far more sense to me than using NAT-PT. > in most cases tunneling seems far better than messing with DNS. > > it would be interesting to see all of these scenarios > compared side-by-side. > > Keith > From owner-v6ops@ops.ietf.org Thu Sep 26 23:06:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29637 for ; Thu, 26 Sep 2002 23:06:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulU1-000Ith-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:08:01 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17ulTs-000ItT-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:07:52 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8R354028534; Thu, 26 Sep 2002 23:05:04 -0400 (EDT) Message-Id: <200209270305.g8R354028534@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Keith Moore" , itojun@iijlab.net, "Stewart Tansley" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 22:53:33 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B02BE93AA@tayexc13.americas.cpqcorp.net> Date: Thu, 26 Sep 2002 23:05:04 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > what I am concerned about is that we don't have mechanisms > for those who want to not do nat at all. that's a rather odd statement, or at least I don't understand it. surely we have such mechanisms in native v4 and native v6? the only legitimate reason to use nat is to compensate for a shortage of IPv4 addresses. if a site can get enough IPv4 addresses to not use NAT for v4, or if the site can avoid using v4 altogether, it should never need to use a NAT. and anyone who makes a NAT for v6 should be fed to piranha fish. Keith From owner-v6ops@ops.ietf.org Thu Sep 26 23:07:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29655 for ; Thu, 26 Sep 2002 23:07:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulVS-000Iwr-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:09:30 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17ulVJ-000IwZ-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:09:21 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8R36i028563; Thu, 26 Sep 2002 23:06:44 -0400 (EDT) Message-Id: <200209270306.g8R36i028563@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Keith Moore" , "Margaret Wasserman" , itojun@iijlab.net, "Stewart Tansley" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 23:04:39 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B02BE93AE@tayexc13.americas.cpqcorp.net> Date: Thu, 26 Sep 2002 23:06:44 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > the advantage is that IPv6 apps must be deployed and if IPv6 > is the network preference then that supports that effort. ah yes, the coercive model of network administration. well, if that's how people want to effect a transition then I'm sure vendors will be happy to supply tools to let them do so - it sounds like a good market opportunity. Keith From owner-v6ops@ops.ietf.org Thu Sep 26 23:13:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29784 for ; Thu, 26 Sep 2002 23:13:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulZw-000JBh-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:14:08 -0700 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 17ulZs-000JBI-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:14:04 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 3F54958D5; Thu, 26 Sep 2002 23:14:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 23:14:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 23:14:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5BB@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJlbTBm6u0aMaVcTBONujou3xfYVQAZe3Kg From: "Bound, Jim" To: "Behcet Sarikaya" Cc: X-OriginalArrivalTime: 27 Sep 2002 03:14:03.0880 (UTC) FILETIME=[EECE5680:01C265D3] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29784 Hi Bechet, What I hear and see in the planning of ipv6 with customers is they are doing everything they can to avoid the use of NAT with IPv6. But as Erik stated I also hear they are very worried about tunneling overhead and tunneling adds its own form of managed cost. In the case of DSTM or ISATAP they have told me it MUST be implemented transparently to them. But the pain from NAT is the loss of end-2-end and that is what I hear as the driving factor for them moving to ipv6 when they exist with current NAT. Now users who don't use NAT or who were duped into using it for security (this is too bad really but it happened) they have different view as network planners. What they would like to do is not have to suddenly use NAT when they now deploy IPv6. This seems illogical to them. I think if we continue the discussion of the issues of a parallel v4 with v6 and tunnels or nats within the matrix of that we can provide at least a close set of results for different network definition behaviors. This will also as a note help implementors like me build this as transparently as possible and choose which ones to do first. This is selfish need on my part clearly. /jim > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Thursday, September 26, 2002 10:59 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > Hi Jim, > > Bound, Jim wrote: > > >every input I get is that they don't want NAT and want it to > go away as soon as possible. for "some" (I say some) I am > being told how fast can I get rid of IPv4 period at least on > my site. that "some" is as important as the Lowest Common > Denominator or one size fits all view to me as an engineer. > > > > > > I would like to hope that you are right (and are in line with the > operators and enterprises). For Keith, I understand, in academia one > wants the latest. > What are the views then on the issue of IPv6 NATs? > > >/jim > > > > > > > > --behcet > > >> > >> > > From owner-v6ops@ops.ietf.org Thu Sep 26 23:20:56 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29933 for ; Thu, 26 Sep 2002 23:20:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ulgy-000JY5-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:21:24 -0700 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 17ulgu-000JXl-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:21:21 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E72B73680; Thu, 26 Sep 2002 23:21:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 23:21:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 23:21:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93B5@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJljFbfBU40O2EoReaFKl+Y2J+YTwASGZHA From: "Bound, Jim" To: "Senthil Sivakumar" , "Margaret Wasserman" Cc: "Keith Moore" , , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 03:21:17.0728 (UTC) FILETIME=[F1664A00:01C265D4] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA29933 Just as a note this is one of the benefits stated in DSTM and objective. IPv6 becomes the dominant protocol. /jim > -----Original Message----- > From: Senthil Sivakumar [mailto:ssenthil@cisco.com] > Sent: Thursday, September 26, 2002 2:42 PM > To: Margaret Wasserman > Cc: Keith Moore; Bound, Jim; itojun@iijlab.net; Stewart Tansley; > v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > > On Thu, 26 Sep 2002, Margaret Wasserman wrote: > > > > > > > >it's a tradeoff - NAT-PT is probably slightly less > functional to apps (will > > >cause a few more apps to break than NATs do) but in > exchange for using it > > >you get to get rid of all IPv4 traffic on your local network. > > > > What is the advantage of getting rid of all IPv4 traffic on > the local > > network, since it will just be replaced with translated > IPv6 traffic? > > > You dont have to run IPv4 routing protocols along with IPv6 routing > protocols, which IMO, is an operational advantage. > > Senthil > > Margaret > > > > > > > > > > From owner-v6ops@ops.ietf.org Thu Sep 26 23:45:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00289 for ; Thu, 26 Sep 2002 23:45:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17um4J-000KHO-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:45:31 -0700 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17um4F-000KHD-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:45:27 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4C7AF2FC7; Thu, 26 Sep 2002 23:45:27 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 23:45:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 23:45:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93B9@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJl0q+R1IDF499kQramtCAftDJRnQABY7tQ From: "Bound, Jim" To: "Keith Moore" Cc: , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 03:45:27.0094 (UTC) FILETIME=[5149FD60:01C265D8] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00289 I was thinking Grizzly Bears as they do it quickly so it dont hurt :--) /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, September 26, 2002 11:05 PM > To: Bound, Jim > Cc: Keith Moore; itojun@iijlab.net; Stewart Tansley; > v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > what I am concerned about is that we don't have mechanisms > > for those who want to not do nat at all. > > that's a rather odd statement, or at least I don't understand it. > surely we have such mechanisms in native v4 and native v6? > > the only legitimate reason to use nat is to compensate for a shortage > of IPv4 addresses. if a site can get enough IPv4 addresses to not > use NAT for v4, or if the site can avoid using v4 altogether, it > should never need to use a NAT. > > and anyone who makes a NAT for v6 should be fed to piranha fish. > > Keith > From owner-v6ops@ops.ietf.org Thu Sep 26 23:47:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00382 for ; Thu, 26 Sep 2002 23:47:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17um7f-000KPN-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:48:59 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17um7b-000KP3-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:48:55 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1A6FF2EB5; Thu, 26 Sep 2002 23:48:55 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 26 Sep 2002 23:48:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Thu, 26 Sep 2002 23:48:54 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93BA@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJl0uqfS8FPG/+wS5G8+LR8O85EKwABXXig From: "Bound, Jim" To: "Keith Moore" Cc: "Margaret Wasserman" , , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 03:48:54.0724 (UTC) FILETIME=[CD0BD040:01C265D8] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00382 Part of how the network will be deployed will be why they wanted to do it in the first place. The only reason I keep bringing this aspect of things up is because I thought I heard a single view of transition and the set we need to work on. And it scares me because we need a lot of different tools to get ipv6 transitioned and to inteoperate with legacy v4. My reason for this diatribe is to help bring out our assumptions here. If we don't know or agree on the assumptions for our engineering work we will battle and debate longer than if we get that out of the way. That is part of any good engineering process. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, September 26, 2002 11:07 PM > To: Bound, Jim > Cc: Keith Moore; Margaret Wasserman; itojun@iijlab.net; > Stewart Tansley; > v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > > the advantage is that IPv6 apps must be deployed and if IPv6 > > is the network preference then that supports that effort. > > ah yes, the coercive model of network administration. > > well, if that's how people want to effect a transition then I'm > sure vendors will be happy to supply tools to let them do so - > it sounds like a good market opportunity. > > Keith > From owner-v6ops@ops.ietf.org Thu Sep 26 23:55:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00509 for ; Thu, 26 Sep 2002 23:55:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17umDo-000Kff-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 20:55:20 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17umDf-000KfS-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 20:55:11 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8R3qT028981; Thu, 26 Sep 2002 23:52:30 -0400 (EDT) Message-Id: <200209270352.g8R3qT028981@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Keith Moore" , "Margaret Wasserman" , itojun@iijlab.net, "Stewart Tansley" , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 23:48:54 EDT.") <9C422444DE99BC46B3AD3C6EAFC9711B02BE93BA@tayexc13.americas.cpqcorp.net> Date: Thu, 26 Sep 2002 23:52:29 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I do think we will need a variety of transition tools because not everyone's transition scenario will be the same. At the same time, some of the tools we have seem clearly superior and more widely applicable to others that cover (some of) the same spaces. So it would be good if we could identify some of the less useful tools and/or concentrate on the more useful tools and any missing pieces that are identified. From owner-v6ops@ops.ietf.org Thu Sep 26 23:59:07 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00612 for ; Thu, 26 Sep 2002 23:59:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17umIy-000KsZ-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:00:40 -0700 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17umIs-000Ks9-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:00:34 -0700 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 10BCB87D; Fri, 27 Sep 2002 00:00:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 27 Sep 2002 00:00:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Fri, 27 Sep 2002 00:00:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93BE@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJl2V2ovGc9YCp0Tu2TfHDOKs6TLwAAOltQ From: "Bound, Jim" To: "Keith Moore" Cc: "Margaret Wasserman" , , "Stewart Tansley" , X-OriginalArrivalTime: 27 Sep 2002 04:00:33.0885 (UTC) FILETIME=[6DC750D0:01C265DA] X-Spam-Status: No, hits=0.4 required=5.0 tests=SUPERLONG_LINE version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00612 agree completely. I completely support defining the lowest common denominators for sure. I just don't think that should preclude discussion on other tools and topics thats all. I can operate in a multi-threaded manner :--) /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Thursday, September 26, 2002 11:52 PM > To: Bound, Jim > Cc: Keith Moore; Margaret Wasserman; itojun@iijlab.net; > Stewart Tansley; > v6ops@ops.ietf.org > Subject: Re: ocean: do not boil > > > I do think we will need a variety of transition tools because > not everyone's > transition scenario will be the same. At the same time, some > of the tools > we have seem clearly superior and more widely applicable to others > that cover (some of) the same spaces. So it would be good if we could > identify some of the less useful tools and/or concentrate on the more > useful tools and any missing pieces that are identified. > From owner-v6ops@ops.ietf.org Fri Sep 27 00:03:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00726 for ; Fri, 27 Sep 2002 00:03:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17umLw-000L0L-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:03:44 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17umLs-000L05-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:03:40 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F36EB4B22; Fri, 27 Sep 2002 13:03:38 +0900 (JST) To: Harald Koch Cc: v6ops@ops.ietf.org In-reply-to: chk's message of Thu, 26 Sep 2002 11:30:22 -0400. <32072.1033054222@elisabeth.cfrq.net> 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: tiny v6 operational issue From: itojun@iijlab.net Date: Fri, 27 Sep 2002 13:03:38 +0900 Message-Id: <20020927040338.F36EB4B22@coconut.itojun.org> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >The nameservers for 'ops.ietf.org' (the host for this list) are listed >as: > DOKKA.MAXWARE.NO. > NN.UNINETT.NO. > PSG.COM. >PSG.COM tells me that its addresses are: > A 147.28.0.62 > AAAA 2001:418:1::62 >DNS lookups to 2001:418:1::62 give me "udp port domain unreachable". >Conclusions left as an exercise to the reader. it's not a problem, an FQDN identifies a host (or interface in IPv6 case) and not services. itojun From owner-v6ops@ops.ietf.org Fri Sep 27 00:26:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01535 for ; Fri, 27 Sep 2002 00:26:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17umiH-000Lqx-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:26:49 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17umiE-000Lqm-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:26:46 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B48444B22; Fri, 27 Sep 2002 13:26:44 +0900 (JST) To: Suresh K Satapati Cc: v6ops@ops.ietf.org In-reply-to: satapati's message of Thu, 26 Sep 2002 09:24:05 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ocean: do not boil From: itojun@iijlab.net Date: Fri, 27 Sep 2002 13:26:44 +0900 Message-Id: <20020927042644.B48444B22@coconut.itojun.org> X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Now the dual-stack problem: with NAT-PT, dual-stack will always be forced >to use a IPv6-mapped address (translation path) that the DNS-ALG >synthesized for a v4 destination. dual-stack could very well use IPv4 to >talk to the destination, but is forced to use IPv6+NAT-PT because of >DNS-ALG's current behavior. this is assuming dual-stack is sending AAAA >first, and then A; but not true for other cases. site -> outside: - if the site uses private IPv4 addrss and IPv4 NAT, it doesn't really matter if we use NAT-PT or IPv4 NAT. within site - DNS-ALG needs to be clever when returning synthesized AAAA address for NAT-PT. for instance, DNS-ALG could do the following when asked for AAAA of foo.example.com: query AAAA for foo.example.com - it's not there query A for foo.example.com - it should be there (X) if X is within the site, return empty answer section with NOERROR (indicate that foo.example.com does not have AAAA, and invite client to use IPv4) if X is outside the site, return synthesized AAAA record for NAT-PT translation. itojun From owner-v6ops@ops.ietf.org Fri Sep 27 00:33:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01664 for ; Fri, 27 Sep 2002 00:33:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17umpa-000M9G-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:34:22 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17umpP-000M8r-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:34:11 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id F1CFD4B22; Fri, 27 Sep 2002 13:34:09 +0900 (JST) To: Suresh K Satapati Cc: Margaret Wasserman , v6ops@ops.ietf.org In-reply-to: satapati's message of Thu, 26 Sep 2002 11:38:18 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ocean: do not boil From: itojun@iijlab.net Date: Fri, 27 Sep 2002 13:34:09 +0900 Message-Id: <20020927043409.F1CFD4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Node should not be aware of presence of NAT-PT. can't agree more. itojun From owner-v6ops@ops.ietf.org Fri Sep 27 00:48:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01806 for ; Fri, 27 Sep 2002 00:48:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17un4A-000MZ9-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:49:26 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17un45-000MYj-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:49:21 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5FC144B23 for ; Fri, 27 Sep 2002 13:49:20 +0900 (JST) To: v6ops@ops.ietf.org Subject: IPv6 tunnel over NAT X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Fri, 27 Sep 2002 13:49:20 +0900 Message-Id: <20020927044920.5FC144B23@coconut.itojun.org> X-Spam-Status: No, hits=0.5 required=5.0 tests=NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk there's a widely-practiced alternative to Teredo, and which does not need any special behavior from NAT wrt UDP translation behavior. IPv6 over PPP over TCP/SSH. it needs no documentation. itojun From owner-v6ops@ops.ietf.org Fri Sep 27 00:57:11 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01915 for ; Fri, 27 Sep 2002 00:57:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unBf-000Mmj-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:57:11 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17unBX-000MmU-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:57:03 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8R4sK029672; Fri, 27 Sep 2002 00:54:20 -0400 (EDT) Message-Id: <200209270454.g8R4sK029672@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Suresh K Satapati , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Fri, 27 Sep 2002 13:34:09 +0900.") <20020927043409.F1CFD4B22@coconut.itojun.org> Date: Fri, 27 Sep 2002 00:54:20 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >Node should not be aware of presence of NAT-PT. > > can't agree more. not clear to me; if NAT-PT affects how apps work, maybe they need to know it's there so they don't make bogus assumptions. From owner-v6ops@ops.ietf.org Fri Sep 27 00:57:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01931 for ; Fri, 27 Sep 2002 00:57:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unC6-000MoB-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:57:38 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17unBy-000Mny-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:57:30 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8R4sv029692; Fri, 27 Sep 2002 00:54:57 -0400 (EDT) Message-Id: <200209270454.g8R4sv029692@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Harald Koch , v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue In-reply-to: (Your message of "Fri, 27 Sep 2002 13:03:38 +0900.") <20020927040338.F36EB4B22@coconut.itojun.org> Date: Fri, 27 Sep 2002 00:54:57 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > it's not a problem, an FQDN identifies a host (or interface in IPv6 > case) and not services. not in the last 10 or so years it doesn't. From owner-v6ops@ops.ietf.org Fri Sep 27 00:57:57 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01951 for ; Fri, 27 Sep 2002 00:57:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unDw-000MtO-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 21:59:32 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17unDn-000Mt7-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 21:59:24 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8R4un029719; Fri, 27 Sep 2002 00:56:49 -0400 (EDT) Message-Id: <200209270456.g8R4un029719@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Suresh K Satapati , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Fri, 27 Sep 2002 13:26:44 +0900.") <20020927042644.B48444B22@coconut.itojun.org> Date: Fri, 27 Sep 2002 00:56:49 -0400 X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > for instance, DNS-ALG could do the following when asked > for AAAA of foo.example.com: > query AAAA for foo.example.com - it's not there > query A for foo.example.com - it should be there (X) > if X is within the site, return empty answer section with > NOERROR (indicate that foo.example.com does not have > AAAA, and invite client to use IPv4) > if X is outside the site, return synthesized AAAA record > for NAT-PT translation. > synthesized AAAA records should be forbidden. they make apps think they have a transparent v6 connection when they don't. Keith From owner-v6ops@ops.ietf.org Fri Sep 27 01:04:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02069 for ; Fri, 27 Sep 2002 01:04:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unJl-000N9Q-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 22:05:33 -0700 Received: from [3ffe:501:1802::5] (helo=nebula.sm.sony.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 17unJh-000N6y-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 22:05:30 -0700 Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id g8R54rS21470; Fri, 27 Sep 2002 14:04:54 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id g8R54fR05839; Fri, 27 Sep 2002 14:04:41 +0900 (JST) Date: Fri, 27 Sep 2002 14:04:41 +0900 (JST) From: Atsushi Onoe Message-Id: <200209270504.g8R54fR05839@nest.sm.sony.co.jp> To: itojun@iijlab.net Cc: chk@pobox.com, v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue In-Reply-To: Your message of "Fri, 27 Sep 2002 13:03:38 +0900" <20020927040338.F36EB4B22@coconut.itojun.org> References: <20020927040338.F36EB4B22@coconut.itojun.org> X-Mailer: Cue version 0.6 (020925-1632/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > >The nameservers for 'ops.ietf.org' (the host for this list) are listed > >as: > > DOKKA.MAXWARE.NO. > > NN.UNINETT.NO. > > PSG.COM. > >PSG.COM tells me that its addresses are: > > A 147.28.0.62 > > AAAA 2001:418:1::62 > >DNS lookups to 2001:418:1::62 give me "udp port domain unreachable". > >Conclusions left as an exercise to the reader. > > it's not a problem, an FQDN identifies a host (or interface in IPv6 > case) and not services. It _IS_ a problem. It is effectively same condition as that the NS records point to a server where name server is not running. Of course, there is a chance to resolve by next available address or NS. But it IS a bogus configuration anyway, since it forces unneeded traffic and delay. Atsushi Onoe From owner-v6ops@ops.ietf.org Fri Sep 27 01:20:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02226 for ; Fri, 27 Sep 2002 01:20:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unYp-000NgT-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 22:21:07 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #1) id 17unYh-000NgI-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 22:20:59 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8R5KvIn015603; Thu, 26 Sep 2002 22:20:57 -0700 (PDT) Date: Thu, 26 Sep 2002 22:20:57 -0700 (PDT) From: Senthil Sivakumar To: itojun@iijlab.net cc: Suresh K Satapati , Subject: Re: ocean: do not boil In-Reply-To: <20020927042644.B48444B22@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002 itojun@iijlab.net wrote: > >Now the dual-stack problem: with NAT-PT, dual-stack will always be forced > >to use a IPv6-mapped address (translation path) that the DNS-ALG > >synthesized for a v4 destination. dual-stack could very well use IPv4 to > >talk to the destination, but is forced to use IPv6+NAT-PT because of > >DNS-ALG's current behavior. this is assuming dual-stack is sending AAAA > >first, and then A; but not true for other cases. > > site -> outside: > - if the site uses private IPv4 addrss and IPv4 NAT, it doesn't really > matter if we use NAT-PT or IPv4 NAT. The ALG support on NAT vs NAT-PT would be the difference. > within site > - DNS-ALG needs to be clever when returning synthesized AAAA address > for NAT-PT. for instance, DNS-ALG could do the following when asked > for AAAA of foo.example.com: > query AAAA for foo.example.com - it's not there > query A for foo.example.com - it should be there (X) > if X is within the site, return empty answer section with > NOERROR (indicate that foo.example.com does not have > AAAA, and invite client to use IPv4) How do you determine if X is within the site or outside? Senthil > if X is outside the site, return synthesized AAAA record > for NAT-PT translation. > > itojun > > From owner-v6ops@ops.ietf.org Fri Sep 27 01:31:14 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02411 for ; Fri, 27 Sep 2002 01:31:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unj2-000O4g-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 22:31:40 -0700 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by psg.com with esmtp (Exim 3.36 #1) id 17uniy-000O4M-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 22:31:36 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.25.24]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8R5VXIn018655; Thu, 26 Sep 2002 22:31:33 -0700 (PDT) Date: Thu, 26 Sep 2002 22:31:33 -0700 (PDT) From: Senthil Sivakumar To: Keith Moore cc: itojun@iijlab.net, Suresh K Satapati , Margaret Wasserman , Subject: Re: ocean: do not boil In-Reply-To: <200209270454.g8R4sK029672@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002, Keith Moore wrote: > > >Node should not be aware of presence of NAT-PT. > > > > can't agree more. > > not clear to me; if NAT-PT affects how apps work, maybe they > need to know it's there so they don't make bogus assumptions. > One of the projected advantages of NAT-PT is that you dont have to change the end hosts/apps. You are now suggesting the exact opposite. Senthil > From owner-v6ops@ops.ietf.org Fri Sep 27 01:44:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02655 for ; Fri, 27 Sep 2002 01:44:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unvl-000OXS-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 22:44:49 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17unvg-000OX8-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 22:44:44 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8R5iaX29964; Fri, 27 Sep 2002 08:44:36 +0300 Date: Fri, 27 Sep 2002 08:44:36 +0300 (EEST) From: Pekka Savola To: itojun@iijlab.net cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <20020927044920.5FC144B23@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002 itojun@iijlab.net wrote: > there's a widely-practiced alternative to Teredo, and which does not > need any special behavior from NAT wrt UDP translation behavior. > > IPv6 over PPP over TCP/SSH. it needs no documentation. No TCP over TCP, please... :-( -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Sep 27 01:46:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02736 for ; Fri, 27 Sep 2002 01:46:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unz4-000Ogn-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 22:48:14 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17unz1-000OgV-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 22:48:11 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4CA0A4B22; Fri, 27 Sep 2002 14:48:10 +0900 (JST) To: Senthil Sivakumar Cc: Suresh K Satapati , v6ops@ops.ietf.org In-reply-to: ssenthil's message of Thu, 26 Sep 2002 22:20:57 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ocean: do not boil From: itojun@iijlab.net Date: Fri, 27 Sep 2002 14:48:10 +0900 Message-Id: <20020927054810.4CA0A4B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >How do you determine if X is within the site or outside? NAT-PT device usually reside at the site border, so you can configure what's inside (like 10.0.0.0/8) and what's not. itojun From owner-v6ops@ops.ietf.org Fri Sep 27 01:47:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02767 for ; Fri, 27 Sep 2002 01:47:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17unzh-000Ohg-00 for v6ops-data@psg.com; Thu, 26 Sep 2002 22:48:53 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17unze-000OhT-00 for v6ops@ops.ietf.org; Thu, 26 Sep 2002 22:48:50 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8R5mHA30004; Fri, 27 Sep 2002 08:48:17 +0300 Date: Fri, 27 Sep 2002 08:48:17 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: managing network over v6 [Re: ocean: do not boil] In-Reply-To: <20020926230700.GC23198@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002, Tim Chown wrote: > On Thu, Sep 26, 2002 at 10:02:52AM -0400, Keith Moore wrote: > > > > I don't really know, since I don't manage networks. But I can imagine > > that it's somewhat saner to have only one IP protocol to monitor and > > only one set of host-to-address bindings to deal with. > > But are we in a position now to be able to monitor and manage a network over > IPv6 only? (I haven't yet seen much discussion of this in v6ops, as an > operational issue, or does it belong elsewhere?) Depends on what you want to use it for. At least some router vendors already support: - DNS queries over IPv6 - SSH/telnet over IPv6 - SNMP over IPv6 (I've personally used this too.) - IPv4 over IPv6 tunnels - (I'm not aware of the implementation status of Tacacs/Radius situation, if used, but that could be one element) So at least most components We've found useful are there. Not in all the implementations, of course. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Sep 27 07:03:16 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16435 for ; Fri, 27 Sep 2002 07:03:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17ustG-0004gV-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 04:02:34 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17ust8-0004g6-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 04:02:26 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8RAxj016166; Fri, 27 Sep 2002 06:59:45 -0400 (EDT) Message-Id: <200209271059.g8RAxj016166@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Senthil Sivakumar cc: Keith Moore , itojun@iijlab.net, Suresh K Satapati , Margaret Wasserman , v6ops@ops.ietf.org Subject: Re: ocean: do not boil In-reply-to: (Your message of "Thu, 26 Sep 2002 22:31:33 PDT.") Date: Fri, 27 Sep 2002 06:59:45 -0400 X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > not clear to me; if NAT-PT affects how apps work, maybe they > > need to know it's there so they don't make bogus assumptions. > > > One of the projected advantages of NAT-PT is that you dont have to change > the end hosts/apps. You are now suggesting the exact opposite. it wasn't true for NAT; it isn't true for NAT-PT either. NAT lets you get away without changing *some* hosts/apps; for the rest operation becomes considerably more difficult. and for many the whole point of IPv6 is to get away from NAT. From owner-v6ops@ops.ietf.org Fri Sep 27 09:50:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20641 for ; Fri, 27 Sep 2002 09:50:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uvVZ-0007P2-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 06:50:17 -0700 Received: from [2001:470:1f00:ffff::35f] (helo=persephone.cfrq.net) by psg.com with esmtp (Exim 3.36 #1) id 17uvVV-0007Or-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 06:50:14 -0700 Received: from elisabeth.cfrq.net (elisabeth.chk.cfrq.net [199.85.99.82] (may be forged)) by persephone.cfrq.net (8.12.2/8.12.2) with ESMTP id g8RDo8mR028234 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 27 Sep 2002 09:50:09 -0400 Received: from elisabeth.cfrq.net (localhost [127.0.0.1]) by elisabeth.cfrq.net (8.12.2/8.12.2) with ESMTP id g8RDo8Fm009287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Sep 2002 09:50:08 -0400 Received: from elisabeth.cfrq.net (chk@localhost) by elisabeth.cfrq.net (8.12.2/8.12.2/Submit) with ESMTP id g8RDo5PX009284 for ; Fri, 27 Sep 2002 09:50:06 -0400 X-Authentication-Warning: elisabeth.cfrq.net: chk owned process doing -bs To: v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue References: <20020927040338.F36EB4B22@coconut.itojun.org> <200209270504.g8R54fR05839@nest.sm.sony.co.jp> In-reply-to: Your message of "Fri, 27 Sep 2002 14:04:41 +0900". <200209270504.g8R54fR05839@nest.sm.sony.co.jp> From: Harald Koch MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9281.1033134605.1@elisabeth.cfrq.net> Date: Fri, 27 Sep 2002 09:50:05 -0400 Message-ID: <9283.1033134605@elisabeth.cfrq.net> X-Spam-Status: No, hits=-2.5 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,MAY_BE_FORGED version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > It _IS_ a problem. It is effectively same condition as that the NS records > point to a server where name server is not running. Of course, there is > a chance to resolve by next available address or NS. But it IS a bogus > configuration anyway, since it forces unneeded traffic and delay. The resolver(s) on my hosts (RH 7.2) do not fall back to the IPv4 address if the IPv6 address is unreachable. This is definitely a bug on the client side, but still aggravated the problem. -- Harald Koch From owner-v6ops@ops.ietf.org Fri Sep 27 10:16:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21359 for ; Fri, 27 Sep 2002 10:16:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uvv2-0007px-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 07:16:36 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17uvv0-0007pm-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 07:16:34 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17uvuz-0000y3-00; Fri, 27 Sep 2002 07:16:34 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Harald Koch Cc: v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue References: <20020927040338.F36EB4B22@coconut.itojun.org> <200209270504.g8R54fR05839@nest.sm.sony.co.jp> <9283.1033134605@elisabeth.cfrq.net> Message-Id: Date: Fri, 27 Sep 2002 07:16:34 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The resolver(s) on my hosts (RH 7.2) do not fall back to the IPv4 > address if the IPv6 address is unreachable. This is definitely a bug on > the client side, but still aggravated the problem. hey, it discovered my bug! i wonder if doc needs to be updated to check this. randy From owner-v6ops@ops.ietf.org Fri Sep 27 10:35:42 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21946 for ; Fri, 27 Sep 2002 10:35:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uwE2-0008By-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 07:36:14 -0700 Received: from [2001:298:308:1:2ae:d0ff:fe00:3b] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 3.36 #1) id 17uwDz-0008Bn-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 07:36:11 -0700 Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 730904B22; Fri, 27 Sep 2002 23:36:08 +0900 (JST) To: Harald Koch , v6ops@ops.ietf.org In-reply-to: randy's message of Fri, 27 Sep 2002 07:16:34 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: tiny v6 operational issue From: itojun@iijlab.net Date: Fri, 27 Sep 2002 23:36:08 +0900 Message-Id: <20020927143608.730904B22@coconut.itojun.org> X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >> The resolver(s) on my hosts (RH 7.2) do not fall back to the IPv4 >> address if the IPv6 address is unreachable. This is definitely a bug on >> the client side, but still aggravated the problem. could you name the implementation? i bet it is not the resolver in libc, as it won't traverse NS tree. itojun From owner-v6ops@ops.ietf.org Fri Sep 27 10:48:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22398 for ; Fri, 27 Sep 2002 10:48:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uwQK-0008RS-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 07:48:56 -0700 Received: from sj-msg-core-4.cisco.com ([171.71.163.54]) by psg.com with esmtp (Exim 3.36 #1) id 17uwQG-0008RH-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 07:48:52 -0700 Received: from mira-sjcd-4.cisco.com (IDENT:mirapoint@mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8REmkot012932; Fri, 27 Sep 2002 07:48:46 -0700 (PDT) Received: from [10.34.255.54] (stealth-10-34-255-54.cisco.com [10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id ACN82693; Fri, 27 Sep 2002 07:46:51 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <3D93B002.6040405@sun.com> References: <" <5.1.0.14.2.20020926041139.04311cc0"@mail.windriver.com> <5.1.0.14.2.20020926095950.0214c0d0@mail.windriver.com> <3D93B002.6040405@sun.com> Date: Fri, 27 Sep 2002 07:48:43 -0700 To: Alain Durand From: Steve Deering Subject: Re: ocean: do not boil Cc: Margaret Wasserman , itojun@iijlab.net, v6ops@ops.ietf.org Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I agree with Alain: the domain of applicability of NAT-PT (or other translation approach) is not so much networks/devices that are today running IPv4, but rather new kinds of networks/devices for which (for whatever reason) it is undesirable to run both IPv4 and IPv6 in parallel, while still needing some applications to work between IPv6-only devices and the existing IPv4 Internet. Examples *might* be low-cost wireless devices, where dollar- or power-cost of memory to hold two IP implementations might be the dominant concern, or the military's "wired warfighter" with his or her body-area network of IPv6-enabled sensors and weapons, linked into its environment with IPv6-specific autoconfiguration and ad-hoc routing protocols (but still needing access to the IPv4 world for some apps, like email to home). The specific scenarios where I've found myself suggesting NAT-PT recently are: - for customers who are planning 3G wireless networks, where it is still unclear whether the handset vendors will be producing IPv6-only handsets, or just dual-stack ones. The NAT-PT comes into play only the case of v6-only handsets. - for customers who are IPv6 True Believers, whose motivations for deploying IPv6-only hosts and/or networks go beyond just finding the easiest way to add IPv6 to an existing IPv4 environment. And as Alain said, at some point we may reach the stage that some regular ol' residential and corporate networks are be easier to run IPv6-only, whether because of strategic choices made by OS-vendors or specific technical benefits of IPv6 (e.g., being able to get rid of DHCP servers or whatever). Translators may become the preferred way for such networks to maintain access to the v4 world (access that is no better or worse than what they would get through an IPv4 NAT). Steve From owner-v6ops@ops.ietf.org Fri Sep 27 10:54:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22556 for ; Fri, 27 Sep 2002 10:54:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uwVS-0008Zd-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 07:54:14 -0700 Received: from [3ffe:501:1802::5] (helo=nebula.sm.sony.co.jp) by psg.com with esmtp (Exim 3.36 #1) id 17uwVP-0008Ya-00; Fri, 27 Sep 2002 07:54:11 -0700 Received: from nest.sm.sony.co.jp (onoe@localhost) by nebula.sm.sony.co.jp (8.11.6/8.11.3) with ESMTP id g8RErY626971; Fri, 27 Sep 2002 23:53:34 +0900 (JST) Received: (from onoe@localhost) by nest.sm.sony.co.jp (8.11.6/8.11.3) id g8RErIw00442; Fri, 27 Sep 2002 23:53:18 +0900 (JST) Date: Fri, 27 Sep 2002 23:53:18 +0900 (JST) From: Atsushi Onoe Message-Id: <200209271453.g8RErIw00442@nest.sm.sony.co.jp> To: randy@psg.com Cc: chk@pobox.com, v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue In-Reply-To: Your message of "Fri, 27 Sep 2002 07:16:34 -0700" References: X-Mailer: Cue version 0.6 (020925-1632/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > i wonder if doc needs to be updated to check this. It should be documented here in v6ops since it is not a dns problem but general problems among services. I.e. if you put AAAA record to a node, all the services at the node should be served also via IPv6. Otherwise, the FQDN should be splitted between the services which served only via IPv4 and served via IPv6/IPv4. Again, a client should be robust against such environment by trying all the addresses available. But the configuration for servers should avoid such inefficiency. Atsushi Onoe From owner-v6ops@ops.ietf.org Fri Sep 27 11:05:20 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22841 for ; Fri, 27 Sep 2002 11:05:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uwgh-0008o1-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 08:05:51 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17uwge-0008no-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 08:05:48 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17uwga-0002Jb-00; Fri, 27 Sep 2002 08:05:44 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Atsushi Onoe Cc: chk@pobox.com, v6ops@ops.ietf.org Subject: Re: tiny v6 operational issue References: <200209271453.g8RErIw00442@nest.sm.sony.co.jp> Message-Id: Date: Fri, 27 Sep 2002 08:05:44 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> i wonder if doc needs to be updated to check this. > It should be documented here in v6ops since it is not a dns problem but > general problems among services. I.e. if you put AAAA record to a node, > all the services at the node should be served also via IPv6. Otherwise, > the FQDN should be splitted between the services which served only via > IPv4 and served via IPv6/IPv4. it is obvious to me that one must provide all services on all addresses. given foo.bar. A 1.2.3.4 A 5.6.7.8 AAAA 2001:666:777::42 we do not currently require that all services provided on 1.2.3.4 also be provided on 5.6.7.8. so how can we explain doing so for 2001:666:777::42? and the splitting suggestion seems to put more semantics in names than the dns folk may feel appropriate. i suspect you are trying to bind more semantics to the dns than are generally expected there. randy From owner-v6ops@ops.ietf.org Fri Sep 27 12:58:03 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00110 for ; Fri, 27 Sep 2002 12:58:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uyR0-000BEF-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 09:57:46 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17uyQx-000BE1-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 09:57:43 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E66E718DA for ; Fri, 27 Sep 2002 12:57:41 -0400 (EDT) Date: Fri, 27 Sep 2002 12:57:41 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: References: <20020927044920.5FC144B23@coconut.itojun.org> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020927165742.E66E718DA@thrintun.hactrn.net> X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 08:44:36 +0300 (EEST), Pekka Savola wrote: > > On Fri, 27 Sep 2002 itojun@iijlab.net wrote: > > there's a widely-practiced alternative to Teredo, and which does not > > need any special behavior from NAT wrt UDP translation behavior. > > > > IPv6 over PPP over TCP/SSH. it needs no documentation. > > No TCP over TCP, please... :-( In the general case, I would agree, but this is not the general case. The question is whether IPv6/PPP/xyz/TCP is good enough for the particular case of hosts stuck behind a NAT that they cannot remove or upgrade. I think that the answer in this case may well be "yes". Please note that using PPP tunneling would also give us a handle on some of the nasty relay issues involved with Terado, since they would convert the exciting problem of what to do with tunneled packets from strangers into a boring matter of setting up accounts for each PPP identity, something that most ISPs already know how to do. To be fair, Terado isn't the only transition scheme that has relay problems, it's just the only one that has both has relay and NAT traversal problems. It's NAT traversal that makes PPP/TCP look good. For other relay problems (eg, 6to4) it might make sense to look into some kind of tunnel control using IPsec. Unless I misremember the spec, tunnel mode IPsec does allow the inner and outer versions of IP to be different, so one could have (eg) IPv6/ESP/IPv4 and the only additional cost over the normal 6to4 encapsulation would be the ESP header itself. Account setup for IPsec isn't as well understood as for PPP, but perhaps we can use what works for PPP as a model. From owner-v6ops@ops.ietf.org Fri Sep 27 13:27:06 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01068 for ; Fri, 27 Sep 2002 13:27:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uyth-000BxJ-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 10:27:25 -0700 Received: from patan.sun.com ([192.18.98.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uytd-000Bx0-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 10:27:21 -0700 Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25147; Fri, 27 Sep 2002 11:27:20 -0600 (MDT) Received: from dieselmeat.localnet.net (dsl199-10.Eng.Sun.COM [129.146.199.10]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g8RHRKda635623; Fri, 27 Sep 2002 10:27:20 -0700 (PDT) Date: Fri, 27 Sep 2002 10:26:32 -0700 (PDT) From: Jason Goldschmidt X-Sender: jgoldsch@dieselmeat.localnet.net To: Rob Austein cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <20020927165742.E66E718DA@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002, Rob Austein wrote: Hi Rob, > For other relay problems (eg, 6to4) it might make sense to look into > some kind of tunnel control using IPsec. Unless I misremember the > spec, tunnel mode IPsec does allow the inner and outer versions of IP > to be different, so one could have (eg) IPv6/ESP/IPv4 and the only > additional cost over the normal 6to4 encapsulation would be the ESP > header itself. Account setup for IPsec isn't as well understood as > for PPP, but perhaps we can use what works for PPP as a model. There is a problem with what you describe WRT 6to4. When a 6to4 router is sending a packet to a "native" IPv6 host it can "discover" a 6to4 relay router using the well known anycast address (RFC 3068) or might send the packet to a particular relay router (using unicast). Though it is not guaranteed that a response from the native IPv6 host will arrive at the 6to4 router by way of the same relay router. Routing on the native IPv6 internet will determine which relay router will be used to reply to 6to4 router in question. This makes it very difficult to create a security association with all 6to4 relay routers. Today there are only a few 6to4 relay routers deployed (AFAIK), but there is certainly no limit as to how many will be deployed in the future. The non-deterministic nature of what relay routers a 6to4 router may receive traffic from is the very nature of 6to4's security issues. -Jason From owner-v6ops@ops.ietf.org Fri Sep 27 14:12:59 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02900 for ; Fri, 27 Sep 2002 14:12:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uzbd-000DCD-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 11:12:49 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17uzbT-000DAw-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 11:12:39 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8RIBI028421; Fri, 27 Sep 2002 14:11:18 -0400 (EDT) Message-Id: <200209271811.g8RIBI028421@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rob Austein cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-reply-to: (Your message of "Fri, 27 Sep 2002 12:57:41 EDT.") <20020927165742.E66E718DA@thrintun.hactrn.net> Date: Fri, 27 Sep 2002 14:11:18 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > The question is whether IPv6/PPP/xyz/TCP is good enough for the > particular case of hosts stuck behind a NAT that they cannot remove or > upgrade. I think that the answer in this case may well be "yes". well, obviously it depends on the applications being run and the quality of the underlying links. if you're running real time apps over UDP over PPP over TCP over a lossy IP link, you'd probably be much happier using Teredo. do we really want to say, for instance, that it's okay for the generic solution to break streaming audio? Keith From owner-v6ops@ops.ietf.org Fri Sep 27 14:21:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07526 for ; Fri, 27 Sep 2002 14:21:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17uzkq-000DJv-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 11:22:20 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17uzkn-000DJk-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 11:22:17 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 64BDA190F for ; Fri, 27 Sep 2002 14:22:16 -0400 (EDT) Date: Fri, 27 Sep 2002 14:22:16 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: References: <20020927165742.E66E718DA@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020927182216.64BDA190F@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 10:26:32 -0700 (PDT), Jason Goldschmidt wrote: > > There is a problem with what you describe WRT 6to4. When a 6to4 router is > sending a packet to a "native" IPv6 host it can "discover" a 6to4 > relay router using the well known anycast address (RFC 3068) or might send > the packet to a particular relay router (using unicast). Though it is not > guaranteed that a response from the native IPv6 host will arrive at the > 6to4 router by way of the same relay router. Routing on the native > IPv6 internet will determine which relay router will be used to reply > to 6to4 router in question. This makes it very difficult to create a > security association with all 6to4 relay routers. Today there are only a > few 6to4 relay routers deployed (AFAIK), but there is certainly no limit > as to how many will be deployed in the future. The non-deterministic > nature of what relay routers a 6to4 router may receive traffic from is the > very nature of 6to4's security issues. Yeah, well, I never really bought the RFC 3068 anycast relay router model anyway, it's kludging around an IPv6 routing issue by turning it into an IPv4 routing issue :). I think it makes sense to break down this problem into two separate problems: traffic coming into the relay routers from the v4 side, and traffic coming into the relay routers from the v6 side. The key thing to note here is that most of the tunneling problems are for the entity that's decapsulating, not the entity that's encapsulating. I suppose there might be lurking issues for the encapsulator as well, but presumably the encapsulator has a reason for deciding to send traffic into the tunnel. It's the decapsulator that has to be worry about what this stuff is and whether it should be forwarding it or dropping it on the floor. So, getting back to the two cases: when traffic is coming into the relay routers from the v4 side, the relay router is the decapsulator and has a serious problem deciding what to do unless it has some kind of relationship with the encapsulator. That's what I'm suggesting we might be able to solve using IPsec. When traffic is coming into the relay routers from the v6 side, the relay router is the encapsulator, and has nothing to worry about (assuming that proper ingress filtering was done elsewhere in the v6 net, etcetera, but that's an understood problem, nothing new there). In this case it's the receiving 6to4 site router that's the decapsulator and has the worries, but, as I've mentioned in other postings, I think the problems for the 6to4 site router are much less severe because such a router can make reasonably sane decisions based on physical network topology (eg: "if it came in via an external interface, it does not go out again on an external interface, period"). From owner-v6ops@ops.ietf.org Fri Sep 27 15:07:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00999 for ; Fri, 27 Sep 2002 15:07:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v0R2-000EWX-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 12:05:56 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17v0Qz-000EWM-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 12:05:54 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 30DFE18DA for ; Fri, 27 Sep 2002 15:05:53 -0400 (EDT) Date: Fri, 27 Sep 2002 15:05:53 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <200209271811.g8RIBI028421@astro.cs.utk.edu> References: <20020927165742.E66E718DA@thrintun.hactrn.net> <200209271811.g8RIBI028421@astro.cs.utk.edu> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020927190553.30DFE18DA@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 14:11:18 -0400, Keith Moore wrote: > > well, obviously it depends on the applications being run and the > quality of the underlying links. if you're running real time apps > over UDP over PPP over TCP over a lossy IP link, you'd probably > be much happier using Teredo. do we really want to say, for instance, > that it's okay for the generic solution to break streaming audio? a) Begs the question of whether any of our transition tools are robust enough to support serious real-time streaming use. b) PPP/TCP looks like a reliable link with very erratic timing characteristics. I'm fairly certain that unidirectional streaming protocols can deal with that via buffering (so that it's not real time anymore). Whether the deployed implementations can or not is another matter. Bi-directional real time may be hard enough that (a) applies. From owner-v6ops@ops.ietf.org Fri Sep 27 15:07:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01162 for ; Fri, 27 Sep 2002 15:07:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v0PK-000ESH-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 12:04:10 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17v0PB-000ERm-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 12:04:01 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8RJ2j028885; Fri, 27 Sep 2002 15:02:45 -0400 (EDT) Message-Id: <200209271902.g8RJ2j028885@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rob Austein cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-reply-to: (Your message of "Fri, 27 Sep 2002 14:22:16 EDT.") <20020927182216.64BDA190F@thrintun.hactrn.net> Date: Fri, 27 Sep 2002 15:02:45 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Yeah, well, I never really bought the RFC 3068 anycast relay router > model anyway, it's kludging around an IPv6 routing issue by turning it > into an IPv4 routing issue :). granted that it doesn't change the issue to move it from v6 to v4, but what is the real problem you're concerned about? From owner-v6ops@ops.ietf.org Fri Sep 27 15:18:45 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07105 for ; Fri, 27 Sep 2002 15:18:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v0c4-000Eqv-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 12:17:20 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17v0c0-000EqX-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 12:17:16 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0D37318DA for ; Fri, 27 Sep 2002 15:17:16 -0400 (EDT) Date: Fri, 27 Sep 2002 15:17:15 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <200209271902.g8RJ2j028885@astro.cs.utk.edu> References: <20020927182216.64BDA190F@thrintun.hactrn.net> <200209271902.g8RJ2j028885@astro.cs.utk.edu> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020927191716.0D37318DA@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 15:02:45 -0400, Keith Moore wrote: > > > Yeah, well, I never really bought the RFC 3068 anycast relay router > > model anyway, it's kludging around an IPv6 routing issue by turning it > > into an IPv4 routing issue :). > > granted that it doesn't change the issue to move it from v6 to v4, > but what is the real problem you're concerned about? Many of the open packet relay problems (potential as DDoS reflectors, potential for circumvention of ingress controls, etc -- and note that this applies to all flavors of open packet relays, not just 6to4 relays) stem from treating the entire IPv4 internet as one giant link layer network, making it impossible to apply the usual tools that we use in the IPv4 universe (ingress control, fault isolation, etc) in any useful way. Now set the wayback machine to the days when we were still debating the relative merits of giant bridged networks versus routers in IPv4. Ring any bells? In other words, we have divide-and-conquer techniques for dealing with the problems that arise from excessively large link layer networks. We're not using them at the moment because they'd require us to divide the relevant portions of the IPv6 address space up into smaller subnetworks and deploy routers, which would be unpleasant, but might not be as unpleasant as living with various instantiations of the open packet relay problem for the next decade. From owner-v6ops@ops.ietf.org Fri Sep 27 16:00:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08863 for ; Fri, 27 Sep 2002 16:00:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v1Jh-000G4u-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 13:02:25 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17v1Je-000G4j-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 13:02:22 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8RK2Hk04679; Fri, 27 Sep 2002 23:02:17 +0300 Date: Fri, 27 Sep 2002 23:02:16 +0300 (EEST) From: Pekka Savola To: Rob Austein cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <20020927165742.E66E718DA@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002, Rob Austein wrote: > At Fri, 27 Sep 2002 08:44:36 +0300 (EEST), Pekka Savola wrote: > > > > On Fri, 27 Sep 2002 itojun@iijlab.net wrote: > > > there's a widely-practiced alternative to Teredo, and which does not > > > need any special behavior from NAT wrt UDP translation behavior. > > > > > > IPv6 over PPP over TCP/SSH. it needs no documentation. > > > > No TCP over TCP, please... :-( > > In the general case, I would agree, but this is not the general case. > The question is whether IPv6/PPP/xyz/TCP is good enough for the > particular case of hosts stuck behind a NAT that they cannot remove or > upgrade. I think that the answer in this case may well be "yes". > > Please note that using PPP tunneling would also give us a handle on > some of the nasty relay issues involved with Terado, since they would > convert the exciting problem of what to do with tunneled packets from > strangers into a boring matter of setting up accounts for each PPP > identity, something that most ISPs already know how to do. [...] I do not believe, as of late, that Teredo will be the right solution. Instead, I think we just need a generic bidirectional tunnel through the NAT; in addition to using some UDP port there should be some keepalives and such of course. Plain and simple, always works, no problems at all. Except it must be manually configured. Can't be helped, really, but Teredo was always a cornercase anyway. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Sep 27 16:12:55 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09439 for ; Fri, 27 Sep 2002 16:12:54 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v1VB-000GPI-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 13:14:17 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17v1V7-000GP6-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 13:14:13 -0700 Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01813 for ; Fri, 27 Sep 2002 14:14:12 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H3400BBU5JN1Q@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 27 Sep 2002 14:14:12 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H340035A5JML1@mail.sun.net> for v6ops@ops.ietf.org; Fri, 27 Sep 2002 14:14:11 -0600 (MDT) Date: Fri, 27 Sep 2002 13:13:14 -0700 From: Alain Durand Subject: Re: IPv6 tunnel over NAT To: Rob Austein Cc: v6ops@ops.ietf.org Message-id: <3D94BBDA.6070808@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/20020719 Netscape/7.0 References: <20020927165742.E66E718DA@thrintun.hactrn.net> <20020927182216.64BDA190F@thrintun.hactrn.net> X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Rob Austein wrote: >When traffic is coming into the relay routers from the v6 side, the >relay router is the encapsulator, and has nothing to worry about >(assuming that proper ingress filtering was done elsewhere in the v6 >net, etcetera, but that's an understood problem, nothing new there). >In this case it's the receiving 6to4 site router that's the >decapsulator and has the worries, but, as I've mentioned in other >postings, I think the problems for the 6to4 site router are much less >severe because such a router can make reasonably sane decisions based >on physical network topology (eg: "if it came in via an external >interface, it does not go out again on an external interface, >period"). > No. The 6to4 router has a serious problem in that space. IPv6 routing using 6to4 relays is asymetric, a 6to4 router may choose which relay it send its traffic to for native v6, but has absolutly no control where the packets will come back from. So the decapsulating 6to4 router has no way to know if incoming packets are coming from a real relay or if it is spoofed trafic. - Alain. From owner-v6ops@ops.ietf.org Fri Sep 27 16:42:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10192 for ; Fri, 27 Sep 2002 16:42:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v1wb-000H5o-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 13:42:37 -0700 Received: from pheriche.sun.com ([192.18.98.34]) by psg.com with esmtp (Exim 3.36 #1) id 17v1wY-000H5d-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 13:42:34 -0700 Received: from esunmail ([129.147.58.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18594 for ; Fri, 27 Sep 2002 14:42:34 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H340097W6UYIV@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 27 Sep 2002 14:42:34 -0600 (MDT) Received: from sun.com ([129.146.85.69]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H34002RD6UX6P@mail.sun.net> for v6ops@ops.ietf.org; Fri, 27 Sep 2002 14:42:33 -0600 (MDT) Date: Fri, 27 Sep 2002 13:41:37 -0700 From: Alain Durand Subject: open 6to4 relay routers implementing RFC3068? To: v6ops@ops.ietf.org Message-id: <3D94C281.90606@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/20020719 Netscape/7.0 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT How many open 6to4 relay routers are implementing RFC3068? (the IPv4 anycast address) I've tried from 3 different places, 2 in the US and 1 in Europe, it seems that I always end up in Switzerland... - Alain. From owner-v6ops@ops.ietf.org Fri Sep 27 16:48:35 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10349 for ; Fri, 27 Sep 2002 16:48:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v241-000HL9-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 13:50:17 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17v23v-000HKL-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 13:50:11 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EE9D018EE for ; Fri, 27 Sep 2002 16:50:10 -0400 (EDT) Date: Fri, 27 Sep 2002 16:50:10 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <3D94BBDA.6070808@sun.com> References: <20020927165742.E66E718DA@thrintun.hactrn.net> <20020927182216.64BDA190F@thrintun.hactrn.net> <3D94BBDA.6070808@sun.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020927205010.EE9D018EE@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 13:13:14 -0700, Alain Durand wrote: > > IPv6 routing using 6to4 relays is asymetric, a 6to4 router may > choose which relay it send its traffic to for native v6, but has > absolutly no control where the packets will come back from. Correct. > So the decapsulating 6to4 router has no way to know if incoming > packets are coming from a real relay or if it is spoofed trafic. Correct. So what? If you're suggesting that if I knew who the "real relay" was I could trust it, I can only assume that you live in a much friendlier world than I do. If it comes from the outside world it's dangerous until proven otherwise. This isn't an IPv6-specific issue. From owner-v6ops@ops.ietf.org Fri Sep 27 17:02:23 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10688 for ; Fri, 27 Sep 2002 17:02:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v2FN-000HfT-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 14:02:01 -0700 Received: from [2001:670:86:3001::1] (helo=netcore.fi) by psg.com with esmtp (Exim 3.36 #1) id 17v2FK-000HfG-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 14:01:58 -0700 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g8RL1rP05165; Sat, 28 Sep 2002 00:01:53 +0300 Date: Sat, 28 Sep 2002 00:01:53 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: v6ops@ops.ietf.org Subject: Re: open 6to4 relay routers implementing RFC3068? In-Reply-To: <3D94C281.90606@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002, Alain Durand wrote: > How many open 6to4 relay routers are implementing RFC3068? > (the IPv4 anycast address) > > I've tried from 3 different places, 2 in the US and 1 in Europe, > it seems that I always end up in Switzerland... We (FUNET, AS1741) in Finland do, since about a year ago. We've received packets to 192.88.99.1 from the oddest of places (I've full logs and have done some analysis: like mit.edu and Japan etc etc.). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-v6ops@ops.ietf.org Fri Sep 27 17:31:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11091 for ; Fri, 27 Sep 2002 17:31:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v2jB-000IWY-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 14:32:49 -0700 Received: from attila.bofh.it ([213.92.8.2]) by psg.com with esmtp (Exim 3.36 #1) id 17v2j5-000IW9-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 14:32:44 -0700 Received: by attila.bofh.it (Postfix, from userid 10) id 9C8955F76E; Fri, 27 Sep 2002 23:32:42 +0200 (CEST) Received: by wonderland.linux.it (Postfix/Md, from userid 1001) id E58DC33B27; Fri, 27 Sep 2002 23:32:35 +0200 (CEST) Date: Fri, 27 Sep 2002 23:32:35 +0200 From: "Marco d'Itri" Cc: v6ops@ops.ietf.org Subject: Re: open 6to4 relay routers implementing RFC3068? Message-ID: <20020927213235.GA26938@wonderland.linux.it> References: <3D94C281.90606@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D94C281.90606@sun.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-2.4 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,MISSING_HEADERS version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sep 27, Alain Durand wrote: >How many open 6to4 relay routers are implementing RFC3068? >(the IPv4 anycast address) route-views.oregon-ix.net says: AS559 (SWITCH) AS1741 (FUNET) AS8379 (cybernet-ag.net) Most routes are from AS559. -- ciao, Marco From owner-v6ops@ops.ietf.org Fri Sep 27 19:36:10 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13331 for ; Fri, 27 Sep 2002 19:36:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v4dl-000LcJ-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 16:35:21 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17v4di-000Lc7-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 16:35:18 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 3CDD318DA for ; Fri, 27 Sep 2002 19:35:17 -0400 (EDT) Date: Fri, 27 Sep 2002 19:35:17 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: References: <20020927165742.E66E718DA@thrintun.hactrn.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020927233517.3CDD318DA@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 23:02:16 +0300 (EEST), Pekka Savola wrote: > > I think we just need a generic bidirectional tunnel through the NAT; > in addition to using some UDP port there should be some keepalives > and such of course. Plain and simple, always works, no problems at all. In general, I think this is a reasonable approach (assuming that the scenario work supports it, but I expect that it will). No doubt there will be cases in which it will not work (particularly restrictive NAT boxes or firewalls), but perhaps we can build consensus around the idea that in such cases PPP/TCP is ok? > Except it must be manually configured. Including some kind of authorization model, yeah. From owner-v6ops@ops.ietf.org Fri Sep 27 20:05:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13979 for ; Fri, 27 Sep 2002 20:05:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v57Q-000MV8-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 17:06:00 -0700 Received: from kathmandu.sun.com ([192.18.98.36]) by psg.com with esmtp (Exim 3.36 #1) id 17v57M-000MUv-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 17:05:57 -0700 Received: from esunmail ([129.147.58.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23655 for ; Fri, 27 Sep 2002 18:05:56 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H34003FNG9V7P@edgemail1.Central.Sun.COM> for v6ops@ops.ietf.org; Fri, 27 Sep 2002 18:05:56 -0600 (MDT) Received: from halibut.local. ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H3400EHVG9U69@mail.sun.net> for v6ops@ops.ietf.org; Fri, 27 Sep 2002 18:05:55 -0600 (MDT) Date: Fri, 27 Sep 2002 17:06:04 -0700 From: Alain Durand Subject: Re: IPv6 tunnel over NAT In-reply-to: <20020927205010.EE9D018EE@thrintun.hactrn.net> To: Rob Austein Cc: v6ops@ops.ietf.org Message-id: <1491504E-D276-11D6-97EA-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.543) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT On Friday, September 27, 2002, at 01:50 PM, Rob Austein wrote: > > Correct. So what? > > If you're suggesting that if I knew who the "real relay" was I could > trust it, I can only assume that you live in a much friendlier world > than I do. If it comes from the outside world it's dangerous until > proven otherwise. This isn't an IPv6-specific issue. I think we are in violent agreement here. This may not be a v6-specific issue, but this is a v6-operational/transition issue. Another way to say this, if open relay is the show stopper for teredo, it becomes automatically a 'serious embarrassment' for 6to4. - Alain. From owner-v6ops@ops.ietf.org Fri Sep 27 20:16:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14176 for ; Fri, 27 Sep 2002 20:16:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v5JG-000Mvi-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 17:18:14 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17v5J8-000Mv7-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 17:18:06 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8S0Gn029807; Fri, 27 Sep 2002 20:16:50 -0400 (EDT) Message-Id: <200209280016.g8S0Gn029807@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rob Austein cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-reply-to: (Your message of "Fri, 27 Sep 2002 15:05:53 EDT.") <20020927190553.30DFE18DA@thrintun.hactrn.net> Date: Fri, 27 Sep 2002 20:16:49 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > > well, obviously it depends on the applications being run and the > > quality of the underlying links. if you're running real time apps > > over UDP over PPP over TCP over a lossy IP link, you'd probably > > be much happier using Teredo. do we really want to say, for instance, > > that it's okay for the generic solution to break streaming audio? > > a) Begs the question of whether any of our transition tools are robust > enough to support serious real-time streaming use. 6to4 has a fixed overhead/delay per packet. Teredo and NATs probably do also. > b) PPP/TCP looks like a reliable link with very erratic timing > characteristics. I'm fairly certain that unidirectional streaming > protocols can deal with that via buffering (so that it's not real > time anymore). Whether the deployed implementations can or not is > another matter. PPP/TCP considerably amplifies the amount of jitter in the underlying network. In general, apps that are jitter sensitive will do worse with PPP/TCP (assuming any significant jitter or packet loss in the underlying network) than any per-packet tunneling or translation mechanism. Keith From owner-v6ops@ops.ietf.org Fri Sep 27 20:17:51 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14214 for ; Fri, 27 Sep 2002 20:17:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v5KW-000Mxs-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 17:19:32 -0700 Received: from astro.cs.utk.edu ([160.36.58.43]) by psg.com with esmtp (Exim 3.36 #1) id 17v5KO-000Mxh-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 17:19:24 -0700 Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8S0I8029822; Fri, 27 Sep 2002 20:18:08 -0400 (EDT) Message-Id: <200209280018.g8S0I8029822@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rob Austein cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-reply-to: (Your message of "Fri, 27 Sep 2002 15:17:15 EDT.") <20020927191716.0D37318DA@thrintun.hactrn.net> Date: Fri, 27 Sep 2002 20:18:08 -0400 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > In other words, we have divide-and-conquer techniques for dealing with > the problems that arise from excessively large link layer networks. > We're not using them at the moment because they'd require us to divide > the relevant portions of the IPv6 address space up into smaller > subnetworks and deploy routers, which would be unpleasant, but might > not be as unpleasant as living with various instantiations of the open > packet relay problem for the next decade. to what extent could BGP policy be used to accomplish divide-and-conquer for 6to4 relay routers? From owner-v6ops@ops.ietf.org Fri Sep 27 21:16:05 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15172 for ; Fri, 27 Sep 2002 21:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v6E9-000Ows-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 18:17:01 -0700 Received: from [3ffe:8114:1000::27] (helo=purgatory.unfix.org ident=postfix) by psg.com with esmtp (Exim 3.36 #1) id 17v6E5-000Owf-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 18:16:57 -0700 Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id B14657C16; Sat, 28 Sep 2002 03:16:51 +0200 (CEST) Received: from limbo (limbo.unfix.org [::ffff:10.100.13.33]) by purgatory.unfix.org (Postfix) with ESMTP id C3205795B; Sat, 28 Sep 2002 03:16:43 +0200 (CEST) From: "Jeroen Massar" To: "'Randy Bush'" , "'Atsushi Onoe'" Cc: , Subject: RE: tiny v6 operational issue Date: Sat, 28 Sep 2002 03:18:45 +0200 Organization: Unfix Message-ID: <003501c2668c$fd7b5c50$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org X-Razor-id: e689748b7bab90a5062f4c87c6f6b236efbb8264 X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,PORN_14 version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA15172 Randy Bush wrote: > >> i wonder if doc needs to be updated to check this. > > It should be documented here in v6ops since it is not a dns > problem but > > general problems among services. I.e. if you put AAAA > record to a node, > > all the services at the node should be served also via > IPv6. Otherwise, > > the FQDN should be splitted between the services which > served only via > > IPv4 and served via IPv6/IPv4. > > it is obvious to me that one must provide all services on all > addresses. given > > foo.bar. A 1.2.3.4 > A 5.6.7.8 > AAAA 2001:666:777::42 > > we do not currently require that all services provided on 1.2.3.4 > also be provided on 5.6.7.8. so how can we explain doing so for > 2001:666:777::42? "We" don't have too. IPv6 capable software _should_ use getaddrinfo() This call nicely returns a set of host/port combo's to connect to and the software should walk this list till it is able to fulfill it's job. Check out, the 4 year old doc: http://www.kame.net/newsletter/19980604/ And one can instruct getaddrinfo() to only return say AF_INET6 etc. Greets, Jeroen PS: Yeah yeah I know PuTTY doesn't fall back to IPv4 if the IPv6 connection fails, don't kick me now I am down, I admit, I admit :) From owner-v6ops@ops.ietf.org Fri Sep 27 21:45:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15860 for ; Fri, 27 Sep 2002 21:45:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v6gx-00003b-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 18:46:47 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17v6gu-00003Q-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 18:46:44 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 769A018DA for ; Fri, 27 Sep 2002 21:46:43 -0400 (EDT) Date: Fri, 27 Sep 2002 21:46:43 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <200209280018.g8S0I8029822@astro.cs.utk.edu> References: <20020927191716.0D37318DA@thrintun.hactrn.net> <200209280018.g8S0I8029822@astro.cs.utk.edu> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020928014643.769A018DA@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 20:18:08 -0400, Keith Moore wrote: > > to what extent could BGP policy be used to accomplish divide-and-conquer > for 6to4 relay routers? I'm pretty sure that it wouldn't solve the problem (I suspect you need actual routers to do that, not just routing policy), and from everything I hear BGP is already badly overloaded without taking on new duties, but I confess that the idea of trying to do this with BGP hadn't occurred to me, so I can't claim to have thought about it much. From owner-v6ops@ops.ietf.org Sat Sep 28 00:57:21 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19451 for ; Sat, 28 Sep 2002 00:57:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17v9fP-0006Xf-00 for v6ops-data@psg.com; Fri, 27 Sep 2002 21:57:23 -0700 Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with esmtp (Exim 3.36 #1) id 17v9fM-0006XU-00 for v6ops@ops.ietf.org; Fri, 27 Sep 2002 21:57:20 -0700 Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 839CC18DA for ; Sat, 28 Sep 2002 00:57:19 -0400 (EDT) Date: Sat, 28 Sep 2002 00:57:19 -0400 From: Rob Austein To: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT In-Reply-To: <1491504E-D276-11D6-97EA-00039376A6AA@sun.com> References: <20020927205010.EE9D018EE@thrintun.hactrn.net> <1491504E-D276-11D6-97EA-00039376A6AA@sun.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (Kashiharajingū-mae) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020928045719.839CC18DA@thrintun.hactrn.net> X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At Fri, 27 Sep 2002 17:06:04 -0700, Alain Durand wrote: > > I think we are in violent agreement here. Not sure. The point I was trying to make was that, while the defenses that a edge router has to deploy are annoying, they are a straightforward extrapolation of what we already do for IPv4, and are based in large part on topological information that happens to be one of the very few things that the 6to4 edge router -can- trust. In the common simple case, the router's interfaces partition into two disjoint sets: "my site" and "the rest of the world". Unless the router is badly configured or otherwise crippled, it knows which interfaces are are in which set, and can apply packet filtering rules as necessary when decapsulating to keep itself from being used as a DDoS reflector or as a circumvention tool to get around ingress filtering. The packet filtering rules are seriously ugly, but at the conceptual level this is a small matter of programming. The relay router, on the other hand, does not have any useful topological information on which to make such decisions (to a first approximation, everything a relay router sees is from "the rest of the world"). So it needs to have kind of additional mechanism for figuring out who's allowed to use it as a decapsulator. From owner-v6ops@ops.ietf.org Sat Sep 28 05:13:33 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01380 for ; Sat, 28 Sep 2002 05:13:32 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vDej-000EMA-00 for v6ops-data@psg.com; Sat, 28 Sep 2002 02:12:57 -0700 Received: from [2001:620:0:4:a00:20ff:fea2:f7f] (helo=babar.switch.ch) by psg.com with esmtp (Exim 3.36 #1) id 17vDeg-000ELz-00 for v6ops@ops.ietf.org; Sat, 28 Sep 2002 02:12:54 -0700 Received: from babar.switch.ch (localhost [IPv6:::1]) by babar.switch.ch (8.12.2+Sun/8.12.2) with ESMTP id g8S9CpNv007091; Sat, 28 Sep 2002 11:12:51 +0200 (MEST) Received: (from leinen@localhost) by babar.switch.ch (8.12.2+Sun/8.12.2/Submit) id g8S9CoeM007088; Sat, 28 Sep 2002 11:12:50 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: v6ops@ops.ietf.org Subject: Re: open 6to4 relay routers implementing RFC3068? References: <3D94C281.90606@sun.com> <20020927213235.GA26938@wonderland.linux.it> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <20020927213235.GA26938@wonderland.linux.it> Date: 28 Sep 2002 11:12:50 +0200 Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_AUTH_WARNING,SUBJ_ENDS_IN_Q_MARK version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 27 Sep 2002 23:32:35 +0200, Marco d'Itri said: > On Sep 27, Alain Durand wrote: >> How many open 6to4 relay routers are implementing RFC3068? >> (the IPv4 anycast address) > route-views.oregon-ix.net says: > AS559 (SWITCH) > AS1741 (FUNET) > AS8379 (cybernet-ag.net) > Most routes are from AS559. Hm, how flattering. Maybe we should start prepending AS559 to some of our peers. Anyway, the geographical/topological distribution of RFC3068 relays (Finland, Germany and Switzerland) is certainly somewhat lacking for non-European users. So if you're outside Europe, please consider setting up a public RFC3068 6to4 relay. It's really not that difficult, provided that you have some control over your external IPv4 route announcements. I also don't think you'll see that much traffic - here's the MRTG page for our relay, which seems to be widely used: http://www.switch.ch/lan/stat/6bone/swi6t1-tunnel2.html (Although the load could certainly go up in the future if some worm enables IPv6 on gazillions of XP installations 8-) Especially if you have security/liability concerns about relays 6to4 are insecure, you should consider setting one up so that we get some empirical data. -- Simon. From owner-v6ops@ops.ietf.org Sat Sep 28 08:12:28 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03991 for ; Sat, 28 Sep 2002 08:12:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vGSU-000Ih4-00 for v6ops-data@psg.com; Sat, 28 Sep 2002 05:12:30 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 17vGSO-000Igo-00 for v6ops@ops.ietf.org; Sat, 28 Sep 2002 05:12:24 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17vGSO-00085o-00; Sat, 28 Sep 2002 05:12:24 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Rob Austein Cc: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT References: <20020927205010.EE9D018EE@thrintun.hactrn.net> <1491504E-D276-11D6-97EA-00039376A6AA@sun.com> <20020928045719.839CC18DA@thrintun.hactrn.net> Message-Id: Date: Sat, 28 Sep 2002 05:12:24 -0700 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The point I was trying to make was that, while the defenses that a > edge router has to deploy are annoying, they are a straightforward > extrapolation of what we already do for IPv4, and are based in large > part on topological information that happens to be one of the very few > things that the 6to4 edge router -can- trust. In the common simple > case, the router's interfaces partition into two disjoint sets: "my > site" and "the rest of the world". Unless the router is badly > configured or otherwise crippled, it knows which interfaces are are in > which set, and can apply packet filtering rules as necessary when > decapsulating to keep itself from being used as a DDoS reflector or as > a circumvention tool to get around ingress filtering. The packet > filtering rules are seriously ugly, but at the conceptual level this > is a small matter of programming. > > The relay router, on the other hand, does not have any useful > topological information on which to make such decisions (to a first > approximation, everything a relay router sees is from "the rest of the > world"). So it needs to have kind of additional mechanism for > figuring out who's allowed to use it as a decapsulator. bingo! and relays out in the net would have serious problems of scaling in security associations, where site gateways have little if any. randy From owner-v6ops@ops.ietf.org Sat Sep 28 10:37:22 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05867 for ; Sat, 28 Sep 2002 10:37:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vIix-000Lx1-00 for v6ops-data@psg.com; Sat, 28 Sep 2002 07:37:39 -0700 Received: from ncsmtp03.ogw.rr.com ([24.93.67.84]) by psg.com with esmtp (Exim 3.36 #1) id 17vIiu-000Lwq-00 for v6ops@ops.ietf.org; Sat, 28 Sep 2002 07:37:36 -0700 Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ncsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g8SEbQiZ017087; Sat, 28 Sep 2002 10:37:27 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Sat, 28 Sep 2002 10:37:33 -0400 Message-ID: <3D95BF3F.3040102@nc.rr.com> Date: Sat, 28 Sep 2002 10:39:59 -0400 From: Brian Haberman Organization: Caspian Networks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rob Austein CC: v6ops@ops.ietf.org Subject: Re: IPv6 tunnel over NAT References: <20020927191716.0D37318DA@thrintun.hactrn.net> <200209280018.g8S0I8029822@astro.cs.utk.edu> <20020928014643.769A018DA@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=2.1 required=5.0 tests=DOUBLE_CAPSWORD,RCVD_IN_MULTIHOP_DSBL, X_RCVD_IN_UNCONFIRMED_DSBL,FUDGE_MULTIHOP_RELAY version=2.31 X-Spam-Level: ** Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob Austein wrote: > At Fri, 27 Sep 2002 20:18:08 -0400, Keith Moore wrote: > >>to what extent could BGP policy be used to accomplish divide-and-conquer >>for 6to4 relay routers? > > > I'm pretty sure that it wouldn't solve the problem (I suspect you need > actual routers to do that, not just routing policy), and from > everything I hear BGP is already badly overloaded without taking on > new duties, but I confess that the idea of trying to do this with BGP > hadn't occurred to me, so I can't claim to have thought about it much. > > I work with a group of BGP developers who are very concerned with the amount of work that has been piled on BGP. I doubt that we should rely on BGP to enforce a whole bunch of new policy for 6to4. Brian From owner-v6ops@ops.ietf.org Sun Sep 29 06:16:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00179 for ; Sun, 29 Sep 2002 06:16:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vb4y-0007Rb-00 for v6ops-data@psg.com; Sun, 29 Sep 2002 03:13:36 -0700 Received: from mailhost1-chcgil.chcgil.ameritech.net ([206.141.192.67] helo=mailhost.chi1.ameritech.net) by psg.com with esmtp (Exim 3.36 #1) id 17vb4t-0007Qv-00 for v6ops@ops.ietf.org; Sun, 29 Sep 2002 03:13:31 -0700 Received: from repligate ([67.36.190.215]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020929101331.FGVQ1118.mailhost.chi1.ameritech.net@repligate> for ; Sun, 29 Sep 2002 05:13:31 -0500 Message-ID: <011901c267a0$da7600b0$d7be2443@repligate> From: "Jim Fleming" To: References: <20020927191716.0D37318DA@thrintun.hactrn.net><200209280018.g8S0I8029822@astro.cs.utk.edu> <20020928014643.769A018DA@thrintun.hactrn.net> Subject: Note, BGP goes away once the 32-bit "core" transport is secured. Date: Sun, 29 Sep 2002 05:13:27 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Rob Austein" To: Sent: Friday, September 27, 2002 8:46 PM Subject: Re: IPv6 tunnel over NAT > At Fri, 27 Sep 2002 20:18:08 -0400, Keith Moore wrote: > > > > to what extent could BGP policy be used to accomplish divide-and-conquer > > for 6to4 relay routers? > > I'm pretty sure that it wouldn't solve the problem (I suspect you need > actual routers to do that, not just routing policy), and from > everything I hear BGP is already badly overloaded without taking on > new duties, but I confess that the idea of trying to do this with BGP > hadn't occurred to me, so I can't claim to have thought about it much. > Note, BGP goes away once the 32-bit "core" transport is secured. Announcements become a thing of the past. Whitehouse Ready to Release Next Generation Internet Plan http://news.com.com/2100-1023-958159.html?tag=politech http://www.politechbot.com/p-03994.html http://www.uscryptomail.org/cybersecurity/ Note: The new plan calls for the same architecture used with IPv8 and IPv16, whereby, users do not have direct access to the (out-of-band) IPv16 network. Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au http://ipv8.ods.org From owner-v6ops@ops.ietf.org Sun Sep 29 08:14:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01294 for ; Sun, 29 Sep 2002 08:14:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vcxv-000Afp-00 for v6ops-data@psg.com; Sun, 29 Sep 2002 05:14:27 -0700 Received: from mailhost1-chcgil.chcgil.ameritech.net ([206.141.192.67] helo=mailhost.chi1.ameritech.net) by psg.com with esmtp (Exim 3.36 #1) id 17vcxs-000Afc-00 for v6ops@ops.ietf.org; Sun, 29 Sep 2002 05:14:24 -0700 Received: from repligate ([67.36.190.215]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020929121423.HJEQ1118.mailhost.chi1.ameritech.net@repligate> for ; Sun, 29 Sep 2002 07:14:23 -0500 Message-ID: <015301c267b1$bdafe9d0$d7be2443@repligate> From: "Jim Fleming" To: References: <20020927191716.0D37318DA@thrintun.hactrn.net><200209280018.g8S0I8029822@astro.cs.utk.edu> <20020928014643.769A018DA@thrintun.hactrn.net> <011901c267a0$da7600b0$d7be2443@repligate> Subject: Correction...43-bit...Re: Note, BGP goes away once the 32-bit "core" transport is secured. Date: Sun, 29 Sep 2002 07:14:19 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jim Fleming" > > Note, BGP goes away once the 32-bit "core" transport is secured. > Announcements become a thing of the past. > Correction....the "43-bit *core* transport".... although, one could argue the SNOOPY bit is a 1/2 bit but people seem confused with 43.5 bits... 128-bit DNS AAAA Record Flag Day Formats 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Jim Fleming 3:219...IN-ADDR.INFO From owner-v6ops@ops.ietf.org Sun Sep 29 20:55:31 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11498 for ; Sun, 29 Sep 2002 20:55:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vopA-00074a-00 for v6ops-data@psg.com; Sun, 29 Sep 2002 17:54:12 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17vop3-00074N-00 for v6ops@ops.ietf.org; Sun, 29 Sep 2002 17:54:05 -0700 Received: from kenawang.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA10521; Sun, 29 Sep 2002 17:53:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20020929200942.024a0970@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 29 Sep 2002 20:55:09 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "'itojun@iijlab.net'" , v6ops@ops.ietf.org In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A4C@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Hesham, >=> I think we're drifting from the main issue >a little bit. Here is a scenario that I'd like >to understand how it would work: >What do we recommend a new small 3g operator who only >has 10 million subscribers (just a small town >in china!) and wants to allow people to run p2p apps: > >a. Run a dual network with 1918 addresses >b. Just run an IPv6 network > >If people want to do a), do you really think >this would be simpler than b) ? Easier to manage >and operate? I've been thinking about this question and trying to come up with a good answer... I'm actually thinking of this question a bit differently, so please tell me if it matches what you are asking: What is the best way to set-up a network of 10 million nodes that all to need access both IPv6-only and IPv4-only services? There are two thoughts that I have about this question: (1) It isn't a fully qualified question. Further information is needed to for a complete answer, such as: - Do these nodes need continuous access to IPv4 and IPv6 services, or only occasional access? - How many simultaneous IPv4 & IPv6 connections are expected? - What is the planned internal structure of the network? Obviously you aren't planning to bridge 10 million nodes on a single subnet. (2) Neither IPv4 nor NAT-PT will handle a 10 million node network as a single address space. The limitation of 32-bit addressing in IPv4 is a red herring, since the real limitations on the size of a NAT based network is probably much lower (a few hundred thousand simultaneous connection?). But, given that you've said this is a 3GPP network, I can make some (perhaps flawed) assumptions about how this network will be structured: (1) There will be internal routers (GGSNs) at a density of one per ~100,000-500,000 nodes. (2) All nodes will have point-to-point connections to a single router (PDP Contexts to the GGSN). (3) The nodes will only need occasional access to IPv4 & IPv6 services. (4) IPv4 address configuration (and IPv6 address configuration) of the nodes will be performed on an as-needed basis via the establishment of PDP contexts. In this case, I would suggest that any address translation (IPv4 or IPv6) be performed on a per-GGSN basis, with the NAT either co-resident in the GGSN or sitting directly behind it (between the GGSN and the rest of the Internet). So, really we are comparing two things: (A) The complexity, effort and effectiveness of configuring the GGSNs as IPv6-only routers and running a NAT-PT box per GGSN to translate selected IPv6 traffic into IPv4 traffic. This would allow the end-nodes to be IPv6-only, but would require them to have some special DNS resolution/literal IPv4 address handling mechanisms. (B) The complexity, effort and effectiveness of configuring the GGSNs as IPv4/IPv6 routers, running an IPv4 NAT box per GGSN, and having the GGSNs allocate RFC 1918 addresses on PDP contexts. This would require any nodes that need to reach IPv4-only services to include IPv4 and any nodes that need to reach IPv6-only services to include IPv6 (nodes that need to reach both would need to be dual stack). There are a few key differences between these choices: Choice A has the advantage that it only requires a single stack on the end-nodes, which may save a little bit of memory... However, IPv4 and IPv6 stacks share a large portion of their code, so this will be a small savings. Choice A only supports IPv6-only end-nodes. It won't be possible to set-up an IPv4 PDP context, and two nodes that are behind the same GGSN will not be able to establish an IPv4 connection to each other. Is that okay? Choice A may also have some new (i.e. not present in the IPv4 network today) architectural issues running IPv4 applications caused by: - The DNS resolver/IP address interpretation machinations on the local box. - The availability of IPv4<->IPv6 ALGs for whatever applications the host is using. Choice B will support IPv4-only, IPv4/IPv6 dual stack and IPv6-only nodes, will allow nodes to use IPv6 and IPv4 PDP contexts, and will support IPv4 connections between nodes attached to the same GGSN. Are any of these things needed? Choice B will also have the best chance of supporting all IPv4-only services that work in a NAT-based network today. I agree that Choice B may be marginally more complex to set-up and maintain than Choice A... So, there is a pretty complex trade-off here, but if I had to choose for my own network, I'd probably go with the dual-stack parallel IPv4/IPv6 network approach. I wish that I really understood the DSTM/DHCP choice well enough to explain how it could/couldn't fit into this situation... I'm working up to that now. Margaret From owner-v6ops@ops.ietf.org Mon Sep 30 03:05:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25459 for ; Mon, 30 Sep 2002 03:05:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vubO-000GlK-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 00:04:22 -0700 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by psg.com with esmtp (Exim 3.36 #1) id 17vubK-000Gl3-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 00:04:18 -0700 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8U74nM29810 for ; Mon, 30 Sep 2002 02:04:49 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 30 Sep 2002 02:04:16 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 30 Sep 2002 02:03:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Mon, 30 Sep 2002 00:03:24 -0700 Message-ID: <4D7B558499107545BB45044C63822DDE01991D82@mvebe001.americas.nokia.com> Thread-Topic: ocean: do not boil Thread-Index: AcJoHUNQlPGeHb4XSiOv/bXMByRRfgAMcBOA From: To: , Cc: , X-OriginalArrivalTime: 30 Sep 2002 07:03:26.0025 (UTC) FILETIME=[78EC4390:01C2684F] X-Spam-Status: No, hits=1.6 required=5.0 tests=NO_REAL_NAME,DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA25459 Margaret, That's a pretty summary. Thanks. Speaking only for myself, not Nokia, I'm of the opinion that DSTM doesn't add anything to the 3GPP equation. It's logically equivalent to having an IPv6 PDP context always up, and bringing up a v4 PDP context on demand. The v4 address you get when you bring up that PDP context may in fact be allocated via DHCP, of course. --Rod -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@windriver.com] Sent: Sunday, September 29, 2002 5:55 PM To: Hesham Soliman (EAB) Cc: 'itojun@iijlab.net'; v6ops@ops.ietf.org Subject: RE: ocean: do not boil I wish that I really understood the DSTM/DHCP choice well enough to explain how it could/couldn't fit into this situation... I'm working up to that now. Margaret From owner-v6ops@ops.ietf.org Mon Sep 30 05:29:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27304 for ; Mon, 30 Sep 2002 05:29:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vwsc-000IuZ-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 02:30:18 -0700 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by psg.com with esmtp (Exim 3.36 #1) id 17vwsY-000IuM-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 02:30:15 -0700 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8U9UCOX010781; Mon, 30 Sep 2002 11:30:12 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 30 Sep 2002 11:30:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0A94@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Margaret Wasserman'" , "Hesham Soliman (EAB)" Cc: "'itojun@iijlab.net'" , v6ops@ops.ietf.org Subject: RE: ocean: do not boil Date: Mon, 30 Sep 2002 11:30:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Margaret, Excellent start to the discussion, thanks. > I've been thinking about this question and trying to > come up with a good answer... > > I'm actually thinking of this question a bit differently, > so please tell me if it matches what you are asking: > > What is the best way to set-up a network of 10 million > nodes that all to need access both IPv6-only and IPv4-only > services? > > There are two thoughts that I have about this question: => Good questions, I suggest we focus on those first then look at the different solutions. > > (1) It isn't a fully qualified question. > Further information is needed to > for a complete answer, such as: > > - Do these nodes need continuous access > to IPv4 and IPv6 services, or only > occasional access? => I believe continuous access is needed. a PDP context will be up when the device is turned on and remain up pretty much the whole time. Some operators will configure things differently (e.g. if idle for x hours remove PDP context), but I believe people want to be "always on and connected" (not meant to be a mrketing stunt!). This is simply because once you lose your PDP context you're not reachable. > - How many simultaneous IPv4 & IPv6 > connections are expected? => Depends on the user, this is orthogonal to the PDP context(s). > - What is the planned internal structure > of the network? Obviously you aren't > planning to bridge 10 million nodes > on a single subnet. => No. > > (2) Neither IPv4 nor NAT-PT will handle a 10 million > node network as a single address space. => NAT-PT can handle them in a single address space. Of course not in a single box. > The limitation of 32-bit addressing in IPv4 > is a red herring, since the real limitations > on the size of a NAT based network is probably > much lower (a few hundred thousand simultaneous > connection?). => It's a 24-bit address space :) > > But, given that you've said this is a 3GPP network, I can > make some (perhaps flawed) assumptions about how this network > will be structured: > > (1) There will be internal routers (GGSNs) at a > density of one per ~100,000-500,000 nodes. => Correct. > (2) All nodes will have point-to-point connections > to a single router (PDP Contexts to the GGSN). => correct. > (3) The nodes will only need occasional access to > IPv4 & IPv6 services. => I think continuous accessibility is required. We don't want to tear down PDP contexts and start them again too often. > (4) IPv4 address configuration (and IPv6 address > configuration) of the nodes will > be performed on an as-needed basis > via the establishment of PDP contexts. => No, see above. I will wait with the replies for the second part of your email until we agree on the assumptions/scenario first. I think this is very important and a great start for detailed scenarios. Hesham From owner-v6ops@ops.ietf.org Mon Sep 30 06:56:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28231 for ; Mon, 30 Sep 2002 06:56:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17vyER-000KEh-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 03:56:55 -0700 Received: from mailhost1-chcgil.chcgil.ameritech.net ([206.141.192.67] helo=mailhost.chi1.ameritech.net) by psg.com with esmtp (Exim 3.36 #1) id 17vyEN-000KEW-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 03:56:51 -0700 Received: from repligate ([67.36.190.215]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020930105650.YJFY1118.mailhost.chi1.ameritech.net@repligate>; Mon, 30 Sep 2002 05:56:50 -0500 Message-ID: <04b201c26870$16f906c0$d7be2443@repligate> From: "Jim Fleming" To: "Hesham Soliman \(EAB\)" , "'Margaret Wasserman'" Cc: , References: <4DA6EA82906FD511BE2F00508BCF0538044F0A94@Esealnt861.al.sw.ericsson.se> Subject: "always on and connected" Date: Mon, 30 Sep 2002 05:56:54 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Hesham Soliman (EAB)" > > => I believe continuous access is needed. a PDP > context will be up when the device is turned > on and remain up pretty much the whole time. > Some operators will configure things differently > (e.g. if idle for x hours remove PDP context), but > I believe people want to be "always on and connected" > (not meant to be a mrketing stunt!). This is simply > because once you lose your PDP context you're not > reachable. > The DNS can help keep things connected...at least the modern DNS can... http://www.directupdate.net/ Top 10...IPv8 Compatible Dynamic DNS Services Vote Early and Often... http://www.kvtek.com/ddnsservices.asp Other links... DynDNS www.dyndns.org Yi www.yi.org DtDNS www.dtdns.com HammerNode www.hn.org EyeP www.eyep.net DynU www.dynu.com easyDNS www.easydns.com No-IP www.no-ip.com dyns.cx www.dyns.cx dnsQ.org www.dnsq.org myIP.org www.myip.org ns1.net www.ns1.net ZoneEdit www.zoneedit.com dyn.ee www.dyn.ee www.centralinfo.net NOLS www.nols.com dhs.org www.dhs.org YYweb.com www.yyweb.com dyn.ca www.dyn.ca DDNS.nu www.ddns.nu miniDNS www.minidns.net DynDNS.dk www.dyndns.dk changeIP www.changeip.com dnsArt www.dnsart.com DSL Reports www.dslreports.com GetmyIP.com www.getmyip.com http://www.cafax.se/cgi-bin/where.pl C@t From owner-v6ops@ops.ietf.org Mon Sep 30 10:22:58 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05516 for ; Mon, 30 Sep 2002 10:22:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17w1Rm-000OV3-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 07:22:54 -0700 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 17w1Rh-000OUV-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 07:22:49 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8110AA97; Mon, 30 Sep 2002 10:22:48 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 30 Sep 2002 10:22:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Mon, 30 Sep 2002 10:22:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B5C4@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJoHH/YP9mWR2aTRGy6aHRVw4QNcgAbm0zg From: "Bound, Jim" To: "Margaret Wasserman" , "Hesham Soliman (EAB)" Cc: , X-OriginalArrivalTime: 30 Sep 2002 14:22:48.0326 (UTC) FILETIME=[DA142A60:01C2688C] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05516 Hi Margaret, The DHCP DSTM choice would work as follows: It would assume your choice B below. At the GGSN it would be able to forward IPv4 packets that were encapsulated in IPv6, when the handheld wanted to speak to IPv4 apps. But we need to discuss 1918 address and global IPv4 address space. If 1918 then I would argue the only use for DSTM is behind the GGSN to the UE device (e.g. local 3G provider services) or if the services from the GGSN were within a private 1918 network then the IPv4 packets could be used to get to those services using 1918 addresses. But DSTM could also provide global Ipv4 addresses if as one of your questions/assumptions was that IPv4 is needed for only temporary or limited use of network services. At the UE or handheld lets assume it mostly speaks IPv6 for IM in 3G. When it needs v4 address the dhcpv6 client or a more light weight mechanisms requests a DSTM address (private or global) to speak IPv4. The IPv4 address then is encaped to the GGSN DSTM Edge Router and then forwarded.. The GGSN DSTM router would have to send the IPv4 back thru the IPv6 core network would have to have a mapping of how to get back to the v6 UE/handheld via encaping v4 in v6. This is only useful when IPv4 is being used as limited for services or special apps that have not been ported. DSTM assumes strongly that v6 is the dominant deployment strategy. Once that happens all the e2e pain can be avoided that one gets with NAT and e2e security/vpns are possible with IPv6. Now dhcpv4 could be used but that means the handheld is running IPv4 dhcp client. That means its running a dual stack for services. DSTM does not require this and why we put DSTM options in dhcpv6 for the case where the client only wants to run IPv6 and IPv4 as special operation. The overall DSTM architecture is to avoid NAT completely where it might be used by IPv6 nodes. DSTM does assume that nodes are dual stacked though. regards, /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Sunday, September 29, 2002 8:55 PM > To: Hesham Soliman (EAB) > Cc: 'itojun@iijlab.net'; v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > > Hi Hesham, > > >=> I think we're drifting from the main issue > >a little bit. Here is a scenario that I'd like > >to understand how it would work: > >What do we recommend a new small 3g operator who only > >has 10 million subscribers (just a small town > >in china!) and wants to allow people to run p2p apps: > > > >a. Run a dual network with 1918 addresses > >b. Just run an IPv6 network > > > >If people want to do a), do you really think > >this would be simpler than b) ? Easier to manage > >and operate? > > I've been thinking about this question and trying to > come up with a good answer... > > I'm actually thinking of this question a bit differently, > so please tell me if it matches what you are asking: > > What is the best way to set-up a network of 10 million > nodes that all to need access both IPv6-only and IPv4-only > services? > > There are two thoughts that I have about this question: > > (1) It isn't a fully qualified question. > Further information is needed to > for a complete answer, such as: > > - Do these nodes need continuous access > to IPv4 and IPv6 services, or only > occasional access? > - How many simultaneous IPv4 & IPv6 > connections are expected? > - What is the planned internal structure > of the network? Obviously you aren't > planning to bridge 10 million nodes > on a single subnet. > > (2) Neither IPv4 nor NAT-PT will handle a 10 million > node network as a single address space. > The limitation of 32-bit addressing in IPv4 > is a red herring, since the real limitations > on the size of a NAT based network is probably > much lower (a few hundred thousand simultaneous > connection?). > > But, given that you've said this is a 3GPP network, I can > make some (perhaps flawed) assumptions about how this network > will be structured: > > (1) There will be internal routers (GGSNs) at a > density of one per ~100,000-500,000 nodes. > (2) All nodes will have point-to-point connections > to a single router (PDP Contexts to the GGSN). > (3) The nodes will only need occasional access to > IPv4 & IPv6 services. > (4) IPv4 address configuration (and IPv6 address > configuration) of the nodes will > be performed on an as-needed basis > via the establishment of PDP contexts. > > In this case, I would suggest that any address translation > (IPv4 or IPv6) be performed on a per-GGSN basis, with the > NAT either co-resident in the GGSN or sitting directly > behind it (between the GGSN and the rest of the Internet). > > So, really we are comparing two things: > > (A) The complexity, effort and effectiveness of > configuring the GGSNs as IPv6-only routers > and running a NAT-PT box per GGSN to > translate selected IPv6 traffic into > IPv4 traffic. This would allow the end-nodes > to be IPv6-only, but would require them to > have some special DNS resolution/literal > IPv4 address handling mechanisms. > > (B) The complexity, effort and effectiveness of > configuring the GGSNs as IPv4/IPv6 routers, > running an IPv4 NAT box per GGSN, and > having the GGSNs allocate RFC 1918 > addresses on PDP contexts. This would > require any nodes that need to reach > IPv4-only services to include IPv4 and > any nodes that need to reach IPv6-only > services to include IPv6 (nodes that need > to reach both would need to be dual stack). > > There are a few key differences between these choices: > > Choice A has the advantage that it only requires a > single stack on the end-nodes, which may save a little > bit of memory... However, IPv4 and IPv6 stacks share a > large portion of their code, so this will be a small > savings. > > Choice A only supports IPv6-only end-nodes. It won't > be possible to set-up an IPv4 PDP context, and two nodes > that are behind the same GGSN will not be able to > establish an IPv4 connection to each other. Is that > okay? > > Choice A may also have some new (i.e. not present in > the IPv4 network today) architectural issues running > IPv4 applications caused by: > > - The DNS resolver/IP address interpretation > machinations on the local box. > - The availability of IPv4<->IPv6 ALGs for > whatever applications the host is > using. > > Choice B will support IPv4-only, IPv4/IPv6 dual stack > and IPv6-only nodes, will allow nodes to use IPv6 and > IPv4 PDP contexts, and will support IPv4 connections > between nodes attached to the same GGSN. Are any of > these things needed? > > Choice B will also have the best chance of supporting > all IPv4-only services that work in a NAT-based network > today. > > I agree that Choice B may be marginally more complex > to set-up and maintain than Choice A... > > So, there is a pretty complex trade-off here, but if > I had to choose for my own network, I'd probably go > with the dual-stack parallel IPv4/IPv6 network approach. > > I wish that I really understood the DSTM/DHCP choice > well enough to explain how it could/couldn't fit into > this situation... I'm working up to that now. > > Margaret > > > > > > > > > > From owner-v6ops@ops.ietf.org Mon Sep 30 10:33:24 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05911 for ; Mon, 30 Sep 2002 10:33:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17w1cw-000OpQ-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 07:34:26 -0700 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #1) id 17w1cs-000Oov-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 07:34:22 -0700 Received: from kenawang.windriver.com ([147.11.233.9]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA01036; Mon, 30 Sep 2002 07:33:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20020930101714.02a432f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Sep 2002 10:32:41 -0400 To: "Hesham Soliman (EAB)" From: Margaret Wasserman Subject: RE: ocean: do not boil Cc: "Hesham Soliman (EAB)" , "'itojun@iijlab.net'" , v6ops@ops.ietf.org In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0A94@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi Hesham, >=> I believe continuous access is needed. a PDP >context will be up when the device is turned >on and remain up pretty much the whole time. >Some operators will configure things differently >(e.g. if idle for x hours remove PDP context), but >I believe people want to be "always on and connected" >(not meant to be a mrketing stunt!). This is simply >because once you lose your PDP context you're not >reachable. "Reachable" in what sense? I can see this argument for the IPv6 PDP Context, since you might run a peer-to-peer service over IPv6 for messaging, or whatever... But, what advantage is there to having an IPv4 PDP Context up all of the time? If you are behind any type of NAT (IPv4 NAT or NAT-PT), you won't be reachable from the outside, anyway. > > - How many simultaneous IPv4 & IPv6 > > connections are expected? > >=> Depends on the user, this is orthogonal to the >PDP context(s). Right, but this is key to the scaling issues for any NAT solution. The "10 million" nodes (or 100,000-500,000 nodes) number is much less interesting, from a NAT scaling perspective, then the number of simultaneous communication sessions for which the NAT box will need to maintain state. >=> NAT-PT can handle them in a single address space. Of course >not in a single box. Okay, I agree. My use of the term "address space" was not correct. I probably should have said "address pool" or "address range". We're in agreement, though, that a single NAT box won't be able to handle 10 million nodes. Given that fact, I'm not sure that it matters whether the end-hosts behind the NATs are numbered in different ranges of the same address space (as they could be with NAT-PT), or in private address spaces (as with IPv4 NAT). Both address spaces would be private from the point of view of the IPv4 Internet, requiring translation into globally routable IPv4 addresses. > > > > (1) There will be internal routers (GGSNs) at a > > density of one per ~100,000-500,000 nodes. > >=> Correct. Okay, now we're talking! This starts to bring the problem into a range that I understand how to solve... > > (3) The nodes will only need occasional access to > > IPv4 & IPv6 services. > >=> I think continuous accessibility is required. >We don't want to tear down PDP contexts and start >them again too often. Do you know how potential 3GPP operators think about this? I have heard different things from different equipment manufacturers... However, I'll accept that we want a solution that can handle always-on IPv4 and IPv6 access to every end-node, even if that isn't how all of the networks are deployed. Are you willing to accept that it would probably make sense, in the 3GPP topology to position the NATs (or either type) in or just behind the GGSNs, rather than having a single (set of) NAT box(es) between the full 10 million node network and the rest of the Internet? Margaret From owner-v6ops@ops.ietf.org Mon Sep 30 10:39:08 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06149 for ; Mon, 30 Sep 2002 10:39:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17w1ia-000P0X-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 07:40:16 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17w1iW-000P0K-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 07:40:13 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BEE332F51; Mon, 30 Sep 2002 10:40:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 30 Sep 2002 10:40:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Mon, 30 Sep 2002 10:40:07 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93FB@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJoHUNQlPGeHb4XSiOv/bXMByRRfgAMcBOAAA+fedA= From: "Bound, Jim" To: , , Cc: , X-OriginalArrivalTime: 30 Sep 2002 14:40:10.0288 (UTC) FILETIME=[4722F300:01C2688F] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA06149 Rod, > -----Original Message----- > From: Rod.VanMeter@nokia.com [mailto:Rod.VanMeter@nokia.com] > Sent: Monday, September 30, 2002 3:03 AM > To: mrw@windriver.com; hesham.soliman@era.ericsson.se > Cc: itojun@iijlab.net; v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > Margaret, > > That's a pretty summary. Thanks. > > Speaking only for myself, not Nokia, I'm of the > opinion that DSTM doesn't add anything to the 3GPP > equation. It's logically equivalent to having > an IPv6 PDP context always up, and bringing up > a v4 PDP context on demand. If one wants security to work e2e for handheld NAT must be avoided. If there are only X Ipv4 global address space by a provider then the provider must manage their usage. If the provider service is dominant IPv6 usage then the only reason to use Ipv4 are for services that have not been migrated to IPv6. This is where DSTM brings its value. It permits a network operator to: 1: conserve and manage its precious IPv4 global address space 2: control the use of IPv4 global address space per usage/service 3: identify a migration of services and apps that must move to IPv6 4: avoid the use of any NAT paradigm at the GGSN 5. Use e2e security (e.g. IPsec) inherent on the handheld. 6. Use IPv6 as the dominant routing protocol. The above cannot be done with NAT-PT. In addition DSTM as a solution can be used only when needed and does not require the routing complexity (except coming back into the GGSN) that 6to4 does. But a variation of DSTM is also proposed that will use 6to4 if it is part of the DSTM. DSTM not only is useful for 3G but 802.11 LANs, LMMs, and WANs which I see being deployed much faster and in fact currently and I see NO 3G deployment at this time. So I am testing this with 802.11 as a note and with handheld devices. > > The v4 address you get when you bring up that > PDP context may in fact be allocated via DHCP, of > course. See my note to Margaret we also defined this so dhcpv6 can be used so no dhcpv4 client must be running on the handheld to support the assumption that the goal is to reduce the reliance on IPv4 anything in the network or by the node. Of course 3G has really only done Ipv6 for the IM subsystem and still does not even use MIPv6. So until 3G evolves further with IPv6 it is potential that 3G users cannot live with the DSTM assumptions that the network is dominant IPv6 network which is not the case for 3G current releases. But for 802.11 this can be the case and actually to me more important than 3G as it is installing as I speak to you with IPv6. regards, /'jim From owner-v6ops@ops.ietf.org Mon Sep 30 12:02:25 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09682 for ; Mon, 30 Sep 2002 12:02:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17w30r-0001Tz-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 09:03:13 -0700 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17w30n-0001Tn-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 09:03:10 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 30 Sep 2002 09:03:01 -0700 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , , , Cc: , Subject: RE: ocean: do not boil Date: Mon, 30 Sep 2002 09:02:52 -0700 Message-ID: <031c01c2689a$d59eed90$011aa8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93FB@tayexc13.americas.cpqcorp.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,DOUBLE_CAPSWORD version=2.31 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim Bound wrote: > ... > If the provider service is dominant IPv6 usage then the only > reason to use Ipv4 are for services that have not been > migrated to IPv6. This is where DSTM brings its value. > > It permits a network operator to: > > 1: conserve and manage its precious IPv4 global address space > 2: control the use of IPv4 global address space per usage/service > 3: identify a migration of services and apps that must move to IPv6 > 4: avoid the use of any NAT paradigm at the GGSN > 5. Use e2e security (e.g. IPsec) inherent on the handheld. > 6. Use IPv6 as the dominant routing protocol. > > The above cannot be done with NAT-PT. In addition > DSTM as a solution can be used only when needed and > does not require the routing complexity (except coming back > into the GGSN) that 6to4 does. But a variation of DSTM is > also proposed that will use 6to4 if it is part of the DSTM. > > DSTM not only is useful for 3G but 802.11 LANs, LMMs, > and WANs which I see being deployed much faster and > in fact currently and I see NO 3G deployment at this time. > So I am testing this with 802.11 as a note and with handheld > devices. > Rod was correct, in the sense that for a basic 3G network a demand IPv4 PDP context provides the same functionality that DSTM provides to a routed IPv6 network. The point I think you are trying to make is that DSTM also works in wireless hot-spot networks, and for an operator that is interested in a unified mechanism for handsets that roam between the 802.11 & 3G radios, DSTM may be the best approach. If they really are locked into the point-to-point association between the GGSN & the handset, they could use L2TP as a companion mechanism when the radio drops the IPv4 PDP context. Tony From owner-v6ops@ops.ietf.org Mon Sep 30 12:26:19 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10889 for ; Mon, 30 Sep 2002 12:26:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17w3OE-000293-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 09:27:22 -0700 Received: from mailhost1-chcgil.chcgil.ameritech.net ([206.141.192.67] helo=mailhost.chi1.ameritech.net) by psg.com with esmtp (Exim 3.36 #1) id 17w3OA-00028m-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 09:27:19 -0700 Received: from repligate ([67.36.190.215]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020930162717.FNBN1118.mailhost.chi1.ameritech.net@repligate>; Mon, 30 Sep 2002 11:27:17 -0500 Message-ID: <071a01c2689e$41651420$d7be2443@repligate> From: "Jim Fleming" To: "Bound, Jim" , , , Cc: , References: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93FB@tayexc13.americas.cpqcorp.net> Subject: Re: ocean: do not boil Date: Mon, 30 Sep 2002 11:27:21 -0500 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bound, Jim" > > Speaking only for myself, not Nokia, I'm of the > opinion that DSTM doesn't add anything to the 3GPP > equation. It's logically equivalent to having > an IPv6 PDP context always up, and bringing up > a v4 PDP context on demand. If one wants security to work e2e for handheld NAT must be avoided. If there are only X Ipv4 global address space by a provider then the provider must manage their usage. If the provider service is dominant IPv6 usage then the only reason to use Ipv4 are for services that have not been migrated to IPv6. This is where DSTM brings its value. ====== Dual or MULTI Address Space does not require a change in protocol to go end-to-end. How many addresses does one really need for "handhelds" ? Do those handhelds set the SNOOPY bit ? 128-bit DNS AAAA Record Flag Day Formats 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt Whitehouse Ready to Release Next Generation Internet Plan http://news.com.com/2100-1023-958159.html?tag=politech http://www.politechbot.com/p-03994.html http://www.uscryptomail.org/cybersecurity/ Note: The new plan calls for the same architecture used with IPv8 and IPv16, whereby, users do not have direct access to the (out-of-band) IPv16 network. Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au http://ipv8.ods.org From owner-v6ops@ops.ietf.org Mon Sep 30 23:01:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03312 for ; Mon, 30 Sep 2002 23:01:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wDIi-000MSm-00 for v6ops-data@psg.com; Mon, 30 Sep 2002 20:02:20 -0700 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 17wDIe-000MSb-00 for v6ops@ops.ietf.org; Mon, 30 Sep 2002 20:02:16 -0700 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B75102E07; Mon, 30 Sep 2002 23:02:15 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 30 Sep 2002 23:02:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: ocean: do not boil Date: Mon, 30 Sep 2002 23:02:14 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE93FF@tayexc13.americas.cpqcorp.net> Thread-Topic: ocean: do not boil Thread-Index: AcJomulV0kYQ2i82S2exYbNd6bjxMAAW/mPg From: "Bound, Jim" To: , , , Cc: , X-OriginalArrivalTime: 01 Oct 2002 03:02:15.0341 (UTC) FILETIME=[F222DDD0:01C268F6] X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA03312 agreed. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Monday, September 30, 2002 12:03 PM > To: Bound, Jim; Rod.VanMeter@nokia.com; mrw@windriver.com; > hesham.soliman@era.ericsson.se > Cc: itojun@iijlab.net; v6ops@ops.ietf.org > Subject: RE: ocean: do not boil > > > Jim Bound wrote: > > ... > > If the provider service is dominant IPv6 usage then the only > > reason to use Ipv4 are for services that have not been > > migrated to IPv6. This is where DSTM brings its value. > > > > It permits a network operator to: > > > > 1: conserve and manage its precious IPv4 global address space > > 2: control the use of IPv4 global address space per usage/service > > 3: identify a migration of services and apps that must move to IPv6 > > 4: avoid the use of any NAT paradigm at the GGSN > > 5. Use e2e security (e.g. IPsec) inherent on the handheld. > > 6. Use IPv6 as the dominant routing protocol. > > > > The above cannot be done with NAT-PT. In addition > > DSTM as a solution can be used only when needed and > > does not require the routing complexity (except coming back > > into the GGSN) that 6to4 does. But a variation of DSTM is > > also proposed that will use 6to4 if it is part of the DSTM. > > > > DSTM not only is useful for 3G but 802.11 LANs, LMMs, > > and WANs which I see being deployed much faster and > > in fact currently and I see NO 3G deployment at this time. > > So I am testing this with 802.11 as a note and with handheld > > devices. > > > > Rod was correct, in the sense that for a basic 3G network a > demand IPv4 > PDP context provides the same functionality that DSTM provides to a > routed IPv6 network. The point I think you are trying to make is that > DSTM also works in wireless hot-spot networks, and for an > operator that > is interested in a unified mechanism for handsets that roam > between the > 802.11 & 3G radios, DSTM may be the best approach. If they really are > locked into the point-to-point association between the GGSN & the > handset, they could use L2TP as a companion mechanism when the radio > drops the IPv4 PDP context. > > Tony > > > >