From marka@isc.org Sat Aug 1 00:19:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53F9A3A67A6 for ; Sat, 1 Aug 2009 00:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVXCNUmSnS52 for ; Sat, 1 Aug 2009 00:19:36 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 8FBE33A6873 for ; Sat, 1 Aug 2009 00:19:05 -0700 (PDT) Received: from drugs.dv.isc.org (unknown [212.112.167.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 8DB68E606E; Sat, 1 Aug 2009 07:19:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n717IpTi009329; Sat, 1 Aug 2009 17:19:01 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908010719.n717IpTi009329@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews References: <20090728081435.GA5567@shinkuro.com> <200907280842.n6S8gc5O003027@drugs.dv.isc.org> <20090728092340.GC5567@shinkuro.com> <200907280928.n6S9Sdi1004597@drugs.dv.isc.org> <20090728093454.GE5567@shinkuro.com> <20090728160020.GI6181@shinkuro.com> <20090731203344.GE14838@shinkuro.com> <200907312154.n6VLsVEA006484@drugs.dv.isc.org> <20090731222142.GH14838@shinkuro.com> In-reply-to: Your message of "Fri, 31 Jul 2009 18:21:43 -0400." <20090731222142.GH14838@shinkuro.com> Date: Sat, 01 Aug 2009 17:18:51 +1000 Sender: marka@isc.org Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 reverse X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 07:19:37 -0000 In message <20090731222142.GH14838@shinkuro.com>, Andrew Sullivan writes: > On Sat, Aug 01, 2009 at 07:54:31AM +1000, Mark Andrews wrote: > > You made this way to complicated which is why I suggested the > > CNAME in the first place. > > I am willing to countenance a charge that I've made it more > complicated than you think necessary. Perhaps just synthesizing the > CNAME is indeed trivial (though I think you're waving away some of the > steps I outlined without admitting that you have in fact to do them). > But … > > > > to be _that_ bad, so it's by no means impossible. But it's more > > > complication in an already fragile and complicated mess that we're > > > creating just as a transition strategy. > > > > FUD > > … I am not willing to stand for that. What I am saying is not FUD, > it's simply asking whether a given trade-off is worth it. It's fun to > point and laugh at people we disagree with, but that isn't an > argument. Your making it out to be much harder that it is. You are over estimating the difficulty. Named already does something like this to authorise UPDATES in the 6to4 range. It digs the IPv4 address out of the UPDATE request and matches it against the source address of the UPDATE as well as checking that it is coming in via TCP. Doing this was trivial. Doing a similar thing with queries is trivial. > I know you happen to like the reverse tree, and think everyone should > maintain it. I do too, and I wasted a great deal of time on a > document that ended up practically stating an analytic truth but that > still couldn't find consensus. We lost that battle, story's over, > let's move on. This isn't the same thing. This is like deprecating RFC2317. This is the method not the data. > So, by supporting int6.arpa/in-addr.arpa strategies, we're adding yet > more complication to a strategy that is, bluntly, a way to lie > consistently in the DNS. If it was just a way to lie consistently in the DNS we should not be doing it. It however is not just that. > If you thnk that's not a fragile and > complicated mess, bully for you; but I don't think it's in itself a > good thing. Obviously, if I didn't think it was the right trade-off, > I wouldn't work on it. That doesn't mean I want to do anything more > here than the bare minimum we need to do in order to get the support > that people need. I am asking quite seriously whether the reverse > tree is worth doing anything to support, given that it is in fact one > more step. It is a small step. Today I run netstat on my machines and I find it mildy annoying that I can't see what my machine is talking to in a human friendly form (names). I provide that information for others. Note this really isn't something that can be done another way if the manufacturers don't provide the mapping tools. Your example of a request to not pre-populate the reverse space in dnsop is not the same thing as there are lots of alternative methods to supply the data if one wants to. It's comparing apples to oranges. > But if other implementers also weigh in with, "Yes, this is trivial," > I am not unwilling to change the draft to reflect that. > > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From simon.perreault@viagenie.ca Sat Aug 1 05:50:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B808D3A696A for ; Sat, 1 Aug 2009 05:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYqvs+QsC4-c for ; Sat, 1 Aug 2009 05:50:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id DA5643A68AF for ; Sat, 1 Aug 2009 05:50:03 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 40B9B29E15EC; Sat, 1 Aug 2009 08:50:03 -0400 (EDT) Received: from powerbook-g4-15-de-simon-perreault-2.local (ramadanwk.sorbis.com [66.251.99.126]) by jazz.viagenie.ca (Postfix) with ESMTP id F2F4E29E15CF for ; Sat, 1 Aug 2009 08:49:45 -0400 (EDT) Message-ID: <4A72F0BF.4000609@viagenie.ca> Date: Fri, 31 Jul 2009 15:25:19 +0200 From: Simon Perreault User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 12:50:10 -0000 Hello, This is an implementation issue that I hadn't fully grasped before my talk. Now I have, and I propose a fix. Imagine you have a DNS64 server with IPv4 and IPv6 addresses. In the process of recursing, it may synthesize AAAA records for upstream servers that it wants to contact. It will then end up sending DNS requests to the NAT64 device whereas they should have gone directly over IPv4. This is the first problem. The second problem is that it is not even certain that the NAT64 device is accessible from the DNS64 server. I can imagine useful and common real-life deployments where it will not be the case. This last problem could be fixed by ignoring it. The IPv6 request will time out quickly (assuming we receive an ICMP error) and IPv4 will become preferred for future requests (or so I understood from chatting with a DNS server implementor). But the first problem remains even if the NAT64 device is accessible. Therefore, I suggest that we add something along the line of the following to the draft: A DNS64 implementation MUST provide a configuration directive specifying whether it is allowed to send requests to synthetic IPv6 addresses while it is recursing. Note: If the DNS64 has a usable IPv4 connection, it is expected that the directive will be set to false. Otherwise, and if the DNS64 can reach the IPv4/IPv6 translator, it is expected that the directive will be set to true. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Sun Aug 2 04:09:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E735C3A6B82 for ; Sun, 2 Aug 2009 04:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQ6Pr9FQ4omP for ; Sun, 2 Aug 2009 04:09:48 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 62ABE3A6B97 for ; Sun, 2 Aug 2009 04:08:54 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 721C429E15E4; Sun, 2 Aug 2009 07:08:53 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Sun, 2 Aug 2009 07:08:43 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.5-191.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <200907280735.n6S7ZIJv001883@drugs.dv.isc.org> <200907282030.n6SKTp2T003501@drugs.dv.isc.org> <20090731201043.GD14838@shinkuro.com> In-Reply-To: <20090731201043.GD14838@shinkuro.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908020708.43602.simon.perreault@viagenie.ca> Cc: Andrew Sullivan Subject: Re: [BEHAVE] =?iso-8859-1?q?draft-ietf-behave-dns64-00_Additional_sec?= =?iso-8859-1?q?tion=09processing?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 11:09:49 -0000 On Friday 31 July 2009 16:10:44 Andrew Sullivan wrote: > 1. "We don't care. Don't run a DNS server that offers recursion > and performs caching behind a DNS64, period." I think this won't > really work, because we have no way of knowing how many such > resolvers there are out there, and the whole point of this effort > is to reduce the need to upgrade all the deployed systems > (particularly, all the customer equipment) or to know exactly what > equipment lies where in the network. This is what I would prefer. There are many cases where B is controlled by the same entity as the one who controls the DNS64. In this case, B's configuration can be modified so that it works in this context. No need to change software, just configuration. Otherwise, there are many cases where the entity who controls the DNS64 also controls the network, and may then simply redirect all DNS queries to the DNS64. Many ISPs currently do this anyway with DNS servers that lie in arguably less useful fashion. Are there significant instances of other cases (the entity who controls the DNS64 controls neither B nor the network) we should care about? I can't think of any. Simon -- Please try Numb, a STUN/TURN server implementation. Free access at http://numb.viagenie.ca/. From brian.e.carpenter@gmail.com Sun Aug 2 15:25:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398CE3A6988 for ; Sun, 2 Aug 2009 15:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+1E+hOIYkpY for ; Sun, 2 Aug 2009 15:25:38 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 1C6463A6AE1 for ; Sun, 2 Aug 2009 15:23:46 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so445821wah.5 for ; Sun, 02 Aug 2009 15:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=H4NCIyAvOOPwxgebrCUORx0x6JXHOI9DGQw7rgK0TGY=; b=gMS5aY8BCBaB0wxmtghzCIJFphDlYJmpRXprDA0itOFX9XLjAB/AJ22lKEhLlTxOkv UZH3PK0ykm8B7fLKlgeD0B2cs4ffFX3Fi44q0ZES8HM18/0lJScqhu0atjV445TC0UKg 3/0AGEyD0eaoLzq5eMyW6SnYeuEgyuGnIkE2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=IcR7IFvPya+jsqmei+OyhySgpu+AQc7YWjj8hPFpjGhILdwdH2PaUj73/JSCvXMZQm fRGXYqPVN7MRe16BBOp9zY6uyXprt/DaEBoqqvV17gCYZI0Ct3Kf7RlZPFsZke7NAk8G /ae52T1RXBjMoFZ3GukY6zcloRmBBF3+ugehA= Received: by 10.115.51.19 with SMTP id d19mr5769019wak.208.1249251827768; Sun, 02 Aug 2009 15:23:47 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k2sm5474077rvb.2.2009.08.02.15.23.46 (version=SSLv3 cipher=RC4-MD5); Sun, 02 Aug 2009 15:23:47 -0700 (PDT) Message-ID: <4A7611F0.9030201@gmail.com> Date: Mon, 03 Aug 2009 10:23:44 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <20090731074443.GA14355@shinkuro.com> In-Reply-To: <20090731074443.GA14355@shinkuro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext] DNS64 and lying cache servers] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 22:25:39 -0000 It's an interesting point but it misses the point IMHO: we *have* to lie to classical IPv6-only hosts. I've always preferred the stub resolver approach, right back to draft-van-beijnum-v6ops-mnat-pt-00.txt, but that preference is useless if the real world contains classical IPv6 hosts. Brian On 2009-07-31 19:44, Andrew Sullivan wrote: > Dear colleagues, > > Some of the participants in dnsext are reluctant to join another > mailing list the subject of which is mostly not of interest to them. > I have offered to accept comments from those participants and forward > them to behave when appropriate and if asked. Attached is one such > example. > > A > > > > ------------------------------------------------------------------------ > > Subject: > [dnsext] DNS64 and lying cache servers > From: > Francis Dupont > Date: > Wed, 29 Jul 2009 14:28:26 +0200 > To: > namedroppers@ops.ietf.org > > To: > namedroppers@ops.ietf.org > > > [Please forward this to the behave mailing-list] > > [I use the term "cache server" as a synonym of "recursive DNS server"] > > DNS64 (draft-ietf-behave-dns64-00.txt) is usually presented with > a cache server serving a lot of NAT64 IPv6-only clients and performing > AAAA RR synthesis from A RRs to make external IPv4-only servers > reachable through a NAT64 translator. > > So this is essentially a lying cache server: this is *bad* for the > usual reason (it breaks DNSSEC). Worse, its lie is very location > dependent, so it has very bad interaction when the DNS is assumed > to be location independent, for instance with Mobility. > > But as explained in the draft at the end of the section 2 Overview > this is not the only way to deploy DNS64: in the "DNS64 in stub- > resolver mode" the synthesis is done as close as possible to the > client so there is no longer lying issues. > > Note this doesn't extend to some other lying DNS proposals from > NAT based IPv6/IPv4 transition mechanisms because DNS64 uses a > small set of static parameters (mainly the Pref64::/n) which is > the only state of the synthesis process. > > So I recommend the DNSEXT WG to advise to put more work into > the sub-resolver mode (producing DNS64 capable stub-resolvers, > which should be very easy, and solving the DNS64 parameter > distribution issue) than into the DNS server mode which should be > recognized as an example of a false good idea. > > Regards > > Francis.Dupont@fdupont.fr > > PS: Acknowledgments to Mark Andrews who introduced the strong but > correct "lying" term, and to Wassim Haddad who remarked DNS64 and > Mobility together can easily lead to disasters. > > -- > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From charliep@wichorus.com Sun Aug 2 15:46:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B6C3A6C4F for ; Sun, 2 Aug 2009 15:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uARgnav+QU1c for ; Sun, 2 Aug 2009 15:46:00 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id EF8183A6B2C for ; Sun, 2 Aug 2009 15:45:59 -0700 (PDT) Received: from [99.51.74.16] (helo=[192.168.1.105]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MXjoX-0008Ej-Q8; Sun, 02 Aug 2009 18:46:02 -0400 Message-ID: <4A761728.6010509@wichorus.com> Date: Sun, 02 Aug 2009 15:46:00 -0700 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Andrew Sullivan References: <20090731074443.GA14355@shinkuro.com> <4A7611F0.9030201@gmail.com> In-Reply-To: <4A7611F0.9030201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525cc9cb0489b28e90012450fb0fd02bb7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: behave@ietf.org Subject: Re: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext] DNS64 and lying cache servers] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 22:46:01 -0000 Hello folks, There is a reference below to a disaster that can occur when DNS64 encounters mobility. Is there something more I can read about this? Thanks in advance for any pointers to reading material. Regards, Charlie P. Brian E Carpenter wrote: > It's an interesting point but it misses the point IMHO: > we *have* to lie to classical IPv6-only hosts. > > I've always preferred the stub resolver approach, right back > to draft-van-beijnum-v6ops-mnat-pt-00.txt, but that preference is > useless if the real world contains classical IPv6 hosts. > > Brian > > > On 2009-07-31 19:44, Andrew Sullivan wrote: > >> Dear colleagues, >> >> Some of the participants in dnsext are reluctant to join another >> mailing list the subject of which is mostly not of interest to them. >> I have offered to accept comments from those participants and forward >> them to behave when appropriate and if asked. Attached is one such >> example. >> >> A >> >> >> >> ------------------------------------------------------------------------ >> >> Subject: >> [dnsext] DNS64 and lying cache servers >> From: >> Francis Dupont >> Date: >> Wed, 29 Jul 2009 14:28:26 +0200 >> To: >> namedroppers@ops.ietf.org >> >> To: >> namedroppers@ops.ietf.org >> >> >> [Please forward this to the behave mailing-list] >> >> [I use the term "cache server" as a synonym of "recursive DNS server"] >> >> DNS64 (draft-ietf-behave-dns64-00.txt) is usually presented with >> a cache server serving a lot of NAT64 IPv6-only clients and performing >> AAAA RR synthesis from A RRs to make external IPv4-only servers >> reachable through a NAT64 translator. >> >> So this is essentially a lying cache server: this is *bad* for the >> usual reason (it breaks DNSSEC). Worse, its lie is very location >> dependent, so it has very bad interaction when the DNS is assumed >> to be location independent, for instance with Mobility. >> >> But as explained in the draft at the end of the section 2 Overview >> this is not the only way to deploy DNS64: in the "DNS64 in stub- >> resolver mode" the synthesis is done as close as possible to the >> client so there is no longer lying issues. >> >> Note this doesn't extend to some other lying DNS proposals from >> NAT based IPv6/IPv4 transition mechanisms because DNS64 uses a >> small set of static parameters (mainly the Pref64::/n) which is >> the only state of the synthesis process. >> >> So I recommend the DNSEXT WG to advise to put more work into >> the sub-resolver mode (producing DNS64 capable stub-resolvers, >> which should be very easy, and solving the DNS64 parameter >> distribution issue) than into the DNS server mode which should be >> recognized as an example of a false good idea. >> >> Regards >> >> Francis.Dupont@fdupont.fr >> >> PS: Acknowledgments to Mark Andrews who introduced the strong but >> correct "lying" term, and to Wassim Haddad who remarked DNS64 and >> Mobility together can easily lead to disasters. >> >> -- >> to unsubscribe send a message to namedroppers-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From teemu.savolainen@nokia.com Sun Aug 2 23:42:57 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D6C3A6D53 for ; Sun, 2 Aug 2009 23:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF14aeRxJjSM for ; Sun, 2 Aug 2009 23:42:56 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id E0ADB3A6D63 for ; Sun, 2 Aug 2009 23:42:55 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n736gTIe021051; Mon, 3 Aug 2009 09:42:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:42:36 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:42:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 09:42:27 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 3 Aug 2009 08:42:25 +0200 From: To: , , Date: Mon, 3 Aug 2009 08:41:21 +0200 Thread-Topic: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext] DNS64 and lying cache servers] Thread-Index: AcoTwwoDQ50kzBAjSsicpjXtSyQjWgAQWyXQ Message-ID: <18034D4D7FE9AE48BF19AB1B0EF2729F3A70E27FC5@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090731074443.GA14355@shinkuro.com> <4A7611F0.9030201@gmail.com> <4A761728.6010509@wichorus.com> In-Reply-To: <4A761728.6010509@wichorus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Aug 2009 06:42:27.0060 (UTC) FILETIME=[90D2B340:01CA1405] X-Nokia-AV: Clean Cc: behave@ietf.org Subject: Re: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext] DNS64 and lying cache servers] X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 06:42:57 -0000 Hi, For me this sounds exactly like the split-DNS problem I describe here: draf= t-savolainen-mif-dns-server-selection (http://tools.ietf.org/html/draft-sav= olainen-mif-dns-server-selection-00) and what we discuss in MIF WG. Essentially even today multi-interfaced hosts can not really trust DNS info= rmation being fully coherent between different administrative domains. I plan to include the faked AAAA records as additional example of private i= nformation DNS servers are providing, and information that must be used onl= y in the administrative domain they were learned from.=20 Best regards, Teemu >-----Original Message----- >From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org]=20 >On Behalf Of ext Charles E. Perkins >Sent: 03 August, 2009 01:46 >To: Andrew Sullivan >Cc: behave@ietf.org >Subject: Re: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext]=20 >DNS64 and lying cache servers] > > >Hello folks, > >There is a reference below to a disaster that can occur when=20 >DNS64 encounters mobility. Is there something more I can read=20 >about this? > >Thanks in advance for any pointers to reading material. > >Regards, >Charlie P. > > > >Brian E Carpenter wrote: >> It's an interesting point but it misses the point IMHO: >> we *have* to lie to classical IPv6-only hosts. >> >> I've always preferred the stub resolver approach, right back to=20 >> draft-van-beijnum-v6ops-mnat-pt-00.txt, but that preference=20 >is useless=20 >> if the real world contains classical IPv6 hosts. >> >> Brian >> >> >> On 2009-07-31 19:44, Andrew Sullivan wrote: >> =20 >>> Dear colleagues, >>> >>> Some of the participants in dnsext are reluctant to join another=20 >>> mailing list the subject of which is mostly not of interest to them. >>> I have offered to accept comments from those participants=20 >and forward=20 >>> them to behave when appropriate and if asked. Attached is one such=20 >>> example. >>> >>> A >>> >>> >>> >>>=20 >--------------------------------------------------------------------- >>> --- >>> >>> Subject: >>> [dnsext] DNS64 and lying cache servers >>> From: >>> Francis Dupont >>> Date: >>> Wed, 29 Jul 2009 14:28:26 +0200 >>> To: >>> namedroppers@ops.ietf.org >>> >>> To: >>> namedroppers@ops.ietf.org >>> >>> >>> [Please forward this to the behave mailing-list] >>> >>> [I use the term "cache server" as a synonym of "recursive DNS=20 >>> server"] >>> >>> DNS64 (draft-ietf-behave-dns64-00.txt) is usually presented with a=20 >>> cache server serving a lot of NAT64 IPv6-only clients and=20 >performing=20 >>> AAAA RR synthesis from A RRs to make external IPv4-only servers=20 >>> reachable through a NAT64 translator. >>> >>> So this is essentially a lying cache server: this is *bad* for the=20 >>> usual reason (it breaks DNSSEC). Worse, its lie is very location=20 >>> dependent, so it has very bad interaction when the DNS is=20 >assumed to=20 >>> be location independent, for instance with Mobility. >>> >>> But as explained in the draft at the end of the section 2 Overview=20 >>> this is not the only way to deploy DNS64: in the "DNS64 in stub-=20 >>> resolver mode" the synthesis is done as close as possible to the=20 >>> client so there is no longer lying issues. >>> >>> Note this doesn't extend to some other lying DNS proposals from NAT=20 >>> based IPv6/IPv4 transition mechanisms because DNS64 uses a=20 >small set=20 >>> of static parameters (mainly the Pref64::/n) which is the=20 >only state=20 >>> of the synthesis process. >>> >>> So I recommend the DNSEXT WG to advise to put more work into the=20 >>> sub-resolver mode (producing DNS64 capable stub-resolvers, which=20 >>> should be very easy, and solving the DNS64 parameter distribution=20 >>> issue) than into the DNS server mode which should be=20 >recognized as an=20 >>> example of a false good idea. >>> >>> Regards >>> >>> Francis.Dupont@fdupont.fr >>> >>> PS: Acknowledgments to Mark Andrews who introduced the strong but=20 >>> correct "lying" term, and to Wassim Haddad who remarked DNS64 and=20 >>> Mobility together can easily lead to disasters. >>> >>> -- >>> to unsubscribe send a message to namedroppers-request@ops.ietf.org=20 >>> with the word 'unsubscribe' in a single line as the message=20 >text body. >>> archive: >>> >>> >>>=20 >--------------------------------------------------------------------- >>> --- >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> =20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> =20 > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave >= From remi.despres@free.fr Mon Aug 3 02:41:16 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CAC28C104 for ; Mon, 3 Aug 2009 02:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkdmHNcbURvh for ; Mon, 3 Aug 2009 02:41:10 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id BE6743A697A for ; Mon, 3 Aug 2009 02:41:07 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9F592E08086; Mon, 3 Aug 2009 11:41:04 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8BE66E080E9; Mon, 3 Aug 2009 11:41:01 +0200 (CEST) In-Reply-To: <4A6EC18F.60605@sun.com> References: <4A6E262E.5030007@gmail.com> <4A6EC18F.60605@sun.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Mon, 3 Aug 2009 11:41:00 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.753.1) Cc: Behave WG , Fred Baker Subject: Re: [BEHAVE] Comments on prefix format requirements X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 09:41:16 -0000 Le 28 juil. 09 =E0 11:14, Erik Nordmark a =E9crit : > Brian E Carpenter wrote: > >> I don't think that is quite the point. The point is that if (and it's >> a big if) we ever try to retro-fit some form of 8+8 to the Internet, >> the U flag needs to be trustworthy, since 8+8 requires universally >> unique IIDs. That's an architectural change that IMHO is clearly out >> of BEHAVE's scope and belongs in 6MAN. I see that R=E9mi D has = started >> a thread on that in 6MAN. > > Yes, we definitely should discuss this in 6MAN. > > FWIW I don't see any utility in remote interpretation of the U-=20 > flag. It was added as a result of the 8+8/GSE discussion as being =20 > potentially useful for multihoming. > I've explored many different ways to do multihoming and read about =20 > a few more, > but I've seen no worked out proposal which would benefit from a =20 > remote node using the U bit in the interface ID. And the point is that for SAM, not only would it not be a benefit but =20= it would prevent a simple design. (BTW, your comments and/or questions on draft-despres-sam-03 would be =20= most welcome.) Regards, RD From remi.despres@free.fr Mon Aug 3 03:19:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0613A6D73; Mon, 3 Aug 2009 03:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M274wLbu0mpK; Mon, 3 Aug 2009 03:19:11 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id DF92E28C159; Mon, 3 Aug 2009 03:18:46 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id B6A70E0813C; Mon, 3 Aug 2009 12:18:34 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id DE992E0811D; Mon, 3 Aug 2009 12:18:29 +0200 (CEST) In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Mon, 3 Aug 2009 12:18:29 +0200 To: Christian Huitema X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Christopher Morrow , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 10:19:12 -0000 Le 30 juil. 09 =E0 03:09, Christian Huitema a =E9crit : >> On 2009-07-29 19:43, Benny Amorsen wrote: >>> Brian E Carpenter writes: >>> >>>> Er, do your routers do that when they throw away packets due to >>>> congestion? >>> >>> If a router throws away a packet due to congestion, there's a good >>> chance that a retransmission will go through. In this case you can >>> retransmit as many no-UDP-checksum packets you want, none of them =20= >>> will >>> get through. The host really ought to be told that it is wasting its >>> time. >> >> There's no retransmission in UDP. >> >> Presumably there is no harm in sending back some kind of ICMP error, >> most likely Parameter Problem, at a throttled rate. But we shouldn't >> mandate >> it IMHO, and you certainly can't rely on a host stopping a UDP stream >> as a result. > > What happened to being conservative with what we send and =20 > permissive with what we receive? > > It seems that the direct application should be: > > 1) Be conservative: hosts should not send UDP packets with null =20 > checksums. > 2) Permissive: gateways who receive UDP packets with null checksum =20 > should compute a checksum based on the received bytes, and then =20 > forward the packet. > > I understand there may be resource limits on gateways, and that the =20= > UDP checksum compute requirement might throw the packet back to =20 > some kind of slow path, with potential packet loss due to =20 > congestion. But that's way better than a black hole. In view of the various arguments made, here is IMHO a good combination: - IPv6 hosts MUST create UDP datagrams with non-zero checksums. (Nothing new here.) - IPv6 hosts MAY accept UDP datagrams with zero checksum. ((1) Application of the classic principle "be strict in what you =20 send, tolerant in what you receive"; (2) useful for some UDP =20 datagrams that cross some v4-v6 translators.) - IPv6 hosts that accept zero-checksum UDP datagrams MAY restrict =20 this tolerance to remote hosts whose IPv6 addresses include an IPv4 =20 mapped address. (Thus no new tolerance is introduced for IPv6 hosts.) - IPv4 to IPv6 translators that receive UDP datagrams with zero =20 checksums MAY keep these checksums in translated datagrams. ((1) Simple to implement; (2) works for fragmented IPv4 datagrams; =20 (3) avoids the waste of CPU power to compute UDP checksums of IPv4 =20 unfragmented UDP datagrams received with zero checksums.) Regards, RD From lars.eggert@nokia.com Mon Aug 3 04:56:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC223A6A68; Mon, 3 Aug 2009 04:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Mt7po4raEJ; Mon, 3 Aug 2009 04:56:26 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id B10ED3A6BC0; Mon, 3 Aug 2009 04:56:25 -0700 (PDT) Received: from [192.168.0.198] (funet-wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n73BsTtX068520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 3 Aug 2009 14:54:29 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> From: Lars Eggert To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> Content-Type: multipart/signed; boundary=Apple-Mail-4-410324420; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 14:54:23 +0300 References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Mon, 03 Aug 2009 14:54:32 +0300 (EEST) Cc: Francis Dupont , Behave WG , Benny Amorsen , 6man 6man , Christopher Morrow Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 11:56:26 -0000 --Apple-Mail-4-410324420 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On 2009-8-3, at 13:18, R=E9mi Despr=E9s wrote: > In view of the various arguments made, here is IMHO a good =20 > combination: ... > - IPv6 hosts MAY accept UDP datagrams with zero checksum. I see no reason why allowing a UDP checksum of zero for router-to-=20 router tunnels under specific circumstances (existence of a payload =20 checksum), which is what we've been discussing for AMT and LISP, =20 motivates *any* changes for the host. As far as hosts as concerned, =20 nothing changes with regards to RFC2460. > - IPv6 hosts that accept zero-checksum UDP datagrams MAY restrict > this tolerance to remote hosts whose IPv6 addresses include an IPv4 > mapped address. > (Thus no new tolerance is introduced for IPv6 hosts.) Since there is no IP header checksum in IPv6, these IP addresses can =20 be corrupted, and so this check may fail. > - IPv4 to IPv6 translators that receive UDP datagrams with zero > checksums MAY keep these checksums in translated datagrams. Translators are not tunnels. The argument why a zero outer checksum =20 may be OK for tunnels is that the inner payload is still protected by =20= a checksum, which is not true for translators. Lars= --Apple-Mail-4-410324420 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDMxMTU0MjRaMCMGCSqGSIb3DQEJBDEWBBQOuVIGQBW3A0dn qAF642gqa9TTTzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAL46yiBMdxCClXTpwcizifSOJcDUjqvPskTj3X/pGWtwVLl0zzeOB Xb5tQgL3ZaYE7BsRkZpkypYnRSGI/2ekqcrJ3Qp25IQeApsH8pEWVYN76eP0tSw5G2632aLUpBkr M6RfZUFZl0fpnh8Xyykj0wr3ob7kGCmsSurfs+mJiLaJLrwKVfGJYMQJUsqB0VHrYPqsryv+/j0M vFAWOebjO2QN/SUoAFAduXoHTIeSAkrrHTzT/cGvOPgwBq9EsD+ycP5YGTkKmVePCQJ5U6q6wp3H h1EF/Z/wfW8dpCTZSKI1YuJwEnkEFkgG45EV3oH3U8mi+ljuobKio4megETEBgAAAAAAAA== --Apple-Mail-4-410324420-- From pekkas@netcore.fi Mon Aug 3 05:29:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2933A6B9D; Mon, 3 Aug 2009 05:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MY5JW1f4E-d; Mon, 3 Aug 2009 05:29:10 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 9C2A43A68FD; Mon, 3 Aug 2009 05:29:09 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n73CSxcT008700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 15:28:59 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n73CSx47008696; Mon, 3 Aug 2009 15:28:59 +0300 Date: Mon, 3 Aug 2009 15:28:59 +0300 (EEST) From: Pekka Savola To: Lars Eggert In-Reply-To: <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> Message-ID: References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.2 at otso.netcore.fi X-Virus-Status: Clean Cc: Francis Dupont , Behave WG , Benny Amorsen , 6man 6man Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 12:29:10 -0000 On Mon, 3 Aug 2009, Lars Eggert wrote: > I see no reason why allowing a UDP checksum of zero for router-to-router > tunnels under specific circumstances (existence of a payload checksum), which > is what we've been discussing for AMT and LISP, motivates *any* changes for > the host. As far as hosts as concerned, nothing changes with regards to > RFC2460. While this is true for LISP, unfortunately an AMT tunnel endpoint may be a host; in fact it's likely it will be. :-/ For the specific case of AMT, I wouldn't personally see a problem with IPv6 encapsulating plain IP instead of UDP, though this would complicate the spec slightly. The LAG argument doesn't apply in the case of AMT. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Remi.Denis-Courmont@nokia.com Mon Aug 3 06:02:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFBB28C141; Mon, 3 Aug 2009 06:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Q5K5qJm-J7D; Mon, 3 Aug 2009 06:02:38 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 29B7E3A6AA0; Mon, 3 Aug 2009 06:02:37 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n73D2CiI026119; Mon, 3 Aug 2009 16:02:26 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 16:02:30 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 16:02:30 +0300 Received: from leon.remlab.net (esdhcp034247.research.nokia.com [172.21.34.247]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n73D2P9o022129; Mon, 3 Aug 2009 16:02:25 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Devices - Nokia To: behave@ietf.org Date: Mon, 3 Aug 2009 16:02:26 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.29.6; KDE/4.2.2; i686; ; ) References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908031602.27960.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Aug 2009 13:02:30.0078 (UTC) FILETIME=[A87B1DE0:01CA143A] X-Nokia-AV: Clean Cc: Francis Dupont , 6man 6man , ext Pekka Savola , Benny Amorsen Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:02:39 -0000 On Monday 03 August 2009 15:28:59 ext Pekka Savola wrote: > On Mon, 3 Aug 2009, Lars Eggert wrote: > > I see no reason why allowing a UDP checksum of zero for router-to-router > > tunnels under specific circumstances (existence of a payload checksum), > > which is what we've been discussing for AMT and LISP, motivates *any* > > changes for the host. As far as hosts as concerned, nothing changes with > > regards to RFC2460. > > While this is true for LISP, unfortunately an AMT tunnel endpoint may > be a host; in fact it's likely it will be. :-/ > > For the specific case of AMT, I wouldn't personally see a problem with > IPv6 encapsulating plain IP instead of UDP, though this would > complicate the spec slightly. The LAG argument doesn't apply in the > case of AMT. I still don't understand why AMT cannot use a new Foobar protocol number. Then we can specify that 64 translators translate: =2D UDP/IPv6 to summed UDP/IPv4, and vice versa, and =2D Foobar/IPv6 to unsummed UDP/IPv4, and vice versa. And conversely, that LISP and AMT shall use Foobar instead of UDP in the ca= se=20 of IPv6. Then, we can have a _constant_ checksum that protects the Foobar port numbe= rs=20 but not the inner packets. Basically it's just like UDP-Lite with 8-bytes=20 coverage. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From Remi.Denis-Courmont@nokia.com Mon Aug 3 06:39:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F803A6C11 for ; Mon, 3 Aug 2009 06:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 663CIhlLLk-1 for ; Mon, 3 Aug 2009 06:39:30 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C78223A6DC9 for ; Mon, 3 Aug 2009 06:39:29 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n73DcNBM010061; Mon, 3 Aug 2009 16:39:19 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 16:39:16 +0300 Received: from mgw-da02.ext.nokia.com ([147.243.128.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 16:39:15 +0300 Received: from leon.remlab.net (esdhcp034247.research.nokia.com [172.21.34.247]) by mgw-da02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n73Dd6PM016427; Mon, 3 Aug 2009 16:39:07 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Devices - Nokia To: ext Pekka Savola Date: Mon, 3 Aug 2009 16:39:12 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.29.6; KDE/4.2.2; i686; ; ) References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200908031602.27960.remi.denis-courmont@nokia.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908031639.12607.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 03 Aug 2009 13:39:16.0127 (UTC) FILETIME=[CB637AF0:01CA143F] X-Nokia-AV: Clean Cc: Francis Dupont , behave@ietf.org, Benny Amorsen Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:39:31 -0000 On Monday 03 August 2009 16:20:11 ext Pekka Savola wrote: > On Mon, 3 Aug 2009, R=E9mi Denis-Courmont wrote: > > I still don't understand why AMT cannot use a new Foobar protocol numbe= r. > > Then we can specify that 64 translators translate: > > - UDP/IPv6 to summed UDP/IPv4, and vice versa, and > > - Foobar/IPv6 to unsummed UDP/IPv4, and vice versa. > > And conversely, that LISP and AMT shall use Foobar instead of UDP in the > > case of IPv6. > > > > Then, we can have a _constant_ checksum that protects the Foobar port > > numbers but not the inner packets. Basically it's just like UDP-Lite wi= th > > 8-bytes coverage. > > Off-list: this is likely for consistency with IPv4 that has to use UDP > to pass through v4 NATs. We cannot afford consistency here - except by always having checksums. Either we break consistency with RFC2460 by allowing checksum-less UDP/IPv6= ,=20 or we break consistency with IPv4 by using a different transport protocol o= ver=20 IPv6 and checksum-less UDP over IPv4, or we break consistency with deployed= =20 IPv4 firewall/NATs by not using UDP at all. No matter what, consistency is impossible. We just have to suck it up. I prefer to break consistency with things that don't exist yet: new NAT64, = AMT=20 over IPv6 implementations, than with existing things like IPv4 NATs or IPv6= =20 stacks, but that's just my humble opinion. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From tme@americafree.tv Mon Aug 3 07:32:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E68F3A6E34; Mon, 3 Aug 2009 07:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnznIT+QRFvI; Mon, 3 Aug 2009 07:32:46 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9B8FA3A6E30; Mon, 3 Aug 2009 07:32:46 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id F0F544648214; Mon, 3 Aug 2009 10:32:48 -0400 (EDT) Message-Id: <9A181E80-4C6E-47B6-8A9E-BD01D1A330F3@americafree.tv> From: Marshall Eubanks To: Lars Eggert In-Reply-To: <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 3 Aug 2009 10:32:48 -0400 References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> X-Mailer: Apple Mail (2.935.3) Cc: Francis Dupont , Behave WG , Benny Amorsen , 6man 6man Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 14:32:47 -0000 On Aug 3, 2009, at 7:54 AM, Lars Eggert wrote: > Hi, > > On 2009-8-3, at 13:18, R=E9mi Despr=E9s wrote: >> In view of the various arguments made, here is IMHO a good =20 >> combination: > ... >> - IPv6 hosts MAY accept UDP datagrams with zero checksum. > > I see no reason why allowing a UDP checksum of zero for router-to-=20 > router tunnels under specific circumstances (existence of a payload =20= > checksum), which is what we've been discussing for AMT and LISP, =20 > motivates *any* changes for the host. As far as hosts as concerned, =20= > nothing changes with regards to RFC2460. > I don't see this as a very clear distinction. AMT, as Pekka pointed =20 out, will frequently have host endpoints. If I am running Zebra and LISP and =20 Apache 2 on a Dell server, is that a router or an endpoint ? So, hosts SHOULD drop zero-checksums unless they are participating in =20= a tunnel protocol, which was what we tried to capture. Regards Marshall >> - IPv6 hosts that accept zero-checksum UDP datagrams MAY restrict >> this tolerance to remote hosts whose IPv6 addresses include an IPv4 >> mapped address. >> (Thus no new tolerance is introduced for IPv6 hosts.) > > Since there is no IP header checksum in IPv6, these IP addresses can =20= > be corrupted, and so this check may fail. > >> - IPv4 to IPv6 translators that receive UDP datagrams with zero >> checksums MAY keep these checksums in translated datagrams. > > Translators are not tunnels. The argument why a zero outer checksum =20= > may be OK for tunnels is that the inner payload is still protected =20 > by a checksum, which is not true for translators. > > Lars=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From remi.despres@free.fr Mon Aug 3 08:46:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB0B28C174; Mon, 3 Aug 2009 08:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7cqErsNjI4o; Mon, 3 Aug 2009 08:46:48 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 047CB3A6D74; Mon, 3 Aug 2009 08:46:45 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id CEBD0E080DC; Mon, 3 Aug 2009 17:46:41 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 14427E0801C; Mon, 3 Aug 2009 17:46:38 +0200 (CEST) In-Reply-To: <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Mon, 3 Aug 2009 17:46:35 +0200 To: Lars Eggert X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , Behave WG , Benny Amorsen , 6man 6man , Christopher Morrow Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:46:49 -0000 Le 3 ao=FBt 09 =E0 13:54, Lars Eggert a =E9crit : > Hi, > > On 2009-8-3, at 13:18, R=E9mi Despr=E9s wrote: >> In view of the various arguments made, here is IMHO a good =20 >> combination: > ... >> - IPv6 hosts MAY accept UDP datagrams with zero checksum. > > I see no reason why allowing a UDP checksum of zero for router-to-=20 > router tunnels under specific circumstances (existence of a payload =20= > checksum), which is what we've been discussing for AMT and LISP, =20 > motivates *any* changes for the host. As far as hosts as concerned, =20= > nothing changes with regards to RFC2460. > >> - IPv6 hosts that accept zero-checksum UDP datagrams MAY restrict >> this tolerance to remote hosts whose IPv6 addresses include an IPv4 >> mapped address. >> (Thus no new tolerance is introduced for IPv6 hosts.) > > Since there is no IP header checksum in IPv6, these IP addresses =20 > can be corrupted, and so this check may fail. If a host may receive receive a zero-checksum UDP datagram destined =20 to another host, this is acceptable because: - Probability of this happening is very low (with link layer =20 checksums etc.). - It is even more UNLIKELY that the source address and the two ports =20 of the datagram match those of an existing connection (connection =20 where, in addition, such datagrams must be accepted). - If this nevertheless happens, the harm must be limited because of =20 the application nature. (For example, an application that accepts =20 queries in unchecked datagrams may receive an extra query without =20 significant consequence). If in charge of an IPv6 TCP/IP stack (which I am not), I would ensure =20= that, although it never sends zero-checksum UDP datagrams, it does =20 accept to receive them. Similarly, if in charge of of an SIIT (which I am not either), I =20 would ensure that rather than discarding IPv4 zero-checksum datagrams =20= it forwards them with its zero checksum. This being said, it's up to people in charge to decide. (I don't care =20= very much. Efforts to have IPv6 end-to-end rapidly deployed are IMHO =20 more important than efforts to keep IPv4-only environments work as =20 well as if they would be dual stack.) Regards, RD= From huitema@microsoft.com Mon Aug 3 13:16:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253B83A6A7D; Mon, 3 Aug 2009 13:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lagbDBrMOVSE; Mon, 3 Aug 2009 13:16:10 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 641763A6BDB; Mon, 3 Aug 2009 13:16:10 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 3 Aug 2009 13:16:12 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.621.7; Mon, 3 Aug 2009 13:16:12 -0700 Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.236]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 3 Aug 2009 13:16:10 -0700 From: Christian Huitema To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [BEHAVE] UDP zero checksums and v4 to v6 translators Thread-Index: AQHKECA7/O9Jd1/W4k+8GdXrmkDt1ZCNirqA//+4a1CAB1lwgIAAMEaw Date: Mon, 3 Aug 2009 20:14:13 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA043F5C49@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> In-Reply-To: <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Francis Dupont , 6man 6man , Benny Amorsen , Christopher Morrow , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 20:16:11 -0000 > In view of the various arguments made, here is IMHO a good combination: > - IPv6 hosts MUST create UDP datagrams with non-zero checksums. > (Nothing new here.) > - IPv6 hosts MAY accept UDP datagrams with zero checksum. > ((1) Application of the classic principle "be strict in what you > send, tolerant in what you receive"; (2) useful for some UDP > datagrams that cross some v4-v6 translators.) Except you do not get to specify that as part of the translator specificati= on. The translator spec applies to translators, not to hosts. Translators m= ust assume that IPv6 UDP packets with null checksum will be dropped by the = receiving host. For a translator, forwarding such a packet with a null chec= ksum is pretty much the same as dropping it. -- Christian Huitema From remi.despres@free.fr Tue Aug 4 00:40:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E023A6F9B; Tue, 4 Aug 2009 00:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1mQNcymmOEJ; Tue, 4 Aug 2009 00:40:58 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 40ED63A6939; Tue, 4 Aug 2009 00:40:55 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id CF627E0804F; Tue, 4 Aug 2009 09:40:50 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id A7847E08056; Tue, 4 Aug 2009 09:40:47 +0200 (CEST) In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA043F5C49@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <6B55F0F93C3E9D45AF283313B8D342BA043F5C49@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6B37047E-8CFA-4EA3-AB43-6CC3C6E4EDEE@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 4 Aug 2009 09:40:46 +0200 To: Christian Huitema X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Christopher Morrow , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 07:40:59 -0000 Le 3 ao=FBt 09 =E0 22:14, Christian Huitema a =E9crit : >> In view of the various arguments made, here is IMHO a good =20 >> combination: >> - IPv6 hosts MUST create UDP datagrams with non-zero checksums. >> (Nothing new here.) >> - IPv6 hosts MAY accept UDP datagrams with zero checksum. >> ((1) Application of the classic principle "be strict in what you >> send, tolerant in what you receive"; (2) useful for some UDP >> datagrams that cross some v4-v6 translators.) > > Except you do not get to specify that as part of the translator =20 > specification. > The translator spec applies to translators, not to hosts. Agreed. > Translators must assume that IPv6 UDP packets with null checksum =20 > will be dropped by the receiving host. Different understanding here. A better sentence IMHO would be "Translators MAY assume that IPv6 UDP =20= packets with null checksum are accepted by some receiving hosts (or =20 will be in the future)." > For a translator, forwarding such a packet with a null checksum is =20 > pretty much the same as dropping it. If all destination hosts drop them, the effect is indeed the same. But if some hosts start being open to receive them (a backward =20 compatible extension), then it makes a useful difference. The proposal is a combination of backward compatible extensions in =20 hosts and translators: - They make no harm in general. - They are useful when used in combination. Regards, RD From iljitsch@muada.com Tue Aug 4 04:20:16 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8473A7005; Tue, 4 Aug 2009 04:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+MvdCJq3jZm; Tue, 4 Aug 2009 04:20:16 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id E4CB23A6FCB; Tue, 4 Aug 2009 04:20:15 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74BJlRL041375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 13:19:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Christian Huitema In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA043E92FE@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 13:20:04 +0200 References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <4A70F421.7090403@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E92FE@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Apple Mail (2.935.3) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Christopher Morrow , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 11:20:17 -0000 On 30 jul 2009, at 3:35, Christian Huitema wrote: > The fragmentation issue is different from the zero-checksum issue. > Many IPv4 NAT drop fragmented packets already. That is unacceptable; fragments happen, even with TCP. > They rely on port numbers to find the mappings, fragments don't > carry port numbers, so fragments get dropped. Well the graybeards among us screwed up here, the port numbers should have been part of the unfragmentable headers in IPv6. (Not that that would have helped the problem at hand.) From iljitsch@muada.com Tue Aug 4 04:35:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7556D3A702A for ; Tue, 4 Aug 2009 04:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWJMF9Ad5vqt for ; Tue, 4 Aug 2009 04:35:35 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 114853A7031 for ; Tue, 4 Aug 2009 04:35:34 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74BZEYB041538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 13:35:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 13:35:30 +0200 References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> X-Mailer: Apple Mail (2.935.3) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 11:35:36 -0000 On 3 aug 2009, at 17:46, R=E9mi Despr=E9s wrote: > if in charge of of an SIIT (which I am not either), I would ensure =20 > that rather than discarding IPv4 zero-checksum datagrams it forwards =20= > them with its zero checksum. That's pointless, because the IPv6 spec, against which implementations =20= have been heavily tested, reject such packets. There is really no substitute for doing the right thing. From remi.despres@free.fr Tue Aug 4 06:29:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D153A699F; Tue, 4 Aug 2009 06:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U1GeWHQFLlW; Tue, 4 Aug 2009 06:29:35 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 610113A6CA4; Tue, 4 Aug 2009 06:29:23 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 35EFDE080A1; Tue, 4 Aug 2009 15:27:49 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id D43A7E08056; Tue, 4 Aug 2009 15:27:46 +0200 (CEST) In-Reply-To: <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6C244552-B655-4947-AF1E-4022D5228846@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 4 Aug 2009 15:27:42 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 13:29:36 -0000 Le 4 ao=FBt 09 =E0 13:35, Iljitsch van Beijnum a =E9crit : > On 3 aug 2009, at 17:46, R=E9mi Despr=E9s wrote: > >> if in charge of of an SIIT (which I am not either), I would ensure =20= >> that rather than discarding IPv4 zero-checksum datagrams it =20 >> forwards them with its zero checksum. > > That's pointless, because the IPv6 spec, against which =20 > implementations have been heavily tested, reject such packets. You seem to have missed that the proposal includes a relaxation of =20 the constraint that zero-checksum UDP datagrams MAY be accepted by =20 hosts ion the future, just to avoid unnecessary black holes in case =20 of v4 to v6 translations. Is progress from what is implemented today a taboo? (I hope not.) > There is really no substitute for doing the right thing. Agreed. RD From lars.eggert@nokia.com Tue Aug 4 07:31:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70FE3A6A75 for ; Tue, 4 Aug 2009 07:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lolLxFPqSig2 for ; Tue, 4 Aug 2009 07:31:05 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 8E9713A7067 for ; Tue, 4 Aug 2009 07:31:04 -0700 (PDT) Received: from [10.180.41.51] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n74EUjAW057443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Aug 2009 17:30:45 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6C244552-B655-4947-AF1E-4022D5228846@free.fr> Content-Type: multipart/signed; boundary=Apple-Mail-20-506095468; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 17:30:34 +0300 References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Tue, 04 Aug 2009 17:30:46 +0300 (EEST) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 14:31:05 -0000 --Apple-Mail-20-506095468 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi, On 2009-8-4, at 16:27, R=E9mi Despr=E9s wrote: > You seem to have missed that the proposal includes a relaxation of > the constraint that zero-checksum UDP datagrams MAY be accepted by > hosts ion the future, just to avoid unnecessary black holes in case > of v4 to v6 translations. isn't it a non-starter for a translation based *transition* mechanism =20= to depend on host changes? Lars= --Apple-Mail-20-506095468 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA4MDQxNDMwMzVaMCMGCSqGSIb3DQEJBDEWBBS0uMgTtYYFiBuh lIew7jKYbqg4rzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEAPMEeBqmNYniq2qv3xd+olpYOUoqPKH5Mi9Dn+rDVZmMIEVaOo3rW 43/7KA1BpdozF1M2CJAp4xtpp0e3ppNNhsi5YdCEsk+CytGHaloUR4uGXVzZ9sJ0RyjrXZPE5k7R xK6sHrCtImJL2f6K9HZkspsuly5rfyTIwEnl+vQmrOi4FMPdmWwueRGdaLICwGTiz659ryT6BF3T WBNTry8zu5ZDxCzu57vpkGtPLPMYUBaOUzS17Y8sscVipFddGl9NWNm7Mgy249uQOU0S/HNTHMdt /w41TJqP7W8yJPnOiaWQMlt7w1Hr+R58KYT3vHAzV6l/g0gtvYh/ys1Vm2vWEAAAAAAAAA== --Apple-Mail-20-506095468-- From remi.despres@free.fr Tue Aug 4 07:49:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9133A7049; Tue, 4 Aug 2009 07:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfuuwMhoBl3J; Tue, 4 Aug 2009 07:49:35 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id D574A3A6BA8; Tue, 4 Aug 2009 07:49:33 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id F1413E080E6; Tue, 4 Aug 2009 16:49:29 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 98AC6E0809D; Tue, 4 Aug 2009 16:49:26 +0200 (CEST) In-Reply-To: References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <030FFF85-B4A7-4AB3-AE56-C2B27A5BF5F8@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 4 Aug 2009 16:49:25 +0200 To: Lars Eggert X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 14:49:36 -0000 Le 4 ao=FBt 09 =E0 16:30, Lars Eggert a =E9crit : > Hi, > > On 2009-8-4, at 16:27, R=E9mi Despr=E9s wrote: >> You seem to have missed that the proposal includes a relaxation of >> the constraint that zero-checksum UDP datagrams MAY be accepted by >> hosts ion the future, just to avoid unnecessary black holes in case >> of v4 to v6 translations. > > isn't it a non-starter for a translation based *transition* =20 > mechanism to depend on host changes? I don't think so, because it's never too late do do some good without =20= doing any harm. IMHO, translators SHOULD forward zero-checksum datagrams RATHER THAN =20 dropping them. No harm expected. Avoiding to drop them by computing payload checksums is another =20 possible behavior, at least for single fragment datagrams. But it =20 implies to compute payload checksums, which may be considered too =20 expensive and opening a door to DOS attacks. IMHO also, hosts, at their next patch release, SHOULD silently accept =20= zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No =20 harm expected. By doing this, connectivity during the transition period will =20 eventually be improved, possibly before translators are largely =20 deployed. Some people say this transition period is bound to be long. Who knows? Regards, RD= From mohacsi@niif.hu Tue Aug 4 07:55:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AC73A7075; Tue, 4 Aug 2009 07:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfcHGIl1MaFC; Tue, 4 Aug 2009 07:55:54 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id BAA5B3A707D; Tue, 4 Aug 2009 07:55:53 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id E69DC85196; Tue, 4 Aug 2009 16:55:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TLAqry3xlPWG; Tue, 4 Aug 2009 16:55:51 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 762EE85187; Tue, 4 Aug 2009 16:55:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 73E8B85155; Tue, 4 Aug 2009 16:55:51 +0200 (CEST) Date: Tue, 4 Aug 2009 16:55:51 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6C244552-B655-4947-AF1E-4022D5228846@free.fr> Message-ID: References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1838075961-1249397751=:79765" Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 14:55:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1838075961-1249397751=:79765 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 4 Aug 2009, Rmi Desprs wrote: > > Le 4 ao?t 09 ? 13:35, Iljitsch van Beijnum a crit : > >> On 3 aug 2009, at 17:46, Rmi Desprs wrote: >> >>> if in charge of of an SIIT (which I am not either), I would ensure that >>> rather than discarding IPv4 zero-checksum datagrams it forwards them with >>> its zero checksum. >> >> That's pointless, because the IPv6 spec, against which implementations have >> been heavily tested, reject such packets. > > You seem to have missed that the proposal includes a relaxation of the > constraint that zero-checksum UDP datagrams MAY be accepted by hosts ion the > future, just to avoid unnecessary black holes in case of v4 to v6 > translations. > But the translations cannot expect acceptance of zero checksum. So I think it would be better to use other options... > Is progress from what is implemented today a taboo? > (I hope not.) Not taboo, but changing implementation is very painful. Have a look at e.g. RH0 deprecation. You cannot expect that every single IPv6 implementation is follows RFC 5095... Especially in the embedded devices... Best Regards, Janos Mohacsi --0-1838075961-1249397751=:79765-- From mohacsi@niif.hu Tue Aug 4 08:00:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF4128C3A2; Tue, 4 Aug 2009 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsKI+csIotZN; Tue, 4 Aug 2009 08:00:46 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id B02E728C3C9; Tue, 4 Aug 2009 07:59:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.ki.iif.hu (Postfix) with ESMTP id 903FF851C0; Tue, 4 Aug 2009 16:59:56 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mignon.ki.iif.hu Received: from mail.ki.iif.hu ([127.0.0.1]) by localhost (mignon.ki.iif.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cidQEAZuLewS; Tue, 4 Aug 2009 16:59:54 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 01588851D5; Tue, 4 Aug 2009 16:59:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id F30DD85196; Tue, 4 Aug 2009 16:59:53 +0200 (CEST) Date: Tue, 4 Aug 2009 16:59:53 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= In-Reply-To: <030FFF85-B4A7-4AB3-AE56-C2B27A5BF5F8@free.fr> Message-ID: References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> <030FFF85-B4A7-4AB3-AE56-C2B27A5BF5F8@free.fr> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1532461916-1249397993=:79765" Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 15:00:47 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1532461916-1249397993=:79765 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 4 Aug 2009, Rmi Desprs wrote: > > Le 4 ao?t 09 ? 16:30, Lars Eggert a crit : > >> Hi, >> >> On 2009-8-4, at 16:27, Rmi Desprs wrote: >>> You seem to have missed that the proposal includes a relaxation of >>> the constraint that zero-checksum UDP datagrams MAY be accepted by >>> hosts ion the future, just to avoid unnecessary black holes in case >>> of v4 to v6 translations. >> >> isn't it a non-starter for a translation based *transition* mechanism to >> depend on host changes? > > I don't think so, because it's never too late do do some good without doing > any harm. > > IMHO, translators SHOULD forward zero-checksum datagrams RATHER THAN dropping > them. No harm expected. > Avoiding to drop them by computing payload checksums is another possible > behavior, at least for single fragment datagrams. But it implies to compute > payload checksums, which may be considered too expensive and opening a door > to DOS attacks. > > IMHO also, hosts, at their next patch release, SHOULD silently accept > zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No harm > expected. In your previous mail your state MAY instead of SHOULD. Or you are proposing submitting a draft? : "Acceptance of zero checksum IPv6-UDP headers at end-host" Best Regards, Janos Mohacsi --0-1532461916-1249397993=:79765-- From Remi.Denis-Courmont@nokia.com Tue Aug 4 08:01:32 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775323A6BCF; Tue, 4 Aug 2009 08:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSPNLUwp1LQE; Tue, 4 Aug 2009 08:01:31 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 37C483A6A3E; Tue, 4 Aug 2009 08:01:30 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n74F189g003963; Tue, 4 Aug 2009 18:01:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 18:00:37 +0300 Received: from mgw-da01.ext.nokia.com ([147.243.128.24]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 18:00:36 +0300 Received: from leon.remlab.net (esdhcp035210.research.nokia.com [172.21.35.210]) by mgw-da01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n74F0Vbb019776; Tue, 4 Aug 2009 18:00:31 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Devices - Nokia To: behave@ietf.org Date: Tue, 4 Aug 2009 18:00:33 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.29.6; KDE/4.2.2; i686; ; ) References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <030FFF85-B4A7-4AB3-AE56-C2B27A5BF5F8@free.fr> In-Reply-To: <030FFF85-B4A7-4AB3-AE56-C2B27A5BF5F8@free.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908041800.33871.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 04 Aug 2009 15:00:37.0443 (UTC) FILETIME=[534AF130:01CA1514] X-Nokia-AV: Clean Cc: Francis Dupont , 6man 6man Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 15:01:32 -0000 On Tuesday 04 August 2009 17:49:25 ext R=E9mi Despr=E9s wrote: > Le 4 ao=FBt 09 =E0 16:30, Lars Eggert a =E9crit : > > Hi, > > > > On 2009-8-4, at 16:27, R=E9mi Despr=E9s wrote: > >> You seem to have missed that the proposal includes a relaxation of > >> the constraint that zero-checksum UDP datagrams MAY be accepted by > >> hosts ion the future, just to avoid unnecessary black holes in case > >> of v4 to v6 translations. > > > > isn't it a non-starter for a translation based *transition* > > mechanism to depend on host changes? > > I don't think so, because it's never too late do do some good without > doing any harm. > > IMHO, translators SHOULD forward zero-checksum datagrams RATHER THAN > dropping them. No harm expected. "No harm expected"? I find that generating scary-reading false positive in = my=20 system logs is harmful. > IMHO also, hosts, at their next patch release, SHOULD silently accept > zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No > harm expected. That will cause silent software failures when running on a "too old" system= =2E=20 Silent failures are the most harmful kind of failures to me. > By doing this, connectivity during the transition period will > eventually be improved, possibly before translators are largely > deployed. No. By doing this, people will experience odd failure modes and weird error= =20 reports during the long transition period for IPv6 stacks to accept checksu= m- less packets. Harm very much expected. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From remi.despres@free.fr Tue Aug 4 08:29:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5D628C405; Tue, 4 Aug 2009 08:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg4mySYxjX2O; Tue, 4 Aug 2009 08:29:38 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id B1DB028C40D; Tue, 4 Aug 2009 08:28:58 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id ECC6BE08160; Tue, 4 Aug 2009 17:28:38 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id AE92EE08148; Tue, 4 Aug 2009 17:28:35 +0200 (CEST) In-Reply-To: References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 4 Aug 2009 17:28:34 +0200 To: Mohacsi Janos X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 15:29:38 -0000 Le 4 ao=FBt 09 =E0 16:55, Mohacsi Janos a =E9crit : > > > > On Tue, 4 Aug 2009, R=E9mi Despr=E9s wrote: > >> >> Le 4 ao?t 09 ? 13:35, Iljitsch van Beijnum a =E9crit : >> >>> On 3 aug 2009, at 17:46, R=E9mi Despr=E9s wrote: >>>> if in charge of of an SIIT (which I am not either), I would =20 >>>> ensure that rather than discarding IPv4 zero-checksum datagrams =20 >>>> it forwards them with its zero checksum. >>> That's pointless, because the IPv6 spec, against which =20 >>> implementations have been heavily tested, reject such packets. >> >> You seem to have missed that the proposal includes a relaxation of =20= >> the constraint that zero-checksum UDP datagrams MAY be accepted by =20= >> hosts ion the future, just to avoid unnecessary black holes in =20 >> case of v4 to v6 translations. >> > > But the translations cannot expect acceptance of zero checksum. So =20= > I think it would be better to use other options... YES, translators cannot expect that all hosts accept them. But they can expect that at least some host will take advantage of it =20= once upgraded to accept them. The point is what else do you prefer: - Always dropping? - Always computing payload checksums? (Not realistic in practice for =20 multi-segment datagrams) >> Is progress from what is implemented today a taboo? >> (I hope not.) > > Not taboo, but changing implementation is very painful. It depends on the modification. Here it is just that hosts delete the current test that the received =20 IPv6 UDP checksums are zero in order to drop them. A trivial patch. The following sentence of RFC 2460 was clearly not written with the =20 v4 to v6 translation in mind, and could advantageously be deprecated: =20= "IPv6 receivers must discard UDP packets containing a zero checksum, =20 and should log the error." > Have a look at e.g. RH0 deprecation. See previous comment. > You cannot expect that every single IPv6 implementation is follows =20 > RFC 5095... Especially in the embedded devices... There is no need to expect all hosts to accept IPv6 zero-checksums =20 for others to benefit from it. Regards, RD From remi.despres@free.fr Tue Aug 4 08:37:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B66928C44C; Tue, 4 Aug 2009 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVNjWoHaqxV3; Tue, 4 Aug 2009 08:37:22 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id E569828C45B; Tue, 4 Aug 2009 08:34:31 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 22271E080F5; Tue, 4 Aug 2009 17:34:13 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6173DE0812C; Tue, 4 Aug 2009 17:34:09 +0200 (CEST) In-Reply-To: References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> <030FFF85-B4A7-4AB3-AE56-C2B27A5BF5F8@free.fr> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <697B11B8-082D-4B46-B499-66CC04CF7E67@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 4 Aug 2009 17:34:08 +0200 To: Mohacsi Janos X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 15:37:23 -0000 Le 4 ao=FBt 09 =E0 16:59, Mohacsi Janos a =E9crit : > > > > On Tue, 4 Aug 2009, R=E9mi Despr=E9s wrote: > >> >> Le 4 ao?t 09 ? 16:30, Lars Eggert a =E9crit : >> >>> Hi, >>> On 2009-8-4, at 16:27, R=E9mi Despr=E9s wrote: >>>> You seem to have missed that the proposal includes a relaxation of >>>> the constraint that zero-checksum UDP datagrams MAY be accepted by >>>> hosts ion the future, just to avoid unnecessary black holes in case >>>> of v4 to v6 translations. >>> isn't it a non-starter for a translation based *transition* =20 >>> mechanism to depend on host changes? >> >> I don't think so, because it's never too late do do some good =20 >> without doing any harm. >> >> IMHO, translators SHOULD forward zero-checksum datagrams RATHER =20 >> THAN dropping them. No harm expected. >> Avoiding to drop them by computing payload checksums is another =20 >> possible behavior, at least for single fragment datagrams. But it =20 >> implies to compute payload checksums, which may be considered too =20 >> expensive and opening a door to DOS attacks. >> >> IMHO also, hosts, at their next patch release, SHOULD silently =20 >> accept zero-checksum IPv6 datagrams RATHER THAN silently dropping =20 >> them. No harm expected. > > In your previous mail your state MAY instead of SHOULD. True, but here this is a SHOULD "RATHER THAN drop" > Or you are proposing submitting a draft? : > "Acceptance of zero checksum IPv6-UDP headers at end-host" No plan to do this as long as the discussion shows it will be flatly =20 rejected. (So far I received only doubts, objections and criticisms, but not =20 any support.) Regards, RD From remi.despres@free.fr Tue Aug 4 14:09:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5E13A70A1; Tue, 4 Aug 2009 14:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5SL6e6sQ0ny; Tue, 4 Aug 2009 14:09:45 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 7BD883A709D; Tue, 4 Aug 2009 14:09:21 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id A8362E080AC; Tue, 4 Aug 2009 23:09:19 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 53138E080EB; Tue, 4 Aug 2009 23:09:16 +0200 (CEST) In-Reply-To: <200908041800.33871.remi.denis-courmont@nokia.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <030FFF85-B4A7-4AB3-AE56-C2B27A5BF5F8@free.fr> <200908041800.33871.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1B3E0D98-17E7-48EF-8C4A-59455124B183@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 4 Aug 2009 23:09:13 +0200 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= X-Mailer: Apple Mail (2.753.1) Cc: 6man 6man , Francis Dupont , behave@ietf.org Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 21:09:46 -0000 Le 4 ao=FBt 09 =E0 17:00, R=E9mi Denis-Courmont a =E9crit : > On Tuesday 04 August 2009 17:49:25 ext R=E9mi Despr=E9s wrote: >> Le 4 ao=FBt 09 =E0 16:30, Lars Eggert a =E9crit : >>> Hi, >>> >>> On 2009-8-4, at 16:27, R=E9mi Despr=E9s wrote: >>>> You seem to have missed that the proposal includes a relaxation of >>>> the constraint that zero-checksum UDP datagrams MAY be accepted by >>>> hosts ion the future, just to avoid unnecessary black holes in case >>>> of v4 to v6 translations. >>> >>> isn't it a non-starter for a translation based *transition* >>> mechanism to depend on host changes? >> >> I don't think so, because it's never too late do do some good without >> doing any harm. >> >> IMHO, translators SHOULD forward zero-checksum datagrams RATHER THAN >> dropping them. No harm expected. > > "No harm expected"? I find that generating scary-reading false =20 > positive in my > system logs is harmful. I don't get the point about "scary-reading false positive". On the other hand, I still believe what I wrote yesterday is valid: *If a host may receive receive a zero-checksum UDP datagram destined =20 to another host, this is acceptable because: - Probability of this happening is very low (with link layer =20 checksums etc.). - It is even more UNLIKELY that the source address and the two ports =20 of the datagram match those of an existing connection (connection =20 where, in addition, such datagrams must be accepted). - If this nevertheless happens, the harm must be limited because of =20 the application nature. (For example, an application that accepts =20 queries in unchecked datagrams may receive an extra query without =20 significant consequence).* > >> IMHO also, hosts, at their next patch release, SHOULD silently accept >> zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No >> harm expected. > > That will cause silent software failures when running on a "too =20 > old" system. *IPv4 compatible applications should have no problem with UDP zero-=20 checksums*, or I am mistaken? > > Silent failures are the most harmful kind of failures to me. And to me too, but I don't see any silent "failure" here. > >> By doing this, connectivity during the transition period will >> eventually be improved, possibly before translators are largely >> deployed. > > No. By doing this, people will experience odd failure modes and =20 > weird error > reports during the long transition period for IPv6 stacks to accept =20= > checksum- > less packets. If you could prove your assertion, I would reconsider mines =20 (sentences between *s . > Harm very much expected. An example would be helpful to understand what you fear. Regards, RD From dthaler@microsoft.com Tue Aug 4 15:04:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8183A69ED for ; Tue, 4 Aug 2009 15:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO1Ta3AQzZTF for ; Tue, 4 Aug 2009 15:04:37 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B57CF3A6E8C for ; Tue, 4 Aug 2009 15:04:21 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Tue, 4 Aug 2009 15:04:24 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.621.7; Tue, 4 Aug 2009 15:04:23 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Tue, 4 Aug 2009 15:04:21 -0700 From: Dave Thaler To: Behave WG Thread-Topic: Comments on draft-wing-behave-learn-prefix-03 Thread-Index: AcoJjGe49Yu0DIU8Q6u4PhqaeS+YigLwAbIQ Date: Tue, 4 Aug 2009 22:04:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 22:04:38 -0000 At IETF, Dan asked WG participants to comment on the choice of mechanism, between DNS, DHCP, and RAs. I've done a bit of research and I'd like to no= w provide my recommendation, which is: DHCP. Rationale: 1) Changing Windows host stacks is not required. Windows provides a public API to get any new DHCP option (e.g., see http://msdn.microsoft.com/en-us/library/aa363345(VS.85).aspx for DHCPv4 = and http://msdn.microsoft.com/en-us/library/aa363327(VS.85).aspx for DHCPv6)= . That means it's just a tool or daemon that anyone could write, and in fact it's simpler to write than an RA solution, and either simpler or about the same as a DNS solution). 2) Changing DHCP server code is not required. DHCP servers I'm aware of (including Windows and ISC's - see http://node1.yo-linux.com/cgi-bin/man2html?cgi_command=3Ddhcp-options) allow an administrator to enter arbitrary options (e.g., in hex). That means a human can already do it with some effort, and it's straightforward to make a user-friendly tool to do it. This is simpler than a RA solution, and about the same as a DNS solution. 3) DHCP is the standard general-purpose mechanism for configuring hosts with information that the local router isn't authoritative for, which is the scenario here. Hence it's more appropriate than either DNS or RAs, and is consistent with RFC 5505 principles. Also routers, DHCP servers, and DNS servers may be managed by different people in many enterprises, and it's the DHCP server administrator that does host configuration. 4) If there are folks (not me) that really believe in RA configuration for information that the local router isn't authoritative for, there's already interest in defining an RA option that can contain DHCP options so you don't have to define RA options for all of them. So anyone arguing for RAs should be happy here too. -Dave From xuxh@huawei.com Tue Aug 4 18:24:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6A03A712C for ; Tue, 4 Aug 2009 18:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[AWL=0.839, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPtajrdpmXL4 for ; Tue, 4 Aug 2009 18:24:35 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C4F303A6D2B for ; Tue, 4 Aug 2009 18:23:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNV00HG7QJCWT@szxga03-in.huawei.com> for behave@ietf.org; Wed, 05 Aug 2009 09:23:36 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNV0005BQJBZB@szxga03-in.huawei.com> for behave@ietf.org; Wed, 05 Aug 2009 09:23:36 +0800 (CST) Date: Wed, 05 Aug 2009 09:23:35 +0800 From: Xu Xiaohu In-reply-to: To: 'Dave Thaler' , 'Behave WG' Message-id: <001f01ca156b$5aaad6f0$5e0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcoJjGe49Yu0DIU8Q6u4PhqaeS+YigLwAbIQAAecLAA= Subject: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 01:24:36 -0000 Hi Dave, > 4) If there are folks (not me) that really believe in RA configuration > for information that the local router isn't authoritative for, > there's already interest in defining an RA option that can contain > DHCP options so you don't have to define RA options for > all of them. Defining an RA option that can contains DHCP options directly seems a good idea. Could you please provide any detailed clues? Thanks, Xiaohu From Remi.Denis-Courmont@nokia.com Tue Aug 4 23:31:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C273028C4CB; Tue, 4 Aug 2009 23:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlxrfIKEUPwe; Tue, 4 Aug 2009 23:31:06 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 94D9628C4C4; Tue, 4 Aug 2009 23:31:05 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n756T8hV006639; Wed, 5 Aug 2009 09:29:29 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 09:29:18 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 09:29:16 +0300 Received: from leon.remlab.net (esdhcp034203.research.nokia.com [172.21.34.203]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n756TDlg022332; Wed, 5 Aug 2009 09:29:13 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Devices - Nokia To: ext =?iso-8859-1?q?R=E9mi_Despr=E9s?= Date: Wed, 5 Aug 2009 09:29:19 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.29.6; KDE/4.2.2; i686; ; ) References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200908041800.33871.remi.denis-courmont@nokia.com> <1B3E0D98-17E7-48EF-8C4A-59455124B183@free.fr> In-Reply-To: <1B3E0D98-17E7-48EF-8C4A-59455124B183@free.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908050929.19846.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 05 Aug 2009 06:29:16.0801 (UTC) FILETIME=[0E9E3F10:01CA1596] X-Nokia-AV: Clean Cc: 6man 6man , Francis Dupont , "behave@ietf.org" Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 06:31:06 -0000 On Wednesday 05 August 2009 00:09:13 ext R=E9mi Despr=E9s wrote: > > "No harm expected"? I find that generating scary-reading false > > positive in my > > system logs is harmful. > > I don't get the point about "scary-reading false positive". As already mentioned (several times?), some operating systems log errors wh= en=20 they receive packets with invalid checksums. The rationale is that some pie= ce=20 of hardware might be defective, or whatever. > >> IMHO also, hosts, at their next patch release, SHOULD silently accept > >> zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No > >> harm expected. > > > > That will cause silent software failures when running on a "too > > old" system. > > *IPv4 compatible applications should have no problem with UDP zero- > checksums*, or I am mistaken? It will break silently when an *IPv6* application is run on a system that h= as=20 not been updated to accept zero-checksum. The system will drop the packet, = and=20 the application will mysteriously not receive anything. > > Silent failures are the most harmful kind of failures to me. > > And to me too, but I don't see any silent "failure" here. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From remi.despres@free.fr Wed Aug 5 00:59:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C9B3A6E10; Wed, 5 Aug 2009 00:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTkRRhugPlHR; Wed, 5 Aug 2009 00:59:39 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id B673028C512; Wed, 5 Aug 2009 00:59:05 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0CDEEE0812E; Wed, 5 Aug 2009 09:59:02 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id DBBD3E0813A; Wed, 5 Aug 2009 09:58:59 +0200 (CEST) In-Reply-To: <200908050929.19846.remi.denis-courmont@nokia.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200908041800.33871.remi.denis-courmont@nokia.com> <1B3E0D98-17E7-48EF-8C4A-59455124B183@free.fr> <200908050929.19846.remi.denis-courmont@nokia.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0233509C-0451-499D-A01E-BF95777B9EEC@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 5 Aug 2009 09:58:58 +0200 To: =?ISO-8859-1?Q?"R=E9mi_Denis-Courmont"?= X-Mailer: Apple Mail (2.753.1) Cc: 6man 6man , Francis Dupont , "behave@ietf.org" Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 07:59:40 -0000 Le 5 ao=FBt 09 =E0 08:29, R=E9mi Denis-Courmont a =E9crit : > On Wednesday 05 August 2009 00:09:13 ext R=E9mi Despr=E9s wrote: >>> "No harm expected"? I find that generating scary-reading false >>> positive in my >>> system logs is harmful. >> >> I don't get the point about "scary-reading false positive". > > As already mentioned (several times?), some operating systems log =20 > errors when > they receive packets with invalid checksums. Right. They do what RFC 2460 says they should: "IPv6 receivers must discard =20 UDP packets containing a zero checksum, and should log the error". (You don't need to repeat it once more ;-)) But if *received* UDP zero checksums are no longer considered as =20 errors in IPv6 (the proposal), I don't see in what it is relevant to =20 note that "some operating systems log errors when they receive =20 packets with invalid checksums" . > The rationale is that some piece > of hardware might be defective, or whatever. For this, non-zero checksums are available. (Translators don't change them to zero.) > >>>> IMHO also, hosts, at their next patch release, SHOULD silently =20 >>>> accept >>>> zero-checksum IPv6 datagrams RATHER THAN silently dropping them. No >>>> harm expected. >>> >>> That will cause silent software failures when running on a "too >>> old" system. >> >> *IPv4 compatible applications should have no problem with UDP zero- >> checksums*, or I am mistaken? > > It will break silently when an *IPv6* application is run on a =20 > system that has > not been updated to accept zero-checksum. The system will drop the =20 > packet, and > the application will mysteriously not receive anything. My proposal is precisely to AVOID these mysterious blackholes (in =20 systems that are patched before translators get largely used). But maybe you have another proposal to have the same result. If yes, could you tell what it is? >>> Silent failures are the most harmful kind of failures to me. >> >> And to me too, but I don't see any silent "failure" here. Regards, RD > > --=20 > R=E9mi Denis-Courmont > Nokia Devices R&D, Maemo Software, Helsinki > From iljitsch@muada.com Wed Aug 5 03:57:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D598B3A68A6 for ; Wed, 5 Aug 2009 03:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcLeN0NZLfVn for ; Wed, 5 Aug 2009 03:57:30 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D590F3A71BD for ; Wed, 5 Aug 2009 03:57:29 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n75Av8cs050331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Aug 2009 12:57:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <971D4C0D-8CA6-47B2-8605-007DB3EECB46@muada.com> From: Iljitsch van Beijnum To: Behave WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 12:57:26 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [BEHAVE] NAT64 MTU/fragmentation text X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 10:57:30 -0000 Hi, I don't think anyone introduced any specific ways in which the NAT64 MTU and fragmetation handling could be improved. So please speak up now. Remember: there are basically three options to handle PMTUD and fragmentation: 1. RFC 2460/2765 -> possibility of a black hole 2. Current draft text -> completely different from 1. 3. Middle ground -> changes to RFC 2460/2765 to avoid the black hole I'm assuming everyone agrees with our identification field handling. Note that we currently handle PMTUD on the IPv4 side (where IPv4 MTUs are discovered) are handled by relaying the "too big" messages to the v6 host, but in the other direction the proxy handles the PMTUD locally and doesn't propagate IPv6 too big messages to the IPv4 side (although it may generate too big messages itself). Iljitsch From iljitsch@muada.com Wed Aug 5 07:10:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4AD3A71BF for ; Wed, 5 Aug 2009 07:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8JxW-A1qM0m for ; Wed, 5 Aug 2009 07:09:59 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 60D733A71D0 for ; Wed, 5 Aug 2009 07:09:54 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n75E9VJd051434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 16:09:32 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <931157AA-67A4-4F60-8B32-B930A9AA814C@muada.com> From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6C244552-B655-4947-AF1E-4022D5228846@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 16:09:48 +0200 References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> X-Mailer: Apple Mail (2.935.3) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 14:10:00 -0000 On 4 aug 2009, at 15:27, R=E9mi Despr=E9s wrote: >> That's pointless, because the IPv6 spec, against which =20 >> implementations have been heavily tested, reject such packets. > You seem to have missed that the proposal includes a relaxation of =20 > the constraint that zero-checksum UDP datagrams MAY be accepted by =20 > hosts ion the future, just to avoid unnecessary black holes in case =20= > of v4 to v6 translations. Although actual IPv6 packets flowing over the internet aren't as =20 numerous as their IPv4 counterparts and at least "legacy" IPv6 stuff =20 can't be as old as the oldest IPv4 stuff, we still have a very large =20 installed IPv6 base out there that isn't going to adapt to modifying =20 standards at the drop of a hat. If you send UDP packets with 0 checksums to IPv6 hosts, expect many of =20= them to reject those packets for a very long time, at the very least 5 =20= years. > Is progress from what is implemented today a taboo? > (I hope not.) It's not taboo, just very hard. Apple and Microsoft aren't =20 particularly quick with building in updates to the network stack, and =20= after they've done that, it can take a long time for holdouts to =20 upgrade. This is much harder than updating applications from competing =20= vendors running in user space. But nobody is stopping you from coming up with a new UDP-like =20 encapsulation that doesn't have a checksum.= From remi.despres@free.fr Wed Aug 5 10:20:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929D03A6768; Wed, 5 Aug 2009 10:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6decAYAXJqY; Wed, 5 Aug 2009 10:20:08 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id BDA5C28C5D2; Wed, 5 Aug 2009 10:18:58 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 91EA5E0811B; Wed, 5 Aug 2009 19:18:53 +0200 (CEST) Received: from [192.168.0.15] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 68CD0E08115; Wed, 5 Aug 2009 19:18:51 +0200 (CEST) In-Reply-To: <931157AA-67A4-4F60-8B32-B930A9AA814C@muada.com> References: <75cb24520907280114w1c543206u329ea842d6f46f8c@mail.gmail.com> <200907280853.n6S8rsfI049268@givry.fdupont.fr> <75cb24520907280203h4d5acc64xa0aa3603918f6b3b@mail.gmail.com> <4A6F8C6C.9070405@gmail.com> <4A70CB3D.4080807@gmail.com> <6B55F0F93C3E9D45AF283313B8D342BA043E9283@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <33FE6799-3D0B-4C44-B7B0-E77F8C59AEDF@free.fr> <7076A329-DA78-45CD-8A53-D3C43DC8D66E@nokia.com> <3E534685-6BC2-4D4C-A551-4A6F78D95C75@free.fr> <37540EE6-37BE-4CB6-9060-F1AEB6EC3CD9@muada.com> <6C244552-B655-4947-AF1E-4022D5228846@free.fr> <931157AA-67A4-4F60-8B32-B930A9AA814C@muada.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <65FB0AB1-3340-475C-BFE4-BF9E5849E4C2@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 5 Aug 2009 19:18:49 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.753.1) Cc: Francis Dupont , 6man 6man , Benny Amorsen , Behave WG Subject: Re: [BEHAVE] UDP zero checksums and v4 to v6 translators X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 17:20:09 -0000 Le 5 ao=FBt 09 =E0 16:09, Iljitsch van Beijnum a =E9crit : > On 4 aug 2009, at 15:27, R=E9mi Despr=E9s wrote: > >>> That's pointless, because the IPv6 spec, against which =20 >>> implementations have been heavily tested, reject such packets. > >> You seem to have missed that the proposal includes a relaxation of =20= >> the constraint that zero-checksum UDP datagrams MAY be accepted by =20= >> hosts ion the future, just to avoid unnecessary black holes in =20 >> case of v4 to v6 translations. > > Although actual IPv6 packets flowing over the internet aren't as =20 > numerous as their IPv4 counterparts and at least "legacy" IPv6 =20 > stuff can't be as old as the oldest IPv4 stuff, we still have a =20 > very large installed IPv6 base out there that isn't going to adapt =20 > to modifying standards at the drop of a hat. Never thought they were to adapt this way. > If you send UDP packets with 0 checksums to IPv6 hosts, expect many =20= > of them to reject those packets for a very long time, at the very =20 > least 5 years. Too bad for these "many", but there is nothing vital here anyway. Besides, if it takes 5 years to update IPv6 stacks; it's likely that =20 the coexistence period will last much longer. Then, preventing blackholes in v4 to v6 translation will serve its =20 purpose for quite some time. > >> Is progress from what is implemented today a taboo? >> (I hope not.) > > It's not taboo, just very hard. Apple and Microsoft aren't =20 > particularly quick with building in updates to the network stack, =20 > and after they've done that, it can take a long time for holdouts =20 > to upgrade. This is much harder than updating applications from =20 > competing vendors running in user space. If we would only work on easy things, we would miss many useful =20 opportunities, right? > But nobody is stopping you from coming up with a new UDP-like =20 > encapsulation that doesn't have a checksum. You are the father of this idea and, as far as I am concerned, should =20= remain so. My point is about translated UDP in general, not focused on to tunnels. RD= From root@core3.amsl.com Wed Aug 5 11:30:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0F39028C627; Wed, 5 Aug 2009 11:30:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090805183002.0F39028C627@core3.amsl.com> Date: Wed, 5 Aug 2009 11:30:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] BEHAVE interim teleconference calls X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:30:02 -0000 As announced at last week's BEHAVE meeting, BEHAVE will be using WebEx and PSTN conferencing for the following interim meetings to discuss 6/4 translation and advance those documents: Wednesday, August 19, 7am-9am Pacific Time Wednesday, September 16, 7am-9am Pacific Time Wednesday, October 21, 7am-9am Pacific Time Per http://www.ietf.org/meeting/cutoff-dates.html#76, the cut-off for revised I-Ds is October 26. Agendas WebEx URL and PSTN dial-in information will be published on BEHAVE's wiki at http://trac.tools.ietf.org/wg/behave/trac/wiki From jyrki.soini@teliasonera.com Thu Aug 6 00:01:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86693A69CA for ; Thu, 6 Aug 2009 00:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IpsxTg1sMuV for ; Thu, 6 Aug 2009 00:01:38 -0700 (PDT) Received: from roof.dave.sonera.fi (roof.dave.sonera.fi [131.177.130.23]) by core3.amsl.com (Postfix) with ESMTP id C2F443A698B for ; Thu, 6 Aug 2009 00:01:37 -0700 (PDT) Received: from roof.dave.sonera.fi (localhost [127.0.0.1]) by roof.dave.sonera.fi (Sendmail) with ESMTP id n7671aOn023009 for ; Thu, 6 Aug 2009 10:01:37 +0300 (EEST) Received: from [131.177.116.209] (ws909.secureuser.sonera.fi [131.177.116.209]) by roof.dave.sonera.fi (Sendmail) with ESMTP id n7671aSJ023006 for ; Thu, 6 Aug 2009 10:01:36 +0300 (EEST) Message-ID: <4A7A7FCF.3070606@teliasonera.com> Date: Thu, 06 Aug 2009 10:01:35 +0300 From: Jyrki Soini User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: behave@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 07:01:38 -0000 Should DNS64 draft say something specific on how to handle multicast IP addresses? -- Jyrki Soini From timbaldwin@fastmail.co.uk Thu Aug 6 07:17:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DC63A6D60 for ; Thu, 6 Aug 2009 07:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nvb9V5JPnmT8 for ; Thu, 6 Aug 2009 07:17:55 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by core3.amsl.com (Postfix) with ESMTP id DF1313A6AC5 for ; Thu, 6 Aug 2009 07:17:55 -0700 (PDT) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 65B7017E0; Thu, 6 Aug 2009 10:17:58 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 06 Aug 2009 10:17:58 -0400 X-Sasl-enc: KNdngY5DHfSi5zlf8B9xh8wxEg4uWiq410ruo8/AjDsA 1249568278 Received: from [10.211.92.8] (i-195-137-1-136.freedom2surf.net [195.137.1.136]) by mail.messagingengine.com (Postfix) with ESMTPSA id CBFAD3511; Thu, 6 Aug 2009 10:17:57 -0400 (EDT) Message-ID: <4A7AE641.9090106@fastmail.co.uk> Date: Thu, 06 Aug 2009 15:18:41 +0100 From: Timothy Baldwin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Andrew Sullivan References: <200907280735.n6S7ZIJv001883@drugs.dv.isc.org> <20090728091805.GB5567@shinkuro.com> <200907280947.n6S9lpFH004793@drugs.dv.isc.org> <20090728105037.GD6181@shinkuro.com> <200907281059.n6SAxBfP002154@drugs.dv.isc.org> <20090728154755.GH6181@shinkuro.com> <200907282030.n6SKTp2T003501@drugs.dv.isc.org> <20090731201043.GD14838@shinkuro.com> <4A736340.4060305@fastmail.co.uk> <20090731214558.GG14838@shinkuro.com> In-Reply-To: <20090731214558.GG14838@shinkuro.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-dns64-00 Additional section processing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 14:17:59 -0000 Andrew Sullivan wrote: > On Fri, Jul 31, 2009 at 10:33:52PM +0100, Timothy Baldwin wrote: > > >>> 1. "We don't care. Don't run a DNS server that offers recursion >>> and performs caching behind a DNS64, period." I think this won't >>> really work, because we have no way of knowing how many such >>> resolvers there are out there, and the whole point of this effort >>> is to reduce the need to upgrade all the deployed systems >>> (particularly, all the customer equipment) or to know exactly what >>> equipment lies where in the network. >>> >>> >> But one can be reasonably certain many of them are IPv4 only, >> > > I think I don't understand this part of your comment, which is why the > rest of it is opaque to me. Many of _what_ are IPv4 only? The recursive DNS servers that you describe as "out there". > Do you > mean that the target hosts are v4 only? If so, then yes, that's > exactly the scenario we're trying to help, where one host is on a v6 > only network and another is on a v4 only network. > I was referring to v4 hosts on the proposed v6 only network. Obviously one must ensure that the nodes on a v6 only network are not v4 only, it would not be much extra work to ensure they are not configured to use problematic DNS servers. As for existing v6 only networks for which connectivity to v4 hosts is wanted - do many exist? For existing v6 only hosts in a existing dual-stack network, there may be a problem if these are configured by RAs or DHCPv6. From aeh@db.org Fri Aug 7 10:00:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B3B3A6CF5 for ; Fri, 7 Aug 2009 10:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qZkUj6Wblvu for ; Fri, 7 Aug 2009 10:00:47 -0700 (PDT) Received: from get-mta-out02.get.basefarm.net (smtp.getmail.no [84.208.15.66]) by core3.amsl.com (Postfix) with ESMTP id 6920F3A6F6B for ; Fri, 7 Aug 2009 10:00:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from mx.getmail.no ([10.5.16.4]) by get-mta-out02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KO00069JN9BA610@get-mta-out02.get.basefarm.net> for behave@ietf.org; Fri, 07 Aug 2009 19:00:47 +0200 (MEST) Received: from [10.0.0.32] ([84.215.125.199]) by get-mta-in02.get.basefarm.net (Sun Java(tm) System Messaging Server 7.0-0.04 64bit (built Jun 20 2008)) with ESMTP id <0KO000BBUN876310@get-mta-in02.get.basefarm.net> for behave@ietf.org; Fri, 07 Aug 2009 19:00:47 +0200 (MEST) X-PMX-Version: 5.5.3.366731, Antispam-Engine: 2.7.0.366912, Antispam-Data: 2009.8.7.164826 Message-id: <4A7C5D98.6090503@db.org> Date: Fri, 07 Aug 2009 19:00:08 +0200 From: "Alfred E. Heggestad" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) To: Dan Wing References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> In-reply-to: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, behave@ietf.org, 'Behave Chairs' Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 17:00:48 -0000 Dan Wing wrote: > BEHAVE is starting a 3 week working group last call (WGLC), ending August 19, > for > > draft-ietf-behave-turn-tcp-04 > "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations" > > Please send technical comments to the BEHAVE list, and editorial comments to > the authors. > Here are my WGLC review comments on draft-ietf-behave-turn-tcp-04: General: The document is well written and easy to read. === Technical === 5.2. Receiving a Connect Request "Otherwise, the server MUST initiate an outgoing TCP connection. The local endpoint is the relayed transport address associated with the allocation. ..." ---> why does the local endpoint have to be the relayed transport address? is this a technical requirement to make the TURN/TCP protocol work? Normally an outgoing TCP connection using BSD sockets will use a random port as local endpoint. It is possible to use the same port as the TCP socket is listening on, but will require that things are initialized in the correct order. You should check that this does cause problems for implementors (ref: ICE tcp-SO discussion) 5.4. Receiving a ConnectionBind Request ---> 5th paragraph: "...Connect or Listen request..." I think the "Listen" request is not defined anymore ... === Editorial === Abstract, line 2: "to allows a" --> "to allow a" - some of the text in the abstract is bold in the HTML version last line: "STUN Server" --> "TURN Server" 1. Introduction: "It also allows the client to initiate connections from that allocation to peers" would like to suggest instead: "It also allows the client to initiate outgoing TCP connections from that allocation to peers" ^^^^^^^^^^^^ ", and accept connection requests from peers made towards that allocation" would like to suggest instead: ", and accept incoming TCP connections from peers made towards that allocation" 4.4 Receiving a Connection: line 12: "..attribute, mirrorred from ..." ^^^^^^^^^ - (typo) - eof - From simon.perreault@viagenie.ca Fri Aug 7 13:18:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFC33A6D73 for ; Fri, 7 Aug 2009 13:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS7+OPxJB8UY for ; Fri, 7 Aug 2009 13:18:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id EBF203A68C5 for ; Fri, 7 Aug 2009 13:18:10 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 61A1D29E15E8; Fri, 7 Aug 2009 16:18:10 -0400 (EDT) Message-ID: <4A7C8BF3.3040809@viagenie.ca> Date: Fri, 07 Aug 2009 16:17:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: "Alfred E. Heggestad" References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> <4A7C5D98.6090503@db.org> In-Reply-To: <4A7C5D98.6090503@db.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, behave@ietf.org, 'Behave Chairs' Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 20:18:14 -0000 Le 2009-08-07 13:00, Alfred E. Heggestad a crit : > 5.2. Receiving a Connect Request > > "Otherwise, the server MUST initiate an outgoing TCP connection. The > local endpoint is the relayed transport address associated with the > allocation. ..." > > ---> why does the local endpoint have to be the relayed transport address? > is this a technical requirement to make the TURN/TCP protocol work? > Normally an outgoing TCP connection using BSD sockets will use a > random port as local endpoint. It is possible to use the same port > as the TCP socket is listening on, but will require that things are > initialized in the correct order. You should check that this does > cause problems for implementors (ref: ICE tcp-SO discussion) Here's one case where this is needed: when two TURN servers are talking to each other, the client needs to install a permission on each server for the remote socket. So each client needs to be know in advance where the connection is going to come from. > 5.4. Receiving a ConnectionBind Request > > ---> 5th paragraph: "...Connect or Listen request..." > > I think the "Listen" request is not defined anymore ... Right. Will be removed. > - some of the text in the abstract is bold in the HTML version Yes, this is because the HTML version is generated from the text version by heuristics. It got this part wrong. > last line: "STUN Server" --> "TURN Server" Right. Strange how this was never noticed before... > 1. Introduction: > > "It also allows the client to initiate connections from that allocation > to peers" > > would like to suggest instead: > > "It also allows the client to initiate outgoing TCP connections from > that allocation to peers" > ", and accept connection requests from peers made towards that allocation" > > would like to suggest instead: > > ", and accept incoming TCP connections from peers made towards that > allocation" Sure, why not. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dthaler@microsoft.com Fri Aug 7 13:38:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D785E3A6F3D for ; Fri, 7 Aug 2009 13:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmGZeuXl1-bA for ; Fri, 7 Aug 2009 13:38:33 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 248F23A6B21 for ; Fri, 7 Aug 2009 13:38:33 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 7 Aug 2009 13:38:36 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.621.7; Fri, 7 Aug 2009 13:38:36 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 7 Aug 2009 13:38:35 -0700 From: Dave Thaler To: "draft-ietf-behave-turn-uri@tools.ietf.org" Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 Thread-Index: AcoQ8ov/YM9wzQORRlC6NiHyOFf8mAGqzquQ Date: Fri, 7 Aug 2009 20:35:00 +0000 Message-ID: References: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> In-Reply-To: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_002_E4561B14EE2A3E4E9D478EBFB5416E1B196755TK5EX14MBXW653win_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 07 Aug 2009 13:45:49 -0700 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 20:38:34 -0000 --_002_E4561B14EE2A3E4E9D478EBFB5416E1B196755TK5EX14MBXW653win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached is a copy with my comments. Summary of comments that aren't purely editorial: 1) Why does this diverge from the generic URI syntax in RFC 3986 by omitting // before the host part? 2) The algorithm keep saying convert to "a" TURN transport "as specified above". However, there's nowhere in the doc that actually does so. Page 4 _filters_ the list, but you can end up with multiple (turn/tcp -> TCP and TLS). 3) Is there any ordering constraint on the order in which IP addresses are tried or is RFC 3484 sufficient? 4) Algorithm step 3 is underspecified. It says it recommends "A or AAAA query". In constrast step 2 says "A and AAAA query". Why is step 3 an "or"? I think it should be "and". -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: Thursday, July 30, 2009 1:49 AM > To: behave@ietf.org > Cc: draft-ietf-behave-turn-uri@tools.ietf.org; 'Behave Chairs'; apps- > discuss@ietf.org > Subject: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 > > BEHAVE is starting a 3 week working group last call (WGLC), ending > August 19, > for > > draft-ietf-behave-turn-uri-02 > "Traversal Using Relays around NAT (TURN) Uniform Resource > Identifiers" > > > *** Review by folks familiar with URIs are encouraged. *** > > > Please send technical comments to the BEHAVE list, and editorial > comments to > the authors. > > Thanks, > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --_002_E4561B14EE2A3E4E9D478EBFB5416E1B196755TK5EX14MBXW653win_ Content-Type: application/pdf; name="draft-ietf-behave-turn-uri-02.pdf" Content-Description: draft-ietf-behave-turn-uri-02.pdf Content-Disposition: attachment; filename="draft-ietf-behave-turn-uri-02.pdf"; size=323467; creation-date="Fri, 07 Aug 2009 20:29:11 GMT"; modification-date="Fri, 07 Aug 2009 20:29:12 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDM5IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEyL0tpZHNbIDMgMCBSIDcg MCBSIDkgMCBSIDE1IDAgUiAxNyAwIFIgMjQgMCBSIDI2IDAgUiAyOCAwIFIgMzAgMCBSIDMyIDAg UiAzNCAwIFIgMzYgMCBSXSA+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50 IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0lt YWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50cyA0 IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFi cy9TL1N0cnVjdFBhcmVudHMgMD4+DQplbmRvYmoNCjQgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMzIzMT4+DQpzdHJlYW0NCniczV3db+M2En8PkP9B6MtFRc2IIvVVFAV2N9k2 h9tFrs2iD24fHDvx+prYudhJNv/9kRJnQlrkKvaO7EOBlJVFDTmcL/5myEbH59FPPx1/eHd2EiU/ /xy9PXkXJaySVTQ9PJA8Z6WIqoLJXEY8y1iVRVmVs4JH91eHB9ffHx5Epx/eRZH1FW6+8t/Dg4xl KfSWOWec273/+D6aHx68vTg8OH7Po0IRldHF9eEBjxL1D4/ylCUyyoVgvIgubg8PEj2mJPrl8GB4 FMV/RRf/PDw4Vd3/7RlFSjyKVLI03XgUgngUPGNp3hrFx3ggjq70n1VcHj3pxkI17nXjb9WIdOMP 1Vjoxr1q/K0bM9WY68YU3vkFeunuD7pxp/9E8Dtdg+ZjH3SDwZPzhg2l4oKZ3cpdnm9eBaF6iNAq DMiJ5SFSv+oJPqgJTqFRr/5cNWZNg3YoMhGsqkKj6VICSawESc4Eb43irJm4UYIrkPT5i1DQ8oQn CeOhwVDLAk8kK4PUTmCyI924Bg3YgQLu4qt/Hum/n2AtR6pxDfOspf0GGiOYuV7vSd037kkT/AvR pQkZrSZkqr9o66NHE+bAEOSMZu8S3hlBo7b5S9X4Ed753Xmn/uoE/usePraEtboAB6KXYuz4n/1J 4wcY0DM84bohVOMHeJLqRqIaiW5U/UhNYL26pCYnlpqy9MnuqZ74l8bnG326B/FxJOIjBAiPIFC3 unFpW92a91w1pG7siMu8VP2D8+vickHM5aLaZq1L6lEkTG7Oi4p4FKqf7OTFtxNTmxWeh6hdOE7y 0ZbWJRiIGxDUTyD1M7CeU/jpN5D6m6aX+vMM34hsy7iA2AyNZq0VH1XjDdhKcHBlM7xP8P2PxnmZ N9D5zcD5YXx/C+/8Zisr0q7fGcNP9Ytnti9ANzFzXOoVdF1SB7WVZGpv+TqJaG8tE2LBzFKWeUbR o08iNnmqR5kH5jGxnfF1s9D9WFwvefIYuEqYSAPEZiDiq3qutJTTRNlysaNpplyyJETsEpTzM6yr ccLEY5Ca+I7mK1VQFKC1cswY9a42VQ4jLXc1zYKzJEQMpzijplrWO/YdTVEpaOInFg30T6l6fzw8 SlJywhWTRdCad/gUYrwyk4JlWwyDGLDMhGRtB2t2c/Ze+cEOXhYQBURgSz9D2IHvfHDC/gW1lVeL qCXWO/xOJhLjrVmasXyLtSRGvDKes3wdfI6URgm9w1AaFUXUgUWR177WR9iE0p8hVsTN/5kdT+4A gBMlS4rQGMmjD+USizJEbR2BM0yIWsqzBJW7hOB9Bi+7yFUETxYv7FV/TmGr8N7+/Bx6XMPn683J DbwzBtWee/YPxhjM13YKJpEwg3F8blkF6qgDUBI/izuVjhpcSwqWr+eddqJ0PsLDJhOD+8pHW/tm sKJzRx8XsNh6Md/qxjvVOMfdTaH+q3S2rXNb+qwe/YTT/nlSMxXiaT+1ogGiyiNGTTYtdcLwdZNs CzMx5ierkhVb6BQxKCbLihX70CkvYUTKLdt7D0+uetkvK1lMq9BoyF0Wr1gSpHbiQQfaMJZhS20v nuLuDPIE3tGe5AF83JXD565oEwl2BhTmO6fN5804Zs4S4qJaYyWGtNQeK+EhNneqGDHiK8uElfuI Fb2ETaw4AsnCbNB7W5bGzqrXcGg72Pkz1i1MJWDY1AZerxySP8B3MchBKHbWksh27UQbAJ46jlgH W3fgdhm8Y5Be87GVMz+U81EPQbFQq5Dy0GJ0CiMx8C+LGp7cgzD6CA+bFXPszP0rVjUCM4Zgv5En E2IvnTB9YkdmK/hq/eQSbCLaM5/MfYNdtSQdRXrXdRGiUKIXWgDyGplC9Q8R6ywRI84mSPWvaj3Z thNp9xEOloUse4h2uQrpZRUaSOdCEENwMlMbyS3kgRiCk1LuSR58hPcX7fpH01e066e2ebS7lj3r JZcVGOxqK6v/CIO9AReCW3kX8sEJ6wbiP1+g1y04wNvmncEakrCEF78430D8Af0rde7Y4EMBpnVq NzE2LEXWNjI70W4f4aEHwMGlxbqnS0fCMcjBgi6MECZO5IxB9V2MZQ9W1O6+7IjZAsIeEyOZiOlq jZjpemmP9Sux2gTojJtpdEdDuFVELj2TFzZUjFehxekUTuKMgUwLvSfdg3D6CA9fKrJvYTHdrdKZ vUZuVgFj4RGIq4uE3sXWBt+V4jaGjskuH8awE6eYqoi1KEN8Ik/Jqn1gloeovcYp4jqgEbh2GIVF RE3qgH4vUYRG36lTxAkByUud3t6DTvkID1/Muyu5qAaY/XEssqsP4xiRlIEPosA0b4dFxgwR2teX LTJK0Heeza4vieXq99SWtGXzwUFz6uM7anHLuEbJA/zulDdqzF7tqbaQemrIXh9zKPch9T7CGk+k JVaqDkFin21PgmE1ls23Y+MxOJl7x2TOnR47zpObdFtgij2VrwWofQWSMPZoYAG17ZAV405MVC9t j46h76gP1y1EyoqARrxCMYmBflHx9onEXSiml/CwcQpYx6CjsvrEwLFqHOvGE1j/J4j+1mo2jVE3 WQFj+Y/9L+qvcvhp0o/CBObZk8IEqI2cDdQqXj9eYyF65vcv0CDPaKtYUuahgXaKP3FqQZQpSzdP twlizFcUYk9a6CNslWZt5LaCyGBPLokXnIkA83pABhXHQkv11cOTvztRLYJxT8DDkxgPShlGjYHH mNvE4xS4rdrAx7lR7zpc0mP+MMCrTu0iBvJFLttKvhPt8hHu1cctYysrjADXE/RAyrewteupYCkw 886VJ86diCzT67DxMIhBXiGVOOxFAH2E/88qbwNj7KnyNkDta5W3T7F1QhzP9tX8+QI4w8yGF9Az omk2NRwD68TgbT/HUALzQ9+AWEsd98r4K4eX6Y2DSPWz0Bg7tZIY3RZC9d/COBADgkJZTM8hxnco MtpBPDuBwNQ25XgcFIG12cvWllpj1bMyNOJOxhEjW4JXLNsc2hLE0JbgNTi+B+PuI4yCYwzTc2wB ulOw+xibNrdiaFlpCuN8dsCO7tsHB/CuBkyKoFC2S+Us2HdgobTWOWHrhAGGujP4hpuaw1PMGB25 wM3SQ7WPuqHAOnTKITWSk3CW7yNZ5yU8bKVXrazdvCUmD846LWx5MCk+s7JvWo44IN3tjBNuffST R5TCSR9RsD6YXoY40ykZxCBHWqUs2xxqlMQgR1oKlos9CKiXcDAKfk21TDu/7J7I+g/0GNs93KTZ W9WobfU5PPGdpAlYTytiPwUr/B664h0VeA9PTfkfLzZV/fkXDHEaY6aP/uaxAOs7RY8YAUgLyfJ9 pJ+8hIfN6amNTmHhvRw3sVWfMEMhmdpCsujw2SddIt7H2fwAK1wvjznfq9i6n6utSgvn5bZiTMCx uBnpBq7so7ogMLtOQScGPNI8Y8VebKyPsDluiGYRr1gbt4TY2S4Hz49vY6ebEBfjghUEnT/GBjM7 hsftMBbP/nSjcCb+OI4RKx9Y+UWMZ8lDUG1k/bynr5LXJfkBYlh6cQ0sqe8dIkcQmvq4wCA6tY0Y 10uzXGNKe9A2H2HjVrAychSvV6lhKIweR//05MQnmPVxu25UQ4zqbVV7mV54orxGNJxTVUv/OJ7t IWAgP4bPmyMx9lifY+v8DQJewX1CL+XFgRXqlFBijEu73r2c4/MS9pUXu0VZK3uhMA0WiIkCNws4 Gz7EF/Bj7SgJu89Q7n31wb4NLPnGsbmDJsC9TukhhiZTUbJyc6BWEgN9aVqxqs2NN6j5zhm50Uuw SH06KdEFpIHRdDKFGHZM02SrtSFGnVLO29zYiYHxEd5uU08Nkgud+gyMb+VYF9zluKfNHeQSa13x Dsf6bsezGJEHY6HQY97Gtgv3X8vh+ti2IV5AHPsQW3Cr2XYNrJMhVzZ5pIPcv3UIUl/zBM7Wz+tO XaDG2ZKUVftI83oJD5tAB90VguztbfEIGjfx+qljazs2sA5u4cecG1BRZpEOOuw7EKp7xw9jScyk 5bmRTjsuHDnfGMfrBeNuOOjEFG7tSxMGUNe+VCyvQmvSebc3MejKK8mSfdhnL+HhS9yOW5SAKDp3 gD86MreMEbEcbHzRrtl5OOe63P9ZxVYX7doJNDw3ceNEkAHAg3yLnOch5ncKHzHsqi923eIIREYM iunKPb7FNfvEaAHPC8a34AbxlpBnJUvb2Ml5oye2iFIH0EoayhB5arCqSlgeovUraPoUGugknRNE wduX1x+bS+99tUDovLrvux+8vjDHNzJiK8JLff9ogIOvYYpp9GDc/GMaanrnYH6ndmhbs/SvfmLP IIfaWv0/tPvibA0KZW5kc3RyZWFtDQplbmRvYmoNCjUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0 eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZvbnQvQUJDREVFK0NvdXJpZXIjMjBOZXcvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0 Q2hhciAxMjUvV2lkdGhzIDczOSAwIFI+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PC9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDb3VyaWVyIzIwTmV3L0ZsYWdzIDMyL0l0YWxpY0Fu Z2xlIDAvQXNjZW50IDgzMy9EZXNjZW50IC0xODgvQ2FwSGVpZ2h0IDYxMy9BdmdXaWR0aCA2MDAv TWF4V2lkdGggNzQ0L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDYwL0ZvbnRCQm94 WyAtMTIyIC0xODggNjIzIDYxM10gL0ZvbnRGaWxlMiA3NDAgMCBSPj4NCmVuZG9iag0KNyAwIG9i ag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+ Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg MCA2MTIgNzkyXSAvQ29udGVudHMgOCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJl bmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDE+Pg0KZW5kb2JqDQo4IDAg b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIwMjc+Pg0Kc3RyZWFtDQp4nO1cbW/b NhD+bsD/Qd8WFTPLV70ARYE0ybYMTZolHobB6Ac3L16wxsnipF3//UhFx0kWWcLKyaqTooB7kSwf dffcw+MdpejlUfTq1cuDnf3diL5+Hb3Z3YkoyWUezYYDyRKSiShPiUxkxJQiuYpUnpCURbfnw8HF i+Eg2jvYiaLKr7DyV/4ZDhRRHK6WCSOMVa/+40U0Hw7ejIeDlz+xKNVKZTS+GA5YRPU/FiWcUBkl QhCWRuOr4YCaMdHo5+FgsrUfj8TW3HzcxdnWuRFutVAcOdfCXfw+Gv86HOzpn/9tOHj0YBilhPkG M0JXJknm1bYLNzs1wkVxs1qItBD5hNB5lzA2wu9aODbCIZyyRwoXLFb91bDgPX9ghKkWvsARbgSq BWqEHNkNkgqS5z43RHVtjTjgyHHAJeF85VEI5FEwRXiy8igk8ihoQgRrjGL8gA/98UFD4iNQQYGf ay1cAGx24EidQOYQSgvseJacpJlv2CHjKVzjKX29WN2FCfIosqxpCz3zUGHGdqrHE0XIXki19blb 8WSLGb+TKtvs1yBh+PbaCGdauDfCKZy6hFNzuJzAbyAL1SHiCW0GVFwquuFbj4dCAE2RAZrmzTBZ C0BdiicPU10NoGMguFsjXGnhElBYwPEjCLPqlLmpAMU1tZApoV5bfzuh4B5fKBQy7FCgRPbC1S7F E23s5VA4McKX6oRepAH/Omf/6VKCqz+O9V+HcPga+L64dKyF+ndOHJlwZSzPi6vdHgoBNEcGqL5O 9sLVLsWTLenm6uZa6hrY2/2dEwulJtSOIWtdVPn+HvB/WUtxNyCZkB0B1O2hEEAZRUao4kT1AVCH 3smWauBzD+hyCrnEDUDqfClzwPH5xiW7SUf4dDooCE/kIpuSgqhe8OlSPNHGds7wJtk9NcI98KZZ e93B5F98eSeurMbQF/JKp42Jb9QF557FlXLk1E3HtaLZxkVC2lEkuI0aDAXkOpsSkvSSSjj0TrSt lwOhKEtsQy667YF9GRpnEDVFsOCg8dni0+mgIDyRC7CKK5K4ogQ8UamY45ohUyTzqbcwbZbRwl0E m9CWWJ0BeheA1xK93nrbd3T6cRGAJ3JlXrGEJK4uxZrg6VZv4ekporkWXZVV/74dvV10zYBFF3Gl QOwh2C7hiVwWY5mZgz1mRI2DrKM48AEwEAfYTRaaksTVM1xTHLjV2zhoVtAK+O9p4S2kFX/CqW0j 3MR2SVhS8GmAlE/iSiL8qXaV7cqNIWhmtXG0mwU2Ap4+XATgidx9k3lG0v5o2qPewrNZPytcbld9 c3DXPeS4N/DlZbCWXHz6dXY+Apxew3eu4aprC3o7XUwBno8GbGt4drTVwYuLADyRe28yy0naH3t6 1Ft4NstnHnjeAeF9hycOPH24CMATuR8mM0qyHtnTrd7Cs1k8q8ATuR7Gdb6Y+kZUi4MCo4vvcYAT Bx4ABuIAue0mU0ayPmplTsUTnbMtA/8YgD8Hj9otEhYZdjOYLZaVBbXRUo0Mp7w7etx6zyO0QWhR q6EdIdTtoeCeSeS2m9T/5X3sXHAqnmg+WEboNhDY3wDMgnw+x5UNjAUwZwC8q9huVyzRt2jl/g0o mHWKULeHgghF7rxJpUfTC4e6FE/A5BUn2JnzAoRbEOYAXrsRAcPrOAjFtRnPqWn8eYy26aHgvqtg KCB33qSU7ogEn3ecVrvV1wOCVX1yCLO+3YBZTwg+xXb3xKhSO76ophB247ktjK3A5s+EqX24CMAT ufMmhXJHyZrg6VZfhyev+sRuYL8I4nRUSXzxcPqNwZN1BE8fLgLwRO68SZ4S2kuq61I8WVrh22zh DEBn9+ZuVx1VR6DdfjaF/MJuRpsDpu9a8OZzQ6jbQ0GEIvfEJMtMDtUbgbrVb4PzsI3/8MSoR2tt DXgAWC4WepfA2K4m28hVZvgAgWEY/TPEg2Vs9FxY31LmvTPsZ2E5F0R5tVGY9SIwVMkyHaCIq8Q8 xbeu+9ZXKK82CpQRPTmy8rFEgKywO6Q0Jz2uRZzaLVU1t7FsKIU4b7MrBnEqow9QXiuBrOeuS/7w 3HX5yPzTow9P3AbYA7uBbeb+rEf6cKq3/NHc/rNby6INbcz+j/3Rw8a4sun2iHR7czJx3hU6PbgI wBO5gS1y5n6XxHrg6VFv4el5fO4d4PQdnHobL+/C9LbdsODZCUl7DPJ048ALwEAcIDewRcYJX95P so6aiVNxGQH3gOW/4sqzyD/U0rVtyPRMOcW2Yxa17/TZfHkCCHV7KPi6HeQGtkhFq7f+IHcpRSJb WQO5QySUMtGz8jCQOwFC6iBuYQ3kiq8Q+voW1kAu6wmetXnCWiAv2AXLzSpv5WEgZ/6CUaJaWAM7 w6OMJC2sgTzB8pyb/Gbl14UhsyjPBEnE6sNAZlGeSpK0sAYyi/JEkbSFNZBZtKyGrDwMZBblMm2z l1IisygXGclWn1MkMotynpO8hTWQWZRz2soayCzKGWtlDWwWpZzkq1tDIbMoy6V5Z9bKw0BmUZap Ng0ChcyiTK/kWIuXOSKzKEtSwlpYA5lFmcoIb84pRw9L01Flswn2i3mLipJHPXZNPack8en6JS7f vjQDwe55uIwrzzAs19essHzYvpLnBn6jvtCv7UCzW3iujGC7Obe1pbLUwo9wZPnVuV8ZWXisVpgY 4Si2T3VWdmwUCt93s1r3+MQVBf8BeBYL/g0KZW5kc3RyZWFtDQplbmRvYmoNCjkgMCBvYmoNCjw8 L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDEx IDAgUi9GMyAxMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0g Pj4vTWVkaWFCb3hbIDAgMCA2MTIgNzkyXSAvQ29udGVudHMgMTAgMCBSL0dyb3VwPDwvVHlwZS9H cm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAy Pj4NCmVuZG9iag0KMTAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzk3ND4+ DQpzdHJlYW0NCnicxV1bbxu3En4XoP9A5MlbxPTysrciTdHGSeuiadPYbXEg+MGR5Ms5vtWS4+Tf H87uzpjUklrJpSwUVShqyRmS3wyHM8M12/vAXr3ae//mYJ+lr1+zH/ffsJRXumJnw4EWOS8Vqwqu c81ElvEqY1mV80Kwu+lwcPrNcMDevn/DmNWLaHv5ZzjIeCaxtc4FF8Ju/fc37Ho4+PFoONh7J1hh iGp2dDocCJaa/wTLJU81y5XiomBHV8NBCjyl7KfhYLRzkOyqnWv4mCflzhQKd6ZQ10xNYZ4cs6Nf hoO3pvs/hoN/zYxIUy5CzOxGJ6Z5GaS2j4M9gcJpPVhTYKbAQgX6FpnRQnAVXKOlHFEhLkdSaJ6q EEdHQPJPQ/sjFH5DJqimRtVsJbbXKgR/fw+FE1P4ijUSCqkppFCoIk+PThWvqvCCOdQ6oi0ji7bU XMq1uVCRuRAZl/naXOjIXKQ5V6LDhQAQcAc2B6jmQPHdQeHGFCZQuDeFMf50gT9dxxZ6ZerKEMd9 85bFnbfMtFfrr14emYuy7M6F2UdTBbyNDT8stqIrzOxLP+FWz53jxgjQCWg+0HW3uGfW0LkwhVMs jBv11EVU2+uoAWRkfFUZT4NDi77XVhUvg9T2zSA5zsYUJ+I09qYla+LPNGJplH94fj8hGs5p7T/X Y4/MhGmRlc825DznMkhtjrrzrjEqy51jBPgEZ4NEgizMGT5zQnv8ra2Rx86DZFSAvXaDFhxr5ngj e3xgsH2asYisGYuqq5+fRTP6CActwLEpXDpyfm3b1XNcVFrCCzp/TLD6yBT+hMJHU/gNm84QBneP otSuPiGolrmv2M894uUC+TjDB/eR6UOsOUSCf2HNnYM7YPq+IdgOc9p5cIwP3uF46qYvI6+LqjQ3 58rAwvThsoyNy5TrrezYPsKt2r3vYO4cYUD6YxUdM8Hfp071NaqeOdZc2rsaw8L5hrY3/8inHvlZ NFFIZD470kTaFzB75WjoC5wUspLJjCHtO4sNcNNCBle4D+BVZICbdnoritdHeNRYmXc4/Z9tXHft SsI+KStqPm00sA0Dqu5RxXN8+ASlYYYSdUMqkiTBETTaAEhXXjrKe4rPPCAv08fxkFi11Ut3nMiQ LCueV6E16YOkSCNjMpM82wYkPXRHjyiYhGG3ZPdubbcSrYC2xamzmfp7XcMIWdTNN9jHxNFyY1uw XBYJevSwC2+ybqd2zbVjLvANmQLedelFZWQPc6YVz7YCSx9h6/DubvwTXOIxmnRXXlt18cjS/u6a ArHPHKI07Z2pFDCDqaok/Xt35qv9WI95wUcVaIxEBFcV07wocvO7WSSMRURwBqRLFia697x1dPip HW7I0eGnFv3EnWqeqRC1ekv+wYDxA+7WHx177hZ3fFKHY9S2c6y5QWTXgB5hH+9M4Q0UlClUUMhM oYTCcUIHuKCObmUusrorTPsVUVX/lGVc6hKRnppmkpW8Mp/hsFtk53ymNN+K+eih21qP5KIhi232 uEFZQRVLgcb2fJc8LQIsWrq1Be8tHrEuUG0vcaWu4ml60Zi05uOt+fYrCtF/oPDCJt+2iCzSFahc a/TrqXgyt9gqup6ISW7YEBrcd0Y3Z1VVxVP3Kq14mgXW01rGsqOHgsvYNRhp8aeeRXGkvRmrT9pj ybTMeL7M0pmfnG1GqH2EV7D0Iof6MpHzfDHg+CxKzUfYdwJ5gci6Rxv+GtXbPRqBtyjuLxda7S54 sTl2NkYY1w++9Bxe2poXuBVa/bTk56jMZiFt0927l2g+e+/uPWlv5kzsX5NeTEYO/GZpwfPFUPyz YNJHuA2GwKqe4QYb+/AHqTSpCNHvnf/IAWRdlbx4AgwiR5C1AWWxDRh4CbeHUIp4kJfuqiPcEAyh 5JWg367t7LPjh3Cs+G6w4wa7D7r0dpcGbma2igx4032H6l3LA0K+lxOkM6tbxNZIKZcitBS9UIwc stOGm3Ibu6SX8GidGGzQtdb10y1pQcE1wtuBY94BVsiZ2+LF7tXZ0WN7WqSZpCwPzVV0m7+sk6MC 1Lqhxks0HgLHdJKuMcojzRgJ5pUjs9FlrXE9rjZ/XVmLHIbUheDlNo7ZXsKjR6PrGo8v5EzuBibJ pTj1CwxJJ+l2N45+klhhSFp+ouPqf0h7+0Bq/wRFbJIsRrxnNmek/2+RMgV5XN2xNJQf2xuU8iK0 AL0AjBwm1OafahtxcC/h0QoxOgshbkyRwiMUDKENO7oJaxYP1KJ/DL1ptJHDajpTvFofSjJyHEVr vSUo+QiPdn5ABBE6aNMmvy/l2tRwO7N1mat+upbtUza/tjkZEEs2v4nT/RgJQq8UcSYj48Khs4at u8nQc1VxUYUWpxeckd3ZWmVdGXkWcPoIj3YeEDT3uAHSYtLyMtyBprhYhGRC4c9NP/beSRbyWeJz 0qwBLLszSvcFht5B4Y0pKChUppBBoUys1EnyhC5mpNtQ1RtQzpCGo0Lz3hDctfLp3z1uLZuxNP2M 9ApAZN+nlgV4XbYgAD7CowbBX1DzOn4F9zQFhb9QWmq78kPSdRzuWs72SbKYA/GACpdsT1KGzjHy Gp+ZkwA82LZIICGUCFKoAH4ir8jiCXNRQHyZoZtxMPiXoheKkV2eWpQ83You9hG2Dj1dXUz2wdRZ +aU5Qva32QoQcXZyNxX45BGTQROGuL/C7gmuX51enezSMfV6jwzR6cfZSS6bOYmNxwyAGFiPXjzG dgGnxlLZBhw9dFvLgBben/wVSKac2LB8XGGAAvnOznDN75BOwFolJNFpjMzFuR/jDosXWDNzGLpP rLzcG6dXt7MHuw/S3fdNzWbQ6F2OXjDGDgTAReNyK2j0ELb26W5Mj5bn0lFaM3vBHhwjknz7gSMK ZfJeJsFkCeo+dnaH1JCNGJiGevSu4XiULOb0+g54i/noV7Z8PeL+yisyJJHu9rMpn6h/6L0SEDn+ oCrRvRb8HBLgJTzyBL6mzmJ3DcMusEkCKG3XvX3ThTlF6ZcqQsKSLTyfO5x1j4T+hPQbZ6hdO4LI zxymm7DdRqL0gTXpxWRkP70qJZfbCM96CY9WzylfcnvGupJoWxOkoK5sU5L8Y904rcsLNT/pCAAJ CVnMxP2p80x0j4BQvMhCc9mLpcgud1WoJ732ILLXWOX6KbOhInuNVZYBzhfZkP79lqDs3vYi7+sN AvNr9NRPBbMV4LZ30iJ7M5U2yuEJaxfZp6SUab+VndpH2Pfag/+hpqEtjByv7mVXSqN7n7Shv0PE nJs0B5lv71HX0jMMle7v4VZt4q75+ANpHDxWt5d7u3l9h0nr5YVU3zrn91dP98EHg5xtxIQMLEwv MCN7mJQsV7jv9u+J5bwUuZ+aKwabkQL/KF0w/I5Y+3UFiHUfXgPY7b2L31FAQJLeYvP9BZR7RcpJ ZicWA1myQIeujxw0NS2xHxwp8QXInCtxG4l7rQbBriRE9m0pUfFsG84tL+HR49V08gYtSbijM1LX vdSGqhaX1/VMOXcc6Sc3BazroV0/4Nq9fCRNoX53k0jaW0jHGzFsdQE3yAJz3Yu1yK4rJerUtLXZ iO0/SAXPnzAbkY+MspLwhptFNlTXsD1E+4QQDOD/gs+4iQiUNBVIiHWuta2W2xj7DXwlPBoYfu8q RD5syVLxXK3/drfIhy1ZaJ5vw6vrJdzmxvgRsucH1yHiznpZYltDnk6ypLvuCbpy2caTWliTc8vx KNTc/YgMvcPquvuv9k5Ra/AvYTUMVz/rkyRcBtWkhr/djBoOzHUv1iKfqGWe8eIJkMczKlzIK1XW ftZX+oyhaxS7zDTPqvYyXs91VB35qCkz02AtAeqyFO2Q0YqWjyXf28S6aeR0VfU7B9vjvhFEMw6F lsB7YAje5PYe1qLZEgQ2L2svGvkF076HoWhWhYBU8QACVxCraGZF+/qDZWvmuOZJJ9Ih61ssUADK 896bY2/T7/EZChtTMK6bWv0dnfFWe+2O5Ro+7pvOaPZBe05bbVlTLjR7CF1uZpL9wkyX/2W1qiyq RlUqdtXozrypMHbI5XBwOBw0lbKuLCQ9ZSqMssuLxadMZZHbfZmKMqenDDzB3nqkCHhdJGjqKpte 890m15nqDG0g6+mWj4aCzUYsNW920q3cPfISHoXv+/he5kzKPHCLlyRir+fBWVe//XuzPK24VKFx 9r61N7aNokpebiOe5iW85rUDd53v0S9AF6xrQOzZ2nOOMKK72+4zqynWyIDIJBeh+Yj+OphGywao UY5J9DEWKbyqOkC2F/SRozZSVrzainLzEV4V9JHjaKLiaRXiKPrLnaWqd2M/NQt2i5Jd++6+QfG+ xtlwb7w5IfXJhvS1n/Ve6MY+fsn0SRIUOa4jhdiSBPkIj3ZeoZ/DvYHxOrHCF6/8G8lr26HnXk1+ tR7uFjtzveYk0pSYRtf2L5w+VnFr0zu16vdp5Um5Ibe22S2y4KT3gi5yCEWmkldPwH5k77qoNDiZ 1mYjsncdTqFPyNnOInvXhZFL8YS/PhHZvSzygosn/PmJyO5lkZWwWSyy8YHcN5SqF3s/N2goQ+Rj 7+ZVynM/LbZr9oBc6noP+Pl+Ay+sEaFBnuHpjUKYzpW57imR0RHBqX6Lxsgt9uFeMIVnfsMDAWn/ +jT6KbEzicl80fYutPhnheL8+aL6QuCHxHd9VjW+pLgr0f5pg8BSdLd+0+gXxka196b+ODY1bMIG Wik4Bsusgr8WdQV/6kxxXaCLu/Fp9PXhNGndIoXu9FG/ovSh7Ygo67ovoNxWNGcUreo//SVVAb4V rXKelvhtbKYP9A1+v4TvJSSCtRVZXnGVYVf4raFUN24qzLTLqmndVkjwuGJfuarfstpQar6Mgc2G labiEioaTpsKHEXTFX2rKY2HC6M2rc/NMmPc4B/4PYNsCakqnjGhJNyul5Irs/6PuHA0qOWQWKlx AyrJzCh06YJK1TpcZpnvhQxwy/Xm6srgujBSLerLLxokQAP6q539RAiIokkjdCIFe6ja+TYRndcc rsen8vEJGdEhNv9OpNg5/wrU2eQm0UYQc1AchmE2h9rziyTDiskFPG2UiGEdnrszz58lu2X9hZ0m RV1zk0A2b7aBgbQTrktAjudUaridGiYY8XQ9bXm6MP+P4zOU54B1Pz9/JiIzZrDaOYhPt8gbp6eX cLNYZkkNrK7nMBUnwMoXBpNwzT6az3cAQ2OZm1VT8FtV5gBR9qkBAq4gNKintf6om58BntkePF1/ bG6RjY7vqupPsKAANGDxroUrs5b+HDDczEBdy25P7nAU329CsrQK8bowNWjP/R+oonsPDQplbmRz dHJlYW0NCmVuZG9iag0KMTEgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05h bWUvRjIvQmFzZUZvbnQvQUJDREVFK1RhaG9tYSxCb2xkL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9Gb250RGVzY3JpcHRvciAxMiAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDExNi9XaWR0aHMg NzQxIDAgUj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnRO YW1lL0FCQ0RFRStUYWhvbWEsQm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCAxMDAw L0Rlc2NlbnQgLTIwNy9DYXBIZWlnaHQgNzY1L0F2Z1dpZHRoIDUwNi9NYXhXaWR0aCAyMzIzL0Zv bnRXZWlnaHQgNzAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUwL0ZvbnRCQm94WyAtNjk4IC0yMDcgMTYy NSA3NjVdIC9Gb250RmlsZTIgNzQyIDAgUj4+DQplbmRvYmoNCjEzIDAgb2JqDQo8PC9UeXBlL0Zv bnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YzL0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAxNCAwIFIvRmlyc3RDaGFyIDMyL0xh c3RDaGFyIDEyMS9XaWR0aHMgNzQzIDAgUj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9UeXBlL0Zv bnREZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDYWxpYnJpL0ZsYWdzIDMyL0l0YWxpY0FuZ2xl IDAvQXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MjEvTWF4 V2lkdGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250QkJveFsg LTUwMyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDc0NCAwIFI+Pg0KZW5kb2JqDQoxNSAwIG9i ag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIv RjIgMTEgMCBSL0YzIDEzIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1h Z2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50cyAxNiAwIFIvR3JvdXA8PC9U eXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJl bnRzIDM+Pg0KZW5kb2JqDQoxNiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0 MDEyPj4NCnN0cmVhbQ0KeJztXeuP2zYS/27A/4OQT6uiZsWHXkUQIM22dymaItdscR/cfNj1PuI7 7yNrp21wuP/9SEkzJkXStHepVXEtAji0LHJG4m8enBlyk6/eJs+ff/Xm1evjJHvxIvnm+FWSkVrU ydV0ImhBKp7UJRGFSGiekzpP8rogJU3uL6aTyy+mk+TbN6+SRBuFdqN8nE5ykjPoLQpKKNV7//OL 5GY6+eZkOvnqO5qUkqhITi6nE5pk8h9NCkYykRScE1omJ9fTSaZ4ypK/TSfzo9fpjB/dqI9NWh1d qMa9bDRXLmRjk75PTr6fTr6Vw/9jOnk0MzTLCPUxM4tOTJDKS+0YHvZUNS6bh5WNRDYSXyP0u6tx oho/y8ZPqvEj/IRXmilYHzpquOH9/Y1qnMrGZ7jCVCOTjUw16sjTIDJO6to3DYlJzZIDFlkOmCCM HcwFj8wFzQkrDuZCROYiKwinFhdCgYAYsDmRjZ9V4yfZ+BF+ugUJ8tzzzo31BL4pBbNWjVvZWKnG J5DCJQx/ExmMjAqScd+jhyYgjzsBuezPD4dBEZmLqrLfhbReGVe8LSQ/SRJ5Fkr59pmb8LxVmB/A HCU6rBA/9/vjp+txDT0WMPxp+3slb+408DXcjFcSGHUN3c9Ru96CoVzpunQDPzX3LHReTw07m+gs JK1O7gZbwRgLUNX9h6qkgMadEl7VpKh9cxKCZBkZkmVtC4YJydiIpKSghZuw9fix8O8m9tKAASpa BZwPAKV7A273OpTWgJlF26sPnDV0/QQgvzAGMySvEbi3W4B2+D8HqhcwRjPql3DjBlg8BRlR99wB rO/hnsS45xyoem7syeEw+N8LABb+q9j4z4gYRSW7CM+ld6xPCGquBCbkE8BtYWHiEpC2epCa26FF l4YSjq0PWe59GyEw1JHBIPuJwyFJs8hs5IzkY0DSQXcoJwGheWUAfqnrRnQSTP2J3sJzILgwWLyG xgvZ+BLGeA733MIYG/c9d1t/u4P/C8uJiK4SJfxLz/sPoi9y/CIXnOSjwM9FeN5Oyr5mzpwqRMoS et0ZsCSptlh/bZnKFYxxGwAiqugVEFsbgyGL56kW+rmAK809Z7pre4f4U0J1afgiF/AsaAHQcbmM DctaEFH7JiYIzMgBhZwLsttTHQiXDrpKLcalVckOPlp2TGtfeUAX9Jcj1Wo097H8+tZwIlVA4RX4 n6gNG8X/g2y8U41fUrh7DYJwtyXZQXqz9Rm7Qc5U47PONnrWKGd3MBiKzwKlynY/DDlcgka+GshJ dc5HEPmRg1g5y0kxikp2EZ47Vi+e0OtCn9QLmKu+7u0QaALjFqZ5AwhBta3pux24OsC/MIMQp9BY 6T9tkNdbUMmq639U43UjUYO4BO4JCAIwcvwypwUp+rHcJwGgi/C8nd1z0DOPXh7rPTT3r5v0/+qD oeJbAdxQxSKuTnFUY/12uIwkqbZiu0EA4kOhXl2mmnJE7s+3fkNsv6AmtPZNThCcsWO7WUmKfrrj ScDpIjx/XFyyw8IK5jG0YDfMYghq6Lk2DP2qO6PRF/VSfdWV7xUFIRI58C7qipQPQGrkYKuQTkUZ fBuPJ1aQihZuasOGdhux8DzlSwO3Lx1Id8kHAvTe0NmJpffvDGlYWzK21oXgDgRyAVJ12Tb67uvS YBpHXfgFsmiESTbEVkRnAyzNREky77sOAjtyFFVUGanG8A+ChOevY6/TclK5ycYvq6gzUvhoHQPO 0G3YNDCOXNhBa5LVT/W8lHFSeqmdgXR+AJv4a3slMhM5UxUDT/XIuZRjL7UNrHvuQce8d69Z7nQN uTBcU1RaGGoy9SEudy5BVS5TLX6LvgvejA7vGihfoKeiqVJ3gCv2Kj0jjPreXlALRk4fiJKSaowI lZOw1H3qtas4/Xeq8Uo2uGrUspGrRqXjCdN9C9Al/bCL/GCgdLAhoGFUsJhrccNO34LR/4SrJNuI 4oL7Fow1wvU3fXiv5zvrFdAsgOrS6Bq76I5L65BR33wEC7Ai55GE/K8eI7fpJDxvQzEXMLW2AsLA 4sKpxC5BJa0Qj/t6kWZ+6i7tJ+kRqpeA1+b3a4tFd3kWjqGtqyIDi1WqmMrzYu+3Qthx9BIU+sZg TVtxDgN8N39B4EdOYYmck3oURewiPH9AHt4tCp1B1YXHLhUw6lnsSK2XF6fWRzo95yBysKCuSW5M G1WzlfGa4f/3V66rPzXv90uTH3dnJEKVA09KiZOM8CKTqygoDX+8GGSCsNwHg9iY45l0zr3U7Ji4 ZodnT1oKykvZf8+30vyU54SJqpmrUs5SrohLwa78RfwscrJRCDGS7XQRnrdCimKJxu33VAsVv2l9 ny5hd6I73ij+5+1Ed6KNasjMTmsrBSwY82Za7JLjA6pB+nHPq1SLXy/RQzSyNTsfc5AsoGdOgmYt chpQ8Hwks+YiPO/N8wYshDsR7PGsNDzNtIyx6noFWLkBrGjZXn1U2waqez6jQ4TG9Ez31T4CJu2c S9hez4x6OK2K5J3DFewefD1MFsYzOUFwRk4RClYqD3AEcLoId9GiFUymcqP+DVfMnK6BUjM0ggpx DWNgEvnM6qqFiiN7R9LMc+57zv1i0h1MBTBrps/nqSp/iu3TZU1gy8117DAaq4WKg3uoHcPz4+p/ 0z5/7EUaJ8w7UbEfGZaEPvh3sBg2WMrzQvV/qkeWPbxPjNl53Fb5fqBFrpt+UOFGTnsLWikBG0Hh ugjPWx2JBbYYp0HP8SbVtlfYjqlZWmm6DYaBt5e0/Th0J+eXusBvNxOd6zjZUWN2YRhw1KUY4dY8 3Rl3oG9HGdzpMHWanokJAjN2sl3aq1EcAQfd+XbXxJkBsI8wX1os+CHh6th1E7TKSOl+h3vMZOx6 BbWHvDqcjcjZZV5TeyfxUyDKSRi38muhOlzTmDoJl+l3A7j/lEtpL3UeBwiaAZGqbvAAUbO8rut4 UTMqGCkr39uOPbVUlCT3Unue4k6/2YG7DW50hf8cevX3pnQqB7v2/TNtXYzbDs6Mnxa6/vkVLZB7 2W0Wo/nyGLGPIahIued06uG+DmVtvK8idc52xPsi5255xQgbo4jQSXju221qV6fae1hwWbfP/ij0 aTCrj1WjmMe33ZlTXBSrb89iL+ZkDyWhvjfT97Sepd5wpSbO9qv0inMXIBgiCO55qOCpGJFTw7zk I5lUF+H5IaDrZvYZwOAcVDPCwFwh3KTe0LU7m2tuktG2focNgi1N/WVNv1rCK7Ear7bRGASg3ekx nhkKIjRyDpcXYiSF7CL8UITaBVzP2psP11Z9xe/S3jMtZonL35vUldbRtHcH3gXQeWbg3i62CW// GWR565mYIDAjZwa59Fb4KKrTRbjbn/3Koa7CEHIdwBJSV1r0w+vj2v7FzBVVPxihptlf+2x/7KBj 4Xv1QehFTgByIYEwik50EX7o1mwNDcOs7NzMarA7VIEvHC6GXYV4gIthbq3dKbOHuxjDKF/3S41+ NlKb0/RQC8pb5Jwm57L/A8Q+cqRfZXqsY0meROxdhOdtOfESQKltjnW5BuFikJlrF9u+W3dN04Np Xu+mzH3KWLQ4i7k9z4zDuOPEGMYZ6Ngkz5wEMQlBfhXnq3jefTaFcVVGcmnjaEnklSonknAg+sIj B5o5rUl+UM7AZila0LnDvoul+dFvFhQ9eHJtHu/n3T3bNA8+3AFzHHdum+EyDPYLjBZRY2XexHO3 b/CwyHTwcM5owRCE/gM5NQ5t6eu+wENEWy9zykmZP/whTmFxcGfg1luivE+tLSCgUSm12qRTWNW2 9iuJtlJrfHa3AH8dmpdoPnt7goOHjX4YnFCR/Oabo4Ql3ydyxH8ljbKuaPNmWZ1ct9q7ZO2rrpPV dPJuOmkuFu1FaSu6u9QFJrU779/FmufUxlKHTsBNvMhJVWsE1YW67hGUL1ylnrcE4YJBULvYEoSx NIJGQqDFz14JARHb96ONajj44ODYvl+mjsscw/dzEZ5vc1KPCgfECVh5swAzVzLuMevUGT8k/jdI 1ZFnPoJ4jFzcwWqm1tg2GzCdiI1kgBV+syHayUIyU+WGTDQy8exT9PPt1WH6nme3ExBnqXZ2kdc/ 1CXBOCoOJeoh/uFMi+8ZIbdbYyGWQNdb3T21dxmc4hoNV0GKoaai8q3z6eJvLWvWPV7gBfAfeaXC Kk4KPi7+3Szs3O9jFzI59/e+Sbto1TtAn1HLcgueIu7EXRrTbx9o4zm+I/5pM42/6Z2cAEYi1yux UpDCUlBPYLOdhP+y2aPZbM98BPEYubaFSS+7HFlnuVnYEWH//7ahxomb9kZeLT8wSHzdi4jdwMwj V6GwvFBqewRF6SI8H1oG3ERdqaSDAukec+7dKGkfrqFu7gc2Pea84wM38g1ydpwEqSj9kxQAaeRC FCbKcc62chL+I1vzdfpHKm8ZZhXinpMgJiPXoDBekcqVH31Ci+5mYWdZ3j6KbhbYDd6NgRuI91uy eJRcv3YE9/0Mv2TpNgt6ZzIAqMiVJYzVpB5FybkI/6XkxlVy7jkJYjJyBJ6xbHQl52LBDDUO83c7 Pc/+Z1wm/QDK/elCjT7gBfAfOfXDKHWL4RPi383CX6FG/+QEMBI7HZMxUo9REeok/Ge32/YW953c D1Ko6ZmYIDAj50mo5CYbV3l5WNjPYu4o3nqExXQVb52jMX2oxdQWL/3CYttizqxl1yBH8nrnPwDD yKkYqgLxrioOBwwHOCfcS34IuLtpHWiZ7ahhDMtsRw2HsMxtvHC/d24jL3LShUo7SQ+v1ygih9hp URL6gD98HTmISvNKRTv6bLxFx22zxdEQcugmP8h5/R5afwepu0r7J48YGtxlHJ0281vV+B1sC5bj G0bkR5BurEpvCufx4B1MOFHVEKn219+YamSykalGvYuzMK/YaI4kfwsa4irV8hvN2WSxj2zq9rR6 5sTWw7LT90kyb8oxm4/38kpynkwE5yrwyxlV54zJcQTlKknRlSi2tYuhMYwuUP7IrTHsEn1VOqvK Q5uhkRfZrWjKKPGCdM3VMZGiLRHNVS/BC5JV8G0hX6jSCPB9pb5Xaq9NdyEvasVLNxR+ayg1ndsL TKiTZ1faBdk7gaFY0Xxp6DTtheKx5aP5vlLfWy6b7/h2c/1LQ2Mx7T2v7PtBTjnUgH5Uv+eq6lTx LKeaN3++oVSJ9y1CDN2mBeP36NqCiyVFcwCtAS7e6FZOK9efwVJbMm+vryW+SyndtNmWLpQkCCUF 9dFxSqkyr0yKGs3UQfz10dcpdTnDe3PJXVyqoIaPyZcpZUfn58lGcflhmeZKd0hek8u0lIpDaQjJ 82KVFken90v5uVFsfpb3ZA77/Sg+cwkQ/9vsvRSwWf8D7oqwfA0KZW5kc3RyZWFtDQplbmRvYmoN CjE3IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9G MSA1IDAgUi9GMiAxMSAwIFIvRjMgMTMgMCBSL0Y0IDE5IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0 L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9Db250ZW50 cyAxOCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+ L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDQ+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCA2MDY5Pj4NCnN0cmVhbQ0KeJzdPWtz3DaS31Wl/8DKp+GWhyEefG25 vJXYzp1Sm5TPVnbrSuUPoxnZ0q00UiTZWf/7QwNoDEiihxwNqMxdpSKTGBLdAPrdDTD5/l3y8uX3 v7w+eZPkr14lP755neRZI5vk8/GRZGVWi6SpMlnKhBVF1hRJ0ZRZxZL7i+OjT385Pkre/vI6Sbxe mO3l9+OjIis4vi1LljHmv/3PvyTr46MfT4+Pvv+JJZUCKpPTT8dHLMnVfywpeZbLpBQiY1VyenN8 lANOefIfx0dns5N0LmZr+POY1rMLuLhXF7rlQl08ph+T05+Pj96q7v/r+GhvZFieZ4xCZh4dmMxq EtobHOwCLj7pwaqLRF0k1MXQ76GLU7j4TV28h4tf8SfXopfgYddehy/I33+Bi4W6+IYtHC5ydZHD RRN5GWQusqahliFpQ+vxAY/MB1xmnO+MhYiMBSsyXu6MhYyMRV5mgnWwUGIrF0LhtlT4JElkWqgU RB4GfDa7bZHqibr4hC0vUUTdI/GukW3u4OIWf4JnXjkGuFJ3D9jHCoXaJ/zJibkVPnMOF198WfDF SMh69i8nKgHYH9icINRL7GyNr+o+LlGuJojiBSJ1G3lyheBZRSzr2ezaDM1ie4UDcdj+glLpA1yc xsatLrKcUbgNEX4Rl/AL9b4IsR8hOONORZNnJYXCA5LNLVJ2gsR25VNU0mKDZKO7rU67xYsstk6t c6Axcga3r2MZeR3r+inUVEXGomr6c/EcYjQI+MwYHE7shGWUox8tFT77FHPVevgG6UtbSXdIldf4 oBNmYYH3CWn5Gt/ScBxBrxF8guL8EXu9w5a/Rp483jSZrKjZGyKeOjbx5JncnYSbyFio9+SfQsIh wGczBmuf+UL4BI103fISyfMWyc/T+5YyHzZk7rMBmBXvWkS9QgPgHin3gSZq149jk6RFyysEv8Tu H/1eCU50dswFvnqF43WdedjHVs15xhm1FEOUyPLIpFjwrBivmvVFZP1cZIJEZDTF3CJ65xt5aG3L h5bZOUDmpHnryNzeOdPUma5DBu8LmiDbry7QDr72u+9iFpkqG5nJhiSHAaKMHD0ppMiKw6DKMCZu vZa4TIsWfa56gio2fkwtlHJpg/j5muTsJDZg9UZNAJ4gplSWWUFCe4MM7WyjR8PQkZFQxJDzZxuy spdqEpoTb5dIdF91S2SbjWtL/5lGzIXYMr+PKMfvjUGg/nxE9vrkW9KEbP2Q2sjfP3z172KvX511 sfQt6TUK4hvTWWRpW6n3aTE3IG0jx+gKIbMdvPMJhW0QkTFxpKuWrfgSlf6yZUve4MUrXzo7hf6l RRor7cz7g/YCZBbGI9KQM3l1Z3c+UT7SALsDs320FUgn1DWNKUoQwAAZYpBW9ZbVorB/71UPXBkT lXL5uMhEAwEYLpNGkVq9Jf8SOdha8CIr9zIh+ihGC4shvYdxfImEOES+LiC12lD+fOe4bdd2SRCy C1d+Rfpzr/Zp9HbUDEYLSDkKC87gAsdBJIO8GdrOuIMDihbbshohNB7fnFs8DGEULWBiQ8gkI7Xw yDMmkz/0y1mei4a7f9/DCHjyc6K6/J9EiYZCywUpkhsjKBp9rzC9Pj76cHyk22qhG0uOD0GDYGAK mqf648YQjf94WXpA1H2Fr1sZwZTPI3XeUoGvs0b9JQUUj+14sxLGF1NA8WhuGAqoMI6OWYjwSUs1 axY7R876GrCm+uOIZuCg+xAeB6nf4yTA4kQICEk2MIPREqiiJKevQ45HMNmKrYGrRA2Mp2efGzar kb2hsTSNRYVPQQPnGyHQHxCaB/7jJfOhqAY1JvN+LB7Nq6zs5tDbcdrYYVoltFgZBnz2jJZ4GP5o g9fFXh/QsL4LP9jPBn+jPbkFch/0c93y21zot59o7Vs3bhh9aWVRmHshN/fqJ99tdNHpZUCiRYvG UWQwwP2R87eyqbNqL1UViy4JTBxNOQGrZfOWUO+wgLUPLjek5i26k+jLlnpYI323f3fk+IjkuPT7 GLJWvXDFHMM9cy/k8UfazSK28ig2bD1JkRFJGQMEGjkxLesGvIFDINAwJpr43vlybIUeVLtG5SHt +3a+MGrZHUlY1gEVOhF2O0D2u4v0rcU3vrhuZWt0Z9eoDTqSOrbwbDLW0EQxQJuRyxVknUM49yBo M4hJtxCpWxywtTSmS3dJSwBPWhrD8ybjgp7fgWWOXFggK50W2RmNyJUFUv3T/Bk1hkHAZzMeGVit XiCBRa1gcP4avHGDIrkdaF4j6bvYXIsZnOh+aURqV34T4Fe+wdkPC78Ii9x1C9glcp5j404MehqR G16XwWrfyKEVWSjj5CAyGgQm3bpUa2J+TbdEVp2dOPfKwdzq9lX9ToU37YKZr9j9AlveqItf4eID tvwQMFS8n34wF/6Dv6Pyd+rhyscjtnoQSv2XDU0LAyQZuaJBShnmjOcnyTAmfXG5Q3ZrdzEW2RRg Umk4f2j9ODTkpcLR6TMlUlv4hF92QHhWFQmkH0r1uyjzfBM1jjCSGvbQkOQSO80vsoKERlTi7ZWe 2kJWpHb0AjiTpD/HTbb+qSgyLmukgTwrhvMGgpNpUlZUWV4mUois1qFqVg/2FnlnjBTFnqqyj2K0 TC5KrDCO3RylFxbphxa9GsEB7KPFztzqBrHfIUW5NffgOO3BLZlX3WqZFBStSzkMZV9ExCRtvmUG Vj725ziwUQkiES/tqiQgOJFhFLsJoj1U5MCAonmjGJij+LqTslE0KpiWQJXUyRTVwE1DLV3KRjWC 16UaG4ZPQYNUPm/dfUo1NpXflxKWeYVPwYTbvgxEvQK8A1E3Nh5EbPAh9mfR5YC9xw0uCMXHJZYI 5RXkyQ/BtAtj0jbLvBj1GENtvrVuGaJFv8HFe3QQxsUUbWcuVaovvqT1fmki317ob52h0kTTeMIU UQzsOI3tCStzMj8MTziMyQ7JuchVtmDC1T5au7gMfkTtKjYJ2dLuJ6LWIzLiZRy/0hNqMjJex3dm 0AIKL/0OyVUv1XHfklgmrkwr6bESa9mSFC6c5kQkmebzsoS3+NMjPrw0z0yTeaM4m3Za9FKP8llk 7OhHroTiQUihICI7JGDrTjHkDglY21moyLAfM/bJ7VuPym5QC7oSogV2duVTouOaTd3yWL8ieoTY huMIShhQi1t8aJBdjVK7FXDFuFI+GduJhlNW6qhOtIzuRIdx7NLdAFbxnGOzbARW90N4RHNRGWuy nMRjTIh+p9S+F2cfGGE0DxcjiuERTpDMt32QaeW5l9a4w+awCLXUOTBV8SqeTdUVyc4d3xkqGKWR PLqYmZlyYtHUECdGrxiqIQvdyDg+pRpkXnpesdfISq8vaOClq4xWS1l5APV91QGo17vyANqGFsD+ JG7KpzePG1QslBYqkQSnaFj4dKBnNwwITJzWv28pyOinfHCRVQ09HQOntUR2GkWt/I/dC2eKyEaj qER/Np6jlCEI+GwmzMr/vygx2D0I5AIv5rSmyMZhqQmfmPhBwou8H1KUMkz/zy+Vwpg8bZdX+/iC rVsRJtnQ7A1mguysA8IBO5lVavpypVMb5RXEy86CeyFoAolf4CZIaGHLrVv8s10MtMIWO+zym3ul IeNrUSYJtI5bCz8OYklkVCCkiOwpCoWDOAyDJ4zJmPNW+srHSp15J6jhdu67QPxQnVGo4Mh29iE2 d6k3ipqaB4gO/gNB/47jcObgt9ZcbC15mXeyF1cBnyaCAi1p2hrQnpE3XgupjKjD0J4hTKY9G8Wc gEtMQfzzdhtNwWFowEEZ6vYLFODRj0YRNXiVzzVik7QgoJ0jr106C3uKs1FYxTJB0nn0ISufhOaq 7tko9ewjcpY79WqJa9+P0ZTGpVF/WOolUkZXeG09P8M2uyMJ71tq4XKClbH1XKQEGhCEkXfNCaHe PwxdH8bEUYjbVzZ8DI7vvvb9z6f6JLbX/gksCSrToUN+7lIvRuOKvZbOLrlOt/rTbZ/b636S3B1J GQMEGnnXnOB1+ATC5yfQMCba9mtZYgtcy88tmmqd1Xvj8D9LbSbvJ3XxGi64uqjgok7tMewf0y3n /PSPWJ0/PYPsGc7dkwHmAxlkx3WTHBJN0sEAOUbeKCdYA8XIh0COYUyekh2epDKEwM8WN/msMm4r 6JgdI/NOJsvtQtpSktou/g4ph3kvHx4/sChoyprACQuDIj3hSY4NGDfePkNH3hIpWA6HrxwEQwcx cVTdN6PbFsi5z0aB5Gj/iMFxZ30HSxi3nCD+1CSsRfEUm8clYaeJ11FEMUCbkffJihwOWjkI2gxj Mm5HtY/fadothN3LfvLKFzZm9E3qeQJOvLeTCre+Pf25p440rt6mwDkVWnNnSk1rk6PMpAhi4AsL kXOvvOEQ0zkAuiQw6dPUliXsCti597mr/kkXid9HO+HuzBfnAroMJiGA32NLP2PbF7CtOMYyNoEp b68g59MFkNsF0JOER6o8q2gKGyD0yNl9XousFAdB6GFMnnIku0sD+IJz3OngtfJW52CDT7LDkxhj 9IOczbHRBLRQRHoe/7RuXpQQJH6uIZs0EgHtmU7rNvvsnmvE5uhVAtqWiHQ3Ehw0cT1JPsWR26TY GZB+kUtMeCWz8jDUfBiTPWLDe53X7ZGD63VzvOZN6qUZnBQ+b4Hvf/EjnIXYGLXhiFvfhJ1OMRvX iCSKAdqMXKPAyyKrDkMzhzHZPQ7n2YDW+bjGN9zpKkQKoGMazr3N1tD9i74oa70xdFTu1rMrLcXf os3QP2U39NWkaWiTIooB2pTkxg1UnIXMCrMDLR88/aCMnKKzpkLMjRtltCQNMkEYx31zI62QVtfT tw+6FJnJ9A0MPPaOBWLg/c/YLVocY0ILA7hGi3Q6Kg7i6imcAYSihbe4MnMqEiF3ItPQ0Uzf0t6J TD2kq2ixD8GhjWbH9sYLmPNaGMlh9kGohso0lJt9EKqxlLqx4vgUNCjWL6vuU6qxKv2+VEO92XhR 6TPwPYgwy0UXomqsWxBtgw+xP4vM7bzYPG5xsVB8XGJJPlk95dTEKrYdLPRmk+ev8Q8CPpvJjrXw f6vGf6+qjHnn5CanE9rhtugZOpODJtZjkB5j2768yZqDqNkhMHnaNwY32nEnAh5XHu5boLdpXyd7 kdv28dwtB82dsf3gyPGZ6shNVJRa+AH6i1w8y3keZoM/gf6CmAzVhzv6C21zn48tCyAjq4+p+5yA JZmhivJQhCkyAeXKdymoCYsdfRN5k+UktF/RtIMNyafoImy00aB7MElBJknVA8wV29tj7FCEexiT 3SNnXoWb+vNa3Ylpqp0JjBsFsQDQUE/nAr3dQ8K7mzu+Q6zfqou/G09E/flvdfcd9vEDcrmrmBnz rY8PLQXzFfFoHyNzin18Tr0c+iniOlUEhaK+ASaIXPTJcw5Hoh0CE4Qx2es8RF8XeJ+eCemT4Qof v+gz9OkZLx5IHL3St6M9k2o+eGjlNFuFrMFN0cEAOUYu+mSNhE+/HgA5Epg8TQ69M4s6D9ejWwpy UmeBWvkhSI4u47HZUeZiX9+loeq1DFtWiP13LZra4TM48UskySUfoLzI1YkM+OAgqhMJTEYfLtp3 3HTF3xukwxcjiOURqXMrsbTFYpyza9uYg27WlfrvfBlqPYZJBCFJBwPkGLkgEfZ5sd3rz+rI9Wes rODYl53RiFwdxIoajuXtovHOiSondmPHoxQ11BT42L5ck2clBes/UfB/Tr3Y/BrtDKdpSFHVbX4L F/9GPrzyLROXRfwVWdQFe25QG20+QAYPMriQqbcNQG+mydVFDhfNNsyGcXUXZygKnL3uZI92Oz5O s0GLWJO+/Fcv/ZwkZ/rrt/rPR9WSrJIjfZwxfOWyhvOKVT+SiUxW+MlZE8sf6qP1ChybgV8zbfcB 53bCt3d1RwhZNhxSFgAZG1impkToHcpSkZ6A85XLLK/xbqlmD9gf76/hvoatlLahKBt9SpXuyd1o OPpd3VBwBoO49hp4JtUqmK7sN8ENIHuzBCQ1JrbhGho0orYBp9N05e40pOVxZ8zq7Uu1yJhA/h1+ L2CHE/yuLA8m9C4a3mSVmrgNWbQEmpfoGPe2ISqelPo75y2iElqmFqyAEXWJCpz225sbRdeV4mqm 1awEDpBA/Y1S44yBouXKtWc5ONnN7K8p6yU5d0RUhBCFMxopPE8UXgqT5CqVIDBYyDPZBQEZQKDI WVYUBAYvc1H8+Cr2mAvwgxpq0I8w20nKSjvku4u0mi2v0lJZRdUMpuJCXa+Sxfmtuv6qZwhasiT5 CRb0NgWhKadYK0tUeQ380T+3rJz9e3GTFrO7a/UHbl+kjO+JR2jJZJlDzjaMByzZ2+hLJkslE6iR 6xX7cq8GHZ88ZSW2j/Wn+GOFdCU52AnIqtJfnCXgLdarCSioruGNZ6WgZgvRGhJa3sUfaFNr6faM 5AMClT0f9YAwlZKknnMQhxshmTw8gowEKXpt/0+MmF2krJh9UzxsbhMtXfWyXCbGQ2zAFyinlKsM zjUJMQAg8PcP6byYJYt7HdiDYf0rnSsr9ZsenBG18OylNtqXVk9o3WlUyurWtk2mSnkFdXXhcUyk StWzTFBTZ8a9vAXJDDSQ6+HfuxkBJauvYDYnkDJmXWUjsrLn304kZYR6loAY2Mu/9wil3thDj3AC 7SQLWHFiiBMwpyzBIyLgaeoBglqsjcUWHXyhc68E+DtgaUfP/SNi91fNedZQ69ud7GCQxiuW0Y4m +Iy07yqF0svS813Nd8p813VrL/5LN+YLPKzsdrIBJiEK57mran6qxvmrgpl/jL9q7jb+qrn3/FXT gC6q6crdaUgbh1XKPCs8fxU+GlRJ9Fftp94sIHOz8Vdtw8Zfxa8D2kGYrtwdAPLcVYMJ7a6qx5Q2 tZRSwd4AwlmVfWd127uDrip0opby6a6qHOuqDqNJO6oElh8AH+X7WJ2rNc6N/R9a1o+gqmn+fBpK oPxkQ+E0hjuL3biT55CX97hTf95jV+7UL0Foyf8cjOskfNQq9qteEpDS1p8icb3UUvdivuXFgAFK fEI3+K9sSJ/pybKBLDdGVtqOXYNExgFeU2PwhIK52wgFc+8JBdOAXG66cncakicUOAfzyZMKSnzV pZMKXL3tpIK58aSCafCkgmlwS6e7cncakicWDC60WFCzKzwChe+QEnKh7MuFrS8PCwaFW9Ov0NaM fwF8d63Zbi6NaNBXq5RJJQa2GesjkGLBQIDMiiqMVDIHkoUXlmez829jGLDajQHB1xEeA9pPkOzI gfatG3vOPut10985gxiIWkCwe8Me9uB2S3SiZvozUoYm7Z1jD3u/YQ/bYMndduXuNCSPPXIJX3Px 2CPX3xtE9shLqOe37GFuPPYwDR57mAY3sbord6chLY87oybZAzBvnHnFFWFJij3qHntsf3mQPaDU h/dts/F6sxipN8fgSStOAs0T8EULzxO7hGjnPSrSxfqbdtsSDGqu8Gdwa9efYXTxEcaJZSBAuxgr 3a70OaDNPev/au2cSkB1rQZUeQPq46/98nXyx+XVUtkIl8nJOz2WxWp1b20G46WbvxewMjYwYQMA U4261vtNSD9nE39G18OLzifvU10WKCGfrpZPQExF1hLoz4ZZvnxKGxfIXl5BSGNjIP0t9qAKxsCY IgY1RkA3OwloDt6aL6DtVsMdBbR9y27HUaKo242DJyHr6IljrrxV5lwYrnxl7qwVe+fEsb3fiGPb YMWr7crdaUgbcQyblrgvjmHLUOHEMS8FnEBiIZmbjTi2DRtxbBtwFKYrd6chLY87oybFMWBeO3dX KfqcU/K4yXvyeODtQYHMiwJMracL5HKkQB6FKC2RCTx/A55dr0xBqwzkoOaYhIqNVmHPDQnjtcqS RAvdf6aczS6vQMAsL0H+aIELCP4tsHFr77myiyproM8uUj8q+ADeSHoFPzlZg/cnrUDTuuGhXy+y /wrq7wkQWL2YAJ6ANAIBbwoKlUreE+BMCB+0BpkveTrgRr1fP+NAmxKMDAIeB15M+jmMYMJiL9zC 4XxlshGobY1eP10CCB27ImZjse6X4+09RpmD4U8PkgxgP32QUmTkipMhoj3AFWbz7RiKRhPofwHC MO3oDQplbmRzdHJlYW0NCmVuZG9iag0KMTkgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5 cGUwL0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFu dEZvbnRzIDIwIDAgUi9Ub1VuaWNvZGUgNzQ1IDAgUj4+DQplbmRvYmoNCjIwIDAgb2JqDQpbIDIx IDAgUl0gDQplbmRvYmoNCjIxIDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9TdWJ0 eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAwMC9D SURTeXN0ZW1JbmZvIDIyIDAgUi9Gb250RGVzY3JpcHRvciAyMyAwIFIvVyA3NDcgMCBSPj4NCmVu ZG9iag0KMjIgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9T dXBwbGVtZW50IDA+Pg0KZW5kb2JqDQoyMyAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9G b250TmFtZS9BQkNERUUrQ2FsaWJyaS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAv RGVzY2VudCAtMjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTIxL01heFdpZHRoIDE3NDMvRm9u dFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTIvRm9udEJCb3hbIC01MDMgLTI1MCAxMjQw IDc1MF0gL0ZvbnRGaWxlMiA3NDYgMCBSPj4NCmVuZG9iag0KMjQgMCBvYmoNCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDExIDAgUj4+L1By b2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYx MiA3OTJdIC9Db250ZW50cyAyNSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5 L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDU+Pg0KZW5kb2JqDQoyNSAwIG9i ag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyOTczPj4NCnN0cmVhbQ0KeJzNXG1v2zgS /m7A/4HIp7hoWPFNL0VRoNt073rYFtk0vcXCKArXTlLfOYmbOLtbHO6/LylpGFIiLdsdx0aBdERJ nBH58OHMkDR5dkJevHj27vXbY5K8fEl+On5NElrIglz2e5KlNBekyKhMJWFK0UIRVaQ0Y+T2vN+7 eNLvkTfvXhPi1MLqWr71e4oqDm/LlFHG3Ld/e0Ku+72fzvq9Zz8zkmmlkpxd9HuMJPofIymniSSp EJRl5Oyq30uMTQn5R783PHw7OBKH1+bPYpAfnhvhVgtlybkWFoNP5Oxf/d4bXf2v/d4PG8OShLKY MUfoyiTNo9qO4WNHRrgoP1YLRAskJnTdDwlnRviohVMjvIdbtqTsgrt1a+0WovffGWGkhe9Qwo2Q aCExQoHcDTIRtChi3UB8ba1xwJHHAZeU87WtEMhWMEV5urYVEtmKJKWCBaxYhh9cbBSKirglB0BM 9x4xURirMy3cGeEA7Jtq4cLab179ClRWlpxp4aMRTrXwHj5t4VHBNdQ618IN3FrYWqdw347uX7Tw ASzzB/5XoFXiVjYBo249W29aBn33SqrKcHtA5AVNizgWliNS4SJS6fdFaFw8OiIjlsyhY268PhuD MAOzFoCmywe0+NhBnuuydEkD+mb/oYWpESYAzgmY/SWCObDfGyT/hS+6hg8tn7l5GIPtOupbU8D+ HTQWgWnw3CupKsOGfEI5i4NtOeRTZMjn+Z6QcMSSkiVfad0nQKCnYM0t0NgYuuoW0HRX0aFr9lsX F1dGuNfCDLp7CpQ78xh7DrXeAJrWGHE1/Rtn5w+v1vbMcAcPXnnFHYB/ig3NoqCsiINiOTQzZGhm xb6wcdiSNrlYoitLLgZOTGPBOrH2e4i1D0aYaCk11iCZexiewsgYwRtTQO2167BYsN57mo1R1Gvr t/BRq3k324FmDBTLoZljQzOhcj9YM2zJGLhpCj107aFp7PLKtcdv9r5FygJANPbqGC33au9A8201 6R95Lmd++Cfgz4LZ1loa9H2lCb0m9hNvHEzKYYaMP93Qeay57ZC/gw/HZ2ZJZREH3nL4F8jw1+/J /WDmsCVzj14XLWxZh3MBz9hb0dCrFu6B5mdun9vJ2pK2HzOu4eaaWA63rbimThVtK+y0l+4WylVM 2xJ3blS1au3a2OafepPNFfqw1u+7xuobNElEwe3/t5eh0tPycxrDPPxyrUPpmYtITSIJFaooCpt8 RYkoRHxUYocviiYsps1H8/V2cnmrfWl5SynKZV43fkKV1p7TQv+NZ74TZLJUXPf+PnBl0JA2/VhP 9Q5YdAbE1/Qij5yU7sdBnYU6c53YBdQxX3XeJ56ncOtSwZKAbr1A36TBXxnhZFAnyk7h1gegpH9v aQaPwGH5BM6Q12OUFHos7AUqw5Z8A8jZuMhOmBOAlD/7Xg9sWqwJZDtx38KDEVfT8+PuYZZ/cIu9 mMfC/wVg78ZD/ctgkGVzFddtt9gugnn+iU3LjraTe41ioQOSyEsjSki6Hz5l0JCZ15ONBOGREyCf uPCaVL3ZhNbdQ5fWgJxAieO6InuBLDfLkeGvW7iAuwcXeGZdVzvKPNfVJgym8BmXcT4ewXC6rL7w cdy7NI0CqwPeyGtuiiua7gfjhi2xgU/ZY2PomouBk0SwKLUdjr6QoDKapEtttCw534Z+7Urn0TYS 0DUXrltiPZYRtNxXaKcbeJjYmckbFJHV+VBYmgei2oeVHTthzYMPhuLP7eTnYjDvGG3Ia8uKpTQN rbM//mgLWxLN4DrZhSnAaQTdOLXUuZWxlzEqPIvXCYbJkb5Kua5yPDycYkd+MC43s60FwMjL0ADa U5cak5QnW4jWmQ6gVRQY0UX6JpnYlalzcEGsq3wOCBnDfYrtTOju0BF4dJjFA/GqbVeLxLGX95OM putvAWLIS66yyGm2/h4ghry8JrX3n7VbQxnI+IH2Gy38BbPRVcM5RB7mZtAVMds6mwh5mUca0tmg p5DT7VLTUt70YA1xCbMSptmWEOypIEup4GHFw8PfIBTyMzjtBcHjQb0e9AFKTsHVsQGF40lq4WeY 5C4HTgrdzpEsHjeNvACqSYxONsl3hULr+06QPoNaZ9ZWG9+3Kfl/g+aOrC0tA0U6pnMzI3JqU+r/ iuZq1KMAM6R4WLX960G9uPAUusX418dVaL4dtgpb83/PiPbocDICRx15Viej0L1AUj9s86wz8Cfb K7vt9FPE1oOBzaIdOctaz7HhrVLzfqRBO+GNnCSVStBiJ7wbUjyswPIXcN3VoLkQSV3muoJus0Og 3u7txqI38R63AcgSvgutvNfk6i8i2E0lRnjqMfUqq7R2W0102+M2FgUjvdCJQuS8qJRyRyQbUjzs XAW3G9RsfsN06BfvYTuXY8clTL+RpTHTO7sOOecnhdoIQcjJEMkzs2K7thnI4ZdkuUnt7QDIIcWb 0Ck6WoWgPIvZ19k/2HFpUtCd8ExAb300zCZElyzYskF9cChplRiaOajmQffKvPoG3PSy1t+18Bzm lvZpj3uYjebepHrgXU0GTqLO7gS2WdwrqKwbdu7UZu5jw07oN3is3TtRh52GMEfy8p3ALqB4Ddzx H8EddnK0zChGvmgVhC8AdPPKrQ96+0sOPh3AN9qdn3YJ49yFOq1Kdk28EEaHG6xzCCCnmUTBNjkU yJHTTCLnZjZ6/JEYVDysYgm7d90IlwDHJp6W5CdzINStTuTV8afIh3Se7kROy4hMtPH0KB0ZUow8 lX9o8U4Z15oc9S9GMHtLf2+QmLPxh0LJBHBS01aTxD63Hixf/RyvNQTDR6a1Mm6N9EInCpGzJyKV Gw0G5PBZKGWguYPBEFI8XGFyXIXMrHe4lRg6pSqN2d/Zf8gxtJC6NXcyK4UU7yGZLYBWusgs7Pl9 btWxX2QW7oVOFCKnUITQ7++ERUKKMaOUrWzfilj9CgnuJRvexeE+AoTuQaQhOM0i+FkBxsgpOMHz FQ5OtM1AzjQJVlC1i1RTUPGwkx7bbuDSWfpRgFXH/JEv6uxR5CyOYInxGXbRowHFTX50znQ0d/0l y0uEEaT5k+mrfA8JhktzniTSDJ0wwM5kJIymG6AROZPBC90mu8gpBhV388tq7tdO+CXyRZ0/FYWc 0uC5oKnYRY+GFOPxi6pKjpzfP9tLfok0QycMkHMKPJM03QCNyDkFniqa7QSNIcXDfYIL03DJ8pih nR2FnDzgKjXW7KCjQoqbtPGqxQ1WMEFaAfEbBX6gXgnbzt6JiOmdXYcccXOZbbL3ViJHTFzkNF8/ /yCRIybOC1qse57lB4VVHkRGYFGYPo9+7BZV16cjI6qXbkvewlCsx2C0ITrAhxzccZ5sNAaQgwvO 2EatgR1cJJwW67eGQvaIWSFpsn5rKGSPzIQJG+xdUsgemVmAZRv8fiiyv8HSjLINWgN57mQqp7zt fZ3Y8NGeJcT+gW2NhjymHvuHhoqEpjFd/wSetoRtf7HB25+68uT3BjzrOdTh73A2z7wHz9puqy9d 7C8wVdiDfKzKKjlboZs/gY0zUQ+NcDJwtqPZ3bepET5t5+d5In3SnrITyiT5M3qglJH/EDIsHyr/ fNJKyIT0pBDGTVBmys7JlfmFe0FlBmcLZ/3ehx/V4FV4VZ0M5WlLQ/gY6QpKdYWc1mdArQLBSwUi NwpYlphV/PqJssB5Q19/1T3xxCgpNep4Rmt8aBppkjemaaBAGPulKH+SXjFOea6vUprkcDXWvW/o C65n5jo3i291gUoLKhRUZa9KTeXLVQFn5vNnTgE3P1kHdXFBhfkFp1JTdTE2ZlamVAUzU1BZWhXA V1RV2atS07jf+OqHtimJ9pu5r6rTqsLsCmeCmw/Q4YXMHVh7hOxEESu9XI0JTsw2oNwfE6KcEhRT oZOyxwPGzKCUOkaXlbAwf0ppMmDy8PkgDYycNYxiIaNS3VJZ2KjyHHf5go6Pv3xv6Ibp6284VP8y DQplbmRzdHJlYW0NCmVuZG9iag0KMjYgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIv UmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0lt YWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRzIDI3IDAgUi9H cm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0 cnVjdFBhcmVudHMgNj4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDI2Mjg+Pg0Kc3RyZWFtDQp4nNVdW2/cNhZ+H2D+A5Enq7vDiBfdgqJAayetF5usN3Gx D9M8OOOxM0Bst/YkbYD++CUlHpoakaORfCQhKOAeyyOeQ/LjuXNCnp+R779//vr49ITEP/xAfjo5 JjEtZEGu5zPJUpoLUmRUppKwJKFFQpIipRkj9+v57Oq7+Yy8fH1MiDMKM6P8MZ8lNOHwtkwZZcx9 +3/fkdv57Kfz+ez5K0YyxVSS86v5jJFY/cdIymksSSoEZRk5v5nPYi1TTH6ez5ZHp9FCHN3qH9so P1pr4l4R5ZO1IrbRe3L+r/nspRr+v/PZk4VhcUxZSJgFOjNJ8yC3E5jshSauyskqgiiChIi2v/uI c038qoi3mngDf7JPyi146DpqOxH8+2tNXCjiKzzhmogVEWuiQN4GGQtaFKFtIHVujXPAkc8Bl5Tz zlIIZClYQnnaWQqJLEWcUsE8UvTG+i6BfJ4lp1keEvsf6NwymgS5LdQkF3qS5kfuEsiC5DHNg7uF Pu1cvR/k5pttgMAViyvtEfOxFoGLjGZFr70fZzUKSbNstNUoir2Q8E8bVwbBcxqLsWYshNI0exTk fjWd4KrpRL0vfMaiu5pGVhWsoHERlm8kexDg/zfw/k/l6Kkfl66PW4r0NxBniig/cweOoCZWQHyC weyop9Vb5rcLGP4Shl+DW/fQePUMRr0Hx9vIMgiIg9uzH8QpMojz/Fv0NQJiD+RrBLiN72uMNe3K 1whOe1pfY6RFML5Gn70f09cYazUqX6N9NYb3NUaaMajpkILcr6YzZDWdFVi+xqhq2i+2tbhsj/zW BdAZmRPwBfZMpD5qoX9w9RuFJAqtPWHeV4UmpCIyTeRDuwChXd2PrRwbWzGV36AL4BfbbiU/BFvn ivi3Jt4Nj61EE0IRshoD3/EHBRlamYFAHIDPfhAXyCBW78lvUEH6xa7ro0NAfLyjIJGtP5MlsPYu 8lC8jdfXslJPPZg2zR4PrfRDi7j/vLAY+cAknCbf3nnxSj1U2OdlNkHUN86kTdAXmPTEMd8oSwAh X/d9HzXiG2ctTMDXthYjxHujzBe0c0Attihn5K6ARAqa9BADuSibCEkH9alwKvnDuB1cbQELLEHZ O6BL9R808SkyaWVS+RjIgiRpafkCe9GCCOQCecITmvYAJnKFPGEpTbt3CzDsClCc0bTZOpFqGNAa Ot8BRFaK+KwJXYvYaELXGWzHR+nG6xJE2enzAJ9xCiQGeGUpZKOIO03cRrqegewPFDHlSWiOrUuN XKeQRU6zHjuOnIeTeaFNcF0MEiszpfM4KyUQwVZEWUoF9zNeKlwtqoawsiL2OTK1qw0g5CsAcFWH ivnMJbxucGXguGmgsBzjCsawZTodef6qibeKeAMgvoDPPCrFSxj1wZX1AZ6s4TMEJLvFNu9xrrv7 AsvYCiPklJvUjv0umseBUQvj5SkyXxVV5H62+I2FSmOlIV4nkAPYAN400q+GKb2PNF+mfJQsyO0D HO6PYDS+VE+QhVAeMw8uO/qUk4zGQW7bmhbUqu59ZYsHCZUDQrQqE+TUp8wYzbu7hhw5oSTV/4rd PPAoOs3H2PjoH8vDPoSW8TPFnmGRUBFa2+XRj3qKv6sp/g5hyAZsfcCWa/NsfAZjo7+ATlyBurCW vRzjGp5cwBjWTv8InLUIn6px2tmfAec7+MxdzUH55BHB9UKsL3wFw9+O40EUBWXFgRvfPG3IGQKZ CFrsHvpRTpuPsdG8H10vz26W3d4y7rmBzbqNnM7+S4AJqf60cBq+iLvP2xp6LmHU1aO3aUBz64ZV DxVKXV95U1p/F/v2g4f405tH99V8cF2b+Ad48tV1vC+xManc2bQI7UkrJpHTRVLKiSyAj7GDyXXn 7fWFS4udRsW2cOmwmGcX4OWry8hcQnkFOQFdNy6rW4kick28Lx1aZDyxXNemAuvZiifkZJMUSS9Y IyebJFcu5ySw9jGuOTYGPM8AiTazVCLxWdh0PwPE1994gMGIG9if1o7PCiIKfY5ugLDdtEaTm9+Q NXkpIjLkZaYLTIG13mszsHV5TDkLCdIKeuTUplSaIJ7Ev/AxXvYyzAZRNXh+sM7vjmE2f3+Szdg1 Azg2Y+H0q69dWc1RQoZhpt4P7UIrCrGzvrHyuacAoYfvUllloxBfaeI4Mu05BVjkNBoq32DyPF6p WvcEOwWurwrn3cVATqGKgvW5MMqRky8i55Q3E8pZBYOFUwI6VUQZsL8B4rCCT1NpLAYq+GRMJ/IC M2q9iYucThKZ6HUhGDnOFqlsrsYYKsjL2HH+6nG2DShWka822IxptpVfuIBciTvY1vXwCKCwHP7a 5bxtASipDV+rHt2AWxqQtVlqahrmDl7vIBfnAzvUilDkqFskicbLBAj1MV6GtqUltHgXCi1cYP52 1IiUL8BPWrmIuaztfy2k+LMCnAtz/bhp28su7VrYXdr23yJF/RNes6g142PHJlzfPQks9LthIqEA N/TmroTp4kmAm7WRuqX5vNqbIfzcAPvWM4yc6RBSnahJrIyP8RMLCyZA+vL41iJUWLDnyAb6zUDs Hl5fP/JB7rBSwBehpUBv4kw4ZSFmPtjvKbYY1bfHjvYptuB7lqZ0Eph062FDzucJod6fxGD6GC+1 VXP9JHscVpFz0d3ek7cnpX6s/oxsO5k5N50SycqqDRC3mh7KwLxb9x05paXbiXtcvBDIOQ3BCr0o 4YhRX1Kph47+NqumE/UWIHENiHqwkAhlnwZpGgzMsXWpkVMVgsU06bHj2KmKmNF0ijSWl/GyW2Kf gL4pwWOrty9qcZnTcoOdk0iDK3jARiIne3jB9b2gzl8Phpwa4bmgqZgAT17Gpgl16+oXm7R+AQiz hZR7gJE1ZE43wCC9YgGpW3cNOZPEM0nTHuBBThfwNKHZJODxMe6jjDSuvj5ixjjAf1VaaTcUWTee rMIBjBjECapusAWm37r9yJGmuU3SWQxkH1yHXJM0QHsZd0LhIKWdgFjot2iVC5xkIW42iVxTz1ub MFvBsljjb6+1rBtP9iSiZYTfuVLF8IctYxPdyJEGFznNuwe6EjnS4LygxSSHzMd4efSyFrreQbbH Rr621fSJl1WsFah3yjg3Upp3VGyrivltPZKsYzYLVlmYwOa0ghM5NuM8bp6RccDpYew0C97B1lhk HNybp78vKK1SKgM4EixNdTQbkL91/5CDWs5YLxhhh2Qxp8UkMPIx7pM511B7Dm/tftXlYidXa/uY LFztqAQCcdsoVC/mbh5fX9S+5txxq1c1hXkT7arHC9cZf4F+3V8/Cy1s65e7IgfZrJDabe8sBnLU qK8a9WjESpCjRp2HYT2+cRc5emFpRlmP1UCOXliSU96M5c6qk+GecuyURnmbMsB+kNuUAV6/QJLn OnK6LG9rLlKn73kofcO/QG9uIqfuZ3XeG1COX2ohmfWe7uGDDKIMW1/c/ZcUJvxiCVPUDyzsCPzT 4K6WTRBnkVMJtOo/q9yaQRppgkvRPNX/B7UxdhYNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyOCAwIG9i ag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+ Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAg MCA2MTIgNzkyXSAvQ29udGVudHMgMjkgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFy ZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA3Pj4NCmVuZG9iag0KMjkg MCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjAyMz4+DQpzdHJlYW0NCnic7Vxt b9s2EP5uwP9B6CerWBjxTaKColibvmVYiixxMQxGPziKkwZInC52i+bfj5R1jF7IqFbP1tYMBdyL Xngn8rnjPaezg92j4Nmz3cP9g1dB9Px58PLVfhCRVKTBxXAgaEwUD9KEiFgEVEqSykCmMUlocDsb Ds6fDgfB68P9ICiNQotR/h4OJJEM7hYxJZSW7/7zaTAfDl6Oh4PdNzRItFIRjM+HAxpE+h8NYkYi EcScE5oE4+vhIDI2RcHb4WAyOgh3+GhuPpahGs2McKuF/MhMC8vwYzD+bTh4rYf/Yzj4YWNoFBHq M2YHXZkgyqvtFTzs1Ajn+cNqIdBC4BPazruEsRE+aOHYCO/hlD2SL8Fi3VHbBe/5QyNMtXAHR5gR Ii1ERkiRl0FEnKSpbxmCqraGHzBkP2CCMLa2FRzZCioJi9e2QiBbEcWEU4cVHvzgwiKNSOwzYaz1 fYIYlFvwBPzzixZuV1FL6aOFcR+McKyFA2u8canMCJ8gsl2DYO64rLjdJQQ9GwbN8Gdgwpkd1Zy/ gTFOKyYayxa1O4pr7uAa43afjfBZC1crzfojgzC0BMtuwCBr4hLmZLqBuMzTlNDUj4iHcSlxcSn1 /dzlHdvDpceEa1ieC1iMJZgyB+BUVn8Kq5utThULuoDzS1hri45cGJch/R4utuDK8f/1fsPWHwR5 FpjUlyr/UjwMiBgZEEp1gWWCbEWSNudCZ3kRN0czbU+AjcVEuyNzK7a5WwEii4sbCDH2yBTC0OV9 0CnusoEpawSdHOdn5azwgQi1BxjNwbqrhRfYgBQaib6paEOCwkZCRMT6eEyRrdD3iV7w6FI8GZ0A 6LLKPu3CWrGHziGoXZY32wKz7VizCmeNI5n79lx9rP9CD5dmSpRvZtqAQSNkZEhG5PpWIFNOKTiR dTO2gk+X4slovwKFZXl3zvG5B/g8hFO3gCSDrSPA1tKmbejsOI6JjH32o9PjhBLuWabJ6J1+0i+Q 6nyBZ59XkmUzLc8gm51VXM5mq3aMX2EryiAXJ7Agt3DNc2y31GmtSHyP2OoQyNxTckE6BAdk7imZ JHEvbulSPNGJQrFbLIGs3YDv7Rphv8x75oAUG/KzmlcXt+ZjXEG+Y7cV6+NNhnmghddGONHCW2wg 8oQk3ilohQAy8Zc0JvH6RRCKzfOihMT1itBWkOhSPFmV4wweziuYsXEvA9xVspAxwLZaUTgDXNps 6Loy2HIDWQjV4S7hvsdrXV5k1iZSZTC/thnItE0oPSnN2UhWrFl/MNiKgtBLv0/CZtm2OHIMqLi4 x0CxvpZ9LWHbLNJe7GWXJGK+B22db2RyJFREVIdlR2ZHQmc3qg925FQ8aVQoC+aTlfchGyFsRWkK udKssns1K6ELbEzpVUw8s/gdRXtkQiP0f+n6hJshMxohOUl7wZRLccG4LZFZQqJe2Z6qpaBruNiW K1cFJGTwyIREsc/q1lVDTruFEJ3Ag5x3Cy57Ao9LcZeAZHB1d4+ZYm/7topMP1CTUSO+2oyxc26e b4vux29dfuScWzDtEx1QiJxzC6qMa/aAQpfiriicNWLZfVEmgzHsbnkSll7NVI9kYTM5K64RmygT 5kVsz1S0QgE7P49S0gGQ2Om56QhRfQDSpXiyKgHMy4WFs0rN6yJErmJb/mjfs9jQOW0cma/GKf6a bcnWfIxTUHhXHuxsMy+iPYvTCk5kLsNT2uwW2QY4nYontRLZIqz3M9jgNQGa+kYLeeGbayE1gtJC bISPm9h0ixK2x/7W9UMmgVwxwtanxByZvvCE9wQjl+Ki5PoZyMEVoKelC2UX7rKvmZc2GtkAcxXW uxs+lUdtNspUe1su7293FltamnrmkJTalGEPOz4xc8w3sa3AQiakPBad8I3MsLiUBm19Nux4TKiV +bH7S1MilU+1u2MtB/eTsFlN/M7s97LsXzbm2w6Q3AFs04ZtQ6q2GZ2WXcZWDGZwq73G9odOa/Gi sCMDb2tm0N4QsJHWUi/+WtwAmeFzoYOuyxu36AZuEx5d35p3KVoQgUz6Odf3dwAmMunnTPXTKeRU /Dg71zxT0QoFZNLPqd6z1mf9HJn1cxoZmtADIl2K/+9dE8o3M63IwKbcESVxB4AiM0eWMpPbbR+g TsX/oeY1j/0bal7zaPuZmtc8j9j6XSHkGgZTnMR8fTOQGS9LBIl78UuX4gl6sqD0DV5lj6RLzvP0 rVBDrmqwWJpuqrXNQGaVBaPpAfEuxT9Pl5zn8VqXF5kiGnbQoV1KIFNExhVRD3XJ8bDeJXcMoeD3 nDRp4S849SJsfs2xWS/aqXUBnFQA9TUslaVnFRyZMS7giMXjhR11ATp83A85bKmUpIlvCltXEpnh Maat6QAoZIbHWNScja2ELZfiLu88bN5sd0r75V+7nV65cbn3kI8gg49xQ+g9T9266sjsjVHaCXzY 7C1ixiN7AJ9LsavgVS/U11+NWSjNHFWDnX9DKwtV5lLPA7d+YxyZndBUmF6vtc1AZidUyX66q5yK H2eh1TMVrVBAZg9ULwzt8FMKyOyBxgmhHWYDOculUhHW5FJHNp6Vai/IhFoS5VOPXZTKX8F5dPlK UsjchqYkSn02VGpf3/3DQXn+8g1CxmWZ8C0qPm3c/SucynncaVh+12cupLAf/QJH6j8+hPMjRxMj HEFEqtRClBE+buZNtGfiXe72D76szGQNCmVuZHN0cmVhbQ0KZW5kb2JqDQozMCAwIG9iag0KPDwv VHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+Pi9Qcm9j U2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA2MTIg NzkyXSAvQ29udGVudHMgMzEgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9D Uy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA4Pj4NCmVuZG9iag0KMzEgMCBvYmoN Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTY0Mz4+DQpzdHJlYW0NCnic7VxtT9tIEP4e Kf9hP4bqWPbV3kUIHQWu5SQQV3K6D1E/QAgQCSiXC9X139+uk3HedrvYN8EIUCU6dWzPePaZ2Xme mpCtU7Kzs3W8f3RA2O4u+XiwTxi1ypLrdkvxjBpJbE5VpgjXmlpNtM1ozslo0G5dfWi3yOHxPiFz d+HTu/zdbmmqBVytMk45n7/6rw/kvt362G23tn7jJHdOFeletVucMPeHk0xQpkgmJeU56d61W8zH xMindqvXOdrYlJ17/2O8YToDb4ycURwZOGO88ZV0f2+3Dt3t/2i3/ncwnDHKY8FsojtT1ES9HcDD nnvjqnhYZxBnkJiR+jxkdL3xpzO+eOMEPiqPFEvwT9W7po3o58feOHfGDzgivMGcwbxhkZdBMUmt jS0DWfS2UgcCuQ6EokJUjkIiR8E1FVnlKBRyFCyjki9F4doWk9LF1nfxEIKMhdx5FGHHvc4ZdJ2+ Nx6dMfLGEErzB6C474xvk85lXOlMz7mEy0cTgE+b2tAb36Cp+ULbBtyXDgcrR/rhywv3mfsXRU6M cFcoE8tMChgaFxjaXS+rwzNDjsKYZuAZdNybdGuPjVswvkMnLXfQAh8Pznj0xgWcPAREnQOWf4LK YsO4AeiVO8MlgL4Pt78D5N7DXdFRqaPZSIEhRwZDbutA0mBHwahqBJIhx73O/gKKxjDM9OeHmSEg 5ApOHgF4lnvk9MRt7Dks51RGkreyhAjesuhS9WbDzwgSVRTXKZRSmQ3syVcISTWPhYU9+gpRFG3E 22foINdglG2kREuRlh1nPMy4wPxmfDN/j18hq32AFi0R5Ufsa2/sIj+j1Jm//mmwWukMFrkz+P27 en/iDDkMLahuoj8F/PY6ezDHlYgpEbHljX1n3Czsodfzw1h/qbtNLy3ucTu/Dxe1vA2g7cJdB3Dk yBmH3jhzxifsUpM5zWMZSK4/Ms3XynWZGmEgsywtFV0thnwyorgfCjpESUzH0E5K+YHCkUtoQv7k PRiwHgAFw0kjXxyu5vhB2d9HAKcxGCXAbhdmr3PoWMWlXwCS1/MjWYnGEM9A7nPMFIJRMKfJlUVm rlpomtUAGDJ11Tyj2TKNf5ZGF3Lci8MyDJAp2k4XWtp4NuD/HJZlp0sWzXo6XTgFSQhgk1SW06y6 nsSRWaqyxifl+ZEYdFwqutMONQBgXEIXuwTwPIJ2UuJqENBG5rfRM7hHyS9WG61ahzbCjT818sDJ BUdmospYmtfAHTIVVYZR0wjuQo5DuCv324eFIx5uFwCeUh1ZFviW1ZHhAohjG+/mkpRy4o0tbDgq P+lF0rCH7iynMuYsiTlkkqMckTfVZxCBTHKU+8s2ocIEHb/r1srEMpNEBjL9UVpSWwOgyPRHKdUQ QEOO36xyHclGEg3IlElJXQuUyJRJiZyyRkAZcrw+7Xpz6X+5GxJ6I0+9JqE34u1VCb2RZ0zWETLv VI6NsBrljM07maWNVHPA79tSesMZSK4/Ng31b1KZ6mEg01Bpeeh9mpnUqzeeJvWOoU2/S72xpCbX FpnuSSOoqK50SGS6J3O5mo3naHVBxy9L652rmrX0ukgKkhBA5nUyU7WQiMzrpNYeFw0gMeT4NWu9 kQdOLjgydZPKpb8G7pCpm3TFqBrBXcjxS9N68QmViD55cuWRyYZ00dR4rUQikw3Jree0DQAw5Phd cVUmlpkkMpBpiOSM6hoAxaYhjNOsEYCGHL9ZxTWSjSQakImLsILq6txYIRMXYSTNZAOgDDp+9Ypr 5KnXpLhGvNVRXJHjM8XvFkXie6HabiTaZMUi80yRK5rVaBzIPFNkmuaNNI6Q47el7kZSkIQAMvMU ri7yGkhEZp7+9ZPAiyczeTfbqCDv3sIQ/rbl3UhSk2uLzC2FNNRUFzcUMrcUwlLbhLgRdPwC5d1J 1ayn2YVTkIQAMokUgtVCIjKJFJw3hMSQ49cs70YeOLng2DyRCWqr404j80RuFWVN4C7o+KXJu5sL r/KaNb1hG0lFEgrIBIQ78lbj5RKNTED879DyGl9DgDwE8yynvEY2kIdgrg0Vq5TgtGyra1M2HBpM zD22rmEZzWK+QqrGtEiH2L++LSTNbSyQct568tfeFHzxX2hdQ2hdg3kqcgJt5zt8dOeNi1mPmp7I YV/8BY4sf3UOzlf09IDpnK+QaeuNr+v5ip5I0kP19h9s/pXoDQplbmRzdHJlYW0NCmVuZG9iag0K MzIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0Yx IDUgMCBSL0YyIDExIDAgUi9GMyAxMyAwIFIvRjQgMTkgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRz IDMzIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4v VGFicy9TL1N0cnVjdFBhcmVudHMgOT4+DQplbmRvYmoNCjMzIDAgb2JqDQo8PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDM3NzY+Pg0Kc3RyZWFtDQp4nNVcWXPbOBJ+d5X+AypP4tYYIQ5eU6ns xleOnWS9dmamZrV5kOVzIx/xkePfLxpktwCSMMcOZGcqFRmCCKAJfN39oXGwp9vs2bOnb9dfb7D0 +XO2trHOUl7pih2NVrTIealYVXCdayayjFcZy6qcF4JdHoxWDv82WmGbb9cZc2oRTS2fRisZzySW 1rngQrilf/8bOxutrL0frTzdEqwwjWr2/nC0Ilhq/gmWS55qlivFRcHen45WUpApZS9HK5Px62RV jc/g4zopxweQuDQJm3NgEtfJB/b+zWhl01T/79HKdwsj0pSLkDCr0RvTvAy2toEvO4XEoX1Zk2Am wUKJod/7Eu8h8atJ7EDiHf5EOXYIru5a63Ai+PtbSExN4hvmSEikJpFCooo8DDpVvKpCw8D81jp6 ICPrgdRcyjtLoSJLITIu8ztLoSNLkeZciZYUxmylShnZZkYexiJjoTAtyv6GJ+NdtDozSNyYxCUk TlA1vyGKZyZxXluu0qhO88w+Fr+sAd4YtRNInKNRA0X7GXFPDR50cmb9xW3zufnGI3eMNCV0GeqZ IWBkcYGRmfLq7vDMI0tRlo8Dz96GJ7W1BmzMMfEZLSl5UIuPC5O4gcQePnyCiJoilm9BpXUYxwg9 8gz7CPoZVn+KyD3DWqOjMgv2xhAYishgKKr7QLKMLUXK9aNAsq/hyXjdQ9E1kpmZS2ZOECGH+PAl gqdtI5sHGyRGJmPmRUI9OFlwkkuU32J+GxFOQsYmpFIqnomQWLEZqZRWlwKtvULFPsIEaTcNou2W ZyZxsaDoro88duv4B/bqDEec00AD8z2CxPPI76iyHMoH3nFIYavICgtu9e5mQ6SRxcgkzx7DbPS0 Oxm/QHpFiCFEPIXEukkce67tyOVIs5bRaYraOuaue7S6/DOC9j3WeoA5r01iExK7JvEytqqpgheh Hhgc/8iz70wbK3MPMSJPfjKl+T2UASc/pjJeqqz5vDQ1NNUaG6oqJnTBRcUqk1XeEteIPInJZMbz bteWNR1y5747aBrPELsnLr4ZQv8c2RYh3nezwQmHY4ud2clA50aj7jKtuFSh/mgNcsqFZl9sYZ6m qpL0dwdMk2RvmKnyfwxGWOalHWKt2KkdcgF6BX5TsvloZXe0YjNtVi7xGQM2wbPcf8Jk5blbi8ko 6Bl4A+E0Zd+o1ZLNq5y2MMNtrdvLODVxH68laRpxBYmFTJGDjHdWt9jMOS143o67PIjz6Wt4UqsG KeV/kIZeYM7EJAQkPiBfoYc3kQnNFyrW/P6HRyBJe4k7/YR1lCbxFRPkhs6QdnKa5UP2KUpGPu0U E8S4r1CEz545uOqJHUQmWlpaMtnfzbGpqzLWPQ0MqoumNF0Sn+x/zUFtijwD1FUJtOLhtam34bY2 7SDuDxMnmk+aMOvQrzbAe6MK/Z6NIbgPvcBFX6S7kew1PnjhKeuVKyvzeOc+5tBrXC2Ypvn47BYl WzGBhDSJD8uIiagy46kIjccgHiNPcHRZ8eJ26x4bjsZziry/4Ul7ySFu01XKgw2/RUdyiUAHCbZ7 ZsmR4xqq5GkRkir6kpax+UUZau0VTuyO6oTrqojrcneEXqPGX6BbDdgACkM+tJeTpV0qeaD+lQZi abA1WiJj2C3nS0C5EiVMFh/ojZVh0mbaMGhHUhm7YWWgHDBgf2JZMHKERpdmVnt3cy4jBwq0sa7l 3afoMnKgQJs/VTd4V3Un1S/Q2n5EAwAq8cWzJvtokUIEOrKNzAqrw/3vMNiVkZd6daZ4dY8RjRwm 0Vp3e+NBeGtfw5PFItcU3cxHz81cI88DpL1AOB16XJDY4abn117h70cu7q6w1ikW/Qmr30T/OG95 MvPxh0sr9j3snrh1bHi8FXJ+97zu0eLhRmvmyNMvsdZ9LPoK5SAf3HDfpWzMCIzQIEIjLzprlXUV 5UEQ2tfwZAFMGpY3OKKnmPNPz87NEMUsaa+2EaYpAn7izXhoR8NpOMZAIQxQkmaNZ9WJzV/1TtMo PNF9n09IF9vFV1tL07700yWwaGXcrxShoRiEYuSdB1oWMMV7BCj2NTxZgMbajIuO/fOM5YlH6Wll hqbK/mCeuBDZr0c+sjuuMggcBV6Ntvp0QR99M4MsYetXQJBBjEUOy2rD8tN7QD12PMvG3B8B6T3t Tr5n6wtD2jldINp8fEnau8iu3aL0zImnFTS/O06cZaCvdcuNyZeoXocoma+L56ivpFlEQ2auUHv1 T64+16whsoU1JWSo3wdRFztqBduAy0eBXU/DkzpiCCHKLUis4+jmmKiSJQUThZl9F1VIrMFdqZEn waoS99ocG3kSrErJ5d1DAiryJFgVqq837NpU6s04QMNpd+AhJojX0+LSUli8UAp6KyDtYKdFnu6q XN9r7CJPd1WWgbrfPnaiM4jvPNLe3SL32XUH7RFfDa22RB/xypDlLPSOg10ded6mtLGs9xjxyJxd KVP+MRbmehsOuhSBuCOXQqG0tcTZSbLvzfwvvfnfbtIsdlHOE5yLAtzoWMcXD837LtNvZqfuFPQG f6cFQgpeENq3kmYzTH+cZnGaaB81Zubq0EFsTlOkvAgNwCAAIxN6ZaYXvVsNkYre4yBPbLJR8qwI CUprx5+QZJ8snFiQcv+CiKF1oTni44kH0TWEzjbmWDXQiRNE24k94ysET8vQCxOY6QiUp5wkVXdv 8jGNKZSosESxDIao8jwMrQGER54rKlHBXuk7ixF58qBEClu9HsHS9zUctPSFSdhdiLQTgZT7JWrY HOd/dA6RrCeZ4jNPjV50bP9vaGq/YuLARe92DUq3RHd7xS+Js31iExXYVraXOAEkqvVJLcuqE/yG /R67nrfYweoPE9piHFk5Ks11FRqYweN0sadPKWyN+Ct4gH5BYczpWMEMPYClCt88PkDbZb2INkNE U6gmcAaP4TO0c4jAfolII/JAsWlb/X/HvXDbRbj9Zh9KkBM5nsVlL2TwPR39KTo4K9gPHUTFADgj T6plJXnWF2L40cAZEHQLsbCHMLlJaGlu1TkcCkNpp3i0WyN60KaOaAd7dGBgI4cpZKl4ru4uRuSJ vyw0zx8jpNfbcJ9XVsjTMkiUHa+8gXgCO3eExuygdp0u3aWQQdeRknumaAJYtS9oB2lVbrEU/AQN GpjHU6y1Oe+1lK1UgQ5b0laqQGtr2Nm0+9Ppw6XscAoIYh0e7YDtzlkd17WMyWtAqkHtjRwvk3nG iz4j8sN5h35BdxNnI/BnVOImAufq7nnSPYnd3tT8a+LcKuATnl3kEr91mO4tC+3dpaQNdFlnKMup Bz8ySAeeHTp6GGTWxCWIiQFoRo4vyiyHLa9/AWj2C7qROMuZdHbyM0ETEEshO7p/IkCE4RnDgRtw bGBit6G9FHQJ0t6uE6SH33guzWFXJF+bXWXLYFcQ8AiO+QD0IseUpS7usylUR44sSlXy8jFOcPU2 fCu1spOpvEOt1lzzfOZhPPriSG530AZEj74fP88h8hBojYKjDYl0TkL7EZmtxAndzJEN0aH/o65S c1dzux7H56l0NuLKrfXaM0F+aOfXxNnk2L44YikxnEAXDupa5BinlBWv+lT+h/M2/YJSFJ8OStE9 St3TX/5+VuIUhzYReTaQVlypkNRkDRb+zbkfrWwiOnRDzktPbipMlI886Tf33awGfE3aCxO7qJIb WDRHIxY9IlRT/hDEBpAeOYwuZdqvcD8e0nsF9RyQlUElzWJMuRjAP81t2rfgZckSdiDWd1IEe37g kq/I4WopxH1wmMUOTKaSV4/Cbvoa7mM3GRJfS3N0h92sowGiyeXHpHfhfiNxokNdp73tOe1/Je0j 5UQO5l6tEEGiK12OahfdXqr1jhesQeIdvmFgO8AuqoZ3DPjrcvZ9B4ZiEIqRQ6nCUJH0r+D8A4LC mAUWcG4NbK22bqB7gZz9HZLTtstsDnv7LtObTXannl01CprnVWfBvT+w39zvspSj3UEYDKAxckRd gDR3X9XMIocG4eI2cY8rKSOHgURecHGP3ogcEhBZCcHkthjbNJda2k11Bg1lqPnY01p70D7QVt8t de0z5rdaxXb2JvLyC6yDvF0TU43MwoRRbxV6PdoCSr7XRmb3PI8OYne3L7WvUb6Tr+jNniArmCbO UUbaeWTb+bCcU4GB7ukOhin0hrGJvVHKfnwwOWyfrWilIHqWSdOGvc9JC8V1gdeF1XctDdXhFcHr mlSnjhQuB/3SVEQtw8q7bRi/m8cyppW9FlxXZkYKxw5z2CPWfJuZ3gNDg9/n8L2E/a1NRpZXUEdT FX2DhmzZ+ruy2/nnToaAO62aqjIluYaqCnsnlv0yAymtJE3GHDKsoE0GvkRdFX2zLc1G/jubwsdm jPH+tU/wcwZbyEDuypgRJe1KYMUL028LVHiW04li/rnSNaYky+0NcB6mlDXemdRwy1b3FtNyfH56 atSrMOZD2DsFNaBcAxmvDMsQAviGHBeJSIF8V4ariD52dRdBVZ+gZcWDcu6CRMfniR7fzJNsvM+M nOX4+MSkjaEycrO9g6QYs0vzxEGSG8ORGUtir8wwLwA5+/AEMLLC/oAPLuE9mg4XBYC2s+Z5s2da npv/J+b/bGrfA5Ig1BmbNm8zPWM7W+vw298Ze/1dMuo+GY1NMjrcL+OzVGVrz6N3i7GKpQp1C4wX O4PxvQaIsbobbi5Nth2la5M4nta/Re+NzIyYDI0Y9MZm9N7IlAF7aAAc1AJM675YYCQ6YrOsArYb EKZLcKJpSNrl+vYyxCwPXmj23cjXdkdCb9t2rLfiI19nvMgCTS7DAMFloDLU3vRsP74G6ayArRTh Xo2vQTpP4dBV4C0fWIN0UUFsICDMEjSoFJbNDGtQ9+qg7x7rsrAU6iE1yFCDKmAwlqJBlYAVk0B7 4KumH8EVWddUgwuSZ5CUdS5yDJaIfDy9PEiM4wIAnlmHj8CEv3V569rsA0fAxZZHS1LZtyXW6sUM OZEVxiVX8aUx2luUIWlOSGdrIpQIDbGsvCfq9P3Q0hB3CgjSenGMcvwftuyCjA0KZW5kc3RyZWFt DQplbmRvYmoNCjM0IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8 L0ZvbnQ8PC9GMSA1IDAgUi9GMiAxMSAwIFIvRjMgMTMgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNjEyIDc5Ml0gL0NvbnRlbnRz IDM1IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4v VGFicy9TL1N0cnVjdFBhcmVudHMgMTA+Pg0KZW5kb2JqDQozNSAwIG9iag0KPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAzNjMxPj4NCnN0cmVhbQ0KeJzVHWlvFLny+0jzHyw+ZVaMaR99rRAS 5wICHi+Et0/K8iHkfptJsjm4fv2z3a5Ku9tOM6F6AkIKHve4q2zXXWUPu/eW3b9/7/XjF09Y9uAB e/TkMct4rWu2P51oUfBKsbrkutBM5Dmvc5bXBS8FO9udTvZ+m07Y09ePGWu9Rfi3/DOd5DyXMFoX ggvRHv3nb+x4Onm0MZ3ceyZYaYBqtrE3nQiWmX+CFZJnmhVKcVGyjcV0klmcMvbHdLK59mI2V2vH 9s/FrFrbtY0z03A9u6ZxMfvANl5OJ0/N6/89nfwwMiLLuEghMycHpnmVhPYEJrtlG3tusqbBTIOl GkPPY40N23hvGuu28QYeYY/bgvNl3zrcSD5/bRtbpvEVeqRtZKaR2UZNvA06U7yuU9vAQmg9PpDE fCA1l3JpLBQxFiLnslgaC02MRVZwJTpYGLGVKWVw2zb4MEZMC6WBKIcBb74ghlvlvIqDpRc7dcaL FKwnhsm4ZbJDELdW7u5RCz5R86xe1XyFVLxMQvsIquQAxM6npocYiVxajlrVlPOSZ0loTo9cmpme Ndq1WvtADb/KeJlg4GExktOKkdyMVzFhdmOVSS11hKx4XqYQXTcQT0AJ78KWebr1NsK+bdwFHF8C F2PPa7AjDkCv4qP13pe3AMYOTPitbfDeyy7AKDkAzD6bxnnwsjtgYpx1+MuT3zm87KhteZyDDHKW 3v44Gj9JGNeTZ0FMnlUVZ5KfjjzjiK7D3h/BTn6FDWSw5W6nT0zjskdab2zjIRAJNepSaKO1U6j/ tWZhbhjg74ETHDp/zUzrd5xBfIbu0VPT+BK4J8dt6j0Jehiwywl8egescA6scAgrdUy8EsqIZCnS 1HY9zZfENF/Wv4hIjiO6ATQdk2e++whQew/0cQg0dBj07LbpYw/2/6zDIJ5Q3YQN3XraQdq1fpsh Wy9w71KzUV1znVyNIeKpqIkn4/qXEJhxRHfaxLPXkMIoxmYC/kjGZgIakriTfOSehHHY0iRBPlMj Q6sktI+gAg5ATXxyPcSsmBkeVKuaMejPOLSuI0EMWymeyZXNVJXWS0xAE2aSGgWMk7+fA0n9N8gT NFqtYDkF+/ykMWP9lwON30jtuzDESfpT+OZhW5F0w2DWbic2EoycF8lFGJLzNbGcN+P08tpGZMRo GGGaRwjC7YV3i2TgH9m9egGWX6jQF23X6fBKRvhR6w11zJt4L3p3aFhuX1EPsWQzG1+qxFwHV5w4 F5BrxfMboEEcis2V5l3yW0X0MQZ3c20TPJFntvEYiK6AhhUHHwLLph83aIUDPL2i2LljG3+2xc5F xwX3Q6kjn1KazRaJSZMLeem8nziwJ2073MdAzJ+d9nri4uMXLwPPzTLpPjz6b7PU1dqrK7t8BB9X aZmeVIC0m4Y0jQIadUMW1K5mzrMUQoNcTJzKyGXOi5gw+em8hTiiL9tRE1QUomF5z/d1w87jmNap 9RvYRuJcUC4KXiyfFxPUseSs5EU3SbgSpRADHNMKzkpVQBR5Tys8vxJuXortgoxHZbDRUw/PwV89 A5GIft01oyJC9NXMR5uDTG8Y7g1S/aGG+gO44RDeioE5lL+7IJEx/OhRoLaVNdd1amMGCZM4iqzr ipcx/vjZxFwCUYyx7sNWnoMNgrEStEgwrOqQfTtrBZjRQnYBZvRNYzE2T2DuHW9mrQRGt/7B97yD 12O2Y9GmtjsBCz0CfnwLPQr4kV7dushukgIGCJE4tKsr40nE+OGnI8Q4on2DScPm1Vc76FF7BrT1 EajpMhCUmCewtpbzFjOwvqjVtdTWdUuu/gAREIdotQ2U3YAWIYJg3sYrlfu/Z+YN/r2FmZ7BlteV ZuavrNIFapI4DqBLwau+PeszR15QnA/MUJK5ypXgmUxi1VnpjAvNPrvBPMtULfH/dWu/SPaSmVf+ j9lllkXl1tlgtXDrLoxUcQsv2dF08m46cZ2uqxLwHYNIycsq/IbpqvL2W0xHncN3LI3UsgXLdNRV 1YFl51npFjToaMPrrzPEAtpfb3ABKG1cqEjE/FcvHzeTxC6PzhWvbyNyEQXsjVTRs0Tvz3zRDZYR 2LCnS7veM417oI4/Q8PZjdsgaU+aT9Xat8YsoA71m/GJpdxsQrKYDeZgGFgDZAH4fwNN4ILAD8YR 93H0BgmO2DnTWt+I7omdM63yW6L7GGBP9/JGdN8pv3NE5rsXMOIIjI9F4MUF3tM50Ceau/sAxydv 5lBRTUyfZkRepVaGPK5XFFwmoeEkqYWENLokL1Y2ycoV5SagYS5CQOMbUMwoAkhJxaVKYTPI+tTu ryxtyHFpNKidH2OaZjdYDWrzO6t5fzF8ZtFLD8wp7QCZfAEp9RAoCF2wdZAwKHO2wO3dRcfuGMQM SiDyLJVXytHpDS4ycXpS26Mi1fKV+sRuiapF/8DAKpReFPBmEwU8aAdxWEAq2+lAzmLWSqdcIF19 nLUC3xjNWYDBheVXWFKIJd1h7nUX4JxCaOgjmHGHgFmYmz2ZtXL5W8F8ttqPHHtg0IA8KZ8L6w8l 1nuQ3oiTs6oyLuLyEQZFnJxVpYqtxkM0lcSsFWjGsmVHcBi+3vuOrccdR6q6AH9kN7C7yMNUdW7L XxITJS9tqmsbsUlAs1ErGTBCq4Z3lKqfFU3bV/1EobG5kaKF1E6KZoLcgSu5Sk1zkJuIIwaq0Ddi amI/UuW51Sy3oMtigDev6rQx/n8QaJSg6JtBz0GgbLZAz5zDc8xnbEMPakgEeBg82oFHQRrjuMFl Tl8/KvPCxtYSq0LO8Y2rmNyDboX1HtihJxAcYj1Tor8PmOrESE2YmDwFybYPm0pfXOcSht+3qn1e Iw6WKG0o/zYy2VHAXV57COoFU7w77a11PV9mrSPRF7CrrNln//y0Z+EhZzkS+trmvvBoB5LQ1qxt jfYpCyv0kIOPwJCNW5KhZYyEe9QDj2uyHcBBhKhri/25qMQODVIosU+vjG7WS6S0Rzglm0AhMP7x 8BrKpO1gkwI/h7xIp6m9Ty7VwI4Rhz+UrPoVuyuRKTHAXZnyDFjvS1SmhEyNcmcPtvgS9hllzmnP GGAwIqwusKd0XoEJ0a0Sj4K3jS9ARv2IL7lqyiqbDEss4yAZEYevlKhtSegtkFEMcJeMHrf1AtbG hvSEmgArRFqnAdoy4aytkfC+CyxlWoI6PHEisP5BsnVggse2EZSIVfCd0EpKxGnkzLvW2MjHoMmq 5kWd2pNBmiSO9inhQv23QZMRwJYmiS+gMAMSwAI/mHyWjZ6NT3IpiY0RxjPwGNDmc933Zt3zOGhi bbcNNxYwzk77rV68dxkrPAKP53ptJdF/AuZbj4h/HH6b4h9YLboLg7e+UEe0M8GLWxH/McBd8Y+F igsgmk894kRLPXaKp02Tfc9l/MOh/khfYrL0BwgrW7eTgPYZ1tDOn7pAF2J7K5qoK8gYpN2LLfID oT5Ys6Jp+mBNHNo5yFg0IQ6BjL/OgiMy1PZrzbPE6tOvgRKKl0loo1UbWOt8dYyrlLRX+CSghYXZ mCjpe0ThgSrqhDCE1OJIDiou4tSYrKXljdsMWCRQwPN8rO28dA+7dY2P0yvtNW/VHgWVRuHVPZi4 xejH5QyLkEbJEyXXfGDridORslK8UMujQZzHkaXmRX81rrKi6LH94lnRxERHyoomoNmsqOjx0JhZ 0RVN21tOUWhhVjQbJSuamOYgNxGnI2WR20PxS6NBnKnxBt7q/aEo4B+KqqKjfXylKOatmiDWdq62 QOscjaI/Ms1zlZrj4B4T5zos3fcOzIR7TL3F1mQq4oDpc7yeoOLAlo+v9inLHr552/jnUb8aE+9o kNie/o0q2ZWWHEGmJpdgkN6IMzVSGbf8NrK/UcBLZH/RJmnVnvaD3fNOpcU1Dko/2xMeJEbIH4F6 UFLhsfy/oXECRtDxGCJLGZEl89QSDpIQcZZGyprXt1GsEwXcJSE0a/vRuf4Jz1guZN5Jwb8JKOf7 7vHxhImVK7F7fMZQbWVudVpinQbphDhzImV2S6ImBngJUYPO7CV8B4szTmBrVxSz9YXviRnRez3Z Nes3bsy2ud1uRRP1ofAENAxkkEdsm1uIVjVJ7zrGoZ0HgZ4Vhmz92alVLUJzdioBbbwDYnW9Qr4F ++AacsbfE8HbX05nWIow74RswzIEW8TyL9t44hqjZCATqA9eGE+cgZRCxDXnfHWB3DgKWMqIyom8 oszIRFmnl2BgJ6hD6pnk9Q0Igji8K2ptZejSaBCHd60ZcIPjhTlxXMzeDCZu8LMOxHExUZRc3GA1 iEM3Iq/sQdguGm/R4EcXgdoqdD8akwA/yo/GJGA9B194HxoY/g8KXZJ3/IwkSEUpuEpuED204hpy eAoh0lNYlv69VOhi4nmHRRN4aKfh8PY/ey0RXkTUD2QtccVStHsTAmpbM39pAMbaBKBA/bMxvv78 uzfMDHrJ2Ka73cb9+WB62A6baGPzVva+GW2r2hb2J+6UvcC+uT+oufNl6BXtEf7aGXvfTviGzN6H /9m/BsGa79RuEHZUZpBW7ufetBFbZj20MuRSwadts3RWnMHnI/u5slX4viM371S5fxN+cHDc2KbD Or5VM9h3lPbyRnhVWdkkpQfUfNi2SDaYNB1HtqNBtOnAtXSvwk8O0va0M2cz+sDsMNzH9I99ntua Yvvc2KZCuZvpS5veuaKIQDy3Ip3fM7ahJsks81UhNSmnH+wNSVn/Aksb/DlZLAxjlUZCCVfsqi19 a3tvR22sXCHsYWa5Vs1EZq/wqNd+n4mYlPp+NFUMTWv6prBcn1m+K4wgyI1ksFGmuUGr75D+GAq5 8brzOoVDZ8KgU/8PATHyuA0KZW5kc3RyZWFtDQplbmRvYmoNCjM2IDAgb2JqDQo8PC9UeXBlL1Bh Z2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUj4+L1Byb2NTZXRbL1BE Ri9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDYxMiA3OTJdIC9D b250ZW50cyAzNyAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0Rldmlj ZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDExPj4NCmVuZG9iag0KMzcgMCBvYmoNCjw8L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTk4OD4+DQpzdHJlYW0NCnicxVxtb9s2EP5uwP+B6JfF RcOKb5I4BMXSpts6tF3WJiiGtB8cx0k9NC9LmnT99+PJPoZ6YRSpJwcF0otk6k53D587Humwp7ts a+vpmxevdljy7Bl7vvOCJdxqy07GIy1SnitmM65TzYQx3BpmbMozwS7n49Hx4/GIvXzzgrHgKWL1 lH/HI8ONxNE6FVyIcPSHx+xsPHq+Nx49/VWwzCnVbO94PBIscf8ESyVPNEuV4iJje6fjUQI2Jey3 8ehg49VkU22cwY+vk3xjDsKlE4orcyd8nXxie3+MRy/d4/8aj37YGJEkXMSM2SRXpnke1baDLzsF 4bh4WScwJ7CY0Ha/SdgDYd8J70B4i7f8lSIEV12f2i5E778BYeqE73hFgpA4IQHBEodBJ4pbGwsD K2urzQNJPA+k5lJ2tkIRWyEMl2lnKzSxFUnKlahZsQ0g4PBDOUjwEn52kCUAsAsQTpAu4DNvQTjH qQQEckU9p7UbmcdMb3OgoXWgceNV9zCmxFbked0XLvskCmybOXsYI45C5rwvmxUfuPiHiNlzwmdE Q3Fl2wkXIFw44QsICyfMkJW+4pVzn5vgYe/xGZcg3CD8ZghIT7XwjBO8siiR6yPk3Jfw47X7rcD6 3054hCOuEMKshOXPYXpkKBRXvmAO+Y6Wny0nBq3PlUlhfMTpbZjLiDGX2WbkR1IPrStswtOYCacY lhkCb4oRWWB4T1FgYXinJbxF0vbHDXw+R5yB8KQ07IMTirT+nvjFpZbcxN68UP1xgpbMSu8OVw5L 09Dj9yScJ564L1E48jGdDsDnygieyTie7kZ1To3qhOumubVOVDea0JEzV1buYhzPscI/x5lxjszl SXqKWLhagpoYuUK7hBT38N1xtsRxduN0FW1ryZhNiqsZk5o0rOEq9tJDLLpghRdR9hZT7i5S5Tt8 628IQZ+tL25ZaLVA8wm4Sk6rGeDT9v5A6F2PC6XIYd3a3Yee4D0xXKNH5yVHlaoZf6tcLJ0hSxS/ XSMx+PwxCwPmn3GMcbikThTWcmFjTmkjEJEQM4iBRPygiaLRAmrgI3c0KhuIOhp1NaOeOksJmUN9 FQluC8SIO3ZGK26qZqwlSTUpriapLSxIpkgMQAPfbme/E46c8CxGLuHiitWY6gg/6JdTde6CK/uI hFUXrVrp3kGEC6yJvB4//AiHXyw5svowXyQfDVEqqcwACJuj0IpC4n6ZUZo/8Dqv0YKtWkx93xoi dIoRWjP+iAsBR0QiGgJqXe6jeUTZD86nqrer9USkijtBPYvbOTlIa/peHq5PNeKmsJGGpw9cVDSb AFEt9/B83XgVriWvEQILjOOZN/6+fRnyhWdiuVRx57bEmLjlbkTK0+r2w1qSepPialLfriVBH5pZ OOfrE3fhSRV+28EZfojIWOCKwjfKOqxDqpwwx4f5ob4V7BeOU7w1LYEv2OUMddyf5YdZ1DQHpxWc 1NsZScbTph26NRJQswm+dcVui7JVfG5CQPhsPkPQnC4BsVnpkx2iUFz5XstaVwj3+WSohphSPJFx n7eEnngPSdsc2rDr56VGxU28dIRlmacSv8lzjpO+3gadLgkoRMV0EqxcPA6+lACxCNPbbd+/KPJg AXoDQoqPnSLLfUHU3dGY9QRYhnFQxoagZpMqVp8MstqIhKEVhsTbSjq3PHtYBoqYMEf/zwaoUYSr UUweU80nq134j5N75avu5VkARr9B4Idf+afWW7Rezz9hdVdeHvsZ4tcGQTnZVjAMgvUYyFqwTrzZ pPOE501Tbp1YbzTBV0se9MGm9lBNt6g7WqJCvDWkM8Hz7mtBSdxf1u4/e9fRHD2pHs2BPbw/QdhB AW69LpU15Mf5XBEjs5i1rU4j7phq41bzPWJH3DLTWte9sZZaqknxAZQum3DkxRfDQdXrUgp9KtM2 ZkprKIhbKlqZXoggXvVrmfGkhzeI13da5Dype2N7mXzDxOxb+D+FHYFtLMGPajUG+TE/5a7lMYtb HUe9OnKg7hE+6uIYtsfyh+CVJsUHt+eIL0vdl92w17IYJOtIxTMbM4t8VxLKkyym7Xesq32zej7x bc0BSliRptykMWtaIUlcwyor6qep1wHJRsWY6vYnwU5QcSDhGKHolxb1bTz6VKgl7KhETG0NFXFh q3IJpVrng+/Eha3K1AMhpknxwfIk8CkuUX0n6Oewl1xls1WSvMYe1C84fIYP46UkSn0SWORufMSV 94gocdWtUt0LWMRVtzIGwtzZDOKKU2mHth7eIK44laufdA9vEFecyuXOHqe1FHH9poTlpnsBp4gL OCUSyN2dzaBO2ongaQ9vECckaSU0PTt/B4o4Iclc8VR1N4OYRWWmedrDG8QsKlPDsx7eIGbR1WGU zmYQs6jUWZ+epCZmUalynnfPKZqYRaW03PbwBjGLSpn08gYxi0ohenmDmkUTyW13bxhiFhVWw252 ZzOIWRQq4x79IkPMosItOUSPb6cSs6hIMy56eIOYRYXJ4QRW1YxdvwO4XFrRrpFyN0DGVFM3pBzq 8pgu6nZUsXEX0XVnMyrY7b333wwoVsf/4f7wYhJ888Z3hf13vm/wVrHNcFg60AAfFLhv5Y9AVP/u wI//fYMDJ+xif+cEDSpuCVT4aZhDpJGYNM22/wFqHiIBDQplbmRzdHJlYW0NCmVuZG9iag0KMzgg MCBvYmoNCjw8L0F1dGhvcihEYXZlIFRoYWxlcikvQ3JlYXRvcij+/wBNAGkAYwByAG8AcwBvAGYA dACuACAATwBmAGYAaQBjAGUAIABXAG8AcgBkACAAMgAwADAANykvQ3JlYXRpb25EYXRlKEQ6MjAw OTA4MDcyMDI5MTIpIC9Nb2REYXRlKEQ6MjAwOTA4MDcyMDI5MTIpIC9Qcm9kdWNlcij+/wBNAGkA YwByAG8AcwBvAGYAdACuACAATwBmAGYAaQBjAGUAIABXAG8AcgBkACAAMgAwADAANyk+Pg0KZW5k b2JqDQo0NCAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiA1MDAvRmlyc3QgNDY1MS9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDM5NTY+Pg0Kc3RyZWFtDQp4nJWcza4lOdFF50i8Q75BpR0R/pEQ0jdm 0oIhYsAIMWkY8P5iL5+q219138qzGdDleyrSdizHjgifykv2676yrqgrxzU1nle79cO6Wt5X3Veb dVW7etNPcXXZVl596adxRRtXLT3cr9pXrHkNzdD7NZom1U/9yq2f8qq+rqFHNRxY3dfQBzGusfVB v2bT4utilHnNuKZW0MpLK8xxLa0w17WWTPa1e176663FVr/21t+Hdh1ddvpTM69xtXbLSt7gh55r jXn21XrTM/Kry8fd9OdKzXi16JpS84Qc26k/9eHWfKmta4mW2vvWfKXNb81X2v3WfKVNN33Whhxo t2YccqHd+nRol9qXGMoN9iOY/fBtky3d+nR1jDXvGhjr08Vqt2be8khuaDDYvw7hZg7tv99yqjWd xz1xVSfCx62VBpyd1uttYTyv3jvGS4PCeGuAw/q0h5wTEQ3kXdPJ9cCnzkkHn2jmHHyimYvVu2au 4BPNXJNPNPNgv10zH99DMw8dVAvNPLUpwdVAYdRCM0+OJYiifnhrUBhr5gXx0Mw7MNbMe2Cs6LoB KbfjZvVsGsxzPApDsWkZGhC+2kE0IoK47g1jhWovjKcGHLoYRXSMNXOM4Fg1OOepmVObajqqSAWm TlohzhEp8qMSYxSDg4hg4KCiPQYOooeBgyhi4qDONSYOShUxcVC6iIWDWjgWDop+bByUSGLj4NDM Gwf113njoIIgbxzUeeSNg+iV81R8aYCDisVsOCgJSYgy1gllx0HNlR0HFTEZHO7UzMHhSlqZJzw1 c7K6AjeTw10omcOV0rI4XC2cx3eFV47GJyQPUoVklwPtyf+ciqamKM9ZJ6g1QFaSXq4gqDXzkpdt kyWQi9SXW2feZJeb1QWr7pcCNEiMpwYL46W01DDeGpCTpMFi+i4NVidONWn1gVxCAz0h3SiLEXrS YMXEWDPnjbFmzsRYM+fEWDPX0ZZmLjkokWmw0JZmHshFGqwhByU7DTbGmnmiAJLjHEeIypJISmIs ZE5Q1tasKLO2/OrSYG351cme9xFraIBf0qDkhXEpseKX/jcIIg54QKKTXjt+SYOj45d2MAK/FGcj 8EsaHIFf0uBI/NIDI/FL4T4Sv8jIddKAZi78ChI3fiksxsAvaXAMRWWXBse8yRCaeeon5QwNWEKB MhbZSBocZG9lEQ0UBV0RPDZeSINjDzLNVvLX6SnBaID6i3KgAOjk/ZP5pMGJaruITCIOPU9okdRm l76UjTTY5CeViSDT6NN5TlnQZ+qEuzSoCqOZB6VG0Y02lJnIYZpZx6yBZi5FpXKYig98BlVoYaOZ Z5DnNPOUkmA9F5mYErYwpogtKaBTxqhVXZ7MPciFmnlzXtSim8wnDa57kh1Vtcj6XdJaZCxq7EJt XbtcRIrypQbysuvT1TkUaXAFWVZElvKOBpo5b3KqZk4ORfteOXlKMxdbVTCtEnVS4Spgyts1qAPS 4BosodnX2Bhr5klqp86eeJYGl3Z/oailxS7Sis5WWU3SW/vkZk24J2lbVfNW4If2tG8Sp57ct2YO CunJ1grTjbaU0SnuyqDS4ManEBGVQXI81ZmcKjslSJoP1WclMg00YeoclP5VsTVHKPJ2kWWlwV2b pyjiwVOaUMGqgdaamuPU/Ymx/NeWZSzp7UWy1+Ht41en1iv4VUZoOLTDfqo+mybL3vfks9MANMrO ZkQFIdXdpD+OSV2BZgrq+k3gEaRqEG5qD21AKPiD2iMVJIWJroE1gjXyVC3WSNCQp2/EGjQDQqs1 kjUKOskaAzwUrJvojdOXSCsascZxmqR6H69P67dgRAdxr8mzrEGmCvL7vSmgVLl7rzx9n/oTYQvJ U6PTC9J03JsCWTQtwd/SdlDIVDTpX24KKl0KSYVD1UjSiHGaGvyVWDRitcEaqpbXqdKq+3qCXkXV ndrLGkkwUUlUqbVT6qkKM8+eTkgReKqciiwFmDUGp0Vpb3QnQQd3WrOYrDE5LcqPit6gdjPitE6v tTmtyRqb05qsQbEKamI/EUHbp1KjNRYN5s1pUbM6HRa+aHQaZronalvQuHYSc1A+O1mFdlqACGd6 xc7pxWlgmTVeLazCOk4TmyjrdHV03EEjq+SpNai5SpF0E6wxYE+DqXR302EwkjdBS6scRh9ymjud ctLVdjrVvE+jrMhJCrWSjGo27YpyCs0Ia2xFDolHI5oPetugdic9bdC4JH1EQINUrIOWzpLqHqdd occJim62044rRrPRIJIAqVdqHiXaPP0kEZd01QGTbKejZH+0BApqnmA19RFqe1ijgk6INYp2Cf0G LXueJnSwGq24gka+9dOGagb1TowUa4nOdcg0VqxBE5Po/HRwic51KFrjdK4kwUTnQrzot+hdtfPT VQuT1kDngrNpwmhoO30ZLSltYaLzpKc5/VhSkBOdJ9WEvK6GV8ToWDRKOjjWIJKob8qr8jDRuf5D W8caqZPP0yOrC7ry3PKKLjJPl6xToR3gqqM10LnaORpA1lDV1Yg1VCXpBRnRu53GWuXoQpHt9HRc /iTLm1aRNXZyy2SNTdOJztXXnf6REbGGztXZaY3TjXPh4MalEbGGzotOJ9F50bkkOi+UkuNcx266 T3pych/1QCPYnxae+El0XniY6LzoeE6TW0UkovMqbrDoXOmUJpY1BquhcyWVRhtLu0/koHNdgbgu s8YkctB5LSIHnau4ag10XovIQedFIWFtjYgcdD642SU6V7qiMeYGQE1JdD6oKYnOBzUFhWtE5KDz QU1JdD6oKXluGNQUTlsjIgedD3JaovOB1hKdD2Kgzu2VvdW5vlJT6txfqSn1upa8OnDuJYqcQufq AfmGgDUmzTOaHlzfC8UrxaqlRfEKIXp11ljFlwnnLiMfCp2rF6SBZ42ts6Xf1r2Ghh2dTy66hc61 hNZA55P7Lh0bybvR8zMSxULnk8a50PlpCvFFIy4S6HxShQudT+pEofOZ53rAGmitXrcmvvZA55Nd kkk1kkqoMBrp9Aqdq4TqWXSuzohvSFhjcEl5XbCC+wZrTEUO3xiouHC/QOdz8WUKOleK1RrofG6u BuhcF0VuJqyhzkMjblNqFa5zAV33ONcVLmjcadD54lJc6Hxxoyt0vs51BJ0vemk80GhxseG+Rl9T 6HxRXQudL7J+ofNFNip0vlDJH/7w5Scl1eu+/vzlL1/+8u+///zlp39ccX7+03X/8Y+//933Jj99 +dNfr/a368PsByb9vUk8mnzby3yzl7Rm2W9mKWsWYf/hNB827zY83pOZ703We5Nt+STZvDns25tn vJvHiJr2HDYfa613az3H1svGixyJ881aXuxEfzePERjtOTI+1np7ps/h8zHP2zN9jrFXJniOn5eN k1GMlNKNc+/P5/6yeT7Tl41xXt1Qcjek3A3OYXAOg3M4qdvgHAbnMDiHwTkMzmFwDoNzGpzT4JwG 5zQ4p8E5Dc5pcE6Dcxqc0+BcBucyOJfBuQzOZXD+up35JOX3JvHeJN+b1HuT8d5kvjdZ7032e5Nv bcajjcG3GYCbQbgZiJvBuBmQm0G5GZibwbkbnLsTxwbnbnDuBuducO4G525w7gbnbnAOg3MYnMNJ GAbnMDiHwTkMzmFwDoNzGJzT4JwG5zQ4p5OZDc5pcE6Dcxqc0+CcBucyOJfBuQzOZXAuJz+/TPb7 cvxkEu9N8r1JvTcZ703me5P13mS/N/lWjh9tDL7NANwMws1A3AzGzYDcDMrNwNwMzt3g3J04Njh3 g3M3OHeDczc4d4NzNzh3g3MYnMPgHE7CMDiHwTkMzmFwDoNzGJzD4JwG5zQ48689/GMW7zEm/6LD 24v56Qb6169cv2XR59n/7+ef//Wfv//nn//6+SWt81Wikb4Nv8rwq4z4KSN+yik5RvyUET9lxE8Z 8VNG/Ayn7rxMXt/GP9f1R5swbNKwKcNmGDbTsFmGzTZsvtX3ZyOHdHNQN4d1c2A3h3ZzcDeHd3OA N4d4d4h3K7Yd4t0h3h3i3SHeHeLdId4d4t0hHg7xcIiHlU4c4uEQD4c473TxGpHK8sWbGO1VMz99 kncd/38yeuPOr2rkmL/UyOdk6TiXjnPphFM64ZROOKUTTuWEUznhVE44lRNOZdUnh3g5xMshXg7x cogPh/iwitRXG+Ob+UebMGzSsCnDZhg207BZhs02bD5aBucr+mcjBzVvD/GK1XVeFPqlED9/AX7x SnW7ztvunz7AO1SvJ37zxsaKT6xeCD/fMG89/2iu+sTqNdfn8fGrFXnFWj+eN6x/Sb4/8P37fM37 2q9H+9c/4/0U37cDzpfxz0ZO8HYnertz7t2J33DiN5z4DV4B5y2LqI8y7Dzm7DI/32V8XHJ/G2rz E6tXqDmnEK8r8HmJ3guTdBh9doH/3LPef+jZ/sTq5dmP5qrvstoPWH4/V7xeXfqfJNbjxax/VWk3 VPp9p+F81/5s5JxCOZm2nKpWVllzckM5UVlObihHdeUQHw7x4RAfDvHhEOfXautS584v1/JrVdd0 djmdXU5nl9PZ5XTiYjpxMa2Gx4mL6cTFdOJiOcSX1fO8bF4J47kDfbQJwyYNmzJshmEzDZtl2GzD 5lsH+mzkkG4O6uawbg7s5tBuDu7m8G4O8OYQ7w7xbsW2Q7w7xLtDvDvEu0O8O8S7Q7w7xMMhHg7x sNKJQzwc4uEQD4d4OMTDIR4O8XSIp0M8HeJpZXCHeDrE0yGeDvF0iKdDvBzi5RAvh3j9gPj96yvV x+9CVH5i9V2H+yaiXlcqfjfy/nYteE7GX22G0R082YRhk4ZNGTbDsJmGzTJstmHz0R08Gjmkm4O6 OaybA7s5tJuDuzm8mwO8OcS7Q7xbse0Q7w7x7hDvDvHuEO8O8e4Q7w7xcIiHQzysdOIQD4d4OMTD IR4O8XCIh0M8HeLpEE+HeFoZ3CGeDvF0iKdDPB3i6RAvh3g5xMshXg7xsvL4V5tlFPEnmzBs0rAp w2YYNtOwWYbNNmw+ivijkUO6Oaibw7o5sJtDuzm4m8O7OcCbQ7w7xLsV2w7x7hDvDvHuEO8O8e4Q 7w7x7hAPh3g4xMNKJw7xcIiHQzwc4uEQD4d4OMTTIZ4O8XSIp5XBHeLpEE+HeDrE0yGeDvFyiJdD vBzi5RAvK4+/bF6/9v9cxB9twrBJw6YMm2HYTMNmGTbbsPn4v4x4NHJINwd1c1g3B3ZzaDcHd3N4 Nwd4c4h3h3i3Ytsh3h3i3SHeHeLdId4d4t0h3h3i4RAPh3hY6cQhHg7xcIiHQzx+Q/y/Ie/JqQ0K ZW5kc3RyZWFtDQplbmRvYmoNCjU1NiAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiAxOTgvRmlyc3Qg MTc0OS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMzNzQ+Pg0Kc3RyZWFtDQp4nO2b3a4dxRGF 75F4h3kDT9dfz0gIKddICAF3iAuErCgXgYgYKbx9qnZ/bWxinIIAwdK5wD0+u2bN9Or19Z4pc9z9 OA/3eejM4Tqm5XAfY4zD4zyGXTmOY1yeoxwikqMekjUedsgdOfqhqjlGqqRazMPOlIvrMEu9uA+7 Uq8+G6k38ziv6zO17vxv6hGSenntiPq5H/Os+jhm3dacx8wan9dxnVV3H5dl3XUeV+nmf/fIukuO 27Pu0uO+81qXHeOU+sDzIO/Wr5kzq1u7Ig8eGlce1CSunLTULPLMIXWrd05bqzjvcWhN5NY8qCve qWw1lTuVreaSEsNqMndewms2dyqXJX6ncpw5xzOVw848SOXIWcWZynPktPPjMX3kQSrPvKk4U/kS z4NUvtL6yFsZV4rFmcq3Rh6k8l3ujfOQM/+IXDY5LZVHrtWZBsTIxRqSynkZGbnCMTwP8sZjRK6n pnKaJ5KrFDkl0bxgjDsPrNYllTWNjpQQy8LIBIh5KksqW5oUksouqZy3K5WGkFSuyUW6L6GpnB9L 5ILWQsvMmwpN5Wn5kabyzCWKvBW56lZzGeTKTIam8nVXcSrfUsVRmavijOx5VvGVB1rFdx5UhtJi rQCHjTzIBIdJHtQlckpaGY5cTq0QR4ZAK8VhUSnOa6V9WjmOvDm1utWUUKvV8VT2mlf+Rb3m5alc QY0MnpbZkdZoFUbGQiMTF15cpEnxwCxKJwVnBiTyDvTKyUWyplcCEfmx3rmwkUuud95UJG56Z6Yj E2xnLkhBYmf5k/Gy8y5sErmRRkYxN/KPKOgkQxQ5E5M0IBI7k2Qn8jKmufiR0bGcRh6kcl41D1I5 i45aKrO8YMXUvHxO+szT7EgJK0YjY2EVtEgkrNyKJNAi2Yq8XZsZkMgI2szJRbpvM+Goj+0qn9Ma uyp1GXe761aTQbtz0SJvxe4CJOOVF8/iQuusS2Qa/KylzGn7I9gZZX8EuzB+BDsv449gp8X+CHZi 4xXsmQx6BfuxwVSwZy6nV7BnMugV7JkMegV75j15BXvmmV7Bno9tLc+YZ+2LGYBZG1K5NRM/r2DP 2jpnBmCO2ttylvXT3JxSedQelCs8R209eXdz1AaRAZi1gd25MnMU/Kk6R6GeAZi15Gc6Oh8Y599m JXhkAB4Wj3TiES/JAEx54JfKyWAylsryACmVC9GMXR5U7kftrpXyDMCs6OQa5EGFO8+YtUK1w0+t eKVb8xHTDMCsraeSUptz1CznIxa5OvbISca9NtPzrnTmwXjkLA8kF8bux/ZaC5ObaW6V6WweFEg5 odxVKyxaXzx30ZB7aG29GeKc7/X4fhpRa5vpGFHGZ/hqD7WjtvtZefzgg2ef1K2cx6fPPnv2ybOP vki2vjyeffLX3CDqpx9++P57byq6G0V2dopGp0g6Rdopsk6Rd4qiUzQ7RR3HreO4dxz3juPecdw7 jnvH8X1L8pYaadRoo8YaNd6oiUbNbNRcjZq7UTPOTlHH6dGxetTOk1vNG0vrqfFVO/+LD3/55ptv X3z14m/ffvOozi+C/HnnHjprMDqLMDqrMDrLIJ1lkFbgO8sgnchLJ/PSCb10HJeO49JxXDqOa8dx 7TiurT2m47h2HNeO49pxXDuOa8dx7ThuHcet47h1HLfWtt5x3DqOW8dx6zhuHcet47h3HPeO495x 3DuOe+ubtOO4t/ZxaqzxjPC2Gm3UWKPGGzXRqJmNmqtRczdqXj4jvLWo4/ToWD06Xo+O2aPj9ujY PTp+j47h1fk5f/wqf720OiFvegL6GcHXn4CqQ/DjE9BbA99ZBuksg3SWQTrLIJ1lkM4ySGcZpBN8 7QRfO8HX1h7TcVw7jmvHce04rh3HteO4dhy3juPWcdw6jltrW+84bh3HreO4dRy3juPWcdw7jnvH ce847h3HvfVN2nHcW5s7NdF4RnhbjTZqrFHjjZpo1MxGzdWouRs1L58R3lrUcXp0rB4dr0fH7NFx e3TsHh2/R8fw0XFcOo5LK9sdx6XjuHQcl47j0nFcOo5Lx3HpOK4dx7XjuLa2k47j2nFcO45rx3Ht OK4dx7XjuHUct47j1nHcWjt4x3HrOG4dx63juHUct47j3nHcO457x3HvOO5vdlxvij57/vWLtcb1 g/R+DbGGuYbHi1VObw1jDboGW8M6wal8qB+xToh1QqwrxDoh1oViXSHWebHOm+uEuU6Y60JznTDX heY6Ya4TrnWha51wrROudcLqix+rw31c67xrnXev8+51vXudfq/T73Wf91K5l8q9VO6lci+VcZ6M g1EYldEYnTEYJ+PFiN5Ab6A30BvoDfQGegO9gd5Ab6An6Al6gp6gJ+gJeoKeoCfoCXqKnqKn6Cl6 ip6ip+gpeoqeomfoGXpkcRh6hh7hHKRzEM9BPoehR1AHSa1/x10jemR2OHqEt/7Reo3oEeNBjgdB HiR5BHpEepDpEegR7kG6B/EeEz1yPgj6IOljokfkB5kfEz3CP0j/IP7jQg8OBiCMCz2IGCAxYGIA xYCKARYDLgZgDMgYoDFgYwDHgI4BHgM+BD4EPgQ+BD4EPgQ+BD4EPgQ+BD4EPgQ+BD4EPgQ+BD4E PgQ+BC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQu BC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBC4ELgQuBB4EHgQeBB4EHgQeBB4E HgQeBB4EHgQeBB4EHgQeBB4EHgQeBB4EHgQeBB4EHgQeBB4EHgQeBB4EHgQeBB4EHhQelJwrOVdy ruRcybmScyXnSs6VnCs5V3Ku5FzJt5JvJd8q+3OuR36V/Cr5VfKr5FfJr5JfJb9KfpX8KvlV8qvk V8mvkl8lv0p+lfwq+VXyq+RXya+SXyW/Sn6V/Cr5VfKr5FfJr5JfJb9KfpX8KvlV8qvkV8mvsq8r OVZyrORYybGSYyXHSo6VHCs5VnKs5FjJsZJjJcdKjpUcKzlWcqzkWMmxkmMlx0qOlRwrOVZyrORY ybGSYyXHSo6VHBs5NvZ1Y1839nVjXzf2dSPvRt6NfBv5NvJt5NvIt5FvI9829vkXI/dD3o28G3k3 9nNjPzf2c2M/N3gweDB4MHgweDB4MHgweDB4MHgweDB4MHgweDB4sP3MDQ8GD7YfwvdT+H4MhweD B4MHgwfz/QyPHjwYPBg8GDwYPBg8GDwYPBg8GDwYPFjslwT04MHgweDB4MHgweDB4MHgweDB5n7r QA8eDB4MHgweDB4MHgweDB4MHuzarzHowYPBg8GDwYPBg8GDwYPBg8GDwYPBg8ODw4PDg8ODw4PD g8ODw4Of+z0LvbFfuNCDD4cPhw+HD4cPhw+HD4cPhw+HD4cPhw+HD4cPhw+HD4cPhw+HD9f9Roge fDh8OHw4fDh8OHw4fDh8OHw4fLjtV0304MPhw+HD93sqfPh+Yd1vrPDh+9V1v7vCh8OF77dYuHC4 cLhwuHC48NjvwOjAhcOFw4XDhcOFw4XDhcOFw4XDhcOFw4XDhcOFw4XDhcOFw4XDhcMF/6vY4/cL 1ogOPDg8ODw4PDg8ODw4PDg8+L3f/vfrP+//8BDwEPAQ8BDwEPAQ8BDwEPAQY/cT0IOHgIeAh4CH gIeAh4CHgIeAh5DdoEAPHgIeAh4CHgIeAh4CHgIeAh4CHgIeAh4CHgIeAh4CHgIeAh4CHsJ2BwU9 eAh4CHgIeOAfxB+/GbBGdOAg4CB8t2TQ4Xsi4CF863Bfu6+zGzu7swMPsVs8u8cDD7GbPbvbAw8B DwEPAQ8BDwEPMXfPCD14CHgIeAh4CHgIeAh4CHgIeAh4iGs3o9CDi4CLgIuAi4CLgIuAi4CLgIu4 d3eL9hZcTLiYcDHhYsLFhIsJFxMuJlzMc7fL0IOLCRcTLiZcTLiYcDHhYsLFhIsJF1N2Hw49uJhw MeFiwsWEiwkXEy4mXEy4mLobe+jBxYSLCRcTLubi4suD7uXnP/zj+bPPXnz3/dcvPv/u+fNPv/32 xbNPvvru+TePvx6LmtXcXue98unHz//14qPnPxxDEPv4+7//84ss272mY78sH/vt4tiPT8f+fjh2 0A+SXb+g8Th4/A5AHdzHbtacx27LjGMFb03k7S3X/dW1d/A1vLGtuuEgsywlK7AGfH29Z0qz9KlL +lqX9MvjsTS74/nUMV3jO9ExXWu35/DUPWX8rbqnv3b8nbqt43plzXdn9akDu8af68D+2vFP1rGN +cra7+7tH9XF7Y53a/ztusC/dPxJ1/g/usW/dPx/d5V/6fg7daHZn5X9WtmX9dy+73XdPvFz9kFd +97K9u5IP3W2Gf/snW06guf9yhru7vVTt3uN70S3m7XbtU+d7zW+E53vtXa7m/rUBWd8J7rgrN3u eP9RHfGfjk+d8TX+b53xl79XXmu6u7J/2m75T8anrjnjT7rm9sqzzcvPnjrpa3xHOunvv/dvlQYv /Q0KZW5kc3RyZWFtDQplbmRvYmoNCjczOSAwIG9iag0KWyA2MDAgMCA2MDAgMCAwIDAgMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCAwIDYwMCAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBdIA0KZW5k b2JqDQo3NDAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDYzNzYvTGVuZ3Ro MSA4ODUwND4+DQpzdHJlYW0NCnic7HwJeJRF1u459X2ddDpbJ4SshHTTZCGdsK+hIR2SsEUgQIAE WZJAIIooGkBFIREHl4ACriiMMO4awU5ATQAhjLihiAviOoMoiCMibjgzQvLdt6q7Q0Advf/97/P8 z71+J+et+mqvU6dOnWq6ISaiDgCdeuZNHDUipK5/I/HQKKKEh0fk5Q+PsoROIjq1gUhcNKJw3MT4 e547Q/TtF0QDJ4yYOGlYgGn3D8TpLjRyaNzEHr3DnRcPI+JGtFo6OW9Mce+GMaloq4Yo4q5Z88sW OHsm3kKUifb57VmLF9qeDKtAPHshUeCqOQvmzq+P7N+bqDvaN70/t6xqATkpCP2vQnvWuZddO2f4 kq+TiEbg9U+7KivKZr/zecClaAv9U/9KJFi2CMQZ7VHXyvkLr+l2ssODGHssUdycy66YVfbh1CaD 6LVmvJfPL7tmgfWn4HSUX4fytsvL5lfc+v5FoUTHuhJZ8hdcUbWwNYXk/C+T+Quuqliwc9Nq9N8X 9S31JGVn6tRtedSSrJnhrtPmIDPJ56Hk8WUyfPGB8alG4E9r9DNmJ16DVHn5IAx4ouU+CH2/EWi8 rZ9py/E/mkwJ8dBIxOQjyEo95Ei0I+hXpej7eQ2ZyGy639QHTSZ6Q62M5ohIk0kEakFCmISuf0Lp RjNdk6tGgKdoTK6N3GSjzfrx1mVyJGKum9gwIBetXL9DzpR0fT/NlaURygGfYAvtoKPgVj4ipnMm fUpr2EnbeT99TseQU0cv0CHay5H0Dh3nDryfB1I5VdBd3IHeowiaQtX0ABXTRqqheahRRyWIxVJ3 qqSt4GJqotU0EfNMpkKaRe+KIfQZ1vUoet9JaygTNZahxnu0FHJ4nrbRboymI11Ga5FXg9wDdAdd TINpIHq9m07y3cLFd6FMBKga7cueJqKlc1SHel7a7iPZmp8u9tFZHo9RXE+r+Qo1aiUW3sHZ6CcS Y52PlsrpLvBU8kBf+9NjdITTOIWGYDYL6HM+gXneSvUYy0TMrBr15JgqwZG01vgW8/+IWzgZ7azH yGdB8oE0TxRRGHWgM5Ckkz5BWxGYg+RiSM9LlYomKtrOLvTp4ixBXM/beTAfhPQmo88mSOZdOilc RgvdgNbvRn+ZWL0wXsyTeJZP4+S6LEWbsnQ15il5mXFM7EWfaxQ/gPcW9F6juAYt+7k75Ca5ElIr Rj3Jsp3VWBHJEyFFyRiF4mrMcCrk9Qwn0Dp6k64zjnEk4mEkeKmfJdITkNV9tEYkyg0iEkWiRC/7 H16KXFnauy1+Jf7rj5jrj4DCfbwF652CvadhJDnUiFkKzG8jh2PcQVgVJGO9diBP8CV8CW2BbkgZ +SXnl5JXUkvbeB50dx4NhZx3tOPnUWMbNGs3ZOWXZ41Pnn6ZeuW5pE2Wfk6Gvss1fU/1HwmNK6QF 2JUy3c/Ih3656BaMPgTlgilBmKEfO9hMbuMs5pNj/AgzcZC+Uzu1Aj2+q3ZpCaQh9+idGMds6M1e jGEWekgkF3JnUTlWbSXvoCms03CeTCtpqwiHpuRQEY3mfIx9H8Y9BWuYT4s4DbG14EVKk6tBTUqP 68gB+UfQ1ZSBXuQIpLUYTcXGGbqK0kBXo0QsRuQdRTVGkaHGUULdcHLpau2mQLujMd41kN110Kup CKPwlgW6hvpQEuqvBUtL8ijGfzXmOYaGkx1UgNYfpeXUlW5ErdtRW9qT52ERtlEf42us2DWoMQ89 r8MO70WVIplH8ygeJbryc6B1vA6xAtFV9IdWrxMubSU18evQ7Qe4Iz1Em/hqHoXVreQqrNU2aobV WIH914nGIf4d/UR/pwfpRXqKXqdNWOUVyN1N/8T6foHydyv9bEZek+I3FflbroClPdfuCtWmbLGt Pb4aK7INKU+JXF7FpdyVX+aX6YzApuKP+V7wx/wQeB9/xB/wbFi2H7iai3gAmzmQU+kelP5cjOa3 +HsO5VSOwMqe23/7hCZYaPwgP8x1PJ8nIG0Dl3MpdC9ZFQmmAFXSinHIZw0kr/lONgtIPk/CUn5D 94K/QakHsBdAGIm00970e/lGfhcjf5z3oXwi1sHZFvrj/w0Pxr5BnXBEUdjlFnoNEroXmt/MO/lf apzKWCDumx+/wn9qm6s/zTfXn4UP8HjJSgaSA7yyaQsvfEJ88vGFHI/1bRf6ZQvtPaTCbdjvMt9M V6qwgRtUeiu0Wr5/j7HKB/NRc3mSFqv3udijy+kvtAGWBCzisNrQCyqjiyCRj6AbodCAhyCJ6fAP TFiHfaB3sRo3Ilf2soE28Jd8mk9jf8/jZ/gH/oxTxCxIzYN9k0Mp/AlSPuOveQ9afBlSeAB9vQe/ 4Q3az5fCZ7ud9tNO5c3dTbdCAyPoa2j7TtDLdD/sx008HbQLtJPv58PnpN0mBakpUs6JSh+IR4CK 6Xv6kP+F9XoDSdKewm5iDPdh1+7l17gZdvBFaG4TO7EzYnkG52lL6RVVfyM/z4/wC2qPOxWlKTLa aC8k0P79HA1DaXDb+fl7uf3Z8Ut8DFZJnhn+0+H38oUnR3uepfwOL8sxyD5+pQ734Cg6DYYthH2O gh29RvE8UDnqSy6EZneDbZXn3TCMGW1BH1bxxTySd4NGKrpa7SKpiX5tvGAX/d7wV3fbb+zCX+R7 wevb7dBf4wt37m/s4J/t2N8K5Y72swkkH7/V9O3yn4V+a/obYZt1+JXQby1+K2yTJ6wKvM7vVRwh +JW2df01Dscu9VlT3/p7LZEMp3pJnji4TRTjVGnmTcKCUy6KLCJBdOJ5SKni13khaDP1klZBJHDz havglzoseYOSnoaTfgM957dz7RntZcGXWyEiRQLGcDv9m0OVL3Kv8lU6wg+KhL6Nh/ehg6UXHY3c TMWyRB38Y5lSQ89gp16FbmtwH+mI3fSZ8u52wAp2RKr07FzYXdGot1V5dnvhO90Byyr9ZRd22RCU kp7yXxR9BG9kL3TuDsrEneY4VeBGYQZZMB4z9msgyIK+sHO5R5sf6Pc5Zc9+G/AXWgVd8daVeRaM QHqbF9oer43Zfp4HKtlvB/zefR3I69PeRMfViP2tyB2fdp79kbalEne4dOWBXYqYvM+NVSd8Jd0M Wgqqo4dRdhLOo7n0PHxJ6SHvwK0yApLr6JNeFkqMxSmzlqoU1UFCHwNvBx3APUvSWxidvA82Yj3k nTAHbydxM1tFm6Fh28B16PU69Cpn0ESXw7OrUTkWH5W3xZ7AbTISNJ8zOR2USV/gNGT4Rri1cYsI E2G4b7nVLXAJLRH9caLsBLpwTu2UZ4EqsU6Rizfh5tWHx3AJ92M33l24/QFxB5J3t2zsncHsQu13 EWaBZB/JWpxqy9vC8XOtybnKOvDnt/NB1addtqZqpsnPRbz3QsjtMfhwYXh7kjvzC4LQ306MMw2t m2U9aNW7aNF7vl3Kz/k2UCreenIhp3AMD2INK/EWpDAYJ0A/7yyhwSPgzRJ4LfXGWS3XehXWYSPI jRvBKpzKcuW8urIIsm7CTeQFdWe/AVqzU8W2oV4d/Ru6k4b3LOzze+CXD1L2M0LeuGABu+FckeG1 2JGJuFHInuKxupI7w79300zUi8JMZe1qtLkNUnaJUBFKDEpDu1Nojtq5ydQXO3SNOrli4PfLG7kF +2gK9re8wa2G3Q0ByVPMBFsl+VjbeefAfWKej2SJWErirLZdJHef3AM4+VQN2c8LkIPsX7J/R9wA jysDu8LPsiWBthZiZ1gxI7mrx8MOWtR+jVJywrjgqxTwx7iBNMI3eZ+HAI+CH9FG0acUxZN5GdYR KXQE3tYjeK/D2zq8E3+DW0oPkFzjv/F1Pmvht2FeO1Ynb/o/41/yRDbCbp671Z7P0kORFkRaHz+3 /8xAciy0ws/+zxDaf5bQnrcqW5nZZonaf85wIfs/d7jw84f2bIXOSPbfkaXHIllaKf/nFJInof5A pK3BXMsvoHaPkWAkcDtqn4c9cD5dUE+E8jFYhXsUWy74KFDq7dp2JOtsAO019qqzqT2RsRCUgD12 PpHxlTEZtAyUYATKsasxYixcw3Wq3SnqXr7ot+b4W3P5PX23I7nr5N09Anu0P+QAvWzXtvDRPOXz p8ECRynpyg9H5ecGyPPmtElgH0iGs0CyJjwaWLe0duPxt+kSabAK90FX/Y/8TDEF9i2LPpefCeA+ +yD2zVHY452wxIPR/37+h4+khR3FR2FPs3BDkKViRZivHamlg3H/SIYmyk8RJK2h55ixjw7ASsnT azm4Dtrm4K5K+o/SjaBHaTJGFItTSJ5YJ1HLg7x1eJuHvETYnCN0CLfvCI6GNY5Rt/M58MTPcAwd pG/hKUXCMlzE/dnBwfQ3tcs1eptaYbd7wl73Ammw5Wmw4YNh0V3gFOQORlsXQb9Po2YJtcAzt+GU K4Sdj0GaTOklU86ttGaDX3UT38HXou503At3iXj49v57rf/JolDYrc448RPh63RG3mFqwIickFF2 WynpkVZLCwrPdwQoQtmgGuzcA5DBNdpKrEMCb0Iph/KyJK2D1jbBll3N6+hj3AU/VbeK/dCFDzHO /65bRPu7us+vvPD+/atevd9TvyD038cvvJf/zLP2e+IX3jYI594uoDzR1+O8K4G2n6SxHAefk+Bn HoX2Tab+wGVY0fC2T8kzlS7WQ5cqUH4q1mQZ1mAg2g5Unz/Kf1VYBe0YxOG4Bffi2SANnkKh6MmL QOXwjl1Yv73wrN5FehR0J4qLeKzSnpHcAbf103ylor6cKzWLv4KG7Vf+Qwq0rx/WVJ6L1TgVLrAy aMlLIV660LKxCdQ+XXrsz2N3pMOWh6uzSHoQRQjDEZM2vE7RDvWJnd+2y3MYJzdP8RLtoT1YX+xd zF3u1YUovwC+SbHyteUpJk8teQp4b7fX8Uv8CW4eLuW11eCcquFq76fofA1XwpZeA6rhZJxYNepU WYQTuRIyN1E8JJHJR0BLQScUufyawfIxaRrDqaRY01fBzfQvs4FTP8BopSAKwr3CojCYgoHwS4Ch wLMURqHAcIVWCgNGUDi8jkiFHciqPJAIYEfgT9iHkcAY6gCMpSjj3xRH0cB4hQkUA+wE/Bf2bCyw M8UBkxTaKMH4J2yjxC7UCeigRONHeE8SkxWmUGdgKiUZp+HrSOxGdmA68Afs/C7ADHIAMxV2p67G 99SDkoE9FfaiFGBvSjW+g8VLB/YlJ7Af8FtodgZwAGUCByocRN2Nb2BrJA6mHkAX9QIOAZ6iodQb mE19gG71WW4O9QUOo37AXIV51N84iX01ADicBgJH0CDgSOBXNIqygKNpMLAAeIIuIhdwjMKxNBQ4 jrKNL6FjEseTGziBcoATgf+AXg4DTlI4mfKNL6DBI4DFCktoJHAqjTKOwy+ROI1GA6crnEEFxufY 5xcBS2kMsIzGGsewa8YZ8hN4ibOpEFhB442j8G4lzqUJwEqFl1CR8RnuW5OA8xReRpONT+GvTwFe rvAKKgYuAB6B3SkBXkUXA6uAn2BfTAMuounAxQqvphnGYeyKUuC1VAZcQuXA62iW8Xe6nmYDl1IF cBnwb9iFc4A1NBd4g8LlVGl8jDNP4p/oUuAKmge8CfgRbmWXAW+h+cBbgR9SLV0OXKlwFV0BvI0W GB/AWl4JXE1XAddQFRC3QuN97N+FwDsV3kWLjPdgExYD71F4L10DXEfXGodw4kq8n64Hrle4gZYa 79KfaRnwAYUbqdo4SJvoBuBfFD5Iy4EP0Y3GO7ixSnyE/gR8VOFjtMJ4mx6nm4BP0M3AJ+kW4y3Y mFuBTyncTLXALcA36WlaCfTQKmC9wga63TiAc3I1cJvCZ2iN8QY9q/A5WgtspDuATcD9sKl3AnfQ 3Yb8DPVe43XYx3XAXXQfcLfCZrrfeA1WT+JfaT3wBdoA3Et/NvbRi/QA8CXaCHwZ+Cq9QpuAryrc R38BvkYPGq/Q6wr308PAN+gR4AHgy/QmPQp8S+Hb9JjxEr1DjwMPKnyXngAeojrjRVhvie/TU8AP FH5Im+HRfkRbgB8r/Bs9bbxAf6cG4GHaCvyEtgGP0DPGX2FXJX5GzwKPKjxGzxl74Ls1Ao8r/IKa jGb6B+0AfqnwBO0EfgXcDav+PPBr2gU8pfAb2m3sgh/VDPyO9gC/p78az9MPCk/TC8AfaS/wn8Cd 9C96EfhvegX4k8Iz9Kqxg84qbKF9wFZ6zdhOhsL2Nt2ibLrl/0ubnvaHTf/Dpv9h0/8PbPq6P2z6 Hzb9f5RN/3/JT8/737TpBX/Y9P9o06/8w6b/4af/R5u+/X+UTSf1WZ3kTr5v5i70fiOXl5AOa0Dq X3g0ErCuWbAF07Hvl0LrNsvv0ML6psKyybQyb5rxWTuaZcz62bd91cMBdO4LwkLIrxhdUABD0tXX ACzBIaFh4daIyA5RHaNjYuPiEzolUpLN3sXRNTklNa1bujMjs3uPnr169+nbr/+AgYOyBruGDIVV HUZ5+cNHjBw1uuCiMWPHFY6fMLFo0uQpxSVTL542fcbM0l8a1X/10f5r1f6vSdedU+TOHjrENThr 0MAB/fr26d2rZ4/umRnO9G5pqSnJXR1d7LakzomdEuLjYmOiO0Z1iIywhoeFhgRbgsyBASZdE0wZ +Y7hpTZPSqlHT3GMHJkp3x1lSChrl1DqsSFp+PllPLZSVcx2fkk3Ss65oKTbW9LdVpKtNhe5MjNs +Q6bZ3+ew9bIU8cXI35bnqPE5jmp4mNUfI2KhyJut6OCLT+2Ms/m4VJbvmf44sra/NI8NFcfbMl1 5FZYMjOo3hKMaDBinhjHgnqOGcoqImLys+oFmUMxKE+8Iy/fE+fIkyPwaMn5ZbM9heOL8/MS7PaS zAwP585ylHvIMcwT7lRFKFd14wnI9QSqbmyXyNnQSlt9RnPtqkYrlZc6Q2Y7ZpdNK/ZoZSWyjwgn +s3zxCw5GnvuFY1H5hbf3D43QavNj73EJl9ra2+2eTaNL26fa5dYUoI2UFckDy+tHY6uV0GIBRNt 6E2sKCn28Ap0aZMzkbPyzq/CkS9TSi+1eYIcwxyVtZeWYmniaz004Vp7Q3y8uwlHaXy+rbao2GH3 ZCc4SsryOtVHUe2Ea7fGuW1x5+dkZtRbI7yCrQ8L90VCQttHKtryVEwVl7GCCW2SZTkixygohMc2 y4aRFDswp4ESKgZS7ayBKIanhFHLMxsrcoknKLe01pol02V9jynZ6rDVniZogOPkV+enlPlSApKt p0lGpZ60qRry/XGP0+lJT5cqEpiLNcUYh6r3fpkZixvFJY4FVhsCiI8KIduykqweEL/dLhd4ZaOb yvHiqRlf7H23UXlCA7l7OEs8olTmNPtzOk6SOTX+nLbqpQ5o8ja1pTt6zCltf+HW6A75lVkejv4P 2RXe/IKJjoLxU4tt+bWlPtkWFJ335s0f2Jbni3k65BZrCcIXEwmayoVSTmsrLF+KQzx6Mv4ClFLP bgw0QytVCtuGe6ylI71YYrHbf2elRuMbWUsF56r5hunJcp7/Pvi89/OGF1KrYcB6iigomlpbazkv bzgsUG3tcIdteG1pbVmjUVPusFkdtU1aipZSuyC/1L+ijcb2lQme4atKMIlKzoK2ChpW7+Bbxte7 +ZaJU4ubrDDKtxQVNwgWuaXDSuq7Iq+4yQabq1JFW6p8s8k3KmBoeoMwq6yEJjdRjcrVVYJ6n9XI pNLM/jSmWY3Cm2ZVaXgyt8NpbtaaGyb1cTciyFLB1rCuvWtkGByqwoagPtk5PbRmWgB+GnwArNNM YLUvRaMkYDZYpq5W+Zu0HeQBN4PfBMuU7UjZjpTtSNmOlGytkVh7Tnu2oWsSut62Na5r71M58dpW MsBCW6utxEUsSZvhC2f6wtUI0xGu8YW3aSsbBieF5wThnekU0AALzG1Dw4hxvZtUZIBLRdb7U9Zv RUpSTpy2AaPagFFtwKg2YFSngIxW1yN9PdLXI329Sl9PrJqyd/M15YtsaAiP9qUgkmPRSrTJuNsl acW+cIo2uaF30u6cUm0Smn5a4SatCLha4UyF4xRWq9xqFb9Cxa9Q8WwVz/bFJfZoh0kKwyVqE7SJ uI8maeO10Sos1PJxb03SxuFdhmO1USoco41Q4UVIj0VYgHKRCEdr6js52ii85yEciXcZjtCGN+Ql 9cxZgPeZyBPoT6bnYQx5GFMehCRTVoM3gQ+rlJnAavABsKZKspYHygXlaDmo4UYbbuS4SdPcoGzQ UG0ocoag7BCgW3OpObpQyoWeXJCVCy27sDwuLI+LAjUX0Kb1o55gN7gQXAo2oZ0M1MvAuDLQQ4aW ibt8kmYXqygKoc0XJomV8ntQWmexsqFzkjsnSGyjQnApeAG4RmxrMEWG50ShnCzbAzwOPBNcDd4I fhpspmxvjjtYZItsbZwYp+nQ7m5bXa7eKuzT3xt2SvSGIfG9w3Ou0rpBTN1oI1jDkLthyN0wVf9b ElhAdVJpN/gA+DBYCjwVwkiFMFIxwVTUT1WlAlS5U2ADrEGJUtH++WVMqnYSuEe7VmRqGlLS8JaG Omkom4bUw0BWNWR+IXg1eLcvr4tS5i5KObugrS4YbQ9gtoqFA5O0Lg0iKLwR8uWs8JwBkPs4MDLF bZDmbZDbbVJDhNzEPZCT7SuxGvw02KQ1gbqBUkFpoC4gO8gGwgpqnbF6a0CrQbeDbgOtAq3EakQ9 7dztFDP7XdGvut/qfhv7Pd1vd7/AHaIMVCpK3RaKjpbec4Q5PscqdJpGofyTws0Kr1LoVhjjjp8W enRa6CvTQu+bFnr3tNDiaaFjp4UOnxbaY1poI5e7Y5yhHzlD1zhDJztD+ztD+zlD+zhDuzlDcyK4 hKdQKO1SOExhb4VdFCbylIZQCtrJF5PdDI3n1G32G5KO2Rt1bki60d5oRrDc+3axNxgsE59N6mmf m5ThTUnxBl3tz+togSbxUxTITndG4KuBMwPdgYMCuwdmBqYFpgY6ApMCo8yRZqs5zBxitpjN5gCz bhZmMkc1Gp+4nfLWFBVglUGALlFXcav8ZpC6YLH8arBZ0GjydNAKRMHEYVzgaZ5FBeU2z48THY1s wZlqcgxjT2QBFRQNi/UMcBY0BhoTPAOdBZ6gwouL65lvL8GbR9yCI6uouJENmbQiQbqvTcScseK2 BF9YUiLrFNfrfNttJRS9ODs2O3JoxKDheb8ApT50nntine1fMJJEzz0FE4s9TyaWeHrLiJFYUgDJ SW+3SQwU/fPzmsQAGZQUN1lqxMD8CTLdUpNXcq4c2ZCe10R2GahyZJPlyHZBuc5igCyXLANvuc6q XOfzytUPsefn1dvt/jJDVJkh55eZe36ZuarMXF8ZzVvG3q5M4CdkV2XsgZ/8rEzn31Em+RfLtJNm xTDnf3i4iUbzofrcJfKqUOrIrwCXelYuroz11JTbbE2Uy4d8t4iU0vJZlTIsq2jkQ46KPE+uI89W P3rJz/M9S2T2aEdePS3JLyquX+KuyGsY7R6d7yjLK9k6oix983nd3ervrj697BcaK5ONpcu+Rmz+ hezNMnuE7Guz7Guz7GuEe4TqS2k91NJMw0rgm6pwqwi2QIFLE+wlw6KtC4YqbR5sj12WsF0nfpyC 4aqH4NoXCpZZmTmZOTILu0xmhckboS8rdtlge8J2ftyXZUVyhGMYxeZfkoe/qipf5Hf+VVVVLZxR NaNKhuqvauEisFwm+WXwhYQZ5ISo8y0J1lja5pXgVcpGa1VVJQtJrWnVIpKtLZRwrvG22CK0zFXt lYCqLnykZjjJy2iuahGjlCy4yKc2VfInQ2iG5CB9rRDpx8F3UALCzlo5TmwyDvv4U/mLbJnf2mIY 4j0ULvKx9ykC3a2wiMd4Q5pNB9V3r+9FWh9+g54gN4Uj/SBpTFxMLrqTrqZ3aZLxLVLt9BCdogwa RJVGq/quXSsvpYfY++vXgfSO/L6ZcGlO/QSMYzr31Op4OWWilSK6h2LoAFpMNyx43yoShQu1iug1 baY5w+hpfMfN+qtGOT3ILnFI30Kv00nuolPrjcZKY72xgcLoBy2x5QWjlzEftSZRKS2i6zGCGnqA 9nOJGCJ2G7eq3zhXIPU5eo2dUKhSeHQTUPpPtI6aaBcdoPfpGDOHcxrX8Dt80EQte1v3GqOMcuMK yqexVEg1yE3kZM4RU7Wp2mbtvZbPWj8xOqPtIlpM19B1tFr9/vs9+oA+Yk1YRJGYpG2mBBqifpm8 FjJ7AJJ8lQ6zmftyFrv5Jn5KLNa1lr044XXqCAmOVNJfS+sh00foadpLb9JbaPNb9Y3LOCz+JJ7G S3kF38538SP8FG/hE8Ik3tc07Qb9Jf1E6yHDYtxvPIF+E6gT2eDrZmANLsJ67qcvMb90zuBsfls4 RYbGekhLa2sfY4RRbbxovEcOSkXZIfBr82kMTcGor6UbaQe9hLr76Q36nP4JKWls4UjIwsYOnsAT eRFGsZlPcYuIxvoNFJeJBnFQc2r79Sn6lpZtrR1bG1pPtRpGneExXjBeV+vbH/3kYgWm0wJsMbli z6CfF+ko/YNOo48ATsJYR3IB5rsO7R/ms1Ans1gmnhIGvN812qt6nL6udWzr/NZ1rVuNvsYY6JYG pyuO+oKyoE3yu3ZV6nuxD6nfZmyF9hyirzmWO3NPHsWTuZhLuZKv4AV8JV/H10OqT/A23sGH+CP+ GlfHANERcnKKWWK5uFNsE3vFIXFUI20i7jBXatdpd2rbtDe1L3SrnqH31Mfopfq1+hITXLKAaPPr Z2POzm8pb7m/5YXW7q15rfNaV7buaT3U+qkRbOw2jsEV7YkxltBcjHEp5n8T3U4boR9PYoxH6Did wJp/B1loHMTxGHGSWrdcjHsMRj4FLtMcUCVfCvnXcB038E5u5j38Kr/Gb/PHfAqX546iO2gwdsEk MQdzuF/UCY/4AHRa/BvX8gytt9YHt4pSzOZm7RbM517tY+2YLvSOei99ol6tv2zSTLNN95jWm/aa XjF9GWANuNhnI85ZEPnZ7Otijz5Uu4w24XagaV+Kt4WLl4oz/JhI5D3oLRH3rUKRKwbDN9oBLZ9P UYHrA+wBdhFF1sBS2Ya4T2RqU/QULYQWyl9liKniJlFKj/JOOiNGQtMWa/vFJjFTW6/foQ/l93C/ 2KOTCOUfKYdyeCjW7h26EiuUqT2ty99lksmsnTXNF6HGzfpxk9Dehh0cwkLbx1P5JBeKaEhrsLid HHi38kmEo7ADP4DmN8HtHKh/oq0So8VHSLuM7uQ9mOMOukzs4AexLgOxH6/iQt6g9aJlfCWkMYgu FXdRF7FAdIE+T6LveTl3xM49g7XpKuaQroWKWXRQlGDV3+RI0Z2XQU/n00qupQxu4WZ6Xayl/lyh 7Tob15Im+OxJrtdGUj2f0V/VX4XzfQaSTITmmuFwH4FOr0cvL5FdS4HWDCSTwD0O+6kUez1CnObr xWV0Ca/T/sGPiBwaRxValRjO97Se1nO0PpDYdliT3IBBZjK5TIl6X6z4cRqqfiNFAZX6YdNyGdfe 0X4wSgx760xTWOvHtATSGQnrthJ7aSR9yNE8g8frhijQDWMy1Ymn9Y+NGA5hO71lYIe1PsMu7mrY +EojmMdDw2fI/6NEX6mv0Bfp1+NsOgOreRPdQffTX3GaPIxzKxVyvAjSnAbbcwnOiJ7Um/phdkPl vzTQKOQV0mTY01JYyTl0OV0Jy/tneorqcUIVQB4zUG8OXYr0KpxQ19Ey7P+baRVswD30KL0lnhQb cce9RbwoFotL6EP6UHtZc/NkOqjfqlfTRNyBx3MH9DwAq5SEequMd9BbN0qA9e+LXQq9N04Yh4zH Ww6gvUflL8IChtGJgFxKo3H8ox7PJtg3yFCfa5L/ZBFIw+sDAhs5ZJtgMukyopElwITIs5om4oMC ZdqzTHHmcdfFOsdaf3CNaXGNtf7oGmNtwaXe1eKS3Ktnnwh7RLI9wj5Xp7M2rfms20RnyKY3Yz+d MD4Vn5pMOImSaJw7/FDwsWBhDrSQlTssjEfzz7k7hFJ8cPQW61C2DE3cgmtUIAfuFKNwOrTyWIp1 Wn+cfvLoUevRo5SdfdJ6kiMiB+GvV0+YRS0gwNElJVVL6de3f5/e0R2jNIUBDqQiSTyXImIiImNE sujhcHSvSHUOGZouQb+jZaotPt4mHo0N7tK9u8Ny1jzEmeEakp7pkvcji3hM26O/rX5rWFofZmoU N7ktbAmS/6ON5b2g7eJhCha73CG2iN0RByIOR5yKMEVs52gSYtdWM/Z+o3j4mZ7mK3Av2ynuw2n+ LRd65/HDSWsLZvPDScjOZXVBnpiG3TeLcxH0NTzAFhdnC+C5KhobbzPpb7fGpyQlpfDn3hA3rCO4 M5/AzjBTN7fV9Cxud1vEHbRltdlQXY+hoHMiPNoC+Z1s390R2bQ9Fr3ox1u+T7fb5X8MJKa3noWF Oo7zudCd2i0k3SpMMWEdLJHRAQEma0x0h45DO5jGBAV12BTWlcgKdYrrtG879CqW41ZIDZk+puUH l/WkFb1BObBQg+SCyeWazn0jIwd41ykQh1dUZIxaqy6pKSJFTHc9mRoSFhkXePmMGZcHxkWGhSQ/ 7ubvqljwBEdwbIQlZF9r48OPtDa+GmKJiAvuwqNbIYHM1rOi2jfabkEiKD5OxMXrcsRBkQEx0VZT AEZrsWDQGG84VFBQfOLD2+FL+sb7vzj5FvgoqvPtc2Zmd2f2Npednd3Z3Zm9z953s0l2k0CWnRAU RYFoEcQYglq1KAop1LtFtIoiClVrFUWwKt5qrVxDwEtbW22tVatWv2or+ke81Fi0SLE1m++c2Q0B tP39vy+/5OyZk91k9r087/O85yQH8P3uQTds3O4RdysShMVsBFJbWSi1Eol6lHkkQSKWfePdfrak Nlp7LGKX0d3+Fh53/wPwuN+hu0UxVtuG7ha8R1jI/0F3m4Ot+jVigIvqgS98B2OmbnmF6yqRDPqD sRNjZDo23/Ft1wWx33v+Iez374vR2XSEBEmr6KTFsJBNJ1iriYqDXC4Wj4nxeCwWjcWjsYBfDAT8 fp8/4Iu5BNHlEhiajgm8KAh8Lh6LBkwg6XMJPGNy0jEgMDkKxAdJUhd4i9BL08ASm+4PCU8CJ3QO wrU6S+v+6ULIgp5LfZmEYBBWdNvM5KIkkZTzz+3yDsJYw92Gt0c6fTI37PNyw33DeOZF5sQP1T3V DpytyKqeDvxFrchnnFdyz65w5r0Z+msTCk2A8dyWFsMTeI690QcG+iBfz3I+Xg8is8U0FkGJMU+1 xbWGm4h2r0vwQt5l5by8r/b3hzmZl9wPP+x2CzL/cO1TmfeyNhe5GgaDPl+w9u5cs8yzEj33Q49D kJWPPlJkweH58DTazfKysVW9BnRTFWo6CqJevSj3BoMA0OKDXC/1IM32MgwdeBv00p5envf2chwN ey0W+u0mO7TLIbpnuTcDCnDcXujLMNsewBnJMrKHw3iA85MXjbfChw0IawmPvelwHdmIH+K3VVul +nwqXGq8xaV4TgRrpxtr93tcLg/8CZ7X5uE5uneYqb1GvALzCBBadO8vwR/BbrAPkfptFPwH8Qvw R9YStBCWXfAOYAUXQGUcMQrDRiqEYcO8iMTxtTf8mhwlYX7kzeaobLVj2wwRFspFLEM1xafbwTMo y0yETJ31KC4ae7i9oDAd/yB3uES5vnqQWHbJJeieXhx9Dwm2z4ADBBC6bqJt1Js22XnBDqgCo9ZM HzYAK34kpJ8Sa+85qQ0Pn81snzADf6Hfv3d0Dvmx6QIESBfoExhGgjJDtoMO5lh4PNPLnM9cBC9h bqBvYG6HdzIPwIeZbWAbfA7+lvkT3As/Yg7Ag4zHxkDbIHx+K2mbBHqZQbgJ3VQv/WSBhOQb/CDc +cQuZJX9fSMIvRt2Gejrg4cMU24UoN0jp/N+XrYS99lEJy+bYv86NS6zdrfpIY9TZm0IgN5H7/tD E9YCBfjYZoGwRodGPwfk6P5NOTrVxaB5cnQ/SIz+E0joyz36z20BJ+OkncTQ6EHAjX6+SXHm8CvS o5/r0ZQp4Aw6I8IFtBoQQB4mTI5I1BmuCNmKSTCZHL4Kqka/31aMVZxy071D0IyAL3tt3bzcAWTh Kgq/YSPROviOOvZ1X6qfRuQ5zSt7ZEl2y6JsMgf8il/1B/2UOaEltZSW1iizzW61M3babrGbzKQW 4WM6CLl8OsyY4zrIUQUdRtmwDv0yGjR7Vgd5Ag1Go8BoDaTRR2Y5aG98wPbDP7pPP1V386pLrooq 76nyeJBUVahGBkf/retokhADPBr8HBpkFg0eZzWKh4QoOdAMDaSInkeqgq2as6JBwjNFlMP4h3yi e9CEFT1B/KpglbBy/CQPHuA3dMTwbc+Fbs7AmYSGPkslzihmHgl9WlrRSkKLRgi3W0TXHqmlWSiR Hy4/e+20a/LKMawHzU64Oq9O4aRZ3Wk52TH1pg3dGW+y47hVG4i3Xq59ds8VE0vhWyqzl7wMOTyP 3NI5e9nFL1aicrS2+5kdF/+hEpFjMPwMzrY9iLx9SB1EVe+JTQLtHxw9qLO8GdCMX/f3CD1+imGH iIeBHd6lM5zdznJPMTSBV0xoRYAmEwGfohsHPyyCXxwi3kCs/NztwMTQdpkQdxLLEfPxEH/QreBc nofnIrbGPUksRpL9XviHegRhVtbJjQxzBpmpDg8bEA+4kYrQUfBC7ov9zx5xUWwCfYaXx4DsEL6Z xopsG7EGhjBujSw0kCxU+1RkWNlKy9TBf5/uQVDnFVweqmk2RmoHjdnYo8gSb6BcysDQE2aie9ap 2/22jIkSASpYvVutdrESMSEUqY7U64h/B8qpv+pZf6z1OPYy53WJ65LXpTYmN6Z22rekGYdglUr2 9jSViqbVjJhQk1G7aMOR4vhYGJb+JYxIVJIes+Tb2xuGND0J9yBgtUEHArXeLQxjtfsG4ZdbjN+9 E/FZlPRonX6Xr8S7HMQiJBw8aFVFz7cRFyB59cOxrOQO7MdJiQYMfcNVZN89iPA2zAjqZkTZGQjG BK8UD2nusFcHriivQ09Q1KEQQ0Mju5Yvr9sbfYABOJCZ2xZukGSEwrG2SUSpFYWr2WJuVM4GfpnN FmAZIa7FheWr1yD4fGBW8GeXX/iIbGbsHO9ZsOOMde9pvRfV3hyaFcZO+t4Vez9d9J2ZyYUbv9/n tVg9XNP98/68csIZS5bW3r4Xx+qvRt+jkKEAcvzmhe2ISCDUamluLvETYsfHpsW7278LzMvC17X/ iLq1dHv7A6WN7TtcQ54XXC+IL3recv3F84nrX57RAo9ft1WMIMfxg8iDATRJ0awtk+TJAroRLzBF A0BWQ0ktKyPXbw6FhOwgvGmzVmlBfOamrULFHK2UB6FDt7orZCDQQfomFIaQCwLE8u02uaPFZHZ8 MgSvqjsCwSIu1tP37JnB7UW2n85hzo69MbIHXQ4jnMRwaYQ8Jit10Ay0lmJxl0iZ4q1RHbpMbh3G SpoORUrQATD8shx9oIf2voF20D4ApTp90Q5Ry5bmMvKLVvdIi8e4Mrw0liN1J5GupZd9Mbjwwzzr 4Tjxrsdu+fUZ2/pUnywfN3Dr2ivm3JLleBvvnXPp2vW/P5N4tHXrmT/+4PQmTuC87JLti09Y8y2c S3Bl77w1na0i4+GSlVOe/sGs21Ft+hPOJ8RQFYBUsu5A9TxEqGGTEgxIyKx7tynKUxLrFgbhfF1w Op9yh8LhcwkSMWWSCAdDyPDbSZIyhVWHiuabgBMVH1SvlABOAwmwaE1yk4PENToLTc5zFSUIWBWi VFCHiAtBGPbqNpRDUI5QlNuOqtUfkTtih9wxMB2Jp4FOpJxGOjnMnDDv5D41uJQhp0Y6+Q4TIpiI RKJsQYnzxWudY49ssWkAhkuwhR/jE2OTBhC18HwUkuTIq/DVx4/FlPBYY6w9j8d12doc2H8Gmfjq 99h2tS/G0Aj2E++MhFGcP4vjHFkuC/6qR2x+JhBhUvIErymXOjHVn7owdUfqt/Jb3r95aRkHsYSD 2IUm/lCUFrlQTAr6YFAJgych/heHEG8mwj06o1Qoygq0uGsQ/o/OeCpWX4VD8niIuBakiIVb0TPP jccG4V+2c3IuTlnHQnjcZohuIhsNj/TVwxcLssIwQu3hOinvMOLYiF6vN2BiAiZUv70MGvxmRYcy 7RmPXJTCmUzfAOTHoAIrt6MiNxqxNNhr/Rlw2bTrK/e8vm/LxRfO0DUvx7t+vOnWZzZedc01IQeS UdMwhFC31M4OBv+69fmDpXhbWBJk4abfPnjzY8dwXonIYRxC8Ckg6/oQikRBE3xEt+cjYqw1ombU sKoNjR7AGwm6s0RNpLupE+hTqNNocxwZeDOyb6jxGDEeo62xwdHXdCtGD/TqGO0YRK9cRlEULVIi rVEanXZNcJ3g6nWd57rUdb3r2thO19bYn21/Fv7mcNmgibaEzJrMxkLx8Nmhs8KXhi9NLiksbtoc 2Zn+k/096167cBqNSA/HCyGXGHSrkuKROa8jAmIOe9ymWWFTgchnURVJWTJpk8fsdMSKKEce2Jqr kCTjH4R/1aVgRTQlKozD+665AtJcOpRuSlPpJ4kXQTOIwRiwExu3RypNSKjJxZ2wHS4/ROn6puPa MdJnSH1UQLCv99T7JZ6GksIwFc+GwpSLY3lWYEmz3WFzEOYsldZhyBUZhD/V3UCzIi4XjyVptJgx 5XQYZoP4OzYYdyR0kLIkjLDAgcF1GkwO49qAUXAMtlQvPRk4HipGpKCyg2OlETvRCHCLiD6Nhw5c OOOBs697+akHL3iy3F1t2vD6FbPavRLvEFKVX9WelrX7Fi1ev+HsM07rJFxLLnzn/tu/vO7Gx/54 z/UL1p8dYWXBYxVrT3wQfmXb3Y+vuuan32pDWfnqaI38E8pKN7jqCYbEhduMoCtNmM0k8RRjdzjO dQPR7QZuRCbsHpvbDkgOEufarDzLWSnObhtCmQiJh7Z4GFn65DD6vGe6QXyqBvAg3PEY2YSTCelY Q+F6j6rbsBSuG6KEJnAM0MnlIxsxlpBk7We05BS8ZmqhZqTF+uv+/byP93JWAaHwB0gzfGBohjgo whX6FOHByO/Ap+BTO+WjFHcmNydzNmGyOSmv3yl6V3pvg2vptbZbE+szd+cehvclthJPW4fsQ5kX rb/LuC6FD4SJophDzGZTIKoOjv5lU1M0PzT6FyQ2Dm7h6WQyhtfSycjQ6CcgPvrxpkQkjGmQkEnq dLSSSpmVistUqJgd0UH4f3QulZI4rUK+66tUpZkSIQ3CYd3WEqpw72YrjNx8lOxAIbof98AwFO01 AhXHqRGaTbmiP8i7KVoVQjoIiAiH8hakGZpMqIwGeYRIfjcacnRBB0UkMMbFBC6sX1cSoA/2DYCB brydnxn9cDNSA+iNfLgZiQT8qDchjWDyoiuTF80gnkGvsSbaq24verobr7nxmhuvHSEN5h6q3wgD 28ag0OhutRllG0kBFNuuw+aka8H5uzds2H3+eaenJ7x++49fm5By3Pu9pfeuv+ji9Z6fXnXVTx9b tuwx4saWB+f/6M9//lH/g62ljpPOXPnSSyvP7Jnw0cK77j7vzFtvrVkW3X//hd996CGEiy6Eix4U F3HQAnv0nIWm0pYMyD8SG4qZNQyS0SwanF40OJxqc6s9goZmqSWbyLoxE2N7i+8LX0b/kd6fNz0N YBGjJH7VIHa6hPz/MWhGdsqhV5nFrcVni68WqXm0IwY0pz1hSzJppP7QzKGhBQfFxlIVqwnjmW4t IECzhiuSQxtCmOUgNurWWIX1lXzvWirZJ4mHQOs4dHH7RxDROoBC431Qj4Y91eFGy6hjHLgSiXwk SrkdTruTMPOIzrg4kaPMpniaQTGStKEYSWgRdwwjlQvmKSw26RRadKIhyoXR+laQMxcOYddh4AX6 MhiwBuAhDENzI0kbXvUYfjXY8mE1D5RaE9q4e9vK5NNdm+fNuW/+0xu+u6u1u0O79fTvX39ah8/L 2z2Jltdhs1hat+D8n/zknIlLWsLEb5Ys/fYvzls7cvOKx97fdFHP7YVqhPPyHpsLtnyQfvOFW7fc dMNmXc8gPxu9EvJM4ECar6gz7CbJRm8CZmEnlBAmUFDaarPJcmC8edI5naurCKPne0QLxfWfGirj A3lmT9vEGfhrZPVhXZYzQRfVQU1H2vAaXX3CDGmGiQEoAsYKcHc8Bng0pwFP98JB+MhmYO3luxj4 CLDCXahq3Y405qOAhrs2mXfAQeJRFCPoZ8oCmLncOwijiLLIBeg1ytie4WH0CeT93mGZQ8MKutE1 pPNeY4K7Ui7YyDYIGxXlTHKVZOPlyFcHSCYi8zaJmAr/ZZd52VXrqfW40MSOOO7ZcCW1gLQbtmzb ZImhezmo+90x1ib7FGqmANEnKxSEqkAKcqCx8dGHiCd3oBMUEAc1uugN9Vqn40dcUcWvDP1K3obH w+bEdsxmjPbdq7gxZzTnILgNWfV8w6rX6ZGnza/YP7eTR1jzcCv38oZlkYW7bMiy2KrYug3LolL1 qG4HOwpmaEaG7bkcGTZ8uGFH9vwvDDve1IKNSKfO/2qpYVnS+tU/G5atmQ3Lwp/Dnzcsi9GI/Bv1 c8TSiuApvWsKDdc57+EJh3O99S4HmWDi0aujjzupHE2DKNmD6LLgY6X40qxN2sBmWbWgEipFZVXY 24M4roVODsKJuqvwA5pubrFnw74WV69Xbr4PN5+/3aglBmrgQrIf91QRycXzAiJA1WGD3PY1oEP1 hxx8QOMUIYGe4vc5g/Yk5P1sAjpCbBLWiQxGA0RjcMXog2O1GuV0Q4MdtlLPoCPTirgN6QHvWz25 +66e/L1ZuKbfnZ8x48EXLq39fla2Uk3PylQmEcQpOBpuOumk3JTF69XUbOPqGLvr+Tvn/bB28mF7 UOCN0e+Tb5h4UAFTYd8OwI0+szmgtgqDo8/ojKC2OnQ0VNHVZvToajx6jUdvazd+lgdNhuhdOiFw BUeUI79DhxRYKXcMQqduLZebK5CaOmmKMkiadEYuZp1vT+q1VvCOAE9lp0yRreZYVraFftYxqYx0 3bG6Q7JOKpVjk6bGQBkiIb1+U1fWMggLuk1yx3JSLNeThdld8ANwHHgObwfhBhESaMPcgZH9fSNY hCDNxu03mCnyEZbSyGd7DNJkSDSuE/QZvjq52h1vNXnTmVQmmUlktIzJ7BIFkRc5kTIXtJZ4lelK Am9c6gdsk7sfOJptSdhtQms6PSkJPRm5H4h5Zz+0tzqTcLJ5SrKO95mx4j3GVscOu5UaZKzc0qCh COfdvCi0NB/arTrU9OPrTT/JzRu13xwlzWPYT/bKaeHydb965PpzplYzgaZjNt9x+wk8x3s759/V c20uMIPzXL/wnpNXnieKDpd3yg9+dMGZfFyEeRtF3bHw8ifOuHBVTI5Vn7imtvWXtX9O5bxcSKtM bA3ePuGkxbAHgp9cfcy9C0aeIRAddjNwN7x61onnmPB/gucBoJ6mbgFpkIfb9EyZRxb1T8q25aYK x/tOzB6b6xF6pH5ff7YndzDNZkA6nc1DgshZuUHifl1yrHasdxDvOKAjxTscHK9YeSGawt9yalpL WtNSaSWazjKksWQ2txjkWWGInOwyliRptiBJLkGRBT4SwEvHBUHwquCaIPlyEAZT/mAw4Fcifp8v m06rfp/o9/sEnleJnIjuIhaNWhHKQTXD5oN5Ip9n5FxW87k0n0z4huCpIAsn6WJa8+ssUwU8ZP1B /27/Pj+FxFJ2WxOh8TlNGIKTAI9in7dWeRz7HHouy0PAz+T/zo/yFALN7ObCMQsRctRblwMoFvYb 0YmnI0YPE3cTMHz0GdvaKF5XmIxWwgoEjSuufNYL6EP9zM/6Bgr7nz184f/p0ni1BUkH/FXfYCGP akbARkSG4VHfIMkoSV4+8ubAvcYOz2/w2AWXHDQ6pg/CtV3G8nO4abHh1g+D78IVtRfHmhXkx7jk /PuXh5oXK4izRtbhkwBzUAzNRTEUAAnQDM/Rn3w8/WjmN9Zf296wmlanV2bWhe6Kr8/8LG6+PLYs viTzvdxq62rxxtjqOH0Kdza3zLqYW8wvFha7LNNC08PHx07IXOc0NbMTQxPCE+LV9MTMMexUjmYK cigQ9sf9aX8hyqYz9KXcrthzBfLY0PHxi0LXhVY2/Sj0QGhriM7SAUnOAKBIBG3KQKjQTSEnGU06 m0MJJaVJCY1WFbXY3CzRhERH46w9aC/Yq/aZ9n77IrvFPgiv0VO5OEDJR7D8Gv4Z/mV+N7+PN/O+ 1kRShcbG9T5MPlqmXVqPCVwdBxqnG/qMRhNWd8hfRvuEq3f8Gi3uIxtL9foSywqi1ebSMvG0mMvB uDWag1khlQMxm5aDYFyl4NoyMDDQhz7ifPQw3mBpAErD0a4wQh+j9IT5cHO53hYMQzBgbPZx6379 wDWX9TxwxoixEfhrmOqfWZly28W1zfDhky6ZNPeeG2t/nFV399bL1vYX7p4368YzscuJcjRwXtvM a7+SjjuvQ79kEv67ldF3qBOpx0A7eEe/JCfCAqiCmYA0SW5ptuds8dvSgvxicYm02LvFY20LlJum SdPKvZ7e0nme75SuDdxZsLYU2ZA/AgFJOyVPW3MoqrIOQAq26JaMEG+z3Uip8UwbSREZxqnR88Oa 5pvg19hisFgoVotUUe5YcZgT6jV9ZASb39ibqlvfkAKN0wSeDqwKUGEHJ/zc9q0Tfh476TSk7wJI zSLGhCWrMvrJVknyBLxSQwfOxUUdZfpYB7zRkEg00N5iRkvA4O8NvMdsMk+WSq0CWiHfrLM13kOY Zi+97YzZujY5EYDcloWP9vBuQcqc/OKC3nnHzbuh+doPVrxMBSdil3wU9Hn9s7rmZoK5Gf3Hnnrr rtrf5vW7Jd5TOL0v6j/u0R/OefQKiP/kCf/vReoilHsKgjq7Hr7ZeoPteuEG1w3iKvfq4OrQyvBN iZWp1Wk7qnKJUCoQxgf9mTsTW8NEN+1RMN7afCng8ylA8dAEvi6ZUsbehELzeTaoSpKieuiMyjCE ShMxjWUhy4ZYgvXls6oKQ8jbBJBzO2EHpMd7SePJgGUESgJjwF2O/7bJg3KhNZS2up2sg7WzNpYy a/FEPBlPxSmzSxAFwhyOp62xPAy5o3kYZzN5GBGC+UaTEW8JNjYuUH0+PD/wlhr2m2UcCY2swPor YWSGMtWAwGfPezw/M6V899qzrq514pW7YPG8HX1ybHJs1Um1lxpJcWp7/3nTFyxd/vlpk3FWrPzF vDtmVOb2ZI9H+XAq8kcB+aMEBd3XH1xkXmYmeZszIwiKLRIIlqJRJUAyZsy1WLWKH/UsK1fNswlU FUWfJ+NyKb7WPA5wopgplZR8Iof7eEQ6o2lKLjgIF+qdPgJqtmhM85WAFlcBsPkIGx3R2AD8e2A0 QAS6SA0wsIfZwLzM7Gb2MSampGl5kONyRG4QVUQpHkeiQGVOdhWEvwv7sFQpT1vkbXhueAR3yffj Ssb1DQwjaGug2Ui9TY4/EXoNA+6Lvtc6D00aiGZcZjJj3zi0jrfwID+2jcQf6puPeYkfa2+NP6ex Ak8hrsNm/+oM7JEBA8PIJXhlZCM0eryYOxOlWtCoY7Ut49Wq9g5eebF2Qr/xnU/x2I+8tB55aSny Uiv4TJ833wRZxp7hOIUJ+9VSJKL4W3JsU7CJaMq0tio5VEbKuIwIsjvD84qsZUGKSxGpTDyuZCNR TW4F8ZgGgIy8wsgEQ7fGc3ENZLlsT5bMYntnY7EogBoX0YA/5Cd6/Bv8Lxs8xOQ/mQ9xEHBXcWu4 fRzFyaUDO3AeHSopyPhcwx94owI3DUc6x31xtPXB4V7o+wYnwL6j91AbLmj77z64u765WvOP+YC1 qeQ6bPiRK490whF8wWH9ZhcgH1yFKse1qHJ0Qk1vXxVaGyIKXJWbyZHH24+Nzbb12WfHNto2xnaZ h+wMFfVENXsiqsXKMXMZdKwBHR1AKZcKGLBa2GbYXM43NxfySslKBxNczgVVjxeVp1w5HVQ4Muzv 1MoFrXxOqUS5wnEniejfAj0kii4iHacY9Zx8PqdCCHyTEhpLB2mClisrFh1VVoxji5whQQw8w2xv z3h56WicODLauEfAXF8d5+oXWCQfVnm6rEicfQJM+P8HjX4MUugrOfrx1pgUkaJj9QcVoIE+XIB4 XFnyRKOweBq7rmP1qL7Vhy4pXIvGEsxU35elCvOf7l/x4s0zb/h01QurLLhX7BV4DzS/cvnSnSeV IXj3xKvn1F0Fb1N9nAg31e4olXvWbLph7UpoWrmoKLI+9amg7FFOWXj2zX0X3fnKgVAStiEXe6HH 5ZAsyKPno6xahLKqG/5Stwv3Sj8rbJaeLlB1qWBzZBoKwRcymD+nQCUTVpRQWPFlm40lUICFVEuh 0NyiZDsn4yWOrQarRDXTXa1O7lY66zrCZs40ZERdRNikVENDZOLGz0GiPJmJJZPxmJKZWMJL3aAd tmda29tLrcrEaEQFEDJys5bNZkKaL65lMnXN0DlxohUJihY11qrGuvVAsHV99+PdxOrud7qJ7kFi p+4/RlDDYV5tInRiDUHOJF4mCJboJxYRJLGL2Amm4D99AsZZH5S5mPyhNM50Gt00nLGdWCkYnBCP fIMiHh0q33j1ny/+26uO/hkGAhgt7QJuBrBiVdLRUECFaLvThS7QUG9Ph7+2xdmA6kNboOGvrRwt N64ZedWA69rbRtq3YmHxpYEgRG6x6pODX+KV1v6x58jBxUS5ph4pOQwgPxFuGZt/JY19H8Xc+0iA fIRiLgje0HMFKm+K2kOOkBhyFwIFdZKpxd4kNrmrgao6w9Rt10XdfUJgpjJTdeO/S0WRYy8bR1xQ JAWN60AZBAJBoMh1LmRDyF/nQl4BXyfcZd7tFnjFG9RkQZO9BKHRrMYwNBah/EwOcnJo1TveQxwI ex05u2o0M/4Xrvwmb33tzMsRDcMo8cOjzr3sNki+0T+kJo0ba9yYGH0fRej7OLKbBj7Xr/g+ucx1 mXgDsYpc7VopHpRohrCJNje5llhnecTyAfe++L5kprhzuG3cNpFqprVQtIQEVkgOBt7yepWghRVs NioUJASEpl4PhlLdwVeBbuequwG8Cv0+X5I9x6nStAV/w4K/cZUFWuTEuh3w9Ua5QxQOY+yeGQ2J 3TgnPoxP1hYQtn6TdIpwEmF2SyIaeROLUJc1W1ykJwc5M8JgiRBydXJo9OfSDQHV1zgmmWicjiTx LiLWS0dZlnx8zz392xfiwgan/3jayce39da244Alzqkbd8R35+45Z8GyEb6fT52aVG8+idh7WHd2 LkLEO5GVJxPf1vu8OW/Z1xVrKbW0laeGe7vODS/sujh8RddKfWXXnfpdXY937ex6ocXFgnLLMS1z Wik2kikf29pVml18tvor/Zku2h/xFxdEFhRva30893D5w8iXuS/L1ubJABTHojlzRDQ7QQAGWkIo oEOKnG4yGjah3Joc0ZSDudyaYi7XVFTSRVCPdScwQVPLEeFuQ4SnHu6pKL7u0VgtqDVppJaJ4Hqj pCLhrla9TFUnR4pAAGo4IobDERAuRqgQbNLSUS2dSsnFSCSE8gUljJdob9MmVas0zWk6Q4NB4rIt 4bCXaR6Ep24PTZ5cBJO15iH4EIgQl+kevac4v7i4SIKiXuwpkruL+xAn7mrbCU8FIVCFZZ2fEg7h vAMc3IdTr3vaEJw1LkIMSd7ZKXP7fSNedDngwwdxMOj6ZAN7h71V37AByyOdhkAxztF24rMhRllf kc/gk4Qy0NVOFM2BNjTIzWjw5NAgJqv11uDcFaYr6wePvYf3aQr/HbEP7/D0DfxX0LY4uc7O+hG1 HSAyunuzHGvFSm4TekS3MBfDhCFR/xNkh8cAGh6F2BCfP/SMXRFaAs6+yzi4smGca8P5eOUuYsrp +PGfeClSaz73+mps/gK88pMfbFkBf1db+XWgGfk3YTqE4Gelv7+0a59xeGjBS2mDAaLsOBVlRxgs 1NuRSCphkYQpOMIWPxJJbzU0UQlrIkKz+bHMYRnI+BCbVl2CHHng0sP+sGRvH2LH9a2rcQ78NWaM D0mPH4v+ZjvB14m8cYZtPn6zzz9vWOH9MUCFM3Chqs07ClQh8KL38wx6P+1EQp/wnrJXJY4F09qf AS+DV+GbgVeUA+AAPKBY4yChJFStfWpgTuAhdYf6GngNvqZ8DD9UHKeq0G5knms9ltlBJLNTLpYV XIo9aFAbDkR6IkQkpUUicU0JFgxyY2tuKTc3l8pKwWYyrukWiqZNlGLzu+s/zAtZb9BLeFOi1+sW FX8+Wc/4TE+GyKQSmUwyoeQHR2/UAwoEoYCiqJAQIR7VdgBURRXREspWRbepcS0YVNWAokF8PS0Q 8Le3EaRb8xP5QqKsFQo2m51yaXZaS7S3K6qqtJXVhA5egsFEf2JR4vHE0wlTQk+kWhO6UGITqxMv J3Yn9qG1QeJd3a0EYT8kVsOX8H/3pwIBiiAoZZC4VJdcIZISKXWm6yXXO66/uyiX3PHLhmadjpPY +MsBvqNQ/+wbQJd9mcyAl9vrM8524VUsoEbqOY4fqhgejIt65qPIwW3bFVfWt7RMV3LPZrz/mVoN /P/xswGjrn8XcfoBGIVfP0k2lqIQ/sfDZlHinvm1J7m7jMLzOzxOLeHxD3AS7PiDwanq589eUP0o dQV80OxoJjCSJV47kk6RH+OszKMoXo6iOAsX6RJNQCYgB4jnCGiDZr8fSn7KxhtB5kwJTiePMjae qQcTIt2p/8vZlwA4UWVr163KvlYqlUpV9spSna2TdCfpnU5BSzOC2qggNBJBQFTEaXAZ3EbaERdc BhQZZVDpGWBcUMRuwAZUHB8oDDMPfIILOgP6EJcnij5kVOj0f29Vkl4Q/5knppZblaSTe8653/nO kng4HIu7QzqFdIs6TajVCgJCflo6t8egrtBQmYMedO7n026e97jdQScOKOCRq1CAE7PGhFDIIwSD cGG6ZbOTFqDmu+ChqAN6nQ5o3C4PgM6Z6MSwuBjKmuNt8WnxjviS+KG4Ku5I4ISHcqLbrdQ0a4d1 ifW4VWG2AitX2XBN2ambj5gOUmapENQ4KoO1piJYk2ssJJ+uuAqYgQZafEBbXHBDOqVsjnaJ2v+3 gd2ZoFwy33zgrAY8DYabcgU+t2+5bKv3SAmHkq3+EJ+7ElknGZOMUdhPjxjG339K7BzAgTh2FcSB V0Ev3Ihx4LTYv9u8k8Opo8xR9gfyB+oEc4JTvcm8T75PvcO8y35Ofk6pHaSDsjEMq3iT+tF80ko8 oV1uWIM/o3xGu8bwF9VfNJo78QeUD2o6DYuti22P4CuVmlpVrSatbTI0kGkqzTSwmigeMyTJEBVi kmwjrn7ZvJ3sprqt3bYNzHZ2K6d53ryeXEv90bratoZ5gX2W00yyXsjk2VXkcusy5nF2BacZbR1t G82MZc/jppinkBdRmgjbYK6x1trq2QvMY8nRlEav0mmcKqcmYq6wVtigX8wBhcZqNiowtR2CVEtI R5hCiMr3YSmsC1NiC+iQmutxtNxSLB9BSY8oAUKijKUyovnSf4h7R/VEeSgTmxidy5KjevtP9sA9 2dv/fQ/F5hiUUm+inTmGZdw5Fm20cLHuMXPo0hdor+ztf6d8rqfQ+etory3urWgPgbINPU/enxBN EDTbfEaq2eqBG4BSkaxczljc42hP2nKG4p5FGTpGi7UZmODG4EdHP12ZgOQYQxVrEBNjFhKDIkip MzgqR0C8NqW46t6vF+8p7AHZPYu/Wjzxq1dePAXUa1/5Cm99uvBRF2gHJmAGk7sKHz/zN9Ba2P3h F4V30U8e41gPtCSXQksSwCqx4yKrcCicag/mtTopb8iZdY52bonpolRFb/9XInmjY5EDr9BENcsc y734cDz7095YVRmexiVfLIB5QpQ5mAviwSALXbJIyAwBsCNZCSEiySVODgQKSvQ0YqeRd5HHJA0P ivC7D0KvGG70ZuQHtxerVP91dw1lzCMC+iw0W0mBpdT5UDE2E+DBhuH8GkQcnz3/wZjqceMbLin8 AAz51eOe/U3hADhcuGGoRv918YW/CdU5rBMuvql55pOyTlsknU5gDWC3OO2e2N2p+zKPxlZkng7/ KbomoaHmVF2dxnUVRMxZQcfoSgEbm2rJtNScWz+uIR+cErqkIp+6OD0xM6n20vqpDbNis6quzEyv XZ9anemqfSW1Od2d2VC7peGN2Bspf8pQC6V9c4MupQmiwxPdVZo0Etb2mKFCE6mM1GfDuWhDZUP9 ucExsQeD91fcGVuUWJRaXLMyuLJiWWxpYnlqRc1a7E+xt2Of1/+YOpk5WfNjg6umtr5BkUmniLjg BxCABPx0ALobs6GOQsN/Sbd+troXLBatRMheJ2Da6lDEHiECWtPsONYL8t3gmA8tD2w2GUI0rC+e infFlfEF2ZDANUIN7y2nE0ItJ0/2HUG0Xi6JWD3of5aAtrr/tW4tmYm1H+E+YeG4BA1Mv94xYBFK NRJSxEHKFBRbA02cOZeY5aFysTDcJJCFqPHATQZtalDFUQZtajzwvhpUcZRBmxpUcZRBmxgNFR4M 09J2kFeqi2lj5TiTlFkgB6GK9YsCnkX6i7TYOkiD8evmXVwzeWIT3zDGZaDsOtvYuproI6OrfnHF CFprYe3bnvoaKjdU8MK+D8rqzU+w+OxJym4161kfV2OwWJQsTZP3RMDYz5DCF54ufFP4rvAUPmuw 2uNSBORVqPWVWC34wxaM798hXuDjm2O0nW2+NDu76sYqQh1rqBpbNcUxueoG3w3xm7IPZtdGn63a Kxzwvu07JByo/FqwmAVt1WhvK39T/C7vffGHvH/0rovv8u3mj8aMnm3932NazPyTFmKoA9s4YCG8 vmiMV/kr4wFvAqspeqOVmCeZQEqfQPqeSGigoytEo4jP8W7Fb8Eq8S7RiMEP4iHTIRcmAAGK16aF riUuiEdAWERtvMb7u/z7/Mf9Cj/Cw2aLSIIkeZzESa5u7Nyh8eH8/CP5I3mp4rVJqp+T8IaUNwAN cckJHRwt/lfNTh02bgNV5JS7vQbf1v4TqDX9xpghy3jh+tSd8VXBtaaU2VqklFHq0s+7jGpmiHcY SpcN1sQz/cTTT7x71+NTOh8U0dm8x9d1FL775Jc9Fz5zc2EPriuMHWq23vz1lFXZ5se/lRxC+6vZ CePn1k14DOLPLRCR0NB6nYN9IEZHpM9ztqXz6QXM3cw9jsXOB+pXjNKd62sdiSOReGbk06MO2I/a v7OrnehDWtkaVBrRHhMjIxodrFlJY6DWVJ0KEIkMiipb9JzQ1JSxhFr09ysS91dkQnwLoYDLDi8F l2tD0zwdHtzjaKVDYpUQEMSRHZGFkSWRVZEXIsoIN/qJrcA7KF/+yDEIFOUqcDniXAo591mkMh85 bV4ulLDLbQdQljGQypGHRZPlNFAPjkKVxYTEUspYMYO0mOleIZTrJohlMpKj7EC5etH9axLnTZ+9 buSk9qP/8cGd6GuVr2x78smXWkenHntr6tS3n9+gaHah2XnHgwLMdy+5vPqitNficlfcd9nSPYtT 6NJnKPY89dEn54660mNzBH7xi7sWvYr8giVQr5uk1fy3YtSsNWRRwMzv8tagkCauUWZRjMzKMTXQ i+cCFHQ8cKhGXC/o2EySFg98CXgo+khX0jXdtdelMLtyrjbXNNc8qE0vuA65NK7PQ8ihQ+zfiWKV Tk5afIcFsc4IaZ0hwny5DLp0gC89KHGkEntxsPC0lDX/PPr6hlKkhb8jqQYLCoulfQB+7ouhPN4G P3cK+LdhLvSzEf3fd3tJFyqodUKk51/gPKI66vrC+wP+neo75/feUz6tHleogFPvvcu5UqWiWNlz t5E23JbmbDaWc1MyHWfCKkFlBKusTGHuqEUnx0kiWqNRp3VbZM5tjJAucm0paJkCQiTCCpROoCy4 G+JYP+8BoAPODW7G2rBpqIS6mnN4NJo27TRth3ahdolWqeWqBvk9eYlWRVKbHyBYyw7P/yncIFUz S2alrsiswm+8HFQs+bBSnltNdpgfQ/R9+dS89beM8ThMBo/stax89TcXL75S8m3lAUVz36gXj894 8yb8VSmkKHmvo+5//bwnZ0ojJf6FLK48MdAuutSYmk1h57FjY9PdD5P73D+wP8R0T2NPu3EDLcef yLSNJGmb22Bj/FE0BA38PAHHBFKYLuwTFIIQiQlCNOb2xzC9FHhiO9QAVbt3qKFfG8HVagJ363HA c+jiuW53mnW7OdbNs3YbDoAHfkCoy2wMAhg7S9vtrJ2JCn5O4GnBQAh6P88bDHoc/XplDMSEFDue 3cAeZxUsChnr7biQtE2zbbcRNnje028H9q3gTozB9/XEpVy0WSj1/Wj+RF6qiMhLulJiMdC/ZLLE ZfxECtrwFDOJy/jZgeI0Qx+1mNYuTaGcdRQA6Z8axdfeWGgfaaeNRtoO6lmr0WS1/wHcrQJ3dLE0 PGFBnbwXFc1am8Fg08rb0wzxxeBzZH2gr6ZYA+c2jH8j4zORtbE4Y1eqFNCxCztoleAz4NogbovI SycyHE1SExGpdle8uMPR4exwdbjvZe62v6Z8jf6M0U4np1umU9Otir04IBnSLjKiXcHiTruH87o9 4Yi9Bq9hquyteCsz0t4OLmUm2++1P23fje9iDsKPJQUfLeR4EpBZmiSttNtI2/gKNOoJ+oLzgjgW JIPjg68F9wWVwaXhYLAi7ObDmEEl3aI1a71a3Kzdrj2k/VrbDxV1qVKrVSndBqXC50C30O5pbuDO cm63g3P7OBaDH9jXW/hRzNgUhI9WKhQeG03DNSQMRYzlaJblcIATwMPa4bEdJ3BAeGwMvIPBBXsv /ivRw6LWL4RNIBSaCoF3oP99PqtgVAlGA/p94DiGwRUuj3HwS8+L1Xs54OUAJ0aznJipyXCdSXgQ CGY4UajIcIJoDnvD08ILw0vCq8J7w1+HNeFt+M0QBNoh/LYz8GmMmIQP+FRGdGTNzNdSgc/kjbgo ZCFiu7lb6bO9At+Oxgj41gpQKdq8NHiNBrRAKgGmbFMuUe5VKpSvwKsRbLTE7s+SkzCPQRH9iiOP OMi+WN98BJPZoxzZN9/BHpMrMPJH4FWW/Aor27diJA4R/H0S0ye1DlGWeoigg4GUTfh62HA6/+eS OM8ckHVm3AYBArMoBGYv4Z24w+5gHEUINm6Do5yAhvd/2Y1r7L39x19kyBJEQ5R+Pt/OB1De5jD+ x2pNW63Dxoh3F331+aLbvJLprEMr2I6O/77j82t3yrYUDXiJ3Ok/K5rLsVQ/kTz9FvGPQVZ0PNS0 ThTFx9PicioLGvi6QLZFNLQxbYmRdRcapjH5xIV1lxt+yfwycXndk4mldU/5e6levjfT27KL2sXv yuxqeQ/7MvN17ljLP7FvwDekn4UvWw2oFgvVEiD9AZLPpKsBn8m0UBTl4TM0z2eqAyRFekA1DUA1 DnE2KZgFnVWgBF7wCY5RQouQEbJCY5VQLfh68ZtEF8TpOo1D04hH8a8zICO0tOTq6nKBQCJR0YKg OZUbqSQFAJQGg9LtNjCMG6Bhi1mZVOagXE1TKpWO0dVCAI5uqpjthu+EruvaoM51uAk3d842IEgp bTZ53eTOP8FCU4uqH9DqyZ1/hKVKbDOHphxdlMY4eFIezBeBoQQWjw3eIAFELqOHREElEgWVSBRU Iv2UJ0eajAzcGOiSK9hetORS7J7q398Dn0P1wj18mrSHz6QQ9wOfLJ3D56N999CXMMP/JEMuvU66 /xvRarLnLGaLK2dR2tCGtOUQtyRa4RDPwostaEOyZlp+fbivhvuX4N5igj4dKDupUtrA8JTjYQM1 cGB4DGr4AL4CLJHZkG/R9u7C2sIzd0vnJ1BqShrcV7hXkvFPkERfBs4Boy5DR0fRmA+f1NdXzlF+ tTBKPjYxKmgYPy1Ho/Jg9SCZnwll/ioo89XgcRRg+7TH7kVdPj4Vs1Yut9kPtAFtNRfgqq8OXF2t mkJdxkxzT+EVGn6W/xH/Wr/in/z3AVzFawM2ngsoSuRVtuiayvkuxnKyC++PVcGRHjIBEr3466K+ OpGoqnbHqrGSE5stOrGcFXULY9A95ST5aFDKeaqIBSoqggF3NOD3A9JvwQhOWx2wVgmxoBCL+oSo g6coKacFgvCAML4aVPfi2zdBqy5YSHgkmnkBo9qoJSj5Lz0YH55/TKr6PpE/VoTfckBUymBoaip5 NIMM3XdDzN4ZwFEzFDme/U5JLLH50JPloFkMQbPYg7EWtpiAOx/7KWf1/y9Ly8rAn/MeLCypRmef os3FoAGkLyrLTTVOFs4py83LeKIsKhXg/cGZEwcwjChAWYEro1h/MwGoy7WX26Yz83Tz9fMYVS/x Gf6ZmdDg8GH2EnZzGE8SdagtPLGQWGD+FbkYv5cwywhAr72kuODLeUxR6DvJ00yaccKiUHpMRpyC rhPQmEVf1iy64YNzZcyCAkU3ApyM+TswBeZwWgTDSB8AbaADLATHgQJwDjirMvUAPVVksprO70NL Y7n1Hqo7HlxmPLzmeNwGW3l9Mvd/+yJuKuWioQyiTQRqnEP29n/cU9y/ZDflcMLsbZItQZ7nswN1 yxbeBmylwCtROP0u/mzfWyjIih/ouwRfhL7dW4hX1P+U/K5xC06P0oIQOsYAPqLQRyxXfIpZsFZR sOhN32JYtR56nN/CtUKj15EaCgNBLalL6cbrCB1HXfHM4ASc3E9FgEtyNNAY66+SgTks07CKh3/c jv4i5RdSCwEImZoKffgj0t/QLPqG/w2kntLqgiAnVSTK73669O7D31s5kPFalGI8t2dw5s4LypEo 4+RHyStFLdf79ir+VghgRsy4UX0p0CuSSbmD1NC6weWnVkt/ed7LcX17ywKLY0uh/3oJ0YmFsRow Q7zwWfUa77MJQlCHvI2KG6wLHL9ydtJ3OR6mlzvWqbvoNY71yU3ql00v0hsdWzx7TCeqbDrAgSgg fm95xIHfmrgvsTLxrGldYmfVgapPqjRhfy++XnSEknwo5Of9YcpttUdqeKwmAoi0QRuv6QWHxSng 3jCmS/OEXssjQnZenIhHGg2GMP04ybvV6IIR8/l4Ea5ZZh4k+Rzfxk/jV/Ev8Nv5Q7yGd9TZl6R4 FbreoVql2q46pFKouNrotgGzBWLn9x0tpg7JX32piUEyfwz5uFLNeJmPqbfUDzM+RbuDxH07pobO fab/OJaFD67/RA+lSWiKyZgQlBUTOGl46zbMA2+x9r+GrszPQ6HPlurBqhn7oKYWqEWRnHRQlD1C kK6V6r8mv7Tv0WcPv9twb1tn54wXfVrSrjPNfHz8qu55SAt2Ni4696UrL1hw3bXbZt78+xUdt2w2 k/eOnl2vYymLzuyIPjGzb7/EpP3RQrY1XnTeVZOmoUhAJZz7SVBqXVgYBF9EDst6UU8mJWfFb3Qx 6NzKJW0cx9j8Lo+aAHqfYMjre8HMTQKv9fEQM80Uo4QL2jy1Vu/mzfCbx1WOaGACZvDZaFRWZaY7 6EM0NAaRy347eDrQJBwpBVlyqKPfEQiRjkGIdKSYKftz7Z7GbTAUJ0OcMEcLUvpUcEz4kvCs8DP+ tcGXwBb9y57NFTuUezT7FR9qjii/0FgYRRWoVo7Qt4A2/bmeS8BEZV6d188Cs5Vz9Tfit+pu9dzs XezZ6n3FvynEQIRzvFtPhnv7v3jRw8h9jvJgfjuwwDnCbDSG+LfAMEoUDKrFB9HH3u0FqsI/N324 bOegvPQnDz788EH0UHza9/Ybhe9e31E4/sZaqfVUs5RSsmvV3/++Cj6KOXjjoGZGseObeJ3ejMJ8 J8U4PHjT9mHo/YrD3sP8/4S+qFAHbRXMOb7zQ+dXTPTlQ1Mq5pjncFeHFnMGBgX5rrfS7dZLbNeE ZlecdChVDo60OSJkhAo57iNXkr9jlzvW2tbCewMCZTFztFOqteFcdpkRxe618BG1vkehcv3Rzgf0 pkZNe5cXLPW+5sW9jjjNC2iSuwSAUr+WCoTAxXYMmmeobVJ2NFxkTsh9p+C/I8Wc6IFyG5n8RCwR Sr9DZZNF+lM1mP5kBlfRBPxYNoOlq4mdUgKeVEGjeuGRba+/8+yMPRfZSIv9itW79hROAf2ePxNG F9KSV70Ou3NM5xePrt7/i/G03RIbdQ0g3twDDEgXboff9jrURR5+3x9tPjd6VRRHeGu9nPiWlCCX X+Nh0RDpTNqdTtbu9+gYf1ib10E16Anz8PuG6uDz87QHM+hpNfpJDLtX6+tE/dUBcMRDfCcJyF7w QE8s2lmqF5xf/H4Q6d8kFSbBFekI/P8E0oOzk2xVqXEbmKIS9Jg0lAaZmAG92IJFoc/ooysQESlA zBrQBLmyjSovcYGsqkzNVNtLojy4rYQCl03Mwx9d99bNN791/Ye/k87nvbf8d++997vl7yk+PXUt si1P7br58IKbDt2yCxyUJbnrww+7kCTjUi5/Ekoyh/mwfeLVOmaFDa/GR+EX4TPxN/A3rH/hDlIH uQ+d/81+4v2RMXKuqCuD13nGOs/zTnVO8XY453pvdz7gXOFa4XlJab6R2eraQeygdrt2e1SanRaH zwdXYIubt6sVvEVvmOBo7MLAPAw1Fv1EtPt9jaCxiwYd9HZ6LzRFCprjo88NEtHzj0mlmseOlPqF SGV5Q4xMN0OroEnY6KS9Hry3/8uyqYfQE/AMM6y8S5ZMTC0n3SsqTz/NfPLMZf850moiWTL13R3v FQ4B867/BLpJ3IFly/Y7wBOr32xOmzmLhayeBJy7X4KW43/vuH/9cw8iRPku9D6mQMnMYHvEkGgY r+xU3mm4o6rL0G3YGHs9tj+ms2vMWsMukvRrMwmsCkD3QbEZw/wJCEB6gSg6AJTcYNiPhfIR3o1h lI9LVLIqrUbnh7Io6mqwOPA59kqiuVw0Jm2ibZ5tn01h47I3bgF/Lebfni+V/DSRRyXc34RAYp/U AGhY1WJ+WA6uKRpzwgmNe7GYM+IFiMxEhfBnDYCniw0wBjr5qGy2Eg5LAsmO9nWg7Z7NaLv5ud8u uCdtY2mN9dGrfrkALJYMrbFvTAmt41uQPC6c8zijYSjKTtjnjl4o4zYc+3XhdsXtUDIrsDTwiFWj 6Xk0/iH/duhL/kjoFH8iqLomcm3lzOTM9C3G2yLz0w9EOtNPRB5Kr4t0pbd6TLgGWYMZkoHQKpUa rR/HPLEq1kfafXAuTZ5lVbxPF+OxZYJa04irgAqE3T7g0+lIbZd2g5YwaxER/4J2r1apdWQTfGdg aaArsCGg2B7YGzgcOB5QBLhM9PIhwipZC5THCCcDAcjcEWRSc6VK0vphRmKQFG/DnP0nMEf/ie6o Bvro33d7NBiKycc1KbSLGNJosJJJDoQCi4KOkAvIlvPNaLUJDwz0kautySIrgmczVLp6SEeaO+S1 L8jOm3q+VNrzzdgFFcw9B54/der5A/fsefDBv/zlwQf34Lt+L1mMLRNGxS8LSzUj550bHXl6CwCb NgGsMO6Rv/5t2SN/+xvUhYlQF66FulAHrhMrVzhO+XAFsIFZqhtVS8EjeBdYg28APbhurepP6o3K Teo31O+pDznUDo3FLtltM+2lcXoqS9N21m+JJCXAE5+aiseTKX+E1Mn23giMU6Ugi5+U8as+NLWI X+uq0Xkgm6zKZqur/HUAFU0qIuEwnO46TKEmdRqtjzvEArhOrBb1DRjvq9qe2pvCU73gf3rqx1xe rhKXneimvpLJl6h5y1kN/r9a+QEvlRIUQP9rqDsZQJnAFkcxExgqJOlwKtWqkFPJeYFD7ZJVEvVg G4gRb8FU/Sc2+QxeWkY/7XJQUu7ONoBRy6pbbG1wtmAxuGj8sktnLJ56GXQ+vIWvJVrmzhunjkzO HVz1JWk2xEWnJo0ZvaSt759l/SUuvaXSt6Dvy3KXzma5cxv2CpQGRmnBCIhgF4pRP1fNidxF3Ezu Bm4Rp7Yayck0xLEqg3ayUuk3MC5uuQ3iWGIn3gse2exSGQ06DGwDKCyGQzfEpFAofbY2GtCc+8KF Az4i2SfNUlPu5LFhriI2uG7OFshaz6jFKH4B+NLbFoKx6HP3sZIzN/Y7lHmptLz/fuHC098OslQQ yyC7tLFwO1EnfTI3tkqMkahJKk4Sl5rbXRDduW4wd2KdoBPvJJabTRdolmhWada5trqULo0ThfZd UJuVek0veH6zQuHXyx9YNOlVjgmcj7KamGUeFG6dJlpwnCA8XoPR53a3KYCC82wFm8BbGDsQCpSK kErh1r4juZN9AxWbqBsWXADRJy9/4sFltMrqmix+6LY7CkZEr+BjJk8eMaHwnfQFaK9ZhD5932lJ 82des7TSKyn+A1dCLd8O53UZ1PIs3rsFi0AxZoy5CKqJpQ3SXmyj9LkrrX+y4jsyIEpHQ4lINBPO 1gdzoRGRXGYOPSegn20FAWuNFY/RbZH3Q+9nvgx9mTkVOpXRNIQaMnOCc7Lr6HUBVTAbCGCyGdeX bbgLKf1GzAu8XvSmBjLnlRo/QOTtnRrwev0BvyuAVaYla5FKtWZSqXTGX5nJWvTSC5mSOpNJr/Nb UH419KDk5Gp2hZRd7XfS1riAxsdEIlNDkYgQ8sdDwVAw6Mtm6Gw2E6CtlNWHBWgMC2DWbJBWBoC/ 0eWyNTpVQmM83VhZGY/j+kbKgmkaAa6jkQut7QiAwO9DwYnZraALC8ER47xMZwb3ZVKZ6Rkig6yR u9YK1364+szTdmpxUuvTpuABWodUWq5mG3gC65TDJwPFEehnBFCN77Ei31eKj0hFS8UMWHv9PYqE zDtb+/f3eJpQeuL+HletvOeq5b29Utp3D5RFAFQXIXVmV0pNNX8u/nh21nD4vdCUnXH7kAIJa//h HkcwQ0s5lxbU3+ZwN9xLTZglVmsAQQcggqY1IdQQO9N/cnCtJbwD3jW+eNf3PSEu4yv3AkCUdzkh dwDXlNlIvsxGnkGGvzzIWdwJrohJumJEhuPyQi9YdbmUVHMcjTYWHgW/Ktw3yHX8EcSR+ZB6QH1V aC+TlddDjdoGNYqGGsVieTEzw3a97U4bBB+GyQgzQpQ4GSFEirUtt1j8LAaBIQZ8FpJsI7eTBMlx g62h1JD57FbwrBbwoaH271tk/0quwyCjDv9WG+o5AzFZKx4Vm8y15jpTvbnB3GQeYRbNLebRWkow 1Bg2OrvjigpQA/CJrhnqGa4b1De4lDXqatdo9WjXRLUypakdIennoQbQ0Nrc0DCi2V9rM6Mhj48C 46l91GHqOKXAKJISKYJqNVGU2eS3hbwSUMD8pB/3t3r8fq/HH6pJyYNpMo2nW5PpdCrpr2kV0eAV h1pAS2uupUXM+SuTKo+QqAy7XSqgjtaKjVirKsoTDl6rJdS1NTWhkE1nNPnsjOjNpphOBmdOC26P r0JA50KngAunm7GkL9eMiCyseXvz3maimRsTfZ4dxJnAg1hTeVcuGy2WEZb4d6oe+z/Uf+bPLDQq aY0KWWEJTAwHFUVU4QtHWE5nUCj1oYiiwguUKk5n94KwMuoFrMHhBVipo6fUTjGfh3DDOVDmrOv/ ClPAh7r/IHyvgxC8vF3CnkDusahGf4GjWeqNAPfoL+mGe7l5et5qkxg1yYsdACgBi9xea+j5IKQy XEk/u2buyBl83fUNl9aMkXo+rLwgnZg9slU6bKuqjI9okYY/lvLnpUNixsTrR7e2jm48b0rfJiTN +KPihNFX9L0tHT/UMskdmSWfDDgjUMrnQimfBKW8Dtwj1h5QHdDgO1Q7NPhqTbeqW0PMV3eq8Znq WZpZTmKlc60Kv9XbAzbihMs7x4tjQIHjHg0lcxFmm9eG21qlxCE/NRzTykuSCf30RmtxVZIxLYmF yBA+DNgas60ysK1urFOBreAw5gMzRaubV6ghxqUoi06r8zkOcYBDCwopwdulqS4IbzmEbQcgUxHZ ysLZdwIuFv9+bfK/i2tpp0upUWtUGlzlUkKBc2rcMraNStjWWc5/pOFT//Gik5bFa77UNCefhwiu puh4niEdQ6XoDHg7afJv26e31V0qycNHUrnFb669+Jb5g9FtUVYWtp8T8dx/bt/XA+i2/daWu/q+ GSYgEAM+1H9I0QQlRI/ZwS/EOopRMLSdIXaD3foD+AfKv6sP6FXXqK+24FfgVyiu1lytm2Oca7nC OtuusfGEmdcSeq3awGNSLxEuJ+1NdmkvGm3ZDRggsRQ2HULMXvwekaV4lYg6jYjwng7VdtVe1WHV cZVS1Qs+7mGhCSr5LXBxO9aXn49chtIvPAxpWbANYyACpftPbCRpE23f2v8xXHE/7jF6LJ4BfzIv hfJQdFvPoGIZGm0siN60mj05PQ03Gh3cqNHGgtrDuiHiU9N6Cl6EG4a22JtptLHSKNDc279DpOCB TgfBmgZtpEATKBUwDGqrirjbEj8zmOVqKhx7fUfhK0DteB1YJ37U1fUReoAXXiscB5bt6KdJjv/5 yX8ceuLxw4cQc164XdJe1DG3UsxV6cz1FfCRrbwQTMTzxlkAzonqGuMN4NbodQn9f6he072vfl97 sOL9qqOqT3QajogTt6ofIFYQzxEqxiWpLJd0c5zL7WfkVUpP7RqyJI30J4urETBGkuZGm6sRSqop yet1ER4sU6gxb2NIJfBmDdA40nHM5POY3XK2gsLNVQ8m3yVoV6LejzVJBMJP8Qc/n1Q8mB4LG1LI 76iUUoqNPoBmvar/7y9WBIY0qUBl27KWIXYHkehnVakhXPq452687b+uL/S98tEDchyuYxCl/sTb j63Yv3/Fo/uJGSsunXrD3us2FfpfKqjkDFeIKxolQHT1Q3v3LX1o317ERsK5exbOXQBLgvNQ796T 3eb6CBK+OnP9euwp5/oQcRE2zTEL+6VjDn89dpvjV4k7sQcddydWCI/HH008IzwX/1PCsiYAVkbW +dZFCNl/MA2mgWTbrLftKppl2QxfhMxwyTnAHBWVbCOFgLypknfptIghquCxZX51EHBaztepA2bd Yd1xHaFzVEV51PSuy7vBq9jrPew97iW8XKpEIg9mhqRiR2h64aSihPFc00/RQj9jZYdOrENuepWE QDhEx1FT5zAd64UzGxk2szJrf9aKRJkUDQ6jh57bKTHJEp9cmCdRevd//HKhDxCvHr5//2OP7UcP fPcKNIOndpZmFPz4EgCbNvcXxj20d+9DD+3bJ/9Wh2IKsQBae5tI32YCcW2bbg51M7WY+p3qCava JdM43l1F781p24qvh86OKGqLThlqDbJebAtfIPUF8cf0Jtqgh3OiVBuBFaNNpC4YasRiKl2OhIsh 9MWQS+bUmdXH1bjaUYnRvqA5MD4gE3jHA6oAF+/77cCCKJcfy9XH0q9vSI51qQMxsNT/q8n8P7sI wpmzFGduk5U2MZSrhKCKWjekGczZCFgcX7N69Lg7OKvOZA1kuNqV28ENEnS/Fnnxe6QCQmLG/kcm XuGwcmprwDF5XSEjTQ5lseMvF/HN3v5DRAFq2TngG/FeOucaiVPnYe3Y1ec853uu9g91f7XuHvUP 6zvMO80f/D/2vj0+quraf+9zzkwm80gyj8xMJq+TyWQSIJkJSYDARBggIgUCiKjxAeWRQIIhiSEg IkVq/VguVUQLFCk/f9RSVEojF5EiovUiF7mWH+UiUkr58aOUUvTnq15KuVTC/e51zkwmAazah/0j sz9r7bXXfu+11j57nzn7nBH/33mm4tyIT53nKy6OcFicRrdhaPKIXGe6O31o5ojv+FdXvJJqud15 Z2Vj5ZzIosolkX+p/JfIj1zbXOYVkZdypZtN/frkB/tHb6iq8HlTU5LSrYNZRVlpvhIamJpilc1M tmdEbrghz5430ryTD9guq+LBGr4mmhUcmJfHIkm3Ds6bkCMe7ZdzfKP6T86P9EnPi4qrpBvXw+gd LX14n4wbRybJxqA5zzJVNzl6bEv/6Bbv94H+Xgp60l/IeErXY/6DEx70198F5NBeHFs5aIRDzSpw FniGpueySObgXD5IBXKMQNA9zJvLPN6hNwzJrsJaxhepqswdmMtcw+20lKY3VhDSH7CiNU5M+tsj rgpz1u4rv2ceWG81zHaoaxCs90W/uyqr676u9jpaWl1X4hqbjG1HxAVUKa643rR0hICqxSW22oWL arXLkjosS5SDkRGJfioWFi6BEi6xuLpf61V44nX8CccXXMaE4wtdr+ovDAb0t2LLi7XdrPhfr3LS tx8bHxlV+sgL1dO/fvDNNx80pdvoAEOGJ/+plo0bbp7U+eaycUe+2yH3y4amrszxuTOqCisH9xtQ VZSV6vTmLx59z7P1fleKL+cnUN/0UG7psEXV48NhtaKhqulBset8EqutiDjXzP4jGvhzJrdl+jKl jeaXzHvMb5vPmA0LUh5JWZ2yKWWf5ajF6DGJ72R0MIW3RdNNipJk8vM0V3K6PTXN7nAZMqx9dvIf Ru05kUAgKcI5M1rzMiyuZcpO/nzUVVxsSlaDeftYVlqWmtWa9bMsA1YAv3uxRGz0xLfR6G+W87FX SYnj59ofpVe9H0/7f8WXabZYfMm5zJxpzWXa/yv6i0xiFm539fyLKjig+/8t7nQs9+lNBp2V8++9 dd8gly3Na1P/dO93O+hR++8LYcgzhHFf/s+vzShXbeI7SXk1y+dLYcGkd6uJcbwL43iHPIMVYia2 mpWX3FKRm/tMqck0A1vDJqs12eRP1f5ItWSO1/9ILcwT4RLxEYpRaiCQp/oLuTvVpeZFWKHZ443k 5uSkmpIjaalGV55sUVXGPG6xB0nuk2ZXTb9I4kniBntRzxvsVVXai8r159T0B5s+7+UwNt1GzTwq Jlu12210h1O8H96p2HOZw+jSRl4zQ6duhq+ydJifG4shx5XT+j+G9ABIYcLwk2wGdQVjz388smX/ A9FbtDtBDeP/z49JDB/RNuKB9SNr50s5JIzHJs3ZrZHafWQhg4j4JjpkkM+/Hu3/Y/5jxxanrJpV iypefpSipqrYuUV4pWOIc5Y0297oasx/AYk2Ox3RXC5ex9URTbcxW5otbJNt4+m1XH6z3aFdRNHb XJ5wG1S8c6tDvLv3bnrplj9Z4tptz2Fe7b7n+PhtT7vEuap9NdKVz5jqdLmcTpfTwZlZv8GZmRYx yxFzsjE/4trJ50QtTikStg+zv2CX7bv4HObkyVFb1MFLHS2ODY5DDsXxKn8BOlPA8/Qnv7EQOktn Hj5gCedWhlV95nGHng9vX+NJ7Ws8uS3uBGrnHbrd1CvvyZG2ruh8lt7Gzentnd/hFQU8pH1ksUr8 I3KrbIu9vP3yTdr+L3YvrPLKFWUVJFkkF0d/VOQu9Dwib3b/yLNTetm93WNiUpr0oPtx9wvu19z/ z93pNm2Qtkq/kGSTYkr3Kt70IqmPUpRe6KlUKtNHK6PTb1dud9Wm12bUFs3i9ygN6bM9szNmFz2g LExf617j2ST9WHkufYPnJekVZWf6Vs9PM35a9B/uNz2/dh/xvOs+4+lncWe6+0n93P083874dtEW 9yvufYZ9rhPuc/yc56L0Z/dFj117higlLf4QkXbioSNa3BrgLKAGogH5Y0FtCBwKyK2BpQFJHIGQ AoGn6PyDXz//0BHt83U6niSLUxATkuWPkvkLdBRCFm94SX6Knoz060choJXZ2WE6B+FXM7yr6RzE lTHRstg5CDV+DkJNOAehJpyDUPVzED/jp7Ddboc2nRK3IvmpaL7CJnMuT1bMhZE8X0R1RmzGiDVP VW02q7HFy71vZHDxN3qQfTcjWjogI1rUryIjWlAIlJ0DlOEDSrVXZESi04p40Sv8WToA8Z2ox32r FO0/uEIS6SSRToqm2SuknfzZqM2gTkvn6W+4lO+6IgZxq6t0gPBerBxcQcF+WhDVkI8SyEd+8lGY 8KMOt6fCEE0f8KDhcYMkzktIhlf5adYnwWIuTJkSv3Z/IM5ETBFHJvC7TAcmpsQOTPQ7f1ZEMm/3 c0TDzot3r4P4wkcmrrrJP2XKvVedM7oWU3/6NHbH4aUiU4ZJSeta0PC2vCRZLowdiYhtShKPRMR4 8rKGl3c2dPSJP/Z7z+oX63Y+PkfcnT4rFr1FXMq6fIYnWOgsyXX5fWldopXWY76dAysdKT0ZXZ1r z3VIjkr77XYpU9xjyfVP43MdLXkt+dNGvsHfSDvoOJh3IP9A2Z6KPSNTTczL1vrlax1/oCMPqnbk gY5CqNpRCCnCI6kRTJTOiCOSF1Ejvv6Rskggkh/pOyIyMjIgUhGJRGPHHQpDocJhdxgqdvLQdnXk umFp4s+iTHHsIS/PbbUamJuLow/rUg0tUA3fjWWIfzF/XaGD0uWtK7wjNTus30YwZGdUm80+c19j xHh2F0+Kf84uthA+E//0Q8IJiCniqIM4BkHHHcSBnA+8aWdi5x9038e8PU4/EDJ8OxQ70PBWjwMN W/QDDRdedOQL/7S4twX/5LbMqqFXHYmI5qcNFIcoiuOHKMzIlpYjTi7kiJMU/niu+DEI7dL/kt1r S60o33nl3Db4+tu06D8g/YTE6WiywzLMnmNxDCsXH/waA8JudnuG2nHJHDpyeI5jGBdo5KAs+zAu 0MhBmWmggEaKR6S5QHnmbHVoRSpQmSsjc2iaWHeXiYU2fIfuj9x5Ze+LaS5x53tv1AYivwooT6Dr vrpDLMa5duLus45c6F+iuc5j8sZ8aQP/ZtCVil36J8IovtP5cucrdAHr/CjHl+oM8m92bg44Ef87 cT2r45k8u06Y0O9EbID/e+fjSW6b/nfU4M43tXudNncSNqajTRQj7tF8xO2aVVndJljV6s4lylpY VRnfjcUE8zq8/n62PM8APsA+wRb1/Nn5335LsnOsc4y/gTfYFzoX+pc5l/lftr/q3OXf5/+lPwWm 6Shz2Muc2pomx2YLxxczmf6cpTk85yl/To7fn+nPF2cuOraHSmlv6NEPXfj7lTmTtYcADYantEcA kzkTryvCJcdT6uGeML2yyO9zlomTFx3RuYWFYTp64e+b73eWlanauynsMF/xnRWHk/EyRDjsnJly DI5ksfTJzHRFfD5YtCSWPoFI3/6Rfv36prCciTlSa86pnI/FzrRiojjwlmZQDa2GU4aPDUZDRnnf XTSLax8Nm3Jv2llMf7GbDAmLH/1JS/E9FoM+G/+FP1w/74IoFkzrmTrJlFZlqtKOhPLYN0Cvq149 /gfNk5o6F2Xk+Gzpbjp7cS+/nU+6Vz/Rk+YKXX7/W6R7dFSdJ2FudtjSk2lyniD9q6ZCUK6uO0Zi jv6AMflDaJOHvRs1p4hbxNyUYpZevXKB2a5cZGamiP1IUpheSeU3u0llqp3hVKczLdXvTuGSQ1Jt KS6bLcVmlVK42yZZeUqqyjxY9aoWq5lPUSKp5mHmFnG/LsM9pUV8nts7P+EWXY3+vPOZ+BGLwV1f SsRUp714VdL+NJfEZRzTFfmYseAf24b5KjZFeT/zbAa9c6QfT+exNzUn5Q3g8W/EyUcvf0eqpOct LjOp7fIFbXM39vIN9Lnv/WOlPW2CeJNxvrrzsjxE+T3rz9a+9I7jHb+UhEn2pzkD3P4sf0WOeJ+C C0S+PxCyO9LkVEPxXdFh2MTtlLwvMdV0VzQVVDSPqT5WeCRkPaIYAljzH/GFQ4G8PPUI86X5JF9G 2aWX+TfizxnS4yaExZtXMsJhLEi8vg8y4E2BH/94V/9S+k/xXi7e327XPo2sPzQ4wC5ehUDfThOH yuPfTtO+vmKUBpY5PCP655ptvowJA24aUZ7ldmdVDF842euzJatlw4v4J0F/ydDOpwZ/zSAnWzFt ld04kzcMGqvIbpfTLStjB/GGqd/wOhxWs2wYM6hz7bAaxiVxCuQJjJWN5b0MfSqP2iyMV7BAkikj RT91UlVDH1CEiGT94Au1TXqC638AeZWOS98Wg2+4H1OtOFuyqvNTeTBJ4J2os6+fL/K/5X/PL2/2 86zighLxYZ4j0RQQ2X6gXIE8tDQsqUgXn1yDT18EzQORIzIo4lX5JLBUQ06Nu4apSZBZKk/VZNbv rqiQXjRbk5kuKF9cdJjlIbLd0g5Wzl/hP9e+xqNLS/OuFhl8+ohzTGzxFScWbG08GJNX/ONnmjS1 FyEZY28ZpyMSJExpbbkd4lOTbRkZEytuGlme6fFkVoxYeEtGhtUcE1/xUN5QOUaRk20Oh7e8uq5z LYnP6SLxda6F+JwOa7JsgCxnDxvP6DdId0+w38UcT+Wz+KvSeumS3FeulufIryu/McwyDkpKSfqx 6c7kBcnHzWctx63ZcEut+20ltrdTzqWZ7Sb7fsdK50xXQXqKezR2T9/LCGas8P0h81y2O/twrl3t r17Ou98/Pr8q8IfgPYXfLBpStBjuZbhfFf2qzy/7buo3pdhSvLmkNlQaHhTeWJrf/0CZv3x1xaYB 7QMnDaqqNAyeMoQPeSPy3A0PDAtGa6LvDn9w+OYRX+91va7X9bpe1+t6Xa/rdb2u1/W6Xtfrel2v 63W9rtf1ul7X63pdr/vHOvqPZYj0GhPfhRe/OYQFzZmbQoKWWAov1WmZ3cmH6rSSkMbAvHytThtZ Ft+q00lsXzyNiZWyTTqdjDQHdNomrePnxLvT6DdAeUinObMoP9VpiSUZfDotsxJDnk4rCWkMzGoY r9NGlmK4U6eT2Mx4GhPzKu/odDLSNOi0jdcYFqBkrsioy2p8g2gD6DTj20Qbif9bopOI/xHRJqKv EJ2sj6FGa2Oo0doYarQ2hhqtJKTRxlCjtTHUaG0MNVobQ43WxlCjtTEUtDmh/RbRtqRUoq0J/BRB J+USnSbalhQm2gnakXQD0a6E9OnUR412J/AzKO8EojOpLq3M7IQ0uQl0gNJPIbov0fcQXUL0/YI2 JbTflFCXNYFvjfXleaayMoxIKasENZk1sHr4NayFNQPa2f2slTgjEWoDLfB08BspRQgxw1kTnMom gTcb+dvZPArVw69H6gXAdUgpSpiPcCNxVTYe/n3wGyn9dEA7lV0H/lz4bewe8FrYrC/RLlFqM5Wo 5bsVoUaEREtUdguo6RTSam4GN0wlqFR2g97CmdTiZmpXI6UOUb9mg9tELezZniHX6eUQGoU2lBBr 3wCU1R9OZUUopRF1tSFmHvW3nfVht10nfffytdInokc1GKPRiLuP2iV6ORZx7XBNlPIOyqfSyN4P fz5JRxshTQKzqKZ2GhERbqV8c2ncYiM3g/LGRvVGjOs4yF/L25YQ00q9qUMtM6lETRr3UV0zga9d rxYWaWei1fNJE+oobQtwHcW30sjfH5ebVlejXsJMvax6wkI71at6LlI0EVWEfH3gC32bEa/rWu1q vqrszz9KXaXXUUmzwWsjbdL0amZca6/d+y5N7t6uSMIYiJ5ofWmn+mL2IMrX+lpHuiF63kI2du2e aiM9vduo1ut20dM6xKi2I918yilau4B6Ux8vR6RsQorPlNHzallpaaU6uaFerWlpbmm/v7VeHdnS 1trSNr29saU5pA5valInNc5uaJ+nTqqfV9+2oL4uNLJlfltjfZs6vv4+tXGeOl1tb5teVz93ets9 asus65alNjar7Yi7tbmxvb5OvaV9ens9MjfXhVva1BbEtKkzW+Y3t6PoeaFJ9bPnN01vi5UzJKHK IQvq2+aJ8gaE+vdXi2oaZ7a1zGuZ1d7ntgS+nh7JJ95SM3l0y33T2+rUsfXt7U31bXe0zFfnTr9f nT+vHg1CB2a1NLer0+eprfVtcxvbReNm3E9NvfHWccMR20aB1raWuvkz20U37mtonNmQkBd+Y/PM pvl1yNreotY1zmttQgXoG3I1IsFMpKpvbg+paqzyluam+9Wixj5q/dwZIldXWc2x1NdsEiWva2ye rbbVz8NYzRRDm1A9DbJeVoRaUNSIWtrr5wo5tDWi1rqW+5qbWqYnVopGT9eaijGOi6Nlfnvr/Ha1 rn5B48x6kaahvqm1R48wCbaQCU6HsjVD2VuEAXIbFGwOwu/SBB2L16Z+YTQ0Tcrr5H+VX5V/BnhZ 3iVvSShLpG6Mh39DZdd3q6u+W2lUnpKj9FfGKjcpNwAPRurpMAphbtpFooFv5T/Aek1MAsORvk2/ vEyPrRnx68zHTM7ia7nEn8zESinA+BVaK4EjXvRYTWu7qcBH6d16v0TcMelRxqXHpKeYLK2T1oH+ vvR90Oul9aD/l/Q06P8tfQz6D9JF0P8tGxiXjXISk2WTbAKdLGOVJZtlK2ibbGeS7JDd4HhkDzhe 2Qc6U84EnSVngc6WB4IeJI9CypvkseCMkx8AvVj+BvhL5AdBL5XPg/6j/Cnoywr6o3BFvPtBFis6 xSzWV4oNKyVZcSse0F4FtSiZShbobCUfdEAJgi5UsNZSSpX+oMuUCtADlIGgBylYdylDlSjo4crX QI9RxoIep4wHPUGZAHqicjtqrFVmgZ6tNIGeqzyA2MXKg6CXKj8A/YyhkHFDkaEfkw3FxuGMG0cY RzPZ+DXjGNBjjbeAnmycDPpWYy3oO4xYAxsbjXOYZLzHiPWYscnYBHqucS7oZuMC0PcZ70OahcaF 4NxvXAr6m8aHwP+W8XHQK43fA3+t6S2s2H5uepfJpvcsNsYtKRaMucVjQXssRZa+oPtZ+oMus5Qz yVJhuQn0aAvaZvmaZRzoGgtWkpaJlomgb7bcDHqS5RbQky13gL7TOhYrv3HWGiZZx1tfgLYouqYJ MMNcjjB5etv0GczVUD+jjZU1TW9vZkMRw2+dVK0yF2PQPEnTVaJECaIMEeJi9cqkcZNHq8w9aUKN yrKIz7phg5ikmUq4L+GKuffMvYfdSXhGfO8kdaPsWNkbsYo3YcVuZhbovY2lsFTUZ2cO5kTL0skK ZGqN5ueg5aNggrfBNmbBzBawJewRtoKtYU+zLew1doCdZGfZh+wCt/JiXsGreDUfxyfzu3kdb9JG hQ9EORz+RdQP36qiFfBTqjQ/TdtP8bTntHT2KBPPeXOHC+Ek+FGN75im+4c137WL0imeJs9SzyrP cxQyek96P8kwZvgyQhkjtHjfHt9R33u+Ti0+c2vm3sxjme9nsSyXVk72Ks3PWar5uXdSSpNaoY5W p6rt6nJ1g7pDPUBcW2B34FDgTOBigbVALagoGF1wd0FrwcMFawu2aK0O1gkMf7lWWvBJzS9s0vw+ izS/71YtXfFrur+PNIEXd8IXacv+XP73d6grlWYvRvOWiWYsM2YpJ7PQDGRTjNhxOmDHRcxJFuyC 7U5gmcZJsGAVtnsb8xtrYcEB2Fk6K4CV3MZKLLWwlVLGk6uTnxF7JMyqZYwVjwLAwkIH4U8C1II+ Ah/zbnEdYAFgGeA1xkoxE4aOg27V44eIz/bqgL1t+Qj4iwErAKsADwHWATYANun+FsA2wE6UdQr+ XgBmh9BZ+Ifgv49yngOMBowH4JpRjt16+TT4swBNgA7AdsAuwOuAfVJmsTVUVPJ0eFZxIBQi6BuK FvcNtxWPCNWFF4aXlJhCl4pPhi6V+EJTBRQ3hR4qnkawqnha+OHi7aHXBJSUhT4kSAlNDS/X0pYE AWdDp0uOhEcU56BsAV4dOpBPgCM0BFBRcgrpjiPdnci/EvU4kMYRa09oHNozNbwwVFeyGWXuRnxp aBTBaPDXIDwQtIDxCK/v1s5laOczCeEVBG2gZxGsKD4MWBLaQvBwaEvJDvjPoW3P6W18HbAvtFeH twgOgBZwGPRh4p0gOAn6ZEL4DGgBH/8FOBk6p8NbqPet4oWgBXwKuoPK0OSA8S1xoX9n0KaTGHdd LiXFPcb/trCj5G5AezinZBHCT4dLCTaG3gqj/JLN4YHFHeGO4sna+JVsTYSwNdb/krPh0UJ+8MeT HDW92A6ZjCI4qbdLRT5AXL6aXIfE5Zg4nh1d5RZXhUaFdyXIracchew1+c9Bva9D5pMIJodaw/sQ 7pn+6vy10OcDyL8A+Q9jTB/SYYUO3cNderKOQITbKLwBsCkxPXQ2Mf0mSr8cuiNgZWibDjsJluuw BnFrKF7jrw9tCR9D+Bn463X/JPxdGKdduu69ro/dZ0EsnW6Pcf08FjoEOJqgv0cJuvT3KMG+0GmC k0gvIKa/70H33kvQ0wukk+dKJNCfkt52l/8Z0olRpJPQxavi3wONOYXmhiDFkx7H9dmk0dDn8wQ9 55WYng9F+AzCoMPvIVyN8MciPsxKysIXSlLC1vDy8KeUthIQm49Al0oIjwlNLTWJcNhYKoWNJb6w tSQIqAyzUqk0RUsvwnr6iUgPuyuZEXaU+mBXS2FXTyLcgLCK8CMIr0W4GeEgwo+Gc0oryQ69sEMv 7DBQsijcV7O70mLo7+LwvtIy2NrA4ufCHSU7wgNLDsLfHK7qisf8S3yEu+arddC7dWIOJNiDurrs 1iHgKt3ouDaU7O8BB3WI2fz78D+hObkuvBJtiaU7G4oifjLS3Ql/WslFjJ+ATg0SdOtQN906g7CA 2NwGuUFnz9O8VKnJqexY2RphD2QTsWvLQfRtB2Sh+8V9y4MEI8JLwmswtw/E/CBgfHkxbKhOmzPK y2iuWhNegvliXHEpwpMRxpiWV4bGlVfGw9uvSi/mpJXQ49i1aJY+9tecI3ANXF4+FFBdPqZ8Ivzb 4uPe8xrxqWY7MZsqnxE6R3A36Lu74nX6atvqEb6WLRDEbEHYAdlCeUN4eXlz+dJwKUE76luEa0D3 a8Klkh3lj5QcLH8kNi7lj4YHlj9ZKsZ0avlGwFqEn+4K97zGxOeennOQ3v+/8wpNYh7pI+xhGfae CMnl2IG65W9ij+nDLu9mtkKZjL3eSkOx4YdslWGT4XluNXQY9vI0wz7DPl5o2G/kvAgNMPAZRpPR xuuMaUY3n2P0Gn38XmOWMYu3G3OMg/h84xDjMP44dnl1fLVxlrGB/8B8r/levhH7shz+I8tdlv38 J9gjbJVSutaLfjcgi/HA0/D9gCLQG8Ur7AEVAKwn/bUArAGD2EsENoOO6vFmQJoOWDv2ccAfB8Ba 0o+1ph/rTz/WkX6sL/0LdB/rST/Wkf5lKGsrfKwr/dj3B8Rr8zfA341yFgK8gBxAANAXa/pS+AMB VYAlgIcBywErAWuwtwpipIewauyjarE7a8IuailbzlZhD/Uc28Z2s33sEJOCnxaaCqVC9L/QHOws TCtUQFmD5wsdwUugpOB7hSnBj5HuYqEZsW5QHwaPFjoKvaDOBA8EPw0eBnU8uAe5zchhDO4Mngu+ Rnk7gu8FLyC2M7gxeCS4GdSl4Lrg0eBpUBeCK4OvB9eA+iT4CHIfBLUKZW8JYm8dXI6cHcFdoJYG G4Jrg82gFgSnIvemv7tuynSfgxlbsPs30Z47DTri4IuxU7KyXawfY7mfANCC3E7GVOxbVchdhcxV 6IsKHVEh4/zT8LO0uFys/XPf10CFfgU/hC/eAAEdUaE7KnRHhV6p0BV1ku5Dx1TojQq9UaEnKvRF ha4UYr8QPA+4BBpb2EIjAHoGibDCOwHYRxRiH4G9HytsY/0KNhZsLthasKNgd8Gegv0FBwuOFBwv OFVwtuB94B0FnwQXIMXFgs6CjUFFYEBnwdagOZgWdAPeCi4OPhRcFlwB6awLHoL0TgRPB89hnOyQ AsZBOi/9kUnSnyARhSRiJImYIBEHSyaJmEkiqSSRNJKIHRIZz7wkkSzjbZBIDmThYLkWFyQSIIkE SSJ9/oE1cdhLA0m5L0vCaMMSVezuVOzqVOzuVOzsVOzsCoIsKbAvcCBwOHAscDJwpsAn/qGV/kv6 L7TxgnSBcdkJbZSME6B1MvTtVqaQvhksTouTGb9w6tHYmat/g113ivSYtBq1fk96iiXTfUUr3dey mQ6YfsFSTP9pOswcpqOmo8xlOmb6FUs3/dr0a+Yx/cb0G+Y1nTH9jmWYzpnOsUy6o5VF96lyMV4d bDuNmkPcU8GcWeP3+4v8IX+Ff4h/lT/qH+UfBzzJX5u30T/VX+ef42/1L/AvzjuYd9D/UN5W/7K8 rXCd/nX+Wv8K/waknJS3EW6rBn7tl1hiV3l1oixRUkI5qxBfC+pJcJ7s7sTdDgmzDjNKG6RXMRb/ Jv07y5HelM6yfOMi4yI2UlwhWLUl1xJkN9K9WvEGOYd+p80dz68gP64K0iZpFzNIu1GWj/LgysF8 zE/jIf7BZQErYBbj6hJxR4zu4KIM1CG0Ldo1buo05lTvhDusHgOcFC6wFG5MYGLgtsDdgRmBhkBz oD2wiNqwFmUnS89Kz6INP5FwFZNekF5A+dukbUyWXpJeQgtfQasM6Nt+ZqJemamFFsxmy/h+uuJN YnZ9dvrywPPfYjW5G+A2AbYQpblE+lph4bb14G+7Rhrhdl6H/0XdZ7WxZ/uu15ZrtWfTF28LJGAm K2RkhZysUCIrNJIVmsgKk8kKLWSFVrJCG6zwXZb6ubWYS6OkJ6HLVqwBfIxlY85JAHYNuB7/emkT y5LyTpFfk/3oVW4zXIzeCnd1ikezn4R7NHtH9qlrxmpud/ZZ4LVw3fl7sg/G6f3Z7yfEfEKci59R ZmKrDmZ3Ah8h/Ne7z+611l+txuPdWvJojz4m9u6L9uuvdmK+iF8/voe55ylcRcymn5t+Dt08ZDoE 3XzH9A5084TpFK4lvzX9ljnpOuGy1FhqmMcywTKBeemakfGF5t9aJr70zFkzzcAe8YUUtpGtQKhK n5U9lG4vAGt1drwrHU9jlxByxdOJGfj7sDWs8rT6qbYcqk08q2MiG2RkgwrZoJFsMIlsMJls0Ew2 aKEroe1vXJIYDUajYaDRKPiKSxLjKv4rwOzEjtAYeoknnlgT/zl0dvG4UZMTz0rg5ZCUOK9I4A3U 5MTHJfAmk5Q4n6PzJGb5q3RNaJn3urIxUkmMSuJUkkQlyVSSicpIvm5uBS17DC17Au3j1DIj1Zd0 3RyytEJaqfdFpnYq15XRF0n72S25Vo7P13NhYevYwyRPzXIySOqazXFYX4wnYe23luSZmO4ZTZps p87729nVZ9tvYuzVvf98saJPR3Sd1/rkI94n7ATpfAKPm9n5hDHSeBW6zifyxuk6n8ibo+t8jPf3 1fi/nc7+dfb0z6rxnO1gB2gtLqTDvNhre7HXTn+N1bj2/bM60WfT26a30bvTptPo3e9Nvwfvc68K 2Ta2q2uf4sSqzbOY1TiPwp0Q2DOZ6Livx5xICPVwXSldIzRIyBePTyjv6rISOK5d3Z2wUdMvTce/ bA8dnQQ17iVwD8MtcTqcDhFyHiM8jXCp5us0nHt5LCxyaCm70sTdw84DsRK7youlo3ISSnAvcZx3 nHcu6e6oh0dMZ7/A+kjiAdp9b9FnkkzwZP4MX8+LEV6byJVMksTFDvihbtxmqYFfZPQVmATuEemg NBXh2xK58hC5QhLrrGg37gZ5ndwX4b4JXElh8sqEGS4zoW8O6Rnph+jbj6RNmHWfl56HXW+RtmCv ulXaip7vlHayJPT835hJ2ov+J0u/kA5hfjwsvc1s0jvSOyxVOiYdY2nScek4s0unpFMo87eSmBNV i4o5Md+Sz9ItBZYCkvxnzRr/2LaInftjhJ/4Cut+6iup+4mvsO4nv8K6V32Fda/+Cut+imanMjEP 8djTalnE64s5i7OPu/H8tG840Y3n42IVub8bz8GtCG3vxjNz8XTThm48iX2K0KOJPOwFzyes67L0 dd37Ces6jfceO5OwrtN4p2n9V9WNd5z2REXdeIdpHeGK88RMLmYcRusQTusQidYhMtYhJ7EaPoXV SFI3C4lrrOlEN+0V+LsJfI0+0qVlYo0Tl/pjCfQTXXRiGj3v6oQyNfr/dtMe0a8i5gd2iycDqWfZ XenQC5FuG9PujXJmZgas+s3xcLercMoZxlIrWY2l+Z/VJewUPuc6gz/HP6T7qW3oN5bnjKekxEGE e4LGlxLg7h7hGXGapzQAmsnXeCZWYy79Ct3Jr7T2L+3+Znusz7v6PM3dpPejGKRtDQEqGEtuvTZY zTpd2wVWN6sxjfryzsr+mtx/yX3Jff2XsqmkDsaTlsRBhHtCd/60q9OYfF1pQccgxqsxnvgndqd1 +Cdz/3CbEs87X0rYS4h/50ydrZfPJLovcNUVKwxOViquY/uvVMaua9J0QzrhHOA6wvMMpURz4hcB zyF+rTiRK/mVGuIXAjcaZgJHlenAO5RxxE8VeZWbge9WJlGsSDOXYu9SVlGsoAcpdxF9RtBU/iRK eZeeXsTukTcDl4pTvlKpcQ/RHxM9VWD5iMBKJeG9FIvWylbBl63KeoENjxJmhMX92D3yWoGVaURX EP6UOKKE3VRarcjFzxv2C1rnLAQOCg74JwRNtQcpV9BQR/hRwuK5/Kkilk8VbQDeS1ir8QjVVSkw pdyjXCB6IWFqIdW+R+SVqqn8apFXqiZZVFPeU5RyJdHFOl5PfFHmSipho2ED8GKBpYeVbwGrhBcZ TgNfNPwQeKvhMkam1QD9kJaLcZaPGIsFFuMMeqXgCw5ixcibqNe7CS+nti3XaGrbchqB5dJzNDLT aDSonYLDV8qt1Oa9RB8heivRVtF+SlNMpX39Sn/CQsfargwGXnDlFuCGK0Luk648D/zhle8LiQtN llZdPi5ogdmlTnFf9hJp+H6i93eK9d8agSWH4PMOwZccnTsInxMy1TmiVW2XoaU8RcTyNkqf0tlK eKjgEL+Y8tZS7bWUt1bUzvfobVAFTXmnUu2XqPbdVP5KKmcP1VJMaVZqKanNlzq3CD71yKFhkR60 sJ3jVKOD0ngFloJUztROGkOB2SXirBSt4isFjTJRAjtLo7GZSjNROXWGDBoZkfI8SWSMPmKihadI UudJgudJu86TXqVo/dU0nHpdTCUcoJRjaHzOCz1kj1J/vVr5ZEG1wna4l2L3C71lJ0SZqHELtfY4 8dcTf4O4hyP4bDtp8kHDmyjhW4aXgPsIvUVPj1NPSQOFrjLx41fWE95Ka/gyovcSre2xaCdzZY6E Eq6kEX1MYOzgBL2McLuW68qfgI0iZSfdeeIbqQRtH3WJ0owTGC1gsX0Txk7MBrXE+SPhn1HeNqJ/ QvhXxFlMtLYb1PZ1zxLeRvgXhA9TypWETxFnDWHaV3Iv0e8RflFgSbu/9apOY3ci30gjvI+su+LK bci1U2DwJxLfJWhlv6CNfuK8JuYEkYbtU7Ark7Iu7yN6nMgraJSAva30G2Mt4ajAQrKyW8yQsirO mwHXinJEenmtwFKdcQLhF0n39hO9UYwVzTDjjYsFJ8lDM7yYeaqNKSI2qZb4hwgTbTxA8+FColdS aaRdVEK1zjlBsVTmZXGVqeu8B3jd/1R3HlBRLFu/r5maakIBIiCCkjMIMiAZFBFBRDKICZUcJAoI gihBkgEjGBAE8aiYPYKCIoo5YUCPWcw5oWIO+Lo3yMF7z333rfW+7551Zblnd3fV7p7u+v2rqrur 5junqynf67ha5vtJ2Mr5IwW+UAd1QB20FeomjvHFhK0/+Zk/ylk7UPAeIg+GvEshfji3lVnHRWC4 aClgdzHZXN0H60PB9+HOMN+HaEDt1gLxr4M9AXt8D/YAt5V7S4KfQrgjn8CMAjuMtbLMDS4C0weY BU0AWiuBRyEQmt3Rm7VDwTZDbSXLaRe6Agp2iKunWMv1/V6DJsyHOPs4HWZrOs6KchadALImcUSj L8D1JO4Msz5XT8lyJYrdK1f+GSjzLp1MdfWajTjeoXxOAnsI0qhBmdQBOxzWw/3VzrsmrB5xaRaA TecsewScfQB2H0R24SIj9EMe9rIfLNta+DGp4ylnIc4psAfBvkJsO4TNw/nbIYI92E2dOoG4MYX5 vDjUc0yhC4wp9O8eU6gC4wJFEDffiCjqhXpzP1wB67g2mggSY9tU0kgGUUS6Rxry4V7Cr2MNVXqM MuSxPYTOTykkGxISm4CSwaaDzQqNiYpAheFRcUFoAdjiqLioZFQKtjIqKT4GrQe7hU0YhHaCrY+J D4lB+8EeAXsqNiw0Cp0HezmRi3kT7D347vxuy4cxiwhah5wlPaxIDyvoYWkPi7vOJYIWJmeZHla0 y0qxZ0AHDUQWfznqsTNfQtdnSuc4PjS/s9XKC2CtGPuZ0vW5qPOTudD5KW7Ipmc/JY915pN60TX6 cVvn+t5doxF7d40T7J3B9ekQT8ID4idz7wwigYiEiKSIlEgveLb0mVN3nipPDUYOHmKjKCANZMge /VDkivzYI+YoEWAZ7k1N8EZ0ey7d3shuz7XbGwUew+5RDvVDauw5MYQobyDCW8jdDjnfQa73kOMD N/MNW8oU2LOohdmeBP8T7gu5+kEueUivyKXnegVIAveBOHKQl3tq+IbdK8IiWASJwJuYotDrxEwW k8mHEos7J/8Rx+LQhpaA88CmwE8ZObyUS8HIM/IsBv0YtkfJvX/OpeD5o2qsgtWwFtbDhnggNsUW OAfn4nxciOfiBXgRLsbLcClejavwerwJb8Hb8A68E+/Ge/F+fAgfw6fwWXwBX8bX8S18Dz/Cz/AL /Aq/xm8F3oLRxIgYExMyiJgTS2JNBhMH4kRGEm/iTkaTcWQiCSJhJIrEkngylSSRaSSVpJEZZCbJ JNlkNskjBWQOmUeKyEKylCwnq0gFWUs2kO2khtSRBnKAHCSHyVFygpwhLeQSuUZayV3ykDwlL8kb 8p58Jt8ZHkMYMUaS6c30YVQZdUaT0WZ0GX1mAGPEGDMmjDljydgygxl7ZjwziQlmIqkC7UeVaAAN pKE0ksbQBJpMp9MMmkVzaT6dSxfQJXQZLaWraRVdTzfRbXQn3U330v30ED1CuSee1VgZK7NXQxWr sldDE2siPtbFuuzVGIAHsKXICBshgk2wCWKwOTZnr2k2zkaieDaejcRwHs5D4rgAFyCK5+A5bGko wkVIEi/EC5EUXspezV64BJcgabwSr0S9cTkuRzJ4DV6DZPE6vA7J4Y14I+qDN+PNSB5vxVtRX7wd b0cK+Hf8O1LEu/Au1A/vwXtQf9yIG5ESPogPImV8FLO9WnwSn0Sq+Aw+g9RwC25B6vgSvoQ08DV8 DWniVtzKluC7+C7Sxg/xQ6SDn+KnSBc/x8+RHn6JXyJ93IbbkAF+g9+gAQIvgRcyFPgJ/JARMSSG aCBh/5AxEbK9VCExJabIhJgRM2RKLIgFGkSsiBUyI3bEDpmToWQosiDDyXBkSVyIC7IibsQNWRMv tuVjQ/yIH7IlY8lYZEcCSAAaTAJJIBpCQtla0p5Ekkg0lMSQGORA4tgacxhJIAnIkSSSRDScJJNk 5ERSSApyJtPZOnEESSfpyIVksLX2SDKLzEKuJItkoVEkh+QgN5JLcpE7ySf5yIMUkkLkSeaSuciL zGdrUm+ygCxAPmQJWYJ8yTKyDPmRUlKKRpPVZDXyJ1WkCo0h68l6NJZsI9vQOLKT7ETjyW6yG00g e8leFED2s222iaSJNKFJ5BA5hCaTI+QICmTL9QkURJpJMwom58l5FEL+IH+gUHKVXEVh5CbbRgon d8gdFEEekAcokjwhT1AUeUFeoCnkNdvjiybvyDsUQz6RTyiWfCPfUBzDCXs8I2AEKIERZUTRVEaC kUCJjDQjjZIYOUYOceNSVNA0Ro1RQymMBtuqTGW0GC00ndFhdFAao8fooXTGgDFAMxhDtu2XwQxk BqKZjJARolmMGWOGMhkLxgJlMTaMDcpm7Bg7lMMMYYag2cw4ZhzKZSYyE1EeE8QEoXwmgolABbQv 7YsKqSJVRHOoMlVGc+kEOgHNo5PpZDSfhtAQVEQjaARaQKNpNFpI42k8WkSTaBJaTFNpKlpCZ9AZ aCnNpJmomM6ms1EJzaN5aBmdQ+eg5bSIFqEVdDFdjFbSElqCSulKuhKtouW0HJXRNXQNKqfr6Dq0 mm6kG1EF3Uq3okr6O/0draG76C5URffQPWgtbaSN6Dd6kB5E6+hhehitp0fpUcT9QuVNFI01sA42 wEJsht/h+XgJXoHLcCX+DVfjWlyP9+EmfASfwM34PP4DX8U38R38AD9h9fIFfifwFYwhtsSeOJIR ZBTxJZ5kDJlAJpMQEkGiyWJSQlaScrKGbCS/k11kD2lkY+iQ4+Q0OUcukivkBrlN7pPH5DlpI+3k I/lKfuAnDMUajCyjyJgyAUwgE0pV6CQaTMPpFBpHE2kKTaezaCGdTxfRYrqCltFK+hutplvoDlpL 6+k+2kS5d7CjQckQKBkPlIwPGoZBwwSgYQS0igGVEgF9EgV9EgN9Egd9oqBPEqBDkqBDUqBDvUCH pEGHeoMOyYAOyYIOyYEO9QEdkgcd6gs6pAA6pAg61A90qD/okBJojzJojwpojyroihroijroigbo iiboihboijboig7oii7oih7oij7oigHoygDQFUMg3giIHwjEGwPxQiDeBFg3BdYHAetmwLo5sG4B lFsC5VZAuTVQbgOU2wLldkD5YKB8CFBuD5QPBcodgPJhQLkjUD4cKHcCyp2B8hFAuQvwPRL4dgW+ R0EbwA1IdQcWPYBFT2DRC8jzBvJ8gDxfIM8PyBsN5PkDeWOAvLFA3jggbzzQNgFoCwDaJgJtk4C2 yUBbINAWBLQFA20hQFso0BYGtIUDbRFAWyTQFgWETWFL4QuUhNWxNtbHxngQbsfz8GK8HK/CFXgt 3oBrcB1uwAfwYXwcn8bn8EV8Bd/At/F9/JgrFQIf3C7wEfjjecSGDCHDiDNxJT7Eg/iT8WQSCSbh ZApZRIrJClJGKlnVriY7SC2pJ/vYPBexNjlGTpGz5AK5TK6TW+QeeUSekVfkLflAvpAO/JjYMOJY nZFhFBhTMoz1JjCTmRBygfanE2kQDaNRNJZOpdNoGp1JC+g8upAupcvpKlpB19INdDPdTmtoHW2g B+hx9rsm/ZcRx9X5ysCdCnCnCtypQa2uDvRpAH2aQJ8W0KcN9OkAfbpAnx7Qpw/0GQB9A4A+Q6DP COgbCPQZA31CoM8E6DMF+gZBfWsGDJoDgxbAoCUwaAUMWkN9awMk2gKJdkDiYCBxCJBoDyQOBRId gMRhQKIjkDgcSHQCEp2BxBFAoguQOBJIdAUSRwGJblDfugOPHsCjJ/DoBTx6A48+UGf6Qp3pB2yO Bjb9gc0xUE+OBULHAaHjgdAJQGgAEDoRCJ0EhE4GQgOB0CAgNBgIDQFCQ4HQMCA0HAiNAEIjgdAo IHQKEBoNhMYAobFAaBwQGg+EJgChU4HQRHi7WoLt4QSiKrQF7UZN6BT6A91CT9Bb9I3tsXT1f5AB ErI9MTvM9nXYvsZH1ubiz6wtxF9Zu4DJZq0KE4X4xIiJZq0xE8tak7+I8AEifIIIXyDCN4iQAxGm QIQYiBAHEdgeHBPPpQAvodub2u0ldntJ3V5ytzet20v56Um4dXvu4LH9N1Z17iDEqkMbu9e3pB0J WJVge42sUnxFoizhTdz9CV4ZUkRWaBhyY3vTgazCJbN96cLuc3cdPeCGYPHkeCo8PZ4pz47nzPOC N+MEVI/tF64ET7/bM/jp8c+w3grwznZ757q9891eC3gYevdy/AvcEv8g4lMP/n3WXwZpLnan/qPb u/RLvsuQ7xBri/iHWVsCaa70SCPPP8LF4x9l+7Er2M+r3ZGudXvXu70b3d7Nbq+127vV7d3u9u6A J4Kk2dKh1nWXwo5/kt1bObu/k7DXcv5xGNd2il1azS6fgrWr+WzrhrV3u2PdA48b+9j5vm8lfz2b spq/BYnzt/G3oV78HfzfkTS/hl+LZPi7+XuRXNcMvHLcrD4wVg7BE2Ru7N0adsNm/mY2Zi2bHvMb +Y3w3jCfXwxPI7lxVVw/XYSNQeB+lmbXjGrKMJeaChvjAFKFp4v28HSRi+8Ko6R0kBncK5Cmpmx9 wJY4/Oynx8hDiRjELrWzffhWSCeFM9nag93W+YmfwV0DrmeJoI/IY3PehvslMqjzCaaA/5g9Uu4O Po9fCfsl7Dn+eR8F7lPwT8N3ae6+7g+4t1LAe9jtPfrpMelc6v/rufl5H6pr1rD+3B1FOViL+ucL c/rnMGIG+S75HyV5IvzKnP5J7Kp4Po9nQoViDBkghfn9CBIGMeIDGJ6Al2PJ5wkqfYXeQsMea5Sq VLKUkB38eaJgmBQ1BiYzDUNDuD+heo9gAjm3WdWZis8jNKbuujd6Q+umU82Wo6ZU5siPEOYIZIQ5 /C+VmM/j83uhg2ienV1h75YhH0Je3B4qlOw+Um6WYmGCyQChPoNHC6ishmN8QloiN+Wkml6IvpqJ tbWlWvckjzCh5EATFaFSZ+I+v27pmmrSRF2oym3Hsgp/bveJj09Wc5iWHBmfGJWcJlTpK2ltKTQx EQothey/8X0lTYUmpoNMuhb/hiPK4Wn0PC08gnAOrxdi14vzc3g8tJHfeDDhke1bj/56FcunTxI+ q9pYpD35U0eJ29q6jvIqtSEZ3lWrqhYGmka3DAtNe7Ul5aTf9bfPy/KVFlbkhtccjU4P1rysbHer F2/Jk2VHDhiFl5ZG6qw8b2N4QGLXWJ2Dzo/Fh1gtM9yoZ139YuTsYfdzezWUxowO2pKTsSbQKNXt 6craUNtSLyUTUS25io2PFw9QeDR4RYhc4FgSVqFs6VPwcUNbMf9Y/4sHRjvVzMk6YPPCr9hj2/cN 6bHJHtsVmpeJ6amjMYsCoywbRsmI2Pn/mPD1t3Bx0fUXsv3HtO22nSSfnSq4/mH/tqySjh1nMi9v 6JcYYHdq32vRtRrCGibvZI1aqmzebT5mC/7a7Gph9jphdhV7NpV5guxSYfbyLOkJ5xPaohJXa3rP ktvpvuDH6TWJ//nrl/NvyjjmrmHJE9pU1L5cwfxlPU/ramrv9oBA04rV9PQQsrhw4UmbR+pvX49Z arircsSJ4LZvV5ptbcdvtPCL6tCKtT/ZvOkWyWg1KRpcIZ0wpaFDxlMhqunbecf7vcereT4LnrF9 k+KJAZbaRvvD1sjM1e4Vsvajn9Jn9ZOX+7T7bIlzNBX5ntP308OIGEnvD41vfI43Pj4i/KZmIlao XKLfz/2SMn/dm6w7uHbCu99bT4x5FTbyuI/f7lqsJ/Nj0eXXogtn1S8/utnS8EH6g+rU+ymV6PwU +4MXLObecZCpNp/Sf8oN87t/KAkeVDsJTowfZBXnriQZXCdeNf/iJT975zNKo9cn3JCxKVg6rWLD hUpWFQKFOditUxXEB27ufdPrR0D56aafmqL8d4kBy72VKfuPVQBTVgxMTNlF859ikAYKygZhZPmj fU1khb25BVFZ8TFBSZFRcRHJ7G6khVLcShFZEZ+w0Nj4uNCfByb+rw5MU6jeeWD9em4PDVPzjYqI 46Z49XJ0+LeqUJc28/LEGifrarMtJtc/a5uPTG36qrr6uNPUthbnJ3/MPxzt5hP8biX/sPvVkTHG WkPCDpzVrKMudZnTWp0aNy2U8jqqPeBt5WNJTdUWB60vwSvPKTqtW+qquvJMjbHGYVejjPhrfVRs 51tLW7c26r8LtzXimf7o0HVZvyuGV1D2de/OkMyczwGV2bl5C3a8rS9ee85qvVdeX90Cj1bhBzT4 3bHPg7P357+Msd4w0OxD7cDt4jODF08PL1uRJJm//e2RdrU9njJFIacNr5k6Kb5qcF1m6+WrcDbc O23T1oIT/kMqcrwK48jv5gdnaDX6hA9e6dE8YNaguNwRTMvq8675/Lh89FtTwW3fLlX4Isz+KJTl REFbICEUZ0TZCo0QEYz/O6SiF3eMsjzeDwERYvZDqMytkBLIC+Salc+moIQJ299cP+JR6j184Nrh Ia+FlNvcSyBgMcrvgQ5ozIzN22a56rw9u88juWqsbrLBtJr875vdiqcj96ennivcjDoqVZXRznc8 dqqg+ZNv86GKRv/41yHDNw5Hr5adKL2kVE8rFCWLr1xX2ao/s+3l+qQtC29ZLxi8Yso+q9gLhds1 v99+ejlKbHFhY8dd1GDW/jHjs7TMQPJcf9nSYdF6U+usFt4RkTw5MfJMY5ZDdHh1Q13DArNTb7F0 Rvr7C3eG3Z7Rcffulo4Pty9J1iRcXnLfc7dVVYbRH4NvmNFgS35F9hTNOR8CQhbuGN9gfSVw/ujc foPe266ozJGomjyvxrBuzbrTm6+r7T4gVMxTk5M02OfzzuHOJOH9JXpRBQcT7rVv2Hw2a1hiihSr MemsxgR3aUwQo5sNLSTRnhwRVmf+Rqo5wbFilcbU1MTUzNycExwh2/xgFwdxi8Ls2f8rxyYJBYct ugJ3Ty+fn8nxv0j+b7WnMbF2zmOlirzjyfWBAdhicNn3leml+s4aOzYU+L585WxzfAKhY6rrTpHm i26pIxLyah6evh3xeO33ZN2lERVX5uLhwmMfT+49aaMs6j/cs6+o5OdaxchNWkpfyZi8p0c9RNQt Nzw/a2i8e9gZdbLh8qOLemOO908/q28hcmb16OaGNxrPqzV/k9Q/9PX84fFDQgYfNxxJZ6TlvS5s m9roOP7+2hrJ9tFfte/cU7v4uHRS8bpBRnqZY/qPniJhOrwtPCb+tVVZG39r6ZrWFSLSUnYKUffS PJzl7uyZf35abNkWVGY07L13/fh3051mPx2YMaBh4hnFIL2txY7iR6cM+7HLdNtv+hq35J9c7NKe T8Ls93+tPX9SrNmSZODW+PWh+pepKiv7tPT9fGT9XLh8yr046lmQRbJAN5Q1BQpC+ay/xn44l0BV MFhoK7SutKw0zx8UmZycYGNsHJIYMzD25zUcGBIfa5wQHcWtNe6atjzJ2NGXLXgD2VVCl59HyLZL 7IQ2Qqufy0J+vmFXwNTU1L8KGJbYI1LyPwAF6uOofy6kMeZ+UuzhlVdiJQptj7kkpWufNbxnOaPc rKJR8+z+21cD0npHy3qr8UL2JH4UvX9spreBvN4fLY9XGZxTkLwgO3Wx/gv/xs+Xj0oabw8zinV3 0vdPzPW0vzBF2SF4Y1rAgtfHU+ee5usNLD9eNuDhHgOx1hfL7z1ML5okXei7pjXQM3XF1MDqCdaL L26WUSVPDzttvHjIe8/2+pvfmFz0LnntjR/NypWaROSBrvmh5YsUN+UE6j75mjtApUVwesG5HMkr 1e6OQ6dduNWa2jY3ILpXQejC2r11ezdH+Kk7bXKNfOw3aZ5cQMT0F4sCsPRi0XItteVPbqPeCRs/ 70xMqNt271CFPJ9Vn3JWffI61Ud6Cl3p2YS0N/e+4aQ6Nj2i6h816O9p61gIrU0shCZCMzNLTnqs 2cW/oa3jFxUblpQcFJvw/9rWuWkZ93X7iWGuUxVOnHUZ4tv0ZbPcXkPTBhlPnxOzXw4ZdG2kyRK9 3YtD76h65e49NKolk3xqm7Z/3vHqS9uiEsKn64Y/2V3XlrfnzKtN32V+o+M09I3PDb3mL+ifsis2 NNbV70brm1sHKmYfz7qd6ca3LH7ftFrUXyVyxJlrTSkBxjN3awtq/SdMUQr5kZVh9+qSQNvdOjVZ ZOKhgKv5lobTTko9U7EWy0jpKI+JS7/zYsjC5aunSk028FQIDjRdfWG2xwCNgEinebeMc6W9dn7e 1a8o5pX2KtlPp6Wv5Em9y0lJsjhWkl7VHMi8IDvyB9V9Kp6Q65A7Nq84boeqoUtzfJnjnSlPMnUW RHfqTQ5Pjz0jWn+lOKL/Ha0daUas635DHx7XhEE9hDL+iYf98j1mm0flL9xX9myLrYPjsfNCxe4M cnyBhIo48kXTUDByRA6/toT+qRn1FwJV7N7b5FCGV0PvBWuCRHhS8xOcitqS/BrtxYjRj3pv3zyl l9aL69b601vzd9v2b/m6ZcPJut+91fvHi0bNisZVGs4vY2pjMzTqnS/mthf12i8y1+Lg81lPEyY6 VSy50Hy2dUHT3QMGZzJenNxmeqlgz+mQIxYtCuoHUm7Zltb0T1qtXni1tlbGb/67skNhrqV6OmWB c3vZHpcNm+7ScG7rbBvPHcFjbwmfPrVWvj/n7XXr7M+y6vNDs0IYwbK3pXxH4xnOhXt/8K+FfXa9 dR0nL60hcRLN5Tf1gjJc3vQt661uxVcq2MIcXWZa/3DoMd/BjRvn3HoSbln0TmNZWfOOVD9vm8uJ w3dqfmAFahMrUEu6m0fFRtA8Evv7mkf/JATQPBJampqz0mRqAho1qHPRhFsUZtf8J5pHukLtzkWV OMeoBO4XMYb7Oqk5+XrYWDpYmRpZWFk5GFk7W5uaaAs1O7+T0q/fyciX+1JqvmGJ3C9o/Ft5K8kW Vxum4J1+reTlqu83C1q+Si2UfbbJUk8mpcPda3PKcoOlI+5s9I/iPyye5Z53I3Nq2zR0o8Ex5mv8 lqmvB7RkLDlb3Ld8zdG9nz/Oag26ayRUKdMxSrF/5LxswbarcyyvNre1n5tw+FvknbehC1c9OSzz ee3+3G+X550lgxt5KV66+FNunXx+UeD+ifqGdufWfV8x3lzZU77J6qpKkP1gixp/uT6pJbbSX9CO pfcmWm7WbQgxdJHLHn0/5tnGASVFhVKz1qJ1qVoiKwwScL2B1qLSW0erNEYdcBvHpPolOu4YEtq6 NFd07O6OpwUjxSxqaj4N2jjLrSot03ScvtTqXe/v2K22f+Fs27M59acg6JUUHuDbPr9evHemc68v p9/NKv/R8ktL6S8V4/+npZSclBAS9D/SUvoZKfmvxfqX9h/T9FdqhV5t+XbvQmH4Kf374/ecQTmz +gYc1Ron01D9MfpKQUfR6V0pqv01Pny8e6p2jwOvn+VWF8tlCV+aB23Qm19PdyfL6tXVTLtrIHZv nuftFfbL68xksp9Jtyrf3Bt6zsPL1m3ud8VW7W2XlhU8G3Xk4evPDn0n8p6PKZyZkv4wvqNAbcvS svmlByb3q+wj1LpTNStosbK+/uGRi2wcZ895devS7FZPQ3Pbxw4OvE1Igr69PLL/2WFFM3a0GxVN 1L+7vyhzcZ+U2sCvcrqb4mVChumNtZlrO2/og7qjzUvGKDn7Ry88vcTdn6BTn4RDnTxuKxY2vpd+ 3drvtp5Krffb1Ds69xvEsmVuqticdzLJEWxlFWsjn8cTZhf8jV22XzqSf94Ar8y+KpTrrp30eCYi mMAjD67O6rqYYthEouc9d/Zo/lyiJlLCnlv7sFrSnVFgwgIQOdXvreetiaWMktwQhUV6heUyW4uF wT2ySJj4CX0q9bJ0/uWvvP3yu2lrdLK0/mXZTU5LiI9IDEqITFP7B60S5PDQkLciJzLtsenO+97a Hw8/8/tyaqnvIr/P1vXlPPEvB6zGVSjqZ6a2L7k6pMI1XWrPI/1jT72n6ea/dNJMnpsmpqmRdSGn 4WixzMLSfVojIrcdl/4U8WHpTotD9bOypj3c7i0uL3h00bl+9Y905wXDn1Q3+X2RH1MS3aCdssC9 ZGAxKtOZdFk3duSgEeuKk8Rdrz5e0THNU6J/+ke9a3lhlx0/mMwMGH/x/UeBhpZ4x9CE9UdMn51i XAqqX8hutkv4NHPtldjAqapfte0PxW7wlpsXa7/dYIbO7lrvEhunNn2Xj8vuHfJGJ79X5OQmeNYU teuOHdE0f4/COwd7h6rvl93lI13vDv8hOWFr+5ocvqowh9//zyvEmOTwJdhVov/xAvqPleYvVblI VwGtnChU6FkO6Z8PiHjsPru3EJNebJVrzT0BYf9bmJmP/6diOHalb0T91OVFo2/G6NanWm5wG/ni yD8oFldEwteI5KWvOv77u4Umxu7Jc1Y/D/Xcu3OV8pQl3+JPnY0623L7elCHy5iIr+rBTbc1+skI JnvPc022lj8mOOKvZeVhH24tW+ywq+mCYcGym9olF13iSis+x6/bccxl7oAyrc9808OSHxWdxz93 e78obHvNBNmlemFF92e+EBm2t8Ai+fCN3ajNek5S+wOt1K+79VKcHhbxr70eJJnWnDBd/lxHrc/L +2IT+6Vo792Ypih1xb3OVDGthD/R/fZ3zxlxOfHzxcpFlFUz7ksfvCaTEp+tOl5Y5O1x5HThjD4H fmzlLd7/TXzCwzQHRwnsfPZ0UtujkWOPzwwu0Y5U1DwYNSIz0vl9VOzUN5uPrEfo/wDfYTFDDQpl bmRzdHJlYW0NCmVuZG9iag0KNzQxIDAgb2JqDQpbIDI5MyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDYzNyA2MzcgNjM3IDYzNyA2MzcgNjM3IDYzNyA2MzcgMCAzNjMgMCAwIDAgMCAw IDAgMCAwIDY2NyA3NTcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjEyIDAgMCAwIDAg MCAwIDQ1NCAwIDQ1NCAwIDAgMCAwIDAgMCA2MjkgNTk0IDAgMCAwIDAgMCAwIDMwMiA5NTQgNjQw IDYxNyAwIDAgMCAwIDQxNl0gDQplbmRvYmoNCjc0MiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCA0MTAyMi9MZW5ndGgxIDE5NTkyMD4+DQpzdHJlYW0NCnic7J0JfBRF2v+f6u65 ZzJ3jpkkPZPJPUkm90UgAzkAuUnARAgkECCgSDSgqLiwHqABV3e9dj3R3XXfdT2GRDF4ouju6uuF u954s7oqUdaDVTEz79NHgsy6+v/v+/L58NHnW+lfPV1V3V1dVV3dz6cnM8AAwI0iwOzGlqmT7zw3 ciJwb90P4L1icmNT85fT4QPg3NMB+OmTZ89q4eZY3wcu+ZcAtw1Nbpk3aULu3wPAPTYbIHXV9NaW KVMyT94HkHYFgKVtVkuo9NXVi5wA7CU8Suf8xhlt6/+58VSA/AMAmjeXru7q5R7gnwD29AbM37D0 jLW++878dT6wfT1YIf3y3hWrH3nqvamY/wWA9rwVXX29kAQGrE8dlretOOWs5YdXvHQRsDd7cbWn p3v1+t7LH8kFKH4S2PWRnmVd3a8WzPwdHn8hlq/swQTrGi0en2H9ILNn9dr1ffuM2QBcNZ7vSaes WdoVXf7VZGAHsb6eW1d3re91ZOv6sPwQlved2rV62d2tn80HznQBgOGq3jV9a2N98DjWJ1XK7z19 We/Oj5NbgT2P56P9AKS21VgXNtR/eepia93n4NWDxB3Pvbleih+712n46uRoswX0m7Esnhco4HZ6 Fm3HNuz56uSvWixyylG0SymWVpgMvLzOgQ3CMA9bbSUeV4IXzNz9oAG95hpNGe4gS4n57fA4t0OP p6AXeI0gcMJbUBTbDZ0LcJs8acMZLT4fSGG7Nh3rME7P2O98jMV82K7CUs1e6Uyxc9QqcW3q8iD8 Ev4XaJJhDy5X47ICl0Jc1uOyBJd1uNTLx/o77Pne/ZwIDVorXPO/qYvw7r/P42+GW9R4y7+tgwEq hd1Q/u/yuVWwWXcTbNaIsFk4+K/l+BZw///VmCAIgiAIgiAIgiAIgiAIgiAIgji+sbQylp6eEJdq UgHzaEpCfJE8JTJikGFqnGBlDjk+FrUlCIIgCIIgCII4DmFSYAw9qC/0MdCDIRYFg6zoMqGawIRq BnNsBCxgQU0AK6oVbKg2sKPawYHqAGfsa3CCG9UFiahuWRMhGTUJUmKHIVnWFPCgesCL6oV01FTU ryANRNR08KGK4Ef1QQaqHwKxLyEDMlEDkIWaCdmoWZCLmg15sS8gR9ZcyEfNgwLUfChCDaL+Ewog hFoIxahFUIIaglLUYiiLHYISKEcthQrUMqhCLYdq1AqoiX0OlbJWQS1qNdSh1shaCxNin8E4qEet gzDqeJiIOgEmodZDQ+xTCEMj6kRoQp0Ek1EbYApqI+on0ARTUZthGupkmI46RdapMDP2DzgBZqFO gzmo02WdAXNRZ0JL7CDMknU2zEOdAyeizoW22MfQImsrtKPOgwWo82Eh6omoH0EbLEJth8WoJ0En 6gLoQl0IS2IHoAOWoi6CbtTFsAy1E1agdkFP7ENYIutSWIXaDSejLpN1OZwS+wBWwGrUHuhFXSnr KjgN9WQ4PfY+nAJ9qKthLeqpsA51DZyJ2ov6dzgN1qOeDmej9sE5qGtlXQcbYu/BGXAu6pmwCXW9 rGfBT1HPhvNi78I5cD7qBrgA9Vy4EPUnsAV1I+rfYBNcjPpT6Ec9D7aini/rBbAtth8uhJ+hboZL UbfAZagXwc9RL4ZfxN6BfrgcdStcgboNrkS9BK5C/RlcHXsbLoVfoV4G16D+XNZfwLWol8P1sbfg CrgB9Uq4EfUq2I56NdyE+kv4dexN+JWs18BvUK+F36JeJ+v18F+xN+AG+D3qjXAr6nZZb4I/oN4M t8deh1/DHai/kfW3EEG9BXag/g4GYq/Bf8Eg6u/hLtRb4W7UP8h6GwzF9sHtsAv1DrgX9U5ZI3A/ 6g54IPYqDMg6CA+i3gW7Ue+GR1B3or4C98Ae1CF4FHUXPIZ6L/wR9T74U+xluB8eR31A1gfhCdSH 4EnU3fBU7CV4WNZH4GnUPfAs6qPwHOpjqC/CH+EvqH+Cv6L+GZ5HfRxeQH0CXoy9AP8NL6M+KetT 8Crq07AP9Rl4LfY8PCvrXngd9Tl4E/Uv8BbqX+Ht2F/heXgH9QXYj/oi/A31JXgX9WV4L/YXeAXe R31V1n3wIeprcAD1ddTn4A0YRn0TPkJ9Cw6ivg3/QH0HPonthf3wKerf4HPUd2V9Dw6h/h3+GXsW 3ocvUD+Ar1A/hMOoB+Br1GHUZ+AjGEH9GGKoBxmg/oMx1E8YF3saPmU86mdMQP2caVAPMS3qP5ku 9hR8IeuXzIj6FTOhHkZ9Er5mZtQRloAaZVbUmKyA8yhY2gwGA/A8Hzf161SAP5ISX0SJNBhktFol 5g2KJRyDOxJBEARBEARBEMRxiNFo/H/zq/TxRZSI/CqCIAiCIAiCIH7sSB/p/j/xq0ZfaPEmxdIc i9oSBEEQBEEQBEEcf5jNZhCEeCdIr3LkrZPeEFck3q/Sj/lVetkF0x6L2hIEQRAEQRAEQRx/WCyW 7/KrxjL+nV+lHXWg9OoLLfKrCIIgCIIgCIL4kZGQkPAtfpVB5YhfZTTGF1GiMb/KMOpXWQwGJYMg CIIgCIIgCOJHgdVq/Ra/yqjyDb/KFFdE9at0oy+uDGqChvwqgiAIgiAIgiB+XNhsNtBo/q1fNeYd mcxxRVQ/a8yvGn2hpbEqVvz3shMEQRAEQRAEQfxAsdvt6FfFv1wa+/X3I36VJa6I6kbpQf38n2nU r7KZZJeL/CqCIAiCIAiCIH4kOByO7/Krxrwjc0J8ESU64lepCRq7mfwqgiAIgiAIgiB+TDidTtBq 450gs8oR78gS71epnws0jP6jlVn1q7QOs5wV/3tXBEEQBEEQBEEQP1BcLte3+FUWlW/4Vda4IvF+ lUVN0Dot5FcRBEEQBEEQBPFjwu12f5dfNeYdJdjiiyiRcfQfrcb8KpdFzor/vSuCIAiCIAiCIIgf KImJiehXxb9cSlA54ldZ7XFF4v2qBDVB506QPzJIfhVBEARBEARBED8SkpKSQKeL96usKt/hV6n/ b3XEr1ITdInWBCWDIAiCIAiCIAjiR0FycvJ3+VVjb51sjvgiSmQa/WJA66hflWSVs8ivIgiCIAiC IAjiR4LX6wW9Pv5De3aVI96RwxVfRInMo19gYbcpsd5jl7NMx6CyBEEQBEEQBEEQxyFpaWlgMMS/ XHKoHPGOnInxRZTIMvqPVg7V0TKkOuUs87GoLUEQBEEQBEEQxPGHz+dDvyr+5ZJL5Yh35E6OL6JE 1tEPBLqcSmwUXXKW5VjUliAIgiAIgiAI4vjD7/eD0RjvV7lVjvhViSlxReL9KreaYBQVK/53hAmC IAiCIAiCIH6gZGVlgckU/3IpWeXIW6eU1LgiSUpkH/1HqyT1g4KmQLKcFf87wgRBEARBEARBED9Q 8vPzwWyOf7nkVTniHaX64op4lMgJ6uf/POoLLUuuV86K/152giAIgiAIgiCIHyhFRUVgsdjiUtNU jnhHYiCuiPr+yo1B2cSrxAkFaXKW8xhUliAIgiAIgiAI4jiktLQUrP/yo78+FRj71Sp/dlwRUYmS Rj8QKKYrsbXYJ2e5j0VtCYIgCIIgCIIgjj8qKyvBZot/uZShAmO/WpWZF1fEr0QpoH7+L8OnxLby gJwV/73sBEEQBEEQBEEQP1Bqa2vBbo//0d8slSNvnXIK4opkKpFn9B+tsjKU2FGVJWfFfy87QRAE QRAEQRDED5SGhgZwuZLiUoMqR7yjwrK4Iur7q3RQP/+Xn6vErnBQzor//kCCIAiCIAiCIIgfKNOm TYPERE9carEKeEdTSmviihQpUQao76lChUqcNKVYzhKPRW0JgiAIgiAIgiCOP1paWiA5Of7lUoXK 6MsogKr6uCLq+6tsUL/QorxEiVNmVchZGceitgRBEARBEARBEMcfCxcuBK/XF5c6TmX02ykAxjfH FalWonwMMrVVSpzaNk5+tRX//YEEQRAEQRAEQRA/ULq7uyEtLf7lUlhl9NspABqmxxUZr0SFoH7+ r36cEqcvDk+Q4vxjUVuCIAiCIAiCIIjjEgY8LgBmEKAXpG/ys2GKHvxQDbXQCK2wADpgGayBtbA9 FsMSPijBnAY1pxtOUXJi73xLWCrv+1sJh1un1NaNq62prqqsKC8rLSkOFRUWBPPzcnOyszIDGX6f mJ6W6vWkJCclul1Oh91mTbCYTUaDXqfVCDzHoIBFkhvadqTogl6/399eqK57jl6P8Fm2T/wRcBxV yBu3UWrcelrcevrY+swIuCLNgYZGacc7oPndCDgjzBUB6SjMOQOPpG7U1L0q0LQyktLQ3dmJWzQG bL5I88GQWhV53ztMxoZAwzJjYQHsMJrQNKGFZXt3sOYJTDa45qbaHRzoLYUFEUcwwmU1ScuqSHhr JxqBRtwT5jiP5AzFdm/7ZhbgZqOWU7FYRNsQ0cnH9a2MhLsisNW3o2B3/7YhGyzpDJq7A91dC7Hl urCOO4DPauppldqxSVo6e3wRAXcuixdTfE09vv6A1BxNPZ2ogUbc6lvTMdnQ0LbFv9sbcWDcFLEH I5OxxOSz93v5/qbklT5ptb9/iy+yfU7bN3P9kra3tydjhfubArhD3FnTqkl4KsmhwgLlnNQG6O5c JR1zVZdUz6ZVvv6ty+S6bpPrIBdt6sGO6fq+Uv39Td2Bpu6u7knK3hsi4VY5gtaT2uQTxKZrbFeT 1AKYI8g5nY3tfqWxp81ta5AqFuhq9CrdPpbSqaZgQtNopk+qwVTcQcS31BeBuW0BLFotybJq6F9a LQ8efzvDrWYf2SqiybIFfP2fQ4R1BoYPHJ3SpaZos2yfg2Q2B5o7+/ubA77m/s7+rqHYpiUBny3Q v2PatP7epk486uw23Goodu9Wb6R5W3vE1tnDarHtpRHQPLet3uu3t4+uzh5dBRxSOLBM8ulgK+Df VDXCVobWNr8PG2peW7sX26lNslvRVmJpIOHArcY+VptNaqNl1WPN06Cafr80OrcOhWEJrkQ2zWlT 1n2wxDsA4VAQ+6NTytk9muOeJ+VsGs0Z27wzgEe5S56g3BF99tif1ZbobOqpjbDE78hepuRHnA1t vJdrVyzOy0uWMYhXel0kKYh2brAfO+HZQMQWjGjadnvr2n02O84AUu+1BKbNOanN19Q/NgqUFPVM pXGAQz3Q1dOvXkrSoP/21Gktow0ujVi8pLdii29asgoHDf51bZOmH3+/LdJ8yO/199sDDl9NqF0Z 1bZnA48znLhwWrNFWJ18Wkye0/BIUyN8UjVm/sdHOPqUcB6btCPALpqzI8wuajmpbZcNbycXtbYN cIxr6JzUviMT89p2+fDuIKdyY6nSmk9ag2nS1TPA6eUs764wwCY5V5AT5PWlQwzkNP1oGoOlQ5yS ZpPTkEKAHa2LJybhnQQ7mY2g2lDDuFyGCw/17HNYLC+H4FlchNhuFhwwWyp3oVEwkJWnGi6/Ygwa bJXhIZY74PHICbmDFouUkDXY3CzHA6JPzsga8KaqhjtRNax21TCaZSNjICdHNdLTFWPQaJR2kzFo NkuxfzApRYr5gaQkuQA/kCId+BHmHkgXVcPokg3nAG67K/YwSxxomacaM2epRlOTajQ0qEZenmIM ZmZLR0gcSEmRj5A4kJioGna7ahiU9kgZKClRjMGCAmmjlAHRr+akpauGWlHHIO4GizgGkpX9OgZm zlSNpsmqkZWtGuqRHKMtLw6YTKphGU1Ry4gDTqdqqBUV5WZkOYwNlIp4SO2AwyFncAO5Sv+xwZw8 qTLcINYOYzZay8yB5GTVsNoqH2AJTAN2ELFdNIMWuaeFQTyuFA8YjHJJYbShhIG68apxwgmKMXhi u1Q2NGAwyY2rHzB4ZMMwEG5QDXkjySgqVo2cfNXIyFQNz+hWLrdsuAYyM1UjO0cxBs3OSuvEBFaG Q7gMh28ZDmaR2YExG7NCOdrWAWG2KFULwqIpuTL2vih+8KFHLP6Qve/yiB8fsIkf4QKHwoc4vDmE kw+ZzJWHmEccPmASbQcvPciFD/QeeOgAj1P24Fc2VyXG4dovHa7K9971iO9WeMTwK1jh+pfY3hfr xRde9IibnmfPY9T5Yu+L3BOP54tPPF5T/QQz/bnxz1xkH8PNd+7Dq6f3OckMX/ic0VmZua1129pt F2z7zbbItke36cJ7WNUuu7gSl4dxeQiXB3F5AJf7cblvvl28d5dXvBvtnbs84j24DOGyC+tSV28X x+MyAZdGXBpwmVTvFifiEka7vsIulpa5xLIKl1hR7hLLMd5eIdfEX2HCnj6ttrbyjdNY+DSDs/LS 3kgv98YaFl6DZ/vsqXKpxFOlui+/bHlkOR9eYbBW3riMRbrlrHHd0qSwnfmujFzJ1f+CLb5046Wc 75Ldl3C+k8Mnc9DD5L/ZPZ09/MYuVrwgvGDjgk0LhOrr7KK0/afXmXH7x1h4kO3Anom43OKdLrt4 By6343KbyyT+wZUg3opLMN8u9uazgsIEsdBlEW/wNYiiK13Em67oc9WJd3kyxRs9y0Svp1Tc6LnU w3lcGeKfnFNEtyskOl0+sdgRdsx2XOYQeh2bHM86eIcrWbTjAi4229Xp6nXxxQkMtMzK8C/E6tka tpHdyR5iz7CPWYwZrYCDKwT16CpshDvhIXgGPoYYGI2GKtHKWXnuGe4ZPsbFeEFKMejzRUGTL3J8 tmi21GiEGp6rYVAzW8OGcG8RxzSY1jop4mQYt0zaYSgNTot0z5104SWXpEWukp4vNqW1D+mxDD6o RNjP2iN66Q4lm2NfvNe3Fv/61kb4poi2qacrog009kkrCdJKgrSS0BSxSivWQCOLuJp6Ii5MXRsM rl0nbb8uOLanI1aftPThfmWk9T4suE4S+Ea5f6Wvj2F+H8h7CMrC5K8HlBKCowse+7t28h8g1TUI oE3XujQHNXuFzcJS/h708iD2duy16Ppod7Sdv1b6jkI2n3WyVewMdt6Yc7iIrZCN37AudjI78ygH bjrcjZ38CrwD/xhLizEB5xjpx7f+xpxwrrz1X+B1eAM+g8NMw+zMwwLf65NeA3eo1gtsiNPJlhG2 cTfCn1gUc69B77MBa/MBt4G/kJfyN8O5OK+Vf++evwXewl3KFnJnwnZ2E9fAtXGvcbd+M5/pYTqe ++nsF/+6LUtkIl4KtayZzWVLWD/7mCtjE+F9+BRGsCWcTIR7YR/shwOMY3rmYiewi7kZ3GEWZau0 /Rq78MlRe1vJpuCZLGR9rIf1wCG0W+TWuAL1VPTQPaPfW4LHDcLD2FclzMwv4Qb46fzZ/CcaIz8A oNkLHq2N+4xbjhfhRrgcQzugtwCdcD78FJ7C9j/IvoY8uR2vxxInY3hDWCqcxf+JDcBymA/LMf4L nMQug6VwMZ7fDJbC/Te4YJD7G9wEL7OF/ES4nD+L4XMFTgVrsD5X4Fb7YBAuFfb+J31A/F8ivKJL 1R2A2+EiXG5l9wg7Nc/Dh3ALvAyr4THgJJdGB1oc+hilha1aTgBciiEMszEt1PHUa09BCKWk2G/3 27NQcN6HrzZp4LAUAxrAwS9RsnG0SXsJhdM4jue1uzV6n6HeMMvAY7KwgweNTePT8JpQR9lIaSjU AfXD9TWhkmLG+3mG++Wy86KP5rFt0TNYv2bv4X1C5lchvODwUXwPnse1WG8rNIeDmp1arZlP4IeY /mPM0+BV54MQ48Gc4GM+fjbPWe2iHStgt9kdNaGOjrLhmtKOUJl0wJHS+rLQMJ6KdC7+itLKqsrK KrSEa7/OZbXRPzZdlFdcIeAVXMYE3vkp3vXm1B0O4VGuxhq8pvkIfPCzcGLAUuudmnCCd7auNWF+ 8oK0lcLZXqNrKPY+PvRXWYdiN4ezE2xV4Ejw2hxp3pB3hfdMr87hMN2byIXQuRF3MX2n2Cty8k09 yWSrcvRizX16v+jgUlIyrBliBsdJT1O4Oy4U7LCXhRw1NcN4BriCrVbTUS+tlBQHgx1+f0WldBYV 5dmBDK1Oq9UF7JWZZT7B7ZLX/MJrh+/d+lrr6iUb1tQsKy+b4kirZ+YNzMDsGy476dZs7sxPT320 re+OhT1rUhOTis2sKb3+wAsXjPy8fWsanveK2FvCkOYgzrF3hr0Flsxg9vjSuoa6tnFzJy6rXjqp r9pYUI7nah6KvTCIcSk2QniWwVKlT8K6TxjvHepMZamp5dpZxay4OO/eci5sZEaj9V6tMRTG8qZm lIB/Xi2r9YaKXf5i7/hawQB4Q+IAmqxNYhNnMkgtYbRVGULBMqkpOhxJNcPYnaGOYbxfyi0hi9zZ IzU1UrNgwzD5/AMZ2Tn2ssTEslK1kXKyswMB+1Gr32i20sSkxESp5dyJkiUMzZk56/lf3fHlzMy5 ry2o3BjMyKstLt5cFh7XeHpubmG+mNmZUXV6Zf7CRHEG01x04Z6m6dMvX1+xrLhwHNuz+q76+oba TNZQPt3pS5naMGmyzS4wrdnhbKwtrLE5zB6XrczC6v3jiwpCP1+w8aHUBH12MOccPPXC2NfCR3g1 GcECZ4QrzRZLlVbnwkqatTqDZRerF2YJi4WNAsLreD6kq9ct0J2sO0enAZ3ZwmsFHxjkJ06HwVyF T2hWKz50WbRhe2KVVm3FYFnZsD0JWwxC9VLD4SVpr6nZoikKCufaHsWLMiBdIXa8LstQhY8ej149 chp3Plv3+MjT0S1sQfQmtpgl8p1fX8UORzU4UtbjSLkP61wEZ4VnGPUF1lKh1NUoNLo6EuYV6i2t 2NH6FBwUfn/arrw8bdauDF4eC3YcC4EsMSNsSqjKSPIHMuTu9+GUAcXWYrGYM6hXgkG5EjqkSyEU HA6Ndj3WHqcT+WJQ+zxb6fOkuG7PkDoZT8pdWal0tHDfrFkzX7z+lo9nZqQ211SsbqjdnJeeEQyU XVY+99oaH//KyJb0lqSTdzbPW8S+WPvHKZNnsqoM1mTLTXR707LTT5hQPi0pw+mx8o3R977g+GBh 1S5pLlyCLfFXzTBkQC2cE64zmxNS0sxiSr4pZC5IOcl0uu70cqOHLxiCNFsal5bGW53OpF3tVmbl qu+p5Jt5jjfOB+ZwZPtB6kOrwVoFUGetE+s4T6lfbg6TQ2qOkVK5J4flqa1juL4D20G+CrBNSoqx NcCPwz+bqyh3VCmD2x5Q2mG0Bdg3G8eldbvURhP+Gn0h+vV5T06ed1Lr4gUs+/Gpl3u9nvUz7nww cerVi2dfUjVjQXRmmpjp97eGcloyucIMT0NWejM7/GF077Sp85ntgUdZ8bo15zq10Vct/qHbQtXB vHG7oxdnzps/ZVFqqttlNRYFNl2X60tNl+b3dTi73o9jRwvd4QweXdMbON6F9xDg+F0antPzDLqB cW3SfIj3p6HYwUGcY+TWMRtM2Dp6q17Uc4I6UgRlpASD2BZBabxAff2IHZtEGt5bzn2UMb90vxHu H9kc7eR+NVIrTBZ+f/hEYUh6WOWhPva68LLmU8jCZ8hm2B5epgm5Q7kJoeoS3/iqSb4ZVa3C4oT2 qsV159jXpSUUF5WXhosaS9tTWosWV82f2Fm0qmpt0caqs8dZxlVZMkqLtNq8e1ak4FPTxHu0xpMy lsNK80rnclGT7RMLfE6rU8wQzBU++WQSsPIAU6xTxCncBJ9ZOh2bo8qMXax0NM58oeHQsHzn7JDW OuRuHp3osrMryiurKpRotIvV2YzJ9welg5MqK51yr+dopRTlIhFenjV9+quXXPX2lMmNl2w+v2fK lMa95/U/Nalxyjkbr9gW7e2eP3fZ+HDqjHBOpjhhedrq/JzxF5ySNi3Nl8Nu7PxtXV1j07hx29s3 3VqjDe/snXtZTeXEccUlW+es+kOttm4Plzt9wdy6uqliQnpy2eKRc6fOLEnId+T0NfVscLqSJkhX Dd7juSxhqfwEkRtOYXs4jXaPRm8z+Az41B/RAvoSPsYzeaqSWwDv40y+j+OjQ1b0BrZEWrhX2MWH r2cX46hqiL2jceM9uxBuDvsFozHfZfTmj08uSZ2RHE5tSzwx/SxhrWlDniXQg3OTfSh2gXQHw/vu zrABR5dwAkqa1CsFaCSFUUIWXw4nyxoLs1hcFWdrmZbrzGE5Ob6KdXhEoyVXmXWtVbm5IWsoHFoc 4j1ufnmR7TOlC+ukC1WatmTt6FBuVjh1aXxgt4Ff7jL5Mh27M41dlNKzSpldK6XxqdEd+Ji0lc1q /9nEsvVZ2d655eXnNs7ZMr568gl1tZdOPmFzUen01Iy8U2qaz05jV6J7voT91uWwljuj1yc3+HyF ZfU1j1yw9YHa6tKSdDGcEr3ZWWJ3J2I/XINew5N4LSZAGtSHg+2O+d7l3EqLoOUtZi6xQs8nVej0 epyt3GdKzwdiWJwtckkuXXe67dBwh+2zDmV4DitDk9NphQB2UKmQlOjQHH371Ty5c+va6MfXRIvY 09czx/rLb41uWrZy+u/W6nQ/uX3mwk7uvWej97RNC2r25s5YFH34+cv3jsvXf73QUFL7pPImUXgX 66mDknC6llXwPM4CBtHAaRboXNyCTVIRgz5s2GjglEeD/SP7O6SJoFR5kpXvbkPRKcK7uNzNUqP7 D0+T5qJbout5j9Yl7zdZ8yDHtA8yk9XAeCs6XCHptqS9jckTDd5alcm37JvD0Y0L7xnZxq2N3sea out11x34qg73uyW6njs8ul/hQR3j1f3eNrZjzTf2W4b7HT6y3wrpcdXPHR7Zhvu8D/e9/oDm0QPS dVOJd5vzcb+JEICGcCHOOmnTLdPTep2aQL7ZVsVL4gbvRHz20Psn6Y2uJOaBNVnpXlNvJvaYbWSk tFQ6DP6NPlBqlQmFs49NI/jQb89WJxDp9nB+9OaME/35c2t2vzm9YfwdXW2nTWOLojd7WtN/snHZ aUWL1qWGbS4Xm8CMl780e+q8rBz2+uEMLsdij9xwyxWZWOvy2NvCL4TNkI6z7IpwIMtSbpnIzRIm Wloy+7iz3XqPVO2sOpMJMiZohe3JLFlqGrw+pTicgpN+crI9DIaUFNFjPC3HmsOyTB6+N9t2CCcH vNjKlMcDPB/5AQHbcOwSQ3X7E//1mnIqFxz3WPSR6O2sjqWimy6MME11UeH6yePPKAlOTcoKTp5Q c1Ya39W9vE+bzopZCjq9U6IfREd+MnOlKHq9ic4Ce/QNe5rVaufeXLP27JXSiNqMsh97iIecnRxD j8bDlMk+AZ/NNEKxJqyZreHlQRocxhGquCdsf/Rmtgg3U/agyxTOgyAsCYe0Pm2O2+fOEXTORq8/ E8ya5HQhRZOsD3qgy59k8pi9SZ7krk3miPlZMy/dRMI2nLzM5sICW2GoMFzYWSgoB+v4bKTUNmyv +Uw6aj3eTqRro8NvH3sisB9tjz45jd1a7JpHtVZrfU3uzKLodh1a1cG5OVK15/9y8Yrr8pYNLpy5 IRgKcSUtp2dm+gO+r/dzJXP70Mz1fr1fWLph6twlXYuWlZZWXrl+JEs5T+FmPM9EqAlnci6nq9zY ZOx1a2wWfaNTSNAwi14avMmdycxm8lhOTVK6+xDWv66+Xnnq8X9rnd3CzdHtJqujsSbYVirX8NdL b9vJFTZu8WX7fQG1Ni8/DfLYfE24H8emCa+orLDbETYI6WHeaPbCaVn1WSzZq5WvHGmYjV6fyrCS lZV/+9Qt3B/dG/0wOhx9hpXgqHGx4uiv/GnizNLQdF96ZoY3tbUs/0SP6ONKsNTDrJ65WTIbH304 +vfuC3Pz/Wl5ORetWLExOyczMzN4FraVO/YBf4LmN+CFtrDbJI1Wvd4i1Bt1muRkVz0Ykk1Sz/vw icJkSqtPm5XGaY0Wj86qFbU+dM6Bt/F38ug74OwlueOKTyB5yKF6XC/DB+oOTUZ2hT1QUWZXprWx kylza7Vc+Qt7Nm9mi9ic6J2cNWFyY+oCR3rNpsTInznLZ2xi9KHPoqePawsE8pKN/7TacbIOqGHu 94TLmZU9wWVyv+cn8RcL6EAIq+ODRq9Z+D3hoqPCXRje/GbQjtPuOCo8p2vWXazbNxr05RQoUKBA gQIFChQoUKBAgQIFChQoUKBAgQIFChR+GEH+0OwE7iPpP6EFHjhIwKDYAkg/kiLZGkw3Qr5qC5CM OZKtxXQtTFJtAVxQLts6TNfDfNUWIBGmyLYe081wimoL4Pkf3r4HLqrkzrPe66ZpmtYwjDGOQxhi iEtYw7CGJa7hPM+4hDgOaAvEEMMgNv2Xbh7QMoxrCMNi0/9pul83LCGEI64xLmccYjziea5xOc8Y z7Cc4xLXeK4hLvFYh3UMIcZ17lv1XjcN42Rz+/ncTX9+9ftWvap6v/r9q6q2dUg1wyl4j560yphD n1syxjzcvIwVJJe7LmPMyc3IOIms4Z7KWEVW86tlnEwW4vOoMXaXjFNIBr9BxqmkmC+R8Qq+jw8w rKF6SCqQMfSQtJ7hVLSnJ+2SsZJkJUlr11I5kwQZQ7akWoZXoj0tKShjJclM6mA4jc0jyJjOI/V/ nuoz6aSMoc+kIYZXMXkuypjKc5rhD6N9VdJtGSvJuqQJhunvWlaqiIxp/4cMv0D7qzJkjP4qydYv UvuqtsgY9lXlM/xRZt9KGVP7Srp6ifWvlDHtL7XTXzpoVXYZw76qGoZzqX5ULhlDP6pDDH+KzTMo YzoP05U6Qf/qBP2rE9alTliXNqG/NqG/NsEu2phdysl+YiINxAaeRUpJHTGSJpQO1Jc+c5CD3Api J79c1m5Ab/2ytmI2g2Npq8Kl+K+KccVfo3yLfAe9NpJ8fDYBvUrM5ADe20CaQQaMzCKfA2oiAiv3 o8UMZCd5ePIfEDP14E1oM2J+B0ZlMambQU2khUmUt0wmM+tVB+5AK+2Xxdqb2JrpUwdrpWPpaulb 9ajR0U3EiraG+JhnPzX8X62ESmRnc1FpskgFamYmA33/HmYBB1sTfacdrS/LEjQkrOAAagfx1MG0 QXvnPVOGpbrYBlSPGSvZLM1xif4Yo/NJ4ZLen4r3fpVJJL37dbYuunZJayb2RCCbIeXLeEo/eRi/ XJI8JrENfRzkDaYTI9OKgBneIF9iq8li730D/CCzqKQjyX4GJqmD6YTWBfZ2G9NcTHe1bGxMr38K ze6Ez0hjmxKeCEwyPd5ygM0o2eN19q4DKJ/9XqlO+x6AVg4yL5A8pgGlnj0X8ERagWQ56V1meYYD 8lx1rKQevXzd9Hk9QzkY9UnmtzasK/amZ0llf9/Mv7+OFmfXs5mM8XiS/OpA3GufvfZFT14q12cT NEBXIq3Fwd4Xiwc6v7RWPVpeZytvYNH17JVKet6/RKd1clwsjw6qVeqVB9lIKm0LW01dfB7asx49 freFnp0lzc/IkjvRagJqQQt9fnDZ88+zNTczv3YwGZZnzl9CHiuZxwy/RN+lTyvZqKVtJSjr0dvw jGe75Pg6COtK9nvjd6xlmSzKl5RblJ9Vfk5ZqNyk3Kr8d8pXlH+ybHT5B+wJr1CZuD/Ck+Xt1KsE rG/Zu7jnyF3Fx4GXa7OBeeR+dvJi/70nkB99wF92ov9WDU4YhHvvvfi/ZEP4Sr4arZiB/wLh+B38 PqLgv8L7gP38XwD38/3AX+e/DjzADwB/g8cezH+TnwP+Z34B+DcKLeEUKxRpRKF4TvEC8FrFWuAX FcXAn1e8ArxTcQj4zxR/BnxY0Qb8NcXXCK9oVzwC/pXiCfC/KDdib/+08tNEoSxQHgDWK/XAdUoD sFFpA7YrDwK3KL8K3Kb0AvuUkFPZr4Scyq8r/xL4mPIY8LeV3wY+rrwC/GPlj4GvKu8A/4Py58DT ygfA7yjfBX6khAzKXyl/DbyQ9HPCJU0n4byY9Muk+8D/O+kR8K+SfgU8n4T1Jv0mGe9K/nryL4gi +V7yu4RPfpSyjXApn0vBySblCymngb+f8n3gMyk/AD6bcgn4v6f8L+A7Ke8Az6W8RzgN0eDsq1Fr 1MApmueA0zXpwM9rdgC/onkFeKfmS8BVmiqi0HxZIwA3ahrR3qTxAvs0J9D+V5q/QsuI5rvApzRY r+bHmreBb6TCpqk7UnVEkbonFfpM1acagI2pduCGVMyW2pjqBvak+tEeSA0Di6lR4N7UvwDuT/0m 8JB2P85Etdo6otAatN8AHtR+k/DaIe1Z4P+iHUf7f1uxBz6lJIR5Fk/+AL60Ax7yCv8KUfI7+Vdl 60s2TYI1LSitsCkPa74OfAg2TVJGYM0k5TeVQyQJGsa6kv9T8imiTH4r+S3g7yX/Z+CzyedQ/nXy j1D+JHkS5f9MnsLTnyb/FPhm8k3gv0/+GfDtZFg8+R+S7xIlrFMs2yKmqx9r/gfwNc3fEqVmUjPJ 9OAlylRfqo+tFxrT6rV6otTWYe2c9pz2hygvai+i5W+0fwM8jrUr2Yo1xMcZSNL+pv21JOvAG031 pMhUV9tEdtTvd9hJpcO0n+YQDeEqdNuzcDYmiEIe41QMcSSZ6U5q5Yg6XuPYbYrTlb26OEqBW4mE lESTMC4JNxStbX+TlexgpY6Ve1l5mJVBVh61WW1WcoKVo6w8y8qLrLzCyklmRcmaHGamf+/oeUjw YdzPPoI73Qu4j72Im91HSSZ5CbnoY+z/aEnlTsKa1JBQA2lWfEAbR/9WNebnWd5a5CvJh57JnyPp 5A/JXlKD7Cfg7tdOXCRI+sgQOU5OkTFygVwmE2SK3CEzZI4scDjyc2ncGi6Ly+OKuB3cXq6GM3EC 5+ROcKPcWe4id4Wb5G5yd7n7zH4c10/o39PiUs9BUvCVqyT+oaeST6cNSvwT2TKfl/gflEs8Z6PE C7dJ/DO5Et+0UuL/XiS4JBNuayZR0X9DpXQ1UeEBt6tJeq7bgLsc+BeziQpq5/ZekeTa+xR6A69q kupVgzI/L/Evb5D4V9ayfsrX1r+2+bXS12rl2sRr068t1GilWs3lmls1c/uVUg2e6tzfv/+kNL7W IvEDlRLX57Ne6jpNXWZdQd2Oupq6ljpf3TBr/ZDBZRgwnDKMG6YMs0ZiXGXMMRYZdxn1xlajzzgk SWyqpyV4SJrR1C9xs0PilrsSr18j9bM5ZR5gEcDZEKcp21Oi7FuAm/T/p9pwDDRCOOEq+ChojHBN GkK+ehH4PGgcdIUQG57b4L+2KdQnQDdAt0B3QTOgByBkfCEf/DFh/5ibgDgUsB8KTaBWmdpAnehX CO4BBUFRwjWI4NgJG5+CD4OOg06CToOQEZtgUeEC6BIh7fdAs6CHhHvTAr4Aesqvteka7A2HbKsb 2m3Vtgxbjm2dLc+2E1gH3GILsHqLzcKwaOu3DdmONWrRts5eyNrxvGHQ7qFkG0F9RNDYm+zZlFDP YzSKdkrnZSqw5dm32bbah+019mGbxX7SXiMowc/axinZ9tr0tiu2CdsNjC2wbUW92t6JcXvtNcCW RXnsxDYkaCB3sT1qK46129vQ/0JCP3l8gpw5kHPd0rotJ7He4LPl2JtsxUIe5j0vzW+/gHUlUEPI NsGozzbG6APqkCWHUrzexObOgVy/kxp8kIeS05YjzGBM1O6hJDxAXW/Lkexgy2tMt1ULAtossAns EqvDhnmMYvqX7MH0yfQ4IoyBzqNPMaUGB7P11pj+hCto75B1e1i4gbZxSjH7gVvs2/DOBDvYNoNQ t6fjWbqke2pz+xrMk0l1Cb8A2XMxRz7mcNnu2m5hDsFeZNfa7jLaZi+xPbCX2grsJfZycKzJXgVf MWCeevB66gvwkb3wEdknoM9xRjEfiskY84EZyDGa6DuSLy/6jJBmvyCstrdirlbZZ84yzOpMJ51L fM9jG7IHYzaxD8A+A4s+RP2H0aJPFdtG7IWLdYH6nMU+QMe+f7wUS3Rdgk7IAxWANgu6uC/G2rfC R4tBy3gsBpf77AeS3P/39Wmh+n0+/pjScp+P+bLQIvvuI+DHcp6huaNd6LDpBFcjEQ7b1gmHG9OF gCAIYsLzfjwXG1Xwc/h74xopTzVqZV+XOfzXIowIx5bnnMZtGEMpE5hSCTClbGAQ5h5iNApfoiTH TKx/rN6wHflj+2K9MRPvzmTvjfWfoBSv52J87mLMNZbaqkGL9XLUy5/5fKsUo1g3qMEhDCFWEJOI qQuCRhiHLA7b1gZHYxV7FvPbdPg7+i31P7TLMRuP3fOLROME/sIo1oZ9gFG8nxxHwi0pFzM5OoWM eD/kAOEuy+mMPjAHNsE/KC3msMfIYY8RB6MxX47pzj7ZsI/6ubBT2Bv346i9SJigOd6uYhTLOTQW aUxesZP2toT6Ynyzensb6uJinY0Xl/dv70zoX422+J7RMEhj8/3x2T7cfrz9ZPtpyFgk5LWfXb43 0DihtCx3F9N4aC8EFSEWMqT4SKzb1rVfAF2C/2tsuvari3XqY+2T7bdteYymIQOlWH2YyrRYj/l1 w6AwBjrfPmcrZjTf/sQ28iaPuY5TanC8qaa5v71N0subK2GHVtQ9tur2IMuBbG9oj0IvV96/l9g7 se4EWr5+nJ5WsFs6YXdyNbuNp7D78Ep2E/4Q7sDvkHTlPG6/z7N774dx450ja5Pexb03i9141+EO uZt8gt0G6bfwa/h3cPsnCpVChVv7KsUq3OlXKz6CE+4LuP2rFBmKDJKsyFTgDKn4tKKQvKh4E7f8 lxT/ovgXEla8p3iPiLiXHycR3Mhvkyi7f38HN+92ciKpI6mD+3RSZ9LPuYKk36iUnKhSqdTcUMpo yve4b9GbLveXuMtWcsdS96Z+iTuBu+kKDmdCbpbfsnhSbMTtonE1TmI4uTVmgNYRrg6nr+ZB4BxQ HqiAkAM4vTVuBm0FFRNiwUmycSdIB9oLqgbppbGNlHBUbGwhxLwG/LDMO0AuUEDuh9OhwQDeL9d3 Qo4i8CEQTrCNIyCcXg0D8vMxEE6vLTgptuD9LbOEex3ytDwELeC+tYH968KluP3Usm+y2omHiGQQ N59Rco5cwr3nJpklTzk1UTSSxvpGVWNTo7axlfDCucbNwkWsjRdGG/OFscZCoOON64XTjRuABhsz hFPQDI8sny6MNGYCeRrVwnDjWqB24anQ16gEahEeYW94TJ8K94VOYY49vSMcEu4B4XyCfeMWUJNw VTAIk0B24aKwT7gMZBHGkGPOA+ULl4QSnJB5YT2ebhFOEKWgFybQg43HW3AfSKwdOCXMEL5hAThN OEz4g2NCvaDC+fz/hUcnsW+jCPseikueTX6XpLDvR55j33Q8D/9K5zrYnzWexT2UCCWgUlA5qAr2 2w5eA4LdhXrpFmG/Kd0iDsCvTIfitwlih+T2a4s3CjtuBwcOs5sFvVU860ZBGlaD4Kf69MWbBb0F QdtEwC1HuA2aJsThBNWCfCD4usNB/lAoErZB89uEAaFUKAePfaqEGvYx4FMD3TYJrShb8WkCrwFv Y7wGNu9kZU3zfPMTB+9QO+ifVabDCvBR/hH/K8Lzv4ZFlMwiKmaRZGYRLbPICmaRNFhknjzHLJIO izwgH0mag11eZHbJSPp10q9JJuxSSl5K3QXrZMM6A2R96iBs9Mn/7+/jyFbiYBbPw32W7IdFDiBq DyBa96+R6MB5iTc9IOr97QeG9x86cJx9TjbTb1rV/Lv8u5B3np8nnPLX8EY+6Z2kd4gCHjhPlEkL 8MOk1LLUMqJK/UbqN0jyv2kMlz7z/GaiIFruPLIDaS4ifATe1rwNBC9thpc2w0ub4aXN8NBmg1yn RPs30T9MB2+VqU3uA6o+GycukI5522VyMiLNnYjmS/E6w9AFH/EtbadUIyztR4m2xYjOG2uX+5Nm jyxnUJKNytIclZ9VLXmH9GyA9YvNQ5oRSc2wW/NJmU7/G4jOe4HpY3H9EpHmxTWQxtk4SfJRHV6V aWoJ8ZEQ+G3wPv7WkRs+Q3i2ts1XH3545JavKbxQ6/G1hp8euetrc5AjM75OUVk77fOIGrQH0f7A FxXTjjxCufrIY99A+KGToE+GU+UbFtdhhoGDq1C2hhcwtl5UUizmAB/HPG0o85xa30mxwJmOOTfj 7cHwrHON77S4FU/PNltoKRY7M33Hm0ec2b4L4k5nru+SuNmZ77sq6pyFvklxr7PINyVWO7f5bjtK nCW+aVHvLPXdFy3Oct+cKDirfPNiC1qexFtq/HzzuNPgV6OlyL8SY+tRHnaW+FdhbJN/Lfq0+rPE Dmebf73oQs8NYsDZiVJ0evwbD25yBvc/xhpba7VivzO6/9GhcueAfxMkZyXWWC8OOYf9WxzEedy/ /eAq50n/jvCC87R/FySf8x/FKub8J1hJ8bz/FCspfuIzoKSrG+3i/WfEapRHWUmx2n8O5Ur/RXEM 5WWUq4CFrrX+ayiz/NdFC3reZP0XS2mUmuH1/jtiYEmZ5b+HcgPGnnee9VeKx6jVxBFoaVYch34e ildcQnd5pNN5wb8Pa7zkr0V53G8KL3TtCKSJN7p2BVaLt2oW/Atif1dlIKPZgp529Lnqd8Cy0qhJ /yFoe9iPLcA55W8X0+Tytt8Zx9N+H7SUWN73h6CxhLJrX2AdrEMCOWJGV20gT7zbZfJveUPosgcK xJkuh39L80jXIf/RQ+W1Hn9f+GnXRqxdV9vqH2y2dG3yP4WEWwJK4O0BjTjR1R7YLD7ockIPeuft wFYxjfnkI2b9fud0oBhr9EH/uq5QoFh83NXnPxohXYO+1oiq62hgZ3i26wRatDRqIunUPyNruk4F ih0GZ2FAJ+6t9QT2SrETyaReGsnuOgOdWLrO+c9EcrsuBqqxissBPV0Ri5rygCW2OmABeDrQcnAV LHUTo64FWgx813X/TeiQ6Qf2vQ6b3vRvEZVddwKHRQEr3YLV3Qt0SFjM69oUcMGTEWWRfOrPkcKu 2UAAdmkLiPDt+4F+aPUh9QRZwwwnarJrITAE/FQvRIpcysCxZsGZGRgR9S5NYDSyzTkQGAvPutKo ZhI15jwZOA+8MTAu6lyrA1ccBB5IffhMYAJr8QGj3X/IQVwZgRtob8fbNa511BaunMAt4LzAXVFP s02kRG4vCMzApmcCD0TLkVuBR4is0sBj0eLa3E3EtK613Spo7Ha3Fr5U3p0OPNW9Bu2rKKaZKlKI 9sxIqWtrd3ak3FXcnRupolkrUoP8cDxicO3szoeXQv+Reqkni4UhmisihkTsPNldiNUhpiJNzumv lgNTGwWQ2Z5EWmkOiZTGPdMlzshZjuncpYPXbUbcUZ2fxkpj+H53ETCLSpoPI2008zhqXHu7t4lb XdXdJQc3ufT+QbFY8mSXpbtUFJY8TcDuJz2CuNXD97Qc3JTo/0dudVeFF1wt3TViwPWg+z4iy9A9 Jwbg+QZ4Pnw4GnLpew6LxR41clRH7TC818C8N1+KX89KmpE8q3o6mE2RVaDnbDHNs9Z1jOq5xxXT M8v2QzTHYux0TyC8gLG0f3x1mJl5nYdpgGX7R1JelWSGDJDZs75HbLYgwwDHPDmUHimUdhZnK/J/ B42y6BlJThqP0T5pLZ4NgTFkJLZr0H0N8wNH2ih2ZLuBHfWejT394afYTdpozPpao4MUR496NgGf oDhyO7HdhfdGnni2AJ+S9ZMPGUYTZfBs7xkSlZ4dPcccJZ5dgVvRlZ5K/x20b+wZCT/17OsZFS10 D8WcpT1jEUOsPTAmt5+j7Y6axD6JPoyM1BJ+iHyyBbGQ4MMUO4YpxthOZJIJT213ZvSixwR5Jjz2 nvORUtoevUzniV6rHYa3G6Q5PY6ecXGd51DPleZxT3vPBLCz5wb2Suzm0evOmp5bUbvH13P34CpP CHnVsjw6ojcpdtQktiM72aGHPtj9sGc7Vqf0DGIscM8M8NGeB5Eieh6I3qFRE71HcfW4s6nnUXTW swF98jwneh6zDHYc2jvlz4rukjKb50yIwD8TMO2PPugfKfScC6nEAs/FkBZZLsFnGM6mOPpwSXui T74f52P3H3VeCq0Jz3ouw1dF+JgHPoZTQeS+HGvXQpk4G+D0El2g54ToU/gedkPP9VC2mPEMfILt mFKmtSN/FtFzDnYinCiiWyh21DO8UfIErCVXdHluhvIPbvLcCRUiLu6FisSdntnQNuSBwzjP6Fwd 3YaIx+XynTRkuQLd9ZEml9jdhLPTtu5WscPV390WIa6h7k5kgGPdHvQf6Q4a1K7RQH8k6BrztSJL XO+Oiudrr3YPRPLRf7j5fNeWbpzT6Pkt0uo6330SmXkc9j2MU8HpSNR1hZ6pjjzoPousm+sbMKyX zlquK90XINVE9yWkvBvdVyMD1Csiw3EPQeS6bnVPQqq73VPiasxmwGwz3bfFCbRPR47TPTGS63kY KulVIrLqkW1qu+cjJ51t3U8ip2G7VrGgOtB9KXKWYkT9rSCPOR8F1ZELrsfBlZFLrkBwVeSqfHqU zmmShlnp6g+VRojnVKi8V+MuDw5Gz3gWQlW9aZ6noZre1V5lyNCb4dWE6nvXedNCTb053tW+4715 3oxQa2+Bd12orXezN6f7au9W54VQZ3jWm+c/2lvsnAp5xDRvQSgojkkZz7sZe0SulOW8W5EBmtxN oag44y0ODfTuhM8MIz+zE7V0dvXu9Id6dThX3Ondi/2uBfsd85DEXIoY7BeHvDrMnE+fivoue+h4 9J53b+hkb7W3OnS6N82rD53t1XstoQu9GdLeSt+O/dQTuhRRHbkb3IhMxU4XyL04XUjnNK/AzqUX QldjZ5vEnO8cDk0CZwEHvC3d2YZN3gLsrWPew6Gpgxu8Hf6LvZYleX46dDuG5VOKPXA4UuR1haZ7 BW8gcPjghsT8L+2AXhFY574fut/b4u0PzTnKIecM9vrh0DxOPulBde9h1zjkX+8aDz2JrqfW7O2g 9u11eYfCPFZxLKxGXEBL0L+Onn49G8IrWcTRHSQYXBvJdZNgVoTUng2uF8+7xtAnz60KbohMurU4 xU05C4MbI7dR8uJedzryebl7TXCT2OHODG6JTLm1we0oM4M70DMfZwadOzu4KzLtzg1WwruYHTH/ PpyIOoO1kftOQ9CE1Rm685FPSoN2aBslzbpBhyi48wPrInPuwuChyLy7KNiOclvQCV+lOfm0uyTo izxxlwZDUd5ZE+yLqiHzYCRTKuG3R6ET6RZTEzzRPO6uCp6KrnTXBM9ESpzZwXOOErcheBFlffBc 85CbnUyk0tkUvIy3twavGTa524LXESMlwZsH10qnX3cuPeO5O4N3oqsww73oWqxOjRZPcDaa5Q4G H+JWJd2M6oMLsAK9KVRjvU9F0R3tUUY3uAdwohDd9f6H0bVyHqPlJjm/sdI93KOJbncP9KQZstzH e1Y7gs7Wngx6SmE7e35PRnQHtLdeDLhP9qyLEHd5T46DYFRedBfaBx012CkKcC4N9Gx25C6Z7XTP 1mil+2xPcXQfw7XuC8ETUZP7Us/OqN19tUcXdbgne/ZGD7mnuuei7e7btSqcmqZ7qqNO9/0efXOH ryp8sa+J3jj6tvkyg7vEFtdYeJX4yHUl+DBS6h3Beh95R7tVvQH3XI8l6nPP09I7Fl7bK3rPh7N6 +73j4fW9Q94r4Q29x7wT4Y29I9I533sjvKl3lOrZMcD8dsx7K7yl97x8ty0Mb8etVrrPJt5VpVsq u59674Z3LLulsvzmnQnv6h33PghX9l7xPgrv653wPg7X9t7wkbCp95ZPFbZjFJvHpw07Ik2+9PCh 3rv0vb0zeG977wP63t5H8Xv0k97H9NbcR6gkfSoqCVrikqAdMvRpJW+hu2FfOr0d962h8vRl0jNY X7Z0s6Y2aj1HT0d9uTSO+vJpHPXly/d36S1Nvqt9hfJs8K7ex741YWdfkfSNhPQtAT2pNlvoWauv xJcbDiHzs+8fpJu+Lz/c11fqKwwP9pVL3zNIGpO/SWBnS195+FxffezOxb4TYFj+jgKjIq2+ovDR aMi3LXyir8pXEj7VV+MrDZ/pM/iywz6Hin3ru4N/lRD2KzJl8teT3yJJ7PdgGez3YB9jvwfLTv5J 8l3yMvut1+fYb70+r/mxZpKUp3pSfWQf+w3ba9pz2nFyADNuItns/3u+nXyFrCW15E1SQNz4lJMg 6SEVZIj8R/JFcgyfL5ERcopUkR+Qs+Q1com8TfaTO+QXpJH8I5klr5N58h75KsdzuaSL28RtJqe4 7dyfk+9xXi5E3uWL+S+Q3/Jf4WvIe/xB/hCn4I/wLi5FsVNRxq1Q6BVG7jmFQ/EG92Hlp5R53IvK Hyovch9VvaBay72kylB9nPuYar3qZe6TqgLVZ7hPqzarvsB9RrVTZeQ+rxJUr3MHVIdUYc6q6lO9 xR1JnlfncN9Ub1B/iptUv6x+mbuuLlBv595Wv6p+lbun1ql93D+qe9Qhfp06oo7y2eoB9Vl+vfqc eoH/U/qnK3yH5pTmLf7PNac1P+CPpH4t1cV7tSu1RXxEO6Qd4ce1l7SX+L/VXtZe4ye1b2vf5n+q ndJO8Te109pp/u8JB91Z2LemmfR3TWWdIA8oCIqStWVVZZ6yYFm0bKBsuOw40Mmy02VnUbtQdqns atlk2VTZ7bLpsvtlc2gxlNWXzZc9ob8NY78fJMkDyQOET/5W8rcI/btH6dxN7iYh3D3uHuG4GW6G 8Nw/cf9EFNwc989Eyc1z80TF/Zb7LUnmFbyCqPkkXk1S+BX8CvhSGv8cWcnTv/+Txr/Iv0ie4z/O f5yk85/gc8jzfAFfQD4CO/yQrKGaIy9gTVPkNltZOv1NXPlFUlsxVJlZmV2ZW5lfWVhZVLmtsgSf 0sryyirgmkpDZX1lU2VrZVtlZ6WnMlgZrRyoHC4/U3GsYqRitPxixVjF+Yrx8ssVVyomKm5U3Kq4 i7aZigcVjyoeV5Lya5WqSm1levn1yjUVeyuqK6oxsrpCX2GpEMovomdLRQfoMOqWCldFACRKn/Kb 5XfK71X0l89W9FdklD8sXyh/WqGs0FSkVayuWFehq8ipyKsoqNhcsbWiuGIn/aVVyjvQ5uolsUB/ 6V1ABHj2ZvIG4mIbi4VXEAOnyKuIgh+QUsTA26SM3MdnF9PRbvjSINGph9RDpEJ9VH2UVKqPqb9N vqj+jvo75Evq76q/S6rU31N/j3xZ/X3198k+9QX1D8lX1NfVb5PX1H+n/jvEFEcGEG1Uy+vobw53 3yBElwnKBuWC8knR7rO6E7pTujO6c7qLusu6a7rrupu6O7qjunu6Wd1D3YLu6R7lHs2etD2r92Ts WbcnZ0/engLdRl2WbtPuSd0W3XbdDt0uXaVun65295TOpLPrHLpDuvbdt3dP776vc+p8upCuTze4 e063Qbdex+++tPvqns2753dTP+SSryRfY79H1CzR1hv4FJCf4PPH5Of4FCIz/IJ8hszgs0n9I/WP yJ+or6mvkc3qn6l/Rj5LOO3cChX708pckkyI3gISCGeaBG8BHQaeIlzJOcUf6fWmC3qL6ZJeMF3V t5gm9YdNU/oO0229yzStD5ju60XTnL7fNK8fMj3RHzPz+hGzWj9qXqkfM6/SnzevZXzcnKW/Yl6v nzBv0N8wb9TfMm/S3zVvYXPPmLfrH5h36B+Zd+kfmyvriHlfncpcW6c1m+rSzXaG15gddZnmQ3XZ 5va6XLOT4Xyzj7UXmkOsD6Uic1/dNvNgXYn5KHtWaj5RV24+VVdlPlNXYz5XZzBfrKs3XaDE1oO1 1DWZV9a1mlfVtUEuKsMziMlE5UkkKkMixWRZTrQ9kYbN1+s6zZepXuqOm2/SPoZKS3FMLibLWfNs 3QXzQyoz1Q9r90DWGKcUNM0tITouRlhLnKhsl8wLdVfNT+smzeuZfqbMO5guouZrdSfNd+oG8A6q n9Pme0yPt03TlFPb1k3vm6djqL6YHu7LfM6iZPajOpJ53bxpsu6JRUPnZbqlevJI3MCbeSoL9RGD 2pLG+ErLaqZ/qpcYp/JTnawyZ1F7xnhMdupD1L6GteYNhixLBlsjHRfjsbXJ3LDess6wwZJj2GjJ i8t5f+lalssa57Ie4vpwSdywyXTfsMXsMGy3FBh2WDYzPdG1yZzZI6FO44P6Lo0R5r8gun72bFRa d5yPSeuP8/Fnrz+2XhpPieuP1Wl8Md+XbWvYZdlqHJHalvN4n32WnYZai85w1CIaTlj64/qq/9e5 cfT3e76k33J9/x7cOJZQX65nWWcxH/pd3Hh+sW4cl9b9QTyml+W6Nl6R9PSvcRbDNL4GlvKYLZnc WE/MD2N6N04g7yInsvybwOP+S+ON+mXL7+bL9Rh/zzK/N94w3TbeQs69vejnzJcCEo/5fawe5wl+ b7xrPmScMT0xPoCPy/4e57LP01xA+8VjQObGR2Y1zesxTvcSlueblsXIMv5Bdo3b97F5LV1PjMdy Siy2ltfjsXZFzpeom8hSTttpDmL2m/gAfmNZTC7zH8qpPk0q8ya6V9F9kfJYXMZjmOZ9uofFeMyP 5BxH989EzuamOYKOpX4GXzJpLVup7xhMlr0xPzLYLdXMr+heGMvvyN0Gh0VP+zDfoTkIfmI4ZLHE 933IaWi3CLHYi+c16gM0jzgtLdQ2Bp/lMPVtQ8jSYeizuAyDlgDzS/k8wHR4yjLE9r9l+jOcsRyj +jKcs4wYLlpGY2ujfeN003LFcNkyRuc0pVsHTGusw6ZM63FTtvWkKdd6murBlG89ayq0XjAVWS/F 846cN+J+ErMHYsC0zXyZ7suxXB+LhbhPL8sxphLITnWO/G4qXZQhNs5Ubr1qqrJOxve35blxeY4L Lt1Dlvvy+/bFZfufqcY6xfQkx6rJYL1tqrdOU4r7R+zdsblj+Yi2yWep+Fksdh6Tz2SGa5bzhuuW cab7O5YJwz3Ljfg5jcbWrOUWO3fRc07iuUc+JxkeWu4aFiwzhqeWB8x/qN/RGI+d52heVVoesbjV WB4b06zEuNqqYmtdRsYMq5YS3YMpMX+ivgR5jOus6cYc6xoWB/J50JhnzTQWWLNj50LjZmuucas1 n+rEWGwtZLqhFFu3TNTmxp3WIrpWuj4qn1Fn3UZ93rjXWsLWLvc1VltLjXprudFirTIK1hpji9Vg PGytN3ZYm4wua6sxYG0zitZOY7/VYzpZvz52rjU1We+bWq1zpjbrvKnT+sQ4ZA0aj1mjJk89T4nt CXKMsnM2jRWamyCvKVivZvaiclBbxHQpn4mpjuLnBro+6pfR+pXMfwfqV1GbMDmon0M/VE9L5qN8 +bk74bzNdE51SnMTzUMJfsR8RvaX+LkZa2Bj6Dy0P81HsXtBbG+Sz0xUZ7GcwXK0vJeajtdnJe4f 7K5B8wp9N9ZpGq5fS3MOfRe9wSf/PPn/sPf9cVFeV973eeaZZ4aBAKLCSJCAIsIUiCFgUH5ksNRS wwzzix8xhCaGWpZY11o/NGuNcS1lLauWWDTWWOtSa4ix1lprfC1NDbWG+rLUWJtQ11pribEstZQS X9fqsOd8n2dg+JE1Tfv2r+V+znnOnOc855577rn3nnuBZ94RwvJz/r/E0C2hWwTvf9L/zucvm8Sw ocTwWekjOG1x47SlAqctj+K05TE1Tv2u9DjOUP5kTjPfLyfz6Yls4/2tnMunJ3IeTk8+j9OTf8Lp yRdwerILpydv4/SkB6cnF3B6chmnJ318emKYwacnhmQ+PTHM5dMTQwafnhju59MTwzza9+4TB0bP GOz7RLG9237Bftl+1d5vH7TftPsLFSqWwsjC6MI4+87CWYUphRmFWYUL7fsK7YWL7Z2FJYUe+/nC ysLqwprCusJVhfWF6wo3Fm4q3FrYUrirsNJ+gO7tLdxfeLDwiP1w4fHC1wpPFZ4pPGs/gHKYyjGU dpQOog4AmCbg8wLTEeq70HE74LXUd8+K52jve4jKAuyGF4o3xTna756nki99XnpGFPCZl7DzmRc9 KYlKUR3U3kExi1o6mLfafrOgnttq99sHubX5sdxeanUktZjamx9ecK1wYUFcYUpBfaE9Pzw/nFpP 7c/ryevJD4eNPyQbY8jGJLIxmYokUqjItOPmN9OkCf6/uQxxvzCKB0Qm7cKzRY4IIZuKxD1iMZVw UUwlQiyhEilKqEwRTlFKlrqFR0yj6KwU0fgf9VhRT+VesZ5KnNhAZaboohJPbf+5uE8Kl8JFopDU enXdaFsdmYYHHJm5/fYwR07+DUcBXYvsOxxLCPc5XI5yR5VjmaOWYGVehmNNbr9j7cO3imtyGx0b HCvtSY5Gx2bHNsdOx578Xsc+wg0FLscBx2HHMUd7foOjo2Cto7O4xtHtOO+44LjsyKRylWohrfYu 0jBaBkkPSn6vVqAlUG5qJb/L0U/2+J2K8wp0VTmjnXGOC1RDJmklyL9h36EVkqviWrjk99r7SONK RwfZfdmR4zhMT1xwWpyR9jDnLPsOZ4ozwx5mT2KgFmUSN8u5sLje0Vhc77Q7F5PuzaShgbVAUzlZ x1BFti1zljiW5TfkNuZlOD3OyrwMavMaRycD18bgrHbW5NkdmXkpgVrybzjrAkC1rWI7nPXOVY4i xx5HkXMd2bTRvoNqI3Bucm51tjj2OXc59zr2OPc7DzqPOI87X3OeQv0EzjPOs9w6suCtQN0MzovO i461jm5uLfUGUQFgDp5mSbLrL4Hc9tJi9shkQPecbHOpr3Rp6RPOWQELg2EyPvP4nDXYeobS1bmH S58pXW8/WtrAJ7bFNaU7PCfze+xhrpu53Z7TsKc/t1E/x8UpbnF90CnuOe0cN/9G6QCf4bpkl5kg HNdprtiPb3AlsM9dya40XDNdOXn2vDhXgauI25HfZ7e6lrhcBOWuKtcyVy3BStca11rXmrwU1wZX I8Fm1zbXzuL9rj2ufYADrsP5N4prXMdc7a5jfC2uye9ydRB0EnS7zrsuuC67rrr6CQZdN11+t+Ia zMtg2m0p7cvLcEe6o0ubS/tKm91x7lnuFHeGO8u90G13L2Z/2LvcJbn9pU1uj7syd4+72l3jrstt tDsZiLuKI85tcdcTrHOlka5q90ZXI8f/I4tzG6mQv5zXOAqL64vrSbrRed1utSc5hygKb5UKjjr2 BfWiWhrmKC+NclSVWkvjaT5Y6azTRlFpUqnN0VE6r3Q+jcFrpXnOSq61dJEzxdPFdnjOeXo8lzy9 nj7PgOeG57ZX9pppvG5gn3J/06h0esPzFnun0Xyzk4Fr9MZ6EwDJ3jTHPk0D3/NmenMw3kgDQ243 RRpBYISMRBKNQwbWjhoKHhqA3iJ7F409n3cJNFRp4588T8W9yb3V3ULAuGWE2uXe697vancfdB/J X+8+7n6N5yT7Dvcp9xn3Wfdb7ovuK+5rJHnd1Z572D3kvuUR/LRH9YR5ojxWouLzMjxJHptnnme+ O7K0gXRtcre42j157uOEF3mKPc7SBo/Ps9TzhGd5/g3PCjy/2vOMZz1dtTtNnmbPDs9uT6unTZsV PYc8h3x1PNd6Xd5yb5Wjw3PUc8K7zFvryPSu9K6hPurwrvVu8DZSPzU6tmE2PpbfwHOxM9JxOb/L u9m7zbvTvsO7x3HMu897wHvYe8zbTvwOb6e323ueuBe8l71Xvf3eQe9Nr9+nULH4In3Rjs2+ON8s X4ovw5dF68Aanm99i2ml2Ocr8XnY7+zV3EFtpnQs8y10bPBV+qp9NT47VsLX/jfTmiTT4vcI8Ak8 vyVM5FwS0oIEMS2ne0FkzoUFcVmtWb7s7uwLOZcXzHrw+oKUnKsLMrLUB69nd2ZfzelfkEW8hTmD C+w5NxcsBs+/oCRr9/wzWTuyWhcoCzz8BesLLAsq+e0NpuOm/4N3M3xMfJx64BPiEco/HJRFqMJL fg6lHnmc/8OELLsOi/CbM998IVUcpWseXU8YHvDNK1vjm0+QR7CIoJjASeAjWErwBMFyghUEqwme IVhP0EDQpF+bCXYQ7CZoJWgjOETAuo8SnCA4SXCaoIvgHEEPwSWd7iXoIxgguKHTtzV+mazLEJSZ CcIJpun3YgkSCJIJ0ggy9Trn6e0pDrK1VbdhMujS7QmGvnGg2zIeYHsQlBUR5Gh1li3R5dqD7GJ+ FcEyzWb4Z55ua+BarPs9GBqCoDUIyLayWoKVWh+wf9jf7IuyAgKXVgf8U6770qdfSS9KuO6vrtFr 2VrdnpNBV4qPsg2aXtjYE3RdrfuJrmWN+nWz7v/eoGuD7rdmrT9HrgHbd+v9y9dteht7g65620ba uJNgD8G+IDvHtWWCrYFrwA/jr0v1vjxAcFj3f9//cOXxwbHLY+SGDgF/vF/7x/thfPvHt3v89ZAW +yN9eyyIN/4akOkg6CxbU24hiJykf//W1/fz+we9jvfzeN99wGug3Xe7jvdxwE93uwb8O+Ea6MuG ce0K+Ifn3dOTXANxy/PxuQ9w/aD+5Hmd51xf2Zg4v+t1fD8E4nz8NWgOmPTKa8ftSa7jx8jdxsz4 a5PensB1/NzyfnPN3a7Bc9Fk17uN0cC1TVurRq7jx+c8bQ0buR7V42fcXDdy7dXqx9rHcif18U+x U9ZdNhJHZefLRuMpMK/zmnBBlzmn+4/io+xy2ei6z3ZeDerzQP/26fNIv9Y3ZYN6H9wk8NNYUEb9 H/BhebS2/o33X3mc5p/yWQQpo22DrA7ldoIMTWdFFIGVIJ4gicCm+aGCfFZBbanIKxsdV+Pni0A/ 0BjgtZnX5QlzfqCN42ILtrDPB8baEHiugsZgRSDP6C27+xx4tzltfKyOi6UKp26PPjYryI6KpRqM xEeg7oDOQDydLBvJpUZysa4gHtlXnkWwUPf9YoKSstE8jaDco8Uw5zljch89TyqvJKgmqNF53C+3 y0byOcyrdZpd5asI6gnWaW0dD+UbNeA1GBCu9QfbU76JYKs+DqbpelsIdpWN5IXlewn2az4pP6jH V2ZQuwNAfio/orWV28f2lR/X4qH8Nb3tumz5KYIzBGcJ3iK4SHCF4BrBdYIhglvUH4Jgd9lIXltB /V1BeUIFxVkFzYcVKkEYwTMajOSsXA/Pl7v19pK9Fev1/jqn90XAl+dG/RQYW2gfx6Xe9xVNWp/A jnOaf9hPY/SdK5uQd4/Jt9t1nybr+oPjqGc0Xkby5i69n3p1+fllo/uCwDjQcyb22Zg5W4/Vih1l Y9ePJk0Gcx21s6JZm3O4Lv4LKrx5T/zvjnTijlRqlm7x+bAULuxCZK8hWEuwgaCRYDPBNoKdBHv0 zwz7CA4IkZxD18M6HNNlCBIGRyG7naBDf65TkwW/W9MN+ryu4wLBZYKrOvR/CGB9N3Vb/EJkJY0C 8+YrOlh0iNQhWtizY7MTspOz07Izs3OyC4BzCAdKUWIL4SUorsQW+lSenYlrEfELsquyl2XXoqyk sgZ4bfYGKkw1Am/mJ0h6W/ZOKnuy91E5kH04+xiVdn7nIN5gKYLeXWnAGym1d1FOxzsno/G2yTi8 Z3Im/uo4AX91nIR3Sz6At0pm4X2S2Xif5Hy8STIHb5JcgHdIPvx3rInfYlE3+haLrCeoz4v+Z8ha TrBiEv7q9+El0/UZgvUT72U1TOTftf4mgmbxkQevPXj9b1yGHrzFb5jEG0oF3jKqvV/UiL8nt+Dv ye/B+0WteLNoHN4pOhNvE03AW0Nn4X2hyXhHaAreC5qKN4La/r/plZTDyjlhoR508pt8068Ike4h qBy5mjMWAUIyyOPp1cKUTiMrvUbIGWHCQPeVjHhhJFBJPicxa5JSPbGkp0wsiYsnKZPoS8+YWBKj J5b0rIlldufEkr4wfT8ggFmjPf0gQMcZaoaavniSUjK2ZIRlhKV7xpaMqIyoyXiJu8aWDGuGNTFl YkmvnKRUTyyT+u+v8al9khI5SZlE3+zaxIWJSvpb6VfSrydaEpX3rWM/9UntnHOJG9OHZt+cXcu8 pKyJJTEufVWCnzReS15COm8xb7xPuUxqX8sk5cgkZVwbMuIz4tNrJimT9GXykoklvS79CEDH7Pv0 VZOU+vTjgACmOmZvmFjS16W/ln6W4DWiiIZnLBNL+sb0UwAdM292+cQymc2zV04siZ6JJX3r2JJY l1iX3jK2ZCRlJKXvGlsybBm29E2TlJJJyiRyfO6N9z0LvL2b39tdL8zKOuVZEYI3PfN3pJiULOVJ knhKeUpkKJ9SPiXuV/5R+ZyYp/yr8q8iG2/2no93XD9EK1iN1CjMNP8tEvcINbVViAnQJqQZG4VC YCQwgXdIyEQbCKJSG1IyZpTMPZ96KbVhRoktZ0bJaLFN066prVS6Urve93PbfZbRzzNPpx6a2ZV6 LvXGzD7btNQmvfTaZFuCrSB1fepugvWpA7ZwW5qtKLWZykkC4tkybUtmlMQnzO2OT5h5cua5mV2k e33qjtSjqadTe1Jv22JT18cn2Mpt5fE3bVW2ZXPbqba+uZ3xZpLtmdueupyfIN5Jza65nayN5GtJ fqVtDcsHt2vmgG0tbDtB0Gcz25JTm2wugg0EjbbNtm22nWP6rA59Fng7twnv5eY+U99XAr0KuUj8 zUUmfqcRy2+cT64CiLmnhGFu+2jhfQHeBC6CKEkqkXyjv6GZuUFIccXCYUuyJcVsHS02+omrsvkC tG2ebV7g3pz+Of22+VToZ0Q+z5Y3Qi+iUmwrDtYVfCXKF7gXVxVXNSLn08v4n6TR8r42TmJfsF3B No23J6ADzwVknFT0+lhusjbzb6HkHWE/4H6T98o/JDe/Lv9ExMtvyFfF7JBXQ14VH8X4Kgp9LHSZ +Bi+HYDfyhylv/97Nv8eUeY3MSv0PO045P3yCWGU20lXLJ6JI4lYMQu5JforKUOI0lYhTb+E2vk7 A0gHv6dezBd5o38HM2NQTLm36d6m2KzYKzMGuSSpSeqMmzP8sUqsJTYyNjo2LnYW6ufIDJFfkl+i +r8tf5s435G/Q7qPyEeEQf4B2aJQizqFCW0JIbs+KSyhT5J1ERRNm6RuRJNHTKFa1wlpLu2SZrcJ MX3JhwLH3Mq5ldZV1lVxO+J28HVu9dzqGUdnHE3albQrVv+ZcXrG6bk1oyU2PDac5WITqLTHts/u mN0Rm0alQC97qOykQnJMx3TEdMSejz3P+gNlxu4Zu4N1cmG54MK2BQo/w3WN2EjPz4mfEw/7Vs9Y PUYT3Y/bHbcbdgVsmsSe2Wtmr4E+bhPJjFhXZ62L6YzpjM2JzWFdKHVU6BozGDPIfzeG75IQ+JYH 7VsSZMtWy/PCYPmqpYX6bqdlpwix7LK8KCyWr1u+LsIs37R8U9xj2W95SYRbDlgOiMgPHMeSdFDq R6/XU3SKGXlCxNJeds5pgi6NjmnUwHpW4wd4sw+PwowoDYI/83WqbxT0z9KcXuGwnphTYF0fXR5d Hrsudii6fNaeOUUxx2N2xeyftcEaZRUM0UtiDsbcmrPEup6glUpUzJA1ak5R4nKrGrvR2jpnZWKb 9YQ1KrrcmmRdb02a3mttoOt664mYoem3iY6a3maN50/R5SNwPGZj7MY5SxhIgwYsFwRkS0EANBut rUE2bow5PlvR7auEnvUBPXOKYlk72RWwaVJ7jicuZb14jmTYLmsSQVS0K7pg+qHoKpIiXbO65xRN b5vjmrOGrqen9/D/1Mlb5O3Upy/IL9A4/5r8NYqALZYtItSyzbKN4uAFywsUB3ssrRQH37J8S0zF t1lMw/dVxPxFcxv/Xt5FsBKzWxL+m3Qp/h4xT5/xkiC3FiuYJBYHyWWK5fRp2ogcz24vchTTHIT6 UVs8auNvPjMjugWiW0F0q4huE6I7BNFtQXSHIrrvgSZug0AbjGjDHNjTrNu9H3VrvHWwWqId/Siv U7c7WO4orJbw37nM+2v8vR3+nry9KnQI6JCgQ4YOA3SY6ekWwd/UZ5xYO/SHhm4n/eHv6wVZNIjN 8IPWA/juNvGM7oVVIzxZVOn9Fyy3XPdCsc77MP1ztx5/P7ubxZEgu+eCd1TsCYo6jVer918wb7Pe fwHeX997H8T/f03/TuYFSRwTXVj7OR8UcbMIqJ1xGcIR5YxLnhIdlxZVTGCLKsY1Ly7znmNEO4mm +0StoJIXl0NUHpUVcWkomfwpriCuAFwuTi5BGp8I0oc7rIn1EGh6kknLCpZGbcV6zaSJ22LZbiFf WfZZ9lGbX7a8jG8s+YBrEPX6idG8KMojRNhZbm+UL6KJ4FJUWNTSKCeuPi4RlyKLop6IGCC8POJS xKUp1yHli2hjKS4BySjfvdaINgatvWM1BqQii1gXnhvRc2+8VhOVG1EqlRWMI9qoTv7WDtnyNcvu D9vCKQcJjgjHlEPhA1OOTgkLH4gomnIifIA+nQjvm3JyyknQp6d0ET45JYngHHMjloT3RCwLv8Ql oii8T5ft0cqUQ1xGNUZuDR8g0PVBF2sa0UMaBnDv0pRzETI9UUW8ZYyn9KCFOyxtf8GawSP1LXru oD4CU4hnkDKlHMF/Eb9zDDdFyiA5SWwcw42XksQO+rxiDHeaFCtoZyPKx3AtUiTmafsYrpBUQRmG sAVxZXFDFATNDClBbbv7CI+SW+VvksS35P00p70sv0wZ9EH5ID15WD5MvjkuHxcm8s3rwiyfIg+F yD+Tz1IGd07+ubhH/oX8CxEh98g9IlK+IF8QU+TL8mXS+Vv5tzTbVIVW0WzzScrBp1MO/iTFBufw zwNvAf7aBPr5IHpbEN0SRG/XaWq75JOWUo6Xprc9FbwSyUM86xhekbSEeMoYXp60iD4NjOFlSQvp 08UxvDQpEytqMC9JsmFFDebFSbxL2TuGx70r0dwdzAuTorBeBfMUyUKfaoJ54rYkB60WGm9I3Apa LTRevxgMWi00Xq/oC4qJVMQ597/A3C1h7pYxdxto7t5L614rzeCm8T1h2TOhJ7YF8b8KekcQvS2o t54PordMoLcHyWwPenZ7kM7tQXVp9DfGRIBGc3tn4T87ovENxNxi26g0tU7buzLm9dcijGIGf6OW zh0zd4U10N7utnCEVYX0h3WErw8rCO0LKw8r4GtIP/Gqwlx0bzB0gKgq5lhaiJsZ1hFyNYzfLkNl RLIq5KpWmB6vcVSKdTE9qke7B84yS/T0q5atYa7p/YQLLAuDso8PugcKl5xo4WpqtwjdTdBK0KbD IQKK5NATBCd1mu6H0H4muoTAo0OlDtUENTpN90NPjwJ/tu4RDsuQ+ZDlVogrVISqoWGEoyyV5qMh 5aHWUGEZMvYRNz40ynw0NCmkNjTJfNJ8mz7Hmw9xCVXNR+mOlUq8VixDXMZoHNFnGWJdrGlUD2k4 FFLOT5BElPmEuS1UEO0KtZl7/wZ50wddE69I0fA6/yeRsGTS7rCWYCXBGo220Lw1da1+3UAeX01X 2nlOpfli6jb63CwcIedNNZaFoTdCjoUsC+kmTFdTjakm5HxIJ92rC6kl6jxzzGHEPWBZaKomzgWU gOR5U7VWmJ6gcUSKdTEdpGeZ9pk4F0xbp1ab1ZDOqTWEj+E/wD7MzuZDxaz6hBDms5p3opbqn09p ELJCA75vridYR0Arr3kTwVaCFp3eRbBXu68uJ13HtCvkFwuH2W68ZV6s7jaXmD3mSsLVpn2qUFvN NUTbDfOJW2euVoV5lXqUIEwtps91xltczB6Vv96uhkqdXuxcxmgc1WdnXaxpVI/ZQ7Kr+AmSqFZV 45C5hOjd5np13t8xZvl7224FZRB8Bmj2r7pzc6S0+wv+gtWEd1oS+pHn4c7hnMC8LMUZ6wlnqrRn k/KND/Oszd/ZKa6yjNSsUp4tFxlriD4OjsYfAqdDHWLOnQssCX6maQXTfFfc4mclgboGIRMPmQ4j WSMnaxqMzwBfZKwc5hwCMlbcFf4wppXdhH2gO8CvVu1MQ7IataRpkqDjUdcQZNKgv9l/HvYwZ8jA WckQc+ipVtTCe9VOzTaWkZOhp9p0ljnAaeRttpn2g3IT7IxnjtSs1aXAJ0zLlYwNCbAz0syZwyA0 G5kmTgJrhp5k4wBbxZg4A7CkAC0tgCX7gDnPvGVq4n7R9WDHbJqHtjfi2RqstYLr9W8lzbWofabx c4Rz1WbCSSrPgQMqr8RvqvysWa0i/LCR63pYdROeOvwe6zF+QkjD5xU+q36IaXFHXQ35eYiNL9Ld X4MfyjTJP8j+Qb/H+xOBvejrE2wJbJ46zP4PZf3Sy8whD3O7ruq96UN/paG9aexh5svX9QhhL0Ur +1DXTLYNFvYpnC2EmmKIfk/5GnNglTD6mMMtoiUK50XGf0dbeH/g4LYM96m8AxZoV/zwTwnPZq+S 5avQC62gW9EXq0BztFj16O1km9GbHcDVpoWIE8avotea8eyvhrVWPIpxxHFVhAhsRns74LGN0PkQ avkl+j0R+DiwQHRdRexVwm+Vmk/Av8y1yGbgZH3cYRyZKgm/qEUm4moII6gZHh6ChUNqHzh9sGo1 eiQcdDh6hO/Ohc40bXyhdWmIZyH+CdH4a3jv69CzGk91IFbPAq+A5fDk8DbEwE+5X/ikj/z5Kmvg OBGhd75LcYvdnNyO3zY1M1ZOIZ5Pgo5kbESmrmKPYTgPfg/oa6BjgfuBS8C/DToDz2qjYytqOQt6 ufYU6aCnGMvXIXkUnBMahkwdrNLqbYCGStDYaxqxV6AZgbCpCHeb4AFBtkjyBv5PY7lSfVNId/5s pP2GP85owt3biEwTt9p8L2NItjE2hGmY9RgSQJ/E3RbQ10DXG1NYHniPhrkWGjtMr2BsyGIsXQbn dXBsePZhcO5Fjo79ivw48I/8NArkvOHd3COM5fZh9kwLcBNzlCTG+q5uB/AB4NeAtR0W9tv6Lg/7 Oikc9FXgW+BoO2rs8KRqYB/wZeBDuJsJq34Djhmnij8AvqNj3mO/y7S0GZxBxnIvnpqHPgrDs/uA a7UZEvRx0MWQ3IB+xB5Negv4aeCper2MnwDOAl4C/DBjGresAb+do9jmSNgGzWfAbwFGVCjrUYu2 o83TYg9r05AYOS8gz5L9yho8dRP8G9B2BJw+YOysDE5ow15YedT4ND37RyPt4Yx5xs1cu+ES8Tcp SYRvGC3Az4NDu2DlCmQagH/IkobznAMo7axHmW6sZBv4rlICfJv5xhTIF4NzmLH0DmPVx9hYg7tf Mf4z3Q2BTAR0FgF3Q2YaY9Np0AIyW4Dvg7US8GM8gxl+DKuyjG8zR0klPJU50hvKbPJALo1pSYlW eBV7med2dbuBv1m8gjmGj7K8YY+i0N0uni2VfG61uh168oEXMcdwjWmK8G5EcgTHxvAfuV7G8k3m y21aFGm0zics3easSm7CvO0HZy56px4YJ0tyMuKkCxo8OBf/B8YUgf9AOMn/e7o7y/8O2TYfMkv4 DQyGnZjPtwgvz+3gTwG2QcNS8S9ER7MG+bq/i+hWpqXs4TjSMwuSrcBZqGUrtK3gU3bJDz6+SVpe LPM6fphPAqRz0v/lKJVoZpYTJD7xvilT5iAuSV+iu3/mu2KIvwlZOirx73pTZK79K4Jzhh9Jf+DY k3kmnwosZPKJSJMLScYtnSL8S5myFzlJ+j5HO40qSZ4uvUF4ofwR4hgk6nF5tnSNORJZK96ReLX1 SuU8exi+SjY/Jj1GdwulT0IPP+uAJbOlX/JIlzgL9dOsLBlomiX6Ftss/UHqYP38+275SzKtVvIv +NREfhv2Pyb/jPDnZW57Bb8vVf61/DrJ18s/JvqT8o94zjeQjCGcTyfkf5PJ//JF+QuElxq+BJrW OLna8CKPdPmb3F6ZbJb3UW4vyV82LKBn18vUFvlJeOARqYSjV36OZy2Jx5rR8AI8RtqUBYaneP4x /D+iv8jfR60kMa1epjWHYttAz5o+xrTUDZlEA7VI+Rzo5YZNVNejbInhjmEt4X83/IbwOsNb4PAY fMrA/v8xy8t+PJVioDlBnQn6GcZGA2NDLDi/M7wBC3lERxo2g2ZcxHaStbyO/4glpaOG96CZsFKK u9UGysSUz0BPJnTuNFLfKY8bvsHjjlZ1nmG+Q3S+cR/TkHzUwLFaafg92k7xIL1pPEAW+uGBEjz1 JLdR+UeWMTyNWeLbzJcuGhfxXAGPfQPaMiBzEvSnjSGYf2jfYYxQXkTtn8RsQ9i4WPkzZxdMG1aB 7zfWkiUGptV1kLlXoWxK2cirtjFP2Un0K0wr2zgjVd7V9ABPY0yzHOvpB8cI+jBjKcu4Afk2RbWU qvKZ5KBKfSdOIyMdVD8NGV6189VkwpnGVOYgmxWcqw//Gln3Is5ypanIu6aqucRJBD9Rz8w5e0/j DJly49vIjX3gXEVW/J/Mh+QirlE8xJg4HailB7mxliE/Sz5p5J2CeNMUxnFragMNzNmsodHUAmwG 5ozlecbqbZX2rMp/mCiKpFalQkjmb6pHif8LlUaWctZEUSr1KstoFxpuoIzCXM7WGq/zXcoYX+Oc X1C/GzqHv8e+Gl7Hq7w/Dngu8S9x9mgY8meSzqphmh+UBOSZT/MbXsw7WV799PBy4s8f/iwyBNoB haj8rCnGT+NR+aP/bWj+F67RyPH8hLYjQNvvcNupX3LB0fZKKeiRMu4dYzyfYHKPUC63Fb05D/sU 9nwoS1KP8FuYo7UegWQ0xwDJcH6YZuJT6mj4Npr7l/qoA3urHnBWswz2L4m6VYOMzS7GpkjinzD1 g97PmHJn3hVqnH703UlwkkBXgeZIE9BQz62TnkYcPg26zOSnfEalrIpXYs60G7FSLEQeEooM56fA yEP0c3jt9Fw7f9+Lu8iUxGngXcBvAiNDlh8AfQd4EPhdfbVivBY5lYZPAiPPp7yIMTSQ3xlrGVS5 TlPfUf8RVpFNmbBuKsidTFiLVax9yibgfpZUrugcfraTVwrKuzhbgP3yWV5T5NOMDTbGfo9e10bU tRF6NkLDRmi4DA2kbThJy80oh6W9GCzPgc4mPRMQOP8WWMcZH4MM9iykGfZzXqHcAK4D7mEsn9Yz AZbfpHnbTz3rv8Z543AkcA4yySSm6RnOjddpGSafkIhOHfN+XNBOSxper92VsL+WsI9jvrAAC5wc CehJo3yc7/Is0Qn5xSwvXtMlXYgE3p9aWWYYvTN8g3JqafgKnhLAz0AmDXQm3yXcAW2Ma7QcGzp3 oJZbwHvB6eQah7GnGz7B/OFTaEU3+D2aVfreIR47kXhwUpB1L8YOZTE/BZnF0HAC1nZrtYNzRfOG 8hPeoeC0JAuj+w7G0UUelbTLNnM+w5gkT2BWZ5l3MaO+iZE7qI07I+92L5q+y3p4PhSD5hXg8Mi1 Yocer51fmfYA897ZqrJnBM+EUjX4zcg2X8V51K9A/wp7/FU4QzgPfBz848ynHleZ1s5YMD9vxjzW jBovg38ZcYV4o936KpwDUL1+LWv9OGL1t8DPgYP9jpSOk65I0H/Q4gd7xirEcOA3YPw7nY+CrgD2 otewZ+e/OSAcA5wIPf+Mu91a5kyjU/InML5zAbhF1XrkCvyJmKSsmTndwCUcydpdGvfU77qkBTgF 8nbcxeqmcB54P8vI9+M08n4+0yP+YR5Z0DBNoYxiuJ8x7Z0p8uWX+C9s5ZeYlrxKJE5LKAO/08vY vxb0HnMD6uoCrsWs2wJ6CHQc8ArMw2Gg27h29RAwxgiftNDdaNBO0Dh1MfWybbpmeIPPaqh1t9hC 7l/5JdWDMwTGf0J8enkVkOOG8bdGw1gLhsuB0d5hrAjD8AmNCYpP2pfzjpjPJ+Pu9DKfsZTFWN4A Tt4wfyPqbn0GY+8d5P0R7Z66ea+NPVQDOFnAxdg39Wp3eTzSnotlWhkrkZBpgMw8TZJlpFxtzvQ3 YOfFz/pwtnkae7EmXSd6AbgSOs8DPweZFXhqCBqe0lYZplU7nm3z78Q5EueEeEreg33cOmCP/wuc +2kzOe420bpElsOGSsbKp2hV5BMhijFDAdO0Zw9lOyFfyfJU+1bOeMFpwbO9uratsGcV2sJ21kKD ExqswJfRlgTs4IoYG2R+ivywFs/CG9CzHLa1+M+wfv9ByBzE2UIE2sjaajkG5LOo/SnYlgsNZ5k2 Fmo2syUU2Tt4xkC/RIO/TNsX6y3ayRj8s6h9p65zK87r4jEPxGNWYflaWFsMbIOdR0C38mmwIdp/ BZzfQ/MarJKhoI8B015JfgUyvwY+y3zqhS4+rxD8P3rvMqbI0bS9zTRLEt0FWuO8Dk4T+mUvYiwa 5z+hoBNxZsi9Och/kUiYdR6EJbmQaeKnqC9+j8h5hXMk1FiKKDXD/tphA2SuQKYL+PfotVfghyug 3waGPPbvMltlOKPHEjBkzuBuFmrJgrbTaEUW7D8Ne4r5LsXPe+j354D5NMCntYufokjoAv0K6FdA v44x2Icefw/+PAbPvAL6FfTve+C8DuxFX1Sj9ibUzja34m4brGrleomuxhh8Dz31OvzGvsLaoUTC A8/BqiH/TcTMK8BaX++FVfzsvcDP4fcFb/CsRXqagLmN1cCYf+QvQHIzc6QBrCPX8VQX7HmbI4p8 yzneNLTxvyD/VXi1iPmGx1mztAXn0naWl95hS6RH4MOPQH6eRrP90huIgZMcP9IWrpfmLq7xBeAv Q7ISerSzoBbw39Fa5N+OeYnpl4BnQjILkbYOvX+NsfIQvNoHTjgkF6KuBEH7a9kBzgHg3+g9VYxZ gucTnMFKVv9naB+Ec3XzPcgqZyITfkub01jSUM9j1oRzS9M9TBvfgQZk9cZhzJnFmH+agK/jbiVj FafrUhoyh32cTyqbeHalPEwga+WT/x8xVnYzVnECbHgL9WYNv4tZnfG3+VkaBXzmg/NSQ7ocwiOL JU3pqOXn4D8J/EXgLyMr/jrsSQJugyWH8VQ27n4PnHbUeETzDOzBXXkF+NXADVw7eY8t+Z3/J3yW wlhGbiP5Qedh3vu+/1E8yzI4tVbWaGsTZ780fmm+VbtYp/EAaonC3PgsJB+B5dopbpPxIcb4HcGX eVcuf9lIM7ZxrSmK8LPAFYzVCMZKP/B+8G+AP5Ox4RL4EvjbQLcwNs2BjA04FXcXAf8MeAokr4L+ HfByxuYFoB/H3T8DnwEnHHQO6BDQJ1E7bDPex1iuA34Xd8/Bhn8DPQDJZ0DHg/aCxl0TOMpbwC8C Z0PnWnMW2w+cytj4O8am32neYNpwCXcf0GyGDNpreg4y74G/GO16BPwr4B+DnYc0P/BTyp/x7A3G lGXB8+AIzf+opUnzLer9T7RC897PoOEq8BBq+RL49wMPaD0FbfdBTyH402EDespohcwPQCugC0DD n+pZ0NHQ/B/A8K0RvW/eDpnvAhuAHbj7fVjbC04KMGLJeBH8z4HzDdDzgDNxV/NYJDhfRBv3AL8A 7MFdSKqITxWxqjpxF5GjoJeN1cCVwNPA1+r6LDhfBf0rPPUG8B/RllpgRFfIKWh+GfI9aDVqMbWC XwI+nlU+AbwR/IcgE6VFMnrkDPBJ4AH4/wfADvTIs+DvR5+il+U68LeBfw7xNgecReDEg14OSUSC 5W1gjCbzO8A/gQ2vohV/AudNcNBeE2LYaNWexd12tMWOVsDbRow741No0ffAhw9V9LuCsWz6Nujj 8N5/Qc9qcG4BYzwqrzOWvjL8Gaw403lMcfZufBa4grEawVjpB94P/g3w/5u9746L6tr23zP7rJlh DiAiIioq9oY6oKJiiT1qBBVrbEFRFAVBxBqjiIgdG9YgYoliiRob9ha7iGJBY0FjiTVqlChYf3t/ z3Gu9768d9/94/fu530+z3zyPWvWXmfttddea+1z5uw5lJDIc8A3gD8XdJJEc3nIVAFWRmtT4Flg QUj+BvohMFSipR7oXmh9CzwFjjPouqAdQB9E77CNSuG+YxDwPlrPw4bloJ9DchTokqA7gkarGRwl G/g9sDb4sMrkA/0YhXk8Wv8EpyWs/Qr82+DvQO8b0Yq7IdM09PUYiJEquZCfBJkaQNhmagK6MDTA e+QB/h7QCuhGoDFG0znQ7tB2DYjxEmbEMh8yPwE5MACt22HDXXAqATG/dB38YeAsA20D+qJVG68L OBMxlhTgQmAQWiFpQsyYED+mQLRiNhV4nnoDuwHdwNf6GgrOPNA3cNZx4B8Yy0AgZtzhCDSvhfwV jBq9mFeA3xZ8nKu0BsaBXwcyrhKtl4GIPcs94FG0pkP/S3CywIEllr3Q2RjaMGpCTFIING8FH2Mx wf8K4tz8I+idGEU+9ESD8waIWFUOYa4Hyu+Qjd3kXhGxluWg2uRgZcnBmpKDVSwH9ScHq08OVooc rGt4Hgr+XNBJEkUtysGamIM1MQd1KQdrUA7WshysRDlYK3NQqXJQCXOwPuZgpctBVZQcZ9B1QTuA PojeYZtYrXJQDyXeR+t52LAc9HNIjgJdEnRH0Gg1g6NkA78H1gYfVpl8oB+jMI9H65/gtIS1X4F/ G/wd6H2jRMYgAzRNQ4+PgRivkouzJkGmBhAWmpqALgw98KGovTlYBSStgG4EGiM1nQPtDm3XgBg1 YV4s8yHzE5ADA9C6HTbcBacSELNM18EfBs4y0DagL1q1UbuAMxFjSQEuBAahFZImRI4JUWQKRCvm VIH/qTewG9ANfK2voeDMA30DZx0H/oGxDARi3h2OQPNayF/BqNGLeQX4bcHHuUprYBz4dSDjKlGs gxIRgZZ7wKNoTYf+l+BkgQNLLHuhszG0YdSEyKQQaN4KPsZigv8VRLv5R9A7MYp86IkG5w0QEasc kvixh8y+j8HYZZeOPTPu2PeSAjwm0fAItAWtRm1HDehE0OHAPIlKMdDTgP7UBPzpAmNB9wIdDro5 6GmgkyRt8ANulMgvanzgFqCndpZEQxucGyhpvgj8EUBXYDq+J0yRO4W4O56yuYOTJ1EJhm3p2EeE 74eN4aCTZKvhkaQNjyTN3cHPA/qbdgKjgRkY9U5gtLwXlrSwX8NojEjDnfAkPABOc3D2gk6TqGyG 30ywfC9s8MOzs97aHif07qntVgLtKjXwKqCnYcdpLDhGcLqBdkSPu8Hpi3PvamMEjoANIzBSP3jJ C/wU8I/pPe7EvEtOrHYuRj3NnI7WaPk9BmIgSN+11U5qgJ/D5Xe5wjbYCc40yDvqvpU+dwXdG7Yl UXvMzjkZP7BnEfrdAplb6CVK29Mld7yI8crR3dX3gE1H74gl7BvspscwLJff+vJa4JyC/F5EVxVN P2LbD/xAyLwA/VQbEWYkDZJ5wHOQ2aC3yjk6jL1hFYCuwOY6pwmeJjSBVaJH9hjyGeBnwFpX4FPY cwqSKYjnRvres+mINCB0ekJDJ9B9Nf3Il8MYxUbYNhV6AsG/BUzQ/EM/y28VJE3XJSrJksMvgtNe 0uQGfjHYswhnVcBIbcCr0HxV9q4UkzEgZLR4zsKMZ2H2z8GfmFPgXsz1Xsg7InKuQtsA6D8GTnO0 NgIdrvlE0gZvbX5B+0EmEbFxUWrmieBcNEUgu9PRYwTmNAsYgSiNgIUReIKD6oFIDofONjgrEJG5 CJIjoG2RfOIgrJLoD8lbwFypwRIqNViM8rmPKRu4U9ppGgv/50g0IzLNqJ+mVboPs1AlstALclmi cgSjaKVZBTuXSL4lVNMjezRlw3J/aPiAjMgFekPPVY0DOhYyuYiQdIzOH+Pai2jxkxnKszG/ms50 031kyn2c6wEbJN3TNFU+q4JMPHbkvpM73o2jyF9eL5leCc5ZSYtK5S/HAtwALAb+RsRqLiIk3FRG 9FLBdBzatLGUQQ2X30x+h5jvRt0FXYDqCwwmuaOgpHzSJKLRGxXSW67vQDdwkoFzwYkDLpAo5lHS 6ySaNkImExyrREsj0DMg+QD628pR8x2gk7EHo5h8zsXjQR+Rz8vEeuGBWPJAhfSATg/MizxrnIby KZiQPyLrgzxLrF9uGKmm54qYTX/skm0rY0bJlM+t6Lp86kQtJYe2STTvhc1tZauyWWuVKGjJSdZQ SvJTkhY1LRsyUlsc0E32SDMgWQzV74FEpZisnKJ3Z9h8HTnijPiXuAWtm7VW4BENJd9skT5RNmOk uyG5W7YSk3syRSVZIHzrLi03d5NjFB7ORr2S8nPR1zSMy4Sz4vB0dZF8fke+sLMtxpgso0XMsvTY XMk3xsoneiJ/D8PzmFmMegPGlQO8CJ1WyHcDfV2f98PS5ziLAVvKVUaMMRu9HEYMrAPnMHzrCS+t Q0RlY+ySXgALg+UucToPzcHo9yB63At6EcY7QqPxbZWnFo2QSYEnM7Gfyg2jjjNXkNEoW4WFzog3 LcKdpbd1a2Xvo6DnlJYF1FL6Cj4fhwhfBclR0v/UHjJHtOyQO9iVKXq+CJ2mR5idJGmDsNYDvvLG Ci75mB0zPGyKljEs+pK9vJJowh54kzPO3YFfHIwAv7FmJ84aq+edMyyU856JaN8ske8AfVuzB7FU TMsR5NdtiWLtc5N7O2F/DDRcgcdagg5GFAViv2sQMguZItZlb6xfbjL2gBYtl4GvZL+maGj2lv3S Nmm5WGHlWFANeKjWOyyZAhlfnOuCVi/0ew6oxVJ3nBsPnY1BH9RyVptxRFQwLN+PTHmly6+TKJ+8 m8qgFoVK2yyOsLAT/O8P+ytoWWNSEGmKjGfJEbUrGzLrsP76o4ZYkAvwKnJ/BiqGG6J3LqpEPKJ9 ATjBOnrjSkauXBvlWWIVc0a1xIombTZthP3rtEoFPRvg+Q0Yy0XQF9GjFZHvr6Mz8sUCO+XYn0DS S7Mc17q7sdo+kBHFQ6F5BeJhN7yXI/Vbt0nNDk+kNstBYKhWWyQ6oOZbxsDn41ANHiDLrmqxJ+fR vAVjyYUNdZFfQVLemgoN+P2C5SIwVKveMh9FBaiAuloB/qwAD0vOO802xHCw5nmtosL+B7IXUfFk DbmCXHiA1eGBXBFEvwsF/zFmoQm1gccEh/9qKomKJ6/8XaTN5KDEyTs1klcFzzGKxVibEJmilsp+ 0yDZDbG6GXWyNvIogy4K+iAFyKgzyd19SxW5L7QSyRX2vmmivO9DZb4Kq/bIdVbprMjqasOObiZ3 Kwksib0NmdjbINfuWPm7OmM6nmgbge7yORR3xJOaY+BUkRzDI3AseEo1AvxE7A2YDc5eYLi+J/y+ 9B7oLUB/tMYCe+mSEqfJ/VrGJOjxA24EZwuwud7vfchIDIS25rKVu0tUgnWbpQ9jJcfQWN+9IEdx Ue9rs7zOhPxm2GaC5t6Q9IRklY9P5Cig2Yizuul+kHRfYDp2CPgDU4DhwBFaL+j9ESz3hFVBmvfA 9wPfVetX60UbO3AEcBr0HAOdh7Nuyae9PBR6TgGjgC+wV2Sz3ksXeYUJ+VzgYW03AuzfoO++0PhS fwVtFvS9E7KvQInsMfyfAfmnsPCU5kPsZGgEy3dC3l+PBG1+pcxU0K7whqu0R9CyxwTwY6H5luSY nCVN13W6i8wRbaeK5FB7qY3cMFPFdGulhqtav8B02OYIuhfwKvodADpFb03E09iemPdE+F+OIlGP HEl7aTOlYyLmLlH2C5lFmj8x6lsSLZgFC3LElA3cKfmmsZDPkWi+Kzlm2GBaBc02xNsRjLGVFkvQ vESXl57x1sao7fnBWPKA0z68gCdfIDukn7M11PzwMQGRPxYeHos4T4D8CplH0BYvn4Mb3oEeJWl6 iB7PgrMB9uThWXkvSHYCnQTaT6KYF+1JeivESSvEaiv00goz0gqRv0LOFNATnGKaBuRUCp4jV4DN 8XqOSMnv4BNkmbEA7AmW9Mf2cs+tqFRWlmJYx6hPdJ++zCtkdHQ46zSwf99o1ju8T8wQFh4zsE8Y myJ3G3UOau4l6hr7+JGZxXkOTGUFWSHmJD8JntyRKN9LXIC5MjfmLD7LX2LJFmanjPirr0JXULsA L/l2QcHDrjy0KczFLmlgxAqHhEREsVhgAnAGMAmYAkzrFx42gG0JDRvSh+0E7g8bEhbDjgBPhQ2L DGfngNlCsA+7DrwdHhkSzh4An0b07xfGcoFvokWzgQFN2CVotqNRjMhBHLU9hMZ/oBRhr3YGfjfD HD9Dp89Q/QxdPkPrZ/sTnT/DAjq6s+rMjzViLVkg68J6s1A2hI1g41gCS2QLWApbzTayHWw/O8Yy WTYzyU2vbDO8Kfd54GhKxXwbLI2ZSf6uxtIFthss0ZrllnFCziCOu7Wjg7Pgi6P1nERmUOXORwdx bK8f+2lHl3Xa0a2uOE8cixzTzvd4oh2LNhc2CP1FO4nYk8eBmh1Fo/X2eH3c4nofb5BkgpLvV2rL AhizbLVsxaf/sXek0yAxly6GMsZavKXSjXkyf9aUtWFBrDvrywaxaDaGxYmMmM0WsVSWJrz8N7/n sLvsCctl7wyKwVFMKXd45fDaasAxz2rEMd/KcXxjVcTxtcMrK+H42mrCMc9qxjHfasHxjdWBGUWr VXzKE9Iqjq+tjjjmWZ1wzLc64/jGWkBI51ldxKd8IV0Qx9dWVxzzrIVwzLe64fjGWlhI51vdxac3 QroIjq+tHjjmWYvimG8thuMba3Eh/eYfPCL/jt4oFvvf8ognRv7KWkL3TEndM6V0z3jpnikt+nll LaP7p6zul3K6X8rrfqmge6Si7pFKukcq6x6ponukKjzirXukmu6R6rpHaugeseke8YFHfHWP1NQ9 Ukv3SG3dI366R+r8E4/8x9z8e4/U1T1ST/eIv+6R+rpHGugeaQiPNNI98oUeMY11zzTRPdNU90wz RExz3T8tdP+01P3ype6XVrpHWuseaaN75CvdI211jwTAI4G6R9rpHmmve6SD7pEg3SMd/wWPHGEZ 7CK7jvcVvWBvDEaD1dpJ90hn3SNddI901T3STffI1/BId90jPXSP9NQ90kv3SG/dI9/AI8G6R/ro HumrR0yI7pl+umf6I2JCdf8M0P0zUPdPmO6XSDlS6yDdL4N1v4TrfonQ/TJE88u/7JEndo9E6R4Z qnskWvfIMN0jMbpHhsMjI3SPjNQ9Mkr3yGjdI2N0j3wLj4zVPfKd7pFxukfG6x6J1T0yAR6J0z0y UfdIvO6RSXrEJOiemYyImaJ7ZqrumWm6Z6ZrnpHvepZ2Y42aK9YARzZEPnIV1d+TVWA24a/mYrXr 5ijWJXOyeZ2xreN4nQpwjAW1XvAm6FSAY5ygUiA3UacCHONBSblJOhWAtw+WE+tpXTEfbcVqGiyq eoxYS6c4Jth7mmzvaYq9p6n2nqbZe5pu72mGvaeZn3pyXCCoVHOy4C3UqQDHRaBSBG+xTv1XFiXa LZplt2i23aI5dovm2i2aZ7coyW7RfLtFS+wWfW+3KNlu0VK7RWKtMlQ3VBdTc0L+NteQZcjCKuzM FKWq4i3/eg4+58vf1RtKGbzkGfZVvBhW8ULy6khprDT7/K3eQoN8z4xRGav0l6u/Eor3cnqyv71t 2g3y8j3i7F9403hLcTXhzDzEFYS3+KTwL5nR+BpUazvVBhQX/TszN0i8QGsuWv7EWytfGF+IbnON cn/ra0gbDMms6H+cG7aCbRA5e5BdZXflZZLBzVDSUMnga2hgaGloLyJa9CiukYx4U5mi9rdToZ8o 4xlBLQKVaafO2qlzdioLlG638bz8ZLwj3+ltPMSMjnsgc8EufdFOXfq787Jx3mGBM40/C5wPmcuf ybgbj0DrUeGHReJ4xa7pFzt11U5ds1PX7dQNO5Vjp27aqVugzGK+PJiXyHF5TdvAeFL0tlT0dxK9 LjUex/vCT4lPKeLzKXBTjCcEN8X4q13XbVBGZjYmGmeLGUs1rhaSacYNzGrcaNzIChg3G39iLsat xm3M1bjDuFvEFUdEuYnaIt+tKGOtsP5O8+WiYb1xvdC5Tchz4z75NnEZ4cYkvHlJvrNaxru4NmOE uyZxVWJcYlzCShiTjcmspNBxgJXC+5S+wPuUGuO909z8pznXKO9uOEf33MrlLzccuSP0CQn+kL/n 8+QnJVvJFpH+i/zVLzMaurN1vA734u7ck5fklbg3r859uR+P4/E8gU/h03gin82T+AK+hKfwFXw1 X8c38I18M9/Cd/DdfD8/zI/xUzyTn+fZ/CrP4bf5b/wRf8Kf8uf8Bf+onFGylAvKJeW6ksPLKfnK W+W98pEMxInITCoVoEJUhIpTKSpLFakq1aCaVIfqUX1qSF9QE2pGLehLak1fUQC1ow7UkbpSD/qG QmgAhVEEDaXhNJq+o/E0geJpKs2kOTSfFtNSWk4/0Fr6kX6i7bSL9tEB+pmO0kk6TWfoLGXRBbpE l+kXukY36Ve6Q2/og8losjhsVTupXdRu6nL1B3Wt+qP6k7pd3aXuUw+pR9Xj6kn1tHpWvaBeVq+p N9U76n31sfpMfam+Vt+qH4XLzY4OjvKvF6RxC7eIuSjFS4m5KMvLMiMvz8V1JK/KqzITr8arMTP3 4T7Mwmvz2syBT+ATmJVP5BOZyifxScyRT+aTmROfyqcyZz6Tz2QF+Cw+i7nweWIuC/L5fD5z5Yv5 YlaIL+VLRbVZzpezwvwH/gNz52v5WlaEr+frmQf/kf/IivJNfBMrxn/iP7HifDvfzjz5Lr6LleD7 +D5Wkh/ih1gpfpQfZV78JD/JSvMz/Awrw7N4FivLL/FLrBz/hf/CyvMb/AarwH/lv7KK/B6/xyqJ 6HrIKvPH/DGrwn/nv7Oq/Bl/xrz5H/wPVk1E3ntWXclQMlgN5ZxyjtmU88p55qNcVC4yX+Waco3V VG4oN1gtJVfJZbWVPCWP+SlvlDesjvJOecfqKh+UD6weyaTwJyMZWX1SSGENyEQm1pCsZGWNyJmc 2RfkSq6sMbmTO2tCxagYa0olqSRrRmWoDGtOFagCa0FVqAprSdWpOvuSfMmXtSI/8mOtqS7VZW3I n/zZV9SAGrC21IgasQBqTI1ZIDWlpqwdNafmrD21pJasA7WiViyI2lAb1pHaUlvWiQIpkHWm9tSe daEgCmJdqQt1Yd2oO3VnX1Nv6s26U1/qy3pQKIWynjSQBrJeFE7hrDdFURT7hmIohgXTKBrF+tBY Gsv60jgax0IolmJZPxHf8aw/TaEpLJRm0Aw2gGbTbDaQkiiJhdEiWsQGUTIls8GUSqksnFbRKhZB aZTGhtAG2sAiaTNtZlG0jbaxobSTdrJo2kt72TDaT/tZDB2mw2w4HaEjbASdoBNsJJ2iU2wUZVAG G02ZlMnG0Dk6x76l83SejaWLdJF9R9mUzcbRFbrCxtNVuspiKYdy2AS6RbdYHN2m22wi5VM+i6f3 9J5NMhlMBpZgMpvMbLLDFoctbIraUe3Ipqqd1c5smvq1+jWbrqaqqWyGukpdxWaqaWoaS1Q3qBvY LHWzupnNVrep29gcdae6k81V96p72Tz1oHqQJalH1CNsvnpMPcYWqCfUE2yheko9xRapmWomW6ye V8+zJWq2ms2+V6+qV1mymqPmsKXqbfU2S1F/U39jy9RH6iOWqj5Vn7Ll6gv1BVuhvlJfsZXqG/UN W6V+UD+wHxyNjka22tHkaGJrHC2OFpbmaBU34mvxntRhvDQvwgtyE6/Ma/CaShqfzufwhfx7voyv 5Gv4Vp7O9/ADItuO8tP8LL/AL/Nr/Ca/w+/L/BFnvlQy+X3lstAwnSzkSC7kRh7kSV5UjiqRN9mo FnWibtSTgqmfiKNBNISiaQSNEbqKUBwl0DRKpLm0gJZQCq2g1bSONtIW2kG7lUw6yEvTMbpOjuL4 lj6aOCWqXdUV6mp1nbpR3aLuUHer+9XDaoZ6Tr2oXlGvq7fUu+oD9Yn6XM1V89R3jsxRcZTrylBU NobKZkBlM6KmEWqaCTXNjNplQdVyQL2yol6pqFeOqFdOqFfOqEsFUJdcUJcKoi65oi4VQl1yQ10q jLrkjrpUBHXJA3WpKOpSMdSl4qhLnqhLJVCXSqIilUJF8kItKo36UwbrYVlUnnKoKuVRVSqgqlRE VamEqlIZVaUKqkpVVBVvVJVqqCrVUVVqoKrYUFV8UAF8UQFqogLUQgWojQrghwpQBxWgLipAPVQA f1SA+qgADVABGqICNEIF+AIVoDEqQBNUgKaoAM1QAZqjArRABWiJCvAlKkArVIDWqABtUAG+QgVo iwoQgAoQiArQDhWgPSpAB+RyELK4I7K4E7K4M7K4C7K4K/K3G3L2a+Rsd+RsD+RsT+RsL+Rsb+Ts N8jZYORsH+RsX2RoCDK0HzK0PzI0FBk6ABk6EBkahgwdhAwdjAwNR4ZGIEOHIEMjkaFRyNChyMpo PSvLcDdu5kV5FW7jtXgun8Hn8kU8mafyVTyNb+M7+V5+kB/hJ3gGP8cv8iv8Or/F7/IH4krmiTgz VznLHyhXhIbp5EBOVJAKU1EqQaWpPFWmauRDtakzfU29qA/1F3M7mCJpGI2kb4UuN5pIk2k6zaJ5 tJC+p2W0ktbQetpEWymd9ihn6RAvQ8dFVjqJrHxnErcjNEvtrq5U16jr1U3qVjVd3aMeUH9Wz6hZ 6iX1F/WG+qt6T32o/q7+of6p5qvvHQ2O5Oj0f1n5f1n5vyQrDQaTuC8pKe50P93hnmIXWQ57wF6w d/h+xkO0lmNVxH2UuH/j4r5Z3JO8FhjP8wVO4W8FJjrsFHc0+ebfBL41PxD43vxI4Me/0PAKGvKg 4Q00vIOGXdBwHxoeQsNjaBD3f+YnUgLU73bqqZ16Zqee26k/7NQLO/XyE+WYYqeWgTKKjLzJbzEm 1mhxXyjW6U1MEWv1VmYS63U6s4i1lvAe8Tb47qoCq4XnWy5qJFPkmfzRJ0rJxn1/lPj0Utyz3YCc Mx8v7jdEm3bkj3CPKO8kGO4JDOLMm/KbEHyjYsE9r/CEuL81MIMxVbt3ZJesP1k3/8XTEqvw0xJl +mffwLgwUkbKb0uUMcq3n33DIu0n0Sq/N/HDXauYfeNp3Plm2L8luCvfOg7qnp367RPlkC6l/8s7 aYaeDNqTH8aKj8P3PPhXfIQtrni0yaFKQquE104GszE1rniIYH1jNBh8VJuDiao6c2MxYrY+JmtV k0ExxNUxGpTUjrYONu/POJ4rSsZ6sgb4rx3ry4axSBbO+rMY8X8j+Z+t9GfKFLefu09a/7CDssbn 1KTqY38fes/p6mxLapz7l7Y4xdUWZ3yTyo0Go7EAO8SmN2gwpWBWo1chT242tjnZLTUowqYon6q2 yibeWVELlWkWGTU6OmzAwBivSiGVvXzq1avjFRAWEh05LDI0xqtZZHRUdZ+SNk9NuPDft0RG94kJ ixziU9pWSrbzQh5/aw+KjIzxajI8ZmBkdFjMaFvJIk716th8fGy2Ojbxr3sRJ1+bj29NH/3jv8Gi OEOZz91iIMbjDAWY4FuNcQYDW2vcdyjqt/ovAotXWrZwVG/boxVrZ5b/Ju/D/LYr0z8sXeHVaGyH Fd+vmBXsOzirab/RTzeMONnp6ovHyQmes5bFh249OnhM37LZJRrkFDDMfbDgyIFqoUuWDKyw+Jy/ 9wHH7d0qHGp539qo7gLvtZXqpT1pPbHpnfgCe5aEd+6zIW7s8uBqI9s+XLytX/0l7T19LOXclq29 P6eqx28NF4W4BXej/stK1Ama/HrNsyTjseIXDnRusXVq7AH/J52SAje+XzMmIiZwk0fGAodKpVnX 2cFhdfZ85Wpu0OVjj7erQq2W1ecndOn6bEf93u4TRipXX+3fGDv/w+Yz47PXFIvu2eDU3ueWlWVs W02TTm71Gllo0k2j/NsdKyek2Sb8YJuwQnizhEGZsMQ2YWGsS49zUc/ColPKdhjntiUg8ePp5dH/ 8/MX909inMs5nP9APTjz5UKP2r/vNJS7MrLgy57BvstS1NONaM6UWSf9fyv94nnXed7bU7880ffZ u8sZ9et3X+vXKexDuYgvTmasy6GxN3xmNlzmEjVozwfXdh5hB9+da3anYHevdo/6frtpXdETVeuU r7a//3LXaeULhKx83ckzv/TJ7MIvgzYMaeZrfh9XJO/egHCnDq/2/RF0fN/9I7Z3Xj4OU0rMr1ws 4FIJ4w9/xN7i23rk/nTjRNen/VsfD+q0Yxuv5PpxdvZzy6xxOxceXV/H++6Yu2kj74xIZecGfXHo vN+0W01c02oPKj7oWu1fL3oqd9NaKCe616w7JMDTqW+6dcWMC5c6fdHyjGfn1VHXXP0nzxu+bM35 VFEVgm1xvK1WFazV1xe83v5jz6WnD36qKSX+XcVA5H1dX/FPVABfUQx8fMXH2p+KwWhUUKHEVMjY uaNPIVtB+cFSyNq1z7CBYUMGxIhuXGzOkmkuZA7q3y8icki/T4ZZ/zPDytpKa4YV+7y9X3+vjmED hgitXu2bNfmnVSF99HfZvba2qJdWa4PP1fzytVuPPPi2VMrxFkOfZbV8cHHGz4PbBvXNXWz8OeBK 6/Aa5Rr1P5BZNl1tlT5++I0W+9bNcm5/tHzVF6n3ncqWympS7k3fxWeLtvhhXptSi89srVHm5zbV xkb+Urhk/Rn1XOrd2Fc5N7R+NYPvxw8VW63eHm6YnPx295aQ8XH5PVMnxE9K3PxiZ9LKs3VXt59U pOLkwBu2V6xh7rH8hhP2J/weXm9N9VqvtlXfZP2u75xRocmLhjklbHpx5KXXrnauM0NOe//i26Lo 0z1tFtRv39EjM7TD6HU/Tj7RpdGyuPZThtBPtQ99W25fUGjDxYEZVcfVHBL/pSkr5VybBOOQBLbq 4OSbHfWq8MY24bWtkCwK5RVHm9VkEQsakZnz/x2looC0sZDB8FEhGxcHWwnJcFbcFbeMEpkjWFSP TX9cPRK4pEPz6iubhzy3qbK5gKKINEr4LHVQY75dv3FcmwovMvcGxqzoVjGmyvCtCe/Xt00axQIe nnrscT3sqPOKsS+NzY6dmpyR1zHj8LJ9XSKfhzRf25w9XXBiySXPneqyok5Jl6+W/LHyd89+Xz1s w6yceokNFw3aWzfi/JRNZd/ffJgd5jBnyr4Pv7I9tV6+Hpvv4lqdHldeMK/p4EpD0+vOumV2Otlr 4Jl9sU0Gh6btSd+TWOvUC+4ydsyf5281vfnth19/3fDh1c1LTlujsufeabej7oqx1S42vFZL7VvH uGzCoLJTX/UMmbW5+556l4NndI4vVvPP+otS4xxXfDN9q3f68h9Or7/qteOAregkLzenKnuDcpvc 6m27M7dS2ORDUbdfrlmfGds0eoSzqDFjRI3pq9eYPqaKE3CFZPk8j0jUmX9jVsuCU1dUGl9fH99a tWvLgmMTlx/iY0350TZh4v8X25wQOCJ0lYB27YM+ifP/RPyf1p590dum3vdcNul4zM7gntyvYfL7 xWOWVG5ZZvOayR1/f9rS/3gPUrumpZ+ijAttR34ZNWnrvdM3B9xf+T6m4rwByy5P481tx16f3H3S v4SlS/N2RSxO+duKDlxXzvMtdZ308GiguXSdNY8zvWvsaHqmNK3J/u1Cpa7Hi4/JrOxnPpPSOWPP H2Uep5Vd5VT58NtzP3dvFNLwuHdr9dvRk55PeTZ0X7Pud1ZudXrZ+W35W7e9Ltxf0jvph5rVKo3v WrzzIEff5s9CwyOf101+ZvxxyfIbi8wuzg08wm6PDmzpdmvXjHPDI5I3sORqTf/ssLN77qgWEx9W H1t1T68zRftU+jGpmfXooKYft/tuXFW5TI77gwt67cmzTfjzr2vP37K4bNawKm33vb1X+s3QkosL ZxXJP7J6GqavRAGZ9SKRzbGoGyXKKh4299i/TvvmUqCU0tBW31YvtU5q7YSaA2Niovxr1AiJDq8e 8WkOq4dERtSIGhwmuTWioiP7DQ+JGVajWUcReNUFy9bqk4XiuqSBzd9W99NnmzHBW1c4cuTIv1LY P/ozTTH/kFCoPs0qnw3ZF35nWMTPiy9HOE6pf6zVsDHlM71v1/l2aa1l+8pm7r95pefogoMLdfAy hOyKfm25c+y7DlXcK13Muv99lbMeTucLDZ1T+UmXffnZR51qbOpfLSKgReUu0fHtvjg/qESTvmtH 90x8fnzktNPGStWXHk+uem9XFYcbTxbevjdmZm+XKR2X3whuN3LR0OC0HvXmXFjvWooe/txi7YXD HXZt2nn9nSme5casvPYxo0RqWTLfrVj78MLZRdfFBVd88Da+asks5XTi2Tiny2kBzRoPP59zY+Sz aT0HF5jcb9a23em71w/oVLrFujYD73fqPd2t54BRT2b35C5zLEvLeS18cJMVjFqbvyU6Kn3j7cPL 3I2i+iwV1WeSVn1cBqmL2x1k5dcXvNaiVLcxA1b8Yw3691zr+Nnq+fjZfGy1atWRpaee+PhvuNbp FBbRf1hMn4io/+61zvU6Q95uOtG0zVCPE5mtGnU8+Ga9225v3z2u7YJOTPy9Uc1fWvvMrbRjTr9b pdrH7z78VdZ4yns2fP/042mXNoZFhY6qGPpgR/qzSbvOPF333nWV+nWZyjXONv6li1J8xPaIfhFt Ol278UfOgWUTj8feHN/WWCfpz4Mpli4lB3555peDI3rW+G5HeWVblx6DPEM+xo5t8PSSUj6g3sgY c6/DPa8k1PEeftL5Ucl6DmNHfFgaPmTMrSeNZi1MGer8TZV2Hn2DfVPOTwysWqbnwBbTc2rEu7Tf kr+92Mzwp+W/L5R32uXyJOfcuBHD/I7NH7MiI9j0hDYn1EzPS+oR3yS+26SkIZtLebfKiExudmvQ g/EVEgdr9SbOUEl4pNxfVRzL/46rHReTg/59Q2GDvIRhnxXKyAeBXyzcVWv9/5t3W/+eOa/WWDs6 H7tgIAnXIMLEwiPHxRDMUMqQxODM4IjaEsJoRmEpoKb4ChoeqgnYLdi3MJGdka+nwLX3fXHIXntO Vt3/OwKDW2XeWk7cvjiM+17PNmvpi7/XLD+5fWOgonQ+R2ZdNvMiJbe3OVtya5R2uF1u+dzLv4+9 y+zg67qXBbGu8yddOnPubt+Bh/u1zta8ObnO6Gr7ztPJR8wuSijuL7tnPWuzdPE8xY4bW7YIhfR8 mXMo1WuWhtqchC5+6+PCqRUeu8+vbbby35AUcc/g5UtL2cedn25ZNv4UVuxJaUhmY5n2aRaTs361 W8eu/0w3U3963bvFXDJ5M2sez5m5dzQSazw+is8RVLRgkmlfw3Z0mtGOpw7Hgm33ruy89yLNvPeL 0rQ5ZzaUhwRaXSty2aT8DVhArQIWUJPgzaMpuuDmEefANY8wCgJw88jA3MgUWDQZGYLLKGMI1xDE NWjcTI/mkbqBKoQrl+ecWZCRWqTgEuyq4BrsZ2XuaGGka2Zh4ahr6WZpZKhqoAzxkwyqn3SDQZ5S CE4tKstMTiVYvE1t5FJwkgisujn17ey/d9ov/ubrF361ylxDqOyfb8Dqsulak90frAzLZHo6pc63 9XZ94ftShtu7nXN+568p/KB9sWbSuSnicxce3fXze93dxIe6BnJz1HTL7J+5Tetbd6PT/MaZ95/P Rx/+k/HgU0r/7BeHhX4u3tfy51r3OVbbvYxlAerMP1q2i7X1JuyL1dSxOb/074woU1l/sQMWN+QS 7W3NNoeJiJZPtRb4xbBh8qNY89Xqu5N1PEQaQx/nvFqpPbW3g69uMcPSchX2GVoFzDu0VCbMund0 kZL3fp9ItvKQIucNdil3J7dwRGz797Ldk9Ns8+YfxivrfBZV1htFavLN2/r1gc08+zdu1sjNKUSB oDG1Yz+T9etbU3bVuvH/Ov2lbu7/iygtJawlBiUtpZLiguREqrSUYCaVYC+sUdp/bAewlVYM79b8 eXSpI+2U5uOonWcZmurEY46qRArtXvE9+3r7v97TW8vkpZW+fX94astOR0Yp87Ue5tMKfp0xXq7R s4N7W4mwxvbNpQ+1OB91+9+fYT99u4lQ4yuBu7J3dqWc9wuw9un6K3lXdd3Vae2vvI88/fDTUTyW 8XV4R21Z1dP8f+0KaybP6Zm1P15qgaiByoNFdYkTZTU1D3tOsHJu7nx372rzXX8dU+vnjo6Mqxh4 uD9d85Q+59RbveGzbm+s5sN9vfUTRcu2JPwWUV+VL5TspBFh1WXd7fBk+9Ezk8Jl3MKy+09P8g1j ZTj1w8DB1e++ZMferwIf7krd15DbEvip/IHa492cjUJ35KwuuBqCm1MsM5kYGQ0a2wewy4bSkUQM gC9oPGEgAq+dNBgN2ZlZwSvUQHUWNDI5mQ15kMfcga5B8LgN+QyQZUWBZQlcI4shMAM8f7m8pjMg qPJt6VMewQjlitpFge4GQUhaeAxdDJwWSDSIMYQwJDJkMOQz5AJpBQYn8NB9ykK1BhWcabWksiA/ vSixIKNSAa1sYmliZOCetz3Uqvd9/5ktu249Wl56dM5KpYKkBX8ehL+dw8Kx72igWOyspRMu5t44 19bHpHMgJiZ3wrONr3c+8FzpO3/XDRWt9To7NpnKtvg850n5XcFpXbsoa/2OpT6CYs7LVuQG2R0o XbZH20Xk8OcJPE81v5W/X20dpCQgvn33uZPtG51evoszanNhmmytGFHtf3RhxE0z7YyX4c4HDJfP 28vX5eMS41wUyB3hqJW/85Ls5ztXjq37Ypp7Z5+0RcHV25dP3KwXLlmVbH+R++WCbedOrXGfy8c4 UeIE76HzS58zr7ZcoJKr8ZPhYZX2oslMZ5/rp3jcEGwSdWNU+L9iK+eiC6H2ilPu2Npf3qEi8z9l YROTvEETkzQiRtgMm5h4gEIcdE+Q6JUkStXNDk2QC2INJJDTHTdiQogRaCdchtWQH1jFgipXYyA2 NDSLwkh2VzSd9GptDrk4zuO27NWp4rOca26HVkKBkkjEyTnzHttN42F1ucphOfXp9nMLQ6VYJrP1 3P0kmPBBXl/i9HzvH3+nxL5eenXrM9bMtaYTlM93FAT+0Jiz/M1u8bWtRhc3LV2tso7jmsSbBFse /4v+77clHnDZLl6x0++bzpocrpuOdxREdmWFflT7VcH/QV655+vquldFjlNc8vS/zTF+adHjYNx7 ZPLTcMf5Bse6RVa8P6p+fGpo18+rj4RbxZM/WuXuOinwyfGqfdi/Gu5y25DznCotDN9jE9zrhVh2 yqwz2CVz4rP3BMM1K2232ivdXc/vv1E++uW7L3az8j9Wz1nQ4tP59KeGpWlayYvrf14a3/WMfhpR 3uk1w/W4r7RZ+JVZFuLLPj1kYAAA74sAIw0KZW5kc3RyZWFtDQplbmRvYmoNCjc0MyAwIG9iag0K WyAyMjYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI1MCAzMDYgMjUyIDM4NiA1MDcgMCA1MDcgNTA3 IDUwNyAwIDUwNyAwIDUwNyA1MDcgMCAwIDAgMCAwIDQ2MyAwIDU3OSA1NDQgNTMzIDAgMCA0NTkg MCAwIDI1MiAwIDAgNDIwIDAgMCAwIDUxNyAwIDU0MyA0NTkgNDg3IDY0MiAwIDg5MCAwIDAgMCAw IDAgMCAwIDAgMCA0NzkgNTI1IDQyMyA1MjUgNDk4IDMwNSA0NzEgNTI1IDIzMCAwIDQ1NSAyMzAg Nzk5IDUyNSA1MjcgNTI1IDAgMzQ5IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1M10gDQplbmRv YmoNCjc0NCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4OTM1MS9MZW5ndGgx IDE4OTM0ND4+DQpzdHJlYW0NCnic7FsHWJRXuj5n/mkwM8wMMLQBZmAExQFRQMDKUBWx0EYBRUGw 94Itakw3JKZsek82dWPKMGrEVJOY3kw2bZNNYjbZJLuJielZjXDf839zFE02N7l3n7t3n4cD77zv +U75T/3+TwHGGWMOfGhZdVld5bgja78ZwDRPxzHm3FpeUlZ/2bKYMsb2FzJmO728ZGJpzaHYtYw9 i0b6wnFl5RUfP/71j0yzbxBjyufjqqfULWgfdTpjBx5k/FrzuDp/yRPvftDLNBufZmzczCl12Tn/ +PDNTxjjb6KDlrYlrctvz7xtF2ODFmMAiW1rVrsD1+x7hbHGnYzpEucun7fku+8mmRnL3MpYWMK8 1lXLWSLzMPbMIbS3zVu8fm70iqb7GJu5n7GCwvlzWts/SusZg/5noDx/PgyWuw0YO78U+QHzl6xe 91hr9JWMaWBLz1k0Z+XSy5+8rYWxndWMGeYvXtbWavvCUMTY5UbGkiuWtK5bnjJswKdo34327qWt S+akr6n5hrEHkI+IWb5s1epeJzsb49kvypevnLN80b2aHsaG34LH2ZhYW9313QOeuOeyWdbR37J4 dIv0wKcbnxf8ROqVG44cPnpe2GcGzIGFMQ2jhHZ61sP4vvAbjxw+fGPYZ2pPfZLyvbBYU1kL07FK pqCljWWzOYzZL1Kfy5mi9fKLUGrUXaXLRZfJxMp+draGGZnGqtNoNFpFo32faXp97K5edQRIk+rc bubDdGw0BsP1mnQ34zeoz92tixAzRe8Rx0fDX8Lu3ST25bclbRO7S1vGWn9ru19Kyt3srv+ujkb7 39f5p/03/8/b/tqkTT3+DG3Dic/D/Mb97Lg+Yta+eV0qu/O3PNOQzMb8lvr9qT+JpLzGZvzWNto8 dpUymzX9yrotJzzvCGv+Ne00K1jabx3X/2VS9rHhv6aeWCup+evsrP/x824+oZ+rfq6Ovp1d1fd5 PxlL4a/bs2P1+/SlefbEfpUUVvNr+tDcw1J+yzP/NwnjvfTX1lWuY6m67p/uobKWZSg3sNR/7cj6 U3/qT/2pP/2nJc01PFxqZdcvv795Lxt8rJ2OXfGvHIcSe/K/IUPPWcXK/5XP6U8nJvw7eVGIa//N 4xgf4pXAPGBoKH9sfP/uMfan/tSf+lN/6k/9qT/1p/7Un/pTf+pP/ak/9af+1J/6U3/6j01KCIn0 0wiejhyUEsm06s9JMpmbaZkZysJS2FCWx/LZCFbESlkFq2QTWTXzs2lsAVvO1rMb2d1uW2+v2q8F 7TJZDmoXonbxsdq1qN3KFrGVx2rz3m/VgTyofkUw1nug96Per5gBxiQaZG+b5okPZod+XjLo+M9k +qh0NTeSlR2fmTJB8SsrlQZlsfIZ5mBnkayJzWTtbD7XcCu38QSezAfxat7Em/livox38DV8Ez+X n88v4lfzXXwvf5Q/yZ9iev6Z2uOXP/mJDWea0O8IatgvJy7H9LObcHycTPlc+UI5BP4K+Eb5tk+t SYyF5iFnzFi2+jk2VGUaEJoj1OqfGcZPZg5bn7kjd/Ls/78n5V/aW/+pD+27b1z7rJnNM6Y3NTb4 6+tqa6qnTJ40sWpC5fhxFeVlpSXFvqKxY0aPGjmisCB/ePaQrMxB6WkDPKmuuGi7zWoxhYcZDXqd VtFwllnuqWhxB9JbAtp0z/jxWSLvaYWhtY+hJeCGqeLEOgF3i1rNfWJNH2rOPammj2r6jtXkNvdo Njor013ucQdeKPO4u3lTTQP0tjJPoztwUNWTVK1NVzMWZFJS0MJdHje/zB3gLe7yQMWa+Z3lLWXo r8sUXuopnROelcm6wk2QJqjAIM/yLj5oLFeFZlD5yC4NM1rEYwNKWnlre6C6pqG8zJmS0qjaWKna V0BfGjCofbkXiDGz89xdmXs7z++2sdktXnO7p711RkNAaUWjTqW8s/OcgN0byPCUBTI2fBiHKc8J ZHrKygNeDzqrqj32AB7Qpdk87s5vGQbvOfjZiZbWkEWfZvuWCSmmeGyZUC41w9gwQswvJUWM5bxu H5uNTGBLTQPl3Wy2M8h82d7GgKZFlOyVJQ6/KNkiS441b/GkiK0qbwl9r5kfF9gy252VidVXv9Pw jXJ3QElvmd02X3DrnE5PWRmtW31DwFcG4WsNzbW8a2g26re2YBILxDLUNASyPcsD0Z4SqgCDW+zB groGtUmoWSC6NMBa2kKtAtnlZWJc7vLOljIaoOjLU9Owh+X2HujKczt35OL2N4pxBGJKsSnp5Z0N 7XMDrhZnO87nXHeDMyXga8TyNXoa5jSKXfLYAhkH8LgU9YlqK8ztpNqyspi5Ic3obtA4lUaxWzC4 K/DhKRmNAhu2S82KHS0Z7W7gTiar4SmhGkKd0A8ySlrpeFGkiKal450pjSmUfmFIztCYdGkBY5++ bDAcGxM9558OjWqLAWW4y+eU9RngCZ3qQgMM9fbz49SItQg9GC2MYjvHyyIlDTcXNg26UU1iF+Pc AVbtbvDM8TR6cIZ81Q1ibmKt1f2tqvNU1TQ1qLsdOiX1J+SovJByAZaCYpnRlOIMVnidclvV/Dg1 fyw7/qTiSlns7jR6quo6ReeeUIfMjRuESevTK1vPK4zMw9WsgHfzVLR63DZ3RWdrd++W2Z1dPl/n 8vKW+SNFH57K9k5PXcNopzrW2oZNzg3iUZGsilfVl2RlwveUdHn41pouH99a19Swx8aYe2t9Q1DD NaUtJY1dA1DWsMfNmE+1aoRVGEXGLTKip1pkjGp95x4fY1vUUq1qUPNt3ZypNqO0cdbWrSGbTdo0 sGnJ5lNtImGT4uZjieFuy93tYns2Ns7vbGkUl4vFYCvxzQPcM5YFNJ6xXVyjNwfCPXNKAiZPibAX CXsR2fXCbsDB4DEciyN8UmeLB34KB6qBOTkdRUV06e7u7a1vSHnBebAxBUdtBtDUEAjzwvfr0iag 3jiBFpjHBba0tYpxMH+DaGtIq2xrxLGVHaJKZSAMPYSFekCNCrWNOI5o1Ia9wQaq7bcgE9jSGGj0 ioc2LGhUj7MtwMZ7RmLbqU9dunhQdmNnpCdHvZu4CuFp5wgKw9hYXQNZnMjiYY20SAYzRt7mQVFb ixurrWVtdTjq5EvDnWSZA5eoTZ+jItwZKmRiWkqayRIeCBuCDvEttGmIuJK6NENjIw1ezZ0TqoBn 2wImjCi9z1KGGmB1UFQpxoLvczBUUfVR0U1NN6v1rINnEYNWezKgOGBJq2yF86f2Jlg8hbKxUfgI U6iPfWQ1iJmbse5KWn137+2e9Sl9UlamR7wcxMFkzj042Kyx82RDYLo3K9N4stWimjs7jZafb0Dr ZbQcY2F0l+OtwVgwTHF3a87cGRbHJ0CcIcXpUpwmxRYpTpVisxSbpNgoxSlSbJBivRTrpFgrxRop OqRYLcUqKVZIsVyKZVIslWKJFIulWCTFQikWSDFfinlSzJVijhTtUrRJMVuKVilapJglxUwpmqWY IcV0KZqkaJSiQYppUkyVwi9FvRR1UtRKUSNFtRRTpJgsxSQpJkpRJcUEKSqlGC/FOCkqpCiXokyK UilKpCiWwidFkRRjpRgjxWgpRkkxUooRUhRKUSBFvhTDpciTIleKHCmGSTFUimwphkiRJUWmFF4p BkuRIcUgKQZKkS5FmhQDpPBIkSpFihRuKVxSJEuRJEWiFE4pEqSIlyJOilgpYqRwSBEtRZQUkVLY pbBJYZUiQgqLFGYpTFKESxEmhVEKgxR6KXRSaKVQpNBIwaVgIcF7peiR4qgUP0pxRIrDUvxDih+k +F6K76T4VopvpPhaiq+k+FKKQ1J8IcXnUhyU4jMpPpXi71L8TYpPpPhYio+k+KsUH0rxgRR/keJ9 KQ5I8Z4U70rxjhR/luJtKd6S4k9SvCnFG1K8LsVrUrwqxR+leEWKl6XYL8VLUrwoxQtSPC/Fc1I8 K8UzUjwtxVNSPCnFE1Lsk+JxKR6T4lEp9krxiBQPS/GQFA9K8YAU90uxR4puKXZLcZ8Uu6TYKcUO KYJSdEkRkOJeKe6R4m4p7pJiuxR3SvEHKe6Q4nYpbpPiVilukeJmKX4vxU1S3CjFDVJcL8V1Ulwr xTVSXC3FVVJcKcUVUlwuxWVSXCrFJVL8ToqLpbhIiguluECKbVKcL8V5UnRKca4UW6U4R4qzpThL Chn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn2cBn28JVS yPiHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iH y/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy7CHy7CHy7CHy2iHy2iHy2iH y2iHy2iHy2iHy2iHy2iHy2iHl+4QAlFzMHmsCzFzMNkBOp1ypwWTR4K2UO5Uos3BZDNoE+U2Ep1C tIFofTCpGLQumFQKWku0hqiDylZTbhXRSjKuCCaVgJYTLSNaSlWWEC0mWhRMLActJFpANJ9oHtHc YGIZaA7l2onaiGYTtRK1EM0imkntmik3g2g6URNRI1ED0TSiqUR+onqiOqJaohqiaqIpRJOJJhFN JKoimhB0VoIqicYHnRNA44gqgs4qUHnQORFURlRKVEJlxdTOR1RE7cYSjSEaTTVHEY2k5iOICokK iPKJhlNneUS51EsO0TCiodRZNtEQapdFlEnkJRpMlEE0iGggdZ1OlEZ9DiDyEKVS1ylEbmrnIkom SiJKJHISJQQTJoPiieKCCVNAsUQxZHQQRZMxiiiSyE5lNiIrGSOILERmKjMRhROFUZmRyECkD8ZX g3TB+BqQlkgho4ZynIipxHuJetQq/CjlfiQ6QnSYyv5BuR+Ivif6jujbYFw96JtgXB3oa8p9RfQl 0SEq+4JynxMdJPqMyj4l+jsZ/0b0CdHHRB9Rlb9S7kPKfUC5vxC9T3SAyt4jepeM7xD9mehtoreo yp8o9ybRG8HYaaDXg7FTQa8RvUrGPxK9QvQy0X6q8hLRi2R8geh5oueInqUqzxA9TcaniJ4keoJo H9HjVPMxyj1KtJfoESp7mOghMj5I9ADR/UR7iLqp5m7K3Ue0i2gn0Y5gTBEoGIyZDuoiChDdS3QP 0d1EdxFtJ7ozGAN/zf9AvdxBdDuV3UZ0K9EtRDcT/Z7oJqIbiW6gzq6nXq4jupbKriG6mugqoiup wRWUu5zoMqJLqewS6uV3RBdT2UVEFxJdQLSN6HyqeR7lOonOJdpKdA7R2UFHK+isoGM26EyiM4KO uaDTiU4LOvygLUEHnDE/NejIB20m2kTNN1K7U4g2BB3toPXUfB3RWqI1RB1Eq4lWUdcrqfkKouVB RxtoGXW2lGouIVpMtIhoIdECajefaB6NbC41n0PUTjXbiGYTtRK1EM0imkmTbqaRzSCaTpNuoq4b 6UENRNNouFPpQX7qpZ6ojqiWqCYY7QNVB6PFE6YEo8XxnhyMPgM0KRidBZpIVaqIJgSjERfwSsqN JxpHxopg9GZQeTD6HFBZMPpUUGkweguoJBhZASom8hEVEY0NRuL9zsdQbnTQ3ggaRTQyaBdHYwRR YdA+DlQQtDeA8oP2JtBwKssjyg3aM0E5VHNY0C4mNjRoF3czm2gINc+iJ2QSeamzwUQZ1NkgooFE 6URpQbtYpQFEHuozlfpMoc7c1IuLKJnaJRElEjmJEojig7ZmUFzQNhMUG7TNAsUQOYiiiaKIIqmB nRrYyGgliiCyEJmppolqhpMxjMhIZCDSU00d1dSSUSHSEHEi5uu1znYJ9FjbXEet7a4foY8Ah4F/ wPYDbN8D3wHfAt/A/jXwFcq+RP4Q8AXwOXAQ9s+AT1H2d+T/BnwCfAx8FDHP9deI+a4PgQ+AvwDv w3YA/B7wLvAO8n8Gvw28BfwJeNOyyPWGZZjrdfBrlsWuVy3prj8Cr0C/bPG69gMvAS+i/AXYnrcs cT0H/Sz0M9BPWxa6nrIscD1pme96wjLPtQ9tH0d/jwGPAr7evfh8BHgYeMi8wvWgeaXrAfMq1/3m 1a49QDewG/b7gF0o24myHbAFgS4gANxrWu+6x7TBdbdpo+su0ybXdtNm153AH4A7gNuB24BbTVmu W8A3A79Hm5vAN5oWuW6Avh76OuBa6GvQ19Xo6yr0dSVsVwCXA5cBlwKXAL9Du4vR30Xhk10Xhk9x XRA+z7Ut/FbX+eG3u85S0lxnKoWuM3ih63T/Fv9p27f4T/Vv8m/evslv2sRNm5ybqjadsmn7prc3 +SL14Rv9G/ynbN/gX+9f61+3fa3/fs3ZbK7mLN9o/5rtHX5tR3TH6g7lmw6+vYOXdfChHVzDOmwd 7g7FvNq/0r9q+0o/W1m9csvKwErtqMDKAys1bCUP7+7du2OlM7kC7Nu40mKrWOFf5l++fZl/6dwl /oUY4ILCef752+f55xa2++dsb/e3Fc72txa2+GcVNvtnbm/2zyhs8k/f3uRvLGzwT0P9qYX1fv/2 en9dYY2/dnuNf0rhZP9k2CcVVvknbq/yTygc76/cPt4/rrDCX47Js0RbojtRsYkBTE7ESJiTlwx1 +pwHnIecWuYMOPc6lUhrgitBk2GN56VT4vmy+FPjL4xXrHEvxWl8cRmZFdbYl2Lfi/0iVhvli80Y UsFibDHuGMUh5hYzqb5C5aIy4mHD1blOivGkV1gd3OpwOTTlLgdn9gP2Q3bF8YjtJZvGauVWa69V 47OiujXCFaERH70Rii9iWEGF1eKyaMRHr0WJ8VlgET0ONFfXV1hNLpPGX2SaYtL4TEWlFT5T1tAK pnA354zbQIpRjII7XBW41ztiuI7jfd5VX+f1VnUbWW1VwFg9PcC3BtLqxKevpimg3xpg/qbpDV2c X9DYxTWl9YFo8RNbNX/Wtm2sJKkqkFTXELgxqbEqsAXCJ0QvBEvqimEljd6ZqzpWeb2rZ+Jj5qrV XvUbOd4hcl5hFN+rViMvvjrUPPP+YqJqoFmrkFZL4+pfbvX/PfF/9wD+81MXE79kUNyrOZO1a84A TgdOA7YApwKbgU3ARuAUYAOwHlgHrAXWAB3AamAVsAJYDiwDlgJLgMXAImAhsACYD8wD5gJzgHag DZgNtAItwCxgJtAMzACmA01AI9AATAOmAn6gHqgDaoEaoBqYAkwGJgETgSpgAlAJjAfGARVAOVAG lAIlQDHgA4qAscAYYDQwChgJjAAKgQIgHxgO5AG5QA4wDBgKZANDgCwgE/ACg4EMYBAwEEgH0oAB gAdIBVIAN+ACkoEkIBFwAglAPBAHxAIxgAOIBqKASMAO2AArEAFYADNgAsKBMMAIGAA9oAO0xb34 VAANwAHG2jlsvAc4CvwIHAEOA/8AfgC+B74DvgW+Ab4GvgK+BA4BXwCfAweBz4BPgb8DfwM+AT4G PgL+CnwIfAD8BXgfOAC8B7wLvAP8GXgbeAv4E/Am8AbwOvAa8CrwR+AV4GVgP/AS8CLwAvA88Bzw LPAM8DTwFPAk8ASwD3gceAx4FNgLPAI8DDwEPAg8ANwP7AG6gd3AfcAuYCewAwgCXUAAuBe4B7gb uAvYDtwJ/AG4A7gduA24FbgFuBn4PXATcCNwA3A9cB1wLXANcDVwFXAlcAVwOXAZcClwCfA74GLg IuBC4AJgG3A+cB7QCZwLbAXOAc4GzmLtxVs47j/H/ee4/xz3n+P+c9x/jvvPcf857j/H/ee4/xz3 n+P+c9x/jvvPcf857j/H/ecrAfgADh/A4QM4fACHD+DwARw+gMMHcPgADh/A4QM4fACHD+DwARw+ gMMHcPgADh/A4QM4fACHD+DwARw+gMMHcPgADh/A4QM4fACHD+DwARw+gMMHcNx/jvvPcf857j7H 3ee4+xx3n+Puc9x9jrvPcfc57j7H3f93++H/8NT47x7Af3iKmzWTMcP1jPVccsJvklezhWwV24Kv s9k2dgl7hL3NZrMzoK5iN7Lb2B9YgD3KnmFv/C9+W/0nqWe9bgkzK7uZnkUx1nu492DPbUC3LqKP 5RLkorTu45ZeW+/nJ9k+77mk19bTrY9k4Wpbi+YVWL/mR3sP4/2KfG++yGvOgbaqLb40XN9zb8/t J61BDWti09kM1sxaWCvmL/4yYQFWZhFbzJawpWpuKcrm4XMucrNQC75E1cdrLWPLgZVsNetga/C1 HHpVKCfKVqj5DrYWX+vYeraBncI2sk2hz7WqZSNKNqj5dcBmdip25jR2uqokk+UMdiY7C7t2DtvK zv3F3LnHVCc7j52Pfb6AXfhP9bYTchfh62L2O5yHS9ll7HJ2Jc7FNezak6xXqPar2fXsBpwZUXYZ LDeoSpQ+yJ5ku9g97F52n7qWbVg1WhG5LnPVNRR/qbARMzyjz4hp/dYeW63NmLuYW2doputgP71P izWhdRQ1z0BN6oX2QfSy6aSVuAhzIH18RpS7TJ3/cWvfVfklq1yPa/uszDVqTqiTrf9MX86uww28 CZ9iVYX6PTSpG1Td1379sbo3qvmb2S3sVuzF7aqSTJbboG9nd+Bu38m2s7vwdVz3VcT3sLvVnQuw LhZkO9hO7OR9bDfrVu2/VPZz9h0he/CYZQ+7nz2AE/Iw2wtP8xi+pOUh2B4JWfepNso/xh5HXtSi 3JPsKXioZ9lz7Hn2EnsCuRfVz6eR289eYX9kb3AL1Mvsb/g8yvbrPmQRrJgx3f1Y52vZTHzp4JVW Ka/AiyjMwEawSWwym/4gs+B1H8NG8l27HGVlxizDw3iVa5gbwYCRcV7qs2o1lt0JCUWe3cP12xR7 ZTfP2llk2IYwt+jou0dfzD767sHIEdkHefY777/7vu3LF+0jsnPff/X9YUO5PcWuIjpCYzBE6z2p QzTDB6bn5+bmjNUMz0v3pEZoVFtefsFYJTcnWaNES8tYjchz5ZUfm5QpR/WazZ6iqbm65ARrtEWv 0yTGRWaNTrPVTU8bPSTJoBj0is5oGFRQklq1uDz1LYM9yRGTFGk0RibFOJLshqNv6yIOf6WLOFKq XXzkUkU/akbRAOXKcKNGq9d3J8fFDx6VUjnVGmXTmqJs9hijIdJuHlQ24+jZjkTRR6LDQX0dnYRl 8fQe1m7WRbNUls6u28MG9H6y02zjEz3dIZHe3XtopwnCJEU4hC9BqDSb+LSon2b10zeIp4niTBOf NMCTnvaN2WSOS03yhFt4jNbMzDaz5l7PI56XPIrH7DFHJtVG+nV+VlRUFDliRHZ2c7M9doQd0p5r O5hjz8WKe5vpVci83rSYGL265AOVFCVC8aSmp+cXcFrnWINHSdF2GLktzeVKiwrTLjv60UIlPMqT mJRm5UYe1FriBya7BydEaE/h7/HHxsQ4I7SKwRzGR/U8E2YJ0+oinDHaoCnCqChGq2nb0VPEX3/d Jf5oC6crmXlZIXval+CKs/FJLptVfFjwEWfGhxtzFT8j9g1KcPhQ7vCh3OEwZYrKmaJypqicKSpn isqZ9+PfhKx37y5olp6Lld6BmuBDO6whtqj83Q6zyp/sMAnW2HyWG017TRpTwsBvhg0zDFD/V7om r5ubugz1rOhgkXpuR/Ds5vfVRct51UsCZq93BGksanSE1pOSmj7cnpefm4LVc4jznKzwvCEaj8cu DnPUcanlrsIpbSsqe+6JzciI5emrL23LifEWDx4+o3xQz9GEwqYJwX2ltfnxk9PGLap58fCohtJ0 vmrMvNqxgx2ugdrTB7oy6zdMGlI/rjAyfHjtUg3Pnjg8safZM2rK0XdGNox29RQmFtQyzlp7D2nN umTc4tk7Etkob2hVvKFVAX8mVgX8uVgVb2hVvA/j39gRLI5nsxSWzjODUXXaB/hgNpwN5UO6wqbi Sr96UIBn0/Rtr+8bNjQtOkLf51rqHaFrKi6wIzpZI+YtjpXWrNEZo32zTqnc/NyFk+ouf/nUwoVN FU6jTtEaTcaInCkrpkzd1l4wvO2i6ZNW1eRZDeF6ZbctLjIiOmOgs/6WL6+76cd7Zzjcg50RUQmR 0YlRYQOzB5af/ejGUx46tTg9O11vT8bM7+o9rNTjlA1kM7oMUaF5R4XmHRU6DVGh0xAVmndUt8a+ y5LEkpMM3dy8IyoqXt/NB+1IrYkX1ynkv7L32UObnqPuusaTYpf7DSl9kzwGSr023GLoSed7DZZw rap9xmh3QlxqtDEjVlOhWvdFJdqNPeMNNqcjymkPO/pXg8Wg0+FDe89AF5wKoxnxBvgUB6veXRQ7 JfbeWIWF5sVC82KhebHQvFhoXux+jZ2F9+7d7eCTwm21qnPg2V55dJvTjg+atsjBG4zRKfFijGGO lNj4lGhjgtEshmQ2at+SSh0VrnQVRpXAxu9hDhqOIzQcR2g4jtBwHKHhOMRv4rIwa62jm3u79Ool 49kvyOGoo6GbFBqNur5KlRY+5ei+2AxjdGqcGBLfL5xMVbQzKgyX4h45rCM3hdkTxV/4ijPwFM5A Istg67oG6EOrpQ8NTx8anj40PH1oeHoMzxdrTxKeJkl4miSb2cInJgkvkyR+pYXZ07p5+A693uyB l9jhqDH3OR6vqtOwnXhCPCcfC63huC9QnvKtvXvdJWFRKfFiVoMTuGPwpAVLJmbsGjWtOfOGaybP qxigXNJ67dLRPUOObcKdg1INsUUz1k+bsjAv4ug/Bo1rC81Ya8KM81kZu9iXbBtiLzBi1AViFgXq LArErArihLFbk7s7Q/jWjCK7WAooe2hp7KGlsYeWxh5aGrv4VZfEIbZubrxvuY/7fLFjsAK7Umpi Q28csQjNwln+xFeOCG2s+qoZovxkSWJik5WQy4yNionheekD09OltzTpowckJ6REm7RrHVlj60et kosF3xk1rDihatXkgZ6SGSPceVmDoldHGHuOllXHF+VefEdZW4kLJ9eo1YbZzHxY3rQiz9E/HVtE XC6dYimcuqy0eN6UkdER3tGTh/V8MCBJOWvigliDvmdiyqhqnPFxvQeVNl0Kq2Qf72HFeIVb8VIu Di1RcWjpVDarrC5Vcbcm0+fN8UVF84k5Pjve3DkDcszOONHWKV5dTptNfKCJU2yH837NMPH+2uFU 7+3eHfEhjia+z2rnE5l5yAN8ICtg4TzdZ7K7C3iBz2TmE+3i5yzhQhXYC+wxo+G9dhU7dRl1Md08 o0s3VdwwbMFBuwgIvN5m20GbOKpiZ47tjyjo8zITe6OVERaFYkP0/8S165W20rU3NRcvmzYq1qTF ckfkVq+YUNhcOiCndsHS+bW5oxZcXO+dNml0lF6rUfQmgym7rHlkfnVeQk7dwqUL63L5oukX4AXo To1LcyEmM6QO8iQXVOcWTB41LHds/YopNadOzbLGu6JM9rioSHj8RE9S0tCStPzJo3Nyx9StwB5Z cdffwMlPZXN2x/mwvHF2sWo7hTf81RdfuEk7Qghx8vWRwvUnhe52Dtzll+riPOG17fMec/zHznCK fPGpruoNuCpjz6XSh0JZjDodPpQzjXBZ5O+PXH/sIM422hOjoiiAFF71zt6D2vXwql52lS+pJYu7 xa11i1vsFkfHHY5Ru8WpEX/L4LMzHxw780WJD5w0FhOacExowjGhCceEJhwTmnDM/RqbeC/sEO8F cYTC0EV4eq2t1nn83Ig3RehgvOo9fkSa+U9eGvbQS/64Rbu+fEt3x6LA5jJ65UUZM+s6Kqs6arzq 0qREhfF31+zZUjJ2/X1rFY9cjh+/ajq7MSuz4fRpSmzfd82Y3sP6A1iV0WzejvTRPKe79wdfqTj0 adgeoxCDsjnCZ2FJ46lxQmSk8ji3EFnDeNZQnjWAZ3l4Qe3gWs9Qk9I3VI4dUVSEWSGJ8Dj0lSYi Yjgs7lGkQnycrwbHPFeGySGFSNqgO0NrS8xIdnkTI7Q9X2oOKxEJGe6UzESr0nOnntvT3a4BUQYN 93AerYRFpyUnpkSHKTxDw5MUfZQnKdlj47r0CDuOSJg9Qnn5x2yptdtjEWYrxgjTkX3akSYrPBpC 6iNPakeFQ+siEmKF/58BT1WkPMtymY8FfG5riasku0QxhcXmmbHteeLs5Iljk2cTbggx7vc+hEgD rYybmThdbGTIi40UJ8QSYhOx6vZGdmuMvmh77BMsz5anGbU3j7M8npc3pHhwN3f6rPtTeWqqNunv QyaM+bN5kpZlh+Ln5oN28bliZrOMGfd5ZzaPyKb3ZA5eDjMRhYh/iaSnDx+uPx5H5g7PIzcTsmjV c2UgxxOTm5NfoBTZEp0JrohRF9eMW1WTNXb1HQs2xgybPGJMa+Uws9EcpjU4S6bOzWvdWp9+y7ay 9hJXY3XxsjFxZjPe3+amooq0irnFE5dPSKvIqx7uTPIkGW3x1vikBE9SVKZ/c/2+2KyijIq6kjKs 7lVY3dd0K9hgNoadtQsXIzwlP3Sj8kM3LD+0XiKvrld+N//B53R4I0V47Raxtlh/r7jPXpsagmvC fWHMEZ4/PEWrG9rNdfelT3BW2P6LvS8Nb6s6Ez7nXu3r1WpLsqUrL5Js2ZL3NbGV2E7s2E6cBCeO iZPIlpyIeEOWE5KQstOmpA8ZCjMfKc90o1Dm6wBhS8LSOt/wxKVteJiylC5Q6MZSUqBDoRTi+73n 3CtZcRKGzsyf7/nsE7/33KNzzznvet73vSdWTyNUj8l7qQYCCXMa065FcIFmGR302y5URlE4lRL5 lCa7nTobL1aPHBkKdq1a5VeZXTZrnlmhtPC5Dt6sCnR3dgaGb9kcuN9WsynCt0Q6/O1Xt7UM1Dvw GzNP3LjK5GsqmQB9lMlAH+UNdFcFcO73JQ2F3NobHpzpuD623Fy6smr+zo2bl40cAI0dBIrx7DMQ OBw6lkd3M9FbfU3yUt98hHinfslc+SVz5ZfCEb9ETLi+TR7wn2C0EX3YgA2ONzwRjb7TA8Ea84hl DfvHSmLr1frOyrITWHFM3UsilOBZCjKB29OiQ3ZhmKIQtzJFdpDC8oxc6VjWPRCO/mO8dsWVd24J rm+vzVUrGLPe6F/W37T3Gm9kaFnjptagTqlRst8yOUx6R3G+OXLg4ZmbfrC/mXMW5BosuWa/xxvw Hr9/8w0DwaJgocqST/R0B9DlLvk48kFkdkvE09qMta5Gop2NxLI3Es+gkUhHIxGWxifwxwihsEi1 sESssESssKSxYYlYYSJQGot3lbbR75IZSslBqtw1oOqyhw298h6ymVFxak37aJJUUXnKBALZKgiu WUaqWJ8vO5yrZ+9SmvKsJAWy+s7LRw5vDlQN/8P2dTdElFYPkSn1PW0H21tBgkCiVniXR1b5HWkB 2tu7qfeGY8OpJ25c3dHGaNMBz7kOkJ3hqyPt18dBltoqCbWGgFp3glULohp0f6Q0XNdaN1nHWog2 WXgSzlm8ZcSPKiPUEtMC1L6BLHz8aHvw7iBDAt5HibbVyCThk0kyRu+19CoaOBmhn9dbNnet7IiM mZXh52RYJssL/8q3JvftHYYpA2NQv51HBWxIsm1XJtNGreqVoChsNDdAFVRR6M0SK9v5wsfY/HWU oEr2Tr/j3EPuVVPrI7GusE6pVbAMq9TWbboyMnlvsmnZld8YueKOHeX3sPv2Lt/aUsAwjN/bfdWm kM1pUxocZr3FqNM6ci0t+0/sT528rqN9+msDlutvD/XE68nOWSz8jblZfhXsnLGH7BxRQKp4Lslq udLWyiWZM5ckTC5yZLyitPiE8FzEzIEDWqw5W7fa6Ttb0cn3cJ3U469qBeyDT1e/L+pY9dMZ91F0 D20i3opsjx/MfNq6UzrImJtlcpVCaXOXuIpreMMzKq1abjY+owLTlMtbVNdwHDE11xR2jq8pXFmk U7FyoyXHIFdr1bnV65uGlSanpYj/9I8qLbFJWhVr44ssTpNyaNsXN5XojTqLi2Seaue/yh5if4ha 0Fq0HT0XsZnLVxMtW60ClFfznAX3rK5uBa+CkKBV0i+4vvYY+ahVuQ6qEb3RjHvWuWTGCrZaqSTS w1F6zUb0UCmvVrpcyupyGaFxpIYQeYBMMcBz8NhAaXFEC9diY4WSbVjzC93GN222HQ3sW8s6S/mV P29Yc/nP+XVSyqmV7phnXxJNf7D6DCFuDnjpxE83QSN3Jgj/gmlAqA40ttvFrcDnV4A9s+dIUVVa 5uphe62po1DUbAi8cI0vs52SJJXP7zew0h17yGK8rjCvaujatfUjLnPOiro/tk1tCNXsvufK8TuH yzhvJV8Zrir2FNVsva6nZLUHcybT/Hx8qGJ1OCd+eWVnOGfj9vVv8SW56hv3dMdbXGyq0FO0Obz2 qo1l+XZzyF0YYjSMd/mW5pap/sriyJYab0tDtcPRU7Z8h694aGXv/svK1Srv/Ptbd/INXYEto576 znPbmloZlaO8JGBb0ZZf0ULk+07w/r8BO3MV2vdIaw0uXUjoSIKdlemRMj+wLee4tcTcaonF0BLb oaVmQ0s+06AISaC4Sx0Q7CqOl68pWuXooeaTBrk4LKVPxM248fwkCt1NlKYL92TRdbSx31CZxT03 N9RV0XJ1O9w6QM6V6a149ZGuwQM9Xkdanhlj77b2ooH+c7ekW7L33+6u5aOHosRS3iT8Da+Xh5EN edHh462F6wonC1m75Mud5/1b6PW1RVGCGBU8wVyJ8pDtUskbiaQ2INNjGg/Jy5LD0484uC5Kn5fO BiVrKO0sF88wWci2S4QRpBC3LCaApay5KUh+MyRgb1SKCCtxRVNpSSP8pjl/NXC+Bt0R0bXW4ZJK XBkx415wCJ6jy6yUDH4lcSJ09EoNfuUTjB+iRZ2EjU4SDJ2Erk5CV0eEwWkvL0cEUVEo7AVaeaAr b5UpLRAQPeMwuBfgz1IrWPVaGu8M4n58EXGQAggwjkqM7Xb2apWlwOkqzDUq5m9cTBF8mcrsKMh1 FNjUeuP843hCr6WJDVapV+M/z+svFIxPf4r3aPRqFrYRtS6Xm398vthkk2iGW4BmNhShmcRJmkm8 eOYwzW1E/nO5hltFMZb4e/HM4QW8dFy4NGkV8udgV+9Db0dcZo5oK9FBH43f/DR4m9qAV12YoxXz LVm53LczGu1226HqdldpiGJriGJryKAaqtga2M2O95EIua/FLw2b5WO+t8gHpQTxP4H/CmaFw4qH uteAu6mI6FesaVlV3tBV3uPI4j8x2mmPqlHKepka0zlWYh/osdHPMhKXsho2KeCUhEX+nGg8LCpr WXuocbqDbJI5XovSXtYWakxlbInCnJdjz+eUPbd2NWxpr+DK13evLtq8p8uzYFUKGxdZlQtb2Bth K2ZZtVa1t3+dM7wiUNleagFz05O2usDBKnR7xChykADJAC/m0iUy7iQ8cmuJxyvaYbJbimaZWmT4 /LhkiokhjmjK15Q6irrSpCf7ZMYWp7OuErU/h0G2/WcGOUPEf+r9TwzyeYQCAu0g9pjEP68ChSzI j74byWstwQEzLjFhnx77dNinwj4lLqXxv1ty690SwdyS2XJLfqpbIpibuKfusAZrrCSGtBJyWYkn bCURppXQzPo4oyGZxONG1DsFbHKQ/y9hXFMIsZIUUJKYSCJZOjgSUx/0B2f5C9khZNrpZ19tmv7X 5OR3Juoap783Ddf6+10tV6zrSrR7Xa1XrOu8op3Hv584eXP3yi88koTrGrhe3XX9cGPN9ut711wf bazZdj2JpudvZ18E2pBo+loSTXvrNJKUaCQp0aStj0bCXkO3bZsYSNOQmuZTxZj6opF0F7fukpH0 xQLpi8jIpQPp27YF2ldEirKExWpzmZUlPb3ry4e/TALpahpIr/K3729r2VLvxG/tefKG1VxBTeF8 S9oWyt4CmWFZkJ59pS0ltp4bH5jpuC62zFLSVjl/dOPAstjVkrVk7qWZnZFHpmqxzyiRyChRxpgm lVGioZGQypyVFCQ0Q06gYHFEHVzjM9r4LhvRIWq86PYVzPgy2Q78xdSGkkTB3Mso1CpVTn6RzVFR 21S4WGmKVzQ15uu9Rfk6GYvZYbvbpFarVdZQT/25By9Umxvq2v1GVqXRqA0ugvF64SzzLGDchZ6N 6MLdrd3ruq/pfqBbnpV4/1BKuFONWUHSC5ZFCXmaiMe/injE7DvNuxPjIiXfSYhDNMj1OP6QqExE QzZ5XYRu/HDrg/FadQ/oGF3olXrNH019ph2mKRMrJtl/STLsa+xviqKVSa9LyfUhki7NSq4v+EJ/ b3KdebZ62/VrKzZ3VNg1MpI8D7Zuaihtr3L5I3396yP+kg0HNhR1NpXYlCzs9RqFuqCuK1waKbEF Ihv6N0b82NAxBvzOcViLPBYnp3TxLnNhXbGvJuApCLZsWlYb7SrTmW2czmjnTA5OaXfYLYUVef7a AF9Quuwywguv8C4zLvtX1IS2PlKCTIXlEs3LJV6US7wol6xYuSSV5UQIdTn68rOFnfn6szmdlSew 7JhSNEJniNhVS9mHM0+LqRnZxQPE88NIezqcZsZVHF8SylkVi+R/wWgmGfaDabfjDZL7MxvfqF+d U5RnVcnVctnl+QWcQa0o7p5eyxjECPElpY4kWHVQoTHkvGZou1qjlhtyCd63kzwN+yTscLdFPLCv af1EgvxEgvzkxZqf+hV+jjoQ+OPHRE3zSFTxSFSB61+pbpLKw/Rgg6SsHklGwYH+OKK2lHf5tXJH F7gZ8oVkDdHPtGeREamLJmsWJeLr6hfSNncpzfm2nHyTovcf6UamtIqBdU64s6LlQIfS6gHNNasz +9ve/rXLdh4aZgrS2nnug3Xb24oH+pmZdAuhTwF4AAeAPmXotydRoQC2mbhtHpqLL/Zgt1hxY7uE p026WhecOXo1Z94vCu9F6snLSdgjTdjP4YAcFwSgYXkBLirAXlJt9eIiL+ZpK4+LeOw34j1e7CVJ CrXJ1unlQWvh7s2IGkTRSzJE5I5wwkvG18GD3kCXV+vs0ooGkL7iCJLzMEN0HwyK/zDZDUW6k7cB QXpCCadfBCxskDmWnHqLdDTpAGZYZv6MTO8MuN0Bh0E2/6xMjlUWT05+oUUtm5exnzAai9eV4zYp 2a/L1Bqd8tP7yAkZmcqgYTfrzGoWQhwGgPqcU6dj/qDWqVhGpSXUrgWP+Uagdgd69SRaDeZpOaDW QJIXJQ24nlyLQ9jnxT4e+zzY58a+fOzPwwEZLmFxUzNubsLN5XgZ+Vu7NtzLSeEfuUY0IK4cDyNw RqmZXCM6spGQZuOKLtqPELOVW8dNctdwMi5itndy1V3FXU1HynAZ+ayMWE3OYu/cWba3jOmA1pwe NSHyi4SSQ0+3tp4BSor0Dov2EFGfI+N9iIRWZOjM+pVZ714uQvKsqvxGmXz+I1afE3B7Sh069imG eYDVO0vcHj/czX8sl4GvnJNXYFaxP2eYOUZtBrH3mFXMzxj8EqO2eJ25+YQtSqtxgSnMV9Tqc9ML LDJalWotcAjirnNOtRo4pAfDC8Hpudz0HaPSEH6VgHZ0A7/C6OaTqBIIYyL5WWI3QsRiNIdwLsjj Y+R9TC7OkWyDPd1kx2oiraUkCiPPLEO4oRDXabGWJ84y4YpWW1lR0lWoNeV3mTIOcWOryYzF9CMi hCXCK8pvsNhuTR/2WjjrtfBGy2JJv8bCbJvK4ve4C21a2cs/k2ltBXn5xSasxrnzH6mwxc/nF1o1 sjPPyTQmjyu/2Myo5z8uM1h0cog1lTg+/zW4sHKdxYCP43sNFr2MVWiU88fwOriwMq3VOL+NWA/w AK8G+hShDSeRC3CtJZrvwiUunEtDwVzsM9QZGL8aO8mW3OTEjgZCOAf2dDk0li5Nt2wd6pZCMPL2 LigqLVFeLyuiWm/x+UByajJv7Sw08WW3KpnqqxSVVU7exCiuVnPs/A9UXJHbXWBVyzFm/6owFfB5 RSbF/KOcSa6zGnCjzKxht9pyDXJWZdSfCzEvWbRy2CfMiMEa4UP8K/k2iKhLkOFRebGrl1sFy3rl 2YVcaC3ry2Q+Fh1ffEpJjg/mmZUmrLIV5rkKbSqD2hHweEpAonJLPJ6AQ41n0v4i+7jOrJMrdCbd J43eoEurdQW93nKHVusopxmgD9nNsJIa1Il8EUNRkUdtfVgur1C3N5FdBh+rWEU231fI+UuaYRRX mDl4SVcpeSQXvHdbHBmwm6sGv9CrLPTb3GaVAqvNeWb7iq2NTj4SXdm0OVKiUcJ2orA2ro/W7D4a q5h/GrBx84ANYMe7ATv21wNf2lEnf99oJAqEYYeyKEvat1Y1bu/wOdy5ClO+Pddh8TjNy3cd/rR5 MbYYlc6/iqfRa8iFNA9pc/IQ98IZ8ZiJUinajHpLhsrTCkOO6ZBcb3FYTDkaLLtJm1vkdBTlaG/1 1ITKHc8qNSqqxthyrYvnFAqOJzr8T8JHeAJm0KKcY+Qgwexj5MCAmgVlOwNW7BSZLiuRNRFuWRYi v+Orw6EO+CVj4Pk3WI38+yAdqmOcHIWB5jnS8qQMkPK7Mr013+bwmmUKZkimt7ht4MLI5O/rjSqZ Um/RKw7ojWpYnVUP43XgR5gQsxwZkeERpNSelSFy8EjKAHvFtZBjCEzIbJrfZoYf/C2VHsT6Y7/b 4/O5FSYnSMpu8G2ekvNUUu48idaAfcoxMr071uDgTCsebcVtrbimFRe14tYTTFvEqsvL0+2vxVfU 4u5a3FSLg7W4Fj54DEJMHhZFtg3xCNqbx2EYVKHD4EL/DTxqplfXJFRUyH0nMHrIsqX9BLYdk2/P nKwEKg69ABZq6HVq/83kpTCtVRGFznKWZYudY+WiyCwdnz5VM3bPleuv3rq8mDOH1u29Z6K4J1Jm UMoYrNSqtb663uqhm/tLWOeK3k2ViSNbfPfn1A2uLF7T0er0tm5rjWxrycff7v/6vq7AmrEv371t 47/88y07l6mNZq3eaDGYnZzKYDL0XHvfVqM719gYP7SjafvKIn2Ox3zd/YnyivVx8qZhA9D2cbkX kaM6q/H1J1EdcfhM5HUwVMg5rNoTUkttuqUm3VKTbqGHVk0Lh1i76DEgYFEXrkj3qUi7ktktNMFZ cYJxRBzWAD32FaCOqlQnB9kCJ5jciNNtLHQDFiRxQIDb6tY00D4NxJmy5YN7QR+UGsmDDY8zbRAq vfAwYfIC0zPnlKQ3vLNSNnGWvmhaSXYyDRljZQUMujK96JXpRa+UFr2SiJpJQ6y9pna5vPycY0vH uYywNGYOLb4gumXnHV6CC5cV1xPpyfxX7WzLVR9iM1GFeOCMrcm8/82pqyPHdNNvQOrYx5ddec/u 2D9PNAW6JzqWbY14K0fuHB2+daiMvP5dPdntfzm/YWPt2KSrcfOy+FhpQcfO9tbtyz033XjtDbjn shsGQ6UbrupdPrqpu8DTsX5rXfvegerw+onW6m2XdfGFa/q3M9tL2yscw/3+tmWNnpovnPtWqHvF cq+nZWVXWfSK3aCnnSBLcyBLFhREb0ccixJIxekEUjnxvIqJdJTjrNQQyYdaSbxiJcyzkuPS1ieY coQQL4ZqvCRcvJRH5aWgBa5vElsH/jX5q7ERtYZHFSiCWHpSXU3ePGvWaRhEvW4jTbFSgZilGo80 SFNe5iJ/6MO4kZyWlA4TnSW+CeUWcUlA0bPzdpRln5GFkmVloWTsXHj8wev23zsarBh78NoDcH3Q 4Aou663ov2K53b0i3tnQvzyQq2a+fMeHx6Kb7/voG7d/RK/fix7d01/v6Dv85Ng//PjapqK2bcmb wHwlQW3vAiq3oNsj+pI6HHTjknziQ0dOpA1jBNsJXe1UF+w89dWY8seqi6GgRinybXycuQZpQfyJ e0Y8Zi3JZ5oaGnm+EcgReqzarght5BpP4IB48rVKyhyERfEGkT5DCERJQkWY+sbSmVhJgMFPW7Q9 KzLSrKQH0O6Sq43qc7UGm1HJaoy6TzYnGs15tX019FAMOGcyRq7Kbd6yu3nbV4ZC9tU3T55hqlVG rXwNOV2n5Nx2qzsnR481W2+7ajgY7G0qKAgUqMxum9HOGWxFhbm1W/d3tBy49YHkS2ozzdbsBCm9 Deg3gOUn0SCQLI+QbBBXqoAolUQUKyndKgndKk8wtRHN2o2+tWtzIVaLkFjNB118JISIQKsvwhpc Ki6dnaFPunj6Qlr0kl1A+UepW0xPkRCJM0jGyCAJtIEwzgJsMDSTVzfNJJjpCTdjclZSOuM6K9qk ZlOzyV53Amsjmq6NZf/B8/IucnBSmzk4GT7byGXOToIxCYsWSLI+9KUsSfebGxcsjyS+CuoXZHI8 TOHCwaYLfawFJtrAJt3WkvqX3SuuHGgyqhSsQa+u3TjZvjLWXhDcuK/3APBKqdAa1FeuTHT5nTXr a5uiPVUa4nUzCpWlqX8yMvily8v5lsHmtsm+cpzccutovS3fYzCAl1GUxxfzBS39VfUDkQIl57RZ HEZlQWRLfaCrzlMYKJQbXXZjjslgAT6HLptZvTyxvlHLKGv7iDWqgJjmebkVlaIQ+iTSRALOcuwv w0V+XOTDxXnY58KFTlzkwMW5uDgH++zYZ8M+K/ZxGFhcJMdFMhx0kQ1sNmImMlKBy+25ULHznPRO UnwX+dpx8q4yLxSCwPPTSD704Ij6cUQiOJKG4YhZ40gkxT3BmGCvlYm7kgxMUvpoR0RDznbIKsJ+ V4gyWBb0cpzGu0HTTyN/0Lrqs1VVUsQUlLJRwSoTed9OjwulNXDRDz7/QENGNdOv9EzEGyzEXvZ5 q/k2lVVMjJ57W8fp5QwEQfincou7zO2tdHO3mWzz32TmL8f34imvb/69dAoGcwrOnWtxO3L0rJn4 /XLw4T49Xci8da4JCULaf2MU7I8QuZd8Drj/CSLvHsj9PXLybUgr0VMRS0kIl8pxCc0FlPqwT4Pb CQt4woJ2UFN9WkPz91fixsquykQlG6zEleQYsxoZDDyaQoy44Ysb/yNk428m+giPNpNNwUwen2nG dc2rmkeb2aJm3HyCCUYM4WJcHPkzzyvrPijdmHsCq44pN2W5f9Txo8ezhiTfrypt+kTKYzEteF7C tD77gJJ0nD6zO9Sx91gr1h+4byq4fkWZVc0qtCptYPmG6ugtA2VM7e07xr66xV91xd3J9Qe3Rvym BwpW7mhdsbU5z9EwuLL7MPP4Zd/7+i27mrWc2exx2p0GudFs7P7CPVs9Fc2jhzdu+tqeVSW941/+ 5qprHxirCK+L1TYPtxeTDRV9Uyw4fMnye2b4c5YfLy6s/TNL7O8ur5Ai+5JY5INZ5ZRYFD2XKK8s lUsV5eFLFVWx6tiFRd0plbcuLJqx/9mi3XKR8gopuk2fWd4jRV+9UAxWw3eyi7H6EuVHpHBtYjGp L1Ju+q8Us+2i5SeWu9PFWmO9c6kslf/vy6uk2PoXlZtp+e7nLM9llf/4f6vYv2n/Zs7cf6/k7s/d 73A6Dc7nofwSym9ddy2VpbJUlspSWSpLZakslaWyVJbKUlkqS2WpLJWlslSWylJZKn9PoX+FGSOk jCGMGxUIqfAmJENm4X2AMWEHwF3CawBTwoNIho8KPwE4K/wC4JzwMyRje4UnAfYjI8ABpAOYhGdN SCa8AzAmPAcwJbyJTDhAWmAEAmcpPE16wjhQZ/uF3yEziiENMkP9I+SDEb4C0Cz8CeA24bfIhxnh GYAc9PRhJzzlw27hNwAP0pYjwivIB8/WABwQWgGOCT9ALTDC2wBjwhUAdwkvAEwJX0YtsJ63AB4F XFpgPQ8BPCWcADgnHEMtgJEJbYY1JADGYD2bYfYXAHLCiwCdwqsA3UCBzTgAWG+GNZD6EaDVZnyU tswRCOthAA7MfwJwTLgdYFL4NzRI8RoEvH4PMAa4DMKqoAXG/BXAg8JLAGeFPwA8Jfwa4ByBQGEN 2gareh9gTPgzwBSpQ8+3AJ4S3gU4J7yBtsEsHwE1ZcDBGMz1EsBtwocAYygPxQAX8jf4OYH8JX2n QP6Gv1sgf0W/TyB/v39GIN8SsIfCg7T9EK0fpvCIQP62/6O0PiuQbzc4JZDvPjgtkG88mBO+jWKA dQjggFALcEy4A2ASZtwF63ke7aK83gWf/gqloOXbAAmPUnSFKVjbSYAccCQFazsB0C08CrBP+BHA GeFpgHsoPAjzpmBtpH6YwiPCcYCP0vos8CgF6/kxSsGMAYADQhXApPBdzAD3PwB4VDgLEHoCPCX8 GeBp2jIn/AIboc+7AI8IHwI8KnwEcJbWT1F4WvgZwDmoc7DmdwEeBOiGp/4E8KjwF4Ckv5v2d0P/ 1wHOCf+BA9D/ZYCc8DxAp/BjgG7hDEDQEYB9wtMADwovAjwi/B7gLNIDPIUUAOeQBgcAo+sBDghX AUwKz+A+GPMXADnAqw/GPAvQDevpw33IAvAgYNcHq3od94Fs5wAcQ114kNJhkNJhkNJhkNJhkNJh kNJhDEZ+BSAnPAfQKfwQoFv4PsCDwhMAj0DPMRjhQ4CPCn/AY7Ceh/EMHXmGjjxDR56hI8/QkWfo yHtonz20zx7aZw/ts4f22UP7HIT2jwCeEv4K8DTQ7SC0/wUfBAr8Eh+iPDpEeXSI8ugQpfkhSvND lEeHKI8OAxYvAeSE3wB0Cr8D6AbaHgZqk/pB4dcAwYYAnAWKHQZqawESah+GufoAgvwATAJ3jsC8 ZwEeFd4COAtUPUJnPAIzvg1wDtZ2FGZ8AyBHoRN6HoUZ3wZ4ELh8FJ79LT4Ko53Cs9DzNwBJz1li 2QC6KQzAGmbpCmfhqbMAjwCOs2BhNABnkQ7gKQrnCIR1RgEOCAMAk8K/41Mw8lsAORjtFIz8J4Bu CgMgS6dgZFInI5+CkUn9KFj2U3TkUzCyCiAZ+RSlwCkYGTgBI7+IT8PIvwTICT8F6BReAOgWfgTw IEjjaRjtA4BHYZbTIBXv4NPw1P/Bc/DU6wA5kJM5eOpNgG7Aeg7WowHYR9sP0nYiV3MU0zm6njm6 njnKkTlYzwTAAWEfwKTwPMi0jOwiYBUPAEwJV7D9QOEXwWLKkA6gWfgFwJiwE+Au4U8AU8IUOwB8 fBlgH7IDPCq8AHBWeBjgKeFJgHOkDuPfCtoiE06yRBd+yRJdINBNYZ/wCkt0gcAjws/ZJLEAAGcp PA3zJukeh1A5U4DIaX3yE6OQpbuvgd6x9BSdgZVJdRZVsGapLsvqI0e57EqprshqV6K/sYNSXYVK 2eekuhrxssukuob5Rqa/Fm2SpaS6DpXKfiTV9cz/kn0g1Q1oTHmY+Af0p0r5V6mOkVJVKtUZpFTv l+osylVfJ9VlWX3kSKe+U6orstqV6KD6O1JdhWzq16S6GnGaAqmuwX2Z/loU1FRJdR2yaYakuh73 aJJS3YDqtN+HlWCZWqKzWBfpLNZFOot1kc5iXZbVR6SzWFdktYt0FusincW6SGexLtJZrIt0Fusi ncW6SGexLtL5PsSjKlQBpQFqvfTbGpJoEk3D7yjsjzxqo99yIX7XRRRaElCbQCH4ZAUag8KjDdC2 E3baFDxF7uJwjUPvPQBj0LMNnhuDPsPQloAeCdovCr/jMFaM9p2Au2lom6Cfic8nYAU8/EahXwJG 2Ad3e6GWgrl4+t0aw1Afg748XfMMPB2j392xk44yKY2agh7j0pykBw84TtI54/Q7OgguXRTXUWiJ 0u+OSFIseHqNUizJvCIeI/BJGR15nLaM0RGjQCOxPT3LOIwzRik2Ja1yAlrG6azimATPVNYKyIxT FJf0d4uI1BbXTmaaBArw9Fs1dlIqJOj3aJDvJ0nRO4JxKsMPkWbiLDxd+4SE1ySl7TDtubDibIwI 1a6iz4lY74b7EJWHbG766WjjdIR9lA4zEuez6U04JuIfp+sn+It8SVJpIFdxRsJrHsaYymAjrnGn 1Gca7vZLo6cAC5FDezJcilIZiULr+Hl4paV5BFYSpfOPSPOHqMTupLwin1yoA00XYN2U0ZpatEmS ooQkb7UwYh18enGpj0vyK2ITlda/k34qricuUYysMUYll6xqN+VZ+pmLfzr6d2nwgrSIvOmHuwRd A5l/I5X21Hl8DEsrmMzCYETSuxTFMk5luQdaRlCA8rgE+sTo+KvpqsRnU1CmgIphKHtpCVEdP3/l ITr6OPRJgWyR9e+kGEzBCPuglXBwlOJCNOf8UdPto/QbfpJUftPjbaFrFqV2H5W2abrCFNWraWoH xKd5igPRyTiVqASdQ6TQMH02Tb0OoF8PWETx2WTWJ6I+xyhNFnR0r/TNOLsuMa94T/qOgBTNUBrG MjIfo59PUYndlyXnUxTTCUnSxbHiFBLNXYw3+Vy0EAF4qoRK5zjgFc/o7IWrmrhg5M9Po4XR01aa l+ysKD0j59m7C3FfkNfz19WcRQGCiYiLaPXTUp/M7CAxakMnqC2NXhJTkc7R82gal6R/sQ4QqhLJ m6FPxqg9ItjEM+OQnmPUpn0Wh/6n9GJBJ8J0NUQHxJ0oRHk1ha66j6+qqGjgexMjycnpydEU3zaZ nJpMRlOJyYkQv2JsjN+Q2LkrNc1viE/Hk3visVBbdCwxnEzwiWk+yo9PxuLJCX46OjHNw+eJUX40 Op4Y28fvTaR28dMzw6mxOJ+cnJmIJSZ2TvOT0DUVH4cnJ2L8yGRyIp6cDvFdKX40Hk3NJOPTfDIe HeMTKZhjZLqMnx6PwgpGolNQJ4+Mz4ylElMw5MTMeDwJPafjKTrAND+VnIR1k2XD6GNjk3v5XbBw PjE+FR1J8YkJPkXwgJXBI/xYYgLmmhzlhxM76cDiRKn4VSl4OLE7HuIlNP3T/Hh0Yh8/MgPIi+tO 7YL543v5ZBRwSSYAbXgwOs7PTJFpYMSd0DKd2A/dU5OA0B6CUpTfG02Oi3MRMo/siiZhYfFkaEN8 58xYNJnhQFN66ibCmtpNQCJAiq8N1VVlkT4O9IVpojD+zgRZRxwWlozG4uPR5G5+knySdTt6cQZT sgA2/ROJFDy/MRVNiTiGYYBJOsEI8C6VTMSnQz0zI4HodAkfi/Ork5PwaSo11RQO7927NzSeHjw0 MjkeTu2bmtyZjE7t2hceSY1OTqSmpa6kPhoFBHaTflsmZ4C0+/iZ6TgsAlAiH/NR4GQ8OZ5IkQUN 76PL6+jvWQGfJukN8Dk2I3J0767EyK6sZ+GamBgZm4kRWkzyscT01BhMQGg+lUxAhxHoFZ9Ihfj0 3JMTIBCBRAkfHx8mDy0MNZHufNEV0e5EpIH800CeEVHuMrNTukpjNdMFBBIwC4g+IX2SKEhscu/E 2GQ0e1JYc1RcKRA+w4HJmdTUTArIvicxEid9dsXHphYh9Hl4QTkRjsVHo6BEoej01FWZeBAJuejm xd/WJ8VaLMQWGmRBSkFARohdxCgKQcyM0Mti/vYzfmTsX3Q6jJH44Ofqr9fT/i9/3v5GI+nPPvh5 +3Mc6S/70uftbzKR/vIdn7e/xQL94YpIVCmj/UlUXUGhCemRGTmRD/zlMKpBLeApbEZr6fcQbgOr TbyDXeh6sNC3YgbdjY3oAcyhJ7ETzWE3egGo/mvch97Bg+hjPIQVeAxb8CTm8Qwux3twAz6I2/Ah vBYfxpfjI3gUH8VX4kdJHgt/CZ/CX8Wn8d14Dj/ArsFPsr34GbYfv8QO4FfZMfw7Nok/YN/Bf2P/ xCjZdxkr+x7jZf/MhNgPmGb2L0wn8KT/fLyYLf9NvJ4CvH4IeL0EeL0OeL0LeH0KeGkArxzAqxjw qga8WgCDLsDrMsArCniNAV57Aa8bAa9bSd4I8PrfgNdjgNe/AV7/Dnj9GvB6A/A6C3idY99hWMCL A7zyAa9SwKse8GoHvNYDHtvOx0t2PAuvHMCrGPCqBrxWAF7rAK8hwGs34LUP8Poi4HUH4PVtwOtx wOs04PUi4PU64PUe4PUp7sNaPIidgFcJrLwe8FoFePUDXrsArxTgdS3gdSvg9TXA5F7A61GSWYNy BvB6DfB6B/D6hO1lNGw/42AHmAJ2jClhk8CXd5gVgNc6wGsI8NoNeO0DvL4IeN0BeH37fLyU/5e4 M4GPqjr//rl3JnfuLAkhsiSAkgAimxCUCoUAESNCwBBRKUWrIyA6iDSshn0kEaNSjUspLlWkFqla sKS1Wuk0Ao0gi4hJjIQqBIKKI6SUGaY05b7fc2aSTBD7r+/yeef4vXPvPcuc3/M8Z5kxM0yJ05WG rl7oGoyu0ei6Vf6/BnTNQ9dKzp5E1zp0bUbXTnRVousYuhq0yzRGv+ZBVxd09UXXMHSNRdeP0eVD 11J0laDrGXT9Cl2b0fUuqnahqwpdR9B1RntfF7ZcvQ26uqJrALqGoGskum5C14/QNQNdC9BVjK6n 0bUeXb9DV3lrXa5Ocbo6o6svuoahaxy6bkPXfehagq7H0PU8ul5HVwW6jqDrJLosvONB16Xo6oOu Yegah67b0XUfupai62foWo+uzejaiq496PoUXcfRFdLKdV17T2+jVeg90DUQXdeiayK6pqFrFrrm oWsVulaj6wV0vYGurejag65D6Aqiq7G1rsQOcbouRVd/dI1D1+3ouh9dy9H1BLreQNef0bUPXV9r umZqbbQOWrL8fF+7Bl1jOJuErnvRtQhdj6Hrl+jaLD8XR5f8XPs4us5oq/UErVS/RHtOz9D+oA9E 10h0TULX/ehagq616HoNXVvRVYGuveg6iq6v0HXOdsrmtjXYuthO235oO2PLtYVstzE3z5LTv+ng v+TkXr1ylq5caSZopuNwaWlDSUlJg7wwCkr8PEoKTDsXDX5/g7w0Nc20+2MPmZMQO4/WUbVljmxN XZSWlKgGvKX+7PTkUq+ZIEwjkh59mIZmmsXRR6HpFqa7OL04PTc7N/smUro/3W8kaIajwSwsKSlU bfJCJbJZw64ZCQXyhQvUfVMWoZAqX1AS8fsLTbsw7ZnZDdnyQSHDKCwt9foLovJo6c2dskpUkWhR ZPj9pevK160rbaXVMDXD9dauR3io14hWjr0cD9kNwxHtHKVtmmE/HK1IT40Cf3lm8mGHXTjs0Q5l qpqy9Np7jQRhJJSU5OenpxtOYThL/CX+Wxn+3UjRPHLyS8yWYuhp6ZuI9vpwcrI3O1tk23Sh2bKz /RoPm9+dIJwJppmcnC5r+f2aTdjth5UTVLdVx9UFhdKzI00XBaYZy8nMzM8vjSQnq4sh2cr+TXVK CuIvcFHy4f8QVDjbMSRHdjlnyPcIKsf/aVB5/kNQORM0p8MfH1VGNKpUhtkcVjLDW9ogM+zCSVhd LK6aGrtIYDntmpPAikWWU9OczYK/b2jJyH+z/ILQUsGeffHYMv5DbBktsWU0xVZ870S0597S7xVd +KklutRFU3RFL2LRxUVLdMngaI6uaAMF8RcqupxO4XSaop1opxRcK/8RZmldQ3OasmoEn0ecDq6y Rqn+j8pSTmE+8EdUyVaWl3lG00VEtaJaaG5TXZWUFBerVuSMqLrudAin43xy7CFfz7ky+sgZ4nRr zkQZcY/GYm6gX8acI0FzSOmFOMVlaC6Tl3h7B83veFtmRWfbkgKVZbfb568ma/V8h6E5zMLi4ka/ f6nLLlwJzYGXTUmHY6m0kJ8Cha3apL9KZyz4/K4EzSUDs0SGX2mJS9NcLUbwO5yaw1Mm9vhLmpN6 3VhTTX0ojr5K7P6Ot2VNu+aIxaI6l2PHm4ybGCMJTT3NVA2o+giSZpCBRqQ5XMLhzsnOye7jl6kt a2o0m8z8/BJXXFGiy6XprqZ5QcQkybjKTE8X6el2XejEf7Zf1zQdbYmGcBt2e6vY1OwJh2N+jAVn 7EqVyo40X0V9jP8dqb16jRlT0miaKo/4jAZocysKVTIaoYSoi3dnhGhLkK4gTJUTHJrLqQKqmEBp dJlcjrg2KujaEUpPc5j6L3CR9K6j+apROVs2FQ3V5paJ1eLilTHTSFdIIS6HcJnNwZosX9f1YOwx Ksvl1lxJMlyjU2RcwEbdbl+K19yG5pbBFR+xjljEqjz7xUPWbRduGbLNMesgb7kMJD+rw9LWzV4Y tO4Eza00x6LWrWnuOJP83wpbKaVQjeuG/xdh69Z0d1PYSmlKlQyy7xm4yuWFxU3rWuxSFUzPbmy+ LMQRsdzU5uBVl1nZMTsXNjdVWNzqcvV8mmtwu4Tb5WFvK1MGKdu/wk/dbH+226G5Y3GmQthtcn3Z XdlKW/Zdlyl/NqoIjXrwAo/J/JYo9jfG2qOpaBw3X0fjeKVqr7CYtjNNKcvtEO64SE52OzW32/+t h3xT6E7U3G1WmivN65Ojqdc6mZKzk7PV/kAFNoo9Ds3jjIagnL53vN1ql6JydR5DR8vc0UNV3SE5 MrjJTRCehCEt0S3tY7aE98qlFzS+cmV0VDcFuN9jaB4zLsKLPZrmiTeY33RrZtI75RXpxXHJ5GWc TU2qiyE50bXH3ZKjAl1tkmKB7o8tpHJWYFJgjjCysyPRjg9RrUQbRCRbOJPmcnr1YmGO30A1xbtq Su0WCHh3fHGC1qPpnuZFVYpVMgtKiMzviPkkh/A4dL0p6mNBn5BwWAVEVFyTPrezsBiH2GXYn2++ Ju51nQCRAelp165HTk6xxeup/Gjgt9SX7eVEDy3tjx5KIxGPW3jcSSKJ96wyDfQP9HvLV5R7y/nP 6zE1j6uxoqJiR2PF9u3bKxo9Tm50FQV+ryiPS17udBXK9+fLeahDeblHxyzlcQ9Zwoy7Ph97AdV2 tIR8gUZRIbarVCHkefTqPb96gawZ5eWHC7skGcaeQo8pPE4rteXhcWkeT/lFHnf5RwpPG83T9j3j PWP7qmmrp62esWfGnmtqBk3OKkzNTM1UO5qlFYaxvKJi38JEU0t0yXqHjm+Xj+OHojusGaqxGVkq 38Zj2D0q/55hTpP6WTMqKtA+NSvR0BKNLK/XG/HGHh6ZvwJTViwtX06N5Re+xPbtibqWaC8vF6K5 14kOLdEpTyr21DQ01OzZUxErE/dwejRnm0OHv8isaJVkf1zNTaurrBnqfEaWJy7v+CHZhlzcaw43 tSi3gYU7pJU9qwvl7G20CBmimoo1i2y5O33P/55/mpDpGlIXkjOJ/7Z7tnumpd6zdvraQW9mNaR6 U71sEpzm9hkzslKzZszY7rl43VRSpkjU9cS42BExYxSuNgzDMyQzM1NkZibYND2BPpX75YSVUF7e 1iGSHPJfmfQQC5TJlJnlml1LMBpUqMVM0GQFj2tpBU6kRmqm12q+YWQZ3K1YqoIxSVwmOtC1nmKG GE0oWn5DyKRKX8YrlKv4jbUnX2CGepW4G9unjZSvEYl9cusS6/XJwjZt0dxZot09c+++Twydddf8 2WI8OdrNE0elYwD5+2LyMxdDJLKnil5pAnmivbofvaOz52pD7zoI29j8/DGix8QJN6aLzFsmjktn QYiWkZ+dJ4uO6srGK7Rtbp2dCutdWuyKmV1cIjqJztMK5hWIV9TxNXV8Ux3fUset6rjtvrvnzhY7 1XGfOlaq40F1PKyOx9UxKP/fjzgtj5qhjp3Usb86jlLHSeo48/777r9PW66Oq9TxcXVco44vquMG ddzU/An4/3TU/sujiSV5Hyf/Motz+RdL///u6fgh8Xs/yyiVfzsi/7pgpXhKrBdbxDZxQNSJ05ou nEqpGVMbFPLvtmzUa8dw0+TnYtrQ6HPJqujzLyNxdYi3k+tbXWuextbXST1bX7dNaX19yXOtry8/ 3/q61wX5fTq1vh6UKZx6/PWZuHxDaDdktb4e/yjPLmK6l8iXf+tGnZWYKlPPFyv0V/RPxDrbL22/ FJX2+faXRVXCx0aJZnPd7LpLe8f1MFu4nZ5kz/X6dZ7bPC/qixKnJ87U/5y4InG1viNJTzL1A0ln k87qnwrNH5a2MaoT37po2k86mHgsLp2Ipf0XSWeSujWnXqShpBzSTJXWXpgS9yetT/p98ppYWheX XpNJ7lkuklxt85vTo22faU7haErpcpHUnzSo3XNx6ZVoUjkXpHZb2u1sTvvaHyYdl6mD/WIppX+H lA69Oj4al55RadtF0/6O55pSarvUTs0pJ5ZyL5ryVZoUe26d/LGjLFehUmVzitb+LLUhrU/a9LQX 0zbKdGHraZsulqKtp72dVhdLZ1qSfJW0c+q1/JJLx3cf2pzGd5/YnKbH0kySv/tM+Q/q9Mi+vP/l Od1ncux/+baeO6+oVulMrymkgt49Sf161/WOQF3v83129n1Rpt51fbf2PdH3RD97v6R+7fr9iVTZ fwQpv/+UAS/EUmCg/+qeV3856KlrBpFGDE4dPGVw4ZAtsbR1SMWQyqF9SEOGrhp2aLihUunwbSo1 jrhmxBux9NbwRq7fGNGgrhpG6iP1EW+M7Jf9ePbWa/tfP5n02Q33Di+Nlua5IVpq7AhZbuz43G65 mbkjcjeO66lS/riZKhWOWzXuBY6F4z4gHR6/eLx//Gc3FpDW5HkplZ+3L2/fuA84HpJnpLq8YN65 CX6VNkzYo9JnE4Lw2YRwvn1CmPxg/pT8Q/l1N80nPTUxnXIbJoSjORMXTwhPPDbx5K35kyomT/5J yk+6/KTnPfZ7ptxTc8+5pud7+5G2zE6e3a2gsGBlQXlBXUGwIDzHPueqOTlzZswpmLN4TsmcNXPe mPPWnB1zDswtmPvU3I1zT88T81LmjZk3dd7WedXzB82fOv+FBZMWlCwILDiz0FjYb+HohW8sPP5A zgPnCrsUji70Fs4tfKFwU2HNom6Lbl/01qKaRecWexZ3WDxk8ajF0xdvWFyzpM+SnCV3LFm75LUl h5aEl2YvXbx06zJjWfayucveXFaxrHF5p+X3Lt+wPLhi6IrCFZv8+d8xV7114XzUerbxL2xJch7x r2tJ0RnkO8Ze7oUjrvU4iUb6RWedppknLrWeO/wVLUnODv7KlhSdF+QcmvxaakXHZ5iHD45oYNZU c7B6Zr5tm8/8ujZpffKaxP3NcyZl24a7T5d1E99KWtsyd0atxOyco+bfaKluSeubrCfvyrlYlT0o 81X5mAVp963EY8zk66lxULW2n96t4fmgSi2rw4kLVoWcuHWgZSVYL/v9rdn/tW/N/q7YnP+omu/V LK/aoXZSDudrm2ZC/LEx5i/mpuj8E53fYn5kTmQGlF6b3jw7NnmUOS41118na7T4uPtEf52/jtZk qTPk5afVdZ/47ZhgHqyMm1EvMs/Gz6vfnlNjM3eFiqboLDq+af6U8zp3eFV/MG0jdyam5l8zKG9f B3t0HVPPrFkdz7U/TFSlNK0+TatKSpcO9pYVKBqVcm1Tpe2yBHW3dUiROfKOLCXvp3RJ3N8Uqamd UrqwAqbI+vI8erdlHY1fSWVf1KoZWzfjVs4UWrhwnXym1eq4P7YytmvqPfnnoq8uX39cfvvDqTn0 p5X1pdWkjfFU3IhtsnF0JEprRiOl+3TsnSu9KS2Rmt/uOeXvjdI3caN6aNomtDatsJXRVv3BVL8/ GE3yFeRz94nSK/IsGmny2R+8vH+Pq6JEV7geV6lVKS7JFS66uqn18X8zqTU1Ln27hFpp41JsxW1O 364hV9rvl9Ra/F+n5hX7O9KFlpKpeR3/jqRW9v86qd3Gf5kutI7ao8Slb9tP7V3ikoz7qKe/X/p2 y/9z7/67FLWz3LskrR9u5HYb3ph4UO56VCpVdwy501FXpbnd5B4olkdiBzVE7pqid+XcL89kUruj yWpnJfdQDSMa1P6I3RFn24aXqt2Jv3kXI9OGCf68QxP8cgejrjbE9jnR8w3sgurkHbmjkfXyYknt eOarvRFlVe4GeUzbROkNcjfFbNEz75DadxXGUr6601PuutRVft4hOS/F8kjs3DLZq8kdmqy3Sp2R 1D6tQO3nKKt2as37tXH5I3VlkUZpi5vmRy0x3FB66HG0p+M+UG3LV1ql2lLtth6J3/ZofBxcUR29 Eob89rb81rb8zrb8xrb8vrYtIAYL+T3Y/VzVq7Og+paupr6LrXPcZZts7ecd+utWo9hhNWpecYl2 l5ioTRVp2jSRoU0XbbX71Pe4B8lvX6vvXmu0c1TYKeuhbFvKeijrUu3VU+qkcGp3iC7kdyf/VvIv Jb87bV1OWxnUfp7+fCa/A2ltkd/Iti2lH8usP9Lfobaj1i9sx0SmrV5cZftC9LV9ZX1kO8G7Xdn6 flqvk99Lt3T53Wv5zWv1vetC0UbkimQYKnqLYTDd+kjcDTNgnvWFmG+dEQtgITwAhbBIeMRi64BY AkthGSyHIuoXw0OwCh6GEngEHoXHYDW8I0aJP0GE8/Ngid6aAA3yxTDtJpgIN8Mt4BMTtArRFcU+ 2ySRZbtNmLY7YZYosa0Ql9keFOm2InGZ/SXrgH0dvAwHRG/7x1AJVVANn0ANfAoHoRYOwd9E74Rk 66OEw9aBhK+FJyHI+TfQYB0wEkSu0Zvnq0Vv4xqeZ1kfGffDbPgpLLC+MBYCtjGwjYFtjMWAbYzN YpjxJvwRzophjj6iq6Mv3Cl6O7wwFebAXFgEfngQsJGjFJ6El+BlMcrxOs/fwElogL/DaTgL2NCc BtPhblggujqFGOZsJ7qq2D2uvicvz75S34NvT9SWEbVlRFtPou1aom0l0XYz0TaVaBtLtGXL77LL 763bJlmP235kLZbfXpffXZffXLcFrA22o8RZvbDZjhODX4nbVJwdU99ib9s8Ku4QA+LaH0P7C2n/ etofTOkptP0Mbf+RWlfT9hrafp72ttLeJJFEK6do5RStJNPKFbQym1YG0MoAWulLK1fIb0nLb7PT kvx+/VXy2+xK6S7ONotU2vgLbfyFNnppd1p/op0BtHMn7QyinZtpZ6Tmsz6krQHaWuttar5Le3ba W0jPZtDmJfSsiNYes9VZZ+jdB7YvGa1fiSttJ2Ijti2t9qFVH60OptXrabUHLfaitY/lt3HV70L8 kfh1x2aYfzOTyJnlWVFkBUUxPASr4GEogUfgUXgMVsMHVkTshj2wF/bBh7AfPoID8DFUQhXUwN8s S3wGn8NhOAJ1cNTaLY5BPZy2asU/GOdnIARhOAsRZrd/kn8O/gWN8G84T18sK6gJ0NSseNQ2hQi7 3Tplu4Nnr3XKfsAK2j+GSqiCavgEauBTOAi1cAj+Bl9aEftXcAK+hiB8AyfhFDTA3+E0/APOAH2x nwfL2p2QYu12ZFsRx/WQC+Mgz/rCcQvPt8IU8m+DO+BOK+jwwlS4j7w5PM+F+Zw/AIWwiOulPPt5 fhBWcf4w4AfHEzyX8vwkPM35M/BzWAO/oP2XuL+e81c4f53zzZy/C/jIgY8c+MiBjxy1luU4BPjI gY8c+MhxmDpHoA7wkeMrq9ZxAr5GSxC+sfY7TsIp8hpo++9wGs5wje8cYZ7Pco2PzGkwHe7GX7p4 XLRTK5dNPE7s3koMy9UrgavfcpXL1ViifIftQ9FXaNwNixwis5bIrCUya4nMWiKzlsisJTJricxa IrOWyKyl9BdEWoRIixBpESItQqRFiLQIURQkYsJETJiICRMxYV5PfiO/1vYTkWC7C6YSQdOso0RN LVFTS9TUEjW1RE0tUVNL1NQSNbVETS1RU0vU1BI1tXgyjCfDeDKMF2vxYi2eC+O1WrxWi7fCeCqM p2rxSi3eqMXqEaweweoRrB7B6hGsGsSqQSwaxqJhLBrGirVYMYwVa7FiLVasVSP2oHBgy2sZySZr 759Ze/9g289a+xGrEKuNsu8JFH6EwiPKvku5SuWqC/ZdSQufiMmskxmskxmskxmskxmskxmskxms kxmskxmskxmskxm80jWslT1YK3swZisZs5WM2UrG7BHGbIgxG2LMhhizIcZsiPU0hTFbz5itZ8zW M2brGbP4W4xj3RzEOD3COP2ccXqEcfq5baroaZsmfxdGFLOOdmUd7co62pm1M4O1M4O1M4O1M4O1 M4O1M4O1M4O1M4O1M4O1M4O1M4O1M4OxWM9YrGcs1jMWKxl7IcZcJWOukjFXzxqXwRqXwfqWwfqW wbqWwVipZ23LYG3rwVipZ33LIP4rif9K4r+S+K8k/o8Q/0eI/xDxH2L9S2H9SyH+64n5SmI+RMzX swZmsP5lsP5lsP5lyHi3TmPr0+zPHrcewgNjmM+PMJ8vwBNj8MSvyV1NtF9vO8BOqtI6b6sSU5X3 ail9kFI1rJiPW8u5mkrdA9T9mLvZ1H2cuu9TN5e6ldT7sTBi4+hHlKyiZCUlc9X+SsbMq6qlu8kf Sf4+8qvJH0ZLj5D7Ji2NoqUPaClTlf9U7RM/U8ewcGltRFdtCsyC++GnUABzYC7Mh0dZ6dvKX0WR v4MifwVF/gaK2hutEx1t74of2N7D/3WiO6v2zewSU1i5O7FL7G77kpnhK3pwgntfix+wns+13qNG B/aU3eSaTv1ZYiwr2BRi/jYx1naH2n2NFUn0rDM960zPOtOzzvSsMz3rTM8607PO9KwzPetMzXbU nE3NdtScrWomUjORmonUTKRmIjUTqZlIzURqJlIzkZo9qTmQmj2pOVDV9FDTQ00PNT3U9FDTQ00P NT3U9FDTE6s5KFZzEEpuE30466NsXKb2CGflb6bI31OAm2Ai3Ay3CBd7Nxd7Nxd7Nxd7N5dT/n9a u/wlFPnLH7Gdxg7loyPyOzBWndYb+kBf6AdXQn8YAJkwEK6Cq2EQ/ACugcEwBH4IQ2EYZMFwGAEj IRuuhVFwHeTA9TAaboAxMBZyYRyMhxshDybAc/A8vAAvwkuwDl6G9fAreAV+DRvgVdgIv4HX4HV4 A34Lm2AzvAm/gy1QBr+HP7BbK+f5Peugtg22ww74K1Rw/32rStsJu+AD2A17rOPaXtgHH7KDmMK7 lTus/fa/spOogPdhJ+yCD2A37IG9VpV9H3xoVSW0teoS2kF76AAdIRXSrDrjCXgWsIHxonXc2GCd Ml6FjfAbeA1+z/3tPLPbNP7K+X6ryviY8jWch606x6VwGXSFdMiwTjm6QXfoAZdDT6vKcQX0sg46 egOx4CAWHPjdcRXXV5M3zDruyOJ5onXK1K060wZ2SAADHGCCE1zgBg8kQhK0gWRAr5kClwC6TXSb 6DbRbaLbRLfZCTpDF6D/Jv036b9J/80M6AbdoQdcDj3p01XWcfNq+KFVZQ6FYdzLhtFwA9xJuak8 zyDvHsrdCz6YCQvIWwbLYQX44Qnu/4ryr1J+o3XQ/A3Xr8Fp7oWsOqcGaHVeYlU50eFsbx13phND S9QvAGEdDetoWEfDOhrW0bCORg0N62hYR8My6neC2kIKXALtoD10gI6QCmkgf0lI/o5QV0iHDOgG 3aEHXA494Qr5q1O8y+4NfaAv9IMroT8MgEwYCFfB1TAIfgDXwGAYAj+EoTAMsmA4jICRkA3Xwii4 DnLgehgNN8AYGAu5MA7GC/lvLbq1PJgA8jeQboKJcDPcArfS70nwI5gMPwb5W0bLYQX44UFYCUVQ DA/BKngYSoD3G+o3lZ6Ep+BpeAZ+DmtA/nvM8jeInocX4EV4CdbBy7AefgWvwK9hA7ACahvhN/Aa vA5vwG9hEzDXasy12u9gC5TB7+UvOslfWoJtsB12wF/lLx/BTtgFH8BuuHAWudW6S/7uE+tAG2b+ LNaBNsz+WfJXoOzMeHZmPDsznp0Zz86MZ2fGszPj2Znx7Mx4dmY8OzOenRnPvon3KJvhTfgdbIEy +D38Ad62vrG/A3+Cd2Er/BkC8Bcoh/dgG2yHHbBXeOz74EPhSWgrXAnthDuhPXSAjpAKacJtrLa+ MX5mBY0nOF/D+VrrC+NZ1iR8oGazdeShxfg1efTZoM8GfTaYpY3N1jHjTdhCXhnIWe4tyv+Re++Q /yd4l+utQD8N+qlmv/e5/oC83Tzv4d5e2Acfwn7hMT7mtXlvZ/Dezqjm3ifWWTVTHqRvvJ8zvqAu 71mMIOfsrg1218Yp4D2LwXsWg/csxj/gDIQgjLaz1jFHkvWNow0kQ1tItc460qATdIYucKlwOS6D rpAOPYXHcQX0gt4wkHtX8Xw1sMo6WF2js67wmLpwmzawQwIYIP+g1gQnuMANHkiEJGgDydAWUuAS aCdcZnvoAB0hFdKgE3SGLkA/Tfpp0k+TfpoZ0A26Qw+4HK6wvjH78h6tH1wJ/blmp2AO5LxpJh7E +TUwGIbAD9ExFMZzfiPwPtecQL18a4d5E0yEH1tnzTvp5wzKXThL837X5P2u+QAsow/LYQX4Kf8I r834V7P2Gp7X0u6z8Bw8D6/S3kZomsVf5x4+NEPU/Zd11imsY05N/u2/FXRiT6eL57bcv0R41MzO CuXsyL1USAPmY2cX+bmkHOmxfdUy+Wtqao+2rfn+bPm7ZupzFLnfOikS9DHW7bYbre3sTl3ysy3y vhH99EzrhD4IBsNIGGN9pI+1duvj4EZ25bdan7G7OMTu4pBrsrXbNQUetk64SuAReBQeg9XwM+C9 nOsJKIUn4Sl4Gp6Bn8Ma+AWshWfhOXgeXoBfwovwEqyDl2E9/ApesU54+lonhI2ehvXJvCeey3vo YfQ/RP9D+lCrnv6H9Ot4fsQ6oj/Ke5fbxJXMX1dScrfrZqvedQtMgtthmnXENRNmwWwogPnwsBVC WwhtIbSF0BZCWwhtIbSF0BZCWwhtIbSF0BZCWwhtIbSF0BZCWwhtIbSF0BZCWwhtIbSF0BZCWwht IbSF0BZCW8idax1xj4PxcCPkwQTIh5usI2gP4cPB1id4aI+u/GjtVJ8cdkX7RnRv1G+zNunT4X54 xCrHBvIX/A6ifSPaN6J9I9o3or0c7eVoL0d7OdrL0V7uKrQ2uRbBEngQHrI20a9y+lVOv8rpVzn9 Kqdf5fSrnH6Vi2vxgA8P+OjbUTzgo39niaAzRNAZ+vk5PamhJzW2W8+fsU0+H2J1ScQzA1hdEvHO gNh7/B1E1xmi6wy9q6F3NfSuht7V0LsaeleDZ3x4xodnfHjGh2d8eMaHZ3x4xodnfHjGh2d8eMaH Z3x4xodnfHjGh2d8eMaHZ3x4xodnfHjGh2d8eMaHZ3x4xodnfHjGh2d8eMaHBWqwQA0WqMECNVig BgvUYIEaLFCDZ3ziOqzgxQpefLELK3jxxy59jLgU9Xmoz4t93vpY7P10H6zQAStcjRU6YIWrY58S /xhf7cJXu/DVLny1C2vkYY08rJGHNfKwRh7WyMMaXqzhxRperOHFGl6s4cUaXqzhxRperOHFGl6s 4cUaXqzhxRperOHFGl6s4cUaXqzhxRperOHFGl6s4cUaXqzhxRperOHFGl6s4cUaeVgjD2vkYY08 rJGHNfKwRh7WyMMaXuEgFs6g2IPiJ1G8EMUpKFyOwgdEGjbagX12YJtqbFONHVKwQQq5T6N/B/p3 oH8H+negvxr91eivRn81+qvRX00/qulHNf2oph/V9KOaflTTj2r6Uc1Y8VmvXjDfnRFX6jcxx00G H/PcTOa4+2AW0DY9Ptw81y1jzlhh7XYvsU64l8IyWA4rwA8PwkoogmJ4CFYBc6ObudHN3OhmbnQz N7qZG93MjW7mRjdzo5u50c286GZedDMvupkX3cyLbuZFN/Oim3kxyQkucDPnyZn9hOp7iDFezxiv Z4zXYzf5Pr0nuQcYu/WM3XrGbj1jt56xW0/fQ/Q9RN9D9D1E30P0PUTfQ/Q9RN9D9D1E30P0PUTf Q/Q9RN9D9D1E30P0PUTfQ/Q9RN9D9D1E30P0PUTfQ/Q9RN9D9D1E30P0PUTfQ/Q9RN/lnDXZ+hRr 78HC7zXPWVLR5+IqFJWRX0f+WbzRiDca8UYjZT+nrElZNyPFhdL+jBQXavvHPgOqwEONeKgRlWWo LENlGSrLUFmGyjJUlqGyDJVlqCxDZRkqy1BZhsoyVJahsgyVZagsQ2UZKstQWYbKMlSWobIMlWWo LENlGSrLUFmGyjJUlqGyDJVl4gcoKcI3O/HNTt0nuuCfnSiYxgj4JyMgjJJilHSMfTLTUX4yg5Jf yE+z8N1OfLcT3+3Edzvx3U5UFaGqCFVFqCpCVRGqilBVhKoiVBWhqghVRagqQlURqopQVYSqIlQV oaoIVUWoKkJVEaqKUFWEqiJUFaGqCFVFqCpCVRGqilBVhKoiVBUxjiercTwEFR/G/p/TaHr9NL3e Itzo3YvevWjdi672aGpPzs/Rsxc9e9GzFz170bNXGPoC/LrQ+qf+gHVcLyYufmad1H8uP2nn7jm9 2AoLjeM/RW9KhPVCImIRFFtV+iph6g9Te7X1pb5G/ual9S/9Wetfbva3bva37kvhMugK6ZAB3WA6 Ze6GGXAP3As+mAn3wSy4H2bDT6EA5sBcmAfzYQEshAegEBbBYutfSs85enpUX2Z9gZZj+jPWKZ13 emKKPpdonwcLuFuIykWwwtqv++FBWAnFor2+ytqsP0G5Uuuw/iQ8BU/DWusd9L3j1q09bhvYIQEM cIAJTnCBGzyQCEnQBpKhLaTAJdAO2kMH6AipkAadoLN1EhuexIYnseFJbHgSG57Ehiex4Un3UGu/ exhkwXAYASMhG66FUXAd5MD1MBpugDEwFqaj426YAffAveCDmXAfzIL7YTb8FApgDsyFeTAfFsBC eAAKYREstt4RdiLnM6z4MVY8oq+x/k4sFVuniZOzIh8vRPBCBA+cwwMywo6w4oRZccKUCGPlCFaO sMKEWWHCrDBhVpgwK0yYFSaM9SNYP4L1I1g/gvUjWD+C9SNYP4L1I1g/gvUjWD+C9SNYP4L1I1g/ gvUjWD+C9SNYP4L1I1g/gvUjWD+C9SNY/xzWP4f1z2H9c1j/HNY/h/XPYf1zrHJhVrkwq1yYVS7M KhdmlQuzyoVZ5cJYN4J1I1g3gnUjWDeCdSNYN4J1I1g3gnUjWDeCdSNYN4J1I1g3gnUjWDeCdSNY N4J1I1g3gnUjWDfCmFtIdMuxuAybLie6i0US1j6Kteuw9ilRgI0D2DhApH9JyZ3Y+ii2Pqov5nqZ 9RW1ThP5QSI/SOQHifwgfvg3fgjghwB++Lv+uPU+I+ATRsAnjIBPGAGfMJb2MDdU4KMqfFSFjwL4 KICPAvgogI8C+CiAjwL4KICPAvgogI8C+CiAjwL4KICPAvgogI8C+CiAjwL4KICPAvgogI8C+CiA jwL4KICPAvgogI8C+CiAjwL46Cg+OoqPjuKjo/joKD46io+O4qOjjJAgIyTICAkyQoKMkCAjJMgI CTJCgoyQICMkyAgJMkKCjJAgIyTICAkyQoL4OICPA/g4gI8D+DiAjwP4OICPA/i4Ch9X4eMqfFyF j6vwcRU+rsLHVfi4Ch9X4eMqfFyFj6vwcRU+rsLHVfi4Ch9X4eMqfFyFj6vwcRU+rhI+PFiPB+vx 4D/w9za8eArPHcRzX+O5k3juJJ47iedO4n8P/t+C94J4L6g/xr2f4ekn/hdxdx5fdX3ne/yXc5KT cHLiLq6tdW2t01rr0ql2mXYYx05HW7tY207tzKi1UGlFRUVEoXWpK+6igktFClqWmqKi4IpFY4MJ OcDhJJAIxCSHkx9JyAYo3/s8Ke21c+993PvPvfeP1+N31t/3+31/9hhDmM+CnSzYyYKdLNjJgt0s 2MtPlrFiKyu2smKRFYusWGTFIisWWbHIiu2s2M6K7azYzortrNjOiu2s2M6K7azYzortrNjOiu2s 2M6K7azYzortrNjOiu2s2M6K7azYzortrNjOiu2sFLNSzEoxK8WsFLNSzEoxK8WsFLNSzEoxK8Ws FLNSzEoxK8WsVGSlIisVWanISkVWKrJSkZWKrNTKSq2s1MpKrazUykqtrNTKSq2s1MpKrazUykqt rNTKSq2s1MpKrazUykqtrNTKSq2s1MpKrazUGn2GlQZZaXAkGv9shX5W6GWFXhYYZIHS3NRL3V7q 9lK3l7q91O2l7iB1B6k7SN1B6g5Sd5C6g9QdpO4gdQepO0jdQeoOUneQuoPUHaTuIHUHqTtI3UHq DlJ3kLqD1B2k7iB1eqnTS51e6vRSp5c6vdTppU5v9EmZ4X2Z4X3RX1TP04lbneI2pxjZvcf3Y4Z6 /6C6fYiu7lB8BB/FYfgYDscRuMBnLsRPcBF+Ch0krYdoPUTrIVoP0XqI1kO0HqL1EK2HaD1E6yFa D9F6iNZDtB6i9RCth6Kf0rqT1p12XLTjoigoiIKCKCiIgsKI/n+JALr/D56vg0+UfrLxv/b2Tvbo ZI9O9uhkj0726GSPTvboZI9O9uhkj0726GSPTvboZI9O9uhkj0726GSPTvboZI9O9uhkj0726GSP TgoWKVikYJGCRQoWKVikYJGCRdFQEA0F0VAQDQXRUBANBdFQEA0F0VAQDQXRUBANBdFQEA0F0VAQ DYX/g2gosFCBhQosVGChAgsVWKjAQgUWKrBQgYUKLFRgoQILFViowEIFFiqwUIGFCixUYKECCxVY qDBS43tG/ivkKWxVZKuibFOUbdppX6R9SeMijYs0LtK4SOMijYs0LtK4SOMijYs0LtK4SOMijYs0 LtK4SOMijYs0LtK4SOMijYs0LtK4SOPSGYvOWHTGojMWnbHojEVnLDpj0RmLzlh0xqIzFp2x6IxF Zyw6Y7G65AsTcQWuBH9zxqIzFqO95OKBv40ZnnbrSKQPyqmD/7sY0btfoUc1mYq2jGhLibZ3Rdr+ Ii0dnfXXjDJRNZ6Ca83l11vr5tDDs3t8elhs9qjO/b71aQoPUrj/Q11TD+/u4d09vLuHd/fw7p7/ R9mmh/f18L4e3tfD+3p4Xw/v6+F9Pf9Xu6LStDJMqRV/nVv6o+Tu14ZZaWf0XdrW0baO/brZr5u2 pckmzxIV9O2gb8dI/pvu+b1mhPt0SjO89mDooGsHXTvo2kHXDrp20LWDrnV0raNrHV3r6FpH1zq6 1tG1jq51dK2jax1d6+haR9c6utbRtY6udXSto2sdXevoWkfXOrrW0bWOrnV8qptPdfOpbj7Vzae6 +VQ3n+rmU91076B7B9076N5B9w66d9C9g+4ddO+gewfdO+jeQfcOunfQvYPuHXTvoHsH3Tvo3kH3 Drp30L2D7h3VpXNOxBW4EldhEq4OHSMab98dCcPRvonF0ejEqzrO1/jl62FqYkWYm9imzxgI0xPb Q0NS5kx+yvR6fFiYPCm0//W3lc+J9kp+b+Rf8yj9TmFnpjmsZLHZ7rsAr4mA10M2sZynv4EV1nzT 9e3QnFhp0s1abbXrGnRGoxJdInVAjzuoExrCjtCbjEJbshJVOMj0f3zYlDwhbEt+Fifi5DCYPC1s zPx7KGYuDPWZn0GOyPzC9ZLQnJkAOSEz2XWK67XQQ2d+BRUzcztEZWa69+/xmtyXecDzGZjpHrPD 9sw891+IRWFb5vd4xmu1ni9xdaZMg9casQprPc+h2eMWtPlcd2jLbMNQaKvZL8Q1+2M0TIc1psOa o7w+LtTX6Olr7KvmptBfc3vYVnMfHsQTIY7+ZbeqeXYapupaqnZTtZuq71N1M1VzVF1L1W1UXUvV tdQcpGYfNfso2UfJPkr2UXE7FQeoOEDFAQp2UzBPwbUUXEvBPAXXUjBHwRwF8xTM/RcF8xTspmA3 BbspmKNgnoJ5CnZTsJuCa6nXTb1u6g1Qb4By3RQboNgAxQYoNUCpAUp1U6qPUn2U6qNUH6X6KNVH qT5K9VGqj1JrdyuVp1Q3pQYoNUCpAUr1RUckngqTE4vDIkq9xAd3UmgOVbYkNoSL+NnERFd4lHef k+jXaW8PX+Jnf0wmw/JkKtyRzISf8/bVyf3C4cnDop8kjw6X8/wjkp8OX6XaE7z/dD73cPJL4drk V8IPd/92Vmvye+Gx5LlhXHJsWFb6/SWnekFOelWVeB0rwnorvsceG6zYboUud+1xx43uuFUsnSaW vmgifIrFXg2NvlWKlz+NxEhn9FHfXuWbb/nmZntrt7dqd8iOxMNJIeubr4a3fOs933rWN/b1jXet 1zoSv6bqkRg+TJx+yvPjwwbfarPL5dFHeNa2kW8u51lv4E0e87Zvr+RVWV3katc1YTPv2Mw7NvOM zTzjXZ7xLq94l1ds4xXbeMU2HjHMI4Z5xDCPeJcnDPOEYZ6wmeU2s9w2Vitl/s5oD/tJ2fls6z1l 3eeddQneDDvo2kLP9sxVYdD9+9y/z/37Mg96/kgYdJ++qNy3+u38Ut/YWPJ7nfBTcsliZ3k9NHi1 OdEoj5Q03BAKdGt037XuuzY616rTfXqqmNo04i3PhylWn+KbvZTYQYkd7rCJEoES/bvjqp8S/Ylc WOCOtTypIVHkPWnsFy5MjmaNA3AgjgyXJY/C0WFL8hPsfCw+xXp0T37Z+18Z+d3lE+zmBLG3ibr9 1O0Xe5so3E/hQOEg9jZRYQqlAyWmU2I6JaaLv03U3kHtHdTeQe0g/jaJv01U30H1HdSaQvl+ik3J zJeJFuDFcFlmueufUI+VWIc81nuv1fVd99gYLquJwh9rKsKCmhQqcbjnx2CcDDUtTBeDm1hzR839 YWPNA5iBhzArLIiqeWQfb9zI0ifKPh/IPh/IPh+w+udE+gci/QOR/oGo/iA6lD1KthykfQ/te3wr JUf1ylG9clSvs/c7e7+z9zt3j3P3OHePs/Y4a4/80iu/9MotvXJLr9zSy7975ZZee+23zx65oleu 6JUresvSVpzGA+5n/VdY/27WvzuxjEVfwqthRWK5qvgGVoQneMHOxCqvZ/lWLkxMrAtLE3k0owXr sSHclGh13YhN7rnZtR0d6Iym8ZbaRMHjLSjyvG7XGFvDZYke9Hrch21hrNzUIHPnZO6cCD5HjlqZ 2Om99/FBWJbY5RpU4TIkUMpf5bytwuOUPJUOU5PVHmfC+JF8tqfrXtgb+2C/cBpvPYO3nsFbz1Bb b0weHK5MHuK9Q3FY9P3k4a5H4Eg57ygcHf4teYznH8cnPD8Wn/T47/Cp8I9y5H/ILPNZbRqrTWO1 abz9TPny9uQpPvM5/H34ZfLzrqfitHBd8guuX8SXwo9ExRnJf/D4K+FSkXHO7t+YnS9Crkz+IDow eR7Ghnfk199lxoaGzDhcEnaKkp0i5G4RspOXTOMl03jJtMw07/8Sv8bNuAW3RaMzt+MOTPf5+7x2 Px7wfAYedJ+HPX/E9dEwPvM4nsDscGPmyXClanZd5inPn8bvMD+cLqpOV+Gu44HTeOA0/cGNqtx1 mT+EX2YW41mfW+K1F31uqcfL8JLXl3u+wutvum+d197Gn7xWj5VocK9GrEKTz6/12RzWeS8P2Zt3 TxO1p2c2hKUi93RV9DrRe4boPT2zyWt8MMMHM++BH2Y60RVeyfDDDD/MFMEHM1vRg14ZoA+DHg+H ZZnt2OHxB+BzGT4nK0yt4Xc1/K4mGZbVlLtWhImyxERZYmJNleejZI80+GBNJrxSU4M9PN4Te3l9 b+yDfb2+X8ip9DmVPldzgPsd6DMH4WAcgkPxEZ89zPsfw+HWP8JrMqxsNLXmutAgwqfV3BSNrmHr GrauYeuaW3EbbvfePeFKkT9NpjpdpjpdpjpdFpgmW51e87D7zLLvR93zCfef7fmTmIPfhsuiw2WJ S2WJ349U5tdG6vkbMkGHiJ8usn8ksheL2oWi9i01d0DEvixiN4nKRtFYJwqXicImUfdPIus8kbRQ xNwuYt4QMR2i5D5R0iQKXuL9T/L+b/D+V3h/6f9UOIXHvxP9p3w1z05+p2KtSixUpRbLCc97bQle U+de997ysEb2XKNyvSJndatci9XAbrvtUr0Wq16L5a/Zdv6GPNVl5yvlouV2nZNvNso3G+28Q77O 2vlWOTsrZ2flk+V2P18umC8XzLfLnXb5rVLPo3qtyvyHTHthWKyCLVbBVqlgi8Vmt9jsVsFWic95 4rNbfM4Tn/PE5zwVbFXmet+7AbfitrBGVl8jq68Rm92q2SrVbJUMv0aGXyM256lmi8XmPLE0n9/P 5+fz+XSXepJVT7L8tktNyfLVLn66nF/O5pez+eVsvtjF1zbytY18bSPf6uJbXfxqI7/ayK+Wq0VZ PrVchVvMp+apcKtUjjX8Yzb/6OIfG3WQy/jBS3hVh7YiPE/pzapDI1/4qmzeIpu38Ie3qdpG1Qaq NvCJ52TuDZR9U6ZuoeyblH2Tb2zhG+/Jxk2ycZNs3MRH/o6PDMmyeVk2z1fW8ZN2mbVeZq2XWev5 zGrZdJ0smpM5m2TERhmxkeqbqb6Z2ptlwEYZsFEGbJQBG2XARspulvUaZb1Gma5RRsvJYnlZLC+L 5WSxelmsXgbLyWDrZLB1stU62SovO+Vlp7zslJed6mWnetmpXnZaJyvlZaX87qxULxvlZaOcbNTE Om/KLC0ySwsrvclCb8ouG2SXDTLIBtmiRbZokRlaZIYWmaGFpRpYqoGlGmSFDTJAC0s1sFSDyG9h qTdFfqOIbxTxjSK+UcQ3ivhGEV8v2utFe16050V7XrTXi/a8aG9hxQZR3iLKW0R5iyhvMRN36o5L ffVJ4f3oZFFWmrN+JqJmiKgZIuo1dp4qaraz6xx2rWXXWtFSYNdN7LqATRew6QIRMSwKhtliKltM FQHD7DGVxw/z8hm8fAYvn8EWU3n5MC8f5uUzePkM3rydXgvotIA3b6fVAlptotUmXr2dXpt48nb6 1NKnlj619NnEm7fz5u00qqVRLX0W8N5h3juD52535lpnfD3czmOHnGCZZ9vsfSA8xTc3RAc72TbP 2p2sy8m6nKzHqerlgYKT1TtZvd1ts7t6u6u3u212V29X2+xomx112VGXHXXZzTa72WY3XXbTZTf1 dlGaZbuiw6w0YKV1Vmq3UruVOmlYmlEbrNZvtQarNVhtwGoNVmuw2oDVGmjRR4s+qw7Qos/KA1Zu t3K7ldtp0Wf1AasPWL3d6u1Wb7B6aT5sNyNskC+3hXec+h0r91uxRS5bIuOulXFL88FzIxk35VP9 u2eowu7/h+n45LnRZ0eUa/NOi3faRp6VZrudIzpW7P5Wn2dF91/j/r264ZyetkjhHc6ZpkSECj1p CpU43PNjMCv0uMeGEcs0+nSzKlLaY390jHu84Z3n6dfnXi/4xHt/me9H6k0kv1SiCunwglOd7TTn 07GPjhvouIGOpfl6A/367OEFe3jDHt6whzdo+bdz9yE49EPz9+E+f5RYPMZ1ls8/6rXSzF3mzHF0 gP312lOvPW2xpy27f4Kz1e677GurfW21j632sdUetlq719q91u617hbrbrHuFuttsd4Wa221Tq81 tkRHufuLTv9HJ3/zQ1k2S+f5Vhocyarpkd8UuWG3Ldc5/djSb/T8Jfs48ZtWfdGqL1r1xf9p5ill msN9rpRljnEtZYxZPvtfM8aokSq6TR+w3WydYtfvhkt2/3bHO1b+/shvjH7Wvjf45HOsVm8uWGP/ L1Np4YcySKky5Cg1i61Ldfc9as2i1iznedldb3W3BaxYr3dbQ8FZFJzFkvVUnCUiciIix6L1zvey qMg54wZn3OCMG1i1Xg+2Rg+2Rr+15r9kjhwr17Ny/V8zx+HucVSY5ewvO/cGVq4fyR6HUL2Z6s0j P40YkEW2h9ftupvyzXbcbceln+F0U7uZ2s122W2H3VRupnIzlZup3EzlZio3U7jZSt0UbqZuM3Wb qdtM3WZRNSDr7lD9eA8PGwgvRwlVcIdOaXuU1I2s8KzXs47ocM9iM8yw/iTWn8Qq5ZBKOaRSDu3+ GWFBz9Kjjx9W8QoqXUGlG1LphvTrw6pdQY8+rK+I9eTDqtuQ6jakug3pu4f13cMq25DKNqTviFW2 gt4jVmmGVJoh1WUoGqWWb7eTmWp3rGaX+rr3rBqz4BMs+MRIVhml2vcn95NJPhWKTtDlU8XkydGe MoyZJzrBOrmo3H02u0/pZ67DpRM4cWbkJwiF0ucpsZ94OjkMe730U1mf8L2N0f6elU7f7/T9Tt8/ cvIf6BXOC6s/dPJ+J+8fOXWDayNWoRktcDon63eyfifrjz5mtZX0HaDvWvqu/fBkbu2iVdppO2CF diu0/3Uaf2bkJ37ttB2g7VraDvzNhL7W89zITwFHJnXarrV6O23Xfnhaj8qcfCA6Klnj0X7hUd1S rFuKdUuxPT1rT89Sa0DH1KVjKv10rZtOW3RGMQu8zwJPs8DT5sh9zJGl344sdT1dup4u+3pWd9Ol u+nS3XTpbrp0M126mS77eVYn06WLie3pWR1Fl46iS0fRpZvoiirt5vdW3mbFYStus9p2q71ttbej I737Lt067HGdPa7zycHdP8P+7xY6WWd3Gr/+Ch1mhw4a7qDhjr9a6Rmv1Xq+xPVFndYK1w9bba3n OfzFeut9ps3nN4Z1f2PF0VRro1ob1doo1UapNvtu3f0zqTaKtFGkjRpt1GijRhs12qjRRo02SrRR oo0KbVRoo0IbFdqig51zvTOud8b1zrjVGbPO2OSMTc7YpFMteV2T8zTpKgu6yoKzrNdZljywyVma nKVJJ1lwjibnaHKO9c6w3hmanKHJGZpG/i/KI5M/jo6MZkQXhAejC/ETXBYei64Od0WTcQ2m4Fps CjOizWhHn89sD3dGO7AT7+ODUPqX4xvKjsUncRz+Dp/Cp3E8PoMT8FmciJNwMk7B5/D3+DxOxWn4 Ar6IL+HL+Ad8BV/FP2IM/gmn459xBr6Gf8HX8a84E2fhGxgbHVD2Sni57NXwXNlreB3L8QZWhGVl b+It1OHtsKz80XBX+WN4HPWer8Q7cNbyXQjhzoq9woMV+4QZFbrsCl12hS674gAciIPQFu6qKPpM N3rCXaljcQouDg+mxuPn+AUmhsdSV4DuqemhIdUQlqVMPJXHhGWVH8cnwnOVx+KzONHzL+AHYUbl D3FeuLPyAcxGm+fvYiPYrLIrPFZZwFbv9Xs+GO6sSoSGqiTKUYEUdIpVOsWqUUijGhnUYA/sib2w N/bBvvh8WFZ1Kn7s8U9cp7r+1nVueK5qIDSMcq9R++qPfxTtE1ZG+0L2i/bHaByAj+MTOBafxHH4 Ov4VZ+IsfAPfxNn4Fr6Nc/B9XBBm8tyZPHcmz702ujzMiibiClyJq3B1mMub5/Lmubx5Lm+eW35L WFl+K27D7bgD03En7sLduAf34j7cj0d97zE8Huay+syKtWFlRQvWoxVtXn/PtQNF73ejx2sfhJWp FCoxCmkciINwNI4BHVJ04B1zUye5nuJ6mus/40c4Dz/Gv+PiMJPnzOQ5M3nOTJ5zLc+5NuW8Kefl QXOrflHSJrorNER34x7ci/twP+bgt5iLeXgKdXgbf0I9VuIdNKARq9CELFYjh03hGTnhGTnhGTnh rWgb+jGAQQxhe1goTyyUJxbKEwvliYXlnaGhvAsFbEERppPyGFvRg170wcRS3o/S93YhhIXi7ZlK uaBS7FeK9UqxXinOK88Kb1V+x/W7+IHP/BDnhYWVP/P8ckzElbgK1+BG3ATxVkmjShpV0qiSRuJp YeVvXGe7LnR9EXSopEMlHSrpINaeEWvPiLVnxNozYu0tsfZW5RYUsdV3+71OD3G3sOzTUXm0d1SB VOkf2ij94wMYhdJf765GZuTfOtw72gOnRqOj03BBmMzHJ/PxyXx8Ih8fx8fH8fFxfHwcHx8XTXKH q8N4fj6en4/n5+P5+fjoV9Ge0fW4ATfiJvwaN+MW3IrbsCT6aPQCNoWrWfRqFr2aRe9l0bksOpdF 57LoXBadG5X+gvT2MIVVp7DqFFadwqpTyh4Kq8sexkw8gkfxGB7Hb/AEZuNJzMFvMRfz8BSexu8w HwuwEIvwezyDWvwhrE58JtozcUI0OnGS65dxRpic+Fq4LPF1nO352DAtMS5cnPgZLg4X69m+nvxh uFzf9vXkj10vD3XJiaEx2RBVJBuj/ZJNut7VpvI1UTq5KcxNbtaLtEefSL7n2lH620CuW6J9yi+P 9i6fiCtwJa7CJFyNybgGU3AtrsOjYbx8MV6+GF++KtqzvAlZrMYarEUO65BHM1qwHvTk7VN4+xS5 ZnLF3mE1r79ajhlfsSVKyy+T5ZfJ8sv4ip3R3qkk+FZqH+yLI3FsGJ/6pOsJODEaLaeMT33O44vD ZPljsvwxWf6YLH9MlD8myh/j5I9xKb6Uuhp8KfVgWJ16aOT/oF9d+RF8FIfhYzgBZ4W5Iu1qkXa1 SJtSOSHas/JSTMU03IUHvP6o6+PRR0XTlMqnPW7z+XexEXxO5Nwrcu4VOXNFztzK7mhUZYytPt/v ff4ngqZUDkV7Vu0XVlftj9E4AAfiIByMQ3Ao7LXKXqvstcpeqw7HETgSR+FonO9eF+BCTPH8WlwX Vo8qC6vT54bL0j/AlHBx+jqIm7S4SYubtLhJi5u0uEnfjjswHXfCedN34x7ci/twPx7ADDyIh/Aw ZmIWHgF90o/hcfwGT2B2tGf1ZFyDKbgW14G21bSt/iXEd7X4rhbf1eK72j6r7bPaPqvts9o+q+2z 2j6r7bPaPqvts9oeq+2x2h6r7bHaHqvtsdoeq+0xc1y05x6jkEZ16V/mTb4jUjbJRqVHpb89ckDi StksM/KvC6RQiSqMQhrVyIz8BfuMbJbRAeR1AHkdQF4HkNcB5HUAeR1AXgeQ1wHkdQB5HUBe5ttX 5ttXJ1DQCRR0AgWdQEEnUNAJFHQCBZ1AQSdQ0AkUdAIFWfIiWfIiWfKi6KchjsZiHH6GizEeP8cv cAkm4FJcFsbKqJfIqJfIqJfIqJfIqJfIpmNk0zGy6RjZdIxsOkY2Tcumadk0LZumZdO0bJqWTdOy aVo2TcumaXW3Rd1tUXdb1N0WdbdF3W1Rd1ui0s875mIensKS6CCZ9yD1N1Z/Y/U3Vn9j9TdWf2P1 N1Z/Y/U3Vn9j9TdWf2P1N5atJ8jWE2TrCVGHWbYTXShgC4roRoyt6EEv+sIDMvscmX2OzD5HZp8j s8+R1SfJ6pNk9Umy+iRZfZKePqenz+npc3r6nJ4+p6fP6elzevqcnj6np8/p6XN6+pyePqenz+np c3r6nJ4+p6fP6elzevqcnj6np8/p6XN6+pyePqenz+npc3r6nJ4+p6fP6elzevqcnj6np8/p6XN6 +pyePqenz+npc3r6XNk3o9FlZ+Nb+Da+g4dCViXKqkRZlSirEmVVoqxKlFWJsipRViXKqkRZlSir EmVVoqxKlFWJsipRViXKqkRZlSirEmVVoqxKlFWJsipRViXKmiVqzRJLzRJLzRJLzRJLzRJLzRK1 Zolas0StWaLWLFFb9qcoXVaPlXgnSqtiGVUso4plEqeW/h9V1390PSNcp5qdpZqdNVLNfhiKiQsw VnX7UFVLjA9Fle2LKts4le2LKts4s/j05GVhfvLF8FrypWiP5Kuq3zvm+UZzelN0gCpXUOWSybXm +z9XugqV7qiRvzFZ8PoWlefyKKPKZVS5jCqXUeUyqlxGlcuochlVLqPKZVS5jCqX0UkXdNIFnXRB J13QSRd00gWddEEnXdBJF3TSBZ10QSdd0EkXyh8IcfkMPIiH8DBmYhYewaNhjMo5RuUcY+6qNXfV mrtqVdG0KppWRdOqaFoVTauiaVU0rYqmVdG0KppWRdOqaFqfGeszY31mrM+M9ZmxPjPWZ8b6zFif GeszY31mrM+M9Zlx+UAolg9iCMPYjh3YifchJlTmSSrzJJX5IpU5qzJPMP/lzH8581/O/Jcz/+XM fzlTQt6UkDclFEwJeRV8TMXmEJsU8iaFvEp+kUp+UYU9VdiTij5GRc+YGvIVuzwPIU5FKEMCySij 0mdMFHkTRd5EkTdR5FX+jMqfMVnkTRb51KE++xEc6bWjPT8Gcq0pI68zGKMzyKQ+430+qDvY19SR 1yGM0SFkTB55k0fe5JE3eeRNHnmTR17ncJHO4SKdw0U6h4tS8mhKHk3Jo6nLcDkmhrG6ibG6iUt0 E5foIsaYZ3M6iaxOIpt6ZOQvMo1OLcIfRv4q0+jUG64NoVaXkU2xpbk3lxqKRus4sjqOrI4jq+PI moVrzcK1ZuGlZuGlOpCseXipebi28rQobSauNRfE5oLYXBCbC2JzQYsuZY65IDYXxLqVCbqVCZX/ FoqVP8J5YZL5IK682GMxVflz/AKXYIJ7XgrnMju0mB1is0Nsdoh1OGkdTtoMEZsh4spbfP7Wkb8q GOt60uaJ2DwRmydi80SsC5qkC0rrgg4yV8Q6oUk6obTZIjZbxGaL2GwRmy1is0WsQ5qgQ5qgQ5qg Q5pQudm92/Ee5PpKuV7X9ICu6QFd0xxd0xzd0iTd0gTd0hzd0iTdUtqsnzPr58z6ObN+zqyfM+vn zPo5s37OrJ8z6+fM+jmzfs6snzPr58z6ObN+zqyfM+vndF1ZXVdW15XVdWV1XVldV1bXldV1ZXVd WV1XVteV1XVldV1ZXVdW15XVdWV1XVldV7bqs/Z0Ij4faqtOxY/d+3zPL8CF+InXLnL9KcZiHH4R Cjq0rA4tq0PLVk31nele/63Pzg1Lq+Z5/BQGQm5UFI3WwWVHOduofUPtqP2jdPrbYVP6OzgH54az dHZnpf/N46tCMT0Jk/GXTm+axzfgpiij48vo+DI6voyOL6Pjy+j4Mjq+jI4vo+PL6PgyOr6Mji+j 48vo+DI6voyOL6Pjy+j4Mjq+jI4vo+PL6PgyOr6Mji+j48vo+DI6voyOL6Pjy/x/7Pgyf9Px7R/d Eb5Qdl50Ztm/R98u+4/oqrL/jP6p7PzoC2UXRN9LnBGdmxgbnZP8bvhq8tzwleQLYU7ypXBmcmN4 S2+4X1KGS74X7kp2hhXJruiQZMG8tSUMRodFd+x6PXo6rIqWh1Xu/qXdfw32FHc/zt2Pc/d/KBsb BtXWdquY5kxl3w2nWuWLVpmYXBpeTC7DS7uKyVfCYjVubfK18Eby9XCH1a+38nCyPXRY/VSrT7d6 0uqPWP31qCq5MsxONtiTST65KpyfbApLklnfWhOaVcX1+tSnwx/t7Y8++X21c6VPP+DTk5Ordu3y 6cd9+mvq6GLfuNI3Hhr5247H2+0U1fwjqvfXEmeq5GPD2MTPo2TiKX3y6+E/EyvCjMSG6OTEgIq8 X7Rn8vjwZHJplFGlj3eC31tphXk0mVxl1lwd/qBKV7j7LifKqtSTd1fq5O6ZNOlkHckupyp4fUvo LvteVB6WRBVIoRJVGIU0qpFBDfbAnuHFaC+cGpqj0/CrsCi6HjfgRtyEX+Nm3IJbcRvuoOGS0Bi9 EBrLEqG5LIlyVCCFSlRhFNKoRg32wt7YB/tiP+yP0TgAB+IgfBSH4WM4HEfgSByFo3EMPo5vhvVl Z+Nb+Da+gym4FtdhKqbhl/gVrscNuBE34de4M6wruwt34x7ci/twPx4I6xKfCYsSJ+HLODs8n7g5 5BO3hDwv/y6rFPnZ+3xsEUsU+dg3+Nj7ycFdnckhETEcKpPbdw0ld+xqTu4MqeT7uzqSH4QvJ3d5 PYSDyit2dZanwlfLK0NledWuofJRu5rL0yFVXr2rozwTvlxe4/U9fO7ysKR8Iq7AlbgKk3A1JuMa TMG1uA6/Cc3lT2A2nsQc/BZzMQ9P4Wn8DvOxAAuxCL/HM6jFH7AYz4f15UvwAl7EUizDS3gZr+BV vIbXsRyrwqLyJmSxGmuwFjmsQx7NaMH6sKhiZ1iSSoL/pirCi6l9XPfFkfgkTsCJoTn1OdfbwvrU /ZjhuXOmnvTYeVLOk3KelPOkFnptEZ5BLZ7DEq+/gBexFPaesvdUncdv408e12Ml3sEarA3rUnnv dWALetGHbejHAIbC+so9sCf2wt44MKyrPAgH4xAcipNCc+XnMCEsqrwUUzENd+FRPB4aK592HQqL qj4e1lcdF5qrPu36Gdez8A2Pvx/WVZ3v/QtwIW72+gyvP4iH8DCexs6wblQU1o/a21V8jRJXow7G oaE5fX7Ip8fhYvwcl+ByiPe0eE+L97R4T4v3tHhP3447MB13wn7Td+Me3Iv7cD8ewAw8iIfwMGZi Fh6BM6Yfw+P4DZ7A7LCo+l9Cvvrr+FecibPwDXwTZ2NyeL76GkzBtbgOUzENv8SvcD1uwI24Cb/G zbgFt+I23I47MB134m7cg3txH+7HA5iBB8PzmePCoj1Ghef3SKM6PB+VqxWLZP5CcnX0aXn5/ei+ 6OrwcDQZ12AKrsX2kDc/583PefNz3vycNz/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pz c2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY/Bybn2Pzc2x+js3Psfk5Nj/H5ufY /Bybn2Pzc2x+js3Psfk5Lv0VrrI/2ueKUDSzFs2sRTNr0cxaNIfOMIfOMHc2mTubzJ1Nidmhc+T3 I//8W0fvJobCu6pZThV7OPlOdJh62aaC3WaGe9gM97AZ7mEzXNEMVzTDleanvPkpb37Km5liM1Ns ZorNTLGZKTYzxWak/0bdlcBHUWT9V8d09cz0JCGEEMIVbryBRVQ8goq6Coiu4sGtoniAulwicnis ioiCqIALCgrqKi66HqCg4IWKB4icBrkSIAHChCOcCanvXzWTmJBADljdr/tXPdV1vq569a/3qrrf TIEeNAV6yhToJFOgQ0yBDhGGjpAN3SAMPSAbekC2OlWnqdOsPc5syP5Glk+DnJ0G2ToNsnAaZOA0 yL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyL9hyKvZ kFezIa+GIaNmu4NR9sPwv2mspukw5M0w5M1sfwLG0016MmTMyZApl0OmXO6N0FneSLhROiuUoDeF asAlwtWHS4F7BOEz9CbimFXewbwOOU7Mo/PEfOohFlJr8TkloX3nii8hSX1FzcQSuhptfTX0eh8k houg28eLFdQK7b4BkkM9yDnpCM2gUyEvXA15oanIostR7pfRtezTUNMXehbSP2/rfA9xd0OqmE8x CFuMu6XGLmVpW7rsLkot254u6GmJ0XEBau2I+fBK0BAJaYnZ8gBCL8FsOR+z5XZro3iH+TdKhNbB 3UV2TbEm0jYBDea/CLbSGUhxJu6WUiqeMAFx9fCsxurbTfonMYjagv4v5YWQ1zhCvsPdD0iNuQky YQ7u1uGuH4Vwdxh331EzkpRKPjgHTsG5cH64AFwQzoMLwcWgxi5UQ3SFjNcTrh+eaT7kwM8hZ36h l8lBlCoHww2BewBuKNyDcMPgHoIbDjcCbiTcKEqFLp8KnT0VOnsqdPRU6Oip0MlToX+nQvdOhb6d av//IgTpNhc1rcNTbBUL0ZPm30y+0HMg3e7Asw9Cm8wDXZ8hFZ4Wzx6iePYzNWLLqAVapifa4VLR Fam6UTfR09qY6yb66S+MVSIxRKeLidRGTKJzUE8YPd0EksxseR61km2pBVqrG9VDjnqopzV6cxCl oKadpn5bUyj6vybfiu7I3QPpe+P3FvwOAof9rH+FjJwN+fiQ5Z9V5CKXIMf8EwpSJyJlIlL6kTKM FDmUSBlAUchQtAVy0wDUZPp0iF4OuTsbvR4LxF1my1uBHlyJXCjTSMS+eJ0PHT4fOnw+dOR86Mj5 0JHzoSPnQ/fNR51ddJb54gklnoqRomxpK3Uu1SxRZ3dgVm+4/ni2QZDEl+rdoC4HzxEGx9VA3fuQ axHqDaLeg+XWG0S96ea/WVBaPOr1ocR9KDEbJeaiRD9K2x19inyMsy4INfYCu0OS7w03ADGDqBZy +kGxg5z7kTMfOUOgpcC0GnLmYVRk0BW0GW4L3CFw9mG4PLh8uCNAhy7QXG7SLUR3oEUP6iV64/cW /PaH7jMA9AzRM8Rw8MVEOhf8cAFa/GfU2Nb2zS/6ZVvbCr0KYy4BWs7hKI+0kihbFsBpauaLpytU V7hucD2pmZoENxNuI+43waXDgU6Vg7Bc/O4Hbcb+Yw4oO4RnPgTKTsVzHwJlp+K5k/HcBjFcPG8A z5opVlOc5bpPkeNL5NiMHMnIsRk5kpHjXKSOA81bLef9ovNA90Hk3GxzrbD/S9AV9XUDJ/fEby/8 DgYqplNDIF4OMCYAZKwFZKwGvPvU/qOO6b80pBIIyUE/dIHvJjs2jDW8RDEQXPUA5rutoDsLNW7T YctvG5FvM/IFULqLkjli0qgW9dG76Xa4O+AGove7oD+7gq6ecIPBmSZ1BrhkK1o6EzRtg365HaXs wDx5IdX0xendvmy4nXq30w+uP9y9cPfBDYYbgnJjov8JtAYlp6HkNDEQTzUYmJ+OfswAF23GCLJP CxzOQhtt0z9aXbwm6MsDfXmgLy/69GZNeT1KWY9SOEo5FTTGoZQDKKUApRhL8y5K2GT+jwj05YG+ PNCXB/ryQF8e6MsDfXl0BvWhjnQ73B1ww6g9PQQ3HG4E3EhqjxpjUePpwCwfWvhaYJYPrXwtMOtN tPT7aOnPwKffgk+vBJ92FG/r5/BMP2CGaBqhBvOWoSYL0sR51BY82lZeqNfIadReTod7ldr74qij byN+s/G7E24XtXdOgWsD1486Ov3h7oW7D87Q54Kq/VG+4VG+4bavTAtu05l2NWI26H4jmioxmioR dIeRspVdgdiml4Mz+hV8BV1wJ3S/jdD1dkK32yibF2wBr/UrCCM0ByE5srm+CKX2K1gv9qOd85A7 H9hwRC+RPn0AeuFBGdS5SLkEKS+3eb9A7DKELENIwOYNi8OoLw+tckSvhI5ZIP3kIG8BUq2ELlmA lKnApX4FW1FLAbTUXFCWLQ7hNw+15oMzIznzUWsBtNNcUJwtXfwGQEUQ4ZGS8vEE+8B1/aDXHiCG UnJQSgFK0Sghy9btEEPuHOQuQG6NnFlRGk4x7VQwHjSkI3cj5F6L3PvFYYxYQ30++PgIOK4AcoLW R0BLOkprhNLWorT90q9X2KcKop89ioOmvB0lHwFN/zazqOYo8SDoWCcKiCPXQdS9Tobgb64bmBQF S5EiE/WZlkpDikyUaVopDWXsQuse1V/o/Wg/IXc5/WPT2n5B2nL6A894gv0APK1k+wNlTnK74xmP 0d42psx2phiZQH5ZA/QlUUAmo7TayFMHMkNd+Oshrj7iGiKuMe6bIK4p4pphPpAyETXURmwKfpug TzyZgDvoELIm6k9GDbVRkymrHsLrI7wBwhsjvAnCUQ56waQ2NdeOpjA1mbLiQRdH7BaZiJCacElU D/TFI+UWlFkP9HHQx5Fri0xBfAO4hghvjDRNENYU/mbmX8lRyjrQap6Qy1qgNZl80VJM7nWg3zwh l40Q1xhxkdwcz5sAVwO8lwiak1BuMp6lNnq/Duqqa54L8fURn4L4hohvjLAmiG+K+GZ4PjwF+qYG yk1EaE24JL0KNBSgddJlHfRlXTxzPaSpjzQpiG8A1xBpGiFNY6RpijTNMLOZfvJsuyZRAugwLXYQ dCSAjiDo8GzbNsR9Y9uCB0FDAmgIml4hYZ89OdrOEepN6wn73JEcOVGqOcVWlScwasNov6P4AqP9 LApVljeQqwWpY/EHYptQ9ZPFIyjtdDx1FfkEuZtTtRPlFZRynnmik8Mv6InvbT9WiWfs3BCqLN9Y VG8u9hdsA5L2BuLUAap1EocLcoBql4n8gu1Anz5AtRSgWlvpK9gGRO0NNKoDVOsk/QU5QLXLZLBg O5CpD1AtBajWViYU7EeLnIEWOQUtcopMwn0tfTpaJAZUtUSrNEWrNJH1EF4f6VKQpgFcQ9w3QrrG SNcE6ZoiXTNwjR+amwedK1WY//X5iqpD2k2ApNsYUsW5kBUWQdqLtf8tNI/1pPNZb7qc3UJPs1vx exs09y56qrgBusiNeh4kj6n2n+pOOU6qRTaV+Q+k1Ta08O69ojsOTX4B+1y/Z33m3+3S4YuFlnwG EbWFTnoqXYyzBXWg66gl3UA3IvRmyHIX0J00lq6iZ+ltuo/m0QLcfY7zOfqeVtEEWoNzGq2DdjKd MlHiW6w2q02/sHrsDFrOOrJOlME6s+tpC+vKutMO1ov1ojC7hfWhHNaP3Ut72WA2mfazf+JMZlNx 1mav4KzD3mJvs7rsc7aU1ecteCt2Fm/Nz2GteFvelrXhF/FUdg6/lLdn5/HL+eXsfP5X3oFdwDvx Tqwdv5Zfxy7mN/CbWHvejXdjV/BevBf7K+/Db2dX8r68L+vA7+L3so58AB/C/saH8ifZjfwp/gzr y8fxiawfn8xfYoP4TP4fNoR/wBexf/Bv+So2ia/hGexNvo3vYB/wHL6LzeF7+AH2MT/E89gCrgWx LwQXgn0llAixRSJWxLMfRYJIYD+LRJHMlokGoiFbJRqLJmyNaCZOYWnidHEGWyfOEmexDaKlaMU2 itaiDUsXbcX5bIu4UFzEMkU70Y5tE5eIS9h20V60ZztEJ9GZZYvrxU0sR3QVt7Fc0U/0ZwVigHiA kxguhnNHjBQjuRITxSTuitliNg+ID8WHPCjmirncE5+Ir3hILBGreZJIFzt4Q7FfaH669MkY3kYm yOa8nbxQXsi7yEHySX6DHCM/4nfLj+UCPlH+JJfyl+UvcgufLrOk5h/6Ar4A/9Hn+Tz+ky/OF8+X +Jb7fuXLfL/5NvI1vgxfBl/n2+rbytf7snzb+AbfDt8uvsm3x7eHZ/r2+Q7wLN8h3yG+w5fny+PZ viOOj+90lBPD9ztxThwvcOKdGlw7SU49IZwGzl9EwDnbOVvUdc5xrhD1nM5OF3GW08N5VLRx/uE8 Ibo7TzlPi17OOGecuNV5zpkgbnNedF4UtzuTnKniDme6M130c2Y4M0R/53XndXGvM8v5QNznzHE+ FUOdhc6XYpTzjfOteMxZ7KwUjzurnTVigpPmpIkXnPXOBvGik+lsF5Oc3U6+mKJIcfGmUipFvK2a qtbia3WeulAsV+1UO7FGXaquEL+qq9TVYr26Vl0rMtT16nqxWd2gbhBbVFfVS2xVt6k+Ilvdpe4S YXWPGipy1DA1UhxRD6tHJFdPqCelVGPU09JR49Rk6ap/qn/KeDVVTZXV1StqmkxQM9VMmahmqfmy pvpKLZbN1TK1Sp6l1qo98myVqw7LTipfaXm929RtKm9ym7unypvdM92zZHe3tdta9nTPc9vKXu4F 7oXyFred207e5v7VvUr2cTu6HWVf92q3s7zTvc7tIu92b3Zvlv3d29y+8l73PvfvcqA7zB0mh7gj 3BHyAfdh91E51H3SfUo+5D7tjpUj3XHuOPmwO8GdIB9xJ7pT5KPum+6/5Gh3ljtLjnFnu7Pl0+4e d68c6+5z98ln3YPuQTnOD+CT4/3SL+UEv/IH5PN+z19TTvLX8teSM/y1/fXkTH+KP0X+K3BdoKt8 K9A70Fv+J9An0Ee+H7gzcJf8IHBP4B75UaB/4F45J3B/4H75cWBIYIj8JDAsMEzOCwwPjJLzA08G 3pELA58HvpNbAisDv8lwYH1gi9wfOBRMlgXBRsHxvpTghOCrvmeDc4ILfK8Elwb3+N70lJfk+8E7 zbvMt867ybvTd9C7x7vf8XsDvEFOrDfEG+rEe8O8YU4Nb7j3uJPojfaedVK88d54p5k3wXvBae5N 9KY7p3mvea85bbyZ3jvOOd673odOO2+uN9+53PvM+8zp4C30FjodvS+875xO3o/eL04Xb4W3wunu rfLWOD28NG+D09vb5O1y7vD2egedId5hL98Z7hWEyBkV4iHuPBqSIcd5LOSGQs4TobhQojM2lBRK cp4PJYfqOC+E6oUaO5NCTUNNnVdCo0KjnGmhR0KPO9NDo0PPOK+Hngs978wKvRia6MwOvRR6yXkv NCU0xflP6OXQq877oRmhN525MTwmxvk0Jj6mprM4pnZMXWdpzIGYw84vxAOQ34m8S6pdQ80phU7S oefpDL2VWugs+NeWmaJAT9Hv4szRY3B3je6GPIvgy4rGZ+ntuG6K3u0vld/Ebte5OH+PU2XUsxfu hXLpfQjusxIh61FDoqnlmAc0L6T7VefB72Em704h3GeUpLHwacqo80e9UYf1TyghHU+bWR6NFThc lDoxWvpmna0X6S3Ruz2lat8Bt05v0Mv1QX0V+dF2p1KDYvEF5VWm96HvclHC75Sj/SGxRGJf16+T B1fUh0fl3gm3RaehjPW49UHOakoXwVffxn6tl+hV4B/wDvT2sut/W7+mX8HvaLhUfaYerAfBV6wd C58evuxSuQv0NzoTHPSN/gF0oB9M65XMVZT2x3KagqCnEsVY37PRkDDK/qmQN4tzRTQkF0++B22/ Vu+FvB+LoNbohaLa9Q7bQzsKU5fKn623YYyFC1vcrIza39+KpymP7mi6tBJ3fy9x913FysDR0qaP cppejf5z9epyaj5QbGy3pHPLSf2O/pcZ0fqbCtNUMv9Wwx2GZ0vFrKxAbjyZfsL65hw9nvWtFcgP HtEfWtxab/qtsod+y6LpW2jX0odboRJy9DyLmhXkizJK2FNxriojdxRh9S9Vyv2eva42yHHSj79U oP6tkblM54GP9la6Bu+4sc3g/mZrKZzxNkXOaHz9MvKcgrM+zlNKUPlG9Hdp5DxO/pZl5o+2Lrhk H9Bp37EIBn7u1LuBYBvtmDJcfdCGP2+j6+nP9QK9wszox8ifX8z/NNUC/t9Inc0IiYatw9wwvzQW F+XJK+Yfj5knlq6k3vDPjoZloPWWHXtWLazfcvRLyO8H+gyIIrkJf1+/S0LPPWb+o7nQB+mpL8Kf icZ/p79F+38fvSuN34eL+ccgdy3qREYSSo2GfaY/QQn/Pmb9m8sOL0CPGXzU1+qrdR/dOZp6Wqn8 jwLFXtf/1j/rFcWCOfWgx2gsfM/SOPPNDL0Dzp1NcyEdzqcF1MquKrShr2gVnUO/0hbqQJmM0U2s N+tNA6HR/40GGV2ehhgtnh7gd/P+9CD08TU0gq/lGTSSZ/EsepJv5ztotNHNaQzfzw/QWJ7H8+hZ o5vTOKOb03PQzYP0vKgv6tNk0V30oJdEb3ELTZFz5BwyWq2mV3zxvnj60fnI+Yh+cj5zFtASZ63z G/3saEfTL0ano+VGp6M16hp1La0zOh1tgE53I200Oh2lG52OsoxOR9uNTkc7jE5Hh4xORwXQ6Z5m BG3uOeao59Vk5jc6HYs1Oh2LMzodq6ZmqJmsutHpWA2j07Gm0On2sDOgzWnW2RWuj3VzXTfAerqe G8Nucau51Vkft4Zbk/V1k9067G63npvC+ruN3CbsfvciN5UNhNZ2OxsM7Ww0Gwrt7Gk2zOhf7CGj E7HhRidiI4IPBcezR4ymwyZ5cV4Sm++9473DvvYyvF1skdE12HKja7Bfja7BfjO6BttgdA220ega LMPoGmyb0TXYLqNrsN1G12C5RtdgeUaPYPlGj2BHjB7BeYw/JshVTI2YmjwQczDmMDd7CqstxzDL MRwcMxEaxST6J3h6Cs1EyOs4Fb1Bb2OWmgV+ciw/OeCnTzHqPgNXBSxXBcBVixH+Pa2gIK3EycFl qyBV/0q/QbpaR+kYYxnguQaUSbsx4vfgbEh76QA1ooM4G9MhOkJNqAAcWc1yZF3LkcJypGc50gNH 9qM43h986Vm+jAdfrqNEvp6vp+p8A99ENXk6T6ckngF+rWP5tbbl1yTLrzUsvyZbfq3ONddUXUD8 pwRwLccVB9UA7yr40flUS/jBxwmWj2uDj7tTU9ED3NwM3Nwb/lvA080sT9cFT68jJtfLLcTlVplJ jsySYQrKHJlL9eQ+uZ9i5QGZT/XlEXB/E8v9DSz317XcX9dyf13L/XXB/ZdSgmqv2lNQXaYuI6ku x3jwYTxchZAOqgNCOqqOpFQn1YlcdTXGSSOMk2uQ91qMFr8dLUGzAkIhdSPGTAzGTDdqoLqrHhSr eqqe1ET1wiiqZkdRNTuKGEbRPcjVT92PNH9XAxAyUA0krgapwahliBqCkh/ASAtipD2EXMPVcISP UCOQfiTGXsiOPWbWU5BmtHoK9Y5RTyN2nBqHkPFqPHI9p55DmufVRIRMUpNAyWQ1GSEYnxQw4xPl vKJeQa5pahrCZ6gZKGemmomUs9QshLyjZiPvu+pdtMN76kO0zEfqE9A5T81Dm8xX80HVV2oRqP1G LUaZyxQ4U61U4Em1WqWhtLVqA6WojSoDbbJZZaGubWo7NVQ7VDZacqcKU2OVo3JQ4y61BzTnqlyk 3Kf2IXa/2o/wA+oAKDmoDqH8w+owSs5TeSg5X+VTdXVEHUHtBaoAebXS5v9VXR/VNWiCK9AEV6AJ rkATXIEmuAJNcAWa4Ao0wRVoQgxo8iSuo93RxA2mkDSYQsxgCnnAlOG4jgiMojiDLCSALKvIC64O rqFQ8NfgHoozKEPCoAzVAspkUHVvs7eZErwt3hYKeVu9rZToZXqZiM3ysijJ2+Ztozredm8n/GEv jPQ5Xg7S7PJ2Ic1eby/8ud4+Svb2e/uR5oB3EGkOe4cRm+flU9Ar8DQlhYxqXd3gF64yJHH1hRyK B4q5VDPkDwWoRigYCiKlFwpRHeBadYQkhBIp2aAbJQLdknGtHaqDNPVC9SkhlBJKQTkNQg3hbxRq hPSNQ43hB/YhHNiHkJdDr6CWaaHpyPVq6FWUPCM0E2W+HnqTahg0JGHQkOIMGlIcEOs/UTQcj1NY NPQBDSfDPwU4KCwOOkDBd+CfTR/j+gmB24CGn8P/JTBQ0CLgoAAOrgRirgK+Crt+71ocFBYHa1gc TLQ4GLA4WNPiYJLFwVoWB5MtDnoslsVSiHVlXXHtx/rjeh8bgOsgNgjXMWwMhYCS1xK3KOkHSvbB 1aBk0KKk36JkjMXEBJ7Ns6maxcF4i4PV+RF+hGItAsYJKSTFA/tc+AMiQNVEV9GV6ohu9k02g311 LfbVFz1FT4T3sm+3GRysa3GwvrhV3Ea1i3AwkwQQMJdcYF8+BSzqJVvUSzSrthifF6uLMXovUZeQ sBjnqiuAcRIY1wF+g27Coptj0S1JdVadEWLQTajr1HW4Xq+6IKXBOGnRLdGiW8CiWzLQrTd56lZ1 K663qduQ/nZ1O659VV9cDdK5FukCUaQbpAYhZDCQzrEY56oH1YPIO0wNQ/pCpBsFfwTjHlWPwW+Q zrVIJyzSBdRYNRa5nlHPIsSgnmtRz4ui3gQ1AeEG+1yLfckW9YRFPaleBuqJKOpNV9Phf1W9CkR7 Tb2G9AYHhcXB5GI4KCwOusDBefBHsO9T9QX8X6mfcTXY5wL70uA3qFfDol6iRb2ARb2aFvWSLOrV sqiXbFHPU3vVXuQy2JdosS/JYl9yFPvygXHCYpznMpeRiKBVYGjgQfIHHgo8hOuIwAgKBkYBm4KB RwKPIOTxwOPktzjFgxOCLxG3iJPg7QTWxHm7vT0Ub/ElziJLApDlAPwHvUMUC0wpwDg3mFItJEKC YoEmimIsjsRbHEkAgsTDbxCkeqhmqCbSGOxICNUN1UV4/Sh2NEAJBjviLXbEWeyoZrEjHtjxMsqc FpqGXDNCM5B+JlAj3qIGJ95ql1l5PWfrpW3oKrrpWHL+/49DZ+ltxkXvNpald5l1HrvWV9myN5sV Lqt5f27v1xbWaa8/R7XPbKN/Wl00TafrzJIrOuXXW7hCp++vPIUn99AdoHma32Pq3qVyZEHT/rbq 6zJF5WQffad322s0HLpiLlo2XYfhilb2immiCcVypyHVGjLrHjXhi64wFmrXf9ARKKKmeL0e3WzD dpS1uqC3l16b03v0Jv0rYkrtQlT1KFwlL3lnxk+Uq4utF4B2UeTPPlYv6w2lVzVP1lH2Dk65uWbq V+1vvl0N/844sz6k34JvcTRNIWeZEbxPLy0Mr1Q9my2Ppv9+b1bB9LpiKZ6x60FmrXyD9W0GNcUR Ktq+Fe1fu2qdXn66yh/gtGLl6v06H+6wWevSR0qkO96+1P/Y8QeP+QoceuoJZL6mjPLSqTl4sN4J lHr8ozlZbDV4ajG1zAPYUOE9xBOfK44qrwRVxcdeBfO/rxfo96L7Awl6ml5gQzPM7F589q6S/LAG 2LjRyg+ZVjaxaGbmJL0Rv7OiqcJ2v+17uEU4M0uuXFskq0WFa7NfYy5YrJfBTUXoVXq5/sGGr4hI EXZH++bKU1qK8m0l7uwcqv9TLORuPUP310+ZVX49oCj0fIR9bMZd6V1HMnuupfdCt+vP8SxpJ2+k FvKDmceAYIVy4WKK7s8WpwG4XLQ3YvZYyin5p5NFY1UPtFLI/j5n9ptLxQ7SX5dIG/ldh9ktw3BI Fepbabjeylu2nYwP89vGaKvhqu/SS2x/HyBRxhwWohalygxjHOyM7i4JIEfhrtOBSOyJz2+/70OX 3K8slFKM7GXn7c04w6Vkzw1W9ixjtGM0n2TsKus4Cs+Wl4rPPzokGv73ssOpMvvolT70HZXMEHnH YrR+3P7mWAT4wDj4/qXnRHw2rlA+s/ud6KlPqkDd+/pjIOZH0buv9dtk3g+aa/xwQE6g2NdAiUIp OAfo+0MUJyL7ZzGlyvxWf6QXRstMMHfR8BLooHXlqbX5MEr1r0V3hbrLJuMr1CsjkrhFtMWGPyLv iETHzx6LyD30NfZuIZndvPvhHoBvvJ6Mue6BaCnF3m1BC8zXw6pA7S16hH5N94fvS4zq13Rfiw/P YDZ6De28UE/Vd2JuzTF7gPbJ5unZenqk5uiskay/PKrMTL0KWmVk5J5d5IvKnfpQxFVcYi5Rdq4d 70VvBZWcpew8XaT5Wsl3o33vofgbF2eWfGPljzpK7uLaN5h2lk+JfaJS71/9EUdJTda0Knh4b3n4 aXvnpGm6lTmKyx8YDUbLWo3fY+x0F6XcfuL06pf1cP0PPcn6l4LfXzVvykTnoYi8uE9/CLfgxOqx JbWIvMlyQmVk6K2YCe38iD7dCj4skrkjva53QebYVZYEWOm6qiBzF8v9Q6RXQYvBwZ+idxui4ydK 9Z8znss69B36dv2pnkPc3o3QQ4DWvSMSgZ6rD+JurP67Pk83Ao621g/ou06groj8mHJC9EYxKaLT Fr1v+GrJ2JN56JknoQzDvasiqA75tlTv2/h0/cvvs/Cfe4CatRhzds0TPGw0xSJNJSLpIvZbuGO8 q/pHH6D32eIjF/LVvD+TnmMfGG2DjOwUedNVD4R0tAKjLxK30F7X6k90N/0UfOP0b5GwKtb17YnT W8kac4u/5/W/exTJuHtO/O3Kst51P5lHRDqE/L0Fs95JWLEo7x3l4+atIEfpd+3a/o6q11TsqHVS SqnQAVnohCVX/dzJoKScOqJIB+n2hNflT1IvlVdLBiTb//JIOXkHpJ7ck9Yy8SdAx8kY73/gfkRV uBFyT3okZ/TLjsJ1kSV2n2HJcTPfG037XuXr/aOPqnwDUaqMY+6GHCePXa03K0URTTiyolO0Fxw4 nn5s13ZrUX9yKl+vzV+Fr7x0pp07fv+WrHBNrqK6XZCuqHytf+qRWNWMld95IvNWg9mXLtLs9Xx7 3Ql8Lnc34n/tgNy/79jfTBRLd/C/T0vFjoohZFVn9TK/lSq3LvsGwe/fDtodiyLOCpSZqTCtWauq Q90w5v6Eo6TsHkENaE/l4KzdifkT1vv07pNY1iaKriiX+cXRKfYrJ7ODvrSM2PLKNt9RbSrMWeiz K/yboiGFdZ5v6zqKrmJ3T/5eZiEt5nutUlSZr7Jaml2aqmjteqp+Q88r+g4s6jMSQXRNc2kRHS1L 0ftG5esrkb8KbwrpX+yuxPdF9/YdIMibToV3+irw9d4x6i7z2+Ry8my1q1ZmJrdYYO++xtiLIEPg ePKlnVFi6aKKfa9ZRv6qvP+w3Hxvad3+yL29RlfNj48O0WepU/J9I/DXbr3MuqlUEzLptuhu0sbI mLa8dnflKS3nOSI7bMW0dd1bP6Df1K9YuwFF7/ToDvr9Spb89R8jMRsaj12PLihrVzmyo3hU2O7y d3Gqeth3ZKLIrPdAntgD+WiNTvsdiXQ2wsye8bn6Bnv/AThgle6hF5l7vVC/oL8xK+Y27vkSZa8r DK8URZ11f/2Ivip6Z33gwL7W/4aeoQeAD6ZCWpuHmdekmKM/0h9GZ22zOp9ILeye81Ddz4ZF3kd8 BXL1y6Y/jJWEoreASqwF6UOFX/NXit6X9FvQ1f4ZvVti655qcX6JbQOz+/qeztVf2ASRr/ajbxhE ufjsytf6Zx3/la+xS9eyqRCxIvvOf9ZRlX0q9PROKrbqUGQhoSJzT3Uy7+9cZ/11qDV0zxSbdwuk ji12NqlNf9ErMULNuU6v1+dhvPQlT0fm9aieitEZ0alqRu/fj+5UcCr6YtqGv3Oc57DvVuhhmOei K5D6Yt0LroO+g6rryBxcaENjBNxl+nzdRUe/bNDf6d/s2xJmxG7HnLQpqr+eRs3tzHmaTXX81Y2y 6XpVz8D1raL7eUaXK/FmxfVRTzf6G51LraydmCY2pvizBwp+0cGCA3am/FTfoz8wc5geqR8zPpQ6 pkS1kXfA7qkCvf30fXj+++yNC18/i5uP2Zl6GfoysyDyJf1caxWk8LAtqwdGy6iAjldm3dvKT1Mq T7Z9I8DICZabLDd/jXtpo73jyjsmVyxdAOo5LS/Hjl3XqB27R+lKxlkN6mOt0w211ulGW+t0Y1hX 1oPGs7vYXfSCtUv3IhvMxtBkNpZNotnGOh3NM9bpaL6xTkefGut09Bn7gi2lhbwFb0lLeGvehn42 1uloOU/lqbTCWKejlfxK3oFW8wF8IKXxofxB+o2P58/Tej6Tz6R0/iafTRl8Dp9LO/gn/BPayT/l CyjMv+aLaDdfzBfTXv4TX0K5/Ge+jPbz5Xw5HeSr+Co6JDwRosMiTsRTvrEwR9pamCNrYc4nGovG TFkLc661KhcUbUQbFrJW5WKsVbk4a1Uu3tqTqy66im4sQfQUvVii+VaOJRmrbyzZWH1jZ8q5cgHr aqy+sVuNpTd2u7H0xu7wxfmqsb6+BF8tdpex98bu8/3m28SGGHtvbLix98ZGGHtvbKSx98YeNvbe 2BO+fb489qSx8caeNTbe2CRj441NMzbe2HRj443NNDbe2Cxj440tMDbe2EJj44397PRwnmCrjXU3 zox1Ny6NdTfuM9bduDLW3bjrTHdm8Bhj143HG7tuvLqx68brGLtuvJGx68abOYudNfwUY9GNn2cs uvG2Tqazg19gLLrxi41FN97JWHTj1xiLbvxuY9GNP2i+j+MjXe5yPsp1XMUfdoNukD/qxrpx/DE3 wU3gj7tJbi3+hFvXrctHuw3chvwpY3GNP20srvGxxuIaH+e2dFvy54zdNT7B2F3jzxu7a/xFt517 MZ9k7K7xl4zdNT7V2F3jLxu7a3yasbvGX3PvcPvyGcbuGn/dHeQO4v8y1tf4W8b6Gn/bWF/js9yn 3Kf4bHesO5a/645zx/P3jPU1/r6xvsY/MNbX+CfG+hqf737gLuCfup+7y/l37ip3Nf/N/dVdy9e7 69xMvsnd5u7l2cYqGz9grLLxg672M37IWGXj+cYqGz9irLIJ5q/lrydCxh6bqO5v6G8uEvyn+c8U tf2t/K1Eff/Z/rNFiv8c//migf9C/yWiqb+9v7043X+5/6/iDP9V/g6ihb+Tv7No5b/Rf5M423+v f4A4J5ASaCwuMNbdxMXGupu40lhrE1cZa23ifmOtTTxorLWJR4y1NvFU8PrgbWKW+WpPzDfW2sRX nvJixY/GTptY6XXz7hS7jJ02UWDstElp7LRJZey0yYCx0yaDxk6brGHstMk6xk6brGvstMkUY6dN nubN9GbJ042dNtna2GmTbY2dNplq7LTJdsZOm7zY2GmTVxo7bfIaY6dNXmvstMnrvU1euuxqrKzJ 7sbKmuxhrKzJW42VNXmnsbIm7zFW1mT/GB7jyntjvJgYOTgmPiZBDjWW1eRDMQdiDsiRsRTL5Cji LB2oFwONL5biiFE1nILiMQ9LSsLc7cOs3gThTXEqaoZZ0KXTgZJ+4OH55AEPzf88XGT/AcMgZoxF zFgg5g3IdSPOasDNHiixJ91G7agPMPRiYOgASA4DcV5Cg2go1aAHcSbSMBqJmkcBYZOAsB7VYiEW Q8n2C+HaLA6YewYwtxlCmrPm1IKdwk5F+GnsNPhPBxbXsljcEljcGddrgMiXWXuhtVgP4HIri8ut LC7/Bbg8HOEj2JPUmo1mo1HmU0Dq2kDqcdSGjWcv0jlsIlC7pUXtlha1W1rUbgHUfgv+t4HdLYDd izAffMO+ofPZt+wHuoD9CDS/0KI5B5q3xvVsYLpjMT3OYjq3mB5nMT3BYvqlFtPPsph+rsX0OsD0 t6g+f5u/TXX5LP5vasBnA+UbWpT/P8rOByqq6973e4Y5ew5wAEWiiIQYQhCREIKEUIIGCSHEWEKN MV5rnQGGmQGGYRhmhmEYzvxltMZaY60h1hprrbXWGGuttdZnrddan/VZrrHGeg2h1mut9VrrNdZr rLnf/Rtibdd6a72XrP2dvX5nn33OnBn2/nxZ4ZtcWuWnYpU/AP1fWOtzaK3Po7X+Yaz1/wd6Eiv+ VKz4w9B/w7qfQ+t+Dq37j2HdV9jjCSlY/fNp9S+g1X8aVv9MVpgwOWEym5GQlZDFasVOgD52AjYd O8E0aEHCdJyF/YAVif0AZ1UmVEKfTXgWR2clzILOTpiNMdgboNgbUBF/a/0i/a11Pf199Yv099X1 9DfVddgnAmy2LqhbxjTYLVazNN2bunXsc7q3dENsgu5t3UZWqXtH9y02SbdZ9y6brNup+xHLwo7y Y1Yq0kRZmdhXWJXYV5gi9hXoOGkcmyONl8azp8Tuwkqxu5xmCdJvpN+wqdIZ6QxLkz6QPmA66az0 WyZh1zmPyofSh6iMSCNML30kfcRkaVQaZQ9Jv5N+x5LFnsRSxJ6EkZely2y89EfpjywdO9OfmEa6 Kv0nrnhN+jObIF2XrrNJYq/CFT+WPmaZ0i3pFpsl/VX6K+7ttnQb9/Pf0n+jf0e6g/4n0idstvQ3 6W+Y+R7Xsgk8gevYbC5xiWmww+kZNgsusxSeyJNYGk/mySyBK1xhmTyFp7BZPJWnYgx2QfF/decT cG4GfwjnZvLJGJ/Fp7B0ns0fxsw5PIeJBNRHobk8FzM8xh/D+Dyeh/GP8wKMn86ns0m8kBeiPoPP YDpexItYKn+CF2P+J/mTOLeEl2C2p/hTGFPKS3HuTD6TKWLHxbWe4c+gXsErMfJZ/ixmqOLVTOJz +AsYWcfrmJ6/yF/EPb/Cv4D3NZ+/hvm/xI24ehNvxlVauBnzWHgHq+Y23sXmcAd34Ypu7mE1vJdj 9eB93Mcm8n7ej7v1cxXvJcCDmCfEQ5ghzMOYIcIjLJlHeRRXGeSDGBPjMVwFBMCmCAJgJSCAN1kZ X8PXsJmCA9hkcMBbODrEh1gWf5tjHeDf4N9gVXwD34CnvYlvgn6Lb2alIgMW48EKmOH7/PvQHRzf Ur6T78S57/Fd7AX+A/4DzLyb/xBH9/K9OPfH/Meo7+P7MfKn/ABG/owfwtGf88OsHIRxFPVf8l+y YnDG/8b44/w4Kr/iv8LIE/zXGDnMh3E//8ZPYcz7/H3c4Wn+G9zzGX6GPcE/4B+wZ/hZfhbnglFw 1ggfwcwf8Y9w1h/4HzDbZX4F4//E/4Txf+EfY8wtfgtP46/8r7i32/wumyw4hs0Ex6Sgn6ofz8r0 6foJbIo+Qz+Jlesz9dnsGf3D+qnsKVDONFalL9BPZy/pC/Uz2LP6In0RKk/on2Sz9CX6EszwlP4p jCzVl2LMTP1MHC3TwzuCjT7HntZX6itxrWf1z2J8lb4KR2fpZ+FaIlNAI5iJlQpmgoKZoGAmKJgJ CmaCgpmgYCYomIllCWZiUwQzQcFM7AnBTOiDmViVYCY2WWTVsmJ5jjwHZ4GcUAE5YQzICQpyYuWC nNgzICc4AdkiW9gs8FMXS5MdcjfGgKJwLigKdVAURgblIOYJySH0w3IYdRAV7gdEhfFflb/KyuTV 8mqcBa5iM8FV61B5S8a3Th6Sv4H+d+Xv4lrb5G3sJUFaqIC0WJIgLShICwrSgoK0oH+U/8Kek2/I N3CV/5L/C/OAuliJoC70P5U/Ff/vrUTGXkjUJGrYZEFgbAoITA+VE2X2dCL+YSWJSYlJ6CuJqdC0 ROy/ieMSx7HyxPGJ6ahMSJzAqhIzEjPYzMSHEh9isxInJk5CfXLiZFaWmJWYxZ5InJI4Bf3sxGxc 5eHEh3E0JzEHFbAd+mA73AnYDgq2g4LtoGA7KNgOCraDgu2gYDso2A4KtoOC7ViSYDv2HNjuVTYu aUHSAsaTXkt6Df2FSQvRfz3pdfQXJS1mGYL8UFmWtIVpk76TtAN98B/64D+MAf9hzH8na5g2WZuc xZ4XFMgq4tkNggKZVlAgFBQI/aLyRfawskRZwqYqX1K+xMYrS5Wl7BHFoBjYY4pRMbJcpUlpYglK s9KKvlkxY7xFsWCMVbFiTIfSgb5N6WR5il2xY0yX4sAYp+LE0R7FxXJAlr2oexUv6uBLqF/xQwcU lWUrASXIHlVCShgjI0oEI6PKIK64XHkDlZXKKswMBsVV1ihroF9T1mLMOuUt3POQMoR53lbWo/8N 5RsYv0HZgP43lW9izo3KRhx9R3mHTVM2KZvYdEGurADkuoXNUL6jfIfVKluV76G/XdmOMd9Xvo+j 7ynvQXcpP2BFym5lN47+UNmDoz9W9rFC5SfKflR+qvwUFfAuFLwL/blymD2u/KtyBGN+oRxl+cov lV9i5DHlGK5yQvk1KsPKKcwJGsb8Z5Qz0A+UsxhzTvl3HD2vnMc8Hyoj6H+kfMTKQMm/w2wXlAts mmBllgNWDrPslEhKlOWmDKbgKYGbl7OilC+n4FmlrExZyR5J+UrKV1B5M2UNm5HytZSvsVrB06iA p1mR4GmWIXiaaQVPQ8HTUPA0yxA8zUpBdtXE03XE01oi6Tg3f0bMgo9TiY9T2b/g31Qi43oi47lE xulExvOIjCcSGU8iMs4kMp78QH6PRPk9MuX3SJTfI1F+TxLl90iU3yNRfk8K5fdIlN8jUX6PRPk9 aZTfI1F+Txrl90iU3/MS5fe8TPk9Eyi/5/OU39NA+T2vUH5PI+X3ZIHUk8HNKZoUYvTJ7GlNliYL DC1IvQKk/gqrJBZ/VfOa5l9QFyz+rMasMYOw3Ro31KPxgZv9IPJnQOTL2Syw+JfRf0PzBsYLIn8G RP4WqwaLb2BzQOF7oD/S/IjVaPZqfoajgsJfJwp/nii8lij8BVB4CUsgCk94gL8TwN/PE3+/BP5+ mShcJAzpKGFoPCUMjaeEoYcoYWg8MfoXiNE/p/2ydgWbLZL92YIxUhdcPkP7nvY9Nl27D1z+GBH5 40Tk07S/0v4K/C1Y/FHtKe0p1H8D/n6UUose1v5W+yGI/CPtR1CRYFREqW6F2ova/0DlD9o/QEW2 Ww4lG+Vp/1N7DX2Rb5Sv/Yv2Bvoi5ahA+4n2Lvoi6+gR7T3tpyyHEo9yEzQJWvRF7lF+gpQgoS/S j3Ip/SgvITkhGZU00H8xcX8pcX8Zcf/8hCkJ2agL+i9OeAz0/2RCPui/mOi/JKEwoRD9ooQi6FMJ M9lMOIFn0K9IqGBPJHwOfqCY/MBTCVXwA8UJzyU8h/mFHygmJ/AaOYGF5AReIyewkDxAHeh/HUsF 929k6UT8mUT8U4j4K3R7QfzPgviPsFm6X+hOsBri/toHMpkkymRKo0ymCZTJ1EhOYC45gTmUz/Qy +YFK+IH3GScPoJd+Cw/AyQPoyQOkEv3rif4zpYvSRVD+JekPqAju50T8k4j45xLxpxPxZxLxT5Zu SjehgunriOn1xPTpxPR1xPRazsH0eqJ5PdH8ZKL2OuJ1PZF6OpH6ZKLzOuJyPXF5JnF5HVgcvpcX g8g5sXg6sXjdGIWX8TKML+flGC9YvI4oPM7ceuJsPbF1PbH1XGLrdGLrecTWE4mtJxFbZxJbTyZ6 nsxX8pVgyq/wr4AmBT1XEjFX8XV8HeqCmJ8mYp7DN/KN4EjByuV8M1i5ilh5CrHyLL6VbwfHfx+U PIUo+VXi41l8D9+DswQllxMlvwpK3odzfwJWnkKsXEGsPIv/Kz+CGX7Bf4HxgpXLiZKnECVXECXP Ikqu5adAyVVEyXOIksuJkmcRJVcTJb9AlPw0/5B/iKOCj+Nk/DS/yq+jIvi4gvi4kvj4VX6P3wOh CjKuIjKeBTKehL5g4mpi4jn6R/WPsxoi41oi49eJjJ8nDp5DHPw6cXAtcfAU/TP6Z6CCgF8gAq7V P6d/DnOKRLE0yhKTKEssjVLE0ihFTKIUsSRKEWugFDGJUsQk/Xz9fFxdZIlJlCWWRiliL1OK2ARK EWukFLEsShHLohQxiVLEJEoRkyhFLI1SxCY8kCKWRiliSZQilkYpYlmUIiZRilgapYhJD6SISZQi lkYpYhKliE2gFLEsShGTKEUsjVLEsh5IEZMoRSyNUsQaKUVMovww6YH8MInyw1IoPyyN8sMkyg9r fCA/TKL8sDTKD5MoPyyN8sMkyg+TKD8sjfLDJMoPe4nyw16m/LAJlB/2ecoPa6D8sFcoP6yR8sOy KD9Movywlyk/rIHywxofyA+TKD8si/LDJHiYCawSjuVxNof8SY08TZ4Gb1AgF4D1Z8gzWIVcJD8B v1EsF6NeIpeM+ZZyuVSeyV4g91Iul8sVUOFhauVn5Wcxj/AwNXKd/CK0Xn4Zs82TP48xDXIDe1p+ BU5mltwoz4dDeF1+HUeFn6mWDbIB99MsN+OseBKjcDi1cDjtuJZwOKlyt+zEPD1yD85yy272vNwr 96IyIAfwLoTPqSRvM4WSG8vJ4VTJq+RVUOFzXiCfUyV/XcYqQT6nnBzOLPkd+R1Uvi1/G1cXbqeW 3M7r8vfk7ThLeJ5Z8rvyuxjznrwL+kM4n2R5RP499D/geZLJ87xInqdGvinfxMzC81TKn8if4N0J z5NMnudV8jxzyPNUkdspJ7dTSW6nPDEFDqcKDmc8qyaHU0sO53lyOC/A4UyEC5qUmImRk+FwKsjb TCE/UwM/Mw1XKYSfSYafKYOWJ1ZCZ8HDJJOHSYaHeQUq3EsyuZdkci8vwr0sGHMswqssgg9ZTI5l SdISVFqSWtjspPakdqgtyQa1J9mhjiQH1JXkgoosuvGURTeesugeoiy6hyiLbjxl0Y0n55NA3uYL yVOSc9nnkucmf4HNTjYl+9gCSqrTkdvRweHMgIsQHmYGeZjpSis8zKNKm9IOUhe+5VFyLDPgWLrQ dyjdcA4exYOK8CqPKf1KPyoDSgAuRfiTx8mfzCB/Mh3+ZAUqb8ClTCeXMk35qvJVjBf+ZIbydWUd jr4FfzIN/uRtzCb8yePkT+LO5DFyJsXKt5RvQb+tfBsqnEkZOZP5yvfgTJ6CM9mB+rvKTlZCzuQp ciYzyZmUwZn8EJU9yo/YE8peZS9G/kT5CerCnzypHIA/KVYOKgdx9AicSQl5kjLyJPOV48qvcPSE chJ14UxmKu8r72Ok8CRlym+Vc6j/OzzJTHiSDzHbCJxJDjmTEmVUGcV1hT8pJX/ypPJ7BYxH6YBF lEdaqFxRrqIikgJzlWvKdfRFXmA+5QXmUl5gEeUF5lJe4COUR5qj/E35G1RkBxYpnyogQEoQzAOY gwApR/ARyibNoTTBhymbNIcyBfMpU7CIskkLU1JT0lAX+YL5KRNSJqAiUgYLKGXwkZTMlCwcFVmD RZQ1mE9ZgwWUNZiXkpuSi6MicTCfEgdzKXEwL6U9pZ09Sk7scTixEDkxfB9SlqUsg0NbDvf1OLmv meS75sN3fR39dSlDrITc18yU9Snr0RfJhfmUXPgwJRcWUXJhASUX5lNyoY5pptzIDgJ+lYQV7CPG jIvRjGhmNBuaE817/1Xj2I5XFS2KtgJtNdo6tA1om9G2oe1E24O2H+0Q2lG0E2in0M6ijTBt8Dg1 ZrxITRscRjuD/hW062i30O4y1qRFk9FS0TLQstCmxu+hKf//8loUn6updKyJcyrQZtMx1lSLNjd+ v3TO5vh7bGpEW4i2JF4fe9UGz1PTOHah7UX/wv1avF1GuzbWP4N2c6x/J95CbKxxNAUtHS0TLSc+ NpRH41lTM5o1/pya7PefeXxsIY1jTS40H1oQLTb2HlbGrxcqGXuva9CG0DaOHd8ydrx8rFWhhs+x SbyfA2iH77+X+Hvei3YA7TDaMbSTaKfRzqGNol0ae736wOtn42+g3R57PTd23u0Hjt9jrFmHloQ2 Dm0iWvbfX8Xn15yLVvD//KoN1fz9sxLvrbl47LP+/21Z/9jo+70ifh36XmXFx9F1H2xlaJV/f70/ R3xebage9Wq0urHvH441z/v7a/N8tEW68UtHO+cODBujXYyUkyrQFV3p0NVdmdB1XTnQDV150M1d hQPD4qzAEuO2rpJA89JLnY0DZ5Ze7Vw4cN64s6uctOp+f09XzcB5cTRgXXqjc8nABeP+rvqBC/H+ mN7ubB64bDzU1UC6AHqU+kepf6JrMfRUlxF6tssMHemyDVwWZwXsUCv69zrtA9eMF7uc0CtdXuj1 LnXgmqgHXAZdp2vgpvFWVxR6t2tFwGdI6vQN3GnSdq0mXUe6ASo31UJTuzZDM7q2QbO6dkKndu0Z uCPOCgSb8rv2qxsM4zqDKp5s1yGVGSZ2xlQuNBAzZHeuVJWm0q6j0IquE6oiKoGV8fqY5nauUdMN BZ1DambT7K5T97W266yaKeqBNWNa3LlRzWma2zVCehHaSP2FXVegS7quQ5u7bkGtXXfvq92hDQw1 uRxyYKOhrHOLmtfkc6SqeTRb4Vgl6Mj4TEUlsMVQ2bldLWmKObJIp37WF/XAdkN15y61vGmlI18t F/3ALkO1owj9us69alXTGkcpacX9/pBjNnSjoxa6xTEXut3RCN3lWEj9JWqVODew1zCv84BaY5jf eVitb9rraL6vBxzNgQNNhx1Wtd6wqPOY2mBY2nmS7sFO6rrfP+bw4U5MnafVBU0nHcH7etoRUxcY 2jvPqYvbDvUFSWOkK6FH+9ZAT/QNQU/1bYSe7dsCHenbri4WZw362i727RoMGhydo6rR4Om8pJrb rvTthV7vO0Aq+rf6DqtmcXQwZvB3XlV5292+Yypv13ZeHVwZV0O484Zqa5f7TpKehqZSP5X6GX3n oFl9o9CpfZeg+X1XVZs4a3AN9Db6yzvvqc72or4b0NK+29CKPlREfXDIsMquU73ts31Ca31JgxsN a+1Jqto+1zdOaHuM+hOhjb5s6EJfLnSJrwDa7CuGWn1lqirOGtzSbvdVDm43rDdcUKPtLl+1GjVs so9TVwgN5Rm22ieqq9t9vjpo0DdPXS0qg7vi9THdYc9W1xl223PVDe0x3/z7utK3CD87qA/uHdN9 9gJ1c/sa31JS0/3+kK8dutHngG7xeaDbfX7oLl8Yute3fPBA+wHfqkCz4aC9WN3Wfti3dvAwzbZz rHLMtx56UqioDB4zHLGXqXvaT/s2kW79rC/qgycNx+2V6v72c74d6n7RHzzdPurbPXjOMGyvVg+1 X8KTh/r23e9f9R2E3vAdgd72HYfe8w2rhzp0vjPQJN959ZA4d3DUcMZepx41nLfPU090jPNd+Ced 6LusnjBcsM9XTxku2xepZzuyfddIb97v5/ruqGcN1+xL1ZGOgn52X4v7uTpiuGk3qRebzjlWkq6B jlL/kmMIetWxEXrDsQV627Edes+xS70ozgocbtY59gaOGe7Y29UrRmZ3qNebkxwHoONIJ5JmOw6r 18XRwEkjt3vUW0buOCZU9JtzHScDqUbF7lfvNhc4TpOe+6d+sWMUWua4BK10XIVWO26od8VZgdPG dHs4oDVm2pcH5OY6x23oPMc96PxuHXRRd1JANubYVwVSm5eSmrrHBc4Z8+xrAxnN7d0TSbNJcwMZ xrzuAvQd3cVQT3cZ1N9dKeoYP9oc7q5GZXl3XeCSsdC+PpDVvKp7HnRt9/xAlrHEvkk9JTRwtXl9 96LADWO5fSvGb+peihnKu01CURmN18e0yr4jMNVYY9+Ne9va3Q7dQbq724EnI+q3m/d1e7B7Ut9Y b98XyG8+2O0nDd/XI93Loce7V0GHu9dCz3Svh57v3gS90L01cK/5cveOoA7zHAwUGXO6d0Nr7Eeg DfbjuM9r3fugN4VSZdS4wD4cKG2+033wH1XUg7Ct3UcC+S28+3hwnHGx/UygokXpHg5UiH5wonFx NypGo/08va+4Xvis35LefRma2X0NmtN9E5rXfQda6GTQEifHexfn3jaa7RcCs402++VAbUu5U/kn rXKmB2qNTvu1wFyj134z0NhS41gj1Jl5X+udOYFGo2q/E1jY0uDMgy4gXewshBqdJcFswSTB3Baz sxx8AjYIFrTYnFUDl1uczhqo11kf38GDxWIfDJa1qM4GNacl6lyg5oidKFjZssK5WOxKTiMUe02w umW106yWt6xz2rC/4OclWNeywelUL4rvbXBey2anV73bss2pQnc6o/HvWHC++HyDi1r2OFcE8o31 ztVQPIfg0pb9znXimTg3QOPv9JBzM/Soc1ugkXacSx1l/Qp2H7HyX+2o7E9XbR3V/ZnQuv6csfX5 hljlBm93zOvPUzcb9vUXQsU6c69jfn+JWHP6y6FYSWK6jkX9VVg9lvbXqGfpmz/acsK5M2hqOeXc E2xvOevcH3S0jDgPBT0tF51HB863XHGeGLjQct15KujHmLMYc8s5Egy33HVeDC43aZ1XgqtMsvN6 cK0p1Xlr4JphnvOuWmPK6NEG15uyeuTgJsOinlS1wTS1JyO41VDQkxXcYSjumarmmPJ78gPHTEU9 RcHdptKe0uC+OG+YKnoqggdNs3tmDwwLoggeMdX21AaPm+b2zBWfQk/jZzu7qbFnIekS6ELc27Bp SU9z8IypuccaPG+y9tiDF0z2HlfwssnV4wteM/l6gsGbcaZt0vbEQHFxjiJKMQV7VoJdiRtNsZ41 0JU9Q6A48d2409TcAzWt6dkSYqahnu0hbtrYsyukmLaIkQZdz96Bm6btPQdC6XFyM27oOTwwbNrV cww/48Sopr09JwcuN2X1nB64YzrQcw5Xt/aM4jkc7rkEPdZzVc0zney5AQbb3nMb93O65x70nEsX XGW85UrC/KOucaFM0yXXxOCweAKhHNNVV3b8ux3KM91w5WKe264Ctdx0z1UcKmzVucpCJXHCbE1y VYbKW8e5qkNV4uciVNM60VUHSgerh+rj2prtmhcn8FDDA7qAdDFdxUhqbs11zR+43FrgWjRwrbXY tXTgpiDqkK21zGUa6ztJveLnK6SOPUnwcChKukLcVWh1a6WrPbQ63idd11rtcqjprXUuD3gYVBza 0DrP5Y8zcGjzA7oNpOpS81rnu8LQRUIFtYZ2xrV1qWt5nFRDe1pNrlVqSWu7ay0UdVQcrvVxag1W /11D+8VPfegQ6dG4tnpcm8CiINLQiVa/ayvIE1waOtUadu1QG1qXu3ZDHa59YM6TroNgS/G5nI1r 6yrXkdBIc67rOH66xcqc2rrWNYzdM9d1Bv31rvOhi8Yc1wWxI7guh660bnJdC9xo3eq6GbreusN1 J3Srdbebhe627nPzsHZsbafV27jYrYTl1oPudKzGXndmODW+ErYeceeEM1qPu/PCWa3D3XXhqa1n 3IXh/DgDNLe7S7AX0C7Tel6s2/E9uvWCuzxc1HrZXRUubb0mdtvWm+4a7HpYtcIVzcPu+nBF6x3H 6fDs5rXuhkCWmbkXhLPG9uWt7sWBVDN3GwVLuM3qRbPitok93e1U75rT3d5AhjnTreK6591RsX+5 sQaac9yrUc9zrwtktJS4N3y2U5gL3ZvDteYS9zbcG1gilG4ud+8MDot3F55rrnLvia+0gdPmGvd+ zFPvPoRdAHtuuNHcYN8dXij2qfAS8wL30XCzebH7RNhqNrpPhe3iuYVdNI/PbHafDQfNNvcIPA7W 8HAsTjtCg0vj+hnV2D3hlULjlfAa0iFxD+GNpFvMTvfFgNbsdV8JyGZV0Iggk+BSc9R9Pd7HfgfF WdgLwtvFqhvebl7hvhXnivCuMcW7CM43r3bfxX5BfXpf283rPNrAVPMGjwyiAFeE95o3e1LjFIG7 uq/hoeatnoxAkXmbJwu60zM1vuNjHmj4gHmPJz++y4cPm/d7igKl5kOeUijqqBz1VMR3+fCxB/Sk 2KfCp0mHSM+ZT3hmY+/GDh4eNZ/y1GKnxj4evmQ+65kbmGse8TRCL3oWYhdr8CwJLKRnfpX0xtiT ueJpDlSYr3usgVrzLY890Gi+63GpFy1ajy98u8PUXx9L6mjvb4g2dDj6F0A9/YvV1R3+fqNq7gj3 m1XesbzfFhuHMU4cXdXvjU3sWNuv4uj6/mgsu2NT/4pYbsfW/tVwQ5v616krOnb0b4gVGNb2b1bV jt3922LFHfv6d8bKOg7274lVYsfcr27uONJ/KLK843j/0Vh1x3D/iVhd3B0YjvefUvd3nOk/G5vX cd63Oza/40L/SGxRx+X+i/Bxl/uv3Ofwa/3XY0s7bvbfQv9O/93Ibhvza2MmG/fLsXab4k+NOWzp /oyYx5bpz4r5bTn+qbFw3IG2z/Xnw3PFnQ55Cluevyi2PO7ybIWoOG0l/lJ4Luz1sVXtW/wVsVUd Bf7ZsbW2cn9tbL2tyj831t5eJEYaVvkbVa+txr8wtinus9oO+Zd85mfjHtNWT75ybvsl4fj8zfev vt1vhZJXsjX47XBMcY9zDx7zkG1B//VQVftsvwvzL/b7YlttRn8QPgtPILbDZvbHxlhljc3mX6lu tjn9a9SzNq9/KLbbpvo3xvbF/aAt6t8SO2hb4d8eOyI4J3bcttq/C54azjo2THrGts6/F7sGHDT2 C2jsvNAAeerYBXGV2OW42jb4D+AdbYbnctq2+Q+rXuF/Y9dsO/3Hxvo3Se8IXlrGxp4k3OsyPqa4 q2WKbY//5DIl3idNt+33n1bX2Q75z8G9wsMuy7Qd9Y/GHeuynAc0r/2Y/xKe2An/VegpocJjBhfF 1XbWfyPuK5cV2kb8t9U9tov+e1DUUbkyoIt7zGUlD2i5oLhlVaQ1cbVdH0iCc4R/XFZvuzUwDj4R LnJZg+3uwET1VKd2IBsqD+SqZztTBwpiS8XnsmwB6WLDqoHi2LXOjIEydX9n1kCleqJz6kA1RuYP 1KmLLbInGL5H3oH2I1q74FksqZ5YRGfJ8KyMJBm5Z00o3ZLlGRJ7h2djZJxlqlD0t0QmWvI92yPZ 0F33tcizN5JrKfUciBRYKnCWHPd0ltmew5FiS63nWKTMMtdzMlJpafScjlRbssT6SXrbstBzLnRd rJaROtJ5zWHPaCDDssRzKTLf0uy5GllkLPfcCIxarJ7bkaUWu+dexETaLtbJiGPMW0EjHourVxfx x32WxdebFAlbgr3jIsstsd6JkVWWlb3ZkbWWNb250KHegsh6sWZGNpFutWzsLY7sgJYFtJYtvZWR 3ZbtvdWR3fE9xbKrty6yz7K3d17koOVA7/zIEcvh3kWR45ZjvUtDVbSKypaTvSbVbDnd2x4Ztpzr dUTOWEZ7PZHzRluvP1BrudQbDsy2XO1dru6J71BCIxeMKnZD9HtXhX1xcmsd17s2ctlyo3d95JqR 9W6K3LTc7t0auWO517sjfM9S1Ls7kmvV9e6LFFuTeg9GmXVc75Eot07sPR5VrNm9w+pqa65nKJr+ 4GzWgt4z0Uxrce/5aI61rPdCNM9a2Xs5Wmit7r0WLbHW9d6Mllvn9d6JVlnne1m0xrrIy6P11qVe JdpgNXnToe3ezGj6mDq8OepFq8ebF11g9XsLI2Fr2FsSXWxd7i2PGq2rvFVRs3WttyZqs6731ked 1k3ehqhXfL5R1brV6I1GrTu8C6IrrNlerPnW3V5jdHX8s7Pu85qj66wHvbbgKusRrzO6wXrc64UO e9XoZusZnLrNet67IpxhrPfCYVkveNdBL3s3RHdar3k3R/dYb3q3Qe/0Vkb3tzHvztBIG/fuUXmb 4t0fPdSW7j0UPdqW6T2q2tpyvCeiJ9ryvKeip9oKvWejZ9tK7MOhqrZy70iksq3KezE6gpFXMLLG ez16MX6VtnrvreiVtgbv3eBw24I+bfS6kVsL1Ftti/vk6C1jVV9qYGqbsS8jerfN3Jc1qG2z9U0d lNucVv+gbFzQh925zdtXNAiW6ysNLGxT+yoGM9qifbMHs9pW9NUOTm1b3Td3MN9S2tcYui50sCju +tvW9S0cLG3b0LdksELQy+BsQSmDteK3KINz4z9x9BuMlWO/qfjHn46DY78roN8MDDa2be5rjhSI /X1wofDgg0vEt3GwOf7bIVofbrdt8wxhfiKxtp191sBpS36fPXB67Lc39HuVtj12x6DVcqPPNWiP u/62/X2+QZf4rIPzmZZN0lzX/IUxzceaW0yruaP5hOk0n2o1jGslLWeJ2mStwpK147TjWYr2Ie1E lqbN0k5h47W52sfYBG2Bdjp7SPtN7TfZpIT6hJdYplQnvciyJKfUw7Kln0s/Zzmp+Jc9kjo19fNs ampj6hLWkGpIHWRfTH0z9WcsnHos9Sr7Qeq11FvsDO7mC0xH//eDVJbGEtl4toAls4Wsmb3CTOwN toR9ha1iUbaavc9i7Dfsd+w4+70miX2gUTQp7FNNmuYhjUYj/sZJFv/dpGaSZrHGosnWtGlimkLN cs1aTb1mSPNNzWuaH2l+rfliwrsJ72o8OpfOrenVBXVhTZ9uue4NjV/3pu5NTVD3lu5tTUj3ju7b mqhup26X5su6vbqfaFbqfqb7mWa17he6X2repL/HXKs7pXtf85ZuRDeqeVt3SfdHzQbdn3V/1mzS faz7q+Zb4r+i02yRJkgTNN+V3pfuabZxiedpTvNpfJrmJp/OizUf82d4peYT8Rcemk/587xWq+N1 /PNazl/hS7SpvImbtNnczJ3aqdzNVe0T/Mt8lfYZvppv0M7i7/Ct2rn/w97XAEdxXene+dUYi7GM FYxlrMgylmVZxlgQoihEJkQIMX8oBBNCFJhoev56ekbzD2ExxizhKYRHZIIJIRhTPJbVyoRgQghW ABMWy4ToKZhgjHmEVTCLCdYqFGZllsXknfN1jxiEHJPafVWvKqlT39dXt2+fvj/nnHu6mRn4mxP6 6eZt5l/rv2LuMnfpY+Yj5hP6uPmU+ZT+78zd5m79QvN75gv6Z/jzWPrnzB+YL+uXmfvM1/XNOSJn qP75nGE5n9K/lHNvzkP6/5VTkvMZ/facL+Yo+v05iZxV+p6cF3JeMOTm/CBnvWFozss52wz38P+r arg35+c5uw0jc9pzfmko5M8DGUpy3so5YRiXczLnnKEy5w85HxomW0osOwwzLB/c8aDh99b/tP6n kb8vp4hm4lxRyN82nrRdg4VQLkqUxrorSqCmburxmjFKREkqC+q6lcXKshqlvkXZpexRDtS0K4eU LuWYclLpVs45hjiKlRWOtLJqsm1yQFmrbFA2K23Kdkfx5BqyKiPZ+EXY+L8Lne5Puj8JPVl0njDQ uQfwSVShf1n/stDpf6z/MZ3brn9FGPR79XuFCZ9ENet/o/+NsOCbYHfof6s/JobgM6i5+PTpUP3v 9b8XVnzu9C79H/V/JO/gT5YOM+gMuv7/NdhkMIvh+ObYCMNww3Bxn2GEYYQowCdF7zeUGkrFA/hW WKFhgmGCKMJ3wB40TDR8URTjWzGj8JmNh6n/ubphmDlmETooFoYOhg6HjoSOh06FzoTOh3pDl0NX FRG6rJiVXGWYMgIoVEYpZaFeZYwyXpmgTFLqFJcyQ5mtuBWfoihxZb6ySFmqLFdalDXKemUT0Kps U3Yq7cp+pUPpVI4qJ7IlPFM5rZxVLigX+6VPuRbWhy1ZYg3nhwvCRVRbcpM0hEuobXm4IlypXMtI uDpcE7YRs9SHG5WL4QC1jYQbw8nwgvDi8LLwCtJZEl4VXhveEN5M49fdoWhRg7+zfjfmZASJQYwk MYoS8YgwiXKSHPEEiUVUkdwhJpAMEdUkd4oaMRmfLrdT1OHvXd4lviZmizwxh2QYxR1J3CMCJPki IZL4xuUCfNfyWXyi/O9FAcWj58X94gckD4gfkRSKfxBbxKfFyyQPim0kxeJVkofEL0hGib0kD4t/ Fgepf4dJSvG/YT8qToh3RJn4HUm5eJfkcfEeyWhxSXxAfb8i/kM8Ka6TjNXpdTlinG4Ixb4qfH78 8xT78sQEfH68Wleoe1A8pXtI95D4Er7vWUPRsB7f6JwtanXf0LnFFF2jrlHY8VlyB77d6dQpOkW4 dE26JjFNl9KlRb3uGd0SMZ1i5zIxi6Lnd8TXdN/VrRBf17XoWsQ38O3OORRJd4u5unZdu/Do9ut+ KSRdh+4N4dP9SvcrEdD9WtcpgrDfEEWBUqFYyixlogmfzotanrRUiBg+kZewVFmqRNJSbakWKXyT KI3P382zuC3fFN+yeCwe8Xe0tudEH2x/PP+yhLyT0E7YT+ggdGo4quEE4bT4qtwu75c75E75qHxC Pi2flS/IF+U+4mshfchCYg3lhwpCRaGSUHmoIlQZqg7VhGyh+tDMUEOoMRQIRULJ0ILQ4tCy0IrQ qtDa0IbQZpK20PbQrtCe0IHQoVBX6FjoZKg7dC7UE7oUuhK6rjQrRmWIkqcMV0YqxUqpMloZp1Qp E0lqFYcyXZlFMkeRFFmJKmllobKEZKWyWlnH/4OoqdEUpE3wG9Y5+H2Fyf9t9u0kuQtWngcrvxtW fg+sPB9W/ilY+XBY+QhYeQGs/H5Y+UhYeSGs/NOw8iJYeTGs/CFY+ShY+cOw8hJY+SOw8kdFJ0kZ bP0x2Ho5bH00bP0J2PoY2PqTsPWxsPXPkK3rxXjY92dh35/TPaArJLtny54Ay/4CLLsa3494CtY8 Edb8RVjzJFjzl8ianyEfeFb3LPkAf0tiCqy5DtZs031f933yB7ZpB74f4YQ1u2DN9bpOsuPpui5d l/iK5WnL02KGZbZltnjaErQE+fvaeYvzltM65dLc3yl0sTlkdxWESkI1oUarsxHqCTMJDVxnvFse FxsfOvrngTYn4sfkqtgEeWJsUuj0zeA6uTZWFzpLuBA/yZAdMVfo4p8Ht5Gnx2bIs2KzQ303wH/L c2Lu0LWYW9HHu2Up5lMsfx5oY42fk+WYouTHFDkaiwPp2HylgFAUj6BcEu9RyuOX5IWxRfKS2FKl 4gbwd2X8itwcW65UfwJq4tcVW8Ior4y1AKtja+R1sfVKvQou89iUmTeAsW6MbVIaYpv4CGyJtSqN nwxuJ2+NbZN3xHYqgZsh7461Z/RmQ94X269EbkA+GOu4HUTnpNfJh2Od8pHY0UFxPHaCEZXSGxny qdjp28KZ2Fn5fOzCLeiNXWRE5cRK+XKs73YQjaa3yFdj1xghEdcD5riFEU2nt/KxKZJqC7njjaHc uDU0LJ4/ENGF6R2hEfGCT0J0SXo3dBTGi4BR8ZJQWbz8JoyJV9yC8fHKmzAhXn3bmBSvCdXFbbfA Fa8PzYjPvAWz4w03gcd9G1CSiSEhXzwQUuKRQUHnlAWJPGVxYjjaxePJ28L8+ILQovjiW8D6lhFW JEaGlsaX3Q6UVYni0PL4in60xFf1g8+vJWxIlKK8OTFaaUuMC62Jr0V/B0DZnqhCeX18wydB2ZWY qOxJ1N6kY1N8801ojbfdAr72QMIR2hbfrhxKTMexKzFrsP58LHbGd4Xa43tuwf74gVBH/NAt6Ix3 ZUM5lpiTie3ZsTgTK/tj3MmE1B+DuhNydhzpt5Psdc2sS2aOziWi/XPbk0hn9wmxpJliCvl+dKUa A6KrVf+FX62LF2DfIHuPbiRsSe/L2HN0Kx3pPnxeuZRYqFxJLFGuJ5rDxsRK3l/CQxKruZ7HFs5L rAsPT2zk+BoemdjCcTJcnNgaLk3s4D0gPDqxm2M7xkz2Hh6X2JeJz+GqxMHwxMRhHne4NnGE5yLs SBzn2Mk6gemJU+FZiTPhOYnzYSnRG5YTl8PRxNVwOil4frEH8VzSHIYX0j6p7WfhJbT/aPMcbiY9 K5Nm1oFzq5O54XXJYbzv9O+1WWvUr5Oh7SmZvYD7xHtjeGNyBPq2JVmYWWe059hPa499mfY8jG1r chTXhXfQHl6lgvdrnt+b4FD3Zd6vsB/TfTJ7MR8Bsh+MbcAei3sRwrtjixi8x2b21QzC+2ItjP49 kvdMbW/M3itv2iO1fTKD8EHaB2mNsffRfhg+HGtnwG55n9unoj9mEcJHkmU4Hk+OCZ9Kjkc9xY/w meSE8PnkpHBvsi58OelCPfsw7yXst+RH7E/hq8kZEZGczbEoYk664RcZP9DiImyL9HCci+RSbNJ8 BOtFcYuvz8TAW3xrgF/1x5dM/0kHx83IsKSP1zwyIqn0X8/tyd8ihcl4ZFRyPvc7UpZcFBmTXIoY zuOhMUTGJ5dHJiRbcN0nxR+tX5FJWhzP+PiyrDZanzHWAfG4fzwchzP4uHt9TDyN1GlHV3w7j6kf A+Nkdqzk+JiJkdkxkdpCD7fhczQHkRkJR3RH+mB0d/owg3MbXm/kNfvSR1BHMStyNGWNHkwfz+Qv 0cPpU5Glyf2IY5R3RI+kzyCnoJgW2Za8EFmUbM/kBNHj6fOIabz/c97Ase5Uupf36OiZ9OXo+fTV yP7ktWjvPBG9PM8cvTovNybmDYuZ542I5c4rRE6mxUtcy7mZljch58nkKKxL08HnYsPmjeJ4yf3q z+0yedjlGzEYyOQwWu7Bujgfi42YV8b5Tqxw3pjM9WhP48HfNF/wExpbbNS88ajjvDEDLU+8CQNz QS33uwnavA7M6/rBuVgGA/O6TI42SG4WK1PxibkZ517Z+RfnXJm8KyvH4r7iWm6jzcktvkX+F5md XHOLX7mT6zM5VsSX3BRRkq0cizLtIvHkNrbryPzkTthTJg5wG/Y5sj8clyc7Ii3JTpTXJI9G1idP MLL9LbIpeZpjRKQ1eRb2uTN58ZY8hhBpT/YBZI8M+CHHrY6UHsfOlCXjg+wTkROp/MjpVEG//3EM OpsqQqy5kCqJXEyVR/pSFbz3ZMDj5Wcs+B+NOXItVdmkT1VDN8WPJkuqBuPU2jdZU7am/FR9U0Fq ZlNRqoFjUVNJqrGpPBVoqkhFmipTSd7/sAdyfKKcoKk6taCpJrWY43GTLbUMzyy0FzbVp1Y0zUyt ampIreX5ampMbWgKpDbzc0JTMrWd56lpQWoXt29anNrTtCx1oGlF6hDngBz/M7G5aVWqq2lt6hhA +nifYdtu2pA6yfPetDnV3dSWOsd21rQ91YMYRuvYtCt1Cef2pK5Ax4HUdY7lTYfSxqau9JCmY+m8 ppPp4U3d6ZFN59LFTT3p0qZL6dE8v01X0uMQx3j819NVfIwa0xPZHqJD0rXRvLQjOjw9PToyPavf figH5/wjWpyeEy1NS9HRaRn1WsyNjktHo1XpNNaP/CQ6Mb0wWpteEnWkm/ttNfMckNmjqBydnl7J baKz0qu5TuiFzrrM2iLE3/4F5a/oX1B6xKUb/w4g9QnFW+At8pZ4y70V3kpv9Qyjt8Zr89YTz/Q2 SH2qeIsY3kZvQLqmijfiTXoXeBd7l3lXeFd513o3eDd727zbZ6z07vLumbHPe8B7yNvltWqyCjjm PenN16Tbe87b473kveK97jP6hvjyfMN9I33FvlLfaN84X5Vvoq/Wq88ItXD4pvtm+eZ4Lar4JJ/s i1K7NHrIPeKWfI7vR3fg9/xD28i2p/63vAd1km9MI7kb70GH4T3oPXgP+im8Bx0uAkIW9wqFpABv Q+/H29AH8Db003gbWoS3oQ/ibehDeBs6Cm9DH8bb0EfwNrQUb0MfxdvQMrwNfQxvQ8vJ5zrFaNFF 8iTehlbgbehYvA39DN6GjhfviT+Iz4r3SarwTvTzeCf6BbwTfQrvRCfinegX8U70S7pCXaGowTvR yXgnWot3olPwTrQO70Sn4p2oDe9E7Xgn6tA9o3tWuHTP6Z4TX8Y70el4J/oVvBN9Gm9DZ5Kn/1x8 Vfeq7lUxG+9Ev453ot/AO9G5xuXG7wo3fmmw0bjb+KqQyK87hM943vgHESD/7aO51In5YtENW/XQ iD3HPac8ZzznPb0klz1XaeLNUq40TBohFUJ8kiLFpfnSIpKl0nKpRVojrZc2Sa3SNsgoqUwaI42X JkAmgeskF/EMabbkZmG70T9GdvO4ZjfDcH+2GD2t0SNkPWwrRpr/CrIethUzbCWHLGUy2RC/M7+D rGM22RDbx52wj1y8Jx9K4wqRJbE15JEtPE/2xHYwjKxgC9kTW0C+eIXkU7CA4bCAe2n9D5Ld8vvw +2jN3yEL41W/H6s+Eu/AH6CVvyAKscZFujxa4wexusVY14ewoqN0c3Vu8TBW9BFa0ago1aVpRcvw lvsx3QpaxXKs4uNYxdF4p/2E7ue63WKM0FnGWyZkrUeZ8W5P2UCRFkiLPWM84zMilXgmaDJpoEjL PHUelyrSCs8MzwxpFdUMEGmttMEzm8RN4mORNuOoeOIZkdo8828VaTs0zPcs0mSpKtIuz3LPcmkP ccutIh3wrPGs75dN3FaTVk22DZTgtuBOz05Pe0Z8Fz37NekYKMF2T2fmXsH9nqMkm6hmgHjHefo8 J0j4fqdZAqWSlY5ncQXE23urdk9HoBYaOjIz67mgSrDDc9FzMdhK3HerBDtpfNf6xSXp+8WiyiAz dUjqkqxSfr8ckwogJ2/MREakbqlIKskIVvycVD5AegiXpApIJckVrf6610hc3T8il2eRd4hUc6t4 8ySbd7hUL81k8Y6UGlTxFksRqmmUGr2lUmOWnn7xjvZckAL9EpGSGVFn33OaVoTs21sF263zTvTW so15HTwT3ulsH95ZVJqD0ZZ7Ja+MHskYq6qJLeUoVqkzeCJ4GtZwFrN/ATPd442S74yh+RvvmeBN e1q9C2mWrd4l1L9m70qyZbd3Ndn7fO86Se/dSLbc0tjs3SJV0n1Xkp0spbZbvTu8uz3XvPu8B72H qcds/y3eIxilm1bskGep9zi1cHlPec+QLvZajAgtVV/h1V3qmeE9T/3vpTFfpvrl1G48ed1y71Uq jfHO8QnPBJ/Zl+sb5hvhK/SNgi/PUMVX5hvD/uob75tAMslXR96qqB7rc/lm4G50J99sz1Kfm33S R5qppeKL++b7FvmWetb4lmv+xx7Y6mvxKWRrVthbAZ1dI9mkSt96qcC3ydfq2yY1+HbS+tJqeVf6 2n37fR00c+VSDfVpjdTl6/QdpdYnSE5LFb52WCCPEmvF7UjIYniWfGcJF6Qa8uEWXx/VJ33X/Hrf ab/FT/f25/sL/EX+En85zbXsr2B791f6q/01fpu/nm2cZhZr7p/pLSVrq/Q3+BR/I0nAH5GqWehc 0l/hX0AjsEkz6cxiqcG/jO2UuNG/wr/Kv9a/wTfKv9lzwd8mBfzbyR4jPDb/Lv8eumcjWWiSxxe8 6NkZ7AtIFBn2B6/R+pym8dSQvbTIetlCUaBVtlKk6PCt8ffI+Z4RnvbGw/56uUAuYr8mm6HZkkvk crnC1ypXytVkoRw5+iia8ey0BtuD7WoLT0vgiFxDujjewYLRUo0yZMGk66hs86yR6z3b5JmeDklP 7dqpPxflBirt9DfIjZ793ip/RaBKDsgROYkoqEUyeUEQkdVfGTwaPCovlpdRnDurxjp5hbwKd6M7 yWs9F+QNHM2IL8ob5M1ym7w9MFymiO5vUCMXYpcleEHeI6+QGuQD3BP/AVontp0G/yF/F9uPKt6V 1O8O/zGOSf6TtMbdUj2tzjmyq3KKB+X+Hprrzf5LUrX/iv+6xxUwBijueM4G8gLDGw83Hg6MpBXc THZz0TM/UBwoDYwOjAtUBSZKjb7TPO+enVJloDbg8FwMTA/M8p0NzCHvWU4BRpYidP/TtD+eC0wk D7ZSzGqkM9FAOrBQKggsCTQHVgZWexZJlsC6wMbAFs/RwNbAjsBuyRrYR1qtgYOBw54TpPl04Aj1 yUp9OR44FTgTOB/oDVymPnaSbovnIrW8GhRBs2d5MJeizTDyJRfZzQi6ppxspTJYSPbbExzl2RYo 9ff4e7wr/d2e076jwbLgmOAomgd9cHxwQnCSrzNYF3QFZwRnB91BX7BOstFR8fUF48H51HpRYKW/ K7g0uFxKBluCa4Lrg5sCK4OtXgnZ1ON/e8L8K3rCDIgoPtUwnP83GXer0H1TL/Ldm0naSLaT7CLZ 494zm8R9wH1g7om5J9yHSLrcXag7RnKShOu6Sc6R0HWzemf1untILrn5GVZvdVmn0T3y8EQj8ESj x7OMATmvEc8yJjzFmJHz5uApxoKnmDvw5HInnlxykfNakfPehZw3D88sd+Np5R6hy5PyIhgTPnfo Hid0bgcdq+g43Xh33RZ37e3AZqPjVsKOj8FuFbYGFXX7bhMHCYcHwREVtiQdj98ebIvpeErDGQ3n VUw9rR5tawkbqNxLuHwrbG10vPrJsO0i7CG9QoOZkHszMLYBmDpsAEb8BSgkjBoEZYPoZYwZgPG3 BxfN+9QJhEkfgzoVruMqprpuEzMIsweBW4WL1m2q7/bgorWdqmiIa5ivwnVePTq76XiUsIiw9Fa4 yAamLv9kuC5rOlo0rCGsH4BNg6B1ALb9BdhJaB8E+wkdg6BzAI7eHmzn6HjCDf8YFHTO1kO4pLU7 e5u4QLg4CE5oOq/Tse/2YDfS8doN2PQ30N8mTzsOJ4ykc5Yb98qGvVi7v/WTYS8ljL75elv+ABQM Ar52HB2L6FilHScO3p+Pg62EUD4IKgiVg6D6Zthrs+J3drzNxEstjtkd7v74Yp/uvjl+ZOwke121 +e6fo1lZczvn5j71x5TsGJDxYc23eM/I2Py0EQNsuk89b5cIMiGqxgjeX+wL1Xoek30JoVmNr25e L4qT9tWEdeoeYN+oxferqr3baU4y8dlOe5p9hzpe+25tHkgnx0vWCbBeWk87xUU7zZ2d+mBnvee1 +dXmk6/FPpnZw85kzTPpcQhVB59z0H7hyNX6NXCdBqxR/56SWadmdW90DFP75hiRdf1VdSz4e4e2 99HfjkKtbmsWdg+CgfvykUFwPGt/zdpj+9GbhQH7a/9++V/ZJwvdN++FZe4be2DWftcfswiOSdqR 9i2HS/Mxih8O2pMctAc5aP9x+LR68mHeP+C3tao/OWifccTVWOSYr/mF5geZuMi2xXo4ziE+ZXyk WY1bfH1/DBzoWwP8KhNf+n2rWev/Um3Nl9+4Hu3J3xy0NznWqP120J7k4D3otBaTeAy0Bzm2add9 UgwaGMcHa5Pp8yDxuP+c5QY+NtZ9Ujwtuhm3xMnsWFmRFSOz4iHaFmltKtU54Bg9jexnWpkKzm14 vTmnmTZGqyNbcdZQmeOYlr9Mo9zI0afFMVrTaWxbS9V45uS55/nScoJpdVos4/1/jRbn2P5oj55G +qaRPif1dxrZzTTSN43sbBrrJBubtkiLn5l4uU3LzTJ5U/xGHIUuTQf6uFSNl+jXwDg8IAb35zCZ OMzjZF18jmxqWkvW9cu18YxX5ws5F41t2hqtbkIW6gbBwFzQPQi0eR2Y1/VjURYG5nWZHO2/kpvt dN+cf+1338i7snMst3Zte9acDPQt8j9Hp/sWv3IcdffnWA7269NqLOqPV2dVu3Zc0OwpU89t+jT7 4yPFFafmd07yMadVRba/OfPVGOEsUO3TWTJIHkNwlmuoUIE4yPortWP1DR9kn3DSXuesz/I/auec qfqbk/ZoZyMhoO49GSAetanzxGN2RghJTTeNw7lAG6fW3knPdM5lhBWEVW7EIudaAj3DOTcT2tT9 j4E4STmBczthlxqPnXtUO+W90HmAcIjQpc3XMcJJ9TnBeU6dJ2eP2t5Je4fzCuG6mgNy/M/EZhft Aa4hKlgf9hmybVeeOu8uykFdI1U7cxWr88jr6CrVzo3WdIxTY7mLckQX5Ycujj2Uj7koD3NRXuWi fMolqfPrkrU4RuN3RbVjWrUHF+VCLsqBXLRHuFbesB+O3ZwPuCgXclEu5Nqo1Wsx10X5gGurqp/9 xEVz5KIcwLUvy1YzzwGZPYrKroNqG9dhtY4/jTH0wNDX//ZpjL+md2XGMuNB/hdV/WHxEyFyiggl hHJCBaGSUJ11rCHYCPWEmYQGQiMhQIgQkoQFhMWEZYQVhFWEtYQNhM2ENg3bCbsIewgHCIcIXYRj hJOEbsI57Z49H3O8RLiigdtfF8JiVOstQwh5Wt96tCONwTKcMJJQrNb3H0sJo9W+WsbdGLOlijCR UEtwqHos09X7WWYR5hAkrV4mRAlpVa9lIWEJoZmwkrCasI6wkbCFsFU77sg6ZtrvJuzTjhu16/Zl nT9IOEw4QjhOOEU4c+PI82M5T+j9C46ZubiszuNfCqxBNupVsH6sV7fW9vwAXFX/2/nMMXN9Ru8d ZkKutt5Uf8ewG8c7RhAKxU/sdXaXfYZ9tt1t9wGKPW6fb19kX2pfbm+xr7Gvt2+yt9q32Xfa2+37 7R32TvtRkhP20/az9gv2i/Y++zWH3mFxWB35jgKgyFGCv8tJKhyVhGpHjcPmqHfMtLc4GuytjkZH wBEBko4FjsWOZY4VjlWOtY4Njs2ONsd2+nuXY4/jgOOQo8txzHHS0e045+hxXHJccVx3Gp1DnHnO 4c6RzmJnqXO0c5yzyjnRWet08Hmqn+6c5ZzjlJyyM+pMOxc6lwDNzpXO1YNinXOjc4tdcW7VZAfJ YOXdJPucB52HqXxEk+POU8AZkvMkvc7Lzqsu4TIDua5htCfcN+gvLgjtFxcs+MWFIfjFhVz84oIV v7iQh19cGIZfXMjHLy4Mxy8u3IvfWrjPWmR9UtxvHWutEY9bPdaAeMqqWGNisjVp/ZawWxdZnxVf ti61flt8xfq89Rfiaete6z6x2HrI+r5Ygl9f2PL/cc90umG6KD6v0s7/m3xxhQaKLMXVGmo02LLK DPKa4plamds1aOVGDQENFHWLKeoWU9QtpqhbvExru0Jrz3Wrsv5eqx03aNicdc827e/t4jHbYZIj tuO2U7YzJOfBZ2y9JJdtV+3CbrbnqmI7bB9mH2EvtI+i2jKqL7SPsY+3nbFPsE8in4RX2i6TX7rs blqru/BLGwK/saHHb2wYrBXWCmG0TrbWCpN1qtUpcvB7G7nWudZGWoegNSQesMatCVFkXWB9RhRb l1j/XpRY91j3iFLra9bXxKPWHmuPKPt/rF13/evGLxHPJuvQXb8T5SEoP4nykyiPNdYRjzMlUd+I +h+gvIK4wvQKynUoq9c+iXI9rn2CeDTqxxkj0MPXVkB/g3Ess+nr/Nkn0wIq5xsnMZtSxDvQ5iW+ 70cof7QXfViC+hDKY1Eei/I4tbcaLwDH0IZ0fvR742PE3dqIHsPZr6NXGKnxcxhXED0PcNlwAmUL zgpc9U+oCeNaO2ruQvkpXDsP2u5CT54Cm9BmPNr4iMegPAblCmMV6mWUx0MD6sFjcbYCZz9r/Dyz KYSeVKEll8caLqGNOg8roG0PtPFaPGFsRb3KleDpaCNB5y7opNnQf5nvqH/c5Cb+tom8W59G+Snw CVOceBG30enBL6A9+qkXzAYfWr5g8hBvgc67uUb3Npd1H+Ds82g/Ge2/h3I+tH0A7kb7q8ZfU73e +DrxdOMxvguXdX9Ejc/4NvEEbiP6mHU28H+A9zIbDGg5FXqe5va6d6GhFeUf4+wUtP8T2pehfA58 APwztH/f2EQtHaZ/pvIVtlu92fQala9zva7RdJj4jJEsQV/AbcT7pueI/51Zd06rITZUQE8BeCSu 9YKfB99r/BPOfpPKv2HWn0J5D/gI+AVjA6+R+X3wLnAbuBncy5wzgu41Tl1BtPy2mX9DpRHlp8BD NW4DN4P52nvR8iDObkfNCdQsQs1Gdd25TLwL3AZuBveCuf1UtFyIq4TKph+yVaD8Anq+BeV28Bat pg3cDO4F19BY9puaYUUBZtz9bfAHuPZ5jXeB28DNYNbwPGbje9zGsBb8PfT5A3A39HRzn3XvmzqJ L4PfN70IjoLngmEJph7ScC/W6wpadoMvaPwcbOAA2wZqrkPDdWi4Dg3XYRVncPYMas5oNe3EBozl QdNB2EwnOAqeC36TGZbQrdoYl8nSWNubKL9POT33gWr0VRrTWPRvsJXqR6JmJGpGwrtHsmbi18Ht sMytNMYFqn1Ccwv4ee1a9osEbP5e/p+46V4vgqPgueDXwT1g1nkK157CbByBtiMov4DySxrz7B1G P7+cw9qGqqxaGspbVDb9AisbxTry2Q9Qft/8BZ5hlblXAjX0TMtcgPojWNkjqNkBHykBFyEKPYn4 9m1zKfGzqH8Psegyyqt4B9H9K2LaUDUeckvdEJOf+B5Es6XgezEb29CmHL7wFspfBrdqMZD2Fx30 63OYzW/y6pu/y7NhQiw1unlOzLu5bC7nsuE8bLsVdlIB6+3EVbtNO/ha4zb0is/Kajw3c+R8jJl8 8xh86hj8iL3jYZSfx9l/1caYQH98uPZltH8Z84wIYzrP88NMsZpZXa/HzbQ/6tNoPxTlg2i/SIse bYgDzbw7wAd9qH8BfDf4YdzlbfCfcup4NXO24r58djKvMnkul/M1Zp2f0WLyBiqPgE2+iZoi8Enz /by+iLcvwZ6/iri9k6Oo6Shs8gi3NJXC9ixcQ2vHNpzP8VzXqXoxPSvTjoB1OcozTHGgHTbWDq9U +XX4Szv4dewgHKsL+Fqaz9dw1XPwoOdgh3yXFPfKMJXPGqaqUcVIuYruAfj4JFy12/wh4gO3r+Te kiVzzTn2dLLwt3hnQc8rtPjzHFryXTaDnwcfMD/CZfP/hOdO410GnnsKZ/dorHool2eYH8PZHtT0 oP88w+PNb3KsQ29f5N1Q97+xJxagtx+h/hXM+QMoF2EsZzhT0tcbWX+X0Up8nrNH/X3MtF7PIarw qq3DGDewrxmexD74KLOhyEg1+l9B84/Q8gNo/heU/wXlKdDfyTNPzJpt6HOEWWxH+QL4q6YhgvMK 1v95rFQZNHSp+y/nUZQnfBPRjy18ObKXC0YZo2B7ewhn16Hnb+Jee6GtgEdq/C3PhglzYvwQ65vm /d0wnLUZ3uKy8fMo12K8vRjFh4gVH8ITC9BPRHv9Hu6hYRzGfofWW+5JMcrlRspddW9g1D83Ujao m4i+HcK1sHZ9lVFhH8dVMzgH1s8w/BvxauNk0lyNddxplNg+9T+i8jFoe09j1vYS9HwGOiuMRuJ3 mcnqHhCcldEMGHIwD/+Iq+LgFtjAeSPP3jZoKAX/AHpcKKcw9hcxz5MwRhlXvQc+BQ7yjFGWxaNY wlkrle9gq8AeFIa2RvRzBvSYTWs4AmjWyKP7Bfpz1TyK2fQB+C3wXtQXg20cE9Sck1vqx4CrTG9j H+FyrZqFQs+b4Deg5w3oeQN6/g/a+9DexzX6KGomoMalZq1cFn3cE+K3wHtRX4wytx+qZra4y16V kUdNhZ6pfK3+aZSfVsush3gv6ovBD6BmJOwH+QZ0vgttl8Gt4B+Dtxp5B5wCnVOgcwp0ToHOKdA5 BbM0hTUbyriloQwzcAAaDqD8M5R/xqOgWd2A/jP/VB0vl6lvG6BnA676ABq4phL9/FDjw/As7sN0 0xPwVl6d54ycbe7Xng74Lq8bj8Nn8XTALYWayZ9Fbn8fngLqwL+Ctvugvw98HLwV184C1+La3ah/ D9xpJCs1F/O4zG3MRpnbGLtMr5Kn417muIn3qQbMVRQz8B9ob+VZNbfBr59Eb9+EnbwLbtGeU97G 6nTAJt/Gqr2NmYF9spfRDJTwSpnuJV6PZyI9Whai5ZsoL8XdJ6j2hrX4J64xGLBSBtRPRft3wR+C W8EdyORbzedwF675E68LrS+Xz2mMtUZ5t2o5XEOWYMMK2rDi9Bwtlhp+S8+VLtOdzGZ6bv3oN+yJ H/3GRKts+BEypcM8J8bP8b5j9HLZ8Ar4+6hv5XzM+BKiItpTbsx50adxrR15UQgtf8nPm8Y3OEob 8PxoeJqfl415OPtTXPUPzDn3o344NFwDb0V7N+xkEa+F4Wc8t4bTKE8Bj2U2FvEaGYthG81o/xos 6h1m02a0GQurKOCWhu9gZf8NZRlnH8XZEbCWGmhQn1W3gutwr6eQFbyEHbCWZ8zwLnaQZsTGg9g1 Ojg/MWxERroSe9Am5IcLUfNtZDW90LMPfAz8Fvgd6DkL7gLPw970DvbZ3cymX6K8CPwqomsf9qD/ wfmb8TFkce9o5V3gNnAzuJfP8pOX6QLmfypa5oI/Z/4asfpEhidEw6sat4GbwazhFbScj6t+xjXE XFPPNaY5sIoG5LrzwHZwFJlhHPlnLZ5JkcEaS2A/v8C90NLQzLHUiBpiHsV5aH5Y413gNnAzmLSZ HuVnUvNrsJk3TMPpqjuhbSPYA8bzqTEfY/8Wyrs03gVuAzfjLI/rWzxXxr1cznnA/EPwLNaPq4wa 8/zgGcGwlefB8BSyvoUavwiOgueCYUucuZmHYN2/gZa1HBtND5veoPIfTb8k/iHqj2scBc8Fvw5+ gu0NZztQ04Ga73Cua/gJe6juGeTSheAvgOchtyzCc9DnkLuWIyteCYuaB4tdyXmgvhaaf4ryt/D0 uhN9+x3qf8d6jHb0/zTXGO/X+EVwFDwXzP71CPfK+Gl+hjX/o2rz7BH6s9B2J3gjMoTF8KN85A+x /8veuYfrVK0Nf8wx5nzWwTKIRSyyFzmfzyE5RY4JUZJqOyYtEssi2UgqVipKJacklZwq6eCY5JSE JKSybUlFOS6yxbPecf/m3N+b9XZ9u/3t/d/3Xq7rN+95j3vcc4x73GPMOebzrAf5P4vSLyPOhkPg XXAjNi6efmm5SvChvFd0FJsV1FqBnEoEzhGl/cFC5kIpKQ3JjvWI7Fj9H0QTrJGW+O8in0D2yRMf +9HBMUYhpOxed8ju1UVDsmK7P462ScYq5BW0fAWl4SraBOYLUh2VjFdQPNbZyfNEH5Qmk7+BD0Rr qaw8q1lLp2KTjf3rzLifmUf5WFEbsALPQF4lK7DLK1crWMe4bMInu1fzNJ4H4a0K8ruy/3U7XCkd guVqYeIayfBExW7reTzzziQhXO0/YXczkRl6lBn0DrOjHmR3bJbg4TW8Kf8RV2s1ft6Ttvm8p/LZ EbuxkHtoP/bCw0R2Ho7D3czr43A3s/U43E1r33byE1zxfaJ0UZ4BzExWp83Qp22rZI/svwwzhYY3 J2Zr7FG53zGLpyK/g/2L1H2CmT5RNLEBshrE7kX/IfYHYTc4N3ZOmNBD7nTYvCKZk1ACuSisg7eL 2E+jzclyd/ALyXsqv0aQRv6IrKVtwU8y+n4h5s7ocL9JPiwOtkieiN7/NtpTyxvLhexxGjKvW8s9 IqENY/cFI3WtyLHkIL8rPc89a4XsiF32yprQUkoT2nBnmSuzya1XK+FG1qWVUO6h7XiPVAX9AfQH 0J9Afxj9l+h74u0brhLuvEZzZ9wNV8h1g4PSoxjvY80ydtzzuMdNF3v9keyv3Sp3FxH+hTbLutRQ 9tqx/Mz648zutUIXyW2sMzVoiXA7pfl4LsonTz5uPbzEXJjNiiGlY+DEaPWQWntZNz6QfbezmYF+ Bu1nvYqNdfK7tLmVX8LxJaGfTvzfpKdfMTpZ2NwaWYqmFPugj6WP/hWyRza8VTbhrm0fu7YtrMkP EoeSjHs19mUvkC3FArcWxRKp9QtPCG/IfjwY6Ludhf8ka+xg6g6m7mTkBXItfQ1X7M24vMiuvy89 eowd7m5mhI/mCdmV+1Vo5+3Yn+SKtCqYgDxa9ubmPuTQZhAe6sM75HnJPTfKrFzhXyn3BVr4PXke 7qabkwmt6XsNs9r1q4f4iWXCUUJ/rr+ElVNmxPUiByODkbRK4tkVm/DzjjWsZoGUmmFyFws8/BQk /ito4Suy7zb7kU/Ibt3UQm4tu3WziL4UkJYEzCD/Vr+408yh/ePMCcexxmWCf1Q+5Ym9zDNhL9mt u95Je0rInt1k43NYRIlhfnir7NODFfA22UeYX6XvsaJEoB178EPU+rPs000R5LWU5tCeH2nhMvSn +CwjXSITq8jVm8C76G8GrB89W8pdtTi1tsnOXX8uO3fzGPEpzvvDg7SwF2zH6ExiHNvLqLnsddRL 0JSknTPYxUyFTUOZHcpU5tpUdjpTZVflSt1OJKjAE/U6LB+G7wSPsB6KbGH7kHhoj4f2eGiN5XH2 elVE41dBsxfNDN+NuEddXRY+yn75ZvbLN7MLa8j+7gXZK7lMcPZ6AJZfcsWiPH9Ww1s1qeu3RH4o JJqHxJvjGvRl4FXc2V1kgs/o3UDf7QrNLHw2xH/YuybwQdl7uvbTC3xWwWcVenqcnh6XWPm3iudY y2AXfFiyCA9vhiQ+vZHbEIemsQ7ESngT+/f9sn93vegg7778z7huB2bQV3g4g7cOcreSVrmVRzjT L+d4pz/e6UeyorJfdvtrKZ0ES6Jp4k9w8hBf2lYNDeutfxVj8TM8JTRbhcF2oV8NPiR1g+pcpQg+ 28JGcD7eJoaxwsMJWJEIPwAHyYqXsFkikNiReJ5n33cvb+kHiZwQ467XS0qDCkR4K5YtkfuJnLBZ vCV2lCeTIM5+sCH9CnOjAaPcknGZhZyKh8bYLJL3A+bPEn8/jVF4k9woLXcxc0R6Z5YgF0Qeg80B WI1aZWAqo1lU6gbzZMSD+ejrYPkaozxJZP0zmoax+nCa5BuWxWU0XZ48whoo3InPxcjlaHMqMXxQ 9M7yPK09zwzlk/rc15WnTO7HyEvks2xYO/c15EpwonxKHpW+DudhPwo5ZDE4FX1YdynyUrwtht+g +QZ5HzZOrzvnyhvRavARmAWbwn1wjNDTQpWDpjZUQtMf+Vn4KrwikuVTg73UPYNmKmxFraeQUyk9 CC+g4Sq6C5oTyKH/xlz9HPyS0r/DNXgz2LSF3dB/G8nShgVolqBpjZxLrcrIR+B6+A48hmUH5PPI MeQ4LAYPxSvLkyHtwV6dFY0JI1MSponGo9ferXAH+q+RV8Od2ITR6xxv7jzUDcdCZN0UzoFzw1FA rg0VfBa+Gpen03Vh/EXjvQHPUPopnqeHvUO+Mow8NnFsSod9QXOQVh1B/izqS3P6lejqjqLuaNEo 4uONxbJ2vCO9mEHLZ9DaGbRNOBXNGXgMTWmhCuWSMA0e5orlYTqsBb/nWmEGPo38HUyLt3DsilyY kZ0Q5qTo9VLkqnHZfX+B3Ag9WaEThDEyLTZC6K/AwyWJQGyQyMFWxvrVMDK5M+XTRuwfD3MDb0/T hl+w+Tux6iyz0s2pYuS/cEo4ypdOy4yjp1kRNUx3vBI2hWMoHYO3MaJx8RT9DehrQxUxXe4LyM9G FMuORHtvFPl0RmEOFLmV6M1TlOZQqx4tDDM8hx4Rf29/OCL09MUwn5H7YrOcKO0KVw+Jlb+biIXz NxW5JJFZj/36eDN5K4WchZ/hyLOFhlls2pKB54nbVEoZTe8q9Mckht5F2hwjemn0KJEoxYUur0JZ +kisvMdhmIe9IqZTdw5+xH4HPndR+joknuokvT4KZ8NPcws7XqKPyWjeQr4KOZ1R64S8nZb/QGlx kd2KscBpmlE6DM6gdA4RINtNLeRwpqdJxHQl9OGM+BjOxHM/PPTD854oSiKHK9s25vUGZuv3jAKr iucT+WvxE66E2+GPuXUkkshbwzUQy2wsrw7XQK7yGXpmnz+OubMZ+Zfc1q6d4X1kHqvNFxIr/1rk G9Afx88vyKyEOglWgWXCOYvNZvhetDrVc+RO4W3BZnk4oyErgJ5GlJpgsxuG6wZ5q7kvuKi6PYVh 7nuvwaEwXCsqwufhcPSZyC3gQDLwAfSvR/cCyefxkSwRCO8dPbFnDdG9w3sKoxkj/sXgVLgDroas 595bjFcu8ip4gbo7w/FCJpLeCeT+sCNROoecn9I1yG1ht/g5aSH6b/E5BS6Bi6P5G15LMn8zmX+O GdENtka/HrkB9g/hjfuOt5Grx8kN7oweK7kpjuUasgXZO8dqvAd5MfruyOG6yujHFpJRBeHDrDA8 n8RK4S1ckbrR2ndyZ8lnTHjIjT9Ofx29TfAC63AXVpIl8E4sL7AOp9CX8D6VGq2r6eS2rAyN0TQm eo1ZVc6hz08c1kSUtddg2TaieFhA6ZKI6dx3MohhOu2UdSmd0m3wHep24h1jDu/wS/KmsWTsbWeZ En27Rr6d0oDv5Fzi3XIl+Zajt0OoF/L570b2nryh8r7z5Zs569iR8WmLbhnLJzOdT3C2i6w/RD7t 72Ovymde8nyueujyMi7yRsJU9u+Rq/svyzOGyPq4f0qyUWhO+68qeb/kLNXXQm8AtdoIg4W804jB 6v5omZt4WOC7517TEw8XpTTWlVpdYF2+n3AeJvppMuLmQYmY2SA2Iutx8hcuOkNohpgDeHOWaovQ KxPWQrNL6P8kdL0QzjNPSC/w01LeKuhNoR9KuwuD8Xg4Dw/AbLjMyPucykK92sjuPl329fo8mkJB D9op3yJLEY3aJbL6WujsRd4i9kFj/KRTq6aR7++VN9Nl9M082rZY3mlTaxlshKai2AdrqXU4aomU dkczx4yS1QZ9k4jyPSI/8jZPokTb3hXZO0h7jPaEQY786g2y1lo03lpK5RvIdbxDfGNWvtXWSWc7 VpO3Lnq1fkpWXf2YtFy/IvNaZP2oftRxjJZPt7XYe1NhF6G5F5tnNd911FMca5hJjm8hVzWv4cfJ 3hksqatbUfcp5MJ4OyNZ6v2Vq1/QhWUua8mK7roY7Swo+a/5lF/HnKa5LiBzWVeQuSz2XkfYWajO Co3BQxu8ddPFZc3UO/Ap8jn9rdw1kBdj2QEPcer+CfkI/NCTCC+nDUe9q51ldU/ecLp10WkuevIp 8yUvR+4Fuqasq3ocn9rLL8se8w5Ke4Rec11UNPp9uXN538k9F5aE1YXOm6P6FnkKLOQdwPKAzHTk r71RcjfB5w5vvuM07yu5H0lL1Pd4OCst0ReVkm+h+yeFsVTkvyHn59vp+ZCvQf8GGufHfynmfPo9 YEv4k9D8AJcIgxT0F4Xah0+gqYjNHcLYXiwrww6UlkHujdwdyyNo0PvZwoRSyBUo/QDmoOEq5hPk fsjjYCc04+FIoUdrdRNKP0Y+SHti2EyFCyndiPwW8s/wJngbenpkLlE39LYNPgzvgV9gWReZfplf ueL9yBtozx54FM3LeOtLrQZYbkVfGnkp8mxi8j7yCPgirEStlxLc3SdWIhwdkf2fYG44RiIHKWgu IjcLxwjN0+FIiWzugL3hELzdGY4XtRLCUUMmJrET4ahhvwQeobSMMKEUmg9oWw0sJ8OBYXy4+vW0 cF0YE9G4e6LIYcSIsz8PNuaKRNs7RSmR1KvxQNYF0+Am7OfCXfBGSK/9MNNm084x2JfDAzEPLG0g f3R5ci8J+8PYLEJuimWYYy2gFSYukrqJRWinwaY1Ht6DqehL0OuKRGYr9s9Syhzxd1OrLNcitmZa OO+I4V7qEls/G1bAz9vY1MQ/8dTNqbscPbMsCHN1ANcKZ2KpMPfw8ykylnoStY5h8wwMM4TomaFh JnPd0sRqqdA7hWYm1wrzsB68Fnam7k7kOnioDb+Hf0f/KNfqg3wzfuhXwNWD+lg+iZ/pyEResz74 82EW7IZNeMXPYZghqyi9FzIupjhXvA8S+QQ0/hmuOAp9uKYxB/1wdjNzgwJoCkFWBkNWGLzpcKVi VdEnsaeunwlfhwvQh2sjstmBZjPyAa5OXhnmjj5NLbIuCGdT2KM12CRjPwtNOO5r0XeBaZA2G9bM 2ER8hq0iK/yvIHPKJzc8Wh4bS60Hsb+AzEz0R8N96BlTQ/yDnuhZo3xWLZ980Kzqfn+4EvsccmYc +ROuVwsha1HAPDIPowlXzuPUDceUcTeMVIxcMrdD5pqZAsnehO3CRLIi4P4VkO0xop1A32OU+tgb 1ijTEN4kV1dK9iD+S3H5tKgHbAl/Epof4BJhkIL+olD78Ak0FbG5Qxjbi2Vl2IHSMsi9kbtjeQQN ej9bmFAKuQKlH8AcNFzFfILcD3kc7IRmPBwp9GitbkLpx8gHaU8Mm6lwIaUbkd9C/hneBG9DT4/M JeqG3rbBh+E98Ass6yLTL/MrV7wfeQPt2QOPonkZb32p1QDLrehLIy9Fnk1M3kceAV+Elahbgrq5 2DRDfprSIch3ok+A9CV2AtagdDIcCK+n1jquW5IWhi2nv/482Ji69No7RSk90qupy+gH0+Am7OfC XfBGGLYwHPGwX2NgOTzQ98Dik3HU5cmBJOwPY7MIuSmW4Vi3gNRKpDSxCO002LTGw3swldJnkclM fzc2ZfFMZAztN29TWhM/REY3R78cPdkbhDkwAG9hhoe5+il6bPQkNMcofQYyOpo4mKFwJt7CcawH r4WdKd2JXIdateH38O/oH8VnH+Sb8UPLA64S1MfySfxMRyZWmpnlz4dZsBs24RU/h+GYrqL0Xkgk TXGueB8keglo/DNccRT6cDUge/1wXpDzQQE0hSBzyjCOBm86nOPMR30Se+r6mfB1uAB9uKogmx1o NiMf4OpkgiHD9WlqkSdBmPNhj9Zgk4z9LDThyK5F3wWmQdpsWG1iE/EZtopx97+CzAKf0fdoeWws tR7E/gIyc8cfDfehZ0wN8Q96omd2+2SCZiX0+8OV2JDVfriSHEcOR4rRNMQ/RoaY2yE5b6ZAci9h O/nPWAes5wG5GiOGCfQoRqmPvWF9MA2F6iv9pZK3IttdadnwPYZ50mnasO/uL28bzDzeJLSldI78 baxJl++nmem8S9Gi0T+if1L08gULJX9tIZqewmCX0K+OPoe6Qyj9QRgbitwftsHb8dCS63aP3maU VfKOQvaGc9A8Er3xqM7f1slblHa8P7nA+5BU3o0sRj9f6uqdaPpT+hyyxsNxmAUX0PcUoR5HBLrK GxK9ibcWdZHrmvekrtioXN5XFI7enziqv4lNUBs/XajVkjckjUTjFfZnOX3R6N3IYt6BLOZ9iGP8 6Vx5T9Upd7usvcjdZW+rd4rstULuQWlL5DXI+7AcjZyI3IjSj6h1FE2h0BuaQ3HZ6VfFphC1asLe lO4JSWka8gVKX8BDWfSvoK+PXJnSGPLdyI+FbRDZ+zJsA6UjRY53yT3nMqE8mmWquON+5DkimwLs 5XOFpgk8jeYC8nQs/yoMdgl9D72GiylNFHo5yMdhTewVNk/CynACpVm0YRpyb+QFXPEYNqOQt1Ca gZ9k/K+H86OWS0sGonkfzWqYDempaUOpRTMuvor/hV08r43Lm8B0PA+O2iD6r2WMTBOh+pq6S+EU vPHGQx9G01Vs/PJx+a5aU0qbx19zjKsOTl8Qm1qi0SfDNuN5nrQhdhWaNSJ7U9B3ib8l+Sn2/gZK 90ip67uMTgqeu6Avhs+naH+J3AuuneNp7Vnatl9qBUPoyxH0c8m6MVLLq8+1RiGXwU/N+EU+Qbgo 8YTZQvc0JTyIpiQ2R5ALCc31tKouo7aJa43Ec39aeFAY84ltxTBDcrtJ1omNLiQa+f0dt0Iyy/yC 0pdYMeyPiBzcgE0Kmh5hHhLtklwlhcgUkoh5j9Lr7nF5N5tBCxcgJ8dvlRyLy9vOwrAjV99ENFoh 9xZLL4daNZHPYbkJD1OQJ6PfQzS2oS+P5gylU9Hsx9tUNE2xPCF0Kw7jFeYh7e9AX/5GGw6SCWEm T5Neu13AAaLEuMNxjFQO9nE8VOdajSitSf4cRN9A6NZ3GZe2kY3wMDmwC887w/hH0ZCWt6QvB4lV UfT5YXcsM6LrXmReXCT3TpMJoaXErZTILrdPk8licyecguZWLNO4VhqW26m1CZsZ8H1KO0bzt7br S4w2L6ePn6IvCT+gPQNCS/o7OOy1WLos4q01GRWLojqPrCYaEhlvAJ6fYx1YS/TWR9cSP7UZqaLh SkWt49Raj2WcbK+J5XIyM1XkWBlVgExbxYhL+2eFMzqaI+KtJ2NUFv6ZFv4UrXjFudfIVbZFc3a6 K30znMviza2Wz9Gq2tQK11XxPIG3xMdVX/Kqr9zTczs7+Ray7ig2rAMmnEeTqdtRf0Lmr2I0pY/r wrURy7HouxL5aUK3Lq1irZBVJRyRBTCR0nR63YL+HoBPwot4bsl4NYNlYLvIRla5MdE4ysr2jKyZ Lh9WMZteIysu8knuRXL1Ivl8kbEQ+TxxGxfdxYqjkV7PoKeNw7sYa85xRme1MIEsSuAuY37Asi/k HqdOSh66Z+BvWANPswbKCtOVdjYiS2uSwzvJatYiZzkPS7F/A30Glm2Q26OfT8v3IC9Gf0N8NxzC 7Dstz+Rylfj03EOMVxeZrYzpjfSrTHhfi3/E5/VFpLW0fDx9SceyS5xnHuqWVKWcz7RoZJ18aYl4 VorfeVO+/J1O9KZRqJLRJ4teKdHEb5dvWcd7yDfh4/w9SDwZuRZyLeQ68j3teF35Lr3TD0G/EPku +f6YfDPfyRuRjyP/JLL8FY+ru1J+5QZ9Xfk2oPOziN9mOcvv26wWyt8RKCV/5x5Plb/miKfK34PE l8Uy5FduEh6SX7kR+dIakePjY0/Jr9wknBT/scPChBPIX4n/hB+Qf0UObTrDOlj2gn3ld2+kbZcO hm2OPY/9POSw1lHanIO+LPqCwoRm9K46PEF/J1C6HCagvwbLFlzrJ/Rb8VkbTSMiE2ouUHo79tlc cStRugDHcvXmWFahrljWRK6JXDu2Bf155Cr4CfXlacktyJWQb8PPXmFiAjK/5JOYSOntaCbhbYX8 Bg4ersFDLeRayHXk7+Wd/WfIRWERarWizbVpc29GeTY9PUspbYu9iuYuuBHmUHqlY42EN5DfxOda 5MnYvA2fQb8ceRfyGWmh/AqHa63kYR0+lzeXcpGJm3ySHq916UdpzyXGQj55d5rTUnppjUQy1MTH wnRILTzUurQBS+peoteXZiMfxudHyHuQj1NKRl36Es33+JFv4CiV7E1MPKpMnweGZqjUu4f2u1eN yeiVOVgtU27nd3OXFunK7Sxyc1URlaJiqqS6WhVS1VU91VA1U+3UreoO56OzelA9pPqoe9R9arh6 LLLPrxLUVaqsKqxqqPrOS3PVXnVXd7qrdlGj1Xi3cgxUQ1SWmsj/MRjWsSrRrRnlVKqqqa5R16oW bnW+Td2ltLpZ/UU9rPqpe9X9aoSapIoq07ZTpzaqXZebbkxXvbt2aZ+upuPlSn4z9E9ubS7vPNZS jdX1qrW6UfVQf1ZGVVZd1Rg1QfVXGWqoGqmyqZOk0lUFJXe661RL1VFVUY+jL6YKujiUVmmqovNb RzVQTVQr1UbdpG5XvVy7q6puaqx6RN2tBqlh6gE1OWrBFSqfKqNKqErOQ13VVN2g2qpOqqfqrQJV Td2ixqlH1QA1WGWqUfJbpn1qD+tjboF3wv5wMMyCY/r0ysg0j8IpcAacD5fC9/v0GtbPrIdb4Ha4 G+6HB/v0GTTEHIE5Ql/DgrAUrAob9c24527/BtgBduk7+L5Bfnd4J+wLB8IhMAuO7j+0Vx9/PJwM n4Nz4UK4HK51jnv5W+B2uBvuzxg8fJB/EB6BP8HT8DyMCwM/474+GUEyLAiLwVKucGhQFlaGNWF9 2Bi2gG3uEz8dYVfYA/4Z9ocZcOh9Q/sODkbCMXDCENFnwynwOTgLzoML4NJhboyC5XAlXA+3wO1w z7B7BvcPvoaH4A/wOMyBF4YN6jMkpmAyTIWlYEVYe9iwmrVijWFL2AF2hT1hX8fasQyYCUfDCXAy nOZYJzYLzoeL4XK4Gm5wrBvbBnfBffAAPAyPDhvee1jsJDwHLwoTNEyEdtjwIcMSUmEaTIflYVVY O9NFMqEBbAJbwnawE7wFytO4dmtP6r9wNG6el1Al/58kjx8O/b8zcCtG4FbRBJX4HzvzOQtlz616 eZn/D9K4dS4fv7n870ieW71/n4X+MDUjop1XOeNtj9wf5CnxD/OKP8yr/gcL/mGm01LD0fsNpQe/ 1dl/SuPuVEVVsX9RuhJJu/tTmX/peLUq+y8dy6ny/8LRc3fSf85/HhPP3cH/OQv8IdZyTxuZ7q4/ Tc1Xy9UGtVsdVjme76V6Zb26Xkuvq9fXy/QmeNO8+d5yb4O32zvs5Whfl9Id9CidrWfohXql3qr3 66P6gkk2aaayaWTamR5moBllss0Ms9DNQblWYpizpmOe8955zifnOX/yN+d+nvKYm+b7VIL3m/Pk upefp8y7vL49d7n/1B6XnxdRl/svkprnvHwe+zZ5znvmOc/TnyL7Lz8vWjHPeac85yMvb3/JuZeX X7X68vNyVfOcV//NuZt/5WrmKR/PuXbrQ6GwhxU6hceKYc99l3NF3VpVPtLujI77o+Ph6Hjy96wr L4uOq6Pjpui46/JWVLGX97LKysvPa4y/3L7G15ef19p2+Xntd/Ocv3/5eZ2uec5vyXM+JM/50Dzn z/0my5xQf3qe85WX29fPM0r/o3x7nvOdec53XT6KDbc7WheZPt6zqr83i9W2t/un3EydprygYHAF 94pCKpbS1m5KaWM32HV2vdPEvJ+9n53dSe+k8rzT3mmlvbPeWWVsc9tc+fZ6e727b0o+aNPKtJHr 6UK6iNPIXxBZaY/J72pWd+dF3W5kqJqlNqmD6oKX6tqQ6FqVmtJZ6ZQ2KV0c26bc7NjOtb6gW5PT 3W6hptvzNLY/KKMLujb9yHGTdTstXcSdH+O4ye5R2p3tc9xk9ztucX2VDE1TZexB19Z1rvRvHDfZ Q+643p1/y3HTbywPR5bfRZZHIsvvI8t/tLc97e1Ae2+kvf8o6UjJTZR0+m2J3UoLt9HC7bTwHyU7 KdlFyW5KtErQ7p+bZvm0fHO7oC7oolrERdWk3JDS2kV9nV2nYq5N612kjLOQTyPDu76bWq5+L8ZL MVKed8G74EYt18t10Qq0e+7Bb4DfGH4TdJpOU4m6jC6jknRFXVElmzZuNPMFvYPeKiXoG/RV+YP+ QX9lgwHBAFUgGBoMVQWDzCBTXRFkBVmqkE236aqwLWPLuD6VtWVVEVvelldFbUXr9ny2sq2sitmq tqoqbqvb6irN1rQ1+V3uOqqkrWfrqavsNfYaVco2tA3Vn+y19lqVbq+z16nStqlt6kZH8u1q8q2s bW1bq3L2DnuHKm/72D6qgu1n+6mK9m57t6pkM2yGqmwH28FuoRhih6iqNtNmqmo2y2ap6nakHalq 2DF2jKppx9lxqpadYCeo2vYx+5iqYyfZSaqunWwnq3r2Sfukqm+n2qnqGvuMfUY1sM/aZ1VD+7x9 XjWyL9gX1LV2pp3p8nO2na2usy/aF1UT+5J9STW1L9uXVTP7in1FNbev2ddUC/u6fV1dbxfZRaql XWKXqFb2TfumusEus8tUa7vcLldt7Lv2XdXWvm/fV+3sSrtStbdr7BrVgfG+kfHu6HJlg7rJ5com 1clucdnS2W512dXFbnPZdbPd7rKrq93psqqb3eWy6ha722XVrXaPmyPd7T43R26z+90c6WEP2APq dn4Tu6c9YU+oO+wpe0rdac/YM+oue9aeVfI73+Pd/BjvMqmAV0CN9dK8q9Q4/mfUCV4Pr6d6xMvw BqmJ/G+o2d79XqZ63Mv2stVT3nTvBTXFO+WdUk9757xz6hnvV+9XNU0WGfWsjumYek6n6BT1vL5C X6Gm66K6qHpBl9Al1Ax9tb5azdSVdCU1S9fUndRsnamHq7V6hB6h1rnniFHqQ/0XPUat1xP0BLVB P6YfUxv1ND1NbdLP6+fVZj1f71VbTH63/lw0dU1dFTctTEuVa9qatp42s81sz/iZ/kueH/QJ+ni1 g35BP69OcHdwt1c3uCe4x6sXDAuGefWD4cFw75pgRDDCaxB8HpvoNUy+ObmXdyL5sXyeF08pmNJK P5Bye8oc/Ub+vvkH6jP5x+afrC9YbRNNoi1tS5sC9mp7tSloy9ly5gpbwVYwhWwlW8kUtlVsFZNq q9lqpoitYWuYoraWrWWutHVtXVPM1rf1TXHbwDYwabaRbWRK2Ma2sSlpm9gm5irbzDYzpWwL28L8 yba0LU26bWPbmNL2TnunKSP/ObW52va3/U1ZO8AOMOXsIDvIlLf32ftMBXu/vd9UtMPtcFPJjrAj TGX7gH3AVLFj7VhT1T5kHzLV7CP2EVPdTrQTTQ2bbbNNTfuEfcLUsk/Zp0xt+7R92tSx0+w0U9c+ Z58z9ex0O93UtzPsDHONnWVnmQZ2jp1jGtq5dq5pZOfZeeZaO9/ON43tq/ZVc51dYBeYJnahXWia 2sV2sWlml9qlprl9y75lWti37dvmevuOfce0tO/Z90wru8KuMDfYVXaVaW3X2rWmjf3Qfmja2o/s R6ad3Wg3mvZ2s91sOtiP7cfmRvuJ/cR0tJ/aT81NdofdYTrZz+xnprP93H5uutgv7BfmZrvX7jVd 7Zf2S9PNfmW/MrfYv9q/mlvtz/Zn092etCfNbfa0PW162BybY2635+wvpme0l5Inn7qstZVcOgfe Hd4dTt3P66c8/z3/PaVjl2KXlElsktjEzZ7/zGrsMvd/V+P/z1fj/86+NLKvsjxteffEvvrfHPvf HPsP5ZgXDHTP8wW9MrquucHvrkqqRqqFaqe6qB5uvzDQPb+Pcs8D2eppNUPNUwvVMrVSrVdb1S61 Xx1SR9Vp92SvvJiXkjRSmaRhSZlJD3AcnjSKY1bSgxxHJP3FHTOdNIZjZtJYjsOTxnHMSnqI44ik h91xuLObwDEz6RGOw5Me5ZiV9BjHEUmT3DHL2WVzzEx6nOPwpMkcs5Ke4Dgi6Sl3HOHspnDMTJrK cXjS0xyzkp7hOCJptNKudLzj8KSJjllJTzqO+Dci8iw9H5b0XBSZ56PITI8i80IUmRlRZGZGEZkV RWR2FJEXo4jMjSLyUhSReVFEXo4i8koUkVejiLwWRWRBFJHXo4gsiiKyOIrIkigiS6OIvBFFZJrr /7CkOURkPhFZ+G9G5K0oIsuiiLwdRWR5FJF3ooi8F0Xk/ShXVkSRWRlFZlUUmdVRZNZEkVkbReSD KCIfRhFZH0XkoygiG6KIbIwisjmKyJYoIh9HEdkaReSTKCJvEpF3yZR1RGTTvxmRT6OIbI8isiOK yM4oIp9FEfk8isjuKCJfRBHZE0VkbxSRL6OI7I8i8lWUK19HkfkmisyBKDJ/jSJzMIrM36KIfBtF 5HAUke+iiByJIvJ9FJFtRGQXEdlHphz6NyPyYxSRo1FEjkUR+SmKyM9RRE5EETkZReRUFJHTUUTO RBE5G0XkXBSRX6KInI8i8vcoIr9GEbkYReRSFJF4lCu5YWSSVRiZZC+MTLIOI5Nsosj8QESOE5Ec InJBMkX+n0ZpN2/TuqtK3i79oulgbjL9zd1moLnXDDPDzQjzgPmLmWgmmWzzuJlsnnB7l0PmW3PY fGeOmO/ND+ZHc9QcMz+Zn81xc8KcNKfMaXPG5Jiz+evL/6Pk7fR2ugvMkb/ONe1Ne6VNR9NRGdPX 9FO+GWDuUTEz1AxViSbTZKokk2Wy3JPASDNS5TOjzWiVYsaYh1V+M9PMVIXNSvOpSs1fL3893jKk qWS/lP8nP90v7Zfxr/bL+uX88n4F6Zlr0Vnernuq2G/eTVThfVCGWLiaFSKLkr+xqPqbMhdJk+Gs lZ/qy2+BVfQrqnzRdVP9In5R/0q/mF/cT5PfvnMW/31drcqqAn4hv7Af+DE/wU/0k/xkP5+f4uf3 rV/AL+jL+y7f9W2sa4LU0f51fhOV4jf3myvryuqrYuZVs8AsNm+YDWaj2WQ2my3mY7PVfGK2mU9/ L+Lytsy8Yl5xHl+Tv2s2i8wiF++lxq2jLnIfuesdMsf+j/dXnNUiV7rSrDKrzRqz1nxg1pkPzXrz 0e+NMd5fNa867wvMAvlGplnsvL9h3OrsWvip8y79EO/VVervev2dfhCzQ//F3neAVY20bc9MkjOH JCdUAQERFBUE5YCoIIoFsXexdxAVLKBiRxEUy1rXLhYQe+9iQ8WKvawNUbH3BiiCCHxPRnRx1/13 //f79t3/+6/XuZyZJOeEPPPM3Pf9zOQkRW2mfu8v9i72PbU3wPeEQWQXmoAmohg0CU1GU9BUGNfT 0HT2dtFZaDb6GUb5XDQPzUcL0EK0CC2GMb8ELUXL0HIUh+LRCkCAlWgVWo3WoLVoHVoPeLARbUKb 0Ra0FW1D2wEddqJdaDfagxLRXrQPsOIAOoiS0CF0GB1ByYAcx9BxdAKdRKdQCjoNOHIWnUPn0QV0 EV1ClwFVfkFX0TV0Hd1AN1EqYEwauo3uoLsoHd1D9wFxHqJH6DF6gp6iZ+g54M9L9Aq9Rm/QW/QO ZQAaZaH36APKRh9RDspFn1Ae+ozyUQEqhA6NSWvShrQl/qQdaU86kI6kE+lMupCupBvpTnqQnqQX CSCBpDcJIn1IX9KPBJMQ0p8MIAPJIBJKwshgEk9uklRyi6SR2+QOuUvSyT1ynzwgD8kj8pg8IU/J M/KcvCAvyStOJK/JG04ib8k7kkEySRZ5Tz6QbPKR5JBc8onkkc8knxSQQoAg9W57juM5gdNwlNNy Blxrrg3XlvPnunLduJ5cL24gN5ibyMVwk7jJ3FxuMbeU28Zt53Zyu7i93D7uAneRu8Rd5q5wv3BX uWvcde4Gd5NL5W5xadxt7g53l0vn7nH3eW++pvreVv4qf42/zt/gb/Kp/C0+jb/N3+Hv8un8Pf4+ /4B/yD/iH/NP+Kf8M/45/4J/yb/iX/Nv+Lf8Oz6Dz+Sz+Pf8Bz6b/8jn8Ln8Jz6P/8zn8wV8oaAT TGhdWo/60vrUjzagDWkj2pg2oU1pM9qctqAtaSvamrahbak/bUfb0w60I+1EO9MutCvtRrvTHrQn 7UUDaCCkIEh9IQXTENqfDqAD6SAaSsPoYDqEDqXhdBgdTkfQkXQUHQ0pgo6l42gkHU+jaDSdQCfS GDqJTqZT6FT6E51Gp9MZdCadRWfTn+kcOpfOo/PpArqQLqKLaSxdQpfSZXQ5jaPxdAVNoCvpKrqR bqKb6Ra6lW6j2+kOupPuorvpHvXdr3Qf3U8P0IM0iR6ih+kRmkyP0mP0OD1BT9JTNIWepmfoWXqO nqcX6EV6iV6mV+gv9Cq9Rq/TG/QmTaW3aBq9Te/QuzSd3qP36QP6kD6ij+kT+pQ+o8/pC/qSvqKv 6Rv6lr6jGTST5tBc+onm0c80nxbQQi3SYrqarqFr6Tq6nm6gWfQ9/UCz6UdxpDhKHC2OESPEseI4 MVIcL0aJ0eIEcaIYI06SxkgR0lhpnBQpjZeipGhpgjRRmiRNlqZIU6WfpGnSdGmGNFOaJc2WYqUl 0lJpmbRcipPipRVSgrRSWiWtltZIa6V10nppg7RR2ixtkbZK26Tt0g5pp7RL2i0dlo5IydJR6Zh0 XDohnZTOSGel89IF6aJ0SbosXZF+ka5K16Tr0k3pvvRQeiw9lZ5LL6W3UoaUJb2XPkjZ0kcpR8qV Pkl50mepQCqUkYxlInMyLwuyRn4oP5Ify0/kp/Iz+bn8Qn4pv5Jfy2/kt/I7OUPOlLPk9/IHOVv+ KOfIufInOU/+LOfLBXKhDumwjug4Ha8TdBod1Wl1BjpRJ+lknU6n6Ax1RjpjnYnOVGemK6Ez11no LHUldVY6a52NrpTOVldaZ6ez15XRldU56MrpyuuW6JbqlumW6+J08boVugTdSt0q3WrdGt1a3Tq2 +sxmZNnMaCSJI4CgbL5zBdcE+P0a1xz4/QbXmeuCUrnuXA+Uxjj0DhfGhaG7wHhRKJ2bw81BD7lF 3CL0iDH7Y8ZbTxhvPWW89Yzx1nNuD5eIXjCGeMV78TUwYvOmRBAFEesFI8EIu7GZUXfNfc0T/Izq qQd+w2ZJs8TJ4hJCxNXiYWIhnhZziDubKw1gs6RrgO0zkQGogzLA+S1AAcUCAxwCdIY/IcUgopxm tU2spq7RGCFzZCOdgu0bUgrkqdJpyNOkc98+ewNqyUgLWsIS2YICqPhl9UhKVfdLaZCfle5Afl5K h/yi9Fr9plJCPaNirp5RsVDPyM6Vz876dY3GALZOKCLkpxTpuyOG7IgRO2L83RFLdqQkO2LFjhBk AF7Tg+88ifq2JG/ijQhpQBogjjQmjRFPWpKWSBDninORRkwUExEV34nv4HxEWEcu/00c+z3D/v/N r/8ehlU59K/y5t/JmSa0N+1D+9ExwEAqc/oBZzZjbNYamGkm48mOwJEqO37hxqC/yIoRf8KHv2fD xcCDvzJgcXb5f40Nv7Ed8OIi4O/irFgX1IeqPb4oD1V3tALlkVukO/JAdXQCxbGcaY44UByfoNe2 h57aQ+2XX7mTDPyeN2Uj2Vg2kU1lM7mEbC5byJZySdlKtpZt5FKyrVxatpPt5TJyWdlBLieXlyvI jrKTXPGHbBvzY75VDBRRkf4S6276Pe8qhoqRYvw79j0lpUinGQef+yEL3wAeTpXSpDtS+lc+VswV C8bJr/+QlfN/z8uKpVJSsfqX2Pk7bpbz/w3s3AITXAJCWSvsiMxwK+yPyrKVUkfcHQchZ9wX90VV cDAORh64Px6IquJQPBp54gg8H9XHsXgZ6o5344sogAwh4WgsGU7GovEkkkShKWQCmYymkalkBppN ZpE5aD5b81xMFhBAexbjL+dkzgTFcWacGVrDmXMV0VrOhXNFBzk3rj46whj/KmP8ayx6u84n8BfR C8FYMMaWQraQjUsKOUIOthI+CZ+wtQaaC9topmpm4FKaWZq5uIxmvmYRrqCJ1SzDzpo4zQbsqtmk 2YW9NXs0J3F9TYrmEm6nua65jrtrUjVpuIfmjiYdB4A2yMdBmkLQBtG0GvXGe2ktWhsf0jppK+Jk rYvWFR/Tumnd8CltNW01nKL10nrh0+r6GT6jraOtg89q62nr4XPaBtoG+Ly2sbYxvqBtpm2GL2r9 tf74kraDtgO+rO2s7YyvaHtoA/Ev2mBtML5pAGE/ThUDxEB8SwwS++HbYogYju+Jw8Xh+CXw7BL8 Cnj2MP4APJuDCyQidSFU6iaNJr3kOPkBidTN0MWSY1/ub4FodAtbcemG+xTt2VNsD0Y1kKZIe5QH TeMBx1dDUvMtoApWs1LdSiraSoKtO5DUu2ycsTP0msq4MtCdJ/aEczbEDYFcmuKmiMeL8CJ2l00K 6iVYCdaCjVBKsBVKC3aCvVBGKCs4COWE8kIFwVFwEioKzoKLUEmoLLgKesFNcBeq4F/wVXwNX8c3 8E2cim/hNHwb38F3cTq+h+/jB/ghfoQf4yf4KX6Gn+MX+CV+xXM8z2VzH7kcLpf7xOVxn7l8roAr /O/s48EUnrCZBp79WsGYrWZZQuKQDSQeWq4CWOqC1PvSXCFpoVVrgE6sCUlEPpAkVB/5IRk1haSg DpAMUSfUGfRhd0gmqDckU9QPkhkaisJRCTQKjUYWKBJSSRidBFlhQ2yErGGMWqFS2BbbIlt2T0Np GK+tkB2M187Inq3qlmEjtSwegAcgB3aXQzk8DA9H5fFYPBbG9FQ8FTnhaXg6qohn49nIBUZwLKoE I3g3qoyP4GTkik/iU8gNn8PnUBU23+TBRl41pqmbsFmn7mzWqSebC7MqNhdWid1N5U26QouVIm7E DZRjNVJN/Y0YqQ9HmpAmoBzbkDagHDuQDkgA/ROENKB8+oNynCL+hLTidHE2ksQ14lpkJK4XNyET 8bp4A5mLqeJtZCmmiw9BU0dI45A9sMhE5KAyBHIChliBnFU8R66A59eRG6D4HVQVkDwdVQMsf4iq A54/Rp4QYz1FXoDpz1ENwPWXyBuw/TX46re2VGa2NCYhYIvtd7Z4ES84olrEkVYQ0/DMIoFZpAGd 1xlRZpcWVNxgZMDsEpldOmaXCbPLTNwibgOLdoh7kDWz0Y7ZWEZ8Kj5H5cWX4luwS7W0MrPUjVla jVnqCTy4GuKEtRBt1GZW+zGrGwI/ZaOmwE75EKF8WX1Vf+XYm1nkqtqoPmkP1Siy0bXoM44wemfj Bd/2EbwBb4Mts2+fgxHwgzaoSaDdWEvwzLcCaw8Naw/K2kPL2sMAdG83JLJWkZi3ZdY2OrGT2Akp EJmPQ4YQfc0Bn88TlyAbiMH2IAdxr3gYVYNI7C3yETPEHBQEGmIyGghqYTYaDepgE4oG7t+N5gPX p6JlzOd7mc/3AYPfR/uZ5w8wzx9knk9inj/EPH+Yef4IMPtblAzsnoGOAsPno2PA5xp0ATSOJboO usYe3QUtUxE9AVUioTegLoxRBnC8FUQAgIQQIQ1GSI0gUT11lgG1Vu+2QW2lMbIfugDfKYUX/+XP sadd/k2f/tYfUADzqp71+VbF+oP+1/6A/JHPt30ENWBr92bfPkcQJy4VV8HfPCKmQB/PldSRA3tZ lP/lSuzZNeiLrvLrtdYANPsX0B2+WYJhIWJYiBkWcgwLeYaFAsNCDcNCyrBQy7DQgGGhyLBQYlgo MyxUGBYaMiw0YlhowrDQlGGhGcPCEgwLLRgWqr9tPgoWyKQRtx/V+dO1IIJFbAJXWQZXxO64Bq6H m+A2cHUBOASH4eGgn6LxFDwTz4O/Go/X4E14B96LD+Hj+Ay+BG1zG9rhGX6D3+NPQEAaIhMTYkls iQOpCG1cDVcE6x2hLSqxsjMwsFp2w16s7I5rsLIH9mZlT1yTlb1wLVYGYB9WBuLarOyN67AyCNdl ZR9cn5XBuAErBwCrq2UobsnKWMFCLfk9giUrE4WSaqnkaSW1FEy1slpqVml1rEzSKqw8pDVkZb7W iJUFWmNWFmpN1BIUlCkraxti9ndCsBOgkSFoDQJbLpB3BsWh6hfAJLASeiLY6AZ5T+wOeS9cBfIA DFoGbKsKeW9cDfIgXB3yPrieev8J9oW8P/aDfABoFgJWNYI8DDeGfDBuAvkQ3AzyWNwc8qW4BeRL BDNEwN4SkCcK6uxLnhYcA5ZCrwY7eciTtKB5wEaNekeVlkJeoNVCXqg1QARsAwWmrY2cYGx1Bc4f AFwfgSai6WgeWopWoU1oFzqIjqNz6Cq6jR6hV4AvRWuK0JMsoa87QF/S42q4JvSmRrgF9ofW6AlW DcAboLVioYU2srIb3sTK7ngzK3vgLazsibeyMgDQXS0D8XZW9sI7WNkb72RlEN7Fyj7aUmoJNtqq JVhZmpVJWjtWHtLaszJfW4aVBdqyrCzUOqglWFyOlbXxcua/OOa5eOa5FcxzCcxzK5nPVjGfrWZe XMM8t5Z5bh3z3HrVH1oz1uIlWIubsxa3YC1uyVq8JGtxK9bi1qzFbViLY8QbInZnOcewArGRjg3V n4moTxNuwe7rd0TuTAew2TBszvqaBesjlurfVs+CS36r9VN7koq9gCcLWF9hubpKh40AoRAuAXEV ZkhEGL6ovGqJpuJ2uAPuhDvi9rif2BEYsPOXuWkyjIwjU8h8LpZbz+1QPiv5SoFSCCi7TFwuxonx 4goxQVwprgLETRaPisfE4+IJ8aR4SkxRPipE4RReERSNQhWtmCt+EvPEz2K+WCAWSgB70s/SHGmu NE+aLy2QFkqLpMXSHilR2ivtk/ZLB6SDUpJ0SLol3ZbuSvekB9Ij6Yn0THohvZLeSO+kTJnKWtlA FmVJlmWdrMiGsrPsIleSK8uusl52k93lKrKHXFWuJleXPWUvuYbsLdeUa8k+cm25jlxXrif7yvVl P0VWdIqimCimipmSo+QqnxRrxUZR10HLs8gTsWhTANXVFDgthAwA5RAOUaVMxkJUqWP3zSoshjRk kaERm/815rZz25GJZqtmGzLVJGoSUQnNR81H0IwQLyELNV4CbXVXfIyc1KgJlNQU0A81pM2gHHwh 4k9FzSDqT0PNmX5owfRDS6YfWjH90JrphzZMP7Rl+sGf6Yd2TD+0Z/qhA9MPHaUCUA6dZCNQCwFM LYxlamG8UgLUwgSwcz/q/Fc8+q958G/x01cPiaw1EWtNA9aOJqwdrVk7OjDLKzHLqzHLWzPL/ZlO 6vAl+hTY2wah3gSpc8v1kG3x/v/bXvzH/fFL34EzGLOeglhP4ZiHNcyfCvOnIfOnEfOnMfOnCfOn KfOnGfNnCeZPc+ZPC+ZPS+bPksyfVuA3C2RddPWSoBS7egU0b9GIVcc866eI9VPM+ilh/ZQr+q4s GBb7riWokm8o8HWkM+Rgo4D1ZIH1ZMp6svZLJI0zcDbOK1IDxsScWJOyxIlrLAQKQUJfIVgYKgwT Rij2SlmlnFJBcVKclUqKq+KmeCjVFE+lhlJT8VHqKPWU+kojpbvSW+mj9FMGKqHKYGWYMkIZpUQq UUqMMkX5SZmhzFLmKPOUBcoiJVZZqixX4pUEZZWyRlmnbFA2KVuU7cpOZbeSqOxTDiiHlGTlmHJC OaWcVs4q55WLymXlF+WackNJVdKUdOW18k7JVN4r2f/5pcd/7vv8H/ulhxFo/j6CqZIHnF/7L93X DiMRh2huF7sLWavepfPtHp//w3063+7wgXOQWqR7sZkOdU9TQKBv8wX4PfoIGr0q8YRP+MK+lqQ1 aU86ka6kN2BVGKDeWHVd7UdJXUsrnuAs3yfP3yd15a14Utfpfph8f5MaqKt436WWv0/qil7xBLb8 QQI++C6Bzd+nTj9KwB/fJWil71N3ln7d7v2b1BdSyB+ksB8lqeD7BKz1fSr5m1Tm+1Rk35frZWf4 z/zIH8yPYHQX+LMmcH0jUNn+7FksX5/Aoj6N5Sc0Gy2A6CcBrUNbIP7Zj46gkxABXUE3of30bL35 /zb3/Jfylv9K/sNZkC9zJDIUC9S4B9VVYwHgOnMWPajrLBg7QRxNgO3nQ30BXgj1RVh9g/hyiLwI 3o3fqk+hxRkQr2Sy93B8wNlQ/4hzGWfmQf0zLoB6IVHfgkIID31OIBqoU6I+uVUiEH8THXuniBGB GJuYEDOolyDmULdQ3xECvGoNdRtiD/UyBCI34qC+fQQ41gnqFUlFqDsTZ6i7EBekvlWlEtQrE/Vt QEvIEqgvJUuhvowsg/pyriF7kmxjxHFNBFP1WXUC2CtYCX7q0xWFhogTGgm91GeFC8FQD1HfTAxc PQLqI9WnVgkxQgzUJwlHkPqW5WSoH9UCMmsJRJFEW96gP8IGAwxA6RkM1K1HWLdBB1GvbqMuGepH dSegfhKUKlZsQWdwoCYLWYQHqGxIDO2//M6aeYaggKJfB/+qQTDTIJhpEFzsV6yYaRDMNAhmGgQz DYLZb08w0yCYaRDMNAhmGgQzDYKZBsFMg3y5QsKUCGZKBDMlgpkSwUyJYKZEMFMimCkRzJQIZkoE MyWCmRLBTIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZE MFMimCkRzJQIZkoEMyWCmRLBTIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCmRDBTIpgpEcyUCGZK BDMlgpkSwUyJYKZEMFMimCkRzJQIZkoEMyWCmRLBTIlgpkQwUyKYKRHMlAhmSgQzJYKZEsFMiWCm RDBTIpgpEcyUCGZKBDMlgpkSwUyJYKZEvj6j5NsTS6yHQmnG9iLr/vpo674ag4qTGk36qMOUxEdb d4Rd/gRjN0lvoBGcFY5YCUjfSyM6azCPo6sTzMe31bfWuxTbY5NgO96GLSnVRC1RABqKQgFEg1A4 /FeXmHz09sVOxptVoCtbemZVmvq8HrYc/PKnW899D1yKjzavqI/mTfTR5FM8RzABcEhG02rWnGJ8 2Sc78FV6Hb3u25ViHq4pzM1Z76Th2vGSaRnf0LBRQ4L79gu3cwx0snPz8qpu1zw4cEjo0NA+4Xa+ oUPCKrvZ6m2+fLjE90dCh/QKDw4d5GavL60e50wtfz3eJjQ03K7usPB+oUOCw0fpbS10XtX1bm56 fXU9/OtsoXPXu7lXcSva/AeuKBqXKd4s6puqogFWYL9IojFG60lSctgT78wW1o5xC0d2179IWD+j XI+cgvnNViYWLEuw84lonbAkYVZP9/6X6/Ue9WbT8NP+tzJfLp1kMytuYp+dJ/qPDih7vVTNu4Z4 zrMFxw9X6hMb26/84ks1XA7LuzuWT27wVPTxXOCy3tFr3avGE+o9nGh4IHZAu16boiNW9Kw0otnz xbt6e8e2snHTOpjFrX/6s7Plk1qLAs16dhSC4kpVbzP549q388hJ618Ot/PbOXX84Rqv/Oe12JK/ dvTA8BZbLc8tMHC0Rx1m9wyufqCpCa3ZvrBL3qo+onbNlaj2Hd7u8e5uHjWCv5V9aMv4+QXbzkde X2s1pGvNMwffaVeW0e/UxJzeaTfCNCadcNDxV0at00et1kclQGuWwnxUrD5q4XijLpfC3gYPWV62 9TizHc1nFp5dMeTf77/oP+njnOrD+c+kIzOyFlpWfb0XO9wcYZzVtad73HLprI/w85RZp2s8sc98 12Guy+74hikBbz/fOOft3Xl9Nf/gAoeBtU+f23BXiLjjNqNWnFFYyIECk5aWwUc+X/J9aNzZruWL gDFbN5RMca5ertKhoBUmP5UzDFz50d8m1/709RJZbTYN8nWn+dEWOY/7DtC1zk7KaHMq6elx/Wc7 N4MppeY7WTW/Voqszhh/j9vV5f32Oykd3gQ1PtXGf88uztGkcPb1d9pZ4/YuPLGxusuj0Y/WjXg4 PB5dCqmdfKXaT/fqmqyrGmIdklb1/lUb/tE6Pz6lcxXPQc1tdAGJYsL0X675125w3qbdmrA0kxqT 5w6LW3slHlChpz6aa/YFFcTKG41vtyrsuuzska+YUuqfAgMY957u8A8QwB3AwM0dNqt+BYNRDEHh JBpT0q6tm6neWN3Qmoodeg3tFzyobzj8GSO9ou6kprRNUO+BoYN6f70w8Y8urKze/suFWRU/3jvI rm1w30FwVrtWvnX/FBUSR4293m2nn9c6j01ut3LLVW084khe6eWn/Aa/vdzg2dXpx/o3axPwfjE5 1vxm4wGuDj5Bhy+UTZQaJUYOu+OXtGGW0upEOefM+Ke6sqUv13X4FLD4Ykm/1XOblF58fqdrmWNN KkWEppaw9Z7uZeR1J8npfR/vSti9sKBCozW7B+DJS/P27wiMjM7tGh81MWbmtsy981Ze9FzTKsai wuQWd/TZqNb7k7m1og5Nej3Aa21lj+xdlbeKYwN+Htln6aKhuklbM49n2e1raTIj8KxLqrtfyTcH mizwbtXW8kKf1qM2bJ6c0t4nLrrVlEHC9qrJYxyS2vSptbjFOedxVQZNbKi5vPxSk0lk0CS06sjk 9LZFqPBJH/VRb6qCQjle1osaLRCaIFCO+98BFYbqNZqqr50U9BwU+lLqDoU3583OlbowHIV12Zpx 63iL2Nb1K6+sH/hOL6mHDXkehtGkYkOHYcyYjVvGNSmfeeFgi/CEjhXCKw7bOSl/Y7N5I1Hz52de Wt4OPqEkRGQR35NnJp/LaXvuaFxS+9B3gfXX10dvFqTEXrPZK8WV1M27cct2s9PYt6/XDN00667X zFqLQg56DrwyZWvZ/PTn14MNfp6SVHAfHfDI+hiRa2RSWXjptGBuvf6OgxM9Z92jutPd+p1PGl+3 f591BxIPzPQ4k8kZRYz+cOVevfQxBffvbyrITr+m2xl2fc7Dlns8EyIqXa2V5iEFVCdxUSFlp2Z3 DZy1rfMBrxs9p7ebaFXlg/ei+Gg5oce0nS6JK1af3XjLbs9hfckYOzNdxYNt3te9113/cI5j8OTk sAdZazdeGF9vyHAFMCYEMKZNEcb0MhzZnCkkrvg4EgBn/sFR/RVwquj1gDhVAHD0Xnp3dbOKuqkP /1sureg49wfH/xRrEtLEGRePJjdecn5DDY/NZTv1TxtwyL5M4ryUF1sOn7xW/qi78bSDt7q55FVr b1vCecss3R2zlYMcm0Wa1667aUad7Q2m6FKj5m1eqLnUof7wri8yPisPIsNXVjkb/vjtw14rxnGJ foXXfEyubTvTXXdpTGaiqe5zzxDHmGHTEzcfjHlmsWv2oQ/mewK6vTZOr/HGvsu0reOHHvN7OH/q iJ5Lnm4ekVx9RhUzV9O0gNNbrNa3XNR381U7L/3gezP6Nnhw0ua9rlV4XddngkOIff/G2+Yc3+F1 qt7qgV0tm2ycdWPmBJ+RYsObq3ZMLHvsQeaYPtubhCeVr9t0aS+zni30KdFZl6SwiDftmo+4om03 PKoIa3L0UR9Y25cyVEcsDELNkWIDNsu+zsyI1jn+TRc9trgRMsFDqFz+2Y+hScWJUmV5S735+B8P 8/rqB0rztfTeeq/46vFVJ1XpFx4eVsPVNXDIgMoDv/qwcmDoQNew/sHqXtewIaG9hwWGD3X1bQsd rTLs0jf6+idBh9TU19B7ft3Wk0kuRSccMWLEj04YNKTYmcJ/M4AY2tTpENq273K7CR5YeWLRtObm lzejIt/oRoWPaLmwoWUWKhE8Li1gdkJ+3xVLHzk6fWp3Y3FBq8PdDXbuW/M6OmuRbWinTx8y7su/ TNP6mFvYXT6y26+htnzPDgZN573TntvffNC7B41MHKtOsx+S3mPP1mATh3lvnnsYpI0bFDpHbHOm YrPGG9xdJj1bca5b+YMHa97rsmOCtL+qTcuJfg0LD8xb0YmuX3BnZFKHyNVrW5zL3Lw0tu6Ds10d fG5HejRskX0xZcyyl3tOLw00a7t1c+zbG4cvxq/YOP/MaOfJLkdOpX4ewN067Lk543LXkhaGRz6e Gb/GSGt1Z3bZp9tWNPN5sc24/Egl2WXfqv6nZtUEtFkGaBPzFW0aR7xmaCP8c2jjHzwwaGh4r4Fh xdGmmt7LrZrerWpVdyZv3Nimu17d1Eet+VuurYK+3BeitB3kGxzWL2iIXf22fnZ+bVvUcNPX96xU 1dOjeiXfeg08v36QM7X9AyPaBg0ZHhwY9KcA9WK/EJiSOmrLxPo+q3cef91suUO613Bbg+vuTTqO vOKcuprOfvu0Vl5S+YiVeY/HjnO/mFprmlf1zJyb3h7mV+dE53m86hczxGrWvb3N7u2NyaoikuSE 4UOrNuuWkXi/ydhSe+eNTCu0jSlRr8HgC5EVOphcntDS++Knu9nTXtdGD6/d7ZVrMaPpqqiaH4Lr vLg/9TBtuT98zHP5ccMXGwdkXOsbpc0xPzPW9MDQBwbNPgXkvY73iq1R8NI4pZdtQMebov+Ea95N mz5ol+Ta02rmHMH3VreX0WLZhQbxglvQtLktbOvaJ8yZne9X3y+06na/6puD1wflevhutzjq7XXf aHqm1eSH/q1Key9z21wcoH4FpHFD3lWu3d7pXrmP/fbiz03vj7v40Oc77Al91qL2wn0eG5tOmnVw 6YtN3nV9T176b2FP+NCwwF7/I9jz9UzhP0JQ7e9Q+AcAFTw62kA2v3z3YoOplQ9f9hgdFVnBsW7F rF/s5ygLN/do290p93Wyf5N1Yz+aXpLMcptnTiqBBj2cUMrRb62Ll/ud0Njqnd+UbTPLn5tRe+3S 3p7Z1VLMfPfU8Fl0WndscJRjVp+1bg+6dpuV26bN/a4v585eFmzQbOrly8ObeehC7kfUX+vcZYJ/ pJ9DyXLHf2pwotzDkuODncyyLU6+K+MS1aC78/vcNSdH+JQNzV3TO2ZmQoBufSXbdY9n+0QWbpv5 eeGrjHx+6/nGFzqHb/qUZVra2uvCyl3XD77f9SZlc2Z727yaGSnXK9Y/eHhp7bF9LM/vsAsUz9Sp FeReMmLH3lrJ5Ru1KFNy8aDp+uSMn78HKKMQaXHLI6jcRuM0v9IdR/dN+C1M/TPBVxE66T08qqvo 5AWb/0Dw9Tvg/DO8uV19UN7WlHpNBlumXGjk0/bIp41m+13cD5i0bJMy4bVPldTGbnMc9/zc+17p VhP3H216OVLIeTvs0LRT665tCQ7rM7JCn2d7Et/G7Dv/ZkO+ySqpUxkn14t1Utvz1sN3D+w9sIl/ 2p2Mu4fjJpwanx7ZjFSf9+HIcm17234Nz6ceGd7Vdeyecvyu9l1CbAILx0fUfHONL9fca0Q47Xa0 681J1V2GnVZe2HoZRAwvWDZg0Oh7r3xmLVw+WOlRsaVlQE/35VcmtHAu07Wf37S7rhONWu3I3W01 Y8CbcktMc84a3YhR3kcPH1rt5PzRCed6al4J2yZVScyZ12Vi3YkdY+YN2lbapdG50KW+90KeRZaf 2f8L3kRjR2gRhx+P0P8V4ZeRxqBoArQEVmMqVAw9fwiOJb99wYzwsq2I2qJhKAD5orrfh2a/i+t+ AFDzmhu7HY1odcB45opeFCvTw/xmvB3qn1TbQKhUuLd12xib114/J65sL92dvsfb+nLeprWnE7e3 trcO1QaP688llGnwesCugRFl9v7X3C63fO7l38feZXbwdd3LgljX+ZMunTl3t+/Aw/1aZ2venFxn dLV95+nkI2YXJRT3l92znrVZunieYseNLVuEQnq+zDmU6jVLQ21OQhe/9XHh1AqP3efXNlv5b0iK uGfw8qWl7OPOT7csG38KK/akNCSzsUz7NIvJWb/arWPXf6abqT+97t1iLpm8mTWP58zcOxqJNR4f xecIKlowybSvYTs6zWjHU4djwbZ7V3bee5Fm3vtFadqcMxvKQwKtrhW5bFL+ZtjEsh5YSK1mYmQ0 aGwfwF4ZSl8RMca9oPGWgQg8vjUYDdmZWcGrl0GpABqZnMyGPMjD6kDXIHjchnwGyLKiBsoIjSyG wDT2vd+LvdF74r2tHLMCNnTu/6vhP3GrQQqSFh7DMIOQBVoNGgy+DJkMyQxFDPngkfk0hhIGBYYQ hkqGAiAvHSieCGRlMFQuVGtQwVm9llQW5KcXJRZkVCqgFW8sTYwMCvuf7YiUZLASmSXV4Xvu89QN cyY7LHrFZxzO8s6i2O3Pn43rZr5/YPC4ruvr6y/M1V+vxvz8WjK3gTtv8611+sx5LAWvmK99E+/U PdAy1XzpebuW2HC+ypM3JG/s/2vcPe/OZoVF291e76yb/3b9Abtjr/a73L/ouOfHSxHJLu+Pkxld z8cb83TXr+tZ7Nx74o/f/+S1kw6fNVQPLd6SsH0iy/eTvGXrPCrWMc1qOLVuoomZ2rFnKTwL+phO 5srXrqsLMz1yWbhmk5PS1Jnnq/wKyhav0z6q9Lyq+Hrsgv6F78P9DZm0Bcpcfk1xk0maIlzdX/Ok RfnB4tl+5izHfNJWvVh6a2mEcm2nwUV5kYVNTPIGTUzSiDhiM2xi4gEKcdA9iaLXSCgdDHZoEl0Q ayCBnBK5EbNAjEA74TKshvzAqtbC0MAIWNEaWRqbRmEkRKb/Knz3tyX2xurFG3S4Sn1d/+DND7Qy C5RE7k8/7MWhe3/HSellNxVZj/O8SWtT+e/EdN75w94TCxXKpj3a83Byn5DDIzWtRcsmdif2SPw8 o7UxQKr9R/XEV8FHHV7s1o3tP+cyKSUvLEHVift4G1OD4zulmdVHjaoC3uV0PPllJv71WPekJNmQ WVeeCgstvDZ33ff/4VbM7i+vvov4nGbnmO4dt33f3putuk/Cd5yYuDqpMMt+uTDHofPaZ0rvzeyq rChoXus269Dm5k4/dyvt5mBFoxX/Xh23LyljOrBuVVFw7I6M43WvDW0zZqk3fN7CtuH55R2COk2X cvavv1+46UVz0optjGUGt/gcgjdFs37+vsUshTVYUbQ73S1PICs3UjgobwsvAwCxKe1bDQplbmRz dHJlYW0NCmVuZG9iag0KNzQ1IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI0 ND4+DQpzdHJlYW0NCnicXZDPaoQwEMbveYo5bg9LdJc9FETo2i546B9q+wAxGW2gJmGMB9++Y7QW OpCEyfy+yZeRVf1YOxtBvpHXDUborDOEo59II7TYWyfyHIzVccvSrgcVhGRxM48Rh9p1XhQFyHcu jpFmODwY3+KdkK9kkKzr4fBZNZw3UwjfOKCLkImyBIMdN3pW4UUNCDLJjrXhuo3zkTV/xMccEE4p z1cz2hscg9JIyvUoioyjhOLGUQp05l99U7Wd/lLE9PlyZfqU5feJ3u536rfp+fLEGB+3la42eq0v zyzT2P+gJyK2n0aWfC+OrcN9qsGHRbWsH/E2fM0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo3NDYgMCBv YmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzYzMTgvTGVuZ3RoMSAxNjg0NzI+Pg0K c3RyZWFtDQp4nOx9B3yURd7/zLMlm2w2jVQC7BOWhIQ0pEZACGl0CYTFBBCyJJtkIc3NhhAEjA0w Ns52VkTPjmVZW+xYj/MsiJze2Q7L6Z2nngXLoZD3O/PbCUlEX9+7//9z7/v57Ey+z/c7v/lNfWZm J7gC44yxeDyMrLCkYs6s7zsOjWLauu2MpW4rLSpZ8uX+zmzGLprAGGelRfOLD0yZPpqxC4YxpiXP Kikt++jpr35gmncnY4bPZpUvrPDUTj2LsYsnMH5t5KwKZ9Gz77zfy7TsQsZmrVxYkT/unx/88WvU tRetVtc0uVorn1v4EWOjx6K+bTXrfLr/mmf2M7b0A8ZMw+pa65u++WZBJGNZPYyFD613tbWyYcyB 9mFjMfWNnXUxK86tZ2wFkoYLGtyu2g/Tj56E+ufDMKkBBttd5huRPgfpUQ1NvvXRyzja0zIZSzc3 ttS4ug531TG26gLGRpQ1uda3puWOwtj5bfDXm11N7ox1iw4xtukAY1GJrS1tvt5UtoWx8z8R+a1e d+vae7SjjI1D/qgYJubStKMn6xT/plXR075mKRYmwiN/3/iC4GdHXrnh+8NHzg//JOwBJMOZxiig nJkdZfyZiJ3fHz68M/wTWVO/YHAJS/RItpCZpEFjMSyfuRmL3Y52pYsxm29HrsV0lWk8qhxBbNjH tmjMwrRok6ZpRoNmfJdpvYXszl7ZA4QFFbrO8H704dSHsB1ahs749bLSB01RYqSoPYqFQiiEQiiE QiiEQiiEQiiEQiiEQr+gXcMj/t06eC8bo7Shim0Dsv/dOkMhFEIhFEIhFEIhFEIhFEIhFEIhFEIh FEIhFEIhFEIhFELhZ4MhiGHBb2mtQApKmy2+Q4d0pPi6FTRjNpamp+jDe3ulH6WGIcV7vzZkvV/0 ftGg73mZ+SeSvxj8/S+kteC3xTT28yFY0jD3Xx1eKPyyYFhpWIXn8n+x+L+5Vgpn1a5aeeqK5cuq Kp1LKhYvKl948oL58+bOmT2rrLSkuGhm4YzpJ02bOuXEgsmTJubn5eZkZqSPcoy0J8fHxkTbrBHh ljCzyWjQOMspdZRV6/6Mar8xwzF7dq5IO1wwuPoZqv06TGUDffx6tXTTB3oWwrNukGcheRb2efIY fRqblpujlzp0/4slDr2HL1tUCX1hiaNK938q9QKpjRkyYUMiLQ0l9NLkhhLdz6v1Un/Zuobu0uoS 1LfbGlHsKHZH5Oaw3RFWSCuUP9PRuptnTudSaJmlU3ZrzGITzfoN6aWuWn/5osrSktS0tCppY8Wy Lr+52B8m69I9os/sfH13zp7uC3pi2Orq7MhaR61rRaXf4EKhbkNpd/dWf2y2P8tR4s/a8EEyhuz2 5zhKSv3ZDlQ2b3FfA9xvSo9x6N1fM3Te8eknAy2uoMWcHvM1E1IMsW+akK80Q9/QQ4wvLU305fye QrYaCX/XokpK62x1aoAV5mdX+bVqkbNH5SQ4RU6XyukrXu1IE6+qtDr4s64h2d+1Ws/NwezLn3T8 IF/3GzKqV9c0CHa5ux0lJTRvSyr9hSUQha7gWEt3j82Hv6sag/CIaVhU6c93tPrjHUXkAIMu3oGn olIWCRbzxxf7WXVNsJQ/v7RE9Esv7a4uoQ6KuhyLKh9i43sP7p6gp947nk1gVaIf/sRivJSM0u7K 2jq/vTq1FuuzTq9MTfMXVmH6qhyV7irxlhwx/qyDaC5NtihLYWyDvJWzGHlYukWv1FINVeJtwaCX 4eEomoaMGLwumRRvtGiaXslTmXJDK0EPoQbUg4QhvXi2yDKIosWzU9Oq0ij8TJdSg30ypfst/eqK gaGvT9TOT3aNvEWHsvRSd0m/Dg6o1BTsYLC24/dTE3MRbBglLOJ1zlZZhnTsXNg0VCNN4i0m635W rlc63I4qB9ZQYXmlGJuYa/l+51U45i1aVinfdnCVLBmQovwCSvlZGrJVQivGGizLTlWvVaZnyXRf cvag7DkqW++2OOZVdIvKHcEKmY4dhEGbM+a4zi+Im4CtWYbTzVHmcugxelm3q6e3a3X37sLC7tbS 6oYpog7HnNpuR0XltFTZ18WVm1I3iKbi2Dw+b0lRbg7OnqLdDr5t0e5Cvq1iWeVDMYzp25ZUBjSu FVcXVe0ehbzKh3Qc7tKqCaswioQuEqKmxUhYpH/qQ/gE6ZK5RmmQ6ZoezqTNomyc1fRoZItRNg02 I9kKpU0EvKTkBkwxjttSvVa8no1VDd3VVWJzsUS8SvxwP3dMZ37NMX0318yR/giHu8hvdRQJ+wxh n0F2s7CHYWHwRI7JEWdSd7UD5xQWVCVL5bQUDaJKvae3d0ll2oupn1alYamtAJZV+sOzcfab0ufC b5ZANcyz/F01LtEP5qwUZcPS59RUYdmqCuEyxx+OGsKDNcCjTJYRyxGFavBu8AJl+S4k/F1V/qps 0Wilp0ou5xg/m+2YgtdOdZoyREP5Vd1xjnFyb2IrRKRvFRSOvrGKSrKkIonGqmiSwiLR8xoHsmqq dcy2kdVUYKnTWRqRShY3jkRjhlsiIjWYycSwDOlWW4Q/PA8V4kdoa57Ykqb0sKoq6rxMbQ06oO0Y vxU9yug3lcECmB1kzRF9wc9WdFW4PimqWdTDFjvW42QRnZY1hSHbb0uf48LhT+WtsDgKVGGLOCOs wTqeIWuYGHkk5t2QvqSn91ZHZ1q/kJvjEB8OYmGy1IewsFlV92CDf3l2bo5lsNUmzd3dFtvxC9B8 WWx9LIx6KT41GAuEG/Qe7Zz7wpP5XIizlThLiTOV6FLiDCU2K7FJiY1KnK7EBiU6lVivRIcS65Ro V8KnRJsSpynRqkSLEs1KNCnRqMRaJdYo4VGiQYl6JeqUcCtRq0SNEquVcClRrcQqJVYqcaoSK5RY rsQyJaqUqFTiFCWWKuFUYokSFUosVmKREuVKLFTiZCUWKDFfiXlKzFVijhKzlZilRJkSpUqUKFGs RJESM5UoVGKGEtOVOEmJaUpMVWKKEicqUaDEZCUmKTFRiQlKjFdinBInKDFWiXwl8pTIVSJHiWwl xiiRpUSmEqOVyFAiXYlRSjiUGKlEmhK6EnYlRigxXIlhSqQqMVSJFCWSlUhSIlGJBCXilRiiRJwS sUrEKBGtRJQSNiUilbAqEaFEuBIWJcKUMCthUsKohEEJTQmuBAsK3qvEUSWOKPGDEt8rcViJfyrx nRLfKvGNEl8rcUiJr5T4UokvlPhciX8o8ZkSnyrxiRJ/V+JjJf6mxF+V+EiJD5X4ixIfKPG+Eu8p 8a4SB5X4sxLvKPG2Em8p8aYSbyjxJyX+qMTrSrymxB+UOKDEq0rsV+IVJfYp8bISLynxohIvKPF7 JZ5X4ndK7FXit0o8p8SzSjyjxNNKPKXEk0rsUeIJJR5X4jElHlXiESUeVuIhJXqUeFCJB5S4X4n7 lLhXiYASu5XwK3GPEncrcZcSdyqxS4k7lLhdiduUuFWJW5S4WYmblPiNEjcqcYMSO5W4XokdSlyn xLVKXKPE1UpcpcSVSvxaiSuUuFyJy5S4VIlLlPiVEtuVuFiJi5S4UIkLlDhfiW4lzlNimxJbldii xLlKqGsPV9cerq49XF17uLr2cHXt4eraw9W1h6trD1fXHq6uPVxde7i69nB17eHq2sPVtYeraw9X 1x7uVULdf7i6/3B1/+Hq/sPV/Yer+w9X9x+u7j9c3X+4uv9wdf/h6v7D1f2Hq/sPV/cfru4/XN1/ uLr/cHX/4er+w9X9h6v7D1f3H67uP1zdf7i6/3B1/+Hq/sPV/Yer+w9X9x+u7j9cXXu4uvZwde3h 6rbD1W2Hq9sOV7cdrm47XN12uLrtcHXb4eq2w4vvFQK35sCI6XbcmQMjEkBnUerMwIgpoC5KnUG0 OTAiErSJUhuJTifaQNQZGD4TtD4wvBjUQbSOqJ3yfJRqI/KS8bTA8CJQK1ELUTO5NBE1Eq0NDCsF rSHyEDUQ1RPVBYaVgNyUqiWqIVpN5CKqJlpFtJLKnUqpFUTLiZYRVRFVEp1CtJTISbSEqIJoMdEi onKihUQnEy0gmk80j2huIHUOaA7R7EDqXNAsorJA6jxQaSB1PqiEqJioiPJmUrlCohlUbjrRSUTT yHMq0RQqfiJRAdFkoklEE6myCUTjqZZxRCcQjaXK8onyqFwuUQ5RNtEYoiyiTKLRVHUGUTrVOYrI QTSSqk4j0qmcnWgE0XCiYUSpREMDQ08GpRAlB4YuBCURJZIxgSiejEOI4ohiKS+GKJqMUUQ2okjK sxJFEIVTnoUojMgcSCkHmQIpi0BGIgMZNUpxIiaJ9xIdlS78CKV+IPqe6DDl/ZNS3xF9S/QN0deB 5CWgQ4HkCtBXlPqS6AuizynvH5T6jOhTok8o7+9EH5Pxb0R/JfqI6ENy+QulPqDU+5R6j+hdooOU 92eid8j4NtFbRG8SvUEuf6LUH4leDySdAnotkLQU9AeiA2R8lWg/0StE+8jlZaKXyPgi0QtEvyd6 nlx+R7SXjL8leo7oWaJniJ4mz6co9STRHqInKO9xosfI+CjRI0QPEz1E1EOeD1LqAaL7ie4jujeQ OAMUCCQuB+0m8hPdQ3Q30V1EdxLtIrojkIjzmt9OtdxGdCvl3UJ0M9FNRL8hupHoBqKdRNdTZTuo luuIrqW8a4iuJrqK6Eoq8GtKXUF0OdFllHcp1XIJ0a8obzvRxUQXEV1IdAF5nk+pbqLziLYRbSXa Ekhwgc4NJKwGnUN0diChDnQW0ZmBBCeoK5CAw5ifEUiYBNpMtImKb6RypxNtCCTUgjqp+HqiDqJ1 RO1EPqI2qtpLxU8jag0k1IBaqLJm8mwiaiRaS7SGyEPlGojqqWd1VNxNVEueNUSriVxE1USriFbS oE+lnq0gWk6DXkZVV1FDlUSnUHeXUkNOqmUJUQXRYqJFgfhCUHkgXrSwMBAvlvfJgfizQQsC8bmg +eQyj2huIB73Aj6HUrOJZpGxLBC/GVQaiN8KKgnEnwEqDsR3gYoCcWWgmUSFRDOIpgfi8PnOT6LU tEBsFWgq0ZRArFgaJxIVBGJngSYHYitBkwKxy0ATKW8C0fhAbA5oHHmeEIgVAxsbiBV7M58oj4rn Ugs5RNlU2RiiLKosk2g0UQZReiBWzNIoIgfVOZLqTKPKdKrFTjSCyg0nGkaUSjSUKCUQcyooORCz EpQUiFkFSiRKIIonGkIURwViqUAMGaOJoohsRJHkaSXPCDKGE1mIwojM5GkiTyMZDUQaESdihb3R q+0CR6Nr7Eeia+0/QH8PHAb+Cdt3sH0LfAN8DRyC/SvgS+R9gfTnwD+Az4BPYf8E+DvyPkb6b8Bf gY+AD6Pq7X+JarB/ALwPvAe8C9tB8J+Bd4C3kX4L/CbwBvAn4I+2tfbXbSfYXwP/wdZoP2DLsL8K 7Id+xZZt3we8DLyE/Bdhe8HWZP899PPQv4Pea1tj/63NY3/O1mB/1lZvfwZln0Z9TwFPAoW9e/B8 AngceCzyNPujkV77I5Ft9ocjffaHgB7gQdgfAO5H3n3Iuxe2ALAb8AP3WDvtd1s32O+ybrTfad1k 32XdbL8DuB24DbgVuAW42Zprvwn8G+BGlLkBvNO61n499A7o64Broa9BXVejrqtQ15Ww/Rq4Argc uAy4FLgE5X6F+rZHnGy/OGKh/aKIevuFETfbL4i41X6uId1+jqHAfjYvsJ/l7HKeuavLeYZzk3Pz rk1O6yZu3ZS6ad6m0zft2vTmpsI4c8RG5wbn6bs2ODudHc71uzqcD2tbWJ12buE057pd7U5je3y7 r91wqJ3vaucl7XxsO9dYe0y73m6I9Dm9zrZdXifzlnu7vH6vcarfe9CrMS+P6Ondc683dUQZuHCj 1xZTdpqzxdm6q8XZXNfkXIMOegrqnQ276p11BbVO965aZ03BaqeroNq5quBU58pdpzpXFCxzLt+1 zFlVUOk8Bf5LC5Y4nbuWOCsKFjkX71rkXFhwsvNk2BcUzHPO3zXPObdgtnPOrtnOWQVlzlIMng2L GaYPM8SIDpw8DD1hqbxobGph6sHUz1ONLNWfuifVEBc91D5Uy4pO4cULU3hLyhkpF6cYopNfTtYK k7NyyqKTXk76c9I/koxDCpOy8spYYkyinmhIEGNLXLCkTPKMEuITJsqxLkh0ZJRFJ/DoBHuCVmpP 4Cz2YOznsYaEJ2JejtGio3l0dG+0VhgN9+goe5QmHr1RhsKoEyaXRdvsNk08em2GxEIbLKLG0ZHl S8qirXar5pxhXWjVCq0zissKrbljy5iB65wzHgMyWEQveIK9DPv63kRu4vg8372kIjt7Xo+FLZ7n t5Qv9/Nt/vQK8SxctMxv3uZnzmXLK3dzflHVbq4VL/HHi/9iK9PnXnghKxo+zz+8otK/c3jVPH8X RKEQvRBs+O5EVlSVvbKtvS0727cSj5Vtvmz5gxRvF6lsYRQ/bT6kRWyXaZb9s4HcQKvaEHzK6Pv5 Uv/bA/9Pd+D/ftjNxJcMZvZq57Ba7WzgLOBMoAs4A9gMbAI2AqcDG4BOYD3QAawD2gEf0AacBrQC LUAz0AQ0AmuBNYAHaADqgTrADdQCNcBqwAVUA6uAlcCpwApgObAMqAIqgVOApYATWAJUAIuBRUA5 sBA4GVgAzAfmAXOBOcBsYBZQBpQCJUAxUATMBAqBGcB04CRgGjAVmAKcCBQAk4FJwERgAjAeGAec AIwF8oE8IBfIAbKBMUAWkAmMBjKAdGAU4ABGAmmADtiBEcBwYBiQCgwFUoBkIAlIBBKAeGAIEAfE AjFANBAF2IBIwApEAOGABQgDzIAJMM7sxdMAaAAHGKvlsPGjwBHgB+B74DDwT+A74FvgG+Br4BDw FfAl8AXwOfAP4DPgU+AT4O/Ax8DfgL8CHwEfAn8BPgDeB94D3gUOAn8G3gHeBt4C3gTeAP4E/BF4 HXgN+ANwAHgV2A+8AuwDXgZeAl4EXgB+DzwP/A7YC/wWeA54FngGeBp4CngS2AM8ATwOPAY8CjwC PAw8BPQADwIPAPcD9wH3AgFgN+AH7gHuBu4C7gR2AXcAtwO3AbcCtwA3AzcBvwFuBG4AdgLXAzuA 64BrgWuAq4GrgCuBXwNXAJcDlwGXApcAvwK2AxcDFwEXAhcA5wPdwHnANmArsAU4l9XO7OLY/xz7 n2P/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/jv3Psf859j/H/ufY/xz7n3sBnAEcZwDHGcBxBnCc ARxnAMcZwHEGcJwBHGcAxxnAcQZwnAEcZwDHGcBxBnCcARxnAMcZwHEGcJwBHGcAxxnAcQZwnAEc ZwDHGcBxBnCcARxnAMcZwHEGcOx/jv3Psf859j7H3ufY+xx7n2Pvc+x9jr3Psfc59j7H3v9Pn8P/ x0PVf7oD/8dD8qqVjIXtYOzopQO+f13O1rA21oW4hV3ILmVPsDfZanY21FVsJ7uF3c787En2O/b6 v/j97uOGo52mJhZpeJCZ2RDGeg/3fnr0FqDHFNXPcilSQ4z6MUtvTO9ng2yfHb20N+ZojzmORciy Nm0/rF/xI72H8fmKdO8kkda2QkfLEl+E7Th6z9FbB83BIraMLWcr2Kmsmrkw/lrWwDyYmbWskTWx ZplqRl49nnVIrYIXzhKpj3m1sFbAy3ysna1DbIVuC6ZE3mky3c46ENezTraBnc42sk3BZ4e0bETO BpleD2xmZ+DNnMnOkkoxWc5m57Bz8da2sm3svJ9Nndenutn57AK854vYxT+pLxyQ2o74K3YJ1sNl 7HJ2BbsS6+Iadu0g66+l/Wq2g12PNSPyLofleqlE7qPsOXY/u5vdwx6Qc1mDWaMZUfNSJ+ewFXOw ESM8u1+Paf46+mZrM8YuxtYdHOl62M/qV2JdcB6F59nwpFroPYhaNg2aie0YA+ljI6LU5XL8x6z9 Z+XnrGo+ru03M9fIlFCDrT+lr2DXYQfegKeYVaFuhCZ1vdT97Tv6fHfK9G/YTexmvItbpVJMllug b2W3YW/fwXaxOxGP6f6K+G52l3xzfrabBdi97D68yQfYg6xH2n8u73j2e4P2QJ/lIfYwewQr5HG2 ByfNU4jK8hhsTwStz0gbpZ9iTyMtvCj1HPstTqjn2e/ZC+xl9ixSL8nnXqT2sf3sVfY6t0G9wv6G 5xG2z/QBi2IzGTM9jHm+lq1ENOFUajPsxyliYGHsRLaAncyWP8ps+LhPZFP4/fcnlJRYcsMex0e5 xnRcBiyM8+LCaKNme3Do0BmOByeaLzTEzunhuffNCLsQ19wZR9458lL+kXc+jTsx/1Oe//a777wb 88VLsSfmj3/3wLsnjOWxabES8VFaWFi82TEyT5s4OmPS+PHjpmsTJ2Q4RkZp0jZh0uTphvHjRmiG eGWZrok0N+z/YZlh4RGzttkxY+l404ih0fE2s0kblhyXOy09pmJ5+rS84WGGMLPBZAnLnFw0cl5j 6cg3wmKHJyQOj7NY4oYnJgyPDTvypinq8JemqO+LjY3fX2YwT10xY5ThygiLZjSbe0Ykp4yZmjZn afSQGKN1SExsoiUsLjYys2TFkS0Jw0QdwxISqK4jC5jGI3q/4W+ZVrIElsWi7jelpy6IKWMzZrz9 EoarOm/IoN4nDBk8nMfCRHXD4sJiuSXBMSzVkWCJCk/JtNuzksPDk7Ps9syUcN5uibQYjXgYHo6M izSZI2Mjvz8xLTvVak3NTkvLTbFaU3IZZ2MM7bzNtJ6lsvCANWkWm/EidSEsLMogGp08pK/ZNnNU Uux5JtuQlCGxSRHceK41edTQlFFJVlOGfXx+bvJLYZFhBkNYZDgfcsZQPc5sjtPF/322zdBhyJMt TGa2+8wjE8ehlfEvjkM7Cf1GNjn48sKOY01MjA/TbrEmOZKTRyZazbakmK2myLiUuJjECG46mnSc jASr0Thrc7AXQ0eMz8tNedESEWZE9yxHP/2JDNHbbEOH9kpfb62jk8b39bZvVjIyJhybFtNxJ0t7 RXRmm9EWlyw6YzgnIsmRkuRItB69ul8Gum+UOaL3ptF29Cb5RYsVvbFgFmMxi7Fmc6w+9Kcy8Il8 QyiGYiiGYiiG4v+S+OF/F3mSjM38uVAMxVAMxVAMxVAMxVAMxVAMxVAMxVAMxVAMxVAMxVAMxVD8 /xPlN7tytZGM/pZaxmrlU2jOomRKaI1FGYxM/W22Yw1xQW3s52NiyYaioDb3s4exw4ZlQW1hYwz7 gjqc6cYlQR2h7ezzt7KlRl9QR7IxxueD2qZdaTwU1FGsMeyCvr/jdFzYd0HNWZhlTFBrLCx8Q1Ab WHL4mUFt7OdjYpHhVwW1uZ89jG0KvzmoLSwh/GBQh7OYiJFBHcHL+/ytLDtiXFBHsoSIU4PaxudH eIM6ik2yPi7+9l9jeHCeSdM8k6Z5Jk3zTNrYz4fmmbS5n53mmTTNM2maZ9I0z6RpnknTPJOmeSZN 83w709k4NhaxAGqB/Gaal7WwNqCO+WArlt/oo+/1uWDxQDWzPOTMZI2IOlsMWz1rQF6bTLnBbniv w7MWnsUo1wif1bB54OGRfi6gCXXVSt9mpNpga5Z5VN6DHuiAC34e1NCJVAeUD23p8nuEq6Eb4avL PrejdK38nmK9rKUlWKsPHk3BNoWHjjG2yDbd8vuIYixz5FjrYHHJ78l55Sh0yS45StEujaMGOTmy 5iZpaZQ1ujBHZFetNKGeRjljrcFeNsPSJFulOsU4ff16IFpslWNR36Ok2aa+i5ZaMAO6/AZhvZwF j/zOoPgupk+mxIh9fe+D5oxa0WXfm4PjapFzu1p6Hutx/xGJWVsvy9Go1yKdJ9dD/7c5WtbWJGvo lPPQHnzz/edbvDEav1v2X4yf3otXrgbB1KJ41zrqaO0bDfWxPujThtSGYO0+jILe0Lq+t+SSa8QF a9OAcanVXIOeuGT7NcH28+SKrZfvSuT8eA9M+dGop/TtmolsaXAVeYLrbSJqnITc4696d3D90mhc wf7Xy1zqjzs4Y6KPtXLlil6tle9MlTl+bt3/aAcfWy30bpxIeWQfRPsVcrX7BrzH/GAPWvqNoCa4 73xylG65lufDUsMy5TvOgk+trH+W7BWV9SG2YhbzETtkzJN7fGDP82TtTfDxYW2J/tfLEbSihk5Y xRusk2MRO2dgrcpeJ7/N7JXrV9VXJftMq7ZTrrY22UOf3Fdt8hyg0rocg9iTbrmiPLINmqHVsqya vVLM33yciFTW2y+H9nOtnJNje7Qj+C3ghp9ol9LCtwarqF3OYW3fmq+V+a1yxXb2W+etcqTNwZVO dbnlU+zcweMW+XRCZKJUllydTRiXu2/P/rhXzT+q+ZfP0bHa1SmtB89ZWj01A867H4/92Hod2K+p /WZAjITGQqe+WvXevk+QWnmGNsuz1PWTI6V5dg2YU3dw9Q/eA2JWxcprlyVr5XkkRuPuq0d4Nsoz 7efe0P+rfXFsT+TL3og9QJ9EefJdtbL1t+vjxo4t0Bd4arwtbS11Pr24xdva4nX5PC3NefrMxkZ9 sae+wdemL3a3ub3r3LV5xa5Gz2qvR/e06S69qaXW7W3W21zNbTryPXV6navJ09ipd3h8DXpb+2pf o1v3trQ313qa69v0Frj63E0o2Vyr17R4m93etjx9jk+vc7t87V53m+51uxp1jw9t1LTl6G1NLvSg xtUKLYo0tTf6PK2osrm9ye2FZ5vbJyto01u9Lei36DZqb2xs6dAb0HHd09TqqvHpnmbdJ8aBnqGI 3uhpRlstdfpqT72smBryudf7UNiz1p2nB4c5uk1vcjV36jXtGDz129eA9t0duteFsXg9GDYKupr0 9lbRDGqsh6XNswHuvhYMaJ0YkkvvcHmbqC0xzTUNLi865vbmLXbXtze6vH1vYIpqeop4NROXYoow KH1i3qRx/abejflFMy7UX+8R/XCjY15XrbvJ5V2rt4icfsm6479gOS0YjbPZ40P5Cp/LR2PMRwUt soEavDuf1+Nuy5vfXpPpasvSa936LG8Lcn2+1in5+R0dHXlNqvK8mpamfF9na0u919Xa0Jlf46tr afa1BV2FrnNhAGuFX1VLO6a2U29vc6MTGJLI1l14k25vk8cnOrS6U3av1Dl/JnK9MoH3XNtOb7Sj wVPT0K8s2NNc09heK+aiRa/1tLU2ogEx561eDxxq4OVu9uXpqu2WZiyITE+W7m5aLQodq6pZOR+3 R9JdLGlMfxump4bWXV/rcl6DdU2VHcj0oBUsfTH1XrFBals6mhtbXP0bRZ9d1FNMfN8baGn3tbb7 MO3rPDVu4dPgbmwdNKBf8i7km8ivdde5sInyXG2t6/t+H2S9yWzLcf/3JA4P/EbBhrCw3l4WHfy3 RszIyARnMvajf5dkQDDMNayKjOTw4eW/1N9mk/7rf6l/dLT03/lL/WNipP/eX+ofGyv9P/+l/kOG cC6Yid8qjdJf/FZtFP/+imE5sxlWsgTkDoctfZBfVj+/KPglIncEbBmD/Bb284uGXzJy02AbM8iv s59fDPxSkCv+FCB7kN9N/fxi4TcUuQ7Ycgb57evnFwe/YcjNgG2sWBcWzi3GLhlYl0FjFkNhYZfB yC2m8p078QsvuHxnOOfhQSfyCg96hQe9woVXBNciTH1eXUaNRxgL4Wc08Qjz7O3btxtNDGL27O1W rlmVZ9DVqlytYeQqBFwjuRZp7hroG6l8I5VvpPS1aZrNvKcvsD17TAZuM1VXV+/pMoVxm2Vk3Qsv vGAKYzZLXV3dC9vk7ESwG7VKZqjp9Day+Hqvey2b0ujyNeM2GMF4xeIinSVjp/XK1WBmNhYfTHH8 Vh/FEqSdLJg87LVERMOc8vLZbNTihQt0NnbJ4nk6mx70EfsyhiXJlAEtxPbVbsRv/XEsJZgy4ff+ IWwoS61pbWtlN8nnHfLpl88H5PNR+XxqLT7M2V75fEk+D8jnG/J5UD4/lM9PxOcK+1I8uVk+h8pn nnwWyedS+VzTtLZpLd8sn1vk8yL5vEI+d8jnLfJ5d9/u+u+e/Bc+xb+kY8AcmDHDFib+NOQ/Z9Pw Hmz/Y47C/he/l4rfXM5il7AbWYA9xfaz99iXHJtHjtQSHO0nTPyZkAHl4uW/RIU9yacQb9tCfN13 /cpgvX1244A0j/xhYDoqY2A6Nm5gesjVA9PpRwemMwfljxk6MD1hLAvX+qcP9cs3Mz5r2sD0/G5w BNZ0JisXf46GMmdhqsZq5ewM7SbtdbbTcJ3hOnbA6DPewP5getW8jRsiKiJc/KGIrVbO90bGRJZq xZHLI3donbZa2xrtMdsZtgu0Z6K0KIu2P+rbqG+1PzHe9Y2YG/NrtgeOG/chvmH7oF/8OBj3HSce ihrZFzMRpyCWIK6R8crB0bYv6sao+2KuCMad/eIdIsay48aI2PK+2B17WV/8hmLcsOPEPMQJ8Vf3 izdRlDmDYnwgfm9ffCnhIOKHIiYajxfj8hLjEjOTuvvFy2R86rhxX9JhFZPjk4f2xZJgnHvcWC7j 0iAPjF3Bp/B7TsYDfZFKv5P8ecqYlNqUHSm3iTi49pS7jxep9pSelPeC8dCxKFpJOSzb6hIYPt8x pS/Odyzui7XBuAaxy7Fm1DjEwvS89BLHGjzz0p/K2Dv6NRkPZS5DbM3KQMzJei/rO+C9rKNj9mbv EDHrvexHsz/O/jjHmBOVE5/zMOKBvOmI5XnL8q8NxsdP6BqfMf6vEy6ZNAFx+uTkycsmry8IBOOj Bc8VHJgyBrFgypapb51klnH7SU/J+MP0SdPvDMYHTvoB6Tunfy5Tn8/QZmjT75yRU3hR4aMz80or Ed+Z1XDSdvIGf05ec6YLvznz546cO3bu9P/i7UzAm6rWvb+SnSZpkzCUeVAMIIqKKKB4wAEVOQha KgoiTjmIQxCRqVDAQiGIszgiqNdZRFT0GPUcp5yilaEMFmja2iClLSEh7pa2dO+GAq7vt3fLoF6f 6/2e5/ue/fzYO3vvtbLe//9d71pBzr2j1ozuYx6Zo6eYR/boZaNf5c/s0QUce6+bf13udXuun86x IsPHW5kZ2zO2jy7gz93GFUdlhprRNCbXPFaP2Woee8aosGeMnmkbo/NczZyYuTuz8obZHM+NPYP3 Vo/Rm5+MnT9GH7tvbM24zPEbJky4Pf327rf3udd278R7S+9tOn6+7zyOT6e1mdZzevb0JdPzpldO V6frM2wzBswYPuOeGdNnzJ/x6IwVMz6c8cWM/Bk7Z06f+dzMNTPrZ4lZ6bNGzpo065tZxbMHzZ40 +9Ws8VmPZoWyGubY55w3Z8ScD+fsnzt8blN29+wR2b7smdmvZq/LLp3Xc95t876YVzqvab57fsf5 l8y/av7k+avnly44Z8HwBXcsWLlg7YLdC/SHhj00/6Fvcuw5w3Jm5nySsyHn6MKuC+9buHqhumjI ouxF63Iz/6RWffH7evTbapM75+Rh1JHcN04ezRXkT+beqN/PuN/Ok+ZM/2+rzvHKc8rx29qRu+Hk YVSH3KKTR3NdMGpom7WdN3R6gTpcdnktVdOsweaZets2k/q6stVbbVZ4Ck/UTN5tq/eabLT1fNFq 5cna2awS1Xm4WX+b3+rZ6q3j6hl3jVpsvltmPDffb1GQfr/w7KOSv0WLMrO3Qka3gnOZeZxcHRK/ WxWGn7IOnFwJ3jLG/Yfqv/YP1T+tpeY/btZ7s8qb/dC61XCuVx6vhPixpsUvalNz/Wmuby0+UhOp gIZrk09Ux+OOUuM6j8qtNFqc9LjX2NzK3Ep6M95q4Flml8peY/+YE9TBolMq6n9TZ0+tq3+sqS2V e4OZTc1V9Lrj9dOo69zhW3PVLmu4M7Zz5sWDMrZ3tDWvY+aZNatTU4e9ZFX68dXn+KqS3r2j7eQK 1JyVxtpmvm0z3qDtdx3TjSfGHeMt4356d0/h8Uzt3DW9OytgutHeuG6+e3IdPXUlNcZirpot6+Yp K2c6Pfx+nXzhN6tjYcvK2P746Hne1PztxvePzuywt/NwxvMb9Q3VDI1x6pQZe1zj5ploqNmcKb0m o/cow01Dic6Z7V82/V5jeHPKrB7SZR2xHl9hi5p7zVU75+aqzYfxDca511jDFeOqOdOMc6565vm9 BzTTvML1HmCuSqccxgrXvLqZ6+P/5WGuqaccf3zDXGlPOVpW3BPHH1sYK+3/7jDX4r98nFix/+T4 vVLGcWId/5PDXNn/8mHuNv7i8Xt1zD3KKccf9TP3LqccRt43O/2/O/7Y8/88ur92NOts7F1avXWZ fVTPy456yoxdj3k8Y96xGzsd89Mzo3oae6CWZxzsoC4xdk3Nd43ab1wZh7k7mmDurIw9VO3lteb+ iN0RV99d9oy5O8k9sYsxjtVjcjN2j8k1djDmp9Ut+5zm69XsgiqNO8aOxmiX0XKYO57Z5t6Id82n q40/u6zj7dXGbopq0Sdjt7nvym45Ms07fYxdl/kpM2O3UZdannGwc7uAvZqxQzPaLTOvOMx92nRz P8e75k7txH5tdOYVVlORo4YWN8xuVuIyuxkPI24e6egCs2/jm5aZfZn9/nYm/tHRU/PgrOLmT8Ju yZNlyvXyG2WcaK1MEG5lpqxTQmKwsPKkkE9R80pVxsl9wsKfjcLKn5uVCbKQX+gfyKMiXx61+EQ7 yz/EWMsk0cVyl/BaJou2lvtFW94cxJtXKFPlf4SFfqqEjXfdvNuWd928m2b2F+WtGpFquUN053kv no/j+Wk870VfZ9KXl9avMJ49wsXVp4y3rfIQ48iR/2K8Q5Qq+ZKyT1ygRMUAJSbOVQ7IHUrC+P/2 TO+F9F4pbFxZlQm/HmE0L9DT9yJbtBajRBsYIvqKoTBZ7hB3wz0wS8bEbNkgsmAOzIVsmCfcYr7c KRbAQ5ADCyFA+6XwMCyDR+BReAwehyfgSfhSXCW+giTXv4IUfS0CLJAphlpugLFwI9wEfjHGskH0 IGK/Ml5cqtwqnMqdMFU8qiwSpyuLxRlKQJxue13utL0Bb8JO0de2C4ogDMVQAqXwE5RBBHbDz6Jv Shu5I2Wv3Jnyi3CnqFxXQ63caU8Ro+x9OQ8Ufe0Xc54qd9gfgGnwIGTJmH0OoI0dbexoY58PaGP/ WAy1fwL/gkYx1HGO6OE4F+4UfR0+mAQzYCbMg1xYDGjkeAaehdfhTXGV4wPO1VADtVAH9dAIaOi8 CybD3ZAleqQKMTS1vehh5u5+8jrNvDqA642iA1kbJGuDZFsfsu1Ksm0J2XYj2TaJbLuWbBvG2++Q L+cr4+XTys1yPhl0EXnzIj34lJBcrVSRZ1GhKPvJwQPiVjPP9vHWbraZx2fFHaL/Kf2PpP859H8N /Q/m7Yn0/QJ9/4tWA+l7BX2/Qn/f0N940YpeDtLLQXppQy9n0cs0eulPL/3p5Vx6OYtR7qGns+lp Mr0MoIc1ZqSbufpYdKaP/9DHf+jjbMud8iv66U8/d9LPIPq5kX6usPjlj/TV37JS/puWX9Ofjf7m MLJ76LMdIwvQ2xNKpWxgdAVKnNl6QPRTEi0zti29nkOvfnodTK/X0Gtvejyb3nbRchcz73qiHCdc LRXmGJXEqCyrRECqYik8DMvgEXgUHoPH4Ql4EgpkUmyBrbANtsOPUAg7YCfsgiIIQyn8LKXYA+Ww FyqgEqrkFrEPolAvI+IQ87wBNNChEZJUt8M8b4IjcBSOwa+MRUrVIsBiVsUqZSIZdps8qNzB2ScP 2nZK1bYLiiAMxVACpfATlEEEdsPPEJdJ2wFIwC+gQjXUwEGohTqoh0PQAIzF9itIuSUlXW5xDJNJ xzUwCkZDhow5buI8Diby/Fa4A+6UqsMHk+B+ns3gPBNmcz0XsmEenx/inMt5MSzj+hHAB8dyzs9w fhae5/oFeBFWwEv0/zr33+L6Ha4/4Ppjrr8GPHLgkQOPHHjkiEjp2A145MAjBx459tKmAioBjxwH ZMSRgF+IRYVqWeiogYM8q6XvOqiHBj7jnUPn3MhnPHLeBZPhbvyyiqdFe3PlUsTT5O44cthYvVL4 9BGfRvHpWrI8X/lRnCss3NXFcDIzQmZGyMwImRkhMyNkZoTMjJCZETIzQmZGeDtGpiXJtCSZliTT kmRakkxLkkUqGaOTMToZo5MxOt+Xx/dFlNtFivIPmEQG3SWryJoIWRMhayJkTYSsiZA1EbImQtZE yJoIWRMhayJkTQQndZzUcVLHxQguRnBOx7UIrkVwS8cpHaciuBLBjQiqJ1E9iepJVE+iehJVVVRV UVRHUR1FdVSMoKKOihFUjKBixJyxZcKBllcyk52svd+y9n6uFLLW7mAVYrUx9U0Q4Q4irDD1fYhP nfnUHX2X0EOJmMA66WWd9LJOelknvayTXtZJL+ukl3XSyzrpZZ308k0Xs1b2Zq3szZwtYs4WMWeL mLMVzFmNOasxZzXmrMac1VhP05mzUeZslDkbZc5GmbP4LUazbg5inlYwT8uZpxXM03Jlkuij3AVT xVLW0R6soz1YR7uxdnpZO72snV7WTi9rp5e108va6WXt9LJ2elk7vaydXtZOL3MxylyMMhejzMUi 5p7GnCtizhUx56KscV7WOC/rm5f1zcu65mWuRFnbvKxtvZkrUdY3L/lfRP4Xkf9F5H8R+V9B/leQ /xr5r7H+pbP+pZP/UXK+iJzXyPkoa6CX9c/L+udl/fMa+S7r0bqe/dnT8mEcGEk9r6CeZ+HESJx4 l6dPku3XKDvZSRXJX5WwmGS6F+HtMt4qZcV8Wi7k0yTa7qTtLu4Oo+3TtN1I21G0LaLdLcLeMo9u 5s0wbxbx5ihzf2XkzHtmT3fz/Aqeb+d5Mc+H0tNjPP2Enq6ipwJ6usB8/ydzn7jH/FMXaZbWoodl IkyFB+BBmA4zYCbMhsdZ6dta8oSHb1lC79n0s9ncG70hOilfi4uU9fhfKXqxat/ILjGdlbsru8Re SpzKcIARJLj3i7iI9XymXE+LjuwpexprOu2nimtZwSaS87eKa5U7zN3XtaIVI+vGyLoxsm6MrBsj 68bIujGyboysGyPrxsi60bI9LafRsj0tp5ktPbT00NJDSw8tPbT00NJDSw8tPbT00LIPLS+kZR9a Xmi2dNPSTUs3Ld20dNPSTUs3Ld20dNPS3dJyUEvLQURyqziHq3NMjYPmHqERtSLGv9WGG2As3Ag3 iTT2bmns3dLYu6Wxd0tLNf47rQ2F29Ems2WnkW96VCGKLGfLSktfOAfOhfOgH5wP/eECuBAGwEAY BBfBxTAYLoG/wRAYCpfCZXA5XAHD4Eq4Cq6G4XANjIC/w0i4FkbBaLgOrocMGAMvwyvwKrwGr8Mb 8Ca8BW/DO/AurIb3YA28D2vhA/gQPoJ18DF8Av+ETyEIn8Hn7NbyOK+XZZbv4HvIhx9gA/c3yrBl E2yGAtgCW+V+yzbYDj+yg5jIr5U7ZKHtB3YSG2AjbILNUABbYCtsk2HbdvhRhlPaysqU9tABOkIn 6AxdZKV9OawCNLC/JvfbV8uD9vdgDbwPa+Ez7n/Pmd2m/QeuC2XYvov3S7nWZaXjNDgdesAZ4JUH HT2hF/SGM6GPDDvOgrNlmaMvkAsOcsGB744BfB7Is6Fyv+NSzmPlQadVVjoVsEEK2MEBTkiFNHCB GzzQClpDGyBeZzq0A+J2EreTuJ3E7SRuJ3E7u0I36A6M38n4nYzfyfidXugJvaA3nAl9GNMAud85 EP4mw84hMJR7w2AE/B3u5L1JnO/h2b28dx/4YQpk8SwHFsIiyIXl3H+b99/j/TWyzPk+n9dCPfc0 WZlqAWJNbSfDqcSR2kHuTz2DHFpgQR0L6lhQx4I6FtSxoI4FdSy0sKCOBXUsKGNpI2OWtpAO7aA9 dICO0Ak6Qxfoyp71dOgBZ4AXekIv6A1nQh84C87mV3ZfOAfOhfOgH5wP/eECuBAGwEAYBBfBxTAY LoG/wRAYCpfCZXA5XAHD4Eq4Cq6G4XANjIC/w0i4FkbBaLgOrocMGAOZcp/lBhgLN8JNMI5xj4eb YQLcAjmy2rIQFkEuLIYlEICl8DAsg0fgUeD3huUZ2Wh5Fp6D5+EFeBFWwEvwMjXyFXgVXoPX4Q14 E96Ct+EdeBdWAyugZQ28D2vhA/gQPoJ1QK21UGst/4RPIQifQR61fD18B99DPvwAG2ETbIYC2AK/ ryLj5D+o0hNYB1pT+S9lHWhN9b+Uqr3DRsWzUfFsVDwbFc9GxbNR8WxUPBsVz0bFs1HxbFQ8GxXP to7fKB/DJ/BP+BSC8Bl8Dv+W1bYv4Sv4Gr6BbyEE/4E8WA/fwfeQD9uE27YdfhTulLYiLaW9cKV0 gI7QCTpDF+GyPymr7U9J1b6c6xVcr5Qx+yrWJDwwq9kbPCMW+7s8Y8x2xmxnzHaqtP1juc/+CXzK syAYVe4L3v8X977k+VfwNZ+/AcZpZ5xm9dvI5wKebeG8lXvbYDv8CIXCbd/Fd/Pbzs5vO3sx90pk o1kpyxgbv+fsMdrym8Wucs3u2s7u2n4Q+M1i5zeLnd8s9kPQABroxNYo9zlayWpHa2gDbaGzbHR0 ga7QDbrDaSLNcTr0gDOgj3A7zoKzoS9cyL0BnAcCq6yD1bW56gq30ypcTgVskAJ2cIATUiENXOAG D7SC1tAG2kI6tIP2Is3ZATpCJ+gMXaArdIPuwDidjNPJOJ2M0+mFntALesOZcJasdp7Lb7TzoB+c z2d2Cs4LuT5eiQdxfTEMhkvgb8QxBK7j+nrgd65zDO0yZb7zBhgLt8hG552M8x7e+32V5veuk9+7 zrmQwxgWwiLI5f3H+G7mv1m1V3BeSb+r4GV4Bd6jvzVwvIp/wD08dGq0PSIbU4Xcl2phr+SUaip6 pqZxbsv9dsJtVnZWqNRO3OsMXYB6nNrd+HtJY6a37KtymKFhc4/23Yn707g/z/x7FGO/VSNSrCPl bcr18nt2p2nG323xrFqcZ71AJqyDYDBcASPlDuu1cot1NFzPrnyc3MPuYje7i91pE+SWtInwiEyk PQqPwePwBDwJTwG/5dKWwzPwLDwHz8ML8CKsgJdgJayCl+EVeBX+C16D1+ENeBPegrfhHZlwnysT QmGkunUCv4ln8ht6KOPXGL9mHSKjjF+zXs35MVlhfZzfLreKftSvfry5Je1GGU27CcbDbXCXrEib AlNhGkyH2fCI1IhNIzaN2DRi04hNIzaN2DRi04hNIzaN2DRi04hNIzaN2DRi04hNIzaN2DRi04hN IzaN2DRi04hNIzaN2DRi04hNc42SFa7RcB1cDxkwBjLhBllB7BoeDpYlOLTVavooN5l/c9iD2NcQ 9xrrrXKddTI8AI/JPDTIM35/E/saYl9D7GuIfQ2x5xF7HrHnEXsesecRe15atlyXNg8WwGJ4WK5j XHmMK49x5TGuPMaVx7jyGFce48oTV+KAHwf8jK0KB/yMr5EMaiCDGhhnOSMpZSSlyrhfG5QJv2qs Lh6c6c/q4sGd/i2/8fPJrgayq4HRlTK6UkZXyuhKGV0poyvFGT/O+HHGjzN+nPHjjB9n/Djjxxk/ zvhxxo8zfpzx44wfZ/w448cZP874ccaPM36c8eOMH2f8OOPHGT/O+HHGjzN+nPHjjB8FSlGgFAVK UaAUBUpRoBQFSlGgFGf84mpU8KGCDy82o4IPPzZbR4rTiD6D6DNa/r71iZbf0+egQkdUGNjyL48H tvwt8S14tRmvNuPVZrzajBoZqJGBGhmokYEaGaiRgRo+1PChhg81fKjhQw0favhQw4caPtTwoYYP NXyo4UMNH2r4UMOHGj7U8KGGDzV8qOFDDR9q+FDDhxo+1PChhg81fKjhQw0famSgRgZqZKBGBmpk oEYGamSgRgZq+ISDXGggYjcRP0vEc4g4nQgXEuFc0QWN8tEnH22K0abY/BfOd8JM+Tzx5xN/PvHn E38+8RcTfzHxFxN/MfEXE38x4yhmHMWMo5hxFDOOYsZRzDiKGUcxc8Uv3/tdvWsQ/aw3UOMmgJ86 N4Uadz9MBfpmxHtP1LocasYiucW1QCZcD0EOLIRFkAuLYQkEYCk8DMuA2uiiNrqojS5qo4va6KI2 uqiNLmqji9rooja6qIsu6qKLuuiiLrqoiy7qoou66KIutkqFNHBR84zKnjDHrjHHo8zxKHM8im7G 7/Q+PN3J3I0yd6PM3ShzN8rcjTJ2jbFrjF1j7Bpj1xi7xtg1xq4xdo2xa4xdY+waY9cYu8bYNcau MXaNsWuMXWPsGmPXGLvG2DXGrjF2jbFrjF1j7Bpj1xi7xtg1xq4xdqNmTZA/ofZWFF5/omYZEZWL AUQU5Hklzxtx4yhuHMWNo7xbzrtO3nUxU9KI9HxmShrRnt/yd0AbcOgoDh0lyiBRBokySJRBogwS ZZAog0QZJMogUQaJMkiUQaIMEmWQKINEGSTKIFEGiTJIlEGiDBJlkCiDRBkkyiBRBokySJRBogwS ZZAog0QZJMqguIhIAnizCW82Wf2iO/5sIoK7mAGHmQE6kSwlkk4tfzPTyfibGSJ5yfjbLLzbhHeb 8G4T3m3Cu01EFSCqAFEFiCpAVAGiChBVgKgCRBUgqgBRBYgqQFQBogoQVYCoAkQVIKoAUQWIKkBU AaIKEFWAqAJEFSCqAFEFiCpAVAGiChBVgKgCRBVgHk8w5/ElRPFjy39zGsGon2fUnwoX8W4j3m3E uo24jP+lRQeevEg824hnG/FsI55txLNN2K1Z+DpHHrbOlfutS8mLp2SN9UXjb9q522RdKnVh4c/D oi9v6NZsMmIeLJVh6zLhtD5C6ydl3LrC+N/TyyPWVfKIi/2ti/2t6zQ4HXrAGeCFnjCZd+6Ge+Be uA/8MAXuh6nwAEyDB2E6zICZMAtmQxbMgbmQDfNgvjxixtPESKusOTJGLPusL8iDVn7piYnWmWT7 LMjibjZRzoNFstCaC4thCSwVHazL5MfW5bz3jNxrfRaeg+dhpfyS+L50WeVWlwI2SAE7OMAJqZAG LnCDB1pBa2gDbSEd2kF76AAdoRN0hi7QFbrJGjSsQcMaNKxBwxo0rEHDGjSscQ2Rha6hcClcBpfD FTAMroSr4GoYDtfACPg7jIRrYTJx3A33wL1wH/hhCtwPU+EBmAYPwnSYATNhFsyGLJgDcyEb5sF8 +aWwkTl7UHEXKlZYV8g6cmmprCdPGkUmLiRxIYkDTThgZFgFK47OiqPzho7KSVROssLorDA6K4zO CqOzwuisMDrqJ1E/ifpJ1E+ifhL1k6ifRP0k6idRP4n6SdRPon4S9ZOon0T9JOonUT+J+knUT6J+ EvWTqJ9E/STqJ1G/CfWbUL8J9ZtQvwn1m1C/CfWbWOV0VjmdVU5nldNZ5XRWOZ1VTmeV01E3ibpJ 1E2ibhJ1k6ibRN0k6iZRN4m6SdRNom4SdZOom0TdJOomUTeJuknUTaJuEnWTqJtE3SRzbg7ZbczF HDRdSHYvFa1Quwq1K1H7oJiOxiE0DpHpcd7chNZVaF1lnc/nHHmAVvVkvkrmq2S+Suar+HAMH0L4 EMKHOuvTciMzoIQZUMIMKGEGlDCXtlIbNuBRGI/CeBTCoxAehfAohEchPArhUQiPQngUwqMQHoXw KIRHITwK4VEIj0J4FMKjEB6F8CiERyE8CuFRCI9CeBTCoxAehfAohEchPArhUQiPqvCoCo+q8KgK j6rwqAqPqvCoihmiMkNUZojKDFGZISozRGWGqMwQlRmiMkNUZojKDFGZISozRGWGqMwQFY9DeBzC 4xAeh/A4hMchPA7hcQiPw3gcxuMwHofxOIzHYTwO43EYj8N4HMbjMB6H8TiMx2E8DuNxGI/DeBzG 4zAeh/E4jMdhPA4LPw5GcTCKg4fw+ztcPIhzZTj3C87V4FwNztXgXA3+u/H/U9xTcU+1PsG9p3B6 ufwIB+M4GMfBOA7GcbAaB+vIk29xsRwXy3FRxUUVF1VcVHFRxUUVF6O4GMXFKC5GcTGKi1FcjOJi FBejuBjFxSguRnExiotRXIziYhQXo7gYxcUoLkZxMYqLUVyM4mIUF6O4VINLNbhUg0s1uFSDSzW4 VINLNbhUg0s1uFSDSzW4VINLNbhUg0s1uKTikopLKi6puKTikopLKi6puFSOS+W4VI5L5bhUjkvl uFSOS+W4VI5L5bhUjkvluFSOS+W4VI5L5bhUjkvluFSOS+W4VI5L5bhULi7AJR2XdHM2NrvQgAt1 uFCHAzoOGL+b6lC3DnXrULcOdetQtw51ddTVUVdHXR11ddTVUVdHXR11ddTVUVdHXR11ddTVUVdH XR11ddTVUVdHXR11ddTVUVdHXR11ddSpQ5061KlDnTrUqUOdOtSpQ506cQ6V4SiV4SizX2U9T7M+ QRRPEoU5eq5XwErW+1Ws293Y1XWH0+B06AFngBd6wmTeuRvugXvhPmAHidaNaN2I1o1o3YjWjWjd iNaNaN2I1o1o3YjWjWjdiNaNaN2I1o1o3YjWjeI+tI6jdZwRq4xYZRYkmAUJZkGCWZAw9T8+A9D9 D5nPDt5q/M3Gn2d7HD/i+BHHjzh+xPEjjh9x/IjjRxw/4vgRx484fsTxI44fcfyI40ccP+L4EceP OH7E8SOOH3H8iONHHAVVFFRRUEVBFQVVFFRRUEVBldmQYDYkmA0JZkOC2ZBgNiSYDQlmQ4LZkGA2 JJgNCWZDgtmQYDYkmA0JZkPiL8yGBA4lcCiBQwkcSuBQAocSOJTAoQQOJXAogUMJHErgUAKHEjiU wKEEDiVwKIFDCRxK4FAChxLmGl9r/lfIi/FKxSuVaqNSbaJor6K9obGKxioaq2isorGKxioaq2is orGKxioaq2isorGKxioaq2isorGKxioaq2isorGKxioaq2isorERo0qMKjGqxKgSo0qMKjGqxKgS o0qMKjGqxKgSo0qMKjGqxKi6jFzIgjkwF8g3YlSJURVtqMXab+cMmfaEOdN1aqr+P80R9u5z2KPy y5TZ5ma22ZltFcy0Dsy0NJFxoqJksRrnwEJ+ly/lux6TtWR2LW8nmZu1rM4NtDofhXUUbjhl11RL dteS3bVkdy3ZXUt21/5/qja1ZF8t2VdL9tWSfbVkXy3ZV0v21f4/3RUZv1aSKLXxxO+WBqG03Evi 0hExDm0L0LYA/6rxrxptjV82ZTiRgr4x9I2Z9W85n1/gN8KL7JRWcm+VjKFrDF1j6BpD1xi6xtA1 hq4F6FqArgXoWoCuBehagK4F6FqArgXoWoCuBehagK4F6FqArgXoWoCuBehagK4F6FqArgXoWoCu BehagK4F5FQ1OVVNTlWTU9XkVDU5VU1OVZNT1egeQ/cYusfQPYbuMXSPoXsM3WPoHkP3GLrH0D2G 7jF0j6F7DN1j6B5D9xi6x9A9hu4xdI+hewzdYy4jziyYA3MhG+bBfBkzNT7cMhOSop31c9HRup4d 53fk5fcy17pRrrEeYp+hyeXWw7JQoXIq/fj12l9+rAyS0RP/Wnm8aKPcLNwt/6Yw7o7I7Tj2Dv2u g++YAd/LIms+mf4DbOQ7N3HeIiPW7fzSLeLbwpyLIS5SrQeYqRp7XJ2dUCM0yTpFyL2KA5zQhV// /WWVcqE8pAyAgXCR1JWhstLtk6r7brnNfT9QI9wPcp4uI+4ZQE1wL+Ccw3khsId2B4AV0/0UMCvd y3n+PPeofe6X+LwSXqWPd+Rh9/v0/zF8Ig+5/wmfci/I5y85E5O7kHs7YCeU8LkUIlzvhr28Vy33 ug9Bo9zraS9rPB2gI/Dr0MOvQ09v7k+R2zzs6T2My/OIbPA8JQ95XoRV8LasEaNaVC3DpySqlqBq NapWo+pRVN2HqqWoWoKqh1C1BFVLUFNHzXrUrEfJepSsR8l6VDyMihoqaqiooWA1CpahYAkKlqBg GQqWoGApCpaiYBkKlv5OwTIUrEbBahSsRsFSFCxDwTIUrEbBahQsQb1q1KtGPQ31NJSrRjENxTQU 01BKQykNpapRqh6l6lGqHqXqUaoepepRqh6l6lGqHqVKWpQqQ6lqlNJQSkMpDaXqRU/rWrnA+rn8 BKVC5OARFFqNKr9Y98h7ybMs6wH5Otk93trATvuwvJw826AoMl+xy6cVt5xGtoeV9tKr9BD3KGfK 2WR+T+V8eRWqvU32jyDnXlEulwuVK+WtLf86q1y5Wb6hTJBTFL/81vj3S0T1FTVpPavE97BR/sw3 7sePPXxjlG84QK+19FhJjweZS0OZS5fxi3Atjq2XO2hlzJet5hyJi9NpvZOWm2m5j7FFGZuLHorM +TBIFtFyvdxMq/20+oIW7WhRwfeVm/OXX9XmHO7BPO3H5/5yD632Msp8cRqZdchsmU9m/QCbyJgt tN5OVhWxiwxzLpb7yI59ZMc+MmMfmVFBZlSQFRVkxSGy4hBZcYiMSJIRSTIiSUZUkAlJMiFJJuzD uX04dwjXjMofF60Yj52Rv8P3reV7/02sX8Im2YSuu9Ez6s6WOv3X0389/de7V/H5NanTT72w0aqB kc+kRaWR9+yE11JLPieW72UhdyPWHdQRQ8M9MoFuO+i3hH5LxAS+dTlv5zKnqsxs+bfM4dtzaFmH Ek0o0UQPVSghUaKhZV41oESDtVSuo8cgmVRoVcmeNGgv71Y64kYn6Ay95CylN5wpf1HOxue+0A/3 0F25gudXmv92+UJGcyFzrwp1G1C3gblXhcINKCxRWDL3qlAhB6UlSixHieUosZz5V4XaTajdhNpN qC2Zf1XMvypUb0L1JtTKQfkGFMtxf0QlWgdfy1nufM5bYRtsh5+gDH7mWTnnCvqolLM8Qm7wpMh1 Hjs4wMvnPjCFCrVYLmcOVuFmk2eFrPS8BCvhZfgvuU64yMh6srESpwdSfY5RfY5RfY7h+mBm+jFm +jFm+jFm9THRHT8ML3W0r0X7WlrZqVF11Kg6alQdsTcQewOxNxB3LXHXEnctsdYSay31pY76Ukdt qaO21FFb6sjvOmpLHWNtYJy11Io6akUdtaLOksY3LiYDVuB+Hu4/h/vPWb/F0RCslxut+ayKP8BG +TZZcMS6k/tF5FapzLL+JL+xlkEEdsPPsEc+Yi3nXAlV9LmPcxRiEBeLyZagNcH1L6CSedWca+Cg nGWthTqu6+GQ9FObCqncpVTuUmbweGrUdusRnh2FY/Jb66+cJauwBaxg1C8b2ZbCtZ06lSZzFRfX bvmAWc9ac24DbSEd2suhZOtIsnUk2TqStXWZ0lXOVbrxrDv0ELcoXs49oRc1rzecKW9T+vD5LDib z33hHK7Pg37yamrkP6gsH+HaYlxbjGuLyfbrqZdPKRfzzmC4RC5R/sZ5CAyVi5RLOV8Gl8vbmRUj lWFcXylnMjPGt/yL2Y+YIXOViaKz+X8vyC9/pL5+6PbLQvcUmC6PMEuOMEOeY4YcIUsWkyWLyZLF 7sU8XwKPwmPwODwpOrqfgqdhOe+/yL0V8BKfV8Iq+nmFz69xfl0+4H4T3oZ35DL3u3Iuq9ki91o+ fwAfwkdyBLNqBCvcIjJwMRm4mP3BMla5Re7P5BL35/AF733Jva957xuuv4UQ9/P5vJH7m+i3gHtb YCv3tsF2KKSvHbATdvF+Ce+Wwk88KwOqN9m9mFk7wr1HfsPMHcEquojZO5LZO8JdxT1y0E0OuvcD eeiOwwGZ5yYP3eShWwVy0H0QaqGOClAPOtdJ+a37MDRxfQzIOTc5R1XI9ZB3HvLOo8hvPTbOKTKL KpFFlcjyOPmcSvVIA3LQ45Z5Hg+04ro1tOF+W0iHdtxvL0tZ6UtZ6Us9neivM+90ga7wf4g7E+go qrR/36pb3Z10d1hDWGXf3YBBHFGMOhF1BBxUFEFBR5SBCcqOEMIy4zKugAsEAUFFDDAsEpF9lwGX QJZOqHQSJgZC6E6nwpKQhMS+31NtnL/Of75vzsw353yH85zqqq66973vvfd9f2+f0N0W2sE13NuB 9ztCJ/rvzDUiLNFoQcx8lcEOXxjzioiLYa5jmOsY5jrmdXgD3uS9d9Qsdv5CItVgItVgItVgosBC otXgmBW0swq7V9Pmx7S/lvNPYB18qqaJTkSJqUSJzyKZ+XAknx8lEpSy4xexs59gZ29n125h135F zq1ixx5gx55hV2ayG79mF+5jF2az6+5mZ41hJ21hx7zJjjnKjilll7zHLslmF+xn9X/C6n+A1X+Q 1W//T4UBrPiT4rfEq/VY8mcyVpa+hSy1nZiwk2u74DB57gjvfalyiZ65ZK6DxKxyMtd2cmA51gbI XtvJXtuJX2ux/ChxKoDlJ4hFX2K1SbwpJt4UY3kp8dqH5RXEbB8x20c8+RLrNxELNhELNmFlHVY+ aGsesleW9yki7TNqOxlsOxksiwy2nb1Zzt4sJ4NlsT/Xsz/L2Z/r2Z/r2Z/ryWBZ3hd57iV4Hd5Q uUT1XKJ6LnuznGyWRTbLIsLnEuFz2ZvryWbb2Zvr2UubWPebWOebWNMB8omPfOJj3QbIKT7WaoB1 +iXrci3rci3rci1rMcBaK2atFbPWillbAdZWgHVVzLoqZl19SS7ysaa+JMNtZ02tJ8NlkTlyWR9r WR8B1kcxCnIf62A/HEKhHVM78fRZskMma+EuonkB0byA9fANXi3Cqxl4NYM1sYPIfRrPHidSF+DZ 43j2OGujjLVxjmicTTTOJhpns0auY41UE2X9RFk/ayWPdVJCZE0nsqYTWdNZMzlE0zyiqEnkzCYi ZhIRM/H6Wbx+Fm+fJQJmEgEziYCZRMBMImAmnj1L1Msk6mUS6TKJaCZRzE8U8xPFTKJYOlEsnQhm EsHyiGB5RKs8opWf6OQnOvmJTn6iUzrRKZ3olE50yiMq+YlK/oaolE408hONTKJRNrNznMhSQGQp YJaOM0PHiS6niS6niSCniRYFRIsCIkMBkaGAyFDATGUwUxnMVAZR4TQRoICZymCmMtj5BczUcXZ+ Jjs+kx2fyY7PZMdnsuMz2fHp7PZ0druf3e5nt/vZ7ensdj+7vYBZzGCXF7DLC9jlBezyAmri86hj W1f3V/XiJnaZXWf9nh2Vwo5KYUcdZp4XsGtqmdd1zGsa85rGbgkyr2eY183M6WbmdDM7ooZdUMNc LGAuFrADapiPBaz4GlZ5Cqs8hVWewlwsYJXXsMprWOUprPIUVnMt/tqMnzazmmvx1WZ8dQZfnWFV 1+KvM6zkWvyThn/S8E8a/jnDaq5lNdfiozR8lIZ/NrN6a1i9KazcWsacxhiPqDdZsdWMYB9nl7G9 Sm1gbZ4WbRjZZc5KGFmAkQUY2QVGlU4cCDKydEaWjnWXsS4d69Kx7jLWpWPVZSy6jEUBLApgUQBr LmPNZawJYE0Aa9Kxwq5lA6IDPVXRUx49ldBTCT2dx4d2jZpBb5X0lkFvGfRWRW8Z9JZBb1X0loEv LuGLS/RahS8u0XMVPZfQcwk9l+CLS/ReRe9V9F5C7yX0nkHvdn1YQo1wmnh5WZ1k1CfpuZIeC4hl u4i4p4i4dn2wIxJxndxV2VBDBRv+D9ONcqToF/FcEe8U8E5R5Myu7eoifnQ0PHWJsxDt59L+RdSw iaYN4eGrjNONJwQ40KROcEEnzrvDKnWBNk5HZiaTu/PJIraNlaI7bRzlnZ347xJt7eaOcz/W95F8 I4gvLogCt9rNqIYzmqfx4yX8eBo/nsaPdn19Gv9dwobd2HAUG45iw1F8+fO6uy20+0n93Yn7u7IX u3Ncxf2ruWbX3BpjtkRL7LuITRexqQybyho+wanA+gB2VWBXBXZUYEcFNlTQ90X6vkjfF+m3jH7L 6LeM/sror4y+KujnIn2Uia60vofR/4WRH/9JlPXh5030dCUSVd2RvxR5qWEu8xj9BPsven6MPoz4 OL3uodc99LrnH0YeO9J04j47ynTnaEeMVdz79xEjOpJFL6MDaqmtnczrCDW54a87TtLzY5G/GO2H 3ae5cwezlk5dkIv9B/DSlp9EEDszmHhqFXNt591zeGsV3lrFeA7Q6uu0tplZTEe75eLBVXhwFTOZ jhdXsSNMdoTJjKYzvgPsCpMxnmaMpxnjaWY1HQ2WiwbLRW/l/l3kMJnldGY5/W+RoxNtdFWrGPsB xn2aWU6PRI+2eD0fr+dHPo2oIorUqiNYXY7n87G4HIvtz3DK8XY+3s7HynIsLMfL+Xg5Hy/n4+V8 vJyPl/PxcD49lePhfLybj3fz8W4+3s1nV1URda+S/Vg9rLAqdUDoZMGrKKVaIVEjxzi7yFmp6MSZ RQ1Tgz6x0CcWmbKaTFlNpqxu+IwwiGa5gI6vIeMFyXRBMl01ma4avV5Dtgui0WvQFRaavIbsVk12 qya7VaO7a9DdNWS2ajJbNbrDIrMF0R4WmaaaTFNNdqkW0eTyWixZSe62yNm2rjtHrxYz+DEz+HEk qkST7StlLJHkehViBAHuCsmbRGMiDDWP6Es/pjBo5yzt2J+51tgjYMTeyCcIQft+PBHLfrpJ1XDd /lSWO3iuWLTgzB59JaOvZPSVkZGPQiuMUTk/GXklI6+MjDqDYyZkQT4UAKNjZJWMrJKRVYqO9HYC /1bh31P499RPK3P6DtFLCb6toocSeij5WzW+LfKJXwm+rcK3p/Bt1c8q9FOcm5FPASOVOr49Re8l +PbUT6t1oTHyKtFVxvAqVq1GLVmoJQu1ZGHTF9j0Bd6qQjEFUEz2p2vl+KkMZWQxA/XMwEZmYCN1 pP39r/ZfR9qqJ4DqCWDXF6ibAOomgLoJoG4CqJkAaiaAPV+gZAKoGAubvkBRBFAUARRFADUREC6s +YyeL9NjDT1eprdaevuG3r4RXXj3O/xWio152JjHnVcaPsP+fzN0E8ruVtb1nfhhrSrFh1fx4dW/ zdI2rqVxvovjHpTWMY4/nbVTnJvw4+wVck8R9xervJ/NYhxeK8JrRXitCE8V4aki7P5rw2dSRXik CI8U4Y0ivFGEN4rwRhHeKMIbRXiiCE8U4YUivFCEF4rwQpFowzgLGWMhYyxkjBWM0ccYsxljNmPM Rqnaqy6b8WSjKoOoyiBjKURZ2iswm7FkM5ZslGSQcWQzjmzGUcgYChlDNmPIZgzZkf9F2SXyLb8p YpxaLp6BZ2GaWiPmqCUiCeZCMsyDMypFnIUSuMQ9tWqxuAp1UA/fq8VaT5Wh9YLecC1cB9fDDXAj 9IG+0A9+Af3hJhgAN8Mv4RYYCLfCbTAIbod4uAPuhLvgV5AAd8NguAfuhfvg13A/DIGhMAwegAmi pXZQHdAOqR3aYTgCX8JROKb2acfhK/gavlH7jNVqibEGPoR0zk/ASWCsRhiUWuxoopY7mqkUByrb gcp2oLIdLaEVtIYitcQR4p5yuKCWOHvBAEhUy52T4Dl4HmaoNc6ZgN+di1SGM0Ptc1LxuLqrfa4e 0FPtcPWCfvALzm+DUSrFNRrGqMWuZbAWijj/DoqBOXMF1BpXECp4r5LzK2pxlK4yoiQY4AAnoBSj UIpR0eAGD3ghBhpBY2gCTaEZNIdb1L6ogTCW189yXMDxU46pakdUlcqIpq3o5ujjJ0QzdUI0B6Kf aAFx0BJ6QE/oBb3hWrgfhsBQGAYPwG9gODwID8Ej8BiMUytZuStZuStZufPEdLVKzICZMAtegDkq ldWcympOZTWnsppTjdfUCeN1eAPehLdgESyGJfA2vAPvwnuwFFbz3Br4UKUy6ysdp9QJRwEUwl+h iOvnOJZCiPfL4QLXvlcnnE5wQTS4oRW0hm7QHfCDEz+wOlKd/TkO4Hgrx3vgCRgDY+FJSFQrWTkr WTkrWTkrWTnzWDnznIzXyXhZQalRz9u+EUtUhngb3oF34T1YCuvgU0iF9bABvoZv4FtIhxNwEjIg E7IgG3yQAyacUduICduICduICV+Jy1AJVXAFqqFWbSFObCFObCFObCFObDHOqwwjAEEogxBQnRgW VMAFuAiXgIrFqAT7uTAotYX9ts1FLHCx913sdRd73cU+dw1TX7ke5jgCRnHPaBijtrh+z/l0mAGz 4AWYCy/DK8B+c+EjFz5y4SMXPmI/bXF9xHEtxy0c9wB+cOEHF35w4Qf22jb22jb22jb22jb22lfs ta9cZRCCCp6t5Dr+YN9t0W4QhmgqHOAEF0RBNNjf3u0Br/0Vk9AIBoo4cSuMU0ms8STWeBJrfAZr fCJrfCJrfCJrfCJrfKKYTQtz1CTW+STW+STW+STW+STxR9FYvAgvwcvwCvwJXoXX4HV4A3aJ9mI3 nFFzmNE5zOgcZvRdZjSVGU1lRlOZ0VRmNFXY3yBdq5KZ1WRmNZlZTWZWk7X3VY62AlbCB7Aa1sCH 8BF8DGvhE1gHn0IqrIcNsBH+DJtgM2yBrfAZbIM0+Fzl6H1EY72viNP7c4yHe1WSfp+apt8Pwzmf oBbqE1Wi/ntIVIlotvvlaDUd3Xa/HMtxuvpazlCZMkM4ZKaIldmo3hyq8lzhlmdUqjyLFikRPeU5 jqX2dwNxLBPNjOmiqTEDZsIseAFmwxxIgrmQDPNgPqxWk4gXk4gXk4ws0djIBh/kQC6cAhPywA/5 UACFgD9Z7cms9mRiTZKjqcph1c8hxkxylAk38SWJ+JJEfJnkqBNNnRJYW85m0By6QC81ydmbY1/4 hYgjpkxy3szrRJVE/EgifiQRP5KIHzOIHzOIHxOJHxOdrCXnHGAtOZerHOf7kf9Bn+O6BtpDB+gI fWGYSmWnzWGnzWGnJbumiMauqbAAFsISWMb11Rw/FO3ZTcmujbwu4v7voBhYc+ycd9k577JzUtk5 qa5yEe2yoIL7K3mf9ccOSnZVi8ZRsSonqgXEQUtoBa2hDbSFdoCtUdgaha1R2BrVCTpDF+gK3eBp 2hoHz0Ay5/NgvsqJ1lSOe6Sa5h4FySrRPR/YN272jZt942bfuNk3bvaN+014CxbBYmC87rfhHXgX 3oOlsAxSYDm8DytgJayCDwD/uNfAh/ARfAxrRWNPEsyFZJgH8wHfevCt5w/A/vawvz3sbw/724Od Huz0YKcHOz3Y6cFOD3Z6sNODnR7s9GCjBxs92OjBRg82erDRg40ebPReKxo3igY3eOxf/ZAn2Sln iEb2K/u7R1rqs4hm3sivCzjBBVFg/8qgGzzgjXyDvZdo5kUB+FEAfhSAHwXgRwH4UQB+FIAfBeBH AfhRAH4UgJ/I15zI1xwlEEQJBFECQZRAECUQRAkEUQJBlEAQJRBECQRRAkGi5Hii5Hii5HjxO2WJ CTARfg+JMAmeg+dhMkyBqTBNTSCiTiaiTiaiTiaiTiaiTiaaJhBNE4imCUTTBKJpAtHUTTR1E03d RFM30dRNNHUTTd1EUzfR1E00dZN3C8i7BeTdAvJuAXm3gLxbQN4tEPbnHamwHjbALtGayNua/GuR fy3yr0X+tci/FvnXIv9a5F+L/GuRfy3yr0X+tci/FtF6CtF6CtF6iiillj0PAQhCGYSgHCyogAtw ES6pZUT2dUT2dUT2dUT2dUT2dUT12UT12UT12UT12UT12Wh6E01voulNNL2JpjfR9Caa3kTTm2h6 E01voulNNL2JpjfR9Caa3kTTm2h6E01voulNNL2JpjfR9Caa3kTTm2h6E01voulNNL2JpjfR9Caa 3kTTm2h6E01voulNNL2JpjfR9Caa3kTTm9pvRJw2HB6Eh+BheF/5yEQ+MpGPTOQjE/nIRD4ykY9M 5CMT+chEPjKRj0zkIxP5yEQ+MpGPTOQjE/nIRD4ykY9M5CMT+chEPjKRj0zkIxP5yEQ+aok0aom9 1BJ7qSX2UkvspZbYSy2RRi2RRi2RRi2RRi2Rpn0r3Fo6nICTwk0W85LFvGQxrz7Q/j+qHH/F8V41 n2w2jGw2LJLNRquQPg4mkN1+ktX0SSpEZhtEZptIZhtEZptILb5ITlOb5B51WO4XjeQhst9J6vlM 6vRs0ZIsFyTLSXmK+v6HTOcg03WNfMdkkOtlZJ7pwkuW85LlvGQ5L1nOS5bzkuW8ZDkvWc5LlvOS 5bxkOS9KOoiSDqKkgyjpIEo6iJIOoqSDKOkgSjqIkg6ipIMo6SBKOmgsU5aRAsvhfVgBK2EVfACr VQKZM4HMmUDdlUbdlUbdlUYWdZNF3WRRN1nUTRZ1k0XdZFE3WdRNFnWTRd1kUTdZ1I3OtNCZFjrT Qmda6EwLnWmhMy10poXOtNCZFjrTQmda6EzLqFIh4wpUQw3UwlWog3pgT5CZZ5OZZ5OZx5OZfWTm KdR/JvWfSf1nUv+Z1H8m9Z9JleCnSvBTJQSpEvxk8ATHWWVRKfipFPxk8vFk8vEObHJgExk9gYzu pWrwO8KcK2U5BWiggxReMr2XisJPReGnovBTUfjJ/F4yv5fKwk9l4Xe2495roAvXunHeHYi1VBl+ lEECysDr7MP7rEHUQXOqDj8KIQGF4KXy8FN5+Kk8/FQefioPP5WHH+UwHuUwHuUwHuUw3kkcdRJH ncRR5zSYDjPUBNTEBNTEZNTEZFREAvWsiZLwoSR8zg8i38gU59wKn0e+lSnOeZRjhkpDZficzCV1 r+msFnEoDh+Kw4fi8KE4fNTCadTCadTCe6mF96JAfNTDe6mH01y3Cjc1cRp1gUVdYFEXWNQFFnVB ASplHXWBRV1goVamoFamuB5XIdcTMEbNpj6wXIm8Zk+5noPnYTJMoc2pwLioHQqoHSxqB4vawULh uFE4bmoIixrCcr3G/a9HvlXQQvW4qScs6gmLesKinrBQQbNRQW5UUGvqCgslNBsl5Ka2sKgtLGoL i9rCorawqC0sFNIUFNIUFNIUFNIU11naLoFzQKx3EetRTctQTctQTetQTetQS7NRS1NQS+tQS7NR S25qfZNa36TWN6n1TWp9k1rfpNY3qfVNan2TWt+k1jep9U1qfZNa36TWN6n1TWp9k1rfRHX5UF0+ VJcP1eVDdflQXT5Ulw/V5UN1+VBdPlSXD9XlQ3X5UF0+VJcP1eVDdflQXb6oftj0C7hFpUUNhLG0 /TTn4+AZeJZr4zn+DibARHheBVFoPhSaD4Xmi1rAM4u4/in3pqq9Uet5vQGqlBktRBwKzhfN2KKb q7ToFsLtfkidcT8Mj8BINQxlN8z9OK9fUCH3bEiCH5XeQl6/BK8IL4rPi+Lzovi8KD4vis+L4vOi +LwoPi+Kz4vi86L4vCg+L4rPi+Lzovi8KD4vis+L4vOi+LwoPi+Kz4vi86L4vCg+L4rPi+Lzovi8 KD4vis/7f6j4vD9TfC3EW+o2bYwYqj0pHtKeEi9ovxV3a0+L27Rx4lH9XjFSnyAekSPUXXKkulPu VuvkfjVUFquv0Iaxkggnz6kl8rw6JgOirQxSb5WpK6KDeCt8RGxUWeJLlUXrtzd8G+wAWr+W1q+l 9Tu0CeoKubWEXqjmqMpGqIH0MoheZsi9ao/cB/vDIXlQbSfHnZKH1VF5RL1F7y/Sc40sUaX0PpDe F9G7pPcP6P2IiJIn1FqZgU1U8jJLPS2z1S7p46lclU9WLESnblR/wba/cOdj5M4T3L2Mu5NkVjjM 3R9y933k0e08MYsn3o98t+ONWJtMNr+G7H2fPpRMPkFN0J8TUt+ATj6ifqsfUyn6aXGTXkVGjhWN 5Y3qE7lXeMnSNzKCz+jpmP1L3jKLWjNHfU6WdtB6mBH5yNRJDZlaNtSkkpGVygCjCnK9TJVrjwpD 7RIOcIILoiAa3OABL8RAI2is9ogmMFDli1vhj2qreBFegpfhFfgTvAqvwevwBryFD3epTLFbZWq6 ytckGOAAJ7ggCqLBDR6IgSbQFJpBc4iFFhAHLaEVtIb20AE6QifoDF2gK3SD7tADfqMKteHwIDwE D0MyzIP5sAAWwh/gj/AivAQvwyvwJ1is8rQl8Da8A+/Ce7AUlqk8vY/aqveHeBiuduqvKr/+mvKz ykcwKyHWWT1rbCszEWKNPcAaq5dXwudlNTuiRrlkbbhaXg3nyzrllPXhUvm9ipdhrivV2nCEzxtO dZfhUi4jKlxtRIfzDbdyGp5wqeFV8UYM1xtx33S1y5gBM2EWvACzYQ4kwVxIhnkwHz5S+cbHsBY+ gXXwKaTCetgAG+HPsAk2wxbYCp/BNkiDz2E77FSFxi7YDXtgL+yD/XAADsIhOAxH4EvIUluNbPBB DuTCKTAhD/yQDwVQqLY66tQupwTWr9Oh9jibcWwOXaA39IVfqHznzRzfUIXOpZDCOeN0fsJrxuNk PE7G42Q8zi1c2wrbIA12wC6u74Y9sBew3Yntzq95/Q18y+t0OAEnIRdOqTynn/dKoQwuwiW4DJVQ BdWq0NUIGkMTaAqtVJ6rNbSBttAO+qt8180wRW11TYUFsBCWwGr4UGW6NnKsVlujeqjCqGtVftQN HPtwHAYP8PoxlRf1NO+Pg2fgVa6ncH05vA8rYCPUqbxooQqjm3Jkf0Wzr6LbQDuV735a+d0TIRGe g8kwHdjvbva7m/3uZr+72e9u9rv7TXgLFsFiwF732/AOvAvvwVJYBimwHN6HFbASVsEHwBjda+BD +Ag+hrVqq+fXyu+5H4bAUBgGD8BvYDgkqZ2euZAM82A+LICF8Af4I7wIL8HL8Ar8CV6F1+B1eAPe hLdgESyGt+EdeBfeg6WwDFJgudrpvVZtbRStdjZyg0ftFAa5YiuRPyhzxA3E5XrxnpijVogkmAvJ MA9qlZ/62U/97Kd+9lM/+6mfLepni/rZon62qJ8t6meL+tmifraony3qZ4v62aJ+tqifLepni/rZ on62qJ8t6meL+tmifraony3qZ4v62aJ+tqifLepni/rZon62qJ8t6meL+tmifraony3qZ4v62aJ+ tqifLepni/rZon627G/h0v6CncdUiJo1RM0aomYNUbOGqENTqENTqDuzqTuzqTuz9bXqfOTvI3/4 q6Pv9Gr1HdnMJIutkCdFB/JlERnsDWq4FdRwK6jhVlDDhajhQtRwdv3kp37yUz/5qZksaiaLmsmi ZrKomSxqJosaaQV10ArqlBXUJCuoIVZQQ1jUCCFqA4s6IEQdEHL1Vn7XtZHv4wyh/W0t70dn+9HW frSwHw3sR/9a6F8L/Wuhfy30r4X+tdC/FvrXQv9a6F8L/Wuhfy30r4X+tdC/FvrXQv9a6F8LvRpC r4bQqxYaNRQ1g7YX8PpT+1vTlIXetNCboehY9tNIlYLGTEFTZqMps73J6rx3HsxX52Ni1XcxLSAO OkBHWMj1j9V3Qier/Jm8jo6Tu8Utco94Qh4Q/eVB0Qr/7pCHUVJHRA95QgzD18Oo6x0ohtup7ZtJ n+iH3/+KcmiPzinm6hnRG70wDL3QXZ4Xg2n3cMNn2dfS0yG1kfvfifS5lfcmoir2iEZc+4qzk/b3 Uv7/36WrTRDx//j7dLGnL7vjNnodQj68Dxt+uNKXbFnN1bvIlnvIlsHIdxSX2b9GydV2nN0e+Uyx Jfd2wwb7twjOieu54wbOTop4RhjLe+0Zq/2tbyNVupwuBmL/YWMQek3nynHOvuFuchOasIKzQs4S RQxnVzk7LnoIQ8QLBzjBBVEQDW7wgBdioBE9jhAt5Cg03hhIZEx70IEH0ZmHVKYxXcQbM2AmzIIX YDbMgSSYC8kwD+aLeGr5eGr2eGr2eGr0eGr0eGryeOrveGrveOrt+MjvX8SgbivpqZBRnJMHmEn7 10wOqS9Qt2WMfTo+2Y1d+7iL0TL2GNFMyxBdtEzRB8+MwQ+/kqO4a7QYLcdEvmNutExUh+xvJZIz VbFcKgbIZeJm+rGY6W4omc3GLaKfMVD0wVujRXv7t4bppz+zOV10pKdyu/9ITzENv2tyTD7O009w /5Mcn+I4nRWWofLQyCH0cW1k/eSKKJ6Swmn/Egp3x3FnHHdGc6fFHRUiTpwhiqKhRAm6aSo92XM6 U2Wju0PMemMibmakPR8zmMNTtGkrYkczVU8NX08NX0+NXE+NXE+NXE+NXE/tW0+fI9R5+3880WJv door0lqOqhQtf9bn48SsJ2ESY5uOEj+pLmJdBeOwWHEt6LuKp47Sr4d+a/5pvx76LbZ/m4XWmtGv gxaraDFEi5W0GE1rFxtGUc8+G8FV+/sCH0fJPwlTeWe6aM2T0Vjs5MkrPFnPkzHYEra9xpN17Ioz 4h5xFkqglpV9FeqgHr4nOoygchmp+sjHiRZPiLHySY5PcZxE7TMVe2aqj+Vc1sVS8UvWw214PIMe B0bmJkutivTmU7nsuViqnKsNa6SfQdtGGJTo4Wgm7nGNgtEwRvRwLYO1UMT5d1AM2Omq4FolxyvY Zn//YwWW1TLmWizrzbhrsaw3427DuO2IEcV43Yy1VJ4STSKrbi9PHOaJszzRhifO8kQbnvgldzfB 5nORlZel6rC7hifPRp7yRX6XYBT9jWYlj+E4luMMomKx6EzEqyDGuImMrYmMTYl3eyO/qGPPn5+7 JFcqmIcRvBoZ2Rv2t+HFyWmsqlnku3PYfZ4eA8qKrLcinjvLc25aj6JlnXf8orUYpy6KZ+BZmMbs j2A+R2HXGJjByrTvPsMqOYenS7EpQH0ZpJUy8uQg0dLRRF10hKBcXXQmwiR4Dp6HGTCTdhs1/CaQ Sct+WvbLaYxqBjG/mHk8wyo6yw6KjJY4fB4fBdS3kVq8JfbVYV8d9tU1jN7+TPk0rZymFZ1WemNj E1qpppUwrdjfNB9FC9/Zv0eEfXXYV4d9ddhXh3112FeHfXXiejFODBHPwLMwRySIJJgLyTBPJNBj Y3q8jpjlwMPDiVkOvDycmPUpnt6Gp/exTo+xTu9jnQ6RG9QSxvQNGaL7D9aQt2xrzqMmbhEDWaMD jUHKNFaLBGMNfCgSHE3EEEcRxxDHcrggEpy9YAAkiiHOSfAcPA+2fVFYdaVh3egN60aPzJXtwYAq jXwasRm71zXcFddwVxx2W9zZL/IJREBlszISw0eoBcup/Yqo9cqp7YqMnuES1lpi2OJqBVcqjJ7q dlpNDJ+WV/BzHU/XExu+VycMh6qmLqwxPKqSO09w5+DIs4d4N5MrmVxxR5615FX6q8Mr36scasyw ES2cPBvmrhxqyTB3xhOXEsPn6CVMlVqJZSFZy7GOXutZmT88WU+vYarTSiwOGVEc3Vjh4foPLdUz gipWXSJ1bbXQaKWCVsK0omjhfKRvp9B4uoKnwzytePJ8gw29bD+FF2NDMU934el8nr4ir7Jjbevr Wcffs+LC6ASlvseWYlrrQmv5tHbFiFa+yKg8zLNXNKFSDtLy99i0yc6iSqfFGuwolGGh81QNfRca MbzuqTrZd4RPckcp/dme8nNHKW3aXvLTxgW8+3fzxew3zBNP/5P5idwbmRfu/SfzwRj/l/NAPP0X /U+U+Q/7nTH+N/6OvPMP/SwaGbEi2miBfa2E22hDa215ph2a4Rpet+e9DrzXmfe6ct6N97rzXg/y gWHE0UNb3u3IsRtz4jViOaOGMFrSfxt6aEtPdlvtud6B65243pXr3bhOO8yCfbfdc9uGO+ye7Laa YZfOuyVGHFdaQivRHvuacWcJbbbHPh37dJ4qMTryfifozPWu3NONa9153cP+VXJaKcRWe4S60Rpb 2whHQyv204XYb49QN7rwXlfe++FpnfHGQgvWXhw2t6LdNoylLbPfjr6uscfF+x14vyPvd+b9rlzr xvvdeb8H42MUzE0L2o3jaktopXKxIYx3io12zOU1jLk993Tgno683wk6c08X7unKPd25pweZzZ4n b8SvrUQsdtgeq8GOWOzwYIc34tvOnHeNeLAGG2KxwWPPipCRsbdp8PMP1tvek5Fx//BERYPVumj8 764Jdq2F//5uXbDbbxQx/+ra4Kk+wvXfrQ/e7Saa/6fWCK1dx6j/zXXC0z1F0//tWqGVW+wR/WfW CzPxdWQe/601E8kNMf/quolE9Z7ySjhAJH2SiNOOqDZUXg1XENXulvXhINFnHFGtI1FtoOEIB4io TxKN2hHVhhrR4Qqi2t2GJxwkMo0jqnUkqg00YsNX8Mj1eKQXHulltOK8tboOjzTCqr54pTte6Wa0 53oH7uvIPZ2gM+dduK8r93Xjvu7c14NVE03l5qXmipf27/ocEc1Ru7Eo3a6oil+iFY6i9hpHflto tzZG3Ko9KQZrT4nXtd9yfJrKfYRaKR+hFnlU7UZ5rIz8Ul2v/+Guo5G77N9AOhW5+uPZ1r+d6VTy +7WDamvklf3rdsW8akyVfL0QYiA1aW9xJ//6iPvFQ6KveEQ8ytXH0HK3id+JN8SvxVtig3he7Bb7 OTvIvyXia5Er3hYm/1aLQqqTNaKUFtdrbbW2Iktrr10vsrUh2lBxRntAe1iUaKO0x0WZNlYbKyzt KW2cqNAStefEZW2GliKuaO/zr422kn9ttQ/4105br23QrtEOaie1DnofvZ92o95fv1nrpw/UB2oD 9Nv1eO1m/Vd6gnaLPlgfrN2q36vfr92mD9WHanfow/WHtDv1R/SRWoI+Wh+t3aOP1cdq9+rj9Ge0 +/Tx+njtfn2C/pw2RJ+qz9Qe1F/QX9Ee1V/V39TG64v0pVqinqIv16bra/XPtJl6mn5Ue1E/pudq y3RTP6N9qgf0Mi1Nr9AvaF/ol/Rqbadeq9dp+3UlhXZI6lJqR6RLxmhHZWPZTPtWxspYLUPGyTZa puwkO2u5sqvsppmyh+yl+eV18nqtUN4ob9T+KvvKflqR7C8HaMVyoLxVK5GD5O1aqbxD3qEF5F3y Li0oE2SCViaHyge0kHxYjtQq5Cj5tFYpE+UkLSynylm6kHPlXN0p58l5uksulcv0KLlZbtbd8nP5 ue6RO+QO3St3ySN6jDwhT+mtZLEs0zvLK1Lp1xkOo5E+wIg1eup3GIOMQfoIY7rxiv6I8ZqxXZ9o 7DT260uNdOOkvsrIMkr0NcZ5Q+mfO9wOt/5f1H0HfBVF+/Wzs7sze29mk5AESEIvUgSRDlIUFFFB BbuiKDawYUVFBBFsNKUp4AvSseELVlBQsYCKXZEqvSNFeof5zjz3JiYmENqr/2/ubyezs9Pu3pkz 55nZPfne174WP/jJfor40Z/jLxS/+Iv95WKBv8pfJZb4a/21Yqm/3t8glvkb/a1ihb/d3y7W+bv8 PWK9v8/fJzb6B/wDYpN/SPpis1QyUeyWyTJZHJYpsrAwMl2WdF1ZRtZyo7KOrOOWkPXkBW5J2Upe 5Z4p28qebl35tHzWvUH2ln3dm2R/2d+9RQ6Ug9xb5UvyJfd2OVSOcNvL0XK0e48cJ8e5HeUEOcG9 V06U77n3ySnyY7eznCG/cLvLr+TX7lNytpzrPiPnywXuILlILnJflEvlMvcluU7+4Q6V2+RBd7gi JdzXlFKl3TdVBVXbnanOUo3dOaqJauIuUOepC9yFqoW61F2qLlOXuavUlepKd7W6Wl3trlFt1E3u WnWrus3dpO5Ud7pb1N2qs/un6qKecA+pJ1UPT6hn1XOep/qovp5U/dUwL1D/Uf/xUtQINcJLVSPV KC9NjVfjvSJqopruFVVfqtleJfWLmuedqX5X2706aqfa712iDirjXRlUCCp41waVgtO964JqwZne DUHtoLZ3Y3BW0MC7KWgUNPZuDpoETbxbgwuDFt5twcXBxV6H4NKglXdHcEVwlXdXcF1wndcxuDXo 4N0b3Bc84D0UdAm6eI8E3YJu3qPBk0FPr3PwXNDbezzoG/Tzngj6B/29J4NBwSCvRzAkGO71DF4L Xvd6BRODiV6fYFIwyesbbA92eP2CXcEu74Vgb7DX6x8B8HkDIl7E8wZFVCTqDY7oSFFvaCQjkuGN ixSLlPTGR0pHSnuvR6+ItvHeiLaLtvPeid4Wvc17N3pH9E7vvejd0bu9D6Ido/d6U6L3R+/3Pow+ En3E+yjaJdrFmxbtGu3uTY8+F33LmxH9LPqNtyY6N7rY2xJdGl3j7Y7uS8j0DieUSxjgl04YlDDG fyFhSsKn/siEnxK2+69ppdP973QVfb6/RF+r7/D36rv1/TKiH9SdZJJ+RHeWKbqL7iIL6676GVlE 99IvyNJ6gB4gK+pB+kVZSQ/Ro2UVPVaPlXX1eP2WrKcn6/dlEz1VT5fN9Sf6E9lSz9Az5MX6c/2N vER/r3+VV+nf9G/yBj1PL5Bt9SK9TLbTK/RW2V7v0HvlI3q/Pii76sMhye6hCIXsGXqhlE+FQRjK Z8PksIjsF6aH6XJwmBkWly+GJcPycmhYIawgR4bdw+5yVNgjfEaODnuFz8sJ4cBwsJwYvhQOkZPC l8OX5dvh8HC4fCd8JRwj3w3Hha/JqYkiMVF+nJiSWFTOTiyWWEL+lLgncb/8lUQU/J1In1uoNVWi 0nSKnJlmVpm1VN2sR/j3fFMcNsPNZHz+NH1w1tpcjzyzEFofv77e/AF/Rfxsd5789uofZic+f11T +dSzA8eLBbb3cRyf5IpZihqK2FqO6GB5Id1CcwBhjZn8Bgpxvip3G7O+TT51fm+Wmy3mB5SwEt92 XUFtPAYXoNQh8dJXm01mllkTP9uep/aNOJaYZWaO2WtaUAT37nQqk+P64YIqM7vw2+1ECX+1HPcf jCV2dYKZQBpH9m/4t9ybcawxi1DGUpz64FkV6GyESvHVmeZHMw/9B30Hdnv+9b9pxpqR+NsLxzmm mnnYdEIox33M+vYIbcqT+7D5yqxDD/rKfId24Hewdy93ruy03xdwKwh2KlEih16Ix2xB2T9k9c2c vSIesxPffDvu/e9mB/h+EqJq41fIrt1s5F9oY1bqPPk3mQ0YY1uy7rhdGeW/i3OmKajd8XSLcp09 kOvsm2MrA64Gp4/3NDMfv19g5hdQ854cY7sG1S8g9VvmdTuizVfH3Kbc+dfa3mH7bJ4rc48hN76Z eZZDU/4+ns0tx5AffcS8z7i11P5ux+vMG4ymb+C+5nXBMZXwp5nGqHmM/SKfErYfe6/KJ3ccYc2v J5T7bfbnW+Q45a7WMdS/NjaXmQPoRzuOuwZ91KsVcVzOtWTNeCtin/j1UvnkqYxPKXwq52rlq/G/ P8U+R8lfI9/88buLXrIL6LTrSA0Gfm4224Bgy3lM2V69l+MH8+WS5jPzqfnNzuhHyH8wR7gvZQD/ r6FWdoTE45ZgbpieF4uz8xzIER6AmSeJLqJ2CE+Kx63C3fvlyLNqVv3co19G/gjQ58E4ktv4d81k cs3UI+b/ey/0wZ46IP75+PVvzNe4/9/Gz/Li9/4c4T7InUGXkGVC58TjPjEfoYT/HrH+1fnHH8Yv ZvHRXGYuNbeZVvHUo/Lk7wkUm2D+a342v+WIFtSWnqJ+CL1A/e07M/QWeu4kmgp2OJ0+pZq8qlCX vqR5VI8W0hpqSesch6512jnt6CFY9JdTJ2vL0yPWiqdHxV2iIz0Ge3wBdRO/i1X0hFgv1tNz4g+x kXpZ25z6iN1iD/UTB8QBesHa5tTf2uY0ELZ5Ag12S7mlaJh7g9uWXnbbuTfTcG+KN4WsVWtopJ/i p9D38gP5Af0gP5Gf0o/yd7mYfpZGGvrV2nQ0x9p0tEC1VpfREmvT0TLYdNfQcmvT0Upr09F6a9PR H9amo43WpqN91qajw7Dp+joEa26gI9VgNcyJWJvOSbI2nZNsbTqnkBqnxjup1qZzClubzqkAm267 cwasOeO0CtzAd64PgiDq3BjoING5OSgUpDq3BYWDok6HIDMo7twVlAxKOx2DcsFpzv3B2cE5zkOw 2m53HoZ11svpDOusr9PF2l/O49Ymcrpam8jplvB4wgCnh7V0nKE6Wac70/Vb+i1npl6ltzqzrK3h zLG2hrPQ2hrOYmtrOMusreEst7aGs8raGs4Ga2s4W62t4Wyztoaz09oazgFrRzgHrR3hHLJ2hBCJ kcQEoRILJxYV0cS9ifuF3VOYzz3G4R4j0GOGwKIYSv9Bnx5O4xEzAR9Fr9KbmKUmoj9J7k8S/elj jLpP0Kui3Kui6FWzEf8t/UYJNBcfgV42D6x6IS0Gu1pCKzHGVqHPlaF1tA0jfjs+ZWkH7aFytBef 8rSPDtFpdBg9shD3yBLcI13ukZp7pEaPvIeSRUf0S839MgX9cgkVEUvFUkoVy8QKKipWipWULlah vxbn/lqM+2s699fC3F8zub+mCiMMpbqg/5SGXivgw1Fh9F2FMH58ynAj6Mdp3I+LoR/fQBXctujN FdGb2yF8M/p0Re7TJdCnl5DjLfXWkPDWeutIeuu9LZTg/entpJLeLm83JXl7vINUyjuE3n8a9/4y 3PtLcO8vwb2/BPf+Euj951GaaqaaUYI6X51PnmqO8eBjPLRATEvVEjEXq4tJqUvUJRSoSzFOymGc tEbeyzBaIjxaEuwKCIXqGoyZRIyZ66mMukG1pSR1o7qRTlM3YRQV4lFUiEeRg1F0N3Ldo+5HmgfU g4h5SD1EQnVSD6OWR9QjKPlRjLQEjLTHkaur6or4bqob0j+BsRfy2HPsegrS9FK9UW8f1RdX+6v+ iBmgBiDXQDUQaQarIYgZqoaiJcPUMMRgfFLUjk+UM1KNRK5RahTix6lxKGe8Go+UE9VExLylJiHv ZDUZ9+Ft9T7uzAfqI7RzmpqGezJdTUervlSz0Nqv1GyU+YtCz1RzFfqkmq8WobTf1TIqrZarVbgn q9V61LVB/UFl1Ua1CXdys9pC5dWf6k/UuFVtR5t3qp1IuUvtwtXdajfi96g9aMletQ/l71f7UfIB dQAlH1QHKVUdUodQ+2F1GHmNMvb/qwY+lbBoAh9oAh9oAh9oAh9oAh9oAh9oAh9oAh9oQg7Q5Dn4 vYJeJCymkGcxhRyLKaSBKV3hd4t2p2SLLOQCWeaRTpifsIDChIUJ2ynZogy5FmUoAyizilL1ar2a 0vQavYZCvVavpSJ6nV6Hq+v1ekrXG/QGKq7/0JsR3qK3IP2f+k+k2aq3Is0OvQPhnXoXZerdejfS 7NF7kWa/3o+rB/RBStCHtaH00JrWqRa/4HuhB98PJaUAxQIqGkbCKBUOE8IEpNRhSMWBa6mISQuL UKZFNyoCdMuEXywsjjQlw1KUFpYOS6OcMmFZhMuF5ZC+fFgeYWAf4oF9iHklHIlaRoWjkWtMOAYl jwvHo8wJ4WtU2KIhuRYNKdmiISUDsd6Jo+EAfFxGQx9oOAzh4cBBl3FQAgXfQngSfQj/I0JvAxp+ hvAXwECXZgEHXeDgXCDmPOCry+v3AeOgyzhYmHGwCONglHGwKONgOuNgBuNgJuOgdpKcJAqdNk4b +Pc4HeHf5zwIv5PTCX4fpw+FQMnLSDBKRoCSt8G3KJnAKBlhlExkTEwTm8QmKsQ4mMI4mCoOiUOU xAiY7HquRynAvgDhqBulQm4btw0Vd6/nJ9ks9pVg7Cvl3ujeiPib+Ok2i4MlGAdLube4t1KxbBxc Ry4QcCcFwL6DFGXUy2TUK2JXbTE+m6qmGL3nqnPJZYwL1AXAOA8Y1xJhi24uo5tkdEtXrVQrxFh0 c9UV6gr4V6qrkNJinMfoVoTRLcrolgl0a0da3aJugX+ruhXpb1e3w++gOsC3SBcw0kXjSNdJdULM w0A6yRgXqMfUY8jbRXVB+iyk645wDON6qqcQtkgXMNK5jHRR1U/1Q67n1QuIsagXMOrpOOoNUoMQ b7EvYOzLZNRzGfU89QpQz42j3mg1GuExagwQbawai/QWB13GwcwcOOgyDgbAwWkIx7DvY/U5wl+q n+Fb7AuAfYsQtqhXmFGvCKNelFGvKKNeOqNeBqNeJqOeVjvUDuSy2FeEsS+dsS8zjn0HgXEuY5wO nMAhN4ZW0c7RxygSfTz6OPxu0W6UEO0ObEqI9oj2QMwz0WcowjglEgYlvEyCESdNbwbWJOttejul ML4kM7KkAVn2ILxX76MkYMphjHOLKYVCN3QpCWiiKJFxJIVxJA0IkoKwRZDUsGhYFGksdqSFJcIS iC8Vx44yKMFiRwpjRzJjRyHGjhRgxysoc1Q4CrnGheOQfjxQI4VRQ5CoudWuvNZbe15dakHXHonn ///hzHqzwR7xs+X52V12nYfX+o637NV2hYst78/4/PesOtn/OW59brL2J9uii8xKsy73ik7B9Wat 0Jn7j7+Fp9aZlrA87d8j2t55cqyHpf31ia/LZJez6e9nZhv78XjYijtxZ1eaLTiyV/ZyWKJpOXIv QqoFZNc9iiIUX2HMsq7/IRfNbk3OejVdx3Eb81tdMH/kXZsz280KsxBX8uxCnKjLWiXPfWbHT7xX 51gvQNvd7PCmI/3KZlneVc1T5fLfwSkw13gzhv8e5NXwb+xh14fMGwjNjqfJ6ll2BO8yP2XFH1c9 q7mPrvzr3K6CmSU5UjzP60F2rXwZh1ajNTkRKn5/j/X35VXrlQWnO36HnpajXLPbHMSx3651mUO5 0h1tX+r/mPuHx/wxODPiJDK3zqe8lVQJfbDkSZR6dFeJGFstnjKm5uuADce8h3jyc8XfysvVqpxj 7xjzv2s+NW/H9wfSzCjzKceusrN7ztn7hPjDAmDjcuYP65ibMJrZOcksx9+J8VRbeL/tWxyz8FmX e+WakSyDstZmZ2IumG1+wTECsS3MHPMdx/8WYxG8o33d8bc0T8s35DrjOdS8kyPmLjPOdDS97Sq/ eTA7tiHiPrTjLu+uI9k917x7oX+Yz/BdFp26kZrVH+w8BgTL4oWzKb4/m7MNwOXsvRG7x1JAyT+c qjaeqMNdCvnvQLvfnOdqJzMzV9rY3yWY3VbZHnIC9c21vZ75Ft8nG8L8tjx+1+CbO82P/HvvITef OSyk6nnK3IJxsDm+u+QCObJ2nfbErp78/PbXPnTu/coslmK5F8/bq/HZkod7LmPumc9ox2g+xdiV n/sbns3Jc/3g32Pi8Q/kH0/Hs49+3M60P84MsWcsepln+O+fjADv2QOh182UWIivZfEz3u/EL/XR CbTuXfMhEPOD+NlM8ybZ54Om2jAOICdQbCZQIosF/wn0/S6OE7H9s8Q8ZX5tPjAz4mWm2bN4fC50 MOb4W8v5MErNwuyzLNtlhQ1l2ZUxJs6INtv2j9gzIvHxs50Rua1pzWczyO7m3Y/jUYQGmGGY6x6N l5Lj2Rbcgemmywm09mbTzYw1HRH6AqN6rOnA+PA8ZqOxuM8zzAhzB+bWP+0eIH+zaWaSGR2rOT5r ZJov/lbmOjMPVmVs5NbJDsV5p9kXO46dMecqeyeP9+yngnLPUjxPZ1u+zHyX83MPOZ+4qJb7iZV/ yuXexeUnmDYX3BL+Rnmev/onXG5L1t5V9OEdBeEn/zqnzNI9HpeTf2A0WCtrPv4eYac7O+UfJ99e 84rpap42Qzn8E/r7GPukTHweivHFXeZ9HJ+eXD1cUvXYkywnVcYqsxYzIc+P+E3Xoh9mc+7Yr262 gnNszY8BHnddJ8C5c+T+Lvaroi0WB3+Iny2Lj594q/+d8ZyfM+3N7eZjM4UEn3UzjwCt28UYgZlq 9uKsn3nAnGXKAUdrm0fNnSdRV4w/lj6p9sYxKWbTZj9vOCb31VPpzPhTUIbtvfNiqA5+m+fX5+sr za9/zcL/rkNrfseY4zVP9GFrKWZbKjGmi6tf4zjCs6r/tEN7X8g5csGvpv2b7Tmyw2jrZLlT7ElX 8xDY0W8YfbFrM9j/3Xxkrje9EepvFsfiTrCur0++vcdZ486cz3n933XZHHf7yT9dmd+z7qfSxdgh +PcazHqnYMWioGeUj5r3GHuUmcxr+xtPvKYcLuOUlHJMDlzopJmrGXgqWlJAHXGkA7s96XX5U/Qr FVTLKjDb//FIOXUOrGfnKbszKSfRjlMx3v/B/YgT6Y3gPStjOeNvdmSti/zI+ww/HjXzvfG0bx9/ vf+0O5F3IPKUccTdkKPk4dV6u1IUs4RjKzrZe8HRo9nHvLabQR1JHn+9nP8E3vIy63ju+Otdsqw1 uWO17RLoguOv9V91RU404/HvPJF9qsHuS2db9mY6+5uBzwXuRvxfc+D9u478zkSOdHv/9205Nnds CHmis3q+70oVWBc/QfDXu4O8Y5Hds6L5ZspKa9eqitP1GHP/gsvN3WOoAeupAJzlnZh/Yb3PbDuF Za2g+Ipyvm8cVea3nOwO+k/5XC2obPse1YqsnFkhXuFfEY/JqrMh1/W3duU4e+6vMrPaYt/XytMq +1ZWDbtLcyJWuxlhXjXTst8Di4csI4ivaf6U3Y4aedr76vHXlyv/CTwpZH7lXYlvs8/5GSDwTXnM O33H8PbeEerO993kAvKs5VUrO5MzFvDZTIy9GDJEj8YveUZJorOP7X3NfPKfyPMPc+z7lnzsjp2z H181Pzo6xL9L8dzPG6F/bTO/8DGCioKTbojvJi2PjWnua3cdf0sL+B6xHbYc1rppZx41r5mRrBuQ /UyPaWnePc6SZ/4zjNm28cj1mMP57SrHdhT/Fret4F2cE3X8jEwcmc128Int4EcLzKK/kMhsQpzd M65vrubz99AD5pm2ZpY9NzPMi+Yru2LO1wbnKntJVvxxtaiV6Wh6mBbxMw6hB3bg8KtmnHkQ/WAE 2No0zLw2xRTzgXk/Pmvb1fkiVJ33nDubezgu9jziSPDqV+zvYVUSsp8CyrUWZPZlvc1/XO192bwB W+0/8bMfue4RjPM/8j2wu69vm53mc04Qe2s//oRBvBfXOf5a/y33P3kbO28tK7IQK7bv/G+5E9mn wi+9mXKsOmQrJBzL3JNK9vmdKzhcnGrD9izNedeAdazh2aQY1TJzMULtZ4lZas7CeOlA2sTm9bid itEZs6mKxs/fje9UCMp+Y5rj3zrK9+BnK0wXzHPxFUjT1NyEo6VpT6kmNgdnaWh0w3G+aWiuMvE3 G8w3ZjE/LWFH7B+Yk1bE7dcqVIlnziqc6uirG/m3a4wZB/+N7PNp1pbL9WTFlfHA9XQ51aearBNz Gl/J+d2jh381CYf38Ez5sbnbvGfnMPOEecqGUGqfXNXGngG7+wTae4+5D9//Pj4JELqHcfMpnql/ wW+57nDsTfqprAqS5fjOmofiZRyDjZdv3RsKTpMnzyZ+IsDyBO5N3Jtn4tzjy/qofMfmSqJGaL2g OQXo2LWJ69j1pIsc4RSm21idrjOr0/Vidbo+ThunLQ1w7nTupBdZl+4l52GnDw1z+jlDaZJVp6Np Vp2Oplt1OvrYqtPRJ87nzk80Q1QXNehHUVvUpZ+tOh3NEeeIc+g3q05Hc8VFoiXNFw+Kh2iR6Cwe o8VigBhMS8V4MZ5WitfEJFolpoiptFF8JD6izeJj8SltETPFLNomZovZtEP8IH6kneJn8QvtFnPE HNor5ol5tM/Vbkj73WQ3hQ5ahTkyrDBHrDDnu+Xd8o5ihbmAVeUS3LpuXSdkVblEVpVLZlW5FNaT S3XbuNc7ae6N7k1OEfuunJNuVd+cTKv65lTzpnqfOm2s6ptzi1V6c263Sm9Oez/ZL+R08NP8DOdO q/fm3Ocv9lc4j1i9N6er1Xtzulm9N+cJq/fmPGn13pxn/V3+Aec5q/HmvGA13pyhVuPNGWU13pzR VuPNGW813pyJVuPN+dRqvDkzrMab87NsK5915lt1N+FYdTfhWXU34Vt1N6GsupsI5Gg5TiRaXTeR YnXdRKrVdRPFra6bKGd13URFOVsuEJWtops4yyq6iQZyndwoGllFN9HUKrqJS6yim2htFd3EXVbR TTxm348TTwQiEKJ7IAMlngwSggTRM0gKksVTQVqQJp4J0oMM8WxQIighegVlgrKit1VcE32t4pro ZxXXRP+gRlBDDLS6a2KQ1V0Tg63umngpaBI0FUOt7pp42equiRFWd028YnXXxCiruybGBu2DDmKc 1V0TE4JOQSfxulVfE29Y9TXxplVfExOD3kFvMSnoF/QTk4P+wQDxtlVfE+9a9TXxnlVfEx9Z9TUx PXgv+FR8HHwWzBHfBPOC+WJxsDD4XSwNlgTrxIpgQ7BDbLKqbGKPVWUTewMTccQ+q8omDlpVNnHI qrK5TiQjUtINrR6bmxopG6nkpkWqRKq5xSI1IzXdUpE6kTpu6Ui9SEO3TKRx5Fy3QqRZpJlbNdI8 cqF7RqRFpKVbPXJJpJVbM3JN5Fq3TuTeyINuvWjpaHm3kVV3c5tadTf3IqvW5rawam3u/VatzX3M qrW5Paxam9s74cqEW92J9q09d7pVa3O/1Eonud9bnTZ3rr5e3+FutTpt7mGr0+Z5VqfNU1anzYta nTYvweq0eYWtTptX3Oq0eSWsTptX2uq0eVX0eD3Rq2p12rzaVqfNa2B12rxzrE6b18TqtHlNrU6b d5HVafNaW5027zKr0+ZdqVfolV4bq7Lm3WBV1ry2VmXNu8WqrHl3WJU1726rsuZ1TBSJgXdvok5M 9B5OTElM8zpbZTXv8cQ9iXu8J5IoyfG6k3BWAvUSYfElUTI5VAgfl1IwD3uUjrnbx6x+GuIr4KOo ImbBgKoCJSPAw4akgYf2/zyczf8BwyJmIiNmEhDzauS6Bp9CwM22KPFGupWa0G3A0KbA0AfBHB7C 51zqRJ2pMD2GTxHqQk+g5u5A2HQgrKYMJ3QSKZPfEC7mJANzzwDmVkRMJacSVXcqO6cjvopTBeGq wOIMxuIawOJW8FsDkc9nvdAMpy1wuSbjck3G5VrA5a6I7+Y8R7WdXk4vlNkbSF0MSN2f6joDnJeo njMEqF2DUbsGo3YNRu3qQO03EH4T2F0d2D0L88FXzlfU0Pna+Y4aOd8DzRszmgugeW34dYDpkjE9 mTFdMKYnM6anMaafx5h+JmN6fcb04sD0N6iUeFO8SSXERPFfKiMmAeXLMsqXZZQvDZT/GP4nwPqS jPXlGetLAOt/gP8jEL80EP9n+L8A90sy7pdk3C8H3Nd0mhsC/Ssw+ldi9K8I9E+n090MN4OquJlu JjWzMwHCmAmoMmaCivAruZWRC/MBVbXzAXI1cBvAb+g2xNXGbmP4Z7tnIw3mBviYGxBj37W+gN+1 vpDfr76A36++kN+pbo55ojud7T3pPUcOZosBlOQN9IbQWd5Qbxilei97I6mBN8obQ0W9sd5/KcOb 5H1AmZhRplJNqyZKte28Qo3svELazivwk/1kauoX8gtRDTu7UE3MLr+R68/151Jpf54/j5L8+f58 8vwF/kLyMessRswSfwlilvpLSfnL/GUU+Mv95VTYX+GvoAQ7J1Fo5ySkXO+vp0L+Bn8DpWBm2kiO v8nfjBq3+H9Sqr/V30pF7VyFGnf5uyjd3+3vpsb+Hn8P2rbX34v27PP3Ibzf34/wAf8Ane0f8g+h 5MNSUKp0pUdnS1/65GCGU4TJQgYUyoiMUpJMkAnkSi01pctQhtRYJspEpMEsaP+ru0xF3jRZGHnT ZQbSZ8pilCKLyxIouaQsSVYBtQz8srIsSignyyF9eVke6U+TlZC+sqxMReXp8nTEV5FVyJNVZVVK lGfIaij/THkm8laX1VFaDVkDaWrKmshbS9YibWdc1FVP1kN8fdkAKRvKhiihkWxCvmwqz0fK5rI5 KXmBvABtbiUvw/e6XF6F8tvKdqj9ZnkLarlVtkc5HeTd1ETeI++jpvJ+2Qk1PiwfoXPloxLoIR+T XaiIfFw+jtZ2lU/gu3SXT6KcHrIHSugpe6KEp+RTlCCflk+jlmfkM0jzrHwWtYABUDHLAKg6GMBA qi0HyUFUy/IAygAPGIqrw+QwypQvS+CAHC6HUyM5Qo7A3R4tR8MfI8dSTasBi/TgCihhopwI/y2J XionyUnIO1m+TefLd+Q7KPld+R6uTpFTkHeqnIr4D+U0pJwuP0bKGfIzXP1cfkF1wTC+QvzX8muq Bp4xG+m/ld8i5jv5HVJ+L39Cyp/lz2jPL/JXpJkj56CFv8m5aPM8OY/OkPPlfKonF8gFyAuOglxL 5VKUvEwuQ651ch1KWy//QPqNciPSb5O7kGa33I27sUfuQdv2yoOUYXkM1QKPCRFOVIWotkpRqVRM pamiVFelq+JUT5VQpakGWE5FaqQqqcp0kTpdVaGGqqqqipgz1JnUWFVX1VFCDVUDKWuqmkhTS9XC 1doKtiO40VlURzVQDVBXQ9UQ6RupRrjaWDVGXVZTwLGciWpazgQfnAk+OBN8cCb44EzwwZnggzPB B2eiTMuZqJjlTPDBmegMy5kQBmeiRpYzUYbVqqVqQdOgKXKBOSEGzAlpwJzggzlRXcucqB6YEyyB oEPQgRqDP91HScH9wQNIAxaFvGBRiAeLQsongydRTo+gB8I9g56IB6NCe8CokL5/0J9qBwOCAcgF XkW1wKuGIGZogF4XDAuGI/xa8Brqej14nS6yTAsxYFoUtUwLPpgWfDAt+GBa8DcE2+icYHuwHbXs CHagHLAuqm5ZF8ImMPZ/b0WIzo84EYcyLAOjYmBgCn4QCahOBI6qR6KRKMI6kgg/KYL5N5IcSaa6 kUKRFMSkRlKpUSQtkka1IoUjhalxpEikKOIzIhlUO5IZyaQzIsUixRAuHimOWkpESuBqyUhJxIDb IQxuh5aA28EHt4MPbgcf3A4+uB18cDv44Hbwwe3gg9vBB7eDD25HUcvt6BxwuysoOXpl9EqS0aui VyF8dfRqhK+JXoPwtdE2lGaZH2Kei44nEZ0QfQth8D+Ewf+QBvwPafYlOCQSREImnWdZINWPaTdY FkjCskD4YIHwr9fXUwl9g76BSuu2ui0V0jfqG6mUvknfROV0O92Oyuqb9c3k6lv07Qi31+2RvoPu gDR36DuQ5m59N8L36I5UXt+r70Wa+/T9SPOgfhBXH9KdqCSY5aOI76w7Ix78En5X3RV+N/0EFdfd 9ZNURvfQPZHyKf0UUj6tn0GNvXRfxPTTL6BkcFDUMkgPgj9Yv4g0Q/RQtHmYHoZyXtb/QXi4Ho70 I/QIhF/Rr6DMkXokro7So6iiHq1HU2XLXKkSmOt4qqIn6AnUTL+q30D4Tf0m0kzUE3F1sp4M/239 DlXV7+p3cfU9/T6uTtUf0un6Iz0NMdP1dMSA78IH34X/uf6CTtNf6plIM0t/RRX01/prpPxGf4Na vtc/IeZn/SvKBBtG+fP0PPjz9QKkWaR/x9XFejHKWaKXIrxML6PaYMkrUNpKvZIqWq5MJcGVe1Lx 8KnwaSobPhPiLoE396KqYe8Q9yrsF/ajUuHz4fOIGRgOoirh4HAwNbN8GjHg01TV8mlKs3yahOXT 8MGn4YNPU5rl01QTzK4J8+nmzKcFM+kYb85izJYfJzI/TqTr8ElkZnwhM+MWzIxTmBlfzMy4CDPj osyM05kZZ+TQ7/FZvydg/R6f9Xt81u+Jsn6Pz/o9Puv3hKzf47N+j8/6PT7r9ySxfo/P+j1JrN/j s37PRazf05L1e1JZv+cS1u+5lPV7WrF+T2vW78kEU08Abw6dkDl6BtVxMp1McGjL1OuDqbeiBszF r3Cucq5DvOXiDZ32Tnsw7Iedh+E/4nQBb+4KRl4PjLwXNQYX741wX6cv0ltGXg+MfCg1ARcfQU3B wt+H/4HzAZ3rTHFm4Kpl4dcwCz+PWXgzZuHng4VXJ5dZuJuDf7vg3+cx/74I/Lsls3CrMOSxwlAh VhgqxApDhVlhqBBz9MuYo58leos+dLZV9qcr40zd8vIqYrKYTJXFh+Dl5ZiRn8aMvKL4TnwH/m25 eBnxq/gV8XPBv8uwalEJsVAsASNfJpbBtwpGVVnV7XSxWqxBzDqxDr7VdivJykblxWaxBWGrb1RB bBPbEbYqR5XEAXEQYat1VEocFoZKsuJRWddxBcJW96iC67s+wlb9qCyrH5V3E9wExCSB/Vdj3l+T eX9t5v2Xu8Xc4oi37L+aWw7s/0y3Ath/NWb/1d3T3dMRrupWhV/DrUW1YAnUQ7i+W5/OcM+CPVCN 7YEabiPYA9Xcc9xzUL61B6qxJXAVWwJXsyVwFVsCV7MN0BzsfwglgvePpBRm/OnM+Isx46/vTQHj bwjGP5Mae7O87+lc5v3Ncmgy+azJlMSaTKmsydSaLYEWbAk0ZX2mlmwPNIA9MIck2wDKXwgbQLIN oNgGSGT2r5j9p/ur/dVg+Wv9dYixvF8y4y/KjL8FM/4UZvzpzPgz/J3+TviW0zdnTq+Y06cwp2/O nF5ICU6vmM0rZvMZzNqbM19XzNRTmKlnMDtvzrxcMS9PZ17eHFwcdq+sBkYumYunMBdvHmfhtWVt pK8r6yK95eLNmYXHOLdinq2YW1/I3LoFc+sU5tYXM7cuwty6KHPrdObWGcyeM2Q/2Q+c8nn5PNik Zc8NmDE3kkPkEMRbxlyHGXNTOVKOBI+0XLmuHAuu3Ii5cjHmyo3lq/JN8PiJYMnFmCVfwfy4sXxf vo9cliXXZZZ8BVjyh8j7EbhyMebK9ZkrN5ZfypkoYZachfSWK9dlllyMWXJ9ZsmNmSU3k7+CJTdi ltyUWXJdZsmNmSU3YZZ8PrPkOnKJXIKrlh/HmHEduUluRYzlx/WZHzdgfnyFPCwPg6FaZtyImXFj MOOiCFtO3IQ5cVNVRp1G5zIzbsbM+BpmxucxD27KPPga5sHNmAcXU/VUPfiWAZ/PDLiZOkedgzKt olgSa4n5rCWWxCpiSawi5rOKWJRVxC5lFTGfVcR8dbm6HLVbLTGftcSSWEWsJauIpbKKWGtWEctk FbFMVhHzWUXMZxUxn1XEklhFLDWHilgSq4hFWUUsiVXEMllFzGcVsSRWEfNzqIj5rCKWxCpiPquI pbKKWCariPmsIpbEKmKZOVTEfFYRS2IVsdasIuazftj/Y+1roOK4rjRfNU1TRi2MMMYMxhhjjDEm hMiEMAQzhGBMCMaEEEVDCN00TdN0vSq6q6t/aJrqX1pE0TJYoyhESxQFa7UaIrOMRqNVWEUhWq1G QziEgxkto2VYQrQaRkeHsAphWKxR9r7XDUZyEnvP2VPn++rp1avX9XPr3vtxqq6id9UPi6b1w/bS +mFP0vph0bR+WN2u+mHRtH7Yk7R+WDStH/YkrR8WTeuHRdP6YU/S+mHRtH7Yl2j9sC/T+mFP0fph b9H6YbW0ftjbtH5YHa0flkLrh0XT+mFfpvXDamn9sLpd9cOiaf2wFFo/LBo0zFOoGBTLS+gLVJ+U sy+zL4M2yGazIdd/lX0VFbG57KdAb+SxedCfz+ZHdEshu599Db1B1UshW8gWARMNU8F+nv08zEM0 TDlbyb4JXMV+GWarYd+CMbVsLfos+zYomdfZOrYeFMLX2a/DVqJnylgNq4Hj0bE62CtciZEonApQ OCb4LaJw4lgLK8I8VtYKe9lYG/oi62Ad0NPDeuAsiM4pptrmWVq5sZAqnBK2n+0HJjrnDapzStjv sOAlqM4ppArndfYH7A+g5132Xfh1onYqqNr5OvtX7AjsRTTP6+x77Hsw5j+xY8B/A8pnD7vI/gr4 f4Hm2UM1z5tU85Sz6+w6zEw0TzH7AfsBnB3RPHuo5vkq1TxfoJqnhKqdQqp2iqnaKXxiLyicElA4 +1AZVTgVVOF8kSqcN0DhJIEKeuaJZBj5J6Bwiqi2eZbqmXLQMy/Dr+SAntkDeqYAuPCJYuDXQcPs oRpmD2iYt4GJetlD1cseql7eBPXSEFEsRKscBB3SSBVLU2wT9LTGtqLSWFOsCRjHYmAhVgA2x5qB pVgJmNSi20dr0e2jteieprXonqa16PbRWnT7qPKJotrmK3ue3ZOB/nRP9Z6voNI9+j0u1EAr1Smp 2lGCwnkVVATRMK9SDfOKug00zAvqDrUJMnWiW16giuVVUCyd0DarLaAc7Go79BCt8qK6W90NPT1q D6gUok9eovrkVapPXgF9chh6vg0q5RWqUl5W/4X6L2A80Sevqr+jPg5bvwv65GXQJ9+D2Yg+eYnq k7AyeZEqkzz1D9U/BH5X/S4wUSYFVJnUq/8KlMlnQJmcg/731KMonyqTz1Bl8hpVJgWgTP4Gei6o /xZ9Sn1RfRFG/lj9Y+gn+uTT6sugT/LUV9RXYOs1UCb5VJMUUE1Sr55U/xy2TqmnoZ8ok9fU76vf h5FEkxSo/1F9C/r/B2iS10CT/BPMtgjKJI0qk3z1knoJfpfok/1Un3xa/Ss15Hi0OmAurUeao76r vgc9pFJghnpVvQZtUi8wi9YLzKD1AnNpvcAMWi/weVqPNE39b+p/Aya1A3PVv1NDBkgrCGZCYg4Z IK0j+DytTZpGqwk+R2uTptGaglm0pmAurU2aszdu75PQT+oLZu19au9T0EOqDGbTKoPP703emwJb Sa3BXFprMIvWGsymtQYz92bszYCtpOJgFq04mEErDmbuNe01oReoEnsJlJiPKjGwh72H9h4ChdYH 6uslqr5eo7qrHnTXd6B9fO8gyqfq67W9J/aegDapXJhFKxc+RysX5tLKhdm0cmEWrVyoRMyz91O9 kPyqow6j/4mQthGgBRgAGCACnDtrxjwCaxkQBBwGDACOA4YAw4CzgFHABcA4YAJwHTAFmAXMAxaR wjtJgbS3KRTeGcBNaN8FrAE2AA8QalEAWEAcIBGQAkgPH0NL1h9Y54bnatkfAdmnCFBKt6GWCkB1 +HjpPsPhc2ypAxwANIX7I2uFd4GCMY8BLkJ7eacvjBXAaqR9E7AeaW+F4UMRqABqQAIgGZAWHuvL pONRiw5gDF+nFmHnmofH5tBxqEUCuABeQChyDkfCv+fLj5zrUcAg4GRk++nI9sIISqAP7mMLOZ/L gKs75xI+54uAy4CrgBuAacAc4BZgCXAnsr63a709/j5gM7K+Fdlvc9f2hwjplIBYQDwgCZD64Zrc P10GIPsTrxW+8g/vFTk3XV7kXv+/IuVRUPs+HP4dalcp4XH0d3ejAFD84XpnjvC8Cl8V9JcBKiP2 B9t0NR+udfWAg8p9zUt8dc+MNtiJKKsoq4EPdyYAD3QmAx/vTAMe6swEHu7M6Zkhe3matGc78z26 5jt8Xc/N5nv8gZ4F7WhnIeWSnfaFzvKeBbLVY2y+zzf1LGvHO6t6lsPtCG/yup4V7URnLeUG4Ou0 fZ22pzobgWc7tcDznQbgxU7cs0L28gjARmg/5IWeVe3tThH4bqcTeK1T7lkl/R5Jo+SlnnXtRmcQ +EHnYY9LE8u7erZaFJ0DlI9THgJmWyqA4zqHgRM7zwKndI4Cp3de6Nkie3m8LVmd4/KQJp73ynBl OydkpEniQ7KKsCekSeWPyOqW/Z3XgYs6p2Q16fEcCfdHOIM/KidosvlBObmltHN2hys65+Vk0u85 GuE8/qSc1lLduUj5NnAdbR/ovAvc1LkGrOvcADZ2PthhwazwDLZIZtZzUlPAn5YzW1zmODmTzpYT 6fGaE7eZ9HhOa4r5ETm/JWROoZy+3Sb9nhFNGT8mF7YcMWfJhaTtGdOUmXOhXclflEtajpr3Uy7a aQ+aS4FPmiuAT5urgUfMdcBj5gO03SSXkH09FzU1/GW5XFPPX5WrWi6adTt82azzXG65ajbKVZqD /A25VtPMT9NjEChLO+0bZhcciZ6fkxtaps3eHZ4zh+QGjYm/JTd2THR5KYcoHwG+3nUUeKprEHi2 6yTwfNdp4MWuEbmR7NXr6rjdNdbr1Zj5JVmrsfN3ZEPH3a6LwGtdlymT9kbXVdlAtvaGNG7+nqzq eNB1Q1aZFPy93iNh1vj5+zI2sV3TlOeA42g7jrYTu24Bp3QtAad33QHO6ronY7JX71HgTWj38Q9l 0ZTbdR94f9cmcFEX9JD+3kFNv6CUnaZSF+EKV2zvSc0xIVaWTdWueMKmEG0nAde5UoEPuDKAm1zZ wDpXHrDRVSDLZK/e0ybBVdw7ojmhWZaDJslVJgc1p4R4+TBhX6bmjJAkD5hcrkpgr6tGHiA9vWPh /gifE1Ll45rzQoY8ZAq56nf4iOsgPDvQ33sxwpeEbHnYdNTVTFm/0x50mYBPuszAp1124BGXG3jM 5Qe+6OrrvWy67Or36DRXhDz5rOmq61jvVTrbaKTnhusE8DRh0tN7Q3NNKJAvmOZcpyif2W6T/t5p zaRQLI+bbrnOyeOk3TtnWnKd772lmRHK5AnTHbjywK5LO+17rivA913XgDddk8APXTPyBKd03QSO dS3IE2Tf3iXNTaFSvq5ZEGrkKS7etfwYJ7lW5CnNslAvz2pWhIPyPJfqWqW8vtPOcG3J85pVoVle 5LK70Q7ndavkRc26oJdvt9wyH6F8FHiJtu+YB4HvmU8C3zefBt40jwA/NI/Jt8lenqs6pfmi54Zm SzDJd7VIMMtruljzZeB4ykmUU81X5TWy1TOtVQl2eUOrMt8gTNq6DPO0J06rFtzyA122eY7yrcfa eeYl4ALzHeBi8z3gMvN9+QHZyzOnTRD8HoU2WejzsLpK8yZwjfkhcL1FCXzQEuthtWlCvydO10xZ b4n33NJmCsc8iTqTJYlyKuUMT6I205INbbMlD9huKQB2W4pJP4xf0vktZdDTZ6n03NHmCCc8Kbp+ Sw3wMUu9J0WbL5ySZwl77ulOWA567msLhTMw/pSlGWYotOgJQ89SuD/CJcI5T7q2XDgPx3bGYgI+ R/m8xQxXhvRv6i5Z7BA9aVtbJVzyZOmuWNyU/Tt8zdIHPGnpB56xHAO+aTkBvGA5BbxsOeN5qFux nPMqYZ4rnlxtmuU8cLlwDbhWmITjXLVcAl4nTHuWtA3CjGe/bsty5VEm/V6QrZZrnqxWlWXSG69t FG56ilrVlhlPEWl7k7SNFujRaoUFel5hXt5utyZYVoCTLavAaZZ14EzLFnCOiIDzRRWcO9l3U2sQ lj2lWiyseCpaC0X1Y1wiJngqtKKw6qnWOoV1T11rufkoYTF5h6vENE+dVha2PAdaa8VM4AbKjWIO sFbM96aSnMSb0WoQCyE/gdzAm92KxZKelVZRLAd2ilXhCO7NI3HQW9Aqi7VyWmtQbJDTSCTyFrce FhtJVBK1wBBrvGWtA6JBLmw9LmKIL/C8eCtbh0RRvk3s1lvTOiw65QetZ0UZeFQMhm3MW0/ur/dg 6wXxsCdLWyUOAMN18Da3jovHyTURh4DDZzohDgNfF8966mjEucMVdKsh+hDPf48r7k6QMVfWnQxc 2Z0W8c/3iZfr3eRqujPlYc2l7hxg4mcecvXd+cTndBcCgycJKbmD3SXgPZq7y+V5avlLrVPiqFff Oite8Jpa58Vxr7l1UZzw2ltvi9d7FlrvilM9y61r4qzXDWPmYcyGuOj1tz4Qb3v79Arxrrdfz4pr 3mP6OHGjZ1VTIz6Qy/WJVoX3hD7FynpPaQ5a4+Rafbo10XtGk21N8Z7T5FnT5TR9ljXLc0Ofa831 ntfvt+73XgrnG/oia5H3ir7UWtozQzIK7zV9hbXCO6mvtlaTu2Ct247s+jrrAcpNwAfg2Gb0TVad 96ZeZzV6F/RGq+Bd1gtWybuil6wu76reZfV618M5bYvCGoIsLpxH0SxF77UegdyV5o36kPUo8BHr IGRxxDa2WnRWYP1R62kf0g9aR3wq/UnrmE+tP01GapTWiz3r+hHrZV9COHPTDlmv9szox6w34Bmn Oar+onW6Z6UlxTrXs6W/bL0Fv260LsF1uGq9A3zDek/O1E9b70MONmLdhOOZsz4EviUpvf3aDSkW 5l+S4n3J+jtSkneGXAFfmv6elBq2bV+m/r6UAfNsStlyof6hlOfLaVNKBb78cIbZFisV+wrb4qUy Xwl5LnzlbUlSJWTpkKv7qsLclirVhDNwX+0ubqDcSH9FS9nQliHV96y0ZUsHe1bb8qTmnnWSUftw W4Gkj7RFyk7yfPnkyJWEfNgXpHyYHJVvoK1YMvkGwm3Kx9vKJLOc0FYp2SEfhqzYN9RWI7nDObBv eBefhUxVkjPb6iU/8EHCJGv1jYa5rVnqC2eqvgtteqlfzm8zSceAoR96zNKJcNbqLfuQfePkqfdN UL4e5ja7dApyUchIfVNtbukMZJ6Ql/pm2/zSObm2rU86D2yWLkHOOS1dgdyS3Jf5MLf1S9d8i7oM aRKebuKZ49qOSTMQPTOkm9A+IS34bmvTpGUSEaQV3922U9Kq537bGWndt9Z2TtrybbSdtyHfg7ZL NpVfEfHt1HtrG21qP9t2xZYA3thpS/bHhT1h2zVbmj+xbdKW6U9pm7FU+tPbbtpy/FnhHEBnsuVD LKBRpm2B+O1wjG5bthX6c9tWbCX+/W2rJNq2rdvKIeqB1/IX6WZsVf6iti3znL9Ud8xW60kxIFuD PyUSl8/YGj1xBpVNS3IJm0G+bVDbMInpNlF+YEiwOT2JhmSbDL+7YAuS+GUDH2hIsw1Af6btuCex Nd82tB0pDDm2YX+FId92Fo4NcglfgqHQNuqdIWfnrzaU2C6EPa1nzlBuG4d5qmwTEAUg5vrrDLXC ef8BEqf8TYYG23W/ztBom/IbDVrbrF8g180v0XlcBoNt3u81YNsiaBzw4f5QONsh7G0O83ZWI9j9 RwiHe/xHKQ+SY/CfpHzaINpuexQGp+2uhzXIJBshmYm32RC0rYXbEO+AYS+IBf4R4nX9I4bDto1w XuEfizCchbfeMGB7APGCtul5jRiO2xWedMOQnYWMAvIK/0XDsD0unEXAUe2wf1B3xp7oyTWctacA j9rTwxEf5gH2XzZcsGeFo7z/qmHcnuvZb5iw7weGfui5bi8KR3n/jV08TeKUf47yIOVbhil7KcRu iOD+JcOsvQIiNcRx/x3DvL3aU21YtNcB37YfgChWa2/yHKDX/B7l+5Erc9eu8xQZ1uxGT4Vhwy54 6gwP7JJ8u11hd/k3OX13VSiWM3XXBms5c3cDsL27UR7g3N1a2cD5uw2yiuvrxqF4GCPC1v5uZyiJ O9Ytw9YT3cFQKneq+3AogzvTPQBq6FT3cfkwd657KJStOdY9LMvc+e6zoTzuUvdoqIC70n0hVAwR c1we5q51TwT6uMnu66EybqZ7KlQZVgeaye5ZeZy72T0fquEWXOdD9dxy92LoILfSfRt03Er33Z08 fLV7LdTMrXdvQHur+0HgPEZuRUiPVW42ZMJqd1zIjBPciSE7TnanhNw4zZ0e8ocVqKnanQWaK6x0 qKbAme7cUF9Y5eEc6BFxvns/aC6I9aF+02l3Uaify3aXho7hQndF6AQucVeHTKZcMlLT766Tnbjc fSB0KqyzOibcTdt6NqwxcRXVldWmO0TxuXU7vz7iNgJTrYRr3QIoprDGeQgacwI3dK/5Skylbgnm b3S7Qmew1u0FnQVXIHQOG9yhSK5yFGP3EXkYi+6j8jx2ugdD57HsPhm6FNaDOOg+HbqCD7tHQtdI nhOaxAPuMdDUoKxDM5Rv4uPuixA1QEFDvAAOLRD2UE0dWia/EloJMx5yX4YzGgbNJeKz7quyk+jf 0Coedd+ItNcpb5F86RCKXElQr4dUEYajOqTGF9zTh9ThNuUEPO6ek4/jCfctUK+gYQ8l4+vupbBi PZS2izNNN9x34IpNue8BzxImGtN7MMx43n0/rCsP5eBF96Z8Ad92PwSGfui526MMa8xD+bu4kGRx h0ool4cZr/XEgnIE/XioCm/0xINOBBV5qBY/6EmSZ3lFTyow25Mhz/NxPdmhZnJfDjVQbtT09+SF VvnEngJ5nE/pKZan+PSeMhiZ1VMpN7azdq//IdUONB5R3wWapT3OHgoo2xPtRwKxWpX9qC+hPcU+ SGKH/WQgvj2dMLRPB5Las+wjgVTgsR3OtV8MZLTvt18OZLcXwV5sWNO1l9qvBvLaK+w3AgXt1fbp QHF7nX0uUNaeQvwn5c32A/ZbvjXiLQOVlGt0fvuSJ7G9yX4nUN+us98LHNQW2u97ltqN9s1Ac7tg fxjQUzYRPxkwR7QVcMDeLjmUAXdYZ7W7HLEBf7vXER/oaw85kgL97UccqYFj7UcdGcCDjuzACeIz A6con2k/6cgLnAMu8CjaTzuKA+fbRxxlgfPhmNI+5qgMXGq/6KgJXGm/7KgPXGu/6jgYmGy/4Wj2 lVAvyrZPO/SyoX3OYQrMtN9ymAM325cc9sCCFjvcnor2Ow6/p7T9nqNPvhCOUIQDy1oZoiG0Hf1+ Vzhza4t3HAustN93nAisapHjVGC9fdNxJrDV/tBxzv+wPddxPpBhVDouBfKMsY4rQWSMd1wLqoxJ jsmg2pjqmJEHjBn2wWDC7tmM2Y6bwWRjnmMhmGYscCwHM43FjpVgjrHMsRrMN1Y61oOFxhrHVrDE WO9EwXLjQacqWGVsdqqDtUa9MwHY5EwOJkTY7EyTbxvtzsxgg9HtzAn4jX5nfrDR2OcsDGqN/c6S oMF4zFkexMYTzqqgaDzlrA06yf0NysYzWmcwaDznbAgeNqY6wecbzzu1wYHwvTNechqCx41XnNjb b7zmFINDxkmnE3jGKQeHjTdh17PGBedhf6K2ygkKy7jsPA684hwKjhpXncPBC8Z151ngLUdxcLwD OUd9ix0q5wVZ1aF2jgcnOhKcE8HrHcnO6zLuSHNOBac6Mp2zwdmOHOd8cL4jX5jxlXQUOhcDxR0l ztvBRRh5F0aWO9eCt8O/0lHl3Aje7ah1PvDOdDR0KYJrWpUxW97oaOxigxvakq44T3qHtisx+KDD 0JXSq+jAXem9bIdodPey2oYuiM4dzq7cXsjluvZ7DnTIXUW9iR3BrtLelI7DXRW96R0DXdW9We37 u+p8a4R7c8Oqv+N414He/R1DXU29RSR76S0lWUpvBfkrSm91+Imjf8E4EvlLxaNPx5XI3wroXwZ6 6zqGu3SBbBLfew8QDd7bRKyxVxf+6xD1D5sdZ+2DMD/NxDpGu4yeufasLsEzF/nrDf27SscFwdxr bL/fJfUKYdXfMd7l6pXIvfbWIwV6hllj/jdCzG+ZDaRgtpgPkJL5nYJBKkW0QoWeUOxRqNEeRbxi H9qreFqRhJ5UpCieRfsUGYoX0VOKbMUr6GnF9xXfR89EVUV9CSVHV0a/iVKixWgrSo3+WfTPUFoc LOj5uPS4t1B6XF1cE6qN08T1om/EvRP3U+SPuxF3D/113GrcBroJR/MVpKT/+0EcehI9gfahBrQH HUA69DbSo2+jJvTvUD8KogH0Pgqhf0C/RJPoV0ws+u+MmtmLfsc8yTzNMAz5xokl700yzzCNTDuT ynQwISaH6WOOMVXMIPN95mvM3zK/YL4R9V7Ue4xdKSltjEPpVfqZLmWf8tuMW/mO8h3Gq/yu8nuM T/kD5btMUDmqHGO+pbyo/DFzRPlT5U+ZAeV/U/4d8w79HvOYclb5PvNd5aJyifme8o7yX5gh5a+V v2ZOKX+r/Ffmh+QtOuZ09FPRTzH/Mfr96IfMWVW0KpOZU72seplZV72iymN+q/qcqpj5gHzhwfxO 9UVVhUKpqlS9pVCp3lY1KeJULSq9IlVlUImKdJVNJSs+pfqWql/xOdWAakjxuuoHqjOKavLlhKJe Nar6ueKrqmnVtMKimlHNK0TVgmpB0a1aUi0p3Kp/Vt1V9JD3sRQ+1W9U64qQakP1UNEXg2L2Kt6J SYh5WvGDmGdiXlS8G5MV81nFWMwXYrBiIsYac1RxL+Y7Md+JUsd8N2Yoam/Mj2JGo54i/69q1DMx /znmUlRqzHjMz6LSyPtAUVkx/xAzH1UQcyvmTlRRzL/E/GvUG2wWez6qgf3NEy9E/TLug7gPlOR7 OYz6gNUojXxtXD4WAQvIRVlYV7WJjRVVX7pZkY8FLGFX1RL24lAFrhvAF/FlfLViHN/A03gO38JL +E5NbE0GPlJjx0ffqH7DiAfxSXwaj+Cxmow3KsCqlGDja9TGf4sY5nfM75ACLDoeRcG25+ibqEjx I8WPEKN4T/EebBtT/DWKUvxE8RMUTd9EVSl+ofgFYumXYE8o3lfMoVj6Dqqavn26V/FLxS9RHH3v 9EnFrxW/hqeDvFmaEMVEMTv/a3B0lAol0S/HkqOSopLQn0QlRyWjFPqm6LNR2VHZ6Dn6VVhaVElU CUqn34C9EFUW9QWUQb+KyaTvbLwEx69mEuiVI4y4a8jNXeMmuRnuJrfALXMr3Cq3zm1hxK1jFVbj BJxMkYYzcQ63ivNxIS7B5bgK1+IG3Ii12IAxFrETyziID+MBfBwP4WGKs3gUX8DjeAJfx1N4Fs/v XvgDeBHfxnfx2s6ygR/wCp7dtcTxiXwKnw69WY8sTXwWjM3l9/NF+MH2wpfyFXw1MFnqeB1e440w VuB1vMS7eC8f4o/AnFn8UX6QP8mfhvNnnsARr0G+Wd9Hr0kyLFEoFRYlykIvo2iUC0sM+jQsLCqG 5QlUAkssKoVlD6pAb9C3y78MXod8d/kk+nPUiOJRMywJ4Hf06ClkhCURWZFEv7h00W8tPfSN8gBK AX/0DnoWfReW59C/hyUN/Qd0Bj2PfgTLC2gUlgz0Y1heRP8Flkz0E1heQv8VXYPjm4Qlm/5v2K+g efSPKAf9Eyy56FewfAr9Myx56D76DRz7Jvo/6DPoISyvMQomBhUwseD7iun7458H3xePSuj746VM GvMC+jPmReZF9EX6vWcFeMM6+kVnI6pkvslo0ZuMjtGhL9N3yWvo151vMZjBqJbpZDrR24yNsaM6 pofxo3rwnSF0ELznt9CfM99mjqBvMAPMAPom/bqzGTzpJaRhxplx1MpMMD9DeuY683fIwPw98/fI yPycmUId1H458ALZCLM5bA7qpG/nmdnPsPuRhb6RZ2WL2WIksaVsKbLRL4ns9P07B6tlW1AX28q2 om64t3fQBrX9QlJZwnQBMA6YAFwHTEUwG8E8YBF93TRumjBdN02ZZk3zpkXTbdNd05ppA/gBp+BY WOK4RC6FS+eyuFxuP1fElXIVXDVXxx3gmjgdZ+QETuJcnJcLcUe4o9wgd5I7DcsIN8Zd5C5zV7kb 3DQ3x93ilrg73D3uPrfJPcR9WIljcTxOwqk4A2fjPFyAi3EZLJW4Btfjg7A0Yz02YTO2Yzf2w9KP j+ET5H8QjdZFd0AQ/GZcM62v8Mb/N/t+C5YnqZXHUyvfR638KWrlidTKn6ZWnkStPJlaeQq18mep ladSK0+jVv48tfJ0auUZ1MpfpFaeSa38JWrlWdTKX6ZW/gqagiWH2vqr1NZzqa3nUVv/NLX1fGrr n6G2/hq19c+CrStQIbXvz1H7/lPmOSYN7J5Ydgm17NepZZfS7yP+jFpzGbXmL1BrLqfW/EWw5h54 BjyMB54B8pXEm9Saq6g1VzN/yfwlPA/Epmvo9xFvUWuupdZcx0yBHdcz08w0+ir7NfZrqIFtZBvR 19gOtoN8rx3vjT8M90kN134PYizNYHf7AUWAUkBFpK8aUAc4AGgifcp9pgJLITf7x0HHzItzpmJL ianMUs4tPgrSZ6q0VHG3AXfFWwSmGkstt/bHQcaY6i0NpoOWRm7jQ5B/m5otWu6BRYsV4pJJbzFg 9o+DjokT75hMFowTLdhktogUdosTpwDSRYG2s8R7OFe8b3JbZJPfEsT7PwT9d5G4aeqzHMalH4MK 8SGutipN/ZYBimOW46YTliFcFwZpk3PDBz4EPddTlmHcZBkma4ozlrNY9/Eg40znLKOm85YL2Pgo TJcs49vz7obpimUCCx/CdM1y/ZPA3Gw/YZq0TJlmLLO/Fzct8wRmvf0UgWnBsviJsGy5bVqx3P0I Vi1rBGaTtd+0btn4JDCb7WdMW5YHBBwSFRQqkSUw2+3nyLpTsI1wWlHHqcU4LkFMfBxmt/08lyym fBzMfvslOkeamE6RKWZxOWLuI8gX938EhWLRIygRSz8xysUKrkqs/ghqxTquQTzwETSKTY+AnPcn AJassZxBNHJYFH4vYBt2WeOx15pEx4mi9IngFF2cLHo/AjJfCHDEmsoFxdAnAT5qzeAOi0d2MCAe 3QHZPgg4ac2m7dPWPDxiLeCOi4P0eB8DHrMW0/aQePLjgC9ay/Bla+UjcwyLpx/BWXHkIyD7XrXW cKPiGL5hrafraevB33c8fxAXxIvcuHj5I5gQr3LXxRsfwZQ4vRt4ztq87dt3++JtX7nj425Z9Ts+ aMlq2u1Hduxk933dvi/b1+iO1bxzbe9Z7buPifqSPvAp8Oyb+8M+wHws/PzS5+qEmELjBti7+RTg jP3Ktj2bz8Eafodsx/etbrxp9eOH1j5eae0n8YWPtR4j/eTc+HjrCT7Jeor4Vz7Veob4ST7Deo7P tp4nMYDPs14ivp2eM9g7X2C9su2f+WLrNb7MOknOm6+0zpBrwddYbxLfSeakqLcu8Aety3yzdYXX W1d5k3WdN1u3eLuEyPWlMYhcS7iGvBviZCSe8X6IP5HrzPfBPP2SisxBtx2T1PwJKYHEnZ1Yu+se 7cxJEIkp27GAHBOJjfwpKZke2xkpbfs+0/HE98O9p3EZYh49t3NSJunjz0MMLw6DxGtyfR9BTTgu k3hF4zH8znYsJmsKsB96bo/FWPpbAP6SRSYgMXY7rm6Dv2IZINiJkSRmRmLj7lj5SIyMxMlt8Ncg DsI9prEP4iE/aRknoHZL4tyVMHZ8FoCfkXLo+qaUzy9IhbQf/Ae/LJXwK1I5vypV8etSLe0nzzCJ JeS5heeIPE/8ltQgIKmR+CJBJWnpc7H9HET8IrUtmIf4OUENvinyjND7BX6L7L/tAz/ybD32XO34 l+3jhzmI3xQSJAO550KyhHf2J+PheRPSJFHIlJzkuIUcSRbypSD14eR84ByEQumwUCIN0P0+zv9E jksoj/jx7Wc8tGtM5JjpuT7mj3fOh/jhbfyh3/oD/lSoiqxrxTFyTjt43E/u9pXEP277yN0+EcbS ecgYsg2ugdBgrTGft18zX7JPEpDchtxvmtdcsc/QPvBZwqwtznzNfnM7fzFP2heEoDRB/RjkHeYZ +zLNKcCnCaPSXUGWxrdzAvNN+wr1aST+k7yB+LoF+yqJ0eZl+7p5xb4lTEgPzKsOZF53qMxbDrUF ORIsKkeyRe1IozlZxF/SfUluFsmbaM6znaOQuSJzkG2WBEcm8ZfkuHZyu+08bP1DH0yxncNEcg8y F8nHLMmOHJLvWNIc+dv70/FwPvTfcL3ocwLnZsl0FNI+kjduI5InPoLHc8FI7vcIItf18bxuByQX 28bjed12jvZ7cjNLThgfm5uR3Gt3/kVyru28a1eORY6V7kvGRK7JR54teP6ERun4R54rrTS0nWMJ BmlYwNJZ4ou2xwmiNErsWnBKF6g9bfsBMoY8c2B/dH1Yui4MSFO0fVyaFYakeYLdz5swLC0SHyGc lf4ve98CVdV1rb2fB+LjhBiKStASagxBNIrGEmPVWEQ4L41V47VUCWfv84oBajzEWEvUGkusNeI1 1hpDvNYaQtEYq1QJGsP1Va4laokaayhXrbFKiVWL1qv4z/mtDRJCR9Nx/3+Mf4x2rDG/M517rrnX mmuuuR7nhJxDfG6fc/kL+xii3Mo5zSCKRybMQ85bB8IKPg+HI1vnIM+J3JPh6Nz6cGzb/OMcdC4c j1xzMdw/93I4Obc5nMJrTytxf/mMhflHfc69FU7NU8KjYJvyR15kOA39tPTz7GFHXnR4Yl5seGpe fDiLc1Fe/3BOXnI4kJcSzs1LDc/h9Q9rIOcn2hPkjQrPy0sLL+B8nOcIL8GZhdbCvInhZXlTwyvz ssJr2F95OeGSvEB4I58T8uaEt7Kf8uaFK1g/b0G4Km9JuDpvWfgQ7wE5/7fm5ryV4dq8NeE6ENnj dYZjO68kfIr9nrcx3JBXFj7PcZa3NdyIHEbjmFcRvoJnVeEbsFEdbuFcnneoQMurLeiSV1cQlXeq ICavoSAu73xBQl5jQWLelYJB7N+8GwXDkMe4/y0FI/gzXysYw/GQ36UgPT+qwJUfUzApP65gWlv8 0B6c9x/5CQUz8hMLjPxBBSHIrZybP6wgP39EQQHGj+ZJ/piC+fnpBYvyXQVFbbHaeg5oXaOIz59U sJx18qcVrGKZpEiyfYl9hST96xuUf6JvUBqlK3e/BzCapVlmrBlv9jeTzRQz1Rw1WTPTTIc5kXCq mWU0i2LGM5k5ZsC4JYqZa84x55kLzCXmMnOlucYsMTeaZebWycvNCrNq8h6z2jxk1pp2q6wE1Zmn zGirNJjnzUbzinnDbPFpvi6+KF+ML86X4Ev0DfIN843wjfGlm0prIQ2Xb5Jvmm+GGSmKz/CFfPmk V4AWcotYk5/x++gNfM/fvYxiO/P/yj2om+bGBCr34R60B+5B78c96FdwDxojBaSQ1FOaRSUWt6EP 4Da0D25Dv4rb0Hjchj6I29Cv4Ta0H25DH8Jt6MO4DU3EbegjuA1Nwm3oANyGJtOcOywNkmqpDMFt aApuQ4fiNvQx3IYOlz6V/ih9XbpEZQTuRJ/Aneg3cCc6GneiY3An+iTuRL8p95X7Smm4Ex2HO9F0 3ImOx51oBu5EM3En6sCdqBN3oi75+/JLkkdeKC+UnsKd6CTciX4Ld6JTcBs6lWb6r6Sn5V3yLmk6 7kS/jTvR7+BOdKa2VPuRlI2/NJij7dR2SQbN6wOST7ug/VEK0PxtJl/K0lyp8G6seqnH3uPe094z 3gveJirXvDfJ8Tajm9HD6GX0RfEZs4zZxlyjkMpiY6mxwlhtrDM2GKXGFpR+RpIx2BhujEQZC8ww PISTjelGNheOG2UAxc1AK2564P0cMQqN0cMUPRwrGvk/haKHY8WGWImgSBlHMcR35vdQdEynGOL4 6Ir46IZ78u7Ur2cpkjgaoigWiimeOA56UBRsonjiCIiW3qXyFURADCKgJ43/Popbvg/vTWP+MUUY j/oDGPU43IH3oZG/KPXFGMfLUTTGD2J0EzCuX8OI9pNnytnSQxjRh2lE86VEuYBGNAm33APkZTSK yRjFgRjFQbjTflT+lbxTGizJkcMjR7YbjyTtPm9Sx2LMMxZ4B3uHtxajv3ekVcZ2LMYSb4bXI4qx zDvZO9lYSZIOxVhjlHinU8mm4uNibMTnLO/s1mKUeed+sRhbYWGut9Aqi0UxKrxLvUuNKsIVXyxG tXe1d11b2cC6Vim1ypaOJbgluN273VvZWnyXvXutcqBjCVZ6D7e+K7jXe4zKBpJ0KOYwb7P3JBV+ Xz2XQKJhp89zqIFiNn3RuvdAIB0WDrR61ntRlOAB72Xv5WApYfMXS/Aw9e9WW/EYSluJFKUTTx0y ag27Ed1W6oxYlFN3PdFajAYj3ujfWjDi543kDqWR6IqRgpJK5YYlbzE1wlFtPfJ4C80uRtoXixll OMwYY6IxlYsZZ2SJYiYYuSTJMXLMRCOnnZ22Yg7yXjQCbSXXmNNahPe99TQiFN/mCMRuhjnGTOcY M13sCXMSx4c5jbgZ6G2yaZghtCiEvgpLHCnHMEqHgyeD9YiGc/D+RXi60cynuTOY/DfcO9Is8Jaa 88nLdnMRta/IXE6xnG2uonifa641FHM9xfKKnCJzk5FK711OcbKYdMvNbeZO7y1zj7nPrKEWc/yv MI+gl9k0Yoe8i83jpOExT5tnyBbPWvQImmKu8Ogu9k42L1D7m6jP10i+lPSG06xbat4kbrA5wyd5 R/psvm6+Hr5evr6+fpjLk0XxJfkG83z1DfeNpDLWl0GzdZaYsT6PbzLeRm/yTfcu9mXznPSRZdKc 5Zvtm+sr9C32rvYtteYfz8BS3wrfLIo1O+Itlp6uNhxGqm+dEevb4Cv1bTGyfNtpfGm0zOW+St9e 3wHyXLKRRm1abdT6DvuOkfZJKvVGiq8SEci9xFixHhWKGPaS7xzRRSON5vAKXzPJ5/hu+RVfvT/S T+/2R/tj/fH+/v5k8nXIn8Lx7k/1j/Kn+R3+iRzj5FmMuX+qmUjRlurP8s3y51AJ+HONUVzo2Rx/ in8e9cBhTKUnC4ws/xKOU8Ic/zL/Sv8af4mvn3+j96K/zAj4t1I85nLf/BX+KnpnDkXoHO5f8LJ3 e7A5YFBm2Bu8ReNTT/1Jo3hZEVJCkZQFSkN2yhQHfKv9jaFoby9vZU6Nf2IoNhTP85pihrwV6h9K DqX4SkOpoVEUoZw5mimbsXdKg5XBSqHhXRE4EkojW5zvEMHQFFmGIphsHQs5vKtDE71bQlO9BwyF 9CqpPZdDWcRt92eFcrx7zRH+lMCIUCCUG5qDLGhlstC8IDKrPzV4LHgstCC0hPLcOZHrQstCK/E2 elNojfdiqISzGeHlUEloY6gstDUQE6KM7s8SmQu5KzJ4MVQVWmZkhaq5Jf5qGieOnSz/IX8tx48o 5nJq9wF/Heck/yka4wZjIo3OeYqrZMoHyf5G8vVG/xVjlP+Gv8XrCWgByjvec4GoQExOTU5NII5G cCPFzWXv3EBCIDEwKDAsMCIwxsjx1bPfvduN1EB6wOW9HJgUmOY7F5hBs2cpJZiQkUvvr6f18Xxg DM1gO+WsHHqSHygIzDdiA4sCRYHlgVXeQiMysDawPrDJeyxQHtgW2GnYA3vIqj2wL1DjPUmW6wNH qE12asvxwOnAmcCFQFPgGrXxMNmO9F4mzZtBKWjzLg12o2zTg+aSh+KmF9VJplhJDfal+G0M9vNu CST6G/2N5nJ/g7fedyyYFBwc7Ed+UILDgyODY32HgxlBT3BycHowO+gLZhgO+pzlaw7ODs4l7cLA cn9tcHFwqTEnuCK4OrguuCGwPFhqGthNDfzXCfOf6IQZkPLxq4YY/r/JZJdK8jOKFJ29kUoZla1U KqhUZVdNp5JdnV098+TMk9mHqNRm10JWR+UUFZY1UDlPhepNa5rWlN1I5Uo2n2EVu8c+gd4RhRON hBONgrOMij2vhrOMjlOMDXveCJxiInGKuQcnl644uXTDnteOPe+92PNG4cxyH04r90tylBGViz7h d4fZwyQ520WfI+hzknZfxqbs9C9DDgd9lhNt+xu0U5AjS1DGni9J+4hqOqEjghxz6PP4lyPHAvo8 bdEZiy4IyqwXn441RCXENxFd+yI5yujz5t8nRwVRFdmVLLIRdfs8oW8dKLNHB+r1D1Bfon6dUFIn dpkGd6DhX4485PfMkURj/wZlCPIcF5Tp+ZI0mWh6J5QtyEPjlun7cuShsc2cZdFsi+YK8lwQn+4G +jxGVEi0+IvkoRjIXPr3yXPNsrHCotVE6zrQhk6otANt+QdoO1FlJ7SX6EAndLgDHfty5DhPnyez MT86JXrmaCS6Yumd+5J0kehyJ3TSstlCn81fjpwafd66Sw7lLrXpRFmfMURx9Czy7rvakzPBer/9 75MzkWjQ5+s7ojtQbCfEdYfRZzx9jrA+x3Tenr9Fjv5EyZ1QClFqJzTq8+RMb5e/2+fb1nxp5TGn K7stvzgnZX8+f7TGSftxtfzd5qNp7Xw74/Ntassp7XNA6xy25havGa0xP6FXh5huFs+dBlGIKF/k CF5fnPOFnPvkXERUJPJrNo8X5UnnKqK1Yg1wrrfy+00R707ySWt+dtKa5twm+uvcafmBbHK+ZJsg tkvj6aS86CTfOakNTrZ7wfKv5U+ui3WydQ07087PZMclCRv8zEXrhaub1a6O49RhjNrWlNZxKhJr o6uHaJurV7v6N0Vf8O9t1tpH/3b1tWTl7WhnJ9RxXT7SCR1vt762W2PbqKkddVhf29bL/8062Tf7 82thUvbdNbDdeteWs4hcY61PWrdcHmuOUf5w0ZrkojXIReuPy2fJaQ7z+oF5my7mk4vWGddskYtc c615Yc2D1rzIscV2OM8hP7XOkSKRt7h+Ww7sOLc6zKvW/NI2t4qs9i+2xnzp3frQp/nmorXJtVq0 20VrkovXoHorJ3EfaA1ybbHq/b0c1DGPd6bT2uZO8nHbs8i79Ddz3d/Lp/Gfpy/kyfa5MqVdjmyX D6Ebb+mkCh9wjp5A8TMhSRDvbXi8eU8zYbAlo1hxpxHPeczav0ygvZGr2cpjNKYTOLYWi3zmZt+z v6w9wYQMK5fx+r/aynMcf7RGTyB7E8iem9o7geJmAtmbQHE2gW1SjE0otPJna77cYu3NWvdNs+/m UdiybKCNi0W+RLs65uEOObhtD9Oah7mfbIufUUxNWNGu/lKrP8OFv7Dnor5NWG3JRrajjE6o414w uxOy/NpxX9dGhe2o476udY/2v9mbbc/+/P5rb/bdfVf7PVa2VbeynU86zi2af67D2V+YV65j2W17 LBfP63qRi9ry1TkR166LVjy1ylmn2Yo//qS84rbmnZvmmNsuqP18c0eLHOGOFfHp7t/JPobInWxR iiDkQbafan2OujsHeU64aa1zT2w3/0jPPVXMNzet0e4cooBYe1oJ+ahM+In77M4lmmPZpn6451n9 tPTddKZzLyFaRrQyG7nIvYaIznDujURlYv1jQp6kPYF7K1GFyMfuKhGnvBa6q4kOEdVa/qojOiXO Ce7zwk/uRqHvprXDfYOoRewBOf+35mYPrQGeLoLYHtYZim1PlPC7h/agnjgRZ54E4UceR0+i9WyQ ZWOYyOUe2iN6aH/o4dxD+zEP7cM8tK/y0H7KYwj/ekJWHqP+e/KtzwIRDx7aC3loD+ShNcKz/G78 cO7m/YCH9kIe2gt51ltyK+d6aD/gKRf2eZ54yEce2gN49rSL1dZzQOsaRbxnn9Dx1AgZ/xqje3X3 /f/6NcY/012ZlqTt429UlRrpHUmKiCfqT5RMlEKUSjSq3WcakYNoItFUoiyiHKIAUS7RHKJ5RAuI lhAtI1pJtIaohGgjUZlFW4kqiKqIqokOEdUS1RGdImogOm+9s/FvfF4humER67dIUqQm5JFdiKKs tjVan9SHyBiiOKIEIW/7TCQaJNoaOexunyNHEI0hSidyCTuRk8T7IqcRzSAyLHmIKJ+oQNiNnE+0 iKiIaDnRKqK1ROuJNhGVW5/b2n226u8k2mN9rrfq7Wn3fB9RDdERouNEp4nO3P1k/0ReIGr6Bz5b fXFN+PEfJYxBe5ooiO1jvBos3Qsd6Kb43863frbWb7V7j42omzXeJL+nx93Pe3oR9ZXecWY4Pc7J zunObKcPNMs52znXWehc7FzqXOFc7Vzn3OAsdW5xbndWOvc6DzgPO49ROemsd55zXnRedjY7b7kU V6TL7op2xYLiXf3x72QqKa5UolGuNJfDNdE11bnCleUsdeW4Aq5c0BzXPNcC1xLXMtdK1xpXiWuj q8y1lf5d4apyVbsOuWpdda5TrgbXeVej64rrhqvFrbm7uKPcMe44d4I70T3IPcw9wj3Gne528XOS T3JPc89wG+6QO99d4J7vXgQqci93r+qU1rrXuzc5Z7nLrbKNSmf8Tip73PvcNcQfscpx92nQGSoX qDS5r7lveiSPDdTN04PWhN6d/sUFyfqLC5H4iwtd8BcXuuEvLtjxFxei8BcXeuAvLkTjLy7E4C8u 9MTfWuhtj7cPkR6wD7WnSQPtXntAGm2fZf+uNM4+x/6i5LQX2l+SnrIvtr8sfctebH9PmmLfbd8j LbAfsl+SFuGvL2z6/7hlstxDzsfvVSr5/yafkGIRZZaEURalWeRoxzPRrEmYavGsl2XxORYFLKKs m0BZN4GybgJl3YQllu4yS59lK9v9e431WWLRxnbvLLP+vVUa4KihcsRx3HHacYbKBeAZRxOVa46b Tslpc3YTxVHj7OHs5ezr7EfSJJL3dQ52DneccY50jqU5iVnpuEbz0uPMprG6F39pQ8Lf2FDwNzZU e4o9RdLs4+zpkm7PtLulCPy9jW72mfYcGoeg/Vmpj322/Xkp3j7P/n0pwb7I/gOpv73KXiUl2t+3 vy89Ym+0N0pJ/4+tyy3f1r5JOJ2iQ27pCr4L+CHgh4AfqmUQDtPnQJ4D+U/ALyNM0d8FnwFe1B0C fiLqPko4CPJhWi7scN0U2M/ShjLq3+bfPunziI/WxjLqYcJt0HmT33sb/O3daMMiyJ8FPxT8UPDD RGstnAf8LnTI5u3/1gYQNlg9GoCn30ar0FPtcfQriJYHmFdPgo/EUwm13obkOdR1QnIv+NGo+wKs 3YuWjAbq0BkOHR/hYPCDwadoIyAPgR8OC5ADh+JpCp5+XXuCUX8WLRkBTeaHqlegI/ywDNaqYI3H 4lGtFHKBqcBJ0DFgswI2yRvKU/xGZaCeTfiyTrNbKQA/GnhSn01YyDqyAnwN+minIjGqPmi+pnsJ N8HmfSyRTzAvX8XTYuiPg/6r4KNh7SqwAfo3tf8iuaLtJ5yk1fFbmJc/g8SnnSAcyTpSM6PsAP4V uJtRVaGZCTtTWF8+Cwul4Dfj6Xjo34F+EvjzwGrgDuhf0vJI06X/J/E3OG4Vm/4+8S0sl3P0GsIz GkWCEss60iV9IeFfGOXzloRQTYGdWGAc6prAYmBP7Q6ePkP8h4zKafBVwCPA17QsHiPbJWAFsAxY BGxijOhF7xomRhCaL9v4b6jkgB8N7G5hGbAIyHV7QnMfnm6F5CQkhZCsF+POPGEFsAxYBGwCsn4m NOejliRQ/ylHBfjX0PJN4CuBmyxJGbAI2ARMo77s1YsQRQFGvP0E8CrqFltYASwDFgHZQjG88Srr qGuAr6LNV4ENsNPAbZYv6YcJrwEv6W8A84EzgYgEvZEs9MR43YBmA/CihQsRA9UcG5C0wEILLLTA Qgui4gyenoHkjCWpJFTRlwf1fYiZw8B84EzgUUZEQoOIMeYp0tjaUfCXaE/PbSCJMsJC6otykKNU iYMkDpI4zO44tky4H1iJyCynPs4T8QnLK4DFVl2eF88j5nvy/4mb3vUGMB84E7gf2Ahkm6dR9zS8 cQTWjoB/DfybFrL3atDOpyLYWneBItLAbxKov4eRzcc48tOr4C/ZvsEeFsitkiChMy1jLORHMLJH INmGOdIfGI8sNAT57WVbIuFLkH+KXHQN/EpeQeQ/IKd1F/mQNeUuup/wfmSzxcCe8MYW6CRjLnwE /ilgqZUDaX2RYV+JYLQd5dG3/Yi9oSOXatnsE9tO5m3JzKsXENuliJMURO9h1Nqpb+O62ha0ip+G RD63ceYcwEhzsw5zqg7ziGfHQ+CL8fQPVh+fR3t8qPsL6P8CfkaG0S+wfxgpVzOK8Rpoo/VRKYB+ d/D7oF9oZY8y5IEiXh0wB32Qvwa8D/gQ3nICeCcig0czohzv5afjeJRp5jIfbSHbfMzKySXE90JM HoUkHnjK9gCPL/Ltm4jnp5G3t3MW1Y8hJo+wpp6I2ItkCY0dx3A053P5sJjFdFamFQHjcow9THmg EjFWiVkpcD/mSyVwP1YQztWxXJf8+T5qLcQMWog45LeEuVVqJj9VM0VW0WivIvfBHB+LWjtt15Ef WD+VW0uRzJLzPNMpwj/ilQUtT7Hyz0Jo8ls2AouB1baHmbf9GDN3Aq8ymLmn8bTKQjFDmZ9sG4Cn jZA0ov3s4eG2o5zr0No3eDWUf4M1MRatvQ35u/B5H/Dx6MsZ3ikpEzW2X6vZCS/w7lHpzUjjtRBZ hUdtLfpYwnNNHYJ18BFGNV4jifJrWH4dmldh+ffgfw9+POwfZs8TsmUH2pzLKG0FfxH4tN5F4n0F 238CI5UEC7Vi/eV9FO0TnkH24whfit3LRS2EXnC8fQ1P16LlR/Gu3bAWyz3Vfsve0OET7TrGt4DX dzWGrakfMa89AT4d/W1CL64jV1zHTIxFO5HtlSpuoToMfb/Hai23JAF8skZ7V/kgev0rjXaD8hi0 7RDqItqVEdosnuOoNZn3wMpk9U+Eq7RxZHkUxnG7ZnB8Kq8TXwdrn1rI1t6EncdgM0XTCM8yUtT1 kXhXRh5QI+CHt1BrNnAFYuCCxt7bAguJwJ/Ajgd8GH1/A34eiz6GUOtT4GlgkD1GuyzuxSLetRJ/ D0cF1qDnYC0H7ZwMOzZ9NWcAKxq5d++hPTdt/Rj1q8CPgLshTwA6OCeIPSdrKoOBI/QTWEeYTxe7 UNg5CjwIOwdh5yDs/A76Puj7WKLkQzISEo/YtTIvNXNLCD8C7oY8ATzrdxc7W7xlt0DsozJhJ5Pr KlPATxE82yHcDXkCsA8kcYgf7Ddg8yysXQOWAjcDyzVeAcfD5njYHA+b42FzPGyOh5fGs2U1iTXV JHigGhaqwe8Av4N7QV4tQfsZfyn6yzy1rQR2SlDrKiywJBXtvG5hDWYWt2GS/ihmK4/OQo13m3ut 0wG/Zb92HHMWpwPWlMRO/hz29r1xCsgA/hrWesN+M/A4sBx1pwHTUXcn5J8CD2sUpbYE7petjFEL sY5Wq++imY532WbrvE5lwVf58MBfoW9nr9rKMK+HoLVHESdngSusc8oJjM4BxOQJjNoJeAbxybOM PNCfR0rvSbgOZyIFmn2heRT8Yrx9pIg3jMXbLFFVjJQKeSb0zwKvA0uBB7CTL7Wdx1tYcofHhcaX +fMWYqzB7xSRwxKKBAdG0IERp3O0tFj9LZ0rPXpXRhudW29/yDPx9oc6jbL6OnZKNewT7XFedzST efVd4L9DXsr7Me1NZEXo096Y90VfRV0n9kXPQvMDPm9qBzlLqzg/qlP4vKxF4ekvUevnjBEPQB4D C7eA5dDPRpwU8lioO9i3aj348cChjFo8j5GWgNgogv77iKiPGfWN0BmKqIhlTfUVjOyfwIfw9BE8 7YVoSYMFcVYtB2bgXaOxK3gTK2A6e0w9ixWkCLlxH1aNA7w/UddjR7oca9AG7A/nQ/IydjVNsLMH WAf8CPgx7JwD1gJfwNr0MdbZnYz6B+ALgbuQXZuxBv2Q92/aAOziPrb4CmAZsAjYxE/55KVfhP8z odkN+Ljt3wjFiQwnRHWXhWXAIiBbeBeac1FrB0sIWTKRJfoMREUW9rovAJ3AfOwMZ2P/mY4zKXaw Wn/Ez3t4FzTVIs6lGiSE3IsLsPyQhRXAMmARkKzpj/CZ1PY+YuagHkO1usLaeqAXiPOpFo2+vwi+ wsIKYBmwCE+5Xy+yr7TdzEf0sf0UOI3to5ZmIfsHZwS1nP2gjsaub76FbwDzgTOBiCXeudm6YNy/ A810zo36Q/pB4j/TPyD8KeTHLcwHzgTuBz7K8YanByA5AMkrvNdV3+EZKn8fe+m+wG8AX8DeMh7n oMexd03Grng5IuoFROxy3gcq6bD8S/Av4vS6HW37BPJP2I7mRPvrWaI9YOEbwHzgTCDPr4e5VdpX +Qxre0vEPM8I5RysdQWuxw5hAeZRNPYP30X8r8PTjy18A5gPnAncDx3yp/Ygv0X/gO8VCVlnF2rt Ah8NDzTDS6f0MsyFvvxUIE6s5/nEql1gib6bW6JVgP8MvIY40aA/X7+EURDIp9cP+fRK3uCoqNUW oG0csRL4XWj5LjwVWXQUsKseTSjxeOm9bU8Rv4Hl+oOI5E+AL1q5lDNPFXJpMXSWQv9tzLg/YR51 RUZNRQZeC/49zsAUV1RL34txOQCbOL2qK2H5OVgbAL6Cz790wuWn+dCsYozczREeKeG09RNYxp1J hMj2/4XTTRFm6EXMoB2YHY8BcTpWN8PCW7AmaS9TrSrY+RW3TcM9lYYTMY0Fr6EmzsLPM08WmoB1 mNdNwDrM1iZgHVr7S+J/jDfuhJdu8R5AfR3Z6SBQQ9ve4zOy9jPgHEYVNydqjW0Jr3eYxcXgd0D/ TdT9MWZ6EUtsAc4Gtmch/wD6DcApwPW2ZsaI6bzSQefnHDkRD4CPAQ6FtVvQX4U2d+HVQevB91Ta o3os4od5hdumN/Loaz0wd+aL8ybioVw/xHHCcu2sdabmG8synHEex7wez2tERAbG7iOM1BPM27ro 3enpDaxZu/hETNHLOSGNn0ZkYGVZz7OJ8lUlcD/yUiWQ11AH7pEGQF4PeT3kn0F+DvKPIc+CtU/w FnHymo+VsQ64i9+rN3CPbLiPVbfhxL0Ba9wa1lf+k8/XlOVmwsPX0WbOS4/zWdvWHbO+CbN7DyN5 8jDyzKNoCWMtnnbFvqgr73woH97GXHgDGYOfFgKLrOzBtU4gb7zP527SWQv5WrQf+cr2EvEVaPM4 7QHC/2DU4uH/rejp7zA6BdB52tJkSV+cg37NfdTu4zOyiltlVZzaTuLUdgg5+XvwQxzGfSDOZT9F tPTSKRfZIlHrOnYI7/B5XA9pdLLQliPH5qJuLuouA1/K71K+jjfmYFzexKnfQI9+iBNuHWaEBsmP +VSuDUA7vw39y3gjWqUvBj+fz+ZqHnih8xwsDAd+h/dLtG/kWblL68nrAlr4KeJcnKafRCSMR98f VauoX9PZjm0OcB6jtl7bjMzJM+KbzOtz9bloFftzMnTE9x27kc10fqo+z6uYLsNOFPy/Cy38OZ+7 1VPgP+PTujoE/Hg+rau/QF/u5ZbomEHa01pvkpSg/QvUzwhfUikStIv8LY/tZ9gTPsOndeodt+cB PrOrS2HzeQvZh92BT/M5Xd8F/Dc+R6j/w323xcADDpzBz6BWNp/T1a+A34On19CeP6KF2yD/M77L iGfP2BLx9lHAmejvLOBwa2/Jq2pv1DrMJ3flt3xyV38I//TG/WEDWvgM0IHReQXj6ORRo+glVDZD Eod2rsUpphg4WvA4oRRjrhXjpFPMpyp6SicR/WHsqPdC8wfAHfrLyIfM24FOgbDghAUnLIyHZhPO egNYog2A5AQkazUacRl1lX7AJTgvfwvn5W/hFPY4znc/5bMSRQLpKwFofow3xmD/ORDWBnJdLQ38 QoGQLGRrhLshTwD2wcpOntGPonchjU6F6jrYfBz2Re9GAb/HZ09qP3oBmwNgcwB62oSeNrGvtKfZ si1NPwb8AUcRLGwVCP/kgM+AH0bbXPAV4wSc30/x+Z164eK7L+0o3uvCDPodLFyFNRevVtwqyjyM r2sPEc7QFpF8LjIqzst0vuanrwDjIBmlLSY+X+O2DYQE+Vbrg7H4E/DPjGoNo17LqA0ELuS6+iC8 5SuwmQkcAdwIa0XCV7DwGTARHn4R+BxnvIiD7IFID/x5A+e+Z3FL/xzzETases/wU/1heLgGmmng TeYjDrK1SA/vTPQWnAcfR79EbKRilNMwLuvAR8PCSOj8gu8H1Gz2vxaLUdiK2HiQVzH1PPdO3Qw+ CnwhdOqBA1ErARiN0YzhuvoGHnF9I+RDofkWRvkV5pU/QfK4bThwFccbNHvzaFKcvIwcyHgENsvB P4Q2R8OH32M5ad5Aa29ghuKb+jtvS7Kk3vk1+M38XTYw5c5b4B8BFvG35NbTt4EboD8PvMBewGLI Rd0t4LfAWjnwE0g+AX8SOiRXnrrDN6IDgS8DC4CjgSeBhYyywihdgyQFKDGqPvCvATcB77N4/tbg BOpehaQYOA61XgUfjacNwJuQ4C3KJEg+Ay/sj8Tbm4Ef4+lfgbthTYVOJnAK5GctnttQCslmSMaD v4NaSeDPA6uBO4CXoOkCfwO8DXwLsBfwTEsS7wzRHuhLf2GJKjwTB4xliYxey08DP4T8NPgq4BHo CO891fIkWRgmxoJ5ZTSwBLhejAL4FKAEfA24qYV3p3uF/1kivwO8iqe/geU1onfgewrPQ6cFOg+K vkDSgFadB3/U6suT6Fck1Z2HuvNZIsE/8kvQTGnxoBdr0fK1aO1atI2xGJKrwEuQPMgoCT4OGAs8 hzf2B8YDhwA/xbtEBK4E/wdgbMtYwsng78fILhYxyXJlC/jkFj59fwR+BOSICiWC0YZIs73AqO2C hdvsAdtzzOs1GOtNwjN3XudvG6H/IxEbsLYSbbgOnb/CV0/xrKQ51Qvxz7hCjPLtKzzj0NMCCxVg PGFP4GhgIZ4WwlohS8ifLE+HPAUoWRjP6wL41yxkTQ+8fcLyfDxGoQTI/DiWq6/i6TXUegwtFBF+ DT2C/+VTYkTQ0zdFPIM3oLMdXjomsgf7SquDx8T8jQYfB89UQ7+6ZQzfSoEvgJ0w+DcYVcxiNRMR eAN+K8ZTjKbcB/JL7EP5Ftpsg/di0aNIeKmFkeJK8NxH+Er+EVDE4TMWxqNuCeyw/oeweQxP3wbC n9Jl9Poi8A3gb+7cT3gbfewCybvg+4CPx6hNBF+Lll/A097MU8YoJckYPH0euBZPS+ABRLs6BLyY 6bHsMeURyMWM+DXwdVg2YcGE5eOWl5gXme0w5vU+zNZPMQrIKrIGzz8BOyIT1gL/eGcoexJ8jciB 0FwKza+JHIi3HIUcs09bgLlzEPz1O+OpnWId2YBs8xH7SnsCfDrkTbBzHTwyoXIPcAAwQcxZ6BwE /srKTo8RYqWQD0Fnu5jRQGQAZRW8NAo6dUCRNxC3CtYF8iqdKVTMffkt4GygyBWJwJ8Aw5DPAT8W GEIEvgj529ZawPG8yOLZA2LtyII+coiSI9YUjKYN/u8FLAZ+CKwCIp/L72K87oB/D3gTdY+I8QIP T8qfgfcBPfBSM/jueLobfCZwSksztxDys7C5ArgZWG7NX/EujvyDiPxmzIgpwPGQV4NPhf5CWMO6 I+/H21sQG1gZZWRytTc0dyNawMvNyMbHwZdDPg28yKsYfVsZIioK+ANkGOxPbH1hTWSkKWjtjjvr +DsmWLjT8iP0l1A+ALyJPDwJmWQzcAY0byIPd0NfxDoVbeXVeMQ2Z4aRkIyE90YiqzRD3h1+2G0h 514VmpkWsoVSPN1sYTzWnVnwYTzayXkpHk8PA3eg7kTcMV7DHX4cbhrjbL8kzW7Wr2v41ymp+E3O bdwtP8K/cpQ/ZFTK8P3vfpw9cUMl/0HjX+bsxYkM37YoabauPNPxDU4t88oH4K9oJ3FWxXdevD+X piv9eVz4RkJN0oL8du1nvMdgXmnS/szRyKhe0TZJfL9EmtJpRjmAWhmMehnuNGzAQdp8npuwUKrR vlfNgoVb/NQ2GbUmAYfh9wk3gJFaLI+4+j32mLqPdZhXFvB/4aLMYlTz1XpYI03pEKOcIGpBcoxR a2SkXjBuUH/MvYCdNL5VUA4IO3g6jVFfBAs3gPXApcBtKt/nJDEqVSqf7uP5XK/cgKSHPh3t5F+R dWOJdIx56TQj6TN/iPX1kbATj1qDVf79Xn91DY++ugFtK+c7bdTaBhwBSSLr63tQ65zVEn46DZIS dR5nG8hHWci/I9IsaxvYS2hbBfNyA9qjKjKjfo3/6g14RVFYIu/BU/4F8lD5DH4xy79qm6gsJRzI ty5KlfIqZ13lh9xy5ec8r5lXlihLCAsV/nZbYX25GDiJUX0WOq8p+K2jsoLwUfUVwnfBJ6tvwQ7x 8lVooq4yDnVfBX8/rF3lKJV/j7ffVO7nuaxwVExTeqGdURz/Cr7lV2wkeVK5l+ey8jDPZdaXPcCn GKW/MKoqLGTA2hSlN+dM5UPYZL5ZOcurBvhyaLpgoQV1vwr+PPADmT28HW24KH+NNAfJfMNJeZEk t2T+lvm2fI3XAmUw51VlAb61578se0lu4PYwyk8qMSxRdvLKJf+B11xgHHAQI1kjlM6CXwHsIddD s55nOvjT8jxeTWDzQ3kj4Sr5d7wecUukT2HhL9wS5ZYk8a/QtcuMtmjw/w2+O36d3hX81yF/BxKy o/3H/2HvO6CsKLZ2d1V1nzpzuk8x4IAwIJKzMMCIBEVAREAkq0hScpAkDAMiApJBRCSJZJEkICYU JImEIQfJOYnkzIA4MDOv6uv2Xmb0Pb2/9//XW+/dNWt9vWvXrl1VX+2q6q5zTk9A+7QaA6sCLxsU 54GfGbRd6O8b5BbwPWgKwaaZwcABWBYB1kJuHsgtITeC5VlooLdGGpQ5IRdE7vfARGhQi9gKuQ3k AcC60AwE9jbI0FpeEbmbIZ9EewKw+QC4ALkbIH8J+QqwDvAV6NEjkYyynrdtwEHADsB9sIyFjH6J e6jxDcjr0Z79wIvQfAJvrVGqLCy3QJ8b8mLI08DJMsi9gDOAhVHqY6l3n0B2b3SMbF0GpnpjZGTb heY+5EreGEEz1hspI4tmwJbAbvDW3BsvlJLeqEEGJ4Fr3qjB/jPgWeTmMShzQvM92lYClqOAHT1+ UPszaOEajxOj0XuikT3GwLM1C/gkagTb7AZywSRfCQ+IOns8MAH2M4G7gS8A0WvLi7RpaGc/2OeH B3BuK7QB8cMLIPYiYH8GNgshPw1LL8aqAJXB4EJTNpgZ7RSweQ4elgKjoM+OXhcCM1tgPwG5mCPW XpTKh7rArRjvzTtweABlwa01ElgQfr6GTQz8g09eGWWXQI9ZZnux2h51eTMxpxd78LMdMiz5CJS6 BJtxQC9CwJ7o7kUy6s0NrhYbZDegmYK6vDh8HFgBWA9ld0EuDQ+lgOeAv0I/FHW1gtwAftAvG7Xb ZWA5Gn4mQQbzHOuDNRsYD3wRNl6Ne4BehKxA7utAjIvIhhq7AsG8hMa6hRr7QO+taZiDlje7MXPt DNBkAmJlEIgKAW/cW6mwqvDrsEdZKw74KXA+9N7aCFnshGYj5OOoHXElMHf4TZRC1NnebPJ6tAo2 IdhPhcYb99XQ1wdGA9FmgTUzMBw+vVYhKqwjQMwpC7HB0PJAf5R6C/ZJkDETrb7Ag9BjTAX4t5tC jzXKwqplIR44VnWrLXA57BMRMwMQP956tQCItcjGPBKDoPFWzqso640pxl1gpAKIJdEEiLkmxgAR vXKHwSCiwsb+ZSPaA2Bbou8B5FqwF1ijRDlgHVM7kXkGsT5OMZ8WNQZWBV42KM4DPzNou9DfN8gt 4HvQFIJNM4OBA7AsAqyF3DyQW0JuBMuz0EBvjTQoc0IuiNzvgYnQoBaxFXIbyAOAdaEZCOxtkKG1 vCJyN0M+ifYEYPMBcAFyN0D+EvIVYB3gK9CjRyIZZT1v24CDgB2A+2AZCxn9EvdQ4xuQ16M9+4EX ofkE3lqjVFlYboE+N+TFkKeBk2WQewFnAAujbHaUTYVNJchjkdsNcnPoJRB9CVwDlkDuKGBH4DMo tQb15kALvZajv9Ys4JMoi16zG8hFj/hKlMXo2+OBCbCfCdwNfAHotdAbca9f/YD54QF9txV8Yhx5 AcRABOzPwGYh5Kdh6Y11FSBKBZEbzIx2Ctg8Bw9LgVHInQAZkWnthU0+eAYzAu0XXyM3Bn7ADK8M /RLoEb22FwPt4c2LcC9Wt0MPGz4CmkvIHQfE6HDwILoDp8CbN46PAysA6yF3F+TSKFUKeA74K/RD 4bMV5Abwg5bbqMUuA8vR8DMJMrjimFnWbGA88EXYeDXuAXpjugK5rwPBpMiGGrsCwZ6ExrqFGvtA 760GiF7LmxeIeTsDNJmAmFMC4yjgjXtzHPORX4c9ylpxwE+B86H3VhXIYic0GyEfR+2IBIEI5zdR CnFiezHv9WgVbEKwnwqNN7Kroa8PjAaizQKrTWA4fHqtwrhbR4CYBRZGn6Hlgf4o9RbskyBj7lh9 gQehx5gK8G83hR6z20IkcKyEVlvgctggqi1vJbkK2RspjKYA/wFEiGgCRMyLMUDEntyB+MdY21jP bcRqABxK9CiAXAv2AuuDKGeQjvBDZE5FdujcfN45hhitNdXx3N3WnDaIWThJqIHc6ea3sSKX+X6a mISzFG40/AL0o43efMGCzK8tjKapQXu3Qas49Iko2w255w0GukNuC6wOb1c9S9TbyD/NyEfmjMI8 G06HZoh/4lEcv60zpyg1cX6ShPOQKJyNLIJ+tinLd0HTFrkTIXN4uAqMB85H312DfAAYaGhOSHgC Ti1iIceKpaassaFUnFc85J+faKRTxsYuBT/1UaoqTkjKGw17yJqq9Vn8s5FFOANZhPMQjSljU805 Vd3UHWbthdzIPNvyXUZmz0JujNyqkFdBPgjLvpCDkMsjdx1KXYQmk+cNmtMp5km/GGwyoVQMsCVy 93uI3GjIScj9CB7yQT8H+jKQiyA3ALkd5GFeG4zMDnltQG5vI6fUT72jI6EANF9RNo2HIU83ssiA Z/lUg6Ii8CY0SZAnwfKEQXu3QYtBz4GLkBs0yBIhXwXGwJ5gMxpYBDgYufFow3jILSHPR42XYNMH 8ibkdoKfEPyvBc72W25a0hGaZdCsBI4EoqeiOnIVNANSVuC/sBvPq1PMSWAueO7it8Hoj5oxEhUN 0lGUXQwcA2848eBnoGlobKwCKea7ak8jt3LKPI0pVEvrI2FT0mj4da/N8DzLtCHwCDSrjMzGQF8/ 5UsTn8beWo/c/SZX992MjgvP9aHPCp/vo/3ZU5N0OweitbfRtsOmlN0NfTkL/UxEXT9TipVBXX0g 54GfmJT7+AThvuETONKgvpsyeBKaHLA5CzmTQfEMWhWLUUtAXb3huS1aeNJgwAK3hbwISX3RRJ2x 4ZmMxrx/R6+QmGVWpOlLICvszxrZrgYbF5rGXhyC7RyoxQUzmQxjbCh63SjFnM12QgvnQw6lvGxi LMWcdj4ErI3aE8DGs5BbGkuWiFIxkO/AMgEexkAeBf1+sLEN+gLQ3ELuB9AchrcPoHkaltcM6hUH 4+XFIdpfC305hTacRCR4kTze9Fo/BRwHSxh34ACMVCLsU+ChOOoqj9wYxM9J6Msa1Ou7GZcavo3B M4iB3fC8y+PfZ8O0vCr6chJcZYE+DGwEy05+vfcxL+4j9m4iEjxLw1tOI+vYvolINjbNgWOgeRmW 0agrGpY7UCoBNpOBy5Bb25+/pXRfAmjzEvRxO/Q5gN+jPe09S/S3i9drY6mjCKfWiKiAz+osRDXY MMyw9vA8EevAarC31q/L+CmFkcrirVQodRWl1sIyBdEeA8sliMwoIwfyUAZE2gqMuGn/VG9G+3PE eGuKMcoHfA0tvOyveNmw15hatvlzdpLO/cKby8abXi0nolWlUMpbV43nwTglvkqtEVetzZ6eWk/L LyHqLsIG64Dw5tEolK3NtyLyV2A0TR/XeGsjLPtD3xDMjzeo16UVWCvMquKNyHxgELm50Osq6O9x 4GjgfXiuivGqBMwDrOnbmFWunz+OZmUbZ9ZMHQ8rMJvmISru45Pc+4jV+4jn+xgLI98FbwP8XSwb NKbXk9HTJ71dDGvOVYzOSoMSUSSxy4jzsGwNxB5H100c6nvgY1gDb2INNCtMQ7SzPKI0BjG8C1GN tUhbzoKlsf8c+k6wrA75eehno+X7IS+CvlrKXmA3zL6b5p7c1JIyKfU0xqu+ma0Y0xfQrzzevpay Dp/XZzatRcsHoi+5YFk/Bfc8KJuDcmqf0f7Iajn5M+OZCO95I8v8Tsc/aTRIIehDRk9kNClNzLes Uxqbb8Kn4PcgKSHIJSGXhFzafE87JdZ8l17ru0G/APKr5vtj5pv5Wt4A+Srky0Y2v+LRZZebt9xA H2u+Daj9LMS7WW7j/TYrDZrfERCZ37mnRJlfc6REmd+DpHwV6GTeciPfMW+5MXLyKiOnDAy8b95y I68b/4EzBuU1yEeMf3ke8j3Ink09YGlYtgC2Nu+9MW1LPum1OfAh7GdB9kpdRJsToc8HfaRBWQm9 Kw68hv4ORu4SoIT+CVhWQV2Xod8Cn6WgKQ9mPE0ScpvAfiRq3AKWkoD9UXtlWBZFWWMZAzkGcqnA JujvQi4KP56+AFryEuTCkF+BnwMGgxIy3uQTDCK3CTQj4O078w4ceHgCHkpCLgm5tPm9vLb/EXIW YGaUehZtLoU2t8QoT0NPbyMXbQvMheZV4AZgInIf1lhCfg75C/hcDXkUbL4GjoN+CeTdkG+ZFpq3 cOjWmjgsjc/lRXIqZPBmPklPKZl8wbQnGWNhPnnXmpsmN3mVYdLTpPQH5gKiFDyUTF4PS5RNRq+T p0E+A5/rIO+HfBW5iKjkQ9Ccgx/zDRyiEBsevEii1ZvdO1FUu+5tXqd+nVrEdaGvSD/5NahfJRfp J4vUVMpMLgUoB+WlTFScHqdyVIlq0svUTPuoR2/RO9SKOlBX6knDfPswSXqE8tFDVILKaC+V6Xlq RM11rfWpLw3UK0dH6kbxNBz/Y9Aroyio14z8FEUx9ARVoCp6dX6FXiVODehtGkRt6HV6g3rRCMpC okbdutWpZv06L+Silg3rP5+LJsHLw3hn6KN6bS6gPZakJ+kZeo5eoMb0GgkqQg2pHw2mttSJulNv GokyEZSLCpLZ6Z6iqlSbitK70GelSM1DboqmQtpvaSpLFelZqk51qAm10O0uRi9SfxpC7agz9aA3 aZTfgozkUB7KToW1h1h6mqpRDapLTakl2fQYvUQDaCi1py4UR33Mu0xblerRSrwEbA5sC+wCjAf2 a9WiU5wYChwDnAycDVwMXNaqRY82Yi1wE3AHcC/wMPBkq1adu4mzwESDFgdGAnMCiwHLt+7UoZ1V DVgLWL91l66drUbA5sDWwI7AbsB4YN+23Vu0sgYCRwEnAmcCFwCXAFdrxy2sTcAdwL3Aw5269Oxs nQSeBV4G3gTeBaYYtK1OXVt1skPASGBWYE6d2d3OBywCjAGWAT4JrAKs3tX4qQ1sCGwMfA3YFtgJ 2L1r99Zd7N7AfsDB3Yx+JHAMcCJwKnAWcD5wcQ89RvYS4HLgWuAm4A7g/h4durS1jwJPA88DrwIT gUk9OrfqFiBgCBgFzAksBCzVo0dMycCTwKrAWsCGwKbA1hpLBToB44B9gYOBo4DjNZYOTAXOBi4C LgGuBK7XGBvYBtwNPAg8DjwDvNijZ8segevAO8D7BiUHBoGqR89uPWQUMBqYC1gAWAxYKk4zKcsC KwKrAmsC6wJfApq7ca7Xnqh/4Sr0PM9OOf5LEsOLQ//PaOsVw9arqKTgvy1lIeXJTK966TH8F1Ho dc7BO5f/jsT06v3HmOkvI8eIcO3VpHDaY/YHc5f4lzHjX8ZHfoeRfxlzoaUCV/YAmh48qFN/ikLv VFko678oPQyJ6/0pz790zUv5/qVrfirwL1yZ3kn/HP+cE6Z38D/HDH8JS+q7jTi964+n2bSE1tNe OkOJzGJRLB+LZVVZQ9aaxbHBbDybzZaw9WwvO8MSucVz8lq8Dx/JJ/MFfDnfwg/zizxJhES0KCLK i5qisego+oiRYrJYoOegqSvoxayonS7dMl16VLr06AfSVrr8gJ7mB0myB9Kh2LRpd1ba8upOWv9R jdOmM1Na/5mj0qULpLOvni7dNF06XX8yH06bzlIoXbpuunTvtO3PMTNt/iMr06bzF0uXLv5AWs+/ /DHp8gcizfX6kMnrYcG63rWQ13NLx1wWvVYV8LW7/Oth/3rGv17/I+siX/nXlf41wb/uTtuKoipt L4suT5suMTCtfYmjadMlt6VNl/o2XXpZ2nTphunSL6VLd0uX7p4uPfGBKNNCmUnp0svT2pdJN0q/ y9+RLr0rXXp32lEst0Oj0sy0YhOoLZuK1bal/iM9U8cTsyPtjNgrMlHAraES3OpqvVqj1mpNgF1h V7TddXadGLvJbhJnt9ltEqqyqkyWekY9o/dNEw9cPCuqm/p4Jp5Za8wviJRpjwjrksV1Oot+GulO UymBTlISi9JtCOpWRbn1iLvV3foaa7gNNNbUrY/Ua3Iu/bQQo595nlTnSfBI3aYLuCYo/aTFM+v0 JVwT1H7iOnVQY4I6rHGT7quJ0GjKo07qtq7RuadwTVCn9XWtTv+Ea8IDlmd8y599y7O+5Tnf8rf2 Po/21kJ7X0B7f8upjZw6yKn7YI7aghZuQwt3oIW/5exCzm7k7EUOJ8n1n55mDjff3I7kkZrVzJpV 4VZzn9Osr1FrKKDbtFYzJbSF+TTS2/X11NLlW2C8CCPFWBJL0qOWylI1WzbX9z3wa8NvAH4lj+bR FOR5eB6K4IV4IQqJ6no0Hbul3ZJcu7XdmsJ2W7stKbu93Z4y2N3t7hRpx9lxlNGOt+Mpk8qlctFD Ko/Ko/uUT+WjzKqAKkBZVCGln/lUEVWEsqpiqhhlU8VVcYpWMSoG7+UuTTnU4+pxekQ9oZ6gnKqc KkePqgqqAuVST6mnKLd6Wj2tR8fEW17EWz71nHqO8qtmqhkVUK1UKyqo2qg2VEi1U+2osOqkOlER 1UV10QtFN9WNiqk4FUePqXgVT8VVb9WbSqh+qh/FqAFqAJVUg9VgKqWGqWFUWo1QIyhWjVKj6HE1 Wo2mMuoD9QE9ocapcVRWTVATqJz6UH1I5dVH6iOqoKaoKTo+p6lp9JSaoWZQRfWx+pieVp+oT6iS mqPmUGU1T82jKupT9Sk9oxaqhVRVfaY+o2fVF+oLqqa+Ul/Rc2qJWkLV1bfqW6qhlqllVFMtV8vp ebVKraJaGO8XMN61dayspzo6VhKortqko6We2qKjq77apqOrgdqho6uh2qWj6kW1W0fVS2qvjqqX 1X49Rxqpg3qOvKIO6znSWB1Xx6kJ3ondVF1T16iZuqFuUHN1S92iV9VtdZvMe74H6vkxUEdSBpaB +rNo9ggNwH9GHcwas6Y0hHVinWk4/hvqSPYGi6N32Ug2kt5nk9hHNIbdYDdoLLvD7tA4do/do/Fm kaEJPMADNJG73KUPeUaekSbxLDwLfcSz8+w0mefleWkKL8wL01Qew+vSNB7He9Jq3ov3ojX6PqIP /cDf5v1oLR/MB9N6PowPow18PB9PCfxD/iFt5LP5Adokwnr9uS9iRSyliCqiKqWKGqIG42KamMaE FWd9zCy7ld2KlbLb2G1Yabud3Y7F2h3sDuxxu4fdg5Wxe9o92RN2L7sXK2vvCQxn5UINQi3YtdAw h7EUN9J9lr/pNnGn88/DrcMd+a1w//AonqS4Coqgyq1yiwwqr8orIlV+lV9kVAVVQZFJFVaFxUOq qCoqotRj6jGRWZVQJUQWVVKVFA+rWBUrsqoyqozIpsqqsiJalVflRXb1pHpS5FAVVUXxiKqkKomc qoqqIh5VVVVVkUtVV9VFbtVcNRd5zD+nFnlVW9VW5FPtVXuRX3VWnUUB1VV1FQXVG+oNUUj1VD1F YdVL9RJF1JvqTVFU9Vf9RTH1jnpHPKaGqCGiuBquhosSaqQaKWLUe+o9UVK9r94XpdRYNVaUVuPV eBGrJqqJ4nE1SU0SZdRkNVk8oaaqqaKsmq6mi3JqppopyqtZapaooGar2eJJNVfNFU+p+Wq+qKgW qAXiabVILRKV1GK1WFRWX6ovRRX1tfpaPKO+Ud+IqmqpWiqeVd+p70Q1tUKtEM+p1Wq1qK5+UD+I GmqdWidqqg1qg3hebVQbRS21WW0WL6itaquorbar7aKO2ql2irrqR/WjqKf2qD2ivtqn9okG6oA6 IBqqQ+qQeFEdUUfES+qEOiFeVlfUFdFIXVfXxSvqpropGqtElSiaqDvqF9HUf5Yydz6xWGsL63C2 WTPWTKvbsDbErKXWUuKB5EAyiWDFYEU9e/49q7GO3P+sxv+fr8b/jL5oRF8Rc7fFOgSO/CfG/hNj /6YYY3ZHfT8fyfLwWFHNakQ5qDxVoZpUnxrr54WO+v69j74fGEljaTLNogX0FS2ntbSFdtNhOk0X 6aa+sycWYG5EbxIRPSLiIt7EtWdEH1zjI97CtVfE2/oap6V+uMZF9Me1Z8QAXOMj3sG1V8Qgfe2p 7QbjGhcxBNeeEUNxjY8YhmuviBH6Gq/tRuIaF/Eurj0jRuEaH/Eerr0i3tfXXtpuDK5xER/g2jNi LK7xEeNw7RXRl7jOHaixZ8RwjfERozX2+huMTEDPe0RM9Jn50Gdmks/MRz4zk31mpviMTPUZmeYz MsNnZKbPyMc+I7N8Rj7xGZnjMzLXZ2Sez8h8n5FPfUYW+ows8hn5zGdksc/I5z4j43X/e0RMByOz wciCv8nIlz4jX/mMfO0zssRn5BufkaU+I8v8WPnOZ2a5z8wKn5mVPjOrfGZW+4x87zPyg8/IWp+R dT4j631GNviMbPQZ2eQzstlnZIvPyFafkS/AyLeIlDVgJOFvMrLdZ2SHz8hOn5FdPiM/+ozs8RnZ 6zOyz2dkv8/IAZ+RQz4jh31GjvixctRn5pjPzHGfmRM+Myd9Zk75jPzkM3LGZ+Rnn5GzPiPnfEa2 gZHdYOQgIuX032Tkgs/IRZ+RSz4jl31GrviMXPMZue4zcsNn5KbPyC2fkds+I3d8Rn7xGbnrM/Kr z8g9n5H7PiPJPiMpfqykesyEyGMmxDxmQtxjJiR8Zs6DkatgJBGMJJlIMf+n0bQbp2mNqDDbzWeI WqKOaCvaiY7iddFD9BS9xJvibTFcjBAjxbtilHhPP7ucFj+JM+JncVacE+fFBXFRXBKXxRVxVVwT 18UNcVPcEonidriM+T9KbBfbpSuYbn6dK54XzxMXtUVtEqK1aEOWaC86UEB0F90pKOJEHEWIeBGv 7wR6i97kiL6iL7minxhEYTFFTKGHxHKxnaLCj4cfxylDNIWsnNajVi4rt5XHymvls/JbBayCpme6 Rbdxus4o6wNnE0VxHtTJWOiSBX2LHA9YFHsgTzMpOmlrsqIs8y6wQlYhcvx6o6zMVhbrYSurlc2K Nu++0xb/rJdTPspgZbIesmwrYEkraEVYIcuxXCtsKSuDFWmZ8y5L962/boIpw62nrIrkWpWtyqR0 XhnKKuaK+WKR+FysFxtEgtgoNonNYovYKraJ7X/EuDktE3PEHO1xnvlds1goFmq+Fwu9jmrm1un6 TotL//A+R1st1LnLxQqxUqwSq8X3Yo34QawV6/5ojOF9rpirvc8X8803MsUi7f1zoVdn3cLt2rvp h/FenKL+0Osf9AOcnfY5M+X+YnShnIkGXc7uwpfQIBpMQ2goDaPhNELP63dpFP676Ps0hj7Qs3wc jacJNJE+pEn0kZ7zU2gqTaPpNINm0sd6BfiEZtMcmkvzaD59qteDhbSIPqPF9Dl9QV/q1eFrWkLf 0Le0lJbRd3qtWEEraRWtpu9pDf2gV451tJ42UAJtpE20Wa8jW2kbbacdtJN20Y96VdlDe2kf7acD dJAO6TXmCB2lY3ScTtBJOqVXnJ/oDP1MZ+kcnacLev25RJfpCl2la3SdbujV6BYl0m26Q7/QXfqV kuge3adkSqFUHdCM1+P1eQPekL/IX+Iv80b8Fd6YN+FNeTPenL/KX+MteEveirfmbXhb3o635x14 R/4678Q78y68K+/G3+Az+UF+iB/mR/hRfowf5yf4SX6Kn+Y/8TP8Z36Wn+Pn+QV+kV/il0WIX+FX hcOv8ev8Br/Jb/FEfpvf4b/wu/xXnsTv8fs8mafwVL0EmW/bC2EJWwSEFEERIeqJ+qKBaCiaimbi NdFCdBZviMFiiBgqholx4iMxVXwhvhRfiyVimfhO7BA7xS7xo9gt9oi9Yp/YLw6Ig+KQOCyOiKPi mDguToiT4pRVwXrS/N9Wa6+1z9pvHbAOWoesw9YR66h1zDpunbBOWqes09ZP1hnrZ+usdc46b12w LlqXrMvWFeuqdc26bt2wblq3rETrtnXH+sW6a/1qJVn3rPtWspVipdphO5OsLKvIZ2RV+aysJp+T 1WUNWVM+L2vJF2RtWUfWlfVkfdlANpQvypfky7KRfEU2lk1kU9lMNpevytdkC9lSttJ/bfRfO/3X QXaUr8tOsrPsIrvKbvIN2V32kHGyp4yXvWRv+abso//6yrdlP9lfDpDvyIFykBwsh8ihcpgcLkfI kfJdOUq+J0fL9+UY+YEcK8fJ8XKCnCg/lJPkR3KynCKnymlyupwhZ8qP5Sz5iZwtF8pF8jO5WH4u v5Bfyq/k13KJ/EZ+a/73q/xOLpcr5Eq5Sq6W38s18ge5Vq6T6+UGmSA3yk1ys9wit8ptcrvcIXfK XfJHuVvukXvlPrlfHpAH5SF5WB6RR+UxeVyekCflKXla/iTPyJ/lWXlOnpcX5EV5SV6WV+RVeU1e lzfkTXlX/iqT5D15XybLFJkapCCTc+RcOU/Ol5/KBfKWTJS35R35S6h36M1Qn9Bbob6ht0P9Qv1D A0LvhAaGBoUGh4aEhjpvOX2dt51+Tn9ngPOOM9AZ5Ax2hjrDnOHOCGek864zynnPGe2874xxJjtT nKnONGe6M8OZ6XzszHI+cWY7c5y5zjxnvvOps8BZ6HzmLHY+d75wvnS+cr52ljjfON87a5wfnLXO Ome9s8FJcLY4W53tzg5np7PL+dHZ7exx9jr7nP3OQeeU85Pzs3POueBccq45N5xbTqJz27nj/OLc dX51kpx7zn0nxUl1yWUud4VrubYbcH9yz7g/u2fdc+5594J70b3kXnavuFfda+5194Z7073lJrq3 3TvuL+5d91c3yb3n3neT3RQ3NUxhFuZhEbbCdjgQluFgOCIcCjthNxwOq3CGcGQ4YzhT+KFwVDhz OEv44XDWcLZwdDh7OEf4kXDO8KPhXOHc4TzhvOF84fzhAuEp4anhaeHp4RnhmeGPw7PCn4Rnh+eE 54bnhefj02ecyOJktD+fwfUKivPOj0VNvb/vEy/o/f2AaCya0CHRXLxKR7CHHhPdRDc6rne8d+iE GCvG0k9ikphEZ7Cz/4x96yz2rXPYt85j37ogvhVL6SJ2iMtWOas8I5ybcjtkh1iMHWlHspI4GS0V OBU4y87LGBnLruKU9FZoWGgK56E5oe/5w6HNobu8FM5KW+KUdK7e7W9ShL47yKP3/Nr6Dmiy3gFW 69VZV+EMIa42Q1oEyXxGE0lZKIezUacPOJs0HnI2azzibPuH7QEt/UBBfS+RlXLqO4Ai3qdHziGj d45o3Ooc07jdOaFxp3PFlFSZjUeVxXhUDxuP8JUMr799RhOhUxtUSONG5aTJyYCcSORkTJOTFTnZ kBONHE4RetRi9NiV5ea/JVXgFYjzarwaCV6D1yCL1+F1yA6NC42jQGhpaCnJ0PXQde2P2/P5j/9N e2zaHfb/7f31f2aHNXvoX903/zv3zEyytWwr28u39A5kds5n9Z5ZC7tZPb0zjcY+2UjvkWZ39PbG Nn9xV+z7J/vh73fDj/Q++M8d8MHd5f+23fAfu53eFyfp/fvBXbGyvvsw9x7enYe576ir7zx+9e87 7um7jlf0Hcd03HPM0HccSTpqX9KR+qqJy9/2Tt457b7pRroZ3UzuQ26Um9nN4j7sZnWzudFudjeH +4ib033UzeXmdvO4ed18bn63gFvQLeQWdov84W475I/3WxWhQsr5S7vuot/vuyqDilQZf7f7bnQ2 OZuxB2/7w134gN6HDzlHnGPOid/2Y5VFPYw9+cr/dldO/v2+rLKqbCr6v7Q7p9mb3eT/gd25NuMs s36UjWaFKIrVZQ0pLz4pLcSaszZUlLVj7ag068A6UCx7nXWmx1lX1ofKsr5sAlVlk9k0as6+YTup Je/O4+htHs/fpgG8P3+HhvNBfBi9y0fw92gMf5+PpQn4zPMjPpHr1R7P+NOFKzLRDBElomiuyCKK 0DxRTJSglaKkqEprsOPvxY6/D09v+61Z1k66aGe0M7Ks9h37Dstm37Xvsmg7yU5i2QOaLpYjMCLw Hnsk8H5gHMsTmBCYxAoGJgemsaKBGYEFrERgUWAJqxD4NpDAqgY2BXaxFwP7A/tZ88ChwBH2auBY 4ARrqe8NklmbQKq+Nxgoy8gKbJl8Sj7NVgcLB4uwH4LFgiXYumDJYEm2MVgmWIZtCpYLlmObzedn bEuwUrAS2xqsEqzCtgWrBaux7cEawRpsR7BWsBbbGWwYbMh2BV8Ovsx+DDYONma7g68GW7E9wQ7B DuxghH7sZ4dCLUOt2OFQm1B7djTUMRTHTobiQ/Hskt5np7DLep/9nt3W++xdluJwpwmXTjOnD2/h znBP8/7h98KT+Trv+y36aXQxPnFpxtr6mm8f0DAqTwH/3qOAvqeJ1flz9J/BxfquYA6uJrXKT63S qWP6z3zLpigrqqOmOCuut7uyrKz2+Rx7Tm8uz7PnyWKT2CR8y2YTtbCj7ex2DvsRO6f9qJ3Lzm3n sfPa+ez8dgG7oF3ILmwXsYvaxezH7OJ2CTvGLmmXskuzPWwv28f2swPsIDvEDrMj7Cg7xo6zE+wk O8VOs5/YGfYzO8vOsfPsArvILrHLlrAscUf8Iu6KX0WSuCfui2SRIlL/js7SXbE4Thos/FohIz7N yvq/2rsOsCiSbV3VMwNDz9BkiSJJJEoPOQkSVVRAQDHhkgVEQEAwoAIKZjFgYlEBcwCzYEDAiIpx 16yY1jWjgAkDvOojKrru2/vuu/ft977vUh91qrtnevqcU/Wf/1QnUnhIixQ+sVw3oqkZ4q5LsyBF SKzqSHiiMyk0ciFFhDyRFxKjvqQwKJgUOTQEDSX8cAQpiiiSFCUUQ4oySkGpSAWNRxOQKppCijoZ nRTSwHJYHmmSMaqBOmNtrI204ZqGLmS8+iMdMl6HIl04q6sHI1Ufx+N4ZABXOXTFY3EaMsST8CQy pmfimcgYz8ZzkAmej+cjMzKCC5A5GcG7UXdcjWuQBT6GjyMJrsN1yArmm6xh5NkCp/aBWacRMOsU CnNhGh3mwszhaionajixWGdKQkkIc7SlbLl7xChPssWH8iHMMYAKIMwxmApGAsJ/opAUYT6jCHOc Qc9CQnoOPR+J6HX0eiRPb6S3IEX6En0ZdaKv0jeQGn2Lvkc4dYZoMtIlUWQaMuAiBDImEaIYmXJ4 jiwInl9CEoLiN5ENQfJbyJZg+T1kR/D8PrInOdYD5EAw/RFyJLj+BDkRbH9GfPW9Lt1Blz5UHNFF +xtdHCgHsoXTiEf5k5yGDxoJQCMpwvOGImnQS0hY3BgkA3rRoJcs6KUIeinTZfQ2otEOeg/SBB11 QEc9+gH9CBnST+jnRC9O0+6gqQQ0tQVN7UkcXEvyhPUk23AFrb1A614kPr1GfUl0+kgylE9nX7m7 HCNBIwtOR+5Je8ixXUeL9s8YkdE7Hy/5so7Cm/A2sqT85XNkBPzABs4UsRtYgg++FYA9pMAe0mAP IdhDhvDeEESDVUTgbTHYRpYeQg9BDMnMJyM5kn0tJD7Pp39GWiQH24MM6Aq6CtmSTOw5cqEb6bco inCI6Wg0YQvz0QTCDragbBL7d6PFJNZfRSvA5xXg870kgt9B+8Dz+8HzB8DzleD5g+D5KvB8NYns z1ENie6N6BCJ8B/RYRLPpdAZwnHU0CXCa3RRPeEyJuh3wkpEqIGwCwXUSGK8BskACBKSDGkMQlwG idy5WQY0gLvaBgWKJoq90Bnync54+T/8OXja5b/p01/6AwoHr7LQ5/079Af2a39AQcjlyzoKecO5 e+Uvn6MQjy6k15DfrKZrSR9vEXEjh6yFLP/TkejCMbDtR/n5WB0Jmv0T6E6+qQJYiAALMWAhD7CQ D1goACyUAiyUBiwUAhbKABbSgIUiwEIxYCEDWCgHWCgPWKgIWKgEWKgMWKgCWKgKWMjd23yIaCCm evP2oZ5/eS6IwjRWJEeph02wJXbE7tgHB5CjC8dxOAmnEf6UjWfgeTif/GoRXoe34B24Ah/ER/BJ fI7Y5gaxw0PcgF/idyQASVFiSpFSo7QpA8qE2NgWmxDtjYgtzEEOJRGYkyHYAeQI7AjyJ+wEMhQ7 gwzDPUCGYxeQEdgVZCTuCTIKu4GMxp4gY7E3yHgS1TmZiP1AFghUOcnfI1ADWS5Q5yTzXijipEBJ KOak1BqhLMhKIQPyoFAO5EehPMhWoQLINqEiJwmDUgLpKofhd+KwMUEjOcI1KLJkRuqhhHFw/IVg EtGS9ESio4TUodiS1GHYitThmHAZopsNqSOxLamjsB2po7E7d/0J9iD1KOxF6njCWSiiVW9SJ+E+ pB6DfUidjPuRugD3J3Uh9iX1zwJlRBF9VUhdLuBmX94LiWOIpqRXEz35pK4UEs5DdJTirqgSSpO6 VSgkdZtQBlFEN8LAhK7ImIyt4STmx5NYn4GmoTkoHxWiNWgL2oUOoCOoDv2KbqDf0FOCL+3nFElP UiN93YD0JRbbYmfSm3pjXxxErBFKtIrHm4i1CoiFNoMMwVtAjsClIH/CZSBD8VaQ4QTdORmBt4MM wztARuKdIKPwLpDRws6cJDpqc5Jo2QVkpVAH5EGhLsiPQj2QrUJ9kG1CA04SjbuCdMUrwX+rwHNF 4Lli8FwJeG41+GwN+GwteHEdeG49eG4DeG4j5w+hMlhcBSzeCSyuChZXA4urg8U1wOKaYHEtsDhG fDkEV5bzACsQjHQsx90mwj1N2Beu6zdClsADYDYMd4K+pgp9RI37bW4vWP1LK4brSRz2EjxZAn0F au4sHZYnCIWwCsmrMCARBfjCxVU1NBMPxMF4CB6MB+EYejCJgEM/zU1TY6nJ1AxqMa+At5G3g/nA fGRamTaCsivolfQquogupkvo1fQagrg19CH6MH2EPkofo4/TtcwbhmJ4DJ8RMFKMNCOkW+h39Hv6 A/2RbqXbRAT2RAtEC0WLRPmixaIloqWiZaLloj2iclGFaK9on2i/6ICoUnRQdE10Q1Qvui26K/pN 9Lvooeix6KmoQfRC1CSWFgvFMmJaLBKLxbJiRiwnNhWbic3F3cUWYlYsEVuKrcTWYhuxrdhObC92 EDuKncTO4h5iF7GruKfYTewu9hB7ir0YMSPLMIwio8QoM2+ZFuYdo8loMdx5UEPIPBFkmwLCuvqS mBZHxRPmkEqySjE1iWSVsnDdLAM5pBxkhvIw/6vA287bjhSltkptQ0pS5VLlSEXqjdQbwhlJvoRU uXyJcKt6+j4y5rImwqRmEP7gKColzMGDZPxXUT+S9V9H/YE/+AJ/8AP+4A/8YQDwhwDgD4HAH4KA PwwE/jAI+EMw8IfBolbCHIaI5QlbCAe2MAnYQiajQtjCVKLnPjT0H/HoP+fBf4ufPnuIBmsisKYM 2FER7KgJdjQAzc1Bc1vQfABoHgQ8KfhT9imAtw2Stg/i5pbdkXbH/v99L/7z/vip75A9KEBPQdBT eOBhKfAnA/6UA3/Kgz8VwJ+K4E8l8Kcy+FMF/NkJ/KkK/lQDf6qDPzWI31SRZvvRiwRMh6NnCOdt H7HcmId+iqCfYuinFPRTXvt3xQK5Dt9VI6zkCwp8HumAHDAKoCcLoCdLQ08WfsqkcSN+jd+3swEF qhOlSelTxrw+gghBlGCkIFaQIhgrSGd0GX2mK9ONMWZMGXPGgpEw1owtY884Ms6MC9OTcWc8md7M CCaSiWZimNFMIjOGGcukM+OZKUwWk8PMYGYxc5k8ZiGTzyxhljEFTCGzkiliSpg1zDpmA7OJ2cKU MduZncxuppzZy+xnDjI1zGHmKHOcOcGcYk4zZ5nzzC/MReYyc5W5ztxinjEvmCbmJfP6P3d6/Oe6 z3/ZnR7yhPNHC5SY9yTmu/5D17WTkYjjpG50uApZyF2l8+Uan//mOp0vV/iQfVA9qBEdZjq4NX0J An2ZL8Av0RvC0W0oe/IJD7LOjxpADaKGUMOpSIJVSQT1JnHn1X5UuHNpHQvZy7fF/o+FO/PWsXDn 6X5YPL4r3txZvG+K3x8Ld0avYyG6/Ekh8eCbQnT+tgz5USHx45tCrPRtGQHl63Lkd2UkKXF/UpJ+ VESt3xYStb4t6t8VvW9Lu36fjhf28J/5kT+ZH8GonsRPZxLrexOWHQTPYvn8BBbuaSyz0Hy0hGQ/ JWgDKiP5zz5UjY6RDOgCukLsx8L55v9pbf9P1X7/TP3DWZBPcyRiIpZweQ9y43IBEus6QfbAnWfB 2Jjk0RSJ9otJewleStrLMPcG8ZUk86LwbvycewotbiT5ShO8h+MVfk3ab3ALxMz3pP0Bt5J2G8W9 BYWi+KTPCSgp0pamuCe3iiiSf1Oy8E4ReYrk2JQipUzaKlQn0lbl3hFC4qomaWtRuqStR5HMjTLg 3j5CYqwxaZtQJqRtSpmSthllhri3qpiTdneKexvQz9TPpF1IFZL2CmoFaa/k9YInyfZBPJ6PQIl7 Vp2A6CvQEHhxT1cU9EI8QW9BGPescEEsacdxbyYmsTqdtMdxT60S5AhySDtXUI24tyzXkPYhIUFm IUWySEpoKDMKYZl4GcL0ZEbLbkRYdpMsyXplN8vWkPYh2aOkfYwwVcxoE57BI2yyDTI8gspylJzu p/uswTMUCm+/O/grB8HAQTBwENzhLlYMHAQDB8HAQTBwEAz3nmDgIBg4CAYOgoGDYOAgGDgIBg7y 6QgpYCIYmAgGJoKBiWBgIhiYCAYmgoGJYGAiGJgIBiaCgYlgYCIYmAgGJoKBiWBgIhiYCAYmgoGJ YGAiGJgIBiaCgYlgYCIYmAgGJoKBiWBgIhiYCAYmgoGJYGAiGJgIBiaCgYlgYCIYmAgGJoKBiWBg IhiYCAYmgoGJYGAiGJgIBiaCgYlgYCIYmAgGJoKBiWBgIhiYCAYmgoGJYGAiGJgIBiaCgYlgYCIY mAgGJoKBiWBgIhiYCAYmgoGJYGAiGJgIBiaCgYlgYCIYmAgGJoKBiWBgIhiYyOdnlHx5YolmCpHK sBZpjmKzNUdKyZjk9s59I4ulqaJszcFkVRCFsUTEykgJTBkepSFAbJgUbSqF+TjbjsL8okB2AGvW YY1WiXamFpxSckZ+KByloEQColEolfxzp5hcWN0OO+Mrd5Ne7WffbD7zkTtWG/Nk1rVHHvvPFWV3 MmGz+YpsNvWuiEdhioBDDZrt7DxD4bzL64int3qysl+OFPPJMSVJTFljKd5AvkhJzyMxaXxy7MiY VB2jCGMdiYODnU7/2IjkxJTE6FQdj8TkpO4SbVbr04dVvt2SmByWGpuYINFlu3DbeUpqX7cHJCam 6riNTY1JTI5NHc9qq8o62LESCcvaseRvqKqsJSuxtJK0L/4NR5SN9TqahXtTVTaBFbKeprIxRhup ypqk352afDWNVi0dN4J9XLJxbtef3rYu7re6vHVFiY5LxoCSn0vyQi1HnXePHN+wJe1E0LWmJ4W5 WnmrpkXvPDpqQrj+pc7O9XJ44cMlR6rMowsKYgyXn3M0qxLvHmxY4/2AdrFfYrbRyGHD0z5T3e9N k9tfED8wbEt2RnGoeXq/R8t3RToV+GtJhAbKqzY+WGCq9nuPZRHKoYMFUas62wVMf7P+eT51TPOX qoFeO2dmVjk+Dcr3Lfu4fsLoVN+tanVLZIx0UfD80Fi7/X0VpZ0HtQ17vyaaFq67kDUo+PkepxGd stL5114fLMtc3Lrt9JRL6zWShzufPPBCuFqP3SmVc2KnTrpSzi2KRzr+6qwNbNZaNquEWLMz5mcV sFlLM+WHnUt6Hpu8Un/AZOUd/ee1nSpO/r/3X/Zf9HEe58PFD0XVc5uXqtk8q8AGV9IVmoeHWq5a KTrlIlgwI++E4++6TS+CF5ntLupVG/78w+U6J6ehG22DYlsNRrueqNtUL8i4KZnbY5V8Utz+VkU/ tdjqD+c87ikM1fF7HD5x6yb1WlO7ruYHo4oVZ3WVi1j9JkirRffEJZXmgC0JHpbSH7NV394fGS87 4HVlY8DxygdH2A86EpkZnRcba/S/2Jla25h5m7dr2MvtN2uDG6L6HA8I2rOLZ6TYNv/SC2He5Iql Rzfbmf024bcN6ffSitC5ONeaC7azbrspbrCJ04y7bnPnVy3+bxu8+LVDrewT+mvJhpfTJXN+uRjk 6n1aa+C6pOuKjtMXjV21/kIRQYVQNpvX7xMq0N03K9zwbxu+4lT1Z0zp/HeBARn39pbkjyCAJQED iSVZtPkMBuMBQclOpJSogYESJVaBWxAq0cFhKTGxCSNTyc/Iswy3UlpJOiAqcnRiQuTnA6P/7MD0 Wd1PB6bRcXtklE5g7MgEslcdfw+3v0SF8vGTLoXs9HLYYL1Fcq2lq02f9Or3XVYe9xrz/Lz3w1/n HB7VLyD85XLqcP8rfeItDFyiqs7ol4t6l08Ze9OrclMe43+0q2lT0QNZ/S7n3QzehS8/q+61dpFP l+Wnd1roHfYxz0i8qqLtNMdB3uFmpfHLaCdzbNnW2q33ut3xeHrh+307IqZktwwvypqWM29bU0X+ 6rP26/xzVLtN973JvkY9Xh5r6ZF1MPdZvMP67tavd3XfSk8KXzAuunBZimzu1qYjzTp7/RTnRpwy u2rppd6w32eJk3+g2pnoAeM3lU6vHeSyKtt/RoJgu03NRIPKgOgey33rTCdbJUzrJXV+5TmfXCoh F62pnn4rsB0V3rFZb1glDhS68sUsLSUkAU0gkObx/n9AhRx3jErcaycFLI8ItjO3guF34ivXdT6T hpKGbW28dsS3YIBn99WeES9YEbdZjs8nwyi3w9ABjJm4uWyyj2HTmQO+qSWDu6WajN2Z+3Fzv/xx qP+jk0/UbsQeZUoymimPYyen170NrDu0qnJQ4osIz42eqGFJbcFFrQrRKnXZ/MvXtEuNJz1/ti5l S169w7wey+IO2I++MGOr/sdbjy7FyiyYUdl6B+23bn6T0SKv2F3wxHjJIvdRRmPK7fNuS8ueCIk5 XZnpNip6w/7y/fOsTzbx5DMmvLpw2/3WxNY7d7a0vr51UXZn0qWF9/z22JdkmP/a47q1KNyOWpUV pz/z9fCIvG1D9ztcDp0zcJqG1SunZUXZ4pKfZu80Ky9ee2rzNZ09Vax6jo6yrMmBgJdut0ew9xYa xU6vSbrbvH7zmUz35DSGYEwcwZiAdowJkxvXHxgSr+M4EhCc+RtH9WfAsWJZgjhWBHBYB9aSW7Ti FtnUf8uhtW/n/cn2v8Sakuv03LOHavr8fHqTo3Wp/pBR1+MP6uqV59c+Lqs6dtHwkKXC7APXQsze 2w7SVjEty5O9qbw6wajflE6ublvm9tzuPUP2alZ+6VKpc8GeacMfN35g7k5JXW11KvX+83thxZN5 5V5tF10UL247OUL23MSmciXZD6FxRjlj55SXHsh5qLpr/sFXnfaEhzxTuOXYoDts9tbMlMNe9xbP TA/9+UFpeo3dXCtlC6Xr4SfKNDb6LRtZ+quOAzvm9tyR3nePab2U9U91s3goMIjTHdVn28IjOxyO u68dPVzNZ3Pe5XlTXcbRva6s2TFN//DdponR231SKw3d+haGKYf6srXZzedESRkNA/unXxAOTMtq x5q3bNYrsH1nOW7EkkEoVd1hwDbr9pyXMeBtUN9l91Uvx021FnQ3fPhjaOJworM+X43tlPnjYe7J faALvwfrxDoU2RXZ5FrFpKYmOVpYRCTHdx/92YfdIxJHWySNiuXWWiQlJ0aOjUhNsfAIJB2tO1nF 9v78k4SHOLOOrP3nZZbKNWvfYXp6+o92GJXcYU+p3w0gQJuewYmBI1fqTLXGzO+qfZ1Ln1zJmtIg Oz413W9pL7VmpBI7+Xr4/JKPI4sLfzMyfjfw8vJW/6oRMjv3rnuW3bxMO3HIu1eNd8S/zBa6dFLV OV+926uX0DA0WKZv/gth3b7+CS/u9lY0spmtm3zrpz1bYxUN8hseWctcn5yQuJAOOGnSr88mS7Pc h8V1IYYHDjjfHrZjqmifjZbfNK9ebfvzi4dIb1xyc1xl8JS1633rmkoLC9zunhpu4HJjinUv39dn ayeueLLnRGGEcuDW0oLnl6vOFhVvXnxygul0s+rjVz/E865V2Zc2nh+uripX/eZk5jp5ocbN+foP thX3c3m8TcFwHFNjtnfNqON5zgRtVhC0yfmMNn0yngHaCP4+tAmKHR2Vkho2Oqkj2tiyDhJbVmJj Ywn0RgKLliy3yGat+7ccWze266dAqZ3gEZsUE5Ws4xnopeMV6OsoYT3tzW3sre3MPdy97T9/kKek /SdKBEYlp8VGRP0lQD3eJ4iovTq+bJqny9qdR571W2lwyyFNW+aSpc/gcRdMr66Vnv/8QY/3lYYZ q9/fnzTZ8uzVHrMd7JreXnGy7vTrwuz31k9jcpI18m5X9LtdkdNsRVM1JWkpNv1CGsvv+EzqXJE/ 7nqbdo6Ku/eYM1O6BSuen+rndPZd/evZz1zRvYv1YS2qc/uuyXJ+Fdvz8Z2ZVdJ++1InPhLf7/V4 c3zjxZFZwredTk5S2p9yV6bfu/D3z4ocChxbnyjUhmmHD75CB0296NS3792BlRahGvMWCjyuhTzJ pvWXyhQJJFGzF/lqu+mWLJz/0cvTK9Fmu5ddaezGqBZrj+2qh5wc7sjPadKYfi/Iv4vTCklpR4D6 CkiTk190dx1kfLvrm5gK/KHvncln77l8gz2JD31dl+613tw3N+9A4eMtTm4ex879r7AnNSUpIuxf gj2f95T6IwQV/gGFfwBQsROyZcSdztef9Z7Zveq89YSsKd2M3Eyaf9FdyCwt/SlwhHHLs5ognw2T 3iidEym39G/KVUEJ96Z2NvJab+ZgeTOxwG5og35AXhBvruv6wkj717a1yh57HF2WnZA9PCbLqDl6 veTu8JC8loCAO8OfLJq/Ilam38zz59P6WcvG3cnwXG86bGrQFC8D9a5HZnkf7XpPPTPWWPm16rEX emZZ3iNMX7asO5buop/Ysi4yZ15JuOxGc+0N9+e7TGnbNu/D0qeNH/lbT/c5MzR1y7tmpS6aDmdW 77p04OWuhtrSpkHa750bay+ZeB6oKnSdFK12eodOBH2yZ48oS/WMHRU9agx7++qpL0+Yw9Y0LvgW oOTjRMv9qlHXzQrXvboMnjCy5HuY+nuSr3Z0Yq2t7Th0ciCLf0Py9Qfg/Cu8uWGX8H5rrbvPGLXa M71dAqvfbVbeZ2a5X9EvoHbqMxerq30kC432LIi83cV/2r5Dfc9PEbx9Pvbg7OMbLpbFJkWP6xb9 cE/585y9pxs2fVRcIxqiZ2xxtufVQXzNtN2jI0f7BF2/2VhftWrq8cxbU/pRdvmvqlcKB2nH9Dp9 tTptuMWkPV35uwYNi9OKaMvMcG64yO/a3yE9VTrk0PAruXZmY08wj7UdZDLSWlfEJ0y4/dQlb+nK McxPJn5q4aGWKy9M9TXVGx7jNbveYpq8/46W3Rpz4xu6/qz09pT85RzmZXZaiu2xxRNK6kKlngq2 5VqVv80fNs1t2uCc/IRtXcx61yUWetyOezjFcN6oT3iTjY2IRQx+PEL/X6Rf8lIy7ROgKpjLqVAH 9PwhOKp/+YIyxRdr0ygQjUXhyAO5fZua/SGv+wFA5fdXkBzK8N+vMK84TBozc5K85j5PCap0lRGY t1UMCMzReuawoHz1IFH9nD1Omuffb1l/onz7AF3NRGHs5FG8Ej3vZ/G7RmfoVXj/Mq15rtxB6Vm2 NU8mP0oK8Vq18ELdmZvzqu9UmZzOeHqizPLi9L2nIo7YnlfTrUqrdyrYqZmyUnfGlV27FIPmvCw8 FOVTYGRYGDpLzum4UtS43vvPlk519NsWPrieffTIofO9mU3XHLJalHTnRGZGSPGXNBVQHhYTvWfs a6OuRrX41F/jpS7aKUgQ1624YRSW0btRtVBB157Smr5F6ugSy4r7PY8F9qjcOLP+YbTd3Jd6Swrr tqUHDXC8lOy5Q/+1JJu/lYDUZgpjNmv635iVfZMrfp3jLsq6xip/8bcRlkjzBHD1MtcL2p0pw5OI O06rk6P5uiSSMGzHrSqs/tcv8iWkj73J85HO6rugfrewwH/bzKqPRn4LdrORHb4ilgxig4pMMo1Q fxSLIlAySoSZ+WiUinRQEBqPksjSSLI+jLRi0Phiw0yDPw2vqeOTEkcmhyXFjNf5Dt742RjpVP1e MUQdOSoXaMzof6Z58bbCRT1LHjNWwfwG+xTvDx+2ly1/fpu9N3nWqycveRNfXRze8ip1RaYoYee1 MgteAj/pMe/Sa9WZ5tXTFtutPesyLSSYGX/iivqVqo9Ws1fe2KlTUu79ZO/kVc+2Vrsce1zleeu8 24G3j5TVZ/VtXIS9zv5kJZ49pWzOao+5tR982yJKFx4+Lek2MGVXaPkC/psTsmllvceVUQWZJ8sW WNsaHvs9Ulw0jzoxusukssmDbI78opSxw11v8fKzE3yT0laXmR7VezAh5XJIUV7x82A/CWUqn+b5 Lt9bKzxfaWJexm/T9G+v/tnXjn+sX/Smh2uvrR2sP2kme76LcnE21YXNpjS/+khKkk2JySrh/3kX /T4ifZNgSLd30aIQVq1jTxR9PQuEyW9+2SKQyJFQay9hLUmgtXSwshn6h45ItRkwt/aEzQ3p/hM7 w0vj1dbbT99+h1lcF7m19LCP0PxWxQnNdVd1BcfFT6NzDdrcqbMeLypri3XSltw9cGfRPMWedw1N StYtmB02R62lzmS7v8b0txMXPA482vPhfvOQvDOeCyMTBoV2dRcdz6Uy3Rr0lk88ajnBvyF+xm/v bFVfHZu9MLxzUMGv95UUiy+tKHvTFuzI6/XoYsPg5mgXt5F9R5QfrLyaY/5bcEXtgs3hY+Jc1ysJ D501rRtbv3zW+HFJU0u9Cw7tnDrTt5ej6dRAXcsNrY+Pu6amUdVlm5IDQypijk9+IukRU9Ats3mX 1LYHv1QomGVfiK/aemvMjodTwzfswWnsNaZn4I5hguY3u2wjBYG6KrNHeifIx40eohSQsEsW/RdO tPWvDQplbmRzdHJlYW0NCmVuZG9iag0KNzQ3IDAgb2JqDQpbIDg0MlsgMzI2XSAgODU5WyAyNTBd ICA4NjJbIDQxOCA0MThdIF0gDQplbmRvYmoNCjc0OCAwIG9iag0KPDwvVHlwZS9YUmVmL1NpemUg NzQ4L1dbIDEgNCAyXSAvUm9vdCAxIDAgUi9JbmZvIDM4IDAgUi9JRFs8NDQ2OTk5MjY0QzEyMjk0 OUE0MEIwQTg0QjgzRThGRjI+PDQ0Njk5OTI2NEMxMjI5NDlBNDBCMEE4NEI4M0U4RkYyPl0gL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTQ4MD4+DQpzdHJlYW0NCnicNddpvJdzGsfx//eUpUWL tUJoEXXKFllS9n0PbbKmENFirbQqZEkdVAhliUr2fQazMMMsmH2MMYttxjpjxk7O+b1v58F5v677 vh/8H12f11WrNf6tWZPG/+1rtSamFBK8U2jzSqHttEK7iYX2wwod5xU6zS30HFHo1bpQX4dVhd5L Cn0WFwbMLwxcWBi8qDCkM/rj9cLQHoVhHQrDWxZGfVIY/Vph/JjChEGFSbMLk8cWZnYvzOpVWNCv 0NC3sHR1YZkfsWJ5rdb4i+vqa4/jCTzWSK3++3dPNn65sqFMjQ+DOjRDc18+ZVoLa3v4tGkdrOvh D0wtTD80tUQrtMZ6aOPLZ0xt0c7DZ03tsT428O4504bYCBt79yPTJujg4Y9NHdEJm3r3E9Nm2NzD n5o6Ywtsia3QBV3RDd2xNXpgG2yLnuiFevRGH2yH7bEDdsRO6IudsQv6YVfsht2xB/pjTwzAQOyF vbEP9sV+2B8H4EAchINxCA7FYTgcR+BIHIWjcQwG4Vgch+MxGEMwFMMwHCdgBE7ESTgZp+BUnIaR OB2jMBpn4EychTE4G+dgLM7FeRiH8ZiAiTgfF+BCXISLcQkmYTKm4FJMxTRMxwzMxCxchtmYg8tx Ba7EXFyFq3ENrsU8XIf5WIAGXI8bcCMWYhEW4ybcjFuwBLfiNtyOZViKO3An7sLdWI57cC9WYCVW 4T6sxv14AA/iITyMR/AoqhX7OJ7Ak6jWaLU4q1VZ7chqAVYrr9pu1SKrVle1paq99DxewM/wc7yI l/AL/BK/wq/xMl7Bq/gtfoPf4ff4A/6IP+HPeA1/wev4K97A3/B3/AP/xJt4C2/jHbyLf+HfeA/v 4wN8iI/wMf6D/+IT/A9f4v/4FF/gM3yOr/A1vsG3WFOImEZMI6YR0zSHimZdrA0VTQsIZtQwuhnd TBvIZ9pBIiOR2QDaGG3MxhDFdIAaRg2zKWQwm0P/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L /kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6 F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on9RvMhgZDD6F/2L/kX/on/Rv+hf 9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/R v+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hfhC8yGP2L/kX/ on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6F/2L /kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/CFxmM/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C/6 F/2L/kX/on/Rv+hf9C/6F/2L/kX/on/Rv+hf9C9N/Ws8cJouxafHfX8NBnVohur+WwvV4bcOqouv OvVaohVaYz1UN15bVMdde6yP6qrbEBuhOuc2QXXHdUQnVAfcZqguty3QGVtiK3RBV3RDd2yNHtgG 26IneqEevdEH22F77IAdsRP6Ymfsgn7YFbthd+yB/tgTAzAQe2Fv7IN9sR/2xwE4EAfhYByCQ3EY DscROBJH4Wgcg0E4FsfheAzGEAzFMAzHCJyAE3ESTsYpOBWnYSROxyiMxhk4E2dhDM7GORiLc3Ee xmE8JmAizscFuBAX4WJcgkmYjCm4FFMxDdMxAzMxC5dhNubgclyBKzEXV+FqXINrMQ/XYT4WoAHX 4wbciIVYhMW4CTfjFizBrbgNt2MpluEO3Im7cDeW4x7cixVYiVW4D6txPx7Ag3gID+MRPNq4AF9s UfbgS3OayPRW+KKJui4Nha7PNtFserfCjJFNNF/5Rq32HRoY6JgNCmVuZHN0cmVhbQ0KZW5kb2Jq DQp4cmVmDQowIDc0OQ0KMDAwMDAwMDAzOSA2NTUzNSBmDQowMDAwMDAwMDE3IDAwMDAwIG4NCjAw MDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDI1NyAwMDAwMCBuDQowMDAwMDAwNDg3IDAwMDAwIG4N CjAwMDAwMDM3OTMgMDAwMDAgbg0KMDAwMDAwMzk2OCAwMDAwMCBuDQowMDAwMDA0MjEyIDAwMDAw IG4NCjAwMDAwMDQ0NDIgMDAwMDAgbg0KMDAwMDAwNjU0NCAwMDAwMCBuDQowMDAwMDA2Nzk1IDAw MDAwIG4NCjAwMDAwMTA4NDUgMDAwMDAgbg0KMDAwMDAxMTAyMCAwMDAwMCBuDQowMDAwMDExMjY2 IDAwMDAwIG4NCjAwMDAwMTE0MzcgMDAwMDAgbg0KMDAwMDAxMTY3OCAwMDAwMCBuDQowMDAwMDEx OTMwIDAwMDAwIG4NCjAwMDAwMTYwMTggMDAwMDAgbg0KMDAwMDAxNjI4MCAwMDAwMCBuDQowMDAw MDIyNDI1IDAwMDAwIG4NCjAwMDAwMjI1NTggMDAwMDAgbg0KMDAwMDAyMjU4OCAwMDAwMCBuDQow MDAwMDIyNzQ5IDAwMDAwIG4NCjAwMDAwMjI4MjMgMDAwMDAgbg0KMDAwMDAyMzA2NCAwMDAwMCBu DQowMDAwMDIzMzA2IDAwMDAwIG4NCjAwMDAwMjYzNTUgMDAwMDAgbg0KMDAwMDAyNjU4NyAwMDAw MCBuDQowMDAwMDI5MjkxIDAwMDAwIG4NCjAwMDAwMjk1MjMgMDAwMDAgbg0KMDAwMDAzMTYyMiAw MDAwMCBuDQowMDAwMDMxODU0IDAwMDAwIG4NCjAwMDAwMzM1NzMgMDAwMDAgbg0KMDAwMDAzMzgz NSAwMDAwMCBuDQowMDAwMDM3Njg3IDAwMDAwIG4NCjAwMDAwMzc5NDAgMDAwMDAgbg0KMDAwMDA0 MTY0NyAwMDAwMCBuDQowMDAwMDQxODgwIDAwMDAwIG4NCjAwMDAwNDM5NDQgMDAwMDAgbg0KMDAw MDAwMDA0MCA2NTUzNSBmDQowMDAwMDAwMDQxIDY1NTM1IGYNCjAwMDAwMDAwNDIgNjU1MzUgZg0K MDAwMDAwMDA0MyA2NTUzNSBmDQowMDAwMDAwMDQ0IDY1NTM1IGYNCjAwMDAwMDAwNDUgNjU1MzUg Zg0KMDAwMDAwMDA0NiA2NTUzNSBmDQowMDAwMDAwMDQ3IDY1NTM1IGYNCjAwMDAwMDAwNDggNjU1 MzUgZg0KMDAwMDAwMDA0OSA2NTUzNSBmDQowMDAwMDAwMDUwIDY1NTM1IGYNCjAwMDAwMDAwNTEg NjU1MzUgZg0KMDAwMDAwMDA1MiA2NTUzNSBmDQowMDAwMDAwMDUzIDY1NTM1IGYNCjAwMDAwMDAw NTQgNjU1MzUgZg0KMDAwMDAwMDA1NSA2NTUzNSBmDQowMDAwMDAwMDU2IDY1NTM1IGYNCjAwMDAw MDAwNTcgNjU1MzUgZg0KMDAwMDAwMDA1OCA2NTUzNSBmDQowMDAwMDAwMDU5IDY1NTM1IGYNCjAw MDAwMDAwNjAgNjU1MzUgZg0KMDAwMDAwMDA2MSA2NTUzNSBmDQowMDAwMDAwMDYyIDY1NTM1IGYN CjAwMDAwMDAwNjMgNjU1MzUgZg0KMDAwMDAwMDA2NCA2NTUzNSBmDQowMDAwMDAwMDY1IDY1NTM1 IGYNCjAwMDAwMDAwNjYgNjU1MzUgZg0KMDAwMDAwMDA2NyA2NTUzNSBmDQowMDAwMDAwMDY4IDY1 NTM1IGYNCjAwMDAwMDAwNjkgNjU1MzUgZg0KMDAwMDAwMDA3MCA2NTUzNSBmDQowMDAwMDAwMDcx IDY1NTM1IGYNCjAwMDAwMDAwNzIgNjU1MzUgZg0KMDAwMDAwMDA3MyA2NTUzNSBmDQowMDAwMDAw MDc0IDY1NTM1IGYNCjAwMDAwMDAwNzUgNjU1MzUgZg0KMDAwMDAwMDA3NiA2NTUzNSBmDQowMDAw MDAwMDc3IDY1NTM1IGYNCjAwMDAwMDAwNzggNjU1MzUgZg0KMDAwMDAwMDA3OSA2NTUzNSBmDQow MDAwMDAwMDgwIDY1NTM1IGYNCjAwMDAwMDAwODEgNjU1MzUgZg0KMDAwMDAwMDA4MiA2NTUzNSBm DQowMDAwMDAwMDgzIDY1NTM1IGYNCjAwMDAwMDAwODQgNjU1MzUgZg0KMDAwMDAwMDA4NSA2NTUz NSBmDQowMDAwMDAwMDg2IDY1NTM1IGYNCjAwMDAwMDAwODcgNjU1MzUgZg0KMDAwMDAwMDA4OCA2 NTUzNSBmDQowMDAwMDAwMDg5IDY1NTM1IGYNCjAwMDAwMDAwOTAgNjU1MzUgZg0KMDAwMDAwMDA5 MSA2NTUzNSBmDQowMDAwMDAwMDkyIDY1NTM1IGYNCjAwMDAwMDAwOTMgNjU1MzUgZg0KMDAwMDAw MDA5NCA2NTUzNSBmDQowMDAwMDAwMDk1IDY1NTM1IGYNCjAwMDAwMDAwOTYgNjU1MzUgZg0KMDAw MDAwMDA5NyA2NTUzNSBmDQowMDAwMDAwMDk4IDY1NTM1IGYNCjAwMDAwMDAwOTkgNjU1MzUgZg0K MDAwMDAwMDEwMCA2NTUzNSBmDQowMDAwMDAwMTAxIDY1NTM1IGYNCjAwMDAwMDAxMDIgNjU1MzUg Zg0KMDAwMDAwMDEwMyA2NTUzNSBmDQowMDAwMDAwMTA0IDY1NTM1IGYNCjAwMDAwMDAxMDUgNjU1 MzUgZg0KMDAwMDAwMDEwNiA2NTUzNSBmDQowMDAwMDAwMTA3IDY1NTM1IGYNCjAwMDAwMDAxMDgg NjU1MzUgZg0KMDAwMDAwMDEwOSA2NTUzNSBmDQowMDAwMDAwMTEwIDY1NTM1IGYNCjAwMDAwMDAx MTEgNjU1MzUgZg0KMDAwMDAwMDExMiA2NTUzNSBmDQowMDAwMDAwMTEzIDY1NTM1IGYNCjAwMDAw MDAxMTQgNjU1MzUgZg0KMDAwMDAwMDExNSA2NTUzNSBmDQowMDAwMDAwMTE2IDY1NTM1IGYNCjAw MDAwMDAxMTcgNjU1MzUgZg0KMDAwMDAwMDExOCA2NTUzNSBmDQowMDAwMDAwMTE5IDY1NTM1IGYN CjAwMDAwMDAxMjAgNjU1MzUgZg0KMDAwMDAwMDEyMSA2NTUzNSBmDQowMDAwMDAwMTIyIDY1NTM1 IGYNCjAwMDAwMDAxMjMgNjU1MzUgZg0KMDAwMDAwMDEyNCA2NTUzNSBmDQowMDAwMDAwMTI1IDY1 NTM1IGYNCjAwMDAwMDAxMjYgNjU1MzUgZg0KMDAwMDAwMDEyNyA2NTUzNSBmDQowMDAwMDAwMTI4 IDY1NTM1IGYNCjAwMDAwMDAxMjkgNjU1MzUgZg0KMDAwMDAwMDEzMCA2NTUzNSBmDQowMDAwMDAw MTMxIDY1NTM1IGYNCjAwMDAwMDAxMzIgNjU1MzUgZg0KMDAwMDAwMDEzMyA2NTUzNSBmDQowMDAw MDAwMTM0IDY1NTM1IGYNCjAwMDAwMDAxMzUgNjU1MzUgZg0KMDAwMDAwMDEzNiA2NTUzNSBmDQow MDAwMDAwMTM3IDY1NTM1IGYNCjAwMDAwMDAxMzggNjU1MzUgZg0KMDAwMDAwMDEzOSA2NTUzNSBm DQowMDAwMDAwMTQwIDY1NTM1IGYNCjAwMDAwMDAxNDEgNjU1MzUgZg0KMDAwMDAwMDE0MiA2NTUz NSBmDQowMDAwMDAwMTQzIDY1NTM1IGYNCjAwMDAwMDAxNDQgNjU1MzUgZg0KMDAwMDAwMDE0NSA2 NTUzNSBmDQowMDAwMDAwMTQ2IDY1NTM1IGYNCjAwMDAwMDAxNDcgNjU1MzUgZg0KMDAwMDAwMDE0 OCA2NTUzNSBmDQowMDAwMDAwMTQ5IDY1NTM1IGYNCjAwMDAwMDAxNTAgNjU1MzUgZg0KMDAwMDAw MDE1MSA2NTUzNSBmDQowMDAwMDAwMTUyIDY1NTM1IGYNCjAwMDAwMDAxNTMgNjU1MzUgZg0KMDAw MDAwMDE1NCA2NTUzNSBmDQowMDAwMDAwMTU1IDY1NTM1IGYNCjAwMDAwMDAxNTYgNjU1MzUgZg0K MDAwMDAwMDE1NyA2NTUzNSBmDQowMDAwMDAwMTU4IDY1NTM1IGYNCjAwMDAwMDAxNTkgNjU1MzUg Zg0KMDAwMDAwMDE2MCA2NTUzNSBmDQowMDAwMDAwMTYxIDY1NTM1IGYNCjAwMDAwMDAxNjIgNjU1 MzUgZg0KMDAwMDAwMDE2MyA2NTUzNSBmDQowMDAwMDAwMTY0IDY1NTM1IGYNCjAwMDAwMDAxNjUg NjU1MzUgZg0KMDAwMDAwMDE2NiA2NTUzNSBmDQowMDAwMDAwMTY3IDY1NTM1IGYNCjAwMDAwMDAx NjggNjU1MzUgZg0KMDAwMDAwMDE2OSA2NTUzNSBmDQowMDAwMDAwMTcwIDY1NTM1IGYNCjAwMDAw MDAxNzEgNjU1MzUgZg0KMDAwMDAwMDE3MiA2NTUzNSBmDQowMDAwMDAwMTczIDY1NTM1IGYNCjAw MDAwMDAxNzQgNjU1MzUgZg0KMDAwMDAwMDE3NSA2NTUzNSBmDQowMDAwMDAwMTc2IDY1NTM1IGYN CjAwMDAwMDAxNzcgNjU1MzUgZg0KMDAwMDAwMDE3OCA2NTUzNSBmDQowMDAwMDAwMTc5IDY1NTM1 IGYNCjAwMDAwMDAxODAgNjU1MzUgZg0KMDAwMDAwMDE4MSA2NTUzNSBmDQowMDAwMDAwMTgyIDY1 NTM1IGYNCjAwMDAwMDAxODMgNjU1MzUgZg0KMDAwMDAwMDE4NCA2NTUzNSBmDQowMDAwMDAwMTg1 IDY1NTM1IGYNCjAwMDAwMDAxODYgNjU1MzUgZg0KMDAwMDAwMDE4NyA2NTUzNSBmDQowMDAwMDAw MTg4IDY1NTM1IGYNCjAwMDAwMDAxODkgNjU1MzUgZg0KMDAwMDAwMDE5MCA2NTUzNSBmDQowMDAw MDAwMTkxIDY1NTM1IGYNCjAwMDAwMDAxOTIgNjU1MzUgZg0KMDAwMDAwMDE5MyA2NTUzNSBmDQow MDAwMDAwMTk0IDY1NTM1IGYNCjAwMDAwMDAxOTUgNjU1MzUgZg0KMDAwMDAwMDE5NiA2NTUzNSBm DQowMDAwMDAwMTk3IDY1NTM1IGYNCjAwMDAwMDAxOTggNjU1MzUgZg0KMDAwMDAwMDE5OSA2NTUz NSBmDQowMDAwMDAwMjAwIDY1NTM1IGYNCjAwMDAwMDAyMDEgNjU1MzUgZg0KMDAwMDAwMDIwMiA2 NTUzNSBmDQowMDAwMDAwMjAzIDY1NTM1IGYNCjAwMDAwMDAyMDQgNjU1MzUgZg0KMDAwMDAwMDIw NSA2NTUzNSBmDQowMDAwMDAwMjA2IDY1NTM1IGYNCjAwMDAwMDAyMDcgNjU1MzUgZg0KMDAwMDAw MDIwOCA2NTUzNSBmDQowMDAwMDAwMjA5IDY1NTM1IGYNCjAwMDAwMDAyMTAgNjU1MzUgZg0KMDAw MDAwMDIxMSA2NTUzNSBmDQowMDAwMDAwMjEyIDY1NTM1IGYNCjAwMDAwMDAyMTMgNjU1MzUgZg0K MDAwMDAwMDIxNCA2NTUzNSBmDQowMDAwMDAwMjE1IDY1NTM1IGYNCjAwMDAwMDAyMTYgNjU1MzUg Zg0KMDAwMDAwMDIxNyA2NTUzNSBmDQowMDAwMDAwMjE4IDY1NTM1IGYNCjAwMDAwMDAyMTkgNjU1 MzUgZg0KMDAwMDAwMDIyMCA2NTUzNSBmDQowMDAwMDAwMjIxIDY1NTM1IGYNCjAwMDAwMDAyMjIg NjU1MzUgZg0KMDAwMDAwMDIyMyA2NTUzNSBmDQowMDAwMDAwMjI0IDY1NTM1IGYNCjAwMDAwMDAy MjUgNjU1MzUgZg0KMDAwMDAwMDIyNiA2NTUzNSBmDQowMDAwMDAwMjI3IDY1NTM1IGYNCjAwMDAw MDAyMjggNjU1MzUgZg0KMDAwMDAwMDIyOSA2NTUzNSBmDQowMDAwMDAwMjMwIDY1NTM1IGYNCjAw MDAwMDAyMzEgNjU1MzUgZg0KMDAwMDAwMDIzMiA2NTUzNSBmDQowMDAwMDAwMjMzIDY1NTM1IGYN CjAwMDAwMDAyMzQgNjU1MzUgZg0KMDAwMDAwMDIzNSA2NTUzNSBmDQowMDAwMDAwMjM2IDY1NTM1 IGYNCjAwMDAwMDAyMzcgNjU1MzUgZg0KMDAwMDAwMDIzOCA2NTUzNSBmDQowMDAwMDAwMjM5IDY1 NTM1IGYNCjAwMDAwMDAyNDAgNjU1MzUgZg0KMDAwMDAwMDI0MSA2NTUzNSBmDQowMDAwMDAwMjQy IDY1NTM1IGYNCjAwMDAwMDAyNDMgNjU1MzUgZg0KMDAwMDAwMDI0NCA2NTUzNSBmDQowMDAwMDAw MjQ1IDY1NTM1IGYNCjAwMDAwMDAyNDYgNjU1MzUgZg0KMDAwMDAwMDI0NyA2NTUzNSBmDQowMDAw MDAwMjQ4IDY1NTM1IGYNCjAwMDAwMDAyNDkgNjU1MzUgZg0KMDAwMDAwMDI1MCA2NTUzNSBmDQow MDAwMDAwMjUxIDY1NTM1IGYNCjAwMDAwMDAyNTIgNjU1MzUgZg0KMDAwMDAwMDI1MyA2NTUzNSBm DQowMDAwMDAwMjU0IDY1NTM1IGYNCjAwMDAwMDAyNTUgNjU1MzUgZg0KMDAwMDAwMDI1NiA2NTUz NSBmDQowMDAwMDAwMjU3IDY1NTM1IGYNCjAwMDAwMDAyNTggNjU1MzUgZg0KMDAwMDAwMDI1OSA2 NTUzNSBmDQowMDAwMDAwMjYwIDY1NTM1IGYNCjAwMDAwMDAyNjEgNjU1MzUgZg0KMDAwMDAwMDI2 MiA2NTUzNSBmDQowMDAwMDAwMjYzIDY1NTM1IGYNCjAwMDAwMDAyNjQgNjU1MzUgZg0KMDAwMDAw MDI2NSA2NTUzNSBmDQowMDAwMDAwMjY2IDY1NTM1IGYNCjAwMDAwMDAyNjcgNjU1MzUgZg0KMDAw MDAwMDI2OCA2NTUzNSBmDQowMDAwMDAwMjY5IDY1NTM1IGYNCjAwMDAwMDAyNzAgNjU1MzUgZg0K MDAwMDAwMDI3MSA2NTUzNSBmDQowMDAwMDAwMjcyIDY1NTM1IGYNCjAwMDAwMDAyNzMgNjU1MzUg Zg0KMDAwMDAwMDI3NCA2NTUzNSBmDQowMDAwMDAwMjc1IDY1NTM1IGYNCjAwMDAwMDAyNzYgNjU1 MzUgZg0KMDAwMDAwMDI3NyA2NTUzNSBmDQowMDAwMDAwMjc4IDY1NTM1IGYNCjAwMDAwMDAyNzkg NjU1MzUgZg0KMDAwMDAwMDI4MCA2NTUzNSBmDQowMDAwMDAwMjgxIDY1NTM1IGYNCjAwMDAwMDAy ODIgNjU1MzUgZg0KMDAwMDAwMDI4MyA2NTUzNSBmDQowMDAwMDAwMjg0IDY1NTM1IGYNCjAwMDAw MDAyODUgNjU1MzUgZg0KMDAwMDAwMDI4NiA2NTUzNSBmDQowMDAwMDAwMjg3IDY1NTM1IGYNCjAw MDAwMDAyODggNjU1MzUgZg0KMDAwMDAwMDI4OSA2NTUzNSBmDQowMDAwMDAwMjkwIDY1NTM1IGYN CjAwMDAwMDAyOTEgNjU1MzUgZg0KMDAwMDAwMDI5MiA2NTUzNSBmDQowMDAwMDAwMjkzIDY1NTM1 IGYNCjAwMDAwMDAyOTQgNjU1MzUgZg0KMDAwMDAwMDI5NSA2NTUzNSBmDQowMDAwMDAwMjk2IDY1 NTM1IGYNCjAwMDAwMDAyOTcgNjU1MzUgZg0KMDAwMDAwMDI5OCA2NTUzNSBmDQowMDAwMDAwMjk5 IDY1NTM1IGYNCjAwMDAwMDAzMDAgNjU1MzUgZg0KMDAwMDAwMDMwMSA2NTUzNSBmDQowMDAwMDAw MzAyIDY1NTM1IGYNCjAwMDAwMDAzMDMgNjU1MzUgZg0KMDAwMDAwMDMwNCA2NTUzNSBmDQowMDAw MDAwMzA1IDY1NTM1IGYNCjAwMDAwMDAzMDYgNjU1MzUgZg0KMDAwMDAwMDMwNyA2NTUzNSBmDQow MDAwMDAwMzA4IDY1NTM1IGYNCjAwMDAwMDAzMDkgNjU1MzUgZg0KMDAwMDAwMDMxMCA2NTUzNSBm DQowMDAwMDAwMzExIDY1NTM1IGYNCjAwMDAwMDAzMTIgNjU1MzUgZg0KMDAwMDAwMDMxMyA2NTUz NSBmDQowMDAwMDAwMzE0IDY1NTM1IGYNCjAwMDAwMDAzMTUgNjU1MzUgZg0KMDAwMDAwMDMxNiA2 NTUzNSBmDQowMDAwMDAwMzE3IDY1NTM1IGYNCjAwMDAwMDAzMTggNjU1MzUgZg0KMDAwMDAwMDMx OSA2NTUzNSBmDQowMDAwMDAwMzIwIDY1NTM1IGYNCjAwMDAwMDAzMjEgNjU1MzUgZg0KMDAwMDAw MDMyMiA2NTUzNSBmDQowMDAwMDAwMzIzIDY1NTM1IGYNCjAwMDAwMDAzMjQgNjU1MzUgZg0KMDAw MDAwMDMyNSA2NTUzNSBmDQowMDAwMDAwMzI2IDY1NTM1IGYNCjAwMDAwMDAzMjcgNjU1MzUgZg0K MDAwMDAwMDMyOCA2NTUzNSBmDQowMDAwMDAwMzI5IDY1NTM1IGYNCjAwMDAwMDAzMzAgNjU1MzUg Zg0KMDAwMDAwMDMzMSA2NTUzNSBmDQowMDAwMDAwMzMyIDY1NTM1IGYNCjAwMDAwMDAzMzMgNjU1 MzUgZg0KMDAwMDAwMDMzNCA2NTUzNSBmDQowMDAwMDAwMzM1IDY1NTM1IGYNCjAwMDAwMDAzMzYg NjU1MzUgZg0KMDAwMDAwMDMzNyA2NTUzNSBmDQowMDAwMDAwMzM4IDY1NTM1IGYNCjAwMDAwMDAz MzkgNjU1MzUgZg0KMDAwMDAwMDM0MCA2NTUzNSBmDQowMDAwMDAwMzQxIDY1NTM1IGYNCjAwMDAw MDAzNDIgNjU1MzUgZg0KMDAwMDAwMDM0MyA2NTUzNSBmDQowMDAwMDAwMzQ0IDY1NTM1IGYNCjAw MDAwMDAzNDUgNjU1MzUgZg0KMDAwMDAwMDM0NiA2NTUzNSBmDQowMDAwMDAwMzQ3IDY1NTM1IGYN CjAwMDAwMDAzNDggNjU1MzUgZg0KMDAwMDAwMDM0OSA2NTUzNSBmDQowMDAwMDAwMzUwIDY1NTM1 IGYNCjAwMDAwMDAzNTEgNjU1MzUgZg0KMDAwMDAwMDM1MiA2NTUzNSBmDQowMDAwMDAwMzUzIDY1 NTM1IGYNCjAwMDAwMDAzNTQgNjU1MzUgZg0KMDAwMDAwMDM1NSA2NTUzNSBmDQowMDAwMDAwMzU2 IDY1NTM1IGYNCjAwMDAwMDAzNTcgNjU1MzUgZg0KMDAwMDAwMDM1OCA2NTUzNSBmDQowMDAwMDAw MzU5IDY1NTM1IGYNCjAwMDAwMDAzNjAgNjU1MzUgZg0KMDAwMDAwMDM2MSA2NTUzNSBmDQowMDAw MDAwMzYyIDY1NTM1IGYNCjAwMDAwMDAzNjMgNjU1MzUgZg0KMDAwMDAwMDM2NCA2NTUzNSBmDQow MDAwMDAwMzY1IDY1NTM1IGYNCjAwMDAwMDAzNjYgNjU1MzUgZg0KMDAwMDAwMDM2NyA2NTUzNSBm DQowMDAwMDAwMzY4IDY1NTM1IGYNCjAwMDAwMDAzNjkgNjU1MzUgZg0KMDAwMDAwMDM3MCA2NTUz NSBmDQowMDAwMDAwMzcxIDY1NTM1IGYNCjAwMDAwMDAzNzIgNjU1MzUgZg0KMDAwMDAwMDM3MyA2 NTUzNSBmDQowMDAwMDAwMzc0IDY1NTM1IGYNCjAwMDAwMDAzNzUgNjU1MzUgZg0KMDAwMDAwMDM3 NiA2NTUzNSBmDQowMDAwMDAwMzc3IDY1NTM1IGYNCjAwMDAwMDAzNzggNjU1MzUgZg0KMDAwMDAw MDM3OSA2NTUzNSBmDQowMDAwMDAwMzgwIDY1NTM1IGYNCjAwMDAwMDAzODEgNjU1MzUgZg0KMDAw MDAwMDM4MiA2NTUzNSBmDQowMDAwMDAwMzgzIDY1NTM1IGYNCjAwMDAwMDAzODQgNjU1MzUgZg0K MDAwMDAwMDM4NSA2NTUzNSBmDQowMDAwMDAwMzg2IDY1NTM1IGYNCjAwMDAwMDAzODcgNjU1MzUg Zg0KMDAwMDAwMDM4OCA2NTUzNSBmDQowMDAwMDAwMzg5IDY1NTM1IGYNCjAwMDAwMDAzOTAgNjU1 MzUgZg0KMDAwMDAwMDM5MSA2NTUzNSBmDQowMDAwMDAwMzkyIDY1NTM1IGYNCjAwMDAwMDAzOTMg NjU1MzUgZg0KMDAwMDAwMDM5NCA2NTUzNSBmDQowMDAwMDAwMzk1IDY1NTM1IGYNCjAwMDAwMDAz OTYgNjU1MzUgZg0KMDAwMDAwMDM5NyA2NTUzNSBmDQowMDAwMDAwMzk4IDY1NTM1IGYNCjAwMDAw MDAzOTkgNjU1MzUgZg0KMDAwMDAwMDQwMCA2NTUzNSBmDQowMDAwMDAwNDAxIDY1NTM1IGYNCjAw MDAwMDA0MDIgNjU1MzUgZg0KMDAwMDAwMDQwMyA2NTUzNSBmDQowMDAwMDAwNDA0IDY1NTM1IGYN CjAwMDAwMDA0MDUgNjU1MzUgZg0KMDAwMDAwMDQwNiA2NTUzNSBmDQowMDAwMDAwNDA3IDY1NTM1 IGYNCjAwMDAwMDA0MDggNjU1MzUgZg0KMDAwMDAwMDQwOSA2NTUzNSBmDQowMDAwMDAwNDEwIDY1 NTM1IGYNCjAwMDAwMDA0MTEgNjU1MzUgZg0KMDAwMDAwMDQxMiA2NTUzNSBmDQowMDAwMDAwNDEz IDY1NTM1IGYNCjAwMDAwMDA0MTQgNjU1MzUgZg0KMDAwMDAwMDQxNSA2NTUzNSBmDQowMDAwMDAw NDE2IDY1NTM1IGYNCjAwMDAwMDA0MTcgNjU1MzUgZg0KMDAwMDAwMDQxOCA2NTUzNSBmDQowMDAw MDAwNDE5IDY1NTM1IGYNCjAwMDAwMDA0MjAgNjU1MzUgZg0KMDAwMDAwMDQyMSA2NTUzNSBmDQow MDAwMDAwNDIyIDY1NTM1IGYNCjAwMDAwMDA0MjMgNjU1MzUgZg0KMDAwMDAwMDQyNCA2NTUzNSBm DQowMDAwMDAwNDI1IDY1NTM1IGYNCjAwMDAwMDA0MjYgNjU1MzUgZg0KMDAwMDAwMDQyNyA2NTUz NSBmDQowMDAwMDAwNDI4IDY1NTM1IGYNCjAwMDAwMDA0MjkgNjU1MzUgZg0KMDAwMDAwMDQzMCA2 NTUzNSBmDQowMDAwMDAwNDMxIDY1NTM1IGYNCjAwMDAwMDA0MzIgNjU1MzUgZg0KMDAwMDAwMDQz MyA2NTUzNSBmDQowMDAwMDAwNDM0IDY1NTM1IGYNCjAwMDAwMDA0MzUgNjU1MzUgZg0KMDAwMDAw MDQzNiA2NTUzNSBmDQowMDAwMDAwNDM3IDY1NTM1IGYNCjAwMDAwMDA0MzggNjU1MzUgZg0KMDAw MDAwMDQzOSA2NTUzNSBmDQowMDAwMDAwNDQwIDY1NTM1IGYNCjAwMDAwMDA0NDEgNjU1MzUgZg0K MDAwMDAwMDQ0MiA2NTUzNSBmDQowMDAwMDAwNDQzIDY1NTM1IGYNCjAwMDAwMDA0NDQgNjU1MzUg Zg0KMDAwMDAwMDQ0NSA2NTUzNSBmDQowMDAwMDAwNDQ2IDY1NTM1IGYNCjAwMDAwMDA0NDcgNjU1 MzUgZg0KMDAwMDAwMDQ0OCA2NTUzNSBmDQowMDAwMDAwNDQ5IDY1NTM1IGYNCjAwMDAwMDA0NTAg NjU1MzUgZg0KMDAwMDAwMDQ1MSA2NTUzNSBmDQowMDAwMDAwNDUyIDY1NTM1IGYNCjAwMDAwMDA0 NTMgNjU1MzUgZg0KMDAwMDAwMDQ1NCA2NTUzNSBmDQowMDAwMDAwNDU1IDY1NTM1IGYNCjAwMDAw MDA0NTYgNjU1MzUgZg0KMDAwMDAwMDQ1NyA2NTUzNSBmDQowMDAwMDAwNDU4IDY1NTM1IGYNCjAw MDAwMDA0NTkgNjU1MzUgZg0KMDAwMDAwMDQ2MCA2NTUzNSBmDQowMDAwMDAwNDYxIDY1NTM1IGYN CjAwMDAwMDA0NjIgNjU1MzUgZg0KMDAwMDAwMDQ2MyA2NTUzNSBmDQowMDAwMDAwNDY0IDY1NTM1 IGYNCjAwMDAwMDA0NjUgNjU1MzUgZg0KMDAwMDAwMDQ2NiA2NTUzNSBmDQowMDAwMDAwNDY3IDY1 NTM1IGYNCjAwMDAwMDA0NjggNjU1MzUgZg0KMDAwMDAwMDQ2OSA2NTUzNSBmDQowMDAwMDAwNDcw IDY1NTM1IGYNCjAwMDAwMDA0NzEgNjU1MzUgZg0KMDAwMDAwMDQ3MiA2NTUzNSBmDQowMDAwMDAw NDczIDY1NTM1IGYNCjAwMDAwMDA0NzQgNjU1MzUgZg0KMDAwMDAwMDQ3NSA2NTUzNSBmDQowMDAw MDAwNDc2IDY1NTM1IGYNCjAwMDAwMDA0NzcgNjU1MzUgZg0KMDAwMDAwMDQ3OCA2NTUzNSBmDQow MDAwMDAwNDc5IDY1NTM1IGYNCjAwMDAwMDA0ODAgNjU1MzUgZg0KMDAwMDAwMDQ4MSA2NTUzNSBm DQowMDAwMDAwNDgyIDY1NTM1IGYNCjAwMDAwMDA0ODMgNjU1MzUgZg0KMDAwMDAwMDQ4NCA2NTUz NSBmDQowMDAwMDAwNDg1IDY1NTM1IGYNCjAwMDAwMDA0ODYgNjU1MzUgZg0KMDAwMDAwMDQ4NyA2 NTUzNSBmDQowMDAwMDAwNDg4IDY1NTM1IGYNCjAwMDAwMDA0ODkgNjU1MzUgZg0KMDAwMDAwMDQ5 MCA2NTUzNSBmDQowMDAwMDAwNDkxIDY1NTM1IGYNCjAwMDAwMDA0OTIgNjU1MzUgZg0KMDAwMDAw MDQ5MyA2NTUzNSBmDQowMDAwMDAwNDk0IDY1NTM1IGYNCjAwMDAwMDA0OTUgNjU1MzUgZg0KMDAw MDAwMDQ5NiA2NTUzNSBmDQowMDAwMDAwNDk3IDY1NTM1IGYNCjAwMDAwMDA0OTggNjU1MzUgZg0K MDAwMDAwMDQ5OSA2NTUzNSBmDQowMDAwMDAwNTAwIDY1NTM1IGYNCjAwMDAwMDA1MDEgNjU1MzUg Zg0KMDAwMDAwMDUwMiA2NTUzNSBmDQowMDAwMDAwNTAzIDY1NTM1IGYNCjAwMDAwMDA1MDQgNjU1 MzUgZg0KMDAwMDAwMDUwNSA2NTUzNSBmDQowMDAwMDAwNTA2IDY1NTM1IGYNCjAwMDAwMDA1MDcg NjU1MzUgZg0KMDAwMDAwMDUwOCA2NTUzNSBmDQowMDAwMDAwNTA5IDY1NTM1IGYNCjAwMDAwMDA1 MTAgNjU1MzUgZg0KMDAwMDAwMDUxMSA2NTUzNSBmDQowMDAwMDAwNTEyIDY1NTM1IGYNCjAwMDAw MDA1MTMgNjU1MzUgZg0KMDAwMDAwMDUxNCA2NTUzNSBmDQowMDAwMDAwNTE1IDY1NTM1IGYNCjAw MDAwMDA1MTYgNjU1MzUgZg0KMDAwMDAwMDUxNyA2NTUzNSBmDQowMDAwMDAwNTE4IDY1NTM1IGYN CjAwMDAwMDA1MTkgNjU1MzUgZg0KMDAwMDAwMDUyMCA2NTUzNSBmDQowMDAwMDAwNTIxIDY1NTM1 IGYNCjAwMDAwMDA1MjIgNjU1MzUgZg0KMDAwMDAwMDUyMyA2NTUzNSBmDQowMDAwMDAwNTI0IDY1 NTM1IGYNCjAwMDAwMDA1MjUgNjU1MzUgZg0KMDAwMDAwMDUyNiA2NTUzNSBmDQowMDAwMDAwNTI3 IDY1NTM1IGYNCjAwMDAwMDA1MjggNjU1MzUgZg0KMDAwMDAwMDUyOSA2NTUzNSBmDQowMDAwMDAw NTMwIDY1NTM1IGYNCjAwMDAwMDA1MzEgNjU1MzUgZg0KMDAwMDAwMDUzMiA2NTUzNSBmDQowMDAw MDAwNTMzIDY1NTM1IGYNCjAwMDAwMDA1MzQgNjU1MzUgZg0KMDAwMDAwMDUzNSA2NTUzNSBmDQow MDAwMDAwNTM2IDY1NTM1IGYNCjAwMDAwMDA1MzcgNjU1MzUgZg0KMDAwMDAwMDUzOCA2NTUzNSBm DQowMDAwMDAwNTM5IDY1NTM1IGYNCjAwMDAwMDA1NDAgNjU1MzUgZg0KMDAwMDAwMDU0MSA2NTUz NSBmDQowMDAwMDAwNTQyIDY1NTM1IGYNCjAwMDAwMDA1NDMgNjU1MzUgZg0KMDAwMDAwMDU0NCA2 NTUzNSBmDQowMDAwMDAwNTQ1IDY1NTM1IGYNCjAwMDAwMDA1NDYgNjU1MzUgZg0KMDAwMDAwMDU0 NyA2NTUzNSBmDQowMDAwMDAwNTQ4IDY1NTM1IGYNCjAwMDAwMDA1NDkgNjU1MzUgZg0KMDAwMDAw MDU1MCA2NTUzNSBmDQowMDAwMDAwNTUxIDY1NTM1IGYNCjAwMDAwMDA1NTIgNjU1MzUgZg0KMDAw MDAwMDU1MyA2NTUzNSBmDQowMDAwMDAwNTU0IDY1NTM1IGYNCjAwMDAwMDA1NTUgNjU1MzUgZg0K MDAwMDAwMDU1NiA2NTUzNSBmDQowMDAwMDAwNTU3IDY1NTM1IGYNCjAwMDAwMDA1NTggNjU1MzUg Zg0KMDAwMDAwMDU1OSA2NTUzNSBmDQowMDAwMDAwNTYwIDY1NTM1IGYNCjAwMDAwMDA1NjEgNjU1 MzUgZg0KMDAwMDAwMDU2MiA2NTUzNSBmDQowMDAwMDAwNTYzIDY1NTM1IGYNCjAwMDAwMDA1NjQg NjU1MzUgZg0KMDAwMDAwMDU2NSA2NTUzNSBmDQowMDAwMDAwNTY2IDY1NTM1IGYNCjAwMDAwMDA1 NjcgNjU1MzUgZg0KMDAwMDAwMDU2OCA2NTUzNSBmDQowMDAwMDAwNTY5IDY1NTM1IGYNCjAwMDAw MDA1NzAgNjU1MzUgZg0KMDAwMDAwMDU3MSA2NTUzNSBmDQowMDAwMDAwNTcyIDY1NTM1IGYNCjAw MDAwMDA1NzMgNjU1MzUgZg0KMDAwMDAwMDU3NCA2NTUzNSBmDQowMDAwMDAwNTc1IDY1NTM1IGYN CjAwMDAwMDA1NzYgNjU1MzUgZg0KMDAwMDAwMDU3NyA2NTUzNSBmDQowMDAwMDAwNTc4IDY1NTM1 IGYNCjAwMDAwMDA1NzkgNjU1MzUgZg0KMDAwMDAwMDU4MCA2NTUzNSBmDQowMDAwMDAwNTgxIDY1 NTM1IGYNCjAwMDAwMDA1ODIgNjU1MzUgZg0KMDAwMDAwMDU4MyA2NTUzNSBmDQowMDAwMDAwNTg0 IDY1NTM1IGYNCjAwMDAwMDA1ODUgNjU1MzUgZg0KMDAwMDAwMDU4NiA2NTUzNSBmDQowMDAwMDAw NTg3IDY1NTM1IGYNCjAwMDAwMDA1ODggNjU1MzUgZg0KMDAwMDAwMDU4OSA2NTUzNSBmDQowMDAw MDAwNTkwIDY1NTM1IGYNCjAwMDAwMDA1OTEgNjU1MzUgZg0KMDAwMDAwMDU5MiA2NTUzNSBmDQow MDAwMDAwNTkzIDY1NTM1IGYNCjAwMDAwMDA1OTQgNjU1MzUgZg0KMDAwMDAwMDU5NSA2NTUzNSBm DQowMDAwMDAwNTk2IDY1NTM1IGYNCjAwMDAwMDA1OTcgNjU1MzUgZg0KMDAwMDAwMDU5OCA2NTUz NSBmDQowMDAwMDAwNTk5IDY1NTM1IGYNCjAwMDAwMDA2MDAgNjU1MzUgZg0KMDAwMDAwMDYwMSA2 NTUzNSBmDQowMDAwMDAwNjAyIDY1NTM1IGYNCjAwMDAwMDA2MDMgNjU1MzUgZg0KMDAwMDAwMDYw NCA2NTUzNSBmDQowMDAwMDAwNjA1IDY1NTM1IGYNCjAwMDAwMDA2MDYgNjU1MzUgZg0KMDAwMDAw MDYwNyA2NTUzNSBmDQowMDAwMDAwNjA4IDY1NTM1IGYNCjAwMDAwMDA2MDkgNjU1MzUgZg0KMDAw MDAwMDYxMCA2NTUzNSBmDQowMDAwMDAwNjExIDY1NTM1IGYNCjAwMDAwMDA2MTIgNjU1MzUgZg0K MDAwMDAwMDYxMyA2NTUzNSBmDQowMDAwMDAwNjE0IDY1NTM1IGYNCjAwMDAwMDA2MTUgNjU1MzUg Zg0KMDAwMDAwMDYxNiA2NTUzNSBmDQowMDAwMDAwNjE3IDY1NTM1IGYNCjAwMDAwMDA2MTggNjU1 MzUgZg0KMDAwMDAwMDYxOSA2NTUzNSBmDQowMDAwMDAwNjIwIDY1NTM1IGYNCjAwMDAwMDA2MjEg NjU1MzUgZg0KMDAwMDAwMDYyMiA2NTUzNSBmDQowMDAwMDAwNjIzIDY1NTM1IGYNCjAwMDAwMDA2 MjQgNjU1MzUgZg0KMDAwMDAwMDYyNSA2NTUzNSBmDQowMDAwMDAwNjI2IDY1NTM1IGYNCjAwMDAw MDA2MjcgNjU1MzUgZg0KMDAwMDAwMDYyOCA2NTUzNSBmDQowMDAwMDAwNjI5IDY1NTM1IGYNCjAw MDAwMDA2MzAgNjU1MzUgZg0KMDAwMDAwMDYzMSA2NTUzNSBmDQowMDAwMDAwNjMyIDY1NTM1IGYN CjAwMDAwMDA2MzMgNjU1MzUgZg0KMDAwMDAwMDYzNCA2NTUzNSBmDQowMDAwMDAwNjM1IDY1NTM1 IGYNCjAwMDAwMDA2MzYgNjU1MzUgZg0KMDAwMDAwMDYzNyA2NTUzNSBmDQowMDAwMDAwNjM4IDY1 NTM1IGYNCjAwMDAwMDA2MzkgNjU1MzUgZg0KMDAwMDAwMDY0MCA2NTUzNSBmDQowMDAwMDAwNjQx IDY1NTM1IGYNCjAwMDAwMDA2NDIgNjU1MzUgZg0KMDAwMDAwMDY0MyA2NTUzNSBmDQowMDAwMDAw NjQ0IDY1NTM1IGYNCjAwMDAwMDA2NDUgNjU1MzUgZg0KMDAwMDAwMDY0NiA2NTUzNSBmDQowMDAw MDAwNjQ3IDY1NTM1IGYNCjAwMDAwMDA2NDggNjU1MzUgZg0KMDAwMDAwMDY0OSA2NTUzNSBmDQow MDAwMDAwNjUwIDY1NTM1IGYNCjAwMDAwMDA2NTEgNjU1MzUgZg0KMDAwMDAwMDY1MiA2NTUzNSBm DQowMDAwMDAwNjUzIDY1NTM1IGYNCjAwMDAwMDA2NTQgNjU1MzUgZg0KMDAwMDAwMDY1NSA2NTUz NSBmDQowMDAwMDAwNjU2IDY1NTM1IGYNCjAwMDAwMDA2NTcgNjU1MzUgZg0KMDAwMDAwMDY1OCA2 NTUzNSBmDQowMDAwMDAwNjU5IDY1NTM1IGYNCjAwMDAwMDA2NjAgNjU1MzUgZg0KMDAwMDAwMDY2 MSA2NTUzNSBmDQowMDAwMDAwNjYyIDY1NTM1IGYNCjAwMDAwMDA2NjMgNjU1MzUgZg0KMDAwMDAw MDY2NCA2NTUzNSBmDQowMDAwMDAwNjY1IDY1NTM1IGYNCjAwMDAwMDA2NjYgNjU1MzUgZg0KMDAw MDAwMDY2NyA2NTUzNSBmDQowMDAwMDAwNjY4IDY1NTM1IGYNCjAwMDAwMDA2NjkgNjU1MzUgZg0K MDAwMDAwMDY3MCA2NTUzNSBmDQowMDAwMDAwNjcxIDY1NTM1IGYNCjAwMDAwMDA2NzIgNjU1MzUg Zg0KMDAwMDAwMDY3MyA2NTUzNSBmDQowMDAwMDAwNjc0IDY1NTM1IGYNCjAwMDAwMDA2NzUgNjU1 MzUgZg0KMDAwMDAwMDY3NiA2NTUzNSBmDQowMDAwMDAwNjc3IDY1NTM1IGYNCjAwMDAwMDA2Nzgg NjU1MzUgZg0KMDAwMDAwMDY3OSA2NTUzNSBmDQowMDAwMDAwNjgwIDY1NTM1IGYNCjAwMDAwMDA2 ODEgNjU1MzUgZg0KMDAwMDAwMDY4MiA2NTUzNSBmDQowMDAwMDAwNjgzIDY1NTM1IGYNCjAwMDAw MDA2ODQgNjU1MzUgZg0KMDAwMDAwMDY4NSA2NTUzNSBmDQowMDAwMDAwNjg2IDY1NTM1IGYNCjAw MDAwMDA2ODcgNjU1MzUgZg0KMDAwMDAwMDY4OCA2NTUzNSBmDQowMDAwMDAwNjg5IDY1NTM1IGYN CjAwMDAwMDA2OTAgNjU1MzUgZg0KMDAwMDAwMDY5MSA2NTUzNSBmDQowMDAwMDAwNjkyIDY1NTM1 IGYNCjAwMDAwMDA2OTMgNjU1MzUgZg0KMDAwMDAwMDY5NCA2NTUzNSBmDQowMDAwMDAwNjk1IDY1 NTM1IGYNCjAwMDAwMDA2OTYgNjU1MzUgZg0KMDAwMDAwMDY5NyA2NTUzNSBmDQowMDAwMDAwNjk4 IDY1NTM1IGYNCjAwMDAwMDA2OTkgNjU1MzUgZg0KMDAwMDAwMDcwMCA2NTUzNSBmDQowMDAwMDAw NzAxIDY1NTM1IGYNCjAwMDAwMDA3MDIgNjU1MzUgZg0KMDAwMDAwMDcwMyA2NTUzNSBmDQowMDAw MDAwNzA0IDY1NTM1IGYNCjAwMDAwMDA3MDUgNjU1MzUgZg0KMDAwMDAwMDcwNiA2NTUzNSBmDQow MDAwMDAwNzA3IDY1NTM1IGYNCjAwMDAwMDA3MDggNjU1MzUgZg0KMDAwMDAwMDcwOSA2NTUzNSBm DQowMDAwMDAwNzEwIDY1NTM1IGYNCjAwMDAwMDA3MTEgNjU1MzUgZg0KMDAwMDAwMDcxMiA2NTUz NSBmDQowMDAwMDAwNzEzIDY1NTM1IGYNCjAwMDAwMDA3MTQgNjU1MzUgZg0KMDAwMDAwMDcxNSA2 NTUzNSBmDQowMDAwMDAwNzE2IDY1NTM1IGYNCjAwMDAwMDA3MTcgNjU1MzUgZg0KMDAwMDAwMDcx OCA2NTUzNSBmDQowMDAwMDAwNzE5IDY1NTM1IGYNCjAwMDAwMDA3MjAgNjU1MzUgZg0KMDAwMDAw MDcyMSA2NTUzNSBmDQowMDAwMDAwNzIyIDY1NTM1IGYNCjAwMDAwMDA3MjMgNjU1MzUgZg0KMDAw MDAwMDcyNCA2NTUzNSBmDQowMDAwMDAwNzI1IDY1NTM1IGYNCjAwMDAwMDA3MjYgNjU1MzUgZg0K MDAwMDAwMDcyNyA2NTUzNSBmDQowMDAwMDAwNzI4IDY1NTM1IGYNCjAwMDAwMDA3MjkgNjU1MzUg Zg0KMDAwMDAwMDczMCA2NTUzNSBmDQowMDAwMDAwNzMxIDY1NTM1IGYNCjAwMDAwMDA3MzIgNjU1 MzUgZg0KMDAwMDAwMDczMyA2NTUzNSBmDQowMDAwMDAwNzM0IDY1NTM1IGYNCjAwMDAwMDA3MzUg NjU1MzUgZg0KMDAwMDAwMDczNiA2NTUzNSBmDQowMDAwMDAwNzM3IDY1NTM1IGYNCjAwMDAwMDA3 MzggNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDUxNzIxIDAwMDAwIG4NCjAwMDAw NTIxMDMgMDAwMDAgbg0KMDAwMDA5ODU3MSAwMDAwMCBuDQowMDAwMDk4ODA5IDAwMDAwIG4NCjAw MDAxMzk5MjQgMDAwMDAgbg0KMDAwMDE0MDIyNCAwMDAwMCBuDQowMDAwMjI5NjY4IDAwMDAwIG4N CjAwMDAyMjk5ODggMDAwMDAgbg0KMDAwMDMwNjM5OSAwMDAwMCBuDQowMDAwMzA2NDYwIDAwMDAw IG4NCnRyYWlsZXINCjw8L1NpemUgNzQ5L1Jvb3QgMSAwIFIvSW5mbyAzOCAwIFIvSURbPDQ0Njk5 OTI2NEMxMjI5NDlBNDBCMEE4NEI4M0U4RkYyPjw0NDY5OTkyNjRDMTIyOTQ5QTQwQjBBODRCODNF OEZGMj5dID4+DQpzdGFydHhyZWYNCjMwODE0NA0KJSVFT0YNCnhyZWYNCjAgMA0KdHJhaWxlcg0K PDwvU2l6ZSA3NDkvUm9vdCAxIDAgUi9JbmZvIDM4IDAgUi9JRFs8NDQ2OTk5MjY0QzEyMjk0OUE0 MEIwQTg0QjgzRThGRjI+PDQ0Njk5OTI2NEMxMjI5NDlBNDBCMEE4NEI4M0U4RkYyPl0gL1ByZXYg MzA4MTQ0L1hSZWZTdG0gMzA2NDYwPj4NCnN0YXJ0eHJlZg0KMzIzMjg0DQolJUVPRg== --_002_E4561B14EE2A3E4E9D478EBFB5416E1B196755TK5EX14MBXW653win_-- From pete.mccann@motorola.com Fri Aug 7 15:04:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBCB3A6FA3; Fri, 7 Aug 2009 15:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhKjv9PwqSQH; Fri, 7 Aug 2009 15:04:42 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 25B703A6EF0; Fri, 7 Aug 2009 15:03:49 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-14.tower-55.messagelabs.com!1249682628!86462017!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.12] Received: (qmail 17696 invoked from network); 7 Aug 2009 22:03:48 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (136.182.1.12) by server-14.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Aug 2009 22:03:48 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate2.mot.com (8.14.3/8.14.3) with ESMTP id n77M3mQ8021831; Fri, 7 Aug 2009 15:03:48 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n77M3lAn006219; Fri, 7 Aug 2009 17:03:48 -0500 (CDT) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n77M3lUZ006214; Fri, 7 Aug 2009 17:03:47 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Aug 2009 18:03:25 -0400 Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC056D2B5C@de01exm70.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART telechat review of draft-ietf-behave-nat-behavior-discovery-07 Thread-Index: AcoXquMkCQP0UAOMRZSNr5GWKpVcyQ== From: "McCann Peter-A001034" To: , X-CFilter-Loop: Reflected Cc: behave@ietf.org Subject: [BEHAVE] Gen-ART telechat review of draft-ietf-behave-nat-behavior-discovery-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 22:04:43 -0000 I reviewed the -06 version for last call. The Abstract still has an incorrect expansion of the STUN acronym. My other comments were addressed, and the draft contains several other improvements. -Pete From dthaler@microsoft.com Sat Aug 8 11:29:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCEC3A6C39 for ; Sat, 8 Aug 2009 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiXNhZxAqu0G for ; Sat, 8 Aug 2009 11:29:39 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 65A543A6EE4 for ; Sat, 8 Aug 2009 11:29:10 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 8 Aug 2009 11:29:07 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.621.7; Sat, 8 Aug 2009 11:29:07 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Sat, 8 Aug 2009 11:29:05 -0700 From: Dave Thaler To: "draft-ietf-behave-turn-tcp@tools.ietf.org" Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 Thread-Index: AcoQ8pHnO58KBYnbRjO0tt9j9fIZ2QHYMcMQ Date: Sat, 8 Aug 2009 18:29:03 +0000 Message-ID: References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> In-Reply-To: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 18:29:40 -0000 I have reviewed this doc and have a number of comments. A marked-up PDF with my full comments is at http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-behave-tur= n-tcp-04.pdf Summary of non-editorial-only comments: 1) Are data connections to be closed gracefully or abortively, and does this depend on how the corresponding (peer vs client) connection was closed? 2) When error 447 is returned, section 4.3 says the client MUST wait at least 10 seconds before retrying. I think this is for the _same_ destination IP/port, right? If the client has other destination IP/port pairs to try, they can be tried immediately, correct? 3) Section 4.6 notes that no keepalive mechanism is provided and an application can do this at a higher layer. For NATs between a TURN client and a TURN server, why wouldn't TCP keepalives be a possibility? 4) If I understand the 3rd paragraph of section 5.2, correctly, there's an important limitation/constraint that should be called out early (e.g. in the overview). Normally, TCP clients can open multiple parallel connections (e.g., to a web server) to the same destination address/port. To accomplish this with TURN, it seems that the client needs multiple control connections so it can get multiple allocations, since it can only have one connection to a given peer address/port per allocation, correct? 5) The 5th paragraph of Section 5.2 also implies that it's illegal for a TURN server to refuse to initiate connections based on the XOR-PEER-ADDRESS value. For example, if it refuses to initiate connections to 127.0.0.1 it would be violating a MUST. I'd like to see this relaxed. 6) The draft talks about timing out a peer connection after 30 seconds in section 5.3 if the client never does a ConnectionBind for a connection initiated by a peer. However, section 5.2 has no corresponding rule. This means a client can send a Connect request, and then never open a data connection, and the server will never time out the peer connection. The same rule needs to be added to 5.2 to address this. 7) Continuing on the same point, the security considerations section needs to add a discussion of a memory DoS attack due to the TURN server having to buffer data from a peer while waiting for a ConnectionBind (which may never happen). Currently it has references to docs that contain discussion of bandwidth DoS attacks, but not memory DoS attacks, as far as I can find. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: Thursday, July 30, 2009 1:49 AM > To: behave@ietf.org > Cc: draft-ietf-behave-turn-tcp@tools.ietf.org; 'Behave Chairs' > Subject: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 > > BEHAVE is starting a 3 week working group last call (WGLC), ending > August 19, > for > > draft-ietf-behave-turn-tcp-04 > "Traversal Using Relays around NAT (TURN) Extensions for TCP > Allocations" > > Please send technical comments to the BEHAVE list, and editorial > comments to > the authors. > > Thanks, > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From petithug@acm.org Mon Aug 10 09:52:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E883A6EBA for ; Mon, 10 Aug 2009 09:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KItUH1pJo76W for ; Mon, 10 Aug 2009 09:52:25 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 350873A6E79 for ; Mon, 10 Aug 2009 09:52:25 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id B7087DCC4154; Mon, 10 Aug 2009 16:52:28 +0000 (UTC) Received: from [192.168.1.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id F25EBDCC4152; Mon, 10 Aug 2009 16:52:26 +0000 (UTC) Message-ID: <4A805049.7020709@acm.org> Date: Mon, 10 Aug 2009 09:52:25 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Dave Thaler References: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-behave-turn-uri@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 16:52:26 -0000 Thanks for your review. Please see my answers below. Dave Thaler wrote: > Attached is a copy with my comments. > > Summary of comments that aren't purely editorial: > > 1) Why does this diverge from the generic URI syntax in > RFC 3986 by omitting // before the host part? I went back and forth between a hierarchical URI (i.e. with the //) and and opaque URI (without the //), but the changelog[1] that explain this disappeared between the draft-petithuguenin and the draft-ietf versions (I put back the complete changelog in my local copy of the draft, to be publish at the end of the WGLC). The reason I went back to an opaque URI is because of RFC 4395 Section 2.2. The TURN URI does not describe a hierarchical structure and RFC 4395 advises to use opaque URI in this case. > > 2) The algorithm keep saying convert to "a" TURN transport > "as specified above". However, there's nowhere in the doc > that actually does so. The "as specified above" refers to the fourth paragraph of section 4 ("In some steps..."). I inverted "" and "" in the fourth paragraph so it matches the order used in the steps. I did not find a better way to do not have to repeat the text multiple times. Any advice? > Page 4 _filters_ the list, but > you can end up with multiple (turn/tcp -> TCP and TLS). I am not sure to understand this. The conversion described is for the URI elements i.e.: turn:example.com?transport=udp --> UDP turn:example.com?transport=tcp --> TCP turns:example.com?transport=tcp --> TLS There cannot be multiple conversions at this step. Do you have any suggestion to improve the text? > > 3) Is there any ordering constraint on the order in which > IP addresses are tried or is RFC 3484 sufficient? I think that RFC 3484 is sufficient. Should I add a reference? > > 4) Algorithm step 3 is underspecified. It says it recommends > "A or AAAA query". In constrast step 2 says "A and AAAA > query". Why is step 3 an "or"? I think it should be > "and". Yes, modified on my local copy. I also applied all your editorial modifications. I moved the "Running Code Considerations" section in the "Release Notes" appendix so it will be removed (with the URIs section) before publication (see draft-petithuguenin-running-code-considerations for the motivations and the subsequent discussion on the IETF mailing list on how much people disliked it :-( ) [1] http://tools.ietf.org/rfcdiff?url2=draft-petithuguenin-behave-turn-uri-03.txt -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From aeh@db.org Mon Aug 10 12:41:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C7628C259; Mon, 10 Aug 2009 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.293 X-Spam-Level: X-Spam-Status: No, score=-4.293 tagged_above=-999 required=5 tests=[AWL=2.306, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvOa7aaoGZRP; Mon, 10 Aug 2009 12:41:08 -0700 (PDT) Received: from submit-tmp.sysedata.no (submit-tmp.sysedata.no [195.159.29.133]) by core3.amsl.com (Postfix) with ESMTP id 25A1E28C26C; Mon, 10 Aug 2009 12:40:50 -0700 (PDT) Received: from [84.215.125.199] (helo=[10.0.0.31]) by submit-tmp.sysedata.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Maajf-0005yO-RN; Mon, 10 Aug 2009 21:40:47 +0200 Message-ID: <4A8077BE.6080903@db.org> Date: Mon, 10 Aug 2009 21:40:46 +0200 From: "Alfred E. Heggestad" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: draft-ietf-behave-turn-uri@tools.ietf.org References: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> In-Reply-To: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, behave@ietf.org, 'Behave Chairs' , Dan Wing Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 19:41:09 -0000 Dan Wing wrote: > BEHAVE is starting a 3 week working group last call (WGLC), ending August 19, > for > > draft-ietf-behave-turn-uri-02 > "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers" > > > *** Review by folks familiar with URIs are encouraged. *** > > > Please send technical comments to the BEHAVE list, and editorial comments to > the authors. > I have done a WGLC review of the document draft-ietf-behave-turn-uri-02. The document looks good, it is quite easy to read, and it should be quite easy to implement from reading the text. I do not have any major comments. /alfred From dthaler@microsoft.com Mon Aug 10 16:45:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74DBA3A6C84 for ; Mon, 10 Aug 2009 16:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv8vjNGi69sa for ; Mon, 10 Aug 2009 16:45:38 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 727333A6F08 for ; Mon, 10 Aug 2009 16:45:38 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 10 Aug 2009 16:45:41 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.621.7; Mon, 10 Aug 2009 16:45:42 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 10 Aug 2009 16:43:46 -0700 From: Dave Thaler To: Marc Petit-Huguenin Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 Thread-Index: AcoQ8ov/YM9wzQORRlC6NiHyOFf8mAGqzquQAJ31X4AAANEr8A== Date: Mon, 10 Aug 2009 23:43:46 +0000 Message-ID: References: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> <4A805049.7020709@acm.org> In-Reply-To: <4A805049.7020709@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-turn-uri@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 23:45:39 -0000 Marc Petit-Huguenin wrote: > Dave Thaler wrote: > > 1) Why does this diverge from the generic URI syntax in > > RFC 3986 by omitting // before the host part? > > I went back and forth between a hierarchical URI (i.e. with the //) > and and opaque URI (without the //), but the changelog[1] that > explain this disappeared between the draft-petithuguenin and the > draft-ietf versions (I put back the complete changelog in my local > copy of the draft, to be publish at the end of the WGLC). > > The reason I went back to an opaque URI is because of RFC 4395 > Section 2.2. The TURN URI does not describe a hierarchical > structure and RFC 4395 advises to use opaque URI in this case. Ok. No change needed. > > 2) The algorithm keep saying convert to "a" TURN transport > > "as specified above". However, there's nowhere in the doc > > that actually does so. > > The "as specified above" refers to the fourth paragraph of section 4 > ("In some steps..."). I inverted "" and "" in > the fourth paragraph so it matches the order used in the steps. I > did not find a better way to do not have to repeat the text multiple > times. Any advice? I'd suggest: 1) Right before the paragraph starting "First the resolution algorithm checks that the URI can be resolved" Add a table: TURN Transport -------- ----------- -------------- "turn" "udp" UDP "turn" "tcp" TCP "turns" "tcp" TLS "turns" not defined TLS 2) Change the bullets to say basically: if the scheme and transport match an entry in table 1, but the list of TURN transports supported by the application does not include the corresponding TURN transport, stop with an error. And if there is no matching row, stop with an error. 3) Then when you talk about converting "as specified above", say "as specified in Table 1". > > Page 4 _filters_ the list, but > > you can end up with multiple (turn/tcp -> TCP and TLS). > > I am not sure to understand this. The conversion described is for > the URI elements i.e.: > > turn:example.com?transport=3Dudp --> UDP > turn:example.com?transport=3Dtcp --> TCP > turns:example.com?transport=3Dtcp --> TLS > > There cannot be multiple conversions at this step. Do you have any > suggestion to improve the text? Yes, since your answer above does not match what's in the draft. Specifically, section 4 second bullet states: > o If is defined as "turn" and is defined as > "tcp" but the list of TURN transports does not contain TCP or TLS > then the resolution MUST stop with an error. Hence both of these are legal: turn:example.com?transport=3Dtcp --> TCP turn:example.com?transport=3Dtcp --> TLS If you want to guarantee there's a single possibility only, then delete "or TLS". (The table I suggested above already omits this.) > > 3) Is there any ordering constraint on the order in which > > IP addresses are tried or is RFC 3484 sufficient? > > I think that RFC 3484 is sufficient. Should I add a reference? I'd just say the client can choose an order in any implementation-specific way. (Then no need to reference 3484 and any other alternative is okay too.) -Dave From dthaler@microsoft.com Mon Aug 10 18:28:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54743A6B53 for ; Mon, 10 Aug 2009 18:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmwUyLx658SI for ; Mon, 10 Aug 2009 18:28:21 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 19A4B3A6B47 for ; Mon, 10 Aug 2009 18:28:21 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 10 Aug 2009 18:28:24 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.621.7; Mon, 10 Aug 2009 18:28:24 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 10 Aug 2009 18:27:54 -0700 From: Dave Thaler To: Bruce Lowekamp Thread-Topic: Comments on draft-ietf-behave-sctpnat-01 Thread-Index: AQHKGiLeDqnWLGFXFUeWIjmTWRqbFw== Date: Tue, 11 Aug 2009 01:27:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ietf-behave-sctpnat@tools.ietf.org" , "behave@ietf.org" Subject: [BEHAVE] Comments on draft-ietf-behave-sctpnat-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 01:28:22 -0000 SSBqdXN0IHJlYWQgdGhpcyBkb2N1bWVudCBmb3IgdGhlIGZpcnN0IHRpbWUsIGFuZCB0aGVyZSBh cmUgc3RpbGwNCnNpZ25pZmljYW50IGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkLiAg TXkgY29tbWVudHMsIGJvdGgNCnRlY2huaWNhbCBhbmQgZWRpdG9yaWFsLCBhcmUgYXQNCmh0dHA6 Ly9yZXNlYXJjaC5taWNyb3NvZnQuY29tL2VuLXVzL3VtL3Blb3BsZS9kdGhhbGVyL2RyYWZ0LWll dGYtYmVoYXZlLXNjdHBuYXQtMDEucGRmDQoNCkEgZmV3IG9mIG15IGNvbW1lbnRzIGR1cGxpY2F0 ZSB0aGluZ3MgYWxyZWFkeSBkaXNjdXNzZWQgbGlrZSB0aGUgZmFjdCB0aGF0DQppdCBjb250YWlu cyBub3JtYXRpdmUgY2hhbmdlcyB0byA0NjkwLiAgSSBhZ3JlZSB3aXRoIHRoZSBwcm9wb3NhbCB0 bw0KcmVtb3ZlIHRoZW0gZnJvbSB0aGlzIGRyYWZ0Lg0KDQpJIHdvbid0IGRldGFpbCBoZXJlIHRo ZSBvdGhlciB0ZWNobmljYWwgaXNzdWVzIEkgZm91bmQgKHlvdSBjYW4gZmluZCB0aGVtDQppbiB0 aGUgUERGKSBidXQgYSBoaWdoIGxldmVsIHN1bW1hcnkgaXMgdGhhdCB0aGVyZSBpcyBzdGlsbCBh IGJ1bmNoIG9mDQpsb2dpYyBtaXNzaW5nLCBzaW5jZSB0aGUgZXhhbXBsZXMgZG9uJ3QgbWF0Y2gg dGhlIHByZXNjcmlwdGl2ZSBiZWhhdmlvcg0KdGhhdCBjdXJyZW50bHkgZXhpc3RzIGluIHNlY3Rp b24gNSAodGhlIGJlaGF2aW9yIHRoZXJlIG1vc3RseSBtYXRjaGVzLA0KYnV0IHRoZSBleGFtcGxl cyBzaG93IGEgbG90IG1vcmUgdGhpbmdzIHRoYXQgYXJlbid0IHNwZWNpZmllZCBhbnl3aGVyZQ0K aW4gdGhlIGRvYykuDQoNCi1EYXZlDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQnJ1Y2UgTG93ZWthbXAgW21haWx0bzpiYmxAbG93ZWthbXAubmV0XQ0KPiBTZW50OiBN b25kYXksIEp1bHkgMjcsIDIwMDkgMTI6MzggQU0NCj4gVG86IGJlaGF2ZUBpZXRmLm9yZzsgQmVo YXZlIENoYWlyczsgZHJhZnQtaWV0Zi1iZWhhdmUtDQo+IHNjdHBuYXRAdG9vbHMuaWV0Zi5vcmcN Cj4gU3ViamVjdDogb3BlbiBpc3N1ZXMgaW4gZHJhZnQtaWV0Zi1iZWhhdmUtc2N0cG5hdC0wMQ0K Pg0KPiBUaGVyZSB3YXMgYSB0aHJlYWQgb24gdGhlIGJlaGF2ZSBtYWlsaW5nIGxpc3Qgd2l0aCB0 aGUgc3ViamVjdCAiU0NUUA0KPiBOQVQgcXVlc3Rpb25zIGFuZCBjb25jZXJucyIgdGhhdCBzdGFy dGVkIG9uIDExLzIwLzA4IGFuZCByYW4gdGhyb3VnaA0KPiAxMS8yMi8wOCB3aXRoIGEgZmV3IGFk ZGl0aW9uYWwgY29tbWVudHMgZnJvbSBEYW4gb24gMTIvMTcuICBNeSBiZWxpZWYNCj4gaXMgdGhh dCB0aGVyZSB3ZXJlIGEgbnVtYmVyIG9mIGlzc3VlcyBpZGVudGlmaWVkIGluIHRoYXQgdGhyZWFk IHRoYXQNCj4gd2VyZSBub3QgYWRkcmVzc2VkIGJ5IHRoZSAtMDEgcmV2aXNpb24uICBJdCdzIGJl ZW4gYXdoaWxlLCBidXQgSSdtDQo+IGdvaW5nIHRvIHRyeSB0byBzdW1tYXJpemUgc29tZSBvZiB0 aGUgb3BlbiBpc3N1ZXM6DQo+DQo+IC0gdGhlIGRyYWZ0IGRvZXMgbm90IHVzZSB0aGUgc2FtZSB0 ZXJtaW5vbG9neSBhcyA0Nzg3IHRvIGRlc2NyaWJlIE5BVA0KPiBiZWhhdmlvci4gIChNYWdudXMg YWxzbyBzdGFydGVkIGEgdGhyZWFkIG9uIDExLzIwIHRoYXQgZGlzY3Vzc2VkDQo+IHRlcm1pbm9s b2d5IGhlcmUgaW4gbW9yZSBkZXRhaWwuKSAgSXQgYWxzbyBkb2VzIG5vdCB1c2UgdGhlIHNhbWUN Cj4gZm9ybWF0IHRvIGRlZmluZSBhIGxpc3Qgb2YgcmVxdWlyZW1lbnRzLCB3aGljaCBtYXkgYmUg ZGVzaXJhYmxlIGZvcg0KPiB1bmlmb3JtaXR5Lg0KPg0KPiAtIHRoZSBkcmFmdCBpcyBCQ1AsIGJ1 dCBzcGVjaWZpZXMgbm9ybWF0aXZlIGNoYW5nZXMgdG8gU0NUUA0KPg0KPiAtIHRoZSBzcGVjaWZp ZWQgY2hhbmdlcyB0byBTQ1RQIChOQVRfU1VQUE9SVEVEKSBlc3NlbnRpYWxseSBvbmx5DQo+IGlu dGVyb3BlcmF0ZSB3aXRoIG90aGVyIHNpbWlsYXJseSBlbmhhbmNlZCBTQ1RQIGltcGxlbWVudGF0 aW9ucywgc28NCj4gbm9uLU5BVC1hd2FyZSBpbXBsZW1lbnRhdGlvbnMgZG9uJ3QgYmVuZWZpdCBm cm9tIHRoZSBTQ1RQIE5BVA0KPg0KPiAtICBJbiB0aGUgd29ybGQgd2UgYXJlIHF1aWNrbHkgaHVy dGxpbmcgdG93YXJkLA0KPiB0aGVyZSB3aWxsIGJlIG5vIHdheSB0byB0ZWxsIGlmIHlvdSBhcmUg Z29pbmcgdGhyb3VnaCBhIE5BVC4gIEJldHdlZW4NCj4gTkFUNDQ0LCBOQVQ0NiwgYW5kIE5BVDY0 LCB5b3UgY2FuIGhhdmUgYSBwdWJsaWMgSVAgYWRkcmVzcw0KPiBjb21tdW5pY2F0aW5nIHdpdGgg YW5vdGhlciBwdWJsaWMgSVAgYWRkcmVzcyB0aGF0IGdvZXMgdGhyb3VnaCBhIE5BVC4NCj4gSWYg eW91IHdhbnQgdGhhdCB0byB3b3JrIHdpdGggU0NUUCwgSSB0aGluayB0aGUgaW1wbGljYXRpb24g aXMgdGhhdA0KPiB0aGlzIGZsYWcgbmVlZHMgdG8gYWx3YXlzIGJlIHNldCwgd2hpY2ggZWxpbWlu YXRlcyByZXN0YXJ0IGZyb20gdGhlDQo+IFNDVFAgZmVhdHVyZSBzZXQuDQo+DQo+IC0gdGhlIGRy YWZ0IG5lZWRzIHRvIGNsZWFybHkgc3RhdGUgdGhhdCBhIHJlbmRlenZvdXMgc2VydmljZSBpcw0K PiBuZWNlc3NhcnkgdG8gZXhjaGFuZ2UgdnRhZ3MgdG8gbWFrZSBhIGNvbm5lY3Rpb24NCj4NCj4g LSBvdmVybG9hZGluZyB0aGUgdnRhZyB0byBwcm92aWRlIG11bHRpcGxleGluZyBzdXBwb3J0IG1h eSByZWR1Y2UgaXRzDQo+IHVzZWZ1bG5lc3MgZm9yIHNlY3VyaXR5IGFuZCBmcmVzaG5lc3MuICAo SSB0aGluayB0aGlzIGNvbW1lbnQgd2FzIG1vcmUNCj4gdGhhdCB0aGlzIHNob3VsZCBiZSBleHBs aWNpdGx5IGFja25vd2xlZGdlZCByYXRoZXIgdGhhbiBpdCBiZWluZyBhDQo+IHByb2JsZW0gdG8g ZG8gc28uKQ0KPg0KPiAtIGlmIGEgTkFUIG5lZWRzIHRvIHNlbmQgYW4gQUJPUlQgdG8gZm9yY2Ug YW4gU0NUUCBhcHAgdG8gcGljayBhDQo+IGRpZmZlcmVudCBwb3J0LCB0aGlzIGhhcyBzaWduaWZp Y2FudCBpbXBsaWNhdGlvbnMgZm9yIGFwcGxpY2F0aW9uDQo+IGRlc2lnbiwgc2luY2UgdGhleSBt YXkgaGF2ZSBhbHJlYWR5IHB1Ymxpc2hlZCB0aGVpciBjaG9zZW4gcG9ydCB2aWENCj4gYW5vdGhl ciBtZWNoYW5pc20NCj4NCj4gSSB0aGluayB0aGVyZSB3ZXJlIGEgZmV3IG90aGVyIGlzc3VlcyBy YWlzZWQgaW4gdGhlIHRocmVhZCwgYXMgd2VsbC4NCg0K From Michael.Tuexen@lurchi.franken.de Tue Aug 11 00:44:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0E43A69F3 for ; Tue, 11 Aug 2009 00:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.208 X-Spam-Level: ** X-Spam-Status: No, score=2.208 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsZAN5fGaFWJ for ; Tue, 11 Aug 2009 00:44:48 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 358EC3A6FBF for ; Tue, 11 Aug 2009 00:44:24 -0700 (PDT) Received: from [192.168.1.100] (p508FEBBD.dip.t-dialin.net [80.143.235.189]) by mail-n.franken.de (Postfix) with ESMTP id 18B891C0C0BCC; Tue, 11 Aug 2009 09:44:26 +0200 (CEST) Message-Id: <4755150A-18EE-4B45-AA80-60CF82C4B9CF@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Dave Thaler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 09:44:25 +0200 References: X-Mailer: Apple Mail (2.936) Cc: "behave@ietf.org" , "draft-ietf-behave-sctpnat@tools.ietf.org" Subject: Re: [BEHAVE] Comments on draft-ietf-behave-sctpnat-01 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 07:44:49 -0000 Hi Dave, thank you very much for the comments. We'll incorporate them during the splitting of the document. Best regards Michael On Aug 11, 2009, at 3:27 AM, Dave Thaler wrote: > I just read this document for the first time, and there are still > significant issues that need to be addressed. My comments, both > technical and editorial, are at > http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-behave-sctpnat-01.pdf > > A few of my comments duplicate things already discussed like the > fact that > it contains normative changes to 4690. I agree with the proposal to > remove them from this draft. > > I won't detail here the other technical issues I found (you can find > them > in the PDF) but a high level summary is that there is still a bunch of > logic missing, since the examples don't match the prescriptive > behavior > that currently exists in section 5 (the behavior there mostly matches, > but the examples show a lot more things that aren't specified anywhere > in the doc). > > -Dave > >> -----Original Message----- >> From: Bruce Lowekamp [mailto:bbl@lowekamp.net] >> Sent: Monday, July 27, 2009 12:38 AM >> To: behave@ietf.org; Behave Chairs; draft-ietf-behave- >> sctpnat@tools.ietf.org >> Subject: open issues in draft-ietf-behave-sctpnat-01 >> >> There was a thread on the behave mailing list with the subject "SCTP >> NAT questions and concerns" that started on 11/20/08 and ran through >> 11/22/08 with a few additional comments from Dan on 12/17. My belief >> is that there were a number of issues identified in that thread that >> were not addressed by the -01 revision. It's been awhile, but I'm >> going to try to summarize some of the open issues: >> >> - the draft does not use the same terminology as 4787 to describe NAT >> behavior. (Magnus also started a thread on 11/20 that discussed >> terminology here in more detail.) It also does not use the same >> format to define a list of requirements, which may be desirable for >> uniformity. >> >> - the draft is BCP, but specifies normative changes to SCTP >> >> - the specified changes to SCTP (NAT_SUPPORTED) essentially only >> interoperate with other similarly enhanced SCTP implementations, so >> non-NAT-aware implementations don't benefit from the SCTP NAT >> >> - In the world we are quickly hurtling toward, >> there will be no way to tell if you are going through a NAT. Between >> NAT444, NAT46, and NAT64, you can have a public IP address >> communicating with another public IP address that goes through a NAT. >> If you want that to work with SCTP, I think the implication is that >> this flag needs to always be set, which eliminates restart from the >> SCTP feature set. >> >> - the draft needs to clearly state that a rendezvous service is >> necessary to exchange vtags to make a connection >> >> - overloading the vtag to provide multiplexing support may reduce its >> usefulness for security and freshness. (I think this comment was >> more >> that this should be explicitly acknowledged rather than it being a >> problem to do so.) >> >> - if a NAT needs to send an ABORT to force an SCTP app to pick a >> different port, this has significant implications for application >> design, since they may have already published their chosen port via >> another mechanism >> >> I think there were a few other issues raised in the thread, as well. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From petithug@acm.org Tue Aug 11 08:29:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8737A3A6885 for ; Tue, 11 Aug 2009 08:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FfB7MjbhFm4 for ; Tue, 11 Aug 2009 08:29:40 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id C22293A69A2 for ; Tue, 11 Aug 2009 08:29:22 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 6F96BDCC4154; Tue, 11 Aug 2009 15:26:23 +0000 (UTC) Received: from [192.168.1.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id A8089DCC4152; Tue, 11 Aug 2009 15:26:21 +0000 (UTC) Message-ID: <4A818D9C.2030804@acm.org> Date: Tue, 11 Aug 2009 08:26:20 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Dave Thaler References: <0a9801ca10f2$8f933600$5f7d150a@cisco.com> <4A805049.7020709@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-uri-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:29:41 -0000 Dave Thaler wrote: > Marc Petit-Huguenin wrote: >> Dave Thaler wrote: [...] >>> 2) The algorithm keep saying convert to "a" TURN transport >>> "as specified above". However, there's nowhere in the doc >>> that actually does so. >> The "as specified above" refers to the fourth paragraph of section 4 >> ("In some steps..."). I inverted "" and "" in >> the fourth paragraph so it matches the order used in the steps. I >> did not find a better way to do not have to repeat the text multiple >> times. Any advice? > > I'd suggest: > 1) Right before the paragraph starting > "First the resolution algorithm checks that the URI can be resolved" > Add a table: > > TURN Transport > -------- ----------- -------------- > "turn" "udp" UDP > "turn" "tcp" TCP > "turns" "tcp" TLS > "turns" not defined TLS > > 2) Change the bullets to say basically: if the scheme and transport > match an entry in table 1, but the list of TURN transports > supported by the application does not include the corresponding > TURN transport, stop with an error. And if there is no matching > row, stop with an error. > > 3) Then when you talk about converting "as specified above", say > "as specified in Table 1". The table is a good idea, thanks. > >>> Page 4 _filters_ the list, but >>> you can end up with multiple (turn/tcp -> TCP and TLS). >> I am not sure to understand this. The conversion described is for >> the URI elements i.e.: >> >> turn:example.com?transport=udp --> UDP >> turn:example.com?transport=tcp --> TCP >> turns:example.com?transport=tcp --> TLS >> >> There cannot be multiple conversions at this step. Do you have any >> suggestion to improve the text? > > Yes, since your answer above does not match what's in the draft. > Specifically, section 4 second bullet states: > >> o If is defined as "turn" and is defined as >> "tcp" but the list of TURN transports does not contain TCP or TLS >> then the resolution MUST stop with an error. > > Hence both of these are legal: > turn:example.com?transport=tcp --> TCP > turn:example.com?transport=tcp --> TLS > > If you want to guarantee there's a single possibility only, then > delete "or TLS". (The table I suggested above already omits this.) OK, I see what the misunderstanding is. I pasted the revised Section 4 at the end of this email. Can you please read it again, trying to forget the previous version, and let me know if it makes sense now? There is an additional issue in the "...does not contain TCP or TLS" sentence. The motivation for this sentence was to permit to use TLS if TLS was the only protocol available, even if the TURN URI requested TCP (the opposite will fail, see bullet 4). The issue is that there is no text in the resolution steps that explain how to do this. But perhaps doing this kind of "upgrade" from TCP to TLS is a mistake. So before adding the missing text in the resolution steps, I would like to know what people think of this. > >>> 3) Is there any ordering constraint on the order in which >>> IP addresses are tried or is RFC 3484 sufficient? >> I think that RFC 3484 is sufficient. Should I add a reference? > > I'd just say the client can choose an order in any implementation-specific > way. (Then no need to reference 3484 and any other alternative is okay > too.) Done. ------------------------------------------------------------------------------- The URI resolution mechanism is used only to create an allocation. All other transactions use the IP address, transport and port used for a successful allocation creation. The URI resolution algorithm uses , , and as input. It also uses as input a list ordered by preference of TURN transports (UDP, TCP, TLS) supported by the application using the TURN client. The output of the algorithm is a list of {IP address, transport, port} tuples that a TURN client can try in order to create an allocation on a TURN server. An Allocate error response as specified in section 6.4 of [I-D.ietf-behave-turn] is processed as a failure as specified by [RFC3958] section 2.2.4. The resolution stops when a TURN client gets a successful Allocate response from a TURN server. After an allocation succeeds or all the allocations fail, the resolution context MUST be discarded and the URI resolution algorithm MUST be restarted from the beginning for any subsequent allocation. Servers blacklisted as described in section 6.4 of [I-D.ietf-behave-turn] should not be used for the specified duration even if returned by a subsequent resolution. First the resolution algorithm checks that the URI can be resolved with the list of TURN transports supported by the application: o If is defined as "turn" and is defined as "udp" but the list of TURN transports supported by the application does not contain UDP then the resolution MUST stop with an error. o If is defined as "turn" and is defined as "tcp" but the list of TURN transports supported by the application does not contain TCP or TLS then the resolution MUST stop with an error. o If is defined as "turns" and is defined as "udp" then the algorithm MUST stop with an error. o If is defined as "turns" and is defined as "tcp" but the list of TURN transports supported by the application does not contain TLS then the resolution MUST stop with an error. o If is defined as "turns" and is not defined but the list of TURN transports supported by the application does not contain TLS then the resolution MUST stop with an error. o If is defined but unknown then the resolution MUST stop with an error. After verifying the validity of the URI elements, the algorithm applies the steps described below. Note that in some steps, and have to be converted to a TURN transport. If is defined as "turn" and is defined as "udp" then the TURN UDP transport is used. If is defined as "turn" and is defined as "tcp" then the TURN TCP transport is used. If is defined as "turns" and is defined as "tcp" then the TURN TLS transport is used. This is summarized in Table 1. +----------+-------------+----------------+ | | | TURN Transport | +----------+-------------+----------------+ | "turn" | "udp" | UDP | | "turn" | "tcp" | TCP | | "turns" | "tcp" | TLS | +----------+-------------+----------------+ Table 1 1. If is an IP address then it indicates the specific IP address to be used. If is not defined, the default port declared in [I-D.ietf-behave-turn] for the SRV service name defined in is used. If is defined then and are converted to a TURN transport as specified in Table 1. If is not defined, the TURN transports supported by the application are tried by preference order. If the TURN client cannot contact a TURN server with this IP address and port on any of the transports supported by the application then the resolution MUST stop with an error. 2. If is a domain name and is defined, then is resolved to a list of IP addresses via DNS A and AAAA queries. If is defined, then and are converted to a TURN transport as specified in Table 1. If is not defined, the TURN transports supported by the application are tried in preference order. If the TURN client cannot contact a TURN server with this port and any combination of transports supported by the application and resolved IP addresses then the resolution MUST stop with an error. The TURN client can choose the order to contact the resolved IP addresses in any implementation-specific way. 3. If is a domain name and is not defined but is defined, then is converted to a list of IP address and port tuples via a DNS SRV query as defined in [I-D.ietf-behave-turn] section 6.1. is used for the service name and is used for the protocol name in the SRV algorithm [RFC2782]. If the TURN client cannot contact a TURN server at any of the IP address, port and transport tuples returned by the SRV algorithm then the resolution MUST stop with an error. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR. In this case the default port declared in [I-D.ietf-behave-turn] for the SRV service name defined in must be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. 4. If is a domain name and and are not defined, then is converted to an ordered list of IP address, port and transport tuples via the S-NAPTR algorithm defined in [RFC3958] with a "RELAY" Application Service Tag. The TURN transports supported by the application are converted in Application Protocol Tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP and "turn.tls" if the TURN transport is TLS. The order to try the protocol tags is provided by the ranking of the first set of NAPTR records. If multiple protocol tags have the same ranking, the preferred order set by the application is used. If the TURN client cannot contact a TURN server with any of the IP address, port and transport tuples returned by the S-NAPTR algorithm, then the resolution MUST stop with an error. If the first NAPTR SRV query does not return any result then is converted to a list of IP address and port tuples by using the algorithm specified in step 3 for each of the TURN transports supported by the application in order of preference. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From maxpassion@gmail.com Wed Aug 12 09:40:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B71F3A6C22 for ; Wed, 12 Aug 2009 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-A8-73dZjpl for ; Wed, 12 Aug 2009 09:39:59 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id EDB1A3A6C39 for ; Wed, 12 Aug 2009 09:39:52 -0700 (PDT) Received: by vws34 with SMTP id 34so128194vws.31 for ; Wed, 12 Aug 2009 09:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yYvb6N9q2MM5SboOKfzrYBh17WcAcF6mpCVWNAU0J4c=; b=iqxr5+e12mZlBYM+Uo367C8MlFtuXPKkEef2kJmDYxXNQyE/TRQ+N9jr4lkZ7x01+i tS8+oyySFT05dbaEBK27iiluIDK5dawZLkQBjgugWATqyqepQFZ9FY+VCMZKuiCfur9w f1xkg9cgUdmFS5btOoZ80OoOif/fXd/RSH408= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f759f/U+bp6aVG7ar8p8Op2bz6P6Rc0bRHdqbOmsOePMDtKXqRNpux0HD7eBF8Lpiw /FvYudVauLLxzIhIz/hUf31SkfES9RhS82r2nWNlgZZFKnZy1/xCvphgypDYolTRGWTQ cN1I7l0QTrDGA6dACBQedOyIwhXgbLugD/8vM= MIME-Version: 1.0 Received: by 10.220.102.211 with SMTP id h19mr286807vco.90.1250095086532; Wed, 12 Aug 2009 09:38:06 -0700 (PDT) In-Reply-To: References: <20090709170002.159BD28C179@core3.amsl.com> <00A4B478-E832-4E9E-8135-39854C7196CB@muada.com> <25e1aaa40907140154q14c2fcb0mbd588120b0b34c27@mail.gmail.com> <7C1106B5-E72D-4D51-B332-737CB5116FA0@muada.com> <25e1aaa40907151038t463d9de2v3ffa14c90cc6a60d@mail.gmail.com> <1E998B28-0A29-412B-B312-2A8E85E0BDC7@muada.com> <25e1aaa40907201902m35c937e3r2455e6c2e298f757@mail.gmail.com> <25e1aaa40907230353k3f5e71e3qd4c34b6827fe8004@mail.gmail.com> Date: Thu, 13 Aug 2009 00:38:06 +0800 Message-ID: <25e1aaa40908120938s2df10cb3n2f6486a2d3fc9077@mail.gmail.com> From: liu dapeng To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] Fwd: I-D Action:draft-van-beijnum-behave-ftp64-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 16:40:00 -0000 2009/7/23, Iljitsch van Beijnum : > On 23 jul 2009, at 12:53, liu dapeng wrote: > >> But I am still wondering that why we have to use the IPv4 connectivity >> to set up the data connection? > > Wouldn't it be better to use native connectivity (IPv4) rather than go > through a translator (IPv6)? > >> Should we encourage the user to use IPv6 address whenever it is >> possible? This can encourages the user to tranfer to the IPv6 network. >> Besides, we can simify FTP client implemention as well. > > How about this: MAY connect to the IPv4 address or MAY connect to the > server's IPv6 address. Then implementers can decide what they prefer. Hi Iljitsch, It seems that you didnot update version 5 of the draft according to this? BR, Dapeng Liu > Iljitsch > From maxpassion@gmail.com Wed Aug 12 10:22:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B236D3A67B7 for ; Wed, 12 Aug 2009 10:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yviPoldQEgcD for ; Wed, 12 Aug 2009 10:22:19 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 87D6C3A68BE for ; Wed, 12 Aug 2009 10:22:19 -0700 (PDT) Received: by vws34 with SMTP id 34so155713vws.31 for ; Wed, 12 Aug 2009 10:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z6udVnY/WIqqzvHaGjPCXEnFYNPvUklPpa3epLDtsU0=; b=cq+EYYLud9G8gDDri8wyQytLjkmfIMv6ltdYq9OinkGTrsyczKISQWRs3t1yE6+HzZ Ft9jlLQDorh+h8zNxMWXRKdq4VaMjtLBZ47+U3SvGY53qS/Q+kYfBZU/W0yfBk+QqNUm +XkMUSKcuLBJ+QjSpiFYKOjnPTOju9s9FxV8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VSmLMc2m7tdTH1xCXIGtLifAS6gVz8IS2aerlJmBUgMGAYx7PERP4THtCF5/05eXVx 1Ug3zpxR0i03GcOLdmTfdw77112+TAZ4Suf8RlJySMgrc0b3KLWFgE3pkXQ6M8IkrM4O MQvhqZsafScx7uV8UvdRtJBZNyd3zcP4D46IY= MIME-Version: 1.0 Received: by 10.220.44.146 with SMTP id a18mr358896vcf.11.1250097543924; Wed, 12 Aug 2009 10:19:03 -0700 (PDT) In-Reply-To: <4A72F0BF.4000609@viagenie.ca> References: <4A72F0BF.4000609@viagenie.ca> Date: Thu, 13 Aug 2009 01:19:03 +0800 Message-ID: <25e1aaa40908121019o582694f1u79256876bfad4104@mail.gmail.com> From: liu dapeng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 17:22:20 -0000 2009/7/31, Simon Perreault : > Hello, > > This is an implementation issue that I hadn't fully grasped before my > talk. Now I have, and I propose a fix. > > Imagine you have a DNS64 server with IPv4 and IPv6 addresses. In the > process of recursing, it may synthesize AAAA records for upstream > servers that it wants to contact. It will then end up sending DNS > requests to the NAT64 device whereas they should have gone directly over > IPv4. This is the first problem. ==> Why the DNS64 synthesize AAAA records for upstream DNS servers? Since DNS64 has both IPv4 and IPv6 address, why not use its IPv4 interface to send the recurse query to the upstream DNS if the upstream DNS has an IPv4 address? BR, Dapeng Liu > The second problem is that it is not even certain that the NAT64 device > is accessible from the DNS64 server. I can imagine useful and common > real-life deployments where it will not be the case. > > This last problem could be fixed by ignoring it. The IPv6 request will > time out quickly (assuming we receive an ICMP error) and IPv4 will > become preferred for future requests (or so I understood from chatting > with a DNS server implementor). > > But the first problem remains even if the NAT64 device is accessible. > Therefore, I suggest that we add something along the line of the > following to the draft: > > A DNS64 implementation MUST provide a configuration directive > specifying whether it is allowed to send requests to synthetic IPv6 > addresses while it is recursing. > > Note: If the DNS64 has a usable IPv4 connection, it is expected > that the directive will be set to false. Otherwise, and if the > DNS64 can reach the IPv4/IPv6 translator, it is expected that the > directive will be set to true. > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From stig@venaas.com Thu Aug 13 16:20:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0044C3A68B9 for ; Thu, 13 Aug 2009 16:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVElIVmsbo+m for ; Thu, 13 Aug 2009 16:20:06 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 992F53A6945 for ; Thu, 13 Aug 2009 16:20:05 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id 5F9A933D1D; Fri, 14 Aug 2009 01:20:08 +0200 (CEST) Message-ID: <4A849FA1.2040301@venaas.com> Date: Thu, 13 Aug 2009 16:20:01 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dave Thaler References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behave WG Subject: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 23:20:07 -0000 Dave Thaler wrote: > At IETF, Dan asked WG participants to comment on the choice of mechanism, > between DNS, DHCP, and RAs. I've done a bit of research and I'd like to now > provide my recommendation, which is: DHCP. > > Rationale: > > 1) Changing Windows host stacks is not required. Windows provides a > public API to get any new DHCP option (e.g., see > http://msdn.microsoft.com/en-us/library/aa363345(VS.85).aspx for DHCPv4 and > http://msdn.microsoft.com/en-us/library/aa363327(VS.85).aspx for DHCPv6). > That means it's just a tool or daemon that anyone could write, and in > fact it's simpler to write than an RA solution, and either simpler or > about the same as a DNS solution). I wish there was a standard way to do this on other platforms. The main issue I see with DHCP and RA is how to give applications access to the information in a standard/portable way. With DNS it is easy. > 2) Changing DHCP server code is not required. DHCP servers I'm aware > of (including Windows and ISC's - see > http://node1.yo-linux.com/cgi-bin/man2html?cgi_command=dhcp-options) > allow an administrator to enter arbitrary options (e.g., in hex). > That means a human can already do it with some effort, and it's > straightforward to make a user-friendly tool to do it. This is simpler > than a RA solution, and about the same as a DNS solution. Agree > 3) DHCP is the standard general-purpose mechanism for configuring hosts > with information that the local router isn't authoritative for, which > is the scenario here. Hence it's more appropriate than either DNS or > RAs, and is consistent with RFC 5505 principles. Also routers, DHCP > servers, and DNS servers may be managed by different people in many > enterprises, and it's the DHCP server administrator that does host > configuration. Agree on this as well, and am also in favour of DHCP. > 4) If there are folks (not me) that really believe in RA configuration > for information that the local router isn't authoritative for, > there's already interest in defining an RA option that can contain > DHCP options so you don't have to define RA options for all of them. > So anyone arguing for RAs should be happy here too. I'm not sure about this. There may be semantics of DHCP options that don't easily map to their usage in RAs. Stig > -Dave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From maxpassion@gmail.com Fri Aug 14 07:09:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5F73A6951 for ; Fri, 14 Aug 2009 07:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clXboi85jUAC for ; Fri, 14 Aug 2009 07:09:23 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 12E553A689A for ; Fri, 14 Aug 2009 07:09:19 -0700 (PDT) Received: by vws34 with SMTP id 34so1379050vws.31 for ; Fri, 14 Aug 2009 07:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NAGioDmIPNKCVB4D/Swet3M+C7NiyXOgYB/1+1CtAdQ=; b=nOgbZftyYtUolbWFCW9qQRM8NpGcb4yiel3mbyEYhmj9ov95eophItzwkes+ezgmwY Qyiy9FKCB6aisN48r8EPQIDTRelvGlnrRME97oO/QMWxAf565wYE34CC5s/rBKFSN+tI 76gteCrT2wkv+2dsbQID+k+nugA8ij/pxTtCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dTHIVAIEB16TRIw+Lr1FWTLZ2aA3XoAP7Eo2Pl2shTiVA6uwH+35NqcrObwCBq5sZ8 RQ3m/e6mA6yYAArZpc3uJUAw1s66h8MWccm2P9m6l3vQnyEbXOSeIGYepd4N0X7IA9tu s5ZI7Ncv37dXL+BtycUveBCW1cnXlEJlDQDdA= MIME-Version: 1.0 Received: by 10.220.97.145 with SMTP id l17mr2171627vcn.57.1250258881112; Fri, 14 Aug 2009 07:08:01 -0700 (PDT) In-Reply-To: <4A7A7FCF.3070606@teliasonera.com> References: <4A7A7FCF.3070606@teliasonera.com> Date: Fri, 14 Aug 2009 22:08:01 +0800 Message-ID: <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> From: liu dapeng To: Jyrki Soini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:09:24 -0000 Hi Jyrki: Why should we consider multicast address in DNS64? BR, Dapeng Liu 2009/8/6, Jyrki Soini : > Should DNS64 draft say something specific on how to handle multicast IP > addresses? > -- > Jyrki Soini > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From stig@venaas.com Fri Aug 14 11:07:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C203A69D8 for ; Fri, 14 Aug 2009 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE0EerIQTDfx for ; Fri, 14 Aug 2009 11:07:14 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 7BF493A6ACF for ; Fri, 14 Aug 2009 11:07:13 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id 30A4D390F1; Fri, 14 Aug 2009 20:07:15 +0200 (CEST) Message-ID: <4A85A7CB.7070600@venaas.com> Date: Fri, 14 Aug 2009 11:07:07 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: liu dapeng References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> In-Reply-To: <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org, Jyrki Soini Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:07:15 -0000 liu dapeng wrote: > Hi Jyrki: > > Why should we consider multicast address in DNS64? It would be very useful to have the exact same mechanism for multicast as for unicast, except of course that you need different prefix(es) when you synthesize AAAAs. Let me try to describe how it might work in the scenarios in DNS64. The scenarios in the DNS64 draft is: DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. If you add multicast to this scenario, it would become how IPv6-only multicast applications (clients) can receive from IPv4-only multicast sources (streaming servers etc). In practice it would work something like this: The IPv6 application may receive an SDP file telling it which multicast group to join, but by domain name rather than a literal address. The application does a DNS lookup, this goes through DNS64. DNS64 finds just an A record with an IPv4 multicast address. It then synthesizes an AAAA record with an IPv6 multicast address. Application receives this and joins the IPv6 multicast group. The join reaches the translator which knows the mapping, joins the IPv4 group... IPv4 multicast packets coming back are translated into IPv6. There is some complexity as to which exact prefixes to use. Anyway, which prefix to apply to which multicast address ranges must be configured the same on DNS64 and the translator, just like the unicast prefix must be configured on both. It might be sufficient to distinguish SSM from other multicast. The scenario here (but not DNS) is described in draft-venaas-behave-mcast46-01 and section 5.1 talks about how IPv4 multicast addresses might be embedded into IPv6 multicast addresses using multiple prefixes. Much of this is also discussed in draft-venaas-behave-v4v6mc-framework-00 which I presented in Stockholm. Note that that document doesn't say much about DNS. It mostly says that DNS is not much used for multicast. But it is used to some extent, and to aid transition it may be a good idea to use it to a much larger extent. It is easier to use a DNS ALG than to use other ALGs for rewriting literal addresses on a whole bunch of other protocols. I plan to add more on DNS to that document. I think it might be a good idea to add multicast to DNS64. Alternatively someone might at some point have to write a separate document. I think the addition to DNS64 could be just 1-2 paragraphs, and it need not go into much detail. I would be happy to provide further suggestions or text. If there is no multicast in DNS64, then it should specifically point out that it must check that an address is an IPv4 unicast address before synthesizing an AAAA record. And perhaps add that the same technique could be used for multicast, but that it would require a multicast prefix. I think we might just as well write a slightly longer text that says how to handle multicast. BTW, I wonder whether there are other IPv4 addresses that DNS64 should check against. I think it would be useful to configure which IPv4 ranges should get which IPv6 prefix, and also allow for e.g. excluding RFC1918. If you have that flexibility by configuration, DNS64 could be configured to properly handle multicast, without any specific support for multicast. Stig > > BR, > Dapeng Liu > 2009/8/6, Jyrki Soini : >> Should DNS64 draft say something specific on how to handle multicast IP >> addresses? >> -- >> Jyrki Soini >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@shinkuro.com Fri Aug 14 11:28:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3D253A6B24 for ; Fri, 14 Aug 2009 11:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUWkBZ7AzxEG for ; Fri, 14 Aug 2009 11:28:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 25E733A69E8 for ; Fri, 14 Aug 2009 11:28:26 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0BE0A2FE8ED5 for ; Fri, 14 Aug 2009 18:28:29 +0000 (UTC) Date: Fri, 14 Aug 2009 14:28:28 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090814182828.GC377@shinkuro.com> References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A85A7CB.7070600@venaas.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:28:26 -0000 On Fri, Aug 14, 2009 at 11:07:07AM -0700, Stig Venaas wrote: > liu dapeng wrote: >> Hi Jyrki: >> >> Why should we consider multicast address in DNS64? > > It would be very useful to have the exact same mechanism for multicast > as for unicast, except of course that you need different prefix(es) when > you synthesize AAAAs. Why would it be useful? In particular, what multicast v4 services are you suppising exist? Last I heard, multicast is a complete dud under IPv4, although I'd be pleased to be wrong. I'd way prefer to make these DNS64 tricks as simple as possible. That might be at the expense of more esoteric services; everything I've ever heard about multicast and v4 suggests that it meets the criteria to be considered exotic. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From stig@venaas.com Fri Aug 14 11:48:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA933A6D3B for ; Fri, 14 Aug 2009 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr9xBWwUGJG5 for ; Fri, 14 Aug 2009 11:48:52 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 828F93A6B6B for ; Fri, 14 Aug 2009 11:48:52 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id 03672356B8; Fri, 14 Aug 2009 20:48:55 +0200 (CEST) Message-ID: <4A85B195.4090000@venaas.com> Date: Fri, 14 Aug 2009 11:48:53 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Andrew Sullivan References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> In-Reply-To: <20090814182828.GC377@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:48:53 -0000 Andrew Sullivan wrote: > On Fri, Aug 14, 2009 at 11:07:07AM -0700, Stig Venaas wrote: >> liu dapeng wrote: >>> Hi Jyrki: >>> >>> Why should we consider multicast address in DNS64? >> It would be very useful to have the exact same mechanism for multicast >> as for unicast, except of course that you need different prefix(es) when >> you synthesize AAAAs. > > Why would it be useful? In particular, what multicast v4 services are > you suppising exist? Last I heard, multicast is a complete dud under > IPv4, although I'd be pleased to be wrong. I'd way prefer to make > these DNS64 tricks as simple as possible. That might be at the > expense of more esoteric services; everything I've ever heard about > multicast and v4 suggests that it meets the criteria to be considered > exotic. IPv4 multicast is used many places, but rather than try to list that here (although maybe I need to), I would just like to say again that I think it would be useful for DNS64 mechanisms in general to allow for configuration specifying how different IPv4 prefixes should be mapped to IPv6. Allowing different IPv4 prefixes to be mapped to different IPv6 prefixes, and maybe also some prefixes like RFC1918 ones to be ignored. Would you agree that could be useful for unicast? With that mechanism in place, DNS64 would work well with multicast without having to care about multicast at all. It would then be left to the administrator whether to configure mappings that allow multicast. Stig From ajs@shinkuro.com Fri Aug 14 11:57:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7911428C1C4 for ; Fri, 14 Aug 2009 11:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiVVMiJrL0bl for ; Fri, 14 Aug 2009 11:57:25 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A23953A6AD3 for ; Fri, 14 Aug 2009 11:57:25 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0145A2FE8ED5 for ; Fri, 14 Aug 2009 18:57:28 +0000 (UTC) Date: Fri, 14 Aug 2009 14:57:27 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090814185727.GD377@shinkuro.com> References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A85B195.4090000@venaas.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:57:26 -0000 On Fri, Aug 14, 2009 at 11:48:53AM -0700, Stig Venaas wrote: > > Would you agree that could be useful for unicast? That's not the problem we're trying to solve. We're trying to solve a limited number of IPv4/IPv6 inter-networking cases, according to the priorities established by the Chairs. (This limited applicability is also why we have not so far used the DNS64 draft to specify DNS46 as well. Neither have we attempted to solve properly the DNS44 problem, which has existed for many years in split-brain scenarios.) I sometimes get dirty looks when I say this out loud, but in my opinion DNS64 and all its friends are filthy hacks that we are specifying only because in the past, when we said, "That's ugly and wrong lalalala I can't hear you," to things people were going to do anyway, it resulted in deployed technology than was even worse than the bad things people originally found objectionable. In other words, this is least-bad, not actually good. So there has to be some compelling and existing use case to make the inclusion of special text or completely generic approaches worth the effort. Unless, of course, you have a proposal for text specifying the technique completely generically. In which case, I'm interested in the text, please. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From marc.blanchet@viagenie.ca Fri Aug 14 12:05:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D373A6D59 for ; Fri, 14 Aug 2009 12:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IHB2ha5Bw9J for ; Fri, 14 Aug 2009 12:05:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D32FB3A6B19 for ; Fri, 14 Aug 2009 12:05:55 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 2E3CB29E15EC; Fri, 14 Aug 2009 15:05:57 -0400 (EDT) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id 2501D29E15BE; Fri, 14 Aug 2009 15:05:57 -0400 (EDT) Message-ID: <4A85B594.7060303@viagenie.ca> Date: Fri, 14 Aug 2009 15:05:56 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andrew Sullivan References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> In-Reply-To: <20090814182828.GC377@shinkuro.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:05:58 -0000 Andrew Sullivan a crit : > On Fri, Aug 14, 2009 at 11:07:07AM -0700, Stig Venaas wrote: >> liu dapeng wrote: >>> Hi Jyrki: >>> >>> Why should we consider multicast address in DNS64? >> It would be very useful to have the exact same mechanism for multicast >> as for unicast, except of course that you need different prefix(es) when >> you synthesize AAAAs. > > Why would it be useful? In particular, what multicast v4 services are > you suppising exist? Last I heard, multicast is a complete dud under > IPv4, although I'd be pleased to be wrong. multicast is used a lot within ISP networks to deliver IP streaming, IP-TV services. but inter-AS multicast has been almost inexistant. Therefore, Stig work is relevant for within ISP networks. Marc. > I'd way prefer to make > these DNS64 tricks as simple as possible. That might be at the > expense of more esoteric services; everything I've ever heard about > multicast and v4 suggests that it meets the criteria to be considered > exotic. > > A > > -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From cambyrne@yahoo.com Fri Aug 14 12:22:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707173A6CB7 for ; Fri, 14 Aug 2009 12:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOP4lRGI1fZx for ; Fri, 14 Aug 2009 12:22:54 -0700 (PDT) Received: from web32002.mail.mud.yahoo.com (web32002.mail.mud.yahoo.com [68.142.207.99]) by core3.amsl.com (Postfix) with SMTP id 954943A6A2E for ; Fri, 14 Aug 2009 12:22:54 -0700 (PDT) Received: (qmail 40027 invoked by uid 60001); 14 Aug 2009 19:22:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1250277777; bh=WQary+HCqRdBhSQcE6FUxDpJZleos27ndY0OtjVXWiE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=r1ZLy4OYYW/vIn+WtqFlCb9t1SshAvs0/KjGpcunqBn7Uk8jZI1xQqqzaHhQOVp2dBXmSHW84YACs7z6igXm/1lREYiQHz0/PS0UTgFAw/BLeuwlxHOuW+Z9Qf/Gaeos07f6xSIGc5oPFhZFMPyJK0BTcbVHzbXFx3KSDZhxxOw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SFOzwk52Xc3+1sMwIlkwGmVkGswGIIkB3fYGLCA9lgS/YUR4A+UCHb0c4rTLLiLSI+rsxHk6TG5iQ/d10Lnw/aP0DHQ9BOw59Gn8TY0gF1Lcl45txR+IVciHExaBJrp/odmrQC9dGUcNtD82+mGxXbaf/jq2cyshTxGl2gXQsnM=; Message-ID: <119380.39159.qm@web32002.mail.mud.yahoo.com> X-YMail-OSG: I3jUP8cVM1kXjx4RcvtQNiNKU997c.IZp6BYiaZyRVezB.V1WRWYYMdLPxTffayJEPoIeFpFb3NKgGwDn6wOvwP97XSpXLnZJPj.GyaxAJ6XDkkKxky_rkpfLEOWmNRD1ZLVBGI.IzwYNMbodqaAUnlWXlu8RAdfjOUrDDAXdAjzdIB5jrYkA3Sc2pHPVU4RLacq0FN3axtBU9mUCDtWnO.hE0CMTgF86iF.E909dT7sBOxB.78KlrvLeK4mDWpHeCCpA7fXJeaOt7KRsgP4t4ELJLUrgyMiWv.2Es8CrzpIjZcZm356t6_ift_OLwayBKu5pf3lojW3momzResTFg-- Received: from [65.161.188.11] by web32002.mail.mud.yahoo.com via HTTP; Fri, 14 Aug 2009 12:22:56 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Fri, 14 Aug 2009 12:22:56 -0700 (PDT) From: Cameron Byrne To: behave@ietf.org, Andrew Sullivan In-Reply-To: <20090814185727.GD377@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:22:55 -0000 I see DNS/NAT64 as being most relevant in the inter-domain context (aka acr= oss the Internet). I don't need to NAT64 to things in my own intra-domain = environment. For intra-domain, i can solve my own problem with dual-stack o= r load-balancers acting as proxies.=0A=0AMulticast is exotic, and the cases= where it is not exotic is the intra-domain context ... and i don't need NA= T64 for intra-domain.=0A=0ACameron Byrne=0APrincipal Engineer=0AT-Mobile US= A.=0A=0A--- On Fri, 8/14/09, Andrew Sullivan wrote:=0A= =0A> From: Andrew Sullivan =0A> Subject: Re: [BEHAVE] DNS= 64 handling of multicast addresses=0A> To: behave@ietf.org=0A> Date: Friday= , August 14, 2009, 2:57 PM=0A> On Fri, Aug 14, 2009 at 11:48:53AM=0A> -0700= , Stig Venaas wrote:=0A> >=0A> > Would you agree that could be useful for u= nicast?=0A> =0A> That's not the problem we're trying to solve.=A0 We're=0A>= trying to solve a=0A> limited number of IPv4/IPv6 inter-networking cases,= =0A> according to the=0A> priorities established by the Chairs.=A0 (This li= mited=0A> applicability is=0A> also why we have not so far used the DNS64 d= raft to specify=0A> DNS46 as=0A> well.=A0 Neither have we attempted to solv= e properly the=0A> DNS44 problem,=0A> which has existed for many years in s= plit-brain=0A> scenarios.)=0A> =0A> I sometimes get dirty looks when I say = this out loud, but=0A> in my=0A> opinion DNS64 and all its friends are filt= hy hacks that we=0A> are=0A> specifying only because in the past, when we s= aid, "That's=0A> ugly and=0A> wrong lalalala I can't hear you," to things p= eople were=0A> going to do=0A> anyway, it resulted in deployed technology t= han was even=0A> worse than=0A> the bad things people originally found obje= ctionable.=A0=0A> In other words,=0A> this is least-bad, not actually good.= =A0 So there has to=0A> be some=0A> compelling and existing use case to mak= e the inclusion of=0A> special text=0A> or completely generic approaches wo= rth the effort.=0A> =0A> Unless, of course, you have a proposal for text sp= ecifying=0A> the=0A> technique completely generically.=A0 In which case, I'= m=0A> interested in=0A> the text, please.=0A> =0A> A=0A> =0A> =0A> -- =0A> = Andrew Sullivan=0A> ajs@shinkuro.com=0A> Shinkuro, Inc.=0A> _______________= ________________________________=0A> Behave mailing list=0A> Behave@ietf.or= g=0A> https://www.ietf.org/mailman/listinfo/behave=0A> From marcelo@it.uc3m.es Sun Aug 16 06:24:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F783A6784 for ; Sun, 16 Aug 2009 06:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.569 X-Spam-Level: X-Spam-Status: No, score=-5.569 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zum96JWmiFAa for ; Sun, 16 Aug 2009 06:24:25 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1797A3A6E77 for ; Sun, 16 Aug 2009 06:24:19 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (36.pool85-55-7.dynamic.orange.es [85.55.7.36]) by smtp02.uc3m.es (Postfix) with ESMTP id 5A21B6566D4; Sun, 16 Aug 2009 15:24:20 +0200 (CEST) Message-ID: <4A8707BB.9000702@it.uc3m.es> Date: Sat, 15 Aug 2009 21:08:43 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Stig Venaas References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> In-Reply-To: <4A85A7CB.7070600@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16828.007 Cc: Jyrki Soini , behave@ietf.org, liu dapeng Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 13:24:26 -0000 Hi, some comments below... Stig Venaas escribi: > > Note that that document doesn't say much about DNS. It mostly says that > DNS is not much used for multicast. based on this observation.... > But it is used to some extent, and > to aid transition it may be a good idea to use it to a much larger > extent. It is easier to use a DNS ALG than to use other ALGs for > rewriting literal addresses on a whole bunch of other protocols. > > I plan to add more on DNS to that document. > > I think it might be a good idea to add multicast to DNS64. Alternatively > someone might at some point have to write a separate document. > I think this is the best way forward at this stage. I mean, we have a very tight schedule for DNS64 (it is supposed to be out to the IESG for november) Each time we add more stuff is likely it will get more dleayed and if delayed the document becomes less relevant, so i would rather have this in a different document I think it would make more sense to have a different document DNS64 extensions for multicast to deal with this issue. > I think the addition to DNS64 could be just 1-2 paragraphs, and it need > not go into much detail. I would be happy to provide further suggestions > or text. > > If there is no multicast in DNS64, then it should specifically point out > that it must check that an address is an IPv4 unicast address before > synthesizing an AAAA record. right, this should be added to the dns64 document > And perhaps add that the same technique > could be used for multicast, but that it would require a multicast > prefix. > mmm, i would rahter have a reference to your multicast document > I think we might just as well write a slightly longer text that says > how to handle multicast. > > BTW, I wonder whether there are other IPv4 addresses that DNS64 should > check against. I think it would be useful to configure which IPv4 ranges > should get which IPv6 prefix, and also allow for e.g. excluding RFC1918. > that makes sense to me Regards, marcelo > If you have that flexibility by configuration, DNS64 could be configured > to properly handle multicast, without any specific support for multicast. > > Stig > >> >> BR, >> Dapeng Liu >> 2009/8/6, Jyrki Soini : >>> Should DNS64 draft say something specific on how to handle multicast IP >>> addresses? >>> -- >>> Jyrki Soini >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From marcelo@it.uc3m.es Sun Aug 16 06:24:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8493A67E1 for ; Sun, 16 Aug 2009 06:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMHd3unV7XWq for ; Sun, 16 Aug 2009 06:24:25 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id E188C3A6E98 for ; Sun, 16 Aug 2009 06:24:22 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (36.pool85-55-7.dynamic.orange.es [85.55.7.36]) by smtp01.uc3m.es (Postfix) with ESMTP id 9CA63B4D719; Sun, 16 Aug 2009 15:24:24 +0200 (CEST) Message-ID: <4A870969.20609@it.uc3m.es> Date: Sat, 15 Aug 2009 21:15:53 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andrew Sullivan References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> In-Reply-To: <20090814185727.GD377@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16828.007 Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 13:24:26 -0000 Andrew Sullivan escribi: > On Fri, Aug 14, 2009 at 11:48:53AM -0700, Stig Venaas wrote: > >> Would you agree that could be useful for unicast? >> > > That's not the problem we're trying to solve. We're trying to solve a > limited number of IPv4/IPv6 inter-networking cases, according to the > priorities established by the Chairs. (This limited applicability is > also why we have not so far used the DNS64 draft to specify DNS46 as > well. Neither have we attempted to solve properly the DNS44 problem, > which has existed for many years in split-brain scenarios.) > > I sometimes get dirty looks when I say this out loud, but in my > opinion DNS64 and all its friends are filthy hacks that we are > specifying only because in the past, when we said, "That's ugly and > wrong lalalala I can't hear you," to things people were going to do > anyway, it resulted in deployed technology than was even worse than > the bad things people originally found objectionable. In other words, > this is least-bad, not actually good. So there has to be some > compelling and existing use case to make the inclusion of special text > or completely generic approaches worth the effort. > > Unless, of course, you have a proposal for text specifying the > technique completely generically. In which case, I'm interested in > the text, please. > mmm, what i understood stig suggested is that: - as a minimum, the DNS64 shoudl check some the IPv4 addresses it receives in the A RR and see if they fall in some special IPv4 prefixes (such as a multicast prefix or private address prefix or some other special prefix). In the address does contain one of these special prefixes, it should not synthesize an AAAA RR. - In addition, it could be possible to configure different Pref64 for the different prefixes. So, for all the public unicast address space use one or more pref64, bit if the IPv4 address is a muticast address, then use a different pref64 and possibly doing this with different pref64 for different ipv4 special prefixes. I think it makes sense to have a list of v4 prefixes for which the dns64 does not create synthetic AAAA RR. I mean, would it make sense to synthesize a AAAA RR from an A RR that contains an IPv4 multicast address? Regards, marcelo > A > > > From marka@isc.org Sun Aug 16 16:28:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88ED83A62C1 for ; Sun, 16 Aug 2009 16:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYsNFhRWycOd for ; Sun, 16 Aug 2009 16:28:13 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 599D23A6A62 for ; Sun, 16 Aug 2009 16:28:13 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0C7B0E609B; Sun, 16 Aug 2009 23:28:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7GNS6So072710; Mon, 17 Aug 2009 09:28:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908162328.n7GNS6So072710@drugs.dv.isc.org> To: marcelo bagnulo braun From: Mark Andrews References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> In-reply-to: Your message of "Sat, 15 Aug 2009 21:15:53 +0200." <4A870969.20609@it.uc3m.es> Date: Mon, 17 Aug 2009 09:28:06 +1000 Sender: marka@isc.org Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 23:28:14 -0000 In message <4A870969.20609@it.uc3m.es>, marcelo bagnulo braun writes: > Andrew Sullivan escribi: > > On Fri, Aug 14, 2009 at 11:48:53AM -0700, Stig Venaas wrote: > > > >> Would you agree that could be useful for unicast? > > > > That's not the problem we're trying to solve. We're trying to solve a > > limited number of IPv4/IPv6 inter-networking cases, according to the > > priorities established by the Chairs. (This limited applicability is > > also why we have not so far used the DNS64 draft to specify DNS46 as > > well. Neither have we attempted to solve properly the DNS44 problem, > > which has existed for many years in split-brain scenarios.) > > > > I sometimes get dirty looks when I say this out loud, but in my > > opinion DNS64 and all its friends are filthy hacks that we are > > specifying only because in the past, when we said, "That's ugly and > > wrong lalalala I can't hear you," to things people were going to do > > anyway, it resulted in deployed technology than was even worse than > > the bad things people originally found objectionable. In other words, > > this is least-bad, not actually good. So there has to be some > > compelling and existing use case to make the inclusion of special text > > or completely generic approaches worth the effort. > > > > Unless, of course, you have a proposal for text specifying the > > technique completely generically. In which case, I'm interested in > > the text, please. > > > > mmm, what i understood stig suggested is that: > - as a minimum, the DNS64 shoudl check some the IPv4 addresses it > receives in the A RR and see if they fall in some special IPv4 prefixes > (such as a multicast prefix or private address prefix or some other > special prefix). In the address does contain one of these special > prefixes, it should not synthesize an AAAA RR. > - In addition, it could be possible to configure different Pref64 for > the different prefixes. So, for all the public unicast address space use > one or more pref64, bit if the IPv4 address is a muticast address, then > use a different pref64 and possibly doing this with different pref64 for > different ipv4 special prefixes. > > I think it makes sense to have a list of v4 prefixes for which the dns64 > does not create synthetic AAAA RR. I mean, would it make sense to > synthesize a AAAA RR from an A RR that contains an IPv4 multicast address? DNS64 is a unicast translator, i.e class A, B and C address. Class D and E are out of scope for DNS64. Anything else is local configuration. > Regards, marcelo > > > > A > > > > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From stig@venaas.com Mon Aug 17 12:03:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C983A6F83 for ; Mon, 17 Aug 2009 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnWnR7+wSLIA for ; Mon, 17 Aug 2009 12:03:52 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 99F103A6F7E for ; Mon, 17 Aug 2009 12:03:51 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id E7535394D1; Mon, 17 Aug 2009 21:03:52 +0200 (CEST) Message-ID: <4A89A995.5040404@venaas.com> Date: Mon, 17 Aug 2009 12:03:49 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: marcelo bagnulo braun References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <4A8707BB.9000702@it.uc3m.es> In-Reply-To: <4A8707BB.9000702@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Jyrki Soini , behave@ietf.org, liu dapeng Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 19:03:52 -0000 marcelo bagnulo braun wrote: > Hi, > > some comments below... > > Stig Venaas escribi: >> BTW, I wonder whether there are other IPv4 addresses that DNS64 should >> check against. I think it would be useful to configure which IPv4 ranges >> should get which IPv6 prefix, and also allow for e.g. excluding RFC1918. >> > > that makes sense to me I'm fine with what you wrote Marcelo. But one thing I'm trying to say which it might seem you and others have not quite understood (at least it looks that way to me), is that DNS64 can work for multicast without any support for it. As I wrote in the text above, it might be useful in DNS64 to configure that some IPv4 ranges should get one IPv6 prefix, and some other ranges another. And maybe that some IPv4 ranges should be ignored. If you think that is useful, please consider adding that to the draft. I think that is useful for _unicast_. DNS64 implementations with that flexibility could be configured to handle multicast. I think that would be cool, but you don't need to mention multicast in the draft, it's just a configuration thing. Stig > Regards, marcelo From jyrki.soini@teliasonera.com Tue Aug 18 01:32:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A28E3A686C for ; Tue, 18 Aug 2009 01:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMqcudhIeDY2 for ; Tue, 18 Aug 2009 01:32:52 -0700 (PDT) Received: from floor.dave.sonera.fi (floor.dave.sonera.fi [131.177.130.22]) by core3.amsl.com (Postfix) with ESMTP id 3A4893A6C39 for ; Tue, 18 Aug 2009 01:32:51 -0700 (PDT) Received: from floor.dave.sonera.fi (localhost [127.0.0.1]) by floor.dave.sonera.fi (Sendmail) with ESMTP id n7I8UPqa012044 for ; Tue, 18 Aug 2009 11:30:25 +0300 (EEST) Received: from [131.177.116.246] (ws946.secureuser.sonera.fi [131.177.116.246]) by floor.dave.sonera.fi (Sendmail) with ESMTP id n7I8UP47012041 for ; Tue, 18 Aug 2009 11:30:25 +0300 (EEST) Message-ID: <4A8A66A0.5030604@teliasonera.com> Date: Tue, 18 Aug 2009 11:30:24 +0300 From: Jyrki Soini User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: behave@ietf.org References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> In-Reply-To: <4A870969.20609@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 08:32:53 -0000 On 21:59, marcelo bagnulo braun wrote: > Andrew Sullivan escribi: >> On Fri, Aug 14, 2009 at 11:48:53AM -0700, Stig Venaas wrote: >>> Would you agree that could be useful for unicast? >> >> That's not the problem we're trying to solve. We're trying to solve a >> limited number of IPv4/IPv6 inter-networking cases, according to the >> priorities established by the Chairs. (This limited applicability is >> also why we have not so far used the DNS64 draft to specify DNS46 as >> well. Neither have we attempted to solve properly the DNS44 problem, >> which has existed for many years in split-brain scenarios.) >> >> I sometimes get dirty looks when I say this out loud, but in my >> opinion DNS64 and all its friends are filthy hacks that we are >> specifying only because in the past, when we said, "That's ugly and >> wrong lalalala I can't hear you," to things people were going to do >> anyway, it resulted in deployed technology than was even worse than >> the bad things people originally found objectionable. In other words, >> this is least-bad, not actually good. So there has to be some >> compelling and existing use case to make the inclusion of special text >> or completely generic approaches worth the effort. >> >> Unless, of course, you have a proposal for text specifying the >> technique completely generically. In which case, I'm interested in >> the text, please. > > mmm, what i understood stig suggested is that: > - as a minimum, the DNS64 shoudl check some the IPv4 addresses it > receives in the A RR and see if they fall in some special IPv4 prefixes > (such as a multicast prefix or private address prefix or some other > special prefix). In the address does contain one of these special > prefixes, it should not synthesize an AAAA RR. > - In addition, it could be possible to configure different Pref64 for > the different prefixes. So, for all the public unicast address space use > one or more pref64, bit if the IPv4 address is a muticast address, then > use a different pref64 and possibly doing this with different pref64 for > different ipv4 special prefixes. > > I think it makes sense to have a list of v4 prefixes for which the dns64 > does not create synthetic AAAA RR. I mean, would it make sense to > synthesize a AAAA RR from an A RR that contains an IPv4 multicast address? > > Regards, marcelo > > >> A As Stig Venaas pointed out, if the DNS64 is able to handle multiple IPv6 prefixes for synthesizing the AAAA record based on IPv4 address ranges on returned A records the multicast would not need any additional mechanism in DNS64. I think that best way forward would be to specify synthesizing IPv6 multicast addresses in draft-venaas-behave-mcast64 (there might be some considerations on scopes and ASM/SSM). I propose the following text (marked with +) will be inserted to draft-ietf-behave-dns64 5. DNS64 Normative Specification A DNS64 is a logical function that synthesizes AAAA records from A records. The DNS64 function may be implemented in a stub resolver, in a recursive resolver, or in an authoritative name server. + The implementation SHOULD support mapping of IPv4 address ranges to + separate IPv6 prefixes for AAAA record synthesis. This allows handling + of special use IPv4 addresses [draft-iana-rfc3330bis-09]. Multicast + address handling is further specified in [draft-venaas-behave-mcast46]. and modifying existing paragraph later in 5.1 with: If the query results in no error but an empty answer section in the response, the DNS64 resolver attempts to retrieve A records for the name in question. If this new A RR query results in an empty result or in an error, this result is returned to the client. If the query results in one or more A RRs, + the DNS64 SHOULD check each A RR against IPv4 address ranges and + select the corresponding IPv6 prefix for synthesizing AAAA RR. - the DNS64 synthesizes AAAA RRs based on the A RRs. The DNS64 resolver then returns the synthesized AAAA records in the answer section to the client, removing the A records that form the basis of the synthesis. -- Jyrki Soini From marcelo@it.uc3m.es Tue Aug 18 06:08:13 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49D228C15A for ; Tue, 18 Aug 2009 06:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGRKMH09-92b for ; Tue, 18 Aug 2009 06:08:12 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 8108428C102 for ; Tue, 18 Aug 2009 06:08:12 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (36.pool85-55-7.dynamic.orange.es [85.55.7.36]) by smtp03.uc3m.es (Postfix) with ESMTP id 525B37F26D2; Tue, 18 Aug 2009 14:53:41 +0200 (CEST) Message-ID: <4A898161.50801@it.uc3m.es> Date: Mon, 17 Aug 2009 18:12:17 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Mark Andrews References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> In-Reply-To: <200908162328.n7GNS6So072710@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16832.003 Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 13:08:13 -0000 Mark Andrews escribi: > In message <4A870969.20609@it.uc3m.es>, marcelo bagnulo braun writes: > >> Andrew Sullivan escribi: >> >>> On Fri, Aug 14, 2009 at 11:48:53AM -0700, Stig Venaas wrote: >>> >>> >>>> Would you agree that could be useful for unicast? >>>> >>> That's not the problem we're trying to solve. We're trying to solve a >>> limited number of IPv4/IPv6 inter-networking cases, according to the >>> priorities established by the Chairs. (This limited applicability is >>> also why we have not so far used the DNS64 draft to specify DNS46 as >>> well. Neither have we attempted to solve properly the DNS44 problem, >>> which has existed for many years in split-brain scenarios.) >>> >>> I sometimes get dirty looks when I say this out loud, but in my >>> opinion DNS64 and all its friends are filthy hacks that we are >>> specifying only because in the past, when we said, "That's ugly and >>> wrong lalalala I can't hear you," to things people were going to do >>> anyway, it resulted in deployed technology than was even worse than >>> the bad things people originally found objectionable. In other words, >>> this is least-bad, not actually good. So there has to be some >>> compelling and existing use case to make the inclusion of special text >>> or completely generic approaches worth the effort. >>> >>> Unless, of course, you have a proposal for text specifying the >>> technique completely generically. In which case, I'm interested in >>> the text, please. >>> >>> >> mmm, what i understood stig suggested is that: >> - as a minimum, the DNS64 shoudl check some the IPv4 addresses it >> receives in the A RR and see if they fall in some special IPv4 prefixes >> (such as a multicast prefix or private address prefix or some other >> special prefix). In the address does contain one of these special >> prefixes, it should not synthesize an AAAA RR. >> - In addition, it could be possible to configure different Pref64 for >> the different prefixes. So, for all the public unicast address space use >> one or more pref64, bit if the IPv4 address is a muticast address, then >> use a different pref64 and possibly doing this with different pref64 for >> different ipv4 special prefixes. >> >> I think it makes sense to have a list of v4 prefixes for which the dns64 >> does not create synthetic AAAA RR. I mean, would it make sense to >> synthesize a AAAA RR from an A RR that contains an IPv4 multicast address? >> > > DNS64 is a unicast translator, i.e class A, B and C address. Class > D and E are out of scope for DNS64. Anything else is local configuration. > fair enough, so this requires for the first option i described above i.e. the dns64 needs to check that the address int he A RR is part of the class A,B and C space. If it is not, it will not synthesize the AAAA RR, correct? Is there any other special cases we need to handle? What about private addresses, should we create synthetic AAAA RR for A RR with private addresses inside? Regards, marcelo > > >> Regards, marcelo >> >> >> >>> A >>> >>> >>> >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> From stig@venaas.com Tue Aug 18 07:35:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412B03A69CA for ; Tue, 18 Aug 2009 07:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwz3xlY3l9Qt for ; Tue, 18 Aug 2009 07:35:43 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id CF7053A6E36 for ; Tue, 18 Aug 2009 07:35:42 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-186-244-131.dsl.pltn13.sbcglobal.net [99.186.244.131]) by ufisa.uninett.no (Postfix) with ESMTP id CEF9A38D1B; Tue, 18 Aug 2009 16:35:44 +0200 (CEST) Message-ID: <4A8ABC15.90905@venaas.com> Date: Tue, 18 Aug 2009 07:35:01 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Jyrki Soini References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <4A8A66A0.5030604@teliasonera.com> In-Reply-To: <4A8A66A0.5030604@teliasonera.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:35:44 -0000 Jyrki Soini wrote: [...] > As Stig Venaas pointed out, if the DNS64 is able to handle multiple > IPv6 prefixes for synthesizing the AAAA record based on IPv4 address > ranges on returned A records the multicast would not need any additional > mechanism in DNS64. > > I think that best way forward would be to specify synthesizing IPv6 > multicast addresses in draft-venaas-behave-mcast64 (there might be some > considerations on scopes and ASM/SSM). Yes, I certainly think a more detailed discussion need to go somewhere else, e.g. that draft. > I propose the following text (marked with +) will be inserted to > draft-ietf-behave-dns64 > > > 5. DNS64 Normative Specification > > A DNS64 is a logical function that synthesizes AAAA records from A > records. The DNS64 function may be implemented in a stub resolver, > in a recursive resolver, or in an authoritative name server. > > + The implementation SHOULD support mapping of IPv4 address ranges to > + separate IPv6 prefixes for AAAA record synthesis. This allows handling > + of special use IPv4 addresses [draft-iana-rfc3330bis-09]. Multicast > + address handling is further specified in [draft-venaas-behave-mcast46]. Looks good. > > and modifying existing paragraph later in 5.1 with: > > If the query results in no error but an empty answer section in the > response, the DNS64 resolver attempts to retrieve A records for the > name in question. If this new A RR query results in an empty result > or in an error, this result is returned to the client. If the query > results in one or more A RRs, > + the DNS64 SHOULD check each A RR against IPv4 address ranges and > + select the corresponding IPv6 prefix for synthesizing AAAA RR. > - the DNS64 synthesizes AAAA RRs based on the A RRs. > The DNS64 resolver then returns the synthesized AAAA > records in the answer section to the client, removing the A records > that form the basis of the synthesis. And this too. These changes are exactly what I was asking for :) Stig > -- > Jyrki Soini > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@shinkuro.com Tue Aug 18 09:50:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029C228C2F9 for ; Tue, 18 Aug 2009 09:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRFHL0-VTL-j for ; Tue, 18 Aug 2009 09:50:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 5198928C2EC for ; Tue, 18 Aug 2009 09:50:38 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 0887F2FE8ED5 for ; Tue, 18 Aug 2009 16:50:42 +0000 (UTC) Date: Tue, 18 Aug 2009 12:50:41 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090818165041.GI3163@shinkuro.com> References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908162328.n7GNS6So072710@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:50:39 -0000 Mark, On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: > DNS64 is a unicast translator, i.e class A, B and C address. Class > D and E are out of scope for DNS64. Anything else is local configuration. What about the suggested text from Jyrki Soini, downthread? It seems to be consistent with what you are suggesting while allowing for the requested behaviour. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Tue Aug 18 10:16:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483433A6BC9 for ; Tue, 18 Aug 2009 10:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRg2h1FPi32a for ; Tue, 18 Aug 2009 10:16:34 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 96B283A6B28 for ; Tue, 18 Aug 2009 10:16:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEAK9+ikqrR7MV/2dsb2JhbACLIbUJiC2QQwWEGQ X-IronPort-AV: E=Sophos;i="4.43,403,1246838400"; d="scan'208";a="184186880" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2009 17:16:40 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7IHGdKc017103 for ; Tue, 18 Aug 2009 10:16:39 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7IHGdxE008561 for ; Tue, 18 Aug 2009 17:16:39 GMT From: "Dan Wing" To: Date: Tue, 18 Aug 2009 10:16:39 -0700 Message-ID: <2c7101ca2027$a633dab0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcogJ6YBNBM8tFIhSzWpWC4Hqp3wDw== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=332; t=1250615800; x=1251479800; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20WGLC=20reminder=3A=20draft-ietf-behave-turn-tcp -04,=20draft-ietf-behave-turn-uri-02 |Sender:=20; bh=nu6YRNWIMPWvf+a6azQQetty8wBBdAveRvF9y4/MAxs=; b=QmeuUaD8QeFwMftA1cVN8dpIRq2AiVlQ4G90IxPMn7DAreM9ln13uAA1Wv pASQv6vhhNKrmnWJnQ7++HPD1DgEUrHyrsZkpqn1vmPOFrSzPeEOXfl6YMcf l3A06SPfqcKs8PexTSOmxA2PBqvJCuWLchDG3uckkh+jy3ub/gvw4=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [BEHAVE] WGLC reminder: draft-ietf-behave-turn-tcp-04, draft-ietf-behave-turn-uri-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 17:16:35 -0000 Reminder: WGLC for the following documents are finishing tomorrow (August 19): * draft-ietf-behave-turn-tcp-04 announcement: http://www.ietf.org/mail-archive/web/behave/current/msg06476.html * draft-ietf-behave-turn-uri-02 announcement: http://www.ietf.org/mail-archive/web/behave/current/msg06475.html -d From dwing@cisco.com Tue Aug 18 15:45:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51AAD3A6B14 for ; Tue, 18 Aug 2009 15:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BgfeHrCsrmj for ; Tue, 18 Aug 2009 15:45:44 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 762083A6AD0 for ; Tue, 18 Aug 2009 15:45:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEAI/LikqrR7PD/2dsb2JhbACLIbN2iC2QbQWEGYFT X-IronPort-AV: E=Sophos;i="4.43,404,1246838400"; d="scan'208";a="370045692" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2009 22:45:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7IMjVMU022083 for ; Tue, 18 Aug 2009 15:45:31 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7IMjUZp002053 for ; Tue, 18 Aug 2009 22:45:30 GMT From: "Dan Wing" To: Date: Tue, 18 Aug 2009 15:45:30 -0700 Message-ID: <2e0401ca2055$96d76d10$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcogVZalr9nFCnsZQEGVUFdvuj55mg== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=678; t=1250635531; x=1251499531; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Wednesday's=20interim=20meeting |Sender:=20; bh=AFRboFEckQ0kATHhJAyU6Cx3eIF8Hi2psBg/3Ut2o2c=; b=tjNJ0kqZig77DiHd7FF7csGVUxw3C8kfrzU+8ISid6eyz5QCHFwCJsRvIR 5xxGnyTkTgdxPeDM+EObrfmpwi8XhoLmogIn8tJTMXuCQo/XRSo0wgFF3c6F rWg1zUB7Ux; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [BEHAVE] Wednesday's interim meeting X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 22:45:45 -0000 BEHAVE's next interim meeting is tomorrow morning at 7am Pacific Daylight Time. Details for conferencing, including the agenda, is at http://trac.tools.ietf.org/wg/behave/trac/wiki Due to jury duty and vacation we have a very light agenda: * Learning the IPv6 Prefixes of an IPv6/IPv4 Translator (this presentation was canceled in Stockholm) http://www.ietf.org/proceedings/75/slides/behave-3.pdf Dan Wing (15 minutes) * MTU/Fragmentation text http://www.ietf.org/mail-archive/web/behave/current/msg06526.html Iljitsch van Beijnum (10 minutes) If there is something you would like to add to the agenda, please let us know. -d From marka@isc.org Tue Aug 18 20:10:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34043A680E for ; Tue, 18 Aug 2009 20:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFazvkT-VU8t for ; Tue, 18 Aug 2009 20:10:42 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id B7D163A682E for ; Tue, 18 Aug 2009 20:10:42 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id F1197E609B; Wed, 19 Aug 2009 03:10:38 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7J3AXUf008504; Wed, 19 Aug 2009 13:10:33 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908190310.n7J3AXUf008504@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> In-reply-to: Your message of "Tue, 18 Aug 2009 12:50:41 -0400." <20090818165041.GI3163@shinkuro.com> Date: Wed, 19 Aug 2009 13:10:33 +1000 Sender: marka@isc.org Cc: behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 03:10:43 -0000 In message <20090818165041.GI3163@shinkuro.com>, Andrew Sullivan writes: > Mark, > > On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: > > > DNS64 is a unicast translator, i.e class A, B and C address. Class > > D and E are out of scope for DNS64. Anything else is local configuration. > > What about the suggested text from Jyrki Soini, downthread? It seems > to be consistent with what you are suggesting while allowing for the > requested behaviour. Something like that would be fine. I would still exclude Class E addresses. I would add text to ensure that Class D are mapped into FF00::/8 (or whatever the correct IPv6 multicast prefix is). I would describe these as a unicast prefix and multicast prefix and say that the unicast prefix only applies to Class A, B and C addresses. Similarly the multicast prefix only applies to the Class D addresses. That way you you can use 0.0.0.0/0 when checking which addresses matches rather than having to use 0.0.0.0/1 + 128.0.0.0/2 + 192.0.0.0/3 as the default matching acl in configs for the unicast addresses. Mark > A > > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From stig@venaas.com Tue Aug 18 21:24:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6F03A6ADE for ; Tue, 18 Aug 2009 21:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht+RzyxjL0Wu for ; Tue, 18 Aug 2009 21:24:53 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id BF24F28C1DE for ; Tue, 18 Aug 2009 21:24:02 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-186-244-131.dsl.pltn13.sbcglobal.net [99.186.244.131]) by ufisa.uninett.no (Postfix) with ESMTP id 26F8D38F8E; Wed, 19 Aug 2009 06:24:04 +0200 (CEST) Message-ID: <4A8B7E35.9070500@venaas.com> Date: Tue, 18 Aug 2009 21:23:17 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Mark Andrews References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> In-Reply-To: <200908190310.n7J3AXUf008504@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 04:24:54 -0000 Mark Andrews wrote: > In message <20090818165041.GI3163@shinkuro.com>, Andrew Sullivan writes: >> Mark, >> >> On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: >> >>> DNS64 is a unicast translator, i.e class A, B and C address. Class >>> D and E are out of scope for DNS64. Anything else is local configuration. >> What about the suggested text from Jyrki Soini, downthread? It seems >> to be consistent with what you are suggesting while allowing for the >> requested behaviour. > > Something like that would be fine. > > I would still exclude Class E addresses. > > I would add text to ensure that Class D are mapped into FF00::/8 > (or whatever the correct IPv6 multicast prefix is). > > I would describe these as a unicast prefix and multicast prefix and > say that the unicast prefix only applies to Class A, B and C > addresses. Similarly the multicast prefix only applies to the Class > D addresses. That way you you can use 0.0.0.0/0 when checking which > addresses matches rather than having to use 0.0.0.0/1 + 128.0.0.0/2 > + 192.0.0.0/3 as the default matching acl in configs for the unicast > addresses. With longest prefix match one could maybe say 0.0.0.0/0 -> some prefix 224.0.0.0/4 -> ignore Anyway, I suggest implementations can figure this out. We can just say that by default multicast addresses should be ignored. I think ignore is useful for 127.0.0.0/8, and the RFC1918 ranges etc. as well. Stig > Mark > >> A >> >> -- >> Andrew Sullivan >> ajs@shinkuro.com >> Shinkuro, Inc. >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave From zhangdong_rh@huaweisymantec.com Tue Aug 18 21:29:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC073A6921 for ; Tue, 18 Aug 2009 21:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3NvUS0HcLwA for ; Tue, 18 Aug 2009 21:29:47 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 77F713A686D for ; Tue, 18 Aug 2009 21:29:47 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5tHWDsuCvR9+8sI+/EPaBA)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KOL0080BTMVYWA0@hstga02-in.huaweisymantec.com> for behave@ietf.org; Wed, 19 Aug 2009 11:28:07 +0800 (CST) Received: from z90001956 ([10.27.154.76]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KOL0043RTMUCO10@hstml02-in.huaweisymantec.com> for behave@ietf.org; Wed, 19 Aug 2009 11:28:07 +0800 (CST) Date: Wed, 19 Aug 2009 11:28:06 +0800 From: Dong Zhang To: denghui02 Message-id: <200908191128063243076@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: behave Subject: [BEHAVE] A question for draft-huang-pnat-host-ipv6-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 04:29:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_5tHWDsuCvR9+8sI+/EPaBA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Hui, I have a confusion about PNAT44COM. Sorry if i miss something discussed previously. In the draft, the definition of PNAT44COM is: - PNAT44COM communication: When v4 application in the H1 need to - communicate with v4 application in the H2.Or when v4 applicaiton in - the H1 need to communicate with v4 application in the H3. My question is if v4 application in the H1 initiates a communication with v4 application in the H3, how does the PNAT64 know the packet need not to be translated? I mean PNAT64 should be able to differentiate between the packet to H3 and the packet to H2. Thanks a lot. 2009-08-19 Dong Zhang --Boundary_(ID_5tHWDsuCvR9+8sI+/EPaBA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi Hui,
 
I have a confusion about PNAT44COM. Sorry if i miss something discussed previously.
 
In the draft, the definition of PNAT44COM is:
 -   PNAT44COM communication: When v4 application in the H1 need to
 -  communicate with v4 application in the H2.Or when v4 applicaiton in
 -  the H1 need to communicate with v4 application in the H3.
My question is if v4 application in the H1 initiates a communication with v4 application
in the H3, how does the PNAT64 know the packet need not to be translated? I mean
PNAT64 should be able to differentiate between the packet to H3 and the packet to H2.
 
Thanks a lot.
 
2009-08-19
Dong Zhang
 
 --Boundary_(ID_5tHWDsuCvR9+8sI+/EPaBA)-- From marka@isc.org Tue Aug 18 21:34:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887933A6921 for ; Tue, 18 Aug 2009 21:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNGzQ2GEodck for ; Tue, 18 Aug 2009 21:34:23 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id CC79D3A69AE for ; Tue, 18 Aug 2009 21:34:04 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0DD86E609C; Wed, 19 Aug 2009 04:34:06 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7J4Y4vM009316; Wed, 19 Aug 2009 14:34:04 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> To: Stig Venaas From: Mark Andrews References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> In-reply-to: Your message of "Tue, 18 Aug 2009 21:23:17 MST." <4A8B7E35.9070500@venaas.com> Date: Wed, 19 Aug 2009 14:34:04 +1000 Sender: marka@isc.org Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 04:34:24 -0000 In message <4A8B7E35.9070500@venaas.com>, Stig Venaas writes: > Mark Andrews wrote: > > In message <20090818165041.GI3163@shinkuro.com>, Andrew Sullivan writes: > >> Mark, > >> > >> On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: > >> > >>> DNS64 is a unicast translator, i.e class A, B and C address. Class > >>> D and E are out of scope for DNS64. Anything else is local configuration > . > >> What about the suggested text from Jyrki Soini, downthread? It seems > >> to be consistent with what you are suggesting while allowing for the > >> requested behaviour. > > > > Something like that would be fine. > > > > I would still exclude Class E addresses. > > > > I would add text to ensure that Class D are mapped into FF00::/8 > > (or whatever the correct IPv6 multicast prefix is). > > > > I would describe these as a unicast prefix and multicast prefix and > > say that the unicast prefix only applies to Class A, B and C > > addresses. Similarly the multicast prefix only applies to the Class > > D addresses. That way you you can use 0.0.0.0/0 when checking which > > addresses matches rather than having to use 0.0.0.0/1 + 128.0.0.0/2 > > + 192.0.0.0/3 as the default matching acl in configs for the unicast > > addresses. > > With longest prefix match one could maybe say > > 0.0.0.0/0 -> some prefix > 224.0.0.0/4 -> ignore > > Anyway, I suggest implementations can figure this out. We can just say > that by default multicast addresses should be ignored. > > I think ignore is useful for 127.0.0.0/8, and the RFC1918 ranges etc. as > well. 127.0.0.0/8 maybe RFC1918 no. I can well see this being used internally to connect to local legacy devices instead of running dual stack internally. If you get RFC1918 addresses from the DNS then translating them is the correct thing to do. > Stig > > > Mark > > > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@shinkuro.com > >> Shinkuro, Inc. > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From stig@venaas.com Tue Aug 18 21:35:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAE73A6AC2 for ; Tue, 18 Aug 2009 21:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHR+3ytJPxsZ for ; Tue, 18 Aug 2009 21:35:49 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 0B7463A6AFB for ; Tue, 18 Aug 2009 21:35:49 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-186-244-131.dsl.pltn13.sbcglobal.net [99.186.244.131]) by ufisa.uninett.no (Postfix) with ESMTP id 76FCF38F9F; Wed, 19 Aug 2009 06:35:50 +0200 (CEST) Message-ID: <4A8B80FB.9030701@venaas.com> Date: Tue, 18 Aug 2009 21:35:07 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Mark Andrews References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> In-Reply-To: <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 04:35:51 -0000 Mark Andrews wrote: > In message <4A8B7E35.9070500@venaas.com>, Stig Venaas writes: >> Mark Andrews wrote: >>> In message <20090818165041.GI3163@shinkuro.com>, Andrew Sullivan writes: >>>> Mark, >>>> >>>> On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: >>>> >>>>> DNS64 is a unicast translator, i.e class A, B and C address. Class >>>>> D and E are out of scope for DNS64. Anything else is local configuration >> . >>>> What about the suggested text from Jyrki Soini, downthread? It seems >>>> to be consistent with what you are suggesting while allowing for the >>>> requested behaviour. >>> Something like that would be fine. >>> >>> I would still exclude Class E addresses. >>> >>> I would add text to ensure that Class D are mapped into FF00::/8 >>> (or whatever the correct IPv6 multicast prefix is). >>> >>> I would describe these as a unicast prefix and multicast prefix and >>> say that the unicast prefix only applies to Class A, B and C >>> addresses. Similarly the multicast prefix only applies to the Class >>> D addresses. That way you you can use 0.0.0.0/0 when checking which >>> addresses matches rather than having to use 0.0.0.0/1 + 128.0.0.0/2 >>> + 192.0.0.0/3 as the default matching acl in configs for the unicast >>> addresses. >> With longest prefix match one could maybe say >> >> 0.0.0.0/0 -> some prefix >> 224.0.0.0/4 -> ignore >> >> Anyway, I suggest implementations can figure this out. We can just say >> that by default multicast addresses should be ignored. >> >> I think ignore is useful for 127.0.0.0/8, and the RFC1918 ranges etc. as >> well. > > 127.0.0.0/8 maybe > > RFC1918 no. I can well see this being used internally to connect > to local legacy devices instead of running dual stack internally. > If you get RFC1918 addresses from the DNS then translating them is > the correct thing to do. Agree, but I think it needs to be configurable, Stig >> Stig >> >>> Mark >>> >>>> A >>>> >>>> -- >>>> Andrew Sullivan >>>> ajs@shinkuro.com >>>> Shinkuro, Inc. >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave From lin.xiao@nsn.com Wed Aug 19 01:15:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278243A6A53 for ; Wed, 19 Aug 2009 01:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQWZkB8X25Wq for ; Wed, 19 Aug 2009 01:15:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 049BB3A6889 for ; Wed, 19 Aug 2009 01:15:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n7J8BdTT009607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Aug 2009 10:11:40 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n7J8BZFk008400; Wed, 19 Aug 2009 10:11:39 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 10:11:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA20A4.A798098B" Date: Wed, 19 Aug 2009 16:11:24 +0800 Message-ID: <5D84FDD8D5DC8646B9F73CF1EFD1BFA4A683BE@CNBEEXC007.nsn-intra.net> In-Reply-To: <200908191128063243076@huaweisymantec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] A question for draft-huang-pnat-host-ipv6-01.txt Thread-Index: AcoghbqzGGT/invjTaWmzlR/gzZOPwAGXAZg References: <200908191128063243076@huaweisymantec.com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Dong Zhang" , "denghui02" X-OriginalArrivalTime: 19 Aug 2009 08:11:32.0265 (UTC) FILETIME=[A96C4190:01CA20A4] Cc: behave Subject: Re: [BEHAVE] A question for draft-huang-pnat-host-ipv6-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 08:15:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA20A4.A798098B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IMHO, all the applications in the IPv6 site using PNAT ( shown in Figure 1 of draft-huang-pnat-host-ipv6-01.txt ) MUST register AAAA records in the local DNSv6 no matter whether the applications are IPv4 or IPv6. So, the access to the application of H3, even if the application is v4, the packets are routed within the local pure IPv6 site naturally according to the IPv6 address resolved from the local DNSv6. Only if the resolved address is an IPv4 only address (i.e., the destination is outside the site), the WKP is added to form a IPv6 destination address and all the packets are required to go through PNAT64. Therefore, only outbound traffic need go through the PNAT64, while the in site communication are IPv6 automatically. However, the hosts with IPv4 applications must solve the mapping between their internal IPv4 addresses and external IPv6 addresses. =20 BR Lin Xiao ________________________________ From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of ext Dong Zhang Sent: Wednesday, August 19, 2009 11:28 AM To: denghui02 Cc: behave Subject: [BEHAVE] A question for draft-huang-pnat-host-ipv6-01.txt Hi Hui, =20 I have a confusion about PNAT44COM. Sorry if i miss something discussed previously. =20 In the draft, the definition of PNAT44COM is: - PNAT44COM communication: When v4 application in the H1 need to - communicate with v4 application in the H2.Or when v4 applicaiton in - the H1 need to communicate with v4 application in the H3. My question is if v4 application in the H1 initiates a communication with v4 application=20 in the H3, how does the PNAT64 know the packet need not to be translated? I mean=20 PNAT64 should be able to differentiate between the packet to H3 and the packet to H2. =20 Thanks a lot. =20 2009-08-19=20 ________________________________ Dong Zhang =20 ------_=_NextPart_001_01CA20A4.A798098B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
IMHO,=20 all the applications in the IPv6 site using PNAT ( shown in = Figure 1=20 of  draft-huang-pnat-host-ipv6-01.txt = ) MUST=20 register AAAA records in the local DNSv6 no matter whether the = applications are=20 IPv4 or IPv6. So, the access to the application of H3, even if the=20 application is v4, the packets are routed within the local pure IPv6 = site=20 naturally according to the IPv6 address resolved from the local DNSv6. = Only if=20 the resolved address is an IPv4 only address (i.e., the destination is = outside=20 the site), the WKP is added to form a IPv6 destination address = and all the=20 packets are required to go through PNAT64. Therefore, only outbound = traffic need=20 go through the PNAT64, while the in site communication are IPv6=20 automatically. However, the hosts with IPv4 applications must = solve=20 the mapping between their internal IPv4 addresses and external IPv6=20 addresses.
 
BR
Lin = Xiao

From: behave-bounces@ietf.org=20 [mailto:behave-bounces@ietf.org] On Behalf Of ext Dong=20 Zhang
Sent: Wednesday, August 19, 2009 11:28 AM
To:=20 denghui02
Cc: behave
Subject: [BEHAVE] A question = for=20 draft-huang-pnat-host-ipv6-01.txt

Hi Hui,
 
I have a confusion about PNAT44COM. Sorry if i miss something=20 discussed previously.
 
In the draft, the definition of PNAT44COM is:
 -   PNAT44COM communication: When v4 application in = the H1=20 need to
 -  communicate with v4 application in the H2.Or = when v4=20 applicaiton in
 -  the H1 need to communicate with v4 = application=20 in the H3.
My question is if v4 application in the H1 initiates a = communication=20 with v4 application
in the H3, how does the PNAT64 know the packet need not to be = translated? I=20 mean
PNAT64 should be able to differentiate between the packet to H3 and = the=20 packet to H2.
 
Thanks a lot.
 
2009-08-19 =
Dong Zhang
 
------_=_NextPart_001_01CA20A4.A798098B-- From iljitsch@muada.com Wed Aug 19 02:20:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15763A69A6 for ; Wed, 19 Aug 2009 02:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERa4pK+c36m6 for ; Wed, 19 Aug 2009 02:20:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id AB9103A6864 for ; Wed, 19 Aug 2009 02:20:42 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7J9KC6X055308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 11:20:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <36655EFA-B813-427A-B3B3-B910D9E70C86@muada.com> From: Iljitsch van Beijnum To: Mark Andrews In-Reply-To: <200908162328.n7GNS6So072710@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 11:20:39 +0200 References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> X-Mailer: Apple Mail (2.936) Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 09:20:43 -0000 On 17 aug 2009, at 1:28, Mark Andrews wrote: > DNS64 is a unicast translator, i.e class A, B and C address. Class > D and E are out of scope for DNS64. Anything else is local > configuration. Treating class E as a special case landed us in the situation where 268 million perfectly good IPv4 addresses are unusable in practice. So don't treat class E as a special case. Also don't treat RFC 1918 as a special case, just in case the NAT64 operator hosts some services on these addresses or something. Nets 0/8 and 127/8 and 255.255.255.255/32 could be filtered as well as class D and maybe 169.254/16 but I'm not sure the effort of filtering is offset by any practical benefits. From iljitsch@muada.com Wed Aug 19 02:37:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BD728C237 for ; Wed, 19 Aug 2009 02:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0upNkpMujrEj for ; Wed, 19 Aug 2009 02:37:33 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0743A6C58 for ; Wed, 19 Aug 2009 02:37:33 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7J9b3PK056065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Aug 2009 11:37:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <9C66C138-20AB-41D7-BC07-0F76E7885202@muada.com> From: Iljitsch van Beijnum To: Andrew Sullivan In-Reply-To: <20090731201043.GD14838@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 19 Aug 2009 11:37:31 +0200 References: <200907280735.n6S7ZIJv001883@drugs.dv.isc.org> <20090728091805.GB5567@shinkuro.com> <200907280947.n6S9lpFH004793@drugs.dv.isc.org> <20090728105037.GD6181@shinkuro.com> <200907281059.n6SAxBfP002154@drugs.dv.isc.org> <20090728154755.GH6181@shinkuro.com> <200907282030.n6SKTp2T003501@drugs.dv.isc.org> <20090731201043.GD14838@shinkuro.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org Subject: Re: [BEHAVE] draft-ietf-behave-dns64-00 Additional section processing X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 09:37:34 -0000 On 31 jul 2009, at 22:10, Andrew Sullivan wrote: > Suppose one has a DNS server that offers recursion and performs > caching, and that it is behind a DNS64. I'll call this system "B" for > the sake of brevity. B can happen on a CPE box, for instance, which > usually gets its own list of nameservers from DHCP. What B does > _not_ have is a root.hints file: it relies on an upstream server for > some work, in order to make use of the existing cache at the ISP. The > critical ingedient here is that the nameserver is not merely > forwarding. So you're saying that even though this server can simply forward all queries to the ISP nameservers it will try to do its own recursive lookups sometimes and return a failure to the client if that doesn't work? Such a server wouldn't work in an IPv6-only environment today, and probably also not in an IPv4-only environment in the future. This has nothing to do with DNS64, just with the fact that if you want to resolve information that resides on v4-only servers when you only have v6 there is not a lot you can do. (And NAT64 won't help you because you're trying to access literal IPv4 addresses.) As such, the only reasonable way forward is saying "don't do that". Especially since this strange mixture of recursive/forwarding nameserver doesn't seem to have any useful properties. IPv6 CPE specifications are currently being worked on so it's not too late to avoid this type of DNS servers from escaping into the wild. From ari.keranen@nomadiclab.com Wed Aug 19 03:22:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99D53A6D4D for ; Wed, 19 Aug 2009 03:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.086 X-Spam-Level: X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[AWL=1.163, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO6TkexAu7Vd for ; Wed, 19 Aug 2009 03:22:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C0D513A6902 for ; Wed, 19 Aug 2009 03:22:55 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf2ae000007ae0-4d-4a8bd283ea30 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2B.8A.31456.382DB8A4; Wed, 19 Aug 2009 12:22:59 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:21:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 12:21:28 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 43A562495; Wed, 19 Aug 2009 13:21:28 +0300 (EEST) Message-ID: <4A8BD224.1070508@nomadiclab.com> Date: Wed, 19 Aug 2009 13:21:24 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: draft-ietf-behave-turn-tcp@tools.ietf.org References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> In-Reply-To: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2009 10:21:28.0691 (UTC) FILETIME=[D0747430:01CA20B6] X-Brightmail-Tracker: AAAAAA== Cc: behave@ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 10:22:56 -0000 Hi, One technical issue in draft-ietf-behave-turn-tcp-04 caught my attention: In section 4.5., "Sending and Receiving Data" is says: [...] Data on a data connection MUST NOT be interpreted as STUN messages. I think this is too heavy restriction. What about if the peer wants to send some STUN messages on the path via the TURN server and would need the TURN client to parse them as STUN? I would rather make this "SHOULD NOT" to be future proof. Or even removing the whole restriction should not do much harm, right? Cheers, Ari From simon.perreault@viagenie.ca Wed Aug 19 04:31:18 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FAF3A6948 for ; Wed, 19 Aug 2009 04:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aSmKnbscOnm for ; Wed, 19 Aug 2009 04:31:17 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 1C68C3A67DA for ; Wed, 19 Aug 2009 04:31:16 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 52A8329E15F0; Wed, 19 Aug 2009 07:31:17 -0400 (EDT) Message-ID: <4A8BE278.2030505@viagenie.ca> Date: Wed, 19 Aug 2009 07:31:04 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: liu dapeng References: <4A72F0BF.4000609@viagenie.ca> <25e1aaa40908121019o582694f1u79256876bfad4104@mail.gmail.com> In-Reply-To: <25e1aaa40908121019o582694f1u79256876bfad4104@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Behave WG Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 11:31:18 -0000 Le 2009-08-12 13:19, liu dapeng a crit : > Why the DNS64 synthesize AAAA records for upstream DNS servers? > > Since DNS64 has both IPv4 and IPv6 address, why not use its IPv4 > interface to send the recurse query to the upstream DNS if the > upstream DNS has an IPv4 address? This case is explained here: >> Note: If the DNS64 has a usable IPv4 connection, it is expected >> that the directive will be set to false. Note that "IPv4 address" does not equate "usable IPv4 connection". You need static configuration to differentiate between the two. It is the network administrator's job to decide. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Wed Aug 19 04:45:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253703A6EB0 for ; Wed, 19 Aug 2009 04:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx+2-3EbnC-d for ; Wed, 19 Aug 2009 04:45:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8A56F3A6E96 for ; Wed, 19 Aug 2009 04:45:21 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 298A129E15F0; Wed, 19 Aug 2009 07:45:24 -0400 (EDT) Message-ID: <4A8BE5CD.6040900@viagenie.ca> Date: Wed, 19 Aug 2009 07:45:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Ari Keranen References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> <4A8BD224.1070508@nomadiclab.com> In-Reply-To: <4A8BD224.1070508@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 11:45:23 -0000 Le 2009-08-19 06:21, Ari Keranen a crit : > Or even > removing the whole restriction should not do much harm, right? I have no opinion about this. Unless somebody else has something to say, I'll remove the passage. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From dthaler@microsoft.com Wed Aug 19 12:35:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2973A67EF for ; Wed, 19 Aug 2009 12:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.375 X-Spam-Level: X-Spam-Status: No, score=-10.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGABVrn3WKsH for ; Wed, 19 Aug 2009 12:35:26 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 4AF373A677D for ; Wed, 19 Aug 2009 12:35:26 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Aug 2009 12:35:31 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.621.7; Wed, 19 Aug 2009 12:35:31 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 19 Aug 2009 12:35:30 -0700 From: Dave Thaler To: Xu Xiaohu , 'Behave WG' Thread-Topic: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 Thread-Index: AQHKFWtzLra1EIT+6EKUxpLu15hDKJCt3Rxg Date: Wed, 19 Aug 2009 19:35:27 +0000 Message-ID: References: <001f01ca156b$5aaad6f0$5e0c6f0a@china.huawei.com> In-Reply-To: <001f01ca156b$5aaad6f0$5e0c6f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:35:27 -0000 There was discussion in the intarea meeting at IETF 74. Minutes: http://www.ietf.org/proceedings/74/minutes/intarea.txt Slides: http://www.ietf.org/proceedings/74/slides/intarea-4.pdf The discussion concluded by saying that defining an RA option that can contain DHCP options seems like a good idea. E.g. from the minutes: "- Krishnan: Pointing out that he wrote a spec on how to share options betw= een DHCP and RA's." Perhaps Suresh can provide more info here. -Dave > -----Original Message----- > From: Xu Xiaohu [mailto:xuxh@huawei.com] > Sent: Tuesday, August 04, 2009 6:24 PM > To: Dave Thaler; 'Behave WG' > Subject: re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 > > Hi Dave, > > > 4) If there are folks (not me) that really believe in RA > configuration > > for information that the local router isn't authoritative for, > > there's already interest in defining an RA option that can contain > > DHCP options so you don't have to define RA options for > > all of them. > > Defining an RA option that can contains DHCP options directly seems a > good > idea. Could you please provide any detailed clues? > > Thanks, > > Xiaohu > From suresh.krishnan@ericsson.com Wed Aug 19 12:47:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46C93A6FBF for ; Wed, 19 Aug 2009 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2TwjmeOtnHl for ; Wed, 19 Aug 2009 12:47:58 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id E3DA23A67E1 for ; Wed, 19 Aug 2009 12:47:57 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n7JJllvt028448; Wed, 19 Aug 2009 14:47:47 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 14:46:54 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Aug 2009 14:46:53 -0500 Message-ID: <4A8C56AE.4040304@ericsson.com> Date: Wed, 19 Aug 2009 15:46:54 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Dave Thaler References: <001f01ca156b$5aaad6f0$5e0c6f0a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Aug 2009 19:46:53.0969 (UTC) FILETIME=[CD7F1010:01CA2105] Cc: 'Behave WG' , Xu Xiaohu Subject: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:47:58 -0000 Hi Dave, Here is a pointer to that doc. http://tools.ietf.org/html/draft-krishnan-intarea-ra-dhcp-00 I did not update this document further since there was a possibility of redundant (and potentially conflicting) information being passed thru this mechanism and dhcpv6 (Section 2.3 of RFC5505) and I did not know how to reconcile these pieces of info on the host. Cheers Suresh On 09-08-19 03:35 PM, Dave Thaler wrote: > There was discussion in the intarea meeting at IETF 74. > > Minutes: http://www.ietf.org/proceedings/74/minutes/intarea.txt > Slides: http://www.ietf.org/proceedings/74/slides/intarea-4.pdf > > The discussion concluded by saying that defining an RA option that can > contain DHCP options seems like a good idea. E.g. from the minutes: > "- Krishnan: Pointing out that he wrote a spec on how to share options between DHCP and RA's." > > Perhaps Suresh can provide more info here. > > -Dave > >> -----Original Message----- >> From: Xu Xiaohu [mailto:xuxh@huawei.com] >> Sent: Tuesday, August 04, 2009 6:24 PM >> To: Dave Thaler; 'Behave WG' >> Subject: re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 >> >> Hi Dave, >> >>> 4) If there are folks (not me) that really believe in RA >> configuration >>> for information that the local router isn't authoritative for, >>> there's already interest in defining an RA option that can contain >>> DHCP options so you don't have to define RA options for >>> all of them. >> Defining an RA option that can contains DHCP options directly seems a >> good >> idea. Could you please provide any detailed clues? >> >> Thanks, >> >> Xiaohu >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Wed Aug 19 17:54:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBE13A68E1 for ; Wed, 19 Aug 2009 17:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.381 X-Spam-Level: X-Spam-Status: No, score=-10.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCt+8ey0kGxI for ; Wed, 19 Aug 2009 17:54:35 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D6FAA3A68A5 for ; Wed, 19 Aug 2009 17:54:35 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Aug 2009 17:54:41 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.621.7; Wed, 19 Aug 2009 17:54:41 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 19 Aug 2009 17:54:39 -0700 From: Dave Thaler To: 'Behave WG' Thread-Topic: Draft IETF 75 minutes now available Thread-Index: AcohMMk84ipSMsAqQxitHhMy1ha6NA== Date: Thu, 20 Aug 2009 00:54:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E4561B14EE2A3E4E9D478EBFB5416E1B1AC1ABTK5EX14MBXW653win_" MIME-Version: 1.0 Subject: [BEHAVE] Draft IETF 75 minutes now available X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 00:54:36 -0000 --_000_E4561B14EE2A3E4E9D478EBFB5416E1B1AC1ABTK5EX14MBXW653win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to Ed Jankiewicz and Stuart Cheshire for taking notes. The draft minutes are now online at: http://www.ietf.org/proceedings/75/minutes/behave.txt Please send any corrections to the chairs. Thanks, -Dave Thaler --_000_E4561B14EE2A3E4E9D478EBFB5416E1B1AC1ABTK5EX14MBXW653win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to Ed Jankiewicz and Stuart Cheshire for taking= notes.

 

The draft minutes are now online at:

http://www.i= etf.org/proceedings/75/minutes/behave.txt

 

Please send any corrections to the chairs.<= /p>

 

Thanks,

-Dave Thaler

--_000_E4561B14EE2A3E4E9D478EBFB5416E1B1AC1ABTK5EX14MBXW653win_-- From root@core3.amsl.com Wed Aug 19 19:00:01 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A676028C448; Wed, 19 Aug 2009 19:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090820020001.A676028C448@core3.amsl.com> Date: Wed, 19 Aug 2009 19:00:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 02:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Author(s) : M. Petit-Huguenin Filename : draft-ietf-behave-turn-uri-03.txt Pages : 14 Date : 2009-08-19 This document defines two URI schemes and the resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-behave-turn-uri-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-19185725.I-D@ietf.org> --NextPart-- From petithug@acm.org Wed Aug 19 19:10:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F403A69CF for ; Wed, 19 Aug 2009 19:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pny8-kiiIvMn for ; Wed, 19 Aug 2009 19:10:35 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4EC0F3A6957 for ; Wed, 19 Aug 2009 19:10:35 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 851D8DBCC018; Thu, 20 Aug 2009 02:10:40 +0000 (UTC) Received: from [192.168.1.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id DAD97DBCC012 for ; Thu, 20 Aug 2009 02:10:39 +0000 (UTC) Message-ID: <4A8CB09F.8020807@acm.org> Date: Wed, 19 Aug 2009 19:10:39 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Behave WG References: <20090820020001.A676028C448@core3.amsl.com> In-Reply-To: <20090820020001.A676028C448@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 02:10:38 -0000 This new version contains all the modifications discussed during the WGLC. A version for the Amazon Kindle is available here: http://ietf.implementers.org/draft-ietf-behave-turn-uri-03.mobi Changelog: o A turn:?transport=TCP URI fails if the list of supported transports contains only TLS. Using a TLS transport in this case was underspecified. o Reordered paragraphs in section 4. o Added table for conversion of and to TURN transport. o Various editorial modifications. o SRV algorithm changed to "...recommending an A and AAAA query." o Put back the changelog for the versions before been accepted as WG item. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From xuxh@huawei.com Wed Aug 19 20:30:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0C528C0D0 for ; Wed, 19 Aug 2009 20:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.862 X-Spam-Level: ** X-Spam-Status: No, score=2.862 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmjIS9Rk8U3A for ; Wed, 19 Aug 2009 20:30:47 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E679328C0EA for ; Wed, 19 Aug 2009 20:30:46 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KON006MHOF5Q2@szxga02-in.huawei.com> for behave@ietf.org; Thu, 20 Aug 2009 11:30:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KON005RXOF562@szxga02-in.huawei.com> for behave@ietf.org; Thu, 20 Aug 2009 11:30:41 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KON00G00OF5X6@szxml04-in.huawei.com> for behave@ietf.org; Thu, 20 Aug 2009 11:30:41 +0800 (CST) Date: Thu, 20 Aug 2009 11:30:41 +0800 From: Xu Xiaohu In-reply-to: <4A8C56AE.4040304@ericsson.com> To: 'Suresh Krishnan' , 'Dave Thaler' Message-id: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcohEuzV5ELqClh2TXCCUny8OpTgLwAM4/EQ Cc: 'Behave WG' Subject: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 03:30:48 -0000 Hi Dave and Suresh, Thanks a lot for your valuable information.=20 >From the following two drafts, it can be easily concluded that both = DHCPv6 and RA have their own markets. The harassment to ISPs is they had to use these two mechanisms together in some cases because some option defined = in one mechanism has no counterpart in the other one. Either the DHCP = carrier option in RA or the default router option (even the possible RA carrier option) in DHCPv6 is to deal with the above problem. To avoid redundant standardization effort, except the idea of DHCP (or RA) carrier option, another possible way is to unify their TLVs of common options for both = RA and DHCPv6, especially the TLV of a new option (e.g., the prefix64 = option), although the length of their Type/Length field is different from each = other unfortunately. +++++++++++Some quotes from the following two drafts,=20 +++++++++++FYI.++++++++++++++++ In http://tools.ietf.org/html/draft-krishnan-intarea-ra-dhcp-00, there = was a statement as "... Recently there has been interest in doing more of DHCP work using Neighbor Discovery (Router Advertisement) messages. This = is mainly to accomodate environments where DHCP is not available and the = only way of convey configuration information is through RAs." In http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00, there was a statement as " In many IPv6 deployments, particularly in = edge networks, end devices obtain configuration information about default routers, on-link prefixes and addresses from Router Advertisements as defined in Neighbor Discovery. In some deployments, however, there is a strong desire not to use Router Advertisements at all and to perform all configuration via DHCP [RFC3315]." +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++ Xiaohu > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Suresh Krishnan = [mailto:suresh.krishnan@ericsson.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA8=D4=C220=C8=D5 3:47 > =CA=D5=BC=FE=C8=CB: Dave Thaler > =B3=AD=CB=CD: Xu Xiaohu; 'Behave WG' > =D6=F7=CC=E2: Re: [BEHAVE] Comments on = draft-wing-behave-learn-prefix-03 >=20 > Hi Dave, > Here is a pointer to that doc. >=20 > http://tools.ietf.org/html/draft-krishnan-intarea-ra-dhcp-00 >=20 > I did not update this document further since there was a possibility = of > redundant (and potentially conflicting) information being passed thru > this mechanism and dhcpv6 (Section 2.3 of RFC5505) and I did not know > how to reconcile these pieces of info on the host. >=20 > Cheers > Suresh >=20 > On 09-08-19 03:35 PM, Dave Thaler wrote: > > There was discussion in the intarea meeting at IETF 74. > > > > Minutes: http://www.ietf.org/proceedings/74/minutes/intarea.txt > > Slides: http://www.ietf.org/proceedings/74/slides/intarea-4.pdf > > > > The discussion concluded by saying that defining an RA option that = can > > contain DHCP options seems like a good idea. E.g. from the minutes: > > "- Krishnan: Pointing out that he wrote a spec on how to share = options between > DHCP and RA's." > > > > Perhaps Suresh can provide more info here. > > > > -Dave > > > >> -----Original Message----- > >> From: Xu Xiaohu [mailto:xuxh@huawei.com] > >> Sent: Tuesday, August 04, 2009 6:24 PM > >> To: Dave Thaler; 'Behave WG' > >> Subject: re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03 > >> > >> Hi Dave, > >> > >>> 4) If there are folks (not me) that really believe in RA > >> configuration > >>> for information that the local router isn't authoritative for, > >>> there's already interest in defining an RA option that can = contain > >>> DHCP options so you don't have to define RA options for > >>> all of them. > >> Defining an RA option that can contains DHCP options directly seems = a > >> good > >> idea. Could you please provide any detailed clues? > >> > >> Thanks, > >> > >> Xiaohu > >> > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave From maxpassion@gmail.com Thu Aug 20 06:59:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EB03A6DA1 for ; Thu, 20 Aug 2009 06:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6SSt5dOE-VF for ; Thu, 20 Aug 2009 06:59:55 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id F2AC03A6B39 for ; Thu, 20 Aug 2009 06:59:23 -0700 (PDT) Received: by vws34 with SMTP id 34so4610598vws.31 for ; Thu, 20 Aug 2009 06:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Lfcpf9Fn/HiOCe4DwG6E3TZKjfsOPkUaNXLBrdbSuSk=; b=SMJcbmlVZUUHcDb+gJghXtns7kR6WMcfKGYuhrybprXXLltoZH4+9u+7n35LsBRk0w i5dBTr3imoGMQctx2n3LreSQ+fCw5tPTOi9+UBIx12g5zIDV9Ou9tXP4bOfkzj4eSVnW 8g4fCzDl4dHII7up8TuQ7VZmMQhNQzvpMpYeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Ww/aNTE8/yINVUSgaX4Z3HwvYG5H7RhfxqVDFA7cO5u24hiYECe6+bUkH6yExKRUa+ o0VrVJX4dguO2QOuXDSpLbb5ZfcShnMOpryHqG//5aC3vj/tG88uj/DhBfxRtXPiQbpH mURpEq0fULecfQmn6q24sKddcd7wCcmL6K8CY= MIME-Version: 1.0 Received: by 10.220.103.135 with SMTP id k7mr10933076vco.59.1250776767376; Thu, 20 Aug 2009 06:59:27 -0700 (PDT) Date: Thu, 20 Aug 2009 21:59:27 +0800 Message-ID: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> From: liu dapeng To: behave@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 13:59:56 -0000 Hello everyone: We have posted a draft about FTP64 issue (http://tools.ietf.org/html/draft-liu-behave-ftp64-00). We know that there is another solution proposed (http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-05), but we have a different view and approache regarding to this problem, the main differences are: 1. Our viewpoint regarding to FTP64 is that since the ALG problem could be totally avoided by carefully defining the behavior of the FTP client and server, translation box need not to implement FTP ALG. 2.We propose that the client just uses the control channel=92s IP address when it retries with PASV command. This approach not only simplifies the client's implementation, but also avoids some problems caused by using the IPv4 connectivity of the client. Any comments are welcome. BR, Dapeng Liu From iljitsch@muada.com Thu Aug 20 08:16:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3103A701E for ; Thu, 20 Aug 2009 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITDb4PR0tRPP for ; Thu, 20 Aug 2009 08:16:01 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 298E13A7017 for ; Thu, 20 Aug 2009 08:16:01 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7KFFTCa070342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Aug 2009 17:15:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <632E01AE-A0CE-42F9-9A35-38FF1AD5E576@muada.com> From: Iljitsch van Beijnum To: liu dapeng In-Reply-To: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 Aug 2009 17:15:57 +0200 References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 15:16:02 -0000 On 20 aug 2009, at 15:59, liu dapeng wrote: > 1. Our viewpoint regarding to FTP64 is that since the ALG problem > could be totally avoided by carefully defining the behavior of the FTP > client and server, translation box need not to implement FTP ALG. Ok, you don't want to run an FTP64 ALG. However, what if other people do want to run an FTP64 ALG? In that case, it's useful to have a specification about how such an ALG should behave, so that interoperability problems can be avoided. So I would like to know from you: - do you want the ALG specification to be removed from the FTP64 document? And from others: - do you foresee yourself implementing and/or running an FTP64 ALG? If the answer to both questions is "yes" then we have a hard decision to make... From iljitsch@muada.com Thu Aug 20 08:57:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B27D3A6961 for ; Thu, 20 Aug 2009 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vz22BHhfV2g for ; Thu, 20 Aug 2009 08:57:21 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 01A533A67FE for ; Thu, 20 Aug 2009 08:57:20 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7KFupDg070656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Aug 2009 17:56:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Behave WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 Aug 2009 17:57:19 +0200 X-Mailer: Apple Mail (2.936) Subject: [BEHAVE] 64 MTU and fragmentation handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 15:57:22 -0000 Hi, We had a fruitful discussion about MTU and fragmentation handling in the online interim meeting yesterday. My original options for handing < 1280 MTUs on the IPv4 side for stateful translation: 1. Depend on RFC 2460/2765 behavior where 1280-byte packets with a fragment header are sent after a < 1280 "too big" message, translator sets DF=0 when translating packets with a fragment header, DF=1 otherwise. The problem with this is that there is the possibility of a black hole when the operator disables path MTU discovery on the IPv6 side by setting the MTU to 1280 and filtering "too big" messages. In that case, the fragment header is never included, the translator generates a 1260-byte IPv6 packet with DF=1 and communication is impossible. This requires unusual, but not unheard of cases on both the v4 and v6 sides (< 1260 MTU, PMTUD disabled), but the problem is that in the pure IPv4 and pure IPv6 cases these wouldn't cause trouble, it's only when communicating through a translator that the black hole presents itself. Solution in the draft: 3. Rewrite "too big" messages to provide a 1280-byte MTU and have the translator set DF=0 for packets <= 1280 bytes and DF=1 for packets > 1280 bytes. Alternative solution: 2. Adopt the RFC 2460/2765 behavior, except that to avoid the black hole, packets <= 1280 are sent with DF=0 even if there is no fragment header. Additional solution mentioned yesterday: 4. Let the translator track path MTU sizes for IPv4 destinations and fragment packets at the source where needed (just like normal IPv6 hosts do for IPv6, and in our specification, the translator also does this for packets going towards the IPv6 side). One argument that was made yesterday was the applicability to stateless translation. Obviously a mechanism that works for both stateful and stateless would be better than separate mechanisms for both. (However, note that the identification value handling needs to be different between stateful and stateless translation regardless of path MTU discovery handling.) However, solutions 2 and 4 equally apply to the stateful and stateless cases. Solution 3 is somewhat less suited for the stateless case, because it requires the translator to come up with an identification value. If traffic is flowing through multiple translators the identification values could clash and result in reassembly errors. All solutions produce fragments (except perhaps option 4 in the case of TCP when TCP is resegmented rather than fragmented), with the associated risk of incorrect reassemly and subsequent dependence on the weak TCP/UDP checksum to avoid data corruption. Option 4 has the disadvantage of creating more work for the translator and generating more packets and bits, taking over this work from the router in front of the < 1280 byte MTU link on the IPv4 side. As such, I favor option 2 for both stateful and stateless translation, and if implementers feel 4 is a viable option I would be willing to include that as a not specifically recommended alternative. Thoughts? From dthaler@microsoft.com Thu Aug 20 11:34:37 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEFEF3A6F05 for ; Thu, 20 Aug 2009 11:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.387 X-Spam-Level: X-Spam-Status: No, score=-10.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyXPwKzxOZSr for ; Thu, 20 Aug 2009 11:34:36 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3FE973A6EFA for ; Thu, 20 Aug 2009 11:34:00 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Aug 2009 11:32:09 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server id 14.0.621.7; Thu, 20 Aug 2009 11:32:08 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 20 Aug 2009 11:32:08 -0700 From: Dave Thaler To: 'Behave WG' Thread-Topic: Notes from interim conf call 8/19/2009 Thread-Index: AQHKIcSFQsw8YBZ5lEGlN+iqXArAzw== Date: Thu, 20 Aug 2009 18:32:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] Notes from interim conf call 8/19/2009 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:34:37 -0000 Please send any additions/corrections. -Dave Behave WG Interim conf call 8/19/2009 Attendees -------------- Dan Wing (chair) Dave Thaler (chair) Agnes Tow Andrew Sullivan Bo Zhou Congxiao Bao Dapeng Liu Fred Baker Gabor Bajko Gang Chen Hui Deng Iljitsch van Beijnum John Leslie Marcelo Bagnulo Phil Roberts Suresh Krishnan Xing Li Zhen Cao Notes taken by Dave Thaler draft-wing-behave-learn-prefix-03: Dan Wing --------- Dan presented his draft on learning the IPv6 prefix(es) used with IPv6/IPv4 translation. There was consensus on the case for the DNSSEC use, and for the address selection use, for learning the prefixes, but there was some disagreement about the use case for multicast and for IPv4 literals in URLs= . Most of the discussion focused on the solution alternatives: DNS vs DHCP vs= RA. Dave Thaler posted arguments for DHCP to the list last week, and summarized that posting during the call (essentially: DHCP requires no server changes for popular DHCP servers today, no client changes for Windows at least, and is consistent with IETF guidance on host configuration). Iljitsch summarized the argument for DNS, which is that Mac OSX doesn't support DHCPv6, and Linux doesn't have the API support that Windows has; also that not all IPv6 environments might have DHCPv6 relay functionality in routers whereas DNS can go across multiple hops. There was consensus that RAs were the most problematic, since they required routers to change (unlike DNS and DHCP where servers already support new records and options, Fred noted that routers today often cannot be configured with arbitrary RA options), and it would require many routers to be configured rather than a small number of DNS or DHCP servers, and this is especially problematic when the last hop routers are in a different network (or managed by a different organization) than the one running the translator. Still there was some interest in the possibility of a generic RA option container for DHCP options, as discussed in IntArea in IETF 74. It was acknowledged that applications could implement a simple protocol (RA or DHCP INFORM messages) to work around limitations in client stacks that don't have APIs for new options. Eventually those in the meeting got consensus to take the RA option off the table, but to keep both a DNS and a DHCP solution in the doc. MTU/Fragmentation Issues: Iljitsch van Beijnum ---------- The standard mechanism in RFC 2460 is that if a PktTooBig error comes back to a host with a size <1280, the host will send 1280 byte packets with a FragHdr, and the translator will take the presence of the FragHdr to set DF=3D0 in IPv4 packets. Iljitsch mentioned 3 cases where a black hole can arise: 1) If a host just sends 1280 byte packets without ever adding a FH, which would be an RFC violation. The feedback was that there's a small number of host stack implementations, and they get TAHI etc testing which verifies RFC compliance with this requirement, so this is not a very interesting case. 2) If the IPv6 network filters ICMPv6 messages (namely PktTooBig messages) traveling from the IPv6/IPv4 translator towards the IPv6-only host. 3) If the IPv4 network filters ICMPv4 messages (namely FragNeeded messages) travelling from the IPv4-only host towards the IPv6/IPv4 translator. There was some discussion on how likely the above scenarios were and whethe= r this was a problem in practice, or only in theory. Currently the attendees had no data that this problem occurs in practice (any more than the normal case which is no different with translation). If this turns out to be an issue worth considering, there are multiple ways to solve this: 1) Keep things the way they are now, which puts pressure on getting the problems fixed 2) Have the NAT64 set DF=3D0 if the packet is <=3D1280 bytes, regardless of whether a FragHdr is included 3) Same as 2, but also have the NAT64 send PktTooBig messages with a minimu= m of 1280 (so IPv6 hosts will never end up add a FragHdr as a result of following the RFC rule) 4) Do reassembly and fragmentation in the translator 5) Change transport protocols, a la RFC 4821 which isn't implemented on most hosts today Iljitsch proposed letting implementers choose between 2 or 3. The 4th option was brought up by Zhen and Fred who argued for it. There was some discussion about the problem also occurring (if it occurs at all, that is) with stateless translation not just stateful, and having a common solution may be better than a stateful-specific solution. Options 1, 4, and 5 apply to both. Iljitsch explained that stateful translation (actually 1:N translation) requires the translator to do IPv4 id allocation itself, to ensure uniquene= ss across flows from all the IPv6 nodes that share the same IPv4 translation address, and hence the id in the FragHdr isn't used. In contrast, stateles= s translation requires the client to ensure that the id in the FragHdr is unique since fragments could flow through different translators. So in theory different solutions could apply. There were multiple people (not Iljitsch) arguing for a common solution being better, but Iljitsch pointed out that option 2 is a one-line change in a NAT64 (and doesn't apply to stateless). Further discussion is needed on the list. Translation in the host (phone): Hui Deng ---------- The mobile network operator scenario is two hosts on an IPv6-only network communicating using IPv4-only applications, and you want the traffic to flo= w directly between the hosts rather than through some type of remote concentrator. Hui mentioned that on mobile phone platforms, it is easier to modify the host network stack than it is for other types of hosts. Dual-Stack Lite targets a similar scenario, but at the expense of having a central tunnel concentrator for IPv4 traffic, which the operator is trying to avoid. To solve this scenario using tunneling (without a central tunnel concentrat= or the operator is trying to avoid), it would require a host-to-host IPv4-over-IPv6 protocol, for which none exists. ISATAP and 6to4 are exampl= es of protocols that do host-to-host IPv6-over-IPv4 tunneling, but there's no equivalent for IPv4-over-IPv6. Dan Wing asked how one application would get the IPv4 address of another host in this scenario, when there's more hosts in the network than can be represented in the available IPv4 space. The answer was that DNS or whatever other mechanism is used needs to use the IPv6 address for uniqueness (e.g., AAAA queries in DNS), and the resolving host then has to locally synthesize an IPv4 address for that destination and maintain an internal mapping table used for translation. So the IPv4 address returned to the resolving application is only unique and usable within that host. At this point time was up, and further discussion was deferred to the list and/or the next conf call. The next interim conf call will be held the same time (7am Pacific Daylight Time) September 16th. From iljitsch@muada.com Thu Aug 20 11:45:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C513A6B8E for ; Thu, 20 Aug 2009 11:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEy3Ap3audMh for ; Thu, 20 Aug 2009 11:45:04 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id A25083A672E for ; Thu, 20 Aug 2009 11:45:00 -0700 (PDT) Received: from [192.168.0.192] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7KIhqDZ071691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Aug 2009 20:43:52 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Dave Thaler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 Aug 2009 20:44:20 +0200 References: X-Mailer: Apple Mail (2.936) Cc: Behave WG Subject: Re: [BEHAVE] Notes from interim conf call 8/19/2009 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:45:05 -0000 On 20 aug 2009, at 20:32, Dave Thaler wrote: > There were multiple people (not Iljitsch) arguing for a common > solution > being better, but Iljitsch pointed out that option 2 is a one-line > change > in a NAT64 (and doesn't apply to stateless). Actually option 2 does work with stateless translation to some degree. It does fix the black hole, but if the black hole was otherwise present, there is no identification value from the IPv6 fragment header, so the translator has to come up with one itself, and run an increased risk of incorrect reassembly because of that. However, with option 1 the packet would be sent with DF=1 and not make it to the other side at all. In the case where the fragment header is present as required by the RFCs, there is no difference between options 1 and 2. From stig@venaas.com Thu Aug 20 11:45:13 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7977B3A6830 for ; Thu, 20 Aug 2009 11:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iusUZvtBjfVb for ; Thu, 20 Aug 2009 11:45:12 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 4FC0F3A6C18 for ; Thu, 20 Aug 2009 11:45:12 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id D08E037E77; Thu, 20 Aug 2009 20:45:15 +0200 (CEST) Message-ID: <4A8D99B8.6090609@venaas.com> Date: Thu, 20 Aug 2009 11:45:12 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Xu Xiaohu References: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> In-Reply-To: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: 'Behave WG' , 'Dave Thaler' Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:45:13 -0000 Xu Xiaohu wrote: > Hi Dave and Suresh, > > Thanks a lot for your valuable information. > > From the following two drafts, it can be easily concluded that both DHCPv6 > and RA have their own markets. The harassment to ISPs is they had to use > these two mechanisms together in some cases because some option defined in > one mechanism has no counterpart in the other one. Either the DHCP carrier > option in RA or the default router option (even the possible RA carrier > option) in DHCPv6 is to deal with the above problem. To avoid redundant > standardization effort, except the idea of DHCP (or RA) carrier option, > another possible way is to unify their TLVs of common options for both RA > and DHCPv6, especially the TLV of a new option (e.g., the prefix64 option), > although the length of their Type/Length field is different from each other > unfortunately. There are also examples of DHCPv6 options that would not make sense in RAs. So one might need to specify which options should be supported. Stig From rpenno@juniper.net Thu Aug 20 11:52:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC47C3A6AEA for ; Thu, 20 Aug 2009 11:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7oqYswtjTxK for ; Thu, 20 Aug 2009 11:52:55 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 48B9C3A691D for ; Thu, 20 Aug 2009 11:52:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSo2biMUN9eEd+VXoKiVWzdz5YMfAzJe+@postini.com; Thu, 20 Aug 2009 11:53:00 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 20 Aug 2009 11:48:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 20 Aug 2009 14:48:19 -0400 From: Reinaldo Penno To: Iljitsch van Beijnum , liu dapeng Date: Thu, 20 Aug 2009 14:48:18 -0400 Thread-Topic: [BEHAVE] A New Draft on FTP64 Thread-Index: AcohqSc2fHetPigjQeyvF49C3Cu1xQAHaEFn Message-ID: In-Reply-To: <632E01AE-A0CE-42F9-9A35-38FF1AD5E576@muada.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:52:55 -0000 On 8/20/09 8:15 AM, "Iljitsch van Beijnum" wrote: > On 20 aug 2009, at 15:59, liu dapeng wrote: >=20 >> 1. Our viewpoint regarding to FTP64 is that since the ALG problem >> could be totally avoided by carefully defining the behavior of the FTP >> client and server, translation box need not to implement FTP ALG. >=20 > Ok, you don't want to run an FTP64 ALG. However, what if other people > do want to run an FTP64 ALG? In that case, it's useful to have a > specification about how such an ALG should behave, so that > interoperability problems can be avoided. >=20 > So I would like to know from you: >=20 > - do you want the ALG specification to be removed from the FTP64 > document? >=20 > And from others: >=20 > - do you foresee yourself implementing and/or running an FTP64 ALG? Certainly. ALGs (not only FTP64) are alive and well in the 64 world. But in this area there will always be a separation between what gets standardized (or not) and deployed. Standardization of ALGs has always been a tricky problem - just like NATs. The difference is that people finally got around to admit the NATs exist, will be around for a while and producing very good documents on them. ALGs on the other hand are still pretty much unspecified but have existed as lon= g as NATs have. >=20 > If the answer to both questions is "yes" then we have a hard decision > to make... > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Thu Aug 20 11:54:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25ABA3A6DB7 for ; Thu, 20 Aug 2009 11:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfOJy6wqWqxd for ; Thu, 20 Aug 2009 11:54:50 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id DA3C13A6781 for ; Thu, 20 Aug 2009 11:54:45 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Aug 2009 11:54:51 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.621.7; Thu, 20 Aug 2009 11:54:51 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 20 Aug 2009 11:54:51 -0700 From: Dave Thaler To: Stig Venaas Thread-Topic: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 Thread-Index: AQHKIcaHyMtiqqNC6EeFn+MXpNdPv5CvSoMQ Date: Thu, 20 Aug 2009 18:54:47 +0000 Message-ID: References: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> <4A8D99B8.6090609@venaas.com> In-Reply-To: <4A8D99B8.6090609@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Behave WG' Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:54:51 -0000 Stig Venaas wrote: [...] > There are also examples of DHCPv6 options that would not make sense in > RAs. So one might need to specify which options should be supported. I would assume the options that would be legal would be DHCPv6 options that would be legal in a DHCPv6 REPLY message. Are there examples of such options that would not make sense in RAs, or is that clarification sufficient? -Dave From iljitsch@muada.com Thu Aug 20 12:14:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A6F3A6E9E for ; Thu, 20 Aug 2009 12:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wpZ+lLtjawE for ; Thu, 20 Aug 2009 12:14:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC7D3A691D for ; Thu, 20 Aug 2009 12:13:55 -0700 (PDT) Received: from [192.168.0.192] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7KJCpsA072068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Aug 2009 21:12:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Stig Venaas In-Reply-To: <4A8D99B8.6090609@venaas.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 20 Aug 2009 21:13:19 +0200 References: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> <4A8D99B8.6090609@venaas.com> X-Mailer: Apple Mail (2.936) Cc: 'Behave WG' , 'Dave Thaler' , Xu Xiaohu Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 19:14:56 -0000 On 20 aug 2009, at 20:45, Stig Venaas wrote: > There are also examples of DHCPv6 options that would not make sense in > RAs. So one might need to specify which options should be supported. I'm more concerned about the people who want to add gateway addresses to DHCPv6. The fact that there is fait sharing between the device that forwards packets and the device that advertises the address of the device that forwards packets with RAs (because the two are the same) makes IPv6 much more robust than IPv4 where DHCP is almost a given. It's remarkable how often, still after more than a decade of deployment, DHCP problems create IPv4 outages. In an ideal world we would retire DHCP because it's too arcane, has too many flavors (v4, stateful v6, stateless v6) and is too complex. Just pointing towards an HTTP server that has the configuration information would be so much better. But we're stuck with DHCP for IPv4 and we now also need it for prefix delegation in IPv6 so we have to live with it. But DHCP should not be the go to protocol for all our needs. From stig@venaas.com Thu Aug 20 12:36:17 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49EC63A691D for ; Thu, 20 Aug 2009 12:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMlI6sxH0r9Z for ; Thu, 20 Aug 2009 12:36:16 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 4A1383A6839 for ; Thu, 20 Aug 2009 12:36:16 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id 780FE37EA6; Thu, 20 Aug 2009 21:36:20 +0200 (CEST) Message-ID: <4A8DA5B1.50400@venaas.com> Date: Thu, 20 Aug 2009 12:36:17 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dave Thaler References: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> <4A8D99B8.6090609@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Behave WG' Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 19:36:17 -0000 Dave Thaler wrote: > Stig Venaas wrote: > [...] >> There are also examples of DHCPv6 options that would not make sense in >> RAs. So one might need to specify which options should be supported. > > I would assume the options that would be legal would be > DHCPv6 options that would be legal in a DHCPv6 REPLY message. > Are there examples of such options that would not make sense in > RAs, or is that clarification sufficient? There are several. The most obvious are things that are unique per client, e.g. the Client FQDN option (RFC 4704). Of course also options that hand out IP addresses to clients (IA_NA, IA_TA etc). There is also the Information Refresh Time option (RFC 4242) that tells client more or less when it next should query the DHCP server. I can find more. You could maybe say "options that can be in response to DHCP Information-Request messages", or "Stateless DHCPv6". But at least the last one I mentioned (RFC 4242), is an example of an option used in that case that would be meaningless in RAs. Stig > -Dave From dthaler@microsoft.com Thu Aug 20 12:45:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D505428C123 for ; Thu, 20 Aug 2009 12:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.397 X-Spam-Level: X-Spam-Status: No, score=-10.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTVVHu9R8J8I for ; Thu, 20 Aug 2009 12:45:12 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id ECC0828C0F0 for ; Thu, 20 Aug 2009 12:45:11 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Aug 2009 12:45:17 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server id 14.0.621.7; Thu, 20 Aug 2009 12:45:17 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 20 Aug 2009 12:45:17 -0700 From: Dave Thaler To: Stig Venaas Thread-Topic: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 Thread-Index: AQHKIcaHyMtiqqNC6EeFn+MXpNdPv5CvSoMQgACCQYD//4yT8A== Date: Thu, 20 Aug 2009 19:45:12 +0000 Message-ID: References: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> <4A8D99B8.6090609@venaas.com> <4A8DA5B1.50400@venaas.com> In-Reply-To: <4A8DA5B1.50400@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Behave WG' Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 19:45:12 -0000 > -----Original Message----- > From: Stig Venaas [mailto:stig@venaas.com] > Sent: Thursday, August 20, 2009 12:36 PM > To: Dave Thaler > Cc: 'Behave WG' > Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing- > behave-learn-prefix-03 > > Dave Thaler wrote: > > Stig Venaas wrote: > > [...] > >> There are also examples of DHCPv6 options that would not make sense > in > >> RAs. So one might need to specify which options should be supported. > > > > I would assume the options that would be legal would be > > DHCPv6 options that would be legal in a DHCPv6 REPLY message. > > Are there examples of such options that would not make sense in > > RAs, or is that clarification sufficient? > > There are several. The most obvious are things that are unique per > client, e.g. the Client FQDN option (RFC 4704). Of course also options > that hand out IP addresses to clients (IA_NA, IA_TA etc). There is also > the Information Refresh Time option (RFC 4242) that tells client more > or less when it next should query the DHCP server. I can find more. > > You could maybe say "options that can be in response to DHCP > Information-Request messages", or "Stateless DHCPv6". > > But at least the last one I mentioned (RFC 4242), is an example of an > option used in that case that would be meaningless in RAs. The point of the presentation by Thomas/Ralph is that there's apparently demand for unicast RAs providing different information to different clients. So I don't follow why things that are unique per client would not make sense in a unicast RA. I would certainly agree with the restriction that a _multicast_ RA could only contain options sent in response to Information-Request messages. -Dave From stig@venaas.com Thu Aug 20 13:04:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E64128C123 for ; Thu, 20 Aug 2009 13:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EdBJQ9V8RsJ for ; Thu, 20 Aug 2009 13:04:34 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 643A028C220 for ; Thu, 20 Aug 2009 13:04:00 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id 0BAC837ED7; Thu, 20 Aug 2009 22:04:04 +0200 (CEST) Message-ID: <4A8DAC32.6000809@venaas.com> Date: Thu, 20 Aug 2009 13:04:02 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dave Thaler References: <002201ca2146$9870b130$d40c6f0a@china.huawei.com> <4A8D99B8.6090609@venaas.com> <4A8DA5B1.50400@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Behave WG' Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 20:04:35 -0000 Dave Thaler wrote: >> -----Original Message----- >> From: Stig Venaas [mailto:stig@venaas.com] >> Sent: Thursday, August 20, 2009 12:36 PM >> To: Dave Thaler >> Cc: 'Behave WG' >> Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments on draft-wing- >> behave-learn-prefix-03 >> >> Dave Thaler wrote: >>> Stig Venaas wrote: >>> [...] >>>> There are also examples of DHCPv6 options that would not make sense >> in >>>> RAs. So one might need to specify which options should be supported. >>> I would assume the options that would be legal would be >>> DHCPv6 options that would be legal in a DHCPv6 REPLY message. >>> Are there examples of such options that would not make sense in >>> RAs, or is that clarification sufficient? >> There are several. The most obvious are things that are unique per >> client, e.g. the Client FQDN option (RFC 4704). Of course also options >> that hand out IP addresses to clients (IA_NA, IA_TA etc). There is also >> the Information Refresh Time option (RFC 4242) that tells client more >> or less when it next should query the DHCP server. I can find more. >> >> You could maybe say "options that can be in response to DHCP >> Information-Request messages", or "Stateless DHCPv6". >> >> But at least the last one I mentioned (RFC 4242), is an example of an >> option used in that case that would be meaningless in RAs. > > The point of the presentation by Thomas/Ralph is that there's apparently > demand for unicast RAs providing different information to different > clients. So I don't follow why things that are unique per client > would not make sense in a unicast RA. > > I would certainly agree with the restriction that a _multicast_ RA > could only contain options sent in response to Information-Request > messages. OK, if you unicast RAs that would be different. But there are still DHCP options that are kind of part of the DHCP protocol (like RFC 4242) that may not make sense. But also semantics may be a bit different. Some options are sent only when requested. In some cases, like Client FQDN the client is allowed to send a partial domain name to the server, and then the server completes it. I don't mind adding many of the DHCPv6 options to RAs, but I'm not sure it is good to have a mechanism allowing any option to be specified where the implementors have to make guesses as to which options they can expect and how to handle them. At least someone should then write some RFC saying which options you should handle and point out any caveats. For new options that should be in both DHCPv6 and RA one could possibly have a single document describing both uses. Stig > -Dave From xuxh@huawei.com Thu Aug 20 18:36:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5E43A6C42 for ; Thu, 20 Aug 2009 18:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.194 X-Spam-Level: ** X-Spam-Status: No, score=2.194 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEYieujS8CDL for ; Thu, 20 Aug 2009 18:36:26 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DC9833A6935 for ; Thu, 20 Aug 2009 18:36:25 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOP00B1IDSKTR@szxga03-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 09:36:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOP00BPTDSKHE@szxga03-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 09:36:20 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOP00HK8DSKBE@szxml04-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 09:36:20 +0800 (CST) Date: Fri, 21 Aug 2009 09:36:20 +0800 From: Xu Xiaohu In-reply-to: To: 'Dave Thaler' , 'Behave WG' Message-id: <002a01ca21ff$c8fcd3b0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AQHKIcSFQsw8YBZ5lEGlN+iqXArAz5CvtwMg Subject: Re: [BEHAVE] Notes from interim conf call 8/19/2009 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 01:36:26 -0000 > It was acknowledged that applications could implement a simple protocol > (RA or DHCP INFORM messages) to work around limitations in client stacks > that don't have APIs for new options. Eventually those in the meeting > got consensus to take the RA option off the table, but to keep both a > DNS and a DHCP solution in the doc. Will this consensus make the same regret in the future as the lack of DNS option in RA or the lack of default route option in DHCPv6? That's to say, those users who use RA for IP auto-configuration would have to use another solution just for the purpose of obtaining the prefix64. Xiaohu From xuxh@huawei.com Fri Aug 21 03:04:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B843A67E6 for ; Fri, 21 Aug 2009 03:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.159 X-Spam-Level: ** X-Spam-Status: No, score=2.159 tagged_above=-999 required=5 tests=[AWL=1.165, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tglfsR8ZQjAW for ; Fri, 21 Aug 2009 03:04:35 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 04C9B3A6855 for ; Fri, 21 Aug 2009 03:04:35 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOQ00GI81AAE9@szxga03-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 18:03:47 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOQ00HF31A9X5@szxga03-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 18:03:45 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOQ00AMS1A8YO@szxml06-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 18:03:45 +0800 (CST) Date: Fri, 21 Aug 2009 18:03:44 +0800 From: Xu Xiaohu In-reply-to: <4A8DAC32.6000809@venaas.com> To: 'Stig Venaas' , 'Dave Thaler' Message-id: <003701ca2246$aafd69f0$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acoh0YGe9J3Dn6g+Td2pbTlMHc6MNwAdRVkg Cc: 'Behave WG' Subject: Re: [BEHAVE] DHCPv6 v.s. RA//re: Comments ondraft-wing-behave-learn-prefix-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 10:04:35 -0000 > For new options that should be in both DHCPv6 and RA one could possibly > have a single document describing both uses. Absolutely agree. Xiaohu From shengjiang@huawei.com Fri Aug 21 05:08:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC303A6C18 for ; Fri, 21 Aug 2009 05:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj43tbRMuWYd for ; Fri, 21 Aug 2009 05:08:29 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id EA1183A69E2 for ; Fri, 21 Aug 2009 05:08:28 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOQ0055071VKH@szxga03-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 20:08:19 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOQ00H5L71VX5@szxga03-in.huawei.com> for behave@ietf.org; Fri, 21 Aug 2009 20:08:19 +0800 (CST) Received: from JiangXiong ([221.223.106.49]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOQ007ZM71URV@szxml02-in.huawei.com>; Fri, 21 Aug 2009 20:08:19 +0800 (CST) Date: Fri, 21 Aug 2009 20:08:03 +0800 From: Sheng Jiang To: 'Iljitsch van Beijnum' , 'liu dapeng' Message-id: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoiWAivflVKhWccQBWgsGKTBmoe+Q== Cc: behave@ietf.org, denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: shengjiang@huawei.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 12:08:30 -0000 ALGs are always annoying, for sure. They are not generic among applications. Each application may need its own ALG. How many ALGs may we have to run beside NAT64. If applications or protocols are carefully designed and implemented, our world would be much better; IPv6/IPv4 inter-communication would be much easier. For my understanding, any ALGs, except for DNS ALG, are not necessary. draft-liu-behave-ftp64-00 is such effort to avoid ALG in network side. Cheers, Sheng > On 8/20/09 8:15 AM, "Iljitsch van Beijnum" wrote: >> On 20 aug 2009, at 15:59, liu dapeng wrote: >> >> 1. Our viewpoint regarding to FTP64 is that since the ALG problem >> could be totally avoided by carefully defining the behavior of the FTP >> client and server, translation box need not to implement FTP ALG. > > Ok, you don't want to run an FTP64 ALG. However, what if other people > do want to run an FTP64 ALG? In that case, it's useful to have a > specification about how such an ALG should behave, so that > interoperability problems can be avoided. > > So I would like to know from you: > > - do you want the ALG specification to be removed from the FTP64 > document? > > And from others: > > - do you foresee yourself implementing and/or running an FTP64 ALG? From xing@cernet.edu.cn Fri Aug 21 05:31:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0E83A6892 for ; Fri, 21 Aug 2009 05:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.397 X-Spam-Level: * X-Spam-Status: No, score=1.397 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRbgld2IcWFy for ; Fri, 21 Aug 2009 05:31:42 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 7C5473A6B46 for ; Fri, 21 Aug 2009 05:31:40 -0700 (PDT) Received: from [10.97.74.55]([117.136.9.27]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04a8ea3d5; Fri, 21 Aug 2009 20:31:43 +0800 Message-ID: <4A8E93A2.70609@cernet.edu.cn> Date: Fri, 21 Aug 2009 20:31:30 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stig Venaas References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> In-Reply-To: <4A8B80FB.9030701@venaas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: i13R3eWB Cc: Andrew Sullivan , behave@ietf.org, Mark Andrews Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 12:31:43 -0000 I think the special handling of the multicast addresses should also be in the xlate and/or address-format documents. xing Stig Venaas 写道: > Mark Andrews wrote: >> In message <4A8B7E35.9070500@venaas.com>, Stig Venaas writes: >>> Mark Andrews wrote: >>>> In message <20090818165041.GI3163@shinkuro.com>, Andrew Sullivan >>>> writes: >>>>> Mark, >>>>> >>>>> On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: >>>>> >>>>>> DNS64 is a unicast translator, i.e class A, B and C address. Class >>>>>> D and E are out of scope for DNS64. Anything else is local >>>>>> configuration From dthaler@microsoft.com Fri Aug 21 15:04:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5913F3A69ED for ; Fri, 21 Aug 2009 15:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.397 X-Spam-Level: X-Spam-Status: No, score=-10.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4aAFOCS0zJJ for ; Fri, 21 Aug 2009 15:04:53 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5EF0028C16E for ; Fri, 21 Aug 2009 15:04:31 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Aug 2009 15:04:36 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.621.7; Fri, 21 Aug 2009 15:04:36 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 21 Aug 2009 15:04:35 -0700 From: Dave Thaler To: Xing Li , Stig Venaas Thread-Topic: [BEHAVE] DNS64 handling of multicast addresses Thread-Index: AQHKIltjsms8L0OPykSpkOnnN2XGN5CxEMmA Date: Fri, 21 Aug 2009 22:04:31 +0000 Message-ID: References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> In-Reply-To: <4A8E93A2.70609@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Andrew Sullivan , "behave@ietf.org" , Mark Andrews Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 22:04:54 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBiZWhhdmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgWGlu ZyBMaQ0KPiBTZW50OiBGcmlkYXksIEF1Z3VzdCAyMSwgMjAwOSA1OjMyIEFNDQo+IFRvOiBTdGln IFZlbmFhcw0KPiBDYzogQW5kcmV3IFN1bGxpdmFuOyBiZWhhdmVAaWV0Zi5vcmc7IE1hcmsgQW5k cmV3cw0KPiBTdWJqZWN0OiBSZTogW0JFSEFWRV0gRE5TNjQgaGFuZGxpbmcgb2YgbXVsdGljYXN0 IGFkZHJlc3Nlcw0KPg0KPiBJIHRoaW5rIHRoZSBzcGVjaWFsIGhhbmRsaW5nIG9mIHRoZSBtdWx0 aWNhc3QgYWRkcmVzc2VzIHNob3VsZCBhbHNvIGJlDQo+IGluIHRoZSB4bGF0ZSBhbmQvb3IgYWRk cmVzcy1mb3JtYXQgZG9jdW1lbnRzLiB4aW5nDQo+DQo+IFN0aWcgVmVuYWFzIOWGmemBkzoNCj4g PiBNYXJrIEFuZHJld3Mgd3JvdGU6DQo+ID4+IEluIG1lc3NhZ2UgPDRBOEI3RTM1LjkwNzA1MDBA dmVuYWFzLmNvbT4sIFN0aWcgVmVuYWFzIHdyaXRlczoNCj4gPj4+IE1hcmsgQW5kcmV3cyB3cm90 ZToNCj4gPj4+PiBJbiBtZXNzYWdlIDwyMDA5MDgxODE2NTA0MS5HSTMxNjNAc2hpbmt1cm8uY29t PiwgQW5kcmV3IFN1bGxpdmFuDQo+ID4+Pj4gd3JpdGVzOg0KPiA+Pj4+PiBNYXJrLA0KPiA+Pj4+ Pg0KPiA+Pj4+PiBPbiBNb24sIEF1ZyAxNywgMjAwOSBhdCAwOToyODowNkFNICsxMDAwLCBNYXJr IEFuZHJld3Mgd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+PiBETlM2NCBpcyBhIHVuaWNhc3QgdHJh bnNsYXRvciwgaS5lIGNsYXNzIEEsIEIgYW5kIEMgYWRkcmVzcy4NCj4gQ2xhc3MNCj4gPj4+Pj4+ IEQgYW5kIEUgYXJlIG91dCBvZiBzY29wZSBmb3IgRE5TNjQuIEFueXRoaW5nIGVsc2UgaXMgbG9j YWwNCj4gPj4+Pj4+IGNvbmZpZ3VyYXRpb24NCg0KSSBkb24ndCBzZWUgd2h5IHRoZSBETlM2NCBz aG91bGRuJ3QgYmUgY2FwYWJsZSBvZiBkb2luZyBtdWx0aWNhc3QNCmFkZHJlc3MgdHJhbnNsYXRp b24gdG9vLCBpZiBzdWNoIGlzIHVzZWQuICBJZiwgZm9yIGV4YW1wbGUsIGEgRE5TNjQNCmlzIGNv bmZpZ3VyZWQgd2l0aCBhIHNldCBvZiBJUHY0IHByZWZpeGVzIGFuZCB0aGUgY29ycmVzcG9uZGlu ZyBJUHY2DQpwcmVmaXggZm9yIGVhY2gsIGl0IHNob3VsZG4ndCBoYXZlIHRvIGNoZWNrIHdoZXRo ZXIgdGhlIGFkZHJlc3MgaXMNCnVuaWNhc3Qgb3IgbXVsdGljYXN0LiAgT2YgY291cnNlIGVpdGhl ciBhbGwgcHJlZml4ZXMgaGF2ZSB0byBoYXZlIHRoZQ0Kc2FtZSBzdWZmaXggYWxnb3JpdGhtICh6 ZXJvLXBhZCBhbmQgZW1iZWQsIG9yIGVtYmVkIGFuZCB6ZXJvLXBhZCwgb3INCndoYXRldmVyIGVs c2UpIG9yIGVsc2UgeW91IGhhdmUgdG8gY29uZmlndXJlIHRoZSBhbGdvcml0aG0gcGVyIHByZWZp eA0KdG9vLg0KDQotRGF2ZQ0KDQo= From stig@venaas.com Fri Aug 21 15:14:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A2E3A69EA for ; Fri, 21 Aug 2009 15:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvuNSbFj7tZS for ; Fri, 21 Aug 2009 15:14:54 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 286CE3A689D for ; Fri, 21 Aug 2009 15:14:35 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id 3D2AA385CF; Sat, 22 Aug 2009 00:14:39 +0200 (CEST) Message-ID: <4A8F1C4D.7040100@venaas.com> Date: Fri, 21 Aug 2009 15:14:37 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dave Thaler References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Andrew Sullivan , "behave@ietf.org" , Xing Li , Mark Andrews Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 22:14:54 -0000 Dave Thaler wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Xing Li >> Sent: Friday, August 21, 2009 5:32 AM >> To: Stig Venaas >> Cc: Andrew Sullivan; behave@ietf.org; Mark Andrews >> Subject: Re: [BEHAVE] DNS64 handling of multicast addresses >> >> I think the special handling of the multicast addresses should also be >> in the xlate and/or address-format documents. xing >> >> Stig Venaas 写道: >>> Mark Andrews wrote: >>>> In message <4A8B7E35.9070500@venaas.com>, Stig Venaas writes: >>>>> Mark Andrews wrote: >>>>>> In message <20090818165041.GI3163@shinkuro.com>, Andrew Sullivan >>>>>> writes: >>>>>>> Mark, >>>>>>> >>>>>>> On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: >>>>>>> >>>>>>>> DNS64 is a unicast translator, i.e class A, B and C address. >> Class >>>>>>>> D and E are out of scope for DNS64. Anything else is local >>>>>>>> configuration > > I don't see why the DNS64 shouldn't be capable of doing multicast > address translation too, if such is used. If, for example, a DNS64 > is configured with a set of IPv4 prefixes and the corresponding IPv6 > prefix for each, it shouldn't have to check whether the address is > unicast or multicast. Of course either all prefixes have to have the > same suffix algorithm (zero-pad and embed, or embed and zero-pad, or > whatever else) or else you have to configure the algorithm per prefix > too. This is what I've been arguing all along in this thread. There is no need for specific multicast capability as long as you can configure different IPv6 prefixes to be used with different IPv4 prefixes. I think this mechanism is useful in any case. Including a way of ignoring certain prefixes (not synthesize AAAA). As Jyrki wrote: |As Stig Venaas pointed out, if the DNS64 is able to handle multiple |IPv6 prefixes for synthesizing the AAAA record based on IPv4 address |ranges on returned A records the multicast would not need any |additional mechanism in DNS64. I think Jyrki formulates my thoughts better than I can, Stig > -Dave > From dwing@cisco.com Fri Aug 21 17:14:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92223A6924 for ; Fri, 21 Aug 2009 17:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.759 X-Spam-Level: X-Spam-Status: No, score=-6.759 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lozl-iMUxnU for ; Fri, 21 Aug 2009 17:14:29 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8FECD3A68FA for ; Fri, 21 Aug 2009 17:13:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAOvUjkqrR7MV/2dsb2JhbACLFrF6iDc2B5AKBYIygWg X-IronPort-AV: E=Sophos;i="4.44,253,1249257600"; d="scan'208";a="231496464" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 22 Aug 2009 00:14:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7M0E45C028707; Fri, 21 Aug 2009 17:14:04 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7M0E4WC007205; Sat, 22 Aug 2009 00:14:04 GMT From: "Dan Wing" To: "'Ari Keranen'" , References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> <4A8BD224.1070508@nomadiclab.com> Date: Fri, 21 Aug 2009 17:14:04 -0700 Message-ID: <05fd01ca22bd$7534ac30$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcogtwncBlsjNJfmS+GpSby82N7wbwCBb4IQ In-Reply-To: <4A8BD224.1070508@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1984; t=1250900044; x=1251764044; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20WGLC=3A=20draft-ietf-behave- turn-tcp-04 |Sender:=20; bh=CW+1bxh8lcchqUqjIuPPrIPFA/dmqKVArgub5fW7TWM=; b=peTw6Hu+h9xLTUkXzXssUtKgu+M+j999iErlXNRu0hJ6yl5dVuXE4Xivpc PNobHBojmdmg9vo+B5BbmDZi+T5QhtldrJcAkowAnzqscapu52KyWc2g2iCY 7dMcq9fNxmGy4AhpxKOGOQx/IHIdOX2245ID9c1e4CloBy/YRxiFg=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: draft-ietf-behave-turn@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 00:14:30 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Ari Keranen > Sent: Wednesday, August 19, 2009 3:21 AM > To: draft-ietf-behave-turn-tcp@tools.ietf.org > Cc: behave@ietf.org > Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 > > Hi, > > One technical issue in draft-ietf-behave-turn-tcp-04 caught > my attention: > > In section 4.5., "Sending and Receiving Data" is says: > > [...] Data on a data connection MUST NOT > be interpreted as STUN messages. > > I think this is too heavy restriction. What about if the peer > wants to > send some STUN messages on the path via the TURN server and > would need > the TURN client to parse them as STUN? How would the TURN server identify such traffic that it should respond to? Thinking aloud, one solution is for the local TURN client to tell the TURN server which STUN username(s) indicate the STUN message is intended for the TURN server. > I would rather make this "SHOULD NOT" to be future proof. Or even > removing the whole restriction should not do much harm, right? The reason for this passage is so that ICE connectivity checks can be performed, through the TURN server, between the endpoints. If the TURN server 'eats' (processes) the incoming messages from the remote peer, the connectivity checks will fail. This is really something that belongs in the TURN specification because I believe it is not unique to TURN-TCP. If anything, the TURN specification should say something like: In the absence of an standards-track enhancement to identify STUN traffic intended for the TURN server, data on a data connection MUST NOT be interpreted as a STUN message. Thoughts? (CC'ing TURN authors.) -d > > Cheers, > Ari > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Sat Aug 22 10:27:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525AD3A6877 for ; Sat, 22 Aug 2009 10:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.749 X-Spam-Level: X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRrL4Vo81nYs for ; Sat, 22 Aug 2009 10:27:20 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E27233A685E for ; Sat, 22 Aug 2009 10:27:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAMrGj0qrR7MV/2dsb2JhbACLFa8piDePcAWEGg X-IronPort-AV: E=Sophos;i="4.44,257,1249257600"; d="scan'208";a="373019231" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Aug 2009 17:27:26 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7MHRQXa029596; Sat, 22 Aug 2009 10:27:26 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7MHRQJG001398; Sat, 22 Aug 2009 17:27:26 GMT From: "Dan Wing" To: Date: Sat, 22 Aug 2009 10:27:26 -0700 Message-ID: <065a01ca234d$d191d5d0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcojTdFTs4KOS3QnSgKZ+hx+k/auoQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8759; t=1250962046; x=1251826046; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20PROTO=20writeup=20for=20draft-ietf-behave-turn- uri-03 |Sender:=20; bh=XvmvUg9YCu9Pt2NKzGujRUc0JQ0+0PJDRI+yQshiiJE=; b=gPu6+/s0dfUIeDA/t69Eo1KFpb54qizf+iI/1KHfCSIGQyFIfOVSPUJfJR i9ggnCG3MfgfsCmVuSehwcd46robFeuy6VU2FSq+rAxh+QqZMklLflYTRen6 jH7YOYEcJqVAIj4tmuqyyGkvSJuzOfHhfLOKwQbxESQRgZy+mZgo0=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: draft-ietf-behave-turn-uri@tools.ietf.org Subject: [BEHAVE] PROTO writeup for draft-ietf-behave-turn-uri-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 17:27:22 -0000 Below is the PROTO writeup for draft-ietf-behave-turn-uri-03. -d ----- PROTO writeup for draft-ietf-behave-turn-uri-03 (1.a) Who is the Document Shepherd for this document? Dan Wing, dwing@cisco.com Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has received review from the community. The document shepherd solicited URI review from uri-review@ietf.org but didn't receive a URI-specific review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? A URI review would be helpful. As stated, the document shepherd attempted to get a URI review but doubts a URI review occurred. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There has been no working group discussion of this IPR disclosure. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG has a good understanding of it, but most members of the WG do not need this URI to configure their TURN clients. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No such threats or appeals. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Yes. Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? A URI review is needed. If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Intended Status: Proposed Standard (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All normative references are upward references, and all are RFCs. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? No protocol extensions. Are the IANA registries clearly identified? Yes. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? The document does not create a new IANA registry. Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF parses according to http://www.apps.ietf.org/node/12 (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document defines two URI schemes and the resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No. Document Quality Are there existing implementations of the protocol? Yes. Have a significant number of vendors indicated their plan to implement the specification? Only one. Another vendor has indicated interest in implementing after publication as an RFC. Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? They are listed in the document's acknowledgement section. If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? We still need a URI review. Personnel Who is the Document Shepherd for this document? Dan Wing, dwing@cisco.com Who is the Responsible Area Director? Magnus Westerlund, magnus.westerlund@ericsson.com If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' The document doesn't require IANA experts. The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling. From root@core3.amsl.com Sat Aug 22 13:30:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 251643A6A71; Sat, 22 Aug 2009 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090822203002.251643A6A71@core3.amsl.com> Date: Sat, 22 Aug 2009 13:30:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-translator-addressing-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Huitema, et al. Filename : draft-ietf-behave-translator-addressing-00.txt Pages : 24 Date : 2009-08-22 This document discusses how an individual IPv6 address can be algorithmically translated to a corresponding IPv4 address, and vice versa, using only statically configured information. This technique is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-translator-addressing-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-behave-translator-addressing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-22132502.I-D@ietf.org> --NextPart-- From zhouboyj@gmail.com Sun Aug 23 08:27:16 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D99E3A6CC5 for ; Sun, 23 Aug 2009 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXJrwvJjWFRr for ; Sun, 23 Aug 2009 08:27:15 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id CC6733A6C1A for ; Sun, 23 Aug 2009 08:27:14 -0700 (PDT) Received: by iwn38 with SMTP id 38so741819iwn.29 for ; Sun, 23 Aug 2009 08:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Byh0pWQAHovqvThskQBlSB4ppN4t8pnGj52Aj+E/yAg=; b=KCClVoKFStY5bCuo9w5ck9vQFgezMVt3TODPXHOUKQ1BApaabhU0ZfgbXKBE9tAQyD oEKKnhVepcdaPL6wCK0xBBhoZG2W+L1+okrsHUFsngRY693IBWeOTvl0m5OiixraDsVL qtrpAqKBmHkOchmrjYzRoCCIS+xfi3MEEunxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BpP3x0wL9UpqJbXGQEW6RNll2L1rlPSEXzf/4VH4ONpg8nT9S49aPB9Rf9obpeshzO zBBMEIArMyPjN5KfdoqT/lFTbUkk9agcrWDWxVos2NPycKLKq+IaxlWtnqoEdTOwX/C6 HjGuf4hBwwEmADovjBRLItSxE+WA7+hEJ5U80= MIME-Version: 1.0 Received: by 10.231.32.11 with SMTP id a11mr1700740ibd.38.1251041235451; Sun, 23 Aug 2009 08:27:15 -0700 (PDT) In-Reply-To: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> Date: Sun, 23 Aug 2009 23:27:15 +0800 Message-ID: <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> From: bo zhou To: shengjiang@huawei.com Content-Type: multipart/alternative; boundary=0022152d6d757041230471d0bc2c Cc: behave@ietf.org, liu dapeng , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 15:27:16 -0000 --0022152d6d757041230471d0bc2c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed with Sheng. If we can avoid FTP ALG in network side by carefully defined the behaviours of client and server, why we should put ALG inside the standardisation. Furthermore, ALGs (not only FTP) cannot avoid during NAT64 deployment. like Reinaldo mentioned, it is a tricky problem to standardise ALG even everybody know it will exist as long as NAT64 exist. Regards, Bo Zhou On Fri, Aug 21, 2009 at 8:08 PM, Sheng Jiang wrote: > ALGs are always annoying, for sure. They are not generic among > applications. > Each application may need its own ALG. How many ALGs may we have to run > beside NAT64. If applications or protocols are carefully designed and > implemented, our world would be much better; IPv6/IPv4 inter-communication > would be much easier. For my understanding, any ALGs, except for DNS ALG, > are not necessary. > > draft-liu-behave-ftp64-00 is such effort to avoid ALG in network side. > > Cheers, > > Sheng > > > On 8/20/09 8:15 AM, "Iljitsch van Beijnum" > wrote: > > >> On 20 aug 2009, at 15:59, liu dapeng wrote: > >> > >> 1. Our viewpoint regarding to FTP64 is that since the ALG problem > >> could be totally avoided by carefully defining the behavior of the FTP > >> client and server, translation box need not to implement FTP ALG. > > > > Ok, you don't want to run an FTP64 ALG. However, what if other people > > do want to run an FTP64 ALG? In that case, it's useful to have a > > specification about how such an ALG should behave, so that > > interoperability problems can be avoided. > > > > So I would like to know from you: > > > > - do you want the ALG specification to be removed from the FTP64 > > document? > > > > And from others: > > > > - do you foresee yourself implementing and/or running an FTP64 ALG? > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- Regards, Bo Zhou China Mobile --0022152d6d757041230471d0bc2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agreed with Sheng. If we can avoid FTP ALG in network side by carefull= y defined the behaviours of client and server, why we should put=A0ALG=A0in= side the standardisation.
Furthermore, ALGs (not only FTP)=A0cannot avoid during NAT64 deploymen= t. like Reinaldo mentioned, it is a tricky problem to standardise ALG even everybody know it will exist as l= ong as NAT64 exist.
Regards,
Bo Zhou

On Fri, Aug 21, 2009 at 8:08 PM, Sheng Jiang <shengjiang@huaw= ei.com> wrote:
ALGs are always annoying, for su= re. They are not generic among applications.
Each application may need i= ts own ALG. How many ALGs may we have to run
beside NAT64. If applications or protocols are carefully designed and
im= plemented, our world would be much better; IPv6/IPv4 inter-communicationwould be much easier. For my understanding, any ALGs, except for DNS ALG,<= br> are not necessary.

draft-liu-behave-ftp64-00 is such effort to avoid= ALG in network side.

Cheers,

Sheng

> On 8/20/09 8:15 AM, "Iljitsch van Beijnum&q= uot; <iljitsch at muada.= com> wrote:

>> On 20 aug 2009, at 15:59, liu dapeng wro= te:
>>
>> 1. Our viewpoint regarding to FTP64 is that since the = ALG problem
>> could be totally avoided by carefully defining the = behavior of the FTP
>> client and server, translation box need not= to implement FTP ALG.
>
> Ok, you don't want to run an FTP64 ALG. However, what if o= ther people
> do want to run an FTP64 ALG? In that case, it's use= ful to have a
> specification about how such an ALG should behave, so= that
> interoperability problems can be avoided.
>
> So I would l= ike to know from you:
>
> - do you want the ALG specification t= o be removed from the FTP64
> document?
>
> And from othe= rs:
>
> - do you foresee yourself implementing and/or running an FTP64= ALG?

_______________________________________________
Behave= mailing list
Behave@ietf.org
= = https://www.ietf.org/mailman/listinfo/behave



--
Regards,

Bo Zhou
China Mobile
--0022152d6d757041230471d0bc2c-- From joelja@bogus.com Sun Aug 23 09:28:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADF63A67FE for ; Sun, 23 Aug 2009 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1K-17fCO230 for ; Sun, 23 Aug 2009 09:28:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 1FF4A3A6BDE for ; Sun, 23 Aug 2009 09:28:46 -0700 (PDT) Received: from [192.168.1.118] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n7NGS4wK067404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 23 Aug 2009 16:28:07 GMT (envelope-from joelja@bogus.com) Message-ID: <4A916E13.70404@bogus.com> Date: Sun, 23 Aug 2009 09:28:03 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: bo zhou References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> In-Reply-To: <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 23 Aug 2009 16:28:10 +0000 (UTC) Cc: shengjiang@huawei.com, behave@ietf.org, liu dapeng , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 16:28:48 -0000 bo zhou wrote: > Agreed with Sheng. If we can avoid FTP ALG in network side by carefully > defined the behaviours of client and server, why we should > put ALG inside the standardisation. The historical problem being that ftp clients and servers have been disinclined to change their behavior just because someone writes a draft and passes it through the iesg and rfc editor, that's in part why we are where we are today with ftp. You can avoid alg by dropping the client/server combos you don't want to support off the list, it doesn't make the problem go away but it does remove it as an obstacle to this draft. > Furthermore, ALGs (not only FTP) cannot avoid during NAT64 deployment. > like Reinaldo mentioned, it is a tricky problem to standardise ALG even > everybody know it will exist as long as NAT64 exist. > Regards, > Bo Zhou > > On Fri, Aug 21, 2009 at 8:08 PM, Sheng Jiang > wrote: > > ALGs are always annoying, for sure. They are not generic among > applications. > Each application may need its own ALG. How many ALGs may we have to run > beside NAT64. If applications or protocols are carefully designed and > implemented, our world would be much better; IPv6/IPv4 > inter-communication > would be much easier. For my understanding, any ALGs, except for DNS > ALG, > are not necessary. > > draft-liu-behave-ftp64-00 is such effort to avoid ALG in network side. > > Cheers, > > Sheng > > > On 8/20/09 8:15 AM, "Iljitsch van Beijnum" > wrote: > > >> On 20 aug 2009, at 15:59, liu dapeng wrote: > >> > >> 1. Our viewpoint regarding to FTP64 is that since the ALG problem > >> could be totally avoided by carefully defining the behavior of > the FTP > >> client and server, translation box need not to implement FTP ALG. > > > > Ok, you don't want to run an FTP64 ALG. However, what if other people > > do want to run an FTP64 ALG? In that case, it's useful to have a > > specification about how such an ALG should behave, so that > > interoperability problems can be avoided. > > > > So I would like to know from you: > > > > - do you want the ALG specification to be removed from the FTP64 > > document? > > > > And from others: > > > > - do you foresee yourself implementing and/or running an FTP64 ALG? > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > > > -- > Regards, > > Bo Zhou > China Mobile > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From zhouboyj@gmail.com Sun Aug 23 21:26:14 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8FA3A6D7F for ; Sun, 23 Aug 2009 21:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjIg50EA13Uc for ; Sun, 23 Aug 2009 21:26:12 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id C0F533A6D76 for ; Sun, 23 Aug 2009 21:26:12 -0700 (PDT) Received: by iwn38 with SMTP id 38so845196iwn.29 for ; Sun, 23 Aug 2009 21:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=//VGsty3ZYSsEFsU/8gDW5XH4/nKOkXwL+TR4xtxm9c=; b=GQ7lLl30LG849cLd31DYjFXcBdo+b5MecfHI3cmr7BMhIqBE6+WnCRaUdKgG7FpGSx Tlx+J43HAHSj9YNEM1/W0EdU5eFshqvaGcuhEOdFdMzOzYxbIIUUV+3ALSQRhInnOmqv mVcENt2Q5r7zatgo1TygFL1JF3SF6OgGq0zRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZKDs4lkm34WYZohyh2wE6Ectrtgas8ZKkPVzcx1exuM3hhS5ULgN4AV7v6YxpucAEV cW6F+9445ylB5/J3lu3AbnvbFN4TP5aFXxdEM24FpzcljSiQMdWoGL20exTr6rFg2HOy Kl+sqzxH19qJZ2aHQWpID6nu1uHq9mgw9nkD0= MIME-Version: 1.0 Received: by 10.231.12.135 with SMTP id x7mr1915502ibx.42.1251087975418; Sun, 23 Aug 2009 21:26:15 -0700 (PDT) In-Reply-To: <4A916E13.70404@bogus.com> References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> Date: Mon, 24 Aug 2009 12:26:15 +0800 Message-ID: <36a593230908232126m7efdbf85h86f6e9d3b7ac298c@mail.gmail.com> From: bo zhou To: Joel Jaeggli Content-Type: multipart/alternative; boundary=0003255750fe5b8d1e0471db9eeb Cc: shengjiang@huawei.com, behave@ietf.org, liu dapeng , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 04:26:14 -0000 --0003255750fe5b8d1e0471db9eeb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Although FTP behaviours has been disinclined to change its behaviours based by a draft you pointed out, it cannot predict the issue of ALG in 64 translation or others scenarios. If we can carefully modify the FTP client and server behaviour to avoid ALG, why not? Especially, the draft is focus on ftp64 scenario, so no excuse to leave the problem even we know we can sort it out by some slight behaviour modification. Regards, Bo Zhou On Mon, Aug 24, 2009 at 12:28 AM, Joel Jaeggli wrote: > bo zhou wrote: > > Agreed with Sheng. If we can avoid FTP ALG in network side by carefully > > defined the behaviours of client and server, why we should > > put ALG inside the standardisation. > > The historical problem being that ftp clients and servers have been > disinclined to change their behavior just because someone writes a draft > and passes it through the iesg and rfc editor, that's in part why we are > where we are today with ftp. > > You can avoid alg by dropping the client/server combos you don't want to > support off the list, it doesn't make the problem go away but it does > remove it as an obstacle to this draft. > > > Furthermore, ALGs (not only FTP) cannot avoid during NAT64 deployment. > > like Reinaldo mentioned, it is a tricky problem to standardise ALG even > > everybody know it will exist as long as NAT64 exist. > > Regards, > > Bo Zhou > > > > On Fri, Aug 21, 2009 at 8:08 PM, Sheng Jiang > > wrote: > > > > ALGs are always annoying, for sure. They are not generic among > > applications. > > Each application may need its own ALG. How many ALGs may we have to > run > > beside NAT64. If applications or protocols are carefully designed and > > implemented, our world would be much better; IPv6/IPv4 > > inter-communication > > would be much easier. For my understanding, any ALGs, except for DNS > > ALG, > > are not necessary. > > > > draft-liu-behave-ftp64-00 is such effort to avoid ALG in network > side. > > > > Cheers, > > > > Sheng > > > > > On 8/20/09 8:15 AM, "Iljitsch van Beijnum" > > wrote: > > > > >> On 20 aug 2009, at 15:59, liu dapeng wrote: > > >> > > >> 1. Our viewpoint regarding to FTP64 is that since the ALG problem > > >> could be totally avoided by carefully defining the behavior of > > the FTP > > >> client and server, translation box need not to implement FTP ALG. > > > > > > Ok, you don't want to run an FTP64 ALG. However, what if other > people > > > do want to run an FTP64 ALG? In that case, it's useful to have a > > > specification about how such an ALG should behave, so that > > > interoperability problems can be avoided. > > > > > > So I would like to know from you: > > > > > > - do you want the ALG specification to be removed from the FTP64 > > > document? > > > > > > And from others: > > > > > > - do you foresee yourself implementing and/or running an FTP64 ALG? > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > > > > > > > -- > > Regards, > > > > Bo Zhou > > China Mobile > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > -- Regards, Bo Zhou China Mobile --0003255750fe5b8d1e0471db9eeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Although FTP behaviours has been disinclined to change its behaviours = based by a draft you pointed out, it cannot predict the issue of ALG in 64 = translation or others scenarios. If we can carefully modify the FTP client = and server behaviour to avoid ALG, why not? Especially, the draft is focus = on ftp64 scenario, so no excuse to leave the problem even we know we can so= rt it out by some slight behaviour modification.
=A0
Regards,
=A0
Bo Zhou

On Mon, Aug 24, 2009 at 12:28 AM, Joel Jaeggli <= span dir=3D"ltr"><joelja@bogus.com> wrote:
bo zhou wrote:
> Agreed with Sheng. If we can avoid= FTP ALG in network side by carefully
> defined the behaviours of cli= ent and server, why we should
> put ALG inside the standardisation.
The historical problem being that ftp clients and servers have be= en
disinclined to change their behavior just because someone writes a dr= aft
and passes it through the iesg and rfc editor, that's in part wh= y we are
where we are today with ftp.

You can avoid alg by dropping the clien= t/server combos you don't want to
support off the list, it doesn'= ;t make the problem go away but it does
remove it as an obstacle to this= draft.

> Furthermore, ALGs (not only FTP) cannot avoid du= ring NAT64 deployment.
> like Reinaldo mentioned, it is a tricky prob= lem to standardise ALG even
> everybody know it will exist as long as= NAT64 exist.
> Regards,
> Bo Zhou
>
> On Fri, Aug 21, 2009 at 8:08 = PM, Sheng Jiang <shengjiang@hua= wei.com
> <mailto:= shengjiang@huawei.com>> wrote:
>
> =A0 =A0 ALGs are a= lways annoying, for sure. They are not generic among
> =A0 =A0 applic= ations.
> =A0 =A0 Each application may need its own ALG. How many ALGs may we ha= ve to run
> =A0 =A0 beside NAT64. If applications or protocols are ca= refully designed and
> =A0 =A0 implemented, our world would be much b= etter; IPv6/IPv4
> =A0 =A0 inter-communication
> =A0 =A0 would be much easier. For = my understanding, any ALGs, except for DNS
> =A0 =A0 ALG,
> =A0= =A0 are not necessary.
>
> =A0 =A0 draft-liu-behave-ftp64-00 i= s such effort to avoid ALG in network side.
>
> =A0 =A0 Cheers,
>
> =A0 =A0 Sheng
>
> = =A0 =A0 > On 8/20/09 8:15 AM, "Iljitsch van Beijnum" <iljit= sch at muada.com
> =A0 =A0 <http://muada.com/>> wrote:
>
> =A0 =A0 >&g= t; On 20 aug 2009, at 15:59, liu dapeng wrote:
> =A0 =A0 >>
= > =A0 =A0 >> 1. Our viewpoint regarding to FTP64 is that since the= ALG problem
> =A0 =A0 >> could be totally avoided by carefully defining the be= havior of
> =A0 =A0 the FTP
> =A0 =A0 >> client and serve= r, translation box need not to implement FTP ALG.
> =A0 =A0 >
&= gt; =A0 =A0 > Ok, you don't want to run an FTP64 ALG. However, what = if other people
> =A0 =A0 > do want to run an FTP64 ALG? In that case, it's usefu= l to have a
> =A0 =A0 > specification about how such an ALG should= behave, so that
> =A0 =A0 > interoperability problems can be avoi= ded.
> =A0 =A0 >
> =A0 =A0 > So I would like to know from you:> =A0 =A0 >
> =A0 =A0 > - do you want the ALG specification= to be removed from the FTP64
> =A0 =A0 > document?
> =A0 = =A0 >
> =A0 =A0 > And from others:
> =A0 =A0 >
> =A0 =A0 > - do you foresee yourself implementi= ng and/or running an FTP64 ALG?
>
> =A0 =A0 ___________________= ____________________________
> =A0 =A0 Behave mailing list
&= gt; =A0 =A0 Behave@ietf.org <mail= to:Behave@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/behave=
>
>
>
>
> --
> Regards,
>> Bo Zhou
> China Mobile
>
>
> ---------------------------= ---------------------------------------------
>
> ____________________________________________= ___
> Behave mailing list
> = Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave



--
Regards,

Bo Zhou
China Mobile
--0003255750fe5b8d1e0471db9eeb-- From zhouboyj@gmail.com Sun Aug 23 23:00:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF463A6B74 for ; Sun, 23 Aug 2009 22:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLzvgFJHDvNr for ; Sun, 23 Aug 2009 22:59:58 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id A89843A6B47 for ; Sun, 23 Aug 2009 22:59:58 -0700 (PDT) Received: by iwn38 with SMTP id 38so858202iwn.29 for ; Sun, 23 Aug 2009 23:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=kYGNATyFmmOYvlIJzWdPRXme9HA+4hzclUz9eMHh1hk=; b=ldT9Pae6sKPhqQ3nA9LtU7GEuvbR5Gmor/VJK5kpZu3D3U3OPkvk5VGfNTSkhGY4HO x/yBQV5TyjJEEyT91Iz/X+53QHjO2cpFZcukxC3lffIDbhP6jVulR/sFf6rgnKFLlBpH 0cFPG4YGM25BFUyZCBmnI0dbSneNdZEz0bwTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=EWcIiQloLCUEsWFhjRzP7InSpNEW4iIAiWWDZLSpSq2ecRqIcd3GkYcB7mJY1HyYna FSZovvFSyTbENzTlgQaSl+8BAqlZZXUQfTf8RQ8RMdBfsUrRqC1kCUGHIQM7GdqRTD83 Y7es6eqJ+An4p+fZux3r1GHePLCuNSIm7k0DM= MIME-Version: 1.0 Received: by 10.231.12.135 with SMTP id x7mr1947352ibx.42.1251093601365; Sun, 23 Aug 2009 23:00:01 -0700 (PDT) Date: Mon, 24 Aug 2009 14:00:01 +0800 Message-ID: <36a593230908232300m45a10136wce25d01ef8bac439@mail.gmail.com> From: bo zhou To: behave@ietf.org, fred@cisco.com, xing@cernet.edu.cn, congxiao@cernet.edu.cn, kyin@cisco.com Content-Type: multipart/alternative; boundary=0003255750feb0b03d0471dcedb6 Cc: denghui02@gmail.com, liu dapeng , phdgang@gmail.com Subject: [BEHAVE] Proposed text and comments for framework for IPv4/IPv6 translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 06:00:00 -0000 --0003255750feb0b03d0471dcedb6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fred and others authors of framework for IPv4/IPv6 translation We have some texts and comments for this draft. Originally, we tried to propose our comments and discuss them inside last Wed's interim meeting, Unfortunately, the shortage of time caused we have no time to address them. Hence, we pointed them out here. 1) We need more clear IP family host definitions Inside the draft, existing =E2=80=9CIPv6-only=E2=80=9D and =E2=80=9CIPv4-on= ly=E2=80=9D definitions are targeting to IP host capabilities, but there are unclear descriptions of =E2=80=9Capplication instances=E2=80=9D. Hence we propose the IP family ho= st shall be defined combining with four aspects: a. the application type installed on the host, b.the IP family stack supported by a host c.the IP family routing assigned by a network d.available IP family connectivity According to the above principles, following IP family host definitions are suggested to replace current =E2=80=9CIPv6-only=E2=80=9D and =E2=80=9CIPv4-= only=E2=80=9D definitions and propose a new definition for supplement: IPv4 only host comprises an IPv4 enabled end system stack plus routing in the network, IPv4 applications installed on the host. It implies two application instances with installed IPv4 applications are capable of communication using IPv4, but not IPv6 =E2=80=A6=E2=80=A6 IPv6 only host comprises an IPv6 enabled end system stack plus routing in the network, IPv6 applications installed on the host. It implies two application instances with installed IPv6 applications are capable of communication using IPv6, but not IPv4 =E2=80=A6=E2=80=A6 IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications installed on the host. It implies two application instances with installed IPv4/IPv6 applications are capable of communication using IPv6 =E2=80=93 th= ey have IPv4/IPv6 dual-stack, network support including routing in IPv6, IPv4/IPv6 applications can communicate with IPv4/IPv6 hosts respectively. Furthermore, the =E2=80=9CAn IPv6 network=E2=80=9D are proposed to redefine= d as: A specific network that has IPv6-only and IPv4-inherited IPv6 implementation. 2=EF=BC=89How to differentiate IPv6 network & IPv6 Internet The difference between IPv4 network and IPv4 Internet could be identified b= y CGN (NAT) functionalities. However, there are no CGN(NAT) functionalities defined in IPv6 world. It=E2=80=99s difficult to differentiate IPv6 network= and Internet. Hence, we suggest to re-define the IPv6 Internet in the framework draft based on network scale size, as follows: IPv6 Internet means a global system of interconnected IPv6 networks, including enterprise=E2=80=99s IPv6= networks and ISP=E2=80=99s IPv6 networks. Otherwise, we have to introduce a new NAT equipment with NAT66 functionalities to differentiate IPv6 network & IPv6 Internet. 3) Other comments related to the contexts Comments for 3.1.1 and 3.2.2 about stateful translation statements: For stateful translation, the draft has mentioned =E2=80=9Cthe stateful tra= nslation only support IPv6 initiated communication=E2=80=9D. But NAT-PT could suppor= t both directional communication without this limitation. Hence, we suggest to remove this descriptions or point out it is only targeting to NAT64 Comments for 3.3 about ALG descriptions: It only list the demand for FTP ALG. But there should be support any kind o= f applications in which IP address is concluded in payload, such as SIP, RTSP= . Hence, we suggest to extend ALG scope avoid reader=E2=80=99s misunderstandi= ng. Hope all these are meaningful. Regards, Bo Zhou China Mobile --0003255750feb0b03d0471dcedb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fred and others authors of framework for IPv4/IPv= 6 translation
=C2=A0
We have some texts and comments for this draft. Orig= inally, we tried to propose our comments and discuss them inside last Wed&#= 39;s interim meeting, Unfortunately, the shortage of time caused we have no= time to address them. Hence, we pointed them out here.
=C2=A0
1)=C2=A0 We need more clear IP family host definitio= ns
Inside the draft, existing =E2=80=9CIPv6-only=E2=80=9D and =E2=80=9CIPv4-on= ly=E2=80=9D definitions are targeting to IP host capabilities, but there ar= e unclear descriptions of =E2=80=9Capplication instances=E2=80=9D. Hence we= propose the=C2=A0 IP family host shall be defined combining with four aspe= cts:
a. the application type installed on the host,
b.the IP family stack su= pported by a host
c.the IP family routing assigned by a network
d.a= vailable IP family connectivity
According to the above principles, foll= owing IP family host definitions are suggested to replace current =E2=80=9C= IPv6-only=E2=80=9D and =E2=80=9CIPv4-only=E2=80=9D definitions and propose = a new definition for supplement:
IPv4 only host comprises an IPv4 enabled end system stack plus routing in t= he network, IPv= 4 applications installed on the host. It implies two application ins= tances with installed IPv4 applications are = capable of communication using IPv4, but not IPv6 =E2=80=A6=E2=80=A6
IPv6 only host comprises an IPv6 enabled end system stack plus routing in t= he network, IPv6 applications installed on the host= . It implies two application instances with = installed IPv6 applications are capable of communication using IPv6,= but not IPv4 =E2=80=A6=E2=80=A6
IPv4-inherited IPv6 host comprises an IPv4/IPv6 ena= bled end system dual-stack plus IPv6 routing in the network, IPv4/IPv6 appl= ications installed on the host. It implies two application instances with i= nstalled IPv4/IPv6 applications are capable of communication using IPv6 =E2= =80=93 they have IPv4/IPv6 dual-stack, network support including routing in= IPv6, IPv4/IPv6 applications can communicate with IPv4/IPv6 hosts respecti= vely.
Furthermore, the =E2=80=9CAn IPv6 network=E2=80=9D are proposed to redefine= d as: A specific network that has IPv6-only and IPv= 4-inherited IPv6 implementation.
=C2=A0
2=EF=BC=89How to differentiate IPv6 network & IP= v6 Internet
The difference between IPv4 network and IPv4 Internet could be identified b= y CGN (NAT) functionalities. However, there are no CGN(NAT) functionalities= defined in IPv6 world. It=E2=80=99s difficult to differentiate IPv6 networ= k and Internet. Hence, we suggest to re-define the IPv6 Internet in the fra= mework draft based on network scale size, as follows: IPv6 Internet means a global system of interconnected IPv6 networks, inc= luding enterprise=E2=80=99s IPv6 networks and ISP=E2=80=99s IPv6 networks.<= br> Otherwise, we have to=C2=A0introduce a new NAT equipment with NAT66 functio= nalities to differentiate IPv6 network & IPv6 Internet.
=C2=A0
3) Other comments related to the contexts
Comments for 3.1.1 and 3.2.2 about stateful translation statements:
For = stateful translation, the draft has mentioned =E2=80=9Cthe stateful transla= tion only support IPv6 initiated communication=E2=80=9D. But NAT-PT could s= upport both directional communication without this limitation. Hence, we su= ggest to remove this descriptions or point out it is only targeting to NAT6= 4
Comments for 3.3 about ALG descriptions:
It only list the demand for FT= P ALG. But there should be support any kind of applications in which IP add= ress is concluded in payload, such as SIP, RTSP. Hence, we suggest to exten= d ALG scope avoid reader=E2=80=99s misunderstanding.
=C2=A0
Hope all these are meaningful.
=C2=A0
Regards,

Bo Zhou
China Mobile
--0003255750feb0b03d0471dcedb6-- From ari.keranen@nomadiclab.com Mon Aug 24 00:56:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776343A6DCA for ; Mon, 24 Aug 2009 00:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzqzm9ys2d+j for ; Mon, 24 Aug 2009 00:56:44 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 2E0E23A6CAB for ; Mon, 24 Aug 2009 00:56:44 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-ef-4a9247c0485e Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id A7.E7.18827.0C7429A4; Mon, 24 Aug 2009 09:56:48 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 09:56:43 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Aug 2009 09:55:54 +0200 Received: from [127.0.0.1] (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A56632522; Mon, 24 Aug 2009 10:55:54 +0300 (EEST) Message-ID: <4A924786.5060208@nomadiclab.com> Date: Mon, 24 Aug 2009 10:55:50 +0300 From: Ari Keranen User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Dan Wing References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> <4A8BD224.1070508@nomadiclab.com> <05fd01ca22bd$7534ac30$c5f0200a@cisco.com> In-Reply-To: <05fd01ca22bd$7534ac30$c5f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2009 07:55:54.0994 (UTC) FILETIME=[4ED4CD20:01CA2490] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, draft-ietf-behave-turn@tools.ietf.org, behave@ietf.org Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 07:56:45 -0000 Dan Wing wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of Ari Keranen >> Sent: Wednesday, August 19, 2009 3:21 AM >> To: draft-ietf-behave-turn-tcp@tools.ietf.org >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 >> >> Hi, >> >> One technical issue in draft-ietf-behave-turn-tcp-04 caught >> my attention: >> >> In section 4.5., "Sending and Receiving Data" is says: >> >> [...] Data on a data connection MUST NOT >> be interpreted as STUN messages. >> >> I think this is too heavy restriction. What about if the peer >> wants to >> send some STUN messages on the path via the TURN server and >> would need >> the TURN client to parse them as STUN? > > How would the TURN server identify such traffic that it should > respond to? Thinking aloud, one solution is for the local TURN > client to tell the TURN server which STUN username(s) indicate > the STUN message is intended for the TURN server. Actually, my point was about TURN clients (section 4, and the subsections, I assume, are about "client processing"). That is, a TURN client should be able to interpret relayed data as STUN messages. I do understand why this same restriction was in the section 5.4, since section 5 is about the server part. I think the TURN-TCP server can, and should, always just blindly relay the data on the data connection. If there's need for STUN signaling with the server, the control connection should be used for that. >> I would rather make this "SHOULD NOT" to be future proof. Or even >> removing the whole restriction should not do much harm, right? > > The reason for this passage is so that ICE connectivity checks > can be performed, through the TURN server, between the endpoints. > If the TURN server 'eats' (processes) the incoming messages > from the remote peer, the connectivity checks will fail. Yes, that's why section 5.4 is OK with the restriction. Probably this text was supposed to be only in section 5.4 but accidentally slipped to section 4.5 too? > This is really something that belongs in the TURN specification > because I believe it is not unique to TURN-TCP. If anything, the > TURN specification should say something like: > > In the absence of an standards-track enhancement to identify > STUN traffic intended for the TURN server, data on a data > connection MUST NOT be interpreted as a STUN message. > > Thoughts? In the TURN-UDP case you don't have a "data connection" in the same sense as with TURN-TCP, so I think this is actually TURN-TCP specific. Although data sent by a peer should never be interpreted as STUN by the server, but I think this is somewhat clear from the current TURN-UDP draft. Cheers, Ari From jari.arkko@piuha.net Mon Aug 24 04:55:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58773A6DB3 for ; Mon, 24 Aug 2009 04:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L403+yb2k9NZ for ; Mon, 24 Aug 2009 04:55:42 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CA7303A6D9A for ; Mon, 24 Aug 2009 04:55:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7E921198661; Mon, 24 Aug 2009 14:55:47 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjK5ZUma2YX0; Mon, 24 Aug 2009 14:55:46 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BC61A1985F9; Mon, 24 Aug 2009 14:55:46 +0300 (EEST) Message-ID: <4A927FC2.6000701@piuha.net> Date: Mon, 24 Aug 2009 14:55:46 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bob Hinden References: <18256DC3-184D-48FE-B37C-2F9867597304@free.fr> <4A4E2E6F.7030508@gmail.com> <8098F545-2699-4F14-8004-4D428E27B520@free.fr> <5D87A80F-E677-4602-BE5F-3429D01254E3@muada.com> <136D8885-870E-4C44-BAA2-DC2A96AA05EA@free.fr> <4650B459-B4B7-4684-B1F4-363CA93AAE27@muada.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brian Haberman , Behave WG , Dave Thaler , Ralph Droms , Xing Li Subject: Re: [BEHAVE] Modified EUI-64 format X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 11:55:42 -0000 Bob Hinden wrote: >> I agree with Brian that the Behave WG should leave the u/l bit alone >> unless 6man decides to change the address architecture, which is a BIG >> decision. I am not confident of that happening any time soon, >> whereas Behave needs to progress rapidly. >> > > +1 > +1 and sorry for the late reply. I'm now cleaning up my inbox and going through everything... Jari From simon.perreault@viagenie.ca Mon Aug 24 07:27:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E001828C1E1 for ; Mon, 24 Aug 2009 07:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHLRC-X93TDk for ; Mon, 24 Aug 2009 07:27:05 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 7192E28C1AB for ; Mon, 24 Aug 2009 07:26:54 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 9925929E15FC; Mon, 24 Aug 2009 10:26:56 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 814AD29E15ED; Mon, 24 Aug 2009 10:26:56 -0400 (EDT) Message-ID: <4A92A330.1080103@viagenie.ca> Date: Mon, 24 Aug 2009 10:26:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Dave Thaler References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-behave-turn-tcp@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 14:27:07 -0000 Thank you very much for your comments. Dave Thaler wrote, on 08/08/09 02:29 PM: > 1) Are data connections to be closed gracefully or abortively, The draft is intentionally silent about this. It is expected that "closing a connection" will be done by following Figure 6 in RFC 793 (the arrow labeled CLOSE below the ESTAB state), but the server is free to do otherwise as long as it is valid TCP. Do you have a reason in mind why we should be more explicit? > and does this depend on how the corresponding (peer vs client) > connection was closed? Note that requiring this would probably not be implementable in non-root user-space. > 2) When error 447 is returned, section 4.3 says the client MUST > wait at least 10 seconds before retrying. I think this is > for the _same_ destination IP/port, right? If the client > has other destination IP/port pairs to try, they can be > tried immediately, correct? Correct. I have change the wording: The client MAY retry *with the same XOR-PEER-ADDRESS attribute*, but MUST wait at least 10 seconds. > 3) Section 4.6 notes that no keepalive mechanism is provided > and an application can do this at a higher layer. For > NATs between a TURN client and a TURN server, why wouldn't > TCP keepalives be a possibility? Because in non-root user-space, TCP keepalives as provided by the OS are nearly worthless in many important cases because they cannot be setup per-socket. They are setup system-wide and you need to be root to change the timeout. Basically it's another item in the list of things with STUN/TURN that are the way they are because of the requirement that a server be implementable in non-root user-space. > 4) If I understand the 3rd paragraph of section 5.2, correctly, > there's an important limitation/constraint that should be > called out early (e.g. in the overview). Normally, TCP > clients can open multiple parallel connections (e.g., to > a web server) to the same destination address/port. To > accomplish this with TURN, it seems that the client needs > multiple control connections so it can get multiple > allocations, since it can only have one connection to a > given peer address/port per allocation, correct? Yes, this is correct. It follows naturally from the fact that a 5-tuple uniquely identifies a connection, and that the local address and port are fixed from the moment the allocation is created. How about adding the following sentence to the third paragraph of section 3? "Note that a maximum of one connection to a given peer (address and port combination) can be established per allocation." > 5) The 5th paragraph of Section 5.2 also implies that it's > illegal for a TURN server to refuse to initiate connections > based on the XOR-PEER-ADDRESS value. For example, if it > refuses to initiate connections to 127.0.0.1 it would be > violating a MUST. I'd like to see this relaxed. How about this modified text? "Otherwise, *and if the new connection is permitted by local policy,* the server MUST initiate an outgoing TCP connection." This lets the server filter by peer address as well as other criteria. > 6) The draft talks about timing out a peer connection after > 30 seconds in section 5.3 if the client never does a > ConnectionBind for a connection initiated by a peer. > However, section 5.2 has no corresponding rule. This > means a client can send a Connect request, and then > never open a data connection, and the server will never > time out the peer connection. The same rule needs to be > added to 5.2 to address this. Good catch. I've copied the paragraph in question to the end of section 5.2. > 7) Continuing on the same point, the security considerations > section needs to add a discussion of a memory DoS attack > due to the TURN server having to buffer data from a peer > while waiting for a ConnectionBind (which may never happen). Actually, this highlights a bug in the current spec (section 5.2, paragraph 7): The server MUST buffer any data received from the peer. Data MUST NOT be lost. It is up to the server to adjust its advertised TCP receive window should the buffer size become a limiting factor. If it is not not lose data, the server must rely on the peer obeying the TCP window. This is bad. Instead, I propose the following: The server MUST buffer any data received from the peer. Data MUST NOT be lost unless the buffer is about to exceed a limit defined by local policy, in which case the data connection MUST be closed. The server adjusts its advertised TCP receive window to reflect the amount of empty buffer space. Similar wording would be applied to section 5.3, paragraph 3. How about adding the following text to the security considerations section? After a TCP connection is established between the server and a peer, and before a ConnectionBind request is received from the client, the server buffers all data received from the peer. This protocol specification lets the server drop the connection if the buffer size is about to exceed a limit defined by local policy. This policy should ensure that memory resources are not exceeded. > Currently it has references to docs that contain > discussion of bandwidth DoS attacks, but not memory > DoS attacks, as far as I can find. The above paragraph would indeed be much improved with such a reference. Could you provide one? Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jacniq@gmail.com Mon Aug 24 09:12:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D948828C22A for ; Mon, 24 Aug 2009 09:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCY0-SI63Odw for ; Mon, 24 Aug 2009 09:12:01 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id 36C9E28C267 for ; Mon, 24 Aug 2009 09:12:01 -0700 (PDT) Received: by ewy2 with SMTP id 2so3049181ewy.43 for ; Mon, 24 Aug 2009 09:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xYATt6rC2Pdnoqq+uqBSOQomcLoQ03CfL4KMzOUMegI=; b=VjLXNwMjz4QH7VWjKIcM8/ZmasS8DGfKA5BQzy/GH9mJFVRHuO+iumay8OftIMFX1j 61e4+1JHT8K8LqUeZRb5XswBUo0G6rw6tvgtHpzWPmnZiFxQdYd9rFM8XPeo/YDFQ6EO Dhl3iV2QHnQh9ZwY1CFEGzULzJtpXp+9SYuhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NRnOjWgjSM6CPakHAFMes47haUj1rokOcm1yX4rTOss6BtkJaq1wuIxR191V4TJS0l W3LApVXE6NthgIxFxj0KOMgfNCIsbK9FVTTDz+bQTJn15hzsItJlRsiGXqh6W2WXB+yr ZmaCLtOIjjj1bOeSGF72mIrEva75FWjquT8aw= MIME-Version: 1.0 Received: by 10.216.26.82 with SMTP id b60mr998617wea.177.1251130324795; Mon, 24 Aug 2009 09:12:04 -0700 (PDT) In-Reply-To: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> Date: Tue, 25 Aug 2009 00:12:04 +0800 Message-ID: From: Jacni Qin To: liu dapeng Content-Type: multipart/alternative; boundary=0016e655991a93c33c0471e57a82 Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 16:12:02 -0000 --0016e655991a93c33c0471e57a82 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Dapeng, i read the draft, in section6, 2. Behavior of FTP client when retrying with PASV command [I-D.draft-van-beijnum-behave-ftp64-05 ] recommends that the client should use the IPv4 address in the PASV response message if it has IPv4 connectivity and use the control connection's IP address if it does not have IPv4 connectivity. However, this document specifies that the client should use the control channel's IP address without determination whether it has IPv4 connectivity or not. This will simplify the client software, besides, if the client has IPv4 connectivity, the control channel will use its IPv4 address instead of using its IPv6 address to connect to the IPv4 server. reusing the control connection's (or channel, maybe we can unify the words) IP address ? as i understand. if so, it makes the clients neat, or is there other matter of concern i missed? Jacni On Thu, Aug 20, 2009 at 9:59 PM, liu dapeng wrote: > Hello everyone: > > We have posted a draft about FTP64 issue > (http://tools.ietf.org/html/draft-liu-behave-ftp64-00). We know that > there is another solution proposed > (http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-05), but we > have a different view and approache regarding to this problem, the > main differences are: > > 1. Our viewpoint regarding to FTP64 is that since the ALG problem > could be totally avoided by carefully defining the behavior of the FTP > client and server, translation box need not to implement FTP ALG. > > 2.We propose that the client just uses the control channel=92s IP > address when it retries with PASV command. This approach not only > simplifies the client's implementation, but also avoids some problems > caused by using the IPv4 connectivity of the client. > > Any comments are welcome. > > BR, > Dapeng Liu > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --0016e655991a93c33c0471e57a82 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Dapeng,

i read the draft, in section6,

   2. Behavior of FTP client when retrying with PASV command

   =
[I-D.draft-van-beijnum-behave-ftp64-05] recommends that the client

   should use the IPv4 address in the PASV response message if it has
  =
 IPv4 connectivity and use the control connection's IP address if it   does not have IPv4 connectivity. However, this document specifies

   that the client should use the control channel's IP address without<=
br>   determination whether it has IPv4 connectivity or not. This will
 =
  simplify the client software, besides, if the client has IPv4
   conne=
ctivity, the control channel will use its IPv4 address instead

   of using its IPv6 address to connect to the IPv4 server.
reusin= g the control connection's (or channel, maybe we can unify the words) I= P address ? as i understand.
if so, it makes the clients neat, or is the= re other matter of concern i missed?

Jacni


On Thu, Aug 20, 2009 at 9:5= 9 PM, liu dapeng <maxpassion@gmail.com> wrote:
Hello everyone:

We have posted a draft about FTP64 issue
(http://tools.ietf.org/html/draft-liu-behave-ftp64-00). We know= that
there is another solution proposed
(http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-= 05), but we
have a different view and approache regarding to this problem, the
main differences are:

1. Our viewpoint regarding to FTP64 is that since the ALG problem
could be totally avoided by carefully defining the behavior of the FTP
client and server, translation box need not to implement FTP ALG.

2.We propose that the client just uses the control channel=92s IP
address when it retries with PASV command. This approach not only
simplifies the client's implementation, but also avoids some problems caused by using the IPv4 connectivity of the client.

Any comments are welcome.

BR,
Dapeng Liu
_______________________________________________
Behave mailing list
Behave@ietf.org
= https://www.ietf.org/mailman/listinfo/behave

--0016e655991a93c33c0471e57a82-- From jacniq@gmail.com Mon Aug 24 09:15:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3EA728C285 for ; Mon, 24 Aug 2009 09:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL0Zc4gv4M0c for ; Mon, 24 Aug 2009 09:15:28 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id 7652828C28B for ; Mon, 24 Aug 2009 09:15:09 -0700 (PDT) Received: by ewy2 with SMTP id 2so3052277ewy.43 for ; Mon, 24 Aug 2009 09:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=65nLg5Cqu2dYjH2ZE0iR3rwLhppEg14vJV839HXW37I=; b=Do0TgDjekIxfPo0CyZPU+rEX3QNn45XDKEkxGhYCBY+Q5SIL4tfeeRPTppr/yXcEtV 9hXyp33Ug16TPAqZ57015f975q4hg0V3I9TU0lFu6fvrB5aUnfoYjJc3CxYUOoNDR0pM q+CxMR3Grp1lY8457mJHnricQDHqjtY/MBCDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AhjPJ3NzFMqGwdmoqBmORGxQ2mTBwoCHJ9+M1t7yJY/FI2JmmLKFaefCp+0RPU0sMT cVk9q4oZqMcnNn+5zyDM/O0yqlLoQyHbKqV903fh2CYyNnF6+R3SUDrCsSHS00Tbe7Vn JwIjVZzJJxnoTj8vvubCc5bZwMQt5cleC1t0A= MIME-Version: 1.0 Received: by 10.216.47.201 with SMTP id t51mr1026958web.198.1251130512678; Mon, 24 Aug 2009 09:15:12 -0700 (PDT) In-Reply-To: <4A916E13.70404@bogus.com> References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> Date: Tue, 25 Aug 2009 00:15:12 +0800 Message-ID: From: Jacni Qin To: Joel Jaeggli Content-Type: multipart/alternative; boundary=001485f6c2fac69e320471e585b7 Cc: shengjiang@huawei.com, bo zhou , behave@ietf.org, liu dapeng , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 16:15:30 -0000 --001485f6c2fac69e320471e585b7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Aug 24, 2009 at 12:28 AM, Joel Jaeggli wrote: > bo zhou wrote: > > Agreed with Sheng. If we can avoid FTP ALG in network side by carefully > > defined the behaviours of client and server, why we should > > put ALG inside the standardisation. > > The historical problem being that ftp clients and servers have been > disinclined to change their behavior just because someone writes a draft > and passes it through the iesg and rfc editor, that's in part why we are > where we are today with ftp. > yes, you said it, while if we have a chance to improve it now, why not? :-) Jacni > > You can avoid alg by dropping the client/server combos you don't want to > support off the list, it doesn't make the problem go away but it does > remove it as an obstacle to this draft. > > > Furthermore, ALGs (not only FTP) cannot avoid during NAT64 deployment. > > like Reinaldo mentioned, it is a tricky problem to standardise ALG even > > everybody know it will exist as long as NAT64 exist. > > Regards, > > Bo Zhou > > > --001485f6c2fac69e320471e585b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 24, 2009 at 12:28 AM, Joel J= aeggli <joelja@bog= us.com> wrote:
bo zhou wrote:
> Agreed with Sheng. If we can avoid FTP ALG in network side by carefull= y
> defined the behaviours of client and server, why we should
> put ALG inside the standardisation.

The historical problem being that ftp clients and servers have been disinclined to change their behavior just because someone writes a draft and passes it through the iesg and rfc editor, that's in part why we ar= e
where we are today with ftp.

yes, you said it, while if we have a chance to improv= e it now, why not? :-)

Jacni

=A0

You can avoid alg by dropping the client/server combos you don't want t= o
support off the list, it doesn't make the problem go away but it does remove it as an obstacle to this draft.

> Furthermore, ALGs (not only FTP) cannot avoid during NAT64 deployment.=
> like Reinaldo mentioned, it is a tricky problem to standardise ALG eve= n
> everybody know it will exist as long as NAT64 exist.
> Regards,
> Bo Zhou
>

--001485f6c2fac69e320471e585b7-- From joelja@bogus.com Mon Aug 24 09:22:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C60A28C2A1 for ; Mon, 24 Aug 2009 09:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK5vHc62UUnB for ; Mon, 24 Aug 2009 09:22:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id B100228C257 for ; Mon, 24 Aug 2009 09:22:30 -0700 (PDT) Received: from [209.97.124.176] ([209.97.124.176]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n7OGMIAZ042755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Aug 2009 16:22:20 GMT (envelope-from joelja@bogus.com) Message-ID: <4A92BE35.3010805@bogus.com> Date: Mon, 24 Aug 2009 09:22:13 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jacni Qin References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 24 Aug 2009 16:22:20 +0000 (UTC) Cc: shengjiang@huawei.com, bo zhou , behave@ietf.org, liu dapeng , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 16:22:31 -0000 Jacni Qin wrote: > > > On Mon, Aug 24, 2009 at 12:28 AM, Joel Jaeggli > wrote: > > bo zhou wrote: > > Agreed with Sheng. If we can avoid FTP ALG in network side by > carefully > > defined the behaviours of client and server, why we should > > put ALG inside the standardisation. > > The historical problem being that ftp clients and servers have been > disinclined to change their behavior just because someone writes a draft > and passes it through the iesg and rfc editor, that's in part why we are > where we are today with ftp. > > > yes, you said it, while if we have a chance to improve it now, why not? :-) You can write whatever you want, it won't change the deployed code. From dthaler@microsoft.com Mon Aug 24 09:50:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59CD228C162 for ; Mon, 24 Aug 2009 09:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.401 X-Spam-Level: X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3NHLIneMcTl for ; Mon, 24 Aug 2009 09:50:43 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1F2B13A6C26 for ; Mon, 24 Aug 2009 09:50:43 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 24 Aug 2009 09:50:34 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.621.7; Mon, 24 Aug 2009 09:50:33 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 24 Aug 2009 09:50:36 -0700 From: Dave Thaler To: Simon Perreault Thread-Topic: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 Thread-Index: AcoQ8pHnO58KBYnbRjO0tt9j9fIZ2QHYMcMQAyuQhgAAClQMkA== Date: Mon, 24 Aug 2009 16:50:28 +0000 Message-ID: References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> <4A92A330.1080103@viagenie.ca> In-Reply-To: <4A92A330.1080103@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-behave-turn-tcp@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 16:50:44 -0000 Simon Perreault write: > Dave Thaler wrote, on 08/08/09 02:29 PM: > > 1) Are data connections to be closed gracefully or abortively, > > The draft is intentionally silent about this. It is expected that > "closing a > connection" will be done by following Figure 6 in RFC 793 (the arrow > labeled > CLOSE below the ESTAB state), but the server is free to do otherwise as > long as > it is valid TCP. > > Do you have a reason in mind why we should be more explicit? I think you should be explicit that either is ok, rather than it looking like an oversight that will generate questions like mine. > > and does this depend on how the corresponding (peer vs client) > > connection was closed? > > Note that requiring this would probably not be implementable in non- > root user-space. I wouldn't go there, as that's very OS-specific. > > 2) When error 447 is returned, section 4.3 says the client MUST > > wait at least 10 seconds before retrying. I think this is > > for the _same_ destination IP/port, right? If the client > > has other destination IP/port pairs to try, they can be > > tried immediately, correct? > > Correct. I have change the wording: > > The client MAY retry *with the same XOR-PEER-ADDRESS attribute*, but > MUST wait > at least 10 seconds. Looks ok. > > 3) Section 4.6 notes that no keepalive mechanism is provided > > and an application can do this at a higher layer. For > > NATs between a TURN client and a TURN server, why wouldn't > > TCP keepalives be a possibility? > > Because in non-root user-space, TCP keepalives as provided by the OS > are nearly > worthless in many important cases because they cannot be setup per- > socket. They > are setup system-wide and you need to be root to change the timeout. Um, no. Again, this is OS specific, and in fact it's per-socket configurable on Windows: http://msdn.microsoft.com/en-us/library/dd877220(VS.85).aspx This should be rephrased to allow for the possibility that the OS supports per-socket TCP keepalive intervals. > Basically it's another item in the list of things with STUN/TURN that > are the > way they are because of the requirement that a server be implementable > in > non-root user-space. > > > 4) If I understand the 3rd paragraph of section 5.2, correctly, > > there's an important limitation/constraint that should be > > called out early (e.g. in the overview). Normally, TCP > > clients can open multiple parallel connections (e.g., to > > a web server) to the same destination address/port. To > > accomplish this with TURN, it seems that the client needs > > multiple control connections so it can get multiple > > allocations, since it can only have one connection to a > > given peer address/port per allocation, correct? > > Yes, this is correct. It follows naturally from the fact that a 5-tuple > uniquely > identifies a connection, and that the local address and port are fixed > from the > moment the allocation is created. > > How about adding the following sentence to the third paragraph of > section 3? > > "Note that a maximum of one connection to a given peer (address and > port > combination) can be established per allocation." Ok. > > 5) The 5th paragraph of Section 5.2 also implies that it's > > illegal for a TURN server to refuse to initiate connections > > based on the XOR-PEER-ADDRESS value. For example, if it > > refuses to initiate connections to 127.0.0.1 it would be > > violating a MUST. I'd like to see this relaxed. > > How about this modified text? > > "Otherwise, *and if the new connection is permitted by local policy,* > the server > MUST initiate an outgoing TCP connection." > > This lets the server filter by peer address as well as other criteria. Yep, that looks great. > > 6) The draft talks about timing out a peer connection after > > 30 seconds in section 5.3 if the client never does a > > ConnectionBind for a connection initiated by a peer. > > However, section 5.2 has no corresponding rule. This > > means a client can send a Connect request, and then > > never open a data connection, and the server will never > > time out the peer connection. The same rule needs to be > > added to 5.2 to address this. > > Good catch. I've copied the paragraph in question to the end of section > 5.2. Ok. > > 7) Continuing on the same point, the security considerations > > section needs to add a discussion of a memory DoS attack > > due to the TURN server having to buffer data from a peer > > while waiting for a ConnectionBind (which may never happen). > > Actually, this highlights a bug in the current spec (section 5.2, > paragraph 7): > > The server MUST buffer any data received from the peer. > Data MUST NOT be lost. It is up to the server to adjust its > advertised TCP receive window should the buffer size become a > limiting factor. > > If it is not not lose data, the server must rely on the peer obeying > the TCP > window. This is bad. Instead, I propose the following: > > The server MUST buffer any data received from the peer. > Data MUST NOT be lost unless the buffer is about to exceed a limit > defined > by local policy, in which case the data connection MUST be closed. > The > server adjusts its advertised TCP receive window to reflect the > amount of > empty buffer space. > > Similar wording would be applied to section 5.3, paragraph 3. Ok. I would assume it's legal for the server to just not do a read() until after a ConnectionBind request is received from the client, thereby making the OS handle the buffering, right? > How about adding the following text to the security considerations > section? > > After a TCP connection is established between the server and a > peer, and > before a ConnectionBind request is received from the client, the > server > buffers all data received from the peer. This protocol > specification lets > the server drop the connection if the buffer size is about to > exceed a > limit defined by local policy. This policy should ensure that > memory > resources are not exceeded. > > > Currently it has references to docs that contain > > discussion of bandwidth DoS attacks, but not memory > > DoS attacks, as far as I can find. > > The above paragraph would indeed be much improved with such a > reference. Could > you provide one? How about [RFC4732] section 2.1? -Dave From simon.perreault@viagenie.ca Mon Aug 24 10:09:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D36328C17C for ; Mon, 24 Aug 2009 10:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvEPiCwzLcNR for ; Mon, 24 Aug 2009 10:09:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id C5A553A6999 for ; Mon, 24 Aug 2009 10:09:32 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 881A929E1602; Mon, 24 Aug 2009 13:09:38 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 7CB4429E15ED; Mon, 24 Aug 2009 13:09:38 -0400 (EDT) Message-ID: <4A92C952.3040204@viagenie.ca> Date: Mon, 24 Aug 2009 13:09:38 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: Dave Thaler References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> <4A92A330.1080103@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-behave-turn-tcp@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 17:09:34 -0000 Dave Thaler wrote, on 24/08/09 12:50 PM: >> Because in non-root user-space, TCP keepalives as provided by the OS >> are nearly >> worthless in many important cases because they cannot be setup per- >> socket. They >> are setup system-wide and you need to be root to change the timeout. > > Um, no. Again, this is OS specific, and in fact it's per-socket > configurable on Windows: > http://msdn.microsoft.com/en-us/library/dd877220(VS.85).aspx Hence the "in many important cases". > This should be rephrased to allow for the possibility > that the OS supports per-socket TCP keepalive intervals. I'm fine with a MAY. I'll add this to the draft. >> The server MUST buffer any data received from the peer. >> Data MUST NOT be lost unless the buffer is about to exceed a limit >> defined >> by local policy, in which case the data connection MUST be closed. >> The >> server adjusts its advertised TCP receive window to reflect the >> amount of >> empty buffer space. > > Ok. I would assume it's legal for the server to just not do a read() > until after a ConnectionBind request is received from the client, > thereby making the OS handle the buffering, right? This is exactly what I had in mind. >> After a TCP connection is established between the server and a >> peer, and >> before a ConnectionBind request is received from the client, the >> server >> buffers all data received from the peer. This protocol >> specification lets >> the server drop the connection if the buffer size is about to >> exceed a >> limit defined by local policy. This policy should ensure that >> memory >> resources are not exceeded. >> >>> Currently it has references to docs that contain >>> discussion of bandwidth DoS attacks, but not memory >>> DoS attacks, as far as I can find. >> The above paragraph would indeed be much improved with such a >> reference. Could >> you provide one? > > How about [RFC4732] section 2.1? Thanks. I'll link to 2.1.3, which is more specifically about resource exhaustion. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From maxpassion@gmail.com Mon Aug 24 10:33:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AE928C2C7 for ; Mon, 24 Aug 2009 10:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FecGNzqXDl8 for ; Mon, 24 Aug 2009 10:33:33 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id C271D28C29E for ; Mon, 24 Aug 2009 10:33:33 -0700 (PDT) Received: by vws34 with SMTP id 34so2228275vws.31 for ; Mon, 24 Aug 2009 10:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qxDet7kb0MUEAKNJL6ySwhLooymNZHOAL3r5OmCT5YI=; b=FiuciISxebm6ujSDpZwPounttuMXNrzkQNZuc/Nm6Q73z9upBgaUbM+V8V3Enj4flk sS7sAK99M5uEXCUL+NZXwV4rD/90uvLjsGoe3PINoPrMmUZ2flE2rA3ZcPz1xiQLI0dp qy9u6ZfMcVXYH18kbzDAnDCggtPAQJojslChY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cZkpis68HbcohZOOBev5ULYyQunF4tTejcLbburY4XHlLBjgXXCBaX1KSS0iaRT/Bw JdH4y0Okl+4XM0DDImkUbk9Lqq86SQ8LQzcnIx6LhsPbZH9ygd0L8PUPw+KzYzvmvqvO wK+5UEYJ7f3660W7VIuHNyLnHlqyB7gvCkkqY= MIME-Version: 1.0 Received: by 10.220.70.72 with SMTP id c8mr6065639vcj.18.1251135217044; Mon, 24 Aug 2009 10:33:37 -0700 (PDT) In-Reply-To: References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> Date: Tue, 25 Aug 2009 01:33:36 +0800 Message-ID: <25e1aaa40908241033r52ad4f09i996f4af28e616fb4@mail.gmail.com> From: liu dapeng To: Jacni Qin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 17:33:34 -0000 2009/8/25, Jacni Qin : > hi Dapeng, > > i read the draft, in section6, > > 2. Behavior of FTP client when retrying with PASV command > > [I-D.draft-van-beijnum-behave-ftp64-05 > ] > recommends that the client > should use the IPv4 address in the PASV response message if it has > IPv4 connectivity and use the control connection's IP address if it > does not have IPv4 connectivity. However, this document specifies > that the client should use the control channel's IP address without > determination whether it has IPv4 connectivity or not. This will > simplify the client software, besides, if the client has IPv4 > connectivity, the control channel will use its IPv4 address instead > of using its IPv6 address to connect to the IPv4 server. > > reusing the control connection's (or channel, maybe we can unify the word= s) > IP address ? as i understand. > if so, it makes the clients neat, or is there other matter of concern i > missed? It can also avoid the potential problems caused by using the client's IPv4 connection. For example, if the client has a private IPv4 connection and a public IPv6 connection. If the client tries to use its IPv4 connection to establish data connection to the server, it will never success. > Jacni > > > On Thu, Aug 20, 2009 at 9:59 PM, liu dapeng wrote: > >> Hello everyone: >> >> We have posted a draft about FTP64 issue >> (http://tools.ietf.org/html/draft-liu-behave-ftp64-00). We know that >> there is another solution proposed >> (http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-05), but we >> have a different view and approache regarding to this problem, the >> main differences are: >> >> 1. Our viewpoint regarding to FTP64 is that since the ALG problem >> could be totally avoided by carefully defining the behavior of the FTP >> client and server, translation box need not to implement FTP ALG. >> >> 2.We propose that the client just uses the control channel=92s IP >> address when it retries with PASV command. This approach not only >> simplifies the client's implementation, but also avoids some problems >> caused by using the IPv4 connectivity of the client. >> >> Any comments are welcome. >> >> BR, >> Dapeng Liu >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From maxpassion@gmail.com Mon Aug 24 10:40:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8F13A6DEA for ; Mon, 24 Aug 2009 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzMUFp-7xcID for ; Mon, 24 Aug 2009 10:40:09 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id 8E1523A6AFE for ; Mon, 24 Aug 2009 10:40:08 -0700 (PDT) Received: by vws34 with SMTP id 34so2234341vws.31 for ; Mon, 24 Aug 2009 10:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=wInoUhEHysgMYt+zgwl3ZO3I95m7KfY0aYPfMOu+otI=; b=gB61XICtfC0/EUGD+HeV/ThVhk6MdvcAqKc5WTxZcz9CVM5VGXEvdxxnlSRmiGMsc4 y6UV/JEfxnyNmCXaFvG3M5oFQoYd9bH/dZmAJy7XEMje+Y2picQHaooLNt74PuMHyWcT JwtQpRg7F4lw69XICnZuNQuD5MN910TazoWKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=aF/kxyD6jdR7weCGggKVsGads/X7F1VilLjMoOF9/K+rFO42y3CRPVUd7NGTDXS/Rb LEcl6D/9DQ2bejhZ8CRY/8xQWr6CU4D9OoHpwX/XvO+kVwX23zMbBEaPe1QPqrI7VCxa j00NWStskiV6muiGGHQke24Ju/CN33qqS/TcE= MIME-Version: 1.0 Received: by 10.220.113.211 with SMTP id b19mr6266459vcq.60.1251135611809; Mon, 24 Aug 2009 10:40:11 -0700 (PDT) In-Reply-To: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> Date: Tue, 25 Aug 2009 01:40:11 +0800 Message-ID: <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> From: liu dapeng To: behave@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 17:40:09 -0000 Hello everyone: We upgrade the ftp64 draft, add some text considering the legacy FTP implementation and other clarification as well. Any comments are welcomed. BR, Dapeng Liu ---------------------------------------------------------------------------= ------------------------------------------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D Action:draft-liu-behave-ftp64-01.txt X-RSN: 1/0/935/26127/29474 X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D29474 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 IPv4 translation FTP considerations Author(s) : D. Liu, Z. Cao Filename : draft-liu-behave-ftp64-01.txt Pages : 7 Date : 2009-08-24 The File transfer protocol, which is defined by the RFC 959, is widely used. RFC 2428 define IPv6 extensions of FTP, introducing EPRT and EPSV command. In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. There already have some work to address this problem, such as "draft-van-beijnum-behave-ftp64-05" etc, but this document provides a different approach. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liu-behave-ftp64-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ***** Click below to download the attachment(s) in this message: Attachment: draft_liu_behave_ftp64_01.txt (1K) 2009/8/20, liu dapeng : > Hello everyone: > > We have posted a draft about FTP64 issue > (http://tools.ietf.org/html/draft-liu-behave-ftp64-00). We know that > there is another solution proposed > (http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-05), but we > have a different view and approache regarding to this problem, the > main differences are: > > 1. Our viewpoint regarding to FTP64 is that since the ALG problem > could be totally avoided by carefully defining the behavior of the FTP > client and server, translation box need not to implement FTP ALG. > > 2.We propose that the client just uses the control channel=92s IP > address when it retries with PASV command. This approach not only > simplifies the client's implementation, but also avoids some problems > caused by using the IPv4 connectivity of the client. > > Any comments are welcome. > > BR, > Dapeng Liu > From iljitsch@muada.com Mon Aug 24 13:15:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9B43A6DE7 for ; Mon, 24 Aug 2009 13:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp0xhR4QX5df for ; Mon, 24 Aug 2009 13:15:05 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 303B33A6E94 for ; Mon, 24 Aug 2009 13:13:57 -0700 (PDT) Received: from [192.168.0.196] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7OKDLtn004535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Aug 2009 22:13:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> From: Iljitsch van Beijnum To: liu dapeng In-Reply-To: <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 24 Aug 2009 22:13:52 +0200 References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2009 20:15:05 -0000 On 24 aug 2009, at 19:40, liu dapeng wrote: > We upgrade the ftp64 draft, add some text considering the legacy FTP > implementation and other clarification as well. Any comments are > welcomed. Can you please send the new text to the list? A client that implements the client requirements and client recommendations listed in draft-van-beijnum-behave-ftp64-05 will be able to successfully interoperate with any server that implements EPSV or PASV through a stateful or stateless translator. Since updating an FTP client is about the easiest possible upgrade that we could possibly require (an FTP client doesn't need special privileges and can run as a java applet in a browser) this provides a workable solution for most users. However, there is additional benefit in making FTP through a translator work for users with existing implementations, which can be accomplished by either server upgrades or an ALG. Since at least one vendor has expressed interest in implementing such an ALG, having standard ALG functionality is better than undefined ALG functionality and we have the text now anyway, in my opinion it doesn't make sense to remove the ALG text, although I'm willing to make it (even) more clear that such an ALG is optional. From denghui02@gmail.com Tue Aug 25 07:21:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AE53A6F73 for ; Tue, 25 Aug 2009 07:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlmwBeOeBpN3 for ; Tue, 25 Aug 2009 07:21:53 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 72CD53A6F56 for ; Tue, 25 Aug 2009 07:21:53 -0700 (PDT) Received: by ewy3 with SMTP id 3so3741609ewy.42 for ; Tue, 25 Aug 2009 07:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lg3/S+brKb/5SV+N9oo9byYpnI3UymQcXmLJlKlXB6w=; b=PTDQc+F/TEazs1sa1Smk4WTPyFsb39pC1FTCEexMmH0FvNNfFGmibxNQ8iSceipt5p ltjNduKbVwJfdFNnM0YpnJe8/qlOL7s+Q0WO5/8gFCGxOqfP1HxTD11S6VoiM+EeCbMn lX/V/CGtkEptNBoFE5pGEI26ppxdJqhhCp2W4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e6vZtfefugyfnV01/yPJCDKRoQQtDTB7/79izgACguudd1OBg0OJ+DflTooB/M/Hkt iMAIpx3T/7c+SIFiQUKJ6sh1iv53DOSUuwInOIAS5+NrJvv6vUKIoPnn4KF4wCMnL62c RoE61v6aLJI2jvrZPrhbKrdyVJGL6XUccaIt4= MIME-Version: 1.0 Received: by 10.210.34.20 with SMTP id h20mr487331ebh.61.1251210115438; Tue, 25 Aug 2009 07:21:55 -0700 (PDT) In-Reply-To: <4A92BE35.3010805@bogus.com> References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> <4A92BE35.3010805@bogus.com> Date: Tue, 25 Aug 2009 22:21:55 +0800 Message-ID: <1d38a3350908250721h183e638r25a5520833c0c78b@mail.gmail.com> From: Hui Deng To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: shengjiang@huawei.com, behave@ietf.org, Jacni Qin , liu dapeng , bo zhou , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 14:21:54 -0000 > You can write whatever you want, it won't change the deployed code. How many people really use FTP6 today? -Hui > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From joelja@bogus.com Tue Aug 25 11:04:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D4228C4F6 for ; Tue, 25 Aug 2009 11:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9Mm+7eJ0r8D for ; Tue, 25 Aug 2009 11:04:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id DBCAF3A6968 for ; Tue, 25 Aug 2009 11:03:55 -0700 (PDT) Received: from [209.97.124.176] ([209.97.124.176]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n7PI3cCD026767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Aug 2009 18:03:39 GMT (envelope-from joelja@bogus.com) Message-ID: <4A942774.5000500@bogus.com> Date: Tue, 25 Aug 2009 11:03:32 -0700 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Hui Deng References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> <4A92BE35.3010805@bogus.com> <1d38a3350908250721h183e638r25a5520833c0c78b@mail.gmail.com> In-Reply-To: <1d38a3350908250721h183e638r25a5520833c0c78b@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 25 Aug 2009 18:03:43 +0000 (UTC) Cc: shengjiang@huawei.com, behave@ietf.org, Jacni Qin , liu dapeng , bo zhou , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 18:04:35 -0000 Hui Deng wrote: >> You can write whatever you want, it won't change the deployed code. > How many people really use FTP6 today? How long has your host stack and many of the included applications supported ipv6? 6 years? longer maybe? What odds do you put on the windows xp command-line ftp client being changed? and that change being propagated into systems everywhere. That's only one example but it's an ubiquitous one. The point is legacy applications don't change, if they did v4 to v6 migration would be a lot simpler in the first place. > -Hui > >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > From iljitsch@muada.com Tue Aug 25 11:34:10 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0673A6968 for ; Tue, 25 Aug 2009 11:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH1RxORwhAa9 for ; Tue, 25 Aug 2009 11:34:10 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id E1F9E3A68B8 for ; Tue, 25 Aug 2009 11:34:09 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7PIXVEw011692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2009 20:33:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Joel Jaeggli In-Reply-To: <4A942774.5000500@bogus.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 25 Aug 2009 20:34:03 +0200 References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> <4A92BE35.3010805@bogus.com> <1d38a3350908250721h183e638r25a5520833c0c78b@mail.gmail.com> <4A942774.5000500@bogus.com> X-Mailer: Apple Mail (2.936) Cc: Behave WG Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 18:34:10 -0000 On 25 aug 2009, at 20:03, Joel Jaeggli wrote: > What odds do you put on the windows xp command-line ftp client being > changed? and that change being propagated into systems everywhere. > That's only one example but it's an ubiquitous one. But to what degree does that matter? Browsers support FTP with EPSV and in most cases, it's possible to install more capable FTP client. FTP clients are high on those "so I switched to this new OS, what software do I install?" lists. Also note that the ftp64 draft that was adopted as a wg draft in Stockholm requires clients to at least support PASV, or an ALG that goes beyond what is suggested for stateful translation, just supporting EPRT, like the Windows command line client does, doesn't cut it. From dthaler@microsoft.com Tue Aug 25 11:39:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CD63A6B75 for ; Tue, 25 Aug 2009 11:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZEGLEAAeINX for ; Tue, 25 Aug 2009 11:39:40 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 53F293A6B50 for ; Tue, 25 Aug 2009 11:39:37 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Aug 2009 11:39:43 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server id 14.0.621.7; Tue, 25 Aug 2009 11:39:39 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 25 Aug 2009 11:39:37 -0700 From: Dave Thaler To: Iljitsch van Beijnum , Joel Jaeggli Thread-Topic: [BEHAVE] A New Draft on FTP64 Thread-Index: AcoiWAivaOgEcli6FUqumoSnjvYixAB6NUKAAAIfmYAAMde3AAAAPryAAC4XCYAAB71pAAABENeAAA6X4MA= Date: Tue, 25 Aug 2009 18:39:08 +0000 Message-ID: References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> <4A92BE35.3010805@bogus.com> <1d38a3350908250721h183e638r25a5520833c0c78b@mail.gmail.com> <4A942774.5000500@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Behave WG Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 18:39:41 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Iljitsch van Beijnum > Sent: Tuesday, August 25, 2009 11:34 AM > To: Joel Jaeggli > Cc: Behave WG > Subject: Re: [BEHAVE] A New Draft on FTP64 > > On 25 aug 2009, at 20:03, Joel Jaeggli wrote: > > > What odds do you put on the windows xp command-line ftp client being > > changed? and that change being propagated into systems everywhere. > > That's only one example but it's an ubiquitous one. > > But to what degree does that matter? > > Browsers support FTP with EPSV and in most cases, it's possible to > install more capable FTP client. FTP clients are high on those "so I > switched to this new OS, what software do I install?" lists. > > Also note that the ftp64 draft that was adopted as a wg draft in > Stockholm requires clients to at least support PASV, or an ALG that > goes beyond what is suggested for stateful translation, just > supporting EPRT, like the Windows command line client does, doesn't > cut it. That particular client doesn't work through IPv4 NATs either. I think the FTP64 ALG only needs to work for clients that work through IPv4 NATs, but should not require any changes to clients that do. -Dave From root@core3.amsl.com Wed Aug 26 05:00:02 2009 Return-Path: X-Original-To: behave@ietf.org Delivered-To: behave@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0B4923A697D; Wed, 26 Aug 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090826120002.0B4923A697D@core3.amsl.com> Date: Wed, 26 Aug 2009 05:00:02 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-address-format-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 12:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : IPv6 Addressing of IPv4/IPv6 Translators Author(s) : C. Huitema, et al. Filename : draft-ietf-behave-address-format-00.txt Pages : 24 Date : 2009-08-26 This document discusses how an individual IPv6 address can be algorithmically translated to a corresponding IPv4 address, and vice versa, using only statically configured information. This technique is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-address-format-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-behave-address-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-08-26045055.I-D@ietf.org> --NextPart-- From Fred.L.Templin@boeing.com Wed Aug 26 08:55:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856883A70A4 for ; Wed, 26 Aug 2009 08:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOMq2nEAvKpx for ; Wed, 26 Aug 2009 08:55:08 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 5774B3A6A62 for ; Wed, 26 Aug 2009 08:55:08 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7QEukx9015617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Aug 2009 07:56:47 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7QEukfu025079; Wed, 26 Aug 2009 09:56:46 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7QEugf1024909; Wed, 26 Aug 2009 09:56:45 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 07:56:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 07:55:30 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106514D3A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] 64 MTU and fragmentation handling Thread-Index: Acohru6B5owMugkxT52ipzBcwlDRjwErWJ1Q References: From: "Templin, Fred L" To: "Iljitsch van Beijnum" , "Behave WG" X-OriginalArrivalTime: 26 Aug 2009 14:56:44.0775 (UTC) FILETIME=[6DB31F70:01CA265D] Subject: Re: [BEHAVE] 64 MTU and fragmentation handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 15:55:09 -0000 Iljitsch, > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, August 20, 2009 8:57 AM > To: Behave WG > Subject: [BEHAVE] 64 MTU and fragmentation handling >=20 > Hi, >=20 > We had a fruitful discussion about MTU and fragmentation handling in > the online interim meeting yesterday. My original options for handing > < 1280 MTUs on the IPv4 side for stateful translation: >=20 > 1. Depend on RFC 2460/2765 behavior where 1280-byte packets with a > fragment header are sent after a < 1280 "too big" message, translator > sets DF=3D0 when translating packets with a fragment header, DF=3D1 > otherwise. >=20 > The problem with this is that there is the possibility of a black hole > when the operator disables path MTU discovery on the IPv6 side by > setting the MTU to 1280 and filtering "too big" messages. That would not be correct behavior according to RFC2460; ICMP PTBs that report a size smaller than 1280 are still possible and must be handled even when a 1280 MTU is used. > In that > case, the fragment header is never included, the translator generates > a 1260-byte IPv6 packet with DF=3D1 and communication is impossible. > This requires unusual, but not unheard of cases on both the v4 and v6 > sides (< 1260 MTU, PMTUD disabled), but the problem is that in the > pure IPv4 and pure IPv6 cases these wouldn't cause trouble, it's only > when communicating through a translator that the black hole presents > itself. Whether or not the ICMPs could be lost depends a great deal on where the translator is placed. The closer it is placed to the IPv4 host, the less opportunity for lost ICMPv4 messages. =20 > Solution in the draft: >=20 > 3. Rewrite "too big" messages to provide a 1280-byte MTU and have the > translator set DF=3D0 for packets <=3D 1280 bytes and DF=3D1 for = packets > > 1280 bytes. >=20 > Alternative solution: >=20 > 2. Adopt the RFC 2460/2765 behavior, except that to avoid the black > hole, packets <=3D 1280 are sent with DF=3D0 even if there is no = fragment > header. This opens the opportunity for sustained IPv4 fragmentation at high data rates. Inclusion of the IPv6 fraghdr is the IPv6 host's way of setting DF=3D0; when the IPv6 fraghdr is not present, the IPv6 host thinks DF=3D1. Fred fred.l.templin@boeing.com =20 > Additional solution mentioned yesterday: >=20 > 4. Let the translator track path MTU sizes for IPv4 destinations and > fragment packets at the source where needed (just like normal IPv6 > hosts do for IPv6, and in our specification, the translator also does > this for packets going towards the IPv6 side). >=20 > One argument that was made yesterday was the applicability to > stateless translation. Obviously a mechanism that works for both > stateful and stateless would be better than separate mechanisms for > both. (However, note that the identification value handling needs to > be different between stateful and stateless translation regardless of > path MTU discovery handling.) >=20 > However, solutions 2 and 4 equally apply to the stateful and stateless > cases. Solution 3 is somewhat less suited for the stateless case, > because it requires the translator to come up with an identification > value. If traffic is flowing through multiple translators the > identification values could clash and result in reassembly errors. >=20 > All solutions produce fragments (except perhaps option 4 in the case > of TCP when TCP is resegmented rather than fragmented), with the > associated risk of incorrect reassemly and subsequent dependence on > the weak TCP/UDP checksum to avoid data corruption. >=20 > Option 4 has the disadvantage of creating more work for the translator > and generating more packets and bits, taking over this work from the > router in front of the < 1280 byte MTU link on the IPv4 side. >=20 > As such, I favor option 2 for both stateful and stateless translation, > and if implementers feel 4 is a viable option I would be willing to > include that as a not specifically recommended alternative. >=20 > Thoughts? > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Wed Aug 26 09:00:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B8128C1F0 for ; Wed, 26 Aug 2009 09:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9u9i3Zip3TX for ; Wed, 26 Aug 2009 09:00:11 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id F047B3A70A7 for ; Wed, 26 Aug 2009 09:00:10 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7QFbBFo018279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Aug 2009 17:37:12 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <6E7C75D1-5C33-4C67-8456-D68B700DBF47@muada.com> From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106514D3A@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 17:37:44 +0200 References: <39C363776A4E8C4A94691D2BD9D1C9A106514D3A@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.936) Cc: Behave WG Subject: Re: [BEHAVE] 64 MTU and fragmentation handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 16:00:12 -0000 On 26 aug 2009, at 16:55, Templin, Fred L wrote: >> 1. Depend on RFC 2460/2765 behavior where 1280-byte packets with a >> fragment header are sent after a < 1280 "too big" message, translator >> sets DF=0 when translating packets with a fragment header, DF=1 >> otherwise. >> The problem with this is that there is the possibility of a black >> hole >> when the operator disables path MTU discovery on the IPv6 side by >> setting the MTU to 1280 and filtering "too big" messages. > That would not be correct behavior according to RFC2460; > ICMP PTBs that report a size smaller than 1280 are still > possible and must be handled even when a 1280 MTU is used. From the RFC: It is strongly recommended that IPv6 nodes implement Path MTU Discovery [RFC-1981], in order to discover and take advantage of path MTUs greater than 1280 octets. However, a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery. Now we can argue on whether it's ok to filter incoming too bigs if you set your MTU to 1280, but regardless of who wins that argument, I believe the specification is sufficiently vague on the subject that we must assume that there will be people who adopt the interpretation that this is allowed and subsequently do this. Remember that there are many places today that set DF=1 and filter incoming too bigs for IPv4, a practice that actually breaks lots of stuff. But filter too big / MTU 1280 doesn't create any trouble when communicating with IPv6 correspondents, only when talking to IPv4 users on < 1260 MTU subnets through a translator, so it would make sense that even more people would do this. > Whether or not the ICMPs could be lost depends a great > deal on where the translator is placed. The closer it > is placed to the IPv4 host, the less opportunity for > lost ICMPv4 messages. There are many IPv4 hosts all over the place, how do we locate a single translator such that it is close to all of them? >> 2. Adopt the RFC 2460/2765 behavior, except that to avoid the black >> hole, packets <= 1280 are sent with DF=0 even if there is no fragment >> header. > This opens the opportunity for sustained IPv4 fragmentation > at high data rates. Inclusion of the IPv6 fraghdr is the > IPv6 host's way of setting DF=0; when the IPv6 fraghdr is > not present, the IPv6 host thinks DF=1. What do you mean? With a fragment header, the packet would be 1280 - 20 - 8 = 1252 bytes with DF=0. Without the fragment header, the packet would be 1280 - 20 = 1260 bytes with DF=0. Unless the MTU is 1252 - 1259 or < 630, the number of fragments is the same. From phdgang@gmail.com Wed Aug 26 09:21:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0203A6C1A for ; Wed, 26 Aug 2009 09:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=1.295, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQh-XFqBcJbH for ; Wed, 26 Aug 2009 09:21:28 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 5522A3A67C0 for ; Wed, 26 Aug 2009 09:21:28 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so65802wah.5 for ; Wed, 26 Aug 2009 09:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gRB4wE+EDUrSWVoeB0dV1QdE5WrqRFJvcyskj26HMkM=; b=qR4CNrnR0CrBMySC1W21lZFGG47CYJVeVbPpVPp8T4365WwSwDeYxbM1zuGfInCr1X SfJIiaDJfuMCPDbDhnYH8H5vgXS3LNJkP2kKpzB2tFdfCfz0joVSmJWd5IyEbvZIPpw8 8E8NVc+tVmzzycwY1zVrfaPDMXTXLSpI+vf5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jps2+RU2/gvmplbCtkX23SqCQvg5UYjxiz3edfG99k42A+M6H2DbqDQi5T8mjzzg6B Ci5FQ4i1Lqgmv3X8y+mBc1Cg9Obw5aa/ciPL6Kq2vM9kmZeeH/VM98I457kLnc4t8QS4 UwpCfC4YDLtuC2TwuUCzkpZAyID1iKi2NO3/M= MIME-Version: 1.0 Received: by 10.114.214.25 with SMTP id m25mr11205556wag.71.1251303691314; Wed, 26 Aug 2009 09:21:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2009 00:21:31 +0800 Message-ID: <36ba02b00908260921j7faa5731w8090340ccd4d2948@mail.gmail.com> From: Chen Gang To: Dave Thaler Content-Type: multipart/alternative; boundary=0016e64aef9e06e61104720dd8c9 Cc: Behave WG Subject: Re: [BEHAVE] Notes from interim conf call 8/19/2009 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 16:21:29 -0000 --0016e64aef9e06e61104720dd8c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/8/21 Dave Thaler > There was consensus that RAs were the most problematic, since they required > routers to change (unlike DNS and DHCP where servers already support new > records and options, Fred noted that routers today often cannot be > configured with arbitrary RA options), and it would require many routers > to be configured rather than a small number of DNS or DHCP servers, and > this is especially problematic when the last hop routers are in a different > network (or managed by a different organization) than the one running the > translator. > > Still there was some interest in the possibility of a generic RA option > container for DHCP options, as discussed in IntArea in IETF 74. > It was acknowledged that applications could implement a simple protocol > (RA or DHCP INFORM messages) to work around limitations in client stacks > that don't have APIs for new options. Eventually those in the meeting > got consensus to take the RA option off the table, but to keep both a > DNS and a DHCP solution in the doc. With regard to choose RA or DHCP to convey prefix information, there are some concerns that RA is more widely used approach to assign prefix information to UE comparing to DHCP in mobile network. And 3GPP take RS/RA as primary way to configure UE, since RS/RA has widely implemented in host v6 stacks. In some case, the network only support RS/RS. For example, GPRS don't support DHCPv6 but RS/RA. So, the proposed solution will extend their applicable scope when we use RS/RA. -Gang --0016e64aef9e06e61104720dd8c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/8/21 Dave Thaler <dthaler@microsoft.com>
There was consensus that RAs wer= e the most problematic, since they required
routers to change (unlike DN= S and DHCP where servers already support new
records and options, Fred noted that routers today often cannot be
confi= gured with arbitrary RA options), and it would require many routers
to b= e configured rather than a small number of DNS or DHCP servers, and
this is especially problematic when the last hop routers are in a different=
network (or managed by a different organization) than the one running t= he
translator.

Still there was some interest in the possibility o= f a generic RA option
container for DHCP options, as discussed in IntArea in IETF 74.
It was a= cknowledged that applications could implement a simple protocol
(RA or D= HCP INFORM messages) to work around limitations in client stacks
that do= n't have APIs for new options. =A0Eventually those in the meeting
got consensus to take the RA option off the table, but to keep both a
DN= S and a DHCP solution in the doc.
=A0
With regard to choose RA or DHCP to convey prefix information, there a= re some concerns that RA=A0is more widely used approach to assign prefix in= formation to UE comparing to DHCP=A0in mobile network. And 3GPP take RS/RA = as primary way to configure UE, since RS/RA=A0 has widely implemented in ho= st v6 stacks. In some case, the network only support RS/RS. For example, GP= RS don't support DHCPv6 but RS/RA. So, the proposed solution will exten= d their applicable scope when we use RS/RA.
=A0
=A0
-Gang
=A0
--0016e64aef9e06e61104720dd8c9-- From Fred.L.Templin@boeing.com Wed Aug 26 10:44:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45C7C3A67A6 for ; Wed, 26 Aug 2009 10:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlcesf1qbK4i for ; Wed, 26 Aug 2009 10:44:34 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 210B83A6452 for ; Wed, 26 Aug 2009 10:44:34 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7QHiXJc005590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Aug 2009 10:44:34 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7QHiXnj022468; Wed, 26 Aug 2009 12:44:33 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7QHiWDn022452; Wed, 26 Aug 2009 12:44:33 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 10:44:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 10:44:23 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106514F0B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <6E7C75D1-5C33-4C67-8456-D68B700DBF47@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] 64 MTU and fragmentation handling Thread-Index: AcomYzNinxlFIl+KQj+Hpl/54o2gwwAECwAA References: <39C363776A4E8C4A94691D2BD9D1C9A106514D3A@XCH-NW-7V2.nw.nos.boeing.com> <6E7C75D1-5C33-4C67-8456-D68B700DBF47@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 26 Aug 2009 17:44:25.0093 (UTC) FILETIME=[DA1DD350:01CA2674] Cc: Behave WG Subject: Re: [BEHAVE] 64 MTU and fragmentation handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 17:44:35 -0000 Iljitsch, > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, August 26, 2009 8:38 AM > To: Templin, Fred L > Cc: Behave WG > Subject: Re: [BEHAVE] 64 MTU and fragmentation handling >=20 > On 26 aug 2009, at 16:55, Templin, Fred L wrote: >=20 > >> 1. Depend on RFC 2460/2765 behavior where 1280-byte packets with a > >> fragment header are sent after a < 1280 "too big" message, translator > >> sets DF=3D0 when translating packets with a fragment header, DF=3D1 > >> otherwise. >=20 > >> The problem with this is that there is the possibility of a black > >> hole > >> when the operator disables path MTU discovery on the IPv6 side by > >> setting the MTU to 1280 and filtering "too big" messages. >=20 > > That would not be correct behavior according to RFC2460; > > ICMP PTBs that report a size smaller than 1280 are still > > possible and must be handled even when a 1280 MTU is used. >=20 > From the RFC: >=20 > It is strongly recommended that IPv6 nodes implement Path MTU > Discovery [RFC-1981], in order to discover and take advantage of > path > MTUs greater than 1280 octets. However, a minimal IPv6 > implementation (e.g., in a boot ROM) may simply restrict itself to > sending packets no larger than 1280 octets, and omit implementation > of Path MTU Discovery. >=20 > Now we can argue on whether it's ok to filter incoming too bigs if you > set your MTU to 1280, but regardless of who wins that argument, I > believe the specification is sufficiently vague on the subject that we > must assume that there will be people who adopt the interpretation > that this is allowed and subsequently do this. Remember that there are > many places today that set DF=3D1 and filter incoming too bigs for = IPv4, > a practice that actually breaks lots of stuff. But filter too big / > MTU 1280 doesn't create any trouble when communicating with IPv6 > correspondents, only when talking to IPv4 users on < 1260 MTU subnets > through a translator, so it would make sense that even more people > would do this. You can't just read half of the spec and quit there. The spec goes on to say: "In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used." This specifically says that IPv6 nodes (boot ROMs and all) need to be on the lookout for ICMPv6 PTBs reporting a size smaller than 1280, and then must insert the Fragment header in subsequent packets. This implies that the network needs to deliver (and not block) the necessary ICMPv6 PTBs. =20 > > Whether or not the ICMPs could be lost depends a great > > deal on where the translator is placed. The closer it > > is placed to the IPv4 host, the less opportunity for > > lost ICMPv4 messages. >=20 > There are many IPv4 hosts all over the place, how do we locate a > single translator such that it is close to all of them? No; not a single translator that is close to all IPv4 hosts. Rather, each IPv4 network that wish to continue to provide IPv4-only services should deploy a 6/4 translator at the edge of their network and ensure that IPv6 is enabled all the way to the edge. In this way, the servers will have incentive to move to IPv6, as they would otherwise miss out on serving a new class of clients as more and more IPv6-only clients emerge. > >> 2. Adopt the RFC 2460/2765 behavior, except that to avoid the black > >> hole, packets <=3D 1280 are sent with DF=3D0 even if there is no fragment > >> header. >=20 > > This opens the opportunity for sustained IPv4 fragmentation > > at high data rates. Inclusion of the IPv6 fraghdr is the > > IPv6 host's way of setting DF=3D0; when the IPv6 fraghdr is > > not present, the IPv6 host thinks DF=3D1. >=20 > What do you mean? With a fragment header, the packet would be 1280 - > 20 - 8 =3D 1252 bytes with DF=3D0. Without the fragment header, the = packet > would be 1280 - 20 =3D 1260 bytes with DF=3D0. Unless the MTU is 1252 = - > 1259 or < 630, the number of fragments is the same. I'm afraid I can't parse this as being responsive to what I actually said... Fred fred.l.templin@boeing.com From caozhenpku@gmail.com Wed Aug 26 11:26:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14B028C165 for ; Wed, 26 Aug 2009 11:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEs2sWVBR9AV for ; Wed, 26 Aug 2009 11:26:55 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 594A828C124 for ; Wed, 26 Aug 2009 11:26:55 -0700 (PDT) Received: by vws7 with SMTP id 7so299434vws.29 for ; Wed, 26 Aug 2009 11:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M4Eu0dpu+k8od/MT/asUrY8cKw8UI3XuCNscmpjd8eM=; b=aRxL5umtmHFzeVhBTZTyywlfkTI3C1VKVu7GUo3deiwaJLU7CsVqe1rndxCeo4rwka Jf/DJnveHF9lVdeJn0yr5rmhDZeWdJFW7+YOKBu+Km3IcKKjOJzaXV1W+CZb9+z96EJH en+rY8dCStlkX+uo8WY3R3iEw+VAVjizzBufc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SqCsYSV3sfR+XrhIdp+/VtAxIC6dQZXqrNFq69RlC9l+AvgfnQJIofprwTkNo2464S wwFPDIz56qOOs5UXgEMzadr1aKr9fzHd9X+LLdVFbbC471ckeNTm97SH1wPoozIZvOzj 4lknIiBbxE5RbqoR1CFgefnhUX8s/jqQeRTO4= MIME-Version: 1.0 Received: by 10.220.127.193 with SMTP id h1mr10991411vcs.12.1251311218925; Wed, 26 Aug 2009 11:26:58 -0700 (PDT) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106514F0B@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A106514D3A@XCH-NW-7V2.nw.nos.boeing.com> <6E7C75D1-5C33-4C67-8456-D68B700DBF47@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A106514F0B@XCH-NW-7V2.nw.nos.boeing.com> Date: Thu, 27 Aug 2009 02:26:58 +0800 Message-ID: From: Zhen Cao To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG Subject: Re: [BEHAVE] 64 MTU and fragmentation handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 18:26:56 -0000 Hi Fred, Comments in line with [zc] Thanks, Zhen On Thu, Aug 27, 2009 at 1:44 AM, Templin, Fred L wrote: > Iljitsch, > >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Wednesday, August 26, 2009 8:38 AM >> To: Templin, Fred L >> Cc: Behave WG >> Subject: Re: [BEHAVE] 64 MTU and fragmentation handling >> >> On 26 aug 2009, at 16:55, Templin, Fred L wrote: >> >> >> 1. Depend on RFC 2460/2765 behavior where 1280-byte packets with a >> >> fragment header are sent after a < 1280 "too big" message, > translator >> >> sets DF=3D0 when translating packets with a fragment header, DF=3D1 >> >> otherwise. >> >> >> The problem with this is that there is the possibility of a black >> >> hole >> >> when the operator disables path MTU discovery on the IPv6 side by >> >> setting the MTU to 1280 and filtering "too big" messages. >> >> > That would not be correct behavior according to RFC2460; >> > ICMP PTBs that report a size smaller than 1280 are still >> > possible and must be handled even when a 1280 MTU is used. >> >> =A0From the RFC: >> >> =A0 =A0 It is strongly recommended that IPv6 nodes implement Path MTU >> =A0 =A0 Discovery [RFC-1981], in order to discover and take advantage of >> path >> =A0 =A0 MTUs greater than 1280 octets. =A0However, a minimal IPv6 >> =A0 =A0 implementation (e.g., in a boot ROM) may simply restrict itself = to >> =A0 =A0 sending packets no larger than 1280 octets, and omit > implementation >> =A0 =A0 of Path MTU Discovery. >> >> Now we can argue on whether it's ok to filter incoming too bigs if you >> set your MTU to 1280, but regardless of who wins that argument, I >> believe the specification is sufficiently vague on the subject that we >> must assume that there will be people who adopt the interpretation >> that this is allowed and subsequently do this. Remember that there are >> many places today that set DF=3D1 and filter incoming too bigs for IPv4, >> a practice that actually breaks lots of stuff. But filter too big / >> MTU 1280 doesn't create any trouble when communicating with IPv6 >> correspondents, only when talking to IPv4 users on < 1260 MTU subnets >> through a translator, so it would make sense that even more people >> would do this. > > You can't just read half of the spec and quit there. The > spec goes on to say: > > =A0 "In response to an IPv6 packet that is sent to an IPv4 destination > =A0 (i.e., a packet that undergoes translation from IPv6 to IPv4), the > =A0 originating IPv6 node may receive an ICMP Packet Too Big message > =A0 reporting a Next-Hop MTU less than 1280. =A0In that case, the IPv6 no= de > =A0 is not required to reduce the size of subsequent packets to less than > =A0 1280, but must include a Fragment header in those packets so that the > =A0 IPv6-to-IPv4 translating router can obtain a suitable Identification > =A0 value to use in resulting IPv4 fragments. =A0Note that this means the > =A0 payload may have to be reduced to 1232 octets (1280 minus 40 for the > =A0 IPv6 header and 8 for the Fragment header), and smaller still if > =A0 additional extension headers are used." [zc] The specification you quote above uses "may" , but you have changed it to "must"? > > This specifically says that IPv6 nodes (boot ROMs and all) > need to be on the lookout for ICMPv6 PTBs reporting a size > smaller than 1280, and then must insert the Fragment header > in subsequent packets. This implies that the network needs > to deliver (and not block) the necessary ICMPv6 PTBs. [zc] Another fact is that the IPv4 network may not be able to return back a PTB message since it is not mandated on IPv4. In this case, the network has not PTBs to handle. > >> > Whether or not the ICMPs could be lost depends a great >> > deal on where the translator is placed. The closer it >> > is placed to the IPv4 host, the less opportunity for >> > lost ICMPv4 messages. >> >> There are many IPv4 hosts all over the place, how do we locate a >> single translator such that it is close to all of them? > > No; not a single translator that is close to all IPv4 hosts. > Rather, each IPv4 network that wish to continue to provide > IPv4-only services should deploy a 6/4 translator at the edge > of their network and ensure that IPv6 is enabled all the way > to the edge. In this way, the servers will have incentive to > move to IPv6, as they would otherwise miss out on serving a > new class of clients as more and more IPv6-only clients emerge. > >> >> 2. Adopt the RFC 2460/2765 behavior, except that to avoid the black >> >> hole, packets <=3D 1280 are sent with DF=3D0 even if there is no > fragment >> >> header. >> >> > This opens the opportunity for sustained IPv4 fragmentation >> > at high data rates. Inclusion of the IPv6 fraghdr is the >> > IPv6 host's way of setting DF=3D0; when the IPv6 fraghdr is >> > not present, the IPv6 host thinks DF=3D1. [zc] I believe the problem should be handled by the one who introduces it. Having the translator keeps everything is a more reasonable and responsible way, i.e. option. 4 as we proposed in the interim meeting. >> >> What do you mean? With a fragment header, the packet would be 1280 - >> 20 - 8 =3D 1252 bytes with DF=3D0. Without the fragment header, the pack= et >> would be 1280 - 20 =3D 1260 bytes with DF=3D0. Unless the MTU is 1252 - >> 1259 or < 630, the number of fragments is the same. > > I'm afraid I can't parse this as being responsive to what > I actually said... > > Fred > fred.l.templin@boeing.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Wed Aug 26 11:57:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A82C3A6B16 for ; Wed, 26 Aug 2009 11:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twB7icVRuIoK for ; Wed, 26 Aug 2009 11:57:10 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 578913A6BE7 for ; Wed, 26 Aug 2009 11:57:10 -0700 (PDT) Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7QIuXmK019598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Aug 2009 20:56:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106514F0B@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 20:57:05 +0200 References: <39C363776A4E8C4A94691D2BD9D1C9A106514D3A@XCH-NW-7V2.nw.nos.boeing.com> <6E7C75D1-5C33-4C67-8456-D68B700DBF47@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A106514F0B@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.936) Cc: Behave WG Subject: Re: [BEHAVE] 64 MTU and fragmentation handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 18:57:11 -0000 On 26 aug 2009, at 19:44, Templin, Fred L wrote: > You can't just read half of the spec and quit there. Like I said, we can debate that (I think you can or at least you should be able to) but wouldn't you agree that there will be some people that will do exactly this? >> There are many IPv4 hosts all over the place, how do we locate a >> single translator such that it is close to all of them? > No; not a single translator that is close to all IPv4 hosts. > Rather, each IPv4 network that wish to continue to provide > IPv4-only services should deploy a 6/4 translator at the edge > of their network and ensure that IPv6 is enabled all the way > to the edge. In this way, the servers will have incentive to > move to IPv6, as they would otherwise miss out on serving a > new class of clients as more and more IPv6-only clients emerge. I agree with that, but this is not what NAT64 is trying to solve... >>> This opens the opportunity for sustained IPv4 fragmentation >>> at high data rates. Inclusion of the IPv6 fraghdr is the >>> IPv6 host's way of setting DF=0; when the IPv6 fraghdr is >>> not present, the IPv6 host thinks DF=1. >> [...] > I'm afraid I can't parse this as being responsive to what > I actually said... Apparently we're talking about two different things. What I'm saying is that whether we adopt option 1 or 2, the number of fragments will be the same, because in both cases, the IPv6 host will generate a 1280- byte packet which is translated into an IPv4 packet with DF=0. From maxpassion@gmail.com Wed Aug 26 12:02:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DA928C527 for ; Wed, 26 Aug 2009 12:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.279 X-Spam-Level: X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[AWL=-1.464, BAYES_00=-2.599, FRT_BELOW2=2.154, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTkJ7GxIOrLw for ; Wed, 26 Aug 2009 12:02:43 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 7231C3A6D93 for ; Wed, 26 Aug 2009 12:02:29 -0700 (PDT) Received: by vws7 with SMTP id 7so322552vws.29 for ; Wed, 26 Aug 2009 12:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XDyMl/HBMTbIRfXNWHEYAr9o88vGB8ytzSvwqPhaq3I=; b=x6MqXv7Hg61aGtxpvHrHhiOz9K17LAe7zRdM/zLM0ZBKQ0KB78xPr1jtO8h51aCqrE Kc89VZIyaHRTwsVVvhe5VLq+3LF0clNwLwmWN0vyjtcSUZ9EVaLTxBIlrDeORZZhhYqb j+Ap6rs4APoPE65kzbjLv3HWDM68mPbm82p1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cz4LOo/oJB4zkyR7lX3M1IQL3765Uog7T5nDofmz9XH9OrnF+DOefxFjhllgYEq50D 8YTNqU2A8qTTpGFlaLFdodHkideXifHptUh+txxp1RyyNM6tZnVTL9ga0JgLu2R73a60 PbwgDn5WnsFTS46dShNWTIsA+lSzKU6BE9xaw= MIME-Version: 1.0 Received: by 10.220.89.205 with SMTP id f13mr11101238vcm.23.1251313353012; Wed, 26 Aug 2009 12:02:33 -0700 (PDT) In-Reply-To: <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> Date: Thu, 27 Aug 2009 03:02:31 +0800 Message-ID: <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> From: liu dapeng To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 19:02:44 -0000 2009/8/25, Iljitsch van Beijnum : > On 24 aug 2009, at 19:40, liu dapeng wrote: > >> We upgrade the ftp64 draft, add some text considering the legacy FTP >> implementation and other clarification as well. Any comments are >> welcomed. > > Can you please send the new text to the list? we upgrade setion 3 and 5, bellow is the text. 3. Client considerations It is required that all IPv6 FTP clients MUST support both EPSV and PASV command. When the client tries to connect to a server using IPv6 connection, it should use EPSV command first. If the server response that it does not support this command or encounters an error, it MUST retry with PASV command. The server will respond to PASV command with an message that contains an IPv4 address and port number that used for the client to connect to. The client MUST ignores the IPv4 address provided in the response; it should use the control connection's IP address to connect to the server to establish the data connection. This approach could not only simply the FTP client software's implementation but also can avoid the problems caused by using the IPv4 address that included in the response message. For example, if the FTP client has a private IPv4 connection and a public IPv6 connection, if it tries to use the IPv4 connection to establish data connection with the server, it will never success. 5. FTP ALG considerations 5.1. FTP ALG limitations Implementing FTP ALG in the translation box may have some limitations, such as: 1) FTP ALG may case to increase the complexity of translation box, since FTP ALG needs to understand FTP protocol and translate the application layer payload and update the header of FTP control packets. Dapeng Liu Expires February 27, 2010 [Page 4] =0C Internet-Draft IPv6 IPv4 translation FTP considerations August 2009 2) For most of current Network Processor based translation box, ALG processing may cause its performance decreased significantly. The reason is that FTP ALG processing can not take the advantage of Network Processor, which is designed and optimized for processing regular packets (such as header translation). 3) From the evolution perspective, if the network continues to provide support of FTP ALG all the time, the users will have no motivation to upgrade their FTP client software. If things evolve toward this direction, the ALG function of the translation box will become more and more complex. In reality, upgrading FTP client software is a more easy way to solve the ALG issue compared with requiring that all the translation box to implement FTP ALG. 5.2. Solution to avoid FTP ALG This document suggests that the translation box which situated between the IPv6 network and IPv4 network should not implement FTP ALG. It is depend on the client and server that comply with this specification to avoid the FTP ALG issue. The reason that this document does not encourage translation box to implement FTP ALG is that since the FTP ALG problem can be totally avoid by defining the behavior of the client and server, it is not necessary to implement it at all. This approach can reduce the translation box's complexity. Also, the FTP client and server's communication without ALG will significantly improve its performance. For the legacy IPv6 FTP client, this document suggests that the legacy client should behave like RFC1579 recommendation which is that "vendors convert their FTP clients programs to use PASV instead of PORT". For IPv6 FTP client, this recommendation should be "the users or vendors should convert their FTP clients programs to use EPSV instead of EPRT". This can be done by configuration and do not require upgrading of the client software for most of current IPv6 FTP client. This solution may require that the FTP server should support EPSV command. > A client that implements the client requirements and client > recommendations listed in draft-van-beijnum-behave-ftp64-05 will be > able to successfully interoperate with any server that implements EPSV > or PASV through a stateful or stateless translator. The solution in draft-van-beijnum-behave-ftp64-05 suggests that "However, the server will respond to the PASV command with an IPv4 address that the client must use to connect to for the data connection. If the client has IPv4 reachability, it SHOULD set up a data connection towards the IPv4 address." this may can not work in some cases, as draft-liu-behave-ftp64-02 mentioned:'" For example, if the FTP client has a private IPv4 connection and a public IPv6 connection, if it tries to use the IPv4 connection to establish data connection with the server, it will never success." Since updating an > FTP client is about the easiest possible upgrade that we could > possibly require (an FTP client doesn't need special privileges and > can run as a java applet in a browser) this provides a workable > solution for most users. aggree, this is what draft-liu-behave-ftp64-02 suggested. > However, there is additional benefit in making FTP through a > translator work for users with existing implementations, which can be > accomplished by either server upgrades or an ALG. Do not you think that server upgrading may be more reasonable from the evolution perspective? if the network contitue to provide ALG all the time, the server will never has motivation to upgrade, this will cause the ALGs in the translation box become more and more complex, since the translator will try to maintain ALGs for all the legacy implementations; and the legacy implementation never think about upgrading because they never aware the needs to upgrade. this approach may be convenient for a little part of the users but is harmful for the evolution of the network. > Since at least one vendor has expressed interest in implementing such > an ALG, having standard ALG functionality is better than undefined ALG > functionality and we have the text now anyway, in my opinion it > doesn't make sense to remove the ALG text, although I'm willing to > make it (even) more clear that such an ALG is optional. In my personal opioion, If the we do not recommend to implement FTP ALG, maybe we should not include any text to describe how to implement it for not misleading the reader. but maybe the text of ALG could be adjusted as an appendix, then there will be no contradiction. > From Fred.L.Templin@boeing.com Wed Aug 26 12:08:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A563A6EEB for ; Wed, 26 Aug 2009 12:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlrG9PpjmtJl for ; Wed, 26 Aug 2009 12:08:39 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D62103A6C9B for ; Wed, 26 Aug 2009 12:08:37 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n7QJ8XNK007930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Aug 2009 14:08:33 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n7QJ8XSs013260; Wed, 26 Aug 2009 14:08:33 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n7QJ8ERt012505; Wed, 26 Aug 2009 14:08:33 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:08:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Aug 2009 12:08:26 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A106555037@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] 64 MTU and fragmentation handling Thread-Index: AcomevV+m8bl6tU5R+eIqpTdf7SOFgABSuuA References: <39C363776A4E8C4A94691D2BD9D1C9A106514D3A@XCH-NW-7V2.nw.nos.boeing.com><6E7C75D1-5C33-4C67-8456-D68B700DBF47@muada.com><39C363776A4E8C4A94691D2BD9D1C9A106514F0B@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Zhen Cao" X-OriginalArrivalTime: 26 Aug 2009 19:08:26.0732 (UTC) FILETIME=[972AE2C0:01CA2680] Cc: Behave WG Subject: Re: [BEHAVE] 64 MTU and fragmentation handling X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 19:08:40 -0000 > > You can't just read half of the spec and quit there. The > > spec goes on to say: > > > > =A0 "In response to an IPv6 packet that is sent to an IPv4 = destination > > =A0 (i.e., a packet that undergoes translation from IPv6 to IPv4), = the > > =A0 originating IPv6 node may receive an ICMP Packet Too Big message > > =A0 reporting a Next-Hop MTU less than 1280. =A0In that case, the = IPv6 node > > =A0 is not required to reduce the size of subsequent packets to less = than > > =A0 1280, but must include a Fragment header in those packets so = that the > > =A0 IPv6-to-IPv4 translating router can obtain a suitable = Identification > > =A0 value to use in resulting IPv4 fragments. =A0Note that this = means the > > =A0 payload may have to be reduced to 1232 octets (1280 minus 40 for = the > > =A0 IPv6 header and 8 for the Fragment header), and smaller still if > > =A0 additional extension headers are used." >=20 > [zc] The specification you quote above uses "may" , but you have > changed it to "must"? I didn't change anything; the text above is cut-and-paste directly out of RFC2460, Section 5. Fred fred.l.templin@boeing.com From maxpassion@gmail.com Wed Aug 26 12:10:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8193A6C9B for ; Wed, 26 Aug 2009 12:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxTspjpMF-UR for ; Wed, 26 Aug 2009 12:10:33 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 9C0AE3A6853 for ; Wed, 26 Aug 2009 12:10:33 -0700 (PDT) Received: by vws7 with SMTP id 7so327642vws.29 for ; Wed, 26 Aug 2009 12:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=znd/bbqzUu5VxNRswjb9gmzIZ03peg4LvTsHyKUc+rM=; b=SWiAqqowduiIDQh5aWM/uF0UmBWmj95uVQrOV7sTx6bzQ+zAvz5o7Za1KRRYPD9ihS Ksxr6sKYyyPFVFPtsdplFcpnpXxJjVXYMX0cT/FLkV4yszOu6akteH80vF/nwwyiIRt9 re/LQelhvlPwxgrTkJnXswl/RFwnetRwimlxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CNyHvXbsRgp1GCbFW2HGt8WRNKg97xKHesiUwtg00om5apy9pR8QwenwyfBF/0D/M3 NiFAx5PUpuepVatRf1PdNy6wqXpod7da8TWx7W2UvGk2XlPxDxFwJ8ys+d9qDqEghghh W0J9Ue2D0qRQbnP0uuofHzbbZajTW/00X8ynA= MIME-Version: 1.0 Received: by 10.220.89.205 with SMTP id f13mr11115472vcm.23.1251313824453; Wed, 26 Aug 2009 12:10:24 -0700 (PDT) In-Reply-To: <4A942774.5000500@bogus.com> References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> <4A92BE35.3010805@bogus.com> <1d38a3350908250721h183e638r25a5520833c0c78b@mail.gmail.com> <4A942774.5000500@bogus.com> Date: Thu, 27 Aug 2009 03:10:24 +0800 Message-ID: <25e1aaa40908261210q266c32dewcc04792c78dd753c@mail.gmail.com> From: liu dapeng To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Hui Deng , shengjiang@huawei.com, behave@ietf.org, Jacni Qin , bo zhou , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 19:10:34 -0000 2009/8/26, Joel Jaeggli : > > > Hui Deng wrote: >>> You can write whatever you want, it won't change the deployed code. >> How many people really use FTP6 today? > > How long has your host stack and many of the included applications > supported ipv6? 6 years? longer maybe? > > What odds do you put on the windows xp command-line ftp client being > changed? and that change being propagated into systems everywhere. > That's only one example but it's an ubiquitous one. command line users can use the EPSV command to change to pasive mode if the server support this command. besides, most of ordinary users may use GUI based ftp client programs which maybe easily to upgrade (numberless softwares support online upgrading) > The point is legacy applications don't change, if they did v4 to v6 > migration would be a lot simpler in the first place. > >> -Hui >> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> > From maxpassion@gmail.com Wed Aug 26 12:29:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520EC3A7030 for ; Wed, 26 Aug 2009 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNS0HedWysHi for ; Wed, 26 Aug 2009 12:29:32 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 458443A6D40 for ; Wed, 26 Aug 2009 12:29:32 -0700 (PDT) Received: by vws7 with SMTP id 7so339754vws.29 for ; Wed, 26 Aug 2009 12:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S4WuRWm8F+rpuPd2tVgHJklaZr6wolvRhOhX0cmb7wk=; b=HHCegY70OxAbwCd0m+pd7IzZxKVR4sm2vOfPTM4IKtciP05tNr/7QVNN8QaK2AB3C0 gANN6pITusUES4DF3m2JzTRHccFO+fp1bztgUsQU7ug+8yULUOnNU1vkJeZ2pEcG1qd7 WELvrY6p3ZHHkSMJtge7wFtCJhr0zgrvxPaVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kaCxnnB+hfnU2SCDPIRiFkv6hB3T8gUQinoWCMLjQfqN4BrGYr8kEBHvcbbP8wn2ir jPKoyrMUKCDA9+x370P8Te4cqBr0vZ3Hp8qSfc/9W8O+fSnKGaqphI2memXZqNNDH/zF 42KY6MgCZKyeGXlQ1Ks74Buz5E0nmm2O5j7yo= MIME-Version: 1.0 Received: by 10.220.18.78 with SMTP id v14mr11142668vca.102.1251314958533; Wed, 26 Aug 2009 12:29:18 -0700 (PDT) In-Reply-To: <4A8BE278.2030505@viagenie.ca> References: <4A72F0BF.4000609@viagenie.ca> <25e1aaa40908121019o582694f1u79256876bfad4104@mail.gmail.com> <4A8BE278.2030505@viagenie.ca> Date: Thu, 27 Aug 2009 03:29:18 +0800 Message-ID: <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> From: liu dapeng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 19:29:33 -0000 2009/8/19, Simon Perreault : > Le 2009-08-12 13:19, liu dapeng a =E9crit : >> Why the DNS64 synthesize AAAA records for upstream DNS servers? >> >> Since DNS64 has both IPv4 and IPv6 address, why not use its IPv4 >> interface to send the recurse query to the upstream DNS if the >> upstream DNS has an IPv4 address? > > This case is explained here: > >>> Note: If the DNS64 has a usable IPv4 connection, it is expected >>> that the directive will be set to false. > > Note that "IPv4 address" does not equate "usable IPv4 connection". You > need static configuration to differentiate between the two. It is the > network administrator's job to decide. DNS64 should has an IPv4 connection in my opinion, since RFC 3901 recommends that it should be avoid to deploy IPv6 only DNS since this approach may cost many issues. > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > From simon.perreault@viagenie.ca Wed Aug 26 12:37:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E8C3A67B1 for ; Wed, 26 Aug 2009 12:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rycha33S2xYd for ; Wed, 26 Aug 2009 12:37:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4DC9C3A6C17 for ; Wed, 26 Aug 2009 12:37:05 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id DAF5629E1604; Wed, 26 Aug 2009 15:37:09 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id D1E9429E15CE; Wed, 26 Aug 2009 15:37:09 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: liu dapeng Date: Wed, 26 Aug 2009 15:37:03 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <4A72F0BF.4000609@viagenie.ca> <4A8BE278.2030505@viagenie.ca> <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> In-Reply-To: <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908261537.04193.simon.perreault@viagenie.ca> Cc: Behave WG Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 19:37:07 -0000 On Wednesday 26 August 2009 15:29:18 liu dapeng wrote: > DNS64 should has an IPv4 connection in my opinion, since RFC 3901 > recommends that it should be avoid to deploy IPv6 only DNS since this > approach may cost many issues. The relevant passage from RFC 3901 is the following: - every recursive name server SHOULD be either IPv4-only or dual stack, This rules out IPv6-only recursive servers. However, one might design configurations where a chain of IPv6-only name server forward queries to a set of dual stack recursive name server actually performing those recursive queries. I can imagine useful and potentially common cases where a DNS64 would not have an IPv4 connection and would "forward queries to a set of dual stack recursive name server actually performing those recursive queries" through the NAT64. For example, when the RTT between the dual stack recursive name server and the IPv6 hosts is long, you might want to provide a local cache. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Wed Aug 26 12:45:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C9128C390 for ; Wed, 26 Aug 2009 12:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IbKdaSdmuIL for ; Wed, 26 Aug 2009 12:45:36 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 54F7F28C3BA for ; Wed, 26 Aug 2009 12:45:35 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 608DA29E1604; Wed, 26 Aug 2009 15:45:39 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 57F7329E15CE; Wed, 26 Aug 2009 15:45:39 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Wed, 26 Aug 2009 15:45:38 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <4A72F0BF.4000609@viagenie.ca> <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> <200908261537.04193.simon.perreault@viagenie.ca> In-Reply-To: <200908261537.04193.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908261545.38915.simon.perreault@viagenie.ca> Cc: liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 19:45:36 -0000 On Wednesday 26 August 2009 15:37:03 Simon Perreault wrote: > I can imagine useful and potentially common cases where a DNS64 would not > have an IPv4 connection and would "forward queries to a set of dual stack > recursive name server actually performing those recursive queries" through > the NAT64. Actually, here's an even more potentially common case: you have only one IPv4 address, and it's assigned to the NAT64. I wouldn't want to be running NAT44 in parallel with NAT64 on the same IPv4 address just for the DNS64. Better to use NAT64 for everything. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Wed Aug 26 13:23:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB4F328C26D for ; Wed, 26 Aug 2009 13:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQP7tGLMvjaZ for ; Wed, 26 Aug 2009 13:23:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id E378628C56F for ; Wed, 26 Aug 2009 13:23:07 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id AC80B29E1606; Wed, 26 Aug 2009 16:23:11 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id A457729E15FE; Wed, 26 Aug 2009 16:23:11 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Wed, 26 Aug 2009 16:23:08 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <4A72F0BF.4000609@viagenie.ca> <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> <200908261537.04193.simon.perreault@viagenie.ca> In-Reply-To: <200908261537.04193.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908261623.08240.simon.perreault@viagenie.ca> Cc: liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 20:23:33 -0000 On Wednesday 26 August 2009 15:37:03 Simon Perreault wrote: > For example, when the RTT between the dual stack recursive name > server and the IPv6 hosts is long, you might want to provide a local cache. This doesn't make any sense in this context. Please ignore. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From iljitsch@muada.com Wed Aug 26 13:58:31 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA383A6A8B for ; Wed, 26 Aug 2009 13:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWm--LwtS0CI for ; Wed, 26 Aug 2009 13:58:30 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 111253A69AA for ; Wed, 26 Aug 2009 13:57:39 -0700 (PDT) Received: from [192.168.0.193] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7QKv4Hq020467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Aug 2009 22:57:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> From: Iljitsch van Beijnum To: liu dapeng In-Reply-To: <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 22:57:37 +0200 References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 20:58:31 -0000 On 26 aug 2009, at 21:02, liu dapeng wrote: >> However, there is additional benefit in making FTP through a >> translator work for users with existing implementations, which can be >> accomplished by either server upgrades or an ALG. > Do not you think that server upgrading may be more reasonable from the > evolution perspective? No. Many clients use EPSV today, and a good number of servers don't work with those clients. Apparently the people that run these servers don't care. > if the network contitue to provide ALG all the > time, the server will never has motivation to upgrade, I'm afraid the opposite will happen, and people will stay away from NAT64 because "it doesn't work". Waiting for IPv4 users to update their stuff isn't the best strategy. > In my personal opioion, If the we do not recommend to implement FTP > ALG, maybe we should not include any text to describe how to implement > it for not misleading the reader. but maybe the text of ALG could be > adjusted as an appendix, then there will be no contradiction. Does anyone else favor putting the ALG description in an appendix? From rpenno@juniper.net Wed Aug 26 14:27:11 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1A33A6EA6 for ; Wed, 26 Aug 2009 14:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhZ2y2EOyCBw for ; Wed, 26 Aug 2009 14:27:10 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 5223B3A6BFB for ; Wed, 26 Aug 2009 14:27:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSpWosa754ZuZOmJbS37iWgmFiREtuudk@postini.com; Wed, 26 Aug 2009 14:27:17 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 26 Aug 2009 14:25:56 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 26 Aug 2009 17:25:55 -0400 From: Reinaldo Penno To: Iljitsch van Beijnum , liu dapeng Date: Wed, 26 Aug 2009 17:25:54 -0400 Thread-Topic: [BEHAVE] A New Draft on FTP64 Thread-Index: Acomj/90gKp+InTbSVKX2R28TTQ5jgAA8t4c Message-ID: In-Reply-To: <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 21:27:11 -0000 What is the purpose of this document? Is it to make current FTP6 clients work with current FTP4 servers? Or is it to give guidance to future FTP6 an= d FTP4 implementations? The problem at hand as I understand it is to make current clients and servers (that already work through FTP NAT44) to work through FTP NAT64 without change. If that is the case then ALG part is crucial. If the purpose is to guide future implementations although it has merit it does not help the problem at hand. If this turns out into one of those dogmatic discussions that NAT and ALGs are evil and the IETF does not provide a document specifying how FTP64 ALG should work, people are going to develop without guidance (once more). Hopefully we can reach some consensus on the purpose and scope of the document. Thanks, Reinaldo On 8/26/09 1:57 PM, "Iljitsch van Beijnum" wrote: > On 26 aug 2009, at 21:02, liu dapeng wrote: >=20 >>> However, there is additional benefit in making FTP through a >>> translator work for users with existing implementations, which can be >>> accomplished by either server upgrades or an ALG. >=20 >> Do not you think that server upgrading may be more reasonable from the >> evolution perspective? >=20 > No. Many clients use EPSV today, and a good number of servers don't > work with those clients. Apparently the people that run these servers > don't care. >=20 >> if the network contitue to provide ALG all the >> time, the server will never has motivation to upgrade, >=20 > I'm afraid the opposite will happen, and people will stay away from > NAT64 because "it doesn't work". Waiting for IPv4 users to update > their stuff isn't the best strategy. >=20 >> In my personal opioion, If the we do not recommend to implement FTP >> ALG, maybe we should not include any text to describe how to implement >> it for not misleading the reader. but maybe the text of ALG could be >> adjusted as an appendix, then there will be no contradiction. >=20 > Does anyone else favor putting the ALG description in an appendix? > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Wed Aug 26 15:50:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D3D3A6C2C for ; Wed, 26 Aug 2009 15:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4+5qRIyVhQT for ; Wed, 26 Aug 2009 15:50:28 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D1D893A6A1B for ; Wed, 26 Aug 2009 15:50:28 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 26 Aug 2009 15:50:35 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.13; Wed, 26 Aug 2009 14:54:58 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 26 Aug 2009 14:54:41 -0700 From: Dave Thaler To: Iljitsch van Beijnum Thread-Topic: [BEHAVE] A New Draft on FTP64 Thread-Index: AQHKIZ6aaOgEcli6FUqumoSnjvYixJC19feAgAAq8ACAAxC6gIAAICmA//+aZdA= Date: Wed, 26 Aug 2009 21:54:30 +0000 Message-ID: References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> In-Reply-To: <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2009 22:50:29 -0000 > > In my personal opioion, If the we do not recommend to implement FTP > > ALG, maybe we should not include any text to describe how to > implement > > it for not misleading the reader. but maybe the text of ALG could be > > adjusted as an appendix, then there will be no contradiction. > > Does anyone else favor putting the ALG description in an appendix? My personal opinion is that I think the FTP64 document should remain structured essentially as it is now. -Dave From dwing@cisco.com Wed Aug 26 18:11:51 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23D93A6778 for ; Wed, 26 Aug 2009 18:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.707 X-Spam-Level: X-Spam-Status: No, score=-4.707 tagged_above=-999 required=5 tests=[AWL=-1.892, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw5uO8LyZN-P for ; Wed, 26 Aug 2009 18:11:50 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7034A3A68A2 for ; Wed, 26 Aug 2009 18:11:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEALd6lUqrR7PD/2dsb2JhbACLFrRaiDmQEgWEGoFY X-IronPort-AV: E=Sophos;i="4.44,282,1249257600"; d="scan'208";a="199318760" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2009 01:11:56 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7R1BuR3025957; Wed, 26 Aug 2009 18:11:56 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7R1BthF024149; Thu, 27 Aug 2009 01:11:56 GMT From: "Dan Wing" To: "'liu dapeng'" References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com><25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com><59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> Date: Wed, 26 Aug 2009 18:11:52 -0700 Message-ID: <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> Thread-Index: AcomgBfFpWNO34w2ShS/gBiX0yR52QAMqyFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8251; t=1251335516; x=1252199516; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=W5OYE6M+FcVdiM/v5mCokCH/SfHUfgZzoLe0qju1Ozg=; b=uoTYlC/kA/svE/aayQydZGv+4NONv1z3w+2Uw4f4wA4eNnbzIGSp52UfBx dVnSU/5AmVWvDl82fl/MiZjJZSTWEsSL512aXX+WJnPzseDZYlw7t32TSjl4 4h/ZGyU9dQ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 01:11:51 -0000 =20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of liu dapeng > Sent: Wednesday, August 26, 2009 12:03 PM > To: Iljitsch van Beijnum > Cc: behave@ietf.org > Subject: Re: [BEHAVE] A New Draft on FTP64 >=20 > 2009/8/25, Iljitsch van Beijnum : > > On 24 aug 2009, at 19:40, liu dapeng wrote: > > > >> We upgrade the ftp64 draft, add some text considering the=20 > legacy FTP > >> implementation and other clarification as well. Any comments are > >> welcomed. > > > > Can you please send the new text to the list? >=20 > we upgrade setion 3 and 5, bellow is the text. >=20 > 3. Client considerations >=20 > It is required that all IPv6 FTP clients MUST support both EPSV and > PASV command. >=20 > When the client tries to connect to a server using IPv6 connection, > it should use EPSV command first. If the server response=20 > that it does > not support this command or encounters an error, it MUST retry with > PASV command. That algorithm will cause a timeout -- not an error -- with some FTP servers. For example, ftp.dell.com responds positively to EPSV but does not actually allow connecting to the port indicated on the FTP control channel. Other sites, such as ftp.microsoft.com, work just fine with EPSV. Would it be better to just try PASV first (and for the data channel, the FTP client should use the IP address of the control channel,=20 ignoring what is in the PASV response) and if *that* fails it means the FTP server is really listening on IPv6 and refuses to use PASV and wants EPSV, so you only use EPSV after PASV returns an error? -d > The server will respond to PASV command with=20 > an message > that contains an IPv4 address and port number that used for the > client to connect to. The client MUST ignores the IPv4 address > provided in the response; it should use the control connection's IP > address to connect to the server to establish the data connection. >=20 > This approach could not only simply the FTP client software's > implementation but also can avoid the problems caused by using the > IPv4 address that included in the response message. For example, if > the FTP client has a private IPv4 connection and a public IPv6 > connection, if it tries to use the IPv4 connection to=20 > establish data > connection with the server, it will never success. >=20 >=20 > 5. FTP ALG considerations >=20 > 5.1. FTP ALG limitations >=20 > Implementing FTP ALG in the translation box may have some=20 > limitations, > such as: >=20 > 1) FTP ALG may case to increase the complexity of translation box, > since FTP ALG needs to understand FTP protocol and translate the > application layer payload and update the header of FTP control > packets. >=20 >=20 > Dapeng Liu Expires February 27, 2010 [Page 4] > =0C>=20 > Internet-Draft IPv6 IPv4 translation FTP considerations August 2009 >=20 >=20 > 2) For most of current Network Processor based translation box, ALG > processing may cause its performance decreased=20 > significantly. The > reason is that FTP ALG processing can not take the advantage of > Network Processor, which is designed and optimized for=20 > processing > regular packets (such as header translation). >=20 > 3) From the evolution perspective, if the network continues to > provide support of FTP ALG all the time, the users will have no > motivation to upgrade their FTP client software. If=20 > things evolve > toward this direction, the ALG function of the translation box > will become more and more complex. In reality, upgrading FTP > client software is a more easy way to solve the ALG issue > compared with requiring that all the translation box to=20 > implement > FTP ALG. >=20 > 5.2. Solution to avoid FTP ALG >=20 > This document suggests that the translation box which situated > between the IPv6 network and IPv4 network should not implement FTP > ALG. It is depend on the client and server that comply with this > specification to avoid the FTP ALG issue. >=20 > The reason that this document does not encourage translation box to > implement FTP ALG is that since the FTP ALG problem can be totally > avoid by defining the behavior of the client and server, it is not > necessary to implement it at all. This approach can reduce the > translation box's complexity. Also, the FTP client and server's > communication without ALG will significantly improve its=20 > performance. >=20 > For the legacy IPv6 FTP client, this document suggests that the > legacy client should behave like RFC1579 recommendation=20 > which is that > "vendors convert their FTP clients programs to use PASV instead of > PORT". For IPv6 FTP client, this recommendation should be=20 > "the users > or vendors should convert their FTP clients programs to use EPSV > instead of EPRT". This can be done by configuration and do not > require upgrading of the client software for most of=20 > current IPv6 FTP > client. This solution may require that the FTP server=20 > should support > EPSV command. >=20 >=20 > > A client that implements the client requirements and client > > recommendations listed in draft-van-beijnum-behave-ftp64-05 will be > > able to successfully interoperate with any server that=20 > implements EPSV > > or PASV through a stateful or stateless translator. >=20 > The solution in draft-van-beijnum-behave-ftp64-05 suggests that > "However, the server will respond to the PASV command with an IPv4 > address that the client must use to connect to for the data > connection. If the client has IPv4 reachability, it SHOULD set up a > data connection towards the IPv4 address." this may can not work in > some cases, as draft-liu-behave-ftp64-02 mentioned:'" For example, > if the FTP client has a private IPv4 connection and a public IPv6 > connection, if it tries to use the IPv4 connection to establish data > connection with the server, it will never success." >=20 >=20 > Since updating an > > FTP client is about the easiest possible upgrade that we could > > possibly require (an FTP client doesn't need special privileges and > > can run as a java applet in a browser) this provides a workable > > solution for most users. >=20 > aggree, this is what draft-liu-behave-ftp64-02 suggested. >=20 > > However, there is additional benefit in making FTP through a > > translator work for users with existing implementations,=20 > which can be > > accomplished by either server upgrades or an ALG. >=20 > Do not you think that server upgrading may be more reasonable from the > evolution perspective? if the network contitue to provide ALG all the > time, the server will never has motivation to upgrade, this will cause > the ALGs in the translation box become more and more complex, since > the translator will try to maintain ALGs for all the legacy > implementations; and the legacy implementation never think about > upgrading because they never aware the needs to upgrade. this approach > may be convenient for a little part of the users but is harmful for > the evolution of the network. >=20 > > Since at least one vendor has expressed interest in=20 > implementing such > > an ALG, having standard ALG functionality is better than=20 > undefined ALG > > functionality and we have the text now anyway, in my opinion it > > doesn't make sense to remove the ALG text, although I'm willing to > > make it (even) more clear that such an ALG is optional. >=20 > In my personal opioion, If the we do not recommend to implement FTP > ALG, maybe we should not include any text to describe how to implement > it for not misleading the reader. but maybe the text of ALG could be > adjusted as an appendix, then there will be no contradiction. > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Aug 26 18:22:19 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1883A6972 for ; Wed, 26 Aug 2009 18:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.653 X-Spam-Level: X-Spam-Status: No, score=-5.653 tagged_above=-999 required=5 tests=[AWL=0.946, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRZk9peM1Rxu for ; Wed, 26 Aug 2009 18:22:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 14DDC3A6452 for ; Wed, 26 Aug 2009 18:22:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEANN8lUqrR7PD/2dsb2JhbACLFrRgiDmQDAWEGoFY X-IronPort-AV: E=Sophos;i="4.44,282,1249257600"; d="scan'208";a="233648431" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Aug 2009 01:22:24 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7R1MOa6004993; Wed, 26 Aug 2009 18:22:24 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n7R1MOF5020146; Thu, 27 Aug 2009 01:22:24 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Iljitsch van Beijnum'" , "'liu dapeng'" References: <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> Date: Wed, 26 Aug 2009 18:22:24 -0700 Message-ID: <002701ca26b4$d5154470$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acomj/90gKp+InTbSVKX2R28TTQ5jgAA8t4cAAf1wKA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3569; t=1251336144; x=1252200144; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=M0Z3EQe2NkJD76FZKNWrDFpfxPQwnW79as/c/j5ZjAU=; b=Pc6Zdqtx2u6j6Z+gQO28L022wuKTHUERjwuxIrzQSQXS7WO58aAKWOG/zt RVRpy5510Z2ZOK6hqALwOcNDd4E4IQkGv6hq2NkfqhIUfUlSMR2Z7dSYLuFG /BcpxpWiRg; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 01:22:19 -0000 > What is the purpose of this document? Is it to make current > FTP6 clients work with current FTP4 servers? Or is it to give > guidance to future FTP6 and FTP4 implementations? There are two FTP64-related documents. I'm not sure which one you are referring to when you say 'this document': * draft-van-beijnum-behave-ftp64-05.txt This document describes how existing IPv6 FTP clients and existing IPv4 FTP servers function, and explains how an FTP ALG is useful if a NAT64 operator wants those existing FTP clients and FTP servers to work through a 6/4 translator. This document was accepted in Stockholm as a WG document. I am very close to sending a request to the mailing list to adopt it as a WG document, but I am waiting for our new charter (and the FTP-related milestone in it) to be accepted by IESG. * draft-liu-behave-ftp64-01.txt describes how IPv6 FTP clients can be changed to function across a NAT64, so that the NAT64 doesn't need to have an FTP ALG. This document is probably most appropriate in the applications area as it describes a change in how the FTP applications are supposed to work when operating across a translator. -d > The problem at hand as I understand it is to make current clients and > servers (that already work through FTP NAT44) to work through > FTP NAT64 without change. If that is the case then ALG part > is crucial. > > If the purpose is to guide future implementations although it > has merit it > does not help the problem at hand. > > If this turns out into one of those dogmatic discussions that > NAT and ALGs > are evil and the IETF does not provide a document specifying > how FTP64 ALG > should work, people are going to develop without guidance (once more). > > Hopefully we can reach some consensus on the purpose and scope of the > document. > > Thanks, > > Reinaldo > > > > > > On 8/26/09 1:57 PM, "Iljitsch van Beijnum" wrote: > > > On 26 aug 2009, at 21:02, liu dapeng wrote: > > > >>> However, there is additional benefit in making FTP through a > >>> translator work for users with existing implementations, > which can be > >>> accomplished by either server upgrades or an ALG. > > > >> Do not you think that server upgrading may be more > reasonable from the > >> evolution perspective? > > > > No. Many clients use EPSV today, and a good number of servers don't > > work with those clients. Apparently the people that run > these servers > > don't care. > > > >> if the network contitue to provide ALG all the > >> time, the server will never has motivation to upgrade, > > > > I'm afraid the opposite will happen, and people will stay away from > > NAT64 because "it doesn't work". Waiting for IPv4 users to update > > their stuff isn't the best strategy. > > > >> In my personal opioion, If the we do not recommend to implement FTP > >> ALG, maybe we should not include any text to describe how > to implement > >> it for not misleading the reader. but maybe the text of > ALG could be > >> adjusted as an appendix, then there will be no contradiction. > > > > Does anyone else favor putting the ALG description in an appendix? > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed Aug 26 18:31:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C25928C228 for ; Wed, 26 Aug 2009 18:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.968 X-Spam-Level: X-Spam-Status: No, score=-5.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyZEBEfoXoo6 for ; Wed, 26 Aug 2009 18:31:19 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8BD0328C18C for ; Wed, 26 Aug 2009 18:31:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAO9+lUqrR7MV/2dsb2JhbACLFrRUiDmQCgWEGoFY X-IronPort-AV: E=Sophos;i="4.44,282,1249257600"; d="scan'208";a="41464304" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 27 Aug 2009 01:31:26 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n7R1VLcb004750; Wed, 26 Aug 2009 18:31:21 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7R1VKCL028769; Thu, 27 Aug 2009 01:31:20 GMT From: "Dan Wing" To: "'Dave Thaler'" , "'Iljitsch van Beijnum'" References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com><25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com><59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com><25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com><30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> Date: Wed, 26 Aug 2009 18:31:20 -0700 Message-ID: <003201ca26b6$149f2d80$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AQHKIZ6aaOgEcli6FUqumoSnjvYixJC19feAgAAq8ACAAxC6gIAAICmA//+aZdCAADhEMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=545; t=1251336681; x=1252200681; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=Gd9bPt26nUgcsMxYDmisLUWJ2Am8wVLcnH4DAYQbZGs=; b=CDWZW5Zy0Z23qyEoGIs1Uxe7IiCof8DefiTP5eDIGT65R7hGpfIOvfPMIH s8wr+xFVsvut0YdWiqQGRCjBAZo3ZvAade8Hhd01/LT8qgz4kPrBmm7lNo8o e3EwWc9zs3Y9P7p9epUitMqrxiS22J8Txkl8ebndYu5hvdFx+fjUU=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 01:31:20 -0000 > > > In my personal opioion, If the we do not recommend to > implement FTP > > > ALG, maybe we should not include any text to describe how to > > implement > > > it for not misleading the reader. but maybe the text of > ALG could be > > > adjusted as an appendix, then there will be no contradiction. > > > > Does anyone else favor putting the ALG description in an appendix? > > My personal opinion is that I think the FTP64 document should remain > structured essentially as it is now. Agreed, as my personal opinion. -d From marka@isc.org Wed Aug 26 21:09:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7B43A6C9B for ; Wed, 26 Aug 2009 21:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+tMVW6W5qJ0 for ; Wed, 26 Aug 2009 21:09:54 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id AEE6D3A6C50 for ; Wed, 26 Aug 2009 21:09:53 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 0438CE601E; Thu, 27 Aug 2009 04:09:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7R49oln025123; Thu, 27 Aug 2009 14:09:50 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908270409.n7R49oln025123@drugs.dv.isc.org> To: Simon Perreault From: Mark Andrews References: <4A72F0BF.4000609@viagenie.ca> <4A8BE278.2030505@viagenie.ca> <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> <200908261537.04193.simon.perreault@viagenie.ca> In-reply-to: Your message of "Wed, 26 Aug 2009 15:37:03 -0400." <200908261537.04193.simon.perreault@viagenie.ca> Date: Thu, 27 Aug 2009 14:09:49 +1000 Sender: marka@isc.org Cc: Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 04:09:55 -0000 In message <200908261537.04193.simon.perreault@viagenie.ca>, Simon Perreault writes: > On Wednesday 26 August 2009 15:29:18 liu dapeng wrote: > > DNS64 should has an IPv4 connection in my opinion, since RFC 3901 > > recommends that it should be avoid to deploy IPv6 only DNS since this > > approach may cost many issues. > > The relevant passage from RFC 3901 is the following: > > - every recursive name server SHOULD be either IPv4-only or dual > stack, > > This rules out IPv6-only recursive servers. However, one might > design configurations where a chain of IPv6-only name server > forward queries to a set of dual stack recursive name server > actually performing those recursive queries. Note RFC 3901 was written when there were NO root servers that were running IPv6 on address that were associated with the names of the root servers. The intent of RFC 3901 was to ensure that all zones have authoritative nameservers reachable over IPv4 and that all recursive servers had a path to reach those IPv4 authoritative servers. As long as those conditions are met a recursive server doesn't have to speak IPv4 or IPv6. Using DNS64 internally is fine as is forwarding via IPv6 to a another server that is "dual" stacked. Using a DS-lite connection is fine. There are lots of ways to do this. At some point RFC 3901 will need to be updated to says all zones must be served by both IPv4 and IPv6 servers and all resursive servers must have IPv4 and IPv6 paths. At a later point it will be that all zones MUST be reachable over IPv6 and that all recursive server MUST have a IPv6 path to those servers. > I can imagine useful and potentially common cases where a DNS64 would not have > an IPv4 connection and would "forward queries to a set of dual stack recursive > name server actually performing those recursive queries" through the NAT64. > For example, when the RTT between the dual stack recursive name server and the > IPv6 hosts is long, you might want to provide a local cache. > > Simon > -- > DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From xuxh@huawei.com Wed Aug 26 22:13:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9803A3A6976 for ; Wed, 26 Aug 2009 22:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.381 X-Spam-Level: * X-Spam-Status: No, score=1.381 tagged_above=-999 required=5 tests=[AWL=1.876, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTp0UgFkCQsu for ; Wed, 26 Aug 2009 22:13:45 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A85DC3A68B7 for ; Wed, 26 Aug 2009 22:13:45 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP000G74RUTN8@szxga03-in.huawei.com> for behave@ietf.org; Thu, 27 Aug 2009 13:13:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP000BWLRUTIG@szxga03-in.huawei.com> for behave@ietf.org; Thu, 27 Aug 2009 13:13:41 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP000FPHRUS20@szxml04-in.huawei.com> for behave@ietf.org; Thu, 27 Aug 2009 13:13:41 +0800 (CST) Date: Thu, 27 Aug 2009 13:13:41 +0800 From: Xu Xiaohu In-reply-to: <200908261537.04193.simon.perreault@viagenie.ca> To: 'Simon Perreault' , 'liu dapeng' Message-id: <001101ca26d5$246be220$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcomhKDfoXrbzK8NSxCHbi1buVrlugASFrqA Cc: 'Behave WG' Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 05:13:46 -0000 > I can imagine useful and potentially common cases where a DNS64 would not have > an IPv4 connection and would "forward queries to a set of dual stack recursive > name server actually performing those recursive queries" through the NAT64. > For example, when the RTT between the dual stack recursive name server and the > IPv6 hosts is long, you might want to provide a local cache. I agree with your opinion. Even though we have some other approaches (e.g., CGN) to offer an IPv4 path between the DNS64 and the recursive name servers, I still think it's also worthwhile for the DNS64 server to synthesize IPv6 addresses of the IPv4 recursive servers in absence of the IPv4 path between them. Xiaohu From rpenno@juniper.net Wed Aug 26 22:43:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D66228C139 for ; Wed, 26 Aug 2009 22:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 147Hge+8HZJA for ; Wed, 26 Aug 2009 22:43:51 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id D1E683A6B10 for ; Wed, 26 Aug 2009 22:42:18 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSpYcsYEvTkqhS2cMrXG3cVci7NpXgSK9@postini.com; Wed, 26 Aug 2009 22:42:48 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 26 Aug 2009 22:42:05 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 27 Aug 2009 01:42:04 -0400 From: Reinaldo Penno To: Dan Wing , Iljitsch van Beijnum , liu dapeng Date: Thu, 27 Aug 2009 01:42:02 -0400 Thread-Topic: [BEHAVE] A New Draft on FTP64 Thread-Index: Acomj/90gKp+InTbSVKX2R28TTQ5jgAA8t4cAAf1wKAACV4Huw== Message-ID: In-Reply-To: <002701ca26b4$d5154470$c5f0200a@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 05:43:53 -0000 Hello, I'm taking about draft-van-beijnum-behave-ftp64-05.txt Thanks, Reinaldo On 8/26/09 6:22 PM, "Dan Wing" wrote: >> What is the purpose of this document? Is it to make current >> FTP6 clients work with current FTP4 servers? Or is it to give >> guidance to future FTP6 and FTP4 implementations? >=20 > There are two FTP64-related documents. I'm not sure which one you > are referring to when you say 'this document': >=20 > * draft-van-beijnum-behave-ftp64-05.txt >=20 > This document describes how existing IPv6 FTP clients and existing > IPv4 FTP servers function, and explains how an FTP ALG is useful if > a NAT64 operator wants those existing FTP clients and FTP servers to > work through a 6/4 translator. >=20 > This document was accepted in Stockholm as a WG document. I am very > close to sending a request to the mailing list to adopt it as a WG > document, but I am waiting for our new charter (and the FTP-related > milestone in it) to be accepted by IESG. >=20 > * draft-liu-behave-ftp64-01.txt describes how IPv6 FTP clients can > be changed to function across a NAT64, so that the NAT64 doesn't > need to have an FTP ALG. >=20 > This document is probably most appropriate in the applications area > as it describes a change in how the FTP applications are supposed to > work when operating across a translator. >=20 > -d >=20 >> The problem at hand as I understand it is to make current clients and >> servers (that already work through FTP NAT44) to work through >> FTP NAT64 without change. If that is the case then ALG part >> is crucial. >>=20 >> If the purpose is to guide future implementations although it >> has merit it >> does not help the problem at hand. >>=20 >> If this turns out into one of those dogmatic discussions that >> NAT and ALGs >> are evil and the IETF does not provide a document specifying >> how FTP64 ALG >> should work, people are going to develop without guidance (once more). >>=20 >> Hopefully we can reach some consensus on the purpose and scope of the >> document. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >>=20 >>=20 >>=20 >> On 8/26/09 1:57 PM, "Iljitsch van Beijnum" wrote: >>=20 >>> On 26 aug 2009, at 21:02, liu dapeng wrote: >>>=20 >>>>> However, there is additional benefit in making FTP through a >>>>> translator work for users with existing implementations, >> which can be >>>>> accomplished by either server upgrades or an ALG. >>>=20 >>>> Do not you think that server upgrading may be more >> reasonable from the >>>> evolution perspective? >>>=20 >>> No. Many clients use EPSV today, and a good number of servers don't >>> work with those clients. Apparently the people that run >> these servers >>> don't care. >>>=20 >>>> if the network contitue to provide ALG all the >>>> time, the server will never has motivation to upgrade, >>>=20 >>> I'm afraid the opposite will happen, and people will stay away from >>> NAT64 because "it doesn't work". Waiting for IPv4 users to update >>> their stuff isn't the best strategy. >>>=20 >>>> In my personal opioion, If the we do not recommend to implement FTP >>>> ALG, maybe we should not include any text to describe how >> to implement >>>> it for not misleading the reader. but maybe the text of >> ALG could be >>>> adjusted as an appendix, then there will be no contradiction. >>>=20 >>> Does anyone else favor putting the ALG description in an appendix? >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 From denghui02@gmail.com Thu Aug 27 05:23:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C4D3A6841 for ; Thu, 27 Aug 2009 05:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0utdresHA48 for ; Thu, 27 Aug 2009 05:23:34 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id B32A93A68E8 for ; Thu, 27 Aug 2009 05:23:02 -0700 (PDT) Received: by ewy3 with SMTP id 3so1111164ewy.42 for ; Thu, 27 Aug 2009 05:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zxCmhu0PE78JGWLnVuma9METi7LUk17kIKC3UG1mC7M=; b=QMBH03jTvqTgloN5akJ82kAa4EJGoOjCzu+FOFOdFFjub0VJxdgWKdLLW47FKIFtyd 9pvHYfgeAqf6Ii2WYAcP8EoN++8qXDMLhlbKAosQNaQcWdi6F5pvbLLO1rJyz7Zf+HS1 Z0OiVzepmv7W6TtEivmWPJG+FYKLETo315da8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l/xyc4wJAmruGyVBwnRoHCVnxgXzDLIjmvBLcdumltJGtWEqdamNBDsssh2vUcSBIu z9+6B0e974eB0oaxmN9X8n+bjjqvL/tDx918j65K+pjqE/ztWg674N8NNntm1gUIdisY WC+UwkqwGlwFxKmjXu4vgDkM2k6GqOnTfyKKg= MIME-Version: 1.0 Received: by 10.210.66.13 with SMTP id o13mr7182242eba.99.1251375785989; Thu, 27 Aug 2009 05:23:05 -0700 (PDT) In-Reply-To: <4A942774.5000500@bogus.com> References: <33098BF9C9584E8A9A96770D9CD5AD2D@JiangXiong> <36a593230908230827o15129fbbkfddcc958b3c86a04@mail.gmail.com> <4A916E13.70404@bogus.com> <4A92BE35.3010805@bogus.com> <1d38a3350908250721h183e638r25a5520833c0c78b@mail.gmail.com> <4A942774.5000500@bogus.com> Date: Thu, 27 Aug 2009 20:23:05 +0800 Message-ID: <1d38a3350908270523n14ff4506nd95058c92d43ca98@mail.gmail.com> From: Hui Deng To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: shengjiang@huawei.com, behave@ietf.org, Jacni Qin , liu dapeng , bo zhou , denghui@chinamobile.com Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:23:35 -0000 inline please 2009/8/26 Joel Jaeggli : > > > Hui Deng wrote: >>> You can write whatever you want, it won't change the deployed code. >> How many people really use FTP6 today? > > How long has your host stack and many of the included applications > supported ipv6? 6 years? longer maybe? ==> maybe longer than that, and who have ever used that? > > What odds do you put on the windows xp command-line ftp client being > changed? and that change being propagated into systems everywhere. > That's only one example but it's an ubiquitous one. > > The point is legacy applications don't change, if they did v4 to v6 > migration would be a lot simpler in the first place. ==> I change my laptop every two years, and guess most of people around me do the smiliar thing. we download everything each time during installing everything. I updated my skype and MSN software perodically. (Depends on how often they update it) thanks for the discussion -Hui > >> -Hui >> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> > From denghui02@gmail.com Thu Aug 27 05:26:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5460C3A6B43 for ; Thu, 27 Aug 2009 05:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQm1TeCOqNeb for ; Thu, 27 Aug 2009 05:26:19 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 57EE23A69FA for ; Thu, 27 Aug 2009 05:26:19 -0700 (PDT) Received: by ewy3 with SMTP id 3so1113623ewy.42 for ; Thu, 27 Aug 2009 05:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BYFDK5ocD8BZ3D+fx5H5iqfbiJObZwVGgDF+Rpvlh6I=; b=W2bV7Sx5JlBrsE3Kc77/4KUK9ZdNcP6ENbCouVHRohOwp2nE0c0IHm/M7NvvLxmNKz mnIkcI1ZmxYB90uIYQ2bfrEyvcnTeQmPo/fZH6Atq8iUhOnADyhfZEqLXMoFefuEGmyr xU1SU+o35NFSFvk7QmwtsxXXZ5WuMckf0OU3g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BEBQ6521GDcDcKJ/9tSlqpNIT+iCRw5SkZJ1739x/Ceyhh0KAEn04Glu0+7pw5/NKY AyitXefzEUTkrrHZ/nD0SkooSQP7WqLni7Q4zRxwZro056T7jrNikd2zbV6L4FTyfOLY KScpe2hMYmbzGZzjb1EOw40jJVXbhgoeZ3578= MIME-Version: 1.0 Received: by 10.210.143.13 with SMTP id q13mr4873994ebd.64.1251375982550; Thu, 27 Aug 2009 05:26:22 -0700 (PDT) In-Reply-To: References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> Date: Thu, 27 Aug 2009 20:26:22 +0800 Message-ID: <1d38a3350908270526i40af3ee3wae4ce5af2399ed95@mail.gmail.com> From: Hui Deng To: Dave Thaler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:26:20 -0000 If there is not client changing, I agree, it seem it has changed, then how could it remain strcutured essentially here? Thanks -Hui 2009/8/27 Dave Thaler : >> > In my personal opioion, If the we do not recommend to implement FTP >> > ALG, maybe we should not include any text to describe how to >> implement >> > it for not misleading the reader. but maybe the text of ALG could be >> > adjusted as an appendix, then there will be no contradiction. >> >> Does anyone else favor putting the ALG description in an appendix? > > My personal opinion is that I think the FTP64 document should remain > structured essentially as it is now. > > -Dave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From denghui02@gmail.com Thu Aug 27 05:28:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE3D28C176 for ; Thu, 27 Aug 2009 05:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O24Tj0jNOkrV for ; Thu, 27 Aug 2009 05:28:40 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 71F7328C29A for ; Thu, 27 Aug 2009 05:28:31 -0700 (PDT) Received: by ewy3 with SMTP id 3so1115221ewy.42 for ; Thu, 27 Aug 2009 05:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Fcviel5XMmDMljIZKz63MtCq+kgsIEyt2fuQtsvOPWg=; b=ntMqrIzd5qg7uzpRk91tPrgY5PM4l8oTsGrIAxw+aOBRQzStNXGsRNhTtJVngT1Bqo peR1qZoATQwQWh+r+WfCEPxvw29WZv293b+EQpj4gEOY9d56axKy6GFzebr+bjQqbYuD c4hFz9d8VBhNELNenZ7Drk8AEF5YVI1Ygh4c0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c+lv0Dcw/zfksQtUdNpBqBO504BYk0Ey8OMl6MC2PLQeWjkwebjN2fd7lWQxzdAHUj XPIAYb6KE6T3icrpgSzbOpp3YzEe/MkFAOMBhVYwp4+SsiVfyxnV4IdEhujrwxuNiw7h tzXL0pQjdi+8ZDsIZA1duL12HJTA7RSERjqvI= MIME-Version: 1.0 Received: by 10.210.35.10 with SMTP id i10mr355331ebi.92.1251376114891; Thu, 27 Aug 2009 05:28:34 -0700 (PDT) In-Reply-To: <003201ca26b6$149f2d80$c5f0200a@cisco.com> References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> <003201ca26b6$149f2d80$c5f0200a@cisco.com> Date: Thu, 27 Aug 2009 20:28:34 +0800 Message-ID: <1d38a3350908270528s61a4294fsb55aedfff6f3e481@mail.gmail.com> From: Hui Deng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org, Dave Thaler Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:28:41 -0000 then, I would like to ask the chairs, if there are some proposals could enhance FTP6 and make FTP64 more efficiently, how could we process this work, since FTP64 is right here. thanks -Hui 2009/8/27 Dan Wing : >> > > In my personal opioion, If the we do not recommend to >> implement FTP >> > > ALG, maybe we should not include any text to describe how to >> > implement >> > > it for not misleading the reader. but maybe the text of >> ALG could be >> > > adjusted as an appendix, then there will be no contradiction. >> > >> > Does anyone else favor putting the ALG description in an appendix? >> >> My personal opinion is that I think the FTP64 document should remain >> structured essentially as it is now. > > Agreed, as my personal opinion. > > -d > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From denghui02@gmail.com Thu Aug 27 05:38:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D8D3A6DE8 for ; Thu, 27 Aug 2009 05:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30XAHi7N4asO for ; Thu, 27 Aug 2009 05:38:34 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 1ABEF28C538 for ; Thu, 27 Aug 2009 05:38:06 -0700 (PDT) Received: by ewy3 with SMTP id 3so1122373ewy.42 for ; Thu, 27 Aug 2009 05:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1ghcp6jNoXLA9RluIVPFzrzc9weo0Ch3Twtbt4aGL6s=; b=fdoosNP+j+xGPc45zV/C41++T0PMLAQtZWxx3pUznn8PvaH6K7556GnZxn2aErK+lZ foMlxrYYxkJ5lMZBz6iQFOjIqufiLiFax53xYhXQ+l2V+m6HEmrmTW/uZQqE0z6pUtE0 fuE9IMYNCXv2QaukFkPjCGXvy734SXF8qdexw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V3LdxMkttLlqX5wcuvG3LvwbkTCFab5P5/vSMSjmbk1hCLS6nwi3GnhSY/GswbGjej IfCKH3eFrnNIG/AOX/o7WAjkvA70qwO1eEabSfIgeVs9rYaNuALybGJ9RowCPyE+ljhR 3/xquMY9cqdUD9aMTAy53v7mR4Grvx2+lvuNo= MIME-Version: 1.0 Received: by 10.210.76.15 with SMTP id y15mr5562945eba.0.1251376690161; Thu, 27 Aug 2009 05:38:10 -0700 (PDT) In-Reply-To: <200908270409.n7R49oln025123@drugs.dv.isc.org> References: <4A72F0BF.4000609@viagenie.ca> <4A8BE278.2030505@viagenie.ca> <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> <200908261537.04193.simon.perreault@viagenie.ca> <200908270409.n7R49oln025123@drugs.dv.isc.org> Date: Thu, 27 Aug 2009 20:38:10 +0800 Message-ID: <1d38a3350908270538n2aba6ffdhd229e2eb7255a56@mail.gmail.com> From: Hui Deng To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:38:35 -0000 but here NAT64 is assuming an IPv6 only network I would like to see how RFC 3901 work here. -Hui 2009/8/27 Mark Andrews : > > In message <200908261537.04193.simon.perreault@viagenie.ca>, Simon Perrea= ult writes: >> On Wednesday 26 August 2009 15:29:18 liu dapeng wrote: >> > DNS64 =A0should has an IPv4 connection in my opinion, since RFC 3901 >> > recommends that it should be avoid to deploy IPv6 only DNS since this >> > approach may cost many issues. >> >> The relevant passage from RFC 3901 is the following: >> >> =A0 =A0 =A0 - every recursive name server SHOULD be either IPv4-only or = dual >> =A0 =A0 =A0 =A0 stack, >> >> =A0 =A0 =A0 =A0 =A0This rules out IPv6-only recursive servers. =A0Howeve= r, one might >> =A0 =A0 =A0 =A0 =A0design configurations where a chain of IPv6-only name= server >> =A0 =A0 =A0 =A0 =A0forward queries to a set of dual stack recursive name= server >> =A0 =A0 =A0 =A0 =A0actually performing those recursive queries. > > Note RFC 3901 was written when there were NO root servers that were > running IPv6 on address that were associated with the names of the > root servers. > > The intent of RFC 3901 was to ensure that all zones have authoritative > nameservers reachable over IPv4 and that all recursive servers had > a path to reach those IPv4 authoritative servers. =A0As long as those > conditions are met a recursive server doesn't have to speak IPv4 > or IPv6. > > Using DNS64 internally is fine as is forwarding via IPv6 to a another > server that is "dual" stacked. =A0Using a DS-lite connection is fine. > There are lots of ways to do this. > > At some point RFC 3901 will need to be updated to says all zones > must be served by both IPv4 and IPv6 servers and all resursive servers > must have IPv4 and IPv6 paths. > > At a later point it will be that all zones MUST be reachable over > IPv6 and that all recursive server MUST have a IPv6 path to those > servers. > >> I can imagine useful and potentially common cases where a DNS64 would no= t have >> an IPv4 connection and would "forward queries to a set of dual stack rec= ursive >> name server actually performing those recursive queries" through the NAT= 64. >> For example, when the RTT between the dual stack recursive name server a= nd the >> IPv6 hosts is long, you might want to provide a local cache. >> >> Simon >> -- >> DNS64 open-source =A0 --> http://ecdysis.viagenie.ca >> STUN/TURN server =A0 =A0--> http://numb.viagenie.ca >> vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From denghui02@gmail.com Thu Aug 27 05:41:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95F23A6DBF for ; Thu, 27 Aug 2009 05:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frsGoydVFu1U for ; Thu, 27 Aug 2009 05:41:20 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 9934228C378 for ; Thu, 27 Aug 2009 05:41:19 -0700 (PDT) Received: by ewy3 with SMTP id 3so1124759ewy.42 for ; Thu, 27 Aug 2009 05:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/A4zLpEOBd8x3HxF89ADoj8zTKkvkynPrWkMUafkGNY=; b=JZU7vxRvMIArk1gQBRgtL618wCaUga0/ysocO1k0YdUfNucLpOr+M5+Vp5Dyd0tUOP povFI08BaNyTLW1O80qU7aIVKlCdwZgU/lY/ncOSYG6V1A5uzG2M+dUYNzGSRpyI6vqO Ex6XYQWCVw9m7Iya2ibgrvyk463IhLJLe5yS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s5mMH0FoCEUPytgiFVJLUzqWj8GAq7BtCZ3GF2n1JFlGQjnBZXmHYDaLVqNJWzHKTl KVn0L0q0LDg3ki2yB3mc9vEJTkgsq169/jf3B0scbU0LeyXNYhLEsfFFLWQwUE85mbgQ f1SGifa3HEwYrZXtNheGEzGGDPfz/PYryeN7E= MIME-Version: 1.0 Received: by 10.210.9.7 with SMTP id 7mr278262ebi.5.1251376881451; Thu, 27 Aug 2009 05:41:21 -0700 (PDT) In-Reply-To: <200908261537.04193.simon.perreault@viagenie.ca> References: <4A72F0BF.4000609@viagenie.ca> <4A8BE278.2030505@viagenie.ca> <25e1aaa40908261229r5facaf8g6211c2ff8e765d10@mail.gmail.com> <200908261537.04193.simon.perreault@viagenie.ca> Date: Thu, 27 Aug 2009 20:41:21 +0800 Message-ID: <1d38a3350908270541n6d942d81n55a36dc00102c203@mail.gmail.com> From: Hui Deng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:41:22 -0000 how consequently this could happen, DNS64 have to send AAAA resolver to DNS6 side, and send a A resolver through NAT64 meantime? is this your assumpation and described in the draft? -Hui 2009/8/27 Simon Perreault : > On Wednesday 26 August 2009 15:29:18 liu dapeng wrote: >> DNS64 =A0should has an IPv4 connection in my opinion, since RFC 3901 >> recommends that it should be avoid to deploy IPv6 only DNS since this >> approach may cost many issues. > > The relevant passage from RFC 3901 is the following: > > =A0 =A0 =A0- every recursive name server SHOULD be either IPv4-only or du= al > =A0 =A0 =A0 =A0stack, > > =A0 =A0 =A0 =A0 This rules out IPv6-only recursive servers. =A0However, o= ne might > =A0 =A0 =A0 =A0 design configurations where a chain of IPv6-only name ser= ver > =A0 =A0 =A0 =A0 forward queries to a set of dual stack recursive name ser= ver > =A0 =A0 =A0 =A0 actually performing those recursive queries. > > I can imagine useful and potentially common cases where a DNS64 would not= have > an IPv4 connection and would "forward queries to a set of dual stack recu= rsive > name server actually performing those recursive queries" through the NAT6= 4. > For example, when the RTT between the dual stack recursive name server an= d the > IPv6 hosts is long, you might want to provide a local cache. > > Simon > -- > DNS64 open-source =A0 --> http://ecdysis.viagenie.ca > STUN/TURN server =A0 =A0--> http://numb.viagenie.ca > vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From denghui02@gmail.com Thu Aug 27 05:42:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0013A6DF9 for ; Thu, 27 Aug 2009 05:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSWzec68xszG for ; Thu, 27 Aug 2009 05:41:59 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 49ED93A6DBF for ; Thu, 27 Aug 2009 05:41:59 -0700 (PDT) Received: by ewy3 with SMTP id 3so1125326ewy.42 for ; Thu, 27 Aug 2009 05:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rOoaCNnoSJFhIN6Zo2PIcoJ+7Aj7C1NjHDsOA+4vX0U=; b=mF+FSQOyyDYcw1woLRf8drTyy5CUNkoe3Ahe/NzFG2dFHckL5YS/hgnBH2JQ5yjhGA W201SEOYXPfcbdBXMi+3Ubew9kBAtMmXGVtqRwZUHFiqypeTkWyyF+mRINfsZRFxllFX 3SeXwWS2Lf9ys2iLiXZD3e/5G6OCRkkcf62LQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mJVI/l3UFl38f3DDCmrJ5xSA81r8A+yNfZu9Oz4jR/Uykrb7kuCp6bIw5IrXYmHjSQ X+9BYK9413EJltQg6iNTwFdd9gtmfnkiyMVneh2IO7za5dt10rZeHnHyk3TDXRWF18V8 jYhKRapSTDi9M3QTwXo7qyy/yChncI78Ku+mU= MIME-Version: 1.0 Received: by 10.210.35.10 with SMTP id i10mr366622ebi.92.1251376925670; Thu, 27 Aug 2009 05:42:05 -0700 (PDT) In-Reply-To: <001101ca26d5$246be220$d40c6f0a@china.huawei.com> References: <200908261537.04193.simon.perreault@viagenie.ca> <001101ca26d5$246be220$d40c6f0a@china.huawei.com> Date: Thu, 27 Aug 2009 20:42:05 +0800 Message-ID: <1d38a3350908270542m65ab8431m3d62d9feecb26f17@mail.gmail.com> From: Hui Deng To: Xu Xiaohu Content-Type: text/plain; charset=ISO-8859-1 Cc: Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:42:00 -0000 if you propose like this, then I would like to see the text and comment it later thanks -Hui 2009/8/27 Xu Xiaohu : >> I can imagine useful and potentially common cases where a DNS64 would not > have >> an IPv4 connection and would "forward queries to a set of dual stack > recursive >> name server actually performing those recursive queries" through the > NAT64. >> For example, when the RTT between the dual stack recursive name server and > the >> IPv6 hosts is long, you might want to provide a local cache. > > I agree with your opinion. Even though we have some other approaches (e.g., > CGN) to offer an IPv4 path between the DNS64 and the recursive name servers, > I still think it's also worthwhile for the DNS64 server to synthesize IPv6 > addresses of the IPv4 recursive servers in absence of the IPv4 path between > them. > > Xiaohu > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From simon.perreault@viagenie.ca Thu Aug 27 05:46:55 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35E13A6DF3 for ; Thu, 27 Aug 2009 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9i9cutJQ5nO for ; Thu, 27 Aug 2009 05:46:55 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8BF753A6D66 for ; Thu, 27 Aug 2009 05:46:53 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 02EDC29E15FF; Thu, 27 Aug 2009 08:46:58 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id EF5D829E15CE; Thu, 27 Aug 2009 08:46:57 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Hui Deng Date: Thu, 27 Aug 2009 08:46:57 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <200908261537.04193.simon.perreault@viagenie.ca> <001101ca26d5$246be220$d40c6f0a@china.huawei.com> <1d38a3350908270542m65ab8431m3d62d9feecb26f17@mail.gmail.com> In-Reply-To: <1d38a3350908270542m65ab8431m3d62d9feecb26f17@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908270846.57634.simon.perreault@viagenie.ca> Cc: Behave WG , liu dapeng , Xu Xiaohu Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:46:55 -0000 On Thursday 27 August 2009 08:42:05 Hui Deng wrote: > if you propose like this, then I would like to see the text and comment it > later thanks I don't understand what you want. I have proposed some text and based on the feedback I have received it still stands. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Thu Aug 27 05:48:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7923A6DF3 for ; Thu, 27 Aug 2009 05:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTzT554PTEb8 for ; Thu, 27 Aug 2009 05:48:53 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 584223A6E31 for ; Thu, 27 Aug 2009 05:48:49 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 1565429E1605; Thu, 27 Aug 2009 08:48:54 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 0C72F29E15CE; Thu, 27 Aug 2009 08:48:54 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Hui Deng Date: Thu, 27 Aug 2009 08:48:53 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <4A72F0BF.4000609@viagenie.ca> <200908261537.04193.simon.perreault@viagenie.ca> <1d38a3350908270541n6d942d81n55a36dc00102c203@mail.gmail.com> In-Reply-To: <1d38a3350908270541n6d942d81n55a36dc00102c203@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908270848.53749.simon.perreault@viagenie.ca> Cc: Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 12:48:54 -0000 On Thursday 27 August 2009 08:41:21 Hui Deng wrote: > how consequently this could happen, DNS64 have to send AAAA resolver > to DNS6 side, and > send a A resolver through NAT64 meantime? is this your assumpation and > described in the draft? When a DNS64 has only an IPv6 connection, it can only contact authoritative name servers over IPv6. However, if it has access to the NAT64, it can also talk to IPv4-only authoritative name servers through it. To do so it only has to use the synthetic AAAA records it generates. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From iljitsch@muada.com Thu Aug 27 06:25:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005D528C563 for ; Thu, 27 Aug 2009 06:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws3OxxMPRbTE for ; Thu, 27 Aug 2009 06:25:58 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id EA5F328C548 for ; Thu, 27 Aug 2009 06:25:57 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7RDPFAc026695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 15:25:16 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> From: Iljitsch van Beijnum To: Dave Thaler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Aug 2009 15:25:49 +0200 References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> X-Mailer: Apple Mail (2.936) Cc: Andrew Sullivan , Stig Venaas , Xing Li , Mark Andrews , "behave@ietf.org" Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 13:25:59 -0000 On 22 aug 2009, at 0:04, Dave Thaler wrote: > I don't see why the DNS64 shouldn't be capable of doing multicast > address translation too, if such is used. If, for example, a DNS64 > is configured with a set of IPv4 prefixes and the corresponding IPv6 > prefix for each, it shouldn't have to check whether the address is > unicast or multicast. Of course either all prefixes have to have the > same suffix algorithm (zero-pad and embed, or embed and zero-pad, or > whatever else) or else you have to configure the algorithm per prefix > too. I haven't followed the multicast discussion in detail, but the problem here is that in IPv6, there is scope information encoded in multicast addresses. This information isn't present in IPv4 multicast addressing, or at least not to the same degree. This means that it's necessary to add this information during the translation, and AFAIK this information can't be defaulted or algorithmically derived, so this requires additional configuration. From iljitsch@muada.com Thu Aug 27 06:28:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE9628C586 for ; Thu, 27 Aug 2009 06:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlbjV-eY0Sf8 for ; Thu, 27 Aug 2009 06:28:33 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 613DA28C56A for ; Thu, 27 Aug 2009 06:27:40 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7RDR3w2026711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 15:27:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Simon Perreault In-Reply-To: <200908270848.53749.simon.perreault@viagenie.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Aug 2009 15:27:36 +0200 References: <4A72F0BF.4000609@viagenie.ca> <200908261537.04193.simon.perreault@viagenie.ca> <1d38a3350908270541n6d942d81n55a36dc00102c203@mail.gmail.com> <200908270848.53749.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.936) Cc: Hui Deng , Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 13:28:34 -0000 On 27 aug 2009, at 14:48, Simon Perreault wrote: > When a DNS64 has only an IPv6 connection, it can only contact > authoritative > name servers over IPv6. However, if it has access to the NAT64, it > can also > talk to IPv4-only authoritative name servers through it. To do so it > only has > to use the synthetic AAAA records it generates. Being able to perform DNS64 synthesis and being able to do recursive queries through a NAT64 are two different things. One doesn't imply the other, although once you have one the other is easier because you already have the NAT64 prefix that you need. From marc.blanchet@viagenie.ca Thu Aug 27 06:28:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9E5A28C573 for ; Thu, 27 Aug 2009 06:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzAAZMFa83Ew for ; Thu, 27 Aug 2009 06:28:35 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 97C4128C58F for ; Thu, 27 Aug 2009 06:28:27 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 39BDF29E1605; Thu, 27 Aug 2009 09:28:29 -0400 (EDT) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id 2339B29E15CE; Thu, 27 Aug 2009 09:28:29 -0400 (EDT) Message-ID: <4A9689FC.3020607@viagenie.ca> Date: Thu, 27 Aug 2009 09:28:28 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> In-Reply-To: <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , Mark Andrews , Andrew Sullivan , Stig Venaas , Dave Thaler , Xing Li Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 13:28:37 -0000 Iljitsch van Beijnum a crit : > On 22 aug 2009, at 0:04, Dave Thaler wrote: > >> I don't see why the DNS64 shouldn't be capable of doing multicast >> address translation too, if such is used. If, for example, a DNS64 >> is configured with a set of IPv4 prefixes and the corresponding IPv6 >> prefix for each, it shouldn't have to check whether the address is >> unicast or multicast. Of course either all prefixes have to have the >> same suffix algorithm (zero-pad and embed, or embed and zero-pad, or >> whatever else) or else you have to configure the algorithm per prefix >> too. > > I haven't followed the multicast discussion in detail, but the problem > here is that in IPv6, there is scope information encoded in multicast > addresses. This information isn't present in IPv4 multicast addressing, > or at least not to the same degree. This means that it's necessary to > add this information during the translation, and AFAIK this information > can't be defaulted or algorithmically derived, so this requires > additional configuration. yes, but: one can restrict to a subset: i.e. only translate global scope groups, which is most likely what people would need. This could be a config switch within the translator. Marc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From fluffy@cisco.com Thu Aug 27 07:12:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534A53A6E1D; Thu, 27 Aug 2009 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.986 X-Spam-Level: X-Spam-Status: No, score=-105.986 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qScqCI4evd-Z; Thu, 27 Aug 2009 07:12:23 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4284A3A6DEB; Thu, 27 Aug 2009 07:12:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAB4xlkqrR7PD/2dsb2JhbABFv1yIPAGQAgWEGQ X-IronPort-AV: E=Sophos;i="4.44,286,1249257600"; d="scan'208";a="41497151" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 27 Aug 2009 14:12:30 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7RECUPq006897; Thu, 27 Aug 2009 07:12:30 -0700 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7RECS1c029544; Thu, 27 Aug 2009 14:12:29 GMT Message-Id: <5C2EF0B9-5DFA-4DB0-B2D6-4EF1FE7ADDD3@cisco.com> From: Cullen Jennings To: Bruce Lowekamp In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 26 Aug 2009 22:42:09 -0600 References: X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=807; t=1251382350; x=1252246350; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Last=20Call=3A=20draft-ietf-behave-nat- behavior-discovery=20(NATBehavior=20Discovery=20Using=20STUN )=20to=20Experimental=20RFC |Sender:=20; bh=hfmvPFF2MA7RCNGxtERnf68dxRt24CbZ4uoTbbtBBiU=; b=KGDeuXV5eC3uVrDd8lvsnuf6+WGSJar1EzKAFkLBDdxJy8jbK3tj3vZnpw NkX7GpoT4byGNB1PSCa7ScgWr5BjXmg21S3e78bba3/1mEfCBp9PuVOuGBsc hGQlN81oTy; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Behave WG , IETF Discussion Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 14:12:24 -0000 On Apr 14, 2009, at 20:38 , Bruce Lowekamp wrote: > > Many of the NATs out there you > > can not make this determination without multiple IP addresses > behind the > > NAT. > > So you're right that you can test for a few more bizarre NAT behaviors > with multiple IP addresses, but I haven't seen any evidence suggesting > those behaviors are present in most NATs. In draft-jennings-behave-test-results-04.txt (google it, it's expired), you will note all the NATs where the Sec behavior is different than Prim behavior in the results table are NATs where you need more than one IP to characterize them. This includes NATs from Airlink, Cisco, Linksys, SMC, and Toshiba. Other unpublished testing has revealed it is many NATs from other vendors also work this way. Cullen From stig@venaas.com Thu Aug 27 07:55:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3102928C246 for ; Thu, 27 Aug 2009 07:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJJHldVmhJ6W for ; Thu, 27 Aug 2009 07:55:14 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id D1C2A28C5AC for ; Thu, 27 Aug 2009 07:55:13 -0700 (PDT) Received: from [192.168.1.101] (adsl-99-186-244-131.dsl.pltn13.sbcglobal.net [99.186.244.131]) by ufisa.uninett.no (Postfix) with ESMTP id 685C4388B7; Thu, 27 Aug 2009 16:55:15 +0200 (CEST) Message-ID: <4A969E1B.7030109@venaas.com> Date: Thu, 27 Aug 2009 07:54:19 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marc Blanchet References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> <4A9689FC.3020607@viagenie.ca> In-Reply-To: <4A9689FC.3020607@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , Mark Andrews , Andrew Sullivan , Dave Thaler , Xing Li Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 14:55:15 -0000 Marc Blanchet wrote: > Iljitsch van Beijnum a crit : >> On 22 aug 2009, at 0:04, Dave Thaler wrote: >> >>> I don't see why the DNS64 shouldn't be capable of doing multicast >>> address translation too, if such is used. If, for example, a DNS64 >>> is configured with a set of IPv4 prefixes and the corresponding IPv6 >>> prefix for each, it shouldn't have to check whether the address is >>> unicast or multicast. Of course either all prefixes have to have the >>> same suffix algorithm (zero-pad and embed, or embed and zero-pad, or >>> whatever else) or else you have to configure the algorithm per prefix >>> too. >> I haven't followed the multicast discussion in detail, but the problem >> here is that in IPv6, there is scope information encoded in multicast >> addresses. This information isn't present in IPv4 multicast addressing, >> or at least not to the same degree. This means that it's necessary to >> add this information during the translation, and AFAIK this information >> can't be defaulted or algorithmically derived, so this requires >> additional configuration. > > yes, but: one can restrict to a subset: i.e. only translate global scope > groups, which is most likely what people would need. This could be a > config switch within the translator. This is partly why I think this should be configurable. Someone managing DNS64 and the translator can decide on what is appropriate. But yes, it's not that hard to come up with a sensible default I think. E.g. only global scope. Maybe map 239/8 to scope 5... > Marc. > >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From marc.blanchet@viagenie.ca Thu Aug 27 08:04:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7FA93A6A18 for ; Thu, 27 Aug 2009 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hubJsssMpmA6 for ; Thu, 27 Aug 2009 08:04:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 3FBA53A67A3 for ; Thu, 27 Aug 2009 08:04:40 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id EFE5029E15FC; Thu, 27 Aug 2009 11:04:44 -0400 (EDT) Received: from h103.viagenie.ca (h103.viagenie.ca [206.123.31.103]) by jazz.viagenie.ca (Postfix) with ESMTP id DAC4029E15CE; Thu, 27 Aug 2009 11:04:44 -0400 (EDT) Message-ID: <4A96A08C.3060809@viagenie.ca> Date: Thu, 27 Aug 2009 11:04:44 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stig Venaas References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> <4A9689FC.3020607@viagenie.ca> <4A969E1B.7030109@venaas.com> In-Reply-To: <4A969E1B.7030109@venaas.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , Mark Andrews , Andrew Sullivan , Dave Thaler , Xing Li Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:04:42 -0000 Stig Venaas a crit : > Marc Blanchet wrote: >> Iljitsch van Beijnum a crit : >>> On 22 aug 2009, at 0:04, Dave Thaler wrote: >>> >>>> I don't see why the DNS64 shouldn't be capable of doing multicast >>>> address translation too, if such is used. If, for example, a DNS64 >>>> is configured with a set of IPv4 prefixes and the corresponding IPv6 >>>> prefix for each, it shouldn't have to check whether the address is >>>> unicast or multicast. Of course either all prefixes have to have the >>>> same suffix algorithm (zero-pad and embed, or embed and zero-pad, or >>>> whatever else) or else you have to configure the algorithm per prefix >>>> too. >>> I haven't followed the multicast discussion in detail, but the problem >>> here is that in IPv6, there is scope information encoded in multicast >>> addresses. This information isn't present in IPv4 multicast addressing, >>> or at least not to the same degree. This means that it's necessary to >>> add this information during the translation, and AFAIK this information >>> can't be defaulted or algorithmically derived, so this requires >>> additional configuration. >> >> yes, but: one can restrict to a subset: i.e. only translate global scope >> groups, which is most likely what people would need. This could be a >> config switch within the translator. > > This is partly why I think this should be configurable. Someone managing > DNS64 and the translator can decide on what is appropriate. But yes, > it's not that hard to come up with a sensible default I think. E.g. only > global scope. Maybe map 239/8 to scope 5... for configuration purposes, a nat64 is a forwarding device such as a router. by default, routers do not forward multicast trafic, but can if configured to do so. Therefore, I think the nat64/dns64 should not do any translation and forwarding of multicast traffic by default, unless it is explicitly configured to do so. Marc. >> Marc. >> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >> >> -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From wassim.haddad@ericsson.com Thu Aug 27 08:26:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241C83A6B63 for ; Thu, 27 Aug 2009 08:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5a8IjDdlKzh for ; Thu, 27 Aug 2009 08:26:40 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A81963A682F for ; Thu, 27 Aug 2009 08:26:40 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n7RFQfYO000317 for ; Thu, 27 Aug 2009 10:26:46 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 10:25:50 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 10:25:50 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 27 Aug 2009 11:25:49 -0400 From: Wassim Haddad To: "behave@ietf.org" Date: Thu, 27 Aug 2009 11:25:48 -0400 Thread-Topic: NAT64 and MIPv6 Thread-Index: AQHKJsLo1QKPhuJJrU6rFUk9ftYPQg== Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_2991246A29623A4082EB2B06A2B891A41B7C3D85A9EUSAACMS0703e_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Aug 2009 15:25:50.0485 (UTC) FILETIME=[A8A31450:01CA272A] Cc: Wassim Haddad Subject: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:26:42 -0000 --_002_2991246A29623A4082EB2B06A2B891A41B7C3D85A9EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please find attached a note on NAT64 and MIPv6. Regards, Wassim H.= --_002_2991246A29623A4082EB2B06A2B891A41B7C3D85A9EUSAACMS0703e_ Content-Type: text/plain; name="draft-haddad-behave-nat64-mobility-harmful-00.txt" Content-Description: draft-haddad-behave-nat64-mobility-harmful-00.txt Content-Disposition: attachment; filename="draft-haddad-behave-nat64-mobility-harmful-00.txt"; size=9832; creation-date="Wed, 26 Aug 2009 23:03:25 GMT"; modification-date="Wed, 26 Aug 2009 23:03:25 GMT" Content-Transfer-Encoding: base64 CgoKQmVoYXZpb3IgRW5naW5lZXJpbmcgZm9yIEhpbmRyYW5jZSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVy4gSGFkZGFkCkF2b2lkYW5jZSAoYmVoYXZlKSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbgpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjYsIDIwMDkKSW50ZW5k ZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsCkV4cGlyZXM6IEZlYnJ1YXJ5IDI3LCAyMDEwCgoKICAg ICAgICAgICAgICBBIE5vdGUgb24gTkFUNjQgSW50ZXJhY3Rpb24gd2l0aCBNb2JpbGUgSVB2Ngog ICAgICAgICAgICAgZHJhZnQtaGFkZGFkLWJlaGF2ZS1uYXQ2NC1tb2JpbGl0eS1oYXJtZnVsLTAw CgpTdGF0dXMgb2YgdGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRl ZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBC Q1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVu dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMg YXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERy YWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBU aGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQKICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LgoKICAgVGhlIGxpc3Qg b2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdAog ICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLgoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCB3aWxsIGV4cGlyZSBvbiBGZWJydWFyeSAyNywgMjAxMC4KCkNvcHlyaWdodCBOb3RpY2UKCiAg IENvcHlyaWdodCAoYykgMjAwOSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVk IGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyBpbiBlZmZlY3Qgb24g dGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCAoaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKS4KICAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHMgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzCiAgIGFuZCByZXN0cmlj dGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoaXMgZG9jdW1lbnQuCgoKCgoKCgoKSGFkZGFkICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAxMCAgICAgICAgICAgICAgIFtQYWdl IDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBOQVQ2NCBNb2JpbGl0eSAgICAgICAg ICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKQWJzdHJhY3QKCiAgIFRoaXMgbWVtbyBkaXNjdXNzZXMg cG90ZW50aWFsIE5BVDY0IHRlY2hub2xvZ3kgcmVwZXJjdXNzaW9ucyBmb3IKICAgbW9iaWxlIG5v ZGVzIHVzaW5nIE1vYmlsZSBJUHY2IHN0YWNrLgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAg SW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDMKICAgMi4gIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDMuICBOQVQ2NCBJbmNvbXBhdGliaWxpdHkgd2l0 aCBNb2JpbGUgSVB2NiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQogICA0LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcK ICAgNS4gIEFja25vd2xlZGdlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA4CiAgIDYuICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQogICAgIDYuMS4gIE5vcm1hdGl2ZSBSZWZl cmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgICA2LjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA5CiAgIEF1dGhvcidzIEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK SGFkZGFkICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAxMCAgICAgICAg ICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBOQVQ2NCBNb2Jp bGl0eSAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKMS4gIEludHJvZHVjdGlvbgoKICAg TkFUNjQgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLWJlaGF2ZS12NnY0LXhsYXRl LXN0YXRlZnVsXSwKICAgZW5hYmxlcyByYXBpZCBJUHY0IG5ldHdvcmsgY29udmVyc2lvbiB0byBh IHB1cmUgSVB2NiBzdGFjayB3aGlsZQogICBrZWVwaW5nIHBvc3NpYmxlIHRoZSBjb250YWN0IHdp dGggdGhlIHJlbWFpbmluZyBJUHY0IG5ldHdvcmtzLiAgSXQKICAgZm9sbG93cyB0aGF0IG5vZGVz IGF0dGFjaGVkIHRvIGEgTkFUNjQtcG93ZXJlZCBuZXR3b3JrIG9wZXJhdGUgd2l0aAogICBhbiBJ UHY2IHN0YWNrIG9ubHkuCgogICBUaGlzIG1lbW8gYWltcyB0byBoaWdobGlnaHQgcG90ZW50aWFs IE5BVDY0IHJlcGVyY3Vzc2lvbnMgZm9yIG1vYmlsZQogICBub2RlcyB1c2luZyBNb2JpbGUgSVB2 NiAoW0ktRC5pZXRmLW1leHQtcmZjMzc3NWJpc10pIGFuZCBvcGVyYXRpbmcKICAgZnJvbSBiZWhp bmQgYSBOQVQ2NC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkhhZGRh ZCAgICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjcsIDIwMTAgICAgICAgICAgICAg ICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTkFUNjQgTW9iaWxpdHkg ICAgICAgICAgICAgICAgICBBdWd1c3QgMjAwOQoKCjIuICBDb252ZW50aW9ucyB1c2VkIGluIHRo aXMgZG9jdW1lbnQKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS RUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJF Q09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJl IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpIYWRkYWQgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEZlYnJ1YXJ5IDI3LCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgIE5BVDY0IE1vYmlsaXR5ICAgICAgICAgICAgICAgICAg QXVndXN0IDIwMDkKCgozLiAgTkFUNjQgSW5jb21wYXRpYmlsaXR5IHdpdGggTW9iaWxlIElQdjYK CiAgIEl0IGlzIGludGVyZXN0aW5nIHRvIHN0YXJ0IHRoaXMgc2VjdGlvbiBieSBtZW50aW9uaW5n IHRoYXQgTkFUCiAgIHRlY2hub2xvZ3kgaW4gZ2VuZXJhbCBoYXMgaGFkIGZyb20gaXRzIGluZmFu Y3kgdGhlIHJhcmUgZmVhdHVyZSBvZgogICBiZWluZyBpbmNvbXBhdGlibGUgd2l0aCB0aGUgSW50 ZXJuZXQuICBIZW5jZSwgdGhlIGRlc2NyaWJlZCBuZXcKICAgaW5jb21wYXRpYmlsaXR5IHNob3Vs ZCBub3QgY29tZSBhcyBhIHN1cnByaXNlIQoKICAgTkFUNjQgbWVjaGFuaXNtIHJlbGllcyBvbiBE TlM2NCB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbgogICBbSS1ELmlldGYtYmVoYXZlLWRuczY0XSB0 byBwcm92aWRlIHRoZSBxdWVyeWluZyBob3N0IHdpdGggYSBzeW50aGV0aWMKICAgRE5TIHJlc3Bv bnNlIGluIHdoaWNoLCB0aGUgcXVlcmllZCBGUUROIGlzIGxvY2FsbHkgdHJhbnNsYXRlZCB0byBh bgogICBJUHY2IGFkZHJlc3MgdXNpbmcgdGhlIHY2IHByZWZpeCBhc3NpZ25lZCB0byB0aGUgTkFU NjQgdjYgaW50ZXJmYWNlLgogICBCeSBpbnNlcnRpbmcgdGhlIHRyYW5zbGF0ZWQgSVB2NiBhZGRy ZXNzIGluIHRoZSBzeW50aGV0aWMgRE5TCiAgIHJlc3BvbnNlLCB0aGUgcXVlcnlpbmcgbm9kZSBp cyB0ZW1wdGVkIHRvIGJlbGlldmUgdGhhdCB0aGUKICAgZGVzdGluYXRpb24gaXMgYWxzbyB1c2lu ZyBhbiBJUHY2IHN0YWNrIHdoaWNoIGluIHR1cm4sIGVuYWJsZXMKICAgZXN0YWJsaXNoaW5nIGEg c2Vzc2lvbiBiZXR3ZWVuIHRoZSB0d28gbm9kZXMuCgogICBBcyBOQVQ2NCB0ZWNobm9sb2d5IG1h eSBoYXZlIHRoZSBwb3RlbnRpYWwgb2YgYmVjb21pbmcgd2lkZWx5CiAgIGRlcGxveWVkLCB3ZSBh cmUgdGVtcHRlZCB0byBzdHVkeSBpdHMgYmVoYXZpb3IgaW4gdGhlIHByZXNlbmNlIG9mIGEKICAg djYgbW9iaWxpdHkgZGltZW5zaW9uLiAgRm9yIHRoaXMgcHVycG9zZSwgd2UgYXNzdW1lIHRoYXQg YSBtb2JpbGUKICAgbm9kZSAoTU4pIGNvbmZpZ3VyZWQgd2l0aCBhbiBJUHY2IGhvbWUgYWRkcmVz cyAoSG9BKSBsZWF2ZXMgaXRzCiAgIE5BVDY0LXBvd2VyZWQgaG9tZSBuZXR3b3JrIGFuZCBhdHRh Y2hlcyB0byBhIGZvcmVpZ24gTkFUNjQtcG93ZXJlZAogICBuZXR3b3JrIHdoZXJlIGl0IGNvbmZp Z3VyZXMgYSBuZXcgSVB2NiBhZGRyZXNzLCBpLmUuLCBjYXJlLW9mIGFkZHJlc3MKICAgKENvQSku ICBJbiB0aGUgZm9sbG93aW5nLCB3ZSBsb29rIGludG8gdHdvIHNjZW5hcmlvcyB3aGljaCByZXF1 aXJlCiAgIHVzaW5nIE1JUHY2IGVpdGhlciB0byBlc3RhYmxpc2ggYSBuZXcgc2Vzc2lvbiBvciB0 byB0cnkgdG8gc3dpdGNoIHRoZQogICBkYXRhIHBhY2tldHMgZXhjaGFuZ2UgdG8gdGhlIG9wdGlt YWwgcGF0aCB2aWEgdXNpbmcgTUlQdjYgcm91dGUKICAgb3B0aW1pemF0aW9uIChSTykgbW9kZS4K CiAgIEluIGEgZmlyc3Qgc2NlbmFyaW8sIHdlIGNvbnNpZGVyIHRoYXQgYmVmb3JlIGRldGFjaGlu ZyBmcm9tIGl0cyBob21lCiAgIG5ldHdvcmssIHRoZSBNTiBoYXMgZXN0YWJsaXNoZWQgYSBzZXNz aW9uIHdpdGggYSBjb3JyZXNwb25kaW5nIG5vZGUKICAgKENOKSB3aGljaCBpcyBhdHRhY2hlZCB0 byBhbiBJUHY0IG5ldHdvcmsuICBIb3dldmVyLCBkdWUgdG8gdGhlIE5BVDY0CiAgIHByZXNlbmNl IGluIHRoZSBob21lIG5ldHdvcmssIHRoZSBNTiBiZWxpZXZlcyB0aGF0IGl0IGlzIHRhbGtpbmcg d2l0aAogICBhbiBJUHY2LWVuYWJsZWQgQ04gYW5kIGhlbmNlLCBpdCBkZWNpZGVzIHVwb24gYXR0 YWNoaW5nIHRvIHRoZSBuZXcKICAgTkFUNjQtcG93ZXJlZCBmb3JlaWduIG5ldHdvcmssIHRvIHJ1 biBNSVB2NiByZXR1cm4gcm91dGFiaWxpdHkgKFJSKQogICBwcm9jZWR1cmUgd2l0aCB0aGUgQ04g Ynkgc2VuZGluZyBmaXJzdCBhIGhvbWUgdGVzdCBpbml0IChIb1RJKQogICBtZXNzYWdlIHZpYSBp dHMgaG9tZSBhZ2VudC4gIEl0IGlzIGNsZWFyIHRoYXQgc3VjaCBtZXNzYWdlIHdpbGwgYmUKICAg ZGlzY2FyZGVkIGVpdGhlciBieSBhICJtb3JlIiBpbnRlbGxpZ2VudCBOQVQ2NCAoaS5lLiwgaW4g d2hpY2ggY2FzZQogICBpdCBtYXkgYmUgZm9sbG93ZWQgYnkgYW4gSUNNUCBtZXNzYWdlIHNlbnQg dG8gdGhlIE1OKSBvciBieSB0aGUgQ04uCiAgIEluIGJvdGggY2FzZXMsIHRoZSBNTiB3aWxsIGNv cnJlY3RseSByZWFsaXplIGF0IHNvbWUgcG9pbnQgdGhhdCB0aGUKICAgUlIgcHJvY2VkdXJlIGNh bm5vdCBzdWNjZWVkLiAgQ29uc2VxdWVudGx5LCB0aGVyZSBpcyBubyBoYXJtCiAgIGluZmxpY3Rl ZCB0byB0aGUgTU4gYW5kIG1vcmUgaW1wb3J0YW50bHksIG5vIGRhdGEgcGFja2V0IGxvc3Mgc2lu Y2UKICAgdGhlIE1OIHdpbGwga2VlcCB1c2luZyBNSVB2NiBiaWRpcmVjdGlvbmFsIHR1bm5lbGlu ZyAoQlQpIG1vZGUuCgogICBIb3dldmVyLCB0aGUgc2l0dWF0aW9uIGJlY29tZXMgcHJvYmxlbWF0 aWMgd2hlbiB3ZSBjb25zaWRlciBhbm90aGVyCiAgIHNjZW5hcmlvIGluIHdoaWNoLCB0aGUgTU4g ZGVjaWRlcyB0byBlc3RhYmxpc2ggYSBzZXNzaW9uIHdpdGggdGhlCiAgIHNhbWUgQ04gZnJvbSB0 aGUgZm9yZWlnbiBOQVQ2NC1wb3dlcmVkIG5ldHdvcmsuICBJbiBzdWNoIGNhc2UsIHRoZSBNTgog ICB3aWxsIGZpcnN0IG9idGFpbiBhIHN5bnRoZXRpYyBETlMgcmVwbHkgd2hpY2ggcHJlc2VudHMg dGhlIENOIGFzCiAgIGJlaW5nIGFuIElQdjYtZW5hYmxlZCBub2RlLiAgQmFzZWQgb24gdGhhdCwg dGhlIE1OIG1heSBlaXRoZXIgdHJ5IHRvCiAgIGNyZWF0ZSBhIGJpbmRpbmcgYXQgdGhlIENOIGJ5 IHJ1bm5pbmcgZmlyc3QgdGhlIFJSIHByb2NlZHVyZSB3aGljaAoKCgpIYWRkYWQgICAgICAgICAg ICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI3LCAyMDEwICAgICAgICAgICAgICAgW1BhZ2UgNV0K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIE5BVDY0IE1vYmlsaXR5ICAgICAgICAgICAg ICAgICAgQXVndXN0IDIwMDkKCgogICB3aWxsIHVsdGltYXRlbHkgZmFpbCAoaS5lLiwgZm9yIHRo ZSBzYW1lIHJlYXNvbnMgYXMgaW4gdGhlIGZpcnN0CiAgIHNjZW5hcmlvKSBvciBtb3JlIGxpa2Vs eSwgd2lsbCBpbml0aWF0ZSB0aGUgc2Vzc2lvbiB3aXRoIHRoZSBDTiBieQogICB1c2luZyB0aGUg QlQgbW9kZSB0aGVuIHN3aXRjaGluZyB0byB0aGUgUk8gbW9kZS4gIEluIHRoaXMgY2FzZSwgdGhl CiAgIE1OIHR1bm5lbHMgZmlyc3QgaXRzIGRhdGEgcGFja2V0cyB0byBpdHMgSEEgd2l0aG91dCBo YXZpbmcgdGhlbSBiZWluZwogICBpbnRlcmNlcHRlZCBieSB0aGUgZm9yZWlnbiBOQVQ2NC4gIEhv d2V2ZXIsIGFmdGVyIHJlYWNoaW5nIHRoZSBIQSwKICAgdGhlIGRhdGEgcGFja2V0cyB3aWxsIG1v c3QgbGlrZWx5IGJlIGRyb3BwZWQgYXQgc29tZSBwb2ludC4gIFRoaXMgaXMKICAgZHVlIHRvIHRo ZSBwcmVzZW5jZSBvZiB0aGUgZm9yZWlnbiBOQVQ2NCBJUHY2IHByZWZpeCBpbiB0aGUgQ04ncyBJ UHY2CiAgIGFkZHJlc3MuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpIYWRkYWQgICAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDI3LCAyMDEwICAgICAg ICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgIE5BVDY0IE1v YmlsaXR5ICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMDkKCgo0LiAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMKCiAgIFRoaXMgbWVtbyBkZXNjcmliZXMgc2NlbmFyaW9zIHdoZXJlIGEgTkFUNjQg Y2FuIGluZmxpY3QgaGFybSB0byBhCiAgIG1vYmlsZSBub2RlIHZpc2l0aW5nIHRoZSBhc3NvY2lh dGVkIG5ldHdvcmsuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKSGFkZGFkICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAxMCAgICAg ICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBOQVQ2NCBN b2JpbGl0eSAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKNS4gIEFja25vd2xlZGdlbWVu dHMKCiAgIFRoYW5rcyB0byBGcmFuY2lzIER1cG9udCBhbmQgSm9lbCBIYWxwZXJuIGZvciByZXZp ZXdpbmcgdGhlIGRvY3VtZW50CiAgIGF0IGFuIGVhcmx5IHN0YWdlLgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkhhZGRhZCAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMjcsIDIwMTAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgTkFUNjQgTW9iaWxpdHkgICAgICAgICAgICAgICAgICBBdWd1 c3QgMjAwOQoKCjYuICBSZWZlcmVuY2VzCgo2LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAg W0ktRC5pZXRmLW1leHQtcmZjMzc3NWJpc10KICAgICAgICAgICAgICBKb2huc29uLCBELiwgUGVy a2lucywgQy4sIGFuZCBKLiBBcmtrbywgIk1vYmlsaXR5IFN1cHBvcnQKICAgICAgICAgICAgICBp biBJUHY2IiwgZHJhZnQtaWV0Zi1tZXh0LXJmYzM3NzViaXMtMDQgKHdvcmsgaW4KICAgICAgICAg ICAgICBwcm9ncmVzcyksIEp1bHkgMjAwOS4KCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWly ZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KCjYuMi4gIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQuaWV0Zi1iZWhhdmUtZG5zNjRdCiAgICAgICAgICAg ICAgQmFnbnVsbywgTS4sIFN1bGxpdmFuLCBBLiwgTWF0dGhld3MsIFAuLCBhbmQgSS4gQmVpam51 bSwKICAgICAgICAgICAgICAiRE5TNjQ6IEROUyBleHRlbnNpb25zIGZvciBOZXR3b3JrIEFkZHJl c3MgVHJhbnNsYXRpb24KICAgICAgICAgICAgICBmcm9tIElQdjYgQ2xpZW50cyB0byAgSVB2NCBT ZXJ2ZXJzIiwKICAgICAgICAgICAgICBkcmFmdC1pZXRmLWJlaGF2ZS1kbnM2NC0wMCAod29yayBp biBwcm9ncmVzcyksIEp1bHkgMjAwOS4KCiAgIFtJLUQuaWV0Zi1iZWhhdmUtdjZ2NC14bGF0ZS1z dGF0ZWZ1bF0KICAgICAgICAgICAgICBCYWdudWxvLCBNLiwgTWF0dGhld3MsIFAuLCBhbmQgSS4g QmVpam51bSwgIk5BVDY0OiBOZXR3b3JrCiAgICAgICAgICAgICAgQWRkcmVzcyBhbmQgUHJvdG9j b2wgVHJhbnNsYXRpb24gZnJvbSBJUHY2IENsaWVudHMgdG8gSVB2NAogICAgICAgICAgICAgIFNl cnZlcnMiLCBkcmFmdC1pZXRmLWJlaGF2ZS12NnY0LXhsYXRlLXN0YXRlZnVsLTAxICh3b3JrCiAg ICAgICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBKdWx5IDIwMDkuCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKSGFkZGFkICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyNywgMjAxMCAg ICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICBOQVQ2 NCBNb2JpbGl0eSAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA5CgoKQXV0aG9yJ3MgQWRkcmVz cwoKICAgV2Fzc2ltIEhhZGRhZAogICBFcmljc3NvbgogICA2MjEwIFNwaW5lIFJvYWQKICAgQm91 bGRlciwgQ08gODAzMDEKICAgVVMKCiAgIFBob25lOiArMzAzIDQ3MyA2OTYzCiAgIEVtYWlsOiBX YXNzaW0uSGFkZGFkQGVyaWNzc29uLmNvbQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCkhhZGRhZCAgICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjcsIDIw MTAgICAgICAgICAgICAgIFtQYWdlIDEwXQoMCg== --_002_2991246A29623A4082EB2B06A2B891A41B7C3D85A9EUSAACMS0703e_-- From dwing@cisco.com Thu Aug 27 08:40:56 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2383A6B25 for ; Thu, 27 Aug 2009 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dL8-eqSwbq+w for ; Thu, 27 Aug 2009 08:40:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A4A4C3A67C0 for ; Thu, 27 Aug 2009 08:40:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEADdGlkqrR7O6/2dsb2JhbACLFrVQiDwBkAQFhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="186129279" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Aug 2009 15:40:58 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7RFewFM026502; Thu, 27 Aug 2009 08:40:58 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7RFewmX006514; Thu, 27 Aug 2009 15:40:58 GMT From: "Dan Wing" To: "'Hui Deng'" References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <30C27104-1A3A-4FB9-9C3C-3F9E11E2A353@muada.com> <003201ca26b6$149f2d80$c5f0200a@cisco.com> <1d38a3350908270528s61a4294fsb55aedfff6f3e481@mail.gmail.com> Date: Thu, 27 Aug 2009 08:40:58 -0700 Message-ID: <016601ca272c$c6283ad0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1d38a3350908270528s61a4294fsb55aedfff6f3e481@mail.gmail.com> Thread-Index: AconEeX9N3pqeXGuSraumzEDCLQ8pwAGWzBw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2032; t=1251387658; x=1252251658; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=vuAsrrHFRkLJW9A23WnuwWvmf8B9zeCKyar3be2MKXI=; b=lppOATye6U/KAYbmL6DlnMtq0JgHf3XwdhBE0HFKsAYRGaJJXUGpXV8Jlp Bb5RzKxLv8AOVAyNcbOvhrjRzVYYtveRUflW0i8D62hxfrxiEFFWWBbS31Cf vZBGT/Nno5; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org, 'Dave Thaler' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:40:57 -0000 > -----Original Message----- > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: Thursday, August 27, 2009 5:29 AM > To: Dan Wing > Cc: Dave Thaler; Iljitsch van Beijnum; behave@ietf.org > Subject: Re: [BEHAVE] A New Draft on FTP64 > > then, I would like to ask the chairs, if there are some proposals > could enhance FTP6 > and make FTP64 more efficiently, how could we process this work, since > FTP64 is right here. If there are changes to draft-van-beijnum-behave-ftp64 that you'd like to see, please continue to send them to the list. Dave and I only expressed our personal opinion on the placement of the ALG text in the document; if there is widespread support for putting the text into an appendix, we will support that. Suggested changes to FTP clients and FTP servers should be done in the IETF's applications area, because dictating/changing application behavior is outside of BEHAVE's scope. I know the applications area does not currently have an FTP-specific working group, but they do have an area-wide mailing list (apps-discuss@ietf.org) and area meetings (an I-D that I co-authored was presented at the Applications area meeting in Stockholm). -d > thanks > > -Hui > > 2009/8/27 Dan Wing : > >> > > In my personal opioion, If the we do not recommend to > >> implement FTP > >> > > ALG, maybe we should not include any text to describe how to > >> > implement > >> > > it for not misleading the reader. but maybe the text of > >> ALG could be > >> > > adjusted as an appendix, then there will be no contradiction. > >> > > >> > Does anyone else favor putting the ALG description in an > appendix? > >> > >> My personal opinion is that I think the FTP64 document > should remain > >> structured essentially as it is now. > > > > Agreed, as my personal opinion. > > > > -d > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > From dwing@cisco.com Thu Aug 27 09:05:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8403A7013 for ; Thu, 27 Aug 2009 09:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyj9Luo14fgW for ; Thu, 27 Aug 2009 09:05:40 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 104203A6BAC for ; Thu, 27 Aug 2009 09:05:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAEAMZLlkqrR7PD/2dsb2JhbACLFrYKiDwBkAkFhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="41507480" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 27 Aug 2009 16:05:46 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7RG5kWo024157; Thu, 27 Aug 2009 09:05:46 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7RG5jd9019530; Thu, 27 Aug 2009 16:05:45 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Iljitsch van Beijnum'" , "'liu dapeng'" References: <002701ca26b4$d5154470$c5f0200a@cisco.com> Date: Thu, 27 Aug 2009 09:05:45 -0700 Message-ID: <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acomj/90gKp+InTbSVKX2R28TTQ5jgAA8t4cAAf1wKAACV4HuwAVvEag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4601; t=1251389146; x=1252253146; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=g7NHZs4uCaKDqXr3rMy3kHQFCBLkRGibl6vIdQYJ1p0=; b=Y8SIJ6b/7l/wHM3eIQi8o2kudWjm/etYkDkoXQE+qiWPygUtB3XJOiU4cz xwe1F+2HsQBsXsW8dn5oCkSMMARNsmA1x8FMaI64tqm1en10Z06v4jrJbWsn Eim+TtRSHt; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:05:41 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, August 26, 2009 10:42 PM > To: Dan Wing; Iljitsch van Beijnum; liu dapeng > Cc: behave@ietf.org > Subject: Re: [BEHAVE] A New Draft on FTP64 > > Hello, > > I'm taking about draft-van-beijnum-behave-ftp64-05.txt That document explains how current IPv6 FTP clients work in conjunction with current IPv4 FTP servers, and where there is breakage; it does not expect IPv4 FTP servers will change (which is BEHAVE's same expectation for IPv4 HTTP servers, for that matter). -d > Thanks, > > Reinaldo > > > On 8/26/09 6:22 PM, "Dan Wing" wrote: > > >> What is the purpose of this document? Is it to make current > >> FTP6 clients work with current FTP4 servers? Or is it to give > >> guidance to future FTP6 and FTP4 implementations? > > > > There are two FTP64-related documents. I'm not sure which one you > > are referring to when you say 'this document': > > > > * draft-van-beijnum-behave-ftp64-05.txt > > > > This document describes how existing IPv6 FTP clients and existing > > IPv4 FTP servers function, and explains how an FTP ALG is > useful if > > a NAT64 operator wants those existing FTP clients and FTP > servers to > > work through a 6/4 translator. > > > > This document was accepted in Stockholm as a WG document. > I am very > > close to sending a request to the mailing list to adopt it as a WG > > document, but I am waiting for our new charter (and the > FTP-related > > milestone in it) to be accepted by IESG. > > > > * draft-liu-behave-ftp64-01.txt describes how IPv6 FTP clients can > > be changed to function across a NAT64, so that the NAT64 doesn't > > need to have an FTP ALG. > > > > This document is probably most appropriate in the > applications area > > as it describes a change in how the FTP applications are > supposed to > > work when operating across a translator. > > > > -d > > > >> The problem at hand as I understand it is to make current > clients and > >> servers (that already work through FTP NAT44) to work through > >> FTP NAT64 without change. If that is the case then ALG part > >> is crucial. > >> > >> If the purpose is to guide future implementations although it > >> has merit it > >> does not help the problem at hand. > >> > >> If this turns out into one of those dogmatic discussions that > >> NAT and ALGs > >> are evil and the IETF does not provide a document specifying > >> how FTP64 ALG > >> should work, people are going to develop without guidance > (once more). > >> > >> Hopefully we can reach some consensus on the purpose and > scope of the > >> document. > >> > >> Thanks, > >> > >> Reinaldo > >> > >> > >> > >> > >> > >> On 8/26/09 1:57 PM, "Iljitsch van Beijnum" > wrote: > >> > >>> On 26 aug 2009, at 21:02, liu dapeng wrote: > >>> > >>>>> However, there is additional benefit in making FTP through a > >>>>> translator work for users with existing implementations, > >> which can be > >>>>> accomplished by either server upgrades or an ALG. > >>> > >>>> Do not you think that server upgrading may be more > >> reasonable from the > >>>> evolution perspective? > >>> > >>> No. Many clients use EPSV today, and a good number of > servers don't > >>> work with those clients. Apparently the people that run > >> these servers > >>> don't care. > >>> > >>>> if the network contitue to provide ALG all the > >>>> time, the server will never has motivation to upgrade, > >>> > >>> I'm afraid the opposite will happen, and people will stay > away from > >>> NAT64 because "it doesn't work". Waiting for IPv4 users to update > >>> their stuff isn't the best strategy. > >>> > >>>> In my personal opioion, If the we do not recommend to > implement FTP > >>>> ALG, maybe we should not include any text to describe how > >> to implement > >>>> it for not misleading the reader. but maybe the text of > >> ALG could be > >>>> adjusted as an appendix, then there will be no contradiction. > >>> > >>> Does anyone else favor putting the ALG description in an appendix? > >>> _______________________________________________ > >>> Behave mailing list > >>> Behave@ietf.org > >>> https://www.ietf.org/mailman/listinfo/behave > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > > From iljitsch@muada.com Thu Aug 27 09:18:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A6CB3A6909 for ; Thu, 27 Aug 2009 09:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd7ikf7kM8Uv for ; Thu, 27 Aug 2009 09:18:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 286CF3A69B3 for ; Thu, 27 Aug 2009 09:18:47 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7RGI6rg028056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 18:18:06 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> From: Iljitsch van Beijnum To: Dan Wing In-Reply-To: <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Aug 2009 18:18:39 +0200 References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:18:48 -0000 On 27 aug 2009, at 18:05, Dan Wing wrote: >> I'm taking about draft-van-beijnum-behave-ftp64-05.txt > That document explains how current IPv6 FTP clients work > in conjunction with current IPv4 FTP servers, and where > there is breakage; it does not expect IPv4 FTP servers > will change (which is BEHAVE's same expectation for IPv4 > HTTP servers, for that matter). That's not completely accurate. The document does make modifications to RFCs 959 and 2428, imposing new requirements on both clients and servers. This is in line with the feedback I got from the applications people. From dwing@cisco.com Thu Aug 27 09:29:53 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC4328C280 for ; Thu, 27 Aug 2009 09:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBWaT7nr-xZY for ; Thu, 27 Aug 2009 09:29:52 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 852373A6A5E for ; Thu, 27 Aug 2009 09:29:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAKNRlkqrR7PD/2dsb2JhbACLFrYPiD4BkA0FhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="91619407" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 27 Aug 2009 16:29:59 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7RGTxl1019664; Thu, 27 Aug 2009 09:29:59 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n7RGTsqd029900; Thu, 27 Aug 2009 16:29:54 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> Date: Thu, 27 Aug 2009 09:29:54 -0700 Message-ID: <000701ca2733$9ec44a40$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AconMhLBSmeXrKquQc+J7WsuCOA57AAAHeNA DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1704; t=1251390599; x=1252254599; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=O21DjOlUIH1utRJ2aw31rYTHLCCS6qVvJNbTNQlgYU0=; b=Azq/X6wVAXcyRG+rjlRLQts1j8Mh8igQlq52sXHTuAXlpYdp2v9A4jbGXi CkkC8M1R/4SCMJogWbu5I0Detq7kv34ww0YmYkiay52yli/hljcbm9keZTBt 4JMFI+ZULv; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:29:53 -0000 > >> I'm taking about draft-van-beijnum-behave-ftp64-05.txt > > > That document explains how current IPv6 FTP clients work > > in conjunction with current IPv4 FTP servers, and where > > there is breakage; it does not expect IPv4 FTP servers > > will change (which is BEHAVE's same expectation for IPv4 > > HTTP servers, for that matter). > > That's not completely accurate. The document does make modifications > to RFCs 959 and 2428, imposing new requirements on both clients and > servers. This is in line with the feedback I got from the > applications people. My interpretation of draft-van-beijnum-behave-ftp64-05 requirements boil down to 'support EPSV as specified in RFC2428', and the only additional thing you're requiring is that the IP address of the data channel is the same as the IP address as the control channel; but my testing showed that every FTP server I tested on the Internet already met that additional requirement. Are the FEAT requirements new, too? (afterall, I don't think previous FTP specifications required FEAT to agree with the actual features of the FTP server; rather, it's just assumed an FTP server would do that because it is reasonable). That is, excepting perhaps FEAT, requirements are not 'new', and nearly any deployed IPv4 FTP server or deployed IPv6 FTP client would already meet them. If you feel one wouldn't, please say so (as I know you will!). My interpretation of draft-liu-behave-ftp64-03 is that it suggests more substantial changes to requirements, to the point that existing deployed IPv6 FTP clients and existing, deployed IPv4 FTP servers are unlikely to comply with draft-liu-behave-ftp64-03. -d From maxpassion@gmail.com Thu Aug 27 10:03:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A083A682F for ; Thu, 27 Aug 2009 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=-1.726, BAYES_00=-2.599, FRT_BELOW2=2.154, J_CHICKENPOX_73=0.6, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d26GFj5LFPkX for ; Thu, 27 Aug 2009 10:03:32 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id B797F28C636 for ; Thu, 27 Aug 2009 10:02:38 -0700 (PDT) Received: by vws7 with SMTP id 7so945018vws.29 for ; Thu, 27 Aug 2009 10:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iyO9PMJ/WocN8BB1bdIjqxVbiIEcttQl5EzILARnoEE=; b=blP9GFwdQw2xSoc4XXN7eS17hXxp285xTdlXVOGJeo9KwFR+Jf36r5Fjsirlf+MPj4 ltifn2z9ucXxH3pmQ31N2ymxWFAXLE3p/XxewpYt2qw9vugBswu1Wef/TNRYnjAOwHyc kuiSeWDKQhbksYbaycXNDGB2FNBtv8GCDzL/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pD0tYGE3tLvE7H8ZaKJwPFA85MuG2q6jz8Lm9tv7lFDkK4r4Os3FPWCfp9tD8kHgb8 Hr8uWy8t7/vwteTkteoj1u4ju6GUAx2fKZIkpNM2pLHLkNgeeu5LCuXc6jonqFITyTsP x+CZTyRMIeEQmUjbfZu6623WaYUCJjTjRf41w= MIME-Version: 1.0 Received: by 10.220.112.197 with SMTP id x5mr13348975vcp.83.1251392562627; Thu, 27 Aug 2009 10:02:42 -0700 (PDT) In-Reply-To: <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> Date: Fri, 28 Aug 2009 01:02:42 +0800 Message-ID: <25e1aaa40908271002g4856358ch225eb3fa671a8ca@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:03:33 -0000 2009/8/27, Dan Wing : > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of liu dapeng >> Sent: Wednesday, August 26, 2009 12:03 PM >> To: Iljitsch van Beijnum >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] A New Draft on FTP64 >> >> 2009/8/25, Iljitsch van Beijnum : >> > On 24 aug 2009, at 19:40, liu dapeng wrote: >> > >> >> We upgrade the ftp64 draft, add some text considering the >> legacy FTP >> >> implementation and other clarification as well. Any comments are >> >> welcomed. >> > >> > Can you please send the new text to the list? >> >> we upgrade setion 3 and 5, bellow is the text. >> >> 3. Client considerations >> >> It is required that all IPv6 FTP clients MUST support both EPSV and >> PASV command. >> >> When the client tries to connect to a server using IPv6 connection, >> it should use EPSV command first. If the server response >> that it does >> not support this command or encounters an error, it MUST retry with >> PASV command. > > That algorithm will cause a timeout -- not an error -- with some FTP > servers. For example, ftp.dell.com responds positively to EPSV but > does not actually allow connecting to the port indicated on the FTP > control channel. Other sites, such as ftp.microsoft.com, work just > fine with EPSV. > > Would it be better to just try PASV first (and for the data channel, > the FTP client should use the IP address of the control channel, > ignoring what is in the PASV response) and if *that* fails it means > the FTP server is really listening on IPv6 and refuses to use PASV > and wants EPSV, so you only use EPSV after PASV returns an error? maybe this is better, and for the legacy server, this approach can also work. In essence,for the client, this approach use PASV but treat it as as EPSV (ignoring the IP address of the response message) > -d > > >> The server will respond to PASV command with >> an message >> that contains an IPv4 address and port number that used for the >> client to connect to. The client MUST ignores the IPv4 address >> provided in the response; it should use the control connection's IP >> address to connect to the server to establish the data connection. >> >> This approach could not only simply the FTP client software's >> implementation but also can avoid the problems caused by using the >> IPv4 address that included in the response message. For example, if >> the FTP client has a private IPv4 connection and a public IPv6 >> connection, if it tries to use the IPv4 connection to >> establish data >> connection with the server, it will never success. >> >> >> 5. FTP ALG considerations >> >> 5.1. FTP ALG limitations >> >> Implementing FTP ALG in the translation box may have some >> limitations, >> such as: >> >> 1) FTP ALG may case to increase the complexity of translation box, >> since FTP ALG needs to understand FTP protocol and translate the >> application layer payload and update the header of FTP control >> packets. >> >> >> Dapeng Liu Expires February 27, 2010 [Page 4] >> > >> Internet-Draft IPv6 IPv4 translation FTP considerations August 2009 >> >> >> 2) For most of current Network Processor based translation box, ALG >> processing may cause its performance decreased >> significantly. The >> reason is that FTP ALG processing can not take the advantage of >> Network Processor, which is designed and optimized for >> processing >> regular packets (such as header translation). >> >> 3) From the evolution perspective, if the network continues to >> provide support of FTP ALG all the time, the users will have no >> motivation to upgrade their FTP client software. If >> things evolve >> toward this direction, the ALG function of the translation box >> will become more and more complex. In reality, upgrading FTP >> client software is a more easy way to solve the ALG issue >> compared with requiring that all the translation box to >> implement >> FTP ALG. >> >> 5.2. Solution to avoid FTP ALG >> >> This document suggests that the translation box which situated >> between the IPv6 network and IPv4 network should not implement FTP >> ALG. It is depend on the client and server that comply with this >> specification to avoid the FTP ALG issue. >> >> The reason that this document does not encourage translation box to >> implement FTP ALG is that since the FTP ALG problem can be totally >> avoid by defining the behavior of the client and server, it is not >> necessary to implement it at all. This approach can reduce the >> translation box's complexity. Also, the FTP client and server's >> communication without ALG will significantly improve its >> performance. >> >> For the legacy IPv6 FTP client, this document suggests that the >> legacy client should behave like RFC1579 recommendation >> which is that >> "vendors convert their FTP clients programs to use PASV instead of >> PORT". For IPv6 FTP client, this recommendation should be >> "the users >> or vendors should convert their FTP clients programs to use EPSV >> instead of EPRT". This can be done by configuration and do not >> require upgrading of the client software for most of >> current IPv6 FTP >> client. This solution may require that the FTP server >> should support >> EPSV command. >> >> >> > A client that implements the client requirements and client >> > recommendations listed in draft-van-beijnum-behave-ftp64-05 will be >> > able to successfully interoperate with any server that >> implements EPSV >> > or PASV through a stateful or stateless translator. >> >> The solution in draft-van-beijnum-behave-ftp64-05 suggests that >> "However, the server will respond to the PASV command with an IPv4 >> address that the client must use to connect to for the data >> connection. If the client has IPv4 reachability, it SHOULD set up a >> data connection towards the IPv4 address." this may can not work in >> some cases, as draft-liu-behave-ftp64-02 mentioned:'" For example, >> if the FTP client has a private IPv4 connection and a public IPv6 >> connection, if it tries to use the IPv4 connection to establish data >> connection with the server, it will never success." >> >> >> Since updating an >> > FTP client is about the easiest possible upgrade that we could >> > possibly require (an FTP client doesn't need special privileges and >> > can run as a java applet in a browser) this provides a workable >> > solution for most users. >> >> aggree, this is what draft-liu-behave-ftp64-02 suggested. >> >> > However, there is additional benefit in making FTP through a >> > translator work for users with existing implementations, >> which can be >> > accomplished by either server upgrades or an ALG. >> >> Do not you think that server upgrading may be more reasonable from the >> evolution perspective? if the network contitue to provide ALG all the >> time, the server will never has motivation to upgrade, this will cause >> the ALGs in the translation box become more and more complex, since >> the translator will try to maintain ALGs for all the legacy >> implementations; and the legacy implementation never think about >> upgrading because they never aware the needs to upgrade. this approach >> may be convenient for a little part of the users but is harmful for >> the evolution of the network. >> >> > Since at least one vendor has expressed interest in >> implementing such >> > an ALG, having standard ALG functionality is better than >> undefined ALG >> > functionality and we have the text now anyway, in my opinion it >> > doesn't make sense to remove the ALG text, although I'm willing to >> > make it (even) more clear that such an ALG is optional. >> >> In my personal opioion, If the we do not recommend to implement FTP >> ALG, maybe we should not include any text to describe how to implement >> it for not misleading the reader. but maybe the text of ALG could be >> adjusted as an appendix, then there will be no contradiction. >> > >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From stig@venaas.com Thu Aug 27 10:09:02 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBF33A6A11 for ; Thu, 27 Aug 2009 10:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2PsZXZcHdYj for ; Thu, 27 Aug 2009 10:09:01 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id D07013A691A for ; Thu, 27 Aug 2009 10:07:52 -0700 (PDT) Received: from [128.107.163.89] (dhcp-128-107-163-89.cisco.com [128.107.163.89]) by ufisa.uninett.no (Postfix) with ESMTP id 84D403892D; Thu, 27 Aug 2009 19:07:57 +0200 (CEST) Message-ID: <4A96BD66.3030105@venaas.com> Date: Thu, 27 Aug 2009 10:07:50 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Marc Blanchet References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> <4A9689FC.3020607@viagenie.ca> <4A969E1B.7030109@venaas.com> <4A96A08C.3060809@viagenie.ca> In-Reply-To: <4A96A08C.3060809@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" , Mark Andrews , Andrew Sullivan , Dave Thaler , Xing Li Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:09:02 -0000 Marc Blanchet wrote: > Stig Venaas a crit : >> Marc Blanchet wrote: >>> Iljitsch van Beijnum a crit : >>>> On 22 aug 2009, at 0:04, Dave Thaler wrote: >>>> >>>>> I don't see why the DNS64 shouldn't be capable of doing multicast >>>>> address translation too, if such is used. If, for example, a DNS64 >>>>> is configured with a set of IPv4 prefixes and the corresponding IPv6 >>>>> prefix for each, it shouldn't have to check whether the address is >>>>> unicast or multicast. Of course either all prefixes have to have the >>>>> same suffix algorithm (zero-pad and embed, or embed and zero-pad, or >>>>> whatever else) or else you have to configure the algorithm per prefix >>>>> too. >>>> I haven't followed the multicast discussion in detail, but the problem >>>> here is that in IPv6, there is scope information encoded in multicast >>>> addresses. This information isn't present in IPv4 multicast addressing, >>>> or at least not to the same degree. This means that it's necessary to >>>> add this information during the translation, and AFAIK this information >>>> can't be defaulted or algorithmically derived, so this requires >>>> additional configuration. >>> yes, but: one can restrict to a subset: i.e. only translate global scope >>> groups, which is most likely what people would need. This could be a >>> config switch within the translator. >> This is partly why I think this should be configurable. Someone managing >> DNS64 and the translator can decide on what is appropriate. But yes, >> it's not that hard to come up with a sensible default I think. E.g. only >> global scope. Maybe map 239/8 to scope 5... > > for configuration purposes, a nat64 is a forwarding device such as a > router. by default, routers do not forward multicast trafic, but can if > configured to do so. Therefore, I think the nat64/dns64 should not do > any translation and forwarding of multicast traffic by default, unless > it is explicitly configured to do so. Agreed. So my points regarding DNS64 are basically: Recommend that one can configure different IPv6 prefix mappings for different IPv4 prefixes (and also that certain IPv4 prefixes can be ignored). The above would be sufficient for DNS64 to work with multicast, even with various scopes. What exactly those mappings could be should not be in this document. The recommended default should be ignoring multicast addresses. Stig > Marc. > >>> Marc. >>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>> > > From maxpassion@gmail.com Thu Aug 27 10:11:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B335A3A69EC for ; Thu, 27 Aug 2009 10:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[AWL=-1.324, BAYES_00=-2.599, FRT_BELOW2=2.154, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG-qqVm9Iu0I for ; Thu, 27 Aug 2009 10:11:51 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 275A63A6880 for ; Thu, 27 Aug 2009 10:11:50 -0700 (PDT) Received: by vws7 with SMTP id 7so953573vws.29 for ; Thu, 27 Aug 2009 10:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=spgSJvkLDv79tzb8Eb+5s6Zw9jjPin4lUoBhSJP8QfU=; b=QLaUOZ+XUMXJTWBt6QarPMOd8KuxwcwogMa7+553wNF6Shv+z2WPY3zgLI+TYN3/Q1 UbdrgSnnjXlELUwRXBeIxf2QcrhJ5u48MwQ3zZDPka1i1LrgLL6G+oJCdK6wzzx+cCCo 4AfQ6iQjzTQoO2eoBlHHSyl/h+olzLuOvAzJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=McyU3Gmb1vTInTG6J3fIaUjcnB0Yx+h0kL5TghmV78tzxU5O2T47jdcdxc7r2YemqU w6uKFQtRrsPvlsqBJ8RjC7y7Uthi3p6Vt1LglZgwoL08CSO3yXNon435JSnBIp6CFMNI OGg47V/qro9VTNPFwug/bKcbzLIQFEZUMXXmc= MIME-Version: 1.0 Received: by 10.220.69.204 with SMTP id a12mr55714vcj.0.1251393114594; Thu, 27 Aug 2009 10:11:54 -0700 (PDT) In-Reply-To: <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> Date: Fri, 28 Aug 2009 01:11:54 +0800 Message-ID: <25e1aaa40908271011t72fab84fsd65b28f3469c9121@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:11:52 -0000 2009/8/27, Dan Wing : > > >> -----Original Message----- >> From: behave-bounces@ietf.org >> [mailto:behave-bounces@ietf.org] On Behalf Of liu dapeng >> Sent: Wednesday, August 26, 2009 12:03 PM >> To: Iljitsch van Beijnum >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] A New Draft on FTP64 >> >> 2009/8/25, Iljitsch van Beijnum : >> > On 24 aug 2009, at 19:40, liu dapeng wrote: >> > >> >> We upgrade the ftp64 draft, add some text considering the >> legacy FTP >> >> implementation and other clarification as well. Any comments are >> >> welcomed. >> > >> > Can you please send the new text to the list? >> >> we upgrade setion 3 and 5, bellow is the text. >> >> 3. Client considerations >> >> It is required that all IPv6 FTP clients MUST support both EPSV and >> PASV command. >> >> When the client tries to connect to a server using IPv6 connection, >> it should use EPSV command first. If the server response >> that it does >> not support this command or encounters an error, it MUST retry with >> PASV command. > > That algorithm will cause a timeout -- not an error -- with some FTP > servers. For example, ftp.dell.com responds positively to EPSV but > does not actually allow connecting to the port indicated on the FTP > control channel. Other sites, such as ftp.microsoft.com, work just > fine with EPSV. > > Would it be better to just try PASV first (and for the data channel, > the FTP client should use the IP address of the control channel, > ignoring what is in the PASV response) and if *that* fails it means > the FTP server is really listening on IPv6 and refuses to use PASV > and wants EPSV, so you only use EPSV after PASV returns an error? my question is: the server is in an IPv4 network, if the PASV fails, why does it expect EPSV command? > -d > > >> The server will respond to PASV command with >> an message >> that contains an IPv4 address and port number that used for the >> client to connect to. The client MUST ignores the IPv4 address >> provided in the response; it should use the control connection's IP >> address to connect to the server to establish the data connection. >> >> This approach could not only simply the FTP client software's >> implementation but also can avoid the problems caused by using the >> IPv4 address that included in the response message. For example, if >> the FTP client has a private IPv4 connection and a public IPv6 >> connection, if it tries to use the IPv4 connection to >> establish data >> connection with the server, it will never success. >> >> >> 5. FTP ALG considerations >> >> 5.1. FTP ALG limitations >> >> Implementing FTP ALG in the translation box may have some >> limitations, >> such as: >> >> 1) FTP ALG may case to increase the complexity of translation box, >> since FTP ALG needs to understand FTP protocol and translate the >> application layer payload and update the header of FTP control >> packets. >> >> >> Dapeng Liu Expires February 27, 2010 [Page 4] >> > >> Internet-Draft IPv6 IPv4 translation FTP considerations August 2009 >> >> >> 2) For most of current Network Processor based translation box, ALG >> processing may cause its performance decreased >> significantly. The >> reason is that FTP ALG processing can not take the advantage of >> Network Processor, which is designed and optimized for >> processing >> regular packets (such as header translation). >> >> 3) From the evolution perspective, if the network continues to >> provide support of FTP ALG all the time, the users will have no >> motivation to upgrade their FTP client software. If >> things evolve >> toward this direction, the ALG function of the translation box >> will become more and more complex. In reality, upgrading FTP >> client software is a more easy way to solve the ALG issue >> compared with requiring that all the translation box to >> implement >> FTP ALG. >> >> 5.2. Solution to avoid FTP ALG >> >> This document suggests that the translation box which situated >> between the IPv6 network and IPv4 network should not implement FTP >> ALG. It is depend on the client and server that comply with this >> specification to avoid the FTP ALG issue. >> >> The reason that this document does not encourage translation box to >> implement FTP ALG is that since the FTP ALG problem can be totally >> avoid by defining the behavior of the client and server, it is not >> necessary to implement it at all. This approach can reduce the >> translation box's complexity. Also, the FTP client and server's >> communication without ALG will significantly improve its >> performance. >> >> For the legacy IPv6 FTP client, this document suggests that the >> legacy client should behave like RFC1579 recommendation >> which is that >> "vendors convert their FTP clients programs to use PASV instead of >> PORT". For IPv6 FTP client, this recommendation should be >> "the users >> or vendors should convert their FTP clients programs to use EPSV >> instead of EPRT". This can be done by configuration and do not >> require upgrading of the client software for most of >> current IPv6 FTP >> client. This solution may require that the FTP server >> should support >> EPSV command. >> >> >> > A client that implements the client requirements and client >> > recommendations listed in draft-van-beijnum-behave-ftp64-05 will be >> > able to successfully interoperate with any server that >> implements EPSV >> > or PASV through a stateful or stateless translator. >> >> The solution in draft-van-beijnum-behave-ftp64-05 suggests that >> "However, the server will respond to the PASV command with an IPv4 >> address that the client must use to connect to for the data >> connection. If the client has IPv4 reachability, it SHOULD set up a >> data connection towards the IPv4 address." this may can not work in >> some cases, as draft-liu-behave-ftp64-02 mentioned:'" For example, >> if the FTP client has a private IPv4 connection and a public IPv6 >> connection, if it tries to use the IPv4 connection to establish data >> connection with the server, it will never success." >> >> >> Since updating an >> > FTP client is about the easiest possible upgrade that we could >> > possibly require (an FTP client doesn't need special privileges and >> > can run as a java applet in a browser) this provides a workable >> > solution for most users. >> >> aggree, this is what draft-liu-behave-ftp64-02 suggested. >> >> > However, there is additional benefit in making FTP through a >> > translator work for users with existing implementations, >> which can be >> > accomplished by either server upgrades or an ALG. >> >> Do not you think that server upgrading may be more reasonable from the >> evolution perspective? if the network contitue to provide ALG all the >> time, the server will never has motivation to upgrade, this will cause >> the ALGs in the translation box become more and more complex, since >> the translator will try to maintain ALGs for all the legacy >> implementations; and the legacy implementation never think about >> upgrading because they never aware the needs to upgrade. this approach >> may be convenient for a little part of the users but is harmful for >> the evolution of the network. >> >> > Since at least one vendor has expressed interest in >> implementing such >> > an ALG, having standard ALG functionality is better than >> undefined ALG >> > functionality and we have the text now anyway, in my opinion it >> > doesn't make sense to remove the ALG text, although I'm willing to >> > make it (even) more clear that such an ALG is optional. >> >> In my personal opioion, If the we do not recommend to implement FTP >> ALG, maybe we should not include any text to describe how to implement >> it for not misleading the reader. but maybe the text of ALG could be >> adjusted as an appendix, then there will be no contradiction. >> > >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > From dthaler@microsoft.com Thu Aug 27 10:14:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9203A6AFA for ; Thu, 27 Aug 2009 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+BpJ3iQS-ef for ; Thu, 27 Aug 2009 10:14:44 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 1925228C21B for ; Thu, 27 Aug 2009 10:14:44 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Aug 2009 10:14:50 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server id 14.0.639.13; Thu, 27 Aug 2009 10:14:50 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Thu, 27 Aug 2009 10:14:55 -0700 From: Dave Thaler To: Iljitsch van Beijnum Thread-Topic: [BEHAVE] DNS64 handling of multicast addresses Thread-Index: AQHKIltjsms8L0OPykSpkOnnN2XGN5CxEMmAgAlToYD//8pPEA== Date: Thu, 27 Aug 2009 17:14:46 +0000 Message-ID: References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> In-Reply-To: <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Andrew Sullivan , Stig Venaas , Xing Li , Mark Andrews , "behave@ietf.org" Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:14:44 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, August 27, 2009 6:26 AM > To: Dave Thaler > Cc: Xing Li; Stig Venaas; Andrew Sullivan; behave@ietf.org; Mark > Andrews > Subject: Re: [BEHAVE] DNS64 handling of multicast addresses > > On 22 aug 2009, at 0:04, Dave Thaler wrote: > > > I don't see why the DNS64 shouldn't be capable of doing multicast > > address translation too, if such is used. If, for example, a DNS64 > > is configured with a set of IPv4 prefixes and the corresponding IPv6 > > prefix for each, it shouldn't have to check whether the address is > > unicast or multicast. Of course either all prefixes have to have the > > same suffix algorithm (zero-pad and embed, or embed and zero-pad, or > > whatever else) or else you have to configure the algorithm per prefix > > too. > > I haven't followed the multicast discussion in detail, but the problem > here is that in IPv6, there is scope information encoded in multicast > addresses. This information isn't present in IPv4 multicast > addressing, or at least not to the same degree. This means that it's > necessary to add this information during the translation, and AFAIK > this information can't be defaulted or algorithmically derived, so > this requires additional configuration. I would expect this to be trivially configurable simply by configuring a set of IPv6 prefixes and corresponding IPv4 prefixes. I.e. no different from what you'd support for unicast, and I see no reason to distinguish unicast from multicast for this purpose. -Dave From maxpassion@gmail.com Thu Aug 27 10:24:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1223A6E71 for ; Thu, 27 Aug 2009 10:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.641, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpQhArXFknIw for ; Thu, 27 Aug 2009 10:24:53 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 74B523A6D39 for ; Thu, 27 Aug 2009 10:24:53 -0700 (PDT) Received: by vws7 with SMTP id 7so964508vws.29 for ; Thu, 27 Aug 2009 10:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VOriVVDdojn9dP8ihL1jED12ejj7kIt4+h3QYo8l5M0=; b=bdsVJR50zL4VTS43LVnhG9PF0G5YJXNy/gtW5Qmy79SjjQnmX26cqfit6aupUVkKmL x6C59p2yWWRTlkDJXzM/UOA5kqp03nacTRQEEdO5Xh3nanMoyJxNbjFGNnXpY7VjG166 0j6uEFooWR5exvKwpDL7F8vInlcv7cOvJGuZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xXSHx/KMqLCGG2f+Yz8jIQHGXdJr67lL+E3irmqwDxpHBqvP2fmn5tamSSjN6GUaIZ z64baTC/RE2zJYWiUbHEN/hU1JH33t4gq17m6EnQx/TbBWhCwQjxj4Jt7pnjJh+1aYRT Vxacu+xyMtjUHMTWotMxIO1wiN+MBvYOlLmzE= MIME-Version: 1.0 Received: by 10.220.18.78 with SMTP id v14mr13333364vca.102.1251393897112; Thu, 27 Aug 2009 10:24:57 -0700 (PDT) In-Reply-To: <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> Date: Fri, 28 Aug 2009 01:24:56 +0800 Message-ID: <25e1aaa40908271024v19606fdaq9e577227c393b00d@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:24:54 -0000 2009/8/28, Dan Wing : > > >> -----Original Message----- >> From: Reinaldo Penno [mailto:rpenno@juniper.net] >> Sent: Wednesday, August 26, 2009 10:42 PM >> To: Dan Wing; Iljitsch van Beijnum; liu dapeng >> Cc: behave@ietf.org >> Subject: Re: [BEHAVE] A New Draft on FTP64 >> >> Hello, >> >> I'm taking about draft-van-beijnum-behave-ftp64-05.txt > > That document explains how current IPv6 FTP clients work > in conjunction with current IPv4 FTP servers, and where > there is breakage; it does not expect IPv4 FTP servers > will change (which is BEHAVE's same expectation for IPv4 > HTTP servers, for that matter). it seems in section 3 "server requirements", there will be some requirement for the server? also it seems to specify some requirement for the client in section 4. > -d > > >> Thanks, >> >> Reinaldo >> >> >> On 8/26/09 6:22 PM, "Dan Wing" wrote: >> >> >> What is the purpose of this document? Is it to make current >> >> FTP6 clients work with current FTP4 servers? Or is it to give >> >> guidance to future FTP6 and FTP4 implementations? >> > >> > There are two FTP64-related documents. I'm not sure which one you >> > are referring to when you say 'this document': >> > >> > * draft-van-beijnum-behave-ftp64-05.txt >> > >> > This document describes how existing IPv6 FTP clients and existing >> > IPv4 FTP servers function, and explains how an FTP ALG is >> useful if >> > a NAT64 operator wants those existing FTP clients and FTP >> servers to >> > work through a 6/4 translator. >> > >> > This document was accepted in Stockholm as a WG document. >> I am very >> > close to sending a request to the mailing list to adopt it as a WG >> > document, but I am waiting for our new charter (and the >> FTP-related >> > milestone in it) to be accepted by IESG. >> > >> > * draft-liu-behave-ftp64-01.txt describes how IPv6 FTP clients can >> > be changed to function across a NAT64, so that the NAT64 doesn't >> > need to have an FTP ALG. >> > >> > This document is probably most appropriate in the >> applications area >> > as it describes a change in how the FTP applications are >> supposed to >> > work when operating across a translator. >> > >> > -d >> > >> >> The problem at hand as I understand it is to make current >> clients and >> >> servers (that already work through FTP NAT44) to work through >> >> FTP NAT64 without change. If that is the case then ALG part >> >> is crucial. >> >> >> >> If the purpose is to guide future implementations although it >> >> has merit it >> >> does not help the problem at hand. >> >> >> >> If this turns out into one of those dogmatic discussions that >> >> NAT and ALGs >> >> are evil and the IETF does not provide a document specifying >> >> how FTP64 ALG >> >> should work, people are going to develop without guidance >> (once more). >> >> >> >> Hopefully we can reach some consensus on the purpose and >> scope of the >> >> document. >> >> >> >> Thanks, >> >> >> >> Reinaldo >> >> >> >> >> >> >> >> >> >> >> >> On 8/26/09 1:57 PM, "Iljitsch van Beijnum" >> wrote: >> >> >> >>> On 26 aug 2009, at 21:02, liu dapeng wrote: >> >>> >> >>>>> However, there is additional benefit in making FTP through a >> >>>>> translator work for users with existing implementations, >> >> which can be >> >>>>> accomplished by either server upgrades or an ALG. >> >>> >> >>>> Do not you think that server upgrading may be more >> >> reasonable from the >> >>>> evolution perspective? >> >>> >> >>> No. Many clients use EPSV today, and a good number of >> servers don't >> >>> work with those clients. Apparently the people that run >> >> these servers >> >>> don't care. >> >>> >> >>>> if the network contitue to provide ALG all the >> >>>> time, the server will never has motivation to upgrade, >> >>> >> >>> I'm afraid the opposite will happen, and people will stay >> away from >> >>> NAT64 because "it doesn't work". Waiting for IPv4 users to update >> >>> their stuff isn't the best strategy. >> >>> >> >>>> In my personal opioion, If the we do not recommend to >> implement FTP >> >>>> ALG, maybe we should not include any text to describe how >> >> to implement >> >>>> it for not misleading the reader. but maybe the text of >> >> ALG could be >> >>>> adjusted as an appendix, then there will be no contradiction. >> >>> >> >>> Does anyone else favor putting the ALG description in an appendix? >> >>> _______________________________________________ >> >>> Behave mailing list >> >>> Behave@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/behave >> >> >> >> _______________________________________________ >> >> Behave mailing list >> >> Behave@ietf.org >> >> https://www.ietf.org/mailman/listinfo/behave >> > >> > > From maxpassion@gmail.com Thu Aug 27 10:42:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B334C28C459 for ; Thu, 27 Aug 2009 10:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XR6JwPuwZBFB for ; Thu, 27 Aug 2009 10:42:00 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 752893A6D31 for ; Thu, 27 Aug 2009 10:42:00 -0700 (PDT) Received: by vws7 with SMTP id 7so977259vws.29 for ; Thu, 27 Aug 2009 10:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mBL8gHFPVIrmiWHmH2pKF2pgF6DFpktLTFX4ZWZA94o=; b=wURQAJHTAgOoXfkSZv1X4qZ467dSP9nzAA4MjG/+ql3n9PntxIExeec5XC4Mmo8R4R t+8NItQNI+8cfjJdMEOPLgnc3GyU5FJ5Be3M1V12N3p1Tl6nAz0AxjgrjiLIMSmxfqYr mc0/cIc1rzA//jPaEtBWM1YT5PMj9GGckGZ30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ffSPPHyGYLskNtOpMM411nwVDYb/Cw4qQtCMx2/8bOEPx6KkgaFEAxBYm+QXGp4clM zh8fO0o80+T1l89DuVpiOF6SQg1fOW2l/9UR21XAFVj206qv4F437u8HO0jjsR0EZbxs UxJUwYsAk2523dzjKCP0AQn2oQdWeUHRKR4+I= MIME-Version: 1.0 Received: by 10.220.111.80 with SMTP id r16mr40647vcp.76.1251394924254; Thu, 27 Aug 2009 10:42:04 -0700 (PDT) In-Reply-To: <000701ca2733$9ec44a40$c5f0200a@cisco.com> References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> Date: Fri, 28 Aug 2009 01:42:03 +0800 Message-ID: <25e1aaa40908271042v5b603191p771cdc4aa278610c@mail.gmail.com> From: liu dapeng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:42:02 -0000 2009/8/28, Dan Wing : >> >> I'm taking about draft-van-beijnum-behave-ftp64-05.txt >> >> > That document explains how current IPv6 FTP clients work >> > in conjunction with current IPv4 FTP servers, and where >> > there is breakage; it does not expect IPv4 FTP servers >> > will change (which is BEHAVE's same expectation for IPv4 >> > HTTP servers, for that matter). >> >> That's not completely accurate. The document does make modifications >> to RFCs 959 and 2428, imposing new requirements on both clients and >> servers. This is in line with the feedback I got from the >> applications people. > > My interpretation of draft-van-beijnum-behave-ftp64-05 requirements > boil down to 'support EPSV as specified in RFC2428', and the only > additional thing you're requiring is that the IP address of the > data channel is the same as the IP address as the control channel; it seems in draft-van-beijnum-behave-ftp64-05, it suggests that "However, the server will respond to the PASV command with an IPv4 address that the client must use to connect to for the data connection. If the client has IPv4 reachability, it SHOULD set up a data connection towards the IPv4 address. " draft-liu-behave-ftp64-03 points out this approach may cause some issues, and suggests that just simply use control channel's IP address. > but my testing showed that every FTP server I tested on the Internet > already met that additional requirement. the serve may allow the client to establish data connection using the control channel's IP address, but how about the client that has to ignore the PASV respond message's IP address and simply using the control channel's IP address? does the client already support this or it will require the client to upgrade? Are the FEAT requirements > new, too? (afterall, I don't think previous FTP specifications > required FEAT to agree with the actual features of the FTP server; > rather, it's just assumed an FTP server would do that because > it is reasonable). That is, excepting perhaps FEAT, requirements are > not 'new', and nearly any deployed IPv4 FTP server or deployed IPv6 > FTP client would already meet them. If you feel one wouldn't, > please say so (as I know you will!). > > My interpretation of draft-liu-behave-ftp64-03 is that it > suggests more substantial changes to requirements, Actually, draft-liu-behave-ftp64-03 does not have more requriment for the client and server, expect that it suggests to simply use the control channel's IP address when it retry with PASV command. Besides, draft-liu-behave-ftp64-03 gives the clear opinion that it suggests that if the client and server comply with this document then it will not need FTP ALG in NAT64. to the point > that existing deployed IPv6 FTP clients and existing, deployed > IPv4 FTP servers are unlikely to comply with draft-liu-behave-ftp64-03. > > -d > > From iljitsch@muada.com Thu Aug 27 10:44:00 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE423A6E3C for ; Thu, 27 Aug 2009 10:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy9yjssA8xXz for ; Thu, 27 Aug 2009 10:43:59 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id EB55228C1EF for ; Thu, 27 Aug 2009 10:42:39 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7RHg24k028709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 19:42:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <5750ACEE-DEAE-4A3C-8B29-40EC9B9AA47D@muada.com> From: Iljitsch van Beijnum To: Dan Wing In-Reply-To: <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Aug 2009 19:42:35 +0200 References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com><25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com><59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:44:00 -0000 On 27 aug 2009, at 3:11, Dan Wing wrote: > Would it be better to just try PASV first (and for the data channel, > the FTP client should use the IP address of the control channel, > ignoring what is in the PASV response) and if *that* fails it means > the FTP server is really listening on IPv6 and refuses to use PASV > and wants EPSV, so you only use EPSV after PASV returns an error? I can't definitively say that won't work, but the responses IPv6 FTP servers send after a PASV command make me not want to go down this path. We know that with EPSV 65% of the v4 servers and 100% of the v6 servers work, which I wouldn't want to risk breaking. If you want I'll send some examples tomorrow, currently my IPv6 tunnel is having a bad hair day or some such... Iljitsch From iljitsch@muada.com Thu Aug 27 10:50:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547E328C664 for ; Thu, 27 Aug 2009 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKh2ILCM9ppf for ; Thu, 27 Aug 2009 10:50:20 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D5DD128C666 for ; Thu, 27 Aug 2009 10:49:41 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7RHn46x028796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 19:49:05 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Dan Wing In-Reply-To: <000701ca2733$9ec44a40$c5f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Aug 2009 19:49:38 +0200 References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 17:50:21 -0000 On 27 aug 2009, at 18:29, Dan Wing wrote: > That is, excepting perhaps FEAT, requirements are > not 'new', and nearly any deployed IPv4 FTP server or deployed IPv6 > FTP client would already meet them. If you feel one wouldn't, > please say so (as I know you will!). The feat stuff is new, most servers don't do it as specified in the draft now. Also the ability to turn off EPSV and EPSV itself as a requirement are new. On the client side, the requirement to support EPSV shouldn't be a big deal, I doubt any other IPv6-capable clients than the windows command line one don't support this. The PASV stuff is not a requirement. > My interpretation of draft-liu-behave-ftp64-03 is that it > suggests more substantial changes to requirements, to the point > that existing deployed IPv6 FTP clients and existing, deployed > IPv4 FTP servers are unlikely to comply with draft-liu-behave- > ftp64-03. It goes a step or two further, yes, but down a road already taken by draft-van-beijnum-behave-ftp64-05. We currently have one or more people feeling that an ALG is required and one or more people that feel it's a bad idea. The draft allows for both, and also mandates a way for users to make the ALG go into transparent mode, so I'm thinking we're ready to declare victory...? (I'll address the smaller issues in the next version.) From maxpassion@gmail.com Thu Aug 27 11:07:13 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87BE28C5FA for ; Thu, 27 Aug 2009 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6-dpNvtxgrm for ; Thu, 27 Aug 2009 11:07:13 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id DA7C228C5C1 for ; Thu, 27 Aug 2009 11:07:12 -0700 (PDT) Received: by vws7 with SMTP id 7so997283vws.29 for ; Thu, 27 Aug 2009 11:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+2GXI2lcRONHk6BLcfNE4Fjtt8+5HLYbA3fNNTQ8YbI=; b=j1urDKepiOdukFNMc59MWuemmaIBR0dHi7hBJWH+brypXoYX2Nq2dgMk1OmoqVTtEn s4u0i653TCzk1BzenVPwMh8IdkLCVWlEJtPTiTOssPA5j00ExKTyRhSItzUVVqnmsHQs V2xElGpzwzTlqqOqn0xvuWYjuco9quds2LtO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WoMsYuFxDKdFy91clv/IMWPHRsEcl13JDxrLMNk7wJeggIK9bCOrjfYxgAQwjpW9pV s+Lb5SUV/X08M6D5p2Fx6XYWfK2JYdtwOpymvwnM1S+FtD/EsC6mWEl6NxWMiPNUlDF5 qVnXhzEcMNSC6dSudms7v0Bgpcy28kXmPZiC8= MIME-Version: 1.0 Received: by 10.220.127.202 with SMTP id h10mr108306vcs.54.1251396436677; Thu, 27 Aug 2009 11:07:16 -0700 (PDT) In-Reply-To: References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> Date: Fri, 28 Aug 2009 02:07:16 +0800 Message-ID: <25e1aaa40908271107r308f648fr20a467c0671802@mail.gmail.com> From: liu dapeng To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:07:13 -0000 2009/8/28, Iljitsch van Beijnum : > On 27 aug 2009, at 18:29, Dan Wing wrote: > >> That is, excepting perhaps FEAT, requirements are >> not 'new', and nearly any deployed IPv4 FTP server or deployed IPv6 >> FTP client would already meet them. If you feel one wouldn't, >> please say so (as I know you will!). > > The feat stuff is new, most servers don't do it as specified in the > draft now. Also the ability to turn off EPSV and EPSV itself as a > requirement are new. > > On the client side, the requirement to support EPSV shouldn't be a big > deal, I doubt any other IPv6-capable clients than the windows command > line one don't support this. The PASV stuff is not a requirement. > >> My interpretation of draft-liu-behave-ftp64-03 is that it >> suggests more substantial changes to requirements, to the point >> that existing deployed IPv6 FTP clients and existing, deployed >> IPv4 FTP servers are unlikely to comply with draft-liu-behave- >> ftp64-03. > > It goes a step or two further, yes, but down a road already taken by > draft-van-beijnum-behave-ftp64-05. > > We currently have one or more people feeling that an ALG is required > and one or more people that feel it's a bad idea. The draft allows for > both, and also mandates a way for users to make the ALG go into > transparent mode, so I'm thinking we're ready to declare victory...? my question is: should we simply put the different opinions (maybe opposite) together to make a specification or should we investigate the problems more deeply and try to make a specification that could best solve the problem? > (I'll address the smaller issues in the next version.) > From dwing@cisco.com Thu Aug 27 11:10:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE8128C1FF for ; Thu, 27 Aug 2009 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=-2.028, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgKfrEqQgViv for ; Thu, 27 Aug 2009 11:10:06 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1C51528C11B for ; Thu, 27 Aug 2009 11:10:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAFRplkqrR7PD/2dsb2JhbACLFrYxiD4BkAwFhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="186180230" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 27 Aug 2009 18:10:12 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7RIACAv011113; Thu, 27 Aug 2009 11:10:12 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7RIAC2e022090; Thu, 27 Aug 2009 18:10:12 GMT From: "Dan Wing" To: "'liu dapeng'" References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> <25e1aaa40908271011t72fab84fsd65b28f3469c9121@mail.gmail.com> Date: Thu, 27 Aug 2009 11:10:12 -0700 Message-ID: <007a01ca2741$9ef7adf0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <25e1aaa40908271011t72fab84fsd65b28f3469c9121@mail.gmail.com> Thread-Index: AconOXtg9QKxkP2VRFSORmkfQsBsGQAB993w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9488; t=1251396612; x=1252260612; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=cslSGnlqcQUOh4u3lQYiE8u1Fdnx7nKID1fxBBd1vu0=; b=LQqRXt9PBg2/vrzoq+QeEHRwOF6q2OpzvizhnnT4f5qJPD8XYcS6MhJxLs gLqXuNB6xmLjTsn1+gKI3tMzsLILnMnhH0LL1iE/4/lYH+A1ORUl1MR+ZSHL 7IA0Ep5/Vl; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:10:10 -0000 > -----Original Message----- > From: liu dapeng [mailto:maxpassion@gmail.com] > Sent: Thursday, August 27, 2009 10:12 AM > To: Dan Wing > Cc: behave@ietf.org; Iljitsch van Beijnum > Subject: Re: [BEHAVE] A New Draft on FTP64 > > 2009/8/27, Dan Wing : > > > > > >> -----Original Message----- > >> From: behave-bounces@ietf.org > >> [mailto:behave-bounces@ietf.org] On Behalf Of liu dapeng > >> Sent: Wednesday, August 26, 2009 12:03 PM > >> To: Iljitsch van Beijnum > >> Cc: behave@ietf.org > >> Subject: Re: [BEHAVE] A New Draft on FTP64 > >> > >> 2009/8/25, Iljitsch van Beijnum : > >> > On 24 aug 2009, at 19:40, liu dapeng wrote: > >> > > >> >> We upgrade the ftp64 draft, add some text considering the > >> legacy FTP > >> >> implementation and other clarification as well. Any comments are > >> >> welcomed. > >> > > >> > Can you please send the new text to the list? > >> > >> we upgrade setion 3 and 5, bellow is the text. > >> > >> 3. Client considerations > >> > >> It is required that all IPv6 FTP clients MUST support > both EPSV and > >> PASV command. > >> > >> When the client tries to connect to a server using IPv6 > connection, > >> it should use EPSV command first. If the server response > >> that it does > >> not support this command or encounters an error, it > MUST retry with > >> PASV command. > > > > That algorithm will cause a timeout -- not an error -- with some FTP > > servers. For example, ftp.dell.com responds positively to EPSV but > > does not actually allow connecting to the port indicated on the FTP > > control channel. Other sites, such as ftp.microsoft.com, work just > > fine with EPSV. > > > > Would it be better to just try PASV first (and for the data channel, > > the FTP client should use the IP address of the control channel, > > ignoring what is in the PASV response) and if *that* fails it means > > the FTP server is really listening on IPv6 and refuses to use PASV > > and wants EPSV, so you only use EPSV after PASV returns an error? > > my question is: the server is in an IPv4 network, if the PASV fails, > why does it expect EPSV command? I agree. But the problem is that the IPv6 FTP client doesn't know if the AAAA response is 'real' or was synthesized, so the FTP client doesn't know if the FTP server is listening on IPv4 (and thus PASV should work) or listening on IPv6 (and thus EPSV should work). -d > > -d > > > > > >> The server will respond to PASV command with > >> an message > >> that contains an IPv4 address and port number that used for the > >> client to connect to. The client MUST ignores the IPv4 address > >> provided in the response; it should use the control > connection's IP > >> address to connect to the server to establish the data > connection. > >> > >> This approach could not only simply the FTP client software's > >> implementation but also can avoid the problems caused > by using the > >> IPv4 address that included in the response message. For > example, if > >> the FTP client has a private IPv4 connection and a public IPv6 > >> connection, if it tries to use the IPv4 connection to > >> establish data > >> connection with the server, it will never success. > >> > >> > >> 5. FTP ALG considerations > >> > >> 5.1. FTP ALG limitations > >> > >> Implementing FTP ALG in the translation box may have some > >> limitations, > >> such as: > >> > >> 1) FTP ALG may case to increase the complexity of > translation box, > >> since FTP ALG needs to understand FTP protocol and > translate the > >> application layer payload and update the header of > FTP control > >> packets. > >> > >> > >> Dapeng Liu Expires February 27, 2010 > [Page 4] > >> > > >> Internet-Draft IPv6 IPv4 translation FTP considerations > August 2009 > >> > >> > >> 2) For most of current Network Processor based > translation box, ALG > >> processing may cause its performance decreased > >> significantly. The > >> reason is that FTP ALG processing can not take the > advantage of > >> Network Processor, which is designed and optimized for > >> processing > >> regular packets (such as header translation). > >> > >> 3) From the evolution perspective, if the network continues to > >> provide support of FTP ALG all the time, the users > will have no > >> motivation to upgrade their FTP client software. If > >> things evolve > >> toward this direction, the ALG function of the > translation box > >> will become more and more complex. In reality, upgrading FTP > >> client software is a more easy way to solve the ALG issue > >> compared with requiring that all the translation box to > >> implement > >> FTP ALG. > >> > >> 5.2. Solution to avoid FTP ALG > >> > >> This document suggests that the translation box which situated > >> between the IPv6 network and IPv4 network should not > implement FTP > >> ALG. It is depend on the client and server that comply with this > >> specification to avoid the FTP ALG issue. > >> > >> The reason that this document does not encourage > translation box to > >> implement FTP ALG is that since the FTP ALG problem can > be totally > >> avoid by defining the behavior of the client and > server, it is not > >> necessary to implement it at all. This approach can reduce the > >> translation box's complexity. Also, the FTP client and server's > >> communication without ALG will significantly improve its > >> performance. > >> > >> For the legacy IPv6 FTP client, this document suggests that the > >> legacy client should behave like RFC1579 recommendation > >> which is that > >> "vendors convert their FTP clients programs to use PASV > instead of > >> PORT". For IPv6 FTP client, this recommendation should be > >> "the users > >> or vendors should convert their FTP clients programs to use EPSV > >> instead of EPRT". This can be done by configuration and do not > >> require upgrading of the client software for most of > >> current IPv6 FTP > >> client. This solution may require that the FTP server > >> should support > >> EPSV command. > >> > >> > >> > A client that implements the client requirements and client > >> > recommendations listed in > draft-van-beijnum-behave-ftp64-05 will be > >> > able to successfully interoperate with any server that > >> implements EPSV > >> > or PASV through a stateful or stateless translator. > >> > >> The solution in draft-van-beijnum-behave-ftp64-05 suggests that > >> "However, the server will respond to the PASV command with an IPv4 > >> address that the client must use to connect to for the data > >> connection. If the client has IPv4 reachability, it > SHOULD set up a > >> data connection towards the IPv4 address." this may can not work in > >> some cases, as draft-liu-behave-ftp64-02 mentioned:'" > For example, > >> if the FTP client has a private IPv4 connection and a public IPv6 > >> connection, if it tries to use the IPv4 connection to > establish data > >> connection with the server, it will never success." > >> > >> > >> Since updating an > >> > FTP client is about the easiest possible upgrade that we could > >> > possibly require (an FTP client doesn't need special > privileges and > >> > can run as a java applet in a browser) this provides a workable > >> > solution for most users. > >> > >> aggree, this is what draft-liu-behave-ftp64-02 suggested. > >> > >> > However, there is additional benefit in making FTP through a > >> > translator work for users with existing implementations, > >> which can be > >> > accomplished by either server upgrades or an ALG. > >> > >> Do not you think that server upgrading may be more > reasonable from the > >> evolution perspective? if the network contitue to provide > ALG all the > >> time, the server will never has motivation to upgrade, > this will cause > >> the ALGs in the translation box become more and more complex, since > >> the translator will try to maintain ALGs for all the legacy > >> implementations; and the legacy implementation never think about > >> upgrading because they never aware the needs to upgrade. > this approach > >> may be convenient for a little part of the users but is harmful for > >> the evolution of the network. > >> > >> > Since at least one vendor has expressed interest in > >> implementing such > >> > an ALG, having standard ALG functionality is better than > >> undefined ALG > >> > functionality and we have the text now anyway, in my opinion it > >> > doesn't make sense to remove the ALG text, although I'm > willing to > >> > make it (even) more clear that such an ALG is optional. > >> > >> In my personal opioion, If the we do not recommend to implement FTP > >> ALG, maybe we should not include any text to describe how > to implement > >> it for not misleading the reader. but maybe the text of > ALG could be > >> adjusted as an appendix, then there will be no contradiction. > >> > > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > > > > From iljitsch@muada.com Thu Aug 27 11:11:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF023A70AE for ; Thu, 27 Aug 2009 11:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+4SyDLxqbs0 for ; Thu, 27 Aug 2009 11:11:27 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0283A691A for ; Thu, 27 Aug 2009 11:11:27 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7RIAPUr028972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 20:10:26 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: liu dapeng In-Reply-To: <25e1aaa40908271107r308f648fr20a467c0671802@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Aug 2009 20:10:59 +0200 References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> <25e1aaa40908271107r308f648fr20a467c0671802@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:11:28 -0000 On 27 aug 2009, at 20:07, liu dapeng wrote: >> We currently have one or more people feeling that an ALG is required >> and one or more people that feel it's a bad idea. The draft allows >> for >> both, and also mandates a way for users to make the ALG go into >> transparent mode, so I'm thinking we're ready to declare victory...? > my question is: should we simply put the different opinions (maybe > opposite) together to make a specification or should we investigate > the problems more deeply and try to make a specification that could > best solve the problem? The problem is that there is no objective "best". For some people the extra state required by an ALG would be expensive but changing the clients wouldn't be, for others an ALG is no problem but they have little control over the clients so they can't change them or this involves expensive support calls. From maxpassion@gmail.com Thu Aug 27 11:13:32 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430D128C1EF for ; Thu, 27 Aug 2009 11:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cpGDAmi66SR for ; Thu, 27 Aug 2009 11:13:31 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 8E78328C2EB for ; Thu, 27 Aug 2009 11:12:32 -0700 (PDT) Received: by vws7 with SMTP id 7so1001818vws.29 for ; Thu, 27 Aug 2009 11:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=A9yfk4aaTtCxjw3Gpvtg779k5dTdRJuyIW4IEKGgBCQ=; b=JwvamKXB7ICcnnrz8oN9xGHhvFZdYsHOLOgFkZEk6AWZG+AvrCkBv5ZwNcFAq0TxQh vw4BiZZcObb/OfFI+Tg9RedYKEAbxE1jrGxptStrczy8kFVXsF1XpI/GlFsxuzsjomCE sRmd+GObKYSzm/osSfgkgLsi79wNIjUXCW/h0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KYxWkSuPMk4uXiDQ4YOpVg6eNXfduD7QmkTuOyyyAHzjP64Jdj95M36NMkRdEGGice yR1x4JwHLT+7Ixfp/K3u7VFAk/De/F9cRNfkXq0iYPbRZLsrVxDDZ+6/xHRPOjHGRat7 V4S19N3MFxzEjPOeZpkNItWXR5EHJ5PFixVuc= MIME-Version: 1.0 Received: by 10.220.111.80 with SMTP id r16mr97290vcp.76.1251396756311; Thu, 27 Aug 2009 11:12:36 -0700 (PDT) In-Reply-To: <5750ACEE-DEAE-4A3C-8B29-40EC9B9AA47D@muada.com> References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> <5750ACEE-DEAE-4A3C-8B29-40EC9B9AA47D@muada.com> Date: Fri, 28 Aug 2009 02:12:36 +0800 Message-ID: <25e1aaa40908271112p1a596679o623d48d50dc6bf4f@mail.gmail.com> From: liu dapeng To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:13:32 -0000 2009/8/28, Iljitsch van Beijnum : > On 27 aug 2009, at 3:11, Dan Wing wrote: > >> Would it be better to just try PASV first (and for the data channel, >> the FTP client should use the IP address of the control channel, >> ignoring what is in the PASV response) and if *that* fails it means >> the FTP server is really listening on IPv6 and refuses to use PASV >> and wants EPSV, so you only use EPSV after PASV returns an error? > > I can't definitively say that won't work, but the responses IPv6 FTP > servers send after a PASV command make me not want to go down this > path. We know that with EPSV 65% of the v4 servers and 100% of the v6 > servers work, which I wouldn't want to risk breaking. > If you want I'll send some examples tomorrow, currently my IPv6 tunnel > is having a bad hair day or some such... yes, it maybe better if you send some examples or explain this in detail. thanks. > Iljitsch > > > From iljitsch@muada.com Thu Aug 27 11:13:33 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D333A6F63 for ; Thu, 27 Aug 2009 11:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dJW+wzMOtTO for ; Thu, 27 Aug 2009 11:13:33 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id F211E28C5C1 for ; Thu, 27 Aug 2009 11:13:27 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7RICUel029025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 20:12:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Dan Wing" In-Reply-To: <007a01ca2741$9ef7adf0$c5f0200a@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 Aug 2009 20:13:04 +0200 References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com> <25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com> <59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> <25e1aaa40908271011t72fab84fsd65b28f3469c9121@mail.gmail.com> <007a01ca2741$9ef7adf0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:13:34 -0000 On 27 aug 2009, at 20:10, Dan Wing wrote: Not going to repeat all of that... The proof of the pudding is in the eating. If EPSV works, it works. If it doesn't, do PASV. The only downside is that it can take a while to not work, but for FTP that shouldn't be fatal. From dwing@cisco.com Thu Aug 27 11:19:01 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744D328C2FA for ; Thu, 27 Aug 2009 11:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.675 X-Spam-Level: X-Spam-Status: No, score=-6.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avCxiFTsUyaA for ; Thu, 27 Aug 2009 11:19:00 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6234328C2E6 for ; Thu, 27 Aug 2009 11:18:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEALdqlkqrR7PD/2dsb2JhbACLFrYZiD4BkAoFhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="199595588" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2009 18:18:29 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7RIITEU029697; Thu, 27 Aug 2009 11:18:29 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7RIISHF029075; Thu, 27 Aug 2009 18:18:28 GMT From: "Dan Wing" To: "'liu dapeng'" References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> <25e1aaa40908271042v5b603191p771cdc4aa278610c@mail.gmail.com> Date: Thu, 27 Aug 2009 11:18:28 -0700 Message-ID: <007e01ca2742$c6cd5270$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <25e1aaa40908271042v5b603191p771cdc4aa278610c@mail.gmail.com> Thread-Index: AconPbEHMo+BMzwSToqPokRUxGQIegABCofQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4268; t=1251397109; x=1252261109; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=BxRc+0MiDQwfPN7EG8Xpib8E0k/ZuyPhl8zAnPeat20=; b=trPqP09O6/anKWQwwPj3AJAaXSbNyPXgZtEG0gm/PeN6BueeMhPii2GErL 8D3lq+xfTG+STxj5Vt7jhZCZ9jJGdiaBJg2znY41ALOMVWjdf+FjsPQmo3Bz MQoRDfhc0S; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:19:01 -0000 > -----Original Message----- > From: liu dapeng [mailto:maxpassion@gmail.com] > Sent: Thursday, August 27, 2009 10:42 AM > To: Dan Wing > Cc: Iljitsch van Beijnum; Reinaldo Penno; behave@ietf.org > Subject: Re: [BEHAVE] A New Draft on FTP64 > > 2009/8/28, Dan Wing : > >> >> I'm taking about draft-van-beijnum-behave-ftp64-05.txt > >> > >> > That document explains how current IPv6 FTP clients work > >> > in conjunction with current IPv4 FTP servers, and where > >> > there is breakage; it does not expect IPv4 FTP servers > >> > will change (which is BEHAVE's same expectation for IPv4 > >> > HTTP servers, for that matter). > >> > >> That's not completely accurate. The document does make > modifications > >> to RFCs 959 and 2428, imposing new requirements on both clients and > >> servers. This is in line with the feedback I got from the > >> applications people. > > > > My interpretation of draft-van-beijnum-behave-ftp64-05 requirements > > boil down to 'support EPSV as specified in RFC2428', and the only > > additional thing you're requiring is that the IP address of the > > data channel is the same as the IP address as the control channel; > > it seems in draft-van-beijnum-behave-ftp64-05, it suggests that > "However, the server will respond to the PASV command with > an IPv4 address that the client must use to connect to for the data > connection. If the client has IPv4 reachability, it > SHOULD set up a > data connection towards the IPv4 address. " > > draft-liu-behave-ftp64-03 points out this approach may cause some > issues, and suggests that just simply use control channel's IP > address. Yes, that is one place where the drafts differ. Hopefully we can reach consensus on what the FTP client should best do. > > but my testing showed that every FTP server I tested on the Internet > > already met that additional requirement. > > the serve may allow the client to establish data connection using the > control channel's IP address, but how about the client that has to > ignore the PASV respond message's IP address and simply using the > control channel's IP address? does the client already support this or > it will require the client to upgrade? I have no way to test all the FTP clients on the Internet. I can, however, test all the FTP servers that are publicly accessible and have run tests against over 2000 of them. See ftp://ftp-eng.cisco.com/dwing/ftp-epsv > > Are the FEAT requirements > > new, too? (afterall, I don't think previous FTP specifications > > required FEAT to agree with the actual features of the FTP server; > > rather, it's just assumed an FTP server would do that because > > it is reasonable). That is, excepting perhaps FEAT, > requirements are > > not 'new', and nearly any deployed IPv4 FTP server or deployed IPv6 > > FTP client would already meet them. If you feel one wouldn't, > > please say so (as I know you will!). > > > > My interpretation of draft-liu-behave-ftp64-03 is that it > > suggests more substantial changes to requirements, > > Actually, draft-liu-behave-ftp64-03 does not have more requriment for > the client and server, expect that it suggests to simply use the > control channel's IP address when it retry with PASV command. > > Besides, draft-liu-behave-ftp64-03 gives the clear opinion that it > suggests that if the client and server comply with this document then > it will not need FTP ALG in NAT64. Here is where we stand: The IETF will have no success in modifying the behavior of IPv4 FTP servers on the Internet, in the timeframe necessary for deployment of NAT64 devices (~2011-2012). There is a chance we could have success in modifying behavior of IPv6 FTP clients that are behind NAT64 translators. We are certainly able to influence how FTP ALGs, built into NAT64 translators, should function in the event one of today's IPv6 FTP clients is trying to communicate with one of today's IPv4 FTP servers through a NAT64. -d > > to the point > > that existing deployed IPv6 FTP clients and existing, deployed > > IPv4 FTP servers are unlikely to comply with > > draft-liu-behave-ftp64-03. > > > > -d > > > > From dwing@cisco.com Thu Aug 27 11:19:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF5928C309 for ; Thu, 27 Aug 2009 11:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.673 X-Spam-Level: X-Spam-Status: No, score=-6.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eHCkinz3GGU for ; Thu, 27 Aug 2009 11:19:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 08A463A6D91 for ; Thu, 27 Aug 2009 11:19:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAGtrlkqrR7PD/2dsb2JhbACLFrYciD4BkAoFhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="376678217" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Aug 2009 18:19:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n7RIJ8Mk031304; Thu, 27 Aug 2009 11:19:08 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n7RIJ79w023275; Thu, 27 Aug 2009 18:19:07 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <25e1aaa40908200659y629eb05eg5c2f269f11f07f57@mail.gmail.com><25e1aaa40908241040kbf5cb50k904262a307f526f1@mail.gmail.com><59B59B7F-D8E3-4414-8FB3-4EFE8F8D30B8@muada.com> <25e1aaa40908261202m371f6bf7hc912efd86c50d775@mail.gmail.com> <002001ca26b3$5edfb0c0$c5f0200a@cisco.com> <5750ACEE-DEAE-4A3C-8B29-40EC9B9AA47D@muada.com> Date: Thu, 27 Aug 2009 11:19:07 -0700 Message-ID: <007f01ca2742$ddead540$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <5750ACEE-DEAE-4A3C-8B29-40EC9B9AA47D@muada.com> Thread-Index: AconPcl3YxnErd0jQniiHRPiaOG04wABRHJQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1100; t=1251397148; x=1252261148; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=3VWld0Rus/9IP2RKRGP0lXDJDr8b7zGm8Dmar6xPmJs=; b=kHpeMJwEcQ7yL2CwFu0FS7YSsT0EcCyyPip24PJu9+TkBDpR3pZWFDaC3d QIQS2RrjaQYhqM1/u4JnkosqMREWQZqNrkJW+R+Svv/adqk0+IEtPeqXhIio JjvsM7ulxQ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:19:07 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, August 27, 2009 10:43 AM > To: Dan Wing > Cc: 'liu dapeng'; behave@ietf.org > Subject: Re: [BEHAVE] A New Draft on FTP64 > > On 27 aug 2009, at 3:11, Dan Wing wrote: > > > Would it be better to just try PASV first (and for the data channel, > > the FTP client should use the IP address of the control channel, > > ignoring what is in the PASV response) and if *that* fails it means > > the FTP server is really listening on IPv6 and refuses to use PASV > > and wants EPSV, so you only use EPSV after PASV returns an error? > > I can't definitively say that won't work, but the responses IPv6 FTP > servers send after a PASV command make me not want to go down this > path. We know that with EPSV 65% of the v4 servers and 100% > of the v6 > servers work, which I wouldn't want to risk breaking. Ok. -d > If you want I'll send some examples tomorrow, currently my > IPv6 tunnel > is having a bad hair day or some such... > > Iljitsch > > From dwing@cisco.com Thu Aug 27 11:21:13 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926A63A6C54 for ; Thu, 27 Aug 2009 11:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.671 X-Spam-Level: X-Spam-Status: No, score=-6.671 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTX5G3McvpUM for ; Thu, 27 Aug 2009 11:21:12 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C54633A698B for ; Thu, 27 Aug 2009 11:21:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAKdrlkqrR7O6/2dsb2JhbACLFrYgiD4BkAoFhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="186184160" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Aug 2009 18:21:19 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7RILJe2001477; Thu, 27 Aug 2009 11:21:19 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7RILJrK005089; Thu, 27 Aug 2009 18:21:19 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> Date: Thu, 27 Aug 2009 11:21:19 -0700 Message-ID: <008001ca2743$2c772ba0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AconPsT/Gz2+rl9TSwyrmLEFSdH7DwABB8RQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1990; t=1251397279; x=1252261279; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=YaK+JupNOLERcm3+ohMoVc1EpyCk5KtYc6ebc72TAC4=; b=BAntAR+/yI0yJkwSMK2HMW1+xRwwNgCusVPcp3eCoiiE0PYSvIzBRUC9Y6 BNABvGtIOMkuT89aQ6FGXnG0+OY/vRUTNIir9LVxGkO7HFYymPJCLToHjHMy j2y1gJ/pHf; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org, 'liu dapeng' Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:21:13 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, August 27, 2009 10:50 AM > To: Dan Wing > Cc: 'Reinaldo Penno'; 'liu dapeng'; behave@ietf.org > Subject: Re: [BEHAVE] A New Draft on FTP64 > > On 27 aug 2009, at 18:29, Dan Wing wrote: > > > That is, excepting perhaps FEAT, requirements are > > not 'new', and nearly any deployed IPv4 FTP server or deployed IPv6 > > FTP client would already meet them. If you feel one wouldn't, > > please say so (as I know you will!). > > The feat stuff is new, most servers don't do it as specified in the > draft now. Do FTP clients rely on FEAT? Does it benefit the clients (or servers) to use FEAT? Should the clients rely on FEAT working and rely on it accurately describing the supported commands (versus just trying to use a command and getting a 2xx or 5xx response)? > Also the ability to turn off EPSV and EPSV itself as a > requirement are new. > > On the client side, the requirement to support EPSV shouldn't > be a big > deal, I doubt any other IPv6-capable clients than the windows > command > line one don't support this. The PASV stuff is not a requirement. > > > My interpretation of draft-liu-behave-ftp64-03 is that it > > suggests more substantial changes to requirements, to the point > > that existing deployed IPv6 FTP clients and existing, deployed > > IPv4 FTP servers are unlikely to comply with draft-liu-behave- > > ftp64-03. > > It goes a step or two further, yes, but down a road already taken by > draft-van-beijnum-behave-ftp64-05. > > We currently have one or more people feeling that an ALG is required > and one or more people that feel it's a bad idea. The draft > allows for > both, and also mandates a way for users to make the ALG go into > transparent mode, so I'm thinking we're ready to declare victory...? > > (I'll address the smaller issues in the next version.) -d From dwing@cisco.com Thu Aug 27 11:25:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2745528C2F3 for ; Thu, 27 Aug 2009 11:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.669 X-Spam-Level: X-Spam-Status: No, score=-6.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jWTotoogJW9 for ; Thu, 27 Aug 2009 11:25:04 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 309B228C2BD for ; Thu, 27 Aug 2009 11:25:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEANJslkqrR7PE/2dsb2JhbACLFrYgiD4BkAsFhBmBWA X-IronPort-AV: E=Sophos;i="4.44,287,1249257600"; d="scan'208";a="186185613" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 27 Aug 2009 18:24:59 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7RIOu5r031663; Thu, 27 Aug 2009 11:24:56 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n7RIOtBZ008887; Thu, 27 Aug 2009 18:24:55 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'liu dapeng'" References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> <25e1aaa40908271107r308f648fr20a467c0671802@mail.gmail.com> Date: Thu, 27 Aug 2009 11:24:55 -0700 Message-ID: <008201ca2743$ad683420$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AconQc49IcmSR03rRQOURHiXL9e2BgAAZsYA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1438; t=1251397496; x=1252261496; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20A=20New=20Draft=20on=20FTP64 |Sender:=20; bh=rK+A3bkjrPw1/Aa0EMAzfE3+JHjP6ejTj4c/XX19R4A=; b=dG+60hR16P15l/8mWu8fRXBm6KOalkzKdgI4BRnFk26b9LD0T0YmdK8Zct un/XqsSROb13PAWDFiHq4lA9p0YibwfM3at3eJSR2co1hRQ82WVykhPZAFZv NySMOlKNwY; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:25:05 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, August 27, 2009 11:11 AM > To: liu dapeng > Cc: Dan Wing; Reinaldo Penno; behave@ietf.org > Subject: Re: [BEHAVE] A New Draft on FTP64 > > On 27 aug 2009, at 20:07, liu dapeng wrote: > > >> We currently have one or more people feeling that an ALG > is required > >> and one or more people that feel it's a bad idea. The > draft allows > >> for > >> both, and also mandates a way for users to make the ALG go into > >> transparent mode, so I'm thinking we're ready to declare > victory...? > > > my question is: should we simply put the different opinions (maybe > > opposite) together to make a specification or should we investigate > > the problems more deeply and try to make a specification that could > > best solve the problem? > > The problem is that there is no objective "best". For some > people the > extra state required by an ALG would be expensive but changing the > clients wouldn't be, for others an ALG is no problem but they have > little control over the clients so they can't change them or this > involves expensive support calls. A should discussion in the draft could clarify that. It would explain how someone installing a NAT64 should decide to enable/disable the FTP ALG, based on their knowledge of the IPv6 FTP clients behind their NAT64. -d From maxpassion@gmail.com Thu Aug 27 11:29:42 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462A23A6E33 for ; Thu, 27 Aug 2009 11:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, J_CHICKENPOX_82=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQHb+ODfw+4B for ; Thu, 27 Aug 2009 11:29:41 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 642633A6A2E for ; Thu, 27 Aug 2009 11:29:41 -0700 (PDT) Received: by vws7 with SMTP id 7so1014635vws.29 for ; Thu, 27 Aug 2009 11:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nwegKxR5yTM77Y425ZifXp0MXHFizJ541XLoNFQmRL8=; b=nCdQEAbcYvvVX1NQiP/oSbGMlnCCrJLcr1J2b4CYPn77deJ19DUaOUykgjrXB0Li2a PeogmNtd4GnlbragB2v+ldQuxIiRJLYekzaIM6i2Mr3Ut9JWnIrpu7cLhem6MEE7BaTs /0Yd2G6Vc3aTOSsva+5gnKm342AXhEG9n2Y00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YRvc+t0kIdoYPB/RGTMc6f7mMqutjpClzOOLbiN57QZsHrsGSAypymHBh38gM8NR7i qq0wlSXBbI9Uzpb25fVerTx4PWHi3q0x/UHUHT8dDoiuEBm1+oUUMY9MoOL4BhyDQJqp spkS9OOd4vQKv9nJu0ZforwYpvBsk8HMk8jL0= MIME-Version: 1.0 Received: by 10.220.127.202 with SMTP id h10mr149728vcs.54.1251397781835; Thu, 27 Aug 2009 11:29:41 -0700 (PDT) In-Reply-To: References: <002701ca26b4$d5154470$c5f0200a@cisco.com> <018b01ca2730$3c82f7d0$c5f0200a@cisco.com> <4ABC0242-7641-4B42-8541-AF7288AE5390@muada.com> <000701ca2733$9ec44a40$c5f0200a@cisco.com> <25e1aaa40908271107r308f648fr20a467c0671802@mail.gmail.com> Date: Fri, 28 Aug 2009 02:29:41 +0800 Message-ID: <25e1aaa40908271129x4e1c4152r1f148e5d20d5c20b@mail.gmail.com> From: liu dapeng To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Cc: behave@ietf.org, Dan Wing Subject: Re: [BEHAVE] A New Draft on FTP64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 18:29:42 -0000 2009/8/28, Iljitsch van Beijnum : > On 27 aug 2009, at 20:07, liu dapeng wrote: > >>> We currently have one or more people feeling that an ALG is required >>> and one or more people that feel it's a bad idea. The draft allows >>> for >>> both, and also mandates a way for users to make the ALG go into >>> transparent mode, so I'm thinking we're ready to declare victory...? > >> my question is: should we simply put the different opinions (maybe >> opposite) together to make a specification or should we investigate >> the problems more deeply and try to make a specification that could >> best solve the problem? > > The problem is that there is no objective "best". For some people the > extra state required by an ALG would be expensive but changing the > clients wouldn't be, for others an ALG is no problem but they have > little control over the clients so they can't change them or this > involves expensive support calls. the point is: maybe we should all have to aggree that ALG is bad, especially for translation box, so should not we try to find some solutions to avoid it if it is possible(or give some clear guidelines to avoid it if it possiable) ? mybe that is the best we can do. it is quite late here, I will continue to discuss tomorrow, thanks for the discussion. From marka@isc.org Thu Aug 27 18:20:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256DF3A6A9E for ; Thu, 27 Aug 2009 18:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaMbWzrabmAb for ; Thu, 27 Aug 2009 18:20:21 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 262693A6CBC for ; Thu, 27 Aug 2009 18:20:21 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D5BE4E601C; Fri, 28 Aug 2009 01:20:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7S1KFSQ040147; Fri, 28 Aug 2009 11:20:16 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908280120.n7S1KFSQ040147@drugs.dv.isc.org> To: Iljitsch van Beijnum From: Mark Andrews References: <4A72F0BF.4000609@viagenie.ca> <200908261537.04193.simon.perreault@viagenie.ca> <1d38a3350908270541n6d942d81n55a36dc00102c203@mail.gmail.com> <200908270848.53749.simon.perreault@viagenie.ca> In-reply-to: Your message of "Thu, 27 Aug 2009 15:27:36 +0200." Date: Fri, 28 Aug 2009 11:20:15 +1000 Sender: marka@isc.org Cc: Hui Deng , Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 01:20:22 -0000 In message , Iljitsch van Beijn um writes: > On 27 aug 2009, at 14:48, Simon Perreault wrote: > > > When a DNS64 has only an IPv6 connection, it can only contact > > authoritative > > name servers over IPv6. However, if it has access to the NAT64, it > > can also > > talk to IPv4-only authoritative name servers through it. To do so it > > only has > > to use the synthetic AAAA records it generates. > > Being able to perform DNS64 synthesis and being able to do recursive > queries through a NAT64 are two different things. One doesn't imply > the other, although once you have one the other is easier because you > already have the NAT64 prefix that you need. Here is a example of how it would be done, sorry for the line width. client DNS64 NAT64 V4 server (IPv6 only) (IPv6 only) (dual stack) (IPv4 only) 2000:yyyy 2001:xxxx 4.0.0.1 3.0.0.1 example.com/AAAA ->2001:xxxx example.com/AAAA ->:3.0.0.1 example.com/AAAA ->3.0.0.1 example.com/AAAA/NXRRSET <-4.0.0.1 example.com/AAAA/NXRRSET <-2001:xxxx example.com/A ->:3.0.0.1 example.com/A ->3.0.0.1 example.com/A/1.2.3.4 <-4.0.0.1 example.com/A/1.2.3.4 <-2001:xxxx example.com/AAA/:1.2.3.4 <-2001:yyyy NXRRSET (no such RRset) indicates that the name exists but the requested type doesn't. It's another way of expressing NOERROR with zero answers and no referral. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From xuxh@huawei.com Thu Aug 27 19:18:32 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6DB3A6A21 for ; Thu, 27 Aug 2009 19:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.977 X-Spam-Level: **** X-Spam-Status: No, score=4.977 tagged_above=-999 required=5 tests=[AWL=-1.823, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+o3WOpRbi5b for ; Thu, 27 Aug 2009 19:18:32 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CB7713A6D9D for ; Thu, 27 Aug 2009 19:17:39 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200IWNEDC0T@szxga03-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 10:17:36 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200F7OEDC8C@szxga03-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 10:17:36 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP200IPKEDBTK@szxml06-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 10:17:36 +0800 (CST) Date: Fri, 28 Aug 2009 10:17:35 +0800 From: Xu Xiaohu In-reply-to: <200908280120.n7S1KFSQ040147@drugs.dv.isc.org> To: 'Mark Andrews' , 'Iljitsch van Beijnum' Message-id: <002501ca2785$b5587f90$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Thread-index: AconfeWaltvkB1e4RtaC7GRuoXiH0wAAfDXw Cc: 'Hui Deng' , 'Behave WG' , 'liu dapeng' Subject: [BEHAVE] =?gb2312?b?ILTwuLQ6ICBETlM2NCBzZXJ2ZXIgdXNpbmcgaXRzIG93?= =?gb2312?b?biBzeW50aGVzaXplZCByZWNvcmRz?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 02:18:32 -0000 Hi Mark, > Here is a example of how it would be done, sorry for the line width. > > client DNS64 NAT64 > V4 server > (IPv6 only) (IPv6 only) (dual stack) > (IPv4 only) > 2000:yyyy 2001:xxxx 4.0.0.1 > 3.0.0.1 > example.com/AAAA > ->2001:xxxx > example.com/AAAA > ->:3.0.0.1 > > example.com/AAAA > > ->3.0.0.1 > > example.com/AAAA/NXRRSET > > <-4.0.0.1 > example.com/AAAA/NXRRSET > <-2001:xxxx > example.com/A > ->:3.0.0.1 > > example.com/A > > ->3.0.0.1 > > example.com/A/1.2.3.4 > > <-4.0.0.1 > example.com/A/1.2.3.4 > <-2001:xxxx > example.com/AAA/:1.2.3.4 > <-2001:yyyy I think the illustration would become more clearly once you could introduce one more layer of recursive server in your example. For example, the DNS64 firstly sends a DNS query for the AAAA RR of www.example.com to the DNS server (e.g. S1, prefix+3.0.0.1) which is the authoritative DNS server for . com zone, and S1 told the DNS64 that the authoritative DNS server for example.com zone is S2 (i.e., 5.1.1.1 which is expressed in a NS record). Upon receiving the above reply, the DNS64 will then send a recursive query to S2 by using the synthesized address of S2 (i.e., prefix64+5.1.1.1). This synthesis action is exactly implemented by the DNS64 itself. However, in your example, the synthesized address for DNS server 3.0.0.1 could be configured directly on the DNS64, which is transparent to the DNS64. Xiaohu From denghui02@gmail.com Thu Aug 27 19:48:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617F628C26B for ; Thu, 27 Aug 2009 19:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDgf1tFFNUJ4 for ; Thu, 27 Aug 2009 19:48:35 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 6C1CC3A6DD0 for ; Thu, 27 Aug 2009 19:48:35 -0700 (PDT) Received: by ewy3 with SMTP id 3so84392ewy.42 for ; Thu, 27 Aug 2009 19:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NMYb2wH0fJZ/zmwZUI7n1IDEsdOaAz3WOEqbQdwPnNw=; b=dROdNPFplBCqTNEcQJUAl+iC9B0Zlu0sTKHUkx9CouedMa43AqOeUzZZvT/k1AdmBA AYwqNUSzu+Yr7aP37qCdsGf8w6RG+d75cd0n7D8zweEoxvZeI8f32UlDJ3WtlBGRfCIy TxA6FgIiqF1pS78SawpKoCjcm9+1CMQGUB8L8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RIioCjzl7+pj5O+V/dhrhowSwqJ1QlSlx5cG/dvEE/+IH70qkjiOsbSGcoeP2RHp7X RIwMX+eCLyg1GLpsgYQd2rn6MFbFilos/Z9QssR5nyDpm3IWK3zlyKNC0I0GLMvvkjzD FFBN5qzk2psWbkATrBkZet6TWvfc+7Mqh2GUM= MIME-Version: 1.0 Received: by 10.210.35.10 with SMTP id i10mr1265328ebi.92.1251427718184; Thu, 27 Aug 2009 19:48:38 -0700 (PDT) In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> Date: Fri, 28 Aug 2009 10:48:38 +0800 Message-ID: <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> From: Hui Deng To: Wassim Haddad Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 02:48:36 -0000 Hi, Wassim, The problem in your draft has been elaborated inside us before. this is one driving force for us to design PNAT http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01 we guess that identify the peer side IP family type is important for the communication. Current NAT64 assume host is IPv6 only, and network is IPv6 only connection. but PNAT64 assume host is dual stack, and network is IPv6only connection. and NAT64 need DNS64, and PNAT64 don't need DNS64. furthermore PNAT host understand peer side whether it is IPv4 or IPv6 which could remove your concern in this draft. PNAT assume host will rely on PNAT64 for its IPv4 application, will rely on NAT64 for its IPv6 application. thanks for the discussion. -Hui 2009/8/27 Wassim Haddad : > Dear all, > > Please find attached a note on NAT64 and MIPv6. > > > Regards, > > Wassim H. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From marka@isc.org Thu Aug 27 21:25:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415253A6880 for ; Thu, 27 Aug 2009 21:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[AWL=-2.219, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BajEC3YKcR1e for ; Thu, 27 Aug 2009 21:25:47 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 63BA63A682B for ; Thu, 27 Aug 2009 21:25:47 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id E929BE601C; Fri, 28 Aug 2009 04:25:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7S4Plt8043469; Fri, 28 Aug 2009 14:25:47 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908280425.n7S4Plt8043469@drugs.dv.isc.org> To: Xu Xiaohu From: Mark Andrews References: <002501ca2785$b5587f90$d40c6f0a@china.huawei.com> In-reply-to: Your message of "Fri, 28 Aug 2009 10:17:35 +0800." <002501ca2785$b5587f90$d40c6f0a@china.huawei.com> Date: Fri, 28 Aug 2009 14:25:46 +1000 Sender: marka@isc.org Cc: 'Hui Deng' , 'Behave WG' , 'liu dapeng' Subject: Re: [BEHAVE] =?gb2312?b?tPC4tDogIEROUzY0IHNlcnZlciB1c2luZyBpdHMgb3du?= =?gb2312?b?IHN5bnRoZXNpemVkIHJlY29yZHM=?= X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 04:25:48 -0000 In message <002501ca2785$b5587f90$d40c6f0a@china.huawei.com>, Xu Xiaohu writes: > Hi Mark, > > > Here is a example of how it would be done, sorry for the line width. > > > > client DNS64 NAT64 > > V4 server > > (IPv6 only) (IPv6 only) (dual stack) > > (IPv4 only) > > 2000:yyyy 2001:xxxx 4.0.0.1 > > 3.0.0.1 > > example.com/AAAA > > ->2001:xxxx > > example.com/AAAA > > ->:3.0.0.1 > > > > example.com/AAAA > > > > ->3.0.0.1 > > > > example.com/AAAA/NXRRSET > > > > <-4.0.0.1 > > example.com/AAAA/NXRRSET > > <-2001:xxxx > > example.com/A > > ->:3.0.0.1 > > > > example.com/A > > > > ->3.0.0.1 > > > > example.com/A/1.2.3.4 > > > > <-4.0.0.1 > > example.com/A/1.2.3.4 > > <-2001:xxxx > > example.com/AAA/:1.2.3.4 > > <-2001:yyyy > > I think the illustration would become more clearly once you could introduce > one more layer of recursive server in your example. I think you actually mean one more level of iteration. The recurive requests happen between client and DNS64. Iterative requests happen between DNS64 and the authoritative servers. > For example, the DNS64 > firstly sends a DNS query for the AAAA RR of www.example.com to the DNS > server (e.g. S1, prefix+3.0.0.1) which is the authoritative DNS server for . > com zone, and S1 told the DNS64 that the authoritative DNS server for > example.com zone is S2 (i.e., 5.1.1.1 which is expressed in a NS record). > Upon receiving the above reply, the DNS64 will then send a recursive query > to S2 by using the synthesized address of S2 (i.e., prefix64+5.1.1.1). This > synthesis action is exactly implemented by the DNS64 itself. However, in > your example, the synthesized address for DNS server 3.0.0.1 could be > configured directly on the DNS64, which is transparent to the DNS64. > > Xiaohu One can add too much. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cambyrne@yahoo.com Thu Aug 27 22:09:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534A13A6A35 for ; Thu, 27 Aug 2009 22:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.744 X-Spam-Level: X-Spam-Status: No, score=-0.744 tagged_above=-999 required=5 tests=[AWL=1.855, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNZnthmI111c for ; Thu, 27 Aug 2009 22:09:07 -0700 (PDT) Received: from web32005.mail.mud.yahoo.com (web32005.mail.mud.yahoo.com [68.142.207.102]) by core3.amsl.com (Postfix) with SMTP id 555793A67C1 for ; Thu, 27 Aug 2009 22:09:07 -0700 (PDT) Received: (qmail 54466 invoked by uid 60001); 28 Aug 2009 05:09:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251436152; bh=l/rTo56xASbociIrWTyEzhQkJMxAJl2aUbi9lojpMso=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TnEzc35ZgHM8yTXNAtjG4S+0ldjyNM7BulLM36qICJFNeA1Cgbzklr+Cl4oS3OewrR+cpauF+HerLn5JRKRC4X+/luHHe/RfnkNM4QbUw6Xt1bbYCGdxqqLE86/Xq3/pxEvo+/RzyCWO7SGH3VFD4VdEyF2TOhsJjodkomp7bE0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uVGXEUmaQ7eMmfBITLtogi0X4Y6GAostnY0gyf9itIH1x/Qkqi/1GEZGJtlNsJObXOnYFIyIm6y/aI7PIj8Muzd5PEayTIYE1dWoD527+XwrgFrX8c3HzWbOT6puGVFnJaaATFW5L4kF+wyNiUFJlgg46ndki8i3U6Pce1i1iG8=; Message-ID: <657543.54243.qm@web32005.mail.mud.yahoo.com> X-YMail-OSG: km04nsgVM1nl0WPZEpBoFatZvS7huvCQG3AZGJmVbvyUKuEYXWMQ90znl1eOxza5EbTNXGC_EoHy5eIToSshWrlijTVvV61Kcrsj1saS5ASSog.t87rGFw.s4zYZRlT1pokhc.c3rQhLt2mTZZV6VNELtar1hhbtkQoiryoMLGF4TqVOaOv0BMIGVF1ypKC9sbB279r11mG6RRByUUGv6HC3_vrp3YzQqrw8Z3pO13BV3MjA8XoVnScxyo3dzdjpinYT3dl9_cfKtKyFhL7I4ukXwEvu6aoqdcfgy7XOmQEQs4YZT0jpVi9BADRpAI91RR2Znj9fi1UKdG7aOtOMTQ-- Received: from [98.203.136.70] by web32005.mail.mud.yahoo.com via HTTP; Thu, 27 Aug 2009 22:09:12 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.1 Date: Thu, 27 Aug 2009 22:09:12 -0700 (PDT) From: Cameron Byrne To: Hui Deng , Simon Perreault MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 05:09:08 -0000 > Hui Deng wrote:=0A> > how consequently this could happen, DNS64 have to s= end=0A> AAAA=A0 resolver=0A> > to DNS6 side, and=0A> > send a A resolver th= rough NAT64 meantime? is this your=0A> assumpation and=0A> > described in t= he draft?=0A> =0A> When a DNS64 has only an IPv6 connection, it can only=0A= > contact authoritative =0A> name servers over IPv6. However, if it has acc= ess to the=0A> NAT64, it can also =0A> talk to IPv4-only authoritative name= servers through it. To=0A> do so it only has =0A> to use the synthetic AAA= A records it generates.=0A=0AWhile this seems possible, as a network operat= or, i really cannot imagine a scenario where i would deploy something as in= elegant as this.=A0 I cannot imagine explaining to my operations teams why = we did not give DNS64 a global IPv4 address and how the DNS64 is dependent = on the NAT64 in this way.=A0 =0A=0AThe DNS64 / NAT64 is the linchpin of int= er-working the v6 and v4 realms, even in a world with limited IPv4 space, g= iving globally routable IPv4 addresses to the DNS64 (1 address per system, = or even using NAT44 for many systems) seems like a high priority.=0A=0ACame= ron Byrne=0APrincipal Engineer=0AT-Mobile USA=0A=0A From marka@isc.org Thu Aug 27 23:10:15 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761223A6D8D for ; Thu, 27 Aug 2009 23:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYwm-svi0gct for ; Thu, 27 Aug 2009 23:10:14 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 500BD3A6A50 for ; Thu, 27 Aug 2009 23:10:14 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id 67406E601C; Fri, 28 Aug 2009 06:10:19 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n7S6AFbW044198; Fri, 28 Aug 2009 16:10:15 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200908280610.n7S6AFbW044198@drugs.dv.isc.org> To: Cameron Byrne From: Mark Andrews References: <657543.54243.qm@web32005.mail.mud.yahoo.com> In-reply-to: Your message of "Thu, 27 Aug 2009 22:09:12 MST." <657543.54243.qm@web32005.mail.mud.yahoo.com> Date: Fri, 28 Aug 2009 16:10:15 +1000 Sender: marka@isc.org Cc: Hui Deng , Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 06:10:15 -0000 In message <657543.54243.qm@web32005.mail.mud.yahoo.com>, Cameron Byrne writes: > > Hui Deng wrote: > > > how consequently this could happen, DNS64 have to send > > AAAA resolver > > > to DNS6 side, and > > > send a A resolver through NAT64 meantime? is this your > > assumpation and > > > described in the draft? > > > > > When a DNS64 has only an IPv6 connection, it can only > > contact authoritative > > > name servers over IPv6. However, if it has access to the > > NAT64, it can also > > > talk to IPv4-only authoritative name servers through it. To > > do so it only has > > > to use the synthetic AAAA records it generates. > > While this seems possible, as a network operator, i really cannot imagine a > scenario where i would deploy something as inelegant as this. I cannot > imagine explaining to my operations teams why we did not give DNS64 a globa > l IPv4 address and how the DNS64 is dependent on the NAT64 in this way. The DNS64 fate shares with the NAT64. There is nothing inelegent about this. The DNS really doesn't require anything more than basic translation offered by the NAT64. This just lets you put the DNS64 anywhere you like rather than forcing it to be connected to the IPv4 network directly. > The DNS64 / NAT64 is the linchpin of inter-working the v6 and v4 realms, ev > en in a world with limited IPv4 space, giving globally routable IPv4 addres > ses to the DNS64 (1 address per system, or even using NAT44 for many system > s) seems like a high priority. > > Cameron Byrne > Principal Engineer > T-Mobile USA > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From xuxh@huawei.com Fri Aug 28 01:12:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2CF28C193 for ; Fri, 28 Aug 2009 01:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[AWL=1.920, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FstbjoS6Df6e for ; Fri, 28 Aug 2009 01:12:12 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BFFE628C112 for ; Fri, 28 Aug 2009 01:12:11 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200C9PUS7UJ@szxga01-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 16:12:08 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP2007NUUS7BO@szxga01-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 16:12:07 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP200KNCUS7J6@szxml06-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 16:12:07 +0800 (CST) Date: Fri, 28 Aug 2009 16:12:06 +0800 From: Xu Xiaohu In-reply-to: <200908280425.n7S4Plt8043469@drugs.dv.isc.org> To: marka@isc.org Message-id: <003b01ca27b7$3be93c80$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AconnQ+v8PGcipgnTuew1gG+v3bkhQAGe3XQ Cc: 'Hui Deng' , 'Behave WG' , 'liu dapeng' Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 08:12:12 -0000 > > I think the illustration would become more clearly once you could > > introduce one more layer of recursive server in your example. > > I think you actually mean one more level of iteration. The > recurive requests happen between client and DNS64. Iterative > requests happen between DNS64 and the authoritative servers. Oh, yes, I meant "iterative query". Xiaohu From iljitsch@muada.com Fri Aug 28 02:05:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060D828C2AC for ; Fri, 28 Aug 2009 02:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq+rPjNZorll for ; Fri, 28 Aug 2009 02:05:03 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 04F0728C29E for ; Fri, 28 Aug 2009 02:05:02 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7S94QA8033919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2009 11:04:26 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Mark Andrews In-Reply-To: <200908280610.n7S6AFbW044198@drugs.dv.isc.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 Aug 2009 11:05:00 +0200 References: <657543.54243.qm@web32005.mail.mud.yahoo.com> <200908280610.n7S6AFbW044198@drugs.dv.isc.org> X-Mailer: Apple Mail (2.936) Cc: Behave WG Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 09:05:04 -0000 On 28 aug 2009, at 8:10, Mark Andrews wrote: > The DNS64 fate shares with the NAT64. There is nothing inelegent > about this. The DNS really doesn't require anything more than basic > translation offered by the NAT64. This just lets you put the DNS64 > anywhere you like rather than forcing it to be connected to the IPv4 > network directly. The only way you can do iterative queries through a NAT64 cleanly (assuming a world where there are still a few people that don't have IPv6 addresses for their nameservers) is for the DNS server to realize it needs to talk to an IPv4 address and then add the translator prefix. Trying to trick a DNS server that doesn't know about NAT64 into doing this by translating the addresses it will see IS A VERY BAD IDEA. From xuxh@huawei.com Fri Aug 28 03:03:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D30D3A67B7 for ; Fri, 28 Aug 2009 03:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.376 X-Spam-Level: * X-Spam-Status: No, score=1.376 tagged_above=-999 required=5 tests=[AWL=1.871, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPcC0Z-RLled for ; Fri, 28 Aug 2009 03:03:33 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6AE633A6ACE for ; Fri, 28 Aug 2009 03:02:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP200GEWZWA92@szxga03-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 18:02:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KP2005NFZWAL1@szxga03-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 18:02:34 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.12.212]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KP200GF1ZWAT1@szxml04-in.huawei.com> for behave@ietf.org; Fri, 28 Aug 2009 18:02:34 +0800 (CST) Date: Fri, 28 Aug 2009 18:02:34 +0800 From: Xu Xiaohu In-reply-to: To: 'Iljitsch van Beijnum' , 'Mark Andrews' Message-id: <004501ca27c6$aa34df00$d40c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AconvqzPayC5zlFdShGHQXfCNfcQvwABvRbQ Cc: 'Behave WG' Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 10:03:34 -0000 > The only way you can do iterative queries through a NAT64 cleanly > (assuming a world where there are still a few people that don't have > IPv6 addresses for their nameservers) is for the DNS server to realize > it needs to talk to an IPv4 address and then add the translator prefix. > > Trying to trick a DNS server that doesn't know about NAT64 into doing > this by translating the addresses it will see IS A VERY BAD IDEA. The network administrator can make the choice. For example, if there is a NAT64 and there is no IPv4 path from a given DNS64 to the IPv4 Internet, the administrator can enable the IPv6 synthesis function with which the IPv4 address in the glue address RR (associated with the NS RR) can be synthesized into IPv6 address. Xiaohu From simon.perreault@viagenie.ca Fri Aug 28 04:34:05 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FD93A6DFB for ; Fri, 28 Aug 2009 04:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFh5FhsW8+YI for ; Fri, 28 Aug 2009 04:34:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0B1173A6E26 for ; Fri, 28 Aug 2009 04:32:32 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id E625629E1604; Fri, 28 Aug 2009 07:32:36 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id DCDD329E15BE; Fri, 28 Aug 2009 07:32:36 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Cameron Byrne Date: Fri, 28 Aug 2009 07:32:33 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <657543.54243.qm@web32005.mail.mud.yahoo.com> In-Reply-To: <657543.54243.qm@web32005.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908280732.33801.simon.perreault@viagenie.ca> Cc: Hui Deng , Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 11:34:05 -0000 On Friday 28 August 2009 01:09:12 Cameron Byrne wrote: > While this seems possible, as a network operator, i really cannot imagine a > scenario where i would deploy something as inelegant as this. I cannot > imagine explaining to my operations teams why we did not give DNS64 a > global IPv4 address and how the DNS64 is dependent on the NAT64 in this > way. As I mentioned elsewhere in this thread, I expect it to be common that only a single global IPv4 address is available and is allocated to the NAT64. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Fri Aug 28 04:38:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7413A6F5E for ; Fri, 28 Aug 2009 04:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAwTmxSCJa77 for ; Fri, 28 Aug 2009 04:38:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 18DFD3A6E26 for ; Fri, 28 Aug 2009 04:38:46 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 63FC129E1604; Fri, 28 Aug 2009 07:38:50 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 5AAA829E15BE; Fri, 28 Aug 2009 07:38:50 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Fri, 28 Aug 2009 07:38:49 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <657543.54243.qm@web32005.mail.mud.yahoo.com> <200908280610.n7S6AFbW044198@drugs.dv.isc.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908280738.50070.simon.perreault@viagenie.ca> Cc: Mark Andrews Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 11:38:47 -0000 On Friday 28 August 2009 05:05:00 Iljitsch van Beijnum wrote: > The only way you can do iterative queries through a NAT64 cleanly > (assuming a world where there are still a few people that don't have > IPv6 addresses for their nameservers) is for the DNS server to realize > it needs to talk to an IPv4 address and then add the translator prefix. ...which is what both Bind and Unbound do naturally. They just query themselves for the AAAA record of a name server they're trying to reach and synthesize one if none is available. > Trying to trick a DNS server that doesn't know about NAT64 into doing > this by translating the addresses it will see IS A VERY BAD IDEA. I don't understand what you mean. Nobody's tricking anybody, it's doing it by default. The point is that the administrator should be able to stop it from doing so. Hence my suggestion. I also don't understand why this is being so controversial. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From simon.perreault@viagenie.ca Fri Aug 28 04:43:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4713B3A70FE for ; Fri, 28 Aug 2009 04:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iMA-9ySlmOK for ; Fri, 28 Aug 2009 04:43:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id E39C23A6E27 for ; Fri, 28 Aug 2009 04:43:12 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 6170329E1604; Fri, 28 Aug 2009 07:43:18 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 57FE229E15BE; Fri, 28 Aug 2009 07:43:18 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: behave@ietf.org Date: Fri, 28 Aug 2009 07:43:17 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> In-Reply-To: <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908280743.18009.simon.perreault@viagenie.ca> Cc: Hui Deng , Wassim Haddad Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 11:43:34 -0000 On Thursday 27 August 2009 22:48:38 Hui Deng wrote: > Current NAT64 assume host is IPv6 only, and network is IPv6 only > connection. but PNAT64 assume host is dual stack, and network is IPv6only > connection. This is not true. NAT64 doesn't assume anything about the host, while PNAT64 assumes that the host implements PNAT64. This is one of the assumptions driving NAT64: we cannot modify the hosts at this point. If this assumption does not hold for your network, fine, you can use something else. But for many, it does. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From iljitsch@muada.com Fri Aug 28 06:39:49 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8926F3A6B6C for ; Fri, 28 Aug 2009 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbu9M8gOjT0k for ; Fri, 28 Aug 2009 06:39:48 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 68AB63A6A32 for ; Fri, 28 Aug 2009 06:39:48 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7SDd8sf035652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2009 15:39:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <8E7C1082-82D1-43B8-A845-A99340F8B892@muada.com> From: Iljitsch van Beijnum To: Simon Perreault In-Reply-To: <200908280738.50070.simon.perreault@viagenie.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 Aug 2009 15:39:42 +0200 References: <657543.54243.qm@web32005.mail.mud.yahoo.com> <200908280610.n7S6AFbW044198@drugs.dv.isc.org> <200908280738.50070.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org, Mark Andrews Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 13:39:49 -0000 On 28 aug 2009, at 13:38, Simon Perreault wrote: >> Trying to trick a DNS server that doesn't know about NAT64 into doing >> this by translating the addresses it will see IS A VERY BAD IDEA. > I don't understand what you mean. Nobody's tricking anybody, it's > doing it by > default. The point is that the administrator should be able to stop > it from > doing so. Hence my suggestion. If you want to look up www.example.org and it turns out that the nameserver for that is a.iana-servers.net with address 192.0.34.43, then the DNS resolver behind a NAT64 should _contact_ pref64::c000222b but it should NOT _return_ an AAAA record with pref::c000222b in any result, because we haven't analyzed the bad things that can happen in that case. From simon.perreault@viagenie.ca Fri Aug 28 06:54:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144573A6DCE for ; Fri, 28 Aug 2009 06:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4WDUcoghlXw for ; Fri, 28 Aug 2009 06:54:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D52C63A6DA0 for ; Fri, 28 Aug 2009 06:54:39 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 701BD29E1601; Fri, 28 Aug 2009 09:54:46 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 6817A29E15BE; Fri, 28 Aug 2009 09:54:46 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Iljitsch van Beijnum Date: Fri, 28 Aug 2009 09:54:45 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <657543.54243.qm@web32005.mail.mud.yahoo.com> <200908280738.50070.simon.perreault@viagenie.ca> <8E7C1082-82D1-43B8-A845-A99340F8B892@muada.com> In-Reply-To: <8E7C1082-82D1-43B8-A845-A99340F8B892@muada.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908280954.45741.simon.perreault@viagenie.ca> Cc: behave@ietf.org, Mark Andrews Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 13:54:41 -0000 On Friday 28 August 2009 09:39:42 Iljitsch van Beijnum wrote: > If you want to look up www.example.org and it turns out that the > nameserver for that is a.iana-servers.net with address 192.0.34.43, > then the DNS resolver behind a NAT64 should _contact_ pref64::c000222b > but it should NOT _return_ an AAAA record with pref::c000222b in any > result, because we haven't analyzed the bad things that can happen in > that case. I'm confused. Where does your generic DNS resolver come from? I thought we were only talking about the DNS64. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From iljitsch@muada.com Fri Aug 28 07:00:16 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B45828C389 for ; Fri, 28 Aug 2009 07:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DniTQhuKRQT for ; Fri, 28 Aug 2009 07:00:15 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id E282228C331 for ; Fri, 28 Aug 2009 07:00:14 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.71]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n7SDxcu5035826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2009 15:59:38 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <1D6D5BA6-C92A-4753-A510-E358EFEB91D9@muada.com> From: Iljitsch van Beijnum To: Simon Perreault In-Reply-To: <200908280954.45741.simon.perreault@viagenie.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 28 Aug 2009 16:00:12 +0200 References: <657543.54243.qm@web32005.mail.mud.yahoo.com> <200908280738.50070.simon.perreault@viagenie.ca> <8E7C1082-82D1-43B8-A845-A99340F8B892@muada.com> <200908280954.45741.simon.perreault@viagenie.ca> X-Mailer: Apple Mail (2.936) Cc: behave@ietf.org, Mark Andrews Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:00:16 -0000 On 28 aug 2009, at 15:54, Simon Perreault wrote: >> If you want to look up www.example.org and it turns out that the >> nameserver for that is a.iana-servers.net with address 192.0.34.43, >> then the DNS resolver behind a NAT64 should _contact_ >> pref64::c000222b >> but it should NOT _return_ an AAAA record with pref::c000222b in any >> result, because we haven't analyzed the bad things that can happen in >> that case. > I'm confused. Where does your generic DNS resolver come from? I > thought we > were only talking about the DNS64. Could be one box that does both. But it's the resolving that we are discussing so that's the name that I used, whether it does DNS64 or not is largely irrelevant. From simon.perreault@viagenie.ca Fri Aug 28 07:18:44 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9F73A6FFF for ; Fri, 28 Aug 2009 07:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJX2E1tmemqo for ; Fri, 28 Aug 2009 07:18:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 349823A7151 for ; Fri, 28 Aug 2009 07:18:04 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 624FA29E1605; Fri, 28 Aug 2009 10:18:08 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 5983C29E15BE; Fri, 28 Aug 2009 10:18:08 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Iljitsch van Beijnum Date: Fri, 28 Aug 2009 10:18:07 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <657543.54243.qm@web32005.mail.mud.yahoo.com> <200908280954.45741.simon.perreault@viagenie.ca> <1D6D5BA6-C92A-4753-A510-E358EFEB91D9@muada.com> In-Reply-To: <1D6D5BA6-C92A-4753-A510-E358EFEB91D9@muada.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908281018.07918.simon.perreault@viagenie.ca> Cc: behave@ietf.org, Mark Andrews Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:18:44 -0000 On Friday 28 August 2009 10:00:12 Iljitsch van Beijnum wrote: > On 28 aug 2009, at 15:54, Simon Perreault wrote: > >> If you want to look up www.example.org and it turns out that the > >> nameserver for that is a.iana-servers.net with address 192.0.34.43, > >> then the DNS resolver behind a NAT64 should _contact_ > >> pref64::c000222b > >> but it should NOT _return_ an AAAA record with pref::c000222b in any > >> result, because we haven't analyzed the bad things that can happen in > >> that case. I still can't parse this. If a.iana-servers.net only has an A record, why shouldn't the DNS64 (or a DNS resolver using the DNS64 as a forwarder, let's not always mention this case since as you said it's not different) synthesize *and* return a AAAA record? The fact that a NS record points to it is irrelevant. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From cambyrne@yahoo.com Fri Aug 28 07:53:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D0E28C3EA for ; Fri, 28 Aug 2009 07:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29KHa8YhEgWg for ; Fri, 28 Aug 2009 07:53:37 -0700 (PDT) Received: from web32001.mail.mud.yahoo.com (web32001.mail.mud.yahoo.com [68.142.207.98]) by core3.amsl.com (Postfix) with SMTP id 386AF3A6860 for ; Fri, 28 Aug 2009 07:53:06 -0700 (PDT) Received: (qmail 77275 invoked by uid 60001); 28 Aug 2009 14:53:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1251471191; bh=yU6jbYd58PrTqaUOPuFwWAzg7uw4LieRqLAzOmKOEt8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T/Zyar3UXFLkWiO0lSWizauUGbytWSSDBhiBRE4Ch0PFq290UXK1kzkMMZ8w0OxYiLoWfRSHq5haOq2UeFFIbPgKVLE/xU4OeayOjpDHGi7emq2sr6RbbCugp+iwL+a6rs7HtKlEq3bF3NElv4aoTAJN4sFK/n1P3oXpWDep7Ho= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=w5GkEnP8gOekfMB7OluWnRtKsKJGl6/JuEThjR2lW3OGp12rNuNcv7paoC0Q1W/HE/EggNBpiExnFgOYSoIP7KWeuJjz2a4UplE1GAAueq+XZjUFU6ZvQuu1GJ5FHH7ft0K4ga0REs0rRa01aliNlj3KFXFGOUqMXf4o0lJwWlI=; Message-ID: <238191.76604.qm@web32001.mail.mud.yahoo.com> X-YMail-OSG: WZpUP8QVM1laFK6IQisPzt_5hOl7lTkvdiUPRiIyRhpECFA41pz2pS4JAiUhnpPPwyw6QoTfqoLbK5p9Ox0AY4ChEhEIx7D6rgPe1DAXpPTY_WkzE05EqGcM4Y3.Ut4PlfhB_IzSrW.EhlUSKC05hHnzt7SPeG_3RFL1Q9ZLC7CI3IknkdwTySy0vdjManhgts6ghy4BKhgQ1zgOdrp0UUfhtBHvNG8c0.O5enHqBs2GAi9rZTA1lCMdP5wer9hmSkhRSS9Y9Yhco22eEsYUsiSsdlc8TvjQYOPouf1.KDXptE0ux5rvurX0bsnzM0QMDMwVRNB4J4J.usrfBjATPw-- Received: from [98.203.136.70] by web32001.mail.mud.yahoo.com via HTTP; Fri, 28 Aug 2009 07:53:11 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.338.2 Date: Fri, 28 Aug 2009 07:53:11 -0700 (PDT) From: Cameron Byrne To: Simon Perreault In-Reply-To: <200908280732.33801.simon.perreault@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 14:53:38 -0000 =0A> > While this seems possible, as a network operator, i=0A> really canno= t imagine a=0A> > scenario where i would deploy something as inelegant=0A> = as this.=A0 I cannot=0A> > imagine explaining to my operations teams why we= did=0A> not give DNS64 a=0A> > global IPv4 address and how the DNS64 is de= pendent on=0A> the NAT64 in this=0A> > way.=0A> =0A> As I mentioned elsewhe= re in this thread, I expect it to be=0A> common that only a =0A> single glo= bal IPv4 address is available and is allocated to=0A> the NAT64.=0ASimon,= =0A=0ACan you please explain why you assume only 1 IPv4 address is availabl= e? My assumption is that Network Operators are the ones that will deploy N= AT64 / DNS64, and we are address constrained, but not constrained to the ex= tent that 1 more IP address is an issue ... or one more IPv4 address per PO= P is an issue. Furthermore, my expectation is that the NAT64 systems will = scale in the millions of sessions, so a range of IPv4 addresses will be req= uired to create enough unique BIBs to scale in the millions of sessions, ri= ght?=0A=0AThat said, from the other thread, I believe Mark's point regardin= g the virtuous fate sharing is a good one, and DNS64 using its own synthesi= zed records maybe a relevant deployment model, but i am not sure i would go= that route myself. For example, the virtuous fate sharing may not work pe= rfectly as NAT64 and DNS64 scale separately in terms of transactions / sess= ions per second.=0A=0ACameron From simon.perreault@viagenie.ca Fri Aug 28 08:02:27 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1D528C416 for ; Fri, 28 Aug 2009 08:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+akvV3hW88W for ; Fri, 28 Aug 2009 08:02:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D593128C41C for ; Fri, 28 Aug 2009 08:02:26 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 7D99629E1604; Fri, 28 Aug 2009 11:02:33 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 7566629E15BE; Fri, 28 Aug 2009 11:02:33 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Cameron Byrne Date: Fri, 28 Aug 2009 11:02:32 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <238191.76604.qm@web32001.mail.mud.yahoo.com> In-Reply-To: <238191.76604.qm@web32001.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908281102.33025.simon.perreault@viagenie.ca> Cc: Hui Deng , Behave WG , liu dapeng Subject: Re: [BEHAVE] DNS64 server using its own synthesized records X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:02:27 -0000 On Friday 28 August 2009 10:53:11 Cameron Byrne wrote: > Can you please explain why you assume only 1 IPv4 address is available? No. I don't assume. It's only an example. There are other cases where an administrator may want to have its DNS64 talk through the NAT64 instead of giving it an IPv4 connection. Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From wassim.haddad@ericsson.com Fri Aug 28 08:31:34 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C006828C32A for ; Fri, 28 Aug 2009 08:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BedKCKl4ojXY for ; Fri, 28 Aug 2009 08:31:34 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id E21B528C1F5 for ; Fri, 28 Aug 2009 08:31:33 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n7SFVY3D005406; Fri, 28 Aug 2009 10:31:39 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:31:35 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug 2009 10:31:35 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 28 Aug 2009 11:31:35 -0400 From: Wassim Haddad To: Simon Perreault , "behave@ietf.org" Date: Fri, 28 Aug 2009 11:31:34 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: Acon1MZdBnwzEnNTQL2kKl835SUR8wAHsCiP Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com>, <200908280743.18009.simon.perreault@viagenie.ca> In-Reply-To: <200908280743.18009.simon.perreault@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Aug 2009 15:31:35.0798 (UTC) FILETIME=[A0DF6960:01CA27F4] Cc: Hui Deng , Wassim Haddad Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:31:34 -0000 On Thursday 27 August 2009 22:48:38 Hui Deng wrote: > Current NAT64 assume host is IPv6 only, and network is IPv6 only > connection. but PNAT64 assume host is dual stack, and network is IPv6only > connection. This is not true. NAT64 doesn't assume anything about the host, while PNAT6= 4 assumes that the host implements PNAT64. =3D> Your comment does not help solve/avoid the problem! Wassim H. From simon.perreault@viagenie.ca Fri Aug 28 08:41:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB483A6840 for ; Fri, 28 Aug 2009 08:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMg1W3Z2zdwP for ; Fri, 28 Aug 2009 08:41:25 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B312A3A68E5 for ; Fri, 28 Aug 2009 08:41:24 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 3702629E1601; Fri, 28 Aug 2009 11:41:31 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 2D37D29E15BE; Fri, 28 Aug 2009 11:41:31 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Wassim Haddad Date: Fri, 28 Aug 2009 11:41:28 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <200908280743.18009.simon.perreault@viagenie.ca> <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908281141.28240.simon.perreault@viagenie.ca> Cc: Hui Deng , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:41:26 -0000 On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: > NAT64 doesn't assume anything about the host, while > PNAT64 assumes that the host implements PNAT64. > > => Your comment does not help solve/avoid the problem! My apologies. Here's something more constructive: It is pointless to try to solve the problem you pointed out by changing the networking stack in hosts. If this is done, then the major driver for NAT64 goes away, and there is a plethora of solutions that become possible. Therefore, it is better to ask this question: is it possible to fix the NAT64 box (and/or DNS64) so that the problem you pointed out is solved? Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From denghui02@gmail.com Fri Aug 28 20:29:43 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 885BA3A6A55 for ; Fri, 28 Aug 2009 20:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KptWoWV3JvcG for ; Fri, 28 Aug 2009 20:29:42 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 6749F3A6957 for ; Fri, 28 Aug 2009 20:29:42 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so541166eye.51 for ; Fri, 28 Aug 2009 20:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4idq92ib55mg/+0JR2UliPrV/9M5SCwFFwXD4mKjIzw=; b=fBico7kwWvcQMekMPWpTQDOpL2YEAfdHDNcdgBu/XmlOIHF6ZG1/6MceH2YY4bsd5F MchFzQj5YM20ofN/UA/ZkLLNel88tMiAU4XY8VxTdLmqUtHovEyNgqoLs9OqKk3HxwCr vUOfoBFf/HJG+707pH1QpCl9YBdrAPqwZfABs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=idT3bJL2Z9xg7i9tdRhQVyuWXCW0Mm663vwEfSDTObj5I0WLVdwCxnevYeRYgzx+fY 1SguOGwMbKDxi687uaOBVe19cPnDiW1Nyp6ihZ5kvY7K+kYsYWMwJRm7gEI/bJ9SXgEH H6X8P9WObPufYgM0Kx8NE4v9OkcccvD5hcRQE= MIME-Version: 1.0 Received: by 10.210.128.5 with SMTP id a5mr1251615ebd.32.1251516584991; Fri, 28 Aug 2009 20:29:44 -0700 (PDT) In-Reply-To: <200908280743.18009.simon.perreault@viagenie.ca> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> Date: Sat, 29 Aug 2009 11:29:44 +0800 Message-ID: <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> From: Hui Deng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 03:29:43 -0000 2009/8/28 Simon Perreault : > On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >> Current NAT64 assume host is IPv6 only, and network is IPv6 only >> connection. but PNAT64 assume host is dual stack, and network is IPv6onl= y >> connection. > > This is not true. NAT64 doesn't assume anything about the host, while PNA= T64 > assumes that the host implements PNAT64. If you look at section 1.1 of NAT64, it says clearly about IPv6 only, you can also take a look at definition of it in the framework draft but today, please kindly help to let me know whose laptop, mobile, et al. today are IPv6 only, isn't this a strong assumption? > > This is one of the assumptions driving NAT64: we cannot modify the hosts = at > this point. If this assumption does not hold for your network, fine, you = can > use something else. But for many, it does. > > Simon > -- > DNS64 open-source =A0 --> http://ecdysis.viagenie.ca > STUN/TURN server =A0 =A0--> http://numb.viagenie.ca > vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org > > From denghui02@gmail.com Fri Aug 28 20:33:35 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14133A6957 for ; Fri, 28 Aug 2009 20:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGR2lGw7oMxn for ; Fri, 28 Aug 2009 20:33:35 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id CB1163A68A6 for ; Fri, 28 Aug 2009 20:33:15 -0700 (PDT) Received: by ewy3 with SMTP id 3so933015ewy.42 for ; Fri, 28 Aug 2009 20:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i0W33IcTA4yRFUBJ0ulp2lwaGAaOyxCZh9rKo6gMRMI=; b=oeaxZFXUS0vYPcNUguk8GjZCrYCSogau+uShea7JvGx3t+qSoyz+uPkWLW9RiAJBb7 Ri6949ESGlRVpYm0yDnH9HjhA2dSQTIG8KR+lssVlrINmDBJBMUw5n4gYPDdd+rt3T69 FMQqCQKIuFCYABw+XHdMPezKq8W21IHs7NiAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kITZJr5+EdRJTeIPU343E1uSqZmBATLwHjqhOgK0CHLLqixT91tR/bBGKaAIXQtmc1 5khlFT58YEnUjoabSxM6T84rHivUN8nY0k+qeHdZNKVbPNvUyGRf5M+5ENA8LAq75YAR 2j+u5CC0EQCu2VZk0NP3hS4ngBhdge91SN36k= MIME-Version: 1.0 Received: by 10.210.101.1 with SMTP id y1mr2150905ebb.67.1251516799130; Fri, 28 Aug 2009 20:33:19 -0700 (PDT) In-Reply-To: <200908281141.28240.simon.perreault@viagenie.ca> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <200908280743.18009.simon.perreault@viagenie.ca> <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se> <200908281141.28240.simon.perreault@viagenie.ca> Date: Sat, 29 Aug 2009 11:33:19 +0800 Message-ID: <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com> From: Hui Deng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 03:33:36 -0000 I am doubting that NAT64 doesn't change the host, how it learn translator prefix? -Hui 2009/8/28 Simon Perreault : > On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: >> NAT64 doesn't assume anything about the host, while >> PNAT64 assumes that the host implements PNAT64. >> >> =3D> Your comment does not help solve/avoid the problem! > > My apologies. Here's something more constructive: > > It is pointless to try to solve the problem you pointed out by changing t= he > networking stack in hosts. If this is done, then the major driver for NAT= 64 > goes away, and there is a plethora of solutions that become possible. > > Therefore, it is better to ask this question: is it possible to fix the N= AT64 > box (and/or DNS64) so that the problem you pointed out is solved? > > Simon > -- > DNS64 open-source =A0 --> http://ecdysis.viagenie.ca > STUN/TURN server =A0 =A0--> http://numb.viagenie.ca > vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org > > From cb.list6@gmail.com Fri Aug 28 20:49:59 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3863A6957 for ; Fri, 28 Aug 2009 20:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl-IO0SBgugX for ; Fri, 28 Aug 2009 20:49:58 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id CCBCB3A6856 for ; Fri, 28 Aug 2009 20:49:58 -0700 (PDT) Received: by pzk38 with SMTP id 38so2599640pzk.5 for ; Fri, 28 Aug 2009 20:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=S52DldypC7jl3vqJCzd6CiyzJAYT3rM+vy/et2RMfaU=; b=eqG86EVxBu51gfNIdgja6G4WAWytlJC1bqmQ3sWsrtUz7GXtF6hxVPbHpfyaAK52nz SXDSvhTycGXmKbqpgpq6pdRSepFH+/2ijAHcwOFbs7vSAhCJ2rdDhIF6RC48gxNtmCiI q7lNH0JVHLlsUow1Z+I91DavYIVpWjCjzbUm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eQteDEAjhCNmMpEKVxWKc8yKVavlLuK/YM5YtEssDvzlzaOCTrunWyjMoxQSlCVvwQ f7dhqEgOC+MJhqxiOTYvnWplEh+UL3lwsmAGeEU1tKz/o9OWp9Ey0DZD3kf//E9cIUmT cMhvYdhI8j3mx8NfPgBos3ut0YzOFlXoz/0j8= MIME-Version: 1.0 Received: by 10.140.127.21 with SMTP id z21mr1024765rvc.147.1251517801758; Fri, 28 Aug 2009 20:50:01 -0700 (PDT) In-Reply-To: <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> Date: Fri, 28 Aug 2009 20:50:01 -0700 Message-ID: From: Cameron Byrne To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: Wassim Haddad , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 03:58:04 -0000 On Fri, Aug 28, 2009 at 8:29 PM, Hui Deng wrote: > 2009/8/28 Simon Perreault : >> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>> connection. but PNAT64 assume host is dual stack, and network is IPv6only >>> connection. >> >> This is not true. NAT64 doesn't assume anything about the host, while PNAT64 >> assumes that the host implements PNAT64. > If you look at section 1.1 of NAT64, it says clearly about IPv6 only, > you can also take a look at definition of it in the framework draft > > but today, please kindly help to let me know whose laptop, mobile, et > al. today are IPv6 only, > isn't this a strong assumption? Hui, we have had this conversation before, right? http://www.ietf.org/mail-archive/web/behave/current/msg06256.html From dwing@cisco.com Fri Aug 28 22:11:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B4E43A68F9 for ; Fri, 28 Aug 2009 22:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.666 X-Spam-Level: X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Veprg0J7wYx for ; Fri, 28 Aug 2009 22:11:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1340B3A6862 for ; Fri, 28 Aug 2009 22:11:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAEJVmEqrR7O6/2dsb2JhbACLGLQbiEABj2oFhBmBWQ X-IronPort-AV: E=Sophos;i="4.44,295,1249257600"; d="scan'208";a="377758178" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Aug 2009 05:11:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n7T5BU3V018675; Fri, 28 Aug 2009 22:11:30 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7T5BTNe002850; Sat, 29 Aug 2009 05:11:29 GMT From: "Dan Wing" To: "'Hui Deng'" , "'Simon Perreault'" References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se><200908280743.18009.simon.perreault@viagenie.ca><2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se><200908281141.28240.simon.perreault@viagenie.ca> <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com> Date: Fri, 28 Aug 2009 22:11:29 -0700 Message-ID: <044e01ca2867$2ac31150$8e71150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcooWYdDzTCw5toDQRCzOZYXDXPN0AADLWBw In-Reply-To: <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2157; t=1251522690; x=1252386690; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20NAT64=20and=20MIPv6 |Sender:=20; bh=5G9z3xvpvGo49XQzvT2tgFAxKMrW962gZnOmXjZYvn4=; b=0faPbQKJ6zxSxJ/d+yj7G+WUVDMZ6IGeOyPP043+143ZoGkAH4e1hLhDGW 02apYbD1wT3rwFNKNuzatsNAE0PhghHLI26ChQizTe5VmHesBVRsPwQ0mbSM 5LIBSx6Uu9; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Wassim Haddad' , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 05:11:25 -0000 =20 > -----Original Message----- > From: behave-bounces@ietf.org=20 > [mailto:behave-bounces@ietf.org] On Behalf Of Hui Deng > Sent: Friday, August 28, 2009 8:33 PM > To: Simon Perreault > Cc: Wassim Haddad; behave@ietf.org > Subject: Re: [BEHAVE] NAT64 and MIPv6 >=20 > I am doubting that NAT64 doesn't change the host, > how it learn translator prefix? With 6/4 translation and DNS64, the host does not need to learn the translator's prefix, except in special situations such as when the host obtains an IPv4 address literal (instead of a DNS name), such as due to = a referral to an IPv4 address literal or a protocol that only carries IPv4 address literals (e.g., deployments of protocols that use SDP). In typical situations with 6/4 translation and DNS64 -- such as HTTP = with domain names, IMAP with domain names, SMTP submission, or nearly = anything else that uses DNS -- IPv6 hosts and their applications do not need to learn = the translator's prefix. -d > -Hui >=20 > 2009/8/28 Simon Perreault : > > On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: > >> NAT64 doesn't assume anything about the host, while > >> PNAT64 assumes that the host implements PNAT64. > >> > >> =3D> Your comment does not help solve/avoid the problem! > > > > My apologies. Here's something more constructive: > > > > It is pointless to try to solve the problem you pointed out=20 > by changing the > > networking stack in hosts. If this is done, then the major=20 > driver for NAT64 > > goes away, and there is a plethora of solutions that become=20 > possible. > > > > Therefore, it is better to ask this question: is it=20 > possible to fix the NAT64 > > box (and/or DNS64) so that the problem you pointed out is solved? > > > > Simon > > -- > > DNS64 open-source =A0 --> http://ecdysis.viagenie.ca > > STUN/TURN server =A0 =A0--> http://numb.viagenie.ca > > vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Sat Aug 29 00:36:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5143A6851 for ; Sat, 29 Aug 2009 00:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcf35iWxwfYr for ; Sat, 29 Aug 2009 00:36:11 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 4DF753A6918 for ; Sat, 29 Aug 2009 00:36:10 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (174.pool85-55-26.dynamic.orange.es [85.55.26.174]) by smtp01.uc3m.es (Postfix) with ESMTP id B2B53BA5314; Sat, 29 Aug 2009 09:36:15 +0200 (CEST) Message-ID: <4A979C2F.2040407@it.uc3m.es> Date: Fri, 28 Aug 2009 10:58:23 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hui Deng References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> In-Reply-To: <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16854.003 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 07:36:12 -0000 Hui Deng escribi: > Hi, Wassim, > > The problem in your draft has been elaborated inside us before. > this is one driving force for us to design PNAT > http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01 > we guess that identify the peer side IP family type is important for > the communication. > I fail to see how this is the case for the particular problem Wassim is describing in his draft. If you have a node that is IPv4 and another is IPv6 and running MIPv6, then RO mode will fail > Current NAT64 assume host is IPv6 only, and network is IPv6 only connection. > but PNAT64 assume host is dual stack, and network is IPv6only connection. > > so, how this will help MIPv6 RO mode to work? Regards, marcelo > and NAT64 need DNS64, and PNAT64 don't need DNS64. > furthermore PNAT host understand peer side whether it is IPv4 or IPv6 > which could remove your concern in this draft. > > PNAT assume host will rely on PNAT64 for its IPv4 application, > will rely on NAT64 for its IPv6 application. > > thanks for the discussion. > > -Hui > > 2009/8/27 Wassim Haddad : > >> Dear all, >> >> Please find attached a note on NAT64 and MIPv6. >> >> >> Regards, >> >> Wassim H. >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From marcelo@it.uc3m.es Sat Aug 29 00:36:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B633A6851 for ; Sat, 29 Aug 2009 00:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2NUFW7xMzHf for ; Sat, 29 Aug 2009 00:36:11 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4E32F3A6920 for ; Sat, 29 Aug 2009 00:36:10 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (174.pool85-55-26.dynamic.orange.es [85.55.26.174]) by smtp03.uc3m.es (Postfix) with ESMTP id 872B472CE9D; Sat, 29 Aug 2009 09:36:14 +0200 (CEST) Message-ID: <4A9799AC.8050109@it.uc3m.es> Date: Fri, 28 Aug 2009 10:47:40 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Wassim Haddad References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16854.003 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 07:36:12 -0000 Hi Wassim, I understand that the first point being made in the draft is that RO mode doesn't work through NAT64. I certainly agree with that and this was identified RFC 4966. During the requirement discussion, the input from the mobility community was that the support for the RO mode in nat64 was not critical and that it was acceptable to fall back to BT mode in case there is a NAT64 along the path. I am not sure if you agree with that. In case you don't, it would be possible to overcome this by having the NAT64 to terminate the RO procedure (i.e. that the NAT64 replies the RR signalling so that the path is optimized to the nat64, sicne it cannot be optimized to the CN). I think it would be possible to define the nat64 extensions needed for that. Then in your draft, you state that: In this case, the MN tunnels first its data packets to its HA without having them being intercepted by the foreign NAT64. However, after reaching the HA, the data packets will most likely be dropped at some point. This is due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6 address. I am not sure i understand that part. Are you saying that in case the MN decides to move to RO mode things won't work anymore or are you saying that data packets will be lost in BT mode? If you are saying that the RO mode doesn't work, i agree with you as i mentioned above. If you are saying that data packets are lost in BT mode (when RO mode is not used at all), that i don't understnad the scenario, and i would appreciate a figure to understand it better. Regards, marcelo Wassim Haddad escribi: > Dear all, > > Please find attached a note on NAT64 and MIPv6. > > > Regards, > > Wassim H. > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Sat Aug 29 01:07:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC3C3A6945 for ; Sat, 29 Aug 2009 01:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZtD2HW65wRK for ; Sat, 29 Aug 2009 01:07:20 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4D8903A6862 for ; Sat, 29 Aug 2009 01:07:19 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (174.pool85-55-26.dynamic.orange.es [85.55.26.174]) by smtp03.uc3m.es (Postfix) with ESMTP id 46A2C731E2A; Sat, 29 Aug 2009 10:07:25 +0200 (CEST) Message-ID: <4A98E1BC.70807@it.uc3m.es> Date: Sat, 29 Aug 2009 10:07:24 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Simon Perreault References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <200908280743.18009.simon.perreault@viagenie.ca> <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se> <200908281141.28240.simon.perreault@viagenie.ca> In-Reply-To: <200908281141.28240.simon.perreault@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16854.003 Cc: Hui Deng , Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 08:07:21 -0000 Simon Perreault escribi: > On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: > >> NAT64 doesn't assume anything about the host, while >> PNAT64 assumes that the host implements PNAT64. >> >> => Your comment does not help solve/avoid the problem! >> > > My apologies. Here's something more constructive: > > It is pointless to try to solve the problem you pointed out by changing the > networking stack in hosts. If this is done, then the major driver for NAT64 > goes away, and there is a plethora of solutions that become possible. > > Therefore, it is better to ask this question: is it possible to fix the NAT64 > box (and/or DNS64) so that the problem you pointed out is solved? > I think it is (at least if the problem is the lack of RO support which is what i understood from the draft) It basically implies that the nat64 terminates the RO RR signaling on behalf of the IPv4 node. I think this can be done. But, when i raised this question in v6ops during the requirements, several people from the mobility community deemed it was not needed. Maybe we can ask this again and see if they still think the same thing. Maybe it would be more constructive doing it by writing a draft describing the changes needed to nat64. Regards, marcelo > Simon > From marcelo@it.uc3m.es Sat Aug 29 01:09:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18C03A6AC6 for ; Sat, 29 Aug 2009 01:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kipdOsUPECO for ; Sat, 29 Aug 2009 01:09:36 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id EE0033A6A2E for ; Sat, 29 Aug 2009 01:09:35 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (174.pool85-55-26.dynamic.orange.es [85.55.26.174]) by smtp03.uc3m.es (Postfix) with ESMTP id 3BB717F05E0; Sat, 29 Aug 2009 10:09:41 +0200 (CEST) Message-ID: <4A98E244.1060605@it.uc3m.es> Date: Sat, 29 Aug 2009 10:09:40 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hui Deng References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <200908280743.18009.simon.perreault@viagenie.ca> <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se> <200908281141.28240.simon.perreault@viagenie.ca> <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com> In-Reply-To: <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16854.003 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 08:09:37 -0000 Hui Deng escribi: > I am doubting that NAT64 doesn't change the host, > how it learn translator prefix? > the host behind a nat64 doesn't need to learn the prefix for the basic support i.e. to support basic applications (such as any application that works through nat today) and to support a validating stub resolver. Regards, marcelo > -Hui > > 2009/8/28 Simon Perreault : > >> On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: >> >>> NAT64 doesn't assume anything about the host, while >>> PNAT64 assumes that the host implements PNAT64. >>> >>> => Your comment does not help solve/avoid the problem! >>> >> My apologies. Here's something more constructive: >> >> It is pointless to try to solve the problem you pointed out by changing the >> networking stack in hosts. If this is done, then the major driver for NAT64 >> goes away, and there is a plethora of solutions that become possible. >> >> Therefore, it is better to ask this question: is it possible to fix the NAT64 >> box (and/or DNS64) so that the problem you pointed out is solved? >> >> Simon >> -- >> DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> vCard 4.0 --> http://www.vcarddav.org >> >> >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From marcelo@it.uc3m.es Sat Aug 29 01:12:30 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19303A6C30 for ; Sat, 29 Aug 2009 01:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.896 X-Spam-Level: X-Spam-Status: No, score=-5.896 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpMtn6JqkwLe for ; Sat, 29 Aug 2009 01:12:29 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A48193A6BED for ; Sat, 29 Aug 2009 01:12:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (174.pool85-55-26.dynamic.orange.es [85.55.26.174]) by smtp01.uc3m.es (Postfix) with ESMTP id B473ABA524F; Sat, 29 Aug 2009 10:12:34 +0200 (CEST) Message-ID: <4A98E2F2.4020401@it.uc3m.es> Date: Sat, 29 Aug 2009 10:12:34 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hui Deng References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> In-Reply-To: <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16854.003 Cc: Wassim Haddad , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 08:12:30 -0000 Hui Deng escribi: > 2009/8/28 Simon Perreault : > >> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >> >>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>> connection. but PNAT64 assume host is dual stack, and network is IPv6only >>> connection. >>> >> This is not true. NAT64 doesn't assume anything about the host, while PNAT64 >> assumes that the host implements PNAT64. >> > If you look at section 1.1 of NAT64, it says clearly about IPv6 only, > you can also take a look at definition of it in the framework draft > IPv6 only means that the the host doesn't have IPv4 connectivity, either cause it doesn't have the ipv4 stack or because it does have the stack but it doens't have an ipv6 that it can use for the communication (in general it doens't have a global ipv6 address) > but today, please kindly help to let me know whose laptop, mobile, et > al. today are IPv6 only, > if they are connected to an netwrok that doesn't provide an IPv4 address, they are Regards, marcerlo > isn't this a strong assumption? > > >> This is one of the assumptions driving NAT64: we cannot modify the hosts at >> this point. If this assumption does not hold for your network, fine, you can >> use something else. But for many, it does. >> >> Simon >> -- >> DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> vCard 4.0 --> http://www.vcarddav.org >> >> >> > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From zhangdong_rh@huaweisymantec.com Sat Aug 29 02:18:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD22F3A68BB for ; Sat, 29 Aug 2009 02:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.482 X-Spam-Level: X-Spam-Status: No, score=-0.482 tagged_above=-999 required=5 tests=[AWL=1.517, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0xeXXpp8CH1 for ; Sat, 29 Aug 2009 02:18:44 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id B15F43A68A5 for ; Sat, 29 Aug 2009 02:18:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=gb2312 Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KP40009CSITFF80@hstga01-in.huaweisymantec.com> for behave@ietf.org; Sat, 29 Aug 2009 17:18:29 +0800 (CST) Received: from z90001956 ([10.27.154.76]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KP400BU7SISX010@hstml01-in.huaweisymantec.com> for behave@ietf.org; Sat, 29 Aug 2009 17:18:29 +0800 (CST) Date: Sat, 29 Aug 2009 17:18:28 +0800 From: Dong Zhang To: marcelo bagnulo braun , Hui Deng References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> Message-id: <200908291718278507165@huaweisymantec.com> X-Mailer: Foxmail 6, 10, 201, 20 [cn] Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 09:18:45 -0000 Hi, marcelo bagnulo braun 2009-08-29 Wrote: >Hui Deng escribi? >> 2009/8/28 Simon Perreault : >> >>> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >>> >>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>>> connection. but PNAT64 assume host is dual stack, and network is IPv6only >>>> connection. >>>> >>> This is not true. NAT64 doesn't assume anything about the host, while PNAT64 >>> assumes that the host implements PNAT64. >>> >> If you look at section 1.1 of NAT64, it says clearly about IPv6 only, >> you can also take a look at definition of it in the framework draft >> > >IPv6 only means that the the host doesn't have IPv4 connectivity, either >cause it doesn't have the ipv4 stack or because it does have the stack >but it doens't have an ipv6 that it can use for the communication (in >general it doens't have a global ipv6 address) IMHO, I guess the last two word "IPv6" in the sentence should be "IPv4", if I do not misunderstand. >> but today, please kindly help to let me know whose laptop, mobile, et >> al. today are IPv6 only, >> >if they are connected to an netwrok that doesn't provide an IPv4 >address, they are > >Regards, marcerlo > >> isn't this a strong assumption? >> >> >>> This is one of the assumptions driving NAT64: we cannot modify the hosts at >>> this point. If this assumption does not hold for your network, fine, you can >>> use something else. But for many, it does. >>> >>> Simon >>> -- >>> DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>> vCard 4.0 --> http://www.vcarddav.org >>> >>> >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave ------------------ Dong Zhang 2009-08-29 From denghui02@gmail.com Sat Aug 29 02:42:21 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A603A685D for ; Sat, 29 Aug 2009 02:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE89sdD4dguj for ; Sat, 29 Aug 2009 02:42:20 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id F18103A687C for ; Sat, 29 Aug 2009 02:42:19 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so564941eye.51 for ; Sat, 29 Aug 2009 02:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w4d688zkvvkCjgkUObpLbCcINgm8++lI0tici5Ue/KA=; b=dA88L1yDOqNznifQWpim7AVb+oCZtE+CuZ2Vy0IBNkf58A2fBOuqlUTh0JeY/FycZL zxSh6yalYFdkYeDPvTlMkZNNDNxIlyg2/hleHeI0kD4fYIQ1gX8lqMV6AXpqUElICF2j uJAddlY0Yz7jWpxVqh7IkgtOr7A0K6a6kJAwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=U3ql49OV4ertAkQ/piByq6VzMXOyyHTpf/rYeP0PIH63Dy6bfiagPmR+H1HCqM5MJ8 B+Z0zvlT/aZReyoQ8ZNjBZ67sBorMWSw2/tiAfMkMiBj0HZ8SCMfb2peNrU+M1NUzK7w MP4AkLb0Zm8K8mxNcoqLO7F4Y2QMJPqBEYkH4= MIME-Version: 1.0 Received: by 10.210.63.19 with SMTP id l19mr69939eba.42.1251538943513; Sat, 29 Aug 2009 02:42:23 -0700 (PDT) In-Reply-To: <4A979C2F.2040407@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <4A979C2F.2040407@it.uc3m.es> Date: Sat, 29 Aug 2009 17:42:23 +0800 Message-ID: <1d38a3350908290242v5509c77bx9efaab153f18b67b@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 09:42:21 -0000 but the host know he is talking with IPv4 node, he will not initate RO then RO will not fail consequently. but I guess for dual stack, RO may need a new solution. -Hui 2009/8/28 marcelo bagnulo braun : > Hui Deng escribi=F3: >> >> Hi, Wassim, >> >> The problem in your draft has been elaborated inside us before. >> this is one driving force for us to design PNAT >> http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01 >> we guess that identify the peer side IP family type is important for >> the communication. >> > > I fail to see how this is the case for the particular problem Wassim is > describing in his draft. > If you have a node that is IPv4 and another is IPv6 and running MIPv6, th= en > RO mode will fail >> >> Current NAT64 assume host is IPv6 only, and network is IPv6 only >> connection. >> but PNAT64 assume host is dual stack, and network is IPv6only connection= . >> >> > > so, how this will help MIPv6 RO mode to work? > > Regards, marcelo > > > >> and NAT64 need DNS64, and PNAT64 don't need DNS64. >> furthermore PNAT host understand peer side whether it is IPv4 or IPv6 >> which could remove your concern in this draft. >> >> PNAT assume host will rely on PNAT64 for its IPv4 application, >> will rely on NAT64 for its IPv6 application. >> >> thanks for the discussion. >> >> -Hui >> >> 2009/8/27 Wassim Haddad : >> >>> >>> Dear all, >>> >>> Please find attached a note on NAT64 and MIPv6. >>> >>> >>> Regards, >>> >>> Wassim H. >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > > From denghui02@gmail.com Sat Aug 29 02:52:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2D53A6899 for ; Sat, 29 Aug 2009 02:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IsHbxMmHIJR for ; Sat, 29 Aug 2009 02:52:28 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 29A3D3A687A for ; Sat, 29 Aug 2009 02:52:28 -0700 (PDT) Received: by ewy3 with SMTP id 3so1046411ewy.42 for ; Sat, 29 Aug 2009 02:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=twmclCjJ4Lb5fRFptq5TQuHb4doWZXw72stGyH8Gv8U=; b=ee/6fNsfTbmI33aAorr+yVScF6skiYeQKuO4JkHKAPwKbB/0XpBYQ37yMKi2l/PM5n tKaW+rP3X+1Rn3K3j2LGCRLXFQtFIdlph79kC6SrdoNd9Ks5NQo1tz2n7j+Ris1MDkxf 1f+fILHEu+ta5tyLFz/NVn05XM6jIVwx1Qhvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HOiUurM82gGeTRqOzwK+uFjerSVKW7Ekc3jTJQmpC0PDKjCoUqAQlGbO/Oqm90xQoW ITSc3ZSMbu26PhSFj4ms+BFEWZJ2kGLWC1HF1PPLrC18KpWbmLsiPs+x23mQOFsAl53H Rc9WUVShFv/5Hh97GE16eS18+SXSZOdo3CKR4= MIME-Version: 1.0 Received: by 10.210.63.19 with SMTP id l19mr79012eba.42.1251539552776; Sat, 29 Aug 2009 02:52:32 -0700 (PDT) In-Reply-To: <4A9799AC.8050109@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> Date: Sat, 29 Aug 2009 17:52:32 +0800 Message-ID: <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 09:52:29 -0000 firstly, I personally think that NAT64 should support IP mobility. Secondly, I don't agree to put NAT64 as the mobility agent to reply RR mess= age. Regards, -Hui 2009/8/28 marcelo bagnulo braun : > Hi Wassim, > > I understand that the first point being made in the draft is that RO mode > doesn't work through NAT64. I certainly agree with that and this was > identified RFC 4966. > During the requirement discussion, the input from the mobility community = was > that the support for the RO mode in nat64 was not critical and that it wa= s > acceptable to fall back to BT mode in case there is a NAT64 along the pat= h. > I am not sure if you agree with that. In case you don't, it would be > possible to overcome this by having the NAT64 to terminate the RO procedu= re > (i.e. that the NAT64 replies the RR signalling so that the path is optimi= zed > to the nat64, sicne it cannot be optimized to the CN). I think it would b= e > possible to define the nat64 extensions needed for that. > > Then in your draft, you state that: > > =A0In this case, the > =A0MN tunnels first its data packets to its HA without having them being > =A0intercepted by the foreign NAT64. =A0However, after reaching the HA, > =A0the data packets will most likely be dropped at some point. =A0This is > =A0due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6 > =A0address. > > I am not sure i understand that part. Are you saying that in case the MN > decides to move to RO mode things won't work anymore or are you saying th= at > data packets will be lost in BT mode? > If you are saying that the RO mode doesn't work, i agree with you as i > mentioned above. If you are saying that data packets are lost in BT mode > (when RO mode is not used at all), that i don't understnad the scenario, = and > i would appreciate a figure to understand it better. > > Regards, marcelo > > Wassim Haddad escribi=F3: >> >> Dear all, >> >> Please find attached a note on NAT64 and MIPv6. >> >> >> Regards, >> >> Wassim H. >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From denghui02@gmail.com Sat Aug 29 03:00:52 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BED13A68B2 for ; Sat, 29 Aug 2009 03:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzbXlaXI4e4U for ; Sat, 29 Aug 2009 03:00:51 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id D3C233A6856 for ; Sat, 29 Aug 2009 03:00:50 -0700 (PDT) Received: by ewy3 with SMTP id 3so1049326ewy.42 for ; Sat, 29 Aug 2009 03:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A/+ro+wc0zZZfcqkA7DR+x64mhfB7H6CkGc0kOlDe9o=; b=WvCfYs47PQ4DTM/jFt368AP/Hp5yq6psI6tg0POrG4UqftXuRjnl4mgZjOEz5N4n6K b0JdVzG8i3WNDBquCwBVE3vYrHtrZ7Ilpb7Nj4Rev7tASZyKv0JKicsEbrahq/ZQ5jGp cAXTZmfzdmEWFfpszVGypwxwTh1GyaWEKgN7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RoR31X38diMCMmK2rTzfuW8sSALDr/qP1D83KqQR/Uonb9TyVxhyKvlfIgCOduIBy1 ZFGKOqvXOZqP+UlryT/1wZeXb8xDFponU02gF2I5wUeeLFQPWQQIxidpqeEJ6fwQDtbI yDuKnw6b98D4X6iYv2RcGo1NF6SkR4XiQl7lg= MIME-Version: 1.0 Received: by 10.211.130.19 with SMTP id h19mr2529929ebn.54.1251540054404; Sat, 29 Aug 2009 03:00:54 -0700 (PDT) In-Reply-To: <4A98E2F2.4020401@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> Date: Sat, 29 Aug 2009 18:00:54 +0800 Message-ID: <1d38a3350908290300u30735251ga4ef617e653047a0@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun , =?GB2312?B?1tyyqQ==?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 10:00:52 -0000 so many people arguing me before said IPv6 only means that, and now you said differently. I am tired to find those post again, let me try to bring the definition from the framework draft IPv6-only: An IPv6-only implementation, in this context, comprises an IPv6 enabled end system stack plus routing in the network. It implies that two application instances are capable of communicating using IPv6, but not IPv4 - they have an IPv6 stack, addresses, and network support including routing in IPv6, but some element is missing that prevents communication with IPv4 hosts. I guess majority of the list have totally different understanding of IPv6 o= nly and would like to suggest to re-discuss it again, I saw one post to suggest re-wording. thanks -Hui 2009/8/29 marcelo bagnulo braun : > Hui Deng escribi=F3: >> >> 2009/8/28 Simon Perreault : >> >>> >>> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >>> >>>> >>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>>> connection. but PNAT64 assume host is dual stack, and network is >>>> IPv6only >>>> connection. >>>> >>> >>> This is not true. NAT64 doesn't assume anything about the host, while >>> PNAT64 >>> assumes that the host implements PNAT64. >>> >> >> If you look at section 1.1 of NAT64, it says clearly about IPv6 only, >> you can also take a look at definition of it in the framework draft >> > > IPv6 only means that the the host doesn't have IPv4 connectivity, either > cause it doesn't have the ipv4 stack or because it does have the stack bu= t > it doens't have an ipv6 that it can use for the communication (in general= it > doens't have a global ipv6 address) >> >> but today, please kindly help to let me know whose laptop, mobile, et >> al. today are IPv6 only, >> > > if they are connected to an netwrok that doesn't provide an IPv4 address, > they are > > Regards, marcerlo > >> isn't this a strong assumption? >> >> >>> >>> This is one of the assumptions driving NAT64: we cannot modify the host= s >>> at >>> this point. If this assumption does not hold for your network, fine, yo= u >>> can >>> use something else. But for many, it does. >>> >>> Simon >>> -- >>> DNS64 open-source =A0 --> http://ecdysis.viagenie.ca >>> STUN/TURN server =A0 =A0--> http://numb.viagenie.ca >>> vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org >>> >>> >>> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From zhouboyj@gmail.com Sat Aug 29 07:15:39 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A9A3A6A27 for ; Sat, 29 Aug 2009 07:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWmcYG6BgaBB for ; Sat, 29 Aug 2009 07:15:37 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 9BCC83A6908 for ; Sat, 29 Aug 2009 07:15:37 -0700 (PDT) Received: by iwn38 with SMTP id 38so1208724iwn.29 for ; Sat, 29 Aug 2009 07:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RyWd6mk8pZwCmY4WwW5uIyhilSCJ9o5kP/EWRx3u1VY=; b=mV+bIL2aGMH+ui4oxjR92astURMi4E3K14lpTWPqhcuuSg3ydCd8ockankbPtDiAPB 8QmFwWABX0jhsJtflTc1ZI7of/qBMuGaIDCSBnNIzbNJwKqg7NhqLqSueoJtSd6n7SEr hnuuMLhf8gtIaROz1KI4MHUhE26ZbuL8UN6io= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Egjz0LsMkdP04wZUV033XjL2tGoKvxbPfkv9vS7JZVjglcVMUSj8noRS1Xmu+s2Lkf FzcFWnZHtV3IXZ8LVjV+O4DM8jHCo7PZdUp6XdIRXfjlHJl9/5mOoKjgFmjvP70lFuQz /Z6dCW7fiyTh2qyGvzwQKab5/YY4ze9ZCnWCk= MIME-Version: 1.0 Received: by 10.231.29.149 with SMTP id q21mr2258041ibc.35.1251555341146; Sat, 29 Aug 2009 07:15:41 -0700 (PDT) In-Reply-To: <1d38a3350908290300u30735251ga4ef617e653047a0@mail.gmail.com> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> <1d38a3350908290300u30735251ga4ef617e653047a0@mail.gmail.com> Date: Sat, 29 Aug 2009 22:15:41 +0800 Message-ID: <36a593230908290715m1e60bea1n74bb6d0ccb07ac7e@mail.gmail.com> From: bo zhou To: Hui Deng Content-Type: multipart/alternative; boundary=00151774051c869d000472486fce Cc: Wassim Haddad , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 14:15:39 -0000 --00151774051c869d000472486fce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Well, I think hui mentioned the "re-wording" means the comments for the v4v= 6 framework we posted couple days ago. Related to definition of IPv6 only in the v4v6 framework draft, we think we should carefully understand the meanings of =93IPv6 only". The original comments I posted as follows: Existing =93IPv6-only=94 and =93IPv4-only=94 definitions are targeting to= IP host capabilities, but there are unclear descriptions of =93application instance= s=94 IP family host shall be defined combining with four aspects - the application type installed on the host - the IP family stack supported by a host - the IP family routing assigned by a network - available IP family connectivity According to the principles, following IP family host definitions are suggested to replace current =93IPv6-only=94 and =93IPv4-only=94 definition= s and propose a new definition for supplement IPv4 only host comprises an IPv4 enabled end system stack plus routing in the network, IPv4 applications installed on the host. It implies two application instances with installed IPv4 applications are capable of communication using IPv4, but not IPv6 =85=85 IPv6 only host comprises an IPv6 enabled end system stack plus routing in the network, IPv6 applications installed on the host. It implies two application instances with installed IPv6 applications are capable of communication using IPv6, but not IPv4 =85=85 IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications installed on the host. It implies two application instances with installed IPv4/IPv6 applications are capable of communication using IPv6 =96 they hav= e IPv4/IPv6 dual-stack, network support including routing in IPv6, IPv4/IPv6 applications can communicate with IPv4/IPv6 hosts respectively. Furthermore, the =93An IPv6 network=94 are proposed to redefined as: A specific network that has IPv6-only and IPv4-inherited IPv6implementation= . Regards, Bo Zhou On Sat, Aug 29, 2009 at 6:00 PM, Hui Deng wrote: > so many people arguing me before said IPv6 only means that, and now > you said differently. > I am tired to find those post again, > > let me try to bring the definition from the framework draft > IPv6-only: An IPv6-only implementation, in this context, comprises > an IPv6 enabled end system stack plus routing in the network. It > implies that two application instances are capable of > communicating using IPv6, but not IPv4 - they have an IPv6 stack, > addresses, and network support including routing in IPv6, but some > element is missing that prevents communication with IPv4 hosts. > > I guess majority of the list have totally different understanding of IPv6 > only > and would like to suggest to re-discuss it again, I saw one post to > suggest re-wording. > > thanks > > -Hui > > 2009/8/29 marcelo bagnulo braun : > > Hui Deng escribi=F3: > >> > >> 2009/8/28 Simon Perreault : > >> > >>> > >>> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: > >>> > >>>> > >>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only > >>>> connection. but PNAT64 assume host is dual stack, and network is > >>>> IPv6only > >>>> connection. > >>>> > >>> > >>> This is not true. NAT64 doesn't assume anything about the host, while > >>> PNAT64 > >>> assumes that the host implements PNAT64. > >>> > >> > >> If you look at section 1.1 of NAT64, it says clearly about IPv6 only, > >> you can also take a look at definition of it in the framework draft > >> > > > > IPv6 only means that the the host doesn't have IPv4 connectivity, eithe= r > > cause it doesn't have the ipv4 stack or because it does have the stack > but > > it doens't have an ipv6 that it can use for the communication (in gener= al > it > > doens't have a global ipv6 address) > >> > >> but today, please kindly help to let me know whose laptop, mobile, et > >> al. today are IPv6 only, > >> > > > > if they are connected to an netwrok that doesn't provide an IPv4 addres= s, > > they are > > > > Regards, marcerlo > > > >> isn't this a strong assumption? > >> > >> > >>> > >>> This is one of the assumptions driving NAT64: we cannot modify the > hosts > >>> at > >>> this point. If this assumption does not hold for your network, fine, > you > >>> can > >>> use something else. But for many, it does. > >>> > >>> Simon > >>> -- > >>> DNS64 open-source --> http://ecdysis.viagenie.ca > >>> STUN/TURN server --> http://numb.viagenie.ca > >>> vCard 4.0 --> http://www.vcarddav.org > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Behave mailing list > >> Behave@ietf.org > >> https://www.ietf.org/mailman/listinfo/behave > >> > >> > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --=20 Regards, Bo Zhou China Mobile --00151774051c869d000472486fce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, I think hui mentioned the "re-wording" means the comme= nts for the v4v6 framework we posted couple days ago.
Related to definition of IPv6 only in the v4v6 framework draft, we thi= nk we should carefully understand the meanings of =E2=80=9CIPv6 only".=
The original comments I posted as follows:
=C2=A0
Existing =E2=80=9CIPv6-only=E2=80=9D and = =E2=80=9CIPv4-only=E2=80=9D definitions are targeting to IP host capabiliti= es, but there are unclear descriptions of =E2=80=9Capplication instances=E2= =80=9D
IP family host shall be defined combining= with four aspects
  • the application type installed on the hos= t
  • the IP family stack supported by a host <= /span>
  • the IP family routing assigned by a netwo= rk
  • available IP family connectivity
According to the principles, following IP= family host definitions are suggested to replace current =E2=80=9C= IPv6-only=E2=80=9D and =E2=80=9CIPv4-only=E2=80=9D definitions and propose = a new definition for supplement= =C2=A0
IPv4 only host comprises an IPv4 enabled = end system stack plus routing in the network, IPv4 applications installed on the host. It implies two applicati= on instances with installed IPv4 applications are capable of communication using= IPv4, but not IPv6 =E2=80=A6=E2=80=A6
IPv6 only host comprises an IPv6 enabled = end system stack plus routing in the network, IPv6 applications installed on the host. It implies two applicati= on instances with installed IPv6 applications are capable of communication using= IPv6, but not IPv4 =E2=80=A6=E2=80=A6
IPv4-inherited IPv= 6 host comprises an IPv4/IPv6 enabled end system dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications installed on the host. I= t implies two application instances with installed IPv4/IPv6 applic= ations are capable of communication using IPv6 =E2=80=93 they have = IPv4/IPv6 dual-stack, network support including routing in IPv6, IPv4/IPv6 = applications can communicate with IPv4/IPv6 hosts respectively.
Furthermore, the =E2=80=9CAn IPv6 network= =E2=80=9D are proposed to redefined as:
A specific network that has IPv6-only and IPv4-inherited IPv6 implementation. =
Regards,
=C2=A0
Bo Zhou

On Sat, Aug 29, 2009 at 6:00 PM, Hui Deng <denghui02@gmail.com<= /a>> wrote:
so many people arguing me before= said IPv6 only means that, and now
you said differently.
I am tired = to find those post again,

let me try to bring the definition from the framework draft
=C2=A0 I= Pv6-only: =C2=A0An IPv6-only implementation, in this context, comprises
= =C2=A0 =C2=A0 =C2=A0an IPv6 enabled end system stack plus routing in the ne= twork. =C2=A0It
=C2=A0 =C2=A0 =C2=A0implies that two application instanc= es are capable of
=C2=A0 =C2=A0 =C2=A0communicating using IPv6, but not IPv4 - they have an I= Pv6 stack,
=C2=A0 =C2=A0 =C2=A0addresses, and network support including = routing in IPv6, but some
=C2=A0 =C2=A0 =C2=A0element is missing that pr= events communication with IPv4 hosts.

I guess majority of the list have totally different understanding of IP= v6 only
and would like to suggest to re-discuss it again, I saw one post= to
suggest re-wording.

thanks

-Hui

2009/8/29 marce= lo bagnulo braun <marcelo@it.uc3m.= es>:
> Hui Deng escribi=C3=B3:
>>
>> 2009= /8/28 Simon Perreault <si= mon.perreault@viagenie.ca>:
>>
>>>
>>&= gt; On Thursday 27 August 2009 22:48:38 Hui Deng wrote:
>>>
>>>>
>>>> Current NAT64 assume h= ost is IPv6 only, and network is IPv6 only
>>>> connection. = but PNAT64 assume host is dual stack, and network is
>>>> IP= v6only
>>>> connection.
>>>>
>>>
>>= ;> This is not true. NAT64 doesn't assume anything about the host, w= hile
>>> PNAT64
>>> assumes that the host implement= s PNAT64.
>>>
>>
>> If you look at section 1.1 of NAT64, i= t says clearly about IPv6 only,
>> you can also take a look at def= inition of it in the framework draft
>>
>
> IPv6 only = means that the the host doesn't have IPv4 connectivity, either
> cause it doesn't have the ipv4 stack or because it does have the s= tack but
> it doens't have an ipv6 that it can use for the commun= ication (in general it
> doens't have a global ipv6 address)
>>
>> but today, please kindly help to let me know whose lap= top, mobile, et
>> al. today are IPv6 only,
>>
>> if they are connected to an netwrok that doesn't provide an IPv4 = address,
> they are
>
> Regards, marcerlo
>
>> isn'= ;t this a strong assumption?
>>
>>
>>>
>= ;>> This is one of the assumptions driving NAT64: we cannot modify th= e hosts
>>> at
>>> this point. If this assumption does not hol= d for your network, fine, you
>>> can
>>> use somet= hing else. But for many, it does.
>>>
>>> Simon
>>> --
>>> DNS64 open-source =C2=A0 --> http://ecdysis.viagenie.ca
>>> STUN/TURN server =C2=A0 =C2=A0--> http://numb.viagenie.ca
>>> vCard 4.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://www.vcarddav.org>>>
>>>
>>>
>>
>> _____= __________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/beha= ve
>>
>>
>
>
___________________________________= ____________
Behave mailing list
B= ehave@ietf.org
https://www.ietf.org/mailman/listinfo/behave



--
Regards,

Bo Zhou
China Mobile
--00151774051c869d000472486fce-- From cb.list6@gmail.com Sat Aug 29 07:48:12 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079D43A6B5B for ; Sat, 29 Aug 2009 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czytfPEJkk1o for ; Sat, 29 Aug 2009 07:48:11 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 347DD3A6AD5 for ; Sat, 29 Aug 2009 07:48:10 -0700 (PDT) Received: by ywh3 with SMTP id 3so3590037ywh.22 for ; Sat, 29 Aug 2009 07:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=J/7jEEUGO8hUoxgRD4w/JOPAr05vsccjzy1kFkR72P4=; b=G3rlwoC0gWI+OJouooeZSZ3pzeBiUrIHnaLwnGeWYGP+4WWyQ4avxYCmRFZpGo9+8o PJbmiTVmLmzF8ounfbs4mykhosQVXsXZSA9xtVaMjc6LL4AGfFnzIs9aR8kRMLkWulOh aAHBMQrZJWGjfRqKUHGL28oyiYs5VH4Ab9eGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ko7+GRfbXZIqGJlqbigiSzyTmQhdDVAqGRL0lMo/kjzsuH2y6FxBgAbdwMgZc/J6Uf sdalWCdCT/+kpV4dWtXyVBjuvB3ISOs1eQsNsnTdi79/rURvqookg/tehEltwj90miec S5s2LZ0EdV4FnLveaC3aVN26yMvOvR4RRGd3c= MIME-Version: 1.0 Received: by 10.150.75.12 with SMTP id x12mr3174186yba.341.1251557295051; Sat, 29 Aug 2009 07:48:15 -0700 (PDT) In-Reply-To: <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> Date: Sat, 29 Aug 2009 07:48:15 -0700 Message-ID: From: Cameron Byrne To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 14:48:12 -0000 On Sat, Aug 29, 2009 at 2:52 AM, Hui Deng wrote: > firstly, I personally think that NAT64 should support IP mobility. > > Secondly, I don't agree to put NAT64 as the mobility agent to reply RR message. > I do not see a need to support MIPv6. Just like, in IPv4, i see MIPv6 as exotic. I do not believe any of the major latest and forthcoming operating systems support it out of the box. Also, if you are talking about mobility from 3GPP (2G/3G/4G) cellular mobile wireless network provider perspective, it is not required or used in any way The mobile network guys (like me) use PMIPv6 and / or GTP based mobility, both do not have any dependency on the end-host and provide all the functionality in the network without the need for MIPv6. Cameron Byrne Principal Engineer T-Mobile USA From maxpassion@gmail.com Sat Aug 29 10:58:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD8273A6962 for ; Sat, 29 Aug 2009 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qEvjVhtLDfO for ; Sat, 29 Aug 2009 10:58:04 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id C60E13A6ABC for ; Sat, 29 Aug 2009 10:57:58 -0700 (PDT) Received: by vws7 with SMTP id 7so2008940vws.29 for ; Sat, 29 Aug 2009 10:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KvTIFZUdd0N7AfsY2o9IOuGZx/8mY8C4N1tX0zf7BEA=; b=MUR8J/J7wDmr94zbzswhgLk5szB2MMFeiqdgreYvelpksjsJlPhDewKpIs/ORxCQBk TVdgyblwwRggEi/qlPjgfRccuuVCSm5Z5EP0NinUobhjbqarhlvLUW/4B++tvURdRlOh wgBL4dBfZvCrIZrxCp/6MzlZ9T/VvjD9ZQZsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JgcAe+BqJO81yB94oLtRGKaWIRC5tH7pFfyiWyhV8HO+3+bMnK9VUspKIFv/vEq9lm v/m6fwmSC5bd2eLJ7eDmVgN9Qxz5AHouxkLJmoVP1KldXDVfAxkxQrZvhU/jPiFYnKIf KeGKf5UttzoAMtiUmU/9/VWD8JLr0s2nMl7p4= MIME-Version: 1.0 Received: by 10.220.79.140 with SMTP id p12mr3093009vck.57.1251568681619; Sat, 29 Aug 2009 10:58:01 -0700 (PDT) In-Reply-To: <36a593230908232300m45a10136wce25d01ef8bac439@mail.gmail.com> References: <36a593230908232300m45a10136wce25d01ef8bac439@mail.gmail.com> Date: Sun, 30 Aug 2009 01:58:01 +0800 Message-ID: <25e1aaa40908291058h4d3fded7o9c49444184fc811b@mail.gmail.com> From: liu dapeng To: bo zhou Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: denghui02@gmail.com, congxiao@cernet.edu.cn, behave@ietf.org, phdgang@gmail.com, xing@cernet.edu.cn, fred@cisco.com, kyin@cisco.com Subject: Re: [BEHAVE] Proposed text and comments for framework for IPv4/IPv6 translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 17:58:05 -0000 2009/8/24, bo zhou : > Hi Fred and others authors of framework for IPv4/IPv6 translation > > We have some texts and comments for this draft. Originally, we tried to > propose our comments and discuss them inside last Wed's interim meeting, > Unfortunately, the shortage of time caused we have no time to address the= m. > Hence, we pointed them out here. > > 1) We need more clear IP family host definitions > Inside the draft, existing =A1=B0IPv6-only=A1=B1 and =A1=B0IPv4-only=A1= =B1 definitions are > targeting to IP host capabilities, but there are unclear descriptions of > =A1=B0application instances=A1=B1. Hence we propose the IP family host s= hall be > defined combining with four aspects: It seems that it is the time that we should investigate what is the more clear and precise definition of IPv6-only and IPv4-only host. > a. the application type installed on the host, > b.the IP family stack supported by a host > c.the IP family routing assigned by a network > d.available IP family connectivity > According to the above principles, following IP family host definitions a= re > suggested to replace current =A1=B0IPv6-only=A1=B1 and =A1=B0IPv4-only=A1= =B1 definitions and > propose a new definition for supplement: > IPv4 only host comprises an IPv4 enabled end system stack plus routing in > the network, IPv4 applications installed on the host. It implies two > application instances with installed IPv4 applications are capable of > communication using IPv4, but not IPv6 =A1=AD=A1=AD > IPv6 only host comprises an IPv6 enabled end system stack plus routing in > the network, IPv6 applications installed on the host. It implies two > application instances with installed IPv6 applications are capable of > communication using IPv6, but not IPv4 =A1=AD=A1=AD > IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system > dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications > installed on the host. It implies two application instances with installe= d > IPv4/IPv6 applications are capable of communication using IPv6 =A8C they = have > IPv4/IPv6 dual-stack, network support including routing in IPv6, IPv4/IPv= 6 > applications can communicate with IPv4/IPv6 hosts respectively. > Furthermore, the =A1=B0An IPv6 network=A1=B1 are proposed to redefined as= : A specific > network that has IPv6-only and IPv4-inherited IPv6 implementation. > > 2=A3=A9How to differentiate IPv6 network & IPv6 Internet > The difference between IPv4 network and IPv4 Internet could be identified > by > CGN (NAT) functionalities. However, there are no CGN(NAT) functionalities > defined in IPv6 world. It=A1=AFs difficult to differentiate IPv6 network = and > Internet. Hence, we suggest to re-define the IPv6 Internet in the framewo= rk > draft based on network scale size, as follows: IPv6 Internet means a glob= al > system of interconnected IPv6 networks, including enterprise=A1=AFs IPv6 > networks > and ISP=A1=AFs IPv6 networks. > Otherwise, we have to introduce a new NAT equipment with NAT66 > functionalities to differentiate IPv6 network & IPv6 Internet. > > 3) Other comments related to the contexts > Comments for 3.1.1 and 3.2.2 about stateful translation statements: > For stateful translation, the draft has mentioned =A1=B0the stateful tran= slation > only support IPv6 initiated communication=A1=B1. But NAT-PT could support= both > directional communication without this limitation. Hence, we suggest to > remove this descriptions or point out it is only targeting to NAT64 > Comments for 3.3 about ALG descriptions: > It only list the demand for FTP ALG. But there should be support any kind > of > applications in which IP address is concluded in payload, such as SIP, > RTSP. > Hence, we suggest to extend ALG scope avoid reader=A1=AFs misunderstandin= g. > > Hope all these are meaningful. > > Regards, > > Bo Zhou > China Mobile > From zhouboyj@gmail.com Sat Aug 29 11:54:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7E63A68E0 for ; Sat, 29 Aug 2009 11:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=-1.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJaGodw7sBVv for ; Sat, 29 Aug 2009 11:54:02 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 1FFB33A67F4 for ; Sat, 29 Aug 2009 11:54:02 -0700 (PDT) Received: by iwn38 with SMTP id 38so1275810iwn.29 for ; Sat, 29 Aug 2009 11:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=g/StMoGgr3lBI8k53vcDPyPcf/a+Fy+L14mShuf0Pgo=; b=EL5+7L2b5XI2e/BuWLqk8edPs9H0G34HHF7jiPz73N8zF0jwss7Ewku8w8YxnGjpIt 42e1LwDte5oI19yQBE4mN4PpdPkWDKxsFNCX9VYUPiDMOBIGi0LlqB1e6zmE9fG84FXo eHWnGZZYzK/Cf2gRxdCEQXm4HQExk9Pn8ab44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oy+yCA8KqR9nkdydux3eSwO1ozqSM7Dp+vPQ5ngIAfJuYNzYmlCm6ZhwBI0NPadn8r Lf2UD5y6+7piLq7M3dmmMmNUYDMXefWLVKxsl9o2nrSdmLmi0VFedFgMSKsd83T7aWg3 bnoEMS8fWUdfDXFYg3ESm9V5ySvfFFhtWugvQ= MIME-Version: 1.0 Received: by 10.231.124.22 with SMTP id s22mr2765289ibr.33.1251572046605; Sat, 29 Aug 2009 11:54:06 -0700 (PDT) In-Reply-To: <25e1aaa40908291058h4d3fded7o9c49444184fc811b@mail.gmail.com> References: <36a593230908232300m45a10136wce25d01ef8bac439@mail.gmail.com> <25e1aaa40908291058h4d3fded7o9c49444184fc811b@mail.gmail.com> Date: Sun, 30 Aug 2009 02:54:06 +0800 Message-ID: <36a593230908291154l5c5e343dqeb56e2e64448f35@mail.gmail.com> From: bo zhou To: liu dapeng Content-Type: multipart/alternative; boundary=0016e6468fa83fadd404724c534a Cc: denghui02@gmail.com, congxiao@cernet.edu.cn, behave@ietf.org, phdgang@gmail.com, xing@cernet.edu.cn, fred@cisco.com, kyin@cisco.com Subject: Re: [BEHAVE] Proposed text and comments for framework for IPv4/IPv6 translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 18:54:07 -0000 --0016e6468fa83fadd404724c534a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Agreed with Liu. Furthermore, as I said before, shall we introduce NAT66 to differentiate IPv6 network from IPv6 Internet as well? Regards, Bo Zhou 2009/8/30 liu dapeng > 2009/8/24, bo zhou : > > Hi Fred and others authors of framework for IPv4/IPv6 translation > > > > We have some texts and comments for this draft. Originally, we tried to > > propose our comments and discuss them inside last Wed's interim meeting= , > > Unfortunately, the shortage of time caused we have no time to address > them. > > Hence, we pointed them out here. > > > > 1) We need more clear IP family host definitions > > Inside the draft, existing =A1=B0IPv6-only=A1=B1 and =A1=B0IPv4-only=A1= =B1 definitions are > > targeting to IP host capabilities, but there are unclear descriptions o= f > > =A1=B0application instances=A1=B1. Hence we propose the IP family host= shall be > > defined combining with four aspects: > > It seems that it is the time that we should investigate what is the > more clear and precise definition of IPv6-only and IPv4-only host. > > > a. the application type installed on the host, > > b.the IP family stack supported by a host > > c.the IP family routing assigned by a network > > d.available IP family connectivity > > According to the above principles, following IP family host definitions > are > > suggested to replace current =A1=B0IPv6-only=A1=B1 and =A1=B0IPv4-only= =A1=B1 definitions and > > propose a new definition for supplement: > > IPv4 only host comprises an IPv4 enabled end system stack plus routing = in > > the network, IPv4 applications installed on the host. It implies two > > application instances with installed IPv4 applications are capable of > > communication using IPv4, but not IPv6 =A1=AD=A1=AD > > IPv6 only host comprises an IPv6 enabled end system stack plus routing = in > > the network, IPv6 applications installed on the host. It implies two > > application instances with installed IPv6 applications are capable of > > communication using IPv6, but not IPv4 =A1=AD=A1=AD > > IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system > > dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications > > installed on the host. It implies two application instances with > installed > > IPv4/IPv6 applications are capable of communication using IPv6 =A8C the= y > have > > IPv4/IPv6 dual-stack, network support including routing in IPv6, > IPv4/IPv6 > > applications can communicate with IPv4/IPv6 hosts respectively. > > Furthermore, the =A1=B0An IPv6 network=A1=B1 are proposed to redefined = as: A > specific > > network that has IPv6-only and IPv4-inherited IPv6 implementation. > > > > 2=A3=A9How to differentiate IPv6 network & IPv6 Internet > > The difference between IPv4 network and IPv4 Internet could be identifi= ed > > by > > CGN (NAT) functionalities. However, there are no CGN(NAT) functionaliti= es > > defined in IPv6 world. It=A1=AFs difficult to differentiate IPv6 networ= k and > > Internet. Hence, we suggest to re-define the IPv6 Internet in the > framework > > draft based on network scale size, as follows: IPv6 Internet means a > global > > system of interconnected IPv6 networks, including enterprise=A1=AFs IPv= 6 > > networks > > and ISP=A1=AFs IPv6 networks. > > Otherwise, we have to introduce a new NAT equipment with NAT66 > > functionalities to differentiate IPv6 network & IPv6 Internet. > > > > 3) Other comments related to the contexts > > Comments for 3.1.1 and 3.2.2 about stateful translation statements: > > For stateful translation, the draft has mentioned =A1=B0the stateful > translation > > only support IPv6 initiated communication=A1=B1. But NAT-PT could suppo= rt both > > directional communication without this limitation. Hence, we suggest to > > remove this descriptions or point out it is only targeting to NAT64 > > Comments for 3.3 about ALG descriptions: > > It only list the demand for FTP ALG. But there should be support any ki= nd > > of > > applications in which IP address is concluded in payload, such as SIP, > > RTSP. > > Hence, we suggest to extend ALG scope avoid reader=A1=AFs misunderstand= ing. > > > > Hope all these are meaningful. > > > > Regards, > > > > Bo Zhou > > China Mobile > > > --=20 Regards, Bo Zhou China Mobile --0016e6468fa83fadd404724c534a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Agreed with Liu.
Furthermore, as I said before, shall we introduce NAT66 to differentia= te IPv6 network from IPv6 Internet as well?
 
Regards,
 
Bo Zhou

2009/8/30 liu dapeng <maxpassion@gmail.com>
2009/8/24, bo zhou <zhouboyj@gmail.com>:
>  Hi Fred and others authors of framework for IP= v4/IPv6 translation
>
> We have some texts and comments for thi= s draft. Originally, we tried to
> propose our comments and discuss t= hem inside last Wed's interim meeting,
> Unfortunately, the shortage of time caused we have no time to address = them.
> Hence, we pointed them out here.
>
> 1)  We = need more clear IP family host definitions
> Inside the draft, existi= ng “IPv6-only” and “IPv4-only” definitions are
> targeting to IP host capabilities, but there are unclear descriptions = of
> “application instances”. Hence we propose the  = IP family host shall be
> defined combining with four aspects:
It seems that it is the time that we should investigate what is the<= br> more clear and precise definition of IPv6-only  and IPv4-only host.

> a. the application type installed on the host,> b.the IP family stack supported by a host
> c.the IP family ro= uting assigned by a network
> d.available IP family connectivity
> According to the above principles, following IP family host definition= s are
> suggested to replace current “IPv6-only” and &ldq= uo;IPv4-only” definitions and
> propose a new definition for su= pplement:
> IPv4 only host comprises an IPv4 enabled end system stack= plus routing in
> the network, IPv4 applications installed on the host. It implies two> application instances with installed IPv4 applications are capable o= f
> communication using IPv4, but not IPv6 ……
> I= Pv6 only host comprises an IPv6 enabled end system stack plus routing in > the network, IPv6 applications installed on the host. It implies two> application instances with installed IPv6 applications are capable o= f
> communication using IPv6, but not IPv4 ……
> I= Pv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system
> dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications> installed on the host. It implies two application instances with inst= alled
> IPv4/IPv6 applications are capable of communication using IPv= 6 – they have
> IPv4/IPv6 dual-stack, network support including routing in IPv6, IPv4/= IPv6
> applications can communicate with IPv4/IPv6 hosts respectively= .
> Furthermore, the “An IPv6 network” are proposed to re= defined as: A specific
> network that has IPv6-only and IPv4-inherited IPv6 implementation.
= >
> 2=A3=A9How to differentiate IPv6 network & IPv6 Internet> The difference between IPv4 network and IPv4 Internet could be ident= ified
> by
> CGN (NAT) functionalities. However, there are no CGN(NAT) f= unctionalities
> defined in IPv6 world. It’s difficult to diffe= rentiate IPv6 network and
> Internet. Hence, we suggest to re-define = the IPv6 Internet in the framework
> draft based on network scale size, as follows: IPv6 Internet means a g= lobal
> system of interconnected IPv6 networks, including enterprise&= rsquo;s IPv6
> networks
> and ISP’s IPv6 networks.
>= ; Otherwise, we have to introduce a new NAT equipment with NAT66
> functionalities to differentiate IPv6 network & IPv6 Internet.
= >
> 3) Other comments related to the contexts
> Comments for= 3.1.1 and 3.2.2 about stateful translation statements:
> For statefu= l translation, the draft has mentioned “the stateful translation
> only support IPv6 initiated communication”. But NAT-PT could sup= port both
> directional communication without this limitation. Hence,= we suggest to
> remove this descriptions or point out it is only tar= geting to NAT64
> Comments for 3.3 about ALG descriptions:
> It only list the dema= nd for FTP ALG. But there should be support any kind
> of
> app= lications in which IP address is concluded in payload, such as SIP,
> RTSP.
> Hence, we suggest to extend ALG scope avoid reader&rsquo= ;s misunderstanding.
>
> Hope all these are meaningful.
>=
> Regards,
>
> Bo Zhou
> China Mobile
>
<= /div>



--
Regards,

Bo Zhou
China Mobile
--0016e6468fa83fadd404724c534a-- From marcelo@it.uc3m.es Sun Aug 30 00:19:09 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B67A3A63CB for ; Sun, 30 Aug 2009 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP3i9s60cmzs for ; Sun, 30 Aug 2009 00:19:08 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E88633A6862 for ; Sun, 30 Aug 2009 00:19:07 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (132.pool85-55-22.dynamic.orange.es [85.55.22.132]) by smtp03.uc3m.es (Postfix) with ESMTP id 88008732310; Sun, 30 Aug 2009 09:19:13 +0200 (CEST) Message-ID: <4A9A27F2.4020107@it.uc3m.es> Date: Sun, 30 Aug 2009 09:19:14 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dong Zhang References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> <200908291718278507165@huaweisymantec.com> In-Reply-To: <200908291718278507165@huaweisymantec.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16856.003 Cc: Hui Deng , Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 07:19:09 -0000 right, sorry for the confusion. Dong Zhang escribi: > Hi, > > marcelo bagnulo braun 2009-08-29 Wrote: > >> Hui Deng escribi? >> >>> 2009/8/28 Simon Perreault : >>> >>> >>>> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >>>> >>>> >>>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>>>> connection. but PNAT64 assume host is dual stack, and network is IPv6only >>>>> connection. >>>>> >>>>> >>>> This is not true. NAT64 doesn't assume anything about the host, while PNAT64 >>>> assumes that the host implements PNAT64. >>>> >>>> >>> If you look at section 1.1 of NAT64, it says clearly about IPv6 only, >>> you can also take a look at definition of it in the framework draft >>> >>> >> IPv6 only means that the the host doesn't have IPv4 connectivity, either >> cause it doesn't have the ipv4 stack or because it does have the stack >> but it doens't have an ipv6 that it can use for the communication (in >> general it doens't have a global ipv6 address) >> > IMHO, I guess the last two word "IPv6" in the sentence should be "IPv4", > if I do not misunderstand. > > >>> but today, please kindly help to let me know whose laptop, mobile, et >>> al. today are IPv6 only, >>> >>> >> if they are connected to an netwrok that doesn't provide an IPv4 >> address, they are >> >> Regards, marcerlo >> >> >>> isn't this a strong assumption? >>> >>> >>> >>>> This is one of the assumptions driving NAT64: we cannot modify the hosts at >>>> this point. If this assumption does not hold for your network, fine, you can >>>> use something else. But for many, it does. >>>> >>>> Simon >>>> -- >>>> DNS64 open-source --> http://ecdysis.viagenie.ca >>>> STUN/TURN server --> http://numb.viagenie.ca >>>> vCard 4.0 --> http://www.vcarddav.org >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> > > > ------------------ > Dong Zhang > 2009-08-29 > > > From marcelo@it.uc3m.es Sun Aug 30 00:20:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47BEC3A63CB for ; Sun, 30 Aug 2009 00:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXEQGfnAMq-C for ; Sun, 30 Aug 2009 00:20:40 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 6B82F3A687E for ; Sun, 30 Aug 2009 00:20:40 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (132.pool85-55-22.dynamic.orange.es [85.55.22.132]) by smtp02.uc3m.es (Postfix) with ESMTP id 978566553B2; Sun, 30 Aug 2009 09:20:46 +0200 (CEST) Message-ID: <4A9A2850.6060008@it.uc3m.es> Date: Sun, 30 Aug 2009 09:20:48 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hui Deng References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <4A979C2F.2040407@it.uc3m.es> <1d38a3350908290242v5509c77bx9efaab153f18b67b@mail.gmail.com> In-Reply-To: <1d38a3350908290242v5509c77bx9efaab153f18b67b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16856.003 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 07:20:41 -0000 Hui Deng escribi: > but the host know he is talking with IPv4 node, he will not initate RO > then RO will not fail consequently. > ok, so you are not considering the MN being an IPv6 only node, but a dual stack node, correct? in this case, you should be looking at dsmip regards, marcelo > but I guess for dual stack, RO may need a new solution. > > > -Hui > > 2009/8/28 marcelo bagnulo braun : > >> Hui Deng escribi: >> >>> Hi, Wassim, >>> >>> The problem in your draft has been elaborated inside us before. >>> this is one driving force for us to design PNAT >>> http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01 >>> we guess that identify the peer side IP family type is important for >>> the communication. >>> >>> >> I fail to see how this is the case for the particular problem Wassim is >> describing in his draft. >> If you have a node that is IPv4 and another is IPv6 and running MIPv6, then >> RO mode will fail >> >>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>> connection. >>> but PNAT64 assume host is dual stack, and network is IPv6only connection. >>> >>> >>> >> so, how this will help MIPv6 RO mode to work? >> >> Regards, marcelo >> >> >> >> >>> and NAT64 need DNS64, and PNAT64 don't need DNS64. >>> furthermore PNAT host understand peer side whether it is IPv4 or IPv6 >>> which could remove your concern in this draft. >>> >>> PNAT assume host will rely on PNAT64 for its IPv4 application, >>> will rely on NAT64 for its IPv6 application. >>> >>> thanks for the discussion. >>> >>> -Hui >>> >>> 2009/8/27 Wassim Haddad : >>> >>> >>>> Dear all, >>>> >>>> Please find attached a note on NAT64 and MIPv6. >>>> >>>> >>>> Regards, >>>> >>>> Wassim H. >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >> >> > > From marcelo@it.uc3m.es Sun Aug 30 00:21:32 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84493A6781 for ; Sun, 30 Aug 2009 00:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7YUmOAEDTCy for ; Sun, 30 Aug 2009 00:21:31 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6C0663A69B7 for ; Sun, 30 Aug 2009 00:21:31 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (132.pool85-55-22.dynamic.orange.es [85.55.22.132]) by smtp03.uc3m.es (Postfix) with ESMTP id 92D0F732173; Sun, 30 Aug 2009 09:21:37 +0200 (CEST) Message-ID: <4A9A2883.5020104@it.uc3m.es> Date: Sun, 30 Aug 2009 09:21:39 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hui Deng References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> In-Reply-To: <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16856.003 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 07:21:32 -0000 Hui Deng escribi: > firstly, I personally think that NAT64 should support IP mobility. > define what do you mean by that > Secondly, I don't agree to put NAT64 as the mobility agent to reply RR message. > > of course > Regards, > > -Hui > > 2009/8/28 marcelo bagnulo braun : > >> Hi Wassim, >> >> I understand that the first point being made in the draft is that RO mode >> doesn't work through NAT64. I certainly agree with that and this was >> identified RFC 4966. >> During the requirement discussion, the input from the mobility community was >> that the support for the RO mode in nat64 was not critical and that it was >> acceptable to fall back to BT mode in case there is a NAT64 along the path. >> I am not sure if you agree with that. In case you don't, it would be >> possible to overcome this by having the NAT64 to terminate the RO procedure >> (i.e. that the NAT64 replies the RR signalling so that the path is optimized >> to the nat64, sicne it cannot be optimized to the CN). I think it would be >> possible to define the nat64 extensions needed for that. >> >> Then in your draft, you state that: >> >> In this case, the >> MN tunnels first its data packets to its HA without having them being >> intercepted by the foreign NAT64. However, after reaching the HA, >> the data packets will most likely be dropped at some point. This is >> due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6 >> address. >> >> I am not sure i understand that part. Are you saying that in case the MN >> decides to move to RO mode things won't work anymore or are you saying that >> data packets will be lost in BT mode? >> If you are saying that the RO mode doesn't work, i agree with you as i >> mentioned above. If you are saying that data packets are lost in BT mode >> (when RO mode is not used at all), that i don't understnad the scenario, and >> i would appreciate a figure to understand it better. >> >> Regards, marcelo >> >> Wassim Haddad escribi: >> >>> Dear all, >>> >>> Please find attached a note on NAT64 and MIPv6. >>> >>> >>> Regards, >>> >>> Wassim H. >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > From marcelo@it.uc3m.es Sun Aug 30 00:25:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4F43A6969 for ; Sun, 30 Aug 2009 00:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7OenHHlp9En for ; Sun, 30 Aug 2009 00:25:24 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 283F03A63CB for ; Sun, 30 Aug 2009 00:25:23 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (132.pool85-55-22.dynamic.orange.es [85.55.22.132]) by smtp02.uc3m.es (Postfix) with ESMTP id 4FFB96553B2; Sun, 30 Aug 2009 09:25:30 +0200 (CEST) Message-ID: <4A9A296B.5040405@it.uc3m.es> Date: Sun, 30 Aug 2009 09:25:31 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hui Deng References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> <1d38a3350908290300u30735251ga4ef617e653047a0@mail.gmail.com> In-Reply-To: <1d38a3350908290300u30735251ga4ef617e653047a0@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16856.003 Cc: Wassim Haddad , =?UTF-8?B?5ZGo5Y2a?= , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 07:25:25 -0000 Hui Deng escribió: > so many people arguing me before said IPv6 only means that, and now > you said differently. > I am tired to find those post again, > > let me try to bring the definition from the framework draft > IPv6-only: An IPv6-only implementation, in this context, comprises > an IPv6 enabled end system stack plus routing in the network. It > implies that two application instances are capable of > communicating using IPv6, but not IPv4 - they have an IPv6 stack, > addresses, and network support including routing in IPv6, but some > element is missing that prevents communication with IPv4 hosts. > > that seems perfectly fine to me so, below you stated that "but today, please kindly help to let me know whose laptop, mobile, et al. today are IPv6 only," So, if you apply the definition you quoted above and you plug your laptop in a network that is not providing IPv4 connectivity i.e. the network does not provides your laptop an ipv4 address, then your laptop is an ipv6 only node according to the definition above. > I guess majority of the list have totally different understanding of IPv6 only > and would like to suggest to re-discuss it again, I saw one post to > suggest re-wording. > > no, i think almost everyone has the same defintion Regards, marcelo > thanks > > -Hui > > 2009/8/29 marcelo bagnulo braun : > >> Hui Deng escribió: >> >>> 2009/8/28 Simon Perreault : >>> >>> >>>> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >>>> >>>> >>>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>>>> connection. but PNAT64 assume host is dual stack, and network is >>>>> IPv6only >>>>> connection. >>>>> >>>>> >>>> This is not true. NAT64 doesn't assume anything about the host, while >>>> PNAT64 >>>> assumes that the host implements PNAT64. >>>> >>>> >>> If you look at section 1.1 of NAT64, it says clearly about IPv6 only, >>> you can also take a look at definition of it in the framework draft >>> >>> >> IPv6 only means that the the host doesn't have IPv4 connectivity, either >> cause it doesn't have the ipv4 stack or because it does have the stack but >> it doens't have an ipv6 that it can use for the communication (in general it >> doens't have a global ipv6 address) >> >>> but today, please kindly help to let me know whose laptop, mobile, et >>> al. today are IPv6 only, >>> >>> >> if they are connected to an netwrok that doesn't provide an IPv4 address, >> they are >> >> Regards, marcerlo >> >> >>> isn't this a strong assumption? >>> >>> >>> >>>> This is one of the assumptions driving NAT64: we cannot modify the hosts >>>> at >>>> this point. If this assumption does not hold for your network, fine, you >>>> can >>>> use something else. But for many, it does. >>>> >>>> Simon >>>> -- >>>> DNS64 open-source --> http://ecdysis.viagenie.ca >>>> STUN/TURN server --> http://numb.viagenie.ca >>>> vCard 4.0 --> http://www.vcarddav.org >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >>> >> > > From caozhenpku@gmail.com Sun Aug 30 02:32:26 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401153A69DD for ; Sun, 30 Aug 2009 02:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy8nZa6OJhHO for ; Sun, 30 Aug 2009 02:32:25 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 5758B3A659A for ; Sun, 30 Aug 2009 02:32:25 -0700 (PDT) Received: by vws7 with SMTP id 7so2200832vws.29 for ; Sun, 30 Aug 2009 02:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WLDestfn8jK51x3yVgdOCSbdnUZE+sppiRaZjgWZNrM=; b=l3iD53qnYx8jfqT0It7VkwO94ZQ8PVyE9YwLAgJAg08POBaRmzv4oNbQfPiZzpz2ai LM7bFR+A4HZzQn7UHN5joKxSCrpnGWQyRO8T1oYeUt5wxQgKmLth960lFvMBpV31Njes O3POci0acpHLQq0RuoRuk02RO82EsnQRcF0co= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TbmzRJMVLgi/Y4PgQJXc8zdU1JUAlU4c4pa6/QHqDwjRo7/Zs/dE/BIrG+uEAxRPTn wWoYphXQz9pMYKkOB0sZLqpXDNLCcQymqg1800uH5EL7fysZXpxK06lQUwZUsWaMSEEM MbMaWSAHcO0xy3RkNFrbhREuFkh1VsgP3toLk= MIME-Version: 1.0 Received: by 10.220.107.232 with SMTP id c40mr2607074vcp.92.1251624750741; Sun, 30 Aug 2009 02:32:30 -0700 (PDT) In-Reply-To: <4A9A296B.5040405@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> <1d38a3350908290300u30735251ga4ef617e653047a0@mail.gmail.com> <4A9A296B.5040405@it.uc3m.es> Date: Sun, 30 Aug 2009 17:32:30 +0800 Message-ID: From: Zhen Cao To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Cc: Hui Deng , behave@ietf.org, Wassim Haddad , =?UTF-8?B?5ZGo5Y2a?= Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 09:32:26 -0000 >>> IPv6 only means that the the host doesn't have IPv4 connectivity, either >>> cause it doesn't have the ipv4 stack or because it does have the stack >>> but >>> it doens't have an ipv6 that it can use for the communication (in general >>> it >>> doens't have a global ipv6 address) >>> >>>> >>>> but today, please kindly help to let me know whose laptop, mobile, et >>>> al. today are IPv6 only, >>>> >>>> >>> >>> if they are connected to an netwrok that doesn't provide an IPv4 address, >>> they are This is somewhat confusing. When we are saying that a host is IPv6-only, I guess we are expressing one of its static property. But here you mean that its property is changing according to different environments. I think what you are saying here more appropriately refers to a specific scenario. But we cannot confuse a scenario with a definition. From the definition, few hosts are IPv6 only implemented. Thanks and regards, Zhen From cb.list6@gmail.com Sun Aug 30 08:20:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0EE3A67AD for ; Sun, 30 Aug 2009 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9KWdWI+goWO for ; Sun, 30 Aug 2009 08:20:07 -0700 (PDT) Received: from mail-pz0-f234.google.com (mail-pz0-f234.google.com [209.85.222.234]) by core3.amsl.com (Postfix) with ESMTP id 428313A63EC for ; Sun, 30 Aug 2009 08:20:06 -0700 (PDT) Received: by pzk23 with SMTP id 23so132477pzk.5 for ; Sun, 30 Aug 2009 08:20:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: Received: by 10.141.15.6 with SMTP id s6mr1365104rvi.12.1251645611803; Sun, 30 Aug 2009 08:20:11 -0700 (PDT) Message-ID: <00151748e88c138b5504725d7403@google.com> Date: Sun, 30 Aug 2009 15:20:11 +0000 From: cb.list6@gmail.com To: Zhen Cao Content-Type: multipart/alternative; boundary=00151748e88c138b2804725d7400 Cc: Hui Deng , Wassim Haddad , behave@ietf.org, =?UTF-8?B?5ZGo5Y2a?= Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 15:20:08 -0000 --00151748e88c138b2804725d7400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > This is somewhat confusing. When we are saying that a host is > IPv6-only, I guess we are expressing one of its static property. But > here you mean that its property is changing according to different > environments. I think what you are saying here more appropriately > refers to a specific scenario. But we cannot confuse a scenario with a > definition. From the definition, few hosts are IPv6 only implemented. Zhen, i agree that this can be confusing, but my understanding is the same as Marcelo. Here is an example scenario: I want it to act as an IPv6 only node on the my 3G UMTS carrier's network because my wireless carrier is only giving me IPv6 with NAT64 / DNS64 to bridge Internet v4 content. When i am at home on WiFi and my home gateway (cable company ds-lite on the wifi router) gives me IPv4 and IPv6 on my home WLAN, i want my laptop to act as a dual stack. When i am at work, my corporate LAN only supports IPv4, so my laptop must act as an IPv4 node only. All of these scenarios will automatically work today given current major operating systems, assuming we have a NAT64/DNS64 deployment. If your laptop is dual stack capable / enabled today, it will work in these 3 modes (v6 only, v4 only, dual stack) without any user intervention. Regards, Cameron Byrne Principal Engineer T-Mobile USA --00151748e88c138b2804725d7400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > This is somewhat confusing. When we are saying that a host is
>= ;
> IPv6-only, I guess we are expressing one of its static propert= y. But
>
> here you mean that its property is changing acc= ording to different
>
> environments. I think what you are= saying here more appropriately
>
> refers to a specific s= cenario. But we cannot confuse a scenario with a
>
> defin= ition. From the definition, few hosts are IPv6 only implemented.
> =

Zhen, i agree that this can be confusing, but my understanding = is the same as Marcelo. Here is an example scenario: I want it to act as = an IPv6 only node on the my 3G UMTS carrier's network because my wirele= ss carrier is only giving me IPv6 with NAT64 / DNS64 to bridge Internet v4 = content. When i am at home on WiFi and my home gateway (cable company ds-l= ite on the wifi router) gives me IPv4 and IPv6 on my home WLAN, i want my l= aptop to act as a dual stack. When i am at work, my corporate LAN only su= pports IPv4, so my laptop must act as an IPv4 node only. All of these scen= arios will automatically work today given current major operating systems, = assuming we have a NAT64/DNS64 deployment.

If your laptop is d= ual stack capable / enabled today, it will work in these 3 modes (v6 only, = v4 only, dual stack) without any user intervention.

Regards,
Cameron Byrne
Principal Engineer
T-Mobile USA --00151748e88c138b2804725d7400-- From caozhenpku@gmail.com Sun Aug 30 08:37:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A38428C136 for ; Sun, 30 Aug 2009 08:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSmsfcaGurnz for ; Sun, 30 Aug 2009 08:37:03 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 3A99928C13B for ; Sun, 30 Aug 2009 08:37:03 -0700 (PDT) Received: by vws7 with SMTP id 7so2285528vws.29 for ; Sun, 30 Aug 2009 08:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8lri85PgXZbYRakXr/a9LZXQ369s4TUkHt48hH5c+Q4=; b=BVYHYqAfehwh+NcOl7iUHzumoaFIXbvcPKF/YIsvzpnCBCEYQn6zZeyi+EXR5sl+NG RE8kZ+KvnYvA7xHzETG+LOwJJnMgNPuZk2nXTpoVCQnLzHpzf7jz/hBBXVZeaFDGltl5 RMA3obCEmoNS+0a2mGNWTxVsQF/luzMjaxmM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U9NXh9NnztBFuX6nPuMv5ed24ypW6zPU1rkAhXoGIVmB1hI6Dmmp6re+oyAyiAizxF BawszTKLmpEM8Pg06Q3UKou/er/dlAvxxIs6yxJtTgo5R1vDrZNtfBZs3lr/2JDowgCL 35rDF79adsiLBRC+zcQ4opEeEGf5Im3fab8Ls= MIME-Version: 1.0 Received: by 10.220.108.42 with SMTP id d42mr4586309vcp.88.1251646629013; Sun, 30 Aug 2009 08:37:09 -0700 (PDT) In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> Date: Sun, 30 Aug 2009 23:37:08 +0800 Message-ID: From: Zhen Cao To: Wassim Haddad Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 15:37:04 -0000 Hi Wassim, One comment is, even if the HoTI message can traverse the NAT64, the IPv4 host cannot understand and handle it accordingly. Thanks, Zhen On Thu, Aug 27, 2009 at 11:25 PM, Wassim Haddad wrote: > Dear all, > > Please find attached a note on NAT64 and MIPv6. > > > Regards, > > Wassim H. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From wassim.haddad@ericsson.com Sun Aug 30 20:17:23 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A123A6CC7 for ; Sun, 30 Aug 2009 20:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ0f-5ThAVOu for ; Sun, 30 Aug 2009 20:17:22 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 4D02A3A6D17 for ; Sun, 30 Aug 2009 20:17:22 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n7V3HR2M020687; Sun, 30 Aug 2009 22:17:27 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:16:47 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:16:46 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 30 Aug 2009 23:16:46 -0400 From: Wassim Haddad To: Simon Perreault Date: Sun, 30 Aug 2009 23:16:44 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: Acon9gmUZm+i3FaxQMCBDA8q5n3QgQB8aIqX Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C42ED55@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <200908280743.18009.simon.perreault@viagenie.ca> <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se>, <200908281141.28240.simon.perreault@viagenie.ca> In-Reply-To: <200908281141.28240.simon.perreault@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Aug 2009 03:16:46.0632 (UTC) FILETIME=[78EBD280:01CA29E9] Cc: Hui Deng , Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 03:17:23 -0000 > NAT64 doesn't assume anything about the host, while > PNAT64 assumes that the host implements PNAT64. > > =3D> Your comment does not help solve/avoid the problem! It is pointless to try to solve the problem you pointed out by changing the networking stack in hosts. If this is done, then the major driver for NAT64 goes away, and there is a plethora of solutions that become possible. =3D> Just by curiosity: can you explain why? Is it that harmful if the endp= oint is kept aware of what's going on and "somehow" assist the NAT64 in its role= ?=20 Therefore, it is better to ask this question: is it possible to fix the NAT= 64 box (and/or DNS64) so that the problem you pointed out is solved? =3D> This is *your* question! :) My question/task is to try to highlight a potential problem in the current = design=20 when used by a mobile host. If the "behave community" agrees that there is= =20 indeed a problem then we'll start looking into how to solve it. Regards, Wassim H. From wassim.haddad@ericsson.com Sun Aug 30 20:29:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919153A6852 for ; Sun, 30 Aug 2009 20:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKylMkO9Ig2J for ; Sun, 30 Aug 2009 20:29:37 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 287C928C18E for ; Sun, 30 Aug 2009 20:27:45 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n7V3Roq2025991; Sun, 30 Aug 2009 22:27:50 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:27:14 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:27:14 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Sun, 30 Aug 2009 23:27:13 -0400 From: Wassim Haddad To: Dan Wing , "'Hui Deng'" , "'Simon Perreault'" Date: Sun, 30 Aug 2009 23:27:13 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AcooWYdDzTCw5toDQRCzOZYXDXPN0AADLWBwAGDkvnk= Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C42ED56@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se><200908280743.18009.simon.perreault@viagenie.ca><2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se><200908281141.28240.simon.perreault@viagenie.ca> <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com>, <044e01ca2867$2ac31150$8e71150a@cisco.com> In-Reply-To: <044e01ca2867$2ac31150$8e71150a@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Aug 2009 03:27:14.0435 (UTC) FILETIME=[EF1EF530:01CA29EA] Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 03:29:38 -0000 Hi Dan, > I am doubting that NAT64 doesn't change the host, > how it learn translator prefix? With 6/4 translation and DNS64, the host does not need to learn the translator's prefix, except in special situations such as when the host obtains an IPv4 address literal (instead of a DNS name), such as due to a referral to an IPv4 address literal or a protocol that only carries IPv4 address literals (e.g., deployments of protocols that use SDP). =3D> Just a quick question please: if I take the definitions of "referral" = and=20 "callback" as mentioned in Erik's draft (draft-nordmark-multi6dt-refer-00),= =20 wouldn't be a problem in some scenarios if the referral is a DNS64-made=20 v6 address or if the stored peer's address is also a DNS64-made v6 address?= =20 Regards, Wassim H. > -Hui > > 2009/8/28 Simon Perreault : > > On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: > >> NAT64 doesn't assume anything about the host, while > >> PNAT64 assumes that the host implements PNAT64. > >> > >> =3D> Your comment does not help solve/avoid the problem! > > > > My apologies. Here's something more constructive: > > > > It is pointless to try to solve the problem you pointed out > by changing the > > networking stack in hosts. If this is done, then the major > driver for NAT64 > > goes away, and there is a plethora of solutions that become > possible. > > > > Therefore, it is better to ask this question: is it > possible to fix the NAT64 > > box (and/or DNS64) so that the problem you pointed out is solved? > > > > Simon > > -- > > DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca > > vCard 4.0 --> http://www.vcarddav.org > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From wassim.haddad@ericsson.com Sun Aug 30 20:45:41 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B627428C1A0 for ; Sun, 30 Aug 2009 20:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Iltnoygk9IQ for ; Sun, 30 Aug 2009 20:45:40 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D017728C18F for ; Sun, 30 Aug 2009 20:45:40 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n7V3jnpt005434; Sun, 30 Aug 2009 22:45:50 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:45:36 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:45:36 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 30 Aug 2009 23:45:36 -0400 From: Wassim Haddad To: marcelo bagnulo braun Date: Sun, 30 Aug 2009 23:45:35 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: Acooe2WgBQXu39PaQBapMaiDMVMc0gBb6IVG Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se>, <4A9799AC.8050109@it.uc3m.es> In-Reply-To: <4A9799AC.8050109@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Aug 2009 03:45:36.0541 (UTC) FILETIME=[8006FCD0:01CA29ED] Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 03:45:41 -0000 Hi Marcelo, Thanks for the notes. Please see mine inline. >I understand that the first point being made in the draft is that RO >mode doesn't work through NAT64. I certainly agree with that and this >was identified RFC 4966. =3D> OK >During the requirement discussion, the input from the mobility community >was that the support for the RO mode in nat64 was not critical and that >it was acceptable to fall back to BT mode in case there is a NAT64 along >the path. I am not sure if you agree with that.=20 =3D> I don't think we have much choices here. The CN is an IPv4 node only s= o it does not understand RO mode... > In case you don't, it would be possible to overcome this by having the NA= T64=20 > to terminate the RO procedure (i.e. that the NAT64 replies the RR signall= ing=20 > so that the path is optimized to the nat64, sicne it cannot be optimized = to the=20 CN). =3D> I see no problem with that. It should work fine if a MN starts a sessi= on with a=20 CN while at home then moves to a foreign network (equipped with NAT64), tri= es=20 RR and fails then stays with the BT mode.=20 >I think it would be possible to define the nat64 extensions needed for tha= t. =3D> Agree.=20 >Then in your draft, you state that: > > In this case, the > MN tunnels first its data packets to its HA without having them being > intercepted by the foreign NAT64. However, after reaching the HA, > the data packets will most likely be dropped at some point. This is > due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6 > address. I am not sure i understand that part. Are you saying that in case the MN decides to move to RO mode things won't work anymore or are you saying that data packets will be lost in BT mode? =3D> First, am sorry for a possible confusion! But you cut the first part o= f the text! :) What I meant is that when the MN moves to a foreign network and decides to= =20 initiate a new session with a v4 CN then: a) we can forget about RO mode here BUT this is not the problem. b) the MN will try to reach the CN via BT mode but even in this case, it wi= ll=20 ultimately fail because the packet won't reach the home NAT64 in order to g= et=20 translated (as it is using a different prefix). > If you are saying that the RO mode doesn't work, i agree with you as i > mentioned above. If you are saying that data packets are lost in BT mode > (when RO mode is not used at all), that i don't understnad the scenario, > and i would appreciate a figure to understand it better. =3D> Hope the above helps? Regards, Wassim H. From wassim.haddad@ericsson.com Sun Aug 30 20:54:58 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41C43A6D89 for ; Sun, 30 Aug 2009 20:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9R9aNhFJS8L for ; Sun, 30 Aug 2009 20:54:58 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 1CCA93A6D4D for ; Sun, 30 Aug 2009 20:54:57 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n7V3t35M012943; Sun, 30 Aug 2009 22:55:04 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:54:34 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Aug 2009 22:54:33 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 30 Aug 2009 23:54:33 -0400 From: Wassim Haddad To: Hui Deng , marcelo bagnulo braun Date: Sun, 30 Aug 2009 23:51:51 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AcoojnL5JAMF4DMWTM6UgEDXRRzltgBX+yMY Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C42ED59@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es>, <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> In-Reply-To: <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Aug 2009 03:54:34.0074 (UTC) FILETIME=[C06C03A0:01CA29EE] Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 03:54:58 -0000 Hi Hui, >firstly, I personally think that NAT64 should support IP mobility. >Secondly, I don't agree to put NAT64 as the mobility agent to reply RR mes= sage. =3D> I think am lost here! Can you please explain what you mean by "NAT64 r= eplies to RR messages"? Regards, Wassim H. From xing@cernet.edu.cn Mon Aug 31 00:29:07 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB873A6B09 for ; Mon, 31 Aug 2009 00:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.222 X-Spam-Level: ** X-Spam-Status: No, score=2.222 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I03t505C5POZ for ; Mon, 31 Aug 2009 00:29:06 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id C3B753A6D8D for ; Mon, 31 Aug 2009 00:29:04 -0700 (PDT) Received: from [59.66.24.75]([59.66.24.75]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm414a9ba4e0; Mon, 31 Aug 2009 15:29:12 +0800 Message-ID: <4A9B7BA1.6000807@cernet.edu.cn> Date: Mon, 31 Aug 2009 15:28:33 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: bo zhou References: <36a593230908232300m45a10136wce25d01ef8bac439@mail.gmail.com> In-Reply-To: <36a593230908232300m45a10136wce25d01ef8bac439@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: g2MUBiWB Cc: denghui02@gmail.com, congxiao@cernet.edu.cn, behave@ietf.org, liu dapeng , kyin@cisco.com, fred@cisco.com, phdgang@gmail.com Subject: Re: [BEHAVE] Proposed text and comments for framework for IPv4/IPv6 translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 07:29:07 -0000 Thanks for the comments. (1) Personally, I think the following definition is clear. IPv6-only: An IPv6-only implementation, in this context, comprises an IPv6 enabled end system stack plus routing in the network. It implies that two application instances are capable of communicating using IPv6, but not IPv4 - they have an IPv6 stack, addresses, and network support including routing in IPv6, but some element is missing that prevents communication with IPv4 hosts. However, if the consensus is to add the discussion on application instances, I am happy to add the words. (2) Please see the Sec. 1.2, the border between an IPvx network and the IPvx Internet is not defined by NAT. (3) Other comments are inline. Regards, xing bo zhou 写道: > Hi Fred and others authors of framework for IPv4/IPv6 translation > > We have some texts and comments for this draft. Originally, we tried > to propose our comments and discuss them inside last Wed's interim > meeting, Unfortunately, the shortage of time caused we have no time to > address them. Hence, we pointed them out here. > > 1) We need more clear IP family host definitions > Inside the draft, existing “IPv6-only” and “IPv4-only” definitions are > targeting to IP host capabilities, but there are unclear descriptions > of “application instances”. Hence we propose the IP family host shall > be defined combining with four aspects: > a. the application type installed on the host, > b.the IP family stack supported by a host > c.the IP family routing assigned by a network > d.available IP family connectivity > According to the above principles, following IP family host > definitions are suggested to replace current “IPv6-only” and > “IPv4-only” definitions and propose a new definition for supplement: > IPv4 only host comprises an IPv4 enabled end system stack plus routing > in the network, IPv4 applications installed on the host. It implies > two application instances with installed IPv4 applications are capable > of communication using IPv4, but not IPv6 …… > IPv6 only host comprises an IPv6 enabled end system stack plus routing > in the network, IPv6 applications installed on the host. It implies > two application instances with installed IPv6 applications are capable > of communication using IPv6, but not IPv4 …… > IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system > dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications > installed on the host. It implies two application instances with > installed IPv4/IPv6 applications are capable of communication using > IPv6 – they have IPv4/IPv6 dual-stack, network support including > routing in IPv6, IPv4/IPv6 applications can communicate with IPv4/IPv6 > hosts respectively. > Furthermore, the “An IPv6 network” are proposed to redefined as: A > specific network that has IPv6-only and IPv4-inherited IPv6 > implementation. > > 2）How to differentiate IPv6 network & IPv6 Internet > The difference between IPv4 network and IPv4 Internet could be > identified by CGN (NAT) functionalities. However, there are no > CGN(NAT) functionalities defined in IPv6 world. It’s difficult to > differentiate IPv6 network and Internet. Hence, we suggest to > re-define the IPv6 Internet in the framework draft based on network > scale size, as follows: IPv6 Internet means a global system of > interconnected IPv6 networks, including enterprise’s IPv6 networks and > ISP’s IPv6 networks. > Otherwise, we have to introduce a new NAT equipment with NAT66 > functionalities to differentiate IPv6 network & IPv6 Internet. > > 3) Other comments related to the contexts > Comments for 3.1.1 and 3.2.2 about stateful translation statements: > For stateful translation, the draft has mentioned “the stateful > translation only support IPv6 initiated communication”. But NAT-PT > could support both directional communication without this limitation. > Hence, we suggest to remove this descriptions or point out it is only > targeting to NAT64 NAT-PT was deprecated by RFC 4966. > Comments for 3.3 about ALG descriptions: > It only list the demand for FTP ALG. But there should be support any > kind of applications in which IP address is concluded in payload, such > as SIP, RTSP. Hence, we suggest to extend ALG scope avoid reader’s > misunderstanding. Yes, agree. > > Hope all these are meaningful. > > Regards, > > Bo Zhou > China Mobile > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From xing@cernet.edu.cn Mon Aug 31 00:52:45 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9923A6CFF for ; Mon, 31 Aug 2009 00:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.159 X-Spam-Level: * X-Spam-Status: No, score=1.159 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7LPLGe9aZdz for ; Mon, 31 Aug 2009 00:52:44 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 8D2733A67DF for ; Mon, 31 Aug 2009 00:52:43 -0700 (PDT) Received: from [59.66.24.75]([59.66.24.75]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54a9baa66; Mon, 31 Aug 2009 15:52:46 +0800 Message-ID: <4A9B8141.2000705@cernet.edu.cn> Date: Mon, 31 Aug 2009 15:52:33 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dave Thaler References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: gMAhBiWB Cc: Andrew Sullivan , Stig Venaas , "behave@ietf.org" , Mark Andrews Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 07:52:45 -0000 Dave Thaler 写道: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Xing Li >> Sent: Friday, August 21, 2009 5:32 AM >> To: Stig Venaas >> Cc: Andrew Sullivan; behave@ietf.org; Mark Andrews >> Subject: Re: [BEHAVE] DNS64 handling of multicast addresses >> >> I think the special handling of the multicast addresses should also be >> in the xlate and/or address-format documents. xing >> >> Stig Venaas 写道: >> >>> Mark Andrews wrote: >>> >>>> In message <4A8B7E35.9070500@venaas.com>, Stig Venaas writes: >>>> >>>>> Mark Andrews wrote: >>>>> >>>>>> In message <20090818165041.GI3163@shinkuro.com>, Andrew Sullivan >>>>>> writes: >>>>>> >>>>>>> Mark, >>>>>>> >>>>>>> On Mon, Aug 17, 2009 at 09:28:06AM +1000, Mark Andrews wrote: >>>>>>> >>>>>>> >>>>>>>> DNS64 is a unicast translator, i.e class A, B and C address. >>>>>>>> >> Class >> >>>>>>>> D and E are out of scope for DNS64. Anything else is local >>>>>>>> configuration >>>>>>>> > > I don't see why the DNS64 shouldn't be capable of doing multicast > address translation too, if such is used. If, for example, a DNS64 > is configured with a set of IPv4 prefixes and the corresponding IPv6 > prefix for each, it shouldn't have to check whether the address is > unicast or multicast. Of course either all prefixes have to have the > same suffix algorithm (zero-pad and embed, or embed and zero-pad, or > whatever else) or else you have to configure the algorithm per prefix > too. > > I mean we should discuss the multicast in (1) address-format document, since multicast addresses should be mapped differently compared with the unicast addresses. (2) xlate document, since the multicast packets should be translated differently compared with the unicast packets. yes, dns64 (and dns46) must defined the methods for the multicast name/address processing. regards, xing > -Dave > > From xing@cernet.edu.cn Mon Aug 31 00:56:16 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163A63A6BBD for ; Mon, 31 Aug 2009 00:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP-txylZquPP for ; Mon, 31 Aug 2009 00:56:15 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 874A23A6B27 for ; Mon, 31 Aug 2009 00:56:14 -0700 (PDT) Received: from [59.66.24.75]([59.66.24.75]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04a9bab3f; Mon, 31 Aug 2009 15:56:23 +0800 Message-ID: <4A9B820E.3090302@cernet.edu.cn> Date: Mon, 31 Aug 2009 15:55:58 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stig Venaas References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <1ACC1E41-2A91-4D8A-AA26-58CA54B68B16@muada.com> <4A9689FC.3020607@viagenie.ca> <4A969E1B.7030109@venaas.com> <4A96A08C.3060809@viagenie.ca> <4A96BD66.3030105@venaas.com> In-Reply-To: <4A96BD66.3030105@venaas.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: g85kBiWB Cc: "behave@ietf.org" , Mark Andrews , Andrew Sullivan , Dave Thaler , Marc Blanchet Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 07:56:16 -0000 Stig Venaas 写道: > Marc Blanchet wrote: >> Stig Venaas a écrit : >>> Marc Blanchet wrote: >>>> Iljitsch van Beijnum a écrit : >>>>> On 22 aug 2009, at 0:04, Dave Thaler wrote: >>>>> >>>>>> I don't see why the DNS64 shouldn't be capable of doing multicast >>>>>> address translation too, if such is used. If, for example, a DNS64 >>>>>> is configured with a set of IPv4 prefixes and the corresponding IPv6 >>>>>> prefix for each, it shouldn't have to check whether the address is >>>>>> unicast or multicast. Of course either all prefixes have to have the >>>>>> same suffix algorithm (zero-pad and embed, or embed and zero-pad, or >>>>>> whatever else) or else you have to configure the algorithm per >>>>>> prefix >>>>>> too. >>>>> I haven't followed the multicast discussion in detail, but the >>>>> problem >>>>> here is that in IPv6, there is scope information encoded in multicast >>>>> addresses. This information isn't present in IPv4 multicast >>>>> addressing, >>>>> or at least not to the same degree. This means that it's necessary to >>>>> add this information during the translation, and AFAIK this >>>>> information >>>>> can't be defaulted or algorithmically derived, so this requires >>>>> additional configuration. >>>> yes, but: one can restrict to a subset: i.e. only translate global >>>> scope >>>> groups, which is most likely what people would need. This could be a >>>> config switch within the translator. >>> This is partly why I think this should be configurable. Someone >>> managing >>> DNS64 and the translator can decide on what is appropriate. But yes, >>> it's not that hard to come up with a sensible default I think. E.g. >>> only >>> global scope. Maybe map 239/8 to scope 5... >> >> for configuration purposes, a nat64 is a forwarding device such as a >> router. by default, routers do not forward multicast trafic, but can if >> configured to do so. Therefore, I think the nat64/dns64 should not do >> any translation and forwarding of multicast traffic by default, unless >> it is explicitly configured to do so. > > Agreed. So my points regarding DNS64 are basically: > > Recommend that one can configure different IPv6 prefix mappings for > different IPv4 prefixes (and also that certain IPv4 prefixes can be > ignored). > > The above would be sufficient for DNS64 to work with multicast, even > with various scopes. What exactly those mappings could be should not be > in this document. > > The recommended default should be ignoring multicast addresses. agree. xing > > Stig > >> Marc. >> >>>> Marc. >>>> >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>>> >> >> > > From simon.perreault@viagenie.ca Mon Aug 31 04:20:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53153A6A86 for ; Mon, 31 Aug 2009 04:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M4r9P9etlTY for ; Mon, 31 Aug 2009 04:20:46 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D18573A6B33 for ; Mon, 31 Aug 2009 04:20:43 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 351AB29E1603; Mon, 31 Aug 2009 07:20:50 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 2B04B29E15F1; Mon, 31 Aug 2009 07:20:50 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Wassim Haddad Date: Mon, 31 Aug 2009 07:20:45 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <200908281141.28240.simon.perreault@viagenie.ca> <2991246A29623A4082EB2B06A2B891A41B7C42ED55@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C42ED55@EUSAACMS0703.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908310720.46171.simon.perreault@viagenie.ca> Cc: Hui Deng , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 11:20:47 -0000 On Sunday 30 August 2009 23:16:44 Wassim Haddad wrote: > It is pointless to try to solve the problem you pointed out by changing the > networking stack in hosts. If this is done, then the major driver for NAT64 > goes away, and there is a plethora of solutions that become possible. > > => Just by curiosity: can you explain why? It's just a question of meeting the deadline. Changing what is widely deployed takes time and we need a solution to IPv6 transition yesterday. > Is it that harmful if the > endpoint is kept aware of what's going on and "somehow" assist the NAT64 in > its role? Are you suggesting that basic networking would work without changes on the host, but mobility would require a fix on the host? If so, I would think that's acceptable. But that's only my opinion. > My question/task is to try to highlight a potential problem in the current > design when used by a mobile host. If the "behave community" agrees that > there is indeed a problem then we'll start looking into how to solve it. I think you can pretty much take for granted that it will agree that there is a problem. Just how big of a problem depends on who you're asking... ;-) Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From zhouboyj@gmail.com Mon Aug 31 06:51:24 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4618F28C26C for ; Mon, 31 Aug 2009 06:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4BmHklK7GPZ for ; Mon, 31 Aug 2009 06:51:23 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id C921728C25B for ; Mon, 31 Aug 2009 06:51:22 -0700 (PDT) Received: by iwn38 with SMTP id 38so1816645iwn.29 for ; Mon, 31 Aug 2009 06:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HRLeUV4iw8Odc92NfE+uX+8a9XLsnkLs2TmizMDuyuw=; b=CXPAIrLa3t0cwqDBaphP+vxjXV+vXnDRFRxwcMceId/zVrHwWxrA+lZn/khV0l31jU zR6C+c/RurdiNusbrM3g+0sLNBIK4eyDFUt0E+kng1RAeouX9JKFhNKDqC8k2kgaOSxO cJ8bdcPbiApJiDAxQGZQTB+KFzP/d13n70Qvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TJYyL3bNIX5DCzr8mj6LDFkgSCCblQg/XH/Fz/cITYsNlYrKtM2aIaXUyi8rP50dwn 7OZYgHtmwEX4g2woNeNRdDc1ITlxP00sC0CBOhhR8EPB1nKWDlR+OFZ6vBeymxSxBhFb JczFUqgpKTi9scoU+gI9Z4w9a5fVkCS9iQZcg= MIME-Version: 1.0 Received: by 10.231.121.69 with SMTP id g5mr7107731ibr.44.1251726689978; Mon, 31 Aug 2009 06:51:29 -0700 (PDT) In-Reply-To: <4A9B7BA1.6000807@cernet.edu.cn> References: <36a593230908232300m45a10136wce25d01ef8bac439@mail.gmail.com> <4A9B7BA1.6000807@cernet.edu.cn> Date: Mon, 31 Aug 2009 21:51:28 +0800 Message-ID: <36a593230908310651kd76a383j28b845bb07ebba55@mail.gmail.com> From: bo zhou To: Xing Li Content-Type: multipart/alternative; boundary=0016e644cd96b65bd10472705463 Cc: denghui02@gmail.com, congxiao@cernet.edu.cn, behave@ietf.org, liu dapeng , kyin@cisco.com, fred@cisco.com, phdgang@gmail.com Subject: Re: [BEHAVE] Proposed text and comments for framework for IPv4/IPv6 translation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 13:51:24 -0000 --0016e644cd96b65bd10472705463 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for your reply. Reply inline. Regards, Bo Zhou On Mon, Aug 31, 2009 at 3:28 PM, Xing Li wrote: > Thanks for the comments. > > (1) Personally, I think the following definition is clear. > > IPv6-only: An IPv6-only implementation, in this context, comprises > an IPv6 enabled end system stack plus routing in the network. It > implies that two application instances are capable of > communicating using IPv6, but not IPv4 - they have an IPv6 stack, > addresses, and network support including routing in IPv6, but some > element is missing that prevents communication with IPv4 hosts. > > However, if the consensus is to add the discussion on application > instances, I am happy to add the words. > [bo] Yes, we want to introduce the application type to make the definition more clearly. > > (2) Please see the Sec. 1.2, the border between an IPvx network and the > IPvx Internet is not defined by NAT. > [bo] Sorry, I cannot find any words in Sec.1.2 to define the difference between network and Internet. > > (3) Other comments are inline. > [bo] Yes, we knew NAT-PT was deprecated by RFC 4966. However, the comment= s > we pointed out is focus on stateful translation's limitation. We think "t= he > stateful translation only support IPv6 initiated communication" is only > related to NAT64. It is hard to say "stateful translation can only suppor= t > IPv6 initiated communication" because "NAT64 can only do it". We agreed > NAT64 is one of significant stateful translation, but we do not agree it > represents all behaviours of stateful translation. > [bo]About the ALG issue, we should state "all IP packet payload included = IP > address need do ALG". > Regards, > > xing > > > bo zhou =E5=86=99=E9=81=93: > > Hi Fred and others authors of framework for IPv4/IPv6 translation >> We have some texts and comments for this draft. Originally, we tried to >> propose our comments and discuss them inside last Wed's interim meeting, >> Unfortunately, the shortage of time caused we have no time to address th= em. >> Hence, we pointed them out here. >> 1) We need more clear IP family host definitions >> Inside the draft, existing =E2=80=9CIPv6-only=E2=80=9D and =E2=80=9CIPv4= -only=E2=80=9D definitions are >> targeting to IP host capabilities, but there are unclear descriptions of >> =E2=80=9Capplication instances=E2=80=9D. Hence we propose the IP family= host shall be >> defined combining with four aspects: >> a. the application type installed on the host, >> b.the IP family stack supported by a host >> c.the IP family routing assigned by a network >> d.available IP family connectivity >> According to the above principles, following IP family host definitions >> are suggested to replace current =E2=80=9CIPv6-only=E2=80=9D and =E2=80= =9CIPv4-only=E2=80=9D definitions and >> propose a new definition for supplement: >> IPv4 only host comprises an IPv4 enabled end system stack plus routing i= n >> the network, IPv4 applications installed on the host. It implies two >> application instances with installed IPv4 applications are capable of >> communication using IPv4, but not IPv6 =E2=80=A6=E2=80=A6 >> IPv6 only host comprises an IPv6 enabled end system stack plus routing i= n >> the network, IPv6 applications installed on the host. It implies two >> application instances with installed IPv6 applications are capable of >> communication using IPv6, but not IPv4 =E2=80=A6=E2=80=A6 >> IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system >> dual-stack plus IPv6 routing in the network, IPv4/IPv6 applications >> installed on the host. It implies two application instances with install= ed >> IPv4/IPv6 applications are capable of communication using IPv6 =E2=80=93= they have >> IPv4/IPv6 dual-stack, network support including routing in IPv6, IPv4/IP= v6 >> applications can communicate with IPv4/IPv6 hosts respectively. >> Furthermore, the =E2=80=9CAn IPv6 network=E2=80=9D are proposed to redef= ined as: A >> specific network that has IPv6-only and IPv4-inherited IPv6 implementati= on. >> 2=EF=BC=89How to differentiate IPv6 network & IPv6 Internet >> The difference between IPv4 network and IPv4 Internet could be identifie= d >> by CGN (NAT) functionalities. However, there are no CGN(NAT) functionali= ties >> defined in IPv6 world. It=E2=80=99s difficult to differentiate IPv6 netw= ork and >> Internet. Hence, we suggest to re-define the IPv6 Internet in the framew= ork >> draft based on network scale size, as follows: IPv6 Internet means a glo= bal >> system of interconnected IPv6 networks, including enterprise=E2=80=99s I= Pv6 networks >> and ISP=E2=80=99s IPv6 networks. >> Otherwise, we have to introduce a new NAT equipment with NAT66 >> functionalities to differentiate IPv6 network & IPv6 Internet. >> 3) Other comments related to the contexts >> Comments for 3.1.1 and 3.2.2 about stateful translation statements: >> For stateful translation, the draft has mentioned =E2=80=9Cthe stateful >> translation only support IPv6 initiated communication=E2=80=9D. But NAT-= PT could >> support both directional communication without this limitation. Hence, w= e >> suggest to remove this descriptions or point out it is only targeting to >> NAT64 >> > > NAT-PT was deprecated by RFC 4966. > > Comments for 3.3 about ALG descriptions: >> It only list the demand for FTP ALG. But there should be support any kin= d >> of applications in which IP address is concluded in payload, such as SIP= , >> RTSP. Hence, we suggest to extend ALG scope avoid reader=E2=80=99s misun= derstanding. >> > > Yes, agree. > > Hope all these are meaningful. >> Regards, >> >> Bo Zhou >> China Mobile >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > --=20 Regards, Bo Zhou China Mobile --0016e644cd96b65bd10472705463 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for your reply.
Reply inline.
=C2=A0
Regards,
=C2=A0
Bo Zhou

On Mon, Aug 31, 2009 at 3:28 PM, Xing Li <xing@cernet.edu.cn= > wrote:
Thanks for the comments.

= (1) Personally, I think the following definition is clear.

=C2=A0IPv= 6-only: =C2=A0An IPv6-only implementation, in this context, comprises
=C2=A0 =C2=A0 an IPv6 enabled end system stack plus routing in the network.= =C2=A0It
=C2=A0 =C2=A0 implies that two application instances are capab= le of
=C2=A0 =C2=A0 communicating using IPv6, but not IPv4 - they have a= n IPv6 stack,
=C2=A0 =C2=A0 addresses, and network support including rou= ting in IPv6, but some
=C2=A0 =C2=A0 element is missing that prevents communication with IPv4 host= s.

However, if the consensus is to add the discussion on application= instances, I am happy to add the words.
[bo] Yes, we want to introduce the application= type to make the definition more clearly.

(2) Ple= ase see the Sec. 1.2, the border between an IPvx network and the IPvx Inter= net is not defined by NAT.
[bo] Sorry, I cannot find any words in Sec.1.2= to define the difference between network and Internet.

(3) Oth= er comments are inline.
[bo] Yes, we knew NAT-PT= was deprecated by RFC 4966. However, the comments we pointed out is focus = on stateful translation's limitation. We think "the stateful trans= lation only support IPv6 initiated communication" is only related to N= AT64.=C2=A0It is hard to=C2=A0say "stateful translation can only suppo= rt IPv6 initiated communication" because "NAT64 can only do it&qu= ot;. We agreed NAT64 is one of significant stateful translation, but we do = not agree it represents all behaviours of stateful translation.
[bo]About the ALG issue, we should state "all IP packet payload includ= ed IP address need do ALG".
=C2=A0
=C2=A0
=C2=A0
=C2=A0
Regards,
xing


bo zhou =E5=86=99=E9=81=93:=20

Hi Fred and others authors of fr= amework for IPv4/IPv6 translation
=C2=A0We have some texts and comments = for this draft. Originally, we tried to propose our comments and discuss th= em inside last Wed's interim meeting, Unfortunately, the shortage of ti= me caused we have no time to address them. Hence, we pointed them out here.=
=C2=A01) =C2=A0We need more clear IP family host definitions
Inside the = draft, existing =E2=80=9CIPv6-only=E2=80=9D and =E2=80=9CIPv4-only=E2=80=9D= definitions are targeting to IP host capabilities, but there are unclear d= escriptions of =E2=80=9Capplication instances=E2=80=9D. Hence we propose th= e =C2=A0IP family host shall be defined combining with four aspects:
a. the application type installed on the host,
b.the IP family stack sup= ported by a host
c.the IP family routing assigned by a network
d.avai= lable IP family connectivity
According to the above principles, followin= g IP family host definitions are suggested to replace current =E2=80=9CIPv6= -only=E2=80=9D and =E2=80=9CIPv4-only=E2=80=9D definitions and propose a ne= w definition for supplement:
IPv4 only host comprises an IPv4 enabled end system stack plus routing in t= he network, IPv4 applications installed on the host. It implies two applica= tion instances with installed IPv4 applications are capable of communicatio= n using IPv4, but not IPv6 =E2=80=A6=E2=80=A6
IPv6 only host comprises an IPv6 enabled end system stack plus routing in t= he network, IPv6 applications installed on the host. It implies two applica= tion instances with installed IPv6 applications are capable of communicatio= n using IPv6, but not IPv4 =E2=80=A6=E2=80=A6
IPv4-inherited IPv6 host comprises an IPv4/IPv6 enabled end system dual-sta= ck plus IPv6 routing in the network, IPv4/IPv6 applications installed on th= e host. It implies two application instances with installed IPv4/IPv6 appli= cations are capable of communication using IPv6 =E2=80=93 they have IPv4/IP= v6 dual-stack, network support including routing in IPv6, IPv4/IPv6 applica= tions can communicate with IPv4/IPv6 hosts respectively.
Furthermore, the =E2=80=9CAn IPv6 network=E2=80=9D are proposed to redefine= d as: A specific network that has IPv6-only and IPv4-inherited IPv6 impleme= ntation.
=C2=A02=EF=BC=89How to differentiate IPv6 network & IPv6 In= ternet
The difference between IPv4 network and IPv4 Internet could be id= entified by CGN (NAT) functionalities. However, there are no CGN(NAT) funct= ionalities defined in IPv6 world. It=E2=80=99s difficult to differentiate I= Pv6 network and Internet. Hence, we suggest to re-define the IPv6 Internet = in the framework draft based on network scale size, as follows: IPv6 Intern= et means a global system of interconnected IPv6 networks, including enterpr= ise=E2=80=99s IPv6 networks and ISP=E2=80=99s IPv6 networks.
Otherwise, we have to introduce a new NAT equipment with NAT66 functionalit= ies to differentiate IPv6 network & IPv6 Internet.
=C2=A03) Other co= mments related to the contexts
Comments for 3.1.1 and 3.2.2 about statef= ul translation statements:
For stateful translation, the draft has mentioned =E2=80=9Cthe stateful tra= nslation only support IPv6 initiated communication=E2=80=9D. But NAT-PT cou= ld support both directional communication without this limitation. Hence, w= e suggest to remove this descriptions or point out it is only targeting to = NAT64

NAT-PT was deprecated by RFC 4966.=20


Comments for 3.3 about ALG descr= iptions:
It only list the demand for FTP ALG. But there should be suppor= t any kind of applications in which IP address is concluded in payload, suc= h as SIP, RTSP. Hence, we suggest to extend ALG scope avoid reader=E2=80=99= s misunderstanding.

Yes, agree.

=C2=A0Hope all these are meaningful.
=C2=A0Regards,
Bo Zhou
China Mobile
-------------------------------------= -----------------------------------

________________________________= _______________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave=C2=A0




--
Regards,

Bo Zhou
China Mobile
--0016e644cd96b65bd10472705463-- From denghui02@gmail.com Mon Aug 31 08:34:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BF628C2EA for ; Mon, 31 Aug 2009 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU7OKOxPtaqJ for ; Mon, 31 Aug 2009 08:34:02 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 19B1C28C2D2 for ; Mon, 31 Aug 2009 08:34:01 -0700 (PDT) Received: by ewy3 with SMTP id 3so654871ewy.42 for ; Mon, 31 Aug 2009 08:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0dYITCV0bRC0gmI+GAmrfFTuNByyJcKs0chVcUtxe64=; b=HGCUTbzzFTIDliRsp/DWxnTMWD2HHsh2KAwWd+duq2XLwpP9sXzobtYv6+FE6LvaZA tuXioyoeCzpaU4e+qMftDTyqBBJbRDROglnDbgj/MFIi1jR5POknHXGXThw2BuH8JTS8 EizwIJ0Cg42JNBUc2SwcsEEVfTQOzHEmcrBnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QNYtsJVgwcKLvRB2nEv19Nq+h19XU/sGMuIuJl/fMwzL39HiqnoGxTLl/3fCNFRkUZ Wl02TsDsCwCo9dEVKz5Ys5z/F9vd394+9PGygi2gf6833mIEt6p/JbrgOQ9YtUi5WGDJ M5e6QmfHPeFy4rvPur98uSbVL9XruE2FjHBnc= MIME-Version: 1.0 Received: by 10.211.146.2 with SMTP id y2mr5578482ebn.77.1251732843439; Mon, 31 Aug 2009 08:34:03 -0700 (PDT) In-Reply-To: <4A9A2850.6060008@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <4A979C2F.2040407@it.uc3m.es> <1d38a3350908290242v5509c77bx9efaab153f18b67b@mail.gmail.com> <4A9A2850.6060008@it.uc3m.es> Date: Mon, 31 Aug 2009 23:34:03 +0800 Message-ID: <1d38a3350908310834m4f04f0aqb756003990516032@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 15:34:03 -0000 we are considering MN has IPv6 only connections, this is not for DSMIP. -Hui 2009/8/30 marcelo bagnulo braun : > Hui Deng escribi=F3: >> >> but the host know he is talking with IPv4 node, he will not initate RO >> then RO will not fail consequently. >> > > ok, so you are not considering the MN being an IPv6 only node, but a dual > stack node, correct? > > in this case, you should be looking at dsmip > > regards, marcelo > >> but I guess for dual stack, RO may need a new solution. >> >> > > >> -Hui >> >> 2009/8/28 marcelo bagnulo braun : >> >>> >>> Hui Deng escribi=F3: >>> >>>> >>>> Hi, Wassim, >>>> >>>> The problem in your draft has been elaborated inside us before. >>>> this is one driving force for us to design PNAT >>>> http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01 >>>> we guess that identify the peer side IP family type is important for >>>> the communication. >>>> >>>> >>> >>> I fail to see how this is the case for the particular problem Wassim is >>> describing in his draft. >>> If you have a node that is IPv4 and another is IPv6 and running MIPv6, >>> then >>> RO mode will fail >>> >>>> >>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>>> connection. >>>> but PNAT64 assume host is dual stack, and network is IPv6only >>>> connection. >>>> >>>> >>>> >>> >>> so, how this will help MIPv6 RO mode to work? >>> >>> Regards, marcelo >>> >>> >>> >>> >>>> >>>> and NAT64 need DNS64, and PNAT64 don't need DNS64. >>>> furthermore PNAT host understand peer side whether it is IPv4 or IPv6 >>>> which could remove your concern in this draft. >>>> >>>> PNAT assume host will rely on PNAT64 for its IPv4 application, >>>> will rely on NAT64 for its IPv6 application. >>>> >>>> thanks for the discussion. >>>> >>>> -Hui >>>> >>>> 2009/8/27 Wassim Haddad : >>>> >>>> >>>>> >>>>> Dear all, >>>>> >>>>> Please find attached a note on NAT64 and MIPv6. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Wassim H. >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>>> >>> >>> >> >> > > From denghui02@gmail.com Mon Aug 31 08:35:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154D128C2F4 for ; Mon, 31 Aug 2009 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEK16DSTDSM8 for ; Mon, 31 Aug 2009 08:35:05 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id BC17B28C2F5 for ; Mon, 31 Aug 2009 08:35:03 -0700 (PDT) Received: by ewy3 with SMTP id 3so656033ewy.42 for ; Mon, 31 Aug 2009 08:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jhDCgIgaS5204oaQpofLEV5dGBvGOCpD3tk511a08qw=; b=quoKYGcULB4ycsNIjTuiDfKerNgxi+YEcNpZP2ZVfv5d1Tl8MmHcLIolmliZmtp0JO WGcbTz2+sOCx7lNr3z+LxmGj49GufBBRwzfDGi+nByZm+r2WJYM0NjIWpGrRqkNMXde3 m/8RuhXfvDiS9sFUVlv+o5n2QFTk7pEWledJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ht02fcYpWSK8k5jCTdVY4EyXsnL7bzrRF5B50lsbYzCh2/aVTNNY91bvn4AvacLJv6 OtZ9ML+uTD2yeM9l6E48jBdDZQsPCZr67plrl7Wt5JGwUz/iwPF+gwYT38Txo6Wr0uD1 hm3bMGGhD+CNaZufztY45pN58pbDtSsboZKik= MIME-Version: 1.0 Received: by 10.211.152.15 with SMTP id e15mr4658516ebo.30.1251732908686; Mon, 31 Aug 2009 08:35:08 -0700 (PDT) In-Reply-To: <4A9A2883.5020104@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> <4A9A2883.5020104@it.uc3m.es> Date: Mon, 31 Aug 2009 23:35:08 +0800 Message-ID: <1d38a3350908310835g70edabfft899b827716b9a2ce@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 15:35:08 -0000 >> firstly, I personally think that NAT64 should support IP mobility. >> > > define what do you mean by that I mean Mobile IPv6/DSMIP6/PMIP6 could behave normally without any problem. -Hui >> >> Secondly, I don't agree to put NAT64 as the mobility agent to reply RR >> message. >> >> > > of course > >> Regards, >> >> -Hui >> >> 2009/8/28 marcelo bagnulo braun : >> >>> >>> Hi Wassim, >>> >>> I understand that the first point being made in the draft is that RO mo= de >>> doesn't work through NAT64. I certainly agree with that and this was >>> identified RFC 4966. >>> During the requirement discussion, the input from the mobility communit= y >>> was >>> that the support for the RO mode in nat64 was not critical and that it >>> was >>> acceptable to fall back to BT mode in case there is a NAT64 along the >>> path. >>> I am not sure if you agree with that. In case you don't, it would be >>> possible to overcome this by having the NAT64 to terminate the RO >>> procedure >>> (i.e. that the NAT64 replies the RR signalling so that the path is >>> optimized >>> to the nat64, sicne it cannot be optimized to the CN). I think it would >>> be >>> possible to define the nat64 extensions needed for that. >>> >>> Then in your draft, you state that: >>> >>> =A0In this case, the >>> =A0MN tunnels first its data packets to its HA without having them bein= g >>> =A0intercepted by the foreign NAT64. =A0However, after reaching the HA, >>> =A0the data packets will most likely be dropped at some point. =A0This = is >>> =A0due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv= 6 >>> =A0address. >>> >>> I am not sure i understand that part. Are you saying that in case the M= N >>> decides to move to RO mode things won't work anymore or are you saying >>> that >>> data packets will be lost in BT mode? >>> If you are saying that the RO mode doesn't work, i agree with you as i >>> mentioned above. If you are saying that data packets are lost in BT mod= e >>> (when RO mode is not used at all), that i don't understnad the scenario= , >>> and >>> i would appreciate a figure to understand it better. >>> >>> Regards, marcelo >>> >>> Wassim Haddad escribi=F3: >>> >>>> >>>> Dear all, >>>> >>>> Please find attached a note on NAT64 and MIPv6. >>>> >>>> >>>> Regards, >>>> >>>> Wassim H. >>>> ----------------------------------------------------------------------= -- >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >> >> > > From denghui02@gmail.com Mon Aug 31 09:04:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DA928C292 for ; Mon, 31 Aug 2009 09:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WJCFSRnaZvq for ; Mon, 31 Aug 2009 09:04:24 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 23BCE3A67DF for ; Mon, 31 Aug 2009 09:04:23 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so415691eyf.5 for ; Mon, 31 Aug 2009 09:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/q/paAlQdXnzNNGUMIs57btOFzhEl3FmOzsyokNjDGQ=; b=jCcSG2gz47llZnB3Hj4SA0fPx8qqUS1vAZVZUP9WPnu35w3kuFABfQFc4BBmVJVxS9 3+BUJKyG1unyTjwKJBOo22zpRi2KetQYjlSHOLasGvWXmDH2q538TLkLx/+eb50/NJVh royUEgK/2o9x+27rNGgg9hnBC7O0wESZAbDwY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CDayYk7W5KKpR4SBDnNeyhVrhJlVlXh1D2vinJVwvelu0H6u8QZ52SdIbeH4Jzgphj OzctBseW0AK3CHLu0QD6WA6Hi8SsWk+lrjB6ZyIT2IMm0DEno7E3S/mMA8DSCu32fp86 ACWqvQeV0TVqIIHG4fOhXulkO9I+097QDNII4= MIME-Version: 1.0 Received: by 10.211.152.15 with SMTP id e15mr4697867ebo.30.1251734672062; Mon, 31 Aug 2009 09:04:32 -0700 (PDT) In-Reply-To: <4A9A296B.5040405@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> <1d38a3350908290300u30735251ga4ef617e653047a0@mail.gmail.com> <4A9A296B.5040405@it.uc3m.es> Date: Tue, 1 Sep 2009 00:04:31 +0800 Message-ID: <1d38a3350908310904m13adea1eg966751031cc30f6b@mail.gmail.com> From: Hui Deng To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Wassim Haddad , =?GB2312?B?1tyyqQ==?= , behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:04:25 -0000 inline please 2009/8/30 marcelo bagnulo braun : > Hui Deng escribi=F3: >> >> so many people arguing me before said IPv6 only means that, and now >> you said differently. >> I am tired to find those post again, >> =A0let me try to bring the definition from the framework draft >> =A0 IPv6-only: =A0An IPv6-only implementation, in this context, comprise= s >> =A0 =A0 =A0an IPv6 enabled end system stack plus routing in the network.= =A0It >> =A0 =A0 =A0implies that two application instances are capable of >> =A0 =A0 =A0communicating using IPv6, but not IPv4 - they have an IPv6 st= ack, >> =A0 =A0 =A0addresses, and network support including routing in IPv6, but= some >> =A0 =A0 =A0element is missing that prevents communication with IPv4 host= s. >> >> > > that seems perfectly fine to me > > so, below you stated that > > "but today, please kindly help to let me know whose laptop, mobile, et al= . > today are IPv6 only," > > So, if you apply the definition you quoted above and you plug your laptop= in > a network that is not providing IPv4 connectivity i.e. the network does n= ot > provides your laptop an ipv4 address, then your laptop is an ipv6 only no= de > according to the definition above. Here you state without IPv4 address is IPv6 only, then sometime it get Ipv4 address but without IPv4 connection is another kind of IPv6 only? Anyhow, you are assuming that host is dual stack, but don't use it, then I = would like to question, why not use it? >> I guess majority of the list have totally different understanding of IPv= 6 >> only >> and would like to suggest to re-discuss it again, I saw one post to >> suggest re-wording. > no, i think almost everyone has the same defintion let me summary everybody said in the list. http://www.ietf.org/id/draft-ietf-behave-v6v4-framework-00.txt > IPv6-only: An IPv6-only implementation, in this context, comprises > an IPv6 enabled end system stack plus routing in the network. It > implies that two application instances are capable of > communicating using IPv6, but not IPv4 - they have an IPv6 stack, > addresses, and network support including routing in IPv6, but some > element is missing that prevents communication with IPv4 hosts. http://www.ietf.org/id/draft-ietf-behave-dns64-00.txt The dns64 draft also contains this statement in section 2: > By > IPv6-only hosts we mean hosts running IPv6-only applications, IPv6- > only hosts, as well as the cases where only IPv6-only connectivity is > available to the client. Iljitsch van Beijnum http://www.ietf.org/mail-archive/web/behave/current/msg06202.html Cameron Byrne http://www.ietf.org/mail-archive/web/behave/current/msg06279.html if include what you said here, I don't see they have common. Best regards, -Hui > > Regards, marcelo > > >> thanks >> >> -Hui >> >> 2009/8/29 marcelo bagnulo braun : >> >>> >>> Hui Deng escribi=F3: >>> >>>> >>>> 2009/8/28 Simon Perreault : >>>> >>>> >>>>> >>>>> On Thursday 27 August 2009 22:48:38 Hui Deng wrote: >>>>> >>>>> >>>>>> >>>>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>>>>> connection. but PNAT64 assume host is dual stack, and network is >>>>>> IPv6only >>>>>> connection. >>>>>> >>>>>> >>>>> >>>>> This is not true. NAT64 doesn't assume anything about the host, while >>>>> PNAT64 >>>>> assumes that the host implements PNAT64. >>>>> >>>>> >>>> >>>> If you look at section 1.1 of NAT64, it says clearly about IPv6 only, >>>> you can also take a look at definition of it in the framework draft >>>> >>>> >>> >>> IPv6 only means that the the host doesn't have IPv4 connectivity, eithe= r >>> cause it doesn't have the ipv4 stack or because it does have the stack >>> but >>> it doens't have an ipv6 that it can use for the communication (in gener= al >>> it >>> doens't have a global ipv6 address) >>> >>>> >>>> but today, please kindly help to let me know whose laptop, mobile, et >>>> al. today are IPv6 only, >>>> >>>> >>> >>> if they are connected to an netwrok that doesn't provide an IPv4 addres= s, >>> they are >>> >>> Regards, marcerlo >>> >>> >>>> >>>> isn't this a strong assumption? >>>> >>>> >>>> >>>>> >>>>> This is one of the assumptions driving NAT64: we cannot modify the >>>>> hosts >>>>> at >>>>> this point. If this assumption does not hold for your network, fine, >>>>> you >>>>> can >>>>> use something else. But for many, it does. >>>>> >>>>> Simon >>>>> -- >>>>> DNS64 open-source =A0 --> http://ecdysis.viagenie.ca >>>>> STUN/TURN server =A0 =A0--> http://numb.viagenie.ca >>>>> vCard 4.0 =A0 =A0 =A0 =A0 =A0 --> http://www.vcarddav.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>>> >>> >>> >> >> > > From denghui02@gmail.com Mon Aug 31 09:05:46 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED7A3A6DF6 for ; Mon, 31 Aug 2009 09:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmBRBrCF0QhT for ; Mon, 31 Aug 2009 09:05:46 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 9BF5C28C323 for ; Mon, 31 Aug 2009 09:05:45 -0700 (PDT) Received: by ewy3 with SMTP id 3so686938ewy.42 for ; Mon, 31 Aug 2009 09:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=M4XwT0yMhplksuyqqGgygA2jF41X/ZtxP0yUARZosP0=; b=lJd4vQIXrps+iNJaTgJng0LcmDGMwdDWbwKD5cpWTjfCbTOCnAPypvbeKEREz/VDnn XzILA/avnWdJNJjUDKgFkDKQiG1rzKKHCsoKNaHTtGjoIv6atc8uParkUAJVjS3qmEBk LYMhXlFPw/faeI05YoqDRwVyRrCvr/ZEps/IM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rT5+6/LSJBko75JrLJR1z1L40OO+TdBcWQ6I5EUrMx8ZN1xNkQ9DWwW0smWHKw95wd xzdFY5dCRx7qYgtPPdNwoaY1F9HZIBL2HcNUs29YwVv/JDC9ai+bQZZw+XCuXBTle+YB C0zzzqMjOJ4DiTn/PjVIy1IhQoHehWj5fCU2k= MIME-Version: 1.0 Received: by 10.210.7.21 with SMTP id 21mr5602512ebg.75.1251734748743; Mon, 31 Aug 2009 09:05:48 -0700 (PDT) In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C42ED59@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> <1d38a3350908290252n1c8ae2d4r59bb0a144b21ab2f@mail.gmail.com> <2991246A29623A4082EB2B06A2B891A41B7C42ED59@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 1 Sep 2009 00:05:48 +0800 Message-ID: <1d38a3350908310905ib0ef711r3d05560e5d572f40@mail.gmail.com> From: Hui Deng To: Wassim Haddad Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:05:46 -0000 some people suggest here NAT64 could understand RR message, and give some response based on it. then I assume they are putting mobilty agent inside NAT64. thanks -Hui 2009/8/31 Wassim Haddad : > Hi Hui, > >>firstly, I personally think that NAT64 should support IP mobility. > >>Secondly, I don't agree to put NAT64 as the mobility agent to reply RR message. > > => I think am lost here! Can you please explain what you mean by "NAT64 replies > to RR messages"? > > > Regards, > > Wassim H. > From maxpassion@gmail.com Mon Aug 31 09:57:25 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9CD28C398 for ; Mon, 31 Aug 2009 09:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJirxYEjPzhJ for ; Mon, 31 Aug 2009 09:57:25 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 87D7F28C3B6 for ; Mon, 31 Aug 2009 09:56:32 -0700 (PDT) Received: by vws7 with SMTP id 7so2865187vws.29 for ; Mon, 31 Aug 2009 09:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sBqNrtlEzAsJ2dKYWlIsDqV5FD8lywv6sw9jef1mqeQ=; b=HSV6qYaI7OLOznUFuKcc48iR6NhGZrRN2CXLYRwbh8ex82txMtj36VQ8at3+5b/eo4 Ub1bRaBpfUm0f4baMHgGPWIX1fJjX95TG4tOqM9lXAL/Ce6rf/XrTyyoZhzBBJVqMPgW GdjuQjkz6CzKOkOG4DsKsmrlozeLBmpwptUdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XwodQ3BbqXAIozwoWg7tdyQsduUGHyn3s7nZqsDFPs1+gWcxDviPGDmMF9sO5XH7QI LltbkJUNV72eBHcUDTwUv2bFkTbJ9EgMYNBBXmTFYo/x8jF328/cnmY049eIsTCs9ws7 xhwesg56xoCHxd9FH1hFYEHDJp9gLViydjG8Y= MIME-Version: 1.0 Received: by 10.220.105.148 with SMTP id t20mr6698978vco.96.1251737800695; Mon, 31 Aug 2009 09:56:40 -0700 (PDT) In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 1 Sep 2009 00:56:39 +0800 Message-ID: <25e1aaa40908310956m6f638a4x32dca4039b63b21d@mail.gmail.com> From: liu dapeng To: Wassim Haddad Content-Type: text/plain; charset=ISO-8859-1 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:57:25 -0000 Hi Wassim, I am wondering where does the HA locate? it locate in the IPv6 network or in the IPv4 network? if it locates in the IPv4 network, maybe the mobility protocol should be DSMIP instead of MIPv6, since MIPv6 requries that HA is IPv6 capable. BR, Dapeng Liu 2009/8/27, Wassim Haddad : > Dear all, > > Please find attached a note on NAT64 and MIPv6. > > > Regards, > > Wassim H. From maxpassion@gmail.com Mon Aug 31 10:00:20 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C3C03A6A0E for ; Mon, 31 Aug 2009 10:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4AcmYwJLDOO for ; Mon, 31 Aug 2009 10:00:19 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id AF1DB3A6784 for ; Mon, 31 Aug 2009 10:00:19 -0700 (PDT) Received: by vws7 with SMTP id 7so2867734vws.29 for ; Mon, 31 Aug 2009 10:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p2XUJYfwUYbJaBmcY93pn3MC19aeEYPTty4KT/igNXs=; b=R1pGQGLApbAo939NIkzT/POjKFacTVg/8ImE+UL+3cL5Obox9wnntYi1qPeZ8pO2+a zHo7Wp62V7egSfas8RfZFZjJXxrNH28LIv4kNeCTHl94orfrLl1D6e2/zXFzzH0aZM3Z Lkq/TOsSgJRCka81WBY1d7Oeqbwiw+qNzSXL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tw+d5OM5XNcE8XgjNCDnbmjTJJpYdwHSTepjpqkJcEJNxAECD4UBOh1kzrakKu/wt8 t8bhhg4ljyikimPuP1IJkB2OOp4tIASBJp9kMbAvFGf9zCyZ2+/SIG+YH0TdRY0863DT HmKMFgBG0pjK97X5IC35JnsHioAftXgKYZJHk= MIME-Version: 1.0 Received: by 10.220.112.204 with SMTP id x12mr6589480vcp.19.1251738028045; Mon, 31 Aug 2009 10:00:28 -0700 (PDT) In-Reply-To: <00151748e88c138b5504725d7403@google.com> References: <00151748e88c138b5504725d7403@google.com> Date: Tue, 1 Sep 2009 01:00:27 +0800 Message-ID: <25e1aaa40908311000l6221a4e8xe90256fcc410d71c@mail.gmail.com> From: liu dapeng To: cb.list6@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Hui Deng , =?GB2312?B?1tyyqQ==?= , Wassim Haddad , behave@ietf.org, Zhen Cao Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 17:00:20 -0000 2009/8/30, cb.list6@gmail.com : >> This is somewhat confusing. When we are saying that a host is > >> IPv6-only, I guess we are expressing one of its static property. But > >> here you mean that its property is changing according to different > >> environments. I think what you are saying here more appropriately > >> refers to a specific scenario. But we cannot confuse a scenario with a > >> definition. From the definition, few hosts are IPv6 only implemented. > > > Zhen, i agree that this can be confusing, but my understanding is the same > as Marcelo. Here is an example scenario: I want it to act as an IPv6 only > node on the my 3G UMTS carrier's network because my wireless carrier is > only giving me IPv6 with NAT64 / DNS64 to bridge Internet v4 content. When > i am at home on WiFi and my home gateway (cable company ds-lite on the wifi > router) gives me IPv4 and IPv6 on my home WLAN, i want my laptop to act as > a dual stack. When i am at work, my corporate LAN only supports IPv4, so my > laptop must act as an IPv4 node only. All of these scenarios will > automatically work today given current major operating systems, assuming we > have a NAT64/DNS64 deployment. > > If your laptop is dual stack capable / enabled today, it will work in these > 3 modes (v6 only, v4 only, dual stack) without any user intervention. If you called the laptop dual stack, why then saying that it is v6 only or v4 only, is't it confusing? > Regards, > > Cameron Byrne > Principal Engineer > T-Mobile USA > From maxpassion@gmail.com Mon Aug 31 10:22:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA873A6E7E for ; Mon, 31 Aug 2009 10:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juV7TE-2-htb for ; Mon, 31 Aug 2009 10:22:37 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 294143A6CC4 for ; Mon, 31 Aug 2009 10:22:37 -0700 (PDT) Received: by vws7 with SMTP id 7so2885475vws.29 for ; Mon, 31 Aug 2009 10:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NbuWnFQ2F4rrGVAE8LpHvzk+BOUly3z5A55Oja4Egw0=; b=oV2SPrqsgZkbIF7UXg7SOh8QneI+hdZ2QXOoYloPRNino1OF2A3diZj0VQg0DYx0x7 SDg27rAeumrznYiqJvjDyg7YHUoldVe1rxEEchkLqCJm9WYvLGjDxYz8Sl/wV891UNiK UjPSb9axRw6Sp91oB6yxdA/A+SRPpVvgImTnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CH30yv7D2R6svhDN5pqejOdzKpQOJuZenNi/UwIzfrJ7WGsD7McSwBVE2BTZu7Ye/d MXFjJd4mi9eu8W6ee/12/J1kJmQfoYa7IJVFql7xXaWC17fp7L/PANWOqNy23/wpmJ5n LacTdFyvFMOTTb9gDDTe75yZ7P+ANPGdAQ934= MIME-Version: 1.0 Received: by 10.220.88.209 with SMTP id b17mr6825744vcm.98.1251739368182; Mon, 31 Aug 2009 10:22:48 -0700 (PDT) In-Reply-To: <4A9A2850.6060008@it.uc3m.es> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <4A979C2F.2040407@it.uc3m.es> <1d38a3350908290242v5509c77bx9efaab153f18b67b@mail.gmail.com> <4A9A2850.6060008@it.uc3m.es> Date: Tue, 1 Sep 2009 01:22:48 +0800 Message-ID: <25e1aaa40908311022g253063f0kc71c8ee593364720@mail.gmail.com> From: liu dapeng To: marcelo bagnulo braun Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hui Deng , Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 17:22:38 -0000 2009/8/30, marcelo bagnulo braun : > Hui Deng escribi=F3: >> but the host know he is talking with IPv4 node, he will not initate RO >> then RO will not fail consequently. >> > ok, so you are not considering the MN being an IPv6 only node, but a > dual stack node, correct? > > in this case, you should be looking at dsmip Hi maclelo, According to your definition of IPv6 only host, my understanding is that the host talked here is still "IPv6 only", since it does not have IPv4 connectivity. dsmip solves the problems that the MN has IPv4 only access network, it seems the scenario we discuss here is that the MN has IPv6 only access network,right? So in essence, it is the DNS64 that prevent the MN to know that actually the CN is not an IPv6 host, which lead to the MIPv6 can not work properly. BR, Dapeng Liu > regards, marcelo > >> but I guess for dual stack, RO may need a new solution. >> >> > > >> -Hui >> >> 2009/8/28 marcelo bagnulo braun : >> >>> Hui Deng escribi=F3: >>> >>>> Hi, Wassim, >>>> >>>> The problem in your draft has been elaborated inside us before. >>>> this is one driving force for us to design PNAT >>>> http://tools.ietf.org/html/draft-huang-pnat-host-ipv6-01 >>>> we guess that identify the peer side IP family type is important for >>>> the communication. >>>> >>>> >>> I fail to see how this is the case for the particular problem Wassim is >>> describing in his draft. >>> If you have a node that is IPv4 and another is IPv6 and running MIPv6, >>> then >>> RO mode will fail >>> >>>> Current NAT64 assume host is IPv6 only, and network is IPv6 only >>>> connection. >>>> but PNAT64 assume host is dual stack, and network is IPv6only >>>> connection. >>>> >>>> >>>> >>> so, how this will help MIPv6 RO mode to work? >>> >>> Regards, marcelo >>> >>> >>> >>> >>>> and NAT64 need DNS64, and PNAT64 don't need DNS64. >>>> furthermore PNAT host understand peer side whether it is IPv4 or IPv6 >>>> which could remove your concern in this draft. >>>> >>>> PNAT assume host will rely on PNAT64 for its IPv4 application, >>>> will rely on NAT64 for its IPv6 application. >>>> >>>> thanks for the discussion. >>>> >>>> -Hui >>>> >>>> 2009/8/27 Wassim Haddad : >>>> >>>> >>>>> Dear all, >>>>> >>>>> Please find attached a note on NAT64 and MIPv6. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Wassim H. >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> Behave@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/behave >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>>> >>> >>> >> >> > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dthaler@microsoft.com Mon Aug 31 10:23:22 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E334828C3CE for ; Mon, 31 Aug 2009 10:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.429 X-Spam-Level: X-Spam-Status: No, score=-10.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ3j9X7x1nvn for ; Mon, 31 Aug 2009 10:23:22 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 2D49E28C3CA for ; Mon, 31 Aug 2009 10:23:22 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Aug 2009 10:23:33 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.13; Mon, 31 Aug 2009 10:23:33 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 31 Aug 2009 10:23:06 -0700 From: Dave Thaler To: Xing Li Thread-Topic: [BEHAVE] DNS64 handling of multicast addresses Thread-Index: AQHKIltjsms8L0OPykSpkOnnN2XGN5CxEMmAgA8/14CAACm5EA== Date: Mon, 31 Aug 2009 17:22:52 +0000 Message-ID: References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <4A9B8141.2000705@cernet.edu.cn> In-Reply-To: <4A9B8141.2000705@cernet.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Andrew Sullivan , Stig Venaas , "behave@ietf.org" , Mark Andrews Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 17:23:23 -0000 WGluZyBMaSB3cml0ZXM6DQo+IEkgbWVhbiB3ZSBzaG91bGQgZGlzY3VzcyB0aGUgbXVsdGljYXN0 IGluDQo+ICgxKSBhZGRyZXNzLWZvcm1hdCBkb2N1bWVudCwgc2luY2UgbXVsdGljYXN0IGFkZHJl c3NlcyBzaG91bGQgYmUgbWFwcGVkDQo+IGRpZmZlcmVudGx5IGNvbXBhcmVkIHdpdGggdGhlIHVu aWNhc3QgYWRkcmVzc2VzLg0KPiAoMikgeGxhdGUgZG9jdW1lbnQsIHNpbmNlIHRoZSBtdWx0aWNh c3QgcGFja2V0cyBzaG91bGQgYmUgdHJhbnNsYXRlZA0KPiBkaWZmZXJlbnRseSBjb21wYXJlZCB3 aXRoIHRoZSB1bmljYXN0IHBhY2tldHMuDQoNCkkgY3VycmVudGx5IGRvbid0IGJlbGlldmUgZWl0 aGVyIG9mIHRoZSBzdGF0ZW1lbnRzIHN0YXJ0aW5nIHdpdGggInNpbmNlLi4uIg0KDQpDYW4geW91 IGVsYWJvcmF0ZSBvbiB3aHkgeW91IGJlbGlldmUgdGhlbT8NCg0KLURhdmUNCg== From marcelo@it.uc3m.es Mon Aug 31 13:30:04 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1653A6EDD for ; Mon, 31 Aug 2009 13:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-rDsExvg5pL for ; Mon, 31 Aug 2009 13:30:03 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 007623A6EC5 for ; Mon, 31 Aug 2009 13:30:02 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (203.pool85-53-144.dynamic.orange.es [85.53.144.203]) by smtp02.uc3m.es (Postfix) with ESMTP id 000456C042D; Mon, 31 Aug 2009 22:30:11 +0200 (CEST) Message-ID: <4A9C32D3.80106@it.uc3m.es> Date: Mon, 31 Aug 2009 22:30:11 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Wassim Haddad References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se>, <4A9799AC.8050109@it.uc3m.es> <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16860.000 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 20:30:04 -0000 Wassim Haddad escribi: > Hi Marcelo, > > Thanks for the notes. Please see mine inline. > > >> I understand that the first point being made in the draft is that RO >> mode doesn't work through NAT64. I certainly agree with that and this >> was identified RFC 4966. >> > > => OK > > >> During the requirement discussion, the input from the mobility community >> was that the support for the RO mode in nat64 was not critical and that >> it was acceptable to fall back to BT mode in case there is a NAT64 along >> the path. I am not sure if you agree with that. >> > > => I don't think we have much choices here. The CN is an IPv4 node only so > it does not understand RO mode... > > >> In case you don't, it would be possible to overcome this by having the NAT64 >> to terminate the RO procedure (i.e. that the NAT64 replies the RR signalling >> so that the path is optimized to the nat64, sicne it cannot be optimized to the >> > CN). > > => I see no problem with that. It should work fine if a MN starts a session with a > CN while at home then moves to a foreign network (equipped with NAT64), tries > RR and fails then stays with the BT mode. > > >> I think it would be possible to define the nat64 extensions needed for that. >> > > => Agree. > > >> Then in your draft, you state that: >> >> In this case, the >> MN tunnels first its data packets to its HA without having them being >> intercepted by the foreign NAT64. However, after reaching the HA, >> the data packets will most likely be dropped at some point. This is >> due to the presence of the foreign NAT64 IPv6 prefix in the CN's IPv6 >> address. >> > > I am not sure i understand that part. Are you saying that in case the MN > decides to move to RO mode things won't work anymore or are you saying > that data packets will be lost in BT mode? > > => First, am sorry for a possible confusion! But you cut the first part of the > text! :) > What I meant is that when the MN moves to a foreign network and decides to > initiate a new session with a v4 CN then: > > a) we can forget about RO mode here BUT this is not the problem. > b) the MN will try to reach the CN via BT mode but even in this case, it will > ultimately fail because the packet won't reach the home NAT64 in order to get > translated (as it is using a different prefix). > ah! i think i understand what you mean. If the MN uses the dns64 from the visited network and the NAT64 from the home networks, things may break (if the WK prefix is not used) please note that this is not a problem only in mip. for instance, if you are connected to the IETF network but you still use the DNS server at you work, then if there is a nat64 in the ietf meeting wifi, it would fail in the same way (this is actually the reverse situation, you are using the local nat64 and the remot dns64) The point is that you need to use the dns64 (i.e. the dns server) of the network that is running the nat64. Now, there are several ways to address this problem if you use the LIR prefix either you configure the MN to use the dns server from the home network, either you use the dns64 in stub resolver mode (i.e. in the MN) > >> If you are saying that the RO mode doesn't work, i agree with you as i >> mentioned above. If you are saying that data packets are lost in BT mode >> (when RO mode is not used at all), that i don't understnad the scenario, >> and i would appreciate a figure to understand it better. >> > > => Hope the above helps? > It does, if what i understood is correct As you say in the draft, NAT64 is a NAT, so we shouldn't be surprised if somethings break. This seems to be one of these cases. Maybe it would be important to explain this limitation in some of the the documents, not sure where though... suggestions? Regards, marcelo > > Regards, > > Wassim H. > > > From wassim.haddad@ericsson.com Mon Aug 31 13:40:40 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4155528C4E2 for ; Mon, 31 Aug 2009 13:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-EErxqyxySe for ; Mon, 31 Aug 2009 13:40:39 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 6748A28C527 for ; Mon, 31 Aug 2009 13:40:39 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n7VKemJs026194; Mon, 31 Aug 2009 15:40:49 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 15:40:48 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 15:40:47 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 31 Aug 2009 16:40:42 -0400 From: Wassim Haddad To: "maxpassion@gmail.com" Date: Mon, 31 Aug 2009 16:40:39 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AcoqXDYrTwzVSFqNRfGT1+ni8oiTGgAHtHCg Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C458E91@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <25e1aaa40908310956m6f638a4x32dca4039b63b21d@mail.gmail.com> In-Reply-To: <25e1aaa40908310956m6f638a4x32dca4039b63b21d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Aug 2009 20:40:47.0822 (UTC) FILETIME=[51FADEE0:01CA2A7B] Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 20:40:40 -0000 Hi, I am wondering where does the HA locate? it locate in the IPv6 network or in the IPv4 network? =3D> the home network is an IPv6 network which has its own NAT64 and DNS64. Did I answer your question? Regards, Wassim H. From wassim.haddad@ericsson.com Mon Aug 31 13:59:38 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37DEA3A6B3A for ; Mon, 31 Aug 2009 13:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECMzpoSpt+jc for ; Mon, 31 Aug 2009 13:59:37 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 5006E3A6997 for ; Mon, 31 Aug 2009 13:57:38 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n7VKvlfE009429; Mon, 31 Aug 2009 15:57:49 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 15:56:51 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 15:56:51 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 31 Aug 2009 16:56:50 -0400 From: Wassim Haddad To: "marcelo@it.uc3m.es" Date: Mon, 31 Aug 2009 16:56:49 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AcoqefWo3Oj0Ly9eS/SPG57bREBMkwAAVtaQ Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C458EB4@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se>, <4A9799AC.8050109@it.uc3m.es> <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> <4A9C32D3.80106@it.uc3m.es> In-Reply-To: <4A9C32D3.80106@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Aug 2009 20:56:51.0001 (UTC) FILETIME=[90145290:01CA2A7D] Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 20:59:38 -0000 Hi Marcelo, > =3D> First, am sorry for a possible confusion! But you cut the first > part of the text! :) What I meant is that when the MN moves to a > foreign network and decides to initiate a new session with a v4 CN > then: > > a) we can forget about RO mode here BUT this is not the problem. > b) the MN will try to reach the CN via BT mode but even in this case, > it will ultimately fail because the packet won't reach the home NAT64 > in order to get translated (as it is using a different prefix). > ah! i think i understand what you mean. If the MN uses the dns64 from the visited network and the NAT64 from the ho= me networks, things may break (if the WK prefix is not used) =3D> That's correct! please note that this is not a problem only in mip. for instance, if you are connected to the IETF network but you still use th= e DNS server at you work, then if there is a nat64 in the ietf meeting wifi= , it would fail in the same way (this is actually the reverse situation, yo= u are using the local nat64 and the remot dns64) =3D> Sure. Am also suspicious about two other scenarios where things would = break. Please correct me if am wrong: - case of referral when the IPv6 address is a DNS64 reply and then the peer= tries to connect using another interface, i.e., a different NAT64. - case of callback when the IPv6 address is also a DNS64 reply and the peer= decides to connect via another interface, i.e., a different NAT64. The point is that you need to use the dns64 (i.e. the dns server) of the ne= twork that is running the nat64. =3D> Agree. Now, there are several ways to address this problem if you use the LIR pref= ix either you configure the MN to use the dns server from the home network, =3D> Am not sure this approach is optimal. either you use the dns64 in stub resolver mode (i.e. in the MN) =3D> IMHO, this is one way to tackle it. > >> If you are saying that the RO mode doesn't work, i agree with you as >> i mentioned above. If you are saying that data packets are lost in BT >> mode (when RO mode is not used at all), that i don't understnad the >> scenario, and i would appreciate a figure to understand it better. >> > > =3D> Hope the above helps? > It does, if what i understood is correct =3D> Yes you did! :) As you say in the draft, NAT64 is a NAT, so we shouldn't be surprised if so= methings break. This seems to be one of these cases. =3D> My point was/is that it *may* make sense to avoid re-defining "insanit= y" in behave WG! :) Maybe it would be important to explain this limitation in some of the the d= ocuments, not sure where though... suggestions? =3D> As you mentioned above, there are definitely other things that we'll b= reak but we have thought enough about them. So IMHO, this one should be "at= least" documented somewhere. Regards, Wassim H. From dthaler@microsoft.com Mon Aug 31 15:34:50 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0613C28C2F8 for ; Mon, 31 Aug 2009 15:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQtY-jchVI1T for ; Mon, 31 Aug 2009 15:34:49 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 5F49A28C2CF for ; Mon, 31 Aug 2009 15:34:49 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Aug 2009 15:35:01 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.13; Mon, 31 Aug 2009 15:35:01 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 31 Aug 2009 15:34:55 -0700 From: Dave Thaler To: marcelo bagnulo braun , Wassim Haddad Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AQHKKHuIwEJcSog/t0mWiJZwt4jxx5C//1+AgAEYr4D//60LwA== Date: Mon, 31 Aug 2009 22:34:38 +0000 Message-ID: References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se>, <4A9799AC.8050109@it.uc3m.es> <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> <4A9C32D3.80106@it.uc3m.es> In-Reply-To: <4A9C32D3.80106@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:34:50 -0000 Marcelo wrote: [...] > If the MN uses the dns64 from the visited network and the NAT64 from > the home networks, things may break (if the WK prefix is not used) > > please note that this is not a problem only in mip. for instance, if > you > are connected to the IETF network but you still use the DNS server at > you work, then if there is a nat64 in the ietf meeting wifi, it would > fail in the same way (this is actually the reverse situation, you are > using the local nat64 and the remot dns64) > > The point is that you need to use the dns64 (i.e. the dns server) of > the network that is running the nat64. [...] +1 (I said the same thing to someone at IETF, but I forget who) -Dave From dthaler@microsoft.com Mon Aug 31 15:37:03 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CA028C39F for ; Mon, 31 Aug 2009 15:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.434 X-Spam-Level: X-Spam-Status: No, score=-10.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJC0yTET0fN5 for ; Mon, 31 Aug 2009 15:37:02 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A48FC28C2A9 for ; Mon, 31 Aug 2009 15:37:02 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Aug 2009 15:37:14 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server id 14.0.639.13; Mon, 31 Aug 2009 15:37:14 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Mon, 31 Aug 2009 15:36:35 -0700 From: Dave Thaler To: marcelo bagnulo braun , Hui Deng Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AQHKJ4os+BuMJkKlWkGSbD/OhaSx45C7z7uAgAA/yACAAALFAIAAxuOAgABNNgCAA6EfcA== Date: Mon, 31 Aug 2009 22:36:20 +0000 Message-ID: References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <200908280743.18009.simon.perreault@viagenie.ca> <2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se> <200908281141.28240.simon.perreault@viagenie.ca> <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com> <4A98E244.1060605@it.uc3m.es> In-Reply-To: <4A98E244.1060605@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:37:03 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of marcelo bagnulo braun > Sent: Saturday, August 29, 2009 1:10 AM > To: Hui Deng > Cc: Wassim Haddad; behave@ietf.org > Subject: Re: [BEHAVE] NAT64 and MIPv6 > > Hui Deng escribi=F3: > > I am doubting that NAT64 doesn't change the host, > > how it learn translator prefix? > > > > the host behind a nat64 doesn't need to learn the prefix for the basic > support i.e. to support basic applications (such as any application > that > works through nat today) and to support a validating stub resolver. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think there's a typo above. I think you meant to say it doesn't need to learn the prefix to support a non-validating security-aware stub resolver (which is what Windows 7 supports, BTW). -Dave > > Regards, marcelo > > > -Hui > > > > 2009/8/28 Simon Perreault : > > > >> On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: > >> > >>> NAT64 doesn't assume anything about the host, while > >>> PNAT64 assumes that the host implements PNAT64. > >>> > >>> =3D> Your comment does not help solve/avoid the problem! > >>> > >> My apologies. Here's something more constructive: > >> > >> It is pointless to try to solve the problem you pointed out by > changing the > >> networking stack in hosts. If this is done, then the major driver > for NAT64 > >> goes away, and there is a plethora of solutions that become > possible. > >> > >> Therefore, it is better to ask this question: is it possible to fix > the NAT64 > >> box (and/or DNS64) so that the problem you pointed out is solved? > >> > >> Simon > >> -- > >> DNS64 open-source --> http://ecdysis.viagenie.ca > >> STUN/TURN server --> http://numb.viagenie.ca > >> vCard 4.0 --> http://www.vcarddav.org > >> > >> > >> > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Mon Aug 31 15:54:36 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AAAF28C39F for ; Mon, 31 Aug 2009 15:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw-CQu4oaCJz for ; Mon, 31 Aug 2009 15:54:35 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D1F903A68F2 for ; Mon, 31 Aug 2009 15:54:35 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Aug 2009 15:54:47 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.13; Mon, 31 Aug 2009 15:54:47 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 31 Aug 2009 15:54:58 -0700 From: Dave Thaler To: marcelo bagnulo braun , Hui Deng Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AQHKJ4os+BuMJkKlWkGSbD/OhaSx45C7z7uAgAEIcACAAE8GAIADoLPg Date: Mon, 31 Aug 2009 22:54:42 +0000 Message-ID: References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <1d38a3350908271948l7e55b0cai38e40cfb4edc30d7@mail.gmail.com> <200908280743.18009.simon.perreault@viagenie.ca> <1d38a3350908282029m78ccdf5bg3e23a848029e282b@mail.gmail.com> <4A98E2F2.4020401@it.uc3m.es> In-Reply-To: <4A98E2F2.4020401@it.uc3m.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:54:36 -0000 [quote below with typos mentioned in subsequent email corrected] > IPv6 only means that the the host doesn't have IPv4 connectivity, > either > cause it doesn't have the ipv4 stack or because it does have the stack > but it doesn't have an ipv4 that it can use for the communication (in > general it doesn't have a global ipv4 address) [...] "IPv6-only" is an adjective and can be used to describe a network, a host, or an application. The text in the framework doc says: IPv6-only: An IPv6-only implementation, in this context, comprises an IPv6 enabled end system stack plus routing in the network. It implies that two application instances are capable of communicating using IPv6, but not IPv4 - they have an IPv6 stack, addresses, and network support including routing in IPv6, but some element is missing that prevents communication with IPv4 hosts. One problem with the above is that it confuses whether it's an adjective, or a term "IPv6-only implementation" or an "IPv6-only end system" or an "IPv6-only application". One confusing property of the definitions is that it doesn't match what a new person would expect. In other words, if I have an IP-version agnostic application, running on a dual-stack host, which only gets an IPv6 address, then I would probably be surprised to hear I have an "IPv6-only application", since this term is usually taken to talk about capability, not how it's deployed. Someone (Alain perhaps?) had terms "IPvX-capable" and "IPvX-enabled" (or perhaps better "IPvX-connected") to distinguish between these concepts, and I think part of the confusion is due to the loss of this distinction. I think people would expect that an IP-version agnostic application would be "IPv4-capable" but not necessarily "IPv4-connected". Another confusing property is that the "connected" part may vary by destination. For example, if I have IPv4 connectivity to those within the same net-10 as me, but no one else, am I IPv6-only or not? It depends on who you're trying to talk to, and that concept is lost in the definitions as well. -Dave From wmhaddad@gmail.com Mon Aug 31 17:37:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5155F3A69E1 for ; Mon, 31 Aug 2009 17:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZKIs09dh+E4 for ; Mon, 31 Aug 2009 17:37:07 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 611EC3A6B84 for ; Mon, 31 Aug 2009 17:37:07 -0700 (PDT) Received: by ywh4 with SMTP id 4so8567322ywh.17 for ; Mon, 31 Aug 2009 17:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YeyD8WHnrxX2HaMHCvN7RzSC90C47TDtCRyd+U2TQeQ=; b=CDvJo5Be2g/kWM/CT+UpvcI4DlE1SNcijkmnxtguzddNoBxPShYWT5e4I5DIvBsG7N CQp603ieu2OmiJH6DJtn6iqpvP1G13QF1I1/HAtrYUvgWCVMB4awNF3hGVJbS93TlOdp 8qrpKFJn6XBtDXx05hnIvx/WWkEDcvSQPcoGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=miCQ4GX91eU303bz1BHOfj754dOc7KEiwq/o0lkp5iqI/xwMmdBMW+0K3F9rO1Kzk5 XqmPMOYSDkdeAGfn31WKxhqbiliVndcpqkJIdQ06FzeHWkRjJpmf5l8TeXXGHzLrpBPP bbH/JyaTLvma18UnEFF6cZLN/azphJ4K920eY= MIME-Version: 1.0 Received: by 10.150.172.39 with SMTP id u39mr10326264ybe.43.1251765436725; Mon, 31 Aug 2009 17:37:16 -0700 (PDT) In-Reply-To: References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> <4A9C32D3.80106@it.uc3m.es> Date: Mon, 31 Aug 2009 18:37:16 -0600 Message-ID: <9a367ee30908311737v55797620gac89c8913438cc6f@mail.gmail.com> From: Wassim Haddad To: Dave Thaler Content-Type: multipart/alternative; boundary=000e0cd5c7ae32bb970472795a2f Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 00:37:08 -0000 --000e0cd5c7ae32bb970472795a2f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 31, 2009 at 4:34 PM, Dave Thaler wrote: > Marcelo wrote: > [...] > > If the MN uses the dns64 from the visited network and the NAT64 from > > the home networks, things may break (if the WK prefix is not used) > > > > please note that this is not a problem only in mip. for instance, if > > you > > are connected to the IETF network but you still use the DNS server at > > you work, then if there is a nat64 in the ietf meeting wifi, it would > > fail in the same way (this is actually the reverse situation, you are > > using the local nat64 and the remot dns64) > > > > The point is that you need to use the dns64 (i.e. the dns server) of > > the network that is running the nat64. > [...] > > +1 > => You mean if my home network is in Sydney and am in the US then I have to use the cache server in Sydney instead of the local one so that I don't break NAT64 design?! BTW, do you think you'll get the same DNS reply for any service than if you query the local cache? Wassim H. _________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --000e0cd5c7ae32bb970472795a2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 31, 2009 at 4:34 PM, Dave Th= aler <dthaler= @microsoft.com> wrote:
Marcelo wrote:
[...]
> If the MN uses the dns64 from the visited network an= d the NAT64 from
> the home networks, things may break (if the WK prefix is not used)
>
> please note that this is not a problem only in mip. for instance, if > you
> are connected to the IETF network but you still use the DNS server at<= br> > you work, then if there is a nat64 in the ietf meeting wifi, it would<= br> > fail in the same way (this is actually the reverse situation, you are<= br> > using the local nat64 and the remot dns64)
>
> The point is that you need to use the dns64 (i.e. the dns server) of > the network that is running the nat64.
[...]

+1

=3D> You mean if my home network is in Sydne= y and am in the US then I have
to use the cache server in Sydney instea= d of the local one so that I don't break
NAT64 design?!
=A0 BTW, do you think you'll get the same DNS reply for any service than if= you
query the local cache?


Wassim H.

_________________

--000e0cd5c7ae32bb970472795a2f-- From hesham@elevatemobile.com Mon Aug 31 18:28:54 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF12728C617 for ; Mon, 31 Aug 2009 18:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXw8Sj9NZkGX for ; Mon, 31 Aug 2009 18:28:54 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 24C293A69E1 for ; Mon, 31 Aug 2009 18:28:53 -0700 (PDT) Received: from [122.110.175.159] (helo=[192.168.0.4]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MiIB5-0006Gt-QT; Tue, 01 Sep 2009 11:28:57 +1000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 01 Sep 2009 11:28:31 +1000 From: Hesham Soliman To: Dave Thaler , marcelo bagnulo braun , Hui Deng Message-ID: Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AQHKJ4os+BuMJkKlWkGSbD/OhaSx45C7z7uAgAEIcACAAE8GAIADoLPggAAwDgg= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 01:28:55 -0000 > > Someone (Alain perhaps?) had terms "IPvX-capable" and "IPvX-enabled" > (or perhaps better "IPvX-connected") to distinguish between these > concepts, and I think part of the confusion is due to the loss of > this distinction. I think people would expect that an IP-version > agnostic application would be "IPv4-capable" but not necessarily > "IPv4-connected". => It was all defined a million years ago in SIIT :) we should reuse these definitions but we don't. Hesham > > Another confusing property is that the "connected" part may vary > by destination. For example, if I have IPv4 connectivity to > those within the same net-10 as me, but no one else, am I > IPv6-only or not? It depends on who you're trying to talk to, > and that concept is lost in the definitions as well. > > -Dave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dthaler@microsoft.com Mon Aug 31 18:49:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFD528C634 for ; Mon, 31 Aug 2009 18:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.44 X-Spam-Level: X-Spam-Status: No, score=-10.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T13VEelSJPN2 for ; Mon, 31 Aug 2009 18:49:47 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 02B3828C625 for ; Mon, 31 Aug 2009 18:49:46 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 31 Aug 2009 18:49:58 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.639.13; Mon, 31 Aug 2009 18:49:58 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 31 Aug 2009 18:50:09 -0700 From: Dave Thaler To: Wassim Haddad Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AQHKKHuIwEJcSog/t0mWiJZwt4jxx5C//1+AgAEYr4D//60LwIAAl/4A//+c3CA= Date: Tue, 1 Sep 2009 01:49:51 +0000 Message-ID: References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> <4A9C32D3.80106@it.uc3m.es> <9a367ee30908311737v55797620gac89c8913438cc6f@mail.gmail.com> In-Reply-To: <9a367ee30908311737v55797620gac89c8913438cc6f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 01:49:47 -0000 Wassim Haddad wrote: > Dave Thaler wrote: >> Marcelo wrote: >> [...] >>> If the MN uses the dns64 from the visited network and the NAT64 from >>> the home networks, things may break (if the WK prefix is not used) >>> >>> please note that this is not a problem only in mip. for instance, if >>> you >>> are connected to the IETF network but you still use the DNS server at >>> you work, then if there is a nat64 in the ietf meeting wifi, it would >>> fail in the same way (this is actually the reverse situation, you are >>> using the local nat64 and the remot dns64) >>> >>> The point is that you need to use the dns64 (i.e. the dns server) of >>> the network that is running the nat64. >> [...] >> >> +1 > > You mean if my home network is in Sydney and am in the US then I have > to use the cache server in Sydney instead of the local one so that I don'= t break > NAT64 design?! No. I mean you have two choices: a) use the DNS in Sydney if you want to use your home address with the result, b) use the DNS in the US if you _don't_ want to use your home address with the result (i.e. don't use MIP) You can't mix them and expect anything to work. DNS64/NAT64 doesn't change this fact in any way. > BTW, do you think you'll get the same DNS reply for any service than if y= ou > query the local cache? I'm not sure which question you're asking, but the point is that you can't use a DNS server on one network and then communicate on a different network and expect it to work, unless you can guarantee that both are using the public DNS namespace, since enterprises and even homes often use private name spaces. -Dave From xing@cernet.edu.cn Mon Aug 31 18:56:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CF928C641 for ; Mon, 31 Aug 2009 18:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.586 X-Spam-Level: * X-Spam-Status: No, score=1.586 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rCdvAjtIDFT for ; Mon, 31 Aug 2009 18:56:05 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 13F0D28C622 for ; Mon, 31 Aug 2009 18:56:04 -0700 (PDT) Received: from [219.224.98.91]([219.224.98.91]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm74a9ca501; Tue, 01 Sep 2009 09:56:10 +0800 Message-ID: <4A9C7F37.3080108@cernet.edu.cn> Date: Tue, 01 Sep 2009 09:56:07 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dave Thaler References: <4A7A7FCF.3070606@teliasonera.com> <25e1aaa40908140708m7c19e2c9i70874ec198b16d79@mail.gmail.com> <4A85A7CB.7070600@venaas.com> <20090814182828.GC377@shinkuro.com> <4A85B195.4090000@venaas.com> <20090814185727.GD377@shinkuro.com> <4A870969.20609@it.uc3m.es> <200908162328.n7GNS6So072710@drugs.dv.isc.org> <20090818165041.GI3163@shinkuro.com> <200908190310.n7J3AXUf008504@drugs.dv.isc.org> <4A8B7E35.9070500@venaas.com> <200908190434.n7J4Y4vM009316@drugs.dv.isc.org> <4A8B80FB.9030701@venaas.com> <4A8E93A2.70609@cernet.edu.cn> <4A9B8141.2000705@cernet.edu.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: zn2bSiWB Cc: Andrew Sullivan , Stig Venaas , "behave@ietf.org" , Mark Andrews Subject: Re: [BEHAVE] DNS64 handling of multicast addresses X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 01:56:06 -0000 Dave Thaler 写道: > Xing Li writes: > >> I mean we should discuss the multicast in >> (1) address-format document, since multicast addresses should be mapped >> differently compared with the unicast addresses. >> (2) xlate document, since the multicast packets should be translated >> differently compared with the unicast packets. >> > > I currently don't believe either of the statements starting with "since..." > > Can you elaborate on why you believe them? > An example of stateless translator: ------ ----- / The \ ----- / An \ A --- | IPv4 |-----|Xlate|------| IPv6 | --- B \Internet/ ----- \Network/ ------ ----- IPv4 host A: 166.111.8.10 IPv6 host B: pref:202.112.5.6 Packets sent from IPv4 host A to IPv6 host B Unicate: Before the xlate Src=166.111.8.10 Dst=202.112.5.6 After the xlate Src=pref:166.111.8.10 Dst=pref:202.112.5.6 Multicast: Before the xlate Src=166.111.8.10 Dst=233.1.2.3 After the xlate Src=pref:166.111.8.10 Dst=ff3e::1.2.3 So, for the xlate (when muticast translation is enabled) If the Dst address (x.x.x.x) is in the unicast address range Convert to pref:x.x.x.x If the Dst address (x.x.x.x) is in the multicast address range Convert to 3ffe::x.x.x regards, xing > -Dave > From dwing@cisco.com Mon Aug 31 18:58:47 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D120A3A68A9 for ; Mon, 31 Aug 2009 18:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmdaAqZtvCwB for ; Mon, 31 Aug 2009 18:58:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 57B203A68E5 for ; Mon, 31 Aug 2009 18:58:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgEAP8cnEqrR7O6/2dsb2JhbACLGLZKiEEBj0YFhBqBWg X-IronPort-AV: E=Sophos;i="4.44,309,1249257600"; d="scan'208";a="200509604" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 01 Sep 2009 01:58:58 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n811wwN9032639; Mon, 31 Aug 2009 18:58:58 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n811wt8F028029; Tue, 1 Sep 2009 01:58:55 GMT From: "Dan Wing" To: "'Wassim Haddad'" , "'Hui Deng'" , "'Simon Perreault'" References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se><200908280743.18009.simon.perreault@viagenie.ca><2991246A29623A4082EB2B06A2B891A41B7C42ED53@EUSAACMS0703.eamcs.ericsson.se><200908281141.28240.simon.perreault@viagenie.ca> <1d38a3350908282033t67bf8824of7fcfb48f8efe280@mail.gmail.com>, <044e01ca2867$2ac31150$8e71150a@cisco.com> <2991246A29623A4082EB2B06A2B891A41B7C42ED56@EUSAACMS0703.eamcs.ericsson.se> Date: Mon, 31 Aug 2009 18:58:55 -0700 Message-ID: <046e01ca2aa7$c33bed70$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2991246A29623A4082EB2B06A2B891A41B7C42ED56@EUSAACMS0703.eamcs.ericsson.se> Thread-Index: AcooWYdDzTCw5toDQRCzOZYXDXPN0AADLWBwAGDkvnkALtn2UA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4760; t=1251770338; x=1252634338; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[BEHAVE]=20NAT64=20and=20MIPv6 |Sender:=20; bh=E8zZGfhzZpzv0Cc7nCLTl0f6iOWR9qwkCuUK07uzORA=; b=yzE4Hw9EUdyKXXs57g6MOok6wnHGRkIu3sUI6MERTduiOV6rITe3owLAN4 wom1DsTeRWwP7ksGWeGh3xBMR47dq/7V+QKZHg32yk3c281S/5p1Y5eb6yqQ DWsVHcO2JR; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 01:58:47 -0000 > -----Original Message----- > From: Wassim Haddad [mailto:wassim.haddad@ericsson.com] > Sent: Sunday, August 30, 2009 8:27 PM > To: Dan Wing; 'Hui Deng'; 'Simon Perreault' > Cc: behave@ietf.org; Wassim Haddad > Subject: RE: [BEHAVE] NAT64 and MIPv6 > > Hi Dan, > > > I am doubting that NAT64 doesn't change the host, > > how it learn translator prefix? > > With 6/4 translation and DNS64, the host does not need to learn the > translator's prefix, except in special situations such as > when the host > obtains an IPv4 address literal (instead of a DNS name), such > as due to a > referral to an IPv4 address literal or a protocol that only > carries IPv4 > address literals (e.g., deployments of protocols that use SDP). > > => Just a quick question please: if I take the definitions of > "referral" and > "callback" as mentioned in Erik's draft > (draft-nordmark-multi6dt-refer-00), > wouldn't be a problem in some scenarios if the referral is a > DNS64-made > v6 address or if the stored peer's address is also a > DNS64-made v6 address? Yes, referrals of IPv6 address literals will fail if the referrals are between hosts on different networks and those networks have different IPv6 prefixes for the two networks' IPv6/IPv4 translators. However, those applications are referring to IPv4 hosts (not IPv6 hosts) and based on my analysis in draft-wing-behave-nat64-referrals-00, existing applications will do IPv4 referrals for three reasons: * IPv4 referrals to IPv4 hosts always work (as long as the IPv4 address is public! See below). * IPv6 referrals to IPv6 hosts may fail (due to different IPv6 prefix of the translator, as you pointed out). * IPv6 referrals to IPv4 hosts always fail (because IPv4 hosts can't speak IPv6. Yes, we could imagine they can speak Teredo or 6to4, but then they aren't IPv4 hosts -- rather, they are dual-stack hosts. This would mean adding IPv6 support to all of those IPv4 applications and hosts which won't happen on the Internet; maybe it could happen in a walled garden). * IPv4 referrals to IPv6 hosts can be made to work, *if* the IPv6 host can learn the prefix of the 6/4 translator. This is the case where draft-wing-behave-learn-prefix is useful to help referrals. Note that a similar problem occurs, today, on IPv4 networks when NATted IPv4 addresses are referred. For example, if I refer you to 192.168.1.1 (which is behind my NAT) you won't be able to connect to that IPv4 address; you might even connect to a host with that IPv4 address that is behind your NAT, and might even mistakenly think it is my host. On IPv4, applications such as BitTorrent and Skype have long resolved such IPv4 referral problems. The IETF has created a standard ("ICE", draft-ietf-mmusic-ice) which supports smarter referrals in SIP. The concepts in ICE have been used, to varying degrees, by other protocols: * XMPP * HIP * RTSP Going forward, Generic Referral Object (GRO) has been proposed to generalize how to do smarter referrals in various applications, and we have asked for a BoF in Hiroshima, http://trac.tools.ietf.org/bof/trac/wiki/WikiStart, "GROBJ". -d > > Regards, > > Wassim H. > > > > -Hui > > > > 2009/8/28 Simon Perreault : > > > On Friday 28 August 2009 11:31:34 Wassim Haddad wrote: > > >> NAT64 doesn't assume anything about the host, while > > >> PNAT64 assumes that the host implements PNAT64. > > >> > > >> => Your comment does not help solve/avoid the problem! > > > > > > My apologies. Here's something more constructive: > > > > > > It is pointless to try to solve the problem you pointed out > > by changing the > > > networking stack in hosts. If this is done, then the major > > driver for NAT64 > > > goes away, and there is a plethora of solutions that become > > possible. > > > > > > Therefore, it is better to ask this question: is it > > possible to fix the NAT64 > > > box (and/or DNS64) so that the problem you pointed out is solved? > > > > > > Simon > > > -- > > > DNS64 open-source --> http://ecdysis.viagenie.ca > > > STUN/TURN server --> http://numb.viagenie.ca > > > vCard 4.0 --> http://www.vcarddav.org > > > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > From wassim.haddad@ericsson.com Mon Aug 31 19:14:06 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC0428C494 for ; Mon, 31 Aug 2009 19:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STeNqIKkaurf for ; Mon, 31 Aug 2009 19:14:05 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D2D623A6863 for ; Mon, 31 Aug 2009 19:13:33 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n812DjcS011074; Mon, 31 Aug 2009 21:13:45 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 21:12:55 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 21:12:55 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 31 Aug 2009 22:12:55 -0400 From: Wassim Haddad To: Dave Thaler Date: Mon, 31 Aug 2009 22:12:54 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AQHKKHuIwEJcSog/t0mWiJZwt4jxx5C//1+AgAEYr4D//60LwIAAl/4A//+c3CCAAAP1Pw== Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C42ED5C@EUSAACMS0703.eamcs.ericsson.se> References: <2991246A29623A4082EB2B06A2B891A41B7C3D85A9@EUSAACMS0703.eamcs.ericsson.se> <4A9799AC.8050109@it.uc3m.es> <2991246A29623A4082EB2B06A2B891A41B7C42ED57@EUSAACMS0703.eamcs.ericsson.se> <4A9C32D3.80106@it.uc3m.es> <9a367ee30908311737v55797620gac89c8913438cc6f@mail.gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2009 02:12:55.0719 (UTC) FILETIME=[B7EEA370:01CA2AA9] Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 02:14:06 -0000 >>> The point is that you need to use the dns64 (i.e. the dns server) of >>> the network that is running the nat64. >> [...] >> >> +1 > > You mean if my home network is in Sydney and am in the US then I have > to use the cache server in Sydney instead of the local one so that I don'= t break > NAT64 design?! No. I mean you have two choices: a) use the DNS in Sydney if you want to use your home address with the result, =3D> OK. This is what I meant. b) use the DNS in the US if you _don't_ want to use your home address with the result (i.e. don't use MIP) =3D> As far as IP mobility is concerned, let's keep this one aside. You can't mix them and expect anything to work. DNS64/NAT64 doesn't change this fact in any way. > BTW, do you think you'll get the same DNS reply for any service than if y= ou > query the local cache? I'm not sure which question you're asking, but the point is that you can't = use a DNS=20 server on one network and then communicate on a different network and expec= t it=20 to work,=20 =3D> IMHO, if DNS64 and NAT64 were designed in a different way then none of= the=20 "new" rules you mentioned for mobility to work would have been needed! This= of=20 course would involve a "smarter" end host. OTOS, applying what you're sugge= sting=20 does not mean necessarily that you won't need to modify the host! Wassim H.= From brian.e.carpenter@gmail.com Mon Aug 31 19:22:28 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DBB28C316 for ; Mon, 31 Aug 2009 19:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-dFM89utIDM for ; Mon, 31 Aug 2009 19:22:27 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id B066528C2DF for ; Mon, 31 Aug 2009 19:22:27 -0700 (PDT) Received: by pzk38 with SMTP id 38so4452116pzk.5 for ; Mon, 31 Aug 2009 19:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=iMs4mNHcVwvkIL0+j8wHpMD6/SOiYADsQGIAsAFb2ho=; b=E4sW6G/cCxcgltIMH8pDlBvjB7VD/+h1RLHqlX+UFcaq9odNJLVl2SKglNAZg5xPLU 4Mjc6znEg5C/OBGNYAqvJEuofb0FrmeN35jIF9ZzDi1jLjNKmN91VQkKhWF7a4g1ulIk m+NlaaySSqVC+j5TEuSk+cOiIXkGRYRvHoRNc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=tpwi3xAa0fGslcjqtm2prF/C0lNraAKSDsuBdLoeDE6+BxKbQ3WPmFmaogM2o5goJj rjuTfj1AkPqURCPrlAOH2zRAqH98NTlYU5AMfYg1gtnVMi9LvQkr8MsCq1zyZarXrZRv ryazD76fH1cD+Oy+KtyVO9gBjaltYpD1EJncc= Received: by 10.115.103.26 with SMTP id f26mr3584481wam.198.1251771752271; Mon, 31 Aug 2009 19:22:32 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id j34sm1497488waf.42.2009.08.31.19.22.31 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Aug 2009 19:22:31 -0700 (PDT) Message-ID: <4A9C8560.6010903@gmail.com> Date: Tue, 01 Sep 2009 14:22:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Referrals - discussion and possible BOF X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 02:22:28 -0000 Following the short discussion in the Stockholm BEHAVE meeting, there is a proposed (not yet approved) BOF for Hiroshima on the topic of a generic referral object. Please see http://www.cs.auckland.ac.nz/~brian/GROBJ-BOF.txt and if you want to discuss the topic, join the grobj@ietf.org mailing list. We want to attract Applications Area discussion. Brian Carpenter From hesham@elevatemobile.com Mon Aug 31 19:25:16 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5970228C316 for ; Mon, 31 Aug 2009 19:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MxrJYLOv8v1 for ; Mon, 31 Aug 2009 19:25:15 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 4C6643A6F06 for ; Mon, 31 Aug 2009 19:25:14 -0700 (PDT) Received: from [122.110.175.159] (helo=[192.168.0.4]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MiJ3c-0002xI-0t; Tue, 01 Sep 2009 12:25:17 +1000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 01 Sep 2009 12:25:06 +1000 From: Hesham Soliman To: Dave Thaler , Wassim Haddad Message-ID: Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AQHKKHuIwEJcSog/t0mWiJZwt4jxx5C//1+AgAEYr4D//60LwIAAl/4A//+c3CCAAAvsuA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: Wassim Haddad , "behave@ietf.org" Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 02:25:16 -0000 > > No. I mean you have two choices: > a) use the DNS in Sydney if you want to use your home address with > the result, > b) use the DNS in the US if you _don't_ want to use your home address > with the result (i.e. don't use MIP) > > You can't mix them and expect anything to work. DNS64/NAT64 doesn't > change this fact in any way. => An average user who wants to type youtube.com and get there would be able to do that with MIPv6 and IPv6 only if youtube.com had a AAAA record regardless of which DNS she queries. Furthermore, the same scenario would work in a dual stack environment with DSMIPv6 regardless of whether a v4 NAT is used or not, and it won't matter which DNS you query. So I think the additional problem is in fact caused by NAT64. Of course if I query a local name for my company's machine from another DNS it won't work, but this is not the reference scenario to compare with IMHO. At the very least any solution should highlight this as a requirement for MNs because 3775 doesn't limit the DNS queries to the home DNS. But I don't know how to do that if the presence of a NAT is not known to the host. Hesham > >> BTW, do you think you'll get the same DNS reply for any service than if you >> query the local cache? > > I'm not sure which question you're asking, but the point is that > you can't use a DNS server on one network and then communicate on > a different network and expect it to work, unless you can guarantee > that both are using the public DNS namespace, since enterprises > and even homes often use private name spaces. > > -Dave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From cb.list6@gmail.com Mon Aug 31 21:24:29 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A2E3A6EDA for ; Mon, 31 Aug 2009 21:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wDIvPp1BRnp for ; Mon, 31 Aug 2009 21:24:28 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 2E6C13A6EC0 for ; Mon, 31 Aug 2009 21:24:28 -0700 (PDT) Received: by pzk38 with SMTP id 38so4592964pzk.5 for ; Mon, 31 Aug 2009 21:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cjU55rCdDu3W68fR0wjFIKcxs6PDNCn9svfD5n7jDWs=; b=MxpiCNf4ybeUbQ+aiPV4XJhDSFAeaxzDT/eKJISKJS24U9JhftEaG1ujme+VSvoH04 kp7f6fYSJ41HdV6mLUofYBQ+FqL2uj6xO6d94E7CBu4sMC/9nNP8b8pTe9gD1nE+z44k 9KCMVJkXOlORuKTVdlvpTDObSs41H+bE8S8F8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EkTSa44VVQ4RfdtaIl971zCk043jfiQC2hxcxR2qGjWrRoypZBhOoPd2nWWY00OEIx ipG4P1ztCm+9Y5jrcnOJ7yc0RgAi1c+nJKVueDzLOTbE3NzvPa+VezIxKQY3FhVt36AF Ey6XT2btY0qDUpYMCBNyerj8h9aFCMEFL3LuM= MIME-Version: 1.0 Received: by 10.142.9.39 with SMTP id 39mr50282wfi.115.1251779076431; Mon, 31 Aug 2009 21:24:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Aug 2009 21:24:36 -0700 Message-ID: From: Cameron Byrne To: Hesham Soliman Content-Type: text/plain; charset=ISO-8859-1 Cc: Wassim Haddad , "behave@ietf.org" , Dave Thaler , Wassim Haddad Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 04:24:29 -0000 > => An average user who wants to type youtube.com and get there would be able > to do that with MIPv6 and IPv6 only if youtube.com had a AAAA record > regardless of which DNS she queries. Furthermore, the same scenario would > work in a dual stack environment with DSMIPv6 regardless of whether a v4 NAT > is used or not, and it won't matter which DNS you query. So I think the > additional problem is in fact caused by NAT64. Regardless, NAT64 is an interim solution and anything that requires a change to MN / end-host should be out of scope. Other things that should be out of scope include exotic protocols that are not implemented in any major operating system (MIPv6). If a user would like to have MIPv6 work, they should conspire through non-technical means to communicate using IPv6 (i know paying for v6 is a novel idea), because that is the end-state the MIPv6 designers had in mind. If we make the middle-box so smart, we will never get rid of it. Or, it will never be done. I want NAT64 in my network because it is a needed interim step, but i don't want to stop the network evolution there. I need IPv6 end-to-end to be realized (NAT64 does have an exit strategy), then MIPv6 will work great (if your firewall does not break it). Cameron Byrne Principal Engineer T-Mobile USA From hesham@elevatemobile.com Mon Aug 31 21:36:08 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B6B3A6B92 for ; Mon, 31 Aug 2009 21:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Sb7hSeQHuwV for ; Mon, 31 Aug 2009 21:36:07 -0700 (PDT) Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 242CB3A67BE for ; Mon, 31 Aug 2009 21:36:06 -0700 (PDT) Received: from [122.110.175.159] (helo=[192.168.0.4]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1MiL6I-00068a-Q8; Tue, 01 Sep 2009 14:36:11 +1000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 01 Sep 2009 14:35:59 +1000 From: Hesham Soliman To: Cameron Byrne Message-ID: Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AcoqvbP3WbPqAE3FJUeQ2m+4atlgDA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: Wassim Haddad , "behave@ietf.org" , Dave Thaler , Wassim Haddad Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 04:36:08 -0000 On 1/09/09 2:24 PM, "Cameron Byrne" wrote: >> => An average user who wants to type youtube.com and get there would be able >> to do that with MIPv6 and IPv6 only if youtube.com had a AAAA record >> regardless of which DNS she queries. Furthermore, the same scenario would >> work in a dual stack environment with DSMIPv6 regardless of whether a v4 NAT >> is used or not, and it won't matter which DNS you query. So I think the >> additional problem is in fact caused by NAT64. > > Regardless, NAT64 is an interim solution and anything that requires a > change to MN / end-host should be out of scope. => Please read my text above, I didn't suggest host changes. First we need to acknowledge an issue then figure out what to do about it. Other things that > should be out of scope include exotic protocols that are not > implemented in any major operating system (MIPv6). => Hmm, I think linux, BSD and Symbian are pretty major but I guess you disagree. If a user would > like to have MIPv6 work, they should conspire through non-technical > means to communicate using IPv6 (i know paying for v6 is a novel > idea), because that is the end-state the MIPv6 designers had in mind. > If we make the middle-box so smart, we will never get rid of it. Or, > it will never be done. => I have no idea what you're talking about or what you think MIPv6 desginers conspired to do. The point is there is a problem that first need to be acknowledged instead of delving into irrelevant discussions. > > I want NAT64 in my network because it is a needed interim step, but i > don't want to stop the network evolution there. I need IPv6 > end-to-end to be realized (NAT64 does have an exit strategy), then > MIPv6 will work great (if your firewall does not break it). => That's fine, but you can't force everyone in the world to be in lock step with your vision so things that break existing protocols should be documented with a pointer on what IETF concensus is for the solution, or lack of. Hesham > > Cameron Byrne > Principal Engineer > T-Mobile USA From wassim.haddad@ericsson.com Mon Aug 31 21:38:48 2009 Return-Path: X-Original-To: behave@core3.amsl.com Delivered-To: behave@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFAF728C15F for ; Mon, 31 Aug 2009 21:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGxMtwTwfmgB for ; Mon, 31 Aug 2009 21:38:47 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id ADFD728C173 for ; Mon, 31 Aug 2009 21:38:47 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n814csP3023127; Mon, 31 Aug 2009 23:38:55 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 23:38:10 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Aug 2009 23:38:10 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 1 Sep 2009 00:38:09 -0400 From: Wassim Haddad To: Cameron Byrne , Hesham Soliman Date: Tue, 1 Sep 2009 00:35:25 -0400 Thread-Topic: [BEHAVE] NAT64 and MIPv6 Thread-Index: AcoqvCKIqN4mVrX4S+eDDzzNPX/duAAAX2jL Message-ID: <2991246A29623A4082EB2B06A2B891A41B7C42ED5D@EUSAACMS0703.eamcs.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2009 04:38:10.0303 (UTC) FILETIME=[023AA0F0:01CA2ABE] Cc: "behave@ietf.org" , Dave Thaler Subject: Re: [BEHAVE] NAT64 and MIPv6 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 04:38:48 -0000 > =3D> An average user who wants to type youtube.com and get there would be= able > to do that with MIPv6 and IPv6 only if youtube.com had a AAAA record > regardless of which DNS she queries. Furthermore, the same scenario would > work in a dual stack environment with DSMIPv6 regardless of whether a v4 = NAT > is used or not, and it won't matter which DNS you query. So I think the > additional problem is in fact caused by NAT64. Regardless, NAT64 is an interim solution and anything that requires a change to MN / end-host should be out of scope. Other things that should be out of scope include exotic protocols that are not implemented in any major operating system (MIPv6). If a user would like to have MIPv6 work, they should conspire through non-technical means to communicate using IPv6 (i know paying for v6 is a novel idea), because that is the end-state the MIPv6 designers had in mind. If we make the middle-box so smart, we will never get rid of it. Or, it will never be done. I want NAT64 in my network because it is a needed interim step, but i don't want to stop the network evolution there. I need IPv6 end-to-end to be realized (NAT64 does have an exit strategy), then MIPv6 will work great (if your firewall does not break it). =3D> Your second paragraph is in violent contradiction with the first one r= egarding MIPv6 and with your previous comments... Regards, Wassim H.