From root@core3.amsl.com Thu Apr 30 11: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 E20B43A6A91; Thu, 30 Apr 2009 11:00:01 -0700 (PDT) From: IETF Secretariat To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090430180001.E20B43A6A91@core3.amsl.com> Date: Thu, 30 Apr 2009 11:00:01 -0700 (PDT) X-Mailman-Approved-At: Fri, 01 May 2009 09:11:15 -0700 Cc: behave@ietf.org Subject: [BEHAVE] BEHAVE Interim Teleconference X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 Apr 2009 18:00:02 -0000 On Wednesday, May 20, 2009, 07:00-09:00am PDT (10:00-12:00 EDT, 14:00-16:00 GMT), BEHAVE will be having a teleconference interim meeting, with the following agenda: * 6/4 translation document organization * 6/4 translation on a host * DNS-ALG open issues * translation open issues (e.g., fragmentation) Dial-in information for this meeting will be posted to the BEHAVE wiki page at: http://trac.tools.ietf.org/wg/behave/trac/wiki From fred@cisco.com Fri May 1 15:29: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 839DC3A6C97 for ; Fri, 1 May 2009 15:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, 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 jM3s21Aje6J6 for ; Fri, 1 May 2009 15:29:57 -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 936963A6C38 for ; Fri, 1 May 2009 15:29:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="161163508" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 May 2009 22:31:21 +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 n41MVLNn025258; Fri, 1 May 2009 15:31:21 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n41MVLZ8023939; Fri, 1 May 2009 22:31:21 GMT Message-Id: <956E26DC-D729-4C2F-A56F-288843099146@cisco.com> From: Fred Baker To: Behave Chairs In-Reply-To: <0e0f01c9c9c9$f94e7d90$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 v930.3) Date: Fri, 1 May 2009 15:31:18 -0700 References: <0e0f01c9c9c9$f94e7d90$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1747; t=1241217081; x=1242081081; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20working=20group=20status=20u pdate |Sender:=20; bh=DvZ9SgDWfj6trLkJC5yHV9+QCnrcD2xBlJc+bxhczHU=; b=MaFr0bLnyvsUz5S5OBcMIjZ6WRj5sISE2KWsTapVEUC5Af+M/Y7YAKIQcu 7k5C0DzKmRvgigumo5ySkbVXDycuwmdhLY9305fWiDP0D8W0k+X5bosdBAPr cmSs/9tqUH; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] working group status update X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 01 May 2009 22:29:58 -0000 On Apr 30, 2009, at 12:29 PM, Dan Wing wrote: > * no update on SCTPNAT. by which I assume you mean: http://tools.ietf.org/html/draft-ietf-behave-sctpnat "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 16-Feb-09, Something the working group might want to wonder about... We have recently seen several drafts that talk about using port numbers to differentiate among multiple systems using the same IP address. The different systems get different port ranges. http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-ipaddr-assign "Port Restricted IP Address Assignment", Gabor Bajko, Teemu Savolainen, 3-Nov-08, http://tools.ietf.org/html/draft-boucadair-dhc-port-range "DHCP Options for Conveying Port Mask and Port Range Router IP Address", Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis, Alain Villefranque, 29-Oct-08, http://tools.ietf.org/html/draft-boucadair-port-range "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion", Mohammed Boucadair, Pierre Levis, Gabor Bajko, Teemu Savolainen, 30- Jan-09, http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization "Port Randomization", Michael Larsen, Fernando Gont, 11-Mar-09, As I understand the SCTP NAT draft, it has no problem with people changing their addresses, but really hopes they won't change their ports. How do these two lines of reasoning fit together? From iljitsch@muada.com Sat May 2 10:54: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 E2F393A6892 for ; Sat, 2 May 2009 10:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.791 X-Spam-Level: X-Spam-Status: No, score=-5.791 tagged_above=-999 required=5 tests=[AWL=0.508, 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 UzQb5hoNvIi0 for ; Sat, 2 May 2009 10:54:20 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id B5F683A6BAA for ; Sat, 2 May 2009 10:54:19 -0700 (PDT) Received: from [192.168.2.4] (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 n42HslPR066291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 May 2009 19:54:55 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <49F95104.5010004@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 v930.3) Date: Sat, 2 May 2009 19:54:45 +0200 References: <55CFDB58-ADD2-460E-9142-87F28E44506E@cisco.com> <49E8CFD9.40904@it.uc3m.es> <49ED219C.1070202@gmail.com> <49EDD647.3060500@free.fr><49EDD750.1070502@network-heretics.com> <49EDDC57.1060302@free.fr><49EE1507.9090306@network-heretics.com><49EEC270.7040607@free.fr> <49EEDADA.8040906@it.uc3m.es><49EF1888.5020302@free.fr> <49EF1D4B.5050300@it.uc3m.es><49EF5017.5030409@free.fr> <49EF6F5D.2010306@it.uc3m.es><49F032DE.3060604@free.fr> <49F03BB4.9050103@it.uc3m.es><49F074D4.2070006@free.fr> <49F07ACF.9000505@it.uc3m.es><49F1D55E.6000003@free.fr> <0C02E699-3F36-4C04-AEB8-59E78D49B827@muada.com> <02ca01c9c533$e8f14620$c5f0200a@cisco.com> <49F25FCB.5040500@network-heretics.com> <49F5E83A.9020 101@free.fr> <051301c9c760$f13d15f0$c5f0200a@cisco.com> <49F6A398.4040207@f ree.fr> <084901c9c82a$890445b0$c5f0200a@cisco.com> <49F805D0.1010200@free.fr> <7D805B55-0019-49BF-9E96-46E3962BC51A@muada.com> <49F95104.5010004@free.fr> X-Mailer: Apple Mail (2.930.3) Cc: Behave WG Subject: Re: [BEHAVE] Question on embedded address format in draft-baker-behave-v4v6-framework-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: Sat, 02 May 2009 17:54:21 -0000 On 30 apr 2009, at 9:19, R=E9mi Despr=E9s wrote: >> But what about people who run dual stack, and thus have no use for >> NAT64 and thus not for a DNS64? They would see the ::ffff:0:0/96 >> addresses, which may get them to send normal IPv4 packets but there's >> also a good change that it won't. > - If they have IPv4 enabled they don't need NAT64. Right, but when they do a AAAA lookup they get that ::ffff:0:0/96 =20 address, which could cause trouble for them. Also, you would still have to have the DNS64 function becaus there is =20= no way EVERYONE is going to add these addresses. So why not keep =20 things simple and let NOBODY add them but have the DNS64 create the =20 required AAAA records for NAT64? >> For instance, the "mapped on the wire harmful" meme has been >> percolating for half a decade and I'm willing to bet that at least >> the NetBSD people filter this out in some way. > This may be the case, but, if my proposal is accepted, this can be =20 > fixed before mapped DNS64s need to stop translating mapped AAAAs =20 > into ISP specific NAT64 prefixes (i.e. before IPv6-only to IPv4 =20 > connectivity has to be reconciled with DNSsec). Even though hosts running IPv6 are at least not those that haven't =20 been upgraded since 1998, it's still widely optimistic to assume that =20= ANY change can be made to the deployed base within two years. > In my understanding, if an intermediate DNS64 makes synthetic AAAAs, =20= > it necessarily breaks the DNSsec provided guarantee that an RR that =20= > is received does come from the DNS server of the host it points to. Of course. A DNSSEC validator would recognize fake AAAA records as =20 fake. That's the point of having DNSSEC. But it can tell that the A =20 record is real and then perform the DNS64 function after the =20 validation so if the DNSSEC validator knows about DNS64 there is no =20 issue. Iljitsch= From iljitsch@muada.com Sun May 3 07:26: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 3A3AE3A6983 for ; Sun, 3 May 2009 07:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.94 X-Spam-Level: X-Spam-Status: No, score=-3.94 tagged_above=-999 required=5 tests=[AWL=-1.385, BAYES_40=-0.185, 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 TPujLz0MI-ye for ; Sun, 3 May 2009 07:26:38 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id CBF2D3A6E8C for ; Sun, 3 May 2009 07:26:07 -0700 (PDT) Received: from [192.168.2.4] (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 n43EQnsB072967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 3 May 2009 16:26:58 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@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 v930.3) Date: Sun, 3 May 2009 16:26:47 +0200 X-Mailer: Apple Mail (2.930.3) Subject: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 14:26:39 -0000 Hi, I got some feedback from Barry Leiba and John Klensin about the FTP ALG for IPv6-to-IPv4 translation. The comments don't really address what's in the draft, but rather the idea of having an FTP ALG in the first place. They really don't like it. John feels it's a better idea to update clients and servers rather than put ALGs in the middle. I'm afraid they, and perhaps others, will speak up during IETF last call. The fact that the behave charter says to stay away from ALGs probably won't help at that point. Apart from that, there's the question of how much complexity for the sake of completeness we want to have in an FTP ALG. Basically, we have four options at this point: 1. Take this feeback to heart and forego the ALG. This means that the only thing that will work is EPSV mode, which a large majority of clients use and about half of the servers. 2. Do a very minimalist/simple ALG. This would be translating all EPSV to PASV, which is compatible with (almost?) all servers and most clients. (See [1].) 3. Do a more complete ALG that handles EPSV and "normal" EPRT use, and let other EPRT use through transparently. This should work with pretty much all clients. 4. Try to be as complete as possible and cover all exceptional cases that can be covered. This is what http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-02 tries to do. From the feedback I've gotten, I think 4 is the wrong way to go because it makes the ALG relatively complex and because clients trying to do more complex stuff (set up control channels to two servers and instruct one to send and the other to receive so the data flows between the two servers) could fail because of the ALG double guessing what they're trying to do. If anyone has any opinions, please let me know. Iljitsch [1] there is a possible corner case of servers that instruct the client to connect to a different address for the data than for the control channel. I think this is extremely rare because it requires the server to have multiple addresses and the server software to know about this and handle it properly. Also, EPSV doesn't support this so a server implementing EPSV would have to have different behaviors for EPSV and PASV without any obvious benefit for the different PASV behavior. From ajs@shinkuro.com Sun May 3 07:42: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 EA8B13A70CD for ; Sun, 3 May 2009 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.795, 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 CNKlbZVVaQi9 for ; Sun, 3 May 2009 07:42:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2F5F53A6B4C for ; Sun, 3 May 2009 07:42:11 -0700 (PDT) Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A5B652FE960A for ; Sun, 3 May 2009 14:43:35 +0000 (UTC) Date: Sun, 3 May 2009 10:43:34 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090503144333.GB2068@shinkuro.com> References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 14:42:12 -0000 On Sun, May 03, 2009 at 04:26:47PM +0200, Iljitsch van Beijnum wrote: > > 1. Take this feeback to heart and forego the ALG. This means that the > only thing that will work is EPSV mode, which a large majority of > clients use and about half of the servers. > If anyone has any opinions, please let me know. To me, the whole point of this effort is to do _something_ for users to kludge up usable communications between v4 and c6 networks, and _not_ to make the networks really interoperate. If I have the right idea about that, then it seems like the answer we can quite plausibly give to people for whom FTP doesn't work is, "You need to use [client|server] $FOO instead." I know that won't be popular with everyone. I don't think we can reasonably expect to solve all the problems, and I don't think we should try. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From iljitsch@muada.com Sun May 3 07:47: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 D54413A6838 for ; Sun, 3 May 2009 07:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.693, 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 CpJl9LxcNK96 for ; Sun, 3 May 2009 07:47:22 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D0B0A3A6ADE for ; Sun, 3 May 2009 07:47:21 -0700 (PDT) Received: from [192.168.2.4] (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 n43EmSxd073069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 May 2009 16:48:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Andrew Sullivan In-Reply-To: <20090503144333.GB2068@shinkuro.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 16:48:27 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <20090503144333.GB2068@shinkuro.com> X-Mailer: Apple Mail (2.930.3) Cc: behave@ietf.org Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 14:47:22 -0000 On 3 mei 2009, at 16:43, Andrew Sullivan wrote: > To me, the whole point of this effort is to do _something_ for users > to kludge up usable communications between v4 and c6 networks, and > _not_ to make the networks really interoperate. If I have the right > idea about that, then it seems like the answer we can quite plausibly > give to people for whom FTP doesn't work is, "You need to use > [client|server] $FOO instead." I know that won't be popular with > everyone. I don't think we can reasonably expect to solve all the > problems, and I don't think we should try. So you're in favor of option 1, no ALG? I'm with you with regard to the client part, but if you need to download a driver from ftp.lexmark.com or some such, I don't think the advice to upgrade the FTP server is going to be very helpful... From ajs@shinkuro.com Sun May 3 08:39: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 5496E3A68CB for ; Sun, 3 May 2009 08:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.762, 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 ZnMONMQfUrkJ for ; Sun, 3 May 2009 08:39:58 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 62B633A67CC for ; Sun, 3 May 2009 08:39:58 -0700 (PDT) Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 21ED02FE960A for ; Sun, 3 May 2009 15:41:23 +0000 (UTC) Date: Sun, 3 May 2009 11:41:21 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090503154121.GC2068@shinkuro.com> References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <20090503144333.GB2068@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 15:39:59 -0000 On Sun, May 03, 2009 at 04:48:27PM +0200, Iljitsch van Beijnum wrote: > So you're in favor of option 1, no ALG? Yes. > I'm with you with regard to the client part, but if you need to download > a driver from ftp.lexmark.com or some such, I don't think the advice to > upgrade the FTP server is going to be very helpful... To me, that's an opportunity to allow market forces to work: as soon as I can't get my driver, I contact their support people. Support costs money. Quickly, the cost of that will add up & supporting v6-only users will become important, at which point I'd rather them think, "We need to deploy on v6," than, "We need to add some more kludges." A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From huitema@windows.microsoft.com Sun May 3 09:07: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 0976428C24B for ; Sun, 3 May 2009 09:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 x-hMqBZ3LGBi for ; Sun, 3 May 2009 09:07:55 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 589DB28C10A for ; Sun, 3 May 2009 09:07:55 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sun, 3 May 2009 09:09:20 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Sun, 3 May 2009 09:09:20 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Sun, 3 May 2009 09:09:20 -0700 From: Christian Huitema To: Andrew Sullivan , "behave@ietf.org" Date: Sun, 3 May 2009 09:09:17 -0700 Thread-Topic: [BEHAVE] FTP64 ALG: how to proceed? Thread-Index: AcnMBbuE2F7YgtQESJqEJqI4t5bb5AAA1Peg Message-ID: <8EFB68EAE061884A8517F2A755E8B60A1CD848D628@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <20090503144333.GB2068@shinkuro.com> <20090503154121.GC2068@shinkuro.com> In-Reply-To: <20090503154121.GC2068@shinkuro.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 Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 16:07:56 -0000 > > So you're in favor of option 1, no ALG? >=20 > Yes. So am I. As Iljitsch mentioned, most FTP clients support the EPSV mode alre= ady. They have to, because they are bound to encounter networks with no FTP= ALG. The same pressure will force servers to upgrade. Less ALG is generally a good thing, which is a reason for not publishing an= other ALG spec. -- Christian Huitema From iljitsch@muada.com Sun May 3 09: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 3B17D28C25B for ; Sun, 3 May 2009 09:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.118 X-Spam-Level: X-Spam-Status: No, score=-5.118 tagged_above=-999 required=5 tests=[AWL=-0.149, 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 ZueTbwpxFw+l for ; Sun, 3 May 2009 09:18:13 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0BB28C259 for ; Sun, 3 May 2009 09:18:13 -0700 (PDT) Received: from [192.168.2.4] (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 n43GJDq9073448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 May 2009 18:19:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Christian Huitema In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CD848D628@NA-EXMSG-W601.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 v930.3) Date: Sun, 3 May 2009 18:19:10 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <20090503144333.GB2068@shinkuro.com> <20090503154121.GC2068@shinkuro.com> <8EFB68EAE061884A8517F2A755E8B60A1CD848D628@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Apple Mail (2.930.3) Cc: Andrew Sullivan , "behave@ietf.org" Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 16:18:14 -0000 On 3 mei 2009, at 18:09, Christian Huitema wrote: >>> So you're in favor of option 1, no ALG? >> Yes. > So am I. As Iljitsch mentioned, most FTP clients support the EPSV > mode already. They have to, because they are bound to encounter > networks with no FTP ALG. The same pressure will force servers to > upgrade. Well, let me point out that even in the Windows 7 beta the command line FTP client doesn't support EPSV. It will do PORT (IPv4) or EPRT (IPv6). These can't work through neither NAT nor NAT64 nor SIIT without an ALG. However, it is of course not that hard to find an FTP client for Windows that will do EPSV. (And ftp.microsoft.com supports EPSV over IPv4.) From fluffy@cisco.com Sun May 3 11: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 98B073A6896 for ; Sun, 3 May 2009 11:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.778 X-Spam-Level: X-Spam-Status: No, score=-105.778 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63, 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 Rfzfj+yUl-TG for ; Sun, 3 May 2009 11:15:15 -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 EB62A28C183 for ; Sun, 3 May 2009 11:15:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,287,1238976000"; d="scan'208";a="297469172" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 May 2009 18:16:39 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n43IGd0m027057; Sun, 3 May 2009 11:16:39 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n43IGcjk016844; Sun, 3 May 2009 18:16:38 GMT From: Cullen Jennings To: Iljitsch van Beijnum In-Reply-To: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 12:16:37 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2817; t=1241374599; x=1242238599; c=relaxed/simple; s=sjdkim1004; 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=20[BEHAVE]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=cjgmd+nQymJzeFXMSvVJXY6lIPKr64hBqC8Ev3TVuYI=; b=o7i5zE8k/rJLIIgpkrRJjcM8eFkjAagSxsyNDZ1/5IqZyOZHzJiTHXedoh 5dpGxOiT8/cRb8VVZptYsIPoaks1WrMWpeEEHpS0wfNasY7DEe7hRUgW8vyB ibMts303/GCU5iH5FfMlVVKwkqW3qnw06YKVd87XpVcZ5bHhE6XoA=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 18:15:22 -0000 I rather see us do things along the lines of EPSV to fix FTP instead of putting an ALG in the NAT. Cullen On May 3, 2009, at 8:26 AM, Iljitsch van Beijnum wrote: > Hi, > > I got some feedback from Barry Leiba and John Klensin about the FTP > ALG for IPv6-to-IPv4 translation. The comments don't really address > what's in the draft, but rather the idea of having an FTP ALG in the > first place. They really don't like it. John feels it's a better > idea to update clients and servers rather than put ALGs in the > middle. I'm afraid they, and perhaps others, will speak up during > IETF last call. The fact that the behave charter says to stay away > from ALGs probably won't help at that point. > > Apart from that, there's the question of how much complexity for the > sake of completeness we want to have in an FTP ALG. > > Basically, we have four options at this point: > > 1. Take this feeback to heart and forego the ALG. This means that > the only thing that will work is EPSV mode, which a large majority > of clients use and about half of the servers. > > 2. Do a very minimalist/simple ALG. This would be translating all > EPSV to PASV, which is compatible with (almost?) all servers and > most clients. (See [1].) > > 3. Do a more complete ALG that handles EPSV and "normal" EPRT use, > and let other EPRT use through transparently. This should work with > pretty much all clients. > > 4. Try to be as complete as possible and cover all exceptional cases > that can be covered. This is what http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-02 > tries to do. > > From the feedback I've gotten, I think 4 is the wrong way to go > because it makes the ALG relatively complex and because clients > trying to do more complex stuff (set up control channels to two > servers and instruct one to send and the other to receive so the > data flows between the two servers) could fail because of the ALG > double guessing what they're trying to do. > > If anyone has any opinions, please let me know. > > Iljitsch > > [1] there is a possible corner case of servers that instruct the > client to connect to a different address for the data than for the > control channel. I think this is extremely rare because it requires > the server to have multiple addresses and the server software to > know about this and handle it properly. Also, EPSV doesn't support > this so a server implementing EPSV would have to have different > behaviors for EPSV and PASV without any obvious benefit for the > different PASV behavior. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marcelo@it.uc3m.es Sun May 3 11:30: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 8A36C28C26B for ; Sun, 3 May 2009 11:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=-0.565, 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 uLK0sPoEZSJb for ; Sun, 3 May 2009 11:30:31 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A0E4A3A6F99 for ; Sun, 3 May 2009 11:29:53 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (21.pool85-53-144.dynamic.orange.es [85.53.144.21]) by smtp02.uc3m.es (Postfix) with ESMTP id 420C765A415; Sun, 3 May 2009 20:31:17 +0200 (CEST) Message-ID: <49FDE2F4.6070906@it.uc3m.es> Date: Sun, 03 May 2009 20:31:16 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> In-Reply-To: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.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-16620.001 Cc: Behave WG Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 18:30:38 -0000 Hi, If i recall correctly, the comments expressed during the last meeting was that an FTP ALG was needed. I think we have reached a good tradeoff basically defining the FTP ALG in a separate RFC than the basic NAT spec. This allows to be compliant with the NAT spec wihtou having to implement any ALG, but also allows vendors that will implement an FTP ALG to obtain guidance. So, i would suggest to have the FTP ALG be defined but in a separated document. Regards, marcelo Iljitsch van Beijnum escribió: > Hi, > > I got some feedback from Barry Leiba and John Klensin about the FTP > ALG for IPv6-to-IPv4 translation. The comments don't really address > what's in the draft, but rather the idea of having an FTP ALG in the > first place. They really don't like it. John feels it's a better idea > to update clients and servers rather than put ALGs in the middle. I'm > afraid they, and perhaps others, will speak up during IETF last call. > The fact that the behave charter says to stay away from ALGs probably > won't help at that point. > > Apart from that, there's the question of how much complexity for the > sake of completeness we want to have in an FTP ALG. > > Basically, we have four options at this point: > > 1. Take this feeback to heart and forego the ALG. This means that the > only thing that will work is EPSV mode, which a large majority of > clients use and about half of the servers. > > 2. Do a very minimalist/simple ALG. This would be translating all EPSV > to PASV, which is compatible with (almost?) all servers and most > clients. (See [1].) > > 3. Do a more complete ALG that handles EPSV and "normal" EPRT use, and > let other EPRT use through transparently. This should work with pretty > much all clients. > > 4. Try to be as complete as possible and cover all exceptional cases > that can be covered. This is what > http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-02 tries to do. > > From the feedback I've gotten, I think 4 is the wrong way to go > because it makes the ALG relatively complex and because clients trying > to do more complex stuff (set up control channels to two servers and > instruct one to send and the other to receive so the data flows > between the two servers) could fail because of the ALG double guessing > what they're trying to do. > > If anyone has any opinions, please let me know. > > Iljitsch > > [1] there is a possible corner case of servers that instruct the > client to connect to a different address for the data than for the > control channel. I think this is extremely rare because it requires > the server to have multiple addresses and the server software to know > about this and handle it properly. Also, EPSV doesn't support this so > a server implementing EPSV would have to have different behaviors for > EPSV and PASV without any obvious benefit for the different PASV > behavior. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Sun May 3 12:44: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 06BEC3A6A6D for ; Sun, 3 May 2009 12:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.113 X-Spam-Level: X-Spam-Status: No, score=-5.113 tagged_above=-999 required=5 tests=[AWL=-0.144, 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 PqzMa57dFcGr for ; Sun, 3 May 2009 12:44:26 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 71CDE3A6A7A for ; Sun, 3 May 2009 12:44:17 -0700 (PDT) Received: from [192.168.2.4] (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 n43Jj1iD074301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 3 May 2009 21:45:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> From: Iljitsch van Beijnum To: Cullen Jennings 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 v930.3) Date: Sun, 3 May 2009 21:45:00 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> X-Mailer: Apple Mail (2.930.3) Cc: Behave WG Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 19:44:27 -0000 On 3 mei 2009, at 20:16, Cullen Jennings wrote: > I rather see us do things along the lines of EPSV to fix FTP instead > of putting an ALG in the NAT. Would an informational document that explains the following be reasonable? 1. That server operators should support EPSV over IPv4 2. That clients should use EPSV rather than EPRT 3. What an FTP ALG should do in the case !(1 && 2) This would give implementers who feel they need to offer an FTP ALG (which I'm sure will be most of them) guidance without explicitly endorsing ALGs and may get (some) client/server vendors and operators to upgrade. From fred@cisco.com Sun May 3 12:58: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 340E73A705B for ; Sun, 3 May 2009 12:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, 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 du7KvIYAbciz for ; Sun, 3 May 2009 12:58:28 -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 3164328C112 for ; Sun, 3 May 2009 12:58:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,287,1238976000"; d="scan'208";a="74404649" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 03 May 2009 19:59:53 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n43JxrIY016453; Sun, 3 May 2009 12:59:53 -0700 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n43JxrYK023526; Sun, 3 May 2009 19:59:53 GMT Message-Id: From: Fred Baker To: james woodyatt 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 v930.3) Date: Sun, 3 May 2009 12:59:53 -0700 References: <7EA10A3F-BE9C-4A46-8F0F-D409C2EF17C1@muada.com> <49EC8105.80206@network-heretics.com> <593C802D-1216-4799-BB45-CDF68607A1B5@muada.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=801; t=1241380793; x=1242244793; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[BEHAVE]=20Comments=20on=20draft-baker- behave-v4v6-translation-02 |Sender:=20; bh=8LuXq+KBoIwkuQPYvZcJZ7he2JnCyKjh9vD/z6JGntM=; b=sqXsTxCHQ2mfCM3YpjC5u9+eT7lMCmEuIRHkF0HepSDOqkUKEed1dnGog4 mYdZ7Zd83SWNpPciY5oykIcmE4GEUsYkUDE+YgipHdwlftFwBl7JsdlA2FFt IVLfOkeqmk; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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: Sun, 03 May 2009 19:58:34 -0000 yes. It only fails if people try changing ports. On Apr 27, 2009, at 12:18 PM, james woodyatt wrote: > On Apr 20, 2009, at 07:36, Iljitsch van Beijnum wrote: >> >> On the other hand, SCTP includes address management that would >> probably fail in the presence of protocol translation. > > > Thinking about this some, I don't see why it should fail. As long > as the NAT64/DNS64 function operates properly, then SCTP should sail > along fine without caring what network layer is carrying its packets > in which address realms. > > > -- > james woodyatt > member of technical staff, communications engineering > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From Michael.Tuexen@lurchi.franken.de Sun May 3 13:12: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 9FB673A6D76 for ; Sun, 3 May 2009 13:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.374 X-Spam-Level: * X-Spam-Status: No, score=1.374 tagged_above=-999 required=5 tests=[AWL=-0.664, 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 RAkDXgTDM7cT for ; Sun, 3 May 2009 13:12:18 -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 A24923A6CC7 for ; Sun, 3 May 2009 13:11:55 -0700 (PDT) Received: from [192.168.1.194] (p508FFE3D.dip.t-dialin.net [80.143.254.61]) by mail-n.franken.de (Postfix) with ESMTP id 32FE81C0B4629; Sun, 3 May 2009 22:13:17 +0200 (CEST) Message-Id: <450DA87F-0C24-4940-A84D-44056DA727EF@lurchi.franken.de> From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Fred Baker In-Reply-To: <956E26DC-D729-4C2F-A56F-288843099146@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.4) Date: Sun, 3 May 2009 22:13:21 +0200 References: <0e0f01c9c9c9$f94e7d90$c5f0200a@cisco.com> <956E26DC-D729-4C2F-A56F-288843099146@cisco.com> X-Mailer: Apple Mail (2.930.4) Cc: Behave WG , Behave Chairs Subject: Re: [BEHAVE] working group status update X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 03 May 2009 20:12:19 -0000 Hi Fred, draft-ietf-tsvwg-port-randomization is not a problem for SCTP, since it talks about choosing the port for an transport layer endpoint. If middleboxes change the port number, it breaks SCTP in multihoming scenarios, since the port number is not per path, but per end-point. If you are using multiple paths and you have NAT boxes on the different paths changing the port number, they all need to do the same change! This requires therefore the synchronization of all these NAT boxes, which is very hard (I would even say impossible) to achieve. Therefore the NAT solution we propose does not change the port number. So the solutions described below which change the port number will *NOT* be able to support multihomed SCTP associations. Best regards Michael On May 2, 2009, at 12:31 AM, Fred Baker wrote: > > On Apr 30, 2009, at 12:29 PM, Dan Wing wrote: > >> * no update on SCTPNAT. > > by which I assume you mean: > http://tools.ietf.org/html/draft-ietf-behave-sctpnat > "Stream Control Transmission Protocol (SCTP) Network Address > Translation", > Randall Stewart, Michael Tuexen, Irene Ruengeler, 16-Feb-09, > > > Something the working group might want to wonder about... > > We have recently seen several drafts that talk about using port > numbers to differentiate among multiple systems using the same IP > address. The different systems get different port ranges. > > http://tools.ietf.org/html/draft-bajko-v6ops-port-restricted-ipaddr-assign > "Port Restricted IP Address Assignment", Gabor Bajko, Teemu > Savolainen, > 3-Nov-08, > > http://tools.ietf.org/html/draft-boucadair-dhc-port-range > "DHCP Options for Conveying Port Mask and Port Range Router IP > Address", > Mohammed Boucadair, Jean-Luc Grimault, Pierre Levis, Alain > Villefranque, > 29-Oct-08, > > http://tools.ietf.org/html/draft-boucadair-port-range > "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion", > Mohammed Boucadair, Pierre Levis, Gabor Bajko, Teemu Savolainen, 30- > Jan-09, > > > http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization > "Port Randomization", Michael Larsen, Fernando Gont, 11-Mar-09, > > > As I understand the SCTP NAT draft, it has no problem with people > changing their addresses, but really hopes they won't change their > ports. How do these two lines of reasoning fit together? > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From Michael.Tuexen@lurchi.franken.de Sun May 3 13:14: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 3CCC13A6CB8 for ; Sun, 3 May 2009 13:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.54 X-Spam-Level: * X-Spam-Status: No, score=1.54 tagged_above=-999 required=5 tests=[AWL=-0.498, 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 PQMOadvZiUk9 for ; Sun, 3 May 2009 13:14:09 -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 0240D3A7115 for ; Sun, 3 May 2009 13:13:58 -0700 (PDT) Received: from [192.168.1.194] (p508FFE3D.dip.t-dialin.net [80.143.254.61]) by mail-n.franken.de (Postfix) with ESMTP id 0B7741C0B462B; Sun, 3 May 2009 22:15:20 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Fred Baker 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 v930.4) Date: Sun, 3 May 2009 22:15:25 +0200 References: <7EA10A3F-BE9C-4A46-8F0F-D409C2EF17C1@muada.com> <49EC8105.80206@network-heretics.com> <593C802D-1216-4799-BB45-CDF68607A1B5@muada.com> X-Mailer: Apple Mail (2.930.4) Cc: "behave@ietf.org WG" Subject: Re: [BEHAVE] Comments on draft-baker-behave-v4v6-translation-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: Sun, 03 May 2009 20:14:16 -0000 Hi Fred, Hi James, Fred is right here: an SCTP end-point has exactly one port number. So if you have a multihomed SCTP association there can not be middleboxes changing the port number independently. That is why our NAT solution does not change the port number at all. Best regards Michael On May 3, 2009, at 9:59 PM, Fred Baker wrote: > yes. It only fails if people try changing ports. > > On Apr 27, 2009, at 12:18 PM, james woodyatt wrote: > >> On Apr 20, 2009, at 07:36, Iljitsch van Beijnum wrote: >>> >>> On the other hand, SCTP includes address management that would >>> probably fail in the presence of protocol translation. >> >> >> Thinking about this some, I don't see why it should fail. As long >> as the NAT64/DNS64 function operates properly, then SCTP should >> sail along fine without caring what network layer is carrying its >> packets in which address realms. >> >> >> -- >> james woodyatt >> member of technical staff, communications engineering >> >> >> _______________________________________________ >> 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 fluffy@cisco.com Sun May 3 18:07: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 1AF1D3A6AB3 for ; Sun, 3 May 2009 18:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.773 X-Spam-Level: X-Spam-Status: No, score=-105.773 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_PROLOSTOCK_SYM3=1.63, 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 yspc39gPRXaE for ; Sun, 3 May 2009 18:07:13 -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 3550E3A6EF2 for ; Sun, 3 May 2009 18:07:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,288,1238976000"; d="scan'208";a="180204519" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 May 2009 01:08:34 +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 n4418YDx016808; Sun, 3 May 2009 18:08:34 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4418Xni001396; Mon, 4 May 2009 01:08:34 GMT From: Cullen Jennings To: Iljitsch van Beijnum In-Reply-To: <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> Message-Id: <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 19:08:33 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=959; t=1241399314; x=1242263314; 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=20[BEHAVE]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=XIsMVg5E8KNUATxpP18A7yKmzdXVtLEs9yTr8QLWsTQ=; b=E/YNOkxgnAAYFqwUnVguwP/6GlWx7IYoQlnpAb+paoDlx9njGFEBn3fLC+ bZMrF5Z79haRTksz5Jsq3QiezJ2LxqTyPpbNWn0EWygh/r4x7Ey8WW6C5gg4 KUb8XLxElT; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Behave WG Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 01:07:14 -0000 I'm a little confused on how a v6 client, going though a nat64, to a v4 server that supports ESPV, is going to work. I was under the impression that it did not work and we needed to add a XSPV comment (Extra Extended Passive Mode) On May 3, 2009, at 1:45 PM, Iljitsch van Beijnum wrote: > On 3 mei 2009, at 20:16, Cullen Jennings wrote: > >> I rather see us do things along the lines of EPSV to fix FTP >> instead of putting an ALG in the NAT. > > Would an informational document that explains the following be > reasonable? > > 1. That server operators should support EPSV over IPv4 > 2. That clients should use EPSV rather than EPRT > 3. What an FTP ALG should do in the case !(1 && 2) > > This would give implementers who feel they need to offer an FTP ALG > (which I'm sure will be most of them) guidance without explicitly > endorsing ALGs and may get (some) client/server vendors and > operators to upgrade. From iljitsch@muada.com Mon May 4 00:00: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 E3C743A6A60 for ; Mon, 4 May 2009 00:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MANGLED_COST=2.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 1DcLCJVRyuA8 for ; Mon, 4 May 2009 00:00:35 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 1810F28C0D9 for ; Mon, 4 May 2009 00:00:25 -0700 (PDT) Received: from [192.168.2.4] (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 n4470F3k077261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 May 2009 09:00:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Cullen Jennings In-Reply-To: <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 09:00:13 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: Behave WG Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 07:00:44 -0000 On 4 mei 2009, at 3:08, Cullen Jennings wrote: > I'm a little confused on how a v6 client, going though a nat64, to a > v4 server that supports ESPV, is going to work. I was under the > impression that it did not work and we needed to add a XSPV comment > (Extra Extended Passive Mode) Unfortunately I don't have access to a NAT64 (I guess I could try with TRT if I really want) but here's a tcpdump of doing this over v4. EPSV command on control channel: 08:52:20.597609 IP 192.168.2.4.57044 > 192.87.102.42.ftp: P 35:41(6) ack 732 win 65535 0x0000: 4510 003a 3e72 4000 4006 130e c0a8 0204 E..:>r@.@....... 0x0010: c057 662a ded4 0015 7797 130e cee0 f60d .Wf*....w....... 0x0020: 8018 ffff 2d57 0000 0101 080a 2f68 042c ....-W....../h., 0x0030: 6110 f756 4550 5356 0d0a a..VEPSV.. Server gives us port 63483, note that there is no address mentioned: 08:52:20.796189 IP 192.87.102.42.ftp > 192.168.2.4.57044: P 732:780(48) ack 41 win 46 0x0000: 4500 0064 1910 4000 2d06 4b56 c057 662a E..d..@.-.KV.Wf* 0x0010: c0a8 0204 0015 ded4 cee0 f60d 7797 1314 ............w... 0x0020: 8018 002e 7cca 0000 0101 080a 6111 2eda ....|.......a... 0x0030: 2f68 042c 3232 3920 456e 7465 7269 6e67 /h.,229.Entering 0x0040: 2045 7874 656e 6465 6420 5061 7373 6976 .Extended.Passiv 0x0050: 6520 4d6f 6465 2028 7c7c 7c36 3334 3833 e.Mode.(|||63483 0x0060: 7c29 0d0a |).. 08:52:20.796267 IP 192.168.2.4.57044 > 192.87.102.42.ftp: . ack 780 win 65535 0x0000: 4510 0034 957d 4000 4006 bc08 c0a8 0204 E..4.}@.@....... 0x0010: c057 662a ded4 0015 7797 1314 cee0 f63d .Wf*....w......= 0x0020: 8010 ffff 9b5a 0000 0101 080a 2f68 042d .....Z....../h.- 0x0030: 6111 2eda a... Client opens a new session towards port 63483 on the server: 08:52:20.796621 IP 192.168.2.4.57045 > 192.87.102.42.63483: S 973991351:973991351(0) win 65535 0x0000: 4500 0040 b87e 4000 4006 990b c0a8 0204 E..@.~@.@....... 0x0010: c057 662a ded5 f7fb 3a0d edb7 0000 0000 .Wf*....:....... 0x0020: b002 ffff 1ba6 0000 0204 05b4 0103 0302 ................ 0x0030: 0101 080a 2f68 042d 0000 0000 0402 0000 ..../h.-........ 08:52:21.221670 IP 192.87.102.42.63483 > 192.168.2.4.57045: S 3496582725:3496582725(0) ack 973991352 win 5792 0x0000: 4500 003c 0000 4000 2d06 648e c057 662a E..<..@.-.d..Wf* 0x0010: c0a8 0204 f7fb ded5 d069 9e45 3a0d edb8 .........i.E:... 0x0020: a012 16a0 1683 0000 0204 05b4 0402 080a ................ 0x0030: 6111 2fb1 2f68 042d 0103 0307 a././h.-.... 08:52:21.221749 IP 192.168.2.4.57045 > 192.87.102.42.63483: . ack 1 win 65535 0x0000: 4500 0034 8e0d 4000 4006 c388 c0a8 0204 E..4..@.@....... 0x0010: c057 662a ded5 f7fb 3a0d edb8 d069 9e46 .Wf*....:....i.F 0x0020: 8010 ffff 5bea 0000 0101 080a 2f68 0432 ....[......./h.2 0x0030: 6111 2fb1 a./. LIST command on the control channel: 08:52:21.221842 IP 192.168.2.4.57044 > 192.87.102.42.ftp: P 41:47(6) ack 780 win 65535 0x0000: 4510 003a bb64 4000 4006 961b c0a8 0204 E..:.d@.@....... 0x0010: c057 662a ded4 0015 7797 1314 cee0 f63d .Wf*....w......= 0x0020: 8018 ffff ee9f 0000 0101 080a 2f68 0432 ............/h.2 0x0030: 6111 2eda 4c49 5354 0d0a a...LIST.. ACK on the control channel: 08:52:21.351310 IP 192.87.102.42.ftp > 192.168.2.4.57044: P 780:819(39) ack 47 win 46 0x0000: 4500 005b 1911 4000 2d06 4b5e c057 662a E..[..@.-.K^.Wf* 0x0010: c0a8 0204 0015 ded4 cee0 f63d 7797 131a ...........=w... 0x0020: 8018 002e 83a6 0000 0101 080a 6111 3108 ............a.1. 0x0030: 2f68 0432 3135 3020 4865 7265 2063 6f6d /h.2150.Here.com 0x0040: 6573 2074 6865 2064 6972 6563 746f 7279 es.the.directory 0x0050: 206c 6973 7469 6e67 2e0d 0a .listing... 08:52:21.351386 IP 192.168.2.4.57044 > 192.87.102.42.ftp: . ack 819 win 65535 0x0000: 4510 0034 0139 4000 4006 504d c0a8 0204 E..4.9@.@.PM.... 0x0010: c057 662a ded4 0015 7797 131a cee0 f664 .Wf*....w......d 0x0020: 8010 ffff 98f9 0000 0101 080a 2f68 0433 ............/h.3 0x0030: 6111 3108 a.1. Server sends data on the port 63483 session: 08:52:21.352057 IP 192.87.102.42.63483 > 192.168.2.4.57045: P 1:383(382) ack 1 win 46 0x0000: 4500 01b2 af41 4000 2d06 b3d6 c057 662a E....A@.-....Wf* 0x0010: c0a8 0204 f7fb ded5 d069 9e46 3a0d edb8 .........i.F:... 0x0020: 8018 002e d646 0000 0101 080a 6111 3109 .....F......a.1. 0x0030: 2f68 0432 6c72 7778 7277 7872 7778 2020 /h.2lrwxrwxrwx.. 0x0040: 2020 3120 3020 2020 2020 2020 2035 3039 ..1.0........509 0x0050: 2020 2020 2020 2020 2020 2020 2031 204e .............1.N 0x0060: 6f76 2030 3820 2032 3030 3720 6674 7020 ov.08..2007.ftp. 0x0070: 2d3e 202e 0d0a 6c72 7778 7277 7872 7778 ->....lrwxrwxrwx 0x0080: 2020 2020 3120 3020 2020 2020 2020 2030 ....1.0........0 0x0090: 2020 2020 2020 2020 2020 2020 2020 2033 ...............3 0x00a0: 204f 6374 2031 3220 2032 3030 3720 6d69 .Oct.12..2007.mi 0x00b0: 7272 6f72 202d 3e20 7075 620d 0a6c 7277 rror.->.pub..lrw 0x00c0: 7872 7778 7277 7820 2020 2031 2030 2020 xrwxrwx....1.0.. [...] 08:52:21.352842 IP 192.168.2.4.57045 > 192.87.102.42.63483: F 1:1(0) ack 384 win 65535 0x0000: 4508 0034 c545 4000 4006 8c48 c0a8 0204 E..4.E@.@..H.... 0x0010: c057 662a ded5 f7fb 3a0d edb8 d069 9fc5 .Wf*....:....i.. 0x0020: 8011 ffff 5911 0000 0101 080a 2f68 0433 ....Y......./h.3 0x0030: 6111 3109 a.1. On the control channel, the server says it's done with sending 08:52:21.406775 IP 192.87.102.42.ftp > 192.168.2.4.57044: P 819:843(24) ack 47 win 46 0x0000: 4500 004c 1912 4000 2d06 4b6c c057 662a E..L..@.-.Kl.Wf* 0x0010: c0a8 0204 0015 ded4 cee0 f664 7797 131a ...........dw... 0x0020: 8018 002e d2ff 0000 0101 080a 6111 313b ............a.1; 0x0030: 2f68 0432 3232 3620 4469 7265 6374 6f72 /h.2226.Director 0x0040: 7920 7365 6e64 204f 4b2e 0d0a y.send.OK... As you can see, nothing here that wouldn't work through an IPv6->IPv4 translator. From Remi.Denis-Courmont@nokia.com Mon May 4 00:14: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 A30703A690B for ; Mon, 4 May 2009 00:14:37 -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=[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 7DNgUJ0dXe+V for ; Mon, 4 May 2009 00:14:36 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 041983A6A60 for ; Mon, 4 May 2009 00:14:09 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n447F6SQ011117; Mon, 4 May 2009 10:15:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 10:15:28 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 10:15:27 +0300 Received: from leon.remlab.net (esdhcp035176.research.nokia.com [172.21.35.176]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n447FQWY017533; Mon, 4 May 2009 10:15:26 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: behave@ietf.org Date: Mon, 4 May 2009 10:16:12 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.28.9; KDE/4.2.2; i686; ; ) References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> In-Reply-To: <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905041016.12589.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 04 May 2009 07:15:28.0169 (UTC) FILETIME=[1A10B190:01C9CC88] X-Nokia-AV: Clean Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 07:14:37 -0000 Cullen, On Monday 04 May 2009 04:08:33 ext Cullen Jennings wrote: > I'm a little confused on how a v6 client, going though a nat64, to a > v4 server that supports ESPV, is going to work. I was under the > impression that it did not work and we needed to add a XSPV comment > (Extra Extended Passive Mode) No. Tomorrow's NAT64 is no different than today's NAT44 with respect to EPS= V.=20 EPSV only conveys the server-side port number in the control channel. I exp= ect=20 that NAT64 will not change server-side port numbers, but rather IP addresse= s=20 and client-side port numbers. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From fluffy@cisco.com Mon May 4 06:06: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 CA1B83A6A0B for ; Mon, 4 May 2009 06:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.434 X-Spam-Level: X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 4OaZszuDm48w for ; Mon, 4 May 2009 06:06:57 -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 CC2413A6A04 for ; Mon, 4 May 2009 06:06:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238976000"; d="scan'208";a="161495343" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 May 2009 13:08:23 +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 n44D8NSN005083; Mon, 4 May 2009 06:08:23 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n44D8MDv002511; Mon, 4 May 2009 13:08:23 GMT From: Cullen Jennings To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200905041016.12589.remi.denis-courmont@nokia.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> <200905041016.12589.remi.denis-courmont@nokia.com> Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 07:08:22 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=899; t=1241442503; x=1242306503; 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=20[BEHAVE]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=IJYLj5HsgkPnLNd66Q4rtEmUzEGO4VqhYUwYL3hzP58=; b=KTI86/qnHv8aI2yQbkcM8O9w9kM1B1aWnpbcA2qQaET3Xj/U0vwHNvdREK GL7C8VxWCzhgk7HhpcxvgyAm5h9v+rVeDz0f+hI8b0xhvlD3UkNKwR3t6Jyu DvM1NvYkrj; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 13:06:58 -0000 Thanks - I went and reread 2428 - I was confused and thought it only =20 applied to v6 clients. I see what you mean. On May 4, 2009, at 1:16 AM, R=E9mi Denis-Courmont wrote: > > Cullen, > > On Monday 04 May 2009 04:08:33 ext Cullen Jennings wrote: >> I'm a little confused on how a v6 client, going though a nat64, to a >> v4 server that supports ESPV, is going to work. I was under the >> impression that it did not work and we needed to add a XSPV comment >> (Extra Extended Passive Mode) > > No. Tomorrow's NAT64 is no different than today's NAT44 with respect =20= > to EPSV. > EPSV only conveys the server-side port number in the control =20 > channel. I expect > that NAT64 will not change server-side port numbers, but rather IP =20 > addresses > and client-side port numbers. > > --=20 > R=E9mi Denis-Courmont > Nokia Devices R&D, Maemo Software, Helsinki > From root@core3.amsl.com Mon May 4 06:45: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 E2B3F3A7015; Mon, 4 May 2009 06:45: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: <20090504134501.E2B3F3A7015@core3.amsl.com> Date: Mon, 4 May 2009 06:45:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Mon, 04 May 2009 13:45: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 : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations Author(s) : S. Perreault, J. Rosenberg Filename : draft-ietf-behave-turn-tcp-03.txt Pages : 13 Date : 2009-05-04 This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-tcp-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-tcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-04063708.I-D@ietf.org> --NextPart-- From simon.perreault@viagenie.ca Mon May 4 06:51: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 935FE3A6B10 for ; Mon, 4 May 2009 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.282, 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 TTonjt7WSHBL for ; Mon, 4 May 2009 06:51: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 51A4C3A6ADC for ; Mon, 4 May 2009 06:50:53 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 1F3F929E15BA; Mon, 4 May 2009 09:52:17 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 1794929E1585 for ; Mon, 4 May 2009 09:52:17 -0400 (EDT) Message-ID: <49FEF310.1000205@viagenie.ca> Date: Mon, 04 May 2009 09:52:16 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: behave@ietf.org References: <20090504134501.E2B3F3A7015@core3.amsl.com> In-Reply-To: <20090504134501.E2B3F3A7015@core3.amsl.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Mon, 04 May 2009 13:51:41 -0000 Internet-Drafts@ietf.org wrote, on 04/05/09 09:45 AM: > Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations > Author(s) : S. Perreault, J. Rosenberg > Filename : draft-ietf-behave-turn-tcp-03.txt > Pages : 13 > Date : 2009-05-04 Here's the change log: - Removed Listen and Connect limits. - Removed the Listen method since an allocation now listens by default. - Added a note to the effect that TURN-TCP does not keep data connections alive. - Added a small Security Considerations section (adapted from TURN-IPv6). - Updated references. - Picked numbers for attributes and responses. The diff is here: http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-behave-turn-tcp-03.txt All outstanding issues have been fixed. Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From petithug@acm.org Mon May 4 09:06: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 E9F5D3A6A19 for ; Mon, 4 May 2009 09:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.142 X-Spam-Level: X-Spam-Status: No, score=-102.142 tagged_above=-999 required=5 tests=[AWL=0.123, 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 YxHiWykDAYJM for ; Mon, 4 May 2009 09:06:51 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 4ACF23A686D for ; Mon, 4 May 2009 09:06:51 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id CC7456C98430; Mon, 4 May 2009 16:08:16 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 62FF36C98422 for ; Mon, 4 May 2009 16:08:16 +0000 (UTC) Message-ID: <49FF12E9.8000801@acm.org> Date: Mon, 04 May 2009 09:08:09 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: behave@ietf.org References: <20090504134501.E2B3F3A7015@core3.amsl.com> In-Reply-To: <20090504134501.E2B3F3A7015@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-tcp-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: Mon, 04 May 2009 16:06:52 -0000 Some comments and nits on turn-tcp-03: - Section 4.1, 4th paragraph: "are identical to those for TCP.": s/TCP/UDP/ - Section 4.3: There is nothing in the text about the authentication of the data connection. The data connection should be authenticated with the same username that was used for authenticating the control connection. - Section 4.3, 4th paragraph: "...and the response code was XXX...": s/XXX/447/ - Section 5.2, 2nd paragraph: "If the request is received on a control connection for which no allocation exists...": According to section 4.1, 5th paragraph, a TCP connection is called a control connection only after a success response for an allocation is received, so it is not possible to have a control connection for which no allocation exists. - Section 5.2, 5th paragraph: "If the connection attempts fails or times out, the server MUST return a XXX...": s/XXX/447/ - Section 5.2, 7th paragraph: I think that there should be some text advising against using the file descriptor from a Posix system directly in the CONNECTION-ID attribute, as they would be easily guessable. - Section 6.1: The method codepoints are already allocated to TURN UDP (Data, CreatePermission and ChannelBind). That make it impossible to write an interoperable implementation of this draft. Nits: - Section 2, 3rd paragraph: "It then returns the allocated port to the client in the resposne...": s/resposne/response/ - Section 4.3, 2nd paragraph: "When a response to the ConnectionBind request is recevied...": s/recevied/received/ -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From simon.perreault@viagenie.ca Mon May 4 09:24: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 CC3FF28C1B0 for ; Mon, 4 May 2009 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.259, 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 Qvgov3b+JbpF for ; Mon, 4 May 2009 09:24:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 316CB28C128 for ; Mon, 4 May 2009 09:24:11 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 6CE7629E15BC; Mon, 4 May 2009 12:25: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 60E6529E1585; Mon, 4 May 2009 12:25:36 -0400 (EDT) Message-ID: <49FF1700.3080106@viagenie.ca> Date: Mon, 04 May 2009 12:25:36 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Marc Petit-Huguenin References: <20090504134501.E2B3F3A7015@core3.amsl.com> <49FF12E9.8000801@acm.org> In-Reply-To: <49FF12E9.8000801@acm.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Mon, 04 May 2009 16:24:12 -0000 Marc Petit-Huguenin wrote, on 04/05/09 12:08 PM: > - Section 4.1, 4th paragraph: "are identical to those for TCP.": > > s/TCP/UDP/ Thanks, fixed. > - Section 4.3: > > There is nothing in the text about the authentication of the data > connection. The data connection should be authenticated with the > same username that was used for authenticating the control connection. Right. How about the following text: "Authentication of the client by the server MUST use the same method and credentials as for the control connection." I also added it to section 4.4. > - Section 4.3, 4th paragraph: "...and the response code was XXX...": > > s/XXX/447/ Thanks, fixed. > - Section 5.2, 2nd paragraph: "If the request is received on a > control connection for which no allocation exists...": > > According to section 4.1, 5th paragraph, a TCP connection is called > a control connection only after a success response for an allocation > is received, so it is not possible to have a control connection for > which no allocation exists. Right. In this case I think it's better to be explicit so I'll s/control connection/TCP connection/. > - Section 5.2, 5th paragraph: "If the connection attempts fails or > times out, the server MUST return a XXX...": > > s/XXX/447/ Thanks, fixed. > - Section 5.2, 7th paragraph: > > I think that there should be some text advising against using the > file descriptor from a Posix system directly in the CONNECTION-ID > attribute, as they would be easily guessable. Why is this a problem if we're authenticating the data connection? > - Section 6.1: > > The method codepoints are already allocated to TURN UDP (Data, > CreatePermission and ChannelBind). That make it impossible to write > an interoperable implementation of this draft. Too much copy-paste... I replaced that with 0xA, B, C. Ok? > Nits: Thanks, fixed. Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From petithug@acm.org Mon May 4 09:45: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 C6CBD28C15F for ; Mon, 4 May 2009 09:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=0.120, 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 LYfhizBxD+6v for ; Mon, 4 May 2009 09:45:21 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 1D48B3A6F1F for ; Mon, 4 May 2009 09:45:21 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 1FBEB6C98438; Mon, 4 May 2009 16:46:47 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id BCAA96C9842A; Mon, 4 May 2009 16:46:46 +0000 (UTC) Message-ID: <49FF1BF6.1090707@acm.org> Date: Mon, 04 May 2009 09:46:46 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Simon Perreault References: <20090504134501.E2B3F3A7015@core3.amsl.com> <49FF12E9.8000801@acm.org> <49FF1700.3080106@viagenie.ca> In-Reply-To: <49FF1700.3080106@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Mon, 04 May 2009 16:45:21 -0000 Simon Perreault wrote: > Marc Petit-Huguenin wrote, on 04/05/09 12:08 PM: [...] >> - Section 4.3: >> >> There is nothing in the text about the authentication of the data >> connection. The data connection should be authenticated with the >> same username that was used for authenticating the control connection. > > Right. How about the following text: > > "Authentication of the client by the server MUST use the same method and > credentials as for the control connection." > > I also added it to section 4.4. > OK. [...] >> - Section 5.2, 7th paragraph: >> >> I think that there should be some text advising against using the >> file descriptor from a Posix system directly in the CONNECTION-ID >> attribute, as they would be easily guessable. > > Why is this a problem if we're authenticating the data connection? If the data connection is authenticated then there is no problem (but IANASE - I am not a security expert). I put this in here because it was not clear yet that the data connection was to be authenticated. > >> - Section 6.1: >> >> The method codepoints are already allocated to TURN UDP (Data, >> CreatePermission and ChannelBind). That make it impossible to write >> an interoperable implementation of this draft. > > Too much copy-paste... I replaced that with 0xA, B, C. Ok? AFAIK, they are not allocated yet. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From remi.despres@free.fr Mon May 4 09:53: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 783D53A694E for ; Mon, 4 May 2009 09:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSkbgI0sSy0s for ; Mon, 4 May 2009 09:53:28 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5F1E13A6358 for ; Mon, 4 May 2009 09:53:26 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2413ED4822C; Mon, 4 May 2009 18:54:46 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9E2E4D48092; Mon, 4 May 2009 18:54:43 +0200 (CEST) Message-ID: <49FF1DD0.4000600@free.fr> Date: Mon, 04 May 2009 18:54:40 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Fred Baker , Marcello Bagnulo Braun , Iljitsch van Beijnum , Dan Wing , Keith Moore , Behave WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 16:53:29 -0000 Fred, Marcello, Iljitsch, Dan, Keith We have exchanged various mails recently concerning the relationship between IPv6-only hosts, NAT64, DNSsec. After one more simplification (DNS64 discarding mapped-address AAAAs rather than translating them), here is an updated proposal. The objective is that: O1: If an IPv6-only client that performs DNSsec validation wishes to establish connections with an IPv4-only server whose address is DNSsec signed (in both its A and mapped-address AAAA formats), it should eventually be able to receive the signed AAAA so that it can validate it. O2: If an IPv6-only client that doesn't perform DNSsec validation receives, for an IPv4-only server, both a DNS64 synthesized AAAA and a mapped-address AAAA, it should use the synthetic AAAA as an effect of the existing longest match rule. O3: If a dual stack host (with both IPv6 and IPv4 enabled so that it really acts as dual stack) receives, for an IPv4-only server, both an A and a mapped-address AAAA, it should communicate in IPv4 as an effect of existing preferences (for IPv6 addresses over IPv4 addresses if both are available, and for the IPv4 stack over the IPv6 stack if the destination address is an IPv4 mapped address - according to RFCs 3484 and RFC 2553 respectively). Rules proposed to reach the objective are as follows: (1) IN THE SHORT TERM: R1: DNS64s MUST silently discard mapped-address AAAAs they receive. R2: At the first (non urgent) opportunity, dual stack OSes that don't act as follows, MUST be updated to do it: (a) If IPv4 is enabled, datagrams presented at the socket interface with an IPv4 mapped-address as destination MUST be sent in IPv4 (RFC 2553 sec 3.7) (b) If IPv4 is not enabled, these datagrams MUST be sent in IPv6. (Relinquishment of an old but unjustified taboo which seems to have prevented some OSes to act this way.) (2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY WITH R2 (no urgency) R3: IPv4-only hosts MAY start advertising mapped-address AAAAs in their DNS servers (in addition to As). R4: Independently, DNS64s MAY start to forward mapped-address AAAAs (either all of them for simplicity or, if more selectively, ensuring that all those that are DNSsec signed are indeed forwarded). In my understanding, these (simple) rules are sufficient to eventually reconcile NAT64s with DNSsec in IPv6-only hosts. And they are so far the only ones I know for this. If the analysis is right, advices on how to proceed would be welcome. (A possibility would be to add appropriate sentences in draft-baker-behave-v4v6-framework and draft-bagnulo-behave-dns64.) If the analysis is wrong, it's IMHO worth understanding where. Regards, RD PS: apologies to addressees for the retransmission. I had forgotten the copy to th emailing list. From remi.despres@free.fr Mon May 4 10:14: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 8B9C93A6DA5 for ; Mon, 4 May 2009 10:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.284, 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 3LMU9L8EaHXS for ; Mon, 4 May 2009 10:14:36 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 7345C3A70AA for ; Mon, 4 May 2009 10:14:34 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id E61604C81EE; Mon, 4 May 2009 19:15:54 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g21.free.fr (Postfix) with ESMTP id 53C7E4C8155; Mon, 4 May 2009 19:15:49 +0200 (CEST) Message-ID: <49FF22C1.6080100@free.fr> Date: Mon, 04 May 2009 19:15:45 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49FF06EE.1020608@free.fr> <49FF0888.1080703@it.uc3m.es> <49FF17F1.9020206@free.fr> <49FF1DEA.8070903@it.uc3m.es> In-Reply-To: <49FF1DEA.8070903@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: Behave WG , Fred Baker , Dan Wing , Keith Moore Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 17:14:37 -0000 marcelo bagnulo braun - le (m/j/a) 5/4/09 6:55 PM: > Rémi Després escribió: >> marcelo bagnulo braun - le (m/j/a) 5/4/09 5:23 PM: >>> Hi Remi, >>> >>> I must confess, i haven't been able to read the last emails about >>> this tread in the ml, but, it seems you are assuming that IPv6 only >>> hosts will publish AAAA RR with IPv4 mapped addresses in them? >> NO. >> It is IPv4-only host that, in a second phase, will publish their IPv4 >> addresses both in As and AAAAs. > right, this is what i meant, sorry > >>> could you sumarize what is the exact scenario you have in mind by >>> doing so? (if this was already very clear in the mails in the ml, >>> just tell me so and i will reply once i have managed to catch up) >> The target scenario is one where an IPv6-only client reaches an >> IPv4-only server (necessarily via NAT64s), and where it can validate >> that the AAAA it receives has been signed under the responsibility of >> the IPv4-only server (in its DNS server). >> > right, but the traget scenario assumes that the IPv4 only host has not > provisiones the NAT64 box. Right. It is a legacy IPv4 server in a legacy environment. > It just limits itself to publish the AAAA RR with the IPv4 mapped > addresses in it and it hopes the nat64 is available somehere else, is > this correct? Yes. The NAT64 has to be somewhere between the IPv6-only host and the IPv4 Internet. (Otherwise the client host should better be dual stack if it needs to reach IPv4-only servers.) RD From ajs@shinkuro.com Mon May 4 10:26: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 8508A3A6C6D for ; Mon, 4 May 2009 10:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 JpzupRPMRQUd for ; Mon, 4 May 2009 10:26:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id CACDB3A6966 for ; Mon, 4 May 2009 10:26:35 -0700 (PDT) Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BA6512FE960A for ; Mon, 4 May 2009 17:28:00 +0000 (UTC) Date: Mon, 4 May 2009 13:27:58 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090504172758.GE2068@shinkuro.com> References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 17:26:36 -0000 On Sun, May 03, 2009 at 09:45:00PM +0200, Iljitsch van Beijnum wrote: > Would an informational document that explains the following be > reasonable? > > 1. That server operators should support EPSV over IPv4 > 2. That clients should use EPSV rather than EPRT > 3. What an FTP ALG should do in the case !(1 && 2) I'm not opposed to that, FWIW. I think there's a difference between saying, "Here's how to do _x_," and, "We don't think you should _x_, but if you're going to anyway please do it like this." Indeed, the failure to do the latter is how we got so many bad NATs in the first place. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Mon May 4 10:40: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 F022C3A711F for ; Mon, 4 May 2009 10:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=-0.603, 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 C+EDmbwcH0wU for ; Mon, 4 May 2009 10:40:28 -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 02E3C3A6358 for ; Mon, 4 May 2009 10:40:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238976000"; d="scan'208";a="161631782" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 May 2009 17:41:54 +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 n44Hfs0h019386; Mon, 4 May 2009 10:41:54 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n44HfrgK001192; Mon, 4 May 2009 17:41:53 GMT From: "Dan Wing" To: "'Cullen Jennings'" , "'Iljitsch van Beijnum'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com><5DE14123-B1F7-4087-AC8B-43391649F664@muada.com> <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> Date: Mon, 4 May 2009 10:41:53 -0700 Message-ID: <05de01c9ccdf$9d016f20$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 In-Reply-To: <32BA70CB-2986-4B4D-B30F-63FBD8BC9FD6@cisco.com> Thread-Index: AcnMVN1dunTxqp6/Qf+DnhAQa3OMFAAiDHpg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2313; t=1241458914; x=1242322914; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=UIA+SZU1HVUor9j0R2minvMuWS0xYVd8xF9nnKzHgPE=; b=dHlSYHfSzVUYwxBlQT5KqeTk0wxVyIrERz494LHPD15l7yZcTBYPJ6Ci68 dT4yrbAj2sF9d8M7nFOH4llW/v34EVwb3E4SrVf1Enk8zsXc1Z4uAZ5F71gZ nICa/vw88k; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 04 May 2009 17:40:29 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Sunday, May 03, 2009 6:09 PM > To: Iljitsch van Beijnum > Cc: Behave WG > Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? > > > I'm a little confused on how a v6 client, going though a nat64, to a > v4 server that supports ESPV, is going to work. In response to the EPSV command the IPv4 FTP server only returns a port number. From RFC2428: The first two fields contained in the parenthesis MUST be blank. The third field MUST be the string representation of the TCP port number on which the server is listening for a data connection. The network protocol used by the data connection will be the same network protocol used by the control connection. In addition, the network address used to establish the data connection will be the same network address used for the control connection. An example response string follows: Entering Extended Passive Mode (|||6446|) so the IPv6-capable FTP client should be fine with receiving that -- it will connect to the same (synthetic) IPv6 address as the control channel which is listening on the indicated TCP port. -d > I was under the > impression that it did not work and we needed to add a XSPV comment > (Extra Extended Passive Mode) > > > On May 3, 2009, at 1:45 PM, Iljitsch van Beijnum wrote: > > > On 3 mei 2009, at 20:16, Cullen Jennings wrote: > > > >> I rather see us do things along the lines of EPSV to fix FTP > >> instead of putting an ALG in the NAT. > > > > Would an informational document that explains the following be > > reasonable? > > > > 1. That server operators should support EPSV over IPv4 > > 2. That clients should use EPSV rather than EPRT > > 3. What an FTP ALG should do in the case !(1 && 2) > > > > This would give implementers who feel they need to offer an > FTP ALG > > (which I'm sure will be most of them) guidance without explicitly > > endorsing ALGs and may get (some) client/server vendors and > > operators to upgrade. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From magnus.westerlund@ericsson.com Tue May 5 02:11: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 74EE03A6C53; Tue, 5 May 2009 02:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Zcf9+QKaJrt7; Tue, 5 May 2009 02:11:35 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CF7683A6A63; Tue, 5 May 2009 02:11:34 -0700 (PDT) X-AuditID: c1b4fb3e-b7b7aae000004a86-1b-4a00031bd68b Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 85.5F.19078.B13000A4; Tue, 5 May 2009 11:12:59 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 11:12:10 +0200 Received: from [153.88.49.237] ([153.88.49.237]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 May 2009 11:12:10 +0200 Message-ID: <4A0002E9.6080400@ericsson.com> Date: Tue, 05 May 2009 11:12:09 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Behave WG References: <20090310144414.B66263A6A6D@core3.amsl.com> <49D35739.7040008@ericsson.com> <49F96A1E.5020800@ericsson.com> In-Reply-To: <49F96A1E.5020800@ericsson.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 May 2009 09:12:10.0361 (UTC) FILETIME=[921C2690:01C9CD61] X-Brightmail-Tracker: AAAAAA== Cc: IESG IESG , ietf Subject: Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior 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: Tue, 05 May 2009 09:11:36 -0000 Hi, I got a comment regarding my statement below. I missed making it clear that this concerns what it possible to do using a single IP address on the client side, even if there are more possibilities if you have multiple ones. Magnus Westerlund skrev: > Hi, > > After having reviewed all the last call comments I like to make a > consensus call on this document. > > I think there is rough consensus for publication of this document given > that it is updated to make the following clear: > > - Make the applicability statement more clear on that any determination > is transient and may contain error requiring a user to have a fall back. > > - Make the proposed experiments clearer on how they can utilize the > mechanism. Especially the P2P needs to make clear why this could be > applicable given the limitations. > > - Make clear that the algorithms are proposals of what can be determined > using the STUN attributes and their behaviors using a single IP address on the client side. Additional determinations > are possible. > -- Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From petithug@acm.org Tue May 5 12:08: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 E6AF33A712F for ; Tue, 5 May 2009 12:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[AWL=0.118, 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 9Ir-hEPUbPVq for ; Tue, 5 May 2009 12:08:25 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 530143A6DF7 for ; Tue, 5 May 2009 12:08:25 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 2A4BEDDC400A; Tue, 5 May 2009 19:09:52 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id C40AADDC4008 for ; Tue, 5 May 2009 19:09:51 +0000 (UTC) Message-ID: <4A008EFE.2090106@acm.org> Date: Tue, 05 May 2009 12:09:50 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Behave WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Transport protocols in TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 05 May 2009 19:08:26 -0000 I cannot find in turn-14 what transport protocols are mandatory to implement. Only one sentence in a non-normative section would implies that the rules are the same than RFC 5389 (UDP and TCP mandatory, TLS optional): Section 2.1, 5th paragraph: "TURN does not require TLS because..." I think that there should be some normative text about this. Thanks. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From xuxh@huawei.com Wed May 6 02:42: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 C4B733A6AC4 for ; Wed, 6 May 2009 02:42:31 -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.437, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgxE2ShhN2j5 for ; Wed, 6 May 2009 02:42:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 934523A6809 for ; Wed, 6 May 2009 02:42:15 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ7000OKV0JIZ@szxga04-in.huawei.com> for behave@ietf.org; Wed, 06 May 2009 17:43:31 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ7001YBV0HF8@szxga04-in.huawei.com> for behave@ietf.org; Wed, 06 May 2009 17:43:30 +0800 (CST) Date: Wed, 06 May 2009 17:43:29 +0800 From: Xu Xiaohu In-reply-to: <49FF1DD0.4000600@free.fr> To: =?ISO-8859-1?Q?'R=E9mi_Despr=E9s'?= , 'Fred Baker' , 'Marcello Bagnulo Braun' , 'Iljitsch van Beijnum' , 'Dan Wing' , 'Keith Moore' , 'Behave WG' Message-id: <001301c9ce2f$1cd07ca0$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=ISO-8859-1 Content-transfer-encoding: 7BIT Thread-index: AcnM2RPdv64rQu9vQquw6E1JTt5VWABVEdgw Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 09:42:31 -0000 > O3: If a dual stack host (with both IPv6 and IPv4 enabled so > that it really acts as dual stack) receives, for an IPv4-only > server, both an A and a mapped-address AAAA, it should > communicate in IPv4 as an effect of existing preferences (for > IPv6 addresses over IPv4 addresses if both are available, and > for the IPv4 stack over the IPv6 stack if the destination > address is an IPv4 mapped address - according to RFCs 3484 > and RFC 2553 respectively). Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only hosts and dual-stack hosts wihin an IPv6 network is also a scenario in which it's better to allow the hosts, especially those IPv6 only hosts to learn the prefix64 and synthesize the IPv6 addresses for destination IPv4 hosts on demands, rather than depending on the DNS64 to synthesize AAAA records from A records no matter the client is IPv6 only or dual stack.Make sense? Xiaohu > Rules proposed to reach the objective are as follows: > > (1) IN THE SHORT TERM: > > R1: DNS64s MUST silently discard mapped-address AAAAs they receive. > > R2: At the first (non urgent) opportunity, dual stack OSes > that don't act as follows, MUST be updated to do it: > (a) If IPv4 is enabled, datagrams presented at the socket > interface with an IPv4 mapped-address as destination MUST be > sent in IPv4 (RFC 2553 sec > 3.7) > (b) If IPv4 is not enabled, these datagrams MUST be sent in IPv6. > (Relinquishment of an old but unjustified taboo which seems > to have prevented some OSes to act this way.) > > > (2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY WITH R2 (no > urgency) > > R3: IPv4-only hosts MAY start advertising mapped-address > AAAAs in their DNS servers (in addition to As). > > R4: Independently, DNS64s MAY start to forward mapped-address > AAAAs (either all of them for simplicity or, if more > selectively, ensuring that all those that are DNSsec signed > are indeed forwarded). > > > > In my understanding, these (simple) rules are sufficient to > eventually reconcile NAT64s with DNSsec in IPv6-only hosts. > And they are so far the only ones I know for this. > > If the analysis is right, advices on how to proceed would be > welcome. (A possibility would be to add appropriate sentences > in draft-baker-behave-v4v6-framework and draft-bagnulo-behave-dns64.) > > If the analysis is wrong, it's IMHO worth understanding where. > > > Regards, > > RD > > PS: apologies to addressees for the retransmission. I had > forgotten the copy to th emailing list. > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From xuxh@huawei.com Wed May 6 02:52: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 EA65B3A6B98 for ; Wed, 6 May 2009 02:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.797 X-Spam-Level: * X-Spam-Status: No, score=1.797 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7wu-A1KwLQh for ; Wed, 6 May 2009 02:52:36 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 1618D3A6DB1 for ; Wed, 6 May 2009 02:52:30 -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 <0KJ700LERVHUQC@szxga02-in.huawei.com> for behave@ietf.org; Wed, 06 May 2009 17:53:55 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ7006IUVHTIN@szxga02-in.huawei.com> for behave@ietf.org; Wed, 06 May 2009 17:53:54 +0800 (CST) Date: Wed, 06 May 2009 17:53:53 +0800 From: Xu Xiaohu In-reply-to: <001301c9ce2f$1cd07ca0$5e0c6f0a@china.huawei.com> To: =?gb2312?B?J1Kopm1pIERlc3ByqKZzJw==?= , 'Fred Baker' , 'Marcello Bagnulo Braun' , 'Iljitsch van Beijnum' , 'Dan Wing' , 'Keith Moore' , 'Behave WG' Message-id: <001401c9ce30$9105ac70$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=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcnM2RPdv64rQu9vQquw6E1JTt5VWABVEdgwAACyAEA= Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 09:52:43 -0000 Sorry, there was a mistake in the previous email, please see the = corrected text. Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only = hosts and dual-stack hosts wihin an IPv6 network is also a scenario in which = it's better to allow the hosts, especially those DUAL-STACK hosts to learn = the prefix64 and synthesize the IPv6 addresses for destination IPv4 hosts on demands, rather than depending on the DNS64 to synthesize AAAA records = from A records no matter the client is IPv6 only or dual-stack.Make sense? Xiaohu =20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org]=20 > =B4=FA=B1=ED Xu Xiaohu > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA5=D4=C26=C8=D5 17:43 > =CA=D5=BC=FE=C8=CB: 'R=A8=A6mi Despr=A8=A6s'; 'Fred Baker'; 'Marcello = Bagnulo Braun';=20 > 'Iljitsch van Beijnum'; 'Dan Wing'; 'Keith Moore'; 'Behave WG' > =D6=F7=CC=E2: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding=20 > mapped AAAAs inDNS64 >=20 >=20 >=20 > > O3: If a dual stack host (with both IPv6 and IPv4 enabled=20 > so that it=20 > > really acts as dual stack) receives, for an IPv4-only=20 > server, both an=20 > > A and a mapped-address AAAA, it should communicate in IPv4 as an=20 > > effect of existing preferences (for > > IPv6 addresses over IPv4 addresses if both are available,=20 > and for the=20 > > IPv4 stack over the IPv6 stack if the destination address=20 > is an IPv4=20 > > mapped address - according to RFCs 3484 and RFC 2553 respectively). >=20 > Except of the DNSSEC and P2P scenarios, the coexistance of=20 > IPv6-only hosts and dual-stack hosts wihin an IPv6 network is=20 > also a scenario in which it's better to allow the hosts,=20 > especially those IPv6 only hosts to learn the > prefix64 and synthesize the IPv6 addresses for destination=20 > IPv4 hosts on demands, rather than depending on the DNS64 to=20 > synthesize AAAA records from A records no matter the client=20 > is IPv6 only or dual stack.Make sense? >=20 > Xiaohu >=20 > > Rules proposed to reach the objective are as follows: > >=20 > > (1) IN THE SHORT TERM: > >=20 > > R1: DNS64s MUST silently discard mapped-address AAAAs they receive. > >=20 > > R2: At the first (non urgent) opportunity, dual stack OSes=20 > that don't=20 > > act as follows, MUST be updated to do it: > > (a) If IPv4 is enabled, datagrams presented at the socket interface=20 > > with an IPv4 mapped-address as destination MUST be sent in=20 > IPv4 (RFC=20 > > 2553 sec > > 3.7) > > (b) If IPv4 is not enabled, these datagrams MUST be sent in IPv6. > > (Relinquishment of an old but unjustified taboo which seems to have=20 > > prevented some OSes to act this way.) > >=20 > >=20 > > (2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY=20 > WITH R2 (no > > urgency) > >=20 > > R3: IPv4-only hosts MAY start advertising mapped-address AAAAs in=20 > > their DNS servers (in addition to As). > >=20 > > R4: Independently, DNS64s MAY start to forward mapped-address AAAAs=20 > > (either all of them for simplicity or, if more selectively,=20 > ensuring=20 > > that all those that are DNSsec signed are indeed forwarded). > >=20 > >=20 > >=20 > > In my understanding, these (simple) rules are sufficient to=20 > > eventually reconcile NAT64s with DNSsec in IPv6-only hosts.=20 > > And they are so far the only ones I know for this. > >=20 > > If the analysis is right, advices on how to proceed would be=20 > > welcome. (A possibility would be to add appropriate sentences=20 > > in draft-baker-behave-v4v6-framework and=20 > draft-bagnulo-behave-dns64.) > >=20 > > If the analysis is wrong, it's IMHO worth understanding where. > >=20 > >=20 > > Regards, > >=20 > > RD > >=20 > > PS: apologies to addressees for the retransmission. I had=20 > > forgotten the copy to th emailing list. > >=20 > >=20 > >=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 Wed May 6 06:04: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 0247B3A6AED for ; Wed, 6 May 2009 06:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtGxvMvkk8c7 for ; Wed, 6 May 2009 06:04:47 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 5C76F3A6CA6 for ; Wed, 6 May 2009 06:03:53 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 8314A4C80D5; Wed, 6 May 2009 15:05:13 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g21.free.fr (Postfix) with ESMTP id D85214C814B; Wed, 6 May 2009 15:05:10 +0200 (CEST) Message-ID: <4A018B03.6070601@free.fr> Date: Wed, 06 May 2009 15:05:07 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Xu Xiaohu References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> In-Reply-To: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Behave WG' , 'Keith Moore' , 'Fred Baker' , 'Dan Wing' Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 13:04:48 -0000 Xu Xiaohu - le (m/j/a) 5/6/09 11:53 AM: > Sorry, there was a mistake in the previous email, please see the > corrected text. > > Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only > hosts and dual-stack hosts wihin an IPv6 network is also a scenario > in which it's better to allow the hosts, especially those DUAL-STACK > hosts to learn the prefix64 and synthesize the IPv6 addresses for > destination IPv4 hosts on demands, rather than depending on the DNS64 > to synthesize AAAA records from A records no matter the client is > IPv6 only or dual-stack.Make sense? Yes, it makes sense to me. There should be IMHO one more constraint: - If prefix64 is not the mapped-address prefix, synthesis of AAAAs MUST be performed ONLY if no IPv4 address is locally enabled. (Otherwise, a dual-stack application in a dual-stack host that has an IPv4 address enabled may end up using IPv6 although IPv4 is possible and no NAT64 is available). In my understanding, the effect is that IPv6-only applications, if they are in dual-stack hosts having only IPv6 addresses can reach IPv4-only servers via NAT64s. What I propose concerns only hosts that are purely IPv6. (They cannot synthesize AAAAs from As because, being supposed not to query for As, they don't receive any). The new rule is then a complement which concerns dual stack hosts in IPv6 networks. Agreed? RD >>> Rules proposed to reach the objective are as follows: >>> >>> (1) IN THE SHORT TERM: >>> >>> R1: DNS64s MUST silently discard mapped-address AAAAs they >>> receive. >>> >>> R2: At the first (non urgent) opportunity, dual stack OSes >>> that don't act as follows, MUST be updated to do it: (a) If IPv4 is >>> enabled, datagrams presented at the socket interface with an IPv4 >>> mapped-address as destination MUST be sent in IPv4 (RFC 2553 sec >>> 3.7) (b) If IPv4 is not enabled, these datagrams MUST be sent in >>> IPv6. (Relinquishment of an old but unjustified taboo which >>> seems to have prevented some OSes to act this way.) >>> >>> >>> (2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY WITH R2 >>> (no urgency) >>> >>> R3: IPv4-only hosts MAY start advertising mapped-address AAAAs in >>> their DNS servers (in addition to As). >>> >>> R4: Independently, DNS64s MAY start to forward mapped-address >>> AAAAs (either all of them for simplicity or, if more selectively, >>> ensuring that all those that are DNSsec signed are indeed >>> forwarded). >>> >>> >>> >>> In my understanding, these (simple) rules are sufficient to >>> eventually reconcile NAT64s with DNSsec in IPv6-only hosts. And >>> they are so far the only ones I know for this. From Mark_Andrews@isc.org Wed May 6 14:13: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 2E4D33A6E9A for ; Wed, 6 May 2009 14:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 F4ijQrULCAe8 for ; Wed, 6 May 2009 14:12:59 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 384ED3A696A for ; Wed, 6 May 2009 14:12:59 -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 76FA7E601E; Wed, 6 May 2009 21:14: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 n46LEJk0065442; Thu, 7 May 2009 07:14:19 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200905062114.n46LEJk0065442@drugs.dv.isc.org> To: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= From: Mark Andrews In-reply-to: Your message of "Wed, 06 May 2009 15:05:07 +0200." <4A018B03.6070601@free.fr> Date: Thu, 07 May 2009 07:14:19 +1000 Sender: Mark_Andrews@isc.org Cc: 'Dan Wing' , 'Behave WG' , 'Keith Moore' , Xu Xiaohu , 'Fred Baker' Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 21:13:00 -0000 In message <4A018B03.6070601@free.fr>, =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= write s: > Xu Xiaohu - le (m/j/a) 5/6/09 11:53 AM: > > Sorry, there was a mistake in the previous email, please see the > > corrected text. > > > > Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only > > hosts and dual-stack hosts wihin an IPv6 network is also a scenario > > in which it's better to allow the hosts, especially those DUAL-STACK > > hosts to learn the prefix64 and synthesize the IPv6 addresses for > > destination IPv4 hosts on demands, rather than depending on the DNS64 > > to synthesize AAAA records from A records no matter the client is > > IPv6 only or dual-stack.Make sense? > > Yes, it makes sense to me. > > There should be IMHO one more constraint: > - If prefix64 is not the mapped-address prefix, synthesis of AAAAs MUST > be performed ONLY if no IPv4 address is locally enabled. > (Otherwise, a dual-stack application in a dual-stack host that has an > IPv4 address enabled may end up using IPv6 although IPv4 is possible and > no NAT64 is available). > > In my understanding, the effect is that IPv6-only applications, if they > are in dual-stack hosts having only IPv6 addresses can reach IPv4-only > servers via NAT64s. > > What I propose concerns only hosts that are purely IPv6. (They cannot > synthesize AAAAs from As because, being supposed not to query for As, > they don't receive any). The new rule is then a complement which > concerns dual stack hosts in IPv6 networks. Agreed? > > RD Not querying for A's on a IPv6 only host when there are no AAAA's is idiotic. The same is true in reverse. Lots of problems have been caused by that rule. You need to know whether a host exists or not *and* whether it is reachable or not. This is especially true when search lists are involved. You want the unqualified name to refer to the same machine whether you are IPv4 only, dual stack or IPv6 only. One could add MX and SRV (basename) to the list as well. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From brian.e.carpenter@gmail.com Wed May 6 14:33: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 5BD873A694E for ; Wed, 6 May 2009 14:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iImpiOOXcoK for ; Wed, 6 May 2009 14:33:14 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 7B49A3A68C2 for ; Wed, 6 May 2009 14:33:14 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so254183rvb.49 for ; Wed, 06 May 2009 14:34:40 -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=dAxHpYt4fFLLDDDn9lnzmkwQ4LUtNFdbv84t5KkB8TA=; b=hpriiW8FXhhKr0zSJ7V5KEMByX43ydFx90Q7LpdZbbgwkPnQx0+HS007Z8QK32i6Os rePKwV/j/3GPfi2J8fQk2DUJ2gQrC0wJKa3porpRfXOqTJBoFYnVFTJLbkoieB5noPJg JFF6uCIJMDn/l/zsluCXITGYHAGHTuWUS3D3Q= 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=YMurC1tfLEnhE1sSoZ9fctpQRhYExeyybs8zjnSga4nEHZyCkY3z/c6mlI+5BUhTsR fiwudmPtP/xtzZBkcKoRoLybr0j8wQzCQuGcfl8QbykKS1flu7OAfA1J7R8KrkQuTB4u rv9n3owx9+gFLD6cDWAgpsBXgD/ISZinMVjpw= Received: by 10.114.211.2 with SMTP id j2mr1730048wag.139.1241645680276; Wed, 06 May 2009 14:34:40 -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 f20sm13880672waf.52.2009.05.06.14.34.37 (version=SSLv3 cipher=RC4-MD5); Wed, 06 May 2009 14:34:39 -0700 (PDT) Message-ID: <4A020269.40200@gmail.com> Date: Thu, 07 May 2009 09:34:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Xu Xiaohu References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> In-Reply-To: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Behave WG' , 'Keith Moore' , 'Fred Baker' , 'Dan Wing' Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 21:33:15 -0000 On 2009-05-06 21:53, Xu Xiaohu wrote: > Sorry, there was a mistake in the previous email, please see the correc= ted > text. >=20 > Except of the DNSSEC and P2P scenarios, the coexistance of IPv6-only ho= sts > and dual-stack hosts wihin an IPv6 network is also a scenario in which = it's > better to allow the hosts, especially those DUAL-STACK hosts to learn t= he > prefix64 and synthesize the IPv6 addresses for destination IPv4 hosts o= n > demands, rather than depending on the DNS64 to synthesize AAAA records = from > A records no matter the client is IPv6 only or dual-stack.Make sense? Yes, but you're assuming that the IP stacks in the hosts can be modified from basic (RFC2460) behaviour. We certainly need to deal with hosts that only contain a standard resolver, so a DNS64 remains essential for that case. We discussed this in draft-van-beijnum-v6ops-mnat-pt last year, and I don't think the situation has changed much. Brian >=20 > Xiaohu > =20 >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: behave-bounces@ietf.org [mailto:behave-bo= unces@ietf.org]=20 >> =E4=BB=A3=E8=A1=A8 Xu Xiaohu >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2009=E5=B9=B45=E6=9C=886=E6=97=A5= 17:43 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'R=C3=A9mi Despr=C3=A9s'; 'Fred Baker'; '= Marcello Bagnulo Braun';=20 >> 'Iljitsch van Beijnum'; 'Dan Wing'; 'Keith Moore'; 'Behave WG' >> =E4=B8=BB=E9=A2=98: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discardin= g=20 >> mapped AAAAs inDNS64 >> >> >> >>> O3: If a dual stack host (with both IPv6 and IPv4 enabled=20 >> so that it=20 >>> really acts as dual stack) receives, for an IPv4-only=20 >> server, both an=20 >>> A and a mapped-address AAAA, it should communicate in IPv4 as an=20 >>> effect of existing preferences (for >>> IPv6 addresses over IPv4 addresses if both are available,=20 >> and for the=20 >>> IPv4 stack over the IPv6 stack if the destination address=20 >> is an IPv4=20 >>> mapped address - according to RFCs 3484 and RFC 2553 respectively). >> Except of the DNSSEC and P2P scenarios, the coexistance of=20 >> IPv6-only hosts and dual-stack hosts wihin an IPv6 network is=20 >> also a scenario in which it's better to allow the hosts,=20 >> especially those IPv6 only hosts to learn the >> prefix64 and synthesize the IPv6 addresses for destination=20 >> IPv4 hosts on demands, rather than depending on the DNS64 to=20 >> synthesize AAAA records from A records no matter the client=20 >> is IPv6 only or dual stack.Make sense? >> >> Xiaohu >> >>> Rules proposed to reach the objective are as follows: >>> >>> (1) IN THE SHORT TERM: >>> >>> R1: DNS64s MUST silently discard mapped-address AAAAs they receive. >>> >>> R2: At the first (non urgent) opportunity, dual stack OSes=20 >> that don't=20 >>> act as follows, MUST be updated to do it: >>> (a) If IPv4 is enabled, datagrams presented at the socket interface=20 >>> with an IPv4 mapped-address as destination MUST be sent in=20 >> IPv4 (RFC=20 >>> 2553 sec >>> 3.7) >>> (b) If IPv4 is not enabled, these datagrams MUST be sent in IPv6. >>> (Relinquishment of an old but unjustified taboo which seems to have=20 >>> prevented some OSes to act this way.) >>> >>> >>> (2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY=20 >> WITH R2 (no >>> urgency) >>> >>> R3: IPv4-only hosts MAY start advertising mapped-address AAAAs in=20 >>> their DNS servers (in addition to As). >>> >>> R4: Independently, DNS64s MAY start to forward mapped-address AAAAs=20 >>> (either all of them for simplicity or, if more selectively,=20 >> ensuring=20 >>> that all those that are DNSsec signed are indeed forwarded). >>> >>> >>> >>> In my understanding, these (simple) rules are sufficient to=20 >>> eventually reconcile NAT64s with DNSsec in IPv6-only hosts.=20 >>> And they are so far the only ones I know for this. >>> >>> If the analysis is right, advices on how to proceed would be=20 >>> welcome. (A possibility would be to add appropriate sentences=20 >>> in draft-baker-behave-v4v6-framework and=20 >> draft-bagnulo-behave-dns64.) >>> If the analysis is wrong, it's IMHO worth understanding where. >>> >>> >>> Regards, >>> >>> RD >>> >>> PS: apologies to addressees for the retransmission. I had=20 >>> forgotten the copy to th emailing list. >>> >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Wed May 6 15: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 9AAE33A6DA2 for ; Wed, 6 May 2009 15:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 Agr1mzQ96n3z for ; Wed, 6 May 2009 15:54:50 -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 CA25A3A6F3D for ; Wed, 6 May 2009 15:54:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,305,1238976000"; d="scan'208";a="299787889" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 May 2009 22:56:18 +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 n46MuI15025839; Wed, 6 May 2009 15:56:18 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n46MuHiG018654; Wed, 6 May 2009 22:56:18 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Behave WG'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> Date: Wed, 6 May 2009 15:56:16 -0700 Message-ID: <082801c9ce9d$ddd215d0$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: AcnL+2ZIrDBXXoZvROe5bs5FJclnBgBGUQvw In-Reply-To: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2328; t=1241650578; x=1242514578; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=6N/TNwIp7sNCL1ZOLVaN8rWAXuHoFPLr+qGwBQi/L1o=; b=1j9kagipWpfAv/qoWixMXt6kLW05aU+sU7U1t1li0PPClAxV20JjiiK9fW bl/jq5hvYtwQ0DS8rcKrGl9FKeU7JAE+RjJJyr71uUG4ofeiA/Zgv6IDC6W0 H/aL7J+h+L; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 22:54:51 -0000 > I got some feedback from Barry Leiba and John Klensin about the FTP > ALG for IPv6-to-IPv4 translation. The comments don't really address > what's in the draft, but rather the idea of having an FTP ALG in the > first place. They really don't like it. John feels it's a > better idea to update clients and servers rather than put ALGs > in the middle. Without an FTP-ALG the IPv6 FTP client would need to support IPv4's PASV and would also need to know the IPv6 prefix of its IPv6 translator (draft-wing-behave-learn-prefix). There have been objections raised to doing that in the past, specifically that it puts too much IPv6/IPv4 interworking knowledge into the application: http://www.ietf.org/mail-archive/web/behave/current/msg04129.html "... I think the draft-jennings-behave-nat6 approach has the negative characteristic of importing NAT-related issues into IPv6-related code, and that is something we want to avoid if we can." Perhaps the winds have changed. I would certainly like to hear from everyone on this issue, as we are getting close to submitting an updated charter and updated milestones. Based on my tests about 34% of FTP sites do not support EPSV. When lucky, the lack of support causes an immediate 5xx response on the control channel. When unlucky, the lack of support causes a long delay and eventual failure to establish the data channel. My test used a list of anonymous FTP sites from 2003. From that list, I successfully did PASV directory listings with 2491 FTP servers. Of those, 1626 (65%) correctly handled EPSV; 865 (34%) did not support EPSV. My Perl code (which is not very good) and test results are at ftp://ftpeng.cisco.com/dwing/ftp-epsv. > I'm afraid they, and perhaps others, will speak > up during IETF last call. > The fact that the behave charter says to stay away from ALGs > probably won't help at that point. The charter does have an escape clause, "ALGs may be considered only for the most crucial of legacy applications." FTP certainly qualifies as a legacy application. It's a subjective decision if 28% of FTP sites are 'crucial', and subjective if requiring IPv6 FTP applications to support PASV and to learn the prefix of their IPv6 translator is better than an ALG. -d From iljitsch@muada.com Wed May 6 16:43: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 D73DB3A6EC1 for ; Wed, 6 May 2009 16:43:58 -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.703, 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 7SQrcyVL7C5t for ; Wed, 6 May 2009 16:43:58 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id C0B6A3A6EAA for ; Wed, 6 May 2009 16:43:57 -0700 (PDT) Received: from [192.168.2.4] (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 n46NivrY001472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 May 2009 01:44:59 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Dan Wing" In-Reply-To: <082801c9ce9d$ddd215d0$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 v930.3) Date: Thu, 7 May 2009 01:44:58 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <082801c9ce9d$ddd215d0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Behave WG' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 23:43:58 -0000 On 7 mei 2009, at 0:56, Dan Wing wrote: > Without an FTP-ALG the IPv6 FTP client would need to support IPv4's > PASV and > would also need to know the IPv6 prefix of its IPv6 translator > (draft-wing-behave-learn-prefix). There have been objections raised > to doing > that in the past, specifically that it puts too much IPv6/IPv4 > interworking > knowledge into the application: Right. So let's cheat. We already have a session towards the server, what if we simply assume that the address in the PASV response can be reached through the address we're using for the data channel? If we get to assume that the v4 address is always in the bottom 32 bits we can even accommodate the corner case where the control channel goes to one address and the data connection to another by plugging the 32 bits from the PASV response into the lower 32 bits and copying the upper 96 bits from the control channel destination. > When > unlucky, the lack of support causes a long delay and eventual > failure to > establish the data channel. Can you test again with the following: EPSV try to set up data channel if not successful within 5 seconds, time out and: send ABOR retry with PASV If that works, we have a procedure for clients to work with all FTP servers out there without requiring an ALG. (Did you check if any servers allowed you to log in but didn't handle PASV successfully?) In that case the question is: what's more reasonable, requiring everyone who wants to use FTP through a NAT64 or SIIT(bis) to upgrade their client software, or having an ALG. Note that a quick "java ftp client" search returns a good number of results. People could run such a client from their browser. From dwing@cisco.com Wed May 6 16:46: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 9911B3A6EEC for ; Wed, 6 May 2009 16:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 l7UGD07wYlGO for ; Wed, 6 May 2009 16:46:41 -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 ABEF53A6F3D for ; Wed, 6 May 2009 16:46:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,305,1238976000"; d="scan'208";a="299816582" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 May 2009 23:48:09 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n46Nm9Cr005859; Wed, 6 May 2009 16:48:09 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n46Nm83f009042; Wed, 6 May 2009 23:48:09 GMT From: "Dan Wing" To: "'Christian Huitema'" , "'Andrew Sullivan'" , References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com><20090503144333.GB2068@shinkuro.com><20090503154121.GC2068@shinkuro.com> <8EFB68EAE061884A8517F2A755E8B60A1CD848D628@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 6 May 2009 16:48:08 -0700 Message-ID: <083e01c9cea5$1c2285c0$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: AcnMBbuE2F7YgtQESJqEJqI4t5bb5AAA1PegAKWPv/A= In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A1CD848D628@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=997; t=1241653689; x=1242517689; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=r/1mEJGH89mpk9Toy38YERYNE3ipy/xHW7cDGX++7Ts=; b=N1ZWoLW2bDazV1GS/18UewnLdqNW4NSMPjFfhRkeMfWP44YMORiOn2JIZ/ 3nJbzP8tuGy2ccX+5kUaF7CrrcxiDGFZlFJDmQm+gMUS8PrIhiXA4PCSly09 hXpfH5dru7qEF13rwfujjcguihI0pHguNEPgXIaPTjLmc/h5E6h8o=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 06 May 2009 23:46:42 -0000 > -----Original Message----- > From: behave-bounces@ietf.org > [mailto:behave-bounces@ietf.org] On Behalf Of Christian Huitema > Sent: Sunday, May 03, 2009 9:09 AM > To: Andrew Sullivan; behave@ietf.org > Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? > > > > So you're in favor of option 1, no ALG? > > > > Yes. > > So am I. As Iljitsch mentioned, most FTP clients support the > EPSV mode already. Hopefully those clients send just plain "EPSV" and not "EPSV 2". I checked Firefox 3.5b4 (source is easy to get) and it does send plain "EPSV". -d > They have to, because they are bound to > encounter networks with no FTP ALG. The same pressure will > force servers to upgrade. > > Less ALG is generally a good thing, which is a reason for not > publishing another ALG spec. > > -- Christian Huitema > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dwing@cisco.com Wed May 6 18:01: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 B9FE43A6EB4 for ; Wed, 6 May 2009 18:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 gcaG76246zWJ for ; Wed, 6 May 2009 18:01:49 -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 8E67028C220 for ; Wed, 6 May 2009 18:01:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,305,1238976000"; d="scan'208";a="181985402" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 07 May 2009 01:02:45 +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 n4712jdC002795; Wed, 6 May 2009 18:02:45 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4712jfq025921; Thu, 7 May 2009 01:02:45 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <082801c9ce9d$ddd215d0$c5f0200a@cisco.com> Date: Wed, 6 May 2009 18:02:45 -0700 Message-ID: <085c01c9ceaf$88044670$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: AcnOpLAHAEZ1Wd/XRlSjCLn1DR2VYgABlULw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11419; t=1241658165; x=1242522165; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=sDTUt3CGHh0+s8T4cqnvDRqxHNqHoLzqInxpLcmxGhc=; b=LJlrzA1ewWqctvcD9AnqFGf6zluA5Pn780/q55G8UFB7rtVcNS4WSUNu+9 iPUPzWATvZQ4SRTnAXDALlkh0NUw1lV46mjn9YfbHZ4pwhTZ2YUaTMpUBfRE oXyMnhgiIt8NdQfgmQUB3S/utFTkVsWETyOlf5ULXcVxA3/VT1L/o=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 01:01:50 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, May 06, 2009 4:45 PM > To: Dan Wing > Cc: 'Behave WG' > Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? > > On 7 mei 2009, at 0:56, Dan Wing wrote: > > > Without an FTP-ALG the IPv6 FTP client would need to > support IPv4's > > PASV and > > would also need to know the IPv6 prefix of its IPv6 translator > > (draft-wing-behave-learn-prefix). There have been > objections raised > > to doing > > that in the past, specifically that it puts too much IPv6/IPv4 > > interworking > > knowledge into the application: > > Right. So let's cheat. We already have a session towards the server, > what if we simply assume that the address in the PASV > response can be > reached through the address we're using for the data channel? > > If we get to assume that the v4 address is always in the bottom 32 > bits we can even accommodate the corner case where the > control channel > goes to one address and the data connection to another by > plugging the > 32 bits from the PASV response into the lower 32 bits and > copying the > upper 96 bits from the control channel destination. > > > When > > unlucky, the lack of support causes a long delay and eventual > > failure to > > establish the data channel. > > Can you test again with the following: > > EPSV > try to set up data channel > if not successful within 5 seconds, time out and: > send ABOR > retry with PASV > > If that works, It works some places and not others. For example I did the following with the FTP server at ftp.dell.com: 230 Anonymous user logged in. EPSV 229 Entering Extended Passive Mode (|||2067|) LIST I waited a few seconds, then continued: ABOR 225 ABOR command successful. That 225 came back immediately. PASV 425 Can't open data connection. PASV It then disconnected the control channel. With other FTP servers, the response to ABOR didn't come back immediately. For example, with both ftp.nlm.nih.gov and ftp.rsa.com (two sites which give timeouts with EPSV, probably due to incorrectly configured firewalls): 230 Anonymous access granted, restrictions apply. EPSV 229 Entering Extended Passive Mode (|||15296|) LIST ABOR The ABOR command did not receive a response after one minute. > we have a procedure for clients to work with all FTP > servers out there without requiring an ALG. (Did you check if any > servers allowed you to log in but didn't handle PASV successfully?) Yes. Of the list of about 5000 anonymous FTP sites in 2003, 107 of them accepted anonymous logins but didn't give a directory listing using PASV. You can get a list of those by downloading ftp://ftpeng.cisco.com/dwing/ftp-epsv/ftp-site-list.log and then doing: grep "PASV: " ftp-site-list.log | grep -v "PASV: Ok" Output is below. -d > In that case the question is: what's more reasonable, requiring > everyone who wants to use FTP through a NAT64 or SIIT(bis) to > upgrade > their client software, or having an ALG. Note that a quick "java ftp > client" search returns a good number of results. People could > run such a client from their browser. ----- alge.anart.no PASV: Timeout EPSV: 000 01:53 cs.isa.ac.ru PASV: Timeout EPSV: 000 02:23 ftp.academ.com PASV: Timeout EPSV: 000 01:51 ftp.antivir.ru PASV: Timeout EPSV: 000 01:54 ftp.arcetri.astro.it PASV: Timeout EPSV: 000 01:53 ftp.batol.net PASV: Timeout EPSV: 000 01:53 ftp.battlefront.com PASV: Timeout EPSV: 550 Permission denied. 00:02 ftp.bbbs.net PASV: Timeout EPSV: 450 Not connected. 00:23 ftp.bcs.zp.ua PASV: Timeout EPSV: 000 02:02 ftp.blizzard.com PASV: Timeout EPSV: 425 Can't open data connection. 00:25 ftp.buguruslan.ru PASV: Timeout EPSV: 425 Can't open data connection. 00:29 ftp.cert.fr PASV: 500 'PASV': command not understood. EPSV: 500 'E PSV': command not understood. 00:03 ftp.chd.lv PASV: Timeout EPSV: 425 Can't open data connection. 00:23 ftp.ci.tuwien.ac.at PASV: Timeout EPSV: 000 02:04 ftp.combatmission.com PASV: Timeout EPSV: 550 Permission denied. 00:02 ftp.cps.unizar.es PASV: Timeout EPSV: 000 01:53 ftp.crashrecovery.org PASV: Timeout EPSV: 000 02:23 ftp.cs.ualberta.ca PASV: Timeout EPSV: 425 Failed to establish connection . 01:01 ftp.cs.umn.edu PASV: Timeout EPSV: 000 01:58 ftp.cyberglobe.net PASV: Timeout EPSV: 000 01:34 ftp.dfn.de PASV: Timeout EPSV: 000 01:54 ftp.dialognauka.ru PASV: Timeout EPSV: 000 01:53 ftp.dials.ru PASV: Timeout EPSV: 000 01:56 ftp.digimark.net PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 ftp.dreams.org PASV: Timeout EPSV: 000 03:07 ftp.dsi.unimi.it PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 ftp.elliottician.com PASV: Timeout EPSV: 550 Permission denied. 00:22 ftp.emba.uvm.edu PASV: Timeout EPSV: 000 01:53 ftp.freestone.net PASV: Timeout EPSV: 000 02:03 ftp.freiburg.linux.de PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 ftp.fuller.net PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 ftp.gdmag.com PASV: 553 Permission denied. EPSV: 502 Unimplemented c ommand. 00:03 ftp.geo.vu.nl PASV: Timeout EPSV: 000 02:08 ftp.ghost.dn.ua PASV: Timeout EPSV: 000 02:03 ftp.greyhelm.com PASV: Timeout EPSV: 425 Failed to establish connection . 01:01 ftp.habber.net PASV: 500 Unknown command EPSV: 500 Unknown command 00:01 ftp.highcriteria.com PASV: Timeout EPSV: 425 Can't open data connection. 00:22 ftp.iile.ru PASV: Timeout EPSV: 000 02:06 ftp.interklasa.pl PASV: Timeout EPSV: 000 01:55 ftp.irfu.se PASV: 425 Can't open passive connection: Permission de nied. EPSV: 500 'EPSV': command not understood. 00:03 ftp.jclark.com PASV: Timeout EPSV: 425 Failed to establish connection . 01:01 ftp.kompas.kolomna.ru PASV: Timeout EPSV: 425 Can't open data connection. 00:24 ftp.ks.ru PASV: Timeout EPSV: 000 02:04 ftp.lith.com PASV: Timeout EPSV: 425 Can't open data connection. 00:22 ftp.livinglogic.de PASV: Timeout EPSV: 000 01:53 ftp.llnl.gov PASV: 550 Permission denied. EPSV: 550 Permission deni ed. 00:00 ftp.loc.gov PASV: Timeout EPSV: 000 01:51 ftp.lustre.org PASV: Timeout EPSV: 000 01:53 ftp.markv.com PASV: Timeout EPSV: 425 Failed to establish connection . 01:01 ftp.me.ru PASV: 451 Too many passive-mode users. EPSV: 500 'EPSV ': command not understood 00:14 ftp.mebius.net PASV: Timeout EPSV: 000 02:15 ftp.mincom.com PASV: 550 Directory listing disabled. EPSV: 550 Direct ory listing disabled. 00:03 ftp.mns.ru PASV: Timeout EPSV: 000 02:04 ftp.mplik.ru PASV: Timeout EPSV: 000 01:55 ftp.mpovti.ru PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 ftp.mtn.org PASV: Timeout EPSV: 425 Failed to establish connection . 01:01 ftp.nccom.com PASV: Timeout EPSV: 000 01:51 ftp.ncd.com PASV: Timeout EPSV: 425 Failed to establish connection . 01:07 ftp.ndlug.nd.edu PASV: 000 EPSV: 599 Connection closed 00:02 ftp.nek.ru PASV: Timeout EPSV: 425 Can't open data connection. 00:24 ftp.netwizards.net PASV: 550 : No such file or directory EPSV: Timeout 00:10 ftp.newyorker.de PASV: Timeout EPSV: 000 02:04 ftp.njcc.com PASV: Timeout EPSV: 000 02:03 ftp.nndev.org PASV: Timeout EPSV: 000 01:53 ftp.north.ad.jp PASV: Timeout EPSV: 000 01:54 ftp.pflug.homeip.net PASV: Timeout EPSV: 421 Idle Timeout (60 seconds): clo sing control connection. 01:13 ftp.phred.org PASV: Timeout EPSV: 000 01:52 ftp.pitow.wroc.pl PASV: 000 EPSV: 000 02:24 ftp.planet.com.tw PASV: Timeout EPSV: 550 Permission denied. 00:23 ftp.qnet.fi PASV: Timeout EPSV: 425 Can't open data connection. 00:24 ftp.rain.fr PASV: Timeout EPSV: 000 01:56 ftp.rcom.ru PASV: Timeout EPSV: 000 01:53 ftp.rcom.spb.su PASV: Timeout EPSV: 000 01:53 ftp.rtr.com PASV: Timeout EPSV: 000 01:52 ftp.rtsnet.ru PASV: 451 Too many passive-mode users. EPSV: 500 'EPSV ': command not understood 00:13 ftp.science.tver.ru PASV: 000 EPSV: 000 00:04 ftp.sofit.ru PASV: Timeout EPSV: 425 Can't open data connection. 00:25 ftp.softcatala.org PASV: Timeout EPSV: 425 Failed to establish connection . 01:01 ftp.struscia.zuse.it PASV: Timeout EPSV: 425 Failed to establish connection . 01:03 ftp.sztaki.hu PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 ftp.tba.org.tohoku.ac.jp PASV: Timeout EPSV: 000 02:04 ftp.tc.cornell.edu PASV: Timeout EPSV: 425 Can't open data connection. 00:22 ftp.telecharger.com PASV: 550 Permission denied. EPSV: 550 Permission deni ed. 00:03 ftp.telstra.net PASV: Timeout EPSV: 000 01:54 ftp.the.net PASV: 000 EPSV: 000 03:51 ftp.uct.ac.za PASV: Timeout EPSV: 150 About to send file list. 00: 25 ftp.ukr.net PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 ftp.upmost.com.tw PASV: 000 EPSV: 000 03:02 ftp.usyd.edu.au PASV: Timeout EPSV: 000 01:53 ftp.utexas.edu PASV: Timeout EPSV: 000 03:14 ftp.vak.ru PASV: Timeout EPSV: 425 Failed to establish connection . 01:03 ftp.videotest.ru PASV: Timeout EPSV: 000 02:03 ftp.viewml.com PASV: 000 EPSV: 000 00:14 ftp.vix.com PASV: Timeout EPSV: 000 01:51 ftp.wcat.com PASV: Timeout EPSV: 000 01:53 ftp.welmers.net PASV: Timeout EPSV: 000 01:34 ftp.xatech.com PASV: Timeout EPSV: 425 Failed to establish connection . 01:01 ftp.xemacs.org PASV: Timeout EPSV: 000 01:53 ftp.ysn.ru PASV: Timeout EPSV: 000 01:55 ftp.zetnet.co.uk PASV: 550 : No such file or directory EPSV: Timeout 00:03 jueves.cps.unizar.es PASV: Timeout EPSV: 000 01:52 mmfd.nsu.ru PASV: Timeout EPSV: 425 Can't open data connection. 00:23 moonhe.jinr.ru PASV: Timeout EPSV: 000 02:04 moulon.inra.fr PASV: Timeout EPSV: 425 Failed to establish connection . 01:02 net.tamu.edu PASV: Timeout EPSV: 000 01:52 ts.kuban.ru PASV: Timeout EPSV: 425 Failed to establish connection . 00:56 wall.etl.go.jp PASV: Timeout EPSV: 150 Opening ASCII mode data connec tion for LIST (111 bytes). 00:05 From dwing@cisco.com Wed May 6 18:25: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 AB67D28C27A for ; Wed, 6 May 2009 18:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.062, 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 BeDO7qLzhL-g for ; Wed, 6 May 2009 18:25:32 -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 E062F28C275 for ; Wed, 6 May 2009 18:25:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,305,1238976000"; d="scan'208";a="74981739" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 07 May 2009 01:26:53 +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 n471Qr46028817; Wed, 6 May 2009 18:26:53 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n471QrGO013719; Thu, 7 May 2009 01:26:53 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'marcelo bagnulo braun'" References: <49FF06EE.1020608@free.fr> <49FF0888.1080703@it.uc3m.es> <49FF17F1.9020206@free.fr> <49FF1DEA.8070903@it.uc3m.es> <49FF22C1.6080100@free.fr> Date: Wed, 6 May 2009 18:26:53 -0700 Message-ID: <086701c9ceb2$e730b7c0$c5f0200a@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 Thread-Index: AcnM3ALhddB2dHcgTKq9n58fVuROFgB1aNvw In-Reply-To: <49FF22C1.6080100@free.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2529; t=1241659613; x=1242523613; 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=20DNSsec=20in=20IPv6-only-hosts=20=20&=20 discarding=20=20mapped=20AAAAs=20in=20DNS64 |Sender:=20; bh=4lphIkpKMAiugdb5K7hX6o94dJhZKX4lF1ufViMSezM=; b=OYY1eXrkt7/7Wvd7qsJ3wag9st9RjFJDfFKf8jHNyD77zCfrtprdIB5iCv NWp+IynrD+X+h6cxsfFIDq2j0zTS63r0IJPztKAK438vqUGzI6Yo0RRi60Qn TO75Sm1Kyh; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' , 'Fred Baker' , 'Keith Moore' Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 01:25:33 -0000 =20 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 > Sent: Monday, May 04, 2009 10:16 AM > To: marcelo bagnulo braun > Cc: Fred Baker; Iljitsch van Beijnum; Dan Wing; Keith Moore; Behave WG > Subject: Re: DNSsec in IPv6-only-hosts & discarding mapped=20 > AAAAs in DNS64 >=20 > marcelo bagnulo braun - le (m/j/a) 5/4/09 6:55 PM: > > R=E9mi Despr=E9s escribi=F3: > >> marcelo bagnulo braun - le (m/j/a) 5/4/09 5:23 PM: > >>> Hi Remi, > >>> > >>> I must confess, i haven't been able to read the last emails about=20 > >>> this tread in the ml, but, it seems you are assuming that=20 > IPv6 only=20 > >>> hosts will publish AAAA RR with IPv4 mapped addresses in them? > >> NO. > >> It is IPv4-only host that, in a second phase, will publish=20 > their IPv4=20 > >> addresses both in As and AAAAs. > > right, this is what i meant, sorry > > > >>> could you sumarize what is the exact scenario you have in mind by=20 > >>> doing so? (if this was already very clear in the mails in the ml,=20 > >>> just tell me so and i will reply once i have managed to catch up) > >> The target scenario is one where an IPv6-only client reaches an=20 > >> IPv4-only server (necessarily via NAT64s), and where it=20 > can validate=20 > >> that the AAAA it receives has been signed under the=20 > responsibility of=20 > >> the IPv4-only server (in its DNS server). > >> > > right, but the traget scenario assumes that the IPv4 only=20 > host has not=20 > > provisiones the NAT64 box. > Right. It is a legacy IPv4 server in a legacy environment. >=20 > > It just limits itself to publish the AAAA RR with the IPv4 mapped=20 > > addresses in it and it hopes the nat64 is available=20 > somehere else, is=20 > > this correct? > Yes. > The NAT64 has to be somewhere between the IPv6-only host and the IPv4=20 > Internet. > (Otherwise the client host should better be dual stack if it needs to=20 > reach IPv4-only servers.) So, this means=20 1. all networks deploying a translator for IPv6-initiated scenarios=20 (Scenario 1 and Scenario 5) would have to use the well-known prefix 2. all existing dual-stack hosts would see these published AAAA record, = which would require those hosts to use a translator if the host OS or its application prefer IPv6 over IPv4. What happens if there isn't a translator available to that user or its performance=20 is poor? Are there other impacts, too? -d > RD >=20 >=20 From xuxh@huawei.com Wed May 6 19:31: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 398453A6C8E for ; Wed, 6 May 2009 19:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.695 X-Spam-Level: ** X-Spam-Status: No, score=2.695 tagged_above=-999 required=5 tests=[AWL=-0.839, 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, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVsGv0jQ4DWE for ; Wed, 6 May 2009 19:31:38 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id E43333A68DF for ; Wed, 6 May 2009 19:31:09 -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 <0KJ900FLZ5Q2WJ@szxga02-in.huawei.com> for behave@ietf.org; Thu, 07 May 2009 10:32:27 +0800 (CST) Received: from x41208a ([10.111.12.94]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ900CND5Q2QY@szxga02-in.huawei.com> for behave@ietf.org; Thu, 07 May 2009 10:32:26 +0800 (CST) Date: Thu, 07 May 2009 10:32:26 +0800 From: Xu Xiaohu In-reply-to: <4A020269.40200@gmail.com> To: 'Brian E Carpenter' Message-id: <000a01c9cebc$0f759f30$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=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcnOknuKreEVNNeYRo+GmQ85ZjsTywAKO5og Cc: 'Behave WG' , 'Keith Moore' , 'Dan Wing' , 'Fred Baker' Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 02:31:39 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org]=20 > =B4=FA=B1=ED Brian E Carpenter > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA5=D4=C27=C8=D5 5:35 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: 'Behave WG'; 'Keith Moore'; 'Fred Baker'; 'Dan Wing' > =D6=F7=CC=E2: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding=20 > mapped AAAAs in DNS64 >=20 > On 2009-05-06 21:53, Xu Xiaohu wrote: > > Sorry, there was a mistake in the previous email, please see the=20 > > corrected text. > >=20 > > Except of the DNSSEC and P2P scenarios, the coexistance of=20 > IPv6-only=20 > > hosts and dual-stack hosts wihin an IPv6 network is also a=20 > scenario in=20 > > which it's better to allow the hosts, especially those DUAL-STACK=20 > > hosts to learn the > > prefix64 and synthesize the IPv6 addresses for destination=20 > IPv4 hosts=20 > > on demands, rather than depending on the DNS64 to synthesize AAAA=20 > > records from A records no matter the client is IPv6 only or=20 > dual-stack.Make sense? >=20 > Yes, but you're assuming that the IP stacks in the hosts can=20 > be modified from basic (RFC2460) behaviour. We certainly need=20 > to deal with hosts that only contain a standard resolver, so=20 > a DNS64 remains essential for that case. Yes, both of them have their own application scenarios. =20 > We discussed this in draft-van-beijnum-v6ops-mnat-pt last=20 > year, and I don't think the situation has changed much. Thanks for this information. Xiaohu >=20 > >=20 > > Xiaohu > > =20 > >=20 > >> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > >> =B7=A2=BC=FE=C8=CB: behave-bounces@ietf.org = [mailto:behave-bounces@ietf.org] > >> =B4=FA=B1=ED Xu Xiaohu > >> =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA5=D4=C26=C8=D5 17:43 > >> =CA=D5=BC=FE=C8=CB: 'R=A8=A6mi Despr=A8=A6s'; 'Fred Baker'; = 'Marcello Bagnulo Braun';=20 > >> 'Iljitsch van Beijnum'; 'Dan Wing'; 'Keith Moore'; 'Behave WG' > >> =D6=F7=CC=E2: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding=20 > mapped AAAAs=20 > >> inDNS64 > >> > >> > >> > >>> O3: If a dual stack host (with both IPv6 and IPv4 enabled > >> so that it > >>> really acts as dual stack) receives, for an IPv4-only > >> server, both an > >>> A and a mapped-address AAAA, it should communicate in IPv4 as an=20 > >>> effect of existing preferences (for > >>> IPv6 addresses over IPv4 addresses if both are available, > >> and for the > >>> IPv4 stack over the IPv6 stack if the destination address > >> is an IPv4 > >>> mapped address - according to RFCs 3484 and RFC 2553=20 > respectively). > >> Except of the DNSSEC and P2P scenarios, the coexistance of=20 > IPv6-only=20 > >> hosts and dual-stack hosts wihin an IPv6 network is also a=20 > scenario=20 > >> in which it's better to allow the hosts, especially those=20 > IPv6 only=20 > >> hosts to learn the > >> prefix64 and synthesize the IPv6 addresses for destination > >> IPv4 hosts on demands, rather than depending on the DNS64 to=20 > >> synthesize AAAA records from A records no matter the=20 > client is IPv6=20 > >> only or dual stack.Make sense? > >> > >> Xiaohu > >> > >>> Rules proposed to reach the objective are as follows: > >>> > >>> (1) IN THE SHORT TERM: > >>> > >>> R1: DNS64s MUST silently discard mapped-address AAAAs=20 > they receive. > >>> > >>> R2: At the first (non urgent) opportunity, dual stack OSes > >> that don't > >>> act as follows, MUST be updated to do it: > >>> (a) If IPv4 is enabled, datagrams presented at the socket=20 > interface=20 > >>> with an IPv4 mapped-address as destination MUST be sent in > >> IPv4 (RFC > >>> 2553 sec > >>> 3.7) > >>> (b) If IPv4 is not enabled, these datagrams MUST be sent in IPv6. > >>> (Relinquishment of an old but unjustified taboo which=20 > seems to have=20 > >>> prevented some OSes to act this way.) > >>> > >>> > >>> (2) WHEN DUAL STACKS CAN REASONABLY BE EXPECTED TO COMPLY > >> WITH R2 (no > >>> urgency) > >>> > >>> R3: IPv4-only hosts MAY start advertising mapped-address AAAAs in=20 > >>> their DNS servers (in addition to As). > >>> > >>> R4: Independently, DNS64s MAY start to forward=20 > mapped-address AAAAs=20 > >>> (either all of them for simplicity or, if more selectively, > >> ensuring > >>> that all those that are DNSsec signed are indeed forwarded). > >>> > >>> > >>> > >>> In my understanding, these (simple) rules are sufficient to=20 > >>> eventually reconcile NAT64s with DNSsec in IPv6-only hosts. > >>> And they are so far the only ones I know for this. > >>> > >>> If the analysis is right, advices on how to proceed would be=20 > >>> welcome. (A possibility would be to add appropriate sentences in=20 > >>> draft-baker-behave-v4v6-framework and > >> draft-bagnulo-behave-dns64.) > >>> If the analysis is wrong, it's IMHO worth understanding where. > >>> > >>> > >>> Regards, > >>> > >>> RD > >>> > >>> PS: apologies to addressees for the retransmission. I had=20 > forgotten=20 > >>> the copy to th emailing list. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > > 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 remi.despres@free.fr Thu May 7 01:42: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 C33EB3A68AD for ; Thu, 7 May 2009 01:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.285, 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 zbDZqc6Z8yuQ for ; Thu, 7 May 2009 01:42:58 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id D51673A683D for ; Thu, 7 May 2009 01:42:55 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 880DD4B0188; Thu, 7 May 2009 10:44:17 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp2-g21.free.fr (Postfix) with ESMTP id 5C4C44B007A; Thu, 7 May 2009 10:44:15 +0200 (CEST) Message-ID: <4A029F5C.7050706@free.fr> Date: Thu, 07 May 2009 10:44:12 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Mark Andrews References: <200905062114.n46LEJk0065442@drugs.dv.isc.org> In-Reply-To: <200905062114.n46LEJk0065442@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Dan Wing' , 'Behave WG' , 'Fred Baker' , Xu Xiaohu Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 08:42:58 -0000 Mark Andrews - le (m/j/a) 5/6/09 11:14 PM: > In message <4A018B03.6070601@free.fr>, > =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= write s: >> What I propose concerns only hosts that are purely IPv6. (They >> cannot synthesize AAAAs from As because, being supposed not to >> query for As, they don't receive any). The new rule is then a >> complement which concerns dual stack hosts in IPv6 networks. >> Agreed? > Not querying for A's on a IPv6 only host when there are no AAAA's is > idiotic. What has been clearly missing is a common understanding of what is a "purely IPv6" host. It was understood to be "a host in which nothing reflects that IPv4 ever existed". (A host that has a dual stack OS and only an IPv6 local address is NOT "purely IPv6".) With this understanding, it is supposing that a purely IPv6 host queries for As that becomes... what you say ;-). Working now on "purely IPv6" hosts may look premature to some, in view of other priorities, but doing it while working on transition strategies should at least not be considered unreasonable. > The same is true in reverse. I didn't get the point. Clarification? > Lots of problems have been caused by that rule. Which rule? > You need to know whether a host exists or not *and* whether it is > reachable or not. This is especially true when search lists are > involved. You want the unqualified name to refer to the same machine > whether you are IPv4 only, dual stack or IPv6 only. Agreed > One could add MX and SRV (basename) to the list as well. Agreed. Regards, RD From remi.despres@free.fr Thu May 7 03:31: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 3AFF13A6FB9 for ; Thu, 7 May 2009 03:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.280, 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 sBq2LECdbLtU for ; Thu, 7 May 2009 03:31:23 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 340233A6D6C for ; Thu, 7 May 2009 03:31:07 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1420F9400A0; Thu, 7 May 2009 12:32:31 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp1-g21.free.fr (Postfix) with ESMTP id DBAC8940135; Thu, 7 May 2009 12:32:28 +0200 (CEST) Message-ID: <4A02B8B9.1000905@free.fr> Date: Thu, 07 May 2009 12:32:25 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dan Wing , Behave WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 10:31:24 -0000 Dan Wing - le (m/j/a) 5/7/09 3:26 AM: > So, this means > > 1. all networks deploying a translator for IPv6-initiated scenarios > (Scenario 1 and Scenario 5) would have to use the well-known prefix A. The scenario being discussed is "connecting an IPv6 network to the IPv4 Internet", i.e. scenario (2) in Fred's draft on the Translation Framework. (I must confess I am confused with scenarios identified by numbers: Fred has only 4 of them.) B. A network deploying a translator for IPv6-initiated scenarios should route to its NAT64s all packets whose destination start with: - the prefix(es) chosen by the ISP for its NAT64s (an ISP-specific prefix and/or, if a WKP different from that of mapped addresses is standardized, this WKP ) - the mapped address prefix (or at least its 64 first bits, i.e. ::/64, if /96 prefixes are not routed) > 2. all existing dual-stack hosts would see these published AAAA > record, which would require those hosts to use a translator if the > host OS or its application prefer IPv6 over IPv4. What happens if > there isn't a translator available to that user or its performance is > poor? When mapped-address AAAAs start being published, dual-stack hosts are expected to send datagrams having mapped addresses as destinations: - in IPv4 if an IPv4 address is available at the interface - in IPv6 otherwise (and then require a NAT64 to be provided by the ISP) > Are there other impacts, too? DNS64s: - as long as dual-stack hosts cannot be expected to act as specified above, MUST discard mapped address records; - after that, SHOULD forward them, at least if they are DNSsec signed. IPv6-only applications should not artificially block mapped addresses destinations. Does this answer your questions? Regards, RD From iljitsch@muada.com Thu May 7 06:56: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 4561C3A6DB4 for ; Thu, 7 May 2009 06:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.062 X-Spam-Level: X-Spam-Status: No, score=-6.062 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 aR8sRydOtMfs for ; Thu, 7 May 2009 06:56:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id CA1843A6E74 for ; Thu, 7 May 2009 06:56:34 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.66]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n47Dugq1009712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 May 2009 15:56:43 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Dan Wing" In-Reply-To: <085c01c9ceaf$88044670$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 v930.3) Date: Thu, 7 May 2009 12:31:28 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <082801c9ce9d$ddd215d0$c5f0200a@cisco.com> <085c01c9ceaf$88044670$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: 'Behave WG' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 13:56:48 -0000 Ok, before we delve into the details, my conclusion after all this experimentation is that the wide variation in FTP behavior, some of it legitimate but problematic in the case of NATs/firewalls/NAT64s/SIITs, some of it just plain broken. I think we can do a reasonable job of smoothing over all of this with an ALG. On the other hand, we could update RFC 2428, or even RFC 959, in order to provide guidance to implementers to update their implementations to work better in today's and tomorrow's internet. Obviously the former makes sense if we consider FTP a legacy application that isn't going to be maintained in most cases, while the latter is more appropriate if we deem FTP to be a protocol that we want to stick around in the future. Dan: can we have some discussion about this in the upcoming remote interim meeting? I guess we need to ask the apps people for their input. On 7 mei 2009, at 3:02, Dan Wing wrote: > 230 Anonymous user logged in. > EPSV > 229 Entering Extended Passive Mode (|||2067|) > LIST > I waited a few seconds, then continued: > ABOR > 225 ABOR command successful. Hm, it probably makes more sense to establish the data connection first and only then issue commands like LIST. Not sure if it would make a difference, though: > That 225 came back immediately. > PASV > 425 Can't open data connection. > PASV > It then disconnected the control channel. Great. So this doesn't solve the issue. However, if we accept client changes then we can of course just let the client reconnect and then use PASV rather than EPSV. > With other FTP servers, the response to ABOR didn't come back > immediately. I believe they try to first shut down the data connection in an orderly fashion. >> (Did you check if any >> servers allowed you to log in but didn't handle PASV successfully?) > Yes. Of the list of about 5000 anonymous FTP sites in 2003, 107 of > them > accepted anonymous logins but didn't give a directory listing using > PASV. Ugh. The numbers: Filtering out anything that has "Can't " except "Can't open" leaves 2598 entries EPSV + PASV: 1626, 62.6% No EPSV, but PASV: 972, 37.4% No EPSV, no PASV: 107, 4.1% I guess losing compatibility with 4.1% broken servers isn't the end of the world, especially as none of them jump out as high profile destinations. Just for fun, here's what an IPv6 server says when you try to do PASV: ftp> quote PASV ---> PASV 227 Entering Passive Mode (0,0,0,0,237,30) ftp> quote LIST ---> LIST 150 Here comes the directory listing. 226 Directory send OK. Another one: ftp> quote PASV 227 Entering Passive Mode (9,237,25). ftp> quote LIST 150 Opening ASCII mode data connection for file list 226 Transfer complete. With the above two, I could simply connect to their IPv6 address on the indicated port and then get the directory listing. However, in this case that didn't work: ftp> quote PASV ---> PASV 227 Entering Passive Mode (,238,133). (The servers were ftp.nluug.nl, ftp.ripe.net and ftp.apnic.net.) From simon.perreault@viagenie.ca Thu May 7 10:28: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 D7A493A6BC8 for ; Thu, 7 May 2009 10:28:55 -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.450, BAYES_05=-1.11, 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 6dYPWqvHrZJv for ; Thu, 7 May 2009 10:28: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 339193A708E for ; Thu, 7 May 2009 10:28:52 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id AA8CD29E15E2; Thu, 7 May 2009 13:30:17 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id A1C8D29E15B4 for ; Thu, 7 May 2009 13:30:17 -0400 (EDT) Message-ID: <4A031AA9.70305@viagenie.ca> Date: Thu, 07 May 2009 13:30:17 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: BEHAVE WG X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 17:28:55 -0000 Hello, In [draft-bagnulo-behave-dns64-02], Section 3.1, there is the following text: > A synthetic AAAA record is created from an A record as follows: > [...] > o The TTL field is set to the TTL of the original A RR If an NSEC record was returned in the original AAAA query, then wouldn't it be more appropriate to use that record's TTL value instead? The synthetic AAAA record is valid as long as no non-synthetic AAAA record is created. The NSEC's TTL is exactly the time we are allowed to remember that no non-synthetic AAAA record exists. Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From cambyrne@yahoo.com Thu May 7 11:08: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 9A6993A6B69 for ; Thu, 7 May 2009 11:08:57 -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=[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 GwgYC+XADRV0 for ; Thu, 7 May 2009 11:08:56 -0700 (PDT) Received: from web32004.mail.mud.yahoo.com (web32004.mail.mud.yahoo.com [68.142.207.101]) by core3.amsl.com (Postfix) with SMTP id BE4233A6882 for ; Thu, 7 May 2009 11:08:56 -0700 (PDT) Received: (qmail 92443 invoked by uid 60001); 7 May 2009 18:10:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1241719822; bh=PWg3KZWsi8zBTpWq01g1cvYPxBzbEw+KaoFgQEnPxmg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=makVtR9m24ywfGdKYSKgBllfDNSupXNOHoggixDk5lJx4w68TYR347yvkk2i9FBx12mb1NemXsx29njmdDQCMa2IjZBcXA+VbxzJ609/6nckJ9vP+h0SL8SgpehtJAQydpKx9djCkNxgnMyesfeuC8qpbELPaowRw17fBEfqBWs= 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=FnSSJC9p82PTeHfFe2UTwj4foVzrNxw2/OJRCn9/IebE1NJ/Z1SpIkFOIcauely+PpNtixxHSbur+Q1R3lBaQq6gwCEFsoqERecqs3wiBlqLd4McYT3+ncjLkGSMy9meRr8CDMZ2iFrHAoGG0B9dkdGwL2rkOBvJJS8rgIQIomo=; Message-ID: <231413.92419.qm@web32004.mail.mud.yahoo.com> X-YMail-OSG: HKHTlhkVM1l3JG0wL38dTJkbLjJhAQO_lTJEcbsXd24t1qCDllP0pGIu1eZyI8Zz94FBqxXS7zDXxDx9CgyH8UR7Uw5v7yzDVKKqkAB2vkvdUilosRmMcgF8GQlG6qX2fp77fnUc15pZeuLkzUa9RuTzmT0TTBH59wGIxsTZWF8ueUjKbQtZaX2eYdBrYnU.6Y6QTDPbsFo_z0MWqGJF2vLvSOKQs7asOJFk67mQgm841Gs750pC_84_c9aMJFax2deK0yfQ6OpHYBoWpNDWDcdUktrbWxgywVC932WnT6Wjx30r4CGRuHQJif3ySQWG8y0OZ9LFLo4yR8.Llv_0 Received: from [65.161.188.11] by web32004.mail.mud.yahoo.com via HTTP; Thu, 07 May 2009 11:10:21 PDT X-Mailer: YahooMailClassic/5.2.20 YahooMailWebService/0.7.289.1 Date: Thu, 7 May 2009 11:10:21 -0700 (PDT) From: Cameron Byrne To: Mark Andrews , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 'Behave WG' , 'Fred Baker' , 'Dan Wing' , Xu Xiaohu Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 18:08:57 -0000 =0A=0A--- On Thu, 5/7/09, R=E9mi Despr=E9s wrote:=0A= =0A> From: R=E9mi Despr=E9s =0A> Subject: Re: [BEHAVE= ] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64=0A> To: "Mark= Andrews" =0A> Cc: "'Dan Wing'" , "'= Behave WG'" , "'Fred Baker'" , "Xu Xiaohu"= =0A> Date: Thursday, May 7, 2009, 4:44 AM=0A> Mark Andrew= s=A0 -=A0 le (m/j/a)=0A> 5/6/09 11:14 PM:=0A> > In message <4A018B03.607060= 1@free.fr>,=0A> =3D?ISO-8859-15?Q?R=3DE9mi_Despr=3DE9s?=3D write s:=0A> >> = What I propose concerns only hosts that are purely=0A> IPv6. (They cannot s= ynthesize AAAAs from As because, being=0A> supposed not to query for As, th= ey don't receive any). The=0A> new rule is then a complement which concerns= dual stack=0A> hosts in IPv6 networks. Agreed?=0A> =0A> > Not querying for= A's on a IPv6 only host when there=0A> are no AAAA's is=0A> >=A0 idiotic.= =0A> =0A> What has been clearly missing is a common understanding of=0A> wh= at is a=0A> "purely IPv6" host. It was understood to be "a host in=0A> whic= h nothing reflects that IPv4 ever existed". (A host that=0A> has a dual sta= ck OS and only an IPv6 local address is NOT=0A> "purely IPv6".)=0A> =0A> Wi= th this understanding, it is supposing that a purely IPv6=0A> host queries = for As that becomes... what you say ;-).=0A=0A> =0A> Working now on "purely= IPv6" hosts may look premature to=0A> some, in view of other priorities, b= ut doing it while=0A> working on transition strategies should at least not = be=0A> considered unreasonable.=0A=0ANot premature at all. NAT64 and DNS64= will be instrumental in helping me launch IPv6 only devices at T-Mobile US= A in the near term. The mobile device with only an IPv6 address is an impo= rtant and relevant use case that can be deployed in the real world relative= ly quickly with few dependencies, assuming NAT64 and DNS64 move forward qui= ckly.=0A=0A> =0A> > The same is true in reverse.=0A> =0A> I didn't get the = point. Clarification?=0A> =0A> =0A> > Lots of problems have been caused by = that rule.=0A> =0A> Which rule?=0A> =0A> =0A> > You need to know whether a = host exists or not *and*=0A> whether it is=0A> > reachable or not. This is = especially true when search=0A> lists are=0A> > involved.=A0 You want the u= nqualified name to refer=0A> to the same machine=0A> > whether you are IPv4= only, dual stack or IPv6 only.=0A> =0A> Agreed=0A> =0A> =0A> > One could a= dd MX and SRV (basename) to the list as=0A> well.=0A> =0A> Agreed.=0A> =0A>= =0A> Regards,=0A> RD=0A> =0A> ____________________________________________= ___=0A> Behave mailing list=0A> Behave@ietf.org=0A> https://www.ietf.org/ma= ilman/listinfo/behave=0A=0ARegards,=0A=0ACameron Byrne=0APrincipal Engineer= =0AT-Mobile USA From dthaler@windows.microsoft.com Thu May 7 12:07: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 763803A6AE0 for ; Thu, 7 May 2009 12:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Ii9JSnc8V7XC for ; Thu, 7 May 2009 12:07:16 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 702433A6898 for ; Thu, 7 May 2009 12:07:16 -0700 (PDT) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 7 May 2009 12:08:44 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) with Microsoft SMTP Server id 8.2.99.4; Thu, 7 May 2009 12:08:44 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Thu, 7 May 2009 12:08:44 -0700 From: Dave Thaler To: Simon Perreault , BEHAVE WG Date: Thu, 7 May 2009 12:08:42 -0700 Thread-Topic: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC Thread-Index: AcnPOk6u7gebfhzmQUiET6rpmmxuDQADN9dg Message-ID: References: <4A031AA9.70305@viagenie.ca> In-Reply-To: <4A031AA9.70305@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 Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 19:07:17 -0000 I'd say it should really be the minimum of the two. -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Simon Perreault > Sent: Thursday, May 07, 2009 10:30 AM > To: BEHAVE WG > Subject: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of > NSEC >=20 > Hello, >=20 > In [draft-bagnulo-behave-dns64-02], Section 3.1, there is the following > text: >=20 > > A synthetic AAAA record is created from an A record as follows: > > [...] > > o The TTL field is set to the TTL of the original A RR >=20 > If an NSEC record was returned in the original AAAA query, then > wouldn't it be > more appropriate to use that record's TTL value instead? The synthetic > AAAA > record is valid as long as no non-synthetic AAAA record is created. The > NSEC's > TTL is exactly the time we are allowed to remember that no non- > synthetic AAAA > record exists. >=20 > Thanks, > Simon > -- > STUN/TURN server --> http://numb.viagenie.ca > Interplanetary news --> http://reeves.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Thu May 7 12: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 14C583A719C for ; Thu, 7 May 2009 12:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.320, 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 WqH1Dqri82QY for ; Thu, 7 May 2009 12:10: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 A571B3A6C7B for ; Thu, 7 May 2009 12:10:08 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 5CD7029E15CE; Thu, 7 May 2009 15:11:35 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id 51DFC29E15B4; Thu, 7 May 2009 15:11:35 -0400 (EDT) Message-ID: <4A033267.4070807@viagenie.ca> Date: Thu, 07 May 2009 15:11:35 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Dave Thaler References: <4A031AA9.70305@viagenie.ca> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: BEHAVE WG Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 19:10:15 -0000 Dave Thaler wrote, on 07/05/09 03:08 PM: > I'd say it should really be the minimum of the two. Right, thanks for the precision. Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Thu May 7 12:44: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 AC82A3A69B2 for ; Thu, 7 May 2009 12:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.708, 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 muifwQJUMTw8 for ; Thu, 7 May 2009 12:44:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E41DF3A6AE0 for ; Thu, 7 May 2009 12:44:02 -0700 (PDT) Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id F066B2FE9574 for ; Thu, 7 May 2009 19:45:29 +0000 (UTC) Date: Thu, 7 May 2009 15:45:26 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090507194525.GH1274@shinkuro.com> References: <4A031AA9.70305@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A031AA9.70305@viagenie.ca> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 19:44:03 -0000 On Thu, May 07, 2009 at 01:30:17PM -0400, Simon Perreault wrote: > record is valid as long as no non-synthetic AAAA record is created. The NSEC's > TTL is exactly the time we are allowed to remember that no non-synthetic AAAA > record exists. On these grounds, the synthetic AAAA's TTL should be the SOA minimum TTL field, in the spirit of negative caching, no? I'm not opposed to it, but it will mean more queries and synthesis. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dwing@cisco.com Thu May 7 13:14: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 1CD473A69E4 for ; Thu, 7 May 2009 13:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.061, 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 vAiyBormglhN for ; Thu, 7 May 2009 13:14:23 -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 02C8C3A683D for ; Thu, 7 May 2009 13:14:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,312,1238976000"; d="scan'208";a="182455089" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 07 May 2009 20:15:51 +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 n47KFpi6006771; Thu, 7 May 2009 13:15:51 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n47KFpfZ017745; Thu, 7 May 2009 20:15:51 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Behave WG'" References: <4A02B8B9.1000905@free.fr> Date: Thu, 7 May 2009 13:15:51 -0700 Message-ID: <004701c9cf50$9e3f1f40$c5f0200a@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 In-Reply-To: <4A02B8B9.1000905@free.fr> Thread-Index: AcnO/yY4v9nyq6xuSWqA5yf/uDQFYgAT9XqQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3023; t=1241727351; x=1242591351; 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=20DNSsec=20in=20IPv6-only-hosts=20=20&=20 discarding=20=20mapped=20AAAAs=20in=20DNS64 |Sender:=20; bh=j8QYhWYCUg4tZkenlB8ayiltSS1yVf1UW4K1obnFP1w=; b=PC8Gn6chWOMMAs3VM6hBNfGGWZnbZ6damLhjaud4wwDwIaHfRFLv2oMBtL q6ctkQ5oba0B+VSzCctEmCi1m/DFkfPF/iOTOpCnMHlb6ohBMEu8bpH6S7kz Uj50fQ5kXQ; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 20:14:24 -0000 =20 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 > Sent: Thursday, May 07, 2009 3:32 AM > To: Dan Wing; Behave WG > Subject: Re: DNSsec in IPv6-only-hosts & discarding mapped=20 > AAAAs in DNS64 >=20 > Dan Wing - le (m/j/a) 5/7/09 3:26 AM: > > So, this means > >=20 > > 1. all networks deploying a translator for IPv6-initiated scenarios=20 > > (Scenario 1 and Scenario 5) would have to use the well-known prefix >=20 > A. > The scenario being discussed is "connecting an IPv6 network=20 > to the IPv4 > Internet", i.e. scenario (2) in Fred's draft on the Translation > Framework. (I must confess I am confused with scenarios identified by > numbers: Fred has only 4 of them.) Yes, sorry about that. I was going with the 4 we have in the charter, http://www.ietf.org/html.charters/behave-charter.html, and the other two defined by Dave Thaler in the Doodle poll, http://www.doodle.com/participation.html?pollId=3D9qsdgt8r6kqk6zty Our soon-to-be-updated charter will have all 6, because at the San Francisco meeting the clear consensus was to work on all 6. > B. > A network deploying a translator for IPv6-initiated scenarios should > route to its NAT64s all packets whose destination start with: > - the prefix(es) chosen by the ISP for its NAT64s (an ISP-specific > prefix and/or, if a WKP different from that of mapped addresses is > standardized, this WKP ) Ok. > - the mapped address prefix (or at least its 64 first bits,=20 > i.e. ::/64, > if /96 prefixes are not routed) > > > 2. all existing dual-stack hosts would see these published AAAA > > record, which would require those hosts to use a translator if the=20 > > host OS or its application prefer IPv6 over IPv4. What happens if=20 > > there isn't a translator available to that user or its=20 > > performance is poor? >=20 > When mapped-address AAAAs start being published, dual-stack hosts are > expected to send datagrams having mapped addresses as destinations: > - in IPv4 if an IPv4 address is available at the interface > - in IPv6 otherwise (and then require a NAT64 to be provided=20 > by the ISP) Ok, thanks. =20 So, I believe the timeframes would be aligned: An ISP that offers only IPv6 addresses to subscribers will need to operate a translator to access IPv4 anyway. > > Are there other impacts, too? >=20 > DNS64s: > - as long as dual-stack hosts cannot be expected to act as specified > above, MUST discard mapped address records; We would like dual-stack hosts to prefer native connectivity (rather than translated connectivity). > - after that, SHOULD forward them, at least if they are DNSsec signed. >=20 > IPv6-only applications should not artificially block mapped addresses > destinations. So applications and host OSs should ignore draft-itojun-v6ops-v4mapped-harmful, correct? > Does this answer your questions? Yes, thanks. Much clearer now. And I see how this could work now. -d From dwing@cisco.com Thu May 7 13:59: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 3A1D33A6AB8 for ; Thu, 7 May 2009 13:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 IzZkF1kPLcGL for ; Thu, 7 May 2009 13:59:26 -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 14BC63A6C33 for ; Thu, 7 May 2009 13:59:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,312,1238976000"; d="scan'208";a="159925105" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 07 May 2009 21:00:54 +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 n47L0s9W013200; Thu, 7 May 2009 14:00:54 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n47L0stA019633; Thu, 7 May 2009 21:00:54 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <082801c9ce9d$ddd215d0$c5f0200a@cisco.com> <085c01c9ceaf$88044670$c5f0200a@cisco.com> Date: Thu, 7 May 2009 14:00:54 -0700 Message-ID: <006101c9cf56$e965cdb0$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 In-Reply-To: Thread-Index: AcnPG8CmjqDDy1xySdGQx3R+BT7LDgAOpjVQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3668; t=1241730054; x=1242594054; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=wYas5LC1zXx/w6TkEaxT2KPGpHDNwd7JGIe0jJ3uOGk=; b=R73dXHgELWyFFdpHS1FIx9p9QiEwMojl86FkB52oyol+NCpkLXNoB0PvmH 68o7ShHXPqMZJGmvKrNXj6VNKZ8VE5masQM8QinAZPSH9kS0mAdDp+03SnrL L8NB+n6LYk; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2009 20:59:27 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, May 07, 2009 3:31 AM > To: Dan Wing > Cc: 'Behave WG' > Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? > > Ok, before we delve into the details, my conclusion after all this > experimentation is that the wide variation in FTP behavior, > some of it legitimate but problematic in the case of > NATs/firewalls/NAT64s/SIITs, > some of it just plain broken. I think we can do a reasonable job of > smoothing over all of this with an ALG. On the other hand, we could > update RFC 2428, or even RFC 959, in order to provide guidance to > implementers to update their implementations to work better > in today's and tomorrow's internet. > > Obviously the former makes sense if we consider FTP a legacy > application that isn't going to be maintained in most cases, > while the latter is more appropriate if we deem FTP to be a > protocol that we want to stick around in the future. > > Dan: can we have some discussion about this in the upcoming remote > interim meeting? Yes, we will put FTP on the agenda - but towards the end. -d > I guess we need to ask the apps people for their input. > > On 7 mei 2009, at 3:02, Dan Wing wrote: > > > 230 Anonymous user logged in. > > EPSV > > 229 Entering Extended Passive Mode (|||2067|) > > LIST > > > I waited a few seconds, then continued: > > > ABOR > > 225 ABOR command successful. > > Hm, it probably makes more sense to establish the data connection > first and only then issue commands like LIST. Not sure if it would > make a difference, though: > > > That 225 came back immediately. > > > PASV > > 425 Can't open data connection. > > PASV > > > It then disconnected the control channel. > > Great. So this doesn't solve the issue. > > However, if we accept client changes then we can of course just let > the client reconnect and then use PASV rather than EPSV. > > > With other FTP servers, the response to ABOR didn't come back > > immediately. > > I believe they try to first shut down the data connection in an > orderly fashion. > > >> (Did you check if any > >> servers allowed you to log in but didn't handle PASV successfully?) > > > Yes. Of the list of about 5000 anonymous FTP sites in > 2003, 107 of > > them > > accepted anonymous logins but didn't give a directory > listing using > > PASV. > > Ugh. The numbers: > > Filtering out anything that has "Can't " except "Can't open" leaves > 2598 entries > > EPSV + PASV: 1626, 62.6% > No EPSV, but PASV: 972, 37.4% > No EPSV, no PASV: 107, 4.1% > > I guess losing compatibility with 4.1% broken servers isn't > the end of > the world, especially as none of them jump out as high profile > destinations. > > Just for fun, here's what an IPv6 server says when you try to do PASV: > > ftp> quote PASV > ---> PASV > 227 Entering Passive Mode (0,0,0,0,237,30) > ftp> quote LIST > ---> LIST > 150 Here comes the directory listing. > 226 Directory send OK. > > Another one: > > ftp> quote PASV > 227 Entering Passive Mode (9,237,25). > ftp> quote LIST > 150 Opening ASCII mode data connection for file list > 226 Transfer complete. > > With the above two, I could simply connect to their IPv6 address on > the indicated port and then get the directory listing. However, in > this case that didn't work: > > ftp> quote PASV > ---> PASV > 227 Entering Passive Mode (,238,133). > > (The servers were ftp.nluug.nl, ftp.ripe.net and ftp.apnic.net.) From Mark_Andrews@isc.org Thu May 7 17:02: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 166713A6AB6 for ; Thu, 7 May 2009 17:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 MffQQ3q8skvm for ; Thu, 7 May 2009 17:02: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 3D0033A682D for ; Thu, 7 May 2009 17:02: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 68374E601E; Fri, 8 May 2009 00:04:10 +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 n4804622084653; Fri, 8 May 2009 10:04:07 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200905080004.n4804622084653@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews In-reply-to: Your message of "Thu, 07 May 2009 15:45:26 -0400." <20090507194525.GH1274@shinkuro.com> Date: Fri, 08 May 2009 10:04:06 +1000 Sender: Mark_Andrews@isc.org Cc: behave@ietf.org Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 08 May 2009 00:02:48 -0000 In message <20090507194525.GH1274@shinkuro.com>, Andrew Sullivan writes: > On Thu, May 07, 2009 at 01:30:17PM -0400, Simon Perreault wrote: > > record is valid as long as no non-synthetic AAAA record is created. The NSEC's > > TTL is exactly the time we are allowed to remember that no non-synthetic AAAA > > record exists. > > On these grounds, the synthetic AAAA's TTL should be the SOA minimum > TTL field, in the spirit of negative caching, no? I'm not opposed to > it, but it will mean more queries and synthesis. No. It should be the minimum of the TTL of the A record and the minimum of the TTL of the SOA record indicating that there is no AAAA record. These are the TTL's of the two inputs in the decision to create the synthetic AAAA record. 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: Mark_Andrews@isc.org From remi.despres@free.fr Thu May 7 22:56: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 2654E3A6ADC for ; Thu, 7 May 2009 22:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.275, 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 7etll1Fctr+n for ; Thu, 7 May 2009 22:56:43 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 716FF3A68B1 for ; Thu, 7 May 2009 22:56:39 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id E2CDE818049; Fri, 8 May 2009 07:58:04 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp3-g21.free.fr (Postfix) with ESMTP id C19F08180FE; Fri, 8 May 2009 07:58:01 +0200 (CEST) Message-ID: <4A03C9E6.2010905@free.fr> Date: Fri, 08 May 2009 07:57:58 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dan Wing References: <4A02B8B9.1000905@free.fr> <004701c9cf50$9e3f1f40$c5f0200a@cisco.com> In-Reply-To: <004701c9cf50$9e3f1f40$c5f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Behave WG' Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 08 May 2009 05:56:44 -0000 Dan Wing - le (m/j/a) 5/7/09 10:15 PM: >> DNS64s: >> - as long as dual-stack hosts cannot be expected to act as >> specified above, MUST discard mapped address records; > > We would like dual-stack hosts to prefer native connectivity (rather > than translated connectivity). > >> - after that, SHOULD forward them, at least if they are DNSsec >> signed. >> >> IPv6-only applications should not artificially block mapped >> addresses destinations. > > So applications and host OSs should ignore > draft-itojun-v6ops-v4mapped-harmful, correct? Yes. (Concerns of this draft don't apply in this case.) > And I see how this could work now. :-). RD From simon.perreault@viagenie.ca Fri May 8 05:03: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 5E8A83A6C78 for ; Fri, 8 May 2009 05:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.274, 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 maDH2HI1-9Hi for ; Fri, 8 May 2009 05:03: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 54BB128C263 for ; Fri, 8 May 2009 05:03:35 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id D1EC429E15BC; Fri, 8 May 2009 08:05:01 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id BCF1C29E15A0; Fri, 8 May 2009 08:05:01 -0400 (EDT) Message-ID: <4A041FED.7040109@viagenie.ca> Date: Fri, 08 May 2009 08:05:01 -0400 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Mark Andrews References: <200905080004.n4804622084653@drugs.dv.isc.org> In-Reply-To: <200905080004.n4804622084653@drugs.dv.isc.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , behave@ietf.org Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 08 May 2009 12:03:36 -0000 Mark Andrews wrote, on 07/05/09 08:04 PM: > No. It should be the minimum of the TTL of the A record > and the minimum of the TTL of the SOA record indicating > that there is no AAAA record. These are the TTL's of the > two inputs in the decision to create the synthetic AAAA > record. Could you explain why the NSEC record is not considered in your proposal? Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From ajs@shinkuro.com Fri May 8 08:54: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 6915D28C252 for ; Fri, 8 May 2009 08:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 O28+41QtoAAj for ; Fri, 8 May 2009 08:54:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9D6F028C16B for ; Fri, 8 May 2009 08:54:19 -0700 (PDT) Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AF5962FE9574 for ; Fri, 8 May 2009 15:55:47 +0000 (UTC) Date: Fri, 8 May 2009 11:55:46 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090508155545.GD2372@shinkuro.com> References: <20090507194525.GH1274@shinkuro.com> <200905080004.n4804622084653@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905080004.n4804622084653@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 08 May 2009 15:54:20 -0000 On Fri, May 08, 2009 at 10:04:06AM +1000, Mark Andrews wrote: > No. It should be the minimum of the TTL of the A record > and the minimum of the TTL of the SOA record indicating > that there is no AAAA record. These are the TTL's of the > two inputs in the decision to create the synthetic AAAA > record. I don't understand why the SOA TTL itself enters into it. The justification for the SOA Minimum TTL field is made in RFC 4034: The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]). It seems to me that if we're going to do anything other than just re-use the TTL on the A record, we should consider (as was suggested) the minimum time we're supposed to assume that there couldn't be a AAAA. That's the time defined by RFC 2308, no? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Mark_Andrews@isc.org Fri May 8 16:46: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 EB7A13A68CE for ; Fri, 8 May 2009 16:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 zlfGaFEj8MeW for ; Fri, 8 May 2009 16:46:20 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 00EFD3A69D3 for ; Fri, 8 May 2009 16:46:19 -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 29100E6029; Fri, 8 May 2009 23:47:46 +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 n48NlgG1098906; Sat, 9 May 2009 09:47:43 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200905082347.n48NlgG1098906@drugs.dv.isc.org> To: Andrew Sullivan From: Mark Andrews In-reply-to: Your message of "Fri, 08 May 2009 11:55:46 -0400." <20090508155545.GD2372@shinkuro.com> Date: Sat, 09 May 2009 09:47:42 +1000 Sender: Mark_Andrews@isc.org Cc: behave@ietf.org Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 08 May 2009 23:46:21 -0000 In message <20090508155545.GD2372@shinkuro.com>, Andrew Sullivan writes: > On Fri, May 08, 2009 at 10:04:06AM +1000, Mark Andrews wrote: > > > No. It should be the minimum of the TTL of the A record > > and the minimum of the TTL of the SOA record indicating > > that there is no AAAA record. These are the TTL's of the > > two inputs in the decision to create the synthetic AAAA > > record. > > I don't understand why the SOA TTL itself enters into it. The > justification for the SOA Minimum TTL field is made in RFC 4034: > > The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL > field. This is in the spirit of negative caching ([RFC2308]). > > It seems to me that if we're going to do anything other than just > re-use the TTL on the A record, we should consider (as was suggested) > the minimum time we're supposed to assume that there couldn't be a > AAAA. That's the time defined by RFC 2308, no? > > A The SOA record's TTL in the negative response should also start out with the SOA minimum. The SOA's record's TTL is that which defines the time to live of a negative response (RFC 2308). The TTL of NXT/NSEC/NSEC3 records in the negative response should be consistent with the TTL of the SOA record in the negative response. Using the SOA record works independent of whether the zone is signed or not. Mark > -- > 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: Mark_Andrews@isc.org From wwaites@googlemail.com Sat May 9 03:58: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 AEE143A6951 for ; Sat, 9 May 2009 03:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rif32pszlb2i for ; Sat, 9 May 2009 03:58:57 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 9D1FD3A680F for ; Sat, 9 May 2009 03:58:57 -0700 (PDT) Received: by fxm2 with SMTP id 2so1809019fxm.37 for ; Sat, 09 May 2009 04:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=w6YpRoBBVyW64hamuPmihOD9oKgDB0bWshUsylhocak=; b=Gk9VwfkSUVVgPMkZDFtRLPCfLViXVF1bG2NXQtyUteXn2poLdIjTL+befCxdrfJ3Mw aKNno4p7481VmInM1bz6SYBtxJ2eAWoGFifujCuYsSf5IMVyPJkqGoTNrNk2UtxH5QsX 6/uUiMlbKclgvTpfwK89Im50NU0396HY9UTPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AsbRTYL1IY116KrhzGnHckhqbkHsUSW8BFv/GPWI7k/du6lHx1wnCmpbNAZapiq29y WEUpv1mMXig/kSN5PFP9L/ByJQjk1Dez3lsQGrV42FQQjLZpx7Q3l/xzwoltHxXzVTxP jsKOA7SyCKgIoA+xoL5ym9p3l3MsprMD6UD4Q= MIME-Version: 1.0 Sender: wwaites@googlemail.com Received: by 10.204.31.204 with SMTP id z12mr4546474bkc.80.1241866824187; Sat, 09 May 2009 04:00:24 -0700 (PDT) In-Reply-To: <4A018B03.6070601@free.fr> References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> <4A018B03.6070601@free.fr> Date: Sat, 9 May 2009 13:00:24 +0200 X-Google-Sender-Auth: 46c732c0e6180dbf Message-ID: <495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com> From: William Waites To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dan Wing , Behave WG , Keith Moore , Xu Xiaohu , Fred Baker Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 09 May 2009 10:58:58 -0000 2009/5/6 R=E9mi Despr=E9s : > > There should be IMHO one more constraint: > - If prefix64 is not the mapped-address prefix, synthesis of AAAAs MUST > be performed ONLY if no IPv4 address is locally enabled. > (Otherwise, a dual-stack application in a dual-stack host that has an > IPv4 address enabled may end up using IPv6 although IPv4 is possible and > no NAT64 is available). I'd rather say something like, "ONLY if there is no IPv4 route to the destination". That way if I have a private or island IPv4 network address on an interface I can still use a translator to talk to remote IPv4 hosts where there is no native connectivity. Note that on my "IPv6 only" hosts I still have, for example, 127.0.0.1 configured on the loopback interface. -w --=20 William Waites +49 30 8894 9942 From ajs@shinkuro.com Sat May 9 07:34: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 4ABF63A6910 for ; Sat, 9 May 2009 07:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=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 ysV7eULA8XJw for ; Sat, 9 May 2009 07:34:53 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 95BDA3A68BB for ; Sat, 9 May 2009 07:34:53 -0700 (PDT) Received: from crankycanuck.ca (CPE00212980eb9c-CM00194757af08.cpe.net.cable.rogers.com [99.249.242.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 16CA92FE9574 for ; Sat, 9 May 2009 14:36:22 +0000 (UTC) Date: Sat, 9 May 2009 10:36:20 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20090509143619.GC3322@shinkuro.com> References: <20090508155545.GD2372@shinkuro.com> <200905082347.n48NlgG1098906@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905082347.n48NlgG1098906@drugs.dv.isc.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 09 May 2009 14:34:54 -0000 On Sat, May 09, 2009 at 09:47:42AM +1000, Mark Andrews wrote: > The SOA record's TTL in the negative response should also > start out with the SOA minimum. Oh, duh, I see what you mean. Since the negative response's SOA record's TTL is actually equivalent to the SOA minimum TTL, then you can use the SOA TTL as the basis. This is nice because then you don't have to grovel through the SOA fields to figure out what you need. So what you're suggesting is that the DNS64 remember the TTL from the SOA record in the negative response to the AAAA query. Then when it gets the positive answer to the A query, it sets the TTL on the synthesized AAAA to be min(TTL of SOA in first answer,TTL of A in second answer). Right? This way the NSEC record doesn't matter, because its TTL ought to be exactly the same as the SOA minimum field anyway. This seems right to me. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From matthijs@nlnetlabs.nl Sat May 9 07:51: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 5A3813A6923 for ; Sat, 9 May 2009 07:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=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 gGKoE8jyR3Pz for ; Sat, 9 May 2009 07:51:37 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id DA1CC3A6CA6 for ; Sat, 9 May 2009 07:51:21 -0700 (PDT) Received: from [193.0.25.207] (dhcp-25-207.ripemtg.ripe.net [193.0.25.207]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n49EqgHm001289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 May 2009 16:52:48 +0200 (CEST) (envelope-from matthijs@nlnetlabs.nl) Message-ID: <4A0598B0.8010605@nlnetlabs.nl> Date: Sat, 09 May 2009 16:52:32 +0200 From: Matthijs Mekking Organization: NLnet Labs User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Andrew Sullivan References: <20090508155545.GD2372@shinkuro.com> <200905082347.n48NlgG1098906@drugs.dv.isc.org> <20090509143619.GC3322@shinkuro.com> In-Reply-To: <20090509143619.GC3322@shinkuro.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (open.nlnetlabs.nl [213.154.224.1]); Sat, 09 May 2009 16:52:49 +0200 (CEST) Cc: behave@ietf.org Subject: Re: [BEHAVE] [DNS64] TTL of synthetic AAAA records in presence of NSEC X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 09 May 2009 14:51:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My first thought was that you could simply copy the TTL from the A record to the synthesized AAAA record, like the (new) DNAME draft does. However, now I get that it is different than the CNAME from DNAME synthesis, since this is happening at the server side, while with NAT64, AAAA records are generated at the DNS64 resolver. So the TTL of the synthezised AAAA records should reflect negative caching. Still, I would like to see this clarification in the document, instead of solely the statement: The TTL of synthesized AAAA records is the minimum of the TTL of the SOA and the TTL of the A record. Matthijs Andrew Sullivan wrote: > On Sat, May 09, 2009 at 09:47:42AM +1000, Mark Andrews wrote: >> The SOA record's TTL in the negative response should also >> start out with the SOA minimum. > > Oh, duh, I see what you mean. Since the negative response's SOA > record's TTL is actually equivalent to the SOA minimum TTL, then you > can use the SOA TTL as the basis. This is nice because then you don't > have to grovel through the SOA fields to figure out what you need. > > So what you're suggesting is that the DNS64 remember the TTL from the > SOA record in the negative response to the AAAA query. Then when it > gets the positive answer to the A query, it sets the TTL on the > synthesized AAAA to be min(TTL of SOA in first answer,TTL of A in > second answer). Right? This way the NSEC record doesn't matter, > because its TTL ought to be exactly the same as the SOA minimum field > anyway. > > This seems right to me. > > A > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJKBZisAAoJEA8yVCPsQCW56CoH/jFH55nzQd9IFl8x+ZaQ5GVy LyKR8+EjxmsJJiM2NsJGFl+9MMfcRIFBijm2meJ2MqzapjB1UKvUrHas5jK/8NWP G56u3Lu1o9f0vwSem8ob8qkUPSL22Y6dICkfBJg1Vht+7boaW7/ZOsY0sSn9MSuJ Rs0mtyNdCSni/3l29lqjuCqDuPb8+mCp8UQtLBTQYHzn8pEwgc75+yGdxwWrjQdb vUSBgqJsfdKEf4iD0PbJgVwX6LolbBiuihd8cLj7PExYlMbrqc5nGOueiCJ4Wye8 hXIdx4Wf1pTfqmjdZjIT5rBCoIStM4LEpyzqT/ZWVtckD/6mmubULIG5e6lQQKk= =UN03 -----END PGP SIGNATURE----- From carol_chang8009@yahoo.com.cn Sun May 10 18: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 582193A6E13 for ; Sun, 10 May 2009 18:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.722 X-Spam-Level: **** X-Spam-Status: No, score=4.722 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, J_BACKHAIR_33=1, J_BACKHAIR_34=1, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_57=0.6, 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 XoYedTQiqSW8 for ; Sun, 10 May 2009 18:16:10 -0700 (PDT) Received: from web15808.mail.cnb.yahoo.com (web15808.mail.cnb.yahoo.com [202.165.102.88]) by core3.amsl.com (Postfix) with SMTP id 40E253A6904 for ; Sun, 10 May 2009 18:15:44 -0700 (PDT) Received: (qmail 4700 invoked by uid 60001); 11 May 2009 01:17:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.cn; s=s1024; t=1242004633; bh=LsjgtAWWJ4SawqThfdvW83tVWPXo3es0dg6qcdpISD0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=1CDZJHYc7Kqa6VQhCtq6XduvQoCtH1d10CPN2JG8kdefkv9KjXEj4LlMRyoj7VmLNhVGUjrpJfdDoim4Usd9rwSfxbsG7Yqe+wHkONyQeeupqzO0r6OLRO142WqRtS+VXb29RfyyxgEFHxkmqaZ4DrSRixBr8i+/Eyq//x1hjgc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=XOfRWUi3M5Z/2FXfFbaYLgWVkde8N4XofDlRJ+uJ9G9EGI432qf33MxKl2c/q6p9pCbyhr5wmX1Osc3T1wkVPntkgw/ffMTwlAjOOy/mQMFr40oWpHdKA3pNMUEeKCaK13CE6aX7YrIl+uRwpAnHiblcsO+Q1BFFOsV6LEYmLGo=; Message-ID: <597540.2511.qm@web15808.mail.cnb.yahoo.com> X-YMail-OSG: GjQFMagVM1kb.Z2tahVIsSq19Ioj.DrLhBR2pQfmi0nDMPsIDuTwZa3r4SXVhtgu5yvmJmuuo1lCvm4IazunLIT67mb44Lc7WH2Zu5pP0QKNSfrMSY.alaJtvSojp_3H6bD9J9_DKkqO2G0NrMgiNq3TJW85tqPwlcMS67_RXNrDlNsMrXPEBkvZYGXfuOck61e17SV880.EVVibJYLwQwn9gPOnpD3OAhejN8ooQ7T5yro- Received: from [123.52.123.21] by web15808.mail.cnb.yahoo.com via HTTP; Mon, 11 May 2009 09:17:13 CST X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.1 Date: Mon, 11 May 2009 09:17:13 +0800 (CST) From: Carol Chang To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= , William Waites MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-758907300-1242004633=:2511" Cc: Fred Baker , Behave WG , Keith Moore , Dan Wing , Xu Xiaohu Subject: [BEHAVE] Low cost VOIP Phone,Gateway X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 11 May 2009 01:16:11 -0000 --0-758907300-1242004633=:2511 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sales promotion for YUXIN VOIP Phone ,Gateway.Welcome OEM VOIP Phone YWH210B(1RJ45) YWH201D (2RJ45) Support SIP,IAX2 protocol=C2=A0 G.711,G.729,GSM,iLBC codec supported. POE for optional VOIP Phone YWH600A(2RJ45) YWH600B(2RJ45,FXO) 2RJ45 Ports,Built-in Router,conference.Auto-provision or updating by HTTP,F= TP or TFTP. POE,FXO for optional =C2=A0 YWH300C IP Phone 2RJ45 Ports,Built-in Router,conference, 3 SIP accounts, Auto-Provison or updating by HTTP,FTP or TFTP. YWH602 VOIP Phone Support SIP,IAX2,H323 (SIP+IAX2 or SIP+H323) =C2=A0G.711 u/a; G729, G7231 5.3/6.3 Codec supported POE for optional VOIP Gateway YGW30A(2RJ45) YGW30B(2RJ45,FXO) 2RJ45 Ports,Built-in Router,conference, Auto-provison or updating by HTTP,FTP or TFTP. VOIP Gateway YGW50(1FXS,SIP,IAX2) YGW60(2FXS,SIP,VPN) YGW80(4FXS,SIP,VPN) Support Bridge and Router(NAT&NAPT)=20 G.711(A-law/U-law), G.723.1,.729A/B,G.726,ILBC codec supported http://www.yntx.com =C2=A0=C2=A0E-mail:sales@yntx.com=C2=A0 carol@yntx.com= =C2=A0 =C2=A0MSN:carol_chang8009@hotmail.com=0A=0A=0A ________________= ___________________________________________ =0A =E5=A5=BD=E7=8E=A9=E8=B4= =BA=E5=8D=A1=E7=AD=89=E4=BD=A0=E5=8F=91=EF=BC=8C=E9=82=AE=E7=AE=B1=E8=B4=BA= =E5=8D=A1=E5=85=A8=E6=96=B0=E4=B8=8A=E7=BA=BF=EF=BC=81 =0Ahttp://card.mail.= cn.yahoo.com/ --0-758907300-1242004633=:2511 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sales promotion fo= r YUXIN VOIP Phone ,Gateway.Welcome OEM=

<= v:path o:connecttype=3D"rect" gradientshapeok=3D"t" o:extrusionok=3D"f">

VOIP Phone

YWH210B(1RJ45)

YWH201D= (2RJ45)

Support SIP,IAX2 protocol 

G.711,G.729,GSM,iLBC= codec supported.

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l">POE for optional=

<= /SPAN>

VOIP Phone

YWH600A(2RJ45)

<= B style=3D"mso-bidi-font-weight: normal">YWH600B(2RJ45,FXO)<= /SPAN>

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l">2RJ45 Ports,Built-in Router,conference.Auto-provision or updating by HTT= P,FTP or TFTP.

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l">POE,FXO for optional<= /DIV>

 

YWH300C<= /st1:chmetcnv> IP Phone

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l">2RJ45 Ports,Built-in Router,conference,

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l">3 SIP accounts,

Auto-Provison or updating by HTTP,FTP= or TFTP.

YWH602 VOIP Phone

Support SIP,IAX2,H323 (SIP+IAX2 or SIP= +H323)

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l"> G.711 u/a; G729, G7231 5.3/6.3 Codec supported

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l">POE for optional

VOIP Gateway

YGW30A(2RJ45)

<= B style=3D"mso-bidi-font-weight: normal">YGW30B(2RJ45,FXO)

<= SPAN lang=3DEN-US style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Aria= l">2RJ45 Ports,Built-in Router,conference,

Auto-provison or updating by HTTP,FTP= or TFTP.

<= /SPAN>

VOIP Gateway

YGW50(1= FXS,SIP,IAX2)

<= B style=3D"mso-bidi-font-weight: normal">YGW60(2FXS,SIP,VPN)=

<= B style=3D"mso-bidi-font-weight: normal">YGW80(4FXS,SIP,VPN)=

Support Bridge and R= outer(NAT&NAPT)

G.711(A-law/U-law), = G.723.1,.729A/B,G.726,ILBC codec supported

http://www.yntx.com=   E-mail:sales@yntx.com  carol@yntx.com   MSN:carol_chang8009@hotmail.com

=0A=0A=0A
=E5=A5=BD=E7=8E=A9=E8=B4=BA=E5= =8D=A1=E7=AD=89=E4=BD=A0=E5=8F=91=EF=BC=8C=E9=82=AE=E7=AE=B1=E8=B4=BA=E5=8D= =A1=E5=85=A8=E6=96=B0=E4=B8=8A=E7=BA=BF=EF=BC=81 --0-758907300-1242004633=:2511-- From dwing@cisco.com Mon May 11 18:59: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 78ECA28C179 for ; Mon, 11 May 2009 18:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.059, 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 aUMYZckSAK5i for ; Mon, 11 May 2009 18:59:16 -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 07C273A6C44 for ; Mon, 11 May 2009 18:59:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,178,1241395200"; d="scan'208";a="184039216" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 May 2009 02:00:47 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4C20lot024766; Mon, 11 May 2009 19:00:47 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4C20lLE022949; Tue, 12 May 2009 02:00:47 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Behave WG'" References: <4A02B8B9.1000905@free.fr> Date: Mon, 11 May 2009 19:00:47 -0700 Message-ID: <021f01c9d2a5$778ee4e0$c5f0200a@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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnO/yY4v9nyq6xuSWqA5yf/uDQFYgAT9XqQANVW7fA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4345; t=1242093647; x=1242957647; 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=20DNSsec=20in=20IPv6-only-hosts=20=20&=20 discarding=20=20mapped=20AAAAs=20in=20DNS64 |Sender:=20; bh=U7dS5Eq0KZ1n+az3P80X41UYYxje3Pg7YfeaGp80v7Q=; b=TvCWnFZ9O64OgrDN3y48PPBQ3H1IouiT41XNsOSk8TejaevAfp4tcN85gB wnn5bz0t4YnvpLvQbQisG93e4Vv9BssGlxczp2rRcSeKiLwxY5UXKdoujgjS 6b0zc2nkYB; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 12 May 2009 01:59:17 -0000 R=E9mi, I have one more question about using v4-mapped as the well-known prefix = for the 6/4 translator. It appears, based on Iljitsh's testing last summer = [1] that when Windows Vista or MacOS Leopard are configured as IPv6-only = (that is, no IPv4 address), they won't send a v4-mapped IPv6 packet at all. This = seems a problem for using v4-mapped as the well-known prefix of the IPv6/IPv4 translator. [1] http://www.ietf.org/mail-archive/web/int-area/current/msg01476.html I do wonder, however, if configuring those hosts for IPv4 just to know = about 127.0.0.1 would be sufficient for their IP stacks to emit v4-mapped IPv6 addresses. =20 Iljitsch, would you have time to test that idea, or would you know = off-hand the answer from previous testing you did? -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Thursday, May 07, 2009 1:16 PM > To: 'R=E9mi Despr=E9s'; 'Behave WG' > Subject: RE: DNSsec in IPv6-only-hosts & discarding mapped=20 > AAAAs in DNS64 >=20 > =20 >=20 > > -----Original Message----- > > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 > > Sent: Thursday, May 07, 2009 3:32 AM > > To: Dan Wing; Behave WG > > Subject: Re: DNSsec in IPv6-only-hosts & discarding mapped=20 > > AAAAs in DNS64 > >=20 > > Dan Wing - le (m/j/a) 5/7/09 3:26 AM: > > > So, this means > > >=20 > > > 1. all networks deploying a translator for IPv6-initiated=20 > scenarios=20 > > > (Scenario 1 and Scenario 5) would have to use the=20 > well-known prefix > >=20 > > A. > > The scenario being discussed is "connecting an IPv6 network=20 > > to the IPv4 > > Internet", i.e. scenario (2) in Fred's draft on the Translation > > Framework. (I must confess I am confused with scenarios=20 > identified by > > numbers: Fred has only 4 of them.) >=20 > Yes, sorry about that. >=20 > I was going with the 4 we have in the charter, > http://www.ietf.org/html.charters/behave-charter.html, and the > other two defined by Dave Thaler in the Doodle poll, > http://www.doodle.com/participation.html?pollId=3D9qsdgt8r6kqk6zty >=20 > Our soon-to-be-updated charter will have all 6, because at > the San Francisco meeting the clear consensus was to work on > all 6. >=20 > > B. > > A network deploying a translator for IPv6-initiated scenarios should > > route to its NAT64s all packets whose destination start with: > > - the prefix(es) chosen by the ISP for its NAT64s (an ISP-specific > > prefix and/or, if a WKP different from that of mapped addresses is > > standardized, this WKP ) >=20 > Ok. >=20 > > - the mapped address prefix (or at least its 64 first bits,=20 > > i.e. ::/64, > > if /96 prefixes are not routed) > > > > > 2. all existing dual-stack hosts would see these published AAAA > > > record, which would require those hosts to use a=20 > translator if the=20 > > > host OS or its application prefer IPv6 over IPv4. What=20 > happens if=20 > > > there isn't a translator available to that user or its=20 > > > performance is poor? > >=20 > > When mapped-address AAAAs start being published, dual-stack=20 > hosts are > > expected to send datagrams having mapped addresses as destinations: > > - in IPv4 if an IPv4 address is available at the interface > > - in IPv6 otherwise (and then require a NAT64 to be provided=20 > > by the ISP) >=20 > Ok, thanks. =20 >=20 > So, I believe the timeframes would be aligned: An ISP that offers > only IPv6 addresses to subscribers will need to operate a translator > to access IPv4 anyway. >=20 > > > Are there other impacts, too? > >=20 > > DNS64s: > > - as long as dual-stack hosts cannot be expected to act as=20 > specified > > above, MUST discard mapped address records; >=20 > We would like dual-stack hosts to prefer native connectivity (rather > than translated connectivity). >=20 > > - after that, SHOULD forward them, at least if they are=20 > DNSsec signed. > >=20 > > IPv6-only applications should not artificially block mapped=20 > addresses > > destinations. >=20 > So applications and host OSs should ignore=20 > draft-itojun-v6ops-v4mapped-harmful, correct? >=20 > > Does this answer your questions? >=20 > Yes, thanks. Much clearer now. >=20 > And I see how this could work now. >=20 > -d >=20 From remi.despres@free.fr Tue May 12 07:31: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 75B433A6A16 for ; Tue, 12 May 2009 07:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.271, 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 OVzeMNZNhuXv for ; Tue, 12 May 2009 07:31:10 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id AABF73A6E2B for ; Tue, 12 May 2009 07:30:50 -0700 (PDT) Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 05A3394012F; Tue, 12 May 2009 16:32:11 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp1-g21.free.fr (Postfix) with ESMTP id 74BBD940165; Tue, 12 May 2009 16:32:08 +0200 (CEST) Message-ID: <4A098864.3060702@free.fr> Date: Tue, 12 May 2009 16:32:04 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: William Waites References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> <4A018B03.6070601@free.fr> <495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com> In-Reply-To: <495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: Dan Wing , Behave WG , Keith Moore , Xu Xiaohu , Fred Baker Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 12 May 2009 14:31:11 -0000 William Waites - le (m/j/a) 5/9/09 1:00 PM: > 2009/5/6 Rémi Després : >> There should be IMHO one more constraint: >> - If prefix64 is not the mapped-address prefix, synthesis of AAAAs > MUST >> be performed ONLY if no IPv4 address is locally enabled. >> (Otherwise, a dual-stack application in a dual-stack host that has an >> IPv4 address enabled may end up using IPv6 although IPv4 is possible and >> no NAT64 is available). > > I'd rather say something like, "ONLY if there is no IPv4 route to the > destination". That way if I have a private or island IPv4 network > address on an interface I can still use a translator to talk to remote > IPv4 hosts where there is no native connectivity. > > Note that on my "IPv6 only" hosts I still have, for example, 127.0.0.1 > configured on the loopback interface. It should be clear that in a dual-stack host having an IPv4 loopback interface is not sufficient for IPv4 to be enabled. Note that RFC 2765 defines an IPv4 enabled node as "A node which has an IPv4 protocol stack and is assigned one or more IPv4 addresses." It is worth clarifying that 127.0.0.1 must not be taken as an "assigned" address. Regards, RD From remi.despres@free.fr Tue May 12 09:05: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 BC6043A6981 for ; Tue, 12 May 2009 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.266, 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 GSuSb-j79a0A for ; Tue, 12 May 2009 09:05:06 -0700 (PDT) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 5E02C28C14A for ; Tue, 12 May 2009 09:05:04 -0700 (PDT) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 6952C8181B7; Tue, 12 May 2009 18:06:30 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp3-g21.free.fr (Postfix) with ESMTP id 23BE081809A; Tue, 12 May 2009 18:06:28 +0200 (CEST) Message-ID: <4A099E80.9040008@free.fr> Date: Tue, 12 May 2009 18:06:24 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dan Wing References: <4A02B8B9.1000905@free.fr> <021f01c9d2a5$778ee4e0$c5f0200a@cisco.com> In-Reply-To: <021f01c9d2a5$778ee4e0$c5f0200a@cisco.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: 'Behave WG' Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs in DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 12 May 2009 16:05:07 -0000 Dan Wing - le (m/j/a) 5/12/09 4:00 AM: > Rémi, > > I have one more question about using v4-mapped as the well-known prefix for > the 6/4 translator. It appears, based on Iljitsh's testing last summer [1] > that when Windows Vista or MacOS Leopard are configured as IPv6-only (that is, > no IPv4 address), they won't send a v4-mapped IPv6 packet at all. This seems > a problem for using v4-mapped as the well-known prefix of the IPv6/IPv4 > translator. > > [1] http://www.ietf.org/mail-archive/web/int-area/current/msg01476.html That's why it is proposed to DELAY the use of v4-mapped AAAAs in DNS servers. It has to be delayed until what was expected before Iljitsch made his tests becomes a reality, namely: R1: OSes, if they have IPv6 enabled and IPv4 disabled, send packets that have v4-mapped destinations in IPv6. (This makes sense, doesn't it?). Provisionally all IPv6-only networks should have DNS64s that, in addition to their synthetizing AAAAs, filter all v4-mapped RRs. Thus, all existing OSes work in hosts: - of IPv4-only networks (as usual) - of dual-stack networks (They receive A RRs and send IPv4 packets.) - of IPv6-only networks (Provided they use DNS64s, as they must, they never receive mapped addresses). When OSes have been updated, and ONLY THEN, IPv4-only servers can have their addresses protected not only for IPv4-enabled clients but also for clients in IPv6-only networks, provided: - these networks have NAT64s (as normally required) - these clients use DNSes that don't discard v4-mapped RRs (either those of their v6-only provider or some other). Operators of IPv6-only networks should have their DNSes stop discarding v4-mapped RRs ONLY WHEN they know that their hosts that may connect to IPv4-only servers have all been updated. Typically, operators of private sites would be first to do it. Hope it clarifies. Regards, RD From petithug@acm.org Tue May 12 18:08: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 908903A69EC for ; Tue, 12 May 2009 18:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.116, 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 ga3XWYtb6yE0 for ; Tue, 12 May 2009 18:08:11 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id C9B373A692E for ; Tue, 12 May 2009 18:08:11 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id D84F7FBC4022; Wed, 13 May 2009 01:09:42 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 2927CFBC4020 for ; Wed, 13 May 2009 01:09:40 +0000 (UTC) Message-ID: <4A0A1DD2.8040004@acm.org> Date: Tue, 12 May 2009 18:09:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: behave@ietf.org References: <20090307233001.655363A6AA8@core3.amsl.com> <49B30626.1070801@acm.org> In-Reply-To: <49B30626.1070801@acm.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-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, 13 May 2009 01:08:12 -0000 I am preparing a new version of this I-D. Meantime you can find here a compliant reference implementation of a TURN URI parser and resolver as described by this I-D: http://ietf.implementers.org/turn-uri-0.1.zip Marc Petit-Huguenin wrote: > This new version just fixes one small imprecision discovered when > working on a new reference implementation. The draft could use more > feedback and if someone wants to implement TURN URI, I will be more > than happy to provide my reference implementation and a set of NAPTR > and SRV RR that I am developing to help the testing. > > Also draft-wood-tae-specifying-uri-transports proposes a different > way to specify the transport parameter in an URI. I would be happy > to discuss if and how this can be applied to a TURN URI. > > > Changelog: > > o Fixed the contact email. > o Changed the IPR to trust200902. > o Added case for transport defined but unknown. > o Moved RFC 3958 to Normative References. > o Added study of [I-D.wood-tae-specifying-uri-transports] in > TODO list. > > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the 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-01.txt >> Pages : 12 >> Date : 2009-03-07 >> >> This document defines two URI schemes and the resolution mechanism to >> convert these URIs to a list of server transport addresses that can >> be used between a Traversal Using Relays around NAT (TURN) client and >> server. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-01.txt >> > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From wwaites@googlemail.com Wed May 13 03:45: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 2DD3D3A6BCC for ; Wed, 13 May 2009 03:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 fnEv+JdYAKX7 for ; Wed, 13 May 2009 03:45:08 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 158803A6885 for ; Wed, 13 May 2009 03:45:07 -0700 (PDT) Received: by fxm2 with SMTP id 2so556066fxm.37 for ; Wed, 13 May 2009 03:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=IZVYOSBV7zeGU7SaM/yNnEiSevO0cA6jqd/ZppTqYmo=; b=tOPX0ktuMmJp+I+2pmGInzghgFyHzUFO3BLTdCTWqTGUw5GJHEySkHv9X97CoW6Gvr tet6yXZ4CAk/AaE7gj/54V/En8Q7a8i20xmm40DJ1ieDIaWJ7vah5OnJmEKmAc0fn6tt 1yfZaFrBMLqq5vfw4OMAn/DDY6sgGdgTuSFgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wXkAwNGdN0gmzne/ZroxK+CLPQ0cS7iyexPRS3Ir0SBGRdK3FyeIZ9a8qASR/9pSij phicmMCMuPl/vgmmSsGy9oSghrcbOfwHHqZAi+G1rbjYRdk0t3syLMAqvuGDL2KXFNEA 4fLAVPe14Hl/drXlKyg0JMFHTkviX/LSrIY8g= MIME-Version: 1.0 Sender: wwaites@googlemail.com Received: by 10.204.71.210 with SMTP id i18mr497252bkj.48.1242211596210; Wed, 13 May 2009 03:46:36 -0700 (PDT) In-Reply-To: <4A098864.3060702@free.fr> References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> <4A018B03.6070601@free.fr> <495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com> <4A098864.3060702@free.fr> Date: Wed, 13 May 2009 12:46:36 +0200 X-Google-Sender-Auth: 31f3b79c24291d6a Message-ID: <495c4ae90905130346n7fa84708hb746f30110b9cf84@mail.gmail.com> From: William Waites To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Fred Baker , Behave WG , Keith Moore , Dan Wing , Xu Xiaohu Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 13 May 2009 10:45:09 -0000 2009/5/12 R=E9mi Despr=E9s : > It should be clear that in a dual-stack host having an IPv4 loopback > interface is not sufficient for IPv4 to be enabled. > > It is worth clarifying that 127.0.0.1 must not be taken as an "assigned" > address. That would help but I think we need to go further. A host may be connected to a private IPv4 network and yet only have IPv6 connectivity to the global Internet. In this circumstance address translation should be used for networks that are unreachable with IPv4. Unreachable means there is no route to them in the host's tables, having an IPv4 address or not is not sufficient information with which to make the decision. Cheers, -w --=20 William Waites +49 30 8894 9942 From root@core3.amsl.com Wed May 13 10:45: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 5B1DC3A6FC8; Wed, 13 May 2009 10:45: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: <20090513174501.5B1DC3A6FC8@core3.amsl.com> Date: Wed, 13 May 2009 10:45:01 -0700 (PDT) Cc: behave@ietf.org Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-uri-02.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, 13 May 2009 17:45: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-02.txt Pages : 12 Date : 2009-05-13 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-05-13103423.I-D@ietf.org> --NextPart-- From petithug@acm.org Wed May 13 10:51: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 278C428C206 for ; Wed, 13 May 2009 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.505 X-Spam-Level: X-Spam-Status: No, score=-101.505 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292, 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 ArH2yrotPslL for ; Wed, 13 May 2009 10:51:39 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 02AAA28C204 for ; Wed, 13 May 2009 10:50:51 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 6C5C6DC44056; Wed, 13 May 2009 17:52:23 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 5A9D1DC4404E for ; Wed, 13 May 2009 17:52:22 +0000 (UTC) Message-ID: <4A0B08D5.2040905@acm.org> Date: Wed, 13 May 2009 10:52:21 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 CC: behave@ietf.org References: <20090513174501.5B1DC3A6FC8@core3.amsl.com> In-Reply-To: <20090513174501.5B1DC3A6FC8@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-02.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, 13 May 2009 17:51:40 -0000 A version for the Amazon Kindle is available here: http://ietf.implementers.org/draft-ietf-behave-turn-uri-02.mobi Changelog: o Shorten the abstract so it does not overflow on the second page. o Added text to explicitly say that the resolution is only to create an allocation. o Fixed the default port for TLS in the example. o Changed some priority in the example for RFC3958 section 2.2.5. o Fixed the service/protocol order for the SRV RR in the example. o Removed reference to draft-wood-tae-specifying-uri-transports as it has an experimental status. Comments welcome. Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the 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-02.txt > Pages : 12 > Date : 2009-05-13 > > 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-02.txt > -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From philip_matthews@magma.ca Wed May 13 17:49: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 3A23A3A6A6A for ; Wed, 13 May 2009 17:49:30 -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 lXZG4p637pNz for ; Wed, 13 May 2009 17:49:29 -0700 (PDT) Received: from mail-05.primus.ca (mail10.primus.ca [216.254.141.177]) by core3.amsl.com (Postfix) with ESMTP id 650913A68F6 for ; Wed, 13 May 2009 17:49:29 -0700 (PDT) Received: from 72-254-145-67.client.stsn.net ([72.254.145.67] helo=[10.24.17.192]) by mail-05.primus.ca with esmtpa (Exim 4.69) (envelope-from ) id 1M4PA5-0004ql-1L; Wed, 13 May 2009 20:51:01 -0400 Message-Id: From: Philip Matthews To: Marc Petit-Huguenin In-Reply-To: <4A008EFE.2090106@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 13 May 2009 19:46:57 -0400 References: <4A008EFE.2090106@acm.org> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - 72-254-145-67.client.stsn.net ([10.24.17.192]) [72.254.145.67] Cc: Behave WG Subject: Re: [BEHAVE] Transport protocols in TURN X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 14 May 2009 00:49:30 -0000 You are right. There is nothing. Though I understand your point, I think it is rather late to be having this discussion. - Philip On Tue, 5-May-09, at 15:09 , Marc Petit-Huguenin wrote: > I cannot find in turn-14 what transport protocols are mandatory to > implement. Only one sentence in a non-normative section would > implies that the rules are the same than RFC 5389 (UDP and TCP > mandatory, TLS optional): > > Section 2.1, 5th paragraph: "TURN does not require TLS because..." > > I think that there should be some normative text about this. > > Thanks. > > -- > Marc Petit-Huguenin > Home: marc@petit-huguenin.org > Work: petithug@acm.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From mohamed.boucadair@orange-ftgroup.com Mon May 18 07:26: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 22E4128C306 for ; Mon, 18 May 2009 07:26:50 -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.126, BAYES_00=-2.599, HELO_EQ_FR=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 KIHCyi1E2VXC for ; Mon, 18 May 2009 07:26:43 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id DBAA428C2E4 for ; Mon, 18 May 2009 07:26:38 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 16:28:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9D7C4.DFF3A759" Date: Mon, 18 May 2009 16:28:12 +0200 Message-ID: <08BA2C59E081884DB2AAE4A0BE9D6DC10E37A2@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-boucadair-dhcpv6-shared-address-option-00.txt Thread-Index: AcnXuvajaxwYFxicSiq7hafMYLvLHwACdhwg From: To: X-OriginalArrivalTime: 18 May 2009 14:28:13.0347 (UTC) FILETIME=[E04CEF30:01C9D7C4] Subject: [BEHAVE] TR: I-D Action:draft-boucadair-dhcpv6-shared-address-option-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: Mon, 18 May 2009 14:26:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D7C4.DFF3A759 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 FYI. Comments are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org Envoy=E9 : lundi 18 mai 2009 15:15 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-dhcpv6-shared-address-option-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Dynamic Host Configuration Protocol (DHCPv6) Options = for Shared IP Addresses Solutions Author(s) : M. Boucadair, et al. Filename : draft-boucadair-dhcpv6-shared-address-option-00.txt Pages : 18 Date : 2009-05-18 This memo defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Options to be used in the context of shared IP address = solutions. In some deployment scenarios, DHCP (IPv4) cannot be used to = configure customer devices because only IPv6 capabilities are deployed = (e.g. DS-lite context or IPv6 Port Range). Therefore, DHCPv6 may be used to convey IPv4-related configuration information such = as Port Range and/or Port Extended IPv4 addresses. This document = defines also a DHCPv6 Option aiming to convey the IPv6 prefix to be used = to build IPv4-inferred IPv6 addresses required in the context of = stateless IPv4-in-IPv6 encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-dhcpv6-shared-address= -option-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_001_01C9D7C4.DFF3A759 Content-Type: application/octet-stream; name="draft-boucadair-dhcpv6-shared-address-option-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-boucadair-dhcpv6-shared-address-option-00.URL Content-Disposition: attachment; filename="draft-boucadair-dhcpv6-shared-address-option-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItZGhjcHY2LXNoYXJlZC1hZGRyZXNzLW9wdGlvbi0wMC50eHQNCg== ------_=_NextPart_001_01C9D7C4.DFF3A759-- From iljitsch@muada.com Tue May 19 12:27: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 06E003A69E4 for ; Tue, 19 May 2009 12:27:30 -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 o7DLlhIykJQ5 for ; Tue, 19 May 2009 12:27:29 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id EB7083A6971 for ; Tue, 19 May 2009 12:27:28 -0700 (PDT) Received: from [192.168.2.4] (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 n4JJSZcA015780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 19 May 2009 21:28:36 +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 v935.3) Date: Tue, 19 May 2009 21:28:45 +0200 References: <20090519190955.39F4828C362@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Subject: [BEHAVE] FTP64 -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, 19 May 2009 19:27:30 -0000 Hi all, Here's a new version of the FTP64 draft. It now specifies server and client behavior that allow FTP through a translator without an ALG. The text about how to do an ALG is also still in there, but now without taking a position on whether an ALG should be deployed or not. I removed a bunch of exotic cases from the ALG text and made it easier for clients to make the ALG go into transparent mode by issueing AUTH, regardless of how the server responds. Hopefully this will be more palatable to those who expressed criticism of the previous versions. Note that the text is a tad rough and I used strong requirements language that may not be appropriate for an informational document. Other than the question of whether this is the right way forward, we also need to consider whether we want this to be informational or an update to STD 9 and RFC 2428, in which case strong language could be reasonable. Begin forwarded message: > Filename: draft-van-beijnum-behave-ftp64 > Revision: 03 > Title: IPv6-to-IPv4 translation FTP considerations > Creation_date: 2009-05-19 > WG ID: Independent Submission > Number_of_pages: 8 > Abstract: > FTP has an active and a passive mode, both as original commands that > are IPv4-specific, and in extended, IP version agnostic commands. > The only FTP mode that works without changes through an IPv6-to-IPv4 > translator is extended passive However, many existing FTP servers > don't support this mode, and some clients don't ask for it. This > document describes the optimal server, client and middlebox (if any) > behavior to minimize this problem. http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-00 From fluffy@cisco.com Tue May 19 16:24: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 2B6263A68D0 for ; Tue, 19 May 2009 16:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 2hzIyH2O7HuE for ; Tue, 19 May 2009 16:24:17 -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 8C9A93A67D1 for ; Tue, 19 May 2009 16:24:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,218,1241395200"; d="scan'208";a="76749614" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 19 May 2009 23:25:48 +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 n4JNPmVJ003651; Tue, 19 May 2009 16:25:48 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4JNPlw0004078; Tue, 19 May 2009 23:25:47 GMT From: Cullen Jennings To: Simon Perreault In-Reply-To: <49FEF310.1000205@viagenie.ca> Impp: xmpp:cullenfluffyjennings@jabber.org References: <20090504134501.E2B3F3A7015@core3.amsl.com> <49FEF310.1000205@viagenie.ca> Message-Id: <43390F77-65EA-47B8-A3DC-6E9EFA1AC86D@cisco.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, 19 May 2009 17:25:46 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1640; t=1242775548; x=1243639548; 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=20[BEHAVE]=20I-D=20Action=3Adraft-ietf-be have-turn-tcp-03.txt |Sender:=20; bh=T8VWXlNo9eHWYVC24c8Rk7LNUbZPQfp50q+hgmHtgd8=; b=QMREjLO9QuVkGOdWZe4UiL2Org3NHvyFwXQyQIdUneynAUbEO/9rASu/9n 7/kPS/vjkmZvTG4eN7zCUNH0IYwMK8hdsp+NXTwxVb3PFOuzKGPXAfi3quLV PUxhQrvR2N; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Tue, 19 May 2009 23:24:19 -0000 One of the important design principals of TURN was that it could not be used to run a general server and you needed to know who the IP/port of who was going to connect to you before a turn server could form a connection to them. It seems like the changes to remove Listen removed this property - am I mis reading this? I would not want to loose this property. On May 4, 2009, at 7:52 AM, Simon Perreault wrote: > Internet-Drafts@ietf.org wrote, on 04/05/09 09:45 AM: >> Title : Traversal Using Relays around NAT (TURN) >> Extensions for TCP Allocations >> Author(s) : S. Perreault, J. Rosenberg >> Filename : draft-ietf-behave-turn-tcp-03.txt >> Pages : 13 >> Date : 2009-05-04 > > Here's the change log: > > - Removed Listen and Connect limits. > - Removed the Listen method since an allocation now listens by > default. > - Added a note to the effect that TURN-TCP does not keep data > connections alive. > - Added a small Security Considerations section (adapted from TURN- > IPv6). > - Updated references. > - Picked numbers for attributes and responses. > > The diff is here: > http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-behave-turn-tcp-03.txt > > All outstanding issues have been fixed. > > Simon > -- > STUN/TURN server --> http://numb.viagenie.ca > Interplanetary news --> http://reeves.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue May 19 17:14: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 42F503A6DE9 for ; Tue, 19 May 2009 17:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.307, 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 eZBIeWU-nVRf for ; Tue, 19 May 2009 17:13:59 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 3F3C53A6CF5 for ; Tue, 19 May 2009 17:13:59 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id D978B29E15C9; Tue, 19 May 2009 20:15:35 -0400 (EDT) Received: from 203-178-157-201.ip.sipit.net (unknown [IPv6:2001:200:0:ff00:20a:95ff:febc:7f66]) by jazz.viagenie.ca (Postfix) with ESMTP id 14F4529E159A; Tue, 19 May 2009 20:15:34 -0400 (EDT) Message-ID: <4A134BA5.2090109@viagenie.ca> Date: Wed, 20 May 2009 09:15:33 +0900 From: Simon Perreault User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cullen Jennings References: <20090504134501.E2B3F3A7015@core3.amsl.com> <49FEF310.1000205@viagenie.ca> <43390F77-65EA-47B8-A3DC-6E9EFA1AC86D@cisco.com> In-Reply-To: <43390F77-65EA-47B8-A3DC-6E9EFA1AC86D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Wed, 20 May 2009 00:14:00 -0000 Cullen Jennings wrote: > One of the important design principals of TURN was that it could not be > used to run a general server and you needed to know who the IP/port of > who was going to connect to you before a turn server could form a > connection to them. It seems like the changes to remove Listen removed > this property - am I mis reading this? I would not want to loose this > property. Cullen, Thanks for your comments. This important property is still present. What the server does is accept (in the TCP sense) any incoming connection on the relayed address. One the connection is accepted, the server checks the TURN permissions and then either drops the connection or relays it to the client. So the client still has to install a TURN permission to receive anything from a peer. This is necessary because TURN servers implemented using the BSD API cannot know the address of the peer, and hence check permissions, until they accept() the connection. Thanks, Simon -- STUN/TURN server --> http://numb.viagenie.ca Interplanetary news --> http://reeves.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From fluffy@cisco.com Tue May 19 17:45: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 89E203A6AB3 for ; Tue, 19 May 2009 17:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 E+xfoSexiMBA for ; Tue, 19 May 2009 17:45:01 -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 9C5853A6F00 for ; Tue, 19 May 2009 17:45:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,218,1241395200"; d="scan'208";a="163145922" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 May 2009 00:46:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4K0kaNT027690; Tue, 19 May 2009 17:46:36 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4K0kZLv015854; Wed, 20 May 2009 00:46:36 GMT From: Cullen Jennings To: "Simon Perreault" In-Reply-To: <4A134BA5.2090109@viagenie.ca> Impp: xmpp:cullenfluffyjennings@jabber.org References: <20090504134501.E2B3F3A7015@core3.amsl.com> <49FEF310.1000205@viagenie.ca> <43390F77-65EA-47B8-A3DC-6E9EFA1AC86D@cisco.com> <4A134BA5.2090109@viagenie.ca> Message-Id: 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, 19 May 2009 18:46:35 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1369; t=1242780396; x=1243644396; c=relaxed/simple; s=sjdkim4002; 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=20[BEHAVE]=20I-D=20Action=3Adraft-ietf-be have-turn-tcp-03.txt |Sender:=20; bh=57sI+vtvzZbIgdNGDxndmCV3vGj35Osfz9tY+3npg/c=; b=ByIOjK5/NvUhBrPsdg0ZoAwYamyaq+qLdkF42lTQFue+sC+ObV06DH6oJo eejQLnLhnSoZ2k3Gltc1Vr7m6CvvWEq4YQY+5DlYqHJtwUa5vcDeZXoN3SLQ 7wF5RGb68i; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-tcp-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: Wed, 20 May 2009 00:45:02 -0000 On May 19, 2009, at 6:15 PM, Simon Perreault wrote: > Cullen Jennings wrote: > > One of the important design principals of TURN was that it could > not be > > used to run a general server and you needed to know who the IP/ > port of > > who was going to connect to you before a turn server could form a > > connection to them. It seems like the changes to remove Listen > removed > > this property - am I mis reading this? I would not want to loose > this > > property. > > Cullen, > > Thanks for your comments. > > This important property is still present. What the server does is > accept > (in the TCP sense) any incoming connection on the relayed address. > > One the connection is accepted, the server checks the TURN permissions > and then either drops the connection or relays it to the client. So > the > client still has to install a TURN permission to receive anything > from a > peer. > > This is necessary because TURN servers implemented using the BSD API > cannot know the address of the peer, and hence check permissions, > until > they accept() the connection. > Thanks for the explination. Works for me. > > > Thanks, > Simon > -- > STUN/TURN server --> http://numb.viagenie.ca > Interplanetary news --> http://reeves.viagenie.ca > vCard 4.0 --> http://www.vcarddav.org > From dwing@cisco.com Tue May 19 20:18: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 DD1F43A6BE2 for ; Tue, 19 May 2009 20:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 K92Zhal6VQgy for ; Tue, 19 May 2009 20:18:04 -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 214EC3A683B for ; Tue, 19 May 2009 20:18:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,218,1241395200"; d="scan'208";a="167275966" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 20 May 2009 03:19:41 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4K3JfVo032634; Tue, 19 May 2009 20:19:41 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4K3JeZ4019135; Wed, 20 May 2009 03:19:40 GMT From: "Dan Wing" To: "'Behave WG'" Date: Tue, 19 May 2009 20:19:39 -0700 Message-ID: <02c001c9d8f9$cfd68a90$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: AcnY+c+iaTsD8sAbSJibYljWR0vlag== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=421; t=1242789581; x=1243653581; 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:=20interim=20meeting=3A=20Wednesday,=207am=20PDT |Sender:=20; bh=aLHJRAeQCl5dZTIFcOAc2L94GOAOexkCwVeWfaGLzIs=; b=Qae6x2xOzzhJAUUGHU0HtNlkfzDJZ0y3ytJjNKyx1c+Kg5VOQ8Mqb9Sc/b /cu24/5p8Tf+4yLDf2rgTm28KBbDBjmpjG2s5dkPkePgiQMz/qowRzGwBDuh SVlb3HU8lN; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave-chairs@tools.ietf.org Subject: [BEHAVE] interim meeting: Wednesday, 7am PDT X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 20 May 2009 03:18:11 -0000 A reminder: we are having a teleconference interim meeting in about 11 hours (7am Pacific Daylight Time). Details at http://trac.tools.ietf.org/wg/behave/trac/wiki. Agenda (see URL above for links and what-not). New milestones, updated charter 6/4 translation document organization 6/4 translation on a host translation open issues (e.g., fragmentation) DNS-ALG open issues FTP ALG -d From remi.despres@free.fr Wed May 20 02:54: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 C73BA3A69EF for ; Wed, 20 May 2009 02:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.316, 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 l0Ci3MOef0VM for ; Wed, 20 May 2009 02:54:46 -0700 (PDT) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id D9BE93A6BFC for ; Wed, 20 May 2009 02:54:43 -0700 (PDT) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 381834B00CA; Wed, 20 May 2009 11:56:14 +0200 (CEST) Received: from RD-Mac.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp2-g21.free.fr (Postfix) with ESMTP id B17AE4B0162; Wed, 20 May 2009 11:56:11 +0200 (CEST) Message-ID: <4A13D3B7.10407@free.fr> Date: Wed, 20 May 2009 11:56:07 +0200 From: =?ISO-8859-15?Q?R=E9mi_Despr=E9s?= User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: William Waites References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> <4A018B03.6070601@free.fr> <495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com> <4A098864.3060702@free.fr> <495c4ae90905130346n7fa84708hb746f30110b9cf84@mail.gmail.com> In-Reply-To: <495c4ae90905130346n7fa84708hb746f30110b9cf84@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: Fred Baker , Behave WG , Keith Moore , Dan Wing , Xu Xiaohu Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 20 May 2009 09:54:46 -0000 William Waites - le (m/j/a) 5/13/09 12:46 PM: > 2009/5/12 Rémi Després : >> It should be clear that in a dual-stack host having an IPv4 >> loopback interface is not sufficient for IPv4 to be enabled. >> >> It is worth clarifying that 127.0.0.1 must not be taken as an >> "assigned" address. > > That would help but I think we need to go further. A host may be > connected to a private IPv4 network and yet only have IPv6 > connectivity to the global Internet. IMHO, no one should deploy an IPv4 network with global IPv6 connectivity and no IPv4 NAT somewhere to provide also IPv4 connectivity (be it limited because of NAT traversal). I therefore don't see (so far) a need for any additional complexity for this scenario. > In this circumstance address translation should be used for networks > that are unreachable with IPv4. Unreachable means there is no route > to them in the host's tables, having an IPv4 address or not is not > sufficient information with which to make the decision. > > Cheers, -w From philip_matthews@magma.ca Wed May 20 05: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 61CEC3A69A8 for ; Wed, 20 May 2009 05:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtQsjND8eKxb for ; Wed, 20 May 2009 05:45:40 -0700 (PDT) Received: from mail-01.primus.ca (mail10.primus.ca [216.254.141.177]) by core3.amsl.com (Postfix) with ESMTP id F19853A6884 for ; Wed, 20 May 2009 05:45:39 -0700 (PDT) Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-01.primus.ca with esmtpa (Exim 4.69) (envelope-from ) id 1M6lCW-0006C1-0N; Wed, 20 May 2009 08:47:16 -0400 Message-Id: From: Philip Matthews To: Iljitsch van Beijnum In-Reply-To: <006101c9cf56$e965cdb0$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 v929.2) Date: Wed, 20 May 2009 08:47:13 -0400 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <082801c9ce9d$ddd215d0$c5f0200a@cisco.com> <085c01c9ceaf$88044670$c5f0200a@cisco.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.929.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154] Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 20 May 2009 12:45:41 -0000 Chiming in late here ... My quick thoughts on this subject are that what is important is what the major browsers do when given a link of the form: ftp://.... If someone who doesn't know much about computers clicks on such a link, we would like it to work. Do these browsers do "EPSV" or "PASV" or what? The people who explicitly run FTP are somewhat computer-literate, and will more able to find work-arounds if things fail. - Philip On Thu, 7-May-09, at 17:00 , Dan Wing wrote: > > >> -----Original Message----- >> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >> Sent: Thursday, May 07, 2009 3:31 AM >> To: Dan Wing >> Cc: 'Behave WG' >> Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? >> >> Ok, before we delve into the details, my conclusion after all this >> experimentation is that the wide variation in FTP behavior, >> some of it legitimate but problematic in the case of >> NATs/firewalls/NAT64s/SIITs, >> some of it just plain broken. I think we can do a reasonable job of >> smoothing over all of this with an ALG. On the other hand, we could >> update RFC 2428, or even RFC 959, in order to provide guidance to >> implementers to update their implementations to work better >> in today's and tomorrow's internet. >> >> Obviously the former makes sense if we consider FTP a legacy >> application that isn't going to be maintained in most cases, >> while the latter is more appropriate if we deem FTP to be a >> protocol that we want to stick around in the future. >> >> Dan: can we have some discussion about this in the upcoming remote >> interim meeting? > > Yes, we will put FTP on the agenda - but towards the end. > > -d > > >> I guess we need to ask the apps people for their input. >> >> On 7 mei 2009, at 3:02, Dan Wing wrote: >> >>> 230 Anonymous user logged in. >>> EPSV >>> 229 Entering Extended Passive Mode (|||2067|) >>> LIST >> >>> I waited a few seconds, then continued: >> >>> ABOR >>> 225 ABOR command successful. >> >> Hm, it probably makes more sense to establish the data connection >> first and only then issue commands like LIST. Not sure if it would >> make a difference, though: >> >>> That 225 came back immediately. >> >>> PASV >>> 425 Can't open data connection. >>> PASV >> >>> It then disconnected the control channel. >> >> Great. So this doesn't solve the issue. >> >> However, if we accept client changes then we can of course just let >> the client reconnect and then use PASV rather than EPSV. >> >>> With other FTP servers, the response to ABOR didn't come back >>> immediately. >> >> I believe they try to first shut down the data connection in an >> orderly fashion. >> >>>> (Did you check if any >>>> servers allowed you to log in but didn't handle PASV successfully?) >> >>> Yes. Of the list of about 5000 anonymous FTP sites in >> 2003, 107 of >>> them >>> accepted anonymous logins but didn't give a directory >> listing using >>> PASV. >> >> Ugh. The numbers: >> >> Filtering out anything that has "Can't " except "Can't open" leaves >> 2598 entries >> >> EPSV + PASV: 1626, 62.6% >> No EPSV, but PASV: 972, 37.4% >> No EPSV, no PASV: 107, 4.1% >> >> I guess losing compatibility with 4.1% broken servers isn't >> the end of >> the world, especially as none of them jump out as high profile >> destinations. >> >> Just for fun, here's what an IPv6 server says when you try to do >> PASV: >> >> ftp> quote PASV >> ---> PASV >> 227 Entering Passive Mode (0,0,0,0,237,30) >> ftp> quote LIST >> ---> LIST >> 150 Here comes the directory listing. >> 226 Directory send OK. >> >> Another one: >> >> ftp> quote PASV >> 227 Entering Passive Mode (9,237,25). >> ftp> quote LIST >> 150 Opening ASCII mode data connection for file list >> 226 Transfer complete. >> >> With the above two, I could simply connect to their IPv6 address on >> the indicated port and then get the directory listing. However, in >> this case that didn't work: >> >> ftp> quote PASV >> ---> PASV >> 227 Entering Passive Mode (,238,133). >> >> (The servers were ftp.nluug.nl, ftp.ripe.net and ftp.apnic.net.) > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From Remi.Denis-Courmont@nokia.com Wed May 20 06:05: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 776013A6C56 for ; Wed, 20 May 2009 06:05:21 -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=[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 m7IXn8Wh+U4h for ; Wed, 20 May 2009 06:05:20 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 45AAD3A6BE4 for ; Wed, 20 May 2009 06:05:20 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4KD6gdw002875; Wed, 20 May 2009 16:06:48 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 16:06:44 +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); Wed, 20 May 2009 16:06:43 +0300 Received: from leon.remlab.net (esdhcp03589.research.nokia.com [172.21.35.89]) by mgw-da02.ext.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4KD6cZk031404; Wed, 20 May 2009 16:06:39 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: behave@ietf.org Date: Wed, 20 May 2009 16:07:44 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.28.10; KDE/4.2.2; i686; ; ) References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.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: <200905201607.44927.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 20 May 2009 13:06:43.0890 (UTC) FILETIME=[D2C88120:01C9D94B] X-Nokia-AV: Clean Cc: ext Philip Matthews , Dan Wing Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 20 May 2009 13:05:21 -0000 On Wednesday 20 May 2009 15:47:13 ext Philip Matthews wrote: > My quick thoughts on this subject are that what is important is what > the major browsers do when given a link of the form: > ftp://.... > If someone who doesn't know much about computers clicks on such a > link, we would like it to work. > Do these browsers do "EPSV" or "PASV" or what? In the envisioned scenario, the FTP client is running on an IPv6 (only) hos= t.=20 Using EPSV is hence the *only* valid thing to do. Needless to say, there ar= e=20 =46TP client implementations that do not support IPv6. From my memories, so= me=20 send malformatted PASV requests and some simply fail to establish the contr= ol=20 channel in the first place. But of course, if you deploy an IPv6-only network, you assume that your=20 customers are IPv6-capable. In fact, it is not unlikely that a network wher= e=20 you can afford such control will have an HTTP proxy handling outgoing FTP=20 connections (and the issue is moot). Anyway, while we cannot assume that an IPv4 FTP server supports EPSV, we ca= n=20 assume that an IPv6 FTP client does. =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From iljitsch@muada.com Wed May 20 06:07: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 BEE2A3A69C5 for ; Wed, 20 May 2009 06:07:14 -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 FB2gCFtgfeCJ for ; Wed, 20 May 2009 06:07:14 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id CCA623A69A8 for ; Wed, 20 May 2009 06:07:13 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4KD7mEq021645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 May 2009 15:07:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Philip Matthews 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 v935.3) Date: Wed, 20 May 2009 15:07:58 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <082801c9ce9d$ddd215d0$c5f0200a@cisco.com> <085c01c9ceaf$88044670$c5f0200a@cisco.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG , Dan Wing Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 20 May 2009 13:07:14 -0000 On 20 mei 2009, at 14:47, Philip Matthews wrote: > My quick thoughts on this subject are that what is important is what > the major browsers do when given a link of the form: > ftp://.... > If someone who doesn't know much about computers clicks on such a > link, we would like it to work. > Do these browsers do "EPSV" or "PASV" or what? I tried Safari beta 4 and Firefox 3 on my Mac and both did PASV for v4 and EPSV for v6. However, I don't think the browser case is the most relevant one. Yes, it's important, but basically this is just doing with FTP what can also happen over HTTP. An important use case of FTP is uploading files, which browsers can't do with FTP AFAIK. From dwing@cisco.com Wed May 20 16:47: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 EBAD23A6858 for ; Wed, 20 May 2009 16:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.055, 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 nG54pk0n0G14 for ; Wed, 20 May 2009 16:47:52 -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 CF3633A6821 for ; Wed, 20 May 2009 16:47:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,224,1241395200"; d="scan'208";a="167705529" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 20 May 2009 23:49:30 +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 n4KNnUrQ021598; Wed, 20 May 2009 16:49:30 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4KNnUbM026665; Wed, 20 May 2009 23:49:30 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" , References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> <200905201607.44927.remi.denis-courmont@nokia.com> Date: Wed, 20 May 2009 16:49:30 -0700 Message-ID: <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <200905201607.44927.remi.denis-courmont@nokia.com> Thread-Index: AcnZS9lnu/BeHuLLQmKAJOZxXG+XCwAVx1Tw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2568; t=1242863370; x=1243727370; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=1eeWeuroQDRRVxTnvCUVhL5QqYfmLOnq6b62tIsbSEo=; b=qzJsBicHXL7yfPJsYJz7FYH4bWjV52GV8w353NSy+Yis9ME6KdokwGgNp1 U1r3507GLhfJguySDQYGA2hytTPfD/XSIz7Iuxi15ndyAWLzqTNVSq+FaScU YdJuyWxO5B5zwIQ9eis4ar67V8g3s3ufpyFFjqn5aqiLcyJ6M45gQ=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ext Philip Matthews' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 20 May 2009 23:47:54 -0000 > On Wednesday 20 May 2009 15:47:13 ext Philip Matthews wrote: > > My quick thoughts on this subject are that what is important is what > > the major browsers do when given a link of the form: > > ftp://.... > > If someone who doesn't know much about computers clicks on such a > > link, we would like it to work. > > Do these browsers do "EPSV" or "PASV" or what? > > In the envisioned scenario, the FTP client is running on an > IPv6 (only) host. > Using EPSV is hence the *only* valid thing to do. It could use PASV. If EPSV fails, and the FTP client knows the IPv6 prefix of its 6/4 translator, the FTP client can send PASV, parse the response, and open an IPv6 socket that will be translated. For whatever it's worth, I mentioned this in draft-wing-behave-learn-prefix-02: So far, the authors have identified the following applications which can benefit knowing the IPv6 prefix of the host's IPv6/IPv4 translator: ... o In the absence of an FTP ALG in the IPv6/IPv4 translator, IPv6 FTP clients that conect to an IPv4 FTP server which does not support EPSV [RFC2428]. > Needless to say, there are FTP client implementations that > do not support IPv6. From my memories, some > send malformatted PASV requests and some simply fail to > establish the control channel in the first place. Yep. But those don't work with FTP clients behind IPv4 NATs, so they really aren't terribly interesting. I mean, we shouldn't try to make them work with FTP clients that emit EPSV. > But of course, if you deploy an IPv6-only network, you assume > that your customers are IPv6-capable. In fact, it is not unlikely > that a network where you can afford such control will have > an HTTP proxy handling outgoing FTP connections (and the issue > is moot). Many IPv6-only networks are expected to be quite large: wireless networks (which will include tethered PCs which might run FTP clients), and there is already a large IPv6- only network deployed in China (CERNET2) with thousands of clients. This would make such a proxy very busy. And as you know, it is awkward to reconfigure applications (such as an FTP client or HTTP client) to use different application-level proxies when connecting/disconnecting with different networks (e.g., ftp-proxy.comcast.net, proxy.att.net, ftp-proxy-sj.cisco.com, ftp-proxy.starbucks.com). > Anyway, while we cannot assume that an IPv4 FTP server > supports EPSV, we can assume that an IPv6 FTP client > does. Agreed. -d From dwing@cisco.com Wed May 20 16:47: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 452893A6D58 for ; Wed, 20 May 2009 16:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 6wb7sSkkPe26 for ; Wed, 20 May 2009 16:47:55 -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 20C573A6BD6 for ; Wed, 20 May 2009 16:47:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,224,1241395200"; d="scan'208";a="167705541" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 20 May 2009 23:49:33 +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 n4KNnW1m021642; Wed, 20 May 2009 16:49:32 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4KNnUbN026665; Wed, 20 May 2009 23:49:32 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" , "'Philip Matthews'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <082801c9ce9d$ddd215d0$c5f0200a@cisco.com> <085c01c9ceaf$88044670$c5f0200a@cisco.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> Date: Wed, 20 May 2009 16:49:32 -0700 Message-ID: <025f01c9d9a5$9fb74870$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 In-Reply-To: Thread-Index: AcnZTBbMJ0MQzlx6QMiWKNjvYw2qiAAVUK5w DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1629; t=1242863373; x=1243727373; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=rykPx3YEvzN4kHgrLfjqeQiC9cyAlUs5nDbd6lJ302g=; b=MmV3fpYCfx+K1y2Cy/f4qf1ACNC9iC4GJHWmcr6paHY80be40t4bswK23M XzpjpuRUQFwvx4ILh4g/WP5ChF0IRWVuA9XXxh3YDeCyMu6sMt+iCrEAAU6h /V3jBiOQFE0dOw4UFfhvAUwooOHL5rUtDgkjlloUD9df5iVoCeF+Y=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 20 May 2009 23:47:56 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, May 20, 2009 6:08 AM > To: Philip Matthews > Cc: Behave WG; Dan Wing > Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? > > On 20 mei 2009, at 14:47, Philip Matthews wrote: > > > My quick thoughts on this subject are that what is > important is what > > the major browsers do when given a link of the form: > > ftp://.... > > If someone who doesn't know much about computers clicks on such a > > link, we would like it to work. > > Do these browsers do "EPSV" or "PASV" or what? > > I tried Safari beta 4 and Firefox 3 on my Mac and both did > PASV for v4 and EPSV for v6. > > However, I don't think the browser case is the most relevant > one. Yes, it's important, but basically this is just doing with > FTP what can also happen over HTTP. Downloading from anonymous FTP is the most common use of FTP, and we certainly need that to work. And although we can argue that "content providers should just make their content available on HTTP", that is not likely to work. With that logic, content providers would also make their content available on IPv6 -- but that has not yet happened. We have a chicken-and-egg problem: there is still FTP content that needs to be accessible. The FTP64 ALG, like all of the translation being done in BEHAVE, is the 'incubator', so to speak. > An important use case of FTP is uploading > files, which browsers can't do with FTP AFAIK. I found this cute little Firefox add-on today, http://fireftp.mozdev.org/ -d From dwing@cisco.com Wed May 20 18:32: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 BD6AF3A698C for ; Wed, 20 May 2009 18:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 7r1k2iD8lpow for ; Wed, 20 May 2009 18:32:15 -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 6D3A33A682A for ; Wed, 20 May 2009 18:32:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,224,1241395200"; d="scan'208";a="77008972" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 21 May 2009 01:33:53 +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 n4L1XrWf012247 for ; Wed, 20 May 2009 18:33:53 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4L1XqkM009076 for ; Thu, 21 May 2009 01:33:52 GMT From: "Dan Wing" To: "'Behave WG'" Date: Wed, 20 May 2009 18:33:52 -0700 Message-ID: <02cb01c9d9b4$33089170$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: AcnZtDJE+MQl9mz1RauCnQXcDoCEPA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=368; t=1242869633; x=1243733633; 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:=20interim=20meeting=20minutes |Sender:=20; bh=d0GhyZy8dlpr5S101F8kPH5azka1tcXDf9kW8qr964Y=; b=iUHWzAdlQl0CEoKDHjVLVMZCtYaMNjiTWdiCqw3zZKuqTodAJVMSfQxMqI oNIzdgPokbSh9emq7T+JiMJcJozzUJXbeP3fgzP8CSCmYl6Zh2oBGV62EIIO cwzkIlKXEb; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 01:32:16 -0000 Minutes are at ftp://ftpeng.cisco.com/dwing/behave/minutes.txt. That same directory has all the presentations as PDF files. Please let me know if the minutes need any adjustments. Thanks to John Leslie and Philip Matthews for taking minutes! At the top of the minutes are links to play back the WebEx recording, including slides that were presented. -d From iljitsch@muada.com Thu May 21 02:55: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 81D4128C0EA for ; Thu, 21 May 2009 02:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=-0.815, 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 Bki5cXyBAgKc for ; Thu, 21 May 2009 02:55:15 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D2DBF3A6F3F for ; Thu, 21 May 2009 02:55:14 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4L9tixV028564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 May 2009 11:55:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <7AC09AC5-5535-43DD-B2F2-CC2FE8AD44B3@muada.com> From: Iljitsch van Beijnum To: Dan Wing In-Reply-To: <025e01c9d9a5$9e58f0f0$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 v935.3) Date: Thu, 21 May 2009 11:55:56 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: behave@ietf.org, 'ext Philip Matthews' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 09:55:16 -0000 On 21 mei 2009, at 1:49, Dan Wing wrote: >> Using EPSV is hence the *only* valid thing to do. > It could use PASV. If EPSV fails, and the FTP client knows the > IPv6 prefix of its 6/4 translator, the FTP client can send PASV, > parse the response, and open an IPv6 socket that will be > translated. In the ftp64 -03 draft there is an even simpler solution: clients are advised to simply connect to the same address that is the destination of the control channel connection, and ignore the address provided in the server's response to the PASV command. (You wouldn't happen to have correlated the PASV response address with the control channel address in your big FTP server test, would you?) >> Needless to say, there are FTP client implementations that >> do not support IPv6. From my memories, some >> send malformatted PASV requests and some simply fail to >> establish the control channel in the first place. > Yep. But those don't work with FTP clients behind IPv4 NATs, ??? If you have an FTP client that uses the old socket API it can't talk over IPv6. So that case is out. If you have an FTP client that manages to connect over IPv6 but isn't aware of EPSV and EPRT, it would issue a PASV command. The client issuing the command wouldn't be a problem, because there are no arguments or other IP version specific issues with the _command_. Only when the server responds there will be trouble. I tried this with a few IPv6 FTP servers which respond in various ways that don't allow for setting up the data connection successfully. However, if the server is behind a NAT64 then the server will simply respond with its IPv4 address, which the client will then parse without issue. But then the client needs to connect to an IPv4 destination which of course doesn't work in this case. With IPv4 on both sides and a NAT44 in the middle there are no issues, the client simply connects to the server-supplied IPv4 address. Only with PORT the NAT has to cooperate and allow for the data connection to be set up from the server to the client. > And as you know, it is awkward to reconfigure applications > (such as an FTP client or HTTP client) to use > different application-level proxies when connecting/disconnecting > with different networks (e.g., ftp-proxy.comcast.net, > proxy.att.net, ftp-proxy-sj.cisco.com, ftp-proxy.starbucks.com). There is automatic proxy discovery/configuration and large scale proxies have been known to work. If the proxy is only used for FTP I don't think this is an issue, as only a small fraction of the internet's traffic is FTP. Note that Apache can be an FTP proxy: http://httpd.apache.org/docs/2.2/mod/mod_proxy_ftp.html However, it only supports downloads, not uploads, which brings us to: On 21 mei 2009, at 1:49, Dan Wing wrote: >> However, I don't think the browser case is the most relevant >> one. Yes, it's important, but basically this is just doing with >> FTP what can also happen over HTTP. > Downloading from anonymous FTP is the most common use of FTP, > and we certainly need that to work. Right, it's important, but it's also easy, you can do this with the Apache proxy if all else fails. > We have a chicken-and-egg problem: there is still FTP content > that needs to be accessible. The FTP64 ALG, like all of > the translation being done in BEHAVE, is the 'incubator', so > to speak. Not sure what you mean here... >> An important use case of FTP is uploading >> files, which browsers can't do with FTP AFAIK. > I found this cute little Firefox add-on today, > http://fireftp.mozdev.org/ Right. There's also a bunch of Java FTP clients that you can run from your browser. But my point is that we need to look beyond the browser, because the browser in and of itself won't do uploads, and FTP support without uploads doesn't make sense. From iljitsch@muada.com Thu May 21 03:13: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 024E03A6A48 for ; Thu, 21 May 2009 03:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 XLgih5rmzspj for ; Thu, 21 May 2009 03:13:53 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 08A273A69E5 for ; Thu, 21 May 2009 03:13:52 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4LAE3nE028637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 May 2009 12:14:04 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> From: Iljitsch van Beijnum To: Dan Wing In-Reply-To: <02cb01c9d9b4$33089170$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 v935.3) Date: Thu, 21 May 2009 12:14:14 +0200 References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: 'Behave WG' Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 10:13:54 -0000 About the terminology: I suggest NAT64 for stateful and TRANS64 for stateless. (And NAT44, NAT46, NAT66 as well as TRANS46. Maybe even NAT464 if we need it to avoid NAT444 but please no NAT646.) From the minutes, I would remove this and simply point to the slides or the draft, because the text is slightly inaccurate and no point in trying to fix it with good text already out there: Iljitsch: just finished yesterday, hope you had chance to look at it, two folks didn't like "ALG", three options, ALG is third Iljitsch: ALG slide, go transparent after AUTH, stateless, stateful Iljitsch: Servers slide, must support EPSV, but firewall problem, must be able to disable EPSV, control channel adrs in PASV Iljitsch: Clients slide, must EPSV, windows command-line doesn't support EPSV, retry PASV after EPSV failure, ignore ??, no args to EPSV From xing@cernet.edu.cn Thu May 21 03:54: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 6424D3A6AF3 for ; Thu, 21 May 2009 03:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.126 X-Spam-Level: X-Spam-Status: No, score=0.126 tagged_above=-999 required=5 tests=[AWL=0.029, 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 MNZqbvdNr+LC for ; Thu, 21 May 2009 03:54:56 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 022CD3A696E for ; Thu, 21 May 2009 03:54:55 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.111]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54a158c17; Thu, 21 May 2009 18:56:31 +0800 Message-ID: <4A153355.9000401@cernet.edu.cn> Date: Thu, 21 May 2009 18:56:21 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> In-Reply-To: <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.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: UTtwFHWB Cc: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 10:54:57 -0000 Iljitsch van Beijnum 写é“: > About the terminology: > > I suggest NAT64 for stateful and TRANS64 for stateless. (And NAT44, > NAT46, NAT66 as well as TRANS46. Maybe even NAT464 if we need it to > avoid NAT444 but please no NAT646.) > The problem is that the stateless scheme (IVI) supports both TRANS46 and TRANS64, how to name it? xing > From the minutes, I would remove this and simply point to the slides > or the draft, because the text is slightly inaccurate and no point in > trying to fix it with good text already out there: > > Iljitsch: just finished yesterday, hope you had chance to look at it, > two folks > didn't like "ALG", three options, ALG is third > Iljitsch: ALG slide, go transparent after AUTH, stateless, stateful > Iljitsch: Servers slide, must support EPSV, but firewall problem, must > be able > to disable EPSV, control channel adrs in PASV > Iljitsch: Clients slide, must EPSV, windows command-line doesn't > support EPSV, > retry PASV after EPSV failure, ignore ??, no args to EPSV > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From iljitsch@muada.com Thu May 21 07:08: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 C330F28C0DE for ; Thu, 21 May 2009 07:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 EA0mMsRTBO3M for ; Thu, 21 May 2009 07:08:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id C0C9E28C0D8 for ; Thu, 21 May 2009 07:08:42 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4LE7rEc029966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 May 2009 16:07:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@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: Thu, 21 May 2009 16:08:05 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) Subject: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 14:08:43 -0000 Hi, As I promised in the call yesterday, I wrote down the issues with the fragmentation handling specified in RFC 2765 (SIIT) and RFC 2460 (IPv6). Basically, doing it the way that is specified there allows for path MTU discovery black holes that would otherwise not occur. A number of choices to address this issue in the stateful and stateless case are listed, we need to get rough consensus on which one we want to move forward with. The text is a bit longer than I intended (about 3 pages, the draft is 5) so I put it in a draft rather than an email message. Iljitsch Begin forwarded message: > Filename: draft-van-beijnum-behave-frag64 > Revision: 00 > Title: IPv6-to-IPv4 translation fragmentation issue > Creation_date: 2009-05-21 > WG ID: Independent Submission > Number_of_pages: 5 > Abstract: > This draft outlines a way to handle IPv4 MTUs smaller than 1280 bytes > and a way to handle the identification field in fragmentation that > are different from the ones specified in [RFC2460] for the purposes > of discussion in the BEHAVE working group. http://www.ietf.org/internet-drafts/draft-van-beijnum-behave-frag64-00.txt From Fred.L.Templin@boeing.com Thu May 21 08:02: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 C0C543A6E50 for ; Thu, 21 May 2009 08:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=0.455, 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 BNh0bUHReg2X for ; Thu, 21 May 2009 08:02:21 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id D6DE63A6768 for ; Thu, 21 May 2009 08:02:21 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4LF3s7q019806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2009 08:03:55 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4LF3swq000019; Thu, 21 May 2009 08:03:54 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4LF3oMG029814; Thu, 21 May 2009 08:03:54 -0700 (PDT) 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); Thu, 21 May 2009 08:03:52 -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: Thu, 21 May 2009 08:03:51 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcnaHeTObTafHg/pS5qr2RfXYffOpwABmXLw References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" , "Behave WG" X-OriginalArrivalTime: 21 May 2009 15:03:52.0947 (UTC) FILETIME=[5AD73C30:01C9DA25] Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 15:02:22 -0000 Iljitsch, All of these alternatives have strong a dependence on even getting back ICMPv4 messages from the IPv4 side at all. I believe there is a growing consensus that we can't depend on that in all circumstances. AFAICT, the most effective option to avoid black holing and corruption is to locate the translator as near as possible to the IPv4 host; preferably co-resident on the IPv4 host if that can be arranged. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, May 21, 2009 7:08 AM > To: Behave WG > Subject: [BEHAVE] The fragmentation issue >=20 > Hi, >=20 > As I promised in the call yesterday, I wrote down the issues with the > fragmentation handling specified in RFC 2765 (SIIT) and RFC 2460 > (IPv6). Basically, doing it the way that is specified there allows for > path MTU discovery black holes that would otherwise not occur. A > number of choices to address this issue in the stateful and stateless > case are listed, we need to get rough consensus on which one we want > to move forward with. >=20 > The text is a bit longer than I intended (about 3 pages, the draft is > 5) so I put it in a draft rather than an email message. >=20 > Iljitsch >=20 > Begin forwarded message: >=20 > > Filename: draft-van-beijnum-behave-frag64 > > Revision: 00 > > Title: IPv6-to-IPv4 translation fragmentation issue > > Creation_date: 2009-05-21 > > WG ID: Independent Submission > > Number_of_pages: 5 >=20 > > Abstract: > > This draft outlines a way to handle IPv4 MTUs smaller than 1280 bytes > > and a way to handle the identification field in fragmentation that > > are different from the ones specified in [RFC2460] for the purposes > > of discussion in the BEHAVE working group. >=20 > http://www.ietf.org/internet-drafts/draft-van-beijnum-behave-frag64-00.t xt > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Thu May 21 08:08: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 5EB6B3A6ED2 for ; Thu, 21 May 2009 08:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 6o661QK1gZiw for ; Thu, 21 May 2009 08:08:21 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 6958F3A6DB3 for ; Thu, 21 May 2009 08:08:21 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4LF993G030312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 May 2009 17:09:10 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@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 v935.3) Date: Thu, 21 May 2009 17:09:21 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 15:08:22 -0000 On 21 mei 2009, at 17:03, Templin, Fred L wrote: > All of these alternatives have strong a dependence > on even getting back ICMPv4 messages from the IPv4 > side at all. Sure, but that's normal IPv4 behavior. What we're trying to do here is translate IPv4 to IPv6, not fix IPv4. > I believe there is a growing consensus > that we can't depend on that in all circumstances. Doesn't look like that to me, because people are still sending packets with DF=1. One solution would be of course to send all packets on the v4 side with DF=0. > AFAICT, the most effective option to avoid black > holing and corruption is to locate the translator > as near as possible to the IPv4 host; preferably > co-resident on the IPv4 host if that can be arranged. So if I want to go to ftp.dell.com which only has IPv4 and I only have IPv6, how exactly am I going to do that? What you're saying is basically that everyone should adopt IPv6. While I agree with that it doesn't solve the problem at hand, which is how to communicate with people who _don't_ run IPv6. From Fred.L.Templin@boeing.com Thu May 21 08:23: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 6B2653A69D8 for ; Thu, 21 May 2009 08:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 YZLJ-9SR8g7O for ; Thu, 21 May 2009 08:23:31 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A7F843A69A0 for ; Thu, 21 May 2009 08:23:30 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4LFP8Wj003830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 May 2009 08:25:08 -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 n4LFP7HK023615; Thu, 21 May 2009 10:25:07 -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 n4LFP1R9023494; Thu, 21 May 2009 10:25:07 -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); Thu, 21 May 2009 08:25:00 -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: Thu, 21 May 2009 08:24:58 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105F44709@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcnaJiuzkhIZki5USfumqED62pCc6gAAdF2Q References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 21 May 2009 15:25:00.0784 (UTC) FILETIME=[4E87CF00:01C9DA28] Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 15:23:36 -0000 > What you're saying is basically that everyone should adopt IPv6. While > I agree with that it doesn't solve the problem at hand, which is how > to communicate with people who _don't_ run IPv6. Have them put a translator in *their* network; then, do what ever you have to do to reach their translator from *your* network via IPv6 - even if that means tunneling. Fred fred.l.templin@boeing.com From dwing@cisco.com Thu May 21 09:21: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 CD9A33A69A0 for ; Thu, 21 May 2009 09:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.283 X-Spam-Level: X-Spam-Status: No, score=-5.283 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 O0wlRrojJpIs for ; Thu, 21 May 2009 09:21:22 -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 9AED13A67AE for ; Thu, 21 May 2009 09:21:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,228,1241395200"; d="scan'208";a="167999879" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 21 May 2009 16:22:59 +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 n4LGMxYw021040; Thu, 21 May 2009 09:22:59 -0700 Received: from dwingwxp01 (sjc-vpn3-398.cisco.com [10.21.65.142]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n4LGMwxo025864; Thu, 21 May 2009 16:22:58 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> <7AC09AC5-5535-43DD-B2F2-CC2FE8AD44B3@muada.com> Date: Thu, 21 May 2009 09:22:55 -0700 Message-ID: <03df01c9da30$67b3ece0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <7AC09AC5-5535-43DD-B2F2-CC2FE8AD44B3@muada.com> Thread-Index: AcnZ+l/ayHtcSeT/S5CzFcLz6+Di8gANG/Dg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5506; t=1242922979; x=1243786979; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=2xEWMTNtSG0LqLVgCPmJah+xdTvwZDblMMyPEFdFbcE=; b=yRCKd4qzxcR0V47ZTlCSZBSEkY3jp6yqUtu3AxLk2RiFoJh0Fz5SEtU+0a itVDh9Wu8J2Voi9xsl7Gpmvwn7HYBq/P2sLLiNTR2v6WyRzEL6LdZy0XskfI TgItR92fUq; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org, 'ext Philip Matthews' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 16:21:23 -0000 > >> Using EPSV is hence the *only* valid thing to do. > > > It could use PASV. If EPSV fails, and the FTP client knows the > > IPv6 prefix of its 6/4 translator, the FTP client can send PASV, > > parse the response, and open an IPv6 socket that will be > > translated. > > In the ftp64 -03 draft there is an even simpler solution: > clients are > advised to simply connect to the same address that is the > destination > of the control channel connection, and ignore the address > provided in > the server's response to the PASV command. > > (You wouldn't happen to have correlated the PASV response > address with > the control channel address in your big FTP server test, would you?) In my tests? No, I didn't check. Should be easy, though -- I will test that next week. > >> Needless to say, there are FTP client implementations that > >> do not support IPv6. From my memories, some > >> send malformatted PASV requests and some simply fail to > >> establish the control channel in the first place. > > > Yep. But those don't work with FTP clients behind IPv4 NATs, > > ??? What I mean is that an IPv4 FTP client that can't parse the PASV response, or an IPv4 FTP server that sends an un-parsable PASV response, is not going to work with most modern clients (Firefox, IE, etc.) because they default to using PASV because the client is, more often than not, behind a NAT (coffee shop, in-home 802.11 NAT box, etc.). > If you have an FTP client that uses the old socket API it can't talk > over IPv6. So that case is out. That could occur in an IPv4 network to IPv6 network scenario. I agree that, for FTP, we might not want to address place a high priority on that in the working group. But it could be made to work. > If you have an FTP client that manages to connect over IPv6 > but isn't > aware of EPSV and EPRT, it would issue a PASV command. The client > issuing the command wouldn't be a problem, because there are no > arguments or other IP version specific issues with the _command_. > > Only when the server responds there will be trouble. I tried > this with > a few IPv6 FTP servers which respond in various ways that > don't allow > for setting up the data connection successfully. > > However, if the server is behind a NAT64 then the server will simply > respond with its IPv4 address, which the client will then parse > without issue. But then the client needs to connect to an IPv4 > destination which of course doesn't work in this case. > > With IPv4 on both sides and a NAT44 in the middle there are > no issues, > the client simply connects to the server-supplied IPv4 address. Only > with PORT the NAT has to cooperate and allow for the data connection > to be set up from the server to the client. Yes, "active FTP". > > And as you know, it is awkward to reconfigure applications > > (such as an FTP client or HTTP client) to use > > different application-level proxies when connecting/disconnecting > > with different networks (e.g., ftp-proxy.comcast.net, > > proxy.att.net, ftp-proxy-sj.cisco.com, ftp-proxy.starbucks.com). > > There is automatic proxy discovery/configuration and large scale > proxies have been known to work. This gets into the realm of requiring host changes, though. And there are only defacto standards around this area. I have a proxy.pac file in my Firefox configuration (to tunnel traffic over ssh), but this gets fragile. It doesn't work well with wget, curl, HTTP clients built into anything shy of a full- blown, full-featured web browser (IE, Firefox, Safari, Opera), such as you might find in an IP phone, > If the proxy is only used for FTP I > don't think this is an issue, as only a small fraction of the > internet's traffic is FTP. > > Note that Apache can be an FTP proxy: > > http://httpd.apache.org/docs/2.2/mod/mod_proxy_ftp.html > > However, it only supports downloads, not uploads, which brings us to: > > On 21 mei 2009, at 1:49, Dan Wing wrote: > > >> However, I don't think the browser case is the most relevant > >> one. Yes, it's important, but basically this is just doing with > >> FTP what can also happen over HTTP. > > > Downloading from anonymous FTP is the most common use of FTP, > > and we certainly need that to work. > > Right, it's important, but it's also easy, you can do this with the > Apache proxy if all else fails. > > > We have a chicken-and-egg problem: there is still FTP content > > that needs to be accessible. The FTP64 ALG, like all of > > the translation being done in BEHAVE, is the 'incubator', so > > to speak. > > Not sure what you mean here... That the lack of functioning EPSV support in existing IPv4 FTP servers is part of the IPv6 transition problem. BEHAVE's job is to help with the transition. So I was just saying we need to keep pounding on FTP so it'll work as reliably as today's IPv4 FTP. > >> An important use case of FTP is uploading > >> files, which browsers can't do with FTP AFAIK. > > > I found this cute little Firefox add-on today, > > http://fireftp.mozdev.org/ > > Right. There's also a bunch of Java FTP clients that you can > run from your browser. > > But my point is that we need to look beyond the browser, because the > browser in and of itself won't do uploads, and FTP support without > uploads doesn't make sense. Ok. -d From marcelo@it.uc3m.es Thu May 21 09:54: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 A033D3A6BCB for ; Thu, 21 May 2009 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 eVvr+4O6hB95 for ; Thu, 21 May 2009 09:54:43 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A5C013A685A for ; Thu, 21 May 2009 09:54:43 -0700 (PDT) Received: from r190-135-20-227.dialup.adsl.anteldata.net.uy (r190-135-20-227.dialup.adsl.anteldata.net.uy [190.135.20.227]) by smtp03.uc3m.es (Postfix) with ESMTP id 377B37F2D8B; Thu, 21 May 2009 18:56:17 +0200 (CEST) Message-ID: <4A1587AF.9080608@it.uc3m.es> Date: Thu, 21 May 2009 18:56:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Xing Li References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> In-Reply-To: <4A153355.9000401@cernet.edu.cn> 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-16656.000 Cc: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 16:54:44 -0000 Xing Li escribió: > > > Iljitsch van Beijnum 写é“: >> About the terminology: >> >> I suggest NAT64 for stateful and TRANS64 for stateless. (And NAT44, >> NAT46, NAT66 as well as TRANS46. Maybe even NAT464 if we need it to >> avoid NAT444 but please no NAT646.) >> > > The problem is that the stateless scheme (IVI) supports both TRANS46 > and TRANS64, how to name it? > stateless translator? Regards, marcelo > xing > > >> From the minutes, I would remove this and simply point to the slides >> or the draft, because the text is slightly inaccurate and no point in >> trying to fix it with good text already out there: >> >> Iljitsch: just finished yesterday, hope you had chance to look at it, >> two folks >> didn't like "ALG", three options, ALG is third >> Iljitsch: ALG slide, go transparent after AUTH, stateless, stateful >> Iljitsch: Servers slide, must support EPSV, but firewall problem, >> must be able >> to disable EPSV, control channel adrs in PASV >> Iljitsch: Clients slide, must EPSV, windows command-line doesn't >> support EPSV, >> retry PASV after EPSV failure, ignore ??, no args to EPSV >> >> _______________________________________________ >> 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 cambyrne@yahoo.com Thu May 21 09:56: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 006D53A69F8 for ; Thu, 21 May 2009 09:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ENrCtIpkvmyO for ; Thu, 21 May 2009 09:56:42 -0700 (PDT) Received: from web32003.mail.mud.yahoo.com (web32003.mail.mud.yahoo.com [68.142.207.100]) by core3.amsl.com (Postfix) with SMTP id 20E933A68AB for ; Thu, 21 May 2009 09:56:42 -0700 (PDT) Received: (qmail 87607 invoked by uid 60001); 21 May 2009 16:58:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242925085; bh=/Eq+bSBRzJxJdfUa2V5MMRN/mjExPU181+ZDv5S8WK4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=49S8fE2m4YVFCIhyUT0hNCf2zEhJ5VBF4DJQKG2sdoneE1pn8wfe2Fxcl8LKw8mav/TIqD6tGFj68tSSVivr83cnJD5Nw3prChViLjYcmH9ZoqsB78TFrIhcrfUy/KUDgvL9gHPUa5FtOyNP93Sfmjo78BfKmlvkUryN/mSJ3Cs= 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:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BUYpXo5kZYTwFbiJs0Rk8x+F5aTuSFxXC/innPxuR8aVTXNodUSvJRFtzn57jFf5kALfU/pvrzpbIXNubgw2Ll3PCkQI4pXh7Rx71BgrFuREQ+L6IEXhytyEadiV+//BDix5xHBXQrrjEG8FW+JVeDtNZTN14Lh+pdh34dIWkRk=; Message-ID: <857469.87091.qm@web32003.mail.mud.yahoo.com> X-YMail-OSG: k7so1VkVM1msxjDoZ8jZkzpbGO4o8_nDTPcgU3LsxhLhbQwtjYU62w0UM_3hX7.tM53ED2Iw9CFkZI4NB_NbbHv2ovk6_59Jx_xvqaTIpP9FKlGE0SQlDvt7yP0gtdyblfGsPxx2WmBlrhXXNd4RmzKfFW83ZGGp31zCnPVcPRl2eUTKLJCF5pc2Q2dCPRqtZIMLAV3wLY.iq8tU_aa4LD_12J8ywk0tAB5lbxqOFOsrg5DgLO5Mbis7gfyeMfDrA8Zpj3fjSuDF8LCHByq4xBDZTZ2rfboPfIeWSqRh_LREDbQ0HYopWOciFtVX.yzSRrxSeDd4mzI0_luEKw-- Received: from [65.161.188.11] by web32003.mail.mud.yahoo.com via HTTP; Thu, 21 May 2009 09:58:05 PDT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10 Date: Thu, 21 May 2009 09:58:05 -0700 (PDT) From: cambyrne@yahoo.com To: Iljitsch van Beijnum , Fred LTemplin MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cambyrne@yahoo.com List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 16:56:43 -0000 =0A--- On Thu, 5/21/09, Templin, Fred L wrote:= =0A=0A> From: Templin, Fred L =0A> Subject: Re: = [BEHAVE] The fragmentation issue=0A> To: "Iljitsch van Beijnum" =0A> Cc: "Behave WG" =0A> Date: Thursday, May 21,= 2009, 11:24 AM=0A> > What you're saying is basically=0A> that everyone sho= uld adopt IPv6. While=0A> > I agree with that it doesn't solve the problem = at=0A> hand, which is how=0A> > to communicate with people who _don't_ run = IPv6.=0A> =0A> Have them put a translator in *their* network; then, do=0A> = what ever you have to do to reach their translator from=0A> *your* network = via IPv6 - even if that means tunneling.=0A=0AI don't think think a game of= chicken between content and eyeballs is going to solve this.=A0 I can't te= ll my paying customers that they cannot reach Dell's FTP server because I m= oved them to IPv6.=0A=0AThe scale is at the user level, the mobile phones, = home broadband ...=A0 So that is where we need to push the solution because= that is the side of the transaction that needs IPv6 first.=A0 There is not= an IPv6 flag day, and there is not a sustainable business model where we m= ove our users to IPv6 without access to IPv4 content.=0A=0ACameron Byrne=0A= Principal Engineer=0AT-Mobile USA=0A=0A=0A> =0A> Fred=0A> fred.l.templin@bo= eing.com=0A> _______________________________________________=0A> Behave mai= ling list=0A> Behave@ietf.org=0A> https://www.ietf.org/mailman/listinfo/beh= ave=0A> =0A From moore@network-heretics.com Thu May 21 16:20: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 322FE3A6891 for ; Thu, 21 May 2009 16:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ds5kTsWsU+W for ; Thu, 21 May 2009 16:20:13 -0700 (PDT) Received: from m1.imap-partners.net (m1.imap-partners.net [64.13.152.131]) by core3.amsl.com (Postfix) with ESMTP id 64C613A683B for ; Thu, 21 May 2009 16:20:13 -0700 (PDT) Received: from lust.indecency.org (70-11-87-168.pools.spcsdns.net [70.11.87.168]) by m1.imap-partners.net (MOS 4.1.5-GA) with ESMTP id AAW41729 (AUTH admin@network-heretics.com); Thu, 21 May 2009 16:21:31 -0700 Message-ID: <4A15E1F8.9000404@network-heretics.com> Date: Thu, 21 May 2009 19:21:28 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: cambyrne@yahoo.com References: <857469.87091.qm@web32003.mail.mud.yahoo.com> In-Reply-To: <857469.87091.qm@web32003.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fred LTemplin , Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 21 May 2009 23:20:14 -0000 cambyrne@yahoo.com wrote: > The scale is at the user level, the mobile phones, home broadband ... > So that is where we need to push the solution because that is the side > of the transaction that needs IPv6 first. There is not an IPv6 flag day, > and there is not a sustainable business model where we move our users to > IPv6 without access to IPv4 content. There's no right answer that works for all cases. The general answer is that either end of the connection needs to be able to arrange for access from/to the other end - regardless of whether the end arranging for access is running IPv4 or IPv6. The other requirement is that the solution be within reach by the party wishing to arrange for access. "Within reach" encompasses many things - economic, technical, etc., and it includes ability of people to overcome their current mindset, and understand the solution they're choosing and its implications for their operations. From Remi.Denis-Courmont@nokia.com Thu May 21 23:53: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 212F53A6A06 for ; Thu, 21 May 2009 23:53:23 -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=[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 4FyjZ3Zkoj+8 for ; Thu, 21 May 2009 23:53:22 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D93C73A69AA for ; Thu, 21 May 2009 23:53:21 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4M6sM0X019983; Fri, 22 May 2009 09:54:46 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 May 2009 09:54:39 +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); Fri, 22 May 2009 09:54:26 +0300 Received: from leon.remlab.net (esdhcp03589.research.nokia.com [172.21.35.89]) by mgw-da02.ext.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n4M6sMUC014731; Fri, 22 May 2009 09:54:22 +0300 From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: Maemo Software - Nokia Devices R&D To: ext Dan Wing Date: Fri, 22 May 2009 09:55:30 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.28.10; KDE/4.2.2; i686; ; ) References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> In-Reply-To: <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905220955.31472.remi.denis-courmont@nokia.com> X-OriginalArrivalTime: 22 May 2009 06:54:27.0476 (UTC) FILETIME=[2611B540:01C9DAAA] X-Nokia-AV: Clean Cc: "behave@ietf.org" , 'ext Philip Matthews' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 May 2009 06:53:23 -0000 On Thursday 21 May 2009 02:49:30 ext Dan Wing wrote: > > On Wednesday 20 May 2009 15:47:13 ext Philip Matthews wrote: > > > My quick thoughts on this subject are that what is important is what > > > the major browsers do when given a link of the form: > > > ftp://.... > > > If someone who doesn't know much about computers clicks on such a > > > link, we would like it to work. > > > Do these browsers do "EPSV" or "PASV" or what? > > > > In the envisioned scenario, the FTP client is running on an > > IPv6 (only) host. Using EPSV is hence the *only* valid thing to do. > > It could use PASV. If EPSV fails, and the FTP client knows the > IPv6 prefix of its 6/4 translator, the FTP client can send PASV, > parse the response, and open an IPv6 socket that will be > translated. Yes and no. An hypothetical future FTP client that would be aware of networ= k=20 protocol translation could certainly do what you are suggesting. *But* I=20 reckon the motivation for the FTP64 ALG is backward compatibility with=20 existing FTP clients. I'm fairly confident none of those support say, prefi= x=20 learning. > For whatever it's worth, I mentioned this in > draft-wing-behave-learn-prefix-02: > > So far, the authors have identified the following > applications which can benefit knowing the IPv6 prefix of the host's > IPv6/IPv4 translator: > ... > o In the absence of an FTP ALG in the IPv6/IPv4 translator, IPv6 FTP > clients that conect to an IPv4 FTP server which does not support > EPSV [RFC2428]. Hmm. So I guess the FTP ALG should just let PASV requests unmodified throug= h,=20 so that a prefix-aware FTP client will work regardless of the presence of a= n=20 =46TP ALG. > > Needless to say, there are FTP client implementations that > > do not support IPv6. From my memories, some > > send malformatted PASV requests and some simply fail to > > establish the control channel in the first place. > > Yep. But those don't work with FTP clients behind IPv4 NATs, > so they really aren't terribly interesting. I mean, we > shouldn't try to make them work with FTP clients that emit > EPSV. I don't understand what you mean. FTP clients do not interoperate with -oth= er-=20 =46TP clients in my understanding of FTP. =46TP clients that support PASV but don't support IPv6 definitely *do* work= =20 through IPv4 NATs. And they will break if you convert the IPv4 NATs into NA= T64=20 boxes (unless you do double 4-6-4 translation). > > But of course, if you deploy an IPv6-only network, you assume > > that your customers are IPv6-capable. In fact, it is not unlikely > > that a network where you can afford such control will have > > an HTTP proxy handling outgoing FTP connections (and the issue > > is moot). > > Many IPv6-only networks are expected to be quite large: > wireless networks (which will include tethered PCs which > might run FTP clients), and there is already a large IPv6- > only network deployed in China (CERNET2) with thousands > of clients. This would make such a proxy very busy. Ok. But still, you're going to have to assume that your customers are IPv6= =20 capable anyway. And *today* that's not a feasible assumption. In other word= s,=20 there is no foolproof way to make existing FTP clients "just work" on the I= Pv6=20 side of a NAT64 translator. > > Anyway, while we cannot assume that an IPv4 FTP server > > supports EPSV, we can assume that an IPv6 FTP client > > does. > > -d =2D-=20 R=E9mi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki From iljitsch@muada.com Fri May 22 00:29: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 DE97B3A6B5E for ; Fri, 22 May 2009 00:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 j+90eROZNkpW for ; Fri, 22 May 2009 00:29:21 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id D6B783A6C54 for ; Fri, 22 May 2009 00:29:20 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4M7UOYo042118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 May 2009 09:30:24 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= In-Reply-To: <200905220955.31472.remi.denis-courmont@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: Fri, 22 May 2009 09:30:35 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> <200905220955.31472.remi.denis-courmont@nokia.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 May 2009 07:29:22 -0000 On 22 mei 2009, at 8:55, R=E9mi Denis-Courmont wrote: > An hypothetical future FTP client that would be aware of network > protocol translation could certainly do what you are suggesting. =20 > *But* I > reckon the motivation for the FTP64 ALG is backward compatibility with > existing FTP clients. I'm fairly confident none of those support =20 > say, prefix > learning. Please read the -03 draft. In there, it says that IPv6 FTP clients should try PASV if EPSV is =20 unsuccessful, but NOT bother with prefixes or anything, and simply =20 assume that the address returned by the server in the PASV response is =20= the same as the address for the server that the client is connected to =20= through the control channel. So except in the (presumably) very unusual case where the server has =20 multiple addresses and returns a different address in the PASV =20 response than the control channel address, all of this can work with =20 client changes only. (The draft also requires servers to only use the same address in PASV. =20= So if servers are also upgraded it will certainly work.)= From dwing@cisco.com Fri May 22 08:46: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 573563A6976 for ; Fri, 22 May 2009 08:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.058, 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 Nq0T5ZP68iIM for ; Fri, 22 May 2009 08:46:28 -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 391773A690D for ; Fri, 22 May 2009 08:46:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,234,1241395200"; d="scan'208";a="164122962" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 22 May 2009 15:48:07 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4MFm72F022383; Fri, 22 May 2009 08:48:07 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4MFm6wP029515; Fri, 22 May 2009 15:48:06 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Denis-Courmont'?=" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> <200905220955.31472.remi.denis-courmont@nokia.com> Date: Fri, 22 May 2009 08:48:06 -0700 Message-ID: <073a01c9daf4$b340bed0$c5f0200a@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 In-Reply-To: <200905220955.31472.remi.denis-courmont@nokia.com> Thread-Index: AcnaqjhDUGQVtfCRTBiRtE4CEA4sxQAScY/g DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4948; t=1243007287; x=1243871287; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=gXxMdbosi+AyC0zavoCh0NkHAAIbruMCIWjOnVXErPA=; b=ue/q1h+6UV4/DkPyW/idyB7e8RI8J3MG+GmcX+W/fcEYcuYSeal0h1Kgf7 QWncCw/WjeBI29C/hSTGz7hb0Y5sIWxahFJ/PkUdMKzYKUXjuJyyn59CIwuh OaW3JMbSfS; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: behave@ietf.org, 'ext Philip Matthews' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 May 2009 15:46:29 -0000 =20 > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]=20 > Sent: Thursday, May 21, 2009 11:56 PM > To: ext Dan Wing > Cc: behave@ietf.org; 'ext Philip Matthews'; 'Iljitsch van Beijnum' > Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? >=20 > On Thursday 21 May 2009 02:49:30 ext Dan Wing wrote: > > > On Wednesday 20 May 2009 15:47:13 ext Philip Matthews wrote: > > > > My quick thoughts on this subject are that what is=20 > important is what > > > > the major browsers do when given a link of the form: > > > > ftp://.... > > > > If someone who doesn't know much about computers clicks=20 > on such a > > > > link, we would like it to work. > > > > Do these browsers do "EPSV" or "PASV" or what? > > > > > > In the envisioned scenario, the FTP client is running on an > > > IPv6 (only) host. Using EPSV is hence the *only* valid=20 > thing to do. > > > > It could use PASV. If EPSV fails, and the FTP client knows the > > IPv6 prefix of its 6/4 translator, the FTP client can send PASV, > > parse the response, and open an IPv6 socket that will be > > translated. >=20 > Yes and no. An hypothetical future FTP client that would be=20 > aware of network=20 > protocol translation could certainly do what you are=20 > suggesting. *But* I=20 > reckon the motivation for the FTP64 ALG is backward=20 > compatibility with=20 > existing FTP clients. Yep. > I'm fairly confident none of those support say, prefix=20 > learning. Agreed. I was examining how an IPv6 FTP client might operate across a translator without an FTP ALG in the translator. I think Iljitsch's idea of just ignoring the IPv4 address in the PASV response has a lot of merit and is better than my idea of prefix learning -- I will test Iljitsch's idea next week. > > For whatever it's worth, I mentioned this in > > draft-wing-behave-learn-prefix-02: > > > > So far, the authors have identified the following > > applications which can benefit knowing the IPv6 prefix=20 > of the host's > > IPv6/IPv4 translator: > > ... > > o In the absence of an FTP ALG in the IPv6/IPv4=20 > translator, IPv6 FTP > > clients that conect to an IPv4 FTP server which does=20 > not support > > EPSV [RFC2428]. >=20 > Hmm. So I guess the FTP ALG should just let PASV requests=20 > unmodified through,=20 > so that a prefix-aware FTP client will work regardless of the=20 > presence of an FTP ALG. I agree. The FTP64 ALG has no incentive to manipulate PASV=20 from an IPv6 client. > > > Needless to say, there are FTP client implementations that > > > do not support IPv6. From my memories, some > > > send malformatted PASV requests and some simply fail to > > > establish the control channel in the first place. > > > > Yep. But those don't work with FTP clients behind IPv4 NATs, > > so they really aren't terribly interesting. I mean, we > > shouldn't try to make them work with FTP clients that emit > > EPSV. >=20 > I don't understand what you mean. FTP clients do not=20 > interoperate with -other-=20 > FTP clients in my understanding of FTP. >=20 > FTP clients that support PASV but don't support IPv6=20 > definitely *do* work=20 > through IPv4 NATs. And they will break if you convert the=20 > IPv4 NATs into NAT64=20 > boxes (unless you do double 4-6-4 translation). I didn't understand what you meant by IPv6 FTP clients that send = 'malformatted PASV requests', because PASV doesn't work with IPv6 FTP clients. I = don't have a point I was trying to make, I was just trying to understand your = statement about mal-formed PASV. > > > But of course, if you deploy an IPv6-only network, you assume > > > that your customers are IPv6-capable. In fact, it is not unlikely > > > that a network where you can afford such control will have > > > an HTTP proxy handling outgoing FTP connections (and the issue > > > is moot). > > > > Many IPv6-only networks are expected to be quite large: > > wireless networks (which will include tethered PCs which > > might run FTP clients), and there is already a large IPv6- > > only network deployed in China (CERNET2) with thousands > > of clients. This would make such a proxy very busy. >=20 > Ok. But still, you're going to have to assume that your=20 > customers are IPv6=20 > capable anyway. And *today* that's not a feasible assumption.=20 > In other words,=20 > there is no foolproof way to make existing FTP clients "just=20 > work" on the IPv6=20 > side of a NAT64 translator. There is no foolproof way for any NAT or 6/4 translation stuff -- this is all a matter of degrees. -d > > > Anyway, while we cannot assume that an IPv4 FTP server > > > supports EPSV, we can assume that an IPv6 FTP client > > > does. > > > > -d >=20 > --=20 > R=E9mi Denis-Courmont > Nokia Devices R&D, Maemo Software, Helsinki >=20 From ww@river.styx.org Fri May 22 06:00: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 4200228B797 for ; Fri, 22 May 2009 06:00:30 -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 KhqTH6vbj9yC for ; Fri, 22 May 2009 06:00:29 -0700 (PDT) Received: from river.styx.org (river.styx.org [IPv6:2001:470:9a35:3::]) by core3.amsl.com (Postfix) with ESMTP id 6B5E428C0F4 for ; Fri, 22 May 2009 06:00:29 -0700 (PDT) Received: by river.styx.org (Postfix, from userid 1000) id 16AD51F21E1; Fri, 22 May 2009 16:03:47 +0200 (CEST) Date: Fri, 22 May 2009 16:03:47 +0200 From: William Waites To: RRRmi Desprrrs Message-ID: <20090522140347.GA20641@river.styx.org> References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com> <4A018B03.6070601@free.fr> <495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com> <4A098864.3060702@free.fr> <495c4ae90905130346n7fa84708hb746f30110b9cf84@mail.gmail.com> <4A13D3B7.10407@free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A13D3B7.10407@free.fr> User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Fri, 22 May 2009 10:06:58 -0700 Cc: Fred Baker , Behave WG , Keith Moore , Dan Wing , Xu Xiaohu Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 May 2009 13:02:23 -0000 On Wed, May 20, 2009 at 11:56:07AM +0200, RRRmi Desprrrs wrote: > > IMHO, no one should deploy an IPv4 network with global IPv6 connectivity > and no IPv4 NAT somewhere to provide also IPv4 connectivity (be it limited > because of NAT traversal). My ISP finally gives me native only IPv6 and they have a NAT64 somewhere for me to use. (Hooray!) On my home network I have a printer that only speaks IPv4. How do I print something I found on a web site? -w From Fred.L.Templin@boeing.com Fri May 22 15:43: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 89A223A68CC for ; Fri, 22 May 2009 15:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_20=-0.74, 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 h6pQ31JB+nx8 for ; Fri, 22 May 2009 15:43:45 -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 889D83A6947 for ; Fri, 22 May 2009 15:43:45 -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 n4MMjHaV026654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 May 2009 17:45:19 -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 n4MMjGpg002730; Fri, 22 May 2009 17:45:16 -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 n4MMis4Q002273; Fri, 22 May 2009 17:45:16 -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); Fri, 22 May 2009 15:45:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9DB2E.F2F8BF08" Date: Fri, 22 May 2009 15:45:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcnaJiuzkhIZki5USfumqED62pCc6gBB9uhA References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 22 May 2009 22:45:05.0667 (UTC) FILETIME=[F37AF530:01C9DB2E] Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 22 May 2009 22:43:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9DB2E.F2F8BF08 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Iljitsch - here are some comments for your document. Fred fred.l.templin@boeing.com ------_=_NextPart_001_01C9DB2E.F2F8BF08 Content-Type: application/pdf; name="draft-van-beijnum-behave-frag64-00.pdf" Content-Transfer-Encoding: base64 Content-Description: draft-van-beijnum-behave-frag64-00.pdf Content-Disposition: attachment; filename="draft-van-beijnum-behave-frag64-00.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nO1c2XLbyBWtrJMw+QhUXoacsmBiB5wnL3KiqRmXx6NUHmw/UFwk2iTlISnJ +o0kH5xukOhzgT4AaFJyPElmqYIOe+9zl759gZ+cvuv5Tl//WzwM552HrxLnfNXJYefVX7YPy/PO T53UDfQ/OSCfh3PnyamqmCnUj+MwdE4nnb6bZannJ3kJz4lCNw2yyEn8yPVi53Te6Tq903edzA3U X9/pv75Wf4Sp/uP0m9fdJ73ATfpR7HfHvSOvr2onSfciB+N+0h0AvDbgFOClAZcAHQMeA1wY8Bzg dANmsfp5A6axGkg+JC81Q1Lg0oBTgAsDngN0DDgBeGnAZbWk7v2vAKempBjSiFUfsJJDNngMydkJ DEKDxakY5n2CQaAe355+2/EVh4IsVnQ6HXVe32GfJwZ0WclrgAOLFqWSTwCODTgF+I5VvzLgfAOG /WLGR8WUjzZioqf92MjFNegKtgsRGDFhAduHAMcGdAA6DaBYvz1YdCD4n+39f1Iuvgf4zIDHAB+z 6i8MOAa4NuANwEsDLgG+N+CqSS60xdDTPjFysQBd14bDwogsDShKQgTWxeZ63SMDPmPVhVhN7Opf BjPvEDQ0+bLlIgfvVS5y0FMzluD3puQA4C2r7hvQA/iguWQfYN+A2S724tjIxUfQ9QOzFyC2EJaV AR8x0/CC2SBhmGAG5+DGWbMfJVjkG9AH+KC5ZB+gtVRBlm2Xivqd2z82v2gn1DGLt6NhFGDq7Vry E9qMCz2nJvoS4LUB46r20qDQSVt/Mw7Vz7u2GTJZX7OtGwCEC7wCOGMl18yDhl+8qPau97PwoOO0 oG1Z8M4t3pV8MuF+rVl1gMJ7u2RahfqBotKqasXKLt9YVq8T4UNYeGfg4U7XqIUxE5tbksTXKEkO OLLkGUqOGbfeMW5dGXC+U5t6QS6wezgZXNuES42wxWnhKpSdHVQ/BxgbMAR4xFhIzEM9obrbgzfO 2j8agq2x7wPLpVHglQFXjDaXzCMSXII/dgEQZ+0Vo833bDeFNYFGI5p9ByV+ChDhBWEWV2wiJ8yH bPI26yIJlOrPUHJXSZErJqi+YiIJ8IoZZbG2U9YR9LUw3yPWEUpeVsepF+QErD024CnA58wnsiMz JdUrDAO07AzgrMU1HJpKlwAXrHl6aJkza4LqQ4BjNrkbZkLWxt28YDNeA7yo2pXmI1OLYHxgrqGQ cBp3WzEQruHCKlm2KzD7kypjNPgE4FPms6BkAjBl1LQjOXUkfmLApwBfspKJATOAbg5uBqc3Yle1 dAIQMRuhiXFgXbKSQgOtLZcvSYpjvKhesqti9VGdqmehlqCraIjxhm2z6P09U2AtkdQRa3MIkFh1 qX0X1WlWHDVImdAGMOBCclFdCCmV8ROLeXl1opaEc2hbkVLzazZkEZ+BBhLuBdWkaJP2Pq20maul 8ztQNsIKw/EQPsZ7ZoWfM7UEXWVHOMvK5k3XEOEE6LEBTwE+N+CbHlB6EqU2kyo7iNuSkXNQra7B By0yCHkZsZJCsjaMDULO992jc1VKVGnmWGAQqJYI34WMwXZ/AIhFpHF6GnoUba4ZtVvsqHUmDMKm YEsLyQVLqSdMdTqqi/spapDtRavzAOeMOrf1dlKDM9Ym9esE8yAMqyrzKrxHSXHUgvoWsjRm47xh Q1oWFH/fovXOGYlGjETwD68Azi1mKYovGMXXjM2iT7glVCqFx7xgxIWaW7KSVhxes/lIdrSn9v70 8HjJVSzEOQ+Z/ZydpDLP93GS9giSfC5/SEb16Z2oOGZBykaMx23HKJQcVNlZEag5G8hHNhBRslCU qQR39/UgucL2fWQl56xNKrkX1nIfIo/0wnfESs4Bwu+6ZSXPAFJvCtQS1mfEONwSQKAujuUhVcwc jSzTnIeWjizzUTE0ECthp1aFXIhtntWr3Qo4YtQ5M+BtE0eVoaFnB3oKoRImBBSyKAIVVn7CDqF0 arxofJ3aPtHm7eFel7AHU8Z7GAmXVadRv7VVUmiDOq+LZvDAnAg2f2C8v2Ql7aNZqc02t6khQleJ D2JG1G6JA9SiEIYDHJNKzPwZqw6+TGR1IgxtdKSu2JKNbsJAWrIx6HeAaqcKu83lAe+FZZgxitvm uO7W75LxCRrXOmnWUke0aQUwy4cVqoat6rtcLGNIFwBp3pxxedr48icD7n52boxr1yX4fGDME4bn nPUJAVyxebjVeTRp3G5+gbTv1cqYlZwxrorwz7qZqzRYTN3eJSOGYMuC8apBzUk3rqRkl6zNcZWB +klcxD9j1T/1wKHVi9A5LTmLZ4wj1CqLNnEKHks2NateNE/PBMQ9OEBNXjDuCDWJDBiR1/LQgA8B 3hjwxgKF5JTsu7XPld1zm91NEep+yBSqHfgtnQwfAvRY9RGjHlhm+bUVaaDn0qE1pDr9At/vIwNL oT0TC5C31V+00rEURK0XtpuCqGTq7KMghNn7sdns0ejBDZumuKGG4aLmZsg2WVgrerdArZXD2hzs nJRzl4qOjO5utNuOR5r/Pu0mrJgdfS+d2kWbCPq61eoVsYMPOauOc0Ps/2eOVGR9ylYMURaHDekj QJxgp2xI9CAgdnbBOqK3OtdMQhF3o1JP4yA+QOTdPpAliaYRlZBsKrKxsnq7tkti1lNDQHHNA+G+ tchSJuB5s8IQrHxhQPuOqhxbIDE1b0/5eQoQGSIi6+TWgEt0BUstrsMgfnZgRoFvumz88iYXJBSJ xn0DipzijDETCbTHAE8N+Jx1JG6XIRc04GKJakU3ttz5WgdkdZilN6DiYEllBXaPRrOpqRZGfdSS 40Dj4vAuJgwU9200itpyn3ZvuVMi1g5qi3wE5FHSQCQ1DaIjTEsQhsY0aKYNqOUywghiP663ApXw P30P8pwNqeWujOZCrBgoSl4TYoMQ93OmaLP0eP9O6NShAa8A2vfH7ZGIA5M831UXVDq+dceHlmjx XWfnqe1csO08MO1K5EWdGrBQ0XVBN5GWCr9MpABANwqd8nWz9vmODVlkzlg3q81v+rRw+CXAz5bO +Yo5fLu/BNKS/GcFoyu972OVn1XbrI0k7naBXpdfRbOmHEYIYffo7YMdeanjMLXaewkTZJFe6lHv wrpVP+hST7iJsKXiinrGiAvlK65B1qwk+GRdBVTUH05UbdcLJBfKE23edepGZUgi2ZHaYiFMOLs9 AvjQrMhDtuXCTcSF8aqFHOCWsNC2c1d3rSckw2U0g6IWShXzoOkqNENfWKEVG91Rs1jTbBdz+hCj PyDeLbQ7qC+CCTSplr73T18DvbZmWCIfjRG2Xcy13Chb8lDxUPaRB+pwijZbMnIn1d6Vdi+9W1IM U6Rs0Bd7DziWaO1+2/ISy4iRdGUtYl309YxVd9jksDFXrE16my46wk2lMDhWFslBXs/umVDiuhxy QW8D7Iv1Ot+57YVW6rnfsOrUomBP2g5NUOlC1hAKoSeMtrv+BiNX5/XcR65R3eEOb3HjkynCQYBn K0JGNHl1aJUs56l+vnOkIB70+cSiaNkLxt7RWMGsuncVilI60cxW++WBkka93YdjF6wjGu/CqcKy JoqNInH6pRmmSGINmc7CJx3E6e9vzaq7AJWWnjMtLfxlmAthQ1qC1G0vKVC/3jOgCFenBuyzjkTc /Jb1Pt6ubGDnqx6fdn7oeI7GoixIHU9/Pcxzpp0o1R8Fix3fj33HT4LMSVINqALjzuSuvzSmOlC2 Q39prFEs9QXr7kZiwEBxc9aSQ/tZ6L6L72XHkYzbUClJw1DQFBMGUo/Kql5Ol6XMxYGXXg7PqmOv VK95V7j5KJHbgPy9tnv/ngQd3a6iXn0faSt2N+r/b9X/75RcRPm3/SL9Gb8o9QrZC525FMXImXV+ LAPi9yCo/K6BOZoLgiT/vSrvYRRtCnhKBn0/9JwksWT97j8vqGaXG/4Woa+IMj3y0GA+bp+E2Z2w 6nZSaHtMVwgTwuki1kAzIakbRjP0qQvaYt939yGFszphYGExeH5EWzzstQFfAcQHAp4CxOVt8dUM ZYvjlq9mvK32qQ8d0D40qLBX5OyDAemJSVzBQT3QLBNudksy78daIrxUC6x6TvTzRlrxV/GLH8Xi F/3XfFvfj9L8FyOydySpUVTzFdBucX18bQSYGmgh1U+YBEJW37Hq9v1LuU2HiRC9JLsPEB/E2Cup gh4sXzCdcs2qQ9FY371RArxn+gQp2ZIzUYz9/j91eCAI7fQSIP2mD1UKcNDfQvsIqX7t+CH/761a ilFZ6oMs0z+lmZLgIO2nGw2gJRh/QR9E3Hpnqrof9XUb22ffc9RTXz0FffUUZ5unYSfse9Hmeaae ++HmeTMKXWv7pNoabsbmxb7WNdtnVTmv5cX92Mnbyp9Uu7qP/HnWyXvelNCj2dTaPPm67OQbtUab tQjcwPOVF/Rzm8KF2oafVO/qDz/y9BaFYRZsnmfb5zDy8hHqMpvni87fncVe3pTnObEbJ4GihFHS 269Aq2VKA/1JaD+L3HB7hPpFT1Ek9j0/7f6yF7qxok7Y/ZWiq+snUayevNhNQs/r/lphqZt6SdD9 TS9zoyhIsu5ve57rhYE6a32lK2dJ4nd/p1gfp3E/7P5ePWVJHETdN4ueF7hhGnuqypFqMk0Cr/uH Xux6gRcn3T+aOm+WPd/NwkQp7a96fqae48gIzA/7LUnQsCRRkLmaGWJJXvd0HFLvn3JK+m6QpH7q KafEi9yov81vStw4SEOl89S0olCZldA8xb0j31dzjRKl/QrwbS9VqqAf5vrBd/0gjLTDFLphnGaZ VtzF47jneW6kVkC7Aonq3e+notLCNCnqrHuJm0T9QLeu+JzHVKPY7Wsbr9qI4iJpXymhOMy0O2J3 p053sRv6XqbNUNHeBGtxi0oYDnq+YG2ioDY9ahmDRPy6cZa1RyFrX5oZjmSPavXVRvh6RH6id1kU XJLVrRmZmSMrucRsB2aUWHG1IX7kBmmqgzzqKYmT/DRZNImGxN6INv/R85UweUpGSlu73TFFKRNv FEPeDiTztHdfgGJlZqZT7Jooec7WUAxPbPAeu4ouR6zgQlLU7PXUrJ3oHC0JHpbWltQX81gwdtL2 BQdmYvjFJrumNtp53PNUO0o1b0MT+TBmQujs9RDjNTusd3az83ESF7PzkiiPxakli1ULVOjRrPj5 0RYsPpC3kfOtsy3J9E/DoCF6lPw2+koypFiPM/wMWgykrih2o9RQMfSBYE3RuJjEFerItSPCJcYx E3tpc/LEKIN2Ttqi005Jor2mTPApI6/Nug4YDa9qVJUgUEnJ2Bt3JbVVscpU7dnqwpM6QugtapKu mAqia1LSRsXo2H4pJ9tX3m7gJ2KdQlJFbBJUv1hQdMPMzoIxemsbw1gogH8VLSZtIlZ1GVI/Vt6R dBmMH+FjNRLpMxRghEfmNFBV8ClWr9jfkXQkivUYmkUS21uzhsz5aBwGtZSogx3Yyz2ZEqUgDHZJ hqCzRpj7GMoRJp8S+lN0hK1h6lREsTEXGNKArfdetv/PLcaKbYehl9i4kqEq1nYPS3SCJfyCPIdH Yh2K7RDePoyiYCh1LOo8V1trXTI528eLnbG53RjHZfN9Yb0JJd8UprKYmmh8yXxDz1JaymwcoeQZ WxqmZ5ssUeWMIY4JZJhY4ZLph1y3kapFrovqVH/tLtef4oySVSgtEuy+OTxEJi+igTO5dkObMFCl k8/udrTJBnDCQqVRuRfjcM3KWXZ4Gwz4Nzks13dlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKNDI5 MwplbmRvYmoKMTcgMCBvYmoKPDwvTGVuZ3RoIDE4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnic1V3ZkhtHdg2vYyMc/oYKvgww0aypffGbKIkWJ4ayRmp6Hkg9oLF0txpogI1exHnw R/iLnQWg8tysPFVZBNBUeBZF9UXuee6aN1MfvcAPIy+o/lt/TJaDP/6Ye5ebwZbs/fif+4+7y8HH QeHH1X+2BPk9WXqvzlXFUlGjLEsS73w+CPyyLMIo35YIvTTxi7hMvTxK/TDzzpeDoTc6/2VQ+rH6 68+D8z+8H74ZxX4epFk0vB29DANVIc+H91tiFuTDGYh3mihKzjTxfk8swuFLTfyGVR+DOLerZ2qM 2yGFhfr6LYnfg/iVJp6DmGliwqrPsSB3mjhGyUtNXIK4X88y04ucFfV2KOKYEa9BXLHqniZ6TuLP 538aRAo3cZkpCJ1PB+97VPpCxLdsGT6xkpEmBiAGmlg2Z/yynvLL0k+Kato7RlH//P1gR9pxi6e5 xQOIPQ3iFUO2KDnVxGsQN5o4AfFBEzdWSbHlCjErDaNbhkJR8pbB/V4Tr5oobJR8pXv/FsTvdMmv QPxvTfyWDemJDf4OxJvuwV8224wTTcuKWs6Umd4NRXzQxDWI/p5Yo6AWi9tdt7Y+1Fvvs60Xu/yG CUqI1DsQV5o4ZVs/sao7tz5kc+mB3Pcg/qiJr0H8WhMjEBNNzEAMNPFnqyM1/A2Gv9bDn4E4YZs/ Z0SAdMNQJhTKlSU4DOALjC+6oXcD4oZVx+BFRxD+AuOfauQK4X2rhyngjJV7A+IPmvgIYsYk4dqa ehyrYRIxf4NKUEL3IG5Y80tNfGAl79k8NiBStsSQBQPfdbc5bq5inMREtlc8sVNpnczwFsRzTXx3 iMAfW/aNwQwLhuYxAxk1j0IQI00sQAwYRi90758YM8xY76L6mKmbaW/NMm6fkWKGgyB+xfBCMWhD WDHDE2OGK1S61pUmrE8xkCkbCJj698x281hHSxDXFlYM/lwyomU5cmbYGTpOZlg30ZxmiUTzFcP9 W008B/FdP5PIQN4ERGi7RxDBNpZw7SObqUkEJTBjwH1srnkf3F93K6t5c0aKGaitL8QsROIMRI9h EGKWCk+hguYOBwADuWqsQqjmoSWK0bwALoX4dXN0SXCE7KbIFF7sUhOFYQ0vdgHiI6tuixBjx1ds czcMrlR69rN3pb40kCmY5YZh+L4bhGJIKwZs8IVl3ZgmOETRHQOEAKFtmRkiUyAv1MTaAFWyu2Bw DVifFyB+YgPBkIV54rOBUIOMCvQxYwEAaHUCtAsPAb4E9TpE0OWalYQX6lnVBbu3OYew0FcMMAsG LeEHXjMQXnbzmgD2r8yq+I8dMrcQ37lEO2du79khBOZYYxeRunsoKdw9iBkhe2xz1+B+Kjz6yx6X rnuje/8BxEddMmNtHil7+pmIceJUVtQjAVFoRUgU2mZNVBJl5VCA4GkaYHMZsEm33Thj8xBDvma9 j7tLWrboUa6Ri/hhaNlziuozVQrimdWo6ap/IeiFXd5JRXwAEcw0BZEaowjzrlhJV+zizloQA89C Wy1YyUOixHMQ7xg7CEQtGZ5tmZIVtTVVZlqmtNkEqwPaTED8MNLUM0dPsD4MC/pAR8lFhIIWKgG6 +JIRhUax2bxbb1JBXxH7C3rLIKx6p3gXHS2Z7qEeGQJjNP43Y9O0XD+lJw4Sz19r4lsQf2DQA/HY EBoGcg4iVnbFSr5iMp3GB2ksQMiHjTWPrBA21qxpjn57PvjLIPSqgmkZF15YHUgmaeqXasZJFsZe VAaplxcVQf04G8xPfXCZVr1tDy6P5j4cPwoVtNbEFSspfElb87Yx2pgRv+9ptdZnpxXxO2YzCwUI Pn0L4rkmvmMlacBRqCAa8uuw0lo5LQQRh3EFiDiM81l1KvmNjgj7ufxK6qRNWElqRJ6x6u0BkWO0 omC/J8Ub6TZdIK0yA5I0r/kv8ZaSHTNvMfjJJMjfi+bvxe73urki3/7eyu9pnO75Pbf4/fQZC2mS bdXuCRj/lvE4oo4zVt0+nTWdUFh/K8YmLh33kVmU0HF3TSZtqF1qJ9KIDe19ynqnarfjME2pXRp1 FPoGIvNvDtaACpx3tanU7gPj+wsH437UxAc2EJpo0XmEZogNS+lX/pXr3AwdGUrfrXYVw3pRVhaM DU/HfXFeJSedgvsWjNEQa9qw6nYI13QHaSAj1MQIxEITAxDPWPULxhQ2HAz7VpR0HNTRuK5wWxes TfCpxZLm6QA45TWI1G+Etdfv4KhxVHbFuE8wGmyCKWueBoPp+bdLwUJgbJodIbrRzUhxXnwB+zXK /fw09itMVRHJnWjiDYh2Sl6bGgNqaezQEvoNp65/SM+W+v090rIUNrGt8LJE/dy3TStPr+GgPUew pSWrg3DSHQP4A2t+xobsMmope6GjC9aRqE5jjzQDoxf7BYFivyR/Xj0WqjKnsSKhsh5ARJxGcBpS Pi5AXFhbZ3DaGxCp1L9lDACDcc6IQr04Qkf03MFj/COYn6qszz2hUHqM5g1R09KlKeh5ONqsO1J6 bOHwHinU7dOozwpLtoRXT6SkrUPLhho0fMg4SaKKA0PlAKrvpPqOtt4f/tK/5MYv+f6Xqn6ebH/R LuCJeDZQ+vg0tuf3mig8P5ra3t/27K/zHBkfVs43Pa2Te+vWzVS20CMTkfoFRl6xkpbfqXhW4BKi heZ+XLGSVgJNf+eo3fOjLVGRgOM2IXsm3SXdo6uJNPAV28QvctBgJxCbuAfRdsTUsD8Msfn9/SuK cXpQ8dDOIlJ6Fi2ZjDTn4I6V7J/k3mFAKuDToysa+BszFLnMNjumqpTV1HEiXbCW5gyktM/+AczX mnjHhiys2yWbsXUGf1Tii4tIc79gmol0e7hL4liOHCK60ypoiE4gm56M0RwZ22duaxPIvna0SaMR YCF6giFmNK154Jphx3W4TFOhPAaTXy1bVfHAjPGAaN6+GNM2kJOx7Ya1OWYlrYO1Z4A7vS4EZAu4 +/uOkuFxWVEirxe8Rm81ubyoS028tMZumj+O/MWD4hU0n90+MS6y/Tlw4xB6l5FefR0RhaApH057 0B2FcMn+/mGCDWNAwWuQ+Gs2OmobPkfchTqOfU/9jzDJXjCbSngdMMlE9QvGN5esTXRE3QZ6gEtv mrpud1wzPAKkQvGj9wkbktAxj717n1sdGQdby+aQetwYoQl3x9wY2cKtOymqJShWE8U1EqgosbKO OMaaVRcaDnqrKwh5lDZ6AyLuBYpLUz9o4iOIGWOBF5ooHG87I8YA4QWDq0iSf8GgtewGoeAg26Jt 8xVo3r4jqemetUkNR0txmZlOz5N40GyzLSN2wwZCw8oC2DR/6ZCUVldUrmNtjkp+ta5CNXzsG02k PradWG8qiSdLbhh4mjLgntrJbfjdHmsTEpnaZv0yh1p1jJXwrnDvOqLvzww9galwf+3wORwuzQs2 uhUbiBgd7mYK2X3ZbPMo2b0EkV5HgIkuzhkvGbCbnsTwMx9L+AlEeBCCHeDTiEtZSNyh3HRlzU4s cJHt7yVWMBPveLxj0IXIpscj9wzP1jF/48CHXpOlkbFDAr0vQKRHLiuiRfoBzkT2gXmm3akD9KYW 5eANGwhlRvvQ7bOCYC0ZjgfyXQhipIkFiAEDNjyETyDSSC5Whcar+qOon8PbwLBtUBfOnBh6+0vE qxasI9omGFC4DcxmohbEhEEHN2anjuq2AaJ0x9gRs0V49jSh1JNGts5OoGWeQKTRISSuXLHqwhmg V3PB2UcejvWLujTMEjsG0SZyHYcR/W8LUw7qnZT5DYivLbi2aQGHoVWPPa5R0ucWrgDhnGG4/8Xh L3ItirNAz5CQMJ+QgjxlJYVbgbsHwhDCRXTBQTYTH+8XoKQQpDRACnWzYCVpXjI9yqBagPJvv5it eUBBJR2VnpDtc0YUMRvbN21zFugrIIKZHhkyAVearNzfaHHdnu1/G+IE10YFcMEMwnNGmrA4GOif pG8vL9Cs/JMj/OHWeP3pbqLur8xSB6IPg+IUXXAD3UgaJ6dJDo7zY2F5i5NS4yaP8Ah7nykd9AhZ roniEbJUE3/bR8gsZS45s2g5vu14+qMifgPi6wPsi7BJbHuEjCYmUPeKxlc679kqkUmvFlPxRm1k evq7YCWpfTGVWK2Ja1ZdiP4bxj9WEt6pnq+hZ0aIO9rmMI0mmtVtvm6zUsEX1Mi9YtDqdw9RLn/R kidHoy/0IAmDFzlt+xzIovPpDyteFemt6f/CI42cCR1mx9gOfqLxryDSxGP6ENeGlaSv0oE3RDox dAvNJOkZLDBz9Il8ktdeXW0mp7BcGzOilmvHExoyzmJIEJrN3P+JR5E8mDnEo8Nno+kpNPPY9ZpD Z2z9iCNz25cxDb1bBlIAf86IwqI8Muf9JFHZqveD4mn2QXhZCpAKs4Cea9Iw9XMkLF5348146bM7 fRd2w5pBj6aaUK+JsoiYBzWMH9iQ+ztdXdzQU+9TOAtugIqnIQRxqkNTwehNxot25FZE+tqNMFPp LWbqXz1Z+9hmS5zsMIQyvZU8Y4aH1wwvdwyD9msobXEq+xJBHPMEEjqQfjeOG306Xup1PZ5usc1R YTAa3KJ3gV2y/7M9/x4Rr1uGIlTv91J5o/f+aen0qRAka7lyqKjiWtfAprcJ6TNLNCFJuFL04Qvr HcPW6/l3DMM0Tk11kOAwR2bUpjlkx13gME9iLwqDzAvzIHzWm4hRmva60kTz0m053hZRGztK2glj htAUnh6OqqcMxK4kKiqI7de+i5bHdn2G7H20osCbSAZXW/cdG5ppwzqip9oPjAmoLeJ4ndmdhEXY xXXHhN59dxj+TyBesyFT88l6Gsp0YKiOdCfl8iuJihWTihVzb6nZstw9SKP/0r/khfxF/bWs6xdB 5yM2URAVihXj6Ms8YhMlqZ8lvfj+yMyyzmc0lHeN0IArHR5cQjO2rKdpDj5roonK1JvpH26goQFb UWlRZGrJL6icus0/6o2cJPuxy0UZGv9qKCM4tv2j8z5/mIfV81DF875LEwWFH+zv8z9qhqIHrYLL XjHegZP1C6suInhL1qZnLbwB1Gcmfqt7/7Vp+DXsRofGFm3ihTpXxBVMKjKxZ4ShsEgRiLgUSwNo oiSeiBO5BKW18G0JCB5r/rcgvmeqnyb7UMsBC7Y/ymq80Phe6Rn+v5/VUkwbV//LsrrGH1d6Ni4U L22fAdhe8Nd/4VGAkGvTsijVr2mld/ffmfpHqZRvEufVV/Vn9TUZJIGSC9vvhfoOkt33fhSZ/lJt TXZji/Kw6nX/Hagmq1pRVlZflYypvlS7VR/b78Vg2/OuRDWaXa3dl2prMpj/Qa3Rbi1iPw4j70lN 6U/q/7/8v5vKldqOj6r3qHpBJaveYkiSMt59L/bfSgpvR1iV2X1fDf7q3R5k5ahOMz/L40ro1lJ5 /28tDL2kiKtXwtIw10L570YKKlkURsXw70eJn4VFmgz/QcHWj/I0U19h5udJGA7/UdEKvwjzePhP o9JPU7WWw38ehX6o5pIMf1dVLvM8Gv6LQn9WZEEy/Ff1VeZZnA4/3I7CWKmmLFRVXqomizwOh/8+ yvwwDrN8+G+6zoe7UeSXSa6E9+9GUam+s1Qzzl8OW5K4Y0nSuPTVHsslUTaL0qlhFlWKWw07Tbbq 42XkR3GSVuKy/nk2CkM/VaNVAlrxuVKFW0cpitRU08p3q2ujHWUf5H6cK71YCejMT6Jwq+Hr1u9H uZ+nQby1fRI/yYqyVD+HqZ8X0VZz1nVu5e9RGmxthDTzg0gBWnWS7sOYYjpfj9QWVugevq2WvkhU h0rCRUrUxFEuuqmIfhpmQbjNulbbXUSVE7etnorhPo3Uj+ojVCqsHvjOiq0sg8qc6T+Huk2MTfT9 TneEggvdJdsItdJR6sdFUYi+jbFt96RIzQHJDVcl0zAahpoY6a8C2xxo4pkemt6R3T7sTivXmO3d qFAqIkjk0OcMWAJtFHhTtsJvdOtqI+NCDU5tubIMVJ1MDS7D2FEHMxfAE61TtGLTKxMjKsI4l7OU G6RrL0eREi6KB8UsbjEiMMBY/yx27ZrxB2UvsQWZPjDGMHebHuZpFVO1uVx0KeBxo9fQsRyiOpb4 AbNci9WGkCDbYgN2G2giqynwLn5fqFXw8ywPK68Lewl2EevlkEH1z8aI7a3+RORSK/rR1hSzf9DE CSaCMWMkBs5rKebAuRiG2NiJ3GMsMwBYz45KFbGKTYDtN6GuzkSW4uso93dWMba9Lnclxyv4xd6X EERDTtXEgGyMFE8X+B0cIfDXghqyCBQ2jikZHMPqEPCzgsAW1zNimItuUQNsCsmLLm/ZiFoEM+po 4ootMZVZl42OtjLrlnGzGCed0WfwUN1lwvTLXNcxetSrcIlK4IcZQ6/BWPW++PvB1Wk322CGROpX O2NAWSK7WlmeSTCMJULqMbeYbbrTBybLxNqd6Zbk2uk2hcWExcvY4hkY4Jq2UzpDydB1nDFjhrY+ ZeJxLkSzkNcC/wShouiaSE8OEkOp10rKUOqEgS4Y0wl5QheH2khjJka+V/5MHBVxUUMs3RnACntp Gcr9TLpFHOVEw0yptQgXQkQB6ybzPVtUK//TKFZNhvHwu2rkinWL4X9tHaysKOLKaN5P58+VH5ek QZWLWtMwbrGWLjNeFDVQATaDYatLig0QbDbR850xhnVZPobmqVcTw/9bt+kA8QvEC5OfKivZTrd5 L4zLicN6pBLQoTVFdWm7kvWYEfBRzeRQdmuubuqVE64LFxtQAxjmFfM4xCIIALwcRZmfh3lUGSm1 0BoTp4+DjgotW/HlTtltKL690YZhGGoPTg6Rx4Z30d/L0Z/+CI6m/fVTNd402AXFbW67Yvvvdv86 lRL294H5YvdawBsuQQe4t7zj8JIpZql5iEWeUJsfza+5WQbPWgRTAjW7Qs26EU3ZmwFmNGVvWAll 8gr15TrazrFYR/FpmFu2zuWOMIRVizWulx6/y8gXke1rBhyxH6whqnvBetRzeuh2AAwXrF5DpwvW rcuoBnJFr2SwSP9seGF2sOHDUK/shVSVfT0EWzorfGG3qL+1pjLXMFPtOCbVMZ/h8or1lkq3FmBH Lfz/KH5KgzBJomGqK+VSntvWLjdMTHvBsghWVLGAtX6sGLuIsrwcvq56SsosltIiprgAbko2OyGs WsLKtglExTf1j1tUD4nzQNV+GIFnWjw2IPQ77bEdr+tFAL3T2TYVvHbOdMmMwHqu1TpdJ0jaFr/2 uCgmmQQVZmbAcg9QqsGZ5Kj2Y6zFBNgTsXyjKy4m4JB1s01LzKpeb8NzZKN2uYZnRHwIOQNDSRhn IDKn3mVguCJeDBliQRZsQlj6l6OmOIFEd7m0Qgh80q6GINIggRFAbkZgUspOdCcNg8JmW9MM2K8F bNIW/tajZBvVEm23j6ZWhpSvx7YQctJWyTTQ4AjPcSuUCgAZLrc7N0LlJGzVclJEgnKfEe0Rs9Dh aIcXarvVCybYJLqJBSnE5rTb0vjEfQs7pF6lhiZ+HqcNsWcocXs5WoIXdacCPM8du0DrRIS0xS7I XtXjZXtlxCuIf3TDRu4IVzhOwKijbog1ssE+Zk7trTcsDNF7SBPGqWJI/6tbp9XFPIwDtpYT5d2Q hPSmp/wdzlljE86IoHZMWLrqxKyjspSGVelm3nUv11jgkMjSjoOFrVd6gP2FSRBOlIqnxVomiKL5 AlQjt/AilRjHhY4JNhwhPYp2MYs/uhoSctURS6OHSLeUXe6JOSpktRjADWEsGDNubAsfkDm6fQOw 0nB0nYoBvDQ62G3/it/RUtPx2qdJ/R8S2ukfZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iago1ODM0 CmVuZG9iagoyMiAwIG9iago8PC9MZW5ndGggMjMgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJzlXVmT5DZyDt92hyN8v1fsi6o3ZiiSAHjshh+knZU1G9Z6VmrFPkgbju6qvjRdVTN9 7vjBP8K/2ABJIBPER4JVXT2HrdUq0EkCBBJ5ZwL1dpYmWT5Lzf9sY7E6+PzbcnZ+c9CAZ9/+W9e4 Pj94e1AlwvzTAHh7sZp9eaQ71hqaF4WUs6OzgzSp6yrLy+aNbKZkUolazcpcJVkxO1odzGeHRz8d /Pro4HcHmZ5BJVQtKv2m/pRUSvcuZqqWapbXVTUrKwPQD08PzvY+pUwllZnRD/OXhyIpU1Xk8/Xh 88xMqizntw2wSMv5KQGvHZC9eeqAtx2wyubPHfAF6n5MwLOwe6Gx1Ewpq3TrQwJ/S8AvHPCIgIUD StT9rAMWVbd2AzymN88dcEXAFp9COhzr3t1u1IXr7QEvCbhxQNZ95oCzKPAPR785yDWVCE2K6exo qQkk3mkrYKZXvFv3bxAa3qE3cwdMCZg6YN0CZSq6FT+3S35eJ7Iyy245tU6E5tt/N399FmFbva5Z XqhiVpZPx7ZFVTbzWzXbYvl2Ruw0c+x0ScAlYuZ1wHil6WSBZwi4IOCxQybj20tH0BsCrhGPnTng NQE3iB+IndiHLtzXT9GbLwn4ygHvEd/O+mP2Jn+Dvk4fWvYnr/n2lCjuBnHjZwHmPHp/0xcaBrgh 4H3A9kLoeQC+Pe0PL6SY3xFwjQTIWwdkb56idRDwBq046UsVzmOGq5a+NnzQNK8avayMCpZ1x1eF ZpOV/rO0f8rZ1cF3PoA9L9PecwNY0XB6cs3zPh+rKm1fUErM8rJKkfrdv2lQFFVSFlGGVoWcf0fA C8eRGwLeOeAVYn02Jin3C6THGU/cIjY9dsA1YpQr9OZtn1F6YxJL3aExA1KG8oC/6Y35hoDX6M3w Q05uaYZeIJpnyoZ07hli6GMEDEyD3pvniKFXvYk0mvQpzIQLtGI25jIQv946GG5ITdz0dW7D9x7P qyqzPKg0zzKWbHnWA7DnRd57bgArGq7IK8jzTnfLUpvcqhRIdz8Bz6s6yacpcaaaiedP0ZtMXx8j fU08z0RGuGUez18QEHIy1IOn6E0CMp5fBZTpWQuQP9k8H9A84dehdLhGY95ant8gtrhBbAGV+AsC foXYgpjSfkhYtujxfIqG30S4Lhze654R8Fm/u+FP6g4EQTXIviLVpK55yfCebtemXTaMR3/ZJ/oP 9sT8ter6K1k3Txz37YnpZJ3U+SSmuyEgmb6ME0nRHiP+Yob3xgHXwYfqglu5xF/vEH8dI7q9RAwC 9d9DxHKGShF+HRrzLx3wFQHvHbBAYzKedZbzDaJgRtZLRNbQDCXT9rOxMTXTvYlYzsRfTGWT+rwm 4ApN+c24Smb8RWTxDQGPHPD7vvoMzekoYS8JSITNqH2BdMQ90jsUynlHwECWDBqLy2HZ26ONOwe8 QVQU+F89wr5BX/9sXJcxDUXahLHAYrh7uwwwJUYRP0OaY4MomyjihICXDniOxpxxehynbHLVGOMc o+EhiyXomzTlryLcQm+uI28SXzEWuuppox244SUBXzngPQELB2TdSaK/ISC5TtcE3CVA8gzRIzRk oOwPjCNOUB4zMR8N8uLJuEJg3YlFztEyg7VrMb9C5HaLyI1R1gOiAhj7m25bMV4jOQ1lPxTegVPa c7LOxmcHnSz25kWwDo9pb8cUQhvD3MbSIRpmpsoSvUndGQtAn+M1Eskk5qFEZ3J6M06ZjAXOERES UmGcAbJVzNLJHDAnYOWAKfrQCQHfWRaA1D5duH6NROYDGtPKM80Cp4gFmJwN1benbmBs4xaRK+SL CzTlwOAzEcp9mDckppnRcoNI/DMHvEVjnhMwdPni9ASl588QMzAxPUL3PWf5HI1JHwqySj2uI80B k1IxB9zZ7VCtL9GGPzI2fh2hZiamF+MjQdtrupheoTGZlfbu8dTM3EhK1TDheuWAdwRcjnc/Dz7k U3OEcK0IqLKt85k90X6L6Al+nfwHGGNiov0ZGhNaItAxJkl3Rft4hWjjBpEzeZxLRBss5EK5yYqA KSLn5/Sc2P8dIlIoclkmiewsFswO1bM35g0akymZy4CChoyWO8yLOxotO8VEYe3BuQOuCBjmup6I XiPhGSbmyeO8QN2nMzB7EzIw2TxMS1xZMQ+N4Fgo8iFYkMdWV4jI7DS1mL+OiPk1Ilcafie7fY3I FWqJzAFzAhYO2JmDxkR/zrrvqBBOCPgOMUOYwCtL69f4dE9xntcR8yYSeGc0CqM3RHkvCPgVGjOU qUNcB00m+lBGwAR1pze/QHQfRDU13b+ivaXku0RENM3IjXKIMCF4QPcwWgjTi1D0QzENy2uOCPj9 uAaEvjxUoIFfTdYRLKzJqzyfybJMZzat95T1cKqUySNScoy5yNpi3TMHzAlIAaY0+BBTtZ4VwyIv V4ho14g7IB+NhHg4WXlvwrjPdN6EkdUFAjLBcm/ZEIrtmOkBbbWJJpJmw9eRGCq0lkacd0PzR+GU K65+blB3cmeYswVz81DPwTGP3deHMnqaB4XhwWy2cvwomuwc/WWfVJI/MX+tuv6VlKPpd1nUeVfx +j7S76pQiZiWCYQBLigAWPdvHPCIgN+jNymfBcO5jDMoJHCP2IUx1rtxXg+KczjBa+DrcUOXsTWJ n5ipCcNrUCY9WF6HzgNTK4S56cEDxg5/RCr3BvE6HAnaijvFeCnszKrtrtGU6esvCfjKAe8JKNGH gsxKrw5nmDczoRVv9fQK2HwwXgjX40pKxbPMCzSEXzrgKwJSbrMIPuTzBbl1zDOCQbXO6izkoFTN 8koaxJq6RN1ukNwVJbq/3JPKe1J1T0z/qnyKOgkli67CeD58ViHLCi3jpSpnmSrLJ614VqI0BzWm 0MU3BKT0Ngv1bhCxwIAbRYpvAlqrBxLMvwikYCG3cM3PCPgRxtZonov+PHtyKpLRg0ElKJlZd5iH i2X07tHwdqQKS2ZY4girGdfhm8NmlGYX0bLLyrFOW+REf9knKudPzF+rrr8SaWtglaK0o+l2TaPR X/aJHY3+WnX97WhDddBSlNV7rINWeTm1Dvr9BMb9A0kfG/M6WtyOeWNVA7BYx3ounLkiFg7zUWD8 L+KVeWcUAJff9UZq6qBPI7xLHtQGvTndPYyFUSBugu5T6qA1D9aszlmKKvPqnBsAey5V77kBUB20 /jMfd8REas4w1e/LEcuqqXXQLD5Pjtg79CbU9zC16zg5s1qHSYcqevSHuUKwlDhSQsOqAqgsh1Uv kMiABaGx81UUMWIS5w1yA8OkpgPu9RAiDEEM8MpURwwyGHOF4LmliJtoN6bJMQPpYI+FTHOf8jyb 1Vn+9O5TWk0tb2apsj8iDoGVQDcBhwyVhlLEFxIuPBTA3KdbxDZUo2ZPlVXZsLUlitIg3gSgdLs2 7S4A5f5yT2rvSd09Mf3r4incK1nXiXlhhQ6YHv38h7lwm5egzYMe7TKyebA2/QwBFwGPe1vCpCNF pNb9LWkzuWOHZq2CEpW2SHMlsiflDe1QJ1Vczxjb8vcEhLllGNw/RsAb1D30K6ttDs0uxt+EY8ZY ax1wpsvaDCqfwAcc9Ctj3O5sy/h5uL6WGhLvMP4NLUJY+t8vIWpsy9fomwxfpNueERCm6CJlIsfT jUNRCW786T9zz/hrAOx5nfaeGwAZh/rP8Si9KLUxqR3C7P0Yh9pWTeQkffaYKo8hOck+RGUusF6V WVKbcaabXtwdsCcnXI+VYDYAupN3iD1hNjF2AMmdi93JHyRa357lh8r+IPfHalAih3CmV7bC0xOB lJpoMGrbQ8zyOlVPGlSVUiTpNO76uK+RuEcEeoWI/tTp+FglyxVij8hRvGs0ecicCRozqDrp8cdI jelOwYdBUr+ccux8WNFNZxqYxYYH7RnLjoZ0B8rWvYBznP2U5o68KuTTsp8QSTEt8MHyD9CKp2Dn Fer+QMBj1D103z1OO0fECq9ymCGugCZhUH/ey6is3JssRLJLsjkWqSVGve5PyT+hsbeKWsgzsaKv R9ZSxspF4ClAWOh+gj4Es9rHW2k8lZWDduX+WC6Xjyr6CE81+WoQmo7kYrOE4ybA7ZOnEgLDlWsS rzu0Ztfo6/uTF0vLcvDo3BmiNUjUMSswPIqtWW6BWG66u+ddcgS++ftxuxhevgKVaJA8mcpdUkPy WpZPG2HJ5NTiDXbjEHEXYzkqWIZGJtOHzxDLhfbPUFYMFjDCuMmIFwTzZ1xTeFF3eNXZH9HX4c0Q MJjCOBaWfmWWu6B1BAmwIKByQEVAgYBh1YzmrovJ1fuxO5YeaddGrFFWkvkrB3yF3uwcEhOg4YZn nA9FMZxa2x8fpmrq9YDfE/CFA75CbzLVB2Oi8DQBiUjmg60Qge7ig8FDwkGWbrCEi725y9GaWBb9 Br3pbha6i9DvZZ/WfEaZWo3iXXJyF4mawDQ4DKTCY5XEsTCouYyseDtzMa/ypzcXNZqmVp0x9oAF ZhSTZOUopOVg1IRdvwIDgET0C0TKjOXIhgxLFH2qJaI/6hN9zz/clugHw487hXwWlpGgHmHscYLo FwblKa7AWO4yoN+h8CMk+ligZo2+Ce1WWGZHxYg3aMqMt8+3467Uhh+f0FzU2zil2Ov/YPhxyBmD Z31iygdOCZ7Dg7buSJzGv4sLVmutEKWHuf/hQKMFxoL7sXPE8NqKyJVDMeYksQelBKz/P0cfwvm8 Qe7LcjXL8vRpo4+a7qeWXbHbkOAdR3QOlXWnkCRTYw8jb9beJUU3w5xigPAqV9adyq7gCbbAxuzp NmIflgZr9WU7j4Gak0JV7fatdFub+sLgvUmnur/ck9p7UrdPmv519RQ1J6Iou9qgeVdz0tZnmHKT CAGwO7Jg6cPEm4S90gcmqKH4JWHFYmFdjVwhsUPwiIPtvTenFrsM1ENEzolMywFPSTXC2xdIQO54 ATCQv+zGBzi7yGml6U54rOB/+Kh/U6Mx7XaCR13JcozIGd4WyurJYexqzMDx0yFhfY5nI8B8Rszp HTFweo7GXgwcA5xu4AS2jDZGpl+Vxkic6gdg99Fj+doYgVWoi8g3w4u3PKcXmkqQGWCKBVa2wqwP o/uzx9P9HaJmRrhv0ZuwwoaAjBnCyuB4JHaByBHmG6/Rm0GNSy9mC23jMwSE6mb6ifmRg71DF2sx GtwEc/cs2ul2KrtxBcZsYzQauYUOroNdiVQEFOD577BqB54km0j3e79paKe7RMMLC6qBUwd0Yy1k BmapLBGNjugQnmLblw55pJOs6R4myk8QZTFmIDHbPx8UtzmG6D52LQM0fpZoIgv0Jk/lARIfuX19 BykO4/jw4hL2JhTYNCbz8MLbTj0qgYfUYLaaUfMZAi4QPcFClojZziQuLImkczmwlASqIDYlV0oS Mz/CMNCQfQ9tjtBwG7Je4A0+8M6ia0SOkEbZRCgkxEg8iYrhuXcQYjunFMYEKa/MaqIoKhHeWA7L +X1Cfs8/hNOLCdKbd4jolog8YQoZRg9vJ73pp5Bh7iksahrKLcEr1kKNpAkZViRCqb9TDg2eCr1D i4PpMFh8eIbGnHTnla3Nz2VWz7JSiicNw+d1PqUM0QRdIHdBhQLvngvLn3zrahOM6RE9YyR4ySex HLzsnHEX6Y7TyJihIeWk5qAltEaMtJPN5MLwS8RIsPwJBOwrLLKZVUI1UZ7DOVV3wB8rgPoKRGeG 70uwZ1JymfMjLvpP/whLA+DP6/7zmh9x0X+2R1xyoft1g+u2pJHpL/ek9p7U3ZOcRttztDavRDIt 8/z/JDcGC+6hRQanFCuQgmPCnx05BUy5d9sNOgBDuTHWKcxmeD4wrOuI2W4jfnVvyvBnbki3Ti2o fIR3wyrdp5/cnJ6+oI2C9UywmBZewcFo9AyRI1ULBj85wzHpfSh2YSuNGfv9M/g7UiPHToeYIear h0XQcefIAjUzbCYzAyNHstXgT9s8RbFhLHwQHFN51K95wDAtc/DpuD5z20n0s1PkZOOxS4fDiHUV LSX6moBkzj0gGo7dawh/XOoMUSYk7OmHUmDQYPz3D+BJLShc3yAahVUVo87SkIO/Pxdo+pTDuxQ9 DmKFIJEfGBn9QZuJWmD6PTGMsMcEPix19VkAFizA/AO0PyJ35ga/wckTQUNZBZipeEBAyCzbRu2G zm5cIiJ75E/TsupyqAXg71vDWlXmRU0/0PHduGpgY04qxnvc74J8hFY/tBXuhkkHkiPX9h4zBCZR 2wfIbvgrN9C9h+FmlhLZ26kj1n2DKJOAnqEEaJz56lCmQgf9Dk0EZiXsmMPW+Dy8u8a79IUHc+8d OccuSf8SkTMR6U+oO7N5VmjMkIk9gnpi4K/d19kpnzeI9CI/S87G/C3isHvUfcQ9Gcots5+xoJ+p gdk49mbqgOzHiusA8UO/wjdDw38I4A8OyI7+RH4Qk3WnY1F/6FsyTYjrh1kTQQL//kGjYtn7LeW6 ljNVFOb+P1GllW6L9n51+mt1IOuy+4Xz7mFQWVpXtX5ap83Lpl2m2Uy3Ut3KTKuo29biQKaZattX up3Ktt1OxPTqpqTHWnTTU6mpZGzbsjl+ZHpJc1NxM5Zp6XGbb8jmIuP2y80bzWyaXk3LjLU4OPu5 RlOLDpGILJ896CX9Rv//p09uKRd6O2Jbnun1dd8Updtp8wvatNP+72m3T7ovqsrhQpr7y9oZlVWH C9OyuDBtiwvT7r6qX+taqrK4kGmhLC5kqkSLC5lK2eKiaXW4aNodLto3zGzaXm1LjwW39VNbwlbb qf+j7HY2N6i77Wz+omu/BW2nnlhhcSHNL6F3MzKX9bbzFKXFRdPucNG0u5XmrpUVFhdCNXjr2kXR 4kIoVba4aFodLpp2h4v2DTObtlfbavZjaDs/oSVst50qrdx2SlWy7fSvYS5pO0V72XLXlumsm5Gs Z908davDhWh/875blewIuunVtfLa4iKvC2Fxkdcqb3GR11K0uGhaHS6adoeL9g0zm7ZX2yrEyHZ+ QkvYajvzqrnnsd3AvMv80F90a2RO25nXzXX9XTsvZt2MhJp18xTK4qJpd7ho2t1K88K2MulwUaSE C1VbXKgq73BhWhYXpm1x0bzRzKbp1bTMWMPb+QktYbvtVI0t1GxgcwTDbWfvQIZi26kU4aKTDWZG pcWFaVlcmLbFhWl3Xy0sLsxYHS6yqsgtLrJKZS0uskpmLS6aVoeLpt3hon3DzKbt1baKfGw7P50l bLWdWdnkWJsNzGWe0nY2f1HGNqXtzKpMWFxkVS5n3YyEnHXzFNLioml3uGja3Upz18qEw0VRO9LO isrioig70m5aFhembXHRvNHMpunVtuox7vyElmC2863+em4cj0aUSqkfNO0r225+XqB7p2lfHPx+ tt7pukhtuhdJUQpNAi5trhHXps1lJcxJ7aIs3P3Hf3KonaAi1zbW/E8PZVJoepTzP9M+WZKXqtCt rEhKmWXzP9ewKqmyUsz/4rBOlBJlPf/LwyzJpCjk/K9M57os8/lfH5oLu4pUzv9Gt+qyEGr+4/ow E4m2/zPd5bkesipFNv+7wyLJhEbe/G9dnx+vD/OklmVa6iFN0U1dKOcV/m43lIgRlChRm9v9OEq+ OsxUotI29SMTWVR1bSIAtSbBIjdurH5eVnluAme5SkRVmXhWmZQqFU3MtkhkntUceErAs8NKu76p bLKjdvgr9+YzPWaSC6nYd9rAlymGmF8YRGqTvuRDsskx6MyNdHmop1kWZWZmXCaizFPzOFdpE7JS RZJqBTPTj1Rh7x3JskTVdWai2naSrHnp5svmRkCGuLWbMEMMLddOMuPYWKMPvXUDsTfZctcc2sxe mkJcPblCysJfuUWMifrkWgCUdsGy5AuicRiGL9FO4/0j/NunbJILNzh11ivLc80nysSr7XJh73Nq uo0smwq1NpL449yRWYeD2mSn7OgbNzpb2e0oES6p9xvXe8I4Gpcqyz2usXvCEOiRGRgToZX1oe2j 3kvIvT8eOsQkjvZY5MkKa1nkTljLRsu3bVFXTli37VZY70k0Sy2Oqg8vmv9+e9G8J0HMEPDS7dQZ l752+4nMLog0iWWJ4GicV4fPRaWpo5YmCqxfLPQ4BWclO/iakTgSgJ6cHRGkbwKpVJsfhAcLw8pm dZjr/daIwgLsAnAie5HJsufumyeIbVinU8ZLDDMWm3rKeWl2ly2DMfK5mwcJVxpxTTvFNSaQvQPK xDWfuQkRNug7bEILahK2oMz06ETLLc1HmaYT26fA2LB9rh1eaD1MStNGejrLDs5WzncX7pQVnzOS rsccwyE1EzJpU94g64NeZGiDyp4Gf6EljcgrUTHL6V8PzeVamX4vo88kQIYP8LhF7zHU72z3lMud fWNEVpWmqrmTRz9QmtO+d3OjMWmjkJ1AZAl1/oJbd5BY7Y72NqLbKDLF4EZ5Mi00Zzje3OQMsSYq K9Iosa6h/GLreDjM9KhSZb5i79D1epx9Nty2MaNnpaqYmXPHhiTbxFnQiKEnoAPhlWwoYEfeA8OK vXjHeW7EYFUe60NByHifJCHkfTs4lPGM5DbIBr5Cy3A7ZHZmAI1uj6CSOUWrv8dGNpu13cQTrJPJ dguJYYMszFCB9hWTHfIY4XbgzXBCjIuY/PhS22BCr6f5vRYgdDzPy6r3W27Pk063y4SOCrOup/t9 nidqt4ChAdIdF65sBy0bItU25AeH+GRre8ekRSjtrYbNy5jQYl4LfYekymuEGIY4rnSA0Pq6lXi1 wloOynjPDeOLHFfGdkGtopKyVVTaXq80MgcUVY+4ZM+6m66qQgWPzSrstIJF3jqB61nfgMwGNt2a 33JAaIVs0rAW1FWIPF8D+iM1zwThBgr/Aak6UbxB9wF6roTmM2YK2dZQkAcQGEPNL4G2ggKEpsmI hUZ/hniHhB+JF4g3wDvcDfEsZ7uyAUfieSaTUig5tHJa7nSfry9uC65quKRxMxoQNVB5gxAh8tVY wOfKMRTUBdSb4ei+r859h5QLuhdO0DVWuqwLoa3050Lzo8orbqZDQbeNUsLS3pmobkwJODQwUJox j5Hmh9E5midjPBg+GHAWLfBiQCxBoUvhUoYyRg/EFJE4IzRXtuEU6HIDEdGPfVm+bkoSsVMcD8KM Oyzbq/41FNLLcVOIcc+GvQmNVRLX7EPQJQfWCKe/UKj5SqnzoMjQ3k1SMTocIYrGpn9fcRi+W0Dn QdaEqozt2924WkI2SsSH8kQ7Cg29BqQCCYAJdPI5/wtNk02E+7ZAkZ5wC2Q0IoSMMhzvg+JtCSQu FPcwHAhD/BDdyMHazV0el2JcPQLpg/MLEb3x4Cxx6BEgvTCQePlG98pMvWupda7QiM9KyXVu6nbj l2iv/8MZuGdIBsMton3R38m0zhUF+8yPhzihAlU7tizAq3A7PfK0DEMmjpcktUDm/9OY25hS0yMi LfKKsqiwczElupnqfU1jntMuMT7SDF6Mr9GZFdOZEknhxzICCtJ+51bOUDSQ57ZDMkqFOwMF4VMY VzBF6QfRrXPohrxAqmy6c3iG3HH49d1sDJYzAmsj8Rm1vsZ8cC7UPh5jwy7oiksNP+zceQwgekkt FJzCuQa4wThMegvcbi4+RlUADa41iLUX4f5CzmEGDswEsiaZLSeIot8hdGMpaDVMBjWMF52PuJSD 8ekgloTTHhGfEjgMx8jwROwGDRzC8RnTVCThsR4lEQ94DIaSXe3G1AjLcJEIzFhCb3K6IQaMwLGi Cv2f1BZVNO2uqELUqrBFFV17n0UVsizcL7h+yKKKf/hQRRUcAS+AeYuzB+dI+JxyTwcw6Ami9wVi uztkIbIxf+Fiht3JSlBdwaJWrK6Ha4kwL4uFImZt4B4MpCOmBgmRGbjhshsIX4ZT2rNzIOhgvgeW wMFtHgySdFIcZYcnW91c1J30pXxjRAxk/cc8VlyQg31FUnuQHP0Mb7diqCAj2w5jmRs0EGQgmO31 7RFLfyj6cYm8qQ6JlRogP5jeiankcSMEJfsnBImDuCD0cWLxJW8eIAMbT1NNrBKDlEQMx76D6hfj CWs7t9yTc6MZWEpnMLN7T+VOxTYR2f/BFhTwkRgeLoGtzkkprNyBVtcGmNVYiUFmniyuo049oLOh UCQltIEG9fxEmI0YUiJAMXMlApaCrD6sNLfTIu3oMG3rpcEiedfRlJMfeOxkGar4gQLZC2lEiruA zBywHICg/NaUlWh+0iYlZeN+RbUmjN+ZACzc+CzsNGZvi/a0V2tjq+bYe9s2B4Gtvd2292pvZ1rM fHhz+x8/mLlN62elRBeIASGL8MdhmAqLYCSyUFknNE8jzr8nWEPLDhnmW1h4XPDY7Bh7/BNiWViF RCIUGk70GBdVwMhELAzFxf5oVhK6DbCCHXvqoEaOx/mmR1L2VPe8U2p2iJC2V6JjgWI/SDEQKAa6 HgbbkN0GY2kepY0mLSOhScy/DnHsO6/5KklQAH0Dz2NtXWabVqwuE6LwAtsTlq3v4LYg0RXIj97+ X6M8O0yjwjN6qAoEpq+ZYXLuXAG4Ss8SG7W7UUzvDW+Op9HHjdN4AHV6GUZoEKL0c7ScMVZQOPE0 D+WRYXIFOBscU8xmhgcfWDIDKgqeFrO4xModhkqRGBnQUqOyY3pFcLyYDREKIi5ouETK3qK7+SGT f2gzJidl93/8aZtERaSGAVmQ4YHfwawDOBDAZNA9ml2kvt6La4QWDuu9QaND2hoygEfLZWhFkDEi 8pWJ9Hvg6BIlQGqHOxi3Mbc4wDE5iiXRdsEDCTtVWo85o3md1dYZbdqdM5pXSllntGvv0xkVUnwU lx3804fyRjkCPvbkT6AfkG8Jj3o5o8pz7iwv7FTPGCsgnlz6+h4r3x6pNdg1EXQeCGgNfm+CE0Jh DDursVaO1DtH6qe+pTgZFSMMBc+AYQtrtqDvCGfHwwzAqyL7gNAJi3M4EiJVmcCd2CmWWKJYogpj idwwGopgwRtFoPsGKurxEQYUaN2GUKGDTW9aD9nzz2wfrNaBp+G5H3bwIYMIsM4dIprp1anMx/rC qeWvnVh/OW7lQvVOBD2qvpUi9W3aVn2buzyt+m7be1XfaZqUH4H6/ucPpr4ZAqgOMxZJgSk1fPwb 2qTbmJFAVRfdj3B8PHWDNoEJw1YRX5cp6AuELHgPjVcpG9oEMGyJ6miBhMuGxe/4CVSgPaA4gnlJ GJlgzhQkPlhAAW1HdshvMy4XPbcMWmjAgoPHyAc2YZtrHYKYFFddVJDEfLnfuoN4JMCZVGeGCnTW opFvWHc/OfANLmYgfJ5ytQ2Pk4IJ3zHUgWBARN9NP21IEmTgKhxQeQ7jIKjGynN8QegZ+jOwbPUF OOjtX31G5T2Wyd+iD2119Vk4JXgEmeHLu//FToRlsVByESsYdLHHwNUDQEDFjuZFbiuCARl4/mwX X2DA0nRIhFmuSDH0t3ptmjJFJVnJ+K8ISD5Nzc151xRoUFNTHp4+iPnzMFM1tDx4bMB9lBct2xar 3lSwgjzxKKfTbYQU77xQ7PKg0MWC3jKVGNGGXiLNBR0Tj6kAPfDLcEDuzjtbOFH1RB7DM9j/SW/6 kqlTR56+ghF4yGssWbZGiNifGEOH1/CZjJGCYi5lZmzAPhUzm+8WUDGTib9wwM9Biw4Weq0O5+R7 M8kL6up79wEx88qimZEW6cQTpFcYgySHoY+4RPv1OYne/z7UXpbKKu9oHgXame33OcdWaCtHDjzd HOqRzW93WJL8HHnjazSyd+IdpMbYEt1QJfB+syqrrPfbtDvvV3sxwnq/XXuf3m+u11F8BNdB/suH 8n45Aj6ee3nDWkZgkWaD1oGdG69SHYl3B3GzxnWGBrin8NvleOUqXm1BeNaWcQsy2ihO6Z02A5Yx DFRHSmlgxHqJRt/TXbB9WwPEvn538L9afGQsZW5kc3RyZWFtCmVuZG9iagoyMyAwIG9iago4OTEz CmVuZG9iagoyNyAwIG9iago8PC9MZW5ndGggMjggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+Pgpz dHJlYW0KeJztXUmT5MZ1Dq+ySw4ffUbooirGNAQkgARAhw4kRyOOwqTJUU/4MGQ4erq6uptT2/TK 1sE3/wHLP9iZWPK9RH5AoqurhpyQKVKR/ZB7vv29zHofRGEsgkj/ry2cria/eZUH59eTChy8+n1T uDqfvJ8UYaL/qQC8fLoKPj9WDUsFFVKmaXC8mERhWRaxyKsacZClYZGUWZCLLIxlcLyaTIPZ8Q+T MkzUX/82Of7kzfTlLAnzKJNiup4dxZFqkOfTmwooo3x6RsArA2Q1zwzwpgEW8fTIAJ+j5icEXLjN pZpjNaW4UKWfEvg1AT8zwGMCSgNMUfNFA5RFs3YNPKGa5wa4ImC9n0lq9li1bk6jlKa1Bbwk4MYA WfPAAAMv8PvjP0yEQpuklAqDjueTNyMaPQoYqxXv1vwrtA0PqKYwwIiAkQGWNTCNkmbFR+2Sj8ow LfSyazpR///rSQ2qiSUwxBIQDgcGh+eILq4RWV0ScI3oAtZ0T9fCN0ZBtwa4JeDSAM8IeI1IYIVq nqDRYfMbA7zoNu/ME07+Ao1+hYBBSyyMBK4RQpwg4BJR0DsDPBuqmSRqmoBYNogW5wixbwh4MUzf AQJeEPAM1bxGfa66i8MkoIVDTfmD2M4wc47kBSH2DQEvDXCBgKcEPEGi4dKgwYaAa4SEd4jlEgnc dllupzkNdN09PQ28Qs1Zn9cIXedooAVa0RWqedNi+37Ovhcdbw1wS8AlwnbYE9svIgFGF2s0kSsD fIb6fItmd+NZx8XwQHsmgWsDDBAQksCSgEvU3GVbltrAEGZjgHMCBg4OW8z5BAEvuzjMN9Wii1MC Em9fotGXqPk7REGw5kV3mYoEGD7NRzPKkx1QhzH8a492dD+M7b/28HYoBbaIFonomZYXNlvj02m4 7u/B7j8ifQQqKWcIkRmQ6ODaGcjGL6gprxEiL4cRGXLT6y566tFPu/jV4eU0EKQtH9cfr+MYdeYa 4ewKIQDk+gyRrxBSEfqdEXafI+x+QHRygsb0TQTSHq1jiYDX3T4xdo/k1YwDQ1N0jXB0iWoS3m+c Ptm0Cy3MgBx/i1DnBtWEijRxyweEzcyWPOmv2asXsclv0JRuUU2oQe2grjwecRXw3AAfCJuhJcvY 8q3BJzYmNAigugJlziViyzuj6xsCvjLAFwT8wgAFAVMDlASMDPB7AobN6Gkzw9bKrUze3x1Pvp3E ga6alUkRxNoVlRXauySDLCrSQKRlFOS5BqiPZ5PFvl1WMhbVTq2Gd0ov4CWiYVaTyPWCgGSfuzSs gA8EfOb0qZD7pcH4bwhIJgf0BzFTnCiTCZ93SCbcIHqjPu+76NcrZ9jknxvgC9QnJGzHaFeEzUhn gwgiRkAinZ20pLXHDqlmXPmYoNV9goC3aCKMBbxHNVtHXctrGpq5VwidVd7dTDtysyImollxGpLB cvJHG8C+x1lmf9eAFXUXZ3n1vUukaZY1/UVZIMqiCPLCIdL9O5hllHhJ9cO5DPoslkO4DEIkg1mf X6LR7xGl3yEgqa7PEKkyaw0qEJdAo6RprhH9QtMIUgiU6+3OKRl8hUgVUiXjBAtE9AtU8wrVpHVA e+mKgFAh3aCaUMm96U6J/AhQeraEmZaKeA4uPdW4YSZGkSQjn40BsgAPRWgY8Z4b4C0BSXqeOQMx 9Umh5XtEU0SnTFBCTzQRr8+V7IqlQtt7bU3mbiCKZrQ/4IbrVcrHyVlFksyndYlw8RlCO48Lg6kD 0IVxikjyAvV0g2bnM0GdEMFYoijSMhAyzg5LFEXaREH/AuUUa37vYEYfVhNNnXdpqjPPepfqNgZI tuIaLfN9t2bHyIKWFzFjKNLeIgw9JeAG4zKgCp/EhN0P+C462idJL+ZjCRtgwYmKRv/M7bPg5GVp non6WhPWSpXzWJWzuNIZ6a/2Syn4F/3XqmlfClF9MYrjnkgxV4VRlMh8MbeIlC4M8BlqzgiZzEA2 0KVzYBbawzAP9Bcyt4tHZs27ffIQod9fCJ2dUDyxyZO9CWO3y27NPuPOpxVBF8ipATIv362zdCWe ICH6wri3aEyayHtUczD2U3vL/7JlhHuQftchjP3sz+nxrMXMPeFbX/NzB8kS7SUcVpyIRBjjhzqS K337wlXE+J8T8AXq87qL2CMSCByzZQcfZUzAEHFXqvklAcnKuCcguePuHCDjO30udWJlTKVZI3yD 2E4c24kadSyXD+PNsyidkdUSkMBbdPYwGg/DhhBLXBwdQQIfBF3tgWICQmsJkpUj8p8kBRgOj4/r kybD1JuzgZrMn9Hn/2mSS2TqtZQJtRYICOP6H0wGQbpYdKfUwWwYFyL6DRHuMDR5aYDMKKDIuxWb BDQAreL9pW9CRWuF+oS5kJU0rBziUFxt0ED7SI1hSs8GYTalBDCdifxKKwISYbgZyrZnZ7xrhpDY Ucc7WjJMjVk4p2f5lXyZNRs0EAzAbFGfNBBKHmAIQRa0LxgCzWrilOeoT6Ye3SG6YN1TZNWJoPSa 8k76dAddV85ErNk50SUdqjniA+2I2CxeeIdwmNygTAxQMuOWgFsDdNOB2ab3qR3QEQMj+QO+0Q5d bB3ksPANJm2xPmE6MEU7xvubnhPwBVB69qZBRAjIYhgw3AiJ6adQeqC7ts2Re4JSs0XYDPHeZwRT nycOkInWPp5IuY4wJuYgbm9Nh/n2Ol0YLS3QQI91avb6gZwk/L4wnS/MTsIIhrcY73ZzgPtQHGZu MefqEmEzTXmLmjM/KcyyJ7xn2zCU1lgz7GmT1sjyV3iOY2pQPURoyfCfMmpYnsgGofopQvWG95mM mukjL498gQZdd/sfQ3RXqKZHrozLTewoIpTJxqgGxrFd88yvrkHnK2t+MrrmwEC2XIGBZsJ1ZgkQ JTopOGP8Sb5AHHXPzANybMGAiM/MeYEWB6PorRP4Ceo/vPX0UecOf9oCY07gg3HNROZJIPIiPmhc M02TMEpHRVPGO+xeowOAgp0Zeu6NC4tzvCHgKwNkofEvDFAQMDVAScDIAL/vDsQFlcUP4F20OwJC v4Yn/wY67BxWavOY52aaLwjocdj57iu4eoHiMdHo+wowkwfeIIX5c9BSYzWJA45zlXSS6qywZprl LWnphDpGaXVCnQVg3/M0s79rwIq6y9PhhDoFygIhIpi3s/+EujRJQjkuQjoeCNNfGU8eUiZsye3e juszUuG9TXhPYiCrp2OPwljqgO3YGyyAnnmoN2y6AymahobYpovMvfR1hSgRXmRlyno46oa2JqBj ApIK/g5NZOz90v5cAyGzVFOIpjhVrqilqMiJ/mq/SJmzL/qvVdNeyvIQuQapUJs1LhduPPApwV/G MT2Od5lOf4rgL9m9TLGGqQ672A8vCfiN2ZA7QjeJEPMpNq7lFrQk6bAO7ia1Sp6+7g81DNmrw3pj IqNAlEokHVRvjLLKOh1BGOyKyf/rjXvQG9lAt4iE0E1Ajzbo8z+OdIT23Z1iOh5MBzqE78fNHZY9 lzFooCVqPuAdHdAwNRGuOE0KW4PUAPY9TTrfNYBpmEqlG9YwRSEC9Z/4MBqmOlv9ANF+xSK8SwWD fiy+5x5e0fNYyfh8bJjwRvQXE5DeiikQn4D3Nh/Q6L5HVeCU4JMQxh3sixR4TMnH389S1L/w3JyE DiM3bGS5q6DayWYHQ9xL1CeNfo76bBjSyLTzRERJQ3HuJan9EVohw3xc2vl4oCs8+y4zs+Z03kxO FgYDI0QpTFI9IEkFMzdChNWEl8eIKGBo8YPE9u33g9zQvoXKT3yBq9UbFKGdIEKDGYswxLJTeHz8 +0GUE/MNAe8MUD6O0GLR3kY8oD6rUDwUfn22jtCMJTSWpgtfDRiZsdLnYYC20skwAjOjDGaCwbDl 1mluTr5DvJ4sGKjPblBNFGt5vNPDQnrI9OGlDMtMHA5w0pVhX2YxFK3wmSFYEzpHyTRlmi+UfVCD d0zPsSQZpbL3gvD+SFIqet+3knlMQJJ9vpeYSMlkptsGkc8cEcUujg4nFbk3XOVcpOp4aU7R6OPd QbTMRXee9kUPDypDyw42Z4RErza256Zk32uPG5O8LJA3wAtdzIUE2QDMjqTs6SVaHDRbA7RiGC92 8igHSVKUsvgAUjIrwnRctHA88C0BKbf5BtV048KllUTpuU4C714xOeV5TY+5Ll2bY9jh/wEcUW2u i+vQ19P8EiH9PUJ6HyW4yRgj0vthT1B1dO/U+UOIUPYx2qcQIpsStImvUHM67HePI8mijAIhywOT ZFqG0b6DfcwVs0A1KcfId+MGJkuQPsmCfSSSYA7fOBuN61zFYP51B7i3/GumIZjrkD7DDLow4N0c wlpIvFbUYlhKQlvzEFnV48OC/YQUx4GI8uyw6mZShvm+1c2nWIB9qHwIC9AJkOvRYYAcZt36nvMk LgAfkztH81x3gbYF6HkT0PdUjOd9ACcU53/izGCrjkdXAeqDYqtQo49j+wkBPfG3Vw4O2pfUYG6o e3+qz+TZW4qd8yxyRxP7FRod3niAvspLhJjUJ7z76UnIhtFmD7eF7wgOMtYRt+A9rrmUNJwjRGCt 1Cj4bZhx7j6ipWHyyXJ5+PB1Esfhvu0Y9oA/3ea8IiCR1CminvEqhu8ejid+9RUBj83or1FN33WG GJksnpiAz9c4+uVP6GSDtr/HAc8ypOYe6nH9EQr4egc7hgHhbUyYNg6tKI9b0XEWOo8O9pBhWn4I f0IkxmYfjweyPGVhgAUB6UlT99WXUmJvNnwrzJcr6HEIOOTBVWyLtqHKdog3BJxn1hQdgkyJYmSm RIcmPLkfFk2MvRK6b/LoTNmNeipgYYDwBiC76fSARu8R+yNIMi4PH3EWpdh/8jAMLs9RTfdNA9vv vTfqixHQob6ON+Ow1Oe8pNSh/fOWJGH2oM/kdn+Cx8JalpDsZrWMuBBA7ooHNJGdLh39HjX3/ATI kIgf67hL0lgRmkwPKvtEkYQfZ2bxrqGkgcxiPfr4Jz3254MYSDZRdMaUPPdFzD6/nRsslD1X8khZ bVfZl0A5PswGr9n68qqoObxFCGUsXLGjiY/VNoUUDcUdUrTlieIBHyKZCuYsM+CPSLRB9wiUTY/9 RUCYj9HxmezNlei7zUuTRzkeMFt+HK51apJdBR0p7HEqqG3+yauwDVK07/6Ay3Qt4ClaMWwOnyoZ Q3KxIoVSrVn/cVA5J9MxP8bwOKpjHhT4KyuUxsHurcF3CRuyYXldRc8VNUrM9Umq7u9juHnicZpF +gj0NUJVFrrc3CE0f7VfRCbZF/3XqmkvsuIQl55EluGfe/UcH/uBEQoQXqGa7nse4299247mBToU EvXQHnjC26Ydlg1N9E9rMqyYornqPeUPOky770zcmY31peF+jsQJuRt/QM3ZM+urAbKy5UGA9vAQ wN+Z0X8kIEWImb/Qcx2U9fn1aGlEHnzn/o4db6JNYp4AspTgLw+ymvQDssxnUDob36cAwqSOnwL4 xgCZr98T3WDNUwNsUlc6JtmbQKT43+/VVsw7r1SXZRqkRfXjJ0kRFfWL1dVb1OYv835188URh2Wh X6qOqvvedTlWTcsiqn9tIS3rl6zz4HSSRnFWl5eqHKV1uZ6FbtWUVF+n9dySvLqV2pQz1ZtuleSK C1R9VSXVrx6jKi8n1ch1DT2bulVdUpVOJ4tP1B7Ve5GESSyCe7WkP6j/fvjolnKhjsN33vo3ceox ZXUhqjrY6jq9OebqL7o63NzUr8aRWdLuRSJlVu9Fdfm/nqcuNXtRlZu9qMrNqDJrS6qvZi9EUebt XgiNflUrUeSy3ouq1OxFVW72oq6hZ1O3qktljo/1Y1vCo45TiOpWd3WAlRpkjrOjFLHjFElctHsh kiSq90KVynovqlKzF1W52YuqXI+qWzWluGj3IpZCtnsR69+RqFrFMmr2oio1e1GVm72oa+jZ1K3q kpADx/kRLUEf53s1utAV4ri6jCjKurxsykVa8w8h2/LF5D+C9U7XDlW3MpR5onPZWs1UbVytmaZF ou8bZoUIy8aU+KuZYuRSxKKY/vUsDaVClXT6N0qohCLPpCrFMszTOJ7+rYIVYRHnyfTvZmWYZUle Tv9+FodxmigN/Re6cZnnYvoPM/1shozS6T+qUpnLJJt+t57FidLaZKyaHKkuizyJp7+cyTBOYplP /0UB47Aosnj6T6b5d1czNc80V1rWL2ban17KzEi4b3fbnWRgd7I00bok352v9AyLNM20ApSGqSzK UmkzhRK+UVop0DJMRVz/WIQIRaJqnszUUjI1b21dtZ9PDfCWd6QvpGtE0fpqW/VmJrIwl3nMu1/O 8jDPoqRyC7ftn5kxA9Umqq66yyhMsjQ4ysNMmnuDbYM1FXmH6miytFJg2/4+oYq35jNrvaCZ026w NZybRloxFEWcaEW73QLVkRAKGzJtjLTTYIud00CfsMnFalsKIfTjBe3g3+gZZ4r8Yu0lbBuldaMi Yyvamo5O+KmY4jtqThOl2SmjKg+TXET8pO9nsZpIqpC21q61QdiYNVXxgvo0B5RXUaHaXHlety8z ZfKpxSm2kkx/OztKlF6WiSq0Qs3bxbO9wQf7P+Y8aPY05TVfplk8rXiOxjzhaN4Cb+kQWaeXZsz3 ZsMJgyC9sONUGxImQtkO7PMdOjjC3lt0bv9KZ0ATZkeQGYtxYXbLIcY4z3ZE5MHNfGlGVMibFKrz MtU2lWoj1XJT6pLabKkjyF3eoR1+BPK2Fftwt21D51MhbBZFnGn8dqbfsohklTrgLuJ6pvqWaWoN Q2MvQQlSjYPC1UHtiMKAgDgKMy4I0Gx/OAyOL2TM/Uio7cqiNrxd+T04FusAS5gpU5sfG83TI7Au hxFlbWa3QTgBOycspVPfcIbhcnUmUjZQRFJVC00HecvX5jA+M+heb5bMylin1JHMAGsjEtogpKLP bJoPHqZv9elSCdsGOpcfgYi2+IjCjywROUO0FE14Czd2Yxq9RfoB29jVTCi9UOlMGlOUlpIUhb7J QhzWRSlCYwu3eRON27Gw2JAruAiPLqAEvEVTh6yATf3SqFrE3beoI3So+jBrgpG5NAxIYdUNkj7w uP7T7LzNQBpMVbpArNSbRDu7XAT4boqOEBBMdWmwxTTEFS6QeGH7YLGFtk8GZMdAGAIl0QVNhPae SdFztk4grS0Z3W43MRNbN2r7pCl9N0PchFQAH9/B8mJAhRjQhc3ntVFWGd54pBk7z930gZaWGPk9 Rh94ki5rC7a6RNx5iYQROxhu8wCd2MWQNOc8la3oaCaUaRvnljzZMK3VdErGW4u/aamat8dO+8Ww gnb7hFGcmYclK5tiDvtkdOhy91jPo0slfrUGrPFseBY+Tsrw/cHosuz7p01PbSivRZ1KldGT/rOh Z48yw9DC1sQaPF4avmLZ1Mw+cxV1i9pb/CKtDA7JFkc7ApUhrEZeMuVhUD3j3BOokVDajNeQbLnU 2NLoM9drAWt+20WlSivnvJO5EVwZ0KdqA63dst/BCW7YubV8zjosctQAXXwJdA+/7wCy23Ztlq7k cq811GeQDrRBe0j47tM87w2LvoBbvEY0bkk3kYf1qznttp9zyQ/tY8QPEe5eMrUYOJwsPZFtbFcv ET0LYoP2KLlA4IZAs2XWA1RmrDkxTdHSTdoFMhy6ZVrCUZyGeZKlfTsJCH6OWCVW98+QxnDCfF5A C4E7PZp+WOs+qeraXtDsXA/JvQP4cuC2XCKrEBLPeBFCStH/kiBmAd0mhJDIrGhDCFW5CSHoSGwb QmjKdQhhPwGDNBHmldKfR8DglzsEDPYTHuB7QWrrOTLALA8rkL27uOCIeWwRwvpxsz9QwHR0ZSm1 tIRE1lsamlAc8iW8G7TwK+TugCwIORfgkCdYRWtb/9l8/m+FlVFe5OkBfKFsaBROYOKM9AToD4qg UCem9yih7oaoCLabGTtWPjFZSY1Y73OmQg1q5bscFfeUUETvxSxRQ8bq+JmdSo4WK4YAtKl/NxvP zEtWJOUT2uDIt8Oorsc761ocW854Gv2MSxgwiTUiWU7mLpqw450zF82TaIFt70h/a+yhBag+93jE zTkhhLKkNfDIOzLaMWdfG+xoV5+m2FFwDvbT4zCD2hjjHlt0wB4FG50/8FkWzAkhwcwvkJrL5usJ SnlcKVBbmyPrC2HpwusvBTjVVeEaXy+Q5m/RPNh+8LUxjyWx/NFBC+jjd3EHRubZvrITWA5rvHC7 bC9iPTiJhls+Dgj8QZ5KTt1TUtvJTmD7ukXoAeNxX8yUFpooQiTOzzzwRD/M/cE2+3Ol7SbqexHD VSJOy7YVik+vCwlYaltOViARBdK5xWRanxzTPCB7t4zWesuiyDJ7X4MAJzKk2T5AhzNk0T1zYhKg pRdhNrQwpQhpUFz6E43eDiPQFksNFjFxHfBbxPBg6sWGcSfAcxinoeCFx9pmtDE+Zor5Ak35vxT2 Z1GcpmKamUY51ZTojJgros+VN1LevyLiI71C/0Sj4hlKoE4ThgKmOVMSSo9D7NSwG8tYYqdIgULg CEeIsZNzi8iDR6hadaP9qTvuBxCJSFs/QFVu/ABCyKj1AzTlffoBRK5YpPg5+QH++SfzA/C9eI51 SBAc4X4C4PV/sptgVBrgLvoh1DkFsUFou3BuDlWetqMEuh5gGhdeeU98CIQPrH1ARiveCMAU0AnB +GFPQgLgSOTMZ0EU5sKcIy4NFTWfC4bmdMl0PyQOoP4F7Q6U1mP5fsEmwrgAzA3w5tVZWaEmIQYm 1jEd5+fmNe7IEFc1gSYFC8RceIQynB3yCMFYOjLGgB4rtdrVbix0AEBkosNYIlZXWGyCScrmPFsR WWZJIOKk+umgUr+DpsvLphzJOm9f16nLo0XkoFgoq/u5Ii1DSdc+9yNyWvGbts881Z1jd9Rj/MKD Citp2HbijMc9BLAvweeGGag3pcsVH1A3tjIPXa4552QEPCv+iCHDXyslrBq2BNRVJSuhnYIpInAn x/tXuGMCaeHQCiDnjoUw7Y5feWQ8xgJX22cjwtg5PFnCESvZZNCS6vHegMQgiGwwVwDmm6F8WCuv 0o2XeE7NwukWP2FkhOEMjngjNnDHkQKGed3AAHQ9jM5IleioiIHt6DkcVguR3KIJw/j3GjEYjzvA 51kkzaHHxwvok+cHAXuenQURBk6YgCk+g+fyc9SLhJcGf+NxWHp8bNhv4dF+xydaMaylJf8J3cGB h7zw+KkH0KmTibUFPKI3exTehHKdlr5tQHfMYEoEliHQFfLt5P8AgHMEUmVuZHN0cmVhbQplbmRv YmoKMjggMCBvYmoKNjkzNAplbmRvYmoKMzIgMCBvYmoKPDwvTGVuZ3RoIDMzIDAgUi9GaWx0ZXIg L0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V1bc9tIdq5cN2FSleQfsPZlqS0LRjcat2ylKp6Rveut teOxNdkHeypFiSIliyJl6uJR3vMLkh+cbgDd5zT6AwHJ1FySnRm7mgd9P+c7t25gPo3jSMhxbP61 heOL0dO3+XhxNarI47e/bQqbxejTqIgS809F4OXji/FXh7phqakyy5QaH85HcVSWhZB5VUOMUxUV SZmOc5lGIhsfXowm473Dj6MySvSvP4wOf/1+8nIvifI4zeRktbcvYt0gzyfXFTGL88kJETeOyGqe OOJ1QyzEZN8RD1DzKRHnYfNMz7Gakih06cckvibiM0c8JGLmiAo1nzfErGjWbohTqrlwxAsi1vuZ KLfHunXDjTJzrT3iGRHXjsiajx1x3Ev87vD3I6nFJikzLUGHs9H7AY3uRRR6xQ9r/gptwx2qKR0x JmLsiGVNVHHSrHjfLnm/jFRhll3jRP/9q9Hzw9E3IzE2vaRlUmhYaVyqNNVQy8apXs9YlrHGWG4I +uHJaL5r/GZFXs3romKHxeuYYDR2MBJEjBwR1vyWiFcI7lTzmoinbhNPkMi/J+JbR3xBxK8dURJR OWJGxNgRv2sPZEZ/urPRczR62j26IR4BvJ6SpE3dNG+JeOaI67ZeMMQnSPg/o+aWG0mix9yO1wPX 6AXq/oqIJ0H3Xk1GXLcBZ2AUt4mm5mdHPEUDQQ015USzuAZ9nzU00spopsY+qjS38BPjC45GOV6O 3vkE/rxoPy/q57a7QlXPO+GeJXIs0zxBcN+93c7ywjgJQ3A/nDgnIjTJC0e8IGLItiJrTFDLfJ46 ItMQU0ectaFjiBsEsjMiXgXipYmXqDn1eYWIfZOfopozVPPA4v4RkWWIIiBq3K8R7llPoZb2dA1U K3DK0RaTbHB/iIB7jkaHK4bzZLj3MJ/EGh8agIkGrC6XplyjlX7ZJ3nMn5hfF017PVz1xEF2R0jN iijPdozUMyLOkIVeIQtNHJ2TtJ45ET5Gwn6Naq6JuEIIuEU+7dKNfoPwx5rPEXzXyCUeo3lCNUM1 XxLxjUUqM8YZgtrcETdEJFu+IOIFktsVstDQo4bmkAFoth2+20BpiARKNhAE+hjVnG6vOe13nncI gVMinjnigoinqDltVWBDjGycI4FZI8lk4kq4gBYsMCyt0alPRjxGCLpGNddoIJr8LREJ1Esi3lgI QIV8TMQlEscrJCUnSEqaiKO0StzmGQbEUYkodByl8rF2eR4vjlLalgzT0pKI/5fjqCCSMTVPkTjd Iiww1FCK4wla0VFbGlv6fGxFdLjrdEDEF0gPEhDXqLlNDXRpaZa+WTeTS7hloJ4ukfJkqIIO0TUC 0BjV/BTYVG+gJWoO3Mpuz8qFP4koebSUSOFHS4bAn5dx67kmsGgqKeX2aEqqeCwLKX+gaCoR0a6D qTURN6gmaQQWTIW8c55Ty6EhUDFTdL0dqNBCCCJScqxAaoINdOSId2h0Ns8r1Hx4MHUF7BPhY3hC 40HB1ByBH+ZoWE+XyFAeO+I5EaESCwPaLuNLoy9Qn5u2N7bdyopMdgJudziTIsp3DbTQdvpZixVq TvxmZrJwEhgjpDBDdYcMFcwwREiqSS4PESjOUZ99MIc17+ubaqCxMwMKe86QKH/hkYN1GzTQpgho zHrdIONHPQXHKS3LfoEwRVOGviur+dIR3xDx1hGz+wEtLpR2Z4vicYEmZOVg/39PD84Dfu4yPQjd 2TWqGeBUA405jJ8RfK62Cz1U+itEtAN1Ae26R/7PUPf3ydqBmoRTpkUoT8IcX2j7oAMf5EEGQzJO G0g+ZoQZJzvG4yERyfCxzOAVah6eQHlJBIadGULEQzJurM8wE1aWzJVdo9FZuvAYjT48L0nLnLfn eT9BhmEdbA4PqQ+J+G3POR0l/KBmYKHkOmAsVAJdB+NHQeTRH7OO0YoZIJd4F3sBqUqNHpml2aPa SD1ulO7aGT0i4g3yUKnmFRFhXpCivmVbWFvZepgCnCNUENJYEh0eoV2j5j9YFiqyNhJe/DhEYgfh AQUU5i9Z1AdtJOyJjblA3iRNmaEPptshpgjR83vZM1WocixUqR4XPoVqbo796VzLz8F1BWNkvZZo SszKQoNKmRR7zKNt532z6Sor5Q+gWrM0Soap1oSIPdn0t0FQoYmfibhBUkSqFbomTAzgRbwV4s4S 1YTJr1kAa038JRp9jYQQph5IXBeoTzbQRbcU+dl0eJIJj3FIozHdtwpWCcNrrVpPelRrT6StSA3u I7eL8tn7g/vM+OL6VWsmksc/jErNaLtWrTMi0nnphoiEqWMEn+FHjlCq+5K/1PwVEem4+ltUs+9g ViAnpCfHBw9mA7/Iv9R34sSuL2iG3nxPQu2EN98On44IA6Cz58yfES/Q7MjmLcNtyPBRGAyPQPA/ DIdpkj5+Fi1V2dDLtcOJ7BqudMSCiLEjPgmaM9Z4Tga8IX9AxBfdotxpcgJ4tBwswjZMwl0SkQDP XLFzZJxoSjDlwGp+sjj8ooPPDncbyq+dkTZjFwiHPxA8Ok6tJBELR4zRQEdEvEOjB3Z/aNSh0vzx T5DSJN/9vVd4WDRDNVnQHp7e7RJ9AhED9HFpenT0waCFjb6wkIRX0/pOXgi8MMksiBieUifmmvl2 00jprTs0ETZlygn03ab7LWq+QkSY7Q5GHwq0JC800DL1uD6ozP90bbU/vO9Dynr7POEtD3alYsvp sQbagxJh8BWUNWpO3iqzffBC1PDMObM+8GAHXpSAl1FpytDIwhUHrri5uDUIcnHcQO4xbZvQdXbt bsLbEfAOIiN+34yuehMk0Djd953GzgPWxzgdZlrgFvVJkw9CPA05eBd7mKy1alJgBVMpZ7wmgNx/ bvHYOjM18Pp4eCbnBYjzFrF6S/MYrRg2X7cHGgo5KcU4k7L64Rk6IWRcP5ZlHD7eNShj3fmuHU6W YVkiL5RObsNb7qV3k2LhkApv/TDzROnjPkMWsT7xtVAR57lhgXnhRpdLU25ej3O/3JPSe1I2T0z7 sn7hRjNUut4a5ir7JHa91eXSe1I2TyTrTcWl600JwXpzv9yT0ntS91a3Lx/lZSBVlpGp0H7dvkrc m3fuUydiUY80vUWKe46IG0RcIWEMNQmdMJhESDNR/pGAHky8RxN+QcSvHZFdq1eOmBGR8iLfBQP5 CfYDpNahVSCghJDqut/zrg2U1ujD77bSyWmEBvpdzzxnaJlWx+K3hn9JREqLw88JwOAF3i7qe6Xp DeppjcZkxGNEJIcRLu7f0exYroW84eF3FIO7fY/6StOXEH0h/DBxwhG872aI7O4Pfariw16PvF8i iTsOtrV4nJea6IwL4vItEV9YEHyNeMpSZarNaEOMt4vZARIzq0O7zrguqBFlIvryJJTdK4lYOmJB RHtfAkmpUdX2qxWPpbBzpLDTwQr7NXLOyQ9nvv0FEqGN81fYxeknSOM+RxoX1iRhe4dkte/gF76y QR5YkDUwG/KS+PnGEZ8SkTQ2E2s68nmDhPUQiZiXVQbCOvzy5XBF+gz1uUDN4VUZmGC44ANhsf+p K2cmXC+Rxj6Eyvm+mpDLjFdz+MdO4EDswhe5V+yqAkGYhRxTq5z7biT2fKqHEdsvlzZOaofH+sxJ xA0xij5rxSKutSOyc/JfOeIVYv4zIlKKk50lEAy3awaB1jJAf78kIoWWH4lIZ/8sM0TxJgsG4AvU dHEC3pJhUv4VUoHkyH5EzZmYXDil7l9xut8WvHJE9rmx54hZ1Pw1EcNPmOU5u6wPrdV5wFa2hsFs fBZsuS9GU0eEceIMrWEZ1NRrYNct4KkOvJhBaJ8h3sJ3ojbtzeoUIiYv5AhCBcT0V60t6sf3lJc/ oM1aoL2GX7djauAJgkz4cTIveIPh6AytdtxerSGyNzVLR2Snh0VLBgfsxzsiXjoiy06dBfvhtNVD 0wTPiXixfUgmxP+MdhvW/Bh4LF3HnRSjsFd2/tURWeqa3lWHbGVEShPAS9u2z3JrrqX60W3Yep60 /upk061jU98LlF854gna/I+o+Q3icp+3BOX/MYjP3ejfE5FCXiY5pOz7XnSGkQ08dqDIBn1CDl4Z YYEs+UowZmU1oQNVBhvflc2BF/J/DOJ7R2SBT89FVtY8dcQmOG0dvr8fS4X/+05vxaz1/amyVOM0 y8wnEpIiLupvUVVfmXK/6MtUCf7yQVmYp/VnEqpyHouxLsX1p+xUmZV16XikYpHW5aUux6ou17Mw rZr56L6Om7kJ3eHSlk3uvWolsmJc92VKut9qDFNejuqRqxrVbKpWdUn/dTya/1rvUb0XSZQIOf6s l/R7/efjz24pp5odffw23xmsxlQydWxWUkpic/WLzkOazwmacZQs3F4oWTZ7oZK42Yuq1OxFVW72 oio3o5auVLi9UCJ1e6GEKuq9UCIp672oSs1eVOVmL+oa1WyqVnUp7WDrz20J92NnXInpFnY2h0ac nULQXlRnT82M7F6Ykt0LU7Z7YcrNSnWrpiTcXshUFnYvpJbXei9kGuf1XlSlZi+qcrMXdQ0zm7pV XZLFNnb+fJZg2PlJjy7NNzarEzqVVoq0OrtryklczbCqU5VPR38crx70vRjN7izK8kSLgDvHaz7H rTenSMz1wyzP3KHwn+1pRZ5JIYvJn++pKBNFqiZ/oY1KJPM00yWRRbneo8lfaloRFSJPJn+1V0Zp muTl5K/3RCRUot3zX5jGZZ7Lyd9o25QVWawmf6tLZZ4l6eTDak8k2mvLhG6yr7ss8kRM/m4vizRH snzyD5oooqJIxeTvXfMPmz0ZlSrXXtYv9mSpy1nqLNw3D9udZMvupCoxviTfnWd7QvuXSk9rYRaQ qioFYvJzIpNVDiSLlBRlwYvaTstI6lY61rbNz/byKE/jxOYCzUmr8dFVpLKicp1tm7Ub6FLTpN60 1MTvtjl1tKbWK96RFsYqm5jFUZKq8X5efRnMeD+Cqn3Y2yu0BxEr41aINMoLKU1mzy1NBxV5lOQy LvxVajalmies1ZwaLdEqhVuQP75r9cStnTo9oqo3VGS9UtWNWwmbKO08YxdkgmuUMybAmnZIEwnb bWDbRK3/m+bxX3VIpD2tJC6tF3ofsbDctF3o4bLm4O6g7qZMJy/MzLRWStgk9MxkGiVF4TGQBIlq XiORov1lXIsYp/alnm4q5OR3bjWsOS2RDX7rJIERN1gQbGnuuLtGCKSKL13FN9Xc0kTmbMQMLe2S iFOa0bHj7jk9h3vocb/hVA23Oh797Dg0FP+CyRbbY9oFknY2Y1JOJhpXUa6Bz7C66kHQKV+mbcS6 n4V862AClmxbOiWFhpXOq9oMJDIxqX89psjV5F80UWp2ViGfnedvmBy7jc9cevLf3MYz7TTn2k3v QqZ8nUET5UPapTON+QTB4FrPI8qzXPBlnnjMbMONbeGUMcuOyBBMipUqMlZ2QANoaG9IKD9SW35t FfnGePIDZd+O5Ak3ALtjlmFSgD6Rp9VFY1v7fC/Ra830nnlcYhJs93TpNp/pINYTWyttJZXu3Fyp S2Z22FJJrNmmLJBu6dFHCtn+Xpi7NibfIguR5D6fbO9sk6DAdHgRVfMibTIJXJM1vZSCr3sWrrvL ceiQG7twbcqiRBZJ4eM+0dum3WiGQmqi9QZZBjcPKP9M0Nacq1YHMKCdOUFiHogVFAUFhc9dj5jG 2l8lBdLh8yBXYwU6P+EybBnJBBv5ClwRcolqIb9CG0c+SRQzHG0PVDEn4H+46+Q88yba0WGyi3aq 8tKWpYt2mnId7ewmttGRmPtG308jtvnHB8Q2u4lk+F4cAMvM5B4aA+hZf3Gg0x2fMHBeIlXGtZZ9 vIJqmrAvSYS9mMfOHBneGfJTko7giemj7e4F8gU6YidbYspDckfENYqc2wgAKETqAGjKFoBxKhwA 6/IuAajM/9JH/ZQA+E8/GgD5XpgzQi3pqTah3/MQf6tluoGWbbtXuR4Gtne1oU2qjxPolZjL0u+c ATM3rzQfjEGnHMhLmsJrZ/TYusgSDg7LFHKdHsVfnSJnpD+bEuqJjhDKzoi6ZO4aNtPkXs24K2w9 LejE0Yxg9OAlNihJYeUJuR3QIaOQb+rtq9WLC+bd22E2yCG7QeEM7duKA4C7P01URV4JXCMFXTij QAsiBsEsBXSejh0rmMcEccgk9ib0G/tCDRghI5D7YNLozWIx+Q8akAH0gC1tIM+PGSeBaLE10oRP UJbgNwghMFxdc0vLQkOIBy/i2p5JohF65A/OiqN+a9zYIUrMusvcmA4vQEc+CHCp4CjhFuhobR8z BjCT0AS1UKMnPFtE08B52D4NGrmtpk0/JJPBBJ5LZ6ivPqMs4w21pnmCqFR2prNdAEOGZHBi9IiD lXHQPqfdJiG8R+hGzWF6Bw7J5jlHkTCUNMI9ZuEx8mFJjqG5nOPgPJT93mwYcu970mHDrbqneVsa xwsJoMvekXZjeuwaoWfFi0CPLYF7grNNbfffgnliLkZxWWKGAa3pEi1+g9QKzYikBqJwyvUySpwC DXyDojpWhHuElAU0qFxUwkOQL9P0HV6ua6PYpjPx2Hl25sGAIAUB2A9DfiSl3nmJ7Yj7PhCCzAKD GXkJXZABu9muX44QwtiY8KAK5lShyTzpyYteIlcHpfx6EqRsF26h6w1cXny6xbHBXKNwyIccXsMQ wDvLBUP6cGwcfy5e1sdnAn+O5w7MaIeKdxhDygAtHWmFHvXBLbibeefCt3RE82GP77Z7tp7HA2PX EMkQ/QsEaphnf2VSLoXSXTIP71uXFGAz4gfJTB/+Uc9EJLEYfl7qOxDgzOQhx2ln6DSJ4RuZsQd5 Gn6M10j+OtAJCrfpiHO3+jEzfxXNkF2nVk2E2ZGueYA69MTTcuPOHfMxIgwxyUmHGosnCwBMuFHo YIFNfoDHbBpMsXYF9s3GUnOaGxx8xjkUpgBmyAqRjht+zwB6lN6lkfCksyOnBBjQ4073XT5gXENG ju0rXBF5S/axKHVwbAWaHMVLtMVeJgNsTY9Xzg0SOaRMt93/LkhLEEH2E17x8BREk39Avi/06rpU eGN+4BELQ21HoDsw5YU99G2JCnxID5O+kGscYfAM32lYTx1Cvx4d4vclr3d2iM8CJ0qoDc5d94Ep PA0LE3SqNeHwzgfXWGGwXyW8gWxCkevQ9DhJAyBEz3FcDjXRGu0T3Ahwd8Bbk3+PjkfwVeT+9G2S 8sMls2Gvnfo4Id916h0P2VQWqbxrlKveMJu0r9eWF2nC5vHSqa83pAGYyGdM5O2dD92RNuFFLKEA bWjhUy7c4bVM34myeBue3uoyX+EmQPM19WDUjD5zZ2KeOvc8HV1XxkpUtjuYtOfpwPCHTtkBZ6D8 M+3qX+BppnrNXWESWgdPqukR3ewXAZMrZWgn4iTD14XO6PZEIRuOLmy3tqA/m8AbDK28m+P5qbsb CweAZzhrgCuq2mH7rrne38od2t0l7T7yU/0zTcscmK+9oecEcMb8BdSDXLjRRQYKPE9dTf/EBV4L gSeclg03hJdpqCeV57ExkHB7EfoY57R835EL8egruOaQG14UfurkDMl+Z1xEzjS4BULMuUXmBOba O0ygUxG0I3fb44QjhgVnRLwuGzVOPUKl0a9eMDdCYeu43h3a6Sl5ISvQDxvme2RjMJJmSKjRNC/h goiX0IQx6WM3huCVnW9G/wtFFCILZW5kc3RyZWFtCmVuZG9iagozMyAwIG9iago1NzU2CmVuZG9i agozOSAwIG9iago8PC9MZW5ndGggNDAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0K eJxNi70KAjEQhPt9iunUZs1/sq1w2Nh47BsceCCkOO/9wSQo3E7zzcfsBsPWwfT8Yal0nTPWnYbG fP/BZ6WNCvt+Qxx5qbhpe5RmXUohQF9kWKRYl8fCIgYuXiKyi2wTtNIZF32TsG/t0duJJqVnyxdB jh4+ZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iagoxMTcKZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE0IDAgUgovRm9udCAxNSAwIFIK Pj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9iagoxNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTkgMCBSCi9Gb250IDIwIDAgUgo+PgovQ29udGVu dHMgMTcgMCBSCj4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9FeHRHU3RhdGUgMjQgMCBSCi9Gb250IDI1IDAgUgo+PgovQ29udGVudHMgMjIgMCBS Cj4+CmVuZG9iagoyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9F eHRHU3RhdGUgMjkgMCBSCi9Gb250IDMwIDAgUgo+PgovQ29udGVudHMgMjcgMCBSCj4+CmVuZG9i agozMSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAv UGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUg MzYgMCBSCi9Gb250IDM3IDAgUgo+PgovQ29udGVudHMgMzIgMCBSCj4+CmVuZG9iagozOCAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgNDEgMCBSCi9G b250IDQyIDAgUgo+PgovQ29udGVudHMgMzkgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBl IC9QYWdlcyAvS2lkcyBbCjQgMCBSCjE2IDAgUgoyMSAwIFIKMjYgMCBSCjMxIDAgUgozOCAwIFIK XSAvQ291bnQgNgovUm90YXRlIDA+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9Q YWdlcyAzIDAgUgo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZQovT1BNIDE+PmVu ZG9iagoxNCAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagoxNSAwIG9iago8PC9SMTMKMTMgMCBS L1I5CjkgMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKMTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKMjAgMCBvYmoKPDwvUjEzCjEzIDAgUi9SOQo5IDAgUi9SMTEKMTEgMCBSPj4KZW5kb2JqCjI0 IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1IxMwoxMyAwIFIvUjkKOSAw IFIvUjExCjExIDAgUj4+CmVuZG9iagoyOSAwIG9iago8PC9SNwo3IDAgUj4+CmVuZG9iagozMCAw IG9iago8PC9SMTMKMTMgMCBSL1I5CjkgMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKMzYgMCBvYmoK PDwvUjcKNyAwIFI+PgplbmRvYmoKMzcgMCBvYmoKPDwvUjEzCjEzIDAgUi9SMzUKMzUgMCBSL1I5 CjkgMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKNDEgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoK NDIgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKNDMgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NCAwIFI+PnN0cmVhbQp4nJV4CVhT19rujiHZu61i JUYTsAmntbV11mqFWue5ogICgogIEmYIcwYyQsK0IEBCIAQIYZ4nmRWc59pJ61hb9dSeTnagp/9Z my56n7uC9z/n3nv6P8//P4Q8SfZaa6/9fu/3ve+3GITTDILBYMz0i0kQpS7zFSeEJTq+L6XdGPSC GfQrzB0o8XePye2sVwivGuYsMJMJZjrZFwhuudBVc2hqNhx/mWAyGH0ffLFNnCRLiYmKTnN/09/3 0FtLliz91y+rPD093cNl/3nFfbsoNSYq0f0N/CFDFC9OShAlpq1334ZHx8fHHHePipclRae6h0VE iCIc0wLC4kVx7jtj4mOSksQZ7m9ue8t99cqVq5bht9Xr3fenJ4hSxEvdYxIjYxJj0mTuYYkR7gcS RFFh7glhESLHAtsTYtJSZO5rVsYk/nP2/piE8PRU9+lHdt8v9nT3cvcVRaXHh6X8+xWCIPZ4bZEl Ht+3VS6O2L8tSXRge3Kk946UqJ2p0b5pMQd3p8f67cmI85fEh0kTwg8Z33xrsfvSZctXrFy12vS2 as3asuB31ulDPDxD312/gSCWEa8Sh4kDxHZiOfEaEUx4EzuIFcRCwofYSawkXid8iV3EKuIN4iCx m1hE+BF7iLcJf+J9Yg3xFhFA7CXWEouJQ4QX8Q4RSOwjthJBxH5iG+FBUMQLxIvESwSDmEU4E7OJ l4k5hAvBIWKIuUQowSXmERLiPWI+wSNkxEaCT7gSmwk3YgEhIN7HLCCc8KZOMdYzumawZqQwecxg ZovTQicTayarkPUDO4r9hDxCDlHLqLEX3F6YfDH6JcZLkpkzZvrPbJ21a9a482Jnk/Pj2W6z5S/P eVk7hzvHd86vLgrOUk7eXM7c7XP1cy9zm7lt3Afc7+fNmMefJ593dv68+Uoei7eFl8H7ie/HV/F/ dOW7RroWu7m4ZbmZ3K4umLdgDTQ40xDYpCfoX2wuP03M5yTRn8KtXLlImaaQR0f4yTwAtZu9VVXa LaQTSHCzsvJBCWVD3VLytt6iBDuoKW+S0wt2KBVbcygpiad3s0/BrSznyUhgg0ED9F9qGZMBNu5R g9YcfRsV0Td4EjaKmFLvRW+oM4Pz+VJ42EYGSywtFYbKEotwFL7Aglb2wJKKJGMyUPJBijw7oICS QhM5pYJmLiRhC6RQC8uZzkOJE/QpK4MW0wFc5KZgd1RlZeYW6PN0wsWoFZGwVF+ZawHlfFBjNQ4V UVYUriSbcqs1JjlkowKeIdua0BJUFQUUfKBI85InKJPTpUqgB1lF2hKpUV4sB1SaRJIa25Ey+NGp C3DhOSFcTi+1dJSbGwx8fH9gpV3PMz5/BLc/YlbRr3JLDebCckC1lCkOC1EhCXw1ysBcSgGjrWRg saIC9FCwizw1UlfRCaixhvg9QiQigZdKHuQYFGElD5eoK8AYBWXkd6EXtoTEy/fuEjwgdUWHZTEa v0x8R2/tLZrVymi8x6RfhSu5wTuiUn0BtXLv55D89fzNhz0WTaRZWJpuEtfI7IDfVGerv7Dj5LrD gZKocGFQqHgXeI9C8x4sh8yR/qr2HkFzg6257TLl/PssYJt0sjEgY5iumWBOvkN/yp0KIoGHWvUe DirstJFbS5SV4CZFe2MKWCy3SzEFgkmUPFWEMukiFjosZX+RY1GDrdTUYhIsVEo99Hie2kZuLJbX g18oehEJi6dOsirZzpMrMNt64WA/rOiV2lwgawLmTLwLyfmc7urJxVwp+SinQgO2OHgFtqhUHnkO VongX9n3wU17b1dPR+0IOAWGZf3xrQnNSRXvV52x2M0NdorT3Vhn7R1whU6rL6EtAk/0lPsMjOb0 KCiO6GJq83EvV+CfEXE8LU4Wnr0HUIeVZR1COOCEwea8YzeWWQXDbEheDV69ISB0mRBDDdpo1zYG /Q5048qKtUH6TJWcr5THZAUCCgnYsI5+i2VFP5N56EVWDbvsM6v1CqCggI1sU2+xFPQsEvND20Kv bmG0fg0rv2ZCA32Mi+atXIIEyO3bN6ALdPnhP6AAzl/xPZorVIm5jy4vQa8g1tFdmyMiG/ozhOIz mZ9ixL8/ee2mwLHWGdq1hdH8BEoeMeEzLRcuOsOqImUF+SAPUFHZ5aNC+gMypyhYHq3dK+dnkqbC UmACVG+ZNlyIVpKijqTy43jn5HLEQq+iuXfWwBkX+mpPdgn3kpDhBHQ6tVYjk6RoEwHl4fc5nA1Z Y7fvnh07EiDEmayxax0EcXEQ5O3h+ZwRmtZw6XoSXDH32iyV5srivmLMCLWU7MurzLVm1SrLosA+ Cn1NTnFpKQttkrKHQGV2/xFqah/Jkf4ZQRaQeNX9mCKYIMph2sMOPfsZONOZkwTO7iyYwcpg6zMy 1RKQBRQGRenhqiDTEeAJPOL3+e3YJ1oO0AywvG3tad8r738j+glAFvhp9OpDSlazZfueBA/A9wIH a4/1+Y3Ffw0gk4J7voUvwNcvnsk43i/oiLOKbe9TjoKSUC2vgT4dtPMVlzuPYPqT+RxFGf0Kt6zQ CMoA1WXUHhFORZOcMXBIo/HWU3KSo4A5NezNhapycJ2Cq8ju2AbtICbCi99AJ/g6fHnH08UHQ1P8 Q4X3SH2Rf0a0yk/Oh4s3c9su9IzeHtuEKMQ8vHnbEd+eNoEjvT+BiR2Q7GHQS6EHN3jTscS9wBcc a028KOvTdeZfpeBVdvYNbWtKR0JPiP0QCAJHZKKYI+FJ24EnZuWttZD8/s5lSAwK0H24lFt+v6v3 KrgKGsSWNRQOo7KH/l89jC7IpjdCNhP+MenBRQfRArQQhSzrWHnOR3jJ62nEV3j3QXABdIchPyU+ 9rsi9PpkXc8SzDGnUTAq64k7d7h9GUAvAW/VTsmhrBR5SlpadPRRWQAIAUdrotsPjcb+ghEGEy3P Bk9SJ4bG6s4DaloMpL30Y0fG/32CZkPGfE713yGDC7apVZumhSMe9rIhBX7rvHbhxuXep+AZ+Drh vt/5XZ8gRg96BVCcalQvZT/QlWXh4jDRyeXEt5ebBp7cyIw5JbjvP7AWIAKgF8PXvXskMNFHvQZQ x9U4w58HFfpepV1aUmtdGp7AzEfzOQ/hFL2By3nWHJJQFuGG5ixBThgElw9Xf3fpfNOpYSHCteeg TLE9h5JDTSXpV5FtAoMU5yH9vYbcir7kgtRclTY7XRqrjgfxIMksqY1rzbgBPqQ4z+CLZ28/vtYe u1vgDJ9ggVjUwfgVZ+w1h0TNhhT7kq29z16pTawRVCVXaKsBVW+rqe8JbTqwLyApJFmYHJodVbCe 8oz7An3EBls16m0ObbBYSU+DphzcoeBH0BmXlrNYW+v64bgDz58nYKYDz2fwKBzmNuVXFzSB++Cc eajhSkfPVfAhGFT2JbUeH17Tsgyj+BBVS9m3s81asI2a2kGCddnaTbrnNf49g6ISfEbRGU4YGaOx GbpdO7JwsXcQIiXKwqI0wXOj0AuHBu7UwrV90ud+IYX+Dm7gitlBiDiWil4DVBL7MAgr0RlzDPnl oJqCAC4nvwBWlcWDqoeKNLYuPFehUark4uwjuCAthylsjryltLRZAN3YOG3rFNWrqEY2ZygPvsaa asGb/afP+JfLkNO97Gl84c8/Mu4+YhppV26loaywAlCNZZmhQmQgQZBOt1eNwdNZyV0GuRVcpGA6 2TE03lxalqMtF1Qpy/UWQDVYq1s6M2pjwhLTth8WfoNLaEB6lMpbyp/2Fxfh9UYYe6KkxaXl08Qv 4Y57zc3zOYiOpXncExtJCa5EEmO6iZdkTipJxuDC5Vu2rfRqFn0YK5TKZHJ9TmyiSgIkIKNCPSCh OGj7oaTYSNeA+6Hf37nfNHhG0Nde3QH6wLUjg1sMiFvKCyhKKQNVoLazu9lUVmAsMABbvqWgFPSC fmt7c2eLtRuMg9acemUHhXRTrtxO3ef6MUD9rVMV5bMpArHe9mkdrjdaBseFHFgCv+VebukebW+S J1QJaqIrQkAEdTAxOuRA2I0fBM8pdPX/ieRvdCrM5OIQker1MsV6HJzXcXBaShyhWfB/h+bZ/x8a zCMPzXQeO3i0sRh7hVsUTISvkw9BtaLiXVxb+dq6TDu9qlZV53L6GvT8FOc//Bh+xOUszYULWBp2 fn6WrqAgF/D1QFukKcHpbkpPL052e883cNvBjuOPg4WXYrsl1akgnh8aJw6MibfUSQUZjVn1qotU JpvjhVZaSKO5uKgCF+rK/Ho9XkDf0pxb43bvg0ufjqd2HugRIuIDcZWiETTz+9tbRi+2xayuFzx3 cW7nGJ89gvtxnq6CP3AHR9uqTwBqvDFqhxAdJsEurcpH/9zG+Zv1JvAJBYPJ38LOvesdlnogRAAv kjmGGHVK9sFMflI2K5MsLjSAEkANmbKPCafiMGv1WT7ZeH68lfQp1Vbg+dMmiP7Vkb0TE1DlyN6R yUU2rsggMSd2oXBYyvvI0lbR2dzRZBsEJ8GQqje5leLcGxB5NC1z44ygVin7TrZZA7Y/x16r3uyQ 0zaMfYnK4sA+iLxQBLPQVRZcy54Kpp9wOfdayk39cM6lY8uCMsKipIKQ5Gj9knzKGbZjazGzg/Ep fnoTrlJv4CJlLjDoBbosfZZOK/I7FpyZq9HpdSAH5BXmG/Kps+gce13bsctjfQ1nOgWq8owUuTYd 8CMVzdeF8MQvJF4SY3p9gvE9XnKbw/as8GMpsCOpKLIUlgF+w3SGKkiwTavZ6ShvWiu5pyTb7Ng3 JANhBjcpLU0srktraa2va21Jq0/EZfysyp7RTe+zwyUDLjefQOUv8zlj9EGsYBns3DSNRg60ABt2 U2RlpCkOHAOh8tjE6HhZGDgE1g8fhE7et0RnwhtFZaqSDJBKcRS7g0K2rvY6D52DBGlszlgbimbV sQttFZVWgItWrk3Xp+jP7sdSSD598OsXfjcQ76bw1Uthw+AcdX6w79rIoDSqW9AeV5lc5Y0z4nmz MzYMe22Mf0zACxNMKIKICwNIcKu8/J4Re6N2KXlPV675z6qrVW9wZEu7jdxciiN2k4Lh8AI69GdX HJ7731dBAdMO8xLNrVZWutx8BHc+cviy1HFuDjtEg+0g/IHk3EOr5exreRVaEEQhNQnEOUqlJik9 Xp0AqIi4rkEhZwQ+QG8oyVN5lQoQQqES8r1TgZ/1nqhqbhYMDbE8yOL88dqe8tOVfBxU+v4EbhFw TP3pEG6OwTtNpPKWYatZUmgtshaaAb++TI4ZP5sEm/JSNBK9VpmtBAqgNcrtsnplWSbupmTy9Lj+ tHNwxuW78FVh4OSmPws1Vhn6x0EGNGIYjZMEdyqPBO9oNB4OWEZspGex0uKQKdM5ErJBnawezaAa 2Hq4kTV1la1HG1kN7AbIqLdBJ2w8sEY8b21IvBjpMBybVep1uKeA43glQ+a04GGAP6u0PHJY2HEp +fh5/4HRpXfh5jLZodxC3FzmWbVACrT52lztm6iC9zos01fmVYIy3F6WG7sNuL0MVJB9+Ubt6EI4 E/XzivQGnSG7VFaaXQpKgdFi7YVz4W1e68elxjYD9bzweFYyvsDqNcnk4szAEFKdZlWwcCqDBIfy 8rY51EtlJSWFx4uwMnfzoRcJ3dEBQ25RXlGeIY9v0hr0IIfKytKrBVIFTLSyQw3xtrDTaBkM4LU2 3/zw2miriW8trizCPsNkRceU7BMF5blACbKzlEo1bjecebQHmVskUidm+2TyE7IdbTt235M2xt8n 4B/DTBrSFVwwUVH1hRmDo5CS9/VV6WARhbD336UTZSYkBe+N3wy2g8MNSSdlHbpehwv+bJqvnzv4 2iMlH+gxX7dS6AaJtjz0hBsh4073xycEDYNlo+CewxlOo/wxRllBdunMOiAHCn2qJmkVSuGtg2ny UQCAhQ/qyo0njRjjUAXZm1uhqfU3So3SUtlKFMx7E1bmmvPNwMwH9gpTVzEetVtB1uebtHWB0A19 z6tIMClLcUk2WSqasC3X8f6GNJWRxfpSwDeCkrKqftyH/cSrGTSU1OJbPK9fjB8fMW04LqXs8sKK QtxJdZiV2Pwnk8BfqfLKwZHRWEmvYrUZnKfo7zCGh+Qi7U75dJN+ieY1uPR+tfMr+NrD+Zxv6f0f cuVKdY4CJ4CuclgIcZqfyWlVNKT3HLN5Y9twb9mWw15ptZL6BnttXXFBSYFRmF9WYAJGqrmjrn+s OdFfsJ9Ey/fJs4+JKM636RJlTKyr13Do1eEB+5mrgpJDNRkDoAs/fHcfhVZgexqfk5WhTlWKszIA FS3uGhIWk+DyQA+cNfx/eOdhZcD2eTDEyo4Hkqr4YTQXBvK+hDNtzW1VHYV8K1qtINvyzXpMFbU6 PSU+R6+WqSTKWp54UNYFLKDSYmwrxDgfV5SRbaBK1X7kO7SQh9jIMyFcq4vN4yvg61ZSrC6xlBqt llrhAzj7b8i9WF+kB3o+kOlyY7HyTNrwTl45w3jyCHo5Xkwb/SrXYjA5zlCayjKDhajUgbbiYAFG O8VKBhQpysEJCnaToMhkNhob64equwE1XBeNdToBO3aNxtchJ2lW0rdQUQ2uUbCEbBvqrBkF1MWa JA8hiiKBb3a2jw4PElvJ5KKEIlUNOMGH4SR8MeLKRp/AZB9/gexiTLM/CAVipYcXdYfUFQVKYzR+ Coch1HbQL11nfPIISr5iwmWTG7g5RWGKpOwjKn6iQ/hLC4uBEVD9ZVlhwqkqMv5x7OeQNwFnwNfg 7E3fLdrvE3VYIghwOnGy58z98Q3IGTGD93oeOlrfKHD+fbvGPjnLxvjdY3Ix13GccjqnRgOSQIY+ WStGc9A3PMSD3+WXZNUVGPhZdr0Ny1RDvflcIU6yWil5scCc1bW+05PnjrrRQnqmria32nHwVVdp PG3AQ/Kl5Okcq6x3GfSf6uJZ2XA5vR6umVrPsrIfw0pzC2TAk7Yz5WVnzY6S+R/0Du5HnSNXwRVq PPrE0ejUtJi4emlPqbGwsFRgLAKgEJeTUn12rDjKP1KIJ5x6woSnsBZvCU5IjgzZviZ6EUAvAMTp feur1weCm9LPxFVU8dZfF3cn3Un9SHMX/Ax+s3zRfK3lWlvPrUuOO8LgJ8w+tIN7+1RbU+/ozb92 /wzgCwDOjXz29kT4qeS6Qx3qTN7nXs3RLZsbdpdvAovAayqPpP1ir4SobT4OTkO9jQn1tD+3UF6U oU9UxfB1slw50FCSKrnNXmOzl+ZZciwCVbeuD1PISBrz6rLssuZYfmN8tboGUPZKa12TojzUKIwo jatIrsou4Y212IzDxr5SSzlopOoVVRkKuUqcKkhJSElPV+tyeU0kaChtKW8vtRVXgXLKnlklkSgU EnWxrDRDYI4twY0hpSJFdmlVbI+kQW3C+idVZEpSa5WnsoS9ujatTVWu44WnZOpDso5my9UghUqv VNVVlZXYqgWtnSUlJqO5zFjSXYcBMuDXl+gv/62oxIkjn0cFBlxnnIBmrhcsuI6LmgHO+ZmbkJIc n9iY0tre1NjantyUgMe1K+2Tr9QyYD8O4G42kv2xk/UxG0OqbJp0aWI0/AAtPzh02IPrB8LkkdE+ B0WInA4voxO9cPJgb+jp1EvgNBiq7um+dL4Pt/BwFgXDVsK/oPmCvGTuoxHEQiIkCnVfuzb0HzAC Ro9A5hPhdB1iwBjMnGHHOcTulSwlWVFSXlxcVGOsLsZSaC9TxAkdx5Cx2WmZWYosZV6YoxC0Wsn3 CjPN4BRFP3NYIHCXrr/NgH97wqTF8BWuqiTSV5V1FPBRNhu+B7c//fbEXXCf//O7917zO5R+PFIQ F6OIk2+35/D6f+zp+ARQjy76rtsQsnzdaiHaiXxYatoVr+o9BIXfQiETrnCAEnt0PzhABXaLRrob 6rs60mxRetyrYIecD0ABoLL1pabOlp5zvUKYavsfjHY4jKkrLvDWA9Gt+ZyzcBn8knsZ1Oc3ZFEc +7X0E747Xdf5vr8lSWJsiBQk1MiNjvNohTIjeij903sPmgZOCk8ONF0CH4HTmScT2yV10opQG8U5 +8nJxt5zrg/3XlgRFCqPixIkJCmS0w9Yc3kDn410XgfUjZFQryhFVEqKMCFBrNiVitOnj/aDF7jJ EXJ1PMgAGSXystUnZcajIATEZ4TsPRfHazpRXdEO7MCeU5319EiNbgSMgnb76AfTcmKHb3xAb8AM Gr3HpONxC/k67RPKRh9N+bD2wi60/h5cP0Gi3R9wkY4NdfAHx9E9/fkDBpz8lAn30J9zYSC7ChQX GYx9T3lZRkWGNicDx0/ERgykLcjHoOXzc4rzTB39OtWAAJKRZ/eBN6kl+zdvkMiNdQmCuPo0Mxa6 RKU6RXQy9c6jW82nx4WjI/aL4C64JR0NGg8d9q1HL9rxZr3bnsf14p9UuDpp73+RS1Av/R+MxpmH VjZOljUyvrrLhGfQfO5admxmdbdwcg3ZbrF0CL5uRFF/XIZR00nWQjuNMrq+hcVfM2nfyc1cxNb6 SLcGImKjN2ID5ArWNL89FNQXei71Gu5GXn7yPfYqc7c+RGRohk7kJWyGS7CjIeCqJgqFoxPcJ+Pb sFrMiNi/423/7+CK06aWWqvQXtVehoUS3y7bTt+6zaD9schMsdneaFF19tDHNZbzgA8T2Ojw1Les G2wYPfkqy/l3BWTiv5Tn/0z47p/UDvhk3n/rt38hAjfcZXZhRFJg1ORlFJXyhOyskkcL/1hDxitV 8YJpQCadW1wu3N1xG4o/8bs7n/MUDtEkbl9/Ots9+LHrF9uuLEKMd3evfN+W+NsKAecpIjzT43e5 Ln6wC7LgzHsf/novZgzN+logW8j97FBDFDhIvX/06PubAi/99YO6wUsnBWP38FqrL0WNXnC9NDJw /eOh0J2+4qO+IkFOHgC5edNaoh2inVoYbd9A3TPm5XQudLKct3089ve7V+HLALpR0HMFfAFx0Uur 30BuyPnWu5A4P1g1cFYQjtYhpjtamkzBy3CSCyS5WZoscWqkKgpQm4LvwJcuVl2xNwmraxvLWwH1 15G16L3pA8o54wzHO3d8Ki/I4T41GPRCyGTABXTov6OOkNOfVXE9ZkEBnvQPLBOfdA1d+SdZ02Ni /2uy9tH3/0QT6Ktw5ofQ9UMG3U7P404V7qEL2cjV6fkHZ0ktHVAL/WrZbS8+fqnNNHPm45qZswji fwMH8vB0CmVuZHN0cmVhbQplbmRvYmoKNDQgMCBvYmoKNjg2MgplbmRvYmoKNDUgMCBvYmoKPDwv U3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NiAwIFI+PnN0cmVhbQp4 nJ1We1RTV7o/Ecg5I5Ra0gykYpI+RLxaH62POlrpiI5C5SEy4CsCgQQIhMQEEsIrISQQ2BBCwjtA Qh6kxoggL0EtVtFerNdrdez0djrt0pmOtt477dSu7sPa3LXuOTKumXXvf/efrJNzvr339/2+3+/3 bQYWvAxjMBih6YVSkfLNPbLiPPrvenIlg4xeRq4KUiLhwtWFxJBV2MH+kBdAWBAIC3ZFh++NgE9e gkMvQv0KLIjBKG9zx8vkGkVhfkEpP/a3aZlr161b/483m3fs2MEXap5/4e8VKQvzS/gx1INKVCyT S0UlpTv58VR0cXFhLj+/WCMvUPJz8vJEefSyjJxiURH/N4XFhXK5TMWPjV/Lf2vTps1vUj9vJRdK hWVKfppMmlPCT5bt4B/kJ4nyCsuk//cDhmGvaUpyZXnJcpE4VZGvLCgtLEtQFamLc8qlwti1/Dc3 bNyyDcOOYSnYXiwV24dtxA5hv8H2Y5uxw9gBLB1LwH6LJWIZ2L9gmdhB7AiWhO3BjmLJWDz2C2w5 xsDCsRexFRgbi8Rep1DFgjEbYxnjMKN3WdiyomXfBiUGjQRvDG4KORByn7mXWcu8ha/BhfiHxG7i GvHzLxqXv778duimUHnoudDzoTdCvw79OWxrmBuaw0kTyoGvkw1uhh2GBpGlZA4brVMyJxu7DEAJ dI16vWI/So+Kh0nqDwEANg7o6Wr3tNibo9zIrMRdpjZTm94MLqzty4Fh6GKUJqPi6KmiUsDR19na m0FLs5nXbGm2gFbiA6WjUCw/JRKMSebOftDldHKdLsfY8LdwLflqVN9ER4ffTISTV4Cb3Opg3Ic8 yIW8IFhAJ3RYyZwytNeCHALN4CCnTn9STyih0Y2LLdpeMEJABw5arR0d7YMud5cLEMN98sM8VI8D cU1lYQMVqnXjeebaLjBBwFb8QcbVHSkCWaqYG06mksmnGR74KoyAK4LITZDBFuecqhYCYkv6Qxj9 45mbs/beOl0bz6Knis9pPtZfOgKICa/7/PyBi2+j6DWvojcQ95tYuOLza/7713kUnNV+8l0/teUa uBmuCYKtpJSNWLGvoWj0+ndvwEjIfvKUqo2/7ili85qL2dcH0tE7aIM681Cq+kMYA/f2z85T21yp vkaGXoP73dROsXA7jcSjGvZ0t8cyb523RblwgbmmmyqHvIeKlPjt+nYDEBDofTx7WmoXAAIt28FH q1H072N/uhKwX57hmT5mA2NthbZGXarSlQEiQ/ExZEH20I3rAb9S1MMLXxBrnCbPAtMT8XSKjJ+K ZF2AFQvvsFG+gukAfVUX04jFEpxVDtKqqvfoCQVUe/Dd7ZoBcJcgY3DWBfLw4niIj3zABHPd3bc6 CA8qUuD3DQMqsJdA13GqIJTjhHFXyeVzRY6IzygEtsHYSNaX/9TfDrq/i404ENbpj9dRTfM68WRz hQPcJuCr+MUT3popQMDgPzyFsTzWf0Lee9+hoNT80kPF3BYBG1jb7V3djkFX1yAgZt0pKBKtkKWm SUpco1UUnKnV92DKCNziZ5Ax8CV27rFiTTbIAyX9qmHNmbpAwx0CWpjGr6tmikYl5wWOdArBl7bH ohgU88d1cMWXl848vsVDvTCObYZh/WOXgA8MVNqKLeUtspYjRBUeDh9QtF01BY/7GXchbw6GB90l t7LRAxxk67SCeqoYvxvf16LtArcIePvh1BYYjl/tHRzu7zRoG0wGYy1XX9WgA7VEsVd5dsTjGbmR Or79QKYyS84tKzAIwVYiLYsZTkLgUXwAh4bhtWGFJ+J7CsNfwfciWcOwF15jw5XNZ81T/V/6p/4V fE6wtkFi/b+hnVzWMPpMwfzU2FMJ9hGLyThLDJJq1CeMBGvYBGobdY1UMx968F0d+nbwO4KsDmZt c/V1Bb4KZCHsoFZ0qpSrVEsMewGlzVTghnNwdb474ivIi2SNwBK6eYcotzB21oDcZ+IU1uqy6OYN uPHkVm03mCfgIXzWNxmwtRsqO7msO/KBXr135YjXd/5CYeDEUZH8wAlaNkh4BobDsIdDsPiK3h/h +9MuuApGwZXiLyJZf8NIFfka+wr6Jc56gtmzZG25K1Ho9oT1hd0Sl4w3qByomVHvkueKQCYQ9ms+ KSVYP+kO6iUK4SuHPiukpP2rP83+9fOk6dXcROZOtdV32jc4xrvQNAM8bWcdHGr7C17X+JVXwJj2 tMxH7F7MYFPrP/JWSATpp2LfFrimnNZOn4tHnf1nUs+eGRBt2FCef+K45tzjbwdGZqjsOTVOVYB8 J1DmiBj6HnKfRLIC8DH8gs2KhqvLcGOVsV4LjKC2pdJCsIo7JaWtZSs3JSRtTxgX/JDN+3epTwGK iDzpqZP7BBceqrgyJiuAdnjwTmebtR1YgK2xo2FIe0XnA8Rfbs5/czdvMnaCt/8DmQecJQI+z6h3 SKca5DrVnZrerCUHXQhzMO48d9A8WsbpSua03loHhMSi9f/roPnmml7aQZufOWiGWH0ok0sxn9w6 xbhHH3SdYsOb8F0FM3lr7snEdEI+iz7HEydz79weO/3Hca6iUy2qrFYBjkzXN8aDH31LycYPnOQ7 js/gRjpdKlWaT1SqU/p2PZXqMz4Z6gQ66vw6N15g0faAUWIf+TM7u6Ag52RAMjV1NjA1WTicTTsm meBm3Hpe9JMa9mSvu/WWdd5KmWVWC8XESQIuIoESv9zQpQXZBDqHSyQqnQwQwirHhzz4CKUq8fE6 m56eMhb87cuZX80O2y9fp4YEB9DGyIAhcFsQDHnCBkc11e8ZKN386MHjLOU9YJYgy3Ew67TfN1PO 96MCv1fvrAJHCHocOMk9bgap+V9ztaHSoIlHiVG7YJZhoLENtHFAb4fV09ICbM22ZuKfZmtL88wa u5CarZeivEy4heQPTNlsfjNnaVS+5YKH3YxPqZLJDvoISSmzs7GjydzkNnUaQA3Q12p0OvQyejmK jEcpSvysqacCiJ6RIK9KIzEtIXvCWt8GZgjIxF3u79ArfQqrFtRxgLbaKGuiImrcuA7Um/VdKAM6 o77/ydt/00ZQE2OptoVM+uCVSuZIQ2cdKAXaGnHxrqq8OpW2sHbc1KW6r75j8IF2YO+wjJqpymqU +PmG5qaBhLbyqP0oTvmJ3mkYqO/hyD7VnQHdVJjN10qFKZS4t77VOJQAYxeXR7mZ8CV482/oZoiL CTeSq+0jNpvXwqEZ5F4g3IzbdNOFNNPTlMxhk10DxM+KFFeoC/9epKS5cgCM0T0hk/wRHhiDWJAD CciNZN0hpZ+wa2tNJlNTPeBUG9rtPNiDfx13BYVzWSMoJO7Ie0K3YnzM5z7bY+zW2nn6DhPVM8Lp sw9f98qTuXtwFJp/TC1WEKw72VJVYfYryTMnP5mbdly+yu08Mlh+CUwCv310nECZc2x5sVqrBIRU NTR2fWLiD07a/qhWbqZoUu5mV1oMrYZOFAvLo36AEQMuR6ffwnGjXUq8vcnWZAauJpsRVIGq2gpZ kdFYVV6lMlob2kytRROnJin4unraAn/nj7ehrd4hhS+jo1ElYrlEX3341+oKcSOFxruUmFuqraAX 9HonRqdbzFabtX3iYJRL0lEOtHTfi+kwIx6+cH8ps7tLwloSV+7zmW3s1D6XqW7J9g20THW0TGlH abMPdHc47X3WPkCc7y1NeeYoQl2N2LTEqoJWynyWQi106GDfs9DRXmXqs9AcnVZEh+qp61uLrouW 8NL1LU1U+n4mV3qzwH0QHAQCuSiFNj7Khf3k6o/g+44IypCoW9OaSNYlmE+zIoP2P8pUconFp134 F9emhecqLwMO5Dx+CtdC7u4nKOi4uCJPzEsL7pt02AOAmPcfQJE8VhXiShPfz5H7L9JeB28sJLKT JDJVnnDbRgEKBYgNNnneuhg3HT+Z+1+phA9PO6fwqi5I56sfAbgKQG7PD76PnVNu78cU8+CDIbSL PR/wOUfHHzyahqEAvgweKf58/PeCe9lja28QMnxO7FE4T55O6tkAUDRA3OoYWYo6S3EqJZdabqYz iIMEA47BMTZqQARsYFKvKWlsYgtEeSePnxPPXBwdmZ4RnaeGKvSXOxc2Oxjw6sJ+9mYm0v33sZBv mDTZnPBFGETSnxxwNX3ttbHJfTvx1N2UU+xM2JiynoNCYDN6A66Gb9yEQTgS/hKJmFAEL4dQy2uG GD64iQJ4fRApWdjLRpzypLK4TBS8OxUFA8Qh0K8fUev5cMVf/gqj4Qt7/gMxi8oaaqTcEbjmqy9h zGkC1aLz7NuudPQ2Wq6VHivVdAzU8ioCtb8Dj8F825zVYmvrae2h7hxqB5njgJkOZmA55IcGAmFh kO8KewHD/gd8VdwDCmVuZHN0cmVhbQplbmRvYmoKNDYgMCBvYmoKMzI2MgplbmRvYmoKNDcgMCBv YmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0OCAwIFI+PnN0 cmVhbQp4nH1YeVwT59aeGDIzFRQlBFTqDLVYwA13waWCIriBuIBalIqIioJQFSVsEhJEGNZsgkJw rSJFsQzFlbpLq9QVl16XtlivtdxW29ue6X1zv/u9kyDJ7e/r909+mZl33vOe5zznOeeMhHDoQUgk Enp6curGhPiN4n8/wUMivN1DGCjlULjw/R9+soFE4NgNvYqcJJyTlHNy2PP2wAEuwsy+8LkzKPsQ UokkrXjX9OQU5caENWs3e/pELljsO3ToMNudUQEBAZ4rlW+eeAbHb0pYs8HzPfxnS3xickpS/IbN kzyn49WJiQlxnmsSlSlrN3nGrloVv0p8LSo2MX69Z0hCYkJKSvIWT5/pvp6jR44cNRz/jA5PSFqZ uskzLHlDsudczwXxa1ITYzf+102CIILnBik3xIVNS09eFT49JT74o9URMzauCdm0dkHo5oSFM1PX LZq1ZX3k1sTYqLSklYt9fD2HDR80wm/kqNFjxgaOix4/Ybl/wERvghhODCI+IOYRwcQI4l0imogg ZhB+hBcxnwghBhMLiFBiFPEesZCYSXgTi4hZxBjCh4gkZhNjCV8iiphDjCOGEIuJucR4YgkRRkwj JhBLiXBiOuFPvEX0JCREL6I3ISWciT5EX8KFkBOuhIJ4h3AjJhPuRD/ifaI/MYDwINYSM3DICAds 9prkfcnFHhN7NElHSLdKmx2GO5TKaFm27C45hvyU8qLUtAO9kf7jrXU9h/asc/R25J36OG3o5dnr UG+695reJ5wlzsudn/eZ2edYn5/6bu7b5pIqV8hV8k5Xf1eNa77rYdcvXP+jYBRzFZ8p/uW2xg25 L3T/sV9Mv7L+rv0X9Ff3hwGZA04MeCB09hY6OV5I5SUwsQlqG6WwSjAp7pHVOm1FpVqrZFEkqczV ZGXrNdXsfXPqVPEqO0u8EkJhOVmVZ8jO0qjSGTQW1VKWzcCbh5O8RAcrYRKslgqBEKG4iLxldq/C SNKk01ZWqLVp7GoSLRVMMrSCVKqxHZ342IlEoeZUWSKpVOE3DOKtoWS1Hr+Ri480mTwH3jIo4xVo GwkEnJTtIrFlFN4kVPGSFpgCAeAvhaNuwchLhuTYrDo7W6/Gm2Rhv3QVFWqdkp1Ngl6oklXatkVS Mt16wCr2AonGoafIH57KPrdbQZFparxCpzGxFpPY2Q4+hXcBFx4ONLnLH8AkYZwiUPREXFXN1qOO GDLNuquJBXeb2zFQTtbxBuNuIy0/se/jWkODx6ecSbMv7eCWio1cEo24BMrmfQ+yynqIdDYBtOTD GZfHhK3ZOnc+gw+RwUMhvIdP8ZR3lzcI6wQnRezRqJpwjkYDhg5D/ZDrD37g3tZWc7SF/di0u5qr oPUqfa66oDBXzSyJnrNpOl7ZY+q9f4L0fjv0eHInNqqUld9MLy7XVHrs1OpNrLzhOSW/Wa3Rb2Pk DZmaXCXbzZo7vOCMSfM1TFHAKPhNpjenBtrF2dcGXoKQekC8qqgUr3xI5IdeoVHwSuYjRjkrW/Tz gDk1wQax+LbB8nYaGySk6kgYg36TWWHHTsdjzvYRqVbES/EfRaQdW66Qz9tvPv1qxekJR9grRw42 cGfpJ0FfDmGQ0WbsPMmjeAXEgz9192LM/LDwD8ezyBsdUEAG+FKtXL2mLq1hy9413Bo6bOHSYMZi eCX0wcRzEQ0fw3CnCck44OjXYWSaNreiEoPFnIdSCp1HL2RrhJ6dFAYtKxsjxshPLMQJApfghcwS M0FiAa8nPvs5YboCuQz2Rs6o72sfwGx6/RP0BlfvfyBXdqXDPx9PfNdnwkQvrwmPXr96+ugX1vL+ Rh5e8+BQs6fG5VQTCI1x0Ntdni0ohVeK4bYAnEcq8oM7Cz6ZikPsOARbYOUtyLnzPXC8f+XorVOM PGv0S6o7RPLsRSRKhteKVw8neuGV3pMm+npPwVYfPvqJ6Q75Lzzc5KVCgZtgqqe6A4p8RZ6LOmFi 281xJLosFMneIdOtaFex58XQ2hOjytgd2jgSLpuLunDR8pIv8fYbhVLFshPz9s/iZnLzPoqJjl2e PIMLp/0p5AHOyBnevta6/9QZ5uD+nVWcgTbm6lTq7QXqPCZyzpKPQrC3Pb1fQy/2NgWO33eC9Nmj qPASpiijXF3B0ZVaQxULDlSVpku7rOIBI3h4KGYzdlDAse0ELxzbYaILIqtEF6oi8RUWE4MabxCJ 2YzFJBeLiS+UkKdmXUh6wNHQ54e/gyMrfwSOw5+jPoFLUkKiGAi5oHh9P8jXb1Kgr8/key9fft3+ kzWMMI2HIbxE2A3RCu5kQU1m3donk1qGYgdcvf1Qb+T2uxd4PAen0/WGXENuXn7Bdg0bt35aahiH CG7SjazfaN7B9OL2pU6uk2uP2D2Stuk5puh31sywBz6ZBLdX4ACD2AsUDHoPHJAbg5JtGl9P8uZU hZAK71LnuYbMo2v5lfvncVH0NGrQGJ9hf4aqlYc/cE5g6nUKH0KHQv7oenTkkfc9kPPQkcgROf7o B70fXqxtO8miEh8q3SrEFuzkL01W9NJYeWeUUHXOcqeLEsNJ+SMUmoJ5aMHMx3sKxuxh+8/sG82V wGrsWimWOoi20+foVvLsiaNte/j8goPM6TyOK+bondiMPk+XXcwmlodo4zl61JyoaWz4WKpblr9D Hb52qvM3ssrQJdIookvlF/BQYoX0MbYbABkKmEwC2dH+4ocJtwex6LCdrJhT7ZUoi+z2CjEkZDhA CYRRD9sWhoZMXzCW7RKVed+IemaRFa+m3/mtje7ys9gM1iKvGFKpy63cqdNXM+BOVav127LUWE9i kBfEU/IWOOlLpmtVFSKpGWDNQdRfnESeJUTCWLI6T5+dmScK0lkcoK+oN4gmYuvTMetvQqKoaLRI 9G0W2t9DHUMtV1ba38CZqzNW5ujSWRQCH5HyhlfQ48S+Ex57uZqc/Zu1mpKCchF1w06Menol+9Ge VMMGbgkXkTzCn/4Tfb7k4XusXL1E+oTBd5g+bcsWH5nmgRyGD0c0on4YCg53zh1pO8UiBRW6KDKU QW+RNhZRZAt3rOpoQ21dxRGOp/EmPucp+ctuPlhoNCVF8bId02hq4IjhQZhG7e0/sH+uIV5N4Noo tQe8osIGeHZ2N+DwlS+VXq6qrCy3oh35V2j/Ke5WyYaB4Ad9LQqz9QQcPeUuNwrBgkKx9kjMrgUc LQ/xnRY9e331hkNK9lD6IU275qLmoOZg1sHMqo3cZlpujJq9auz4GQ0nGS0lD9mpNuByPFsUMNYf X6dp1ZWMvLBCqzOxRqpp9Zn0NqxGsqcXH3yytT5xL7t+T7xxnnaMPq84tQLvtaUip6pqQNPFuvb7 nyd9WMbIB2UUa9U7PSq0BswV4y1KPgjXrmxGbtyWiy1YEeuqOBbMDoiJgKvNMJvT582m5dZEEnkD /WzlOwZ0pLHiwrWPqy5y/Ru5vbjPOfCmz4mhbOrkbkMtBmvq45mX/cJjN4cvsVYfnPSQ3lX1LeEq VWAj99c2L+pA4+hLNiFIIgPgneRjc5v/XnfqNHed/sb/Nq79RX+ZpO/bXg0kodQB0mE4dedG5LzZ E5f4dgn1XB6Oi6VJcGyUYrmOV+wSz7prpyXCUaKAbsu0+MCiIeSij9aoF2MR9xrzBN5m71LclUPX mxuPNzRXXeY6uDsry5bQ6eWYZOWGauY5ZcrXZWbm4UKURcUcW1Q9i5vNRWyOiV2yLCmIm04HUWj0 b4PBv/Wr6vrLXQ3frxgFvyYpLMW5Co6UKa9rA+QYZNO1drSXDGyNfvENkMcPG9RG1fYdBfkaZuWm GekLOTok9pMWFmog2Vb/32jBz9BDAnU4vndFKRhjB1RP1IHG2lWT/7FqpUV8x5ExwhPFNo1ayS6g MBt3MgdICxsv4S5Il8105cBEyIORybzL33llM1xudpcPEuYLlQq5kY+NqY7wGDQ5dGxs9ar6zWxt 6rFtt7bdzq7JO5B5KL1qPbeWDpoROQJzfiQX1LKjrXA3VnWOxsmJlUhGpenUOyuxOeYwJTdG81c2 3fQAp29vdrZsbo7fzyaaknXvV4QZNmlTqjZVZdZytfT11rOPH7bGzCu1cL9cU+FRUa6rZn+hxJnG guafZQJTXpiFNQJlRNpx9h0bBsuF1P0iK8SWCLPC0VZWz6N4dADiz9k97WlrmPabU2PIreo3KLO2 LIiCDPJNv9dhLRAfN8W+dpdvFua43bdNBfK0BMEJq7Zd8CtJ+Yl5C+clzfRYEsefYeHCMNtAcR4/ nXxu8d/arh46f5HpHp7EwAvvYC/fwZXV7EOFfhA9i0GudhOUgnx+7foLVpiP6m1EAxXOxOzuwFcw +8jK7sBnMXbDAkxqggBMrHu82GIETKMy9Dk7K8tx1IA0L0MkpbS20dXMXZhkTh1kB3Mp+d88tfQ4 VpKaFFbIuoC9Y+s6sUSnItbWwsEdmybh++JGewB4SS3EggJWSuGZG0wUnGSNduo91Mb3GyQeEDpk W0nkCx2y67Zpzn4RT8Jks5PsTTKBi9ijQ/8mPDnMRQMh3F1uhukwU3HyOISiGbIUUv4v2/ncredT YS9jSBQHK/BU5S47RcrNNltuNlt7SRSER2vBcZgNqXNmU5RtxUsrfYQ8XvLK2rjnY7zqLQP+Lk15 mqhWSnVeJoZrNy71z8nRM2aMGR1y6xkDz9v/q71X5uJVlhYRr0IO344BGUg7OsCBsYMxAFZDgFQI c3uCUay2Q7GH7UhnyRB0dzToZEvIcUg3He7iGfv/XGgin2IgW8hnYHyOjFZEhUJLAbIG/pWoTt1D O/Q0m/4fdXqTRsE89ONdMBevWDvXdGGC2492mZS5CGrI26Gfj1g9O0u5iMnZnpfH5dAqXa6xuLSo qJR5uO+Q9hhH3z277gM2mIrYlVi+HCt933ERY1n5malfLn5x+8rBS63MCYeZc6PE2Tokpr7l2u3P fm8+nac6ZuHuHqHA+n0kCFZIocbtEgnxgkl2RORTxS61NShbNV3S8ZBEkeZU2Q4ShQupsgeWGXpX brnSQjqVJXLV7JHuzxEuLTAP+eNAOMMENF6k2zN4DBsUMAFGy7Sk/EG1lUj4fYlNLk6RaCByQwPA TXbSQutKyzGkNjS1JN5vNJqLKZtLyp/Z+uX+tsQMJTFdh4AfGiKbbZd0/Wwrcu0/m9xphPcb416B BP+InacDLjdBtk68HnV0fw2osnwDMXalRgKOkJy/dLzuwFGP+iMJcSy62W43xp4Snx+/UrsPh+no kXXxrLwc3bFf8GkCHCWvLDszf+W6LUtXMamn1+9bwcVyG5QJ0fSfp2tw5gGa3HGn7W/tdrpna1Ke bTbZVYKXz0h5S/Cpqwl3PKBX5yvoC32GdSLnoEXrg5eyEPKF4ucHE9/1nRQwxGfy41evvn70UxcZ 3ql5ykt2QTQEQrQUnN1aSaAFL5CavbDEfIGJUWP7boIGi4iIn8lM7LfkAnMKkghvy8JwPprfXiik yJ7Y6aCXrfzUiLDD3lapMAo7oeI0mvSUYNRjFXqL8+a8Pnn3BnLYF69X6Tm6Qq83lhYWF5SxM6Bv 0ivud+732l9vQe/isqJirhQP2vocxrLXF1KIwHvlqHJz8rmCku3sLdT3sLc4lnomvRuCeu/YzhVw +XSOPtdo0Go/rmJug+RT6Mn9zP2y/p+h4LD5uEqv4kS4xe1WgZciGJUU7ijcwW3vn1mxbXeFtrTG yMBgqBITH1dhiVCA567uIJoH29iLFwiPsCq8hw9Uj8pLNupV1Vz/ak5vKDlQD+X9Pnez3DWoquzv 4rcy90jgNLylWJWUHL+mNulT1kAeP3Lo+PHEQ/GWTbf80UtRoisu4cpog0qnytXsyMpj0N/+PTdf U7idy++vwlO5oaysQitiktkoAZmlNRUy4FcFjJkKBJIi6VREoDGMN27j7iMCpCC9DwSMZtC3LxXc teobh0/ur/+kuolr4uqVexNql5tCuTn0aIqbkxaatDw1IWFrLKbmuppN9RtOKm9w16wTvgQ+we3f PUFQoPCIjPztGk6FD6PSlehKuFIG+jXJzBWItfuCeMduTGasSbjyVxchjF+NZ80ycOcVJdSl019e 7viOlq/A2tGr5vDVAc/GPR4StjA5ejWTtik7iVPSuXqVwViurSxldl291nyDo+99NS8kJi15uB+L ctAmWQQljxAG3idN1ikzjZGXraUs0EAj7yIE8GmWERPBI0VRUUlRER56vrl68HjLpQHfTf3Ke/HS jKQ4ZmtGlpJT0ZgdRl1JyU49U1t/xnSRox9ciZ6zInlVrJLdosoo/ICj03O6wi+/+fLJrMlTp87y W7Sw5tgyVlOWX5LH0apclSp7Z1Z9OtuScjr7DJ6GqB8e/3xjWeuUuq5W15WHb8VyIrjhuugGUxTI daRdyzGL7NbKD8D1jO2j+AcCM4FEaeZ+smUU7OcVKJPEDP5Ntl8ENoyHyTxEYDK8xf/Igwfeehpm dz0uMbpKo0a7rZiFI9Tz0JsjkSwA82M4g8ZTXHB1+LGohiWfbbrK0e33646IdNMUcjk5bGpGXPYK bim31pRyPOlE+iXuKg1jKeh37cXzG2eWhjDR1OCioHBuAh18OfKhwVBUXMM0OWTvyC7M4ej5cUfP Xr302UPWGoPHjTBlD4cTBQ+8e3AFDReuKiCPrLF6uZVFx/DIkI0ztqyspHwn07Sn2djI0U8vh40e NHOa7/zI/c3RbJ52ezEGNyc3V5VdmVm3hT277mzGOQyu4zffgws4BD4a/OFq9ZYloknUh/9jgMWg la1XFS/tKv3AfyfCQNv1MNJ6yBZe8o9P4RQ+nidsVxSYCis5A3e9qvVQ85l7D08+4EycqUC/Xbe9 tLCMo41avdG0dveK2bM3Ll/MBs5dO45DNI2mP0G9oWfn/W+AeD316cjgyLiAOKY0UnGg2Vi9a3fd scY9uDTcvjRr8rgFM4NCl5x6ksLm67mivH1idgmNlhZD5MRKoUmBxpoNhfmFedyO/hYxKyvbVcbA eKFKdt1MT6W24oYXd7s1zFFoprp8Jrt7lDp/xRCbDAPzRyLOvu7rzi6Xa3BnL+MTxQkjCafjM8ER 2hTyB3caaptaBzybeH/o0IlTR4fXxd5azcifTUtYtXjWgCFPJ//yy9OvO9tWnZv2CRMIu/H6+1cX Bc8OXxwYGP55263WC/dY1OAgf/bk2oLAoJnhkwLmtN5rv3bpcRcX1mEN6dEEp49LhQgwK4qUxRmc GotOWPKH0YGTo6dyaZyyVFWmLssv2i7mkjpbeSzjs+vXD5w8x7Z/efRbDt6iYZo/9EY9h7w/HhGD H0x4fudc4yOeybug2PRhjjIzY/2auC2rOXrGgravv710vf1Gy4cTDrKluVxh+WYR50zoB5Oh318r sArO4fsbVq+u3WC9f7ihIfFwfLfcb7PKfekbudcZSq3CvrVGGFeDG++aGvKznrzjZ05OvFMvgvhf aXU1UwplbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2JqCjU1ODUKZW5kb2JqCjQ5IDAgb2JqCjw8L0xl bmd0aDEgMTQwMTYvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA1MCAwIFI+PnN0cmVhbQp4nO07 aXhT15Xnvvf0tO+rJcvvyfIuG8mSNxmDHlgyNosxxhAbcJA3MBCCE0MKWQaaJpAY06T7lrSE6fT7 Jk2DkDvEJhsJdElmsk6bTNPQdJpMO0mhYRLKzIRYnnOfZAfSfG2nM/N984N3de4999zt3HPOPede 4gABAD3sAxY6Vq4OhkH+alKYrR3Y3jeSrUfKAMimgZt2ig/2H3ofCa8DsO9sGtm8/ennftMGwP0Y gL9983V7NmX7W5YDmN4bHuobfHnzEyqAuruQWDeMBOMOgxJAi+1QNLx95+5s/1rsQ5LX7Rjoy9b9 EoDx19v7do/oPq18F/tTPsTr+7YP5fi7FzNhZMfozmy9bpi2j9w4NPJX3he+jv2xnT/BF/A2xXnF S9x+boB9BEwAM7+aOZPZnRnM9LDfABeuuZYkyVZyE7kdch+5lmyWkW+TPrKNfAou/5bD38GT8Bq8 Cf82R5shHDGRPMT+hVjhNnn0P8Iv4A24AJeIgpiJm/jhT31fh4dz2CtkklHKmAbGmW/Bj0gGW78O zdCM3LzD3MreydL2/XAb1GD6Cz5Wz9xDNjCfgsPkAaaZ6WbOMA9e3k5UsBz3fiP5/B+OJQ4ikCBp JC2kk/STMfIuEyGL4G14H6ZRElYiwAm0jrfgLGGIitjIUnI3s4K5RDJkKz+mMHPvXTHbFtKKO9lA RskwGYaLiK+WpfFFzK8HHbhBmFs3AE+hrqqJju1n0uxy9mb2PYWGTQMoXgI3b2IuMJvgKOyFL2Dq gR5SBUn4DHwankP5nycfQrksx/uxxzZMb3AD3B72RyQNm2AtbMLyH2EduRcG4G7c3wqSx/w92GCC +Rd4AH5GNrCL4AvsHvI07tBIdiA/X8RRr8ME3MO99Jfo4Or3v/tJUldrY9P8xmhDfV1tTSRcHQrO q6oMVJSXlZYUF/kLfaJQ4M33uPNcTofdZrWYTUaDXqfVqFVKXsGxDIFKknI1dx/LUwY8Pp+vpypX d19ZT7HFpvd8KbBc0cnzsUH5H6t7P1YvmKu3p8CWavE3x+nEx6Dl1ymwpogtBXQVYl2BK+UGJQa3 +hNbUnnNg8kkjoj7TWKq5Xwwx4o89zGtptnfPKSpqoRjGi2iWsSw78gx0rKQyAjTkmg8xoBKX1WZ sgRSTHGCwtaUdDCJiD+OM2GL9aOWyZmT45c3AQ6bxaxZjKT45pRSXlfckpL6UnBQPFZ5cmx80gT9 yYBu0D/YtwEl14c8HgO2ODHcReWYoJAcFlMcTi5nHqSIiWFxzE/FkRhOYu6P46hPpCNZ3dx9wHfS k7JgmUiZA6kl2GPJzW952LGEa4tIq2NjB8TU4VXdl7f6aN7T0+NChscSfpwQJ0tsXYxbcQWrKrN7 yglgMLmVrrm1j/KZ2CqOHRySeR2XeZC7JoZRMX1/qtfYWGLQnxjsG1ycnb05JXXJBXSt65Y3iKKL 9+RIuQ7YwsktyXiPLyvsZZ3dzZQxf1/ck1X7HCWZoyAhMdsoUg7acIKUOCCmoLPbj10baDbUAGMD DbLx+NBbVi7r+GhUSlFs8otjv4cUSfrPnb2S0pej8MWm3wNFW/wtybGxFr/YMpYc65uc2dfvF03+ sWPLlo2NJJK4akc3jpqcOXHQk2oZ70mZksOkEWVPLaClszvm8Zl7Zqsds1VAk0LD0srbQSngry1X oJShq9snoqDWdPd4UE7dFO9CPFtSQ0LDbUAd58RGZTTUMCee5hzq81HrPDgpQT9WUvtWdWfrIvR7 0iAFA6iPJG05OdtiX0Nb9s22zA1P+nGV7wO9TtlTqpK5n9HksCaGG1PE8Ueah7LtKWtzN+therIY 42EppgngSW9KOQOIlwXGUAkv+lOmQErRfdLT1COazOgBqPZW+5etWtctJsbmrCBLye2U2gGaur9v eCx3lKjRfzJ12epZgVOLxSN9ECW+r38rGg3++sap+/GNmVItF30e35jZbxGjwZ6sVZte9D9D0HGh WzOlSJO8LSL7NFypLcU6G7DxL17hyi2hH1t8zE/uWnVMInetXtc9hTc88a6u7jRDmObk4p5jRdjW PSVidJCpzByV1kRag2X09KQZldzkmZIA9smtnEyQ6wOTBGSaapZGYGCSydJMMg2/KtQsaldFMj14 oR7+YNsHq/Uy5Yqvm1KU78E43kaHQAUMlhKswRu0YWYG7+DMCeiaOUkCaZ2+bgqRynRxeQ6x+bLI hNpUJ02SsrTbLRPKJvR6SiieaGmRy7Qgyg3FaU9+DrE7cojRnEM0OhkpTJeW5pCCgiwyodHQaQon dDpa+iacebRk006n3IFN59GFnyb2dIGQQzQ2GbGmcezUzFPEkV69Joe0r8whiUQOaW7OIeXlWWSi qISu4Ejn5ckrONIORw4xm3OIOiuPvHR1dRaZqKykg/LSgi/X4i3IITlGLRM4DXaxpF3ZeS3p9vYc kliSQ4pLckhuJcus5IW0VptD9LOUXB8hbbXmkByjgixGUkpIOizgknzaYpEbmHRZVn9korScMsNM IHdYklkui9IuVw4xmuoeJwaiADMIKBfFhF7WNDeB69IyrdbIPblZQXHppgU5ZOnSLDJxTQ/tG0yr tbJwVWm1W0bUaak5h8iDKDIvlENKK3JIYVEOcc+OstllxJYuKsohJaVZZEJnrTMuMpAIxBA2IrAg EDMQfA8Z8WUiEGOa6xAoWyAJWlfdzNuC8M5v3ULot+Rtm1t496xJ+B0CXJQuMhg0JNdFra7uInEL 585qBdP5e84z0tmRs0+eZdGVT3xgstVhKTX+p8VW95tfu4Vf17oF6TVkOPZP5KVXY8Irr7qFfT8l P8Ui+erIq8yzz1QIzz4TbXiWaH8c/zGTep3g8OOv4+kZeZmi0p0va6x1ReNd4zvH7xj/9nhq/PS4 UjpF6qfMwhaEpxCeRHgC4XGExxAeXWsWTkx5hL9D/PiUW3gEYRJhCnlpipmFBQgLEeIIzQiLY3Zh EYKEeKzWLIQjNiFSaxNqa2xCDZaHa2VOfLVa1PQNjY11b9xApBvU1rp7RlIjzBs7iLQDd/vi9XIv x/WU9033bkptYqXNamPdt4ZIalBumj9IncJhIn4p9SUm9nmy8Z699zDioZOHGHGbtI2BYSL/OoaT w+zePhJaL63fu37feq7hPrNAx79/nw7H/4BIE+QYaiZlswtHbWbhYYTvITxk0wrftRmEBxECFWZh pIJUVhmEKpte+KbYLAi2AgGDsSDamoTvu4uEb7mHBI87LOx13+Nm3LZC4UfWVsFuCwpWmyiELJKl w3KvhRux7LO8aGEtNpdgRgAb6bAlbSM2NmQgwOMrC39BEiM7yF5ylDxJXiDvkhmiMQIaVxBisAMf ckfxOf4CvAszoNGo6wUjY2SZF5gX2BlmhuUoRa2qEDhFhcCwJYJOH1VwUZaJEoh2KMgkzpayLINl XYtTVoLl6sXH1OHAstRg5+I7Dx3ypr5M7x37vD2TKuyDF5gU+WxPSkUjl4xCIPeN7sTf6M4Um0jx ieG+FO+Pj9KKgVYMtGJIpIy0YvTHScqWGE7ZkLozENi5i47fFZib6SNslMIozit/tD6KHXfRDC7r 94ff6CjB9lGQZwjIGaF0mRCYBVz7j03yl3wY3Rga7pTAA3oCJXglI89wgBDCGNeBtGDvc2eegyBm 1SGf2Wcuxgx1DR/sU8AlWgIiGBPbZ/6Ze1bxLjjBD61Snmeq0bLUsgdthfFN1fIJ/iae5TV+H1DT Naj19QDFxmKhmCnw6air0FvqdcHAuV5zBHOI9Z7DX3WI2Bglz/sLS0pLmNoaS31dXSTscDosClOJ v5A3mxyRcB337MJ4/LVv3v9aIr5wwZKW17/6wKuJ+ILM3euv27Zhw7ZtG5i3n8r8oq9vYGCgnwgn f0hcQwN9Q4P9mV8+SmxvvJF5J3P+zTcxwp/CeP4NxU/BCC1SQHGc53WsgZ0kqnexTUEEIkKQsKAz iERkO1jGaBbMDMuaTWZLNNjbGzkXDfcGI8FeiE2HY5Eg8u6j0vLVhuuQ63rEuG98WEYaMz9M3FUe quVIC4kQjrW+j2dpVdOlIK7yFeTgjOJ3IMJnJYdf3+hpMyz1dCi7DGtd671buJs9GtvkzNt4lag3 Ts4ckUoMpnqwGDwmi9cT9Gz2fMqjtFi0JxxMEK9SwhRRJYURgZFdhVNrqreMIOeiyidYmLy8QmOh UMgwVPA4HRMMULlbotFzuAOsQOxctDdGK9WhQKDX56uto7uoraFSR4Uo/ea6oojI2W1yzceduXTi 4Jmu7f237ogO1URaLd4Y0d1K1MR8673rHixhPvX+9ae7Rx/eMLwj3+EM6UiiIHb2lTumP9dz0Iv7 3oyWM6k4D81wVPJU6osCJQvCTc1N3fM7Fw01DCwebdBU1uBe0UxemcAyjEKQVqIFqZzI+8IFnslk PsnPr+FXhkgoVH6ihpE0RKMxnuA1QQn7a1sw8/vWNJJGTzBk84U8Cxo5NeAljgFIGBNCgtGqqSQ0 pnp1MBChoui1OKPnUJ3B3nN4SGRJyJms7OlolIoFBUPk/VPzNEcc1BazQiotKfH7zVdULxMbNWAH lZzdQTFuclX7yp9+7eH/bC/qPLO+bm+gsLwxFNofkebHbywrq6oQipKF9TfWVWxwCCuI4q47TyWW L//C7tqhUNV8cmr792Ox5sYi0lyz3CrmtTUvXmIyc4TXWazxxqqoyaJz20wRPYn5FsyrDH5u/d4n 8w2qkkDpLbj1qpkPud8pXgIN6OEmqU6n19fzShsyqeOVav0UiXEruY3cXg4/VsmyQWVMuV65TXmL UgFKnZ7lORHUchyzqHX16PeNRnTlel4yO+r5nBQDkcg5sxMlBsEYFVxkOmyORg8o5gW420yn8XT7 6QkxE585gjn3u2cyX5m+gfkM2fXM9POZA2R95gGykTjY5IdfJpcyCrSU3WgpjyLP82CPtEKjqjSG ubAtzsVtvYY1VSp9FypalYdG4fN5p8rL+eKpQla2BTPagr9YKJS0hvpCp89fKKtfRO8GIWNICDHq 3ElQZ09CLz0K6IeCs6pH7qfDQfkw5HRektW582NqL6RKxk3Zc57KwT26cmX7q/d/5932wvyWaO32 5sb95QWFAX/k3prOb0RF9rXpAwWrnduOt6y5lvzHzh+2Lmkn9YUkYSpz2D3ekoKlC2uWOQutbiMb z/zmPxg2UFU/Rb1tP0riJ4pzUAiNcIvUpNMZ8rw6Ia9CG9RV5q3T3qi8sUbjZisnwWvyMl4va7Ra nVM9RmJkGh6pY1tYhtWsBWKxlGQdslFtRIfcZGwSmhh32CeLQ2uh4pgOZ12y7NqoV0Y5yKcAZVId QmmA7yPvLBu32Z+Vw6wEyOXCsfF2W05o3E8yr2Q+vP0flqxZ17VxPSl5pu0LHo9794qjTzjavrKx 41D9ivWZdq9Q5PN1BUtXFzFVhe7m4oIWcum3mZeWta0lpsdPk9CuHbdZ+czP9b7Jh4INgfL5JzN3 F61Z23ptfr7dZtTM8++7r0zML6Bvul3oXR9D2+FhUCpk8cL7TYa1MQw+39gpBcuoWAKDQJhu6g8x Ak7OnJ+gUYpKR6fWonRURpWgYricpXBZSwkEUBYBai8Qi02bUSTUvA/cdpoQH6FO/7Hp/Zkk87Xp Rm4J97eXruEm6X92YCE28wvuZ4r3oRjv3C1wWBpSBO3BMkOwoVpcUL9YXFHfxW009NRvbLrFvMtr CM2rCUvz4uGevK55G+vXLkrO21q/c97e+pvn6+fX6wvD83i+/JHNeSSPWfQIr1lXuAm26LZYNwmK ElGoFK1Gq1DI6WrFXOzFsAGtxlahlVkoyrHXdHnsRc8XPBc8R2MA6htrvbKaZx1dSUltTV19bbaY VXHOmxE5PmQV7Kyrs8paL+UpJXtIuJ+tXL7854e+/KvWJfFD+z8z3Noaf+n2secWx1tv2fvF8czI 4NrOoQVS/gqptEhYuMm7vaJ0wR3XeZd5xVLyreTfNDXFE/PnH+7Z92CUl46PdN4brVs0P1R9cNXW 7zbyTaeYsuXrO5ua2gRDgSuycfq2tvZqQ4WldDQxfKvV5lxIT0185k3uON5RyvBuc4PUYmJNZh8j sqJ5LTPKKG3++ZNGp+BknE4++EjU3+Zn/IxGY5hawxNe0+Mlalu5T+3NRY7FxsXCYqbW56USNFrq vTkJoi3gEaGHBQsqwcvOCl5muCujRf3lUp273VwWM+aOS31NHXe8uzeZefOFlq/mefM3r2+7qzoS 13XcvWnFocYV61a2tb786dufbe26JvPZ8mL3ohJfzOsuKhbFznBFj4dlm57InL5h9BaLkhQbxNKK yjsGwrXlgabHv7zzB22tnW3L1mQu7N9zf6WY7/F5R5pbe/M9DqdOW45bxZsRU8wNyPfDMimPnGIU /CmFyqQW1YwSUjzg21EkLJEdvGw39OYm335QvMWZb5J+Csxr5O5L95O78Sw2z7ypsONNpwqOSD5O o6mwaTwVC1zV+StcUn6345qCPdxO7a3lev8wenTz5MwdNO7jbeW4pMYzyS3FjIpdqkTEKWEW1Iul jJzt0BO93lZ7M6qMSZaS0lKxdheuqNGXZWOVsb6sLGgMSsGNQdZtZzfNM13IGn4TdW/U2ct5b282 xKPDV4hgNoFPNnTZuX2CblCRETNPaWx+5ljmJnKQrOz57KLI7uIST2dNzW3xVQcWNCxZ2tR4z5Kl ++eFl+cXll8XbbnZS76ET6V+8jc2i7HGmrnf1SyKVZFY9Ok7Dj7e2BCuLhCkvMwRa7XZ7sA9fCez m3XzNtRCteRSPMEQ/gmiNaoJawQBX1cYzPiHiOyeMCBnXXbkcnXYEVj39DizM/MoSWR2K+87+0ET znsgs5u5NDsv94SSsLl5H5qbWHHZvBGc99xH89bSS66PuTQ9jnM+inPvPqs4fZaetpqZX3Gf5/ZD AXq5zZK/WF+jX8Ss5BbpVxeNMjfbVe4Knam+uEmrhcKFPHfYRVx0EdQ0LaU8dLoul1kCdV6e4Nbc UGosJcVaNztSYrqIZoZqi2TDM6pIDtDIzZyyMLf7HH+oHWtWdcwPMk9nvkeaSD5hCDdNFA3zqnYv WXBTdaDNWRxYsjC6x8v2DW4a5QtIiOQRK2nFZ8L0X7VvEQSPx2GtNGfeMHuNRjPzyx07b95Co4sd nXoXXwAu6JGaMNJIdtAaYiqzQq8ygtEtgKgOqSU1r1aDQaUCelkKGlmj2Qis1g0Gk0E0HDakDAoD ytZJL+G5KItRBQ9VTL58kGxgtdtlTZr9tRF0GtRjsF0e25qSrSuII3Mxc2R8/J9+vvyOkELHW9u3 qS98+Dl2xwXh+ee1asrnfszeQl2zUHqcIUQFbpINCga8wym4kEJSdChY+Z5Ln2Gx7DOGvJU5Qq7F YdkZlEXc7RCAfinIi3ypXbSXckpr3OMrAp3CVcDlKVyqgBv6fE6tW+dxul19+3Qp3Ys6lgYbyYTH VaerqjRVBaukqmQVl12s98J02HTOHL1AV41h2JkOo8v0medcoflKfPaGNReCzIrTvNEYi5a1z8sc ViLWEOgspWyv/erGzfeVD01saL81EAwy1atvLCry+cUP32KqO0cRLfN8+BY3cGtbZ3/ftUPhcN2X dk8XZ/fJHcF9OiAqFTE2q61Gk9CM2BUmvSpu5QwKolcRN+xwJV3EpHXrr3dmzfIi8t8Ui2U9vu8T ebZzRzKHtUZLPBroDssc/vXAQ8eZqvgBscQn+nPc/Oz57Bk6wz2GZ0iLr+piyW6R1FyBxGp0Hrih OFZMXB5+pAjXpMdh9kRmzV/OyScGEozDj2Veyvw2cy7zAqlG67aRUOZrPq/QHg4uFwuKCj35XZGK a9yCyFRjr6dIjNiJiyzIPJX518E7yyp83vLSuzZv3ltSWlRUFNhDrX/mHXap4tvggW7JrqWnSqXS czGNUuFy2WKgdmmp5kW8eWi13ph3pZfhNXq30sgLvMiyPLAm9iiLbwz0VxEaPOW3A31JB6n1R9D2 exWFJbXU5M1ZRza3mYid55maV07t30+uJasyRxmjYUk8f72lILrPkfoxo79AFmWevJC5cX6331/u 0vy70Sz/m77/z0qfgdNEIpeYNcxr7Ch7gtulMCmif5B+8t9LPF5B+cqPpSP8xY+S0qk8qHxe5ZtL e66mq+lqupqupqvparqarqar6Wq6mq6mq+lq+uQkv/OZ3F/z0X/xon/s50bgESnp7GhddQ27sG2l TfLaHU5XntuTb/0/+Bv3/6cfB8vlnKPyOe+YmcGc0BzrHOYl0Akd0Aqr4BqU3EJog5UoQwm8YAcH OMEFeeAGD+RDVmgELChrBjEe9ABdXYnqRQ0N4ZaGnaGQ/BeV5F5Q/Nncqa6snofzM1cQyGw3MgdM N/yPQOGCdoRTCF9B2IxQhbAboR9hF0IMIc78K5z6U6C4Bpr/L4E9At/JwYE/BtxJqGGNYP8kYLbC fuUDsF8hwH7uPNR8HNjVqGn2T+iJ6oH1v3osdfTERmPT78GTVdzDL/9S/n/EHvv37Wc+2Jbp1oNq P/ZVy/aB338BRBcJ4wplbmRzdHJlYW0KZW5kb2JqCjUwIDAgb2JqCjY0MDEKZW5kb2JqCjEzIDAg b2JqCjw8L0Jhc2VGb250L0xQUFJBVCtUaW1lcy1Sb21hbi9Gb250RGVzY3JpcHRvciAxMiAwIFIv VHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTQ4L1dpZHRoc1sKMjUwIDAgMCAwIDAg MCAwIDAgMzMzIDMzMyA1MDAgMCAyNTAgMzMzIDI1MCAyNzgKNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAyNzggMCA1NjQgMCAwCjAgNzIyIDY2NyA2NjcgNzIyIDYx MSA1NTYgMCA3MjIgMzMzIDAgMCA2MTEgODg5IDcyMiA3MjIKNTU2IDAgNjY3IDU1NiA2MTEgNzIy IDAgOTQ0IDAgMCAwIDMzMyAwIDMzMyAwIDUwMAowIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUw MCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwCjUwMCA1MDAgMzMzIDM4OSAyNzggNTAw IDUwMCA3MjIgNTAwIDUwMCA0NDQgMCAwIDAgNTQxIDAKMCAwIDAgMCAwIDEwMDAgMCAwIDAgMCAw IDAgMCAwIDAgMAowIDAgMzMzIDQ0NCA0NDRdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3Vi dHlwZS9UeXBlMT4+CmVuZG9iagozNSAwIG9iago8PC9CYXNlRm9udC9IT0FHT1orVGltZXMtQm9s ZC9Gb250RGVzY3JpcHRvciAzNCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIg MTIxL1dpZHRoc1sKMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMCAzMzMgMjUwIDI3OAow IDAgMCAwIDUwMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAzODkg MCAwIDAgMCA3MjIgMAo2MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCA1MDAgNTU2 IDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAwIDU1NiAyNzggODMzIDU1NiA1MDAKNTU2IDAg NDQ0IDM4OSAzMzMgNTU2IDUwMCA3MjIgNTAwIDUwMF0KL0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjkgMCBvYmoKPDwvQmFzZUZvbnQvSEdGVlZVK0NvdXJp ZXIvRm9udERlc2NyaXB0b3IgOCAwIFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIg MTIyL1dpZHRoc1sKNjAwIDAgNjAwIDAgMCAwIDAgNjAwIDYwMCA2MDAgMCAwIDYwMCA2MDAgNjAw IDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgMCAwIDAg MAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCAwIDYwMCA2MDAgNjAw IDAKNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCAwIDAgNjAwIDAgNjAwIDAgMAowIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBdCi9FbmNvZGluZy9X aW5BbnNpRW5jb2RpbmcvU3VidHlwZS9UeXBlMT4+CmVuZG9iagoxMSAwIG9iago8PC9CYXNlRm9u dC9WUlFHT0MrVFRFMUE4ODJGOHQwMC9Gb250RGVzY3JpcHRvciAxMCAwIFIvVHlwZS9Gb250Ci9G aXJzdENoYXIgMS9MYXN0Q2hhciAyMi9XaWR0aHNbIDY2NyA2MTcgOTU0IDU5NCA2NDAgNDE2IDI5 MyA0NTQgMzgyIDMwMiA2MzcgNDU0IDM2MyA2MzcgNjM3CjYzNyA2MzcgNjM3IDYzNyA2MzcgNjM3 IDYzN10KL0VuY29kaW5nIDUxIDAgUi9TdWJ0eXBlL1RydWVUeXBlPj4KZW5kb2JqCjUxIDAgb2Jq Cjw8L1R5cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNl c1sKMS9DL28vbS9lL24vdC9zcGFjZS9icmFja2V0bGVmdC9mL2wvb25lL2JyYWNrZXRyaWdodC9j b2xvbi90d28vdGhyZWUvZm91ci9maXZlL3NpeC9zZXZlbi9laWdodC9uaW5lL3plcm9dPj4KZW5k b2JqCjEyIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvTFBQUkFUK1RpbWVz LVJvbWFuL0ZvbnRCQm94Wy03MCAtMjE4IDkzMiA2ODhdL0ZsYWdzIDQKL0FzY2VudCA2ODgKL0Nh cEhlaWdodCA2ODgKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTM5Ci9NaXNz aW5nV2lkdGggMjUwCi9DaGFyU2V0KC90d28vTC9BL3kvcXVvdGVkYmxsZWZ0L24vYy90aHJlZS9N L0Ivei9vL2FzY2lpdGlsZGUvZC9mb3VyL04vQy9wL2UvZml2ZS9PL0QvcXVvdGVkYmxyaWdodC9x L2YvYnJhY2tldGxlZnQvc2l4L1AvRS9yL2cvc2V2ZW4vRi9lbGxpcHNpcy9zL2gvYnJhY2tldHJp Z2h0L2VpZ2h0L1IvdC9pL25pbmUvUy9IL3Uvai91bmRlcnNjb3JlL2NvbG9uL1QvSS92L2svc2Vt aWNvbG9uL1Uvdy9sL2EveC9tL2IvZXF1YWwvVy9xdW90ZXJpZ2h0L3BhcmVubGVmdC9wYXJlbnJp Z2h0L2FzdGVyaXNrL3NwYWNlL2NvbW1hL2h5cGhlbi9wZXJpb2Qvc2xhc2gvemVyby9vbmUpL0Zv bnRGaWxlMyA0MyAwIFI+PgplbmRvYmoKMzQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9G b250TmFtZS9IT0FHT1orVGltZXMtQm9sZC9Gb250QkJveFstMjQgLTIwNiA4MTQgNjk0XS9GbGFn cyA0Ci9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjk0Ci9EZXNjZW50IC0yMDYKL0l0YWxpY0FuZ2xl IDAKL1N0ZW1WIDEyMgovTWlzc2luZ1dpZHRoIDI1MAovQ2hhclNldCgveS9uL2Mvby9kL2ZvdXIv Ti9wL2UvZi9zaXgvUC9yL2cvcy9oL3QvaS91L0kvdi9rL3cvbC9hL3gvbS9iL3BhcmVubGVmdC9w YXJlbnJpZ2h0L3NwYWNlL2h5cGhlbi9wZXJpb2Qvc2xhc2gpL0ZvbnRGaWxlMyA0NSAwIFI+Pgpl bmRvYmoKOCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0hHRlZWVStDb3Vy aWVyL0ZvbnRCQm94WzAgLTE4NiA1OTMgNjY3XS9GbGFncyA1Ci9Bc2NlbnQgNjY3Ci9DYXBIZWln aHQgNjY3Ci9EZXNjZW50IC0xODYKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDg4Ci9BdmdXaWR0aCA2 MDAKL01heFdpZHRoIDYwMAovTWlzc2luZ1dpZHRoIDYwMAovQ2hhclNldCgvdHdvL0wvQS95L24v Yy90aHJlZS9NL0Ivei9vL2QvZm91ci9OL0MvcC9lL2F0L2ZpdmUvRC9xL2YvYnJhY2tldGxlZnQv c2l4L1AvRS9yL2cvc2V2ZW4vRi9zL2gvYnJhY2tldHJpZ2h0L2VpZ2h0L1IvRy90L2kvbmluZS9T L0gvdS9qL2NvbG9uL1QvSS92L2svVS93L2wvYS9WL3gvcXVvdGVzaW5nbGUvbS9iL1cvcGFyZW5s ZWZ0L3BhcmVucmlnaHQvc3BhY2UvY29tbWEvaHlwaGVuL3F1b3RlZGJsL3BlcmlvZC9zbGFzaC96 ZXJvL29uZSkvRm9udEZpbGUzIDQ3IDAgUj4+CmVuZG9iagoxMCAwIG9iago8PC9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0ZvbnROYW1lL1ZSUUdPQytUVEUxQTg4MkY4dDAwL0ZvbnRCQm94WzAgLTE5MSA4 OTIgNzY0XS9GbGFncyA0Ci9Bc2NlbnQgNzY0Ci9DYXBIZWlnaHQgNzY0Ci9EZXNjZW50IC0xOTEK L0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDEzMwovTWlzc2luZ1dpZHRoIDEwMDAKL0ZvbnRGaWxlMiA0 OSAwIFI+PgplbmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC4xNSkK L0NyZWF0aW9uRGF0ZShEOjIwMDkwNTIyMTUzOTQ2KQovTW9kRGF0ZShEOjIwMDkwNTIyMTUzOTQ2 KQovVGl0bGUoTWljcm9zb2Z0IFdvcmQgLSBkcmFmdC12YW4tYmVpam51bS1iZWhhdmUtZnJhZzY0 LTAwLmRvYykKL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjIpCi9BdXRob3IobHoy MTRjKT4+ZW5kb2JqCnhyZWYKMCA1MgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMzM0ODkgMDAw MDAgbiAKMDAwMDA1OTk3OSAwMDAwMCBuIAowMDAwMDMzMzg2IDAwMDAwIG4gCjAwMDAwMzI0MTYg MDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDA0Mzc4IDAwMDAwIG4gCjAwMDAwMzM1 MzcgMDAwMDAgbiAKMDAwMDA1OTI4NiAwMDAwMCBuIAowMDAwMDU3NTM4IDAwMDAwIG4gCjAwMDAw NTk3NzEgMDAwMDAgbiAKMDAwMDA1ODAwNyAwMDAwMCBuIAowMDAwMDU4NDI5IDAwMDAwIG4gCjAw MDAwNTY1OTYgMDAwMDAgbiAKMDAwMDAzMzU3OCAwMDAwMCBuIAowMDAwMDMzNjA4IDAwMDAwIG4g CjAwMDAwMzI1NzYgMDAwMDAgbiAKMDAwMDAwNDM5OCAwMDAwMCBuIAowMDAwMDEwMzA0IDAwMDAw IG4gCjAwMDAwMzM2NjAgMDAwMDAgbiAKMDAwMDAzMzY5MCAwMDAwMCBuIAowMDAwMDMyNzM4IDAw MDAwIG4gCjAwMDAwMTAzMjUgMDAwMDAgbiAKMDAwMDAxOTMxMCAwMDAwMCBuIAowMDAwMDMzNzQy IDAwMDAwIG4gCjAwMDAwMzM3NzIgMDAwMDAgbiAKMDAwMDAzMjkwMCAwMDAwMCBuIAowMDAwMDE5 MzMxIDAwMDAwIG4gCjAwMDAwMjYzMzcgMDAwMDAgbiAKMDAwMDAzMzgyNCAwMDAwMCBuIAowMDAw MDMzODU0IDAwMDAwIG4gCjAwMDAwMzMwNjIgMDAwMDAgbiAKMDAwMDAyNjM1OCAwMDAwMCBuIAow MDAwMDMyMTg2IDAwMDAwIG4gCjAwMDAwNTg5NjIgMDAwMDAgbiAKMDAwMDA1NzEzNCAwMDAwMCBu IAowMDAwMDMzOTA2IDAwMDAwIG4gCjAwMDAwMzM5MzYgMDAwMDAgbiAKMDAwMDAzMzIyNCAwMDAw MCBuIAowMDAwMDMyMjA3IDAwMDAwIG4gCjAwMDAwMzIzOTYgMDAwMDAgbiAKMDAwMDAzMzk5OSAw MDAwMCBuIAowMDAwMDM0MDI5IDAwMDAwIG4gCjAwMDAwMzQwNTkgMDAwMDAgbiAKMDAwMDA0MTAw NyAwMDAwMCBuIAowMDAwMDQxMDI4IDAwMDAwIG4gCjAwMDAwNDQzNzYgMDAwMDAgbiAKMDAwMDA0 NDM5NyAwMDAwMCBuIAowMDAwMDUwMDY4IDAwMDAwIG4gCjAwMDAwNTAwODkgMDAwMDAgbiAKMDAw MDA1NjU3NSAwMDAwMCBuIAowMDAwMDU4MjQ2IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNTIg L1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lEIFsol/wf3YZ/RJPxUPUMyKXckCkol/wf3YZ/RJPx UPUMyKXckCldCj4+CnN0YXJ0eHJlZgo2MDIwNQolJUVPRgo= ------_=_NextPart_001_01C9DB2E.F2F8BF08-- From iljitsch@muada.com Sat May 23 02:32: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 617E63A69BF for ; Sat, 23 May 2009 02:32:32 -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=[AWL=0.000, 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-zLPiF+UgBO for ; Sat, 23 May 2009 02:32:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 24E523A67E4 for ; Sat, 23 May 2009 02:32:30 -0700 (PDT) Received: from [192.168.2.4] (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 n4N9X74i077207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 May 2009 11:33:08 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 23 May 2009 11:33:19 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 May 2009 09:32:32 -0000 In response to an ICMP PTB with an MTU less than 1280, preferred IPv6 node implementations may take it upon themselves to only produce IPv6 packets smaller than 1280 bytes so that the translator need not generate IPv4 fragments. Do we know how many implementations do this rather than stick to 1280 =20= but now with a fragment header? For stateful, there is additional uniqueness material, including (sport, dport, saddr, daddr). No. The port numbers aren't present in fragments except the first one. =20= So if I use the same ID value for a packet with ports 1, 2 and a =20 packet with ports 3, 4 then the second fragment of the first packet =20 may be reassembled with the first fragment of the second. multi-fragment IPv6 packets should have DF=3D1in the IPv4 header of each translated fragment. I don't like this, as there is no way this can occur in IPv4. This has =20= the potential to trigger previously unknown bugs. We REALLY don't want =20= to have to deploy ugly hacks because our ugly hack (NAT64) doesn't work. Disagree because: 1) loss of packet too big messages would be an identical black hole condition to the pure IPv4 or pure IPv6 case, and 2) a n IPv6 node=92s failure to react to the packet too big messages would be a violation of RFC2460. No. Although discouraged, it is allowed for an IPv6 host to not run =20 PMTUD if it doesn't send packets larger than 1280 bytes. So someone =20 who doesn't like ICMP messages could set the MTU option in RAs to 1280 =20= and filter incoming "too big" messages. That wouldn't create any =20 problems for IPv6 communication. However, when you start translating =20 and send translated packets to IPv4 destinations with an MTU smaller =20 than 1260, you have a black hole because the IPv6 host will not reduce =20= its packet size or include the fragment header. I guess you could say =20= "but people create those black holes in the pure IPv4 case too by =20 setting DF=3D1 and filtering "too big" messages" but that doesn't make =20= it a valid choice that we can mandate in an RFC. You may argue that the host SHOULD react to the "too big" messages =20 despite the fact it doesn't want to run PMTUD, but that doesn't fix =20 anything: RFC 2460 allows for this so we must address the situation. I can't seem to make sense of the suggested added text for option 1. =20 So please answer the following questions: - if a packet 1280 bytes or larger is translated to IPv4, set DF to 1? - if a packet 1280 bytes or smaller is translated to IPv4: - without a fragment header, set DF to 0? - with a fragment header more fragments =3D 0, offset =3D 0, set DF to = 1? - with a fragment header, more fragments =3D 1 or offset > 0, set DF to = 0? If the above is correct, it solves the black hole case without =20 creating IPv4 fragments with DF =3D 1 so this does what we want but I =20= would still prefer option 3 because it's simpler. Also, if you take the identification handling from option 1 that is =20 still very broken in the stateful case and somewhat broken in the =20 stateless case. You also say something about "fragment the packet locally". That's not =20= how things work in IPv4. As long as the translator has the same MTU on =20= both sides, it never has to fragment IPv4 packets because the =20 translation never increases them beyond the MTU size so they can =20 always be sent whole. Of course when the destination is sitting behind =20= a link with a reduced MTU, then a router along the way will have to =20 fragment. However, that doesn't involve the translator. The only thing =20= it has to do is set DF to 0. Exposure to SUSTAINED IPv4 fragmentation at high data rates is dangerous no matter how carefully the IP_ID is crafted; too dangerous to allow for a long-term solution. This would seem to be much more of a concern for translation than for tunneling. In particular, tunnels that allow IPv4 fragmentation are likely to occur between endpoints over paths with robust links that will almost always set larger MTUs. With translation, on the other hand, IPv4 end systems may be deeply embedded within sites that have high-speed links with degenerate MTUs such that sustained IPv4 fragmentation at high data rates may be unavoidable. Near-term IPv6 migration of sites and end systems containing IPv4 servers is therefore strongly encouraged (where dual-stacked IPv6/IPv4 services may be maintained for an extended period). If IPv4 networks don't use MTUs smaller than 1280 bytes and they won't =20= have trouble. Note that the sustained stream of fragments issue is much less =20 problematic in the translator case compared to the tunnel case, =20 because presumably, the setup won't be such that ALL traffic for a =20 given host goes through the same translator, while it's very possible =20= that all traffic for a given host goes through the same tunnel. Also, =20= the use of a tunnel makes an MTU reduction unavoidable, while having =20 an MTU < 1280 (1260, really) is orthogonal from the use of a =20 translator. And if the host uses an MSS that reflects the reduced MTU =20= (or the MSS is adjusted somewhere in the path) then the issue doesn't =20= come up for TCP. For UDP, it would be quite extraordinary for an IPv4 =20= host to receive a large amount of fragmented UDP traffic. Basically =20 that only happens with applications like video streaming, but then =20 usually not in the client-to-server direction.= From gaborbajko@gmail.com Sat May 23 12:40: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 0E3193A6B70 for ; Sat, 23 May 2009 12:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 jDkU5KwfdvTc for ; Sat, 23 May 2009 12:40:11 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 50D1D3A6BF8 for ; Sat, 23 May 2009 12:40:11 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so422987waf.5 for ; Sat, 23 May 2009 12:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references:subject :date:message-id:mime-version:content-type:content-transfer-encoding :x-mailer:x-mimeole:in-reply-to:thread-index; bh=YzHxxqd5r8pSGi4oGQVTKQgeCcmc6v+HRsxCqfuIk10=; b=F/v2Pzq0vYUUo/0HUYuG0W3fr2DxSTpEHVijcHovgVw9Ie+6Wwkq/koDUoKAMwLLj7 fO3b1BujNkYLWYEIjL9b+f+mkTCHdQExhlDDyWWqciGl8qm226zEx0f3ZaT/CJ4r0RE/ foMqpYEXsC9fViw7F+TKdyYOwQZQR4esaAPcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:x-mimeole :in-reply-to:thread-index; b=Dsgcs+zbcPRmVbNPfIuohGqHik0yYtQJzY2H1BJ9eb0DkcRx/RWxZLodtrgcZrByix dRJmmZZ826FaifoxOeB6n7Pm4GbTplfYk7ZLGXu4Wdkp3iAoWohQK2Onl8pUtxI4Rlh8 NO/ig7dkaQdS+p0eFKr5WZj837E8KiLD66mOQ= Received: by 10.115.18.1 with SMTP id v1mr10835631wai.175.1243107705298; Sat, 23 May 2009 12:41:45 -0700 (PDT) Received: from 1USL00618 (c-67-169-182-244.hsd1.ca.comcast.net [67.169.182.244]) by mx.google.com with ESMTPS id m28sm3675666waf.2.2009.05.23.12.41.43 (version=SSLv3 cipher=RC4-MD5); Sat, 23 May 2009 12:41:44 -0700 (PDT) From: "Gabor Bajko" To: "'Behave WG'" References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com><4A018B03.6070601@free.fr><495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com><4A098864.3060702@free.fr><495c4ae90905130346n7fa84708hb746f30110b9cf84@mail.gmail.com><4A13D3B7.10407@free.fr> <20090522140347.GA20641@river.styx.org> Date: Sat, 23 May 2009 12:41:41 -0700 Message-ID: <007201c9dbde$8093ead0$6400a8c0@NOE.Nokia.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 In-Reply-To: <20090522140347.GA20641@river.styx.org> Thread-Index: Acna//pxmDtCLAHaS/GzYdNGlYtEqAAJUFrg Subject: [BEHAVE] Question on DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 23 May 2009 19:40:12 -0000 Hello, I have a terminology question regarding the above draft: The draft uses the 'IPv6-only client' and 'IPv4-only server' terminologies, and it was not immediately clear to me what they mean, as they are not defined in the terminology section. I found though this text in section 1: " ... a lot of IPv6-only clients will want to connect to IPv4-only servers. These include hosts running IPv6- only applications, IPv6-only hosts as well as the cases where only IPv6-only connectivity is available between the client and the NAT64." I wonder if a similar description would be valid for the 'IPv4-only server', ie 'a server running IPv4 applications, IPv4-only servers as well as the cases where only IPv4 connectivity is available between the server and the NAT64' (I regard a server not a fixed node, any mobile node can become a server, eg when hosts services). When I have a dual stack node running IPv4 only applications but provisioned with IPv6 address only, would that classify it as an 'IPv6-only client' in this context? Similarly, when I have a dual stack server, running only IPv6 applications, but attached to a network where it can only get an IPv4 address, would the node become an 'IPv4-only server' in this context? Thanks, - Gabor From Fred.L.Templin@boeing.com Tue May 26 11:30: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 563483A702D for ; Tue, 26 May 2009 11:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 K2xuOzdynWgq for ; Tue, 26 May 2009 11:30:06 -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 43BF23A7109 for ; Tue, 26 May 2009 11:30:06 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4QIVeZY007659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 May 2009 11:31:41 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4QIVeKB007119; Tue, 26 May 2009 11:31:40 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4QIVV3Y006422; Tue, 26 May 2009 11:31:40 -0700 (PDT) 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); Tue, 26 May 2009 11:31:36 -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: Tue, 26 May 2009 11:31:36 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcnbiYkygbsPXoTdQTmZMDQtm8Q4ZwCpWgzA References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 26 May 2009 18:31:36.0991 (UTC) FILETIME=[340E2AF0:01C9DE30] Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 May 2009 18:30:08 -0000 Iljitsch, Much of your discussion was too nebulous for me to follow, so I'll just say one thing for now. Including a frag hdr with (MF=3D0; Offset=3D0) is the IPv6 host's way of telling the translator to set DF=3D0; everything else is DF=3D1. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Saturday, May 23, 2009 2:33 AM > To: Templin, Fred L > Cc: Behave WG > Subject: Re: [BEHAVE] The fragmentation issue >=20 > In response to an > ICMP PTB with an MTU less than 1280, > preferred IPv6 node implementations > may take it upon themselves to only > produce IPv6 packets smaller than 1280 > bytes so that the translator need not > generate IPv4 fragments. >=20 > Do we know how many implementations do this rather than stick to 1280 > but now with a fragment header? >=20 > For stateful, there is > additional uniqueness material, including > (sport, dport, saddr, daddr). >=20 > No. The port numbers aren't present in fragments except the first one. > So if I use the same ID value for a packet with ports 1, 2 and a > packet with ports 3, 4 then the second fragment of the first packet > may be reassembled with the first fragment of the second. >=20 > multi-fragment IPv6 packets should have > DF=3D1in the IPv4 header of each > translated fragment. >=20 > I don't like this, as there is no way this can occur in IPv4. This has > the potential to trigger previously unknown bugs. We REALLY don't want > to have to deploy ugly hacks because our ugly hack (NAT64) doesn't work. >=20 > Disagree because: > 1) loss of packet too big messages would > be an identical black hole condition to the > pure IPv4 or pure IPv6 case, and 2) a n > IPv6 node's failure to react to the packet > too big messages would be a violation of > RFC2460. >=20 > No. Although discouraged, it is allowed for an IPv6 host to not run > PMTUD if it doesn't send packets larger than 1280 bytes. So someone > who doesn't like ICMP messages could set the MTU option in RAs to 1280 > and filter incoming "too big" messages. That wouldn't create any > problems for IPv6 communication. However, when you start translating > and send translated packets to IPv4 destinations with an MTU smaller > than 1260, you have a black hole because the IPv6 host will not reduce > its packet size or include the fragment header. I guess you could say > "but people create those black holes in the pure IPv4 case too by > setting DF=3D1 and filtering "too big" messages" but that doesn't make > it a valid choice that we can mandate in an RFC. >=20 > You may argue that the host SHOULD react to the "too big" messages > despite the fact it doesn't want to run PMTUD, but that doesn't fix > anything: RFC 2460 allows for this so we must address the situation. >=20 > I can't seem to make sense of the suggested added text for option 1. > So please answer the following questions: >=20 > - if a packet 1280 bytes or larger is translated to IPv4, set DF to 1? >=20 > - if a packet 1280 bytes or smaller is translated to IPv4: >=20 > - without a fragment header, set DF to 0? >=20 > - with a fragment header more fragments =3D 0, offset =3D 0, set DF to = 1? >=20 > - with a fragment header, more fragments =3D 1 or offset > 0, set DF = to 0? >=20 > If the above is correct, it solves the black hole case without > creating IPv4 fragments with DF =3D 1 so this does what we want but I > would still prefer option 3 because it's simpler. >=20 > Also, if you take the identification handling from option 1 that is > still very broken in the stateful case and somewhat broken in the > stateless case. >=20 > You also say something about "fragment the packet locally". That's not > how things work in IPv4. As long as the translator has the same MTU on > both sides, it never has to fragment IPv4 packets because the > translation never increases them beyond the MTU size so they can > always be sent whole. Of course when the destination is sitting behind > a link with a reduced MTU, then a router along the way will have to > fragment. However, that doesn't involve the translator. The only thing > it has to do is set DF to 0. >=20 > Exposure to > SUSTAINED IPv4 fragmentation at high > data rates is dangerous no matter how > carefully the IP_ID is crafted; too > dangerous to allow for a long-term > solution. This would seem to be much > more of a concern for translation than for > tunneling. >=20 > In particular, tunnels that allow IPv4 > fragmentation are likely to occur between > endpoints over paths with robust links > that will almost always set larger MTUs. > With translation, on the other hand, IPv4 > end systems may be deeply embedded > within sites that have high-speed links > with degenerate MTUs such that > sustained IPv4 fragmentation at high data > rates may be unavoidable. >=20 > Near-term IPv6 migration of sites and > end systems containing IPv4 servers is > therefore strongly encouraged (where > dual-stacked IPv6/IPv4 services may > be maintained for an extended period). >=20 > If IPv4 networks don't use MTUs smaller than 1280 bytes and they won't > have trouble. >=20 > Note that the sustained stream of fragments issue is much less > problematic in the translator case compared to the tunnel case, > because presumably, the setup won't be such that ALL traffic for a > given host goes through the same translator, while it's very possible > that all traffic for a given host goes through the same tunnel. Also, > the use of a tunnel makes an MTU reduction unavoidable, while having > an MTU < 1280 (1260, really) is orthogonal from the use of a > translator. And if the host uses an MSS that reflects the reduced MTU > (or the MSS is adjusted somewhere in the path) then the issue doesn't > come up for TCP. For UDP, it would be quite extraordinary for an IPv4 > host to receive a large amount of fragmented UDP traffic. Basically > that only happens with applications like video streaming, but then > usually not in the client-to-server direction. From iljitsch@muada.com Tue May 26 13:53: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 DA2873A6D6F for ; Tue, 26 May 2009 13:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 aZupvFADNtvG for ; Tue, 26 May 2009 13:53:46 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 008913A684C for ; Tue, 26 May 2009 13:53:45 -0700 (PDT) Received: from [192.168.2.4] (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 n4QKsgCx056722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 May 2009 22:54:47 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@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 v935.3) Date: Tue, 26 May 2009 22:54:56 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 26 May 2009 20:53:46 -0000 On 26 mei 2009, at 20:31, Templin, Fred L wrote: > Much of your discussion was too nebulous for me to follow, > so I'll just say one thing for now. Including a frag hdr > with (MF=0; Offset=0) is the IPv6 host's way of telling > the translator to set DF=0; everything else is DF=1. I explained in the draft and my emails how this introduces PMTUD black holes, so I don't think this is a valid choice. From wangxuewei@huawei.com Tue May 26 20:22: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 D3CF33A6819 for ; Tue, 26 May 2009 20:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, 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 Oiq4vn07WNVo for ; Tue, 26 May 2009 20:22:09 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1D4E43A6D58 for ; Tue, 26 May 2009 20:22:09 -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 <0KKA00D139CBF4@szxga03-in.huawei.com> for behave@ietf.org; Wed, 27 May 2009 11:21:47 +0800 (CST) Received: from w00104636 ([10.111.12.168]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKA00GCJ9CA03@szxga03-in.huawei.com> for behave@ietf.org; Wed, 27 May 2009 11:21:47 +0800 (CST) Date: Wed, 27 May 2009 11:21:47 +0800 From: Xuewei Wang To: Dan Wing , =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= , 'Behave WG' Message-id: <006a01c9de7a$44be0510$a80c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <4A02B8B9.1000905@free.fr> <021f01c9d2a5$778ee4e0$c5f0200a@cisco.com> Subject: Re: [BEHAVE] DNSsec in IPv6-only-hosts & discarding mapped AAAAs inDNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 May 2009 03:22:10 -0000 aGksRGFuLA0KDQpJZiB2NC1tYXBwZWQgYXMgdGhlIHdlbGwta25vd24gcHJlZml4IGlzIG5vdCBh dmFpbGFibGUgZm9yIElQdjYgb25seSBob3N0LCBjb3VsZCB3ZSBjb25zaWRlciBvdGhlciB3ZWxs LWtub3duIHByZWZpeCB3aGljaCByZXF1aXJlcyBJQU5BIGFsbG9jYXRlcz8NCg0KRm9yIEROU1NF QyB3ZSBjYW4gY2FuY2VsIHRoZSBETlM2NCwgYW5kIG1ha2UgdGhlIEROUyBzZXJ2ZXIgc3ludGhl c2l6ZSBBQUFBIFJSIHVzaW5nIGEgd2VsbC1rbm93biBwcmVmaXggZm9yIElQdjQgb25seSBob3N0 LCBzbyBETlNTRUMgY2FuIGJlIGltcGxlbWVudGVkIGF0IElQdjYgaG9zdC4NCkZvciBkdWFsIHN0 YWNrIGhvc3QgaW4gdGhlIElQdjYgbmV0d29yaywgc2hvdWxkIHVwZ3JhZGUgdGhlbSB0byBtYWtl IHRoZW0gdG8gcmVjb2duaXplIHRoZSB3ZWxsLWtub3duIHByZWZpeCwgYW5kIG9idGFpbiB0aGUg b3JpZ2luYWwgSVB2NCBhZGRyZXNzIGZyb20gdGhlIHN5bnRoZXNpemVkIElQdjYgYWRkcmVzcy4N Cg0KWHVld2VpIFdhbmcNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiRGFu IFdpbmciIDxkd2luZ0BjaXNjby5jb20+DQpUbzogIidS6W1pIERlc3By6XMnIiA8cmVtaS5kZXNw cmVzQGZyZWUuZnI+OyAiJ0JlaGF2ZSBXRyciIDxiZWhhdmVAaWV0Zi5vcmc+DQpTZW50OiBUdWVz ZGF5LCBNYXkgMTIsIDIwMDkgMTA6MDAgQU0NClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBETlNzZWMg aW4gSVB2Ni1vbmx5LWhvc3RzICYgZGlzY2FyZGluZyBtYXBwZWQgQUFBQXMgaW5ETlM2NA0KDQoN ClLpbWksDQoNCkkgaGF2ZSBvbmUgbW9yZSBxdWVzdGlvbiBhYm91dCB1c2luZyB2NC1tYXBwZWQg YXMgdGhlIHdlbGwta25vd24gcHJlZml4IGZvcg0KdGhlIDYvNCB0cmFuc2xhdG9yLiAgSXQgYXBw ZWFycywgYmFzZWQgb24gSWxqaXRzaCdzIHRlc3RpbmcgbGFzdCBzdW1tZXIgWzFdDQp0aGF0IHdo ZW4gV2luZG93cyBWaXN0YSBvciBNYWNPUyBMZW9wYXJkIGFyZSBjb25maWd1cmVkIGFzIElQdjYt b25seSAodGhhdCBpcywNCm5vIElQdjQgYWRkcmVzcyksIHRoZXkgd29uJ3Qgc2VuZCBhIHY0LW1h cHBlZCBJUHY2IHBhY2tldCBhdCBhbGwuICBUaGlzIHNlZW1zDQphIHByb2JsZW0gZm9yIHVzaW5n IHY0LW1hcHBlZCBhcyB0aGUgd2VsbC1rbm93biBwcmVmaXggb2YgdGhlIElQdjYvSVB2NA0KdHJh bnNsYXRvci4NCg0KWzFdIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pbnQt YXJlYS9jdXJyZW50L21zZzAxNDc2Lmh0bWwNCg0KDQpJIGRvIHdvbmRlciwgaG93ZXZlciwgaWYg Y29uZmlndXJpbmcgdGhvc2UgaG9zdHMgZm9yIElQdjQganVzdCB0byBrbm93IGFib3V0DQoxMjcu MC4wLjEgd291bGQgYmUgc3VmZmljaWVudCBmb3IgdGhlaXIgSVAgc3RhY2tzIHRvIGVtaXQgdjQt bWFwcGVkIElQdjYNCmFkZHJlc3Nlcy4gIA0KDQpJbGppdHNjaCwgd291bGQgeW91IGhhdmUgdGlt ZSB0byB0ZXN0IHRoYXQgaWRlYSwgb3Igd291bGQgeW91IGtub3cgb2ZmLWhhbmQNCnRoZSBhbnN3 ZXIgZnJvbSBwcmV2aW91cyB0ZXN0aW5nIHlvdSBkaWQ/DQoNCi1kDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGFuIFdpbmcgW21haWx0bzpkd2luZ0BjaXNjby5jb21d IA0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA3LCAyMDA5IDE6MTYgUE0NCj4gVG86ICdS6W1pIERl c3By6XMnOyAnQmVoYXZlIFdHJw0KPiBTdWJqZWN0OiBSRTogRE5Tc2VjIGluIElQdjYtb25seS1o b3N0cyAmIGRpc2NhcmRpbmcgbWFwcGVkIA0KPiBBQUFBcyBpbiBETlM2NA0KPiANCj4gIA0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFLpbWkgRGVzcHLpcyBb bWFpbHRvOnJlbWkuZGVzcHJlc0BmcmVlLmZyXSANCj4gPiBTZW50OiBUaHVyc2RheSwgTWF5IDA3 LCAyMDA5IDM6MzIgQU0NCj4gPiBUbzogRGFuIFdpbmc7IEJlaGF2ZSBXRw0KPiA+IFN1YmplY3Q6 IFJlOiBETlNzZWMgaW4gSVB2Ni1vbmx5LWhvc3RzICYgZGlzY2FyZGluZyBtYXBwZWQgDQo+ID4g QUFBQXMgaW4gRE5TNjQNCj4gPiANCj4gPiBEYW4gV2luZyAgLSAgbGUgKG0vai9hKSA1LzcvMDkg MzoyNiBBTToNCj4gPiA+IFNvLCB0aGlzIG1lYW5zDQo+ID4gPiANCj4gPiA+IDEuIGFsbCBuZXR3 b3JrcyBkZXBsb3lpbmcgYSB0cmFuc2xhdG9yIGZvciBJUHY2LWluaXRpYXRlZCANCj4gc2NlbmFy aW9zIA0KPiA+ID4gKFNjZW5hcmlvIDEgYW5kIFNjZW5hcmlvIDUpIHdvdWxkIGhhdmUgdG8gdXNl IHRoZSANCj4gd2VsbC1rbm93biBwcmVmaXgNCj4gPiANCj4gPiBBLg0KPiA+IFRoZSBzY2VuYXJp byBiZWluZyBkaXNjdXNzZWQgaXMgImNvbm5lY3RpbmcgYW4gSVB2NiBuZXR3b3JrIA0KPiA+IHRv IHRoZSBJUHY0DQo+ID4gSW50ZXJuZXQiLCBpLmUuIHNjZW5hcmlvICgyKSBpbiBGcmVkJ3MgZHJh ZnQgb24gdGhlIFRyYW5zbGF0aW9uDQo+ID4gRnJhbWV3b3JrLiAoSSBtdXN0IGNvbmZlc3MgSSBh bSBjb25mdXNlZCB3aXRoIHNjZW5hcmlvcyANCj4gaWRlbnRpZmllZCBieQ0KPiA+IG51bWJlcnM6 IEZyZWQgaGFzIG9ubHkgNCBvZiB0aGVtLikNCj4gDQo+IFllcywgc29ycnkgYWJvdXQgdGhhdC4N Cj4gDQo+IEkgd2FzIGdvaW5nIHdpdGggdGhlIDQgd2UgaGF2ZSBpbiB0aGUgY2hhcnRlciwNCj4g aHR0cDovL3d3dy5pZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL2JlaGF2ZS1jaGFydGVyLmh0bWwsIGFu ZCB0aGUNCj4gb3RoZXIgdHdvIGRlZmluZWQgYnkgRGF2ZSBUaGFsZXIgaW4gdGhlIERvb2RsZSBw b2xsLA0KPiBodHRwOi8vd3d3LmRvb2RsZS5jb20vcGFydGljaXBhdGlvbi5odG1sP3BvbGxJZD05 cXNkZ3Q4cjZrcWs2enR5DQo+IA0KPiBPdXIgc29vbi10by1iZS11cGRhdGVkIGNoYXJ0ZXIgd2ls bCBoYXZlIGFsbCA2LCBiZWNhdXNlIGF0DQo+IHRoZSBTYW4gRnJhbmNpc2NvIG1lZXRpbmcgdGhl IGNsZWFyIGNvbnNlbnN1cyB3YXMgdG8gd29yayBvbg0KPiBhbGwgNi4NCj4gDQo+ID4gQi4NCj4g PiBBIG5ldHdvcmsgZGVwbG95aW5nIGEgdHJhbnNsYXRvciBmb3IgSVB2Ni1pbml0aWF0ZWQgc2Nl bmFyaW9zIHNob3VsZA0KPiA+IHJvdXRlIHRvIGl0cyBOQVQ2NHMgYWxsIHBhY2tldHMgd2hvc2Ug ZGVzdGluYXRpb24gc3RhcnQgd2l0aDoNCj4gPiAtIHRoZSBwcmVmaXgoZXMpIGNob3NlbiBieSB0 aGUgSVNQIGZvciBpdHMgTkFUNjRzIChhbiBJU1Atc3BlY2lmaWMNCj4gPiBwcmVmaXggYW5kL29y LCBpZiBhIFdLUCBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mIG1hcHBlZCBhZGRyZXNzZXMgaXMNCj4g PiBzdGFuZGFyZGl6ZWQsIHRoaXMgV0tQICkNCj4gDQo+IE9rLg0KPiANCj4gPiAtIHRoZSBtYXBw ZWQgYWRkcmVzcyBwcmVmaXggKG9yIGF0IGxlYXN0IGl0cyA2NCBmaXJzdCBiaXRzLCANCj4gPiBp LmUuIDo6LzY0LA0KPiA+IGlmIC85NiBwcmVmaXhlcyBhcmUgbm90IHJvdXRlZCkNCj4gPg0KPiA+ ID4gMi4gYWxsIGV4aXN0aW5nIGR1YWwtc3RhY2sgaG9zdHMgd291bGQgc2VlIHRoZXNlIHB1Ymxp c2hlZCBBQUFBDQo+ID4gPiByZWNvcmQsIHdoaWNoIHdvdWxkIHJlcXVpcmUgdGhvc2UgaG9zdHMg dG8gdXNlIGEgDQo+IHRyYW5zbGF0b3IgaWYgdGhlIA0KPiA+ID4gaG9zdCBPUyBvciBpdHMgYXBw bGljYXRpb24gcHJlZmVyIElQdjYgb3ZlciBJUHY0LiAgV2hhdCANCj4gaGFwcGVucyBpZiANCj4g PiA+IHRoZXJlIGlzbid0IGEgdHJhbnNsYXRvciBhdmFpbGFibGUgdG8gdGhhdCB1c2VyIG9yIGl0 cyANCj4gPiA+IHBlcmZvcm1hbmNlIGlzIHBvb3I/DQo+ID4gDQo+ID4gV2hlbiBtYXBwZWQtYWRk cmVzcyBBQUFBcyBzdGFydCBiZWluZyBwdWJsaXNoZWQsIGR1YWwtc3RhY2sgDQo+IGhvc3RzIGFy ZQ0KPiA+IGV4cGVjdGVkIHRvIHNlbmQgZGF0YWdyYW1zIGhhdmluZyBtYXBwZWQgYWRkcmVzc2Vz IGFzIGRlc3RpbmF0aW9uczoNCj4gPiAtIGluIElQdjQgaWYgYW4gSVB2NCBhZGRyZXNzIGlzIGF2 YWlsYWJsZSBhdCB0aGUgaW50ZXJmYWNlDQo+ID4gLSBpbiBJUHY2IG90aGVyd2lzZSAoYW5kIHRo ZW4gcmVxdWlyZSBhIE5BVDY0IHRvIGJlIHByb3ZpZGVkIA0KPiA+IGJ5IHRoZSBJU1ApDQo+IA0K PiBPaywgdGhhbmtzLiAgDQo+IA0KPiBTbywgSSBiZWxpZXZlIHRoZSB0aW1lZnJhbWVzIHdvdWxk IGJlIGFsaWduZWQ6ICBBbiBJU1AgdGhhdCBvZmZlcnMNCj4gb25seSBJUHY2IGFkZHJlc3NlcyB0 byBzdWJzY3JpYmVycyB3aWxsIG5lZWQgdG8gb3BlcmF0ZSBhIHRyYW5zbGF0b3INCj4gdG8gYWNj ZXNzIElQdjQgYW55d2F5Lg0KPiANCj4gPiA+IEFyZSB0aGVyZSBvdGhlciBpbXBhY3RzLCB0b28/ DQo+ID4gDQo+ID4gRE5TNjRzOg0KPiA+IC0gIGFzIGxvbmcgYXMgZHVhbC1zdGFjayBob3N0cyBj YW5ub3QgYmUgZXhwZWN0ZWQgdG8gYWN0IGFzIA0KPiBzcGVjaWZpZWQNCj4gPiBhYm92ZSwgTVVT VCBkaXNjYXJkIG1hcHBlZCBhZGRyZXNzIHJlY29yZHM7DQo+IA0KPiBXZSB3b3VsZCBsaWtlIGR1 YWwtc3RhY2sgaG9zdHMgdG8gcHJlZmVyIG5hdGl2ZSBjb25uZWN0aXZpdHkgKHJhdGhlcg0KPiB0 aGFuIHRyYW5zbGF0ZWQgY29ubmVjdGl2aXR5KS4NCj4gDQo+ID4gLSBhZnRlciB0aGF0LCBTSE9V TEQgZm9yd2FyZCB0aGVtLCBhdCBsZWFzdCBpZiB0aGV5IGFyZSANCj4gRE5Tc2VjIHNpZ25lZC4N Cj4gPiANCj4gPiBJUHY2LW9ubHkgYXBwbGljYXRpb25zIHNob3VsZCBub3QgYXJ0aWZpY2lhbGx5 IGJsb2NrIG1hcHBlZCANCj4gYWRkcmVzc2VzDQo+ID4gZGVzdGluYXRpb25zLg0KPiANCj4gU28g YXBwbGljYXRpb25zIGFuZCBob3N0IE9TcyBzaG91bGQgaWdub3JlIA0KPiBkcmFmdC1pdG9qdW4t djZvcHMtdjRtYXBwZWQtaGFybWZ1bCwgY29ycmVjdD8NCj4gDQo+ID4gRG9lcyB0aGlzIGFuc3dl ciB5b3VyIHF1ZXN0aW9ucz8NCj4gDQo+IFllcywgdGhhbmtzLiAgTXVjaCBjbGVhcmVyIG5vdy4N Cj4gDQo+IEFuZCBJIHNlZSBob3cgdGhpcyBjb3VsZCB3b3JrIG5vdy4NCj4gDQo+IC1kDQo+IA0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQmVoYXZl IG1haWxpbmcgbGlzdA0KQmVoYXZlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JlaGF2ZQ== From Fred.L.Templin@boeing.com Wed May 27 14:08: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 E3EB73A6ED2 for ; Wed, 27 May 2009 14:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 4m1MC0IBcoo1 for ; Wed, 27 May 2009 14:08:05 -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 125AC3A6778 for ; Wed, 27 May 2009 14:08:05 -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 n4RL9iLS026338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 May 2009 14:09:45 -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 n4RL9i85024476; Wed, 27 May 2009 16:09:44 -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 n4RL9edS024296; Wed, 27 May 2009 16:09:44 -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, 27 May 2009 14:09:43 -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, 27 May 2009 14:09:41 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcneRER4FItykdHYTOej02956/sibgAxn5Bg References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2009 21:09:43.0311 (UTC) FILETIME=[74C179F0:01C9DF0F] Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 May 2009 21:08:06 -0000 Iljitsch, > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tuesday, May 26, 2009 1:55 PM > To: Templin, Fred L > Cc: Behave WG > Subject: Re: [BEHAVE] The fragmentation issue >=20 > On 26 mei 2009, at 20:31, Templin, Fred L wrote: >=20 > > Much of your discussion was too nebulous for me to follow, > > so I'll just say one thing for now. Including a frag hdr > > with (MF=3D0; Offset=3D0) is the IPv6 host's way of telling > > the translator to set DF=3D0; everything else is DF=3D1. >=20 > I explained in the draft and my emails how this introduces PMTUD black > holes, so I don't think this is a valid choice. Let's look at the RFC2460, Section 5 text: "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." All this says is that nodes that restrict themselves to sending packets no larger than 1280 need not follow the MUST/SHOULD/MAY specifications of RFC1981 - it does *not* say that the nodes will never get an ICMP PTB. Indeed, two paragraphs later it says: "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." In other words, originating IPv6 nodes can receive the PTBs *even if they restrict themselves to sending packets no larger than 1280*. This is because the translator has=20 no way of knowing whether the originating node is restricting itself once and for all, or whether it is only sending small packets for the time being and will begin sending larger packets at a later time. In both cases, the originating node needs to receive the PTBs, i.e., as it says in the spec. =20 Fred fred.l.templin@boeing.com From iljitsch@muada.com Wed May 27 14:52: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 992263A6778 for ; Wed, 27 May 2009 14:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 k540ZOvYeQSu for ; Wed, 27 May 2009 14:51:59 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6C23A6BAB for ; Wed, 27 May 2009 14:51:59 -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 n4RLqvmN068307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 May 2009 23:52:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@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 v930.3) Date: Wed, 27 May 2009 23:53:12 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.3) Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 May 2009 21:52:00 -0000 On 27 mei 2009, at 23:09, Templin, Fred L wrote: > All this says is that nodes that restrict themselves to > sending packets no larger than 1280 need not follow the > MUST/SHOULD/MAY specifications of RFC1981 - it does *not* > say that the nodes will never get an ICMP PTB. So what you're saying is that even if a host doesn't implement PMTUD it should still include the fragment header after receiving a "too big". I agree that's a reasonable way to interpret RFC 2460, but I doubt someone who feels the need to omit PMTUD from their implementation will do it that way, because in this case it's still necessary to have state for each destination address in order to know whether to include the fragment header or not. This is exactly what you would want to avoid by not implementing PMTUD. However, all of that is moot in the case where the _operator_ decides to turn off PMTUD by filtering "too big" messages and advertising a 1280-byte MTU on all subnets. Don't forget that today there are networks that filter all ICMP but still set DF = 1. So I'm sure the same thing will happen with IPv6. At least with using a 1280-byte MTU that doesn't cause black holes for IPv6 destinations, but in the RFC 2460/2765 case or the one you suggest this _would_ create PMTUD black holes with IPv6-IPv4 translation. Is there any particular reason why you want to send <= 1280 byte packets with DF = 1? Simply setting DF to 0 for all packets equal to or smaller than 1280 bytes removes the the potential black hole. If the "too bigs" are propagated intact this means the IPv6 hosts can still send packets with a fragment header if they want. (Although I see no point in that in the stateful case as the ID must be rewritten by the translator anyway.) From Fred.L.Templin@boeing.com Wed May 27 15:26: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 30FF03A69DE for ; Wed, 27 May 2009 15:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 G0EsL+QOGKZx for ; Wed, 27 May 2009 15:26: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 3B03C3A6855 for ; Wed, 27 May 2009 15:26:34 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4RMSALq001689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 May 2009 15:28:12 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4RMS9cb009816; Wed, 27 May 2009 15:28:09 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4RMS3q7009463; Wed, 27 May 2009 15:28:09 -0700 (PDT) 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, 27 May 2009 15:28:07 -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, 27 May 2009 15:28:04 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC1290@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcnfFY40QMcfdhL7Swe5JTbsx87pkwAASApA References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 27 May 2009 22:28:07.0682 (UTC) FILETIME=[68C78620:01C9DF1A] Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 27 May 2009 22:26:35 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Wednesday, May 27, 2009 2:53 PM > To: Templin, Fred L > Cc: Behave WG > Subject: Re: [BEHAVE] The fragmentation issue >=20 > On 27 mei 2009, at 23:09, Templin, Fred L wrote: >=20 > > All this says is that nodes that restrict themselves to > > sending packets no larger than 1280 need not follow the > > MUST/SHOULD/MAY specifications of RFC1981 - it does *not* > > say that the nodes will never get an ICMP PTB. >=20 > So what you're saying is that even if a host doesn't implement PMTUD > it should still include the fragment header after receiving a "too > big". I agree that's a reasonable way to interpret RFC 2460, but I > doubt someone who feels the need to omit PMTUD from their > implementation will do it that way, because in this case it's still > necessary to have state for each destination address in order to know > whether to include the fragment header or not. This is exactly what > you would want to avoid by not implementing PMTUD. The RFC4861 destination cache is for more than just tracking the path MTU, and AFAICT it is soft state. The amount of state needed for each destination is just 1-bit - set to 1 if a frag header needs to be included and set to 0 otherwise. > However, all of that is moot in the case where the _operator_ decides > to turn off PMTUD by filtering "too big" messages and advertising a > 1280-byte MTU on all subnets. Don't forget that today there are > networks that filter all ICMP but still set DF =3D 1. So I'm sure the > same thing will happen with IPv6. At least with using a 1280-byte MTU > that doesn't cause black holes for IPv6 destinations, but in the RFC > 2460/2765 case or the one you suggest this _would_ create PMTUD black > holes with IPv6-IPv4 translation. Correct that 1280s will not black-hole for IPv6 destinations. But for IPv4 destinations, the situation is no different whether the source is IPv6 and going through a translator or IPv4 and going through native IPv4 - if the ICMPs are lost, even 1280's can black hole. Plus, let's face it - IPv4 destinations are underprivileged in relation to IPv6 ones. For example, the source has no way of knowing whether an IPv4 destination can even reassemble a packet as large as 1280 (whereas IPv6 destinations are guaranteed to reassemble at least 1500). Similarly, if there is any chance that 1280 packets will fragment the source needs to limit the number of packets it sends so as to avoid RFC4963 issues. If the fragmentation occurs in the network, the source has no way of knowing this (i.e., as far as the source is concerned, if it does not insert a frag header then DF=3D1.) > Is there any particular reason why you want to send <=3D 1280 byte > packets with DF =3D 1? Several: - to avoid RFC4963 issues - to allow IPv6 nodes that prefer to reduce the size of the packets they send to discover an MTU smaller than 1280 - to allow IPv6 nodes to know when they have to insert a fragment header and limit their data rates > Simply setting DF to 0 for all packets equal to > or smaller than 1280 bytes removes the the potential black hole. If > the "too bigs" are propagated intact this means the IPv6 hosts can > still send packets with a fragment header if they want. If DF=3D0, there will be no PTBs coming through the translator. Go-fast hosts run the risk of loss and/or data corruption if they don't realize their packets are being fragmented by the network. Also a matter for concern is the detrimental effect on slow-path router processing when sustained IPv4 fragmentation is taking place in the network. Fred fred.l.templin@boeing.com=20 > (Although I see no point in that in the stateful case as the ID must > be rewritten by the translator anyway.) From iljitsch@muada.com Thu May 28 01:23: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 BCBDD3A67B4 for ; Thu, 28 May 2009 01:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 vPTLvkFcQQqr for ; Thu, 28 May 2009 01:23:30 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 97CDA3A6A06 for ; Thu, 28 May 2009 01:23:30 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4S8OKjQ072104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 May 2009 10:24:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC1290@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 v935.3) Date: Thu, 28 May 2009 10:24:36 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC1290@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 28 May 2009 08:23:38 -0000 On 28 mei 2009, at 0:28, Templin, Fred L wrote: >> I doubt someone who feels the need to omit PMTUD from their >> implementation will do it that way, because in this case it's still >> necessary to have state for each destination address in order to know >> whether to include the fragment header or not. This is exactly what >> you would want to avoid by not implementing PMTUD. > The RFC4861 destination cache is for more than just > tracking the path MTU, and AFAICT it is soft state. > The amount of state needed for each destination is > just 1-bit - set to 1 if a frag header needs to be > included and set to 0 otherwise. Right. But I'm not convinced all non-PMTUD implementations will apply this logic. > Plus, let's face it - IPv4 destinations are underprivileged > in relation to IPv6 ones. For example, the source has no way > of knowing whether an IPv4 destination can even reassemble > a packet as large as 1280 IPv4 hosts that can't reassemble 1280-byte packets have bigger problems... > Similarly, if there > is any chance that 1280 packets will fragment the source > needs to limit the number of packets it sends so as to > avoid issues. If the fragmentation occurs in the > network, the source has no way of knowing this (i.e., as > far as the source is concerned, if it does not insert a > frag header then DF=1.) Well, this is a leap of faith inherent to the IPv6-to-IPv4 translation: with IPv6 you have 32 bits worth of identification so you can send some 16 Mpps before you run into trouble, with the 16-bit identifcation in IPv4 it's only 0.25 kpps, assuming that packets live for ~ 255 seconds. This of course gets much better if you set your reassembly timer to something that reflects today's realities, such as 100 ms. But under what circumstances would an IPv6 client send large amounts of fragments to an IPv4 server? >> Is there any particular reason why you want to send <= 1280 byte >> packets with DF = 1? > Several: > - to avoid RFC4963 issues There is no evidence that the fragment header helps avoid these issues. > - to allow IPv6 nodes that prefer to reduce the size of > the packets they send to discover an MTU smaller than > 1280 If those hosts are configured with an MTU larger than 1280 they will almost certainly send > 1280 packets that will trigger PMTUD anyway, so the chances of a missed PMTUD opportunity are very small even when sending <= 1280 packets with DF = 0. > - to allow IPv6 nodes to know when they have to insert > a fragment header and limit their data rates If we don't rewrite the reported MTU to 1280 then the frag header will still be inserted after a "too big" triggered by a > 1280 packet. I don't think we can reasonably expect applications to limit their sending rate because the < 1280 PMTU indicates the presence of a NAT64. This requires that the application is able to control the sending rate in the first place and some serious API magic to detect the condition, just in case you're behind a NAT64 and the other side you're talking to is misguided enough to use an MTU <= 1280. Even though not illegal, using such a small MTU in IPv4 is completely unnecessary and AFAIK only ever done over dial-up links or links of similar speed. > Also a matter for concern is the detrimental effect > on slow-path router processing when sustained IPv4 > fragmentation is taking place in the network. That's the choice you make when you use a <= 1280 MTU. From Fred.L.Templin@boeing.com Thu May 28 05:33: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 9E7FB3A6DD0 for ; Thu, 28 May 2009 05:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.245 X-Spam-Level: X-Spam-Status: No, score=-6.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 BHeyPTZUOA3a for ; Thu, 28 May 2009 05:33:22 -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 99EA33A6889 for ; Thu, 28 May 2009 05:33:22 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4SCYoYT006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 May 2009 05:34:54 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4SCYo4i009701; Thu, 28 May 2009 05:34:50 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4SCYnbx009694; Thu, 28 May 2009 05:34:50 -0700 (PDT) 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); Thu, 28 May 2009 05:34:49 -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: Thu, 28 May 2009 05:34:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC13C4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcnfbcdHZwVoAlAAQV+2eckRSA0pRwAHzpxg References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC1290@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 28 May 2009 12:34:49.0883 (UTC) FILETIME=[B14036B0:01C9DF90] Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 28 May 2009 12:33:23 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Thursday, May 28, 2009 1:25 AM > To: Templin, Fred L > Cc: Behave WG > Subject: Re: [BEHAVE] The fragmentation issue >=20 > On 28 mei 2009, at 0:28, Templin, Fred L wrote: >=20 > >> I doubt someone who feels the need to omit PMTUD from their > >> implementation will do it that way, because in this case it's still > >> necessary to have state for each destination address in order to know > >> whether to include the fragment header or not. This is exactly what > >> you would want to avoid by not implementing PMTUD. >=20 > > The RFC4861 destination cache is for more than just > > tracking the path MTU, and AFAICT it is soft state. > > The amount of state needed for each destination is > > just 1-bit - set to 1 if a frag header needs to be > > included and set to 0 otherwise. >=20 > Right. But I'm not convinced all non-PMTUD implementations will apply > this logic. I'm just going by what the RFC says - and it says to be on the lookout for PTBs reporting MTUs smaller than 1280. > > Plus, let's face it - IPv4 destinations are underprivileged > > in relation to IPv6 ones. For example, the source has no way > > of knowing whether an IPv4 destination can even reassemble > > a packet as large as 1280 >=20 > IPv4 hosts that can't reassemble 1280-byte packets have bigger > problems... But they don't violate RFC1122. > > Similarly, if there > > is any chance that 1280 packets will fragment the source > > needs to limit the number of packets it sends so as to > > avoid issues. If the fragmentation occurs in the > > network, the source has no way of knowing this (i.e., as > > far as the source is concerned, if it does not insert a > > frag header then DF=3D1.) >=20 > Well, this is a leap of faith inherent to the IPv6-to-IPv4 > translation: with IPv6 you have 32 bits worth of identification so you > can send some 16 Mpps before you run into trouble, with the 16-bit > identifcation in IPv4 it's only 0.25 kpps, assuming that packets live > for ~ 255 seconds. This of course gets much better if you set your > reassembly timer to something that reflects today's realities, such as > 100 ms. >=20 > But under what circumstances would an IPv6 client send large amounts > of fragments to an IPv4 server? Under circumstances that cannot be forseen if we are to have IPv4-only servers and NAT64s as a long-term deployment strategy. That's one reason why IPv4 servers would be well served to also arrange to be accessible via IPv6 - and that does not necessarily mean dual stacked servers. > >> Is there any particular reason why you want to send <=3D 1280 byte > >> packets with DF =3D 1? >=20 > > Several: > > - to avoid RFC4963 issues >=20 > There is no evidence that the fragment header helps avoid these issues. No; inserting the fragment header in itself does not avoid RFC4963 issues. But, the knowledge that it must insert the fragment header lets the host know that it needs to avoid RFC4963 issues. > > - to allow IPv6 nodes that prefer to reduce the size of > > the packets they send to discover an MTU smaller than > > 1280 >=20 > If those hosts are configured with an MTU larger than 1280 they will > almost certainly send > 1280 packets that will trigger PMTUD anyway, > so the chances of a missed PMTUD opportunity are very small even when > sending <=3D 1280 packets with DF =3D 0. I don't think it is possible for us to unambiguously assume this. For instance, USE_MIN_MTU is a socket option available to individual applications and can restrict packet sizes even if the underlying interfaces configure a larger MTU. > > - to allow IPv6 nodes to know when they have to insert > > a fragment header and limit their data rates >=20 > If we don't rewrite the reported MTU to 1280 then the frag header will > still be inserted after a "too big" triggered by a > 1280 packet. I didn't get that... > I don't think we can reasonably expect applications to limit their > sending rate because the < 1280 PMTU indicates the presence of a > NAT64. This requires that the application is able to control the > sending rate in the first place and some serious API magic to detect > the condition, just in case you're behind a NAT64 and the other side > you're talking to is misguided enough to use an MTU <=3D 1280. Sure. That's why reducing the size of the packets it sends may be the preferred option for many hosts. Especially when they know they are talking to an IPv4 host, e.g., when the IPv6 address is formed from a WKP. > Even > though not illegal, using such a small MTU in IPv4 is completely > unnecessary and AFAIK only ever done over dial-up links or links of > similar speed. There is RFC2734, but I'm not sure it is possible to enumerate all examples because IPv4 can run over pretty much everything. > > Also a matter for concern is the detrimental effect > > on slow-path router processing when sustained IPv4 > > fragmentation is taking place in the network. >=20 > That's the choice you make when you use a <=3D 1280 MTU. No; that's the choice you make when you don't reduce the size of the packets you send when there might be a packet shredder in the path. From dwing@cisco.com Thu May 28 17:19: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 B9B133A67F4 for ; Thu, 28 May 2009 17:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.278 X-Spam-Level: X-Spam-Status: No, score=-5.278 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 1EEnETwVCa6t for ; Thu, 28 May 2009 17:19:48 -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 91EB33A67A6 for ; Thu, 28 May 2009 17:19:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,268,1241395200"; d="scan'208";a="312657103" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 May 2009 00:21:32 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4T0LW2k029261; Thu, 28 May 2009 17:21:32 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4T0LVev029398; Fri, 29 May 2009 00:21:31 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> <7AC09AC5-5535-43DD-B2F2-CC2FE8AD44B3@muada.com> Date: Thu, 28 May 2009 17:21:30 -0700 Message-ID: <029c01c9dff3$6a3f2560$c5f0200a@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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcnZ+l/ayHtcSeT/S5CzFcLz6+Di8gANG/DgAXDXM6A= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6736; t=1243556492; x=1244420492; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=ZpD1o2WxuqpmvliQlnfGTVUJKPXsNrRZyzZ7D0R1wqs=; b=l/0Y9WqYWtIDVNbZsl36ch+k/BvxsFwSa2Nq/eLJQTKLrJFtx8dgiYLpm7 qFvMpPOubrZJZUe1gCBcxPQ+5BNuuhHWkxisCQMSvsBxQnQe7pByUcXOSR16 0j6Iu2eAfA; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: behave@ietf.org, 'ext Philip Matthews' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 May 2009 00:19:49 -0000 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: Thursday, May 21, 2009 9:23 AM > To: 'Iljitsch van Beijnum' > Cc: '"'R=E9mi Denis-Courmont'"'; 'behave@ietf.org'; 'ext Philip=20 > Matthews' > Subject: RE: [BEHAVE] FTP64 ALG: how to proceed? >=20 > > >> Using EPSV is hence the *only* valid thing to do. > >=20 > > > It could use PASV. If EPSV fails, and the FTP client knows the > > > IPv6 prefix of its 6/4 translator, the FTP client can send PASV, > > > parse the response, and open an IPv6 socket that will be > > > translated. > >=20 > > In the ftp64 -03 draft there is an even simpler solution:=20 > > clients are =20 > > advised to simply connect to the same address that is the=20 > > destination =20 > > of the control channel connection, and ignore the address=20 > > provided in =20 > > the server's response to the PASV command. > >=20 > > (You wouldn't happen to have correlated the PASV response=20 > > address with =20 > > the control channel address in your big FTP server test, would you?) >=20 > In my tests? No, I didn't check. Should be easy, though -- I > will test that next week. I just finished testing about 2400 FTP servers and all of them did what you expected -- namely, the IPv4 address from the PASV command is the same IPv4 address as the FTP control channel. My very simple-minded script is at ftp://ftpeng.cisco.com/dwing/ftp-epsv/ftp-pasv.pl should anyone want to run their own tests. The list of FTP servers are the ones reported as "PASV: Ok" in ftp://ftpeng.cisco.com/dwing/ftp-epsv/ftp-site-list.log -d > > >> Needless to say, there are FTP client implementations that > > >> do not support IPv6. From my memories, some > > >> send malformatted PASV requests and some simply fail to > > >> establish the control channel in the first place. > >=20 > > > Yep. But those don't work with FTP clients behind IPv4 NATs, > >=20 > > ??? >=20 > What I mean is that an IPv4 FTP client that can't parse the PASV > response, or an IPv4 FTP server that sends an un-parsable PASV > response, is not going to work with most modern clients=20 > (Firefox, IE, etc.) because they default to using PASV because > the client is, more often than not, behind a NAT (coffee shop, > in-home 802.11 NAT box, etc.). >=20 > > If you have an FTP client that uses the old socket API it=20 > can't talk =20 > > over IPv6. So that case is out. >=20 > That could occur in an IPv4 network to IPv6 network scenario.=20 > I agree that, for FTP, we might not want to address place a high=20 > priority on that in the working group. But it could be made to=20 > work. >=20 > > If you have an FTP client that manages to connect over IPv6=20 > > but isn't =20 > > aware of EPSV and EPRT, it would issue a PASV command. The client =20 > > issuing the command wouldn't be a problem, because there are no =20 > > arguments or other IP version specific issues with the _command_. > >=20 > > Only when the server responds there will be trouble. I tried=20 > > this with =20 > > a few IPv6 FTP servers which respond in various ways that=20 > > don't allow =20 > > for setting up the data connection successfully. > >=20 > > However, if the server is behind a NAT64 then the server=20 > will simply =20 > > respond with its IPv4 address, which the client will then parse =20 > > without issue. But then the client needs to connect to an IPv4 =20 > > destination which of course doesn't work in this case. > >=20 > > With IPv4 on both sides and a NAT44 in the middle there are=20 > > no issues, =20 > > the client simply connects to the server-supplied IPv4=20 > address. Only =20 > > with PORT the NAT has to cooperate and allow for the data=20 > connection =20 > > to be set up from the server to the client. >=20 > Yes, "active FTP". >=20 > > > And as you know, it is awkward to reconfigure applications > > > (such as an FTP client or HTTP client) to use > > > different application-level proxies when connecting/disconnecting > > > with different networks (e.g., ftp-proxy.comcast.net, > > > proxy.att.net, ftp-proxy-sj.cisco.com, ftp-proxy.starbucks.com). > >=20 > > There is automatic proxy discovery/configuration and large scale =20 > > proxies have been known to work. >=20 > This gets into the realm of requiring host changes, though. And > there are only defacto standards around this area. >=20 > I have a proxy.pac file in my Firefox configuration (to tunnel=20 > traffic over ssh), but this gets fragile. It doesn't work well > with wget, curl, HTTP clients built into anything shy of a full- > blown, full-featured web browser (IE, Firefox, Safari, Opera), > such as you might find in an IP phone,=20 >=20 > > If the proxy is only used for FTP I =20 > > don't think this is an issue, as only a small fraction of the =20 > > internet's traffic is FTP. > >=20 > > Note that Apache can be an FTP proxy: > >=20 > > http://httpd.apache.org/docs/2.2/mod/mod_proxy_ftp.html > >=20 > > However, it only supports downloads, not uploads, which=20 > brings us to: > >=20 > > On 21 mei 2009, at 1:49, Dan Wing wrote: > >=20 > > >> However, I don't think the browser case is the most relevant > > >> one. Yes, it's important, but basically this is just doing with > > >> FTP what can also happen over HTTP. > >=20 > > > Downloading from anonymous FTP is the most common use of FTP, > > > and we certainly need that to work. > >=20 > > Right, it's important, but it's also easy, you can do this=20 > with the =20 > > Apache proxy if all else fails. > >=20 > > > We have a chicken-and-egg problem: there is still FTP content > > > that needs to be accessible. The FTP64 ALG, like all of > > > the translation being done in BEHAVE, is the 'incubator', so > > > to speak. > >=20 > > Not sure what you mean here... >=20 > That the lack of functioning EPSV support in existing IPv4 FTP=20 > servers is part of the IPv6 transition problem. BEHAVE's job > is to help with the transition. So I was just saying we need > to keep pounding on FTP so it'll work as reliably as today's > IPv4 FTP. >=20 > > >> An important use case of FTP is uploading > > >> files, which browsers can't do with FTP AFAIK. > >=20 > > > I found this cute little Firefox add-on today, > > > http://fireftp.mozdev.org/ > >=20 > > Right. There's also a bunch of Java FTP clients that you can=20 > > run from your browser. > >=20 > > But my point is that we need to look beyond the browser,=20 > because the =20 > > browser in and of itself won't do uploads, and FTP support without =20 > > uploads doesn't make sense. >=20 > Ok. >=20 > -d >=20 >=20 >=20 From iljitsch@muada.com Fri May 29 00:45: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 36E2D3A6E1F for ; Fri, 29 May 2009 00:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 jvdwNzuH3K5v for ; Fri, 29 May 2009 00:45:12 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 061223A68AC for ; Fri, 29 May 2009 00:45:11 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4T7jVtr081093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 May 2009 09:45:31 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Dan Wing" In-Reply-To: <029c01c9dff3$6a3f2560$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 v935.3) Date: Fri, 29 May 2009 09:45:47 +0200 References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> <7AC09AC5-5535-43DD-B2F2-CC2FE8AD44B3@muada.com> <029c01c9dff3$6a3f2560$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 May 2009 07:45:19 -0000 On 29 mei 2009, at 2:21, Dan Wing wrote: >>> (You wouldn't happen to have correlated the PASV response >>> address with the control channel address in your big FTP server >>> test, would you?) > I just finished testing about 2400 FTP servers and all of them > did what you expected -- namely, the IPv4 address from the PASV Excellent. Unless I missed something, it seems nobody is unhappy about what's in the draft now. So what I want to do is see if I can present it to the apps people in Stockholm and see if they will sign off on it, so to speak. From iljitsch@muada.com Fri May 29 01:24: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 870E43A6A97 for ; Fri, 29 May 2009 01:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 lhz5wWBP2Kk1 for ; Fri, 29 May 2009 01:24:16 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 136A03A68A1 for ; Fri, 29 May 2009 01:24:15 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4T8OnJ0081355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 May 2009 10:24:50 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <3D9C56F8-A82F-432E-AA1C-8B54018CD9F1@muada.com> From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC13C4@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 v935.3) Date: Fri, 29 May 2009 10:25:06 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC1290@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC13C4@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 May 2009 08:24:17 -0000 On 28 mei 2009, at 14:34, Templin, Fred L wrote: >> IPv4 hosts that can't reassemble 1280-byte packets have bigger >> problems... > But they don't violate RFC1122. Well, RFC 1122 is from 1989, predating the fast ethernet standard by 6 years. These days I can buy a _computer_ that supports fast ethernet for less than what a 10 Mbps ethernet card cost 20 years ago. So the mere fact that a configuration isn't specifically disallowed by RFC 1122 doesn't mean that it's a reasonable thing to do today. >> But under what circumstances would an IPv6 client send large amounts >> of fragments to an IPv4 server? > Under circumstances that cannot be forseen if we are to have > IPv4-only servers and NAT64s as a long-term deployment > strategy. IF it's a long term deployment strategy (I disagree with that, but deployments don't always follow the initially set out strategy) then part of that strategy would be to rid the IPv4 internet of < 1260 MTUs. People should upgrade to IPv6 to begin with. If they don't do that, we can accommodate them with a NAT64. We can even avoid breakage if they use unreasably small MTUs (to reiterate: there is no valid reason to use an MTU smaller than 1260 with IPv4 for bandwidths higher than 50 kbps [RFC3150]) but protecting against yet unknown circumstances is a bridge too far. > That's one reason why IPv4 servers would be well served to > also arrange to be accessible via IPv6 At least we can agree on that. >> If those hosts are configured with an MTU larger than 1280 they will >> almost certainly send > 1280 packets that will trigger PMTUD anyway, >> so the chances of a missed PMTUD opportunity are very small even when >> sending <= 1280 packets with DF = 0. > I don't think it is possible for us to unambiguously > assume this. For instance, USE_MIN_MTU is a socket > option available to individual applications and can > restrict packet sizes even if the underlying interfaces > configure a larger MTU. I'm more interested in avoiding black holes and keeping the mechanism simple than optimizing for use of an uncommon socket option along with an unreasonably small remote MTU. >> If we don't rewrite the reported MTU to 1280 then the frag header >> will >> still be inserted after a "too big" triggered by a > 1280 packet. > I didn't get that... What I would like to do is set DF = 0 for packets smaller than 1280 translated to IPv4 and DF = 1 for packets larger than 1280. Since we need to create a new ID value in the stateful case anyway and we don't need the fragment header to make the DF 0/1 decision in this case, I would then simply rewrite the MTU in the "too big" message to 1280 during translation if it reported an MTU smaller than than on the IPv4 side. So: an IPv4 host with MTU=576 sends a "too big", translator turns this into "too big, use 1280", the IPv6 host will start sending 1280-byte packets, the translator translates those to IPv4 with DF = 0, packets are fragmented by a router somewhere between the translator and the IPv4 host. So that's what I would like. But what I suggested above was to change the rewriting of the "too big" message, and then the following would happen, depending on the host implementation: Case A: IPv4 host with MTU=576 sends a "too big", translator turns this into "too big, use 596", the IPv6 host will start sending 596- byte packets, the translator translates those to IPv4 with DF = 0, packets are NOT fragmented because on the IPv4 side, they're 576 bytes. Case B: IPv4 host with MTU=576 sends a "too big", translator turns this into "too big, use 596", the IPv6 host will start sending 1280- byte packets with a fragment header, the translator translates those to IPv4 with DF = 0, packets are fragmented by a router somewhere between the translator and the IPv4 host. (Note that if the host announces a 536 TCP MSS all of this is moot for TCP, but if the host can handle a normal MTU and there is a 576 MTU link in the middle we get fragments for TCP, which is bad news re high speed/ID issues. However, this should be rare in practice because people use MSS clamping to be able to talk to people who filter ICMP.) >> Even >> though not illegal, using such a small MTU in IPv4 is completely >> unnecessary and AFAIK only ever done over dial-up links or links of >> similar speed. > There is RFC2734 That's IPv4 over firewire (RFC 3146 is IPv6 over firewire). This specification is a bit nebulous, but upon careful reading you will see that is specifies that IP packets are fragmented at the link layer and then reassembled at the other end so that IP packets larger than 512 bytes can be supported even when running at 100 Mbps (firewire link MTU depends on the operating speed). This is also why I never had any trouble communicating between my FW400 and FW800 Macs even though the former had a ~2k MTU and the latter a ~4k one. (However, for over a year now Apple has had a bug where IPv6 packets larger than 2k received over firewire are silently ignored.) From Fred.L.Templin@boeing.com Fri May 29 07:28: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 56EEC3A6B60 for ; Fri, 29 May 2009 07:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 d7bHvqKYzEGg for ; Fri, 29 May 2009 07:28: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 F149D3A6B24 for ; Fri, 29 May 2009 07:28:07 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4TE5GkE011931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2009 07:05:16 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4TE5GTO022410; Fri, 29 May 2009 07:05:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4TE5F4C022392; Fri, 29 May 2009 07:05:15 -0700 (PDT) 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); Fri, 29 May 2009 07:05:15 -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: Fri, 29 May 2009 07:05:14 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105FC1A1F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <3D9C56F8-A82F-432E-AA1C-8B54018CD9F1@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] The fragmentation issue Thread-Index: AcngNv/TzfbCS/6QQWGT4GEviJR9owALji5g References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC1290@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC13C4@XCH-NW-7V2.nw.nos.boeing.com> <3D9C56F8-A82F-432E-AA1C-8B54018CD9F1@muada.com> From: "Templin, Fred L" To: "Iljitsch van Beijnum" X-OriginalArrivalTime: 29 May 2009 14:05:15.0980 (UTC) FILETIME=[7DDEA8C0:01C9E066] Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 May 2009 14:28:09 -0000 Iljitsch, It is good that we agree on IPv6 deployment. Also, I don't know how common it is today but NAT rewriting of the IP ID is suggested in the Bellovin paper and for all I know may be enabled in shipping products (are there any references on this?). The setting of DF is where we still disagree - having the NAT64 decide that on its own is asking it to know the mind of the host, and may result in behavior that is not at all what the host intended. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Friday, May 29, 2009 1:25 AM > To: Templin, Fred L > Cc: Behave WG > Subject: Re: [BEHAVE] The fragmentation issue >=20 > On 28 mei 2009, at 14:34, Templin, Fred L wrote: >=20 > >> IPv4 hosts that can't reassemble 1280-byte packets have bigger > >> problems... >=20 > > But they don't violate RFC1122. >=20 > Well, RFC 1122 is from 1989, predating the fast ethernet standard by 6 > years. These days I can buy a _computer_ that supports fast ethernet > for less than what a 10 Mbps ethernet card cost 20 years ago. So the > mere fact that a configuration isn't specifically disallowed by RFC > 1122 doesn't mean that it's a reasonable thing to do today. >=20 > >> But under what circumstances would an IPv6 client send large amounts > >> of fragments to an IPv4 server? >=20 > > Under circumstances that cannot be forseen if we are to have > > IPv4-only servers and NAT64s as a long-term deployment > > strategy. >=20 > IF it's a long term deployment strategy (I disagree with that, but > deployments don't always follow the initially set out strategy) then > part of that strategy would be to rid the IPv4 internet of < 1260 > MTUs. People should upgrade to IPv6 to begin with. If they don't do > that, we can accommodate them with a NAT64. We can even avoid breakage > if they use unreasably small MTUs (to reiterate: there is no valid > reason to use an MTU smaller than 1260 with IPv4 for bandwidths higher > than 50 kbps [RFC3150]) but protecting against yet unknown > circumstances is a bridge too far. >=20 > > That's one reason why IPv4 servers would be well served to > > also arrange to be accessible via IPv6 >=20 > At least we can agree on that. >=20 > >> If those hosts are configured with an MTU larger than 1280 they will > >> almost certainly send > 1280 packets that will trigger PMTUD anyway, > >> so the chances of a missed PMTUD opportunity are very small even when > >> sending <=3D 1280 packets with DF =3D 0. >=20 > > I don't think it is possible for us to unambiguously > > assume this. For instance, USE_MIN_MTU is a socket > > option available to individual applications and can > > restrict packet sizes even if the underlying interfaces > > configure a larger MTU. >=20 > I'm more interested in avoiding black holes and keeping the mechanism > simple than optimizing for use of an uncommon socket option along with > an unreasonably small remote MTU. >=20 > >> If we don't rewrite the reported MTU to 1280 then the frag header > >> will > >> still be inserted after a "too big" triggered by a > 1280 packet. >=20 > > I didn't get that... >=20 > What I would like to do is set DF =3D 0 for packets smaller than 1280 > translated to IPv4 and DF =3D 1 for packets larger than 1280. Since we > need to create a new ID value in the stateful case anyway and we don't > need the fragment header to make the DF 0/1 decision in this case, I > would then simply rewrite the MTU in the "too big" message to 1280 > during translation if it reported an MTU smaller than than on the IPv4 > side. >=20 > So: an IPv4 host with MTU=3D576 sends a "too big", translator turns = this > into "too big, use 1280", the IPv6 host will start sending 1280-byte > packets, the translator translates those to IPv4 with DF =3D 0, = packets > are fragmented by a router somewhere between the translator and the > IPv4 host. >=20 > So that's what I would like. But what I suggested above was to change > the rewriting of the "too big" message, and then the following would > happen, depending on the host implementation: >=20 > Case A: IPv4 host with MTU=3D576 sends a "too big", translator turns > this into "too big, use 596", the IPv6 host will start sending 596- > byte packets, the translator translates those to IPv4 with DF =3D 0, > packets are NOT fragmented because on the IPv4 side, they're 576 bytes. >=20 > Case B: IPv4 host with MTU=3D576 sends a "too big", translator turns > this into "too big, use 596", the IPv6 host will start sending 1280- > byte packets with a fragment header, the translator translates those > to IPv4 with DF =3D 0, packets are fragmented by a router somewhere > between the translator and the IPv4 host. >=20 > (Note that if the host announces a 536 TCP MSS all of this is moot for > TCP, but if the host can handle a normal MTU and there is a 576 MTU > link in the middle we get fragments for TCP, which is bad news re high > speed/ID issues. However, this should be rare in practice because > people use MSS clamping to be able to talk to people who filter ICMP.) >=20 > >> Even > >> though not illegal, using such a small MTU in IPv4 is completely > >> unnecessary and AFAIK only ever done over dial-up links or links of > >> similar speed. >=20 > > There is RFC2734 >=20 > That's IPv4 over firewire (RFC 3146 is IPv6 over firewire). This > specification is a bit nebulous, but upon careful reading you will see > that is specifies that IP packets are fragmented at the link layer and > then reassembled at the other end so that IP packets larger than 512 > bytes can be supported even when running at 100 Mbps (firewire link > MTU depends on the operating speed). This is also why I never had any > trouble communicating between my FW400 and FW800 Macs even though the > former had a ~2k MTU and the latter a ~4k one. (However, for over a > year now Apple has had a bug where IPv6 packets larger than 2k > received over firewire are silently ignored.) From dwing@cisco.com Fri May 29 08:33: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 056FF3A6A3C for ; Fri, 29 May 2009 08:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 4uHnViP7pDYg for ; Fri, 29 May 2009 08:33:51 -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 284E53A6906 for ; Fri, 29 May 2009 08:33:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,272,1241395200"; d="scan'208";a="192002220" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 May 2009 15:31:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4TFViVY027986; Fri, 29 May 2009 08:31:44 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4TFVit8006911; Fri, 29 May 2009 15:31:44 GMT From: "Dan Wing" To: "'Iljitsch van Beijnum'" References: <1CEC538C-1A1B-49C6-B6FF-41D8B64EAE9A@muada.com> <006101c9cf56$e965cdb0$c5f0200a@cisco.com> <200905201607.44927.remi.denis-courmont@nokia.com> <025e01c9d9a5$9e58f0f0$c5f0200a@cisco.com> <7AC09AC5-5535-43DD-B2F2-CC2FE8AD44B3@muada.com> <029c01c9dff3$6a3f2560$c5f0200a@cisco.com> Date: Fri, 29 May 2009 08:31:44 -0700 Message-ID: <03c601c9e072$92790cb0$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcngMYxh+ney2nNbQkGolkT6Y8nndwAQPqTw DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=653; t=1243611104; x=1244475104; 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]=20FTP64=20ALG=3A=20how=20to=20 proceed? |Sender:=20; bh=1xHzp8yoMl8MiMbaYhILhX3wyVeW03sLnhWJ2wytq2U=; b=LN0tv+t92jaLEfTSN9b0gF6whcfnSYDmzpiYKP2YxMrd5LHXPuSQx0FLzl lDQJ6WT85Ohcv4fxgiUOOGCltt+R2xI9BqJs4ecZcgrp4EBHqWFZ6DFbzU/3 BRbwnZvbNM; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Behave WG' Subject: Re: [BEHAVE] FTP64 ALG: how to proceed? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 May 2009 15:33:52 -0000 > On 29 mei 2009, at 2:21, Dan Wing wrote: > > >>> (You wouldn't happen to have correlated the PASV response > >>> address with the control channel address in your big FTP server > >>> test, would you?) > > > I just finished testing about 2400 FTP servers and all of them > > did what you expected -- namely, the IPv4 address from the PASV > > Excellent. > > Unless I missed something, it seems nobody is unhappy about > what's in > the draft now. So what I want to do is see if I can present > it to the > apps people in Stockholm and see if they will sign off on it, so to > speak. That is a reasonable plan. -d From iljitsch@muada.com Fri May 29 09:35: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 F3CE63A68D0 for ; Fri, 29 May 2009 09:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 f2UbjlLkrqN6 for ; Fri, 29 May 2009 09:35:20 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id F0BA83A67F7 for ; Fri, 29 May 2009 09:35:19 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.52]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n4TGYfuj088468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 May 2009 18:34:42 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <81C23463-3132-465D-9150-5B3BBF9F2150@muada.com> From: Iljitsch van Beijnum To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105FC1A1F@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 v935.3) Date: Fri, 29 May 2009 18:34:58 +0200 References: <20090521140024.37C1B28C0DE@core3.amsl.com> <166F3D15-ECB1-40EB-B1D4-181AF51D53A3@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F446BB@XCH-NW-7V2.nw.nos.boeing.com> <17E64193-B6FB-4A1C-9742-7E162BE2AD7C@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81A9B@XCH-NW-7V2.nw.nos.boeing.com> <89A983FE-1494-46D3-9DDC-327B2648994B@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105F81E9E@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC11F7@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC1290@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC13C4@XCH-NW-7V2.nw.nos.boeing.com> <3D9C56F8-A82F-432E-AA1C-8B54018CD9F1@muada.com> <39C363776A4E8C4A94691D2BD9D1C9A105FC1A1F@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] The fragmentation issue X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 29 May 2009 16:35:21 -0000 On 29 mei 2009, at 16:05, Templin, Fred L wrote: > The setting of DF is where we still disagree - having the > NAT64 decide that on its own is asking it to know the mind > of the host, and may result in behavior that is not at all > what the host intended. If the IPv4 host has that infamous 576 MTU and the IPv6 host reduces its packets to 576 after the too big, then everything is ok, right? (Although there could be a corner case where afteer that 576 link there is a 296 link...) From dthaler@windows.microsoft.com Fri May 29 18: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 CEFE93A6FFA for ; Fri, 29 May 2009 18:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3rAeTf-dSRx2 for ; Fri, 29 May 2009 18:53:37 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id A16F13A69BD for ; Fri, 29 May 2009 18:53:37 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 29 May 2009 18:55:21 -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.582.9; Fri, 29 May 2009 18:55:21 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.224]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 29 May 2009 18:55:33 -0700 From: Dave Thaler To: Gabor Bajko Thread-Topic: [BEHAVE] Question on DNS64 Thread-Index: AQHJ297O4CGOyOgqaUWVySC8CIrY5ZAt2hBw Date: Sat, 30 May 2009 01:55:14 +0000 Message-ID: References: <001401c9ce30$9105ac70$5e0c6f0a@china.huawei.com><4A018B03.6070601@free.fr><495c4ae90905090400w6443839qa271fc3837bf8e33@mail.gmail.com><4A098864.3060702@free.fr><495c4ae90905130346n7fa84708hb746f30110b9cf84@mail.gmail.com><4A13D3B7.10407@free.fr> <20090522140347.GA20641@river.styx.org> <007201c9dbde$8093ead0$6400a8c0@NOE.Nokia.com> In-Reply-To: <007201c9dbde$8093ead0$6400a8c0@NOE.Nokia.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] Question on DNS64 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 01:53:39 -0000 Gabor Bajko wrote: > I have a terminology question regarding the above draft: > The draft uses the 'IPv6-only client' and 'IPv4-only server' > terminologies, > and it was not immediately clear to me what they mean, as they are not > defined in the terminology section. > > I found though this text in section 1: " ... a lot of IPv6-only clients > will > want > to connect to IPv4-only servers. These include hosts running IPv6- > only applications, IPv6-only hosts as well as the cases where only > IPv6-only connectivity is available between the client and the > NAT64." > > I wonder if a similar description would be valid for the 'IPv4-only > server', > ie 'a server running IPv4 applications, IPv4-only servers as well as > the > cases where only IPv4 connectivity is available between the server and > the > NAT64' (I regard a server not a fixed node, any mobile node can become > a > server, eg when hosts services). Yes. > When I have a dual stack node running IPv4 only applications but > provisioned > with IPv6 address only, would that classify it as an 'IPv6-only client' > in > this context? No, it would classify as a "nothing" client, since that application has neither IPv4 nor IPv6 connectivity (unless you have some translation scheme in the host like BIS or BIA as I mentioned in my presentation at the interim meeting: ftp://ftpeng.cisco.com/dwing/behave/TranslationInHost.pdf ) > Similarly, when I have a dual stack server, running only IPv6 > applications, > but attached to a network where it can only get an IPv4 address, would > the > node become an 'IPv4-only server' in this context? No, it'd be a "nothing" server, unless you have some translation scheme in the host such as AF_INET6 sockets with v4-mapped addresses. -Dave From dthaler@windows.microsoft.com Fri May 29 19: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 CD5403A6A09 for ; Fri, 29 May 2009 19:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VGk7ad6Fvz+w for ; Fri, 29 May 2009 19:01:38 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1EDAF28C103 for ; Fri, 29 May 2009 19:01:22 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 29 May 2009 19:03:06 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.582.9; Fri, 29 May 2009 19:03:06 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.224]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Fri, 29 May 2009 19:03:17 -0700 From: Dave Thaler To: marcelo bagnulo braun , Xing Li Thread-Topic: [BEHAVE] interim meeting minutes Thread-Index: AcnZtDJE+MQl9mz1RauCnQXcDoCEPAAg15IAAAF4jYAADJHCgAGWhG2g Date: Sat, 30 May 2009 02:03:00 +0000 Message-ID: References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> In-Reply-To: <4A1587AF.9080608@it.uc3m.es> 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: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 02:01:38 -0000 TWFyY2VsbyBCYWdudWxvIHdyb3RlOg0KPiBYaW5nIExpIGVzY3JpYmnDszoNCj4gPiBJbGppdHNj aCB2YW4gQmVpam51bSDlhpnpgZM6DQo+ID4+IEFib3V0IHRoZSB0ZXJtaW5vbG9neToNCj4gPj4N Cj4gPj4gSSBzdWdnZXN0IE5BVDY0IGZvciBzdGF0ZWZ1bCBhbmQgVFJBTlM2NCBmb3Igc3RhdGVs ZXNzLiAoQW5kIE5BVDQ0LA0KPiA+PiBOQVQ0NiwgTkFUNjYgYXMgd2VsbCBhcyBUUkFOUzQ2LiBN YXliZSBldmVuIE5BVDQ2NCBpZiB3ZSBuZWVkIGl0IHRvDQo+ID4+IGF2b2lkIE5BVDQ0NCBidXQg cGxlYXNlIG5vIE5BVDY0Ni4pDQo+ID4NCj4gPiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBzdGF0 ZWxlc3Mgc2NoZW1lIChJVkkpIHN1cHBvcnRzIGJvdGggVFJBTlM0Ng0KPiA+IGFuZCBUUkFOUzY0 LCBob3cgdG8gbmFtZSBpdD8NCj4NCj4gc3RhdGVsZXNzIHRyYW5zbGF0b3I/DQoNClByb3Bvc2Fs Og0KLS0tLS0tLS0tDQpHZW5lcmljIHRlcm0sIGluZGVwZW5kZW50IG9mIGRpcmVjdGlvbjogSVB2 Ni9JUHY0IHRyYW5zbGF0b3IgKG9yIHRyYW5zbGF0aW9uKQ0KDQpXaGVuIHlvdSBjYXJlIGFib3V0 IGluaXRpYXRpb24gZnJvbSBhIHNwZWNpZmljIGRpcmVjdGlvbiwNCmJ1dCBpbmRlcGVuZGVudCBv ZiBzdGF0ZWZ1bCB2cyBzdGF0ZWxlc3M6IE5BVDY0LCBOQVQ0Ng0KDQpXaGVuIHlvdSBjYXJlIGFi b3V0IHN0YXRlZnVsIHZzIHN0YXRlbGVzcywgYWRkICJzdGF0ZWZ1bCIgb3IgInN0YXRlbGVzcyIN CnRvIG9uZSBvZiB0aGUgYWJvdmUgdGVybXMuDQoNClNvIHRoZSBzdGF0ZWxlc3Mgc2NoZW1lIHRo YXQgc3VwcG9ydHMgYm90aCBkaXJlY3Rpb25zIHdvdWxkIGJlDQoic3RhdGVsZXNzIElQdjYvSVB2 NCB0cmFuc2xhdGlvbiIuDQooVGhlIGZhY3QgdGhhdCB0aGlzIGhhcHBlbnMgdG8gaGF2ZSB0aGUg c2FtZSBhY3JvbnltIGFzIFNJSVQgaXMNCmFyZ3VhYmx5IGEgZmVhdHVyZS4pDQoNCi1EYXZlDQoN Cg== From brian.e.carpenter@gmail.com Fri May 29 23:42: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 BBD0A3A6B18 for ; Fri, 29 May 2009 23:42:10 -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 gN8EpBp2ltIH for ; Fri, 29 May 2009 23:42:10 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 077093A69E2 for ; Fri, 29 May 2009 23:42:10 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id g37so1751557rvb.49 for ; Fri, 29 May 2009 23:43:52 -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=rm25/v/Aoq/uPPaboLX6XhdtLe4gF8a230BGIF0YzkU=; b=DoL2/A3K411zdLSD/7PNynyjCBfIzRDeh32/VEE4uzspI2B3Y02boSyUKJCKlbNhl2 QT6kL6rg8XANAXlvO/7dZBCJNDLau4EcMOqzPRV+xqOUIPU7pubSHL5qTPQEzQNyyejE fkx+SlZBHeIb7UwatH5axU/nrMhZUcwS898+k= 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=pqDN1SAqKm5xynB6lF95X2DM/yMT8NIbLIog1KV0D7tPh+wSl+0oVjDKPVEYbq+uCi miPewttu86bhYYD6VeAwx9zlNy6RIWcK3VCFSpCVJqR12tPrDkMlh8Lz9qNEC2V/vUps 3Y5TXhAqpKkuKHcHLub2oqs5+eXet3IyaBs/o= Received: by 10.141.113.3 with SMTP id q3mr2248679rvm.82.1243665832698; Fri, 29 May 2009 23:43:52 -0700 (PDT) Received: from ?192.168.1.65? (host81-151-18-115.range81-151.btcentralplus.com [81.151.18.115]) by mx.google.com with ESMTPS id c20sm6612684rvf.10.2009.05.29.23.43.50 (version=SSLv3 cipher=RC4-MD5); Fri, 29 May 2009 23:43:51 -0700 (PDT) Message-ID: <4A20D59B.9010009@gmail.com> Date: Sat, 30 May 2009 07:43:39 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'Behave WG' , Xing Li , Dan Wing Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 06:42:10 -0000 On 2009-05-30 03:03, Dave Thaler wrote: > Marcelo Bagnulo wrote: >> Xing Li escribi=C3=B3: >>> Iljitsch van Beijnum =E5=86=99=E9=81=93: >>>> About the terminology: >>>> >>>> I suggest NAT64 for stateful and TRANS64 for stateless. (And NAT44, >>>> NAT46, NAT66 as well as TRANS46. Maybe even NAT464 if we need it to >>>> avoid NAT444 but please no NAT646.) >>> The problem is that the stateless scheme (IVI) supports both TRANS46 >>> and TRANS64, how to name it? >> stateless translator? >=20 > Proposal: > --------- > Generic term, independent of direction: IPv6/IPv4 translator (or transl= ation) >=20 > When you care about initiation from a specific direction, > but independent of stateful vs stateless: NAT64, NAT46 Maybe we need a standard set of terminology definitions to be cited by relevant documents. As in NAT64: Bidirectional packet translation between IPv4 and IPv6, initiated by an IPv6 host, which may be stateful or stateless. etc. >=20 > When you care about stateful vs stateless, add "stateful" or "stateless= " > to one of the above terms. Yes. In general, I think it's better to avoid creating a large family of acronyms with subtle differences in meaning. Brian >=20 > So the stateless scheme that supports both directions would be > "stateless IPv6/IPv4 translation". > (The fact that this happens to have the same acronym as SIIT is > arguably a feature.) >=20 > -Dave From xing@cernet.edu.cn Sat May 30 02: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 59F543A67EE for ; Sat, 30 May 2009 02:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.125 X-Spam-Level: X-Spam-Status: No, score=0.125 tagged_above=-999 required=5 tests=[AWL=0.028, 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 5TuJNW1wcgOg for ; Sat, 30 May 2009 02:17:22 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id DAD293A6F1E for ; Sat, 30 May 2009 02:17:21 -0700 (PDT) Received: from [127.0.0.1]([123.112.88.57]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm04a216062; Sat, 30 May 2009 17:18:48 +0800 Message-ID: <4A20F9EC.1030205@cernet.edu.cn> Date: Sat, 30 May 2009 17:18:36 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> In-Reply-To: <4A1587AF.9080608@it.uc3m.es> 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: sSQiUKWB Cc: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 09:17:23 -0000 marcelo bagnulo braun 写é“: > Xing Li escribió: >> >> >> Iljitsch van Beijnum 写é“: >>> About the terminology: >>> >>> I suggest NAT64 for stateful and TRANS64 for stateless. (And NAT44, >>> NAT46, NAT66 as well as TRANS46. Maybe even NAT464 if we need it to >>> avoid NAT444 but please no NAT646.) >>> >> >> The problem is that the stateless scheme (IVI) supports both TRANS46 >> and TRANS64, how to name it? >> > > stateless translator? sounds fine. xing From remi.despres@free.fr Sat May 30 02:22: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 02FE23A6F1E for ; Sat, 30 May 2009 02:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=0.312, 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 QiCOQNVbNBu1 for ; Sat, 30 May 2009 02:22:36 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 26BF53A6EBE for ; Sat, 30 May 2009 02:22:34 -0700 (PDT) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id BE9024C80F2; Sat, 30 May 2009 11:24:13 +0200 (CEST) Received: from [192.168.0.12] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g21.free.fr (Postfix) with ESMTP id 120944C80E1; Sat, 30 May 2009 11:24:09 +0200 (CEST) In-Reply-To: <4A20D59B.9010009@gmail.com> References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> <4A20D59B.9010009@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <325B79F2-92EE-42B6-9D16-C6B8080D4964@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Sat, 30 May 2009 11:24:07 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.753.1) Cc: Xing Li , 'Behave WG' , Dan Wing , Dave Thaler Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 09:22:37 -0000 Le 30 mai 09 =E0 08:43, Brian E Carpenter a =E9crit : > NAT64: Bidirectional packet translation between IPv4 and IPv6, =20 > initiated > by an IPv6 host, which may be stateful or stateless. +1 for this definition. In IPv4, NAT (implicitly NAT44) means bidirectional packet =20 translation between IPv4 and IPv4, initiated by an IPv4 host, which =20 may be stateful or stateless. RD= From xing@cernet.edu.cn Sat May 30 02:24: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 CB91D3A6F0D for ; Sat, 30 May 2009 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[AWL=0.026, 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 PAIusEiNV5NL for ; Sat, 30 May 2009 02:24:45 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 522673A6EBE for ; Sat, 30 May 2009 02:24:44 -0700 (PDT) Received: from [127.0.0.1]([123.112.88.57]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54a21620b; Sat, 30 May 2009 17:25:53 +0800 Message-ID: <4A20FB9F.5050105@cernet.edu.cn> Date: Sat, 30 May 2009 17:25:51 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dave Thaler References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> 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: sdHpUKWB Cc: 'Behave WG' , Dan Wing Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 09:24:45 -0000 Dave Thaler 写é“: > Marcelo Bagnulo wrote: > >> Xing Li escribió: >> >>> Iljitsch van Beijnum 写é“: >>> >>>> About the terminology: >>>> >>>> I suggest NAT64 for stateful and TRANS64 for stateless. (And NAT44, >>>> NAT46, NAT66 as well as TRANS46. Maybe even NAT464 if we need it to >>>> avoid NAT444 but please no NAT646.) >>>> >>> The problem is that the stateless scheme (IVI) supports both TRANS46 >>> and TRANS64, how to name it? >>> >> stateless translator? >> > > Proposal: > --------- > Generic term, independent of direction: IPv6/IPv4 translator (or translation) > agree. > When you care about initiation from a specific direction, > but independent of stateful vs stateless: NAT64, NAT46 > > When you care about stateful vs stateless, add "stateful" or "stateless" > to one of the above terms. > > So the stateless scheme that supports both directions would be > "stateless IPv6/IPv4 translation". > (The fact that this happens to have the same acronym as SIIT is > arguably a feature.) > agree. however, there may be too many names and not organized in a systematic way. stateless IPv4/IPv6 translation (46 and 64) NAT64 (stateful and stateless) NAT46 (stateful and stateless) xing > -Dave > > From iljitsch@muada.com Sat May 30 02:42: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 B512C3A6C8E for ; Sat, 30 May 2009 02:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 ohWk1KT3OZJx for ; Sat, 30 May 2009 02:42:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id C2C253A6A1A for ; Sat, 30 May 2009 02:42:30 -0700 (PDT) Received: from [192.168.2.4] (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 n4U9hSIf098928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 May 2009 11:43:29 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <37960EC4-AF9C-44DD-B61A-F6C5D38EDBF0@muada.com> From: Iljitsch van Beijnum To: Xing Li In-Reply-To: <4A20FB9F.5050105@cernet.edu.cn> 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: Sat, 30 May 2009 11:43:45 +0200 References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> <4A20FB9F.5050105@cernet.edu.cn> X-Mailer: Apple Mail (2.935.3) Cc: Behave WG Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 09:42:31 -0000 On 30 mei 2009, at 11:25, Xing Li wrote: > NAT64 (stateful and stateless) > NAT46 (stateful and stateless) In the stateless case NAT64 and NAT46 are the same. I would prefer to keep "NAT" for stateful unless specifically indicated that it's stateless. We could keep SIIT for stateless translation. From remi.despres@free.fr Sat May 30 07: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 ACE223A6A8E for ; Sat, 30 May 2009 07:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.413 X-Spam-Level: * X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_50=0.001, 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 M4cFY5ynRjFq for ; Sat, 30 May 2009 07:57:26 -0700 (PDT) Received: from smtp2a.orange.fr (smtp2a.orange.fr [80.12.242.140]) by core3.amsl.com (Postfix) with ESMTP id E484E3A69DB for ; Sat, 30 May 2009 07:57:25 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2a16.orange.fr (SMTP Server) with ESMTP id 7C0E680000B5; Sat, 30 May 2009 16:59:09 +0200 (CEST) Received: from [193.248.112.82] (Mix-Lille-207-1-82.w193-248.abo.wanadoo.fr [193.248.112.82]) by mwinf2a16.orange.fr (SMTP Server) with ESMTP id 3ABF780000A8; Sat, 30 May 2009 16:59:08 +0200 (CEST) X-ME-UUID: 20090530145908240.3ABF780000A8@mwinf2a16.orange.fr In-Reply-To: <4A20FB9F.5050105@cernet.edu.cn> References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> <4A20FB9F.5050105@cernet.edu.cn> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <72F5D0A3-D818-43D7-A09E-7BC939A9E326@free.fr> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Date: Sat, 30 May 2009 16:59:05 +0200 To: Xing Li X-Mailer: Apple Mail (2.753.1) Cc: 'Behave WG' , Dan Wing , Dave Thaler Subject: Re: [BEHAVE] interim meeting minutes - NAT64 definition X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 14:57:26 -0000 Le 30 mai 09 =E0 11:25, Xing Li a =E9crit : > > however, there may be too many names and not organized in a =20 > systematic way. > > stateless IPv4/IPv6 translation (46 and 64) > NAT64 (stateful and stateless) > NAT46 (stateful and stateless) Brian proposed (and I suported): "NAT64: Bidirectional packet =20 translation between IPv4 and IPv6, initiated by an IPv6 host, which may be stateful or stateless." But, right, there is the problem of NAT64 and NAT46 being the same if =20= stateless. A slightly better definition can solve the problem: "NATxy: Bidirectional packet translation between IPVx and IPVy, in =20 which the global Internet side (external side) is IPVy, in which the =20 other side (internal side) is IPVx, and which may be stateful or =20 stateless." SIITxy (stateless) , and NAPTxy (stateful) can then be defined =20 similarly. Would this, or something similar, be acceptable? RD From marc.blanchet@viagenie.ca Sat May 30 08:08: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 AF5CC3A682A for ; Sat, 30 May 2009 08:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.186 X-Spam-Level: X-Spam-Status: No, score=-0.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 CXxsH8+qUFls for ; Sat, 30 May 2009 08:08:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id BB0B93A6963 for ; Sat, 30 May 2009 08:08:01 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 217FC29E15BE; Sat, 30 May 2009 11:09:46 -0400 (EDT) Message-ID: <4A214C39.5040105@viagenie.ca> Date: Sat, 30 May 2009 11:09:45 -0400 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "behave@ietf.org" X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] terminology X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 15:08:02 -0000 - to move out of the NAT overloaded term, here is another suggestion for names: - Translation of Address Family (TAF): add (6,4) and SL or SF (stateless or stateful). TAF64-SL ... just an idea. Marc. -- ========= 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 marcelo@it.uc3m.es Sat May 30 08:13: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 0A1F03A6BDE for ; Sat, 30 May 2009 08:13:15 -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.081, 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 opN9+LKNT-Md for ; Sat, 30 May 2009 08:13:14 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 235EF3A6A62 for ; Sat, 30 May 2009 08:13:13 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (209.pool85-53-142.dynamic.orange.es [85.53.142.209]) by smtp02.uc3m.es (Postfix) with ESMTP id 852716C1BD4; Sat, 30 May 2009 17:14:51 +0200 (CEST) Message-ID: <4A214D69.7050407@it.uc3m.es> Date: Sat, 30 May 2009 17:14:49 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> <4A20FB9F.5050105@cernet.edu.cn> <72F5D0A3-D818-43D7-A09E-7BC939A9E326@free.fr> In-Reply-To: <72F5D0A3-D818-43D7-A09E-7BC939A9E326@free.fr> 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-16674.000 Cc: 'Behave WG' , Xing Li , Dan Wing , Dave Thaler Subject: Re: [BEHAVE] interim meeting minutes - NAT64 definition X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2009 15:13:15 -0000 I personally think that the common understanding of the word NAT todya is a device that is statefull and translates not only addresses but also ports. for that reason, i believe that using the expression NAT64 and NAT46 highlight the main difference with current NATs, i.e. that they translate IPv6 to and from IPv4 and in the case of 64 they support communications iniciated from the IPv6 side and in the case of 46 they support communications initiated from the IPv4 side. I think that the stateless translator is a very different device from the most common version of IPv4 nats, since they are stateless, so i think it makes sense to name it with a different name that highlights the fact that they are stateless. I think SIIT, stateless translator, even stateless IPv4/IPv6 translators make sense. I also think that we need to have a short name for these things, in particular, i think we need an acronym, rather than a phrase. So, i would go for: Long name: stateless IPv4/IPv6 translation, short name SIIT Long name: Stateful NAT64, short name NAT64 Long name: Stateful NAT46, short name NAT46 Regards, marcelo Rémi Després escribió: > > Le 30 mai 09 à 11:25, Xing Li a écrit : >> >> however, there may be too many names and not organized in a >> systematic way. >> >> stateless IPv4/IPv6 translation (46 and 64) >> NAT64 (stateful and stateless) >> NAT46 (stateful and stateless) > > Brian proposed (and I suported): "NAT64: Bidirectional packet > translation between IPv4 and IPv6, initiated > by an IPv6 host, which may be stateful or stateless." > > But, right, there is the problem of NAT64 and NAT46 being the same if > stateless. > > A slightly better definition can solve the problem: > "NATxy: Bidirectional packet translation between IPVx and IPVy, in > which the global Internet side (external side) is IPVy, in which the > other side (internal side) is IPVx, and which may be stateful or > stateless." > > SIITxy (stateless) , and NAPTxy (stateful) can then be defined > similarly. > > Would this, or something similar, be acceptable? > > RD > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From xing@cernet.edu.cn Sun May 31 23:06: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 85C4A3A6C0E for ; Sun, 31 May 2009 23:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.697 X-Spam-Level: ** X-Spam-Status: No, score=2.697 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 6DS9YTYX9IFu for ; Sun, 31 May 2009 23:06:42 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id E5EFE3A68E3 for ; Sun, 31 May 2009 23:06:41 -0700 (PDT) Received: from [127.0.0.1]([59.66.24.111]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54a23e5cb; Mon, 01 Jun 2009 14:06:38 +0800 Message-ID: <4A236FE0.60804@cernet.edu.cn> Date: Mon, 01 Jun 2009 14:06:24 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <02cb01c9d9b4$33089170$c5f0200a@cisco.com> <406295AC-660F-4DFB-86ED-5A61B2379BF1@muada.com> <4A153355.9000401@cernet.edu.cn> <4A1587AF.9080608@it.uc3m.es> <4A20FB9F.5050105@cernet.edu.cn> <37960EC4-AF9C-44DD-B61A-F6C5D38EDBF0@muada.com> In-Reply-To: <37960EC4-AF9C-44DD-B61A-F6C5D38EDBF0@muada.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: fWYfALWB Cc: Behave WG Subject: Re: [BEHAVE] interim meeting minutes X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2009 06:06:43 -0000 Iljitsch van Beijnum 写é“: > On 30 mei 2009, at 11:25, Xing Li wrote: > >> NAT64 (stateful and stateless) >> NAT46 (stateful and stateless) > > In the stateless case NAT64 and NAT46 are the same. > > I would prefer to keep "NAT" for stateful unless specifically > indicated that it's stateless. We could keep SIIT for stateless > translation. SIITbis? since it is different from the original SIIT. xing > >